Novamente ao atualizar o kernel o driver não compilou e novamente foi simples patchear. Dessa vez foi este o erro:
/tmp/2009_1204_RT3070_Linux_STA_v2.1.2.0/os/linux/../../os/linux/rt_linux.c:1522:10: error: unknown field 'ndo_set_multicast_list' specified in initializer
O campo ndo_set_multicast_list foi removido do struct net_device_ops do kernel, em
include/linux/netdevice.h por cair em desuso. [1]
Neste caso, basta remover a linha 1522 do arquivo os/linux/rt_linux.c do driver e o driver volta a compilar, mas precisa
também das alterações explicadas no post DWA-125 x Linux 3.0.0.
Quem usa algum adaptador wireless USB num desktop já deve ter passado por situação similar. Depois de ressucitar meu desktop, eu instalei o Debian Wheezy (atual testing) a partir de um DVD e este veio com o kernel 2.6.32 pois o meu DVD não foi baixado recentemente. O meu adaptador D-Link DWA-125 ainda precisava do driver.
Achei um driver no site da própria D-Link [1] e aqui cabe um parênteses: muito legal ver que fabricantes tem se preocupado com os usuários do GNU/Linux. O suporte ao pinguim ainda pode melhorar muito, mas já demos o primeiro passo.
Ao baixar o driver, este compilou normalmente com o make e instalei com o make install. Funcionou perfeitamente e fui atualizar o Wheezy. Eis que começa a saga. O Wheezy está com o kernel 3.0.0 e o driver da D-Link para o DWA-125 data de 2009. De lá para cá, houve várias mudanças no kernel e por conta disso o driver não compila. Como o driver é aberto, comecei a debugar os erros do make. Vamos lá:
$ make
/home/fernando/2009_1204_RT3070_Linux_STA_v2.1.2.0/os/linux/../../common/rtmp_init.c:3710:2: error: implicit declaration of function ‘init_MUTEX’ [-Werror=implicit-function-declaration]
Pelo que andei lendo na internet, a função do kernel init_MUTEX (linux/config.h) foi substituída pela sema_init (linux/semaphore.h). Isso explica o erro do make. Então fui no arquivo de cabeçalho do driver include/rt_config.h e adicionei logo abaixo da linha 42 o novo include:
#include <linux/semaphore.h>
Mas no fonte rtmp_init.c, na linha 3710 que é onde o make dá o erro, teríamos de atualizar a chamada para a nova função. No entanto, pode ser que o driver use semáforos em outros lugares e por isso é preferível adicionar um define para redefinir a função. Fiz isso logo abaixo da linha que incluí no rt_config.h:
#define init_MUTEX(x) sema_init(x,1)
Nova tentativa:
$ make clean && make
/home/fernando/2009_1204_RT3070_Linux_STA_v2.1.2.0/os/linux/../../common/cmm_mac_usb.c:112:4: error: implicit declaration of function ‘usb_buffer_free’ [-Werror=implicit-function-declaration]
/home/fernando/2009_1204_RT3070_Linux_STA_v2.1.2.0/os/linux/../../common/cmm_mac_usb.c:112:4: error: implicit declaration of function ‘usb_buffer_free’ [-Werror=implicit-function-declaration]
Mesmo erro mas para outra função. Desta vez é a usb_buffer_free(). Esta função foi renomeada para maior clareza de código [2] mas a assinatura foi mantida, portanto, basta alterar o nome mesmo. A função usb_buffer_alloc() também mudou de nome, então são mais dois defines:
Lembrando que a licença do driver não permite redistribuição do código alterado. Mesmo assim, o fato do código estar disponível nos permite adaptações deste tipo. Se fosse proprietário, ficaríamos esperando por uma atualização que nem saberíamos se sairia.
Recebi hoje uma mensagem de e-mail
não autorizada (SPAM) com o seguinte conteúdo:
------
from: "sandro ferreira da silva" <sfssaude@hotmail.com>
to: *vários endereços, incluindo o meu*
date: Mon, May 30, 2011 at 12:51 PM
subject: sfssaude:4:51:41 PM:7853751828484559378
mailed-by: hotmail.com
Peguei as fotos do celular, até que ficaram bonitas rsrs..
Beijos !
Em negrito, o primeiro domínio envolvido, webng.com, que é de um hosting americano. Até então nenhuma
novidade, mas o legal é o 302 para um domínio brasileiro, cartomanciaonline.com.br. É lá que está o arquivo
suspeito. Acessei este site hoje e está no ar. O whois retornou que os servidores DNS deste
cara são mantidos pela PPSTech:
Através do chat no site da empresa paulista, denunciei a hospdedagem no arquivo para fins de SPAM
e possível disseminação de vírus. Fui bem atendido pela atendente online Michele, que prometeu
providências por parte da empresa. Avisei também ao hosting americando WebNG do sub-domínio malicioso
(downloadf4) e por fim, encaminhei a mensagem de e-mail para o endereço avs@linhadefensiva.org, galera
do
ARIS-LD que faz um belo trabalho
estudando as pragas brasileiras e ajudando usuários leigos a removê-las.
Agora uma análise básica do arquivo. Não pude ir além porque não tenho uma instalação
de Windows aqui.
$ ls -l IMG2005M.exe
-rw-r--r-- 1 fernando fernando 58880 May 29 02:17 IMG2005M.exe
$ file IMG2005M.exe
IMG2005M.exe: PE32 executable for MS Windows (GUI) Intel 80386 32-bit
Temos um executável de Windows. Para mim, executável com nome de imagem *é vírus*, 100% das vezes. Do
contrário, qual o motivo de tentar enganar o usuário disfarçando o nome do arquivo?
$ pev -c IMG2005M.exe
COFF header:
Machine: 0x14c - Intel 386 and compatible (32-bits)
Number of sections: 3
Date/time stamp: 1306646260 (05/29/2011 at 05:17:40 AM)
Symbol Table offset: 0
Number of symbols: 0
Size of optional header: 0xe0
Characteristics: 0x10f (00000000000000000000000100001111)
IMAGE_FILE_RELOCS_STRIPPED
IMAGE_FILE_EXECUTABLE_IMAGE
IMAGE_FILE_LINE_NUMS_STRIPPED
IMAGE_FILE_LOCAL_SYMS_STRIPPED
IMAGE_FILE_32BIT_MACHINE
Compilado ontem. Alguém não dormiu pra fazer merda...
$ pev -s IMG2005M.exe
Sections:
Name: UPX0
<...>
Vemos o UPX [o packer mais manjado da Terra] no arquivo. O morcegão em questão
não queria que vissem o conteúdo de seu arquivo facilmente e queria reduzir o
tamanho pra facilitar a distribuição do arquivo pela internet. Esperto ele...
A partir deste momento eu já denuncio como vírus. Aliás, desde a mensagem de e-mail
eu já denunciaria, mas de vez em quando gosto de me certificar. Se alguém quiser
prosseguir com a análise pra ver o que ele faz seria ótimo - só falar comigo porque
pode ser que eu arrume um Windows e faça, aí teremos dois trabalhos.
Os eventos de software livre estão bombando. No dia 4 de junho acontecerá o terceiro Fórum
de Software Livre de Duque de Caxias, organizado pelo amigo Alessandro Silva. Ele conseguiu
trazer ninguém menos que
Rasmus Lerdorf, o criador do PHP e
Jon "Maddog" Hall, que dispensa comentários. Já se sabe que são palestras *imperdíveis* no evento.
Além disso, na grade há palestras sobre assuntos variados como Python, SL na educação, Android,
Forense, Telefonia, CMS, Web, DB, enfim, tem pra todos os gostos.
Eu sou voluntário na organização do evento e quero ter trabalho, então vamos lotar esse
evento, valeu? Inscrições e outras informações no site do FSLDC.
No último fim de semana estive no Web Security Forum, em
São Paulo - SP. O evento foi um sucesso. Simplesmente impressionante,
ainda mais em sua primeira edição. Realmente o Gustavo Lima (organizador) soube fazer
um evento que agradou participantes, palestrantes e patrocinadores. Sensacional.
Mais importante que o evento em si, para mim, foi a oportunidade de conversar
com vários hackers brasileiros, inclusive sobre software livre, que não é um tema
muito em alta na scene. Rola um pouco de receio. Não poderia deixar de comentar
que o autor da ferramenta de injeção de pacotes T50, Nelson Brito, me convidou
para transformar o T50 em um projeto open source, sob a GPLv2. Apesar do peso
da responsabilidade, fiquei feliz em saber que teremos mais um projeto open source
100% nacional. O que quero discutir hoje é justamente isso, por que vale a pena abrir o
código de ferramentas de segurança?
A maioria esmagadora deste tipo de ferramenta tem o código fechado. A maioria também
é feita para Windows. Na minha opinião, isso tem que mudar por vários motivos:
- O Windows não reina mais solitário nos desktops.
- Open Source é uma realidade. Lutar contra é correr atrás do rabo.
- Qual o motivo para manter o código fechado? Vou vendê-lo? Se os desenvolvedores pensassem
nessas perguntas antes de distribuir seus softwares, metade deles seriam livres.
- O código aberto incentiva o estudo, eleva o nível do aplicativo (vários contribuidores,
de vários lugares do mundo) e não tira seus créditos. Seu nome estará no programa
para sempre, não se preocupe. Remover isso é ferir os termos da GPL.
Posso citar vários exemplos de softwares que não têm motivo para serem fechados. Além
disso, muitos deles estão completamente desprotegidos e um pouco de ER é suficiente para obter
trechos importantes do código, mas a idéia aqui é repensar nosso objetivo. O que o faz lançar
uma ferramenta?
Se for fama, nada mais respeitável que lançar um SL. Se for trabalho, você ficará numa constante
vitrine por ser o desenvolvedor de um projeto. Se objetivar grana vendendo o software, das duas uma:
dependendo do preço do seu software, ou você não vai vender bem ou vai travar uma eterna luta
contra os crackers, o que pode ter como conseqüência prejuízo nos lucros.
Podemos admitir excessões para projetos grandes, com empresas por trás, como o IDA Pro
ou o Immunity Debugger. Ah, e se você não registrar seu software proprietário, de nada adianta.
Pense bem no quanto se pode aprender gerando um código sob uma licença livre.
Apesar de já termos algumas boas almas liberando projeto
e design de dispotivos de hardware, até o momento ainda
não havia uma especificação concreta para embasar as licenças
livres para hardware. Mesmo podendo registar um hardware em GPL,
por exemplo, as diferenças entre hardware e software geralmente
atrapalham neste ponto e exigem que o hardware tenha uma adaptação
específica de licença. Faltava uma especificação a ser adotada
pela licença livre.
Desde julho de 2010 vem sendo desenvolvida a especificação
OSHW (Open Source Hardware), baseada na OSD (Open Source
Definition), da OSI. Agora publicada em sua primeira versão,
1.0, constam as regras e obrigações que o desenvolvedor do
hardware precisa cumprir para distribuir o hardware sob uma licença livre.
Interessante ver também que várias pessoas e organizações aprovaram
a especificação OSHW. Uma delas foi Massimo Banzi, co-fundador do
projeto Arduino.
Essa semana recebi a triste notícia do falecimento de uma
pessoa com quem trabalhei fazem alguns anos. Em 2008 tive o prazer de
conhecer Sergio Romaguera, figura famosa na divisão
de PABX da Ericsson Brasil (atual Aastra).
Na época trabalhamos com um soft PBX chamado MX-ONE, que rodava sobre um SUSE. Um pequeno
problema com este soft PBX era a impossibilidade de acesso remoto via
porta serial (modem), como nas versões tradicionais de PABX. Já que
estávamos numa distro Linux, procurei uma maneira de habilitar a porta
serial (que existia na caixa), mas não bastava. Faltavam os anos de
experiência com transmissão serial que só o Sergio Romaguera tinha. Foi ele
quem me ajudou a concluir o trabalho. O resultado foi um pequeno utilitário
chamado mxtools, que compartilho aqui. Como não é um projeto que manterei, não
vou falar muito sobre, mas há alguma documentação com ele.
O real motivo deste post é despedir do amigo, que escolheu descançar por hora.
Sem dúvida alguma, ele está rindo deste software que fizemos juntos. Obrigado
pelos ensinamentos, Serginho!
É com grande alegria que bebemoraremos o lançamento da nova versão do
Debian, o 6.0 (Squeeze) no Rio de Janeiro. Todos estão convidados,
inclusive quem não usa Debian ainda e
iniciantes no mundo GNU/Linux! O objetivo é
reunir os usuários do Debian e discutir sobre este maravilhoso SO,
discutir como contribuir para melhorar cada vez mais o projeto e, claro,
beber umas cervejas em homenagem.
O lançamento do Squeeze está programado para o primeiro fim de semana
de fevereiro. Por isso, a nossa comemoração no Rio será no dia 4 de
fevereiro, uma sexta.
Haverá
Debian Release Parties em todo o mundo! Por isso, se ainda não
o fez, organize um na sua cidade! O Brasil tem que fazer bonito nessa!
Data: 4 de fevereiro de 2011.
Hora: 19:00h.
Local:
Restaurante Cataroca - Rua da Carioca, 47 - Centro.
O que levar: Dinheiro e notebook, se quiser. :)
O Cataroca conta com wifi, projetor e cervejas de diferentes marcas.
A entrada é gratuita. Nos encontramos lá! o/
Uso o Gnome há muitos anos e sempre procuro contribuir com os softwares que
utilizo, dentro de meus limites de tempo, conhecimento e dinheiro.
Divulgo a maioria, se não todos os softwares livres que uso mas hoje quero
falar de uma forma de contribuição que ajuda bastante: a doação. Pois é, falou
em dinheiro, a coisa muda de figura. Porém, sejamos mais brandos em nosso
julgamento: a doação não pode ser confundida com pagamento pelo uso do software.
Não! Doar é uma das formas de contribuir para que o projeto continue, cresça e
apareça. Aliás, se formos colocar na ponta do lápis, a doação é livre e a
maioria não pagaria o software (se ele fosse proprietário). Com essa idéia,
doei 30 dólares para o projeto Gnome, via cartão de crédito. Decidi que podia
ajudar este projeto do qual tanto tiro proveito mas há várias outras formas
de doar e ajudar.
Todos os que colaboram com o Gnome recebem o título de "Gnome friend", ou
"amigo do Gnome". E como forma de gratidão, são enviados à casa do contribuidor
um kit com presentes. No meu caso, um mouse pad, adesivos e uma carta de
agradecimento assinada pelo diretor da fundação Og B. Maciel.
Eu adorei o presente, mas presente mesmo é poder contar com este excelente
ambiente gráfico, de forma livre e gratuita. Obrigado, projeto Gnome.