blog do Zé

Se você recebeu um email do malhafina@receita.gov.br com o assunto IRPF2007 não se preocupe. Nem se anime. Não é nem malha fina, nem restituição. É só um meliante que está coletando emails de contribuintes dessa forma.

Vou aproveitar essa mensagem para lhes mostrar como é que eles coletam emails de vítimas dessa maneira. No Thunderbird(cliente de email primo do Firefox) é só acessar o menu View e clicar em “Message Source” para você ver a mensagem completa incluindo cabeçalhos. No Gmail há uma opção encima da mensagem ao lado direito da hora e data da mensagem, um menu com seta para baixo dá a opção “Mostrar Original” - ou algo assim, porque meu Gmail está em inglês por algum motivo…

Descobrindo a origem da mensagem

Para descobrir a origem de uma mensagem tem que achar o cabeçalho “Received:” com o servidor no qual você confia, normalmente é o que hospeda sua caixa postal virtual. Se for Gmail, será algo tipo mail.gmail.com ou no Hotmail terá algo com live.com e por aí vai.

Podem haver dezenas de Received: porque o email pode ser roteado por diversos lugares antes de chegar ao destino. Tem que encontrar aquele recebido pelo seu servidor que normalmente vem depois do “by”, veja abaixo “by meuservidor.retiradodaqui.com.br (Postfix) with ESMTP….”.

Vejamos, no caso da (provável) fraude do malhafina@receita.gov.br a origem é:

Received: from litio.avenidavirtual.com (unknown [64.79.214.55])
by meuservidor.retiradodaqui.com.br (Postfix) with ESMTP id ************
for <meuemailvitimado@meuservidor.retiradodaqui.com.br>; Tue, 6 Nov 2007 01:16:13 -0500 (EST)

Então a mensagem que recebí diz que partiu do servidor litio.avenidavirtual.com e diz para nós que o IP dessa máquina é 64.79.214.55. Quando verifiquei o IP da máquina litio.avenidavirtual.com percebí que o IP reverso informado no email(64.79.214.55) não bateu com o do DNS principal atribuido a esse nome de máquina. Isso já é indício ou de um servidor mal configurado ou de uma fraude.

Vejam, no shell da minha fiel maquina jimi(hendrix) rodando Linux Slackware (v 10 ainda, velhinho pois não atualizei) o que pude achar sobre esse dominio.

(Nesses exemplos meus comentários começam com ### e não fazem parte da operação.)

### Primeiro verifico o nome reverso desse IP, para saber qual o verdadeiro nome da máquina nesse IP.
[root@jimi ~]# nslookup
> set type=PTR
> 64.79.214.55
Server: 127.0.0.1
Address: 127.0.0.1#53

### Abaixo eles nos informam que se não houver resposta do DNS principal, que os seguintes servidores também contém informações sobre esse domínio.
Authoritative answers can be found from:
avenidavirtual.com nameserver = dns1.name-services.com.
avenidavirtual.com nameserver = dns4.name-services.com.
avenidavirtual.com nameserver = dns2.name-services.com.
avenidavirtual.com nameserver = dns3.name-services.com.
avenidavirtual.com nameserver = dns5.name-services.com.

Os endereços 209.59.199.170 e 64.79.214.55 diferem, longe! Mas isso não significa que sejam 2 pessoas distintas, o dono de um IP pode muito bem ter alugado outro servidor com o IP diferente, em outra cidade. Mas não é o caso : efetuei uma consulta e percebí que os dois IP’s estão em computadores fisicamente localizados em Seattle, estado de Washington nos EUA. Mais um indício de que pertencem à mesma pessoa, mas é apenas um indício. Seattle é grande pra caramba!

De fato acontece que se você acessar o site http://64.79.214.55 e o site http://209.59.199.170, ambos tem um servidor HTTP rodando e redirecionam seu navegador para o URL http://aplicacionesyredes.com/index.swf. E se você consultar o nome aplicacionesyredes.com chegará ao mesmo IP :

[root@jimi ~]# ping aplicacionesyredes.com
PING aplicacionesyredes.com (209.59.199.170) 56(84) bytes of data.

Hmmm. Será que o dono desse domínio está tentando nos enganar e coletar o email de contribuintes brasileiros??? Ou será que alguém usou o servidor dele para servir de boi de piranha e manter-se anônimo?

Vamos ver se o servidor de nosso amigo aceita emails enviados por desconhecidos. Uso o bom e velho telnet, de 40 anos atrás, para me conectar à porta TCP 25 do litio.avenidavirtual.com e tentar forjar um email para mim mesmo. Se chegar na minha conta, saberei que ele pode ter sido vítima. Se for recusado, saberei que é alguém “de dentro” ou que se infiltrou naquele servidor por via ilegal sem o consentimento do proprietário.

Eis a transcrição de minha “conversa” no protocolo SMTP. (Não me pergunte porque tive tempo de aprender esse protocolo, é uma longa história tentando arrumar emprego na Itália gelada em Dezembro de 1997…..)

Lá vai.

[root@jimi ~]# telnet 64.79.214.55 25
Trying 64.79.214.55…
Connected to 64.79.214.55.
Escape character is ‘^]’.
HELO
220 litio.avenidavirtual.com ESMTP
250 litio.avenidavirtual.com
Mail From: <pessoafamosa@umlugarai2007xxyy.com>
### remetente falsificado. Saiba que isso é possivel em muitos servidores. É a ciber-falsidade-ideológica numa boa.
250 ok
Rctp
502 unimplemented (#5.5.1)
### ops, hehehe, digitei errado! agora sim…é RCPT de ReCiPienT caramba!
Rcpt To: <zemeloaquitestando@ABAIXO_O_SPAM2007XX.COM>
### como era pra mim mesmo, eu não fiz nada errado em enviar um endereço falso
553 sorry, that domain isn’t in my list of allowed rcpthosts (#5.7.1)
quit
221 litio.avenidavirtual.com
Connection closed by foreign host.

Vejam! “553 sorry, that domain isn’t in my list of allowed rcpthosts (#5.7.1)”

Quando tentei enviar uma mensagem para mim mesmo usando o servidor deles, ele informa que esse destinatário não é autorizado! Ou seja, quem me enviou email através desse servidor está “autorizado”!

Outro vacilo do meliante…se preocupou em forjar tudo, mas esqueceu de incluir o nome do programa forjado.

Para quem não sabe, os nomes de máquinas que aparecem em cabeçalhos de emails não servem como prova de nada. É a informação faltando ou contraditória que nos diz muita coisa. Vejam acima como foi que não me baseei em qualquer dado fornecido por eles, eu fúi testando aquelas partes do cabeçalho que não são possíveis de forjar(como o IP registrado por minha máquina quando ele se conectou) e a informação que eles se esqueceram de incluir!

O sistema atual que usamos para enviar e receber email foi criado para comunicar alguns milhares de máquinas, numa rede acadêmica onde todo mundo confiava um no outro. Isso parte do pressuposto que ninguém vai avacalhar o sistema. Por isso que hoje, de acordo com pesquisas recentes, mais de 70% de todos os emails do mundo são SPAM.

Justamente porque as pessoas abusam o sistema que foi feito para trabalhar na base da confiança. Podemos afirmar com toda certeza que o email veio do IP 64.79.214.55, mas não posso afirmar que o nome litio.avenidavirtual.com seja realmente desse IP - tudo indica que sim, mas aí há o risco de se condenar uma pessoa inocente. Para descobrir quem é o dono desse IP só a polícia.

Enfim, voltando ao email da malha fina : esse email pode ter 2 propósitos, ou outros, mas eu enxergo dois de imediato.

1) Incriminar o dono do domínio avenidavirtual.com junto à Receita Federal. Vira caso de FBI porque o IP e o domíio estão lá fora. Chances de se interessarem no caso? Zero.

2) Coletar emails de contribuintes.

A hipótese 1 é possível, porém é muito mais provável que eles estejam simplesmente coletando dados de contribuintes e tentando ocultar sua verdadeira identidade por trás do nome falso de máquina informado no cabeçalho.

Coleta de Emails para fins de enviar SPAM

Como funciona?

Veja bem, imagine que eu te mande uma mensagem com ofensas pessoais contra toda sua família. Agora imagine que eu envie essa mesma mensagem a milhões de pessoas com ofensas genéricas para cada um. Milhares irão ignorá-la, mas se eu enviar milhões….haverão, pelo menos, centenas ou milhares de respostas, não acha? Essas respostas, quando recebidas, serão lidas por um robô que pouco se importa com sua árvore genealógica e nem teria qualquer coisa pessoal contra você!

Se você responder com um desaforo, ou qualquer outra coisa, o robô buscará num banco de dados imenso de emails candidatos a vítima o seu email contido na resposta e o marca como “positivo, recebeu o email e respondeu”.

Assim, o robô sabe que seu email existe, que você o confere e, ainda por cima, responde emails de spam. O que eles fazem com isso? Te enviarão milhares de mensagens com propagandas de remédios para impotência e assuntos semelhantes. Moral dessa parte da história: não responda mensagens de quem não conheça!

Neste caso a isca não é uma ofensa, e sim uma mensagem forjada da Receita Federal com um endereço que começa com “malhafina” - ou seja, vai preocupar muita gente que provavelmente irá responder a essa mensagem!

Vamos prosseguir com nossa autópsia de uma fraude.

No cabeçalho percebemos que o email do remetente é pertencente à Receita Federal. Então, se reponsermos à mensagem, não é a Receita que vai receber a resposta? Sim. Seria! Porém, nos cabeçalhos há mais um detalhe oculto:

Return-Path: <root@litio.avenidavirtual.com>

Return Path é equivalente ao endereço de devolução de uma carta postal. Mas esse cabeçalho tem 2 significados. O primeiro é para os servidores que transportam o seu email para o destino e quer dizer “se esta mensagem não chegar por algum motivo, devolva para este endereço.” E o outro significado é para o programa de email da vítima uma vez que a mensagem já chegou(Outlook ou Thunderbird, etc) e significa “quando a pessoa responder a esta mensagem, que seja para este endereço e não aquele no remetente”. Essa mensagem irá para o usuário “root” na máquina litio.avenidavirtual.com em vez de malhafina@receita.gov.br - mais um indício de que se trata de fraude é quando o endereço de retorno é diferente daquele informado como remetente.

Só que esse endereço tem algo de muito especial, que praticamente nos entrega quem é o autor da fraude. O “root” é o dono da máquina!!! Só o proprietário da máquina tem a senha root!! Se fosse um nome como ze_melo_o_vitima@64.79.214.55 eu desconfiaria que alguém bobeou e sua senha foi capturada. Neste caso, se roubaram a senha, roubaram a senha do dono da máquina! E o dono, que é alguém que entende de UNIX, nem percebeu? Novamente, é possível, mas fica mais e mais provável que o autor desse email seja o proprietário da máquina cujo endereço de rede IP é 64.79.214.55.

A informação acima praticamente entregou o autor da fraude. O servidor não roteia emails de fora e o endereço de retorno é do proprietário da máquina litio.avenidavirtual.com. Isso descarta qualquer possibilidade de alguém de fora ter usado esse servidor como testa de ferro pois o único a receber o retorno esse email é ele, o usuário root. Ele escreveu um programa robô e o executou como usuário root para enviar os emails e aguarda as respostas preocupadas de contribuintes querendo saber do que se trata o email vindo de malhafina@receita.gov.br.

O cabeçalho do email inclui, ainda:

X-Account-Key: account****
X-UIDL: T!(!7?”!iY#”L4nX&!G!

(Alguns caracteres foram alterados para não entregar de bandeja ao spammer que meu email existe. Bem, depois deste post acho que pouco importa né rss….)

Esses ítens identificam o robô que enviou a mensagem e o seu identificador único(X-UIDL) como vítima no sistema do meliante. Por que, se a intenção é que você responda à mensagem? Veja bem, porque se você por um acaso fizer como eu, e postar esse cabeçalho em algum forum, o robô deles o encontrará e marcará seu email como ativo do mesmo jeito!!!

Qualquer cabeçalho que comece com “X-” é opcional e pode ser incluído sem risco de afetar a entrega da mensagem. Eu poderia criar o Cabeçalho X-ZEMELO e dizer “X-ZEMELO: visite-meu-blog” sem qualquer problema.

No caso, UIDL é mais importante e significa “Unique IDentification Listing” e o X- já vimos que é um cabeçalho opcional. Pode servir para qualquer coisa, mas eu aposto na minha teoria acima, de que serve para identificar sua mensagem e ter uma confirmação de que ela foi entregue e que seu email existe.

Conclusões
Espero que este post tenha sido útil. Recebí essa mensagem há alguns minutos e decidí compartilhar com vocês um pouquinho mais da minha experiência passada na luta contra o SPAM nos meus servidores.

A tecnología do spam é tão, ou mais, avançada que os anti-virus e de sistemas de proteção. Por isso eles estão vencendo. Numa Revista Wired de vários anos atrás, lí uma entrevista com um spammer da Rússia, radicado nos EUA, que ganhava cerca de U$ 60.000,00 Dólares por semana com spam. Ele gastava U$ 10.000,00 com infraestrutura e tecnologia por mês, e lucrava cerca de U$ 230.000,00 - o valor de uma Ferrari novinha nos EUA. Todo mês. A Lei dos EUA fazía do trabalho dele algo perfeitamente legal, lícito. Acontece que a vizinhança não concordava e o sujeito andava protegido por seguranças particulares porque numa vizinhança da Flórida ele foi descoberto e quase foi linchado na rua.

Enquanto o governo dos EUA, e do Brasil, e da Europa não tornarem o SPAM ilegal, eles continuarão praticando. E não pensem que é fácil ilegalizar o SPAM, não é só culpa dos parlamentares desses países(e do nosso).

Espera aí, mas …você não vai nos dizer quem é o principal suspeito?

Só vou dizer quem é o principal suspeito por um motivo simples: porque se a sua casa estiver sendo usada para o crime, então você é cúmplice. Se ele permite que o seu servidor seja utilizado para tentar capturar emails de contribuintes se passando pela Receita Federal, no mínimo ele tem que explicar o que diabos quer fazer com esses emails. E na pior das hipóteses pode ser ele mesmo o culpado, mas seria muita burrice fazer isso através de um servidor registrado em nome de….

Rafa Couto (dominios@aplicacionesyredes.com)
655454328
Fax:
Apartado Correos 24
A Guarda, PONTEVEDRA 36780
ES

“Rafa Couto”, ou alguém de sua confiança e que tem a senha root do servidor dele, está na España utilizando-se de um servidor em Seattle capturando emails de contribuintes no Brasil? Eu ein! Eu pensei que isso só acontecesse por aqui….. Ou será que o servidor do Rafa Couto foi invadido por um hacker e está sendo utilizado para esse fim? É possível, mas aí ele tem que tomar alguma providência!!

Antes que vocês achem que sou algum tipo de araponga saibam que a informação aí é pública e pode ser obtida por qualquer pessoa usuária de um bom sistema operacional da seguinte forma :

[root@jimi ~]# whois avenidavirtual.com
[Querying whois.verisign-grs.com]
[Redirected to whois.enom.com]
[Querying whois.enom.com]
[whois.enom.com]
=-=-=-=
Visit AboutUs.org for more information about avenidavirtual.com
AboutUs: avenidavirtual.com

Administrative Contact:
aplicacionesYredes.com
Rafa Couto (dominios@aplicacionesyredes.com)
655454328
Fax:
Apartado Correos 24
A Guarda, PONTEVEDRA 36780
ES

Á, e de bonus, se você ficou curioso para saber que sistema ele tá rodando para capturar emails das pessoas - tudo indica que é Linux 2.6. Como a gente sabe sem invadir a máquina dele?

Assim :

[root@jimi ~]# nmap -O 64.79.214.55

Starting Nmap 4.20 ( http://insecure.org ) at 2007-11-23 20:58 BRST
Interesting ports on 64.79.214.55:
Not shown: 1672 closed ports
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
25/tcp open smtp
53/tcp open domain
80/tcp open http
106/tcp filtered pop3pw
110/tcp open pop3
135/tcp filtered msrpc
139/tcp filtered netbios-ssn
143/tcp filtered imap
443/tcp open https
445/tcp filtered microsoft-ds
465/tcp open smtps
593/tcp filtered http-rpc-epmap
993/tcp filtered imaps
995/tcp open pop3s
3306/tcp filtered mysql
4444/tcp filtered krb524
5432/tcp filtered postgres
6667/tcp filtered irc
6668/tcp filtered irc
7000/tcp filtered afs3-fileserver
8443/tcp open https-alt
12345/tcp filtered NetBus
12346/tcp filtered NetBus
Device type: general purpose

Running (JUST GUESSING) : Linux 2.6.X (88%)
Aggressive OS guesses: Linux 2.6.15.4 (88%)

No exact OS matches for host (test conditions non-ideal).
Uptime: 1.057 days (since Thu Nov 22 19:37:35 2007)
Network Distance: 15 hops

O NIST é o departamento americano que é responsável por divulgar normas e diretrizes técnicas para todo o governo dos EUA. Vários países utilizam as normas dos EUA para seus próprios trabalhos técnicos, entre eles o Brasil.

Nos anos 1970, auge de Guerra Fria, o governo dos EUA considerava a criptografia uma questão de seguranca nacional, e com motivo de sobra. Um espião de posse de um algoritmo forte poderia se comunicar com o inimigo bem diante das autoridades sem ser pego. Ou, o mesmo espião, se quebrasse o código americano, teria acesso às informacões mais valiosas dos EUA.

Acontece que o sistema teoricamente democrático(ou mais democrático que os outros) impede que o governo mantenha segredos absolutos por muito tempo. Nessa época, o governo dos EUA decidiu que não se isolaria da comunidade de hackers, matemáticos e estudiosos da criptografia, pelo contrário, trabalharia com eles para avancar estudos na área de criptografia. Não é por serem bonzinhos, estavam apenas sendo fiéis ao ensinamento de Maquiavel : “mantenha seus amigos perto, e os inimigos mais perto ainda”.

Assim, desde então, os EUA publicam algoritmos para uso público e aceitam sugestões e feedback dos cientistas do ramo. Assim eles se mantém à par do que está acontecendo na comunidade acadêmica e tentam manter o segredo sobre outros avancos criptográficos internos do governo.

Acontece que no último lote de algoritmos publicados pelo NIST, os criptanalistas encontraram algo estranho. Um dos pesquisadores mais conhecidos no ramo é Bruce Schneier, quem já citei aquí em diversos posts no passado. Schneier afirma que uma certa sequência de números no gerador de números aleatórios Dual_EC_DRBG recém divulgado pelo NIST tem todo o jeito de ser uma sequência de números que, quando combinada a outra sequência, gera uma espécie de assinatura.

As mensagens criptografadas não podem ter “assinatura”. Devem ser o mais próximo possível de “ruído aleatório”. À partir do momento que se encontram padrões no texto, a mensagem se torna vulnerável a ataques diversos. Um dos códigos alemães mais poderosos foi quebrado justamente porque havia nas mensagens algo em comúm : os 3 caracteres iniciais eram parte da chave e as mensagens eram transmitidas 2 vezes para garantir a entrega. Assim, eles comparavam as chaves com as mensagens e encontraram um padrão. Foram os Poloneses que descobriram esse padrão, mas tarde passado aos Britânicos que entao, sob supervisão de Alan Turing, produziram as máquinas que quebravam os códigos alemães em algumas horas. Sir Winston Churchill acredita que, com a quebra dos códigos alemães, os aliados encurtaram a guerra em pelo menos 18 meses.

Voltando à atualidade, Schneier acredita que a sequência de números publicados pelos EUA tem um padrão reconhecido e que pode ser a metade de uma espécie de chave-mestre. Oculta na sequência de números aparentemente inofensivos, estaria o poder dos EUA lerem tudo o que for criptografado com esse novo algoritmo como se fosse texto normal.

Se a denúncia for comprovada, será a maior gafe científica do governo dos EUA dos últimos tempos. Nos tempos modernos é difícil, senão impossível, guardar um segredo por muito tempo. Eventualmente as fotos de torturas vazam, a informacão corre sem atrito nos dias da internet.

O órgão encarregado da espionagem digital dos EUA é a NSA - a agência de espionagem mais temida do mundo. Seus funcionários sequer fazem compras em supermercados comúns, eles tem suas videolocadoras, seus supermercados, seus grupos de amigos e nada sai da NSA. Eles são a agência que só ouvem, nada falam. Portanto sobre o furo do algoritmo do NIST, eles nada tem a dizer.

Mas Schneier tem certeza da participacão da NSA no esquema do gerador de números aleatórios do NIST. É a NSA que trata de assuntos criptográficos nos EUA, é impossível que não haja participacão deles nesse possível furo.

Com a eficiência demonstrada pela Polícia Federal, aliás que dá gosto ver trabalhar, a bandidagem tem inovado no campo tecnológico.

Nos últimos tempos tenho visto mais e mais anúncios de telefones criptografados para venda na internet. O problema é que, creio, não existe legislação no Brasil que proiba a criptografia em telefonemas.

Enfim, o maior medo do governo dos EUA é a proliferação de aparelhos que utilizam criptografia forte. Se todos os bandidos criptografarem seus telefonemas a Polícia Federal teria milhões de vezes mais trabalho para ouvir as conversas. E provavelmente quando conseguissem finalmente decodificar a conversa, o crime já teria ocorrido.

A solução? O Legislativo precisa, urgentemente, passar legislação para proibir telecomunicações criptografadas sem autorização.

Se o governo Brasileiro quer regulamentar as armas, então tem que regulamentar o uso a criptografia. Porque nos proibir de comprar revólveres de uso civil, ou dificultar ao extremo a venda de armas de fogo, e depois permitir que a criptografia seja usada por qualquer um é apenas mais uma mostra de incoerência e despreparo de nossos Legisladores. Com um revólver você mata uma ou algumas pessoas. Com criptografia você pode armar um ataque terrorista que mataria milhares. Criptografia é uma arma muito mais poderosa que qualquer pistola ou revólver à venda.

Infelizmente nosso Congresso está à beira do colapso institucional. Porque o colapso moral já ocorreu, só falta é fechar a Casa.

Com os Senadores negociando vantagenzinhas e fazendo picuinhas para seus partidos, pode esquecer: espere aí uns 15 anos até eles começarem a passar legislação que regulamente o uso de criptografia forte. Até lá a bandidagem já fez o dever de casa e estarão todos utilizando criptografia em seus telefonemas.

Para quem gosta do Firefox, não deixe de experimentar o navegador que iniciou o projeto Mozilla (Thunderbird, Firefox, Netscape, etc)

Confira aqui.

Segundo um antigo colunista da PC Mag, John Dvorak, o Windows Vista é um fracasso tão gritante que a Microsoft praticamente decidiu continuar melhorando o Windows XP ao invés de empurrar o novo Windows na marra.

Eu não sei bem o que dizer do Windows Vista. Pelo que andei lendo na imprensa técnica é mais ou menos unânime que o Vista é um elefante no sofá da sala(roubando, em parte, expressão usada pelo Mr. Dvorak).

Leia o artigo de Dvorak clicando aqui (em inglês).

Bem, você deve estar pensando o que isso tem a ver com o título do artigo. É que eu não poderia começar um artigo sobre Windows sem antes mencionar a matéria do Mr. Dvorak cujo título pode se traduzir algo como “Monitorando a Morte do Windows Vista”…. Pra não fazer 2 posts, está aí : Dvorak diz que o Vista já morreu a não ser que a Microsoft tome algumas atitudes, as quais você pode conferir na matéria dele.

Voltando ao Windows XP(que ainda não morreu) : O que me deixa grilado é o tal do “Tempo ocioso do sistema” no Gerenciador de Tarefas. Já notou esse ítem por lá? Pois é, se não notou, basta dar o famoso Ctrl+Alt+Del no seu teclado e selecionar a folha de “Processos” no Gerenciador. Olhe lá : seu sistema pode estar uma porcaria de lento e o processo que, em tese, consome a maior parte dos recursos é, geralmente, o “Tempo ocioso do sistema”.

O que é esse tal tempo ocioso? De ocioso não tem nada. “Tempo ocioso” foi o termo que o departamento de marketing da Microsoft encontrou para deixar o sistema “mais amigável”. Acontece que praticamente tudo de importante no Windows acontece no Tempo ocioso do sistema. Difícil de acreditar? Mas é verdade.

Explico.

O tempo ocioso do sistema é o que os técnicos chamam de “system time”. O sistema operacional tem que fazer milhões de coisas para seu Word ou Internet Explorer funcionarem. O gerenciador de tarefas mostra os processos em execução no momento, mas o trabalho realizado pelo sistema operacional Windows(ou, em termos de UNIX, o kernel do Windows) aparece nessa lista como Tempo ocioso.

Por exemplo. Todo acesso a rede envolve, necessariamente, um dispositivo físico para acesso à rede. Digamos, uma placa de rede comúm de R$ 25,00. Essa placa se comunica com o Windows através de um programa “driver”, ou “condutor” em português. Esse programa funciona dentro do kernel do windows, lá no centro do sistema operacional. Como esse driver funciona e os detalhes de como ele entra no centro do Windows são um assunto à parte. Quando você envia um email, ele é traduzido do idioma humano e vai sendo colocado dentro de “envelopes”. Para um email sair de seu computador e chegar ao outro lado do mundo, ele é embrulhado aproximadamente em 7 ou 8 envelopes distintos. Os vários encaminhadores pelo caminho vão abrindo os envelopes até que chega ao envelope final que é o endereço de email de seu recipiente.

Quando essa mensagem passa do seu programa de email e vai para ser “envelopado”, adivinha quem está trabalhando? O tempo ocioso do sistema.

Quando você copia um arquivo. O explorer pede ao “tempo ocioso do sistema” que efetue a transação de disco, lhe forneça um arquivo aberto, copie o arquivo, etc.

Quando você clica em outra janela e alterna entre programas, o explorer pede ao “tempo ocioso do sistema” que efetue os trabalhos necessários para que a tela seja desenhada corretamente, etc e o novo programa apareça feito mágica para você.

Quando você liga o Windows e aparece aquela tela inicial preta com o logotipo no centro, lá atrás o “tempo ocioso do sistema” está ocupadíssimo tentando fazer tudo funcionar o mais normalmente possível.

E por aí vai. O tal do tempo ocioso do sistema normalmente é o que trava minha máquina. Decidí escrever este post porque há uns 15 minutos o tal do tempo ocioso estava trabalhando feito um louco e me deixou aquí esperando…. Eu acessei uma pasta Samba num servidor Linux do outro lado da rede. Como havia esquecido de ligar o servidor Linux os “envelopadores” dos protocolos de rede não tinham resposta….o “tempo ocioso do sistema” tomou conta e travou até que descobriu que o Linux do outro lado da rede estava desligado. Um minuto depois o Windows em avisou “Este recurso de rede não está acessível e blah blah blah”.

Os marketeiros exigiram da Microsoft que chamassem a parte do sistema que mais trabalha de “Tempo ocioso do sistema”… Normal, vindo da Microsoft.

Ontem reencontrei os amigos Sandro e Mariana que passam o fim de semana em Brasília. Combinamos uma sessão de “filme horrível” na casa do nosso querido Mateus Tormin e, acreditem, o filme que Mateus escolheu era deveras horrível. Bem, acontece que Sandro e eu fundamos o Perl Mongers Brasilia em 1999, que era na verdade uma desculpa pra tomar cerveja e falar de Perl, e ontem o Sandro chamou minha atencão porque há tempos neste blog, segundo ele, “você só fala em Hugo Chavez e CPMF e onde diabos está o Perl!!??”. Claro que ele está com a razão e hoje decidí tentar recomecar a secão Perl aqui do blog que tem apenas uns 3 posts….

O assunto deste post é o operador de teste de arquivo -M

Ao trabalhar com o operador -M $ARQUIVO para obter o número de dias desde que $ARQUIVO foi alterado, deve-se observar que a forma como Perl trabalha com esse operador não é exatamente intuitiva.

Quando você testa um arquivo com -M, espera obter o tempo desde que foi alterado até o instante em que o operador -M é utilizado. Mas não é isso que acontece.

Perl irá lhe retornar o tempo de modificacão do arquivo até o momento em que o programa foi executado.

Se o seu programa utiliza o operador -M e é um servidor de rede, ou daemon local, ou qualquer processo que permaneca em funcionamento durante longos períodos, o resultado pode ser um desastre.

Veja o seguinte exemplo:


#!/usr/bin/perl

$data = -M "/etc/passwd";
print "$data\n";


Normalmente esperaríamos que a segunda chamada a -M, após 30 segundos, retornasse uma fracão do dia 30 segundos maior(lembre-se, -M não retorna segundos como time(), e sim o número de dias e a fracão do dia atual desde que o arquivo testado foi alterado).

Rodando o programa acima vemos que os 30 segundos não influenciam em nada o resultado de -M


root@clapton:~/perl# perl modificado.pl
514.301099537037
514.301099537037


Vejamos alguns casos em que isso pode causar problemas:

1) Voce utiliza -M para decidir se um arquivo de log deve ser arquivado e um novo criado(estilo logrotate). Neste caso o arquivo irá crescer infinitamente pois seu programa não verá qualquer diferenca na data de modificacão à partir do momento em que o programa é rodado.

2) Você utiliza -M para verificar se arquivos de sistema sofreram vandalismo, algo estilo tripwire. Também não vai funcionar, pois se o arquivo de sistema sendo monitorado for modificado após o nosso programa monitor ser rodado o tempo entre o retornado por -M e a data de alteracão será negativo! O que não faria sentido. Seria um bug difícil de encontrar e remover.

3) Você utiliza -M para decidir se deve, ou não, efetuar backup de um ou mais arquivos. Neste caso pode ocorrer o efeito da data negativa do exemplo 2 e seus backups de dados valiosos podem não ocorrer conforme planejado.

Então, o que fazer?

Claro que em programas quebra-galho, que rodam em minutos ou segundos, a não ser que se estejam organizando longas listas de arquivos por data de modificacão, provavelmente não será preciso se preocupar com isso.

Já em programas de longa duracão será preciso ter cuidado. Como todos os problemas em Perl, há sempre mais de uma solucão.

As duas solucões que conheco utilizando -M envolvem refrescar a data inicial à partir da qual -M efetua sua comparacão. E qual é essa data? É aquela gravada na variável especial $^T.

A terceira solucão que encontrei é deixar de usar -M em favor de stat().

Confira o seguinte programa:


#!/usr/bin/perl

print "$^T\n";
sleep(30);
print "$^T\n";


Rodando, temos o seguinte resultado:


root@clapton:~/perl# perl modificado2.pl
1194827682
1194827682


Aí está o nosso culpado. -M utiliza $^T para determinar a data de modificacão dos arquivos mas $^T não muda durante o runtime de nosso programa. Assim, tenho em mente as seguintes solucões, crie a sua ou escolha a mais apropriada.

Solucão 1 - refrescar $^T toda vez que usar -M.
Exemplo:

#!/usr/bin/perl

# mais tarde...
$^T = time();
$data = -M "/etc/passwd";
print "$data\n";


Solucão 2 - criar um timer com signal handler que refresca $^T para voce periodicamente. Assim há menos risco de você esquecer de refrescar $^T antes de uma chamada.

Exemplo:

#!/usr/bin/perl

# $^T deve estar atualizado, com um erro máximo de 5 segundos
# ajuste o valor do tempo do alarm de acordo com a necessidade
print "$^T\n";


Rodando o código acima, substituindo #….. PROCESSO DE LONGA DURACÃO ….. por um sleep(30), obtemos:


root@clapton:~/perl# perl modificado_alarm.pl
1194828811
1194828816


Percebeu que o tempo inicial não é o tempo final menos 30 segundos? Lembre-se que o sleep() acima é apenas para ilustrar um processo demorado. O sinal ALRM interrompe o sleep() aos 5 segundos(tempo que escolhemos para o alarm()) e retorna na linha após ele. Tratar corretamente de sinais UNIX é assunto para outro artigo. Lembre-se que o sinal interrompe tudo que está acontecendo e retorna no procedimento seguinte ao que foi interrompido. Saiba mais clicando aqui(link em inglês, se você conhecer em português por favor indique nos comentários deste post, obrigado).

Solucão 3 - use stat() no lugar de -M

stat() sempre retorna as datas de modificacão em segundos, assim basta subtrair de time() e teremos sempre preciso o periodo desde que o arquivo foi modificado.

