Jump to content
Belini

Compactar arquivos e extrair sem pedir confirmação

Recommended Posts

Quero fazer um backup de arquivos executáveis para serem restaurados sempre que o programa iniciar e estes arquivos estão dentro de pastas e subpastas, consegui criando um arquivo SFX no winrar e também no 7.zip porém os dois pedem confirmação caso algum arquivo da pasta destino esteja sendo executado e eu precisava substitutuir os arquivos sem avisar que não conseguiu substituir e também sem pedir confirmação caso já exista um arquivo igual na pasta de destino, alguém sabe se é possível fazer isto em Autoit ou conhece algum compactador que funcione da maneira que eu preciso?

Share this post


Link to post
Share on other sites

Olá Belini.

   Suponho que vc está fazendo um backup (zipado) dos arquivos executáveis para alguma eventual contaminação por vírus, principalmente dos envelopadores, correto?

   Não concordo com sua estratégia porque vc estaria resolvendo a consequência e não a causa! E se realmente houver um vírus, mesmo que a cada nova geração de arquivos limpos seja extraída, eles serão novamente reinfectados gerando um loop, ou pior, um dead lock!

   Mesmo assim, estou recomendando uma biblioteca de compactação para utilizar para decompactar os seus arquivos. Acredito que vc já tenha utilizado (ou conheça) esta, mas foi a melhor que encontrei até agora, com uma taxa de compressão muito boa e bem simples de utilizar. É a que eu uso nos meus projetos. O único problema é que é necessário enviar uma DLL junto para que o processo possa ocorrer. E para contornar este problema, eu utilizo com o FileInstall. Segue o link do fórum americano porque por algum motivo não estou conseguindo anexar a LIB na resposta (https://www.autoitscript.com/forum/topic/85094-7zip/).

   Voltando ao problema original que vc descreveu, que é a confirmação da sobregravação dos arquivo EM USO, eu diria que é impossível. É exatamente por este motivo que o próprio Windows pede para reiniciar, pois ele não consegue nem sobrepor os próprios arquivos que estão em uso, portanto não teria como fazer isto diretamente.

   Porém uma alternativa (sem considerar reiniciar a máquina), seria a de utilizar um terceiro programa (ou helper) para efetuar esta tarefa. Este helper pode ser um programa especialmente criado para isto ou uma cópia do próprio programa inicializado especificamente para este fim (minha técnica preferida). De qualquer maneira é preciso um programa externo. Isto SE os arquivos (executáveis ou não) estiverem em uso.

   E finalmente, caso a mensagem de sobreposição não seja mostrada (ou ignorada) e o arquivo não seja sobreposto (dá erro mas não mostra isso), vc não resolverá o problema, visto que o arquivo infectado não seria sobreposto e continuaria sujo, ou seja, de volta ao início!

Share this post


Link to post
Share on other sites

Sim estou tentando resolver o problema de um cliente pelo menos da minha parte pois ele tem lá o win32 sality e o Win32/Injector.EAZJ já mandei hd's limpos prá ele usar como matriz e recomendei que usasse apenas para clonagem mas sempre tem infectado estas matrizes e manda de volta prá mim limpar, fiz testes aqui no hd infectado dele trocando os executáveis assim que o programa abre e deu certo pelo menos enquanto o programa está aberto ele não infecta o problema é que tem outros executáveis que são chamados pelo programa principal e estes estão sendo recontaminados antes de serem chamados prá resolver isto criei dois SFX um contendo todos executáveis prá ser restaurado logo que inicia e outro sem os executáveis que ficam abertos o tempo todo aí coloquei para restaurar este segundo SFX antes de abrir um outro executável, até agora nos testes que fiz está funcionando bem agora vou limpar o HD dele e reinstalar tudo e também vou deixar opcional usar ou não esta restauração pois não faz sentido ficar trocando executáveis que estão limpos aí ele usa esta opção só quando pegar virus de novo, se der certo de não aparecer mensagem quando o programa está em uso ficará melhor pois aí vou usar um backup só mas se não der uso dois mesmo da forma que falei.

Quote

vc não resolverá o problema, visto que o arquivo infectado não seria sobreposto e continuaria sujo, ou seja, de volta ao início!

Os que estiverem abertos terão sido restaurados logo no inicio e durante o tempo que ficarem abertos não serão infectados.

 

 

Share this post


Link to post
Share on other sites

Olá.

   

29 minutes ago, Belini said:

Os que estiverem abertos terão sido restaurados logo no inicio e durante o tempo que ficarem abertos não serão infectados.

   Exatamente pelo mesmo motivo que vc não consegue sobrepor os arqs que vc quer descompactar, pois estão em uso.

   Vc até pode mandar um HD limpo para seu cliente, mas avise ele que:

  1. Tenha um antivírus atualizado, qualquer um, pode até ser o Avast mesmo (arghhh)
  2. Limpe os pendrives
  3. Se estiver na rede, tem que desinfectar a rede também

   Enquanto ele não fizer isto, continuará a ser reinfectado eternamente (e mais 6 meses depois - dizia um colega meu de faculdade kkk)

   Mas ambos os vírus que vc citou são bem antigos. Qualquer AV de hoje pega e elimina antes de dar problema.

   O Sality é o mais chato, porque é um envelopador, o outro é apenas um keylogger. Provavelmente o Sality deve estar em algum programa que ele utiliza que não está no HD que vc mandou ou até mesmo em um pendrive infectado, portanto começe desativando o AUTORUN das mídias removíveis. Isto ajuda bastante.

   Para identificar o arquivo zero, tem que varrer TODOS os HD e mídias removíveis, até mesmo CD's que podem ser sido infectados previamente à gravação.

  Como esta é a minha linha principal de trabalho, sei que este tipo de vírus é muito chato de remover, pois o cliente sempre tem um arquivo infectado em algum lugar que depois reinfecta tudo novamente! É um saco mesmo.

   Boa sorte!

Share this post


Link to post
Share on other sites

Ele conseguir limpar tudo por lá é sem chance mesmo pois tudo que ele tem lá tá infectado e anti-virus ele disse que não gosta porque não deixa ele trabalhar, falou que fica bloqueando tudo e deletando arquivos dele isto logicamente porque tudo dele tá infectado aí pedi prá ele fazer uma cópia do que estou mandando e usar só esta cópia em alguma placa dele quando precisar fazer cópias ou atualizações nos clones dos hd's que mandei prá ele e sempre formatar um pendrive antes de plugar lá mas duvido que vá seguir os consehos por isto já estou tentando me precaver, outra coisa que pensei foi deixar os executáveis sem extensão pois usando o comando Run() ele executa mesmo sem ter extensão, será que o arquivo não ter extensão impede que seja contaminado?

Share this post


Link to post
Share on other sites

Uma pratica que "ajuda" a desativar os autorun's da grande maioria dos vírus e criar uma pasta em cada raiz de disco com o nome autorun.inf

Com isso o vírus não consegue criar o arquivo de inicialização, então mesmo que instale, ele não se auto executa a cada inicialização do disco.

Share this post


Link to post
Share on other sites

@Belini

Em teoria, vc deixar o arquivo sem extensão poderia ser uma solução no seu caso, onde os programas são chamados por você através do Run. Em termos genéricos não resolve o problema dele.

Mas isso pode depender de onde o vírus fez seu gatilho, se na chave do registro do arquivo tipo .EXE ou na chamada de execução do SO para eecutáveis. Se for no registro, este método resolve.

Mas é inacreditável que um cara esteja tão "sujo" que não percebe a situação ridícula que se colocou, a ponto do AV "não deixar ele trabalhar"! Caramba!

@mutleey

A ideia é boa, eu mesmo utilizo em alguns clients esta mesma técnica, mas o ideal é desativar o autorun geral, pois caso algun pendrive estranho (ou sem a pasta) apareça, daí recomeça o ciclo de infecção.

Uma outra técnica que existe, quando vc não quer ativar o autorun para um determinado dispositivo (pendrive ou HD) é segurar o SHIFT enquanto espeta o dispositivo. Mantendo o SHIFT pressionado diz pro SO não ativar o autorun para aquele dispositivo.

Segue um arquivo de registro que eu uso para desativar os autorun de todos os drives.

AutoPlay for all drives - Disable.reg

  • Like 1

Share this post


Link to post
Share on other sites

Vou desativar o autoplay como vc's sugeriram também aí pelo menos prá grande parte dos virus já vai resolver, estive pensando aqui se não seria possível criar uma blindagem para aplicar nos executáveis de forma que não fosse possível inserir mais nada neles e que se for possível isto porque não fizeram isto até hoje e tenho um palpite que isto deve ser possível sim e não deve ser tão difícil fazer só que aí tiraria fora todos os antivirus (as vezes acho que eles mesmos são responsáveis por grande parte dos vírus que tem por aí) sendo blindados mesmo que a pessoa pegasse arquivos infectados não passaria para os executáveis dela e aí não causaria estrago nenhum e não faria mais sentido usar anti-virus para proteger dos ataques dos virus.

Share this post


Link to post
Share on other sites

Criar uma "blindagem" acho pouco provável que funcione já que na "raiz" de qualquer software o que roda são instruções assembly..  e isso é universal, independente da linguagem que foi escrita o código original, na essência o que roda são instruções, então  o vírus nada mais é que a inserção de um trecho em assenbly no codigo original do programa.

Share this post


Link to post
Share on other sites

Mas o que pensei foi justamente isto evitar que depois de compilado fosse inserido qualquer coisa na raiz do programa tipo uma trava de segurança que não deixasse nada mais ser inserido no executável.

Share this post


Link to post
Share on other sites

Olá.

   Para o SO (sistema operacional), um arquivo precisa se encaixar nas definições de um programa executável quando:

  • termina com a extensão .COM ou .EXE ou .BAT (arquivo auxiliar) ou .CMD (arquivo auxiliar mais novo) ou qualquer outra reconhecida pelo SO
  • obedece alguns critérios técnicos (como identificação do PE, Data table definida, etc) específico para cada tipo de arquivo
  • existem prerrogativas de segurança para executar o arquivo (usuário, regras, controle de domínio, etc)

   Finalmente se todas estes pré-requisitos forem observados, o arquivo será executado, ou seja, é carregado na memória e transferido o controle à primeira instrução dele. Portanto, o arquivo executável é exatamente como outro arquivo qualquer dentro do computador, seja ele uma foto, uma música, um vídeo, um documento... A única diferença que existe é que em vez de ser um arquivo tipo secundário (que precisa de um outro programa para utlizar), ele pode ser uma extensão (nativa ou não) do SO.

   Infelizmente aqui no Brasil, nossos procedimentos de segurança não são lá grande coisa e por uma questão cultural nos acostumamos a ser sempre o proprietário, dono e senhor do computador e seus programas, inclusive o SO. Isto inclusive explica a nossa resistência, enquando sociedade a não pagar pelos programas que utilizamos.

   Fica difícil se preocupar com se nossos scripts serão ou não copiados ou descompilados, numa clara preocupação com nossos direitos autorais, aprendizado e esforços, porém na maioria dos casos, desrespeitamos os direitos autorais dos outros sem discriminação, ao piratear um Windows, um Office ou qualquer outro software do mercado.

   Mas, tirando esta questão da frente e nos focando no problema em questão, a trava no executável (se houvesse), deveria ser de responsabilidade que quem o criou e não do SO. O próprio programa, poderia em sua inicialização, deveria fazer um auto-diagnóstico e caso se identifique identificado, se auto-encerra.

   Porém esta abordagem traz algumas dificuldades técnicas:

  • muitos desenvolvedores não se preocupariam com este auto-diagnóstico (preguiça)
  • a verificação só pode acontecer com um código de segurança, checksum por exemplo, se este mesmo checksum for externo, pois não há como inserir um checksum no meu próprio programa sem alterar o valor do próprio checksum. Se fosse um checksum parcial, abre uma brecha para modificação, daí não serve (impossibildade técnica)
  • finamente, se o programa se auto-diagnosticar como infectado, mesmo que ele auto-encerre, o objetico do vírus já foi alcançado, pois o vírus vem antes do programa, então no momento que o programa se verifica bichado, é porque o vírus já foi para a memória (atraso)

   A partir daí, para evitar esta situação, seria necessário que o SO fizesse uma verificação antes de carregar o programa, que aliás isto não é tarefa dele (SO), mas do sistema de segurança (AVs). Assim mostramos que mesmo que haja um mecanismo de auto-bloqueio, ele seria inútil por parte do desenvolvedor. E confiar em um software de segurança, por melhor que ele seja, sempre haverá exceções, falhas, janelas de reconhecimento, etc, ou seja, não há como evitar uma virose surja e se instale.

   Porém podemos e devemos tomar algumas medidas protetivas que não só protegem os programas mas também o ambiente que trabalham (SO):

  • manter nosso SO atualizado, limpo e não corrompido
  • usar programas de segurança confiáveis e comprovadamente eficazes (ou no mínimo que sejam menos furados!!!!)
  • utilizar softwares somente de fontes confiáveis ou verificáveis (quase impossível)
  • utilizar as prerrogativas de segurança do próprio SO, como usuários limitados e restrições de segurança de arquivos
  • bloquear os arquivos executáveis para serem apenas lidos e/ou executados mas nunca gravados ou modificados (com restrições de gravação e não atributo RO)
  • aceitar as restrições

   De qualquer maneira, depende muito mais do usuário (e das configurações aplicadas no computador) do que propriamente do desenvolvedor. E mesmo assim, existe a possibildade de uma infecção acontecer devido a fatores ainda desconhecidos.

   Posso citar aqui como exemplos:

  • erro do caminho da DLL: ao fazer a chamada a uma DLL (coisa comum em programas), foi descoberto que havia um erro na chamada do SO e se houvesse uma DLL com o mesmo nome na mesma pasta do programa, esta seria chamada em detrimento à DLL original pretendida
  • modificação do processo de carregamento: muito utilizado pelos vírus envelopadores ou até mesmo os teimosos mesmo, resulta de uma modificação do mecanismo de chamada do executável (por exemplo mudança no registro) de tal forma que quando qualquer executável seja chamado, uma nova cópia do vírus é executada antes do programa original
  • injeção de DLL ou SQL: quando um malware se auto-coloca em uma seção de memória de um programa conhecido, de tal forma que o programa original ao chamar esta porção de código, execute o vírus
  • e tem mais trocentos exemplos...

   Como disse o @mutleey, as instruções são inseridas em código de máquina e a qualquer momento possível onde haja uma brecha para tal.

   A última ideia do @Belini é a mais correta de se usar atualmente, porém demanda que o usuário aceite as restrições impostas a ele para sua própria proteção, o que culturalmente nunca vai ocorrer por livre e espontâna vontade. Veja o caso que estamos falando onde o usuário não usa o AV porque não deia ele trabalhar. O problema é tão grande que ele (usuário) não percebe o absurdo da situação e ainda reclama do AV, que está tentando ajudar.

   Finalmente, tem vários softwares de segurança que ao fazerem a varredura, montam seus próprios checksum (CRC) para identificarem quando houve alterações nos programas e a partir daí, conseguirem bloquear as infecções futuras. Porém o mesmo remédio que ajuda, também atrapalha, pois mudanças legítimas nos progamas (versões novas por exemplo) não são aceitas.

   E se o software perguntar se houve uma alteração e se o usuário confirma a modificação (até para substituir pelo novo checksum), é o espaço de abertura necessário para um malware se instalar, e por onde passa boi, passa boiada!!!!

   Mas e o que vc acham? Teríamos como poteger mais nosso sistemas (progs e SO)???

  • Like 1

Share this post


Link to post
Share on other sites

Eu ainda sou da opinião que o melhor remédio é o próprio usuário... não adianta ter o melhor antivírus do mundo sendo que um simples click de mouse pode infectar o sistema, eu mesmo uso o Microsoft Security Essentials que de longe deixa de ser uma antivírus de ponta, mas sabendo usar e com os devidos cuidados posso afirmar que nunca tive problemas (e o meu ainda fica com a proteção em tempo real desativada)... então resumindo minha opinião acho que "blindar" um programa não seja uma coisa tão fácil já que o próprio Windows tem trocentas brechas que podem ser exploradas.. mas um minimo de conhecimento ao seu uso já minimiza e muito a infecção do SO ou os programas instalados.

Algumas boas práticas que ajudam...
- Criar a pasta autorun.inf na raiz de cada disco instalado no PC.
- Desativar o autorun do Windows.
- Baixar arquivos/programas de sites mais "confiaveis".
- Ao fazer qualquer download antes de instalar/dezipar verificar com o antivírus.
- Ter coerência ao sair clicando em links ou abrir emails, armadilhas é o que não falta na web.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


×