Hoje de manhã, eu baixei os programas de imposto de renda para instalar no meu Debian. Eu já tinha o Java 1.6 instalado. Para quem não tem, basta fazer:
# apt-get install sun-java6-plugin
Isso já irá instalar o plugin para Iceweasel, o Java-bin e o Java-JRE. Depois de baixar os programas do imposto de renda, já como usuário comum, alterei as permissões dos mesmo para 755 ($ chmod 755 <programa>) e executei-os. Repetindo, isso tudo como usuário comum. O IRPF2010linux-x86v1.0.bin foi tranquilo mas o ReceitanetJava2010.02_setup_linux.bin deu o seguinte erro:
eriberto@canopus:~/downloads/irpf$ ./ReceitanetJava2010.02_setup_linux.bin
Assistente InstallShield
Inicializando Assistente InstallShield…
Procurando Java(tm) Virtual Machine…
……………………..The wizard cannot continue because of the following error: could not load wizard specified in /wizard.inf (104)
Depois do erro, rodei novamente o programa com strace, para ver o que estava ocorrendo. Já era suspeito, pela mensagem de erro, que ele não encontrava o Java. O strace confirmou essa hipótese. Veja um trecho do resultado:
stat64(“/usr/jre1.6.0/bin/java”, 0xbff5b740) = -1 ENOENT (No such file or directory)
write(1, “.”, 1.) = 1
write(1, “.”, 1.) = 1
stat64(“/usr/local/jre1.6.0/bin/java”, 0xbff5b740) = -1 ENOENT (No such file or directory)
write(1, “.”, 1.) = 1
write(1, “.”, 1.) = 1
stat64(“/usr/java/jre1.6.0/bin/java”, 0xbff5b740) = -1 ENOENT (No such file or directory)
write(1, “.”, 1.) = 1
write(1, “.”, 1.) = 1
stat64(“/opt/jre1.6.0/bin/java”, 0xbff5b740) = -1 ENOENT (No such file or directory)
write(1, “.”, 1.) = 1
write(1, “.”, 1.) = 1
stat64(“/opt/jre1.6/bin/java”, 0xbff5b740) = -1 ENOENT (No such file or directory)
write(1, “.”, 1.) = 1
write(1, “.”, 1.) = 1
stat64(“/usr/jre1.6/bin/java”, 0xbff5b740) = -1 ENOENT (No such file or directory)
write(1, “.”, 1.) = 1
write(1, “.”, 1.) = 1
stat64(“/usr/local/jre1.6/bin/java”, 0xbff5b740) = -1 ENOENT (No such file or directory)
write(1, “.”, 1.) = 1
write(1, “.”, 1.) = 1
stat64(“/usr/java/jre1.6/bin/java”, 0xbff5b740) = -1 ENOENT (No such file or directory)
write(1, “.”, 1.) = 1
write(1, “.”, 1.) = 1
stat64(“/usr/local/bin/java”, 0xbff5b730) = -1 ENOENT (No such file or directory)
write(1, “.”, 1.) = 1
write(1, “.”, 1.) = 1
Bem, ele estava procurando nos lugares errados porque, no Debian Squeeze, a JVM fica em /usr/lib. Veja:
canopus:~# ls -l /usr/lib/jvm/
total 16
drwxr-xr-x 5 root root 4096 Fev 12 2008 java-1.5.0-gcj-4.3-1.5.0.0
drwxr-xr-x 6 root root 4096 Fev 6 13:58 java-1.5.0-gcj-4.4
lrwxrwxrwx 1 root root 14 Jan 29 00:31 java-1.6.0-openjdk -> java-6-openjdk
drwxr-xr-x 5 root root 4096 Jan 14 09:00 java-6-openjdk
lrwxrwxrwx 1 root root 19 Jan 29 00:32 java-6-sun -> java-6-sun-1.6.0.16
drwxr-xr-x 6 root root 4096 Jan 14 09:01 java-6-sun-1.6.0.16
lrwxrwxrwx 1 root root 26 Jan 29 00:32 java-gcj -> java-1.5.0-gcj-4.3-1.5.0.0
lrwxrwxrwx 1 root root 18 Fev 6 13:58 java-gcj-4.4 -> java-1.5.0-gcj-4.4
Repare que há um link simbólico chamado java-6-sum, apontando para o Java 6 atual (java-6-sun-1.6.0.16). Esse é o nosso alvo. Faremos um link simbólico para ele. Relembrando, o instalador procurou nos seguintes lugares:
- /usr/jre1.6.0/bin/java
- /usr/local/jre1.6.0/bin/java
- /usr/java/jre1.6.0/bin/java
- /opt/jre1.6.0/bin/java
- /opt/jre1.6/bin/java
- /usr/jre1.6/bin/java
- /usr/local/jre1.6/bin/java
- /usr/java/jre1.6/bin/java
- /usr/local/bin/java
Vamos escolher um local para linkar. Sugiro escolher algo em /opt ou em /usr/local, uma vez que são caminhos próprios para aplicações locais (o sistema operacional não altera o conteúdo desses diretórios e as ações ocorridas dentro deles não influenciam no funcionamento do sistema). Assim, emiti o seguinte comando:
# ln -s /usr/lib/jvm/java-6-sun /opt/jre1.6
Com isso, executei novamente o instalador. Resultado:
Com certeza, esta dica servirá também para outras distribuições. Divirta-se com o seu imposto de renda!
————————————————
TWITTER: para saber sobre os meus livros e outras novidades, me siga em http://twitter.com/eribertomota. Prometo que serão mensagens esporádicas. Não pretendo anunciar cada soluço meu. 
Tags:(104), /wizard.inf, 2010, Debian, error, imposto, imposto de renda, InstallShield, IRPF, java, Java(tm), Linux, ReceitaNet, ReceitaNet 2010, renda, Squeeze, Ubuntu, wizard
Um dos principais problemas do comando dd é fazer tudo em silêncio. Com isso, nunca sabemos o que está acontecendo. Uma solução é o comando dcfldd.
O dcfldd mostra o progresso de uma cópia e também calcula hashes. A sua sintaxe básica é idêntica ao do dd. Veja:
# dcfldd if=/dev/sdb of=imagem-hd.img
A diferença é que ele mostra o progresso da cópia. Veja outro exemplo:
canopus:~# dcfldd if=/dev/sda1 of=1GB_de_particao-windows.img bs=1MB count=1024
512 blocks (512Mb) written.
Ele também pode calcular hashes e faz isso enquanto copia os dados, tornando a operação muito mais rápida. Vamos ver os hashes MD5 (default), SHA1 e SHA512:
canopus:~# dcfldd if=/dev/sda1 of=1GB_de_particao-windows.img bs=1MB count=128 hash=md5,sha1,sha512
Total (md5): 7967be906cf636a47cccf1fae753ec27
Total (sha1): 8764f7bb5a8e7ffce331c20f24480523ac0a406c
Total (sha512): 12537e2268ad55533741317806c99d774461f7d3c0456197859410eff6a782135f99161d543c981d9b62d1bf6021be9caad8318dde422e7e2d3771c4793365b8
128+0 records in
128+0 records out
Se você quiser, ele coloca o resultado do hash dentro de um arquivo. Vamos fazer isso com o MD5 e o SHA512. O SHA1 vai apenas aperecer na tela. O comando final é o seguinte:
# dcfldd if=/dev/sda1 of=1GB_de_particao-windows.img bs=1MB count=128 hash=md5,sha1,sha512 md5log=particao.md5 sha512log=particao.sha512
Para medirmos a diferença de tempo entre o dd + cálculo de hash e o dcfldd, vamos emitir duas linhas de comando. A primeira:
canopus:~# time dd if=/dev/sda1 of=1GB_de_particao-windows.img bs=1MB count=128; time md5sum 1GB_de_particao-windows.img; time sha512sum 1GB_de_particao-windows.img
128+0 registros de entrada
128+0 registros de saída
128000000 bytes (128 MB) copiados, 1,89711 s, 67,5 MB/s
real 0m1.932s
user 0m0.000s
sys 0m0.688s
ebfad6c49d035bb6047f192e109a9676 1GB_de_particao-windows.img
real 0m0.549s
user 0m0.396s
sys 0m0.108s
82b67eadd8fe07ee4db737006f7aa8225936867cdc4f76bb9af618593d5a634c7e1cf8d5fdb5321a0e49f2db3be2ea2bb5d20a7d203ad6f9f3370cc85ac9a8a5 1GB_de_particao-windows.img
real 0m7.449s
user 0m7.180s
sys 0m0.132s
O tempo total foi (1.932 + 0.549 + 7.449) = 9.93s. Agora veja o dcfldd:
canopus:~# time dcfldd if=/dev/sda1 of=1GB_de_particao-windows.img bs=1MB count=128 hash=md5,sha512
Total (md5): 7967be906cf636a47cccf1fae753ec27
Total (sha512): 12537e2268ad55533741317806c99d774461f7d3c0456197859410eff6a782135f99161d543c981d9b62d1bf6021be9caad8318dde422e7e2d3771c4793365b8
128+0 records in
128+0 records out
real 0m7.523s
user 0m6.136s
sys 0m0.696s
Resultado: mais rápido! E isso fica mais evidente em imagens grandes. Bom proveito.
Tags:dcfldd, dd, Debian, Forense computacional, Linux, Segurança
Posted by Eriberto on fev 28, 2010 in
Forense computacional,
Hardware,
Kernel,
Linux Em forenses computacionais, muitas vezes, precisamos realizar um dump de memória. Isso sempre pode ser feito com o comando dd. Veja:
# dd if=/dev/mem of=memoria.dump
No entanto, as pessoas têm reclamado que, ultimamente, o seguinte erro tem aparecido:
dd: lendo "/dev/mem": Operação não permitida
ou
dd: reading `/dev/mem': Operation not permitted
Este foi o fato que gerou este post.
O erro mostrado ocorre porque, há algum tempo, o kernel 2.6 tem vindo com a opção CONFIG_STRICT_DEVMEM habilitada por default. Essa opção protege a memória contra acessos que não ocorram via dispositivos específicos. Para ver isso no Debian, por exemplo, basta executar o comando a seguir:
# cat /boot/config-* | grep CONFIG_STRICT_DEVMEM
Uma solução é utilizar o módulo fmem, disponível em http://hysteria.sk/~niekt0/foriana/. Ele é de fácil compilação e fornece os dados desejados. É necessário ter o cuidado de especificar o limite da memória para que ele não entre em um loop infinito. Exemplo:
# dd if=/dev/fmem of=memoria.dump bs=1M count=4096
O valor em count deverá ser trocado pela quantidade de memória em MB. No meu caso, tenho 4 GB = 4096 MB.
Tags:/dev/mem, computador, dd, dump, Forense computacional, Linux, memória, Segurança
Posted by Eriberto on fev 6, 2010 in
Geral,
Hardware Alguém conhece algum modelo de teclado sem numpad, de preferência ABNT2, mas idêntico a um convencional? Gostaria de algo como o mostrado na figura a seguir (editada por mim no GIMP a partir de um teclado comum):
Notem que quero algo como um teclado comum: setas e conjunto de teclas especiais no mesmo lugar. Apenas menor. Como considero que o numpad nem sempre é útil para usuários domésticos, queria um teclado sem ele. Preciso de algo que seja menor mas que não me faça me perder ao digitar.
Grato a quem responder.
A situação
Imagine uma situação: você possui um pendrive ou partição de HD com arquivos do OpenOffice.Org. Por um acidente ou desastre, esses arquivos são perdidos. Eles podem ter sido apagados, a partição pode ter sido formatada ou a área de controle do filesystem foi perdida (ocorrência típica em FAT32 em pendrives). Agora, você precisa recuperar arquivos, inclusive os do OpenOffice.Org (BrOffice.Org).
Procedimentos
Para obtermos sucesso, teremos que empregar algumas técnicas de forense computacional. A primeira coisa a fazer é criar uma imagem da mídia a ser manipulada. Vamos trabalhar com a hipótese de ser um pendrive que pode ser acessado como /dev/sdb. Adote os passos a seguir para gerar a imagem:
# cd
# apt-get install dcfldd
# dcfldd if=/dev/sdb of=pendrive.img
Uma vez gerada a imagem, poderemos utilizar o foremost e o magicrescue para recuperar os arquivos do OpenOffice.Org. No entanto, antes, é necessário entender o padrão ODF, utilizado pelo OpenOffice.Org.
Vamos analisar um documento .odt. Abra o OpenOffice.Org (ou BrOffice.Org) e gere um arquivo no Writer. Escreva a palavra “teste” e salve como arquivo.odt dentro de um diretório vazio (para fins didáticos, vou considerar /tmp/doc). Esse arquivo.odt é, na verdade, um monte de arquivos e diretórios “zipados” com o padrão PkZip/WinZip. Siga os procedimentos:
# apt-get install unzip
# cd /tmp/doc
# unzip arquivo.odt
Descompactado o arquivo.odt, surgiram os seguintes arquivos e diretórios:
Configurations2 content.xml META-INF meta.xml mimetype settings.xml styles.xml Thumbnails
Esses elementos formam os arquivos gerados pelo OpenOffice.Org quando clicamos em salvar. O texto digitado pelo usuário está dentro do arquivo content.xml. Então, uma conclusão importante: os arquivos do OpenOffice.Org são do tipo zip e sempre conterão, dentre outras coisas, um content.xml. Guarde esta informação; ela é essencial.
As ferramentas foremost e magicrescue permitem recuperar arquivos, por padrões, a partir da leitura da superfície de um disco (e a imagem é a cópia de uma superfície de disco). Vamos recuperar os arquivos do padrão zip, existentes na imagem, com o foremost.
# cd
# apt-get install foremost
# foremost -t zip -o zips pendrive.img
Com o comando anterior, será criado um diretório zips, contendo todos os arquivos .zip encontrados na imagem. Se preferir o magicrescue, utilize a sitaxe a seguir:
# mkdir zips2
# magicrescue -r zip -d zips pendrive.img
Ao final do trabalho é possível notar que o foremost é bem mais rápido. No meu caso, em uma situação real de recuperação de dados em uma imagem, o foremost encontrou 5.044 arquivos zip, enquanto o magicrescue encontrou 5.017 arquivos. Então, aconselho a sempre buscar arquivos utilizando os dois programas.
Depois de encontrados os arquivos, com todos no mesmo diretório, elimine os duplicados. Para isso:
# apt-get install fdupes
# cd <diretório_com_arquivos_zip>
# fdupes -d -N .
IMPORTANTE: na última linha, note o ponto no final.
O próximo passo será descobrir quais arquivos zip poderão ser arquivos gerados pelo OpenOffice.Org. Para isto, basta procurar por “content.xml” dentro dos arquivos. Um grep resolve isso:
$ grep content.xml *
Por fim, abra cada arquivo e verifique o seu conteúdo. Utilize o comando ooffice. Exemplo:
$ ooffice 02268560.zip
A seguinte linha poderá ser útil:
for i in $(grep content.xml *|cut -d" " -f3); do ooffice $i; rm -i $i; done
Essa linha mostrará o conteúdo de cada arquivo no OpenOffice.Org e, em seguida, perguntará se você deseja apagar tal arquivo. Isso será feito arquivo por arquivo e sempre será pedida a confirmação para apagar. É MUITO IMPORTANTE notar que o mesmo documento poderá aparecer várias vezes, em várias versões salvas pelo usuário durante o seu tempo de confecção ou como cópia gravada em outra área do disco. Então, seja criterioso ao analisar cada documento. Uma dica é observar o seu tamanho (teoricamente quanto maior mais recente, caso tenha conteúdo adicionado constantemente) e as propriedades de edição (no OpenOffice.Org: Arquivo > Propriedades).
Extensões suportadas
FOREMOST. Na versão 1.5.6, as seguintes extensões são suportadas: avi, bmp, cpp, doc, exe, gif, htm, jpg, mov, mpg, ole, pdf, png, rar, riff, wav, wmv, zip.
MAGICRESCUE. Na versão 1.1.8, as seguintes extensões são suportadas: avi, canon-cr2, elf, flac, gimp-xcf, gpl, gzip, jpeg-exif, jpeg-jfif, mp3-id3v1, mp3-id3v2, msoffice, nikon-raw, perl, png, ppm, zip.
Palestra sobre Forense
Disponível em http://www.eriberto.pro.br/palestras.
————————
TWITTER: para saber sobre os meus livros e outras novidades, me siga em http://twitter.com/eribertomota. Prometo que serão mensagens esporádicas. Não pretendo anunciar cada soluço meu. 
Tags:arquivos, broffice, broffice.org, Debian, files, foremost, forense, Forense computacional, forensics, Linux, magicrescue, odf, odg, odp, ods, odt, openoffice, openoffice.org, recover, recovering, recuperação
Posted by Eriberto on jan 31, 2010 in
Debian Squeeze,
Hardware,
Sistema Operacional Aqui continua a minha saga com o Squeeze. Desta vez tive problemas com o som. Não há mais alsaconf porque o mantenedor do alsa-utils (pacote que engloba o alsaconf) alega que o alsaconf tem muitos bugs e é de difícil manutenção.
Na quinta-feira passada conectei a minha webcam Microsoft Lifecam VX-1000 para falar com o meu editor e amigo Rubens Prates. A webcam funciona MUITO bem no Kopete do KDE4 (não fica escura). Desliguei o computador no fim do dia. No dia seguinte, o som não funcionava. O KMix mostrava somente o mic da webcam. Então, despluguei a webcam e rebootei a máquina (eu podia ter descarregado os módulos mas estava tentando recriar o cenário anterior). O som voltou a funcionar. Lendo a documentação do Alsa e consultando a Internet, descobri que a webcam estava sendo carregada antes da placa de som (que é on-board em uma placa-mãe Intel).
Procurando pelo fato no Google, encontrei o bug #524196, que dizia:
There are snd cards supported being that driver which one wants to be the first card. So in your case a file /etc/modprobe.d/sound.conf which encloses:
alias snd-card-0 snd-yourdriver
options snd-yourdriver index=0
alias snd-card-1 snd-usb-audio
options snd-usb-audio index=1
No meu caso, com o auxílio do comando lsmod, descobri que o driver correto é o snd_hda_intel. Então, o meu /etc/modprobe.d/sound.conf ficou assim:
alias snd-card-0 snd_hda_intel
options snd-snd_hda_intel index=0
alias snd-card-1 snd-usb-audio
options snd-usb-audio index=1
Com isto, o dispositivo de som Intel será carregado, no boot, antes da webcam. Provavelmente o alsaconf teria feito tudo isso para mim. Mas não há mais alsaconf no Debian (Squeeze).
Apenas como dica final, caso o som esteja baixo, edite o arquivo /etc/modprobe.d/alsa-base.conf e insira no final:
options snd-hda-intel model=3stack
Posted by Eriberto on jan 28, 2010 in
Curiosidades,
Firefox,
Iceweasel,
Internet Essa eu descobri sem querer. Com o Ctrl + e o Ctrl – podemos colocar ou retirar zoom ao visitarmos um site. Isso quase todo mundo sabe. Semana passada, ao tentar teclar Ctrl -, sem querer, teclei Ctrl 0 (zero). Resultado: descobri que isso faz o site retornar ao estado original (sem zoom ou encolhimento).
Fica a dica para quem não conhecia, como eu.
Posted by Eriberto on jan 28, 2010 in
Debian,
Debian Squeeze,
Linux,
Sistema Operacional Resposta: não. Muitas pessoas estão perdidas porque o Ctrl Alt BS do X Window não funciona mais no Debian Squeeze.
A solução é usar AltGR PrintScreen K.
Agradeço ao Gustavo Noronha (Kov) pela dica.
Posted by Eriberto on jan 28, 2010 in
Curiosidades,
Geral,
Microsoft,
Segurança,
Vírus,
Windows Isso que vou falar agora é a coisa mais “manjada” no mundo da informática. Parece ser algo meio óbvio e muito conhecido por todos. Mas, neste mês de janeiro, me convenci que não é bem assim. Poucos usuários conhecem o truque para evitar que pendrives sejam contaminadas por muitos males (vírus) do Windows. Vários usuários ficaram espantados quando falei sobre isso. Então, quanto mais difundida a ideia, melhor.
Vou explicar a situação para quem não a conhece. Nos CD-ROM autoexecutáveis há um arquivo chamado autorun.inf. Esse arquivo, quando existente, é lido pelo Windows e tudo que há dentro dele é executado. A seguir, um exemplo de autorun.inf:
[autorun]
open=teste.exe
icon=figura.ico
Simples. O arquivo diz que deve ser executado o arquivo teste.exe e que o ícone a ser mostrado será o figura.ico. Então, se isto estiver dentro de um autorun.inf existente em um CD, quando este CD for inserido no leitor de CD-ROM, o teste.exe será executado.
Muitos vírus estão utilizando esse mecanismo para se disseminarem via pendrive. Quando o pendrive é inserido em um computador infectado, o vírus copia executáveis maléficos para esse pendrive e cria um arquivo autorun.inf que irá acionar o executável (que é o próprio vírus). Quando o pendrive for inserido em outro computador, o Windows desse outro computador lerá o autorun.inf e executará o vírus. Resultado: mais um computador contaminado.
Para isentar o seu pendrive desse tipo de mal, basta criar um diretório (conhecido pelos usuários Windows como “pasta”) com o nome autorun.inf no pendrive. Assim, quando o vírus tentar criar o arquivo autorun.inf, não conseguirá porque já existe um diretório com o mesmo nome. Ele irá copiar os executáveis para o pendrive. Mas esses executáveis não serão inicializados por ninguém, uma vez que não há o autorun.inf.
Fica a dica para quem não conhece o tema. Hope this help!
Hoje, no meu trabalho, um usuário relatou que o acesso a sites pela sua máquina estava muito lento. Verificando a máquina (um notebook), constatei a lentidão. Loguei na máquina roteadora local e, com o tcpdump apontado para o IP do referido usuário, liguei o note. Resultado:
17:00:29.928829 IP 172.20.6.101.2658 > 209.191.93.52.80: S 1594643053:1594643053(0) win 65535 <mss 1460,nop,nop,sackOK>
17:00:29.928993 IP 209.191.93.52.80 > 172.20.6.101.2658: S 316183073:316183073(0) ack 1594643054 win 5840 <mss 1460,nop,nop,sackOK>
17:00:29.929223 IP 172.20.6.101.2658 > 209.191.93.52.80: . ack 316183074 win 65535
17:00:29.940210 IP 172.20.6.101.2658 > 209.191.93.52.80: F 1594643054:1594643054(0) ack 316183074 win 65535
17:00:29.940480 IP 209.191.93.52.80 > 172.20.6.101.2658: F 316183074:316183074(0) ack 1594643055 win 5840
17:00:29.940711 IP 172.20.6.101.2658 > 209.191.93.52.80: . ack 316183075 win 65535
17:00:30.039752 IP 172.20.6.101.2660 > 209.191.93.52.80: S 3101095795:3101095795(0) win 65535 <mss 1460,nop,nop,sackOK>
17:00:30.039913 IP 209.191.93.52.80 > 172.20.6.101.2660: S 311045640:311045640(0) ack 3101095796 win 5840 <mss 1460,nop,nop,sackOK>
17:00:30.040127 IP 172.20.6.101.2660 > 209.191.93.52.80: . ack 311045641 win 65535
17:00:30.049620 IP 172.20.6.101.2660 > 209.191.93.52.80: F 3101095796:3101095796(0) ack 311045641 win 65535
17:00:30.049779 IP 209.191.93.52.80 > 172.20.6.101.2660: F 311045641:311045641(0) ack 3101095797 win 5840
17:00:30.049995 IP 172.20.6.101.2660 > 209.191.93.52.80: . ack 311045642 win 65535
17:00:30.144803 IP 172.20.6.101.2662 > 209.191.93.52.80: S 2211717516:2211717516(0) win 65535 <mss 1460,nop,nop,sackOK>
17:00:30.144964 IP 209.191.93.52.80 > 172.20.6.101.2662: S 313679525:313679525(0) ack 2211717517 win 5840 <mss 1460,nop,nop,sackOK>
17:00:30.145178 IP 172.20.6.101.2662 > 209.191.93.52.80: . ack 313679526 win 65535
17:00:30.155046 IP 172.20.6.101.2662 > 209.191.93.52.80: F 2211717517:2211717517(0) ack 313679526 win 65535
17:00:30.155207 IP 209.191.93.52.80 > 172.20.6.101.2662: . ack 2211717518 win 5840
17:00:30.171331 IP 209.191.93.52.80 > 172.20.6.101.2662: F 313679526:313679526(0) ack 2211717518 win 5840
17:00:30.171534 IP 172.20.6.101.2662 > 209.191.93.52.80: . ack 313679527 win 65535
Eram cerca de 7.000 pacotes por minuto. E 209.191.93.52 faz parte do range do Yahoo!.
Resolvi instalar o ZoneAlarm no notebook e o mesmo mostrou dois arquivos estranhos tentando acessar a Internet: avgexem.exe e avgexen.exe. Estes arquivos estavam localizados diretamente em C:\Program File. File sem “s” no fim. Quando bloqueados, o note operou normalmente. Depois de um reboot, ao permitir o acesso dos dois executáveis à Internet, tudo começou novamente.
Depois de detectar o worm e removê-lo (usei um Debian em um pendrive para apagar os arquivos), procurei algo no Google mas encontrei muito pouca coisa. A referência mais importante foi:
http://www.superantispyware.com/malwarefiles/AVGEXEM.EXE.html