Exemplo:

#!/usr/bin/perl

Obtemos:


root@clapton:~/perl# perl modificado_stat.pl
44439213
44439243


Lembre-se que, utilizando stat(), você obtém o retorno em segundos. Se o seu programa utilizar o número de dias e fracão de dia retornada pelo -M você deve se lembrar de converter esse dado dividindo o valor retornado do time() - stat()[9] por 86400(número de segundos num dia).

Como em todos os artigos aqui do blog, se tiver sugestões e outras solucões para este problema, envie através do campo de comentários aqui do blog. As melhores sugestões serão publicadas juntamente com o devido crédito ao autor.

Kopimi, em inglês, é pronunciado “copy me” - ou “me copiem”.

Encontrei enquanto navegava o The Pirate Bay buscando mais informacão sobre o fechamento do OiNK.com. Trata-se de um ícone que você coloca em seu site pedindo para ter seu conteúdo copiado. Ou seja, é uma resposta anarquista à campanha anti-pirataria sendo travada pelas polícias do Reino Unido, Estados Unidos e Holanda(entre outros).

Se você encontrar algum dos ícones abaixo num site, significa uma adesão ao movimento “me copiem”.

Super Mário Galaxy recebeu excelente crítica dos principais sites de gamers.

O jogo não tem terra, nem céu, a única referência é a gravidade que às vezes te puxa para baixo e às vezes para cima. O jogo é completamente 3D e segue a mesma linha do Super Mario 64.

Entre os críticos que lí, todos concordam que o último grande épico do Super Mário foi o 64. Porém eu discordo. O Super Mario World do Nintendo DS trouxe de volta o saudosismo dos jogos 2D dos anos 80.

Confira um dos reviews mais favoráveis aqui(inglês).

Representantes do alto escalão da Deutsche Telekom, HTC, Qualcomm, and Motorola e outros 34 pesos pesados estarão presentes no lancamento do Sistema Operacional Android, da Google. O novo sistema operacional é especialmente

Até onde consigo enxergar, o novo sistema é uma ameaca real e imediata ao iPhone da Apple. É uma resposta ao enorme sucesso do iPhone.

No momento não sei muito sobre o Android, deve ser um sistema muito eficiente e compacto, mas estou, na verdade, pensando na estratégia da Google. Só posso concluir que, ou eles estão fortemente armados, ou estão fazendo um jogo extremamente arriscado.

Por que?

Que a Google confia em seu exército de PhD’s nós já sabemos, lhes dão o melhor ambiente do mundo para trabalhar, pagam bem e portanto tem colhido frutos interessantes das criacões de seus funcionários como o Orkut e Google Earth.

Acontece que, ao desafiar a Apple, a Google abre mais um front de batalha.

Hoje a Google é inimiga da Microsoft em diversos campos, o que por sí só já é um desafio monumental.

No mundo online são, além da Microsoft(portal Live, MSN, etc), inimigos número 1 da Yahoo!.

E agora declaram guerra à Apple?

Das duas uma. Ou a Google está armada até os dentes e pronta para encarar as 3 maiores empresas da Internet hoje, ou eles foram com muita sede ao pote e estão correndo um sério risco. Afinal, o caixa da Microsoft lhes permite comprar a Google à vista e o Yahoo! continua sendo o portal mais visitado da internet.

Enfim, foi essa viagem que me veio em mente quando lí que a Google está lancando um sistema operacional para telefones.

Muito em breve teremos a nova edicão do Linux mais popular : o Fedora Core.

Para quem não acompanhou durante os últimos anos, o Fedora Core é o antigo RedHat Linux. Por sua vez, a RedHat foi a distribuicão mais popular do Linux durante os anos 90 e boa parte do novo milênio. A quantidade de distribuicões que surgiram no mesmo período tirou um pouco da popularidade do RedHat, porém continua sendo a minha distribuicão no ambiente de trabalho.

Em casa lhes escrevo este post no Slackware, que é minha predileta para uso pessoal visto que é preciso entender de Linux para se virar com ela.

Confira aquí o cronograma para lancamento do Fedora Core 8