Ir para conteúdo

  • Artigos

    Mostrar todas categorias
    Fernando Mercês
    Introdução
    Em muitas faculdades brasileiras a linguagem C é ensinada aos alunos de cursos de tecnologia. Mesmo assustando os novatos, vários alunos resistem e vencem a matéria. O problema é entender por qual motivo o C foi escolhido para iniciar o curso de programação. Seria uma linguagem didática para se aprender a programar? Um teste para ver quem tem ou não o “jeito pra coisa”? Alguns diriam que o correto seria começar com Pascal, mas há quem defenda linguagens mais modernas como Python, Perl, Ruby ou PHP. E aí, para que serve o C no primeiro período? Neste artigo farei uma análise sobre o que se aprende da linguagem, o motivo pelo qual ela surge no início do curso, seu valor de mercado e o que é possível fazer com esse start que a faculdade nos dá.
    A linguagem C
    A importância histórica da linguagem C é inegável e dispensa maiores comentários. Sabemos que até hoje a maioria dos softwares mais poderosos são feitos em C e/ou C++ (um super conjunto de C, orientado à objetos). O kernel Linux e outros núcleos de SOs são feitos basicamente em C. Muitos drivers de dispositivos como placas de rede, som, vídeo etc são feitos em C. Se contarmos o C++ nesta conta, chegamos perto de 100% dos kernels e drivers. Os interpretadores e compiladores das principais linguagens de programação também não fogem à regra e são feitos em C. Existe uma frase que afirma: metade do universo é feito em C. E é bem verdade. Pelo visto, a linguagem serve para alguma coisa…
    Ensino da linguagem C
    Você acabou de entrar na faculdade, está tendo aulas desta linguagem e não está entendendo nada? Não se preocupe, você não está sozinho. Algumas instituições de ensino acham que C é uma liguagem didática, quando não é. Para se aprender a programar, usa-se pseudo-linguagem, PORTUGOL e ferramentas do gênero. Nem mesmo o Pascal, considerado mais fácil de se aprender que o C, é atraente ou interessante à primeira vista. O grande monstro que aterroriza o aluno é a pergunta: “Por que eu vou fazer isso? Para que?”. Pois é, para que escrever um programa em C que calcule a média de três alunos e imprima na tela? Qual a lição tirada disso? A resposta é simples: nenhuma. A maneira como a linguagem é lecionada tenta empurrar o C guela abaixo em estudantes que viram, por exemplo, Visual Basic e Delphi no segundo grau. Isto é, se é que estudaram tais linguagens ou lembram-se delas. Não poderia dar certo mesmo.
    Antes de criar um programa, o aluno tem que saber o que está fazendo. O que é um programa, para que serve isso, o que é um arquivo executável, um binário, bits, bytes, o processador, dentre outros conceitos importantíssimos antes de se escrever o primeiro “Hello World”.
    O resultado do ensino forçado é o alto íncide de reprovação, abandono, mudança de curso e desistência. É comum encontrar alunos que estão no fim do curso de programação mas ainda não passaram nas matérias mais básicas de C. É o terror da faculdade. Definitvamente, a linguagem C vira uma vilã e a frase mais ouvida nos corredores sobre o assunto é que “C é chato”.
    Por que a linguagem C é chata?
    Porque ela não te mima. Numa escala onde o nível mais alto é o mais próximo da linguagem usada pelo ser humano e o mais baixo, da linguagem usada pelos microprocessadores, a linguagem C é considerada de nível médio. Assembly, por exemplo, é de baixo nível, enquanto Object Pascal (usada no Delphi), de alto nível. Isso significa que para programar em C é preciso conhecer conceitos mais próximos do hardware, que as linguagens de alto nível abstraem para o programador, tornando o trabalho mais fácil. Por isso temos a impressão de que C é chato, difícil, sem sentido. Realmente, sem os conceitos básicos de computação bem sólidos, um código em C pode tornar-se incompreensível. Vejamos um exemplo.
    Um código em PHP (alto nível) para se declarar uma variável e armazenar uma frase nela:
    <?php $str = “Essa é minha string”; ?> Um código equivalente em C, seria:
    void main(void) { char str[] = “Essa é minha string”; } No código em C, uma função teve de ser escrita (a main, que é a função principal de um programa), inclusive com seu tipo de retorno e parâmetros, onde usei void para não retornar nem receber nada. Além disso, foi criado um vetor de caracteres (char) para armazenar a frase. Em C, entende-se como string um vetor de caracteres (ou ponteiro para um conjunto deles) onde o último caracter é o NULL, código 0x00 na tabela ASCII. Tá vendo por que se precisa dos conceitos de computação até para começar uma frase em C? Agora perceba a jogada:
     
    #include <string.h> void main(void) { char str[21]; strcpy(str, “Veja, sou uma string”); } A função strcpy(), fornecida pelo header string.h, copia caracteres para uma variável do tipo vetor (ponteiro, na verdade, mas isto é outro assunto) de caracteres e adiciona um caractere nulo (NULL), zerado, na última posição. Perceba que iniciamos o vetor de char com 21 posições, para abrigar os 20 caracteres da frase proposta mais o NULL, que é um caractere só. As coisas começam a fazer sentido, apesar de “feias”, não?
    E assim é o C. Exigente, porém elegante. Se tem os conceitos de computação, sem dúvida não terá grandes dificuldades com a linguagem.
    Usando o C na vida e no mercado de trabalho
    Certo, você se convenceu de que C é legal de aprender, poderoso e aprendeu. E agora, faz o quê? Tem um colega seu ganhando dinheiro fazendo sites em Ruby on Rails. Outro faturando uma grana fazendo sistemas em Delphi para clientes, com imagens, botões brilhantes e multimídia. O que você, recém-estudado programador em C vai fazer com aquela tela preta pedindo dados com scanf()? Nada. Não é assim que se trabalha com C, ou pelo menos, não mais. Já foi o tempo em que os sistemas eram feitos dessa maneira. Além disso, mesmo nesse tempo a linguagem C foi rapidamente substituída neste meio pela linguagem CLIPPER no mundos dos PCs e pelo COBOL, nos mainframes.
    O forte do C hoje são aplicações desktop, inclusive as baseadas em rede e daemons (serviços). C também é útil para escrever compiladores e interpretadores para outras linguagens, por exemplo. Sabia que o PHP é escrito em C? Pois é, assim como Python, Ruby, BASH e muitos outros interpretadores. Então tem alguém ganhando dinheiro com C por aí, concorda?
    Vale a pena citar também o desenvolvimento embarcados, para microcontroladores e vários microprocessadores, incluindo ARM (usado em vários aparelhos Android).
    Em novembro do ano passado houve uma edição de um evento chamado Universidade Livre em que Olivier Hallot, diretor da ALTA (antiga BrOffice.org) falou durante alguns minutos numa faculdade carioca da dificuldade de encontrar programadores para contratar e fez um apelo para que os alunos levem a sério que o mercado está muito carente de bons programadores, principalmente em C/C++. Também em setembro do ano passado uma empresa publicou uma vaga no Rio de Janeiro buscando um profissional com os seguintes conhecimentos:
    Sistema Operacional Linux; Banco de dados MySQL; Criação e manutenção de tabelas, relacionamentos, scripts, etc.; Linguagem C, e das APIs: (V4L2), GTK, além de OpenGL; Adobe Flex. O salário inicial era de R$ 5.000,00. A vaga deve estar aberta até hoje…
    Em dezembro de 2011, uma grande operadora telefônica abriu nada menos que 20 vagas para desenvolvedores em C no Rio de Janeiro. Empresas que atendem infraestrutura, telecomunicações, embarcados, móveis, desenvolvimento do Linux e kernels derivados também precisam muito de programadores deste tipo. Enfim, vagas não faltam!
    Então por que aprendo Java na faculdade?
    A faculdade tenta ser a mais moderna possível, mas esquece de verdadeiramente orientar na profissão. Java é uma linguagem potente, flexível e poderosa mas tem um fim completamente diferente da linguagem C. Com Java se programa para web, dispositivos móveis, aplicações locais (pouco usada), sistemas de informação, embarcados etc. A flexibilidade é enorme, mas o foco é outro. Não se faz uma suíte de aplicativos em Java, simplesmente porque existe o C pra isso. Um sniffer de rede ou um software ping, por exemplo, são feitos em C, porque C é pra isso. Já uma interface de um aparelho GPS, é feita em Java. Questão de adeqüação. O mercado de Java é tão grande quanto o de C no mundo, mas é maior no Brasil. No entanto, o que não pode é a faculdade tratar a linguagem C como uma introdução à programação, para que o aluno depois aprenda Java. Uma coisa não tem nada a ver com a outra. São dois nichos completamente diferentes e em ambos os casos, é possível conseguir um bom emprego e alavancar na profissão, tanto aqui quanto fora.
    Minha faculdade usa Python para ensinar a programar. É legal?
    Não creio. Python é super divertido e viciante mas não exige os conceitos de computação que todo programador deve ter. A resposta é a mesma para todas as linguagens de alto nível. Como escrevi anteriormente, se começa a programar com uma pseudo-linguagem, para desenvolver a lógica. Antes do estudo de programação médio/alto nível, é preciso estudar computação, do ponto de vista da arquitetura em si (que vai incluir Assembly, SO etc) e aí sim, subir de nível. Se bem gerenciado, é possível manter estas disciplinas em paralelo, mas o programa deve ser cuidadoso (o que as instituições não andam respeitando – Eu já vi projeto de bancos de dados no segundo período. O aluno, teoricamente, nunca usou uma mysql.h ou outras bibliotecas para acesso a SGBD’s em outras linguagens).
    Quem aprende direto no alto nível e se dá bem, ótimo – e está de parabéns. Mas o objetivo do artigo é trazer a linguagem C à tona e não competir com outras linguagens.
    Venho comprovando a tese de que aprender “de baixo para cima” dá certo. Já consegui fazer um amigo escrever um programa em Assembly do zero para calcula a média de alunos. Aí sim ele viu o que é obter dados do teclado, calcular e exibir. Teve de entender por completo a tabela ASCII, uso de registradores gerais, syscalls e interrupções de software. Quando foi para o C, não teve o menor problema.
    E o que dá pra fazer com o C aprendido na faculdade?
    Só com ele, não muita coisa, mas com um pouquinho de pesquisa e afinco, gera-se resultados. Um exemplo é o grupo Coding 40°, onde eu e mais três alunos do curso de Ciência da Computação nos unimos para estudar e acabamos desenvolvendo um pequeno software, capaz de imprimir informações sobre executáveis PE (.exe, .dll etc) na tela. Nada complicado, agora que já está pronto. rs
    Sabe quando você está no Windows e vai nas propriedades de um .exe ou .dll e há uma aba “Versão” como na imagem abaixo?

    A proposta inicial era criar um software capaz de conseguir essa informação, recebendo como entrada o caminho do arquivo executável. O software deveria funcionar no Linux, já que nesse SO não é possível ver esta aba “Versão” nas propriedades dos executáveis de Windows, obviamente. Foi aí que fizemos o pev. Hoje ele já exibe várias outras informações sobre o executável além da versão.
    Conclusão
    Estudar C, C++, Assembly e outras linguagens tidas como “terríveis” é, sem dúvida, uma boa pedida. Há inúmeros projetos no mundo todo precisando de bons programadores nessas linguagens. Não encare o “C de faculdade” como um vilão ou uma introdução à programação porque não é. A linguagem C é uma linguagem poderosa e comercial. Nada de dizer que C é coisa de maluco.
    Ainda não sabe o que fazer com C? Está em dúvida sobre seus aspectos modernos? Nós temos um curso de programação moderna utilizando a linguagem C para você
    Fernando Mercês
    É notória a quantidade de pen drives e cartões de memória infectados com vírus. Freqüentemente nos deparamos com vírus novos, que os antivírus não conhecem (a vacina é criada depois de certo tempo). Essas pragas disseminadas por pen drives são tão perigosas quanto as disseminadas pela internet e às vezes até mais destruidoras, ou seja, o cuidado deve ser redobrado. Veja neste artigo como se defender de um pen drive ou cartão de memória infectado e saiba como remover o vírus destes dispositivos.
    O primeiro ponto a entender é como um vírus infecta um pen drive. Sabemos que vírus são programas (executáveis) e a infecção de um pen drive acontece quando o inserimos em um PC infectado (ou quando o PC infectado já possui um pen drive inserido na porta USB). Se o pen drive infectado é inserido em PC saudável e sem proteção adequada, este PC é infectado e passa a infectar todos os pen drives inseridos nele posteriormente, ou seja, a disseminação da praga fica fora de controle.
    Infelizmente, tudo funciona muito bem graças a uma ajudinha da arquitetura e controle de permissões do Windows. Acontece que normalmente o usuário logado num sistema Windows pertence ao grupo “Administradores”, isto é, possui todas as permissões de escrita e leitura em praticamente todo o disco rígido e áreas de memória. Para um vírus, isto é um prato cheio. Da mesma maneira que um programa de instalação qualquer pode ser executado com sucesso pelo usuário logado (copiando arquivos para diretórios de sistema e criando processos privilegiados), um vírus também pode, pois rodará com as permissões do usuário, que são as de administrador do sistema (as máximas).
    Quando o usuário incauto executa um vírus, este normalmente carrega-se em memória, copia-se para vários locais (backup), tenta infectar outras máquinas na rede e faz com que seja inicializado a cada reinicialização do sistema. É mais ou menos a definição de um worm. Tratamos de algumas técnicas manuais utilizadas para remover estes vírus no artigo Remoção manual de malware no Windows.
    Assim que um pen drive sadio é inserido na porta USB, a praga copia-se para ele. Até aí, nenhuma novidade. Mas como, ao inserir este pen drive em outro computador, ocorre a infecção? Acontece que o Windows possui uma facilidade chamada autorun (ou auto-inicialização) para drives montados e com letra atribuída. Como os pen drives são reconhecidos como uma unidade de disco (recebem inclusive uma letra disponível para serem acessados, por exemplo, F:), esta facilidade pode ser usada nestes dispositivos.
    Funcionamento da auto-inicialização:
    O autorun serve para executar algum aplicativo assim que o drive é montado. O exemplo clássico são os CD-ROMs que, ao serem inseridos no drive de CD, abrem uma aplicação com menus e outros recursos. A questão é que o autorun pode ser utilizado em qualquer drive, seja uma partição do disco, CD-ROM, DVD, pen-drive, câmera digital, etc.
    Para usar esta facilidade, basta adicionar um arquivo chamado autorun.inf no diretório raiz do drive em questão. Neste arquivo são escritas rotinas que o Windows deverá seguir quando assim que o drive for montado. Veja um exemplo:
    [autorun] open=menu.exe icon=menu.ico Se você salvar o conteúdo do exemplo acima num arquivo de texto, nomeá-lo autorun.inf e movê-lo para o diretório raiz de um drive, ao montar ou acessar este drive, as instruções contidas neste arquivo serão executadas.
    Creio que as instruções sejam auto-explicativas. Basicamente o ícone do drive exibirá agora o ícone menu.ico, contido no diretório raiz do drive (do CD-ROM, por exemplo) e a aplicação menu.exe será carregada.
    À esta altura você deve imaginar como o vírus de pen-drive é executado assim que ele é inserido. Isso mesmo, usando essa técnica. Todos os pen-drives infectados que analisei continham um arquivo autorun.inf, com instruções para execução do vírus.
    Evitando a contaminação:
    Ficar imune é impossível. Nunca poderemos prever as técnicas de contaminação que serão inventadas. Aliás, cá entre nós, são muito “boas”. No entanto, algumas medidas podem ser tomadas para diminuir os riscos de contaminação. São elas:
    1. Desabilitar a auto-reprodução em unidades removíveis.
    No registro, navegue até a chave HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionpoliciesExplorer e sete o valor NoDriveTypeAutoRun para 4. Isso desabilitará a auto-reprodução em unidades removíveis. Se quiser desabilitar em qualquer tipo de unidade (recomendo), utilize o valor ff.
    2. Sempre abrir a unidade removível (pen-drive, cartão de memória, etc) pelo Windows Explorer, ao invés de dar duplo-clique no ícone.
    Basta clicar com o botão direito na unidade e escolher “Explorar” ou abrir o Windows Explorer e clicar sobre a unidade.
    3. Desabilitar a execução do arquivo autorun.inf, geralmente responsável pela infecção.Copie e cole as linhas abaixo para o Bloco de Notas e salve como inf.reg:
    REGEDIT4 [HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionIniFileMappingAutorun.inf] @=”@SYS:DoesNotExistSEUNOME” Substitua SEUNOME pelo seu primeiro nome (sem acento ou espaços). Depois basta executar este inf.reg que você gerou.
    Para facilitar as coisas, escrevi um software que faz este trabalho. Chamei-o de USBForce. Funciona assim:
    Na primeira vez que é executado na máquina, o USBForce:
    Desabilita a auto-reprodução em todas as unidades. Desabilita o reconhecimento de arquivos autorun.inf. Habilita sua proteção. A partir deste momento, ao inserir um pen-drive, cartão de memória ou qualquer dispositivo removível, o Windows o reconhecerá mas nenhuma tela será aberta. Você deve então clicar no ícone do USBForce em sua área de trabalho. Ele abrirá o dispotivo pra você e tentará detectar se existe algum vestígio de infecção de vírus no dispositivo. Em caso afirmativo, ele tentará localizar o vírus e deletar (você será avisado antes).
    Naturalmente é interessante colocá-lo em alguma pasta e criar um atalho pra ele na área de trabalho, para facilitar o acesso.
    Fernando Mercês
    Recentemente fui requisitado para verificar a possibilidade de um determinado sistema cliente-servidor funcionar em thin clients (terminais leves, que usam o processamento e o SO de um servidor de terminais).
    O sistema baseia-se em um aplicativo servidor e um pequeno aplicativo cliente, que deve ser instalado em todas as estações. Mas ele não foi feito para funcionar com terminal services: este pequeno aplicativo instalado nas estações mantém suas configurações numa chave de registro em HKEY_LOCAL_MACHINE. Logo, cada estação precisa de um SO para que o aplicativo crie esta chave e armazene suas configurações individuais.
    Imediatamente pensei que se este aplicativo armazenasse suas configurações em HKEY_CURRENT_USER, seu funcionamento em thin client seria viável, uma vez que esta chave do registro existe para cada usuário que se loga no sistema (diferente da chave HKEY_LOCAL_MACHINE, que é única no SO).
    Neste artigo vou mostrar como alterar o comportamento de um executável que armazena suas configurações em HKLM, fazendo-o armazenar em HKCU, para atingir o objetivo desejado.
    O primeiro passo é analisar o executável e verificar que valores ele cria no registro e qual o momento em que isto acontece. Para isso podemos usar o RegMon (Registry Monitor).
    Com o RegMon aberto, criei um filtro para incluir somente o cliente.exe na monitoração do RegMon e dar um highlight quando a operação for CreateKey (criar uma chave no registro).

     

     
    Ao executar cliente.exe, vamos ver o que o RegMon informa.

    Na primeira linha com highlight em vermelho, vemos que o software procura pela chave HKCUSoftwarePCSCliente. Como não existia tal chave, ele a criou (visível nas linhas que seguem).
    Depois o software procura pela chave HKLMSoftwarePCSCliente e também não encontra (veja a coluna RESULT) e também a cria.
    Rolando mais abaixo, vemos que ele procura por sub-chaves também, mas ainda não as cria:

    Cliquei no botão Aplicar do software, que salva as configurações e aí sim, o RegMon acusou várias criações de sub-chaves (CreateKey) e inclusive a criação de valores (SetValue). Veja que todos são em HKLM:

    Nossa intenção é fazer com que o software crie estes valores em HKCU, para permitir o uso de thin clients. Já sabemos quando e onde o programa cria as chaves, agora precisamos saber qual é a API do Windows responsável por criar as chaves no registro. Para isso, basta consultar o Win32 SDK Online Help (win32.hlp). Na busca, procurei por “reg” e imediatamente achei a RegCreateKey e a RegCreateKeyEx. Mas a RegCreateKey é para compatibilidade com aplicativos do Windows 3.11, portanto a API correta é a RegCreateKeyEx. Vamos olhar o trecho inicial da documentação sobre ela:
    LONG RegCreateKeyEx( HKEY hKey, // handle of an open key LPCTSTR lpszSubKey, // address of subkey name DWORD dwReserved, // reserved LPTSTR lpszClass, // address of class string DWORD fdwOptions, // special options flag REGSAM samDesired, // desired security access LPSECURITY_ATTRIBUTES lpSecurityAttributes, // address of key security structure PHKEY phkResult, // address of buffer for opened handle LPDWORD lpdwDisposition // address of disposition value buffer ); Parameters: hKey Identifies a currently open key or any of the following predefined reserved handle values: HKEY_CLASSES_ROOT HKEY_CURRENT_USER HKEY_LOCAL_MACHINE HKEY_USERS The key opened or created by the RegCreateKeyEx function is a subkey of the key identified by the hKey parameter. Basta ler este trecho da documentação para perceber que o parâmetro hKey, que é passado para a função RegCreateKey é o responsável por definir se a criação da sub-chave será em HKCR, HKCU, HKLM ou HKU.
    Então temos que encontrar o ponto onde o programa chama a função RegCreateKey, passando como parâmetro hKey o valor que representa HKCL e substituir pelo valor que representa HKCU. Mas que valores são esses? Bem, eu não achei na documentação mas podemos encontrar isso já debugando o programa. Mãos à obra!
    Ao abrir o cliente.exe no OllyDbg (um debugger de executáveis 32-bits), antes de rodar o software, precisamos definir breakpoints (pontos de parada, numa tradução livre) para que o debugger interrompa a execução do software quando a API que queremos for chamada, no caso, a RegCreateKeyEx. Para isso, na Command Bar, basta digitar “BP RegCreateKeyExA” (sem aspas) e pressionar [ENTER]. Este “A” é porque a função trabalha com caractes em ASCII. Para caracteres UNICODE, usa-se “W”.

    Agora é só rodar o programa no OllyDbg (F9) e esperar parar.
    A primeira parada (breakpoint) na função RegCreateKeyExA não é a que esperamos, pois antes de criar a nossa chave, o software precisa criar outras chaves (de sistema) que são essenciais ao seu funcionamento. Portanto, vamos apertando F9 (Run) até que a parada seja na hora da criação de nossa chave. Aqui precisei rodar (F9) mais cinco vezes. Quando for a correta, a stack (pilha de memória) que o OllyDbg mostra, ficará como na imagem abaixo:

    Perceba que foi passado o valor hexa 80000002 como parâmetro hKey e isso resultou HKEY_LOCAL_MACHINE (o OllyDbg nos mostra).
    Os possíveis valores são:
    Chave                                            Valor (em hexa)
    HKEY_CLASSES_ROOT                 80000000
    HKEY_CURRENT_USER                80000001
    HKEY_LOCAL_MACHINE              80000002
    HKEY_USERS                                    80000003
    HKEY_PERFORMANCE_DATA   80000004
    HKEY_CURRENT_CONFIG          80000005
    HKEY_DYN_DATA                          80000006
    DICA: Se clicarmos com o botão direito no valor 80000002, na stack, e escolhermos a opção “Modify”, poderemos mudar este valor em tempo de execução. Mas é claro que a alteração não será permanente pois estaríamos alterando na memória. Para alterar permanentemente, precisamos saber em que parte do programa está este valor 80000002 (HKLM) e mudar para 80000001 (HKCU), mas em respeito ao desenvolvedor do software, não mostrarei publicamente como fazer isso.
    Fernando Mercês
    Muitos jogos antigos apresentam problemas ao serem executados ou simplesmente instalados no Windows Vista. Isto acontece por conseqüência de diversos fatores, mas o principal é que quando o jogo (ou software) foi desenvolvido, o Windows Vista ainda não estava no mercado, o que impediu testes de serem realizados, entre outros aspectos.
    Este artigo mostra um exemplo de como utilizar a ER para estudar o executável do game e saber o que o impede de rodar no Vista.
    Você verá como uma simples alteração em 2 bytes de um arquivo PE pode salvar seu fim de semana.
    Ao tentar instalar o jogo Mortal Kombat 4 (PC) no Windows Vista Home Basic, obtivemos um erro fatal que dizia: “Start Menu Error”. A única opção era clicar no botão OK, que encerraria a execução do programa de instalação.
    Numa tentativa de contornar tal situção, copiamos o conteúdo do CD-ROM para um diretório no disco rígido e tentamos executar o game pelo seu executável direto, o MK4.EXE. Isso resultou no seguinte erro:

    É notável que o executável checa se a instalação do jogo foi feita e, como não foi feita, recebemos a mensagem acima. Ao clicar em OK, o processo é encerrado.
    Mas o que será que o jogo checa para saber se está instalado ou não? Para responder a essa pergunta precisaremos de um debugger de executáveis. Um aplicativo que mostra, em assembly, as rotinas executadas por arquivo PE. Usaremos o OllyDbg para tal função.
    Ao abrir o executável MK4.EXE no OllyDbg, vamos procurar pela string de texto contida na mensagem de erro da primeira imagem. Para isto, clique com o botão direito do mouse no primeiro quadrante e escolha “Search for > All referenced text strings”, como sugere a imagem abaixo:

    A próxima tela mostra uma lista contendo todas as strings de texto encontradas e entendidas no arquivo MK4.EXE. Nela, clicando novamente com o botão direito do mouse e escolhendo “Search text”, abrirá uma janela como a mostrada abaixo e então digitamos o texto “CD” (sem aspas) e marcamos a opção para diferenciar o caso, para filtrar a pesquisa.

    Isso foi feito para encontrarmos a string de texto que nos foi exibida no erro incial, lembra-se? O texto era “Mortal Kombat 4 is not installed. Run Setup from the CD”. Por isso buscamos a palavra “CD”, para achar essa string dentro do executável do jogo, o que nos leva para próximo da rotina onde esta mensagem é chamada.
    Vamos ver o resultado na imagem abaixo:

    O Olly nos mostra que no endereço 004AD2B1, o comando é PUSH 004F474C, que vai empurrar para a memória (stack) o nosso texto. Para localizarmos exatamente onde está este comando no programa, basta darmos um ENTER nesta linha e a tela abaixo é exibida.
     
    Entramos no bloco onde o texto do erro é exibido na tela. Vamos subir um pouco para ver o que vem antes.
    Na linha 004AD299 temos um CALL (como um GOTO) e, depois que a CALL temina e o programa volta para sua execução normal, temos um TEST EAX, EAX, que é um comando que verifica se o conteúdo de EAX é zero. Então podemos prever que a CALL altera o valor de EAX.
    Mais abaixo, temos um JNZ 004AD2D4. Esse JNZ significa Jump if Not Zero (Pule se não for zero), o que quer dizer que a execução do programa saltará para a linha 004AD2D4 se o conteúdo de EAX não for zero.
    Bom, se a execução não saltar e seguir abaixo, cairemos na mensagem de erro. Se saltar, a pularemos. Então seria interessante alterar essa parte do programa para que sempre salte para a linha 004AD2D4. Isso significa que independente do resultado do teste anterior (TEST EAX, EAX) o salto ocorrerá, sempre. Assim nunca cairemos na mensagem novamente e programa continuará sua execução normal.
    O comando que faz o papel de salto incondicional em assembly é o JMP (Jump). Então, vamos alterar o JNZ da linha 004AD2A0 para JMP (e manter o resto da linha). Para isso, basta selecionar a linha e apertar a barra de espaços, depois clicar em Assemble.

    Feito isso, o Olly marca nossa alteração em vermelho. Clicando com o botão direito do mouse sobre a alteração (ou próximo) e escolhendo “Copy > All modifications”, uma tela com as modificações abre e então basta clicar novamente com o botão direito e escolher “Save file”.

    Dei o nome de MK4-mod.EXE para facilitar o reconhecimento. Agora vamos ao teste. Ao executar este novo executável modificando, vemos o jogo rodando:

    É importante esclarecer que os passos descritos aqui não são genéricos e não servem para todos os softwares que não funcionam, em primeira instância, no Vista. O funcionamento depende de vários fatores e principalmente do nível de integração do software com o SO para o qual ele foi desenvoldido.
    O objetivo deste artigo foi demonstrar como a ER pode nos ajudar a resolver pequenos (e grandes, por quê não?) problemas do dia-a-dia na informática. Este é um dentre dezenas de exemplos de uso da ER para soluções que seriam um pouco difíceis sem ela.
    Fernando Mercês
    A maioria dos vírus e pragas virtuais compartilham de certos métodos de auto-inicialização com o SO. Isto inclui os spywares e seus similares.
    Os sistemas Windows possuem métodos para inicializar programas junto ao seu carregamento limitados. Na maioria das vezes os vírus iniciam justamente por eles e daí a importância de conhecê-los e saber gerenciá-los. Desta forma, o técnico pode remover manualmente muitas pragas, o que economizará tempo com scans de softwares antivírus e anti-spys, além de ser extremamente útil quando o vírus ataca estes softwares de proteção, impedindo sua inicialização.
    Primeiro vamos ver de que jeito um aplicativo pode ser iniciado junto ao Windows. A maior parte dos vírus age deste jeito.
    Em sistemas baseados em Windows NT, o que inclui os Windows 2000, XP e 2003, os métodos de inicialização de programas são:
    Através da pasta Inicializar do Menu Iniciar. No registro do sitema. Por serviço de sistema (o que inclui certa parte do registro). Na primeira maneira, basta colocar um atalho para o programa que se deseja executar na pasta Inicializar do Menu Iniciar. Por exemplo, na imagem abaixo, a cada inicialização do Windows, inicializaremos a Calculadora junto.

    Obviamente um vírus pode se aproveitar deste recurso e colocar um atalho para si neta pasta mas não é comum isso acontecer pois o vírus ficaria facilmente visível e uma das intenções de vírus complexos é passar despercebido ao usuário/técnico. De qualquer forma, não custa conferir.
    Agora vamos ao método mais usado, o registro do sistema. Aqui precisaremos explicar resumidamente como o registro destas versões do Windows funciona.
    O registro é um banco de dados que armazena informações essenciais sobre diversos softwares instalados no Windows, além de informações pertinentes ao próprio sistema. Por conta disto, é comum apelidar o registro de “alma do sistema”.
    Esse banco de dados possui, além de outros dados, chaves, sub-chaves e valores numa organização hierárquica (similar ao Windows Explorer).
    Para o artigo, precisaremos conhecer essas três chaves:
    HKEY_LOCAL_MACHINE – Esta é a chave mais importante do registro. Nela estão contidas informações sobre o PC (hardware instalado, softwares com sua opções e configurações e outros itens). Inclusive veremos que um programa pode ser inicializado por uma sub-chave desta chave. HKEY_USER – Nesta chave são definidas configurações personalizadas para cada usuário do sistema, já que as versões do Windows mais novas permitem logon simultâneo ou não de usuários diferentes. De maneira similar à chave anterior, um vírus pode inicializar-se junto ao SO somente para um usuário específico, usando uma sub-chave desta chave. HKEY_CURRENT_USER – Como o nome sugere, mantém informações sobre o usuário que está atualmente logado no sistema. Todo o registro é dinâmico mas esta chave merece uma definição de dinamismo especial pois muda os valores de suas sub-chaves completamente quando logamos com outro usuário no Windows. Não é difícil de deduzir que ela é um atalho para uma sub-chave de HKEY_USER, já que esta última mantém uma sub-chave para cada usuário cadastrado no sistema. Por exemplo, se logarmos com o usuário “Fernando”, esta chave será uma cópia da sub-chave HKEY_USER. SID (Security Identifier) é uma identificação única que cada usuário tem e o SO conhece os usuários através deste SID. Abaixo, o utilitário “regedit” (Registry Editor), usado para visualizar o conteúdo do registro do sitema.

    Perceba a igualdade entre as áreas destacadas em vermelho. É justamente o que falamos na explicação da chave HKEY_CURRENT_USER. Note o SID do meu suário também.
    Depois desta breve introdução ao registro do sistema, podemos partir para as sub-chaves que realmente importam na questão da remoção manual de vírus.
    São elas:
    HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionRun HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionRunOnce HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionRunOnceEx HKEY_USERS\SOFTWAREMicrosoftWindowsCurrentVersionRun HKEY_USERS\SOFTWAREMicrosoftWindowsCurrentVersionRunOnce As duas últimas chaves acima dependem do SID do usuário mas se a suspeita de vírus for no usuário que está logado, você pode acessá-las pelo atalho como comentamos acima.
    Tudo o que estiver nestas chaves será inicializado junto ao sistema. Faça o teste: verifique o que tem nas sub-chaves de seu PC e veja os caminhos para os arquivos que incializam. No exemplo HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionRun da máquina que usei, está assim.

    Como podemos ver, só há três valores, que são os caminhos absolutos dos executáveis que inicializam junto à máquina usada. Esta é uma máquina virtual. Numa máquina real, os valores normais são outros.
    Para remover programas da inicialização, basta remover os valores desejados.
    É importante salientar que muitos arquivos presentes nestas sub-chaves são essenciais ao sistema e não devem ser removidos. Cabe ao técnico saber identificar caminhos e nomes de executáveis suspeitos. Se você tiver dúvida quando à procedência de algum arquivo, pode digitar seu nome no site Process Library, que mantém uma lista atualizadas de processos (programas em execução) para nos ajudar a identificar se são do sistema ou não.
    Há ainda o método de serviços que podem ser utilizado por alguns vírus mais complexos. A tela de serviços você tem acesso indo no menu Iniciar > Executar, digitando services.msc e clicando no botão OK. Eis a da máquina que usamos para o artigo.

    Esses serviços são na verdade processos (programas) inicializados que recebem este nome pela capacidade de poderem ser muito melhor gerenciados pelo sistema operacional que um processo comum. Perceba a coluna “Status” na imagem. Um serviço pode ser iniciado, reiniciado, pausado ou parado e seu método de inicialização pode ser manual (quando clicado), automático (a cada inicialização do sistema) ou desativado. Um vírus obviamente se aproveitaria do método automático e poderíamos pará-lo e depois desativá-lo numa remoação manual.
    Assim como os processos comuns, a maioria dos serviços é essencial ao sistema, portanto, é bom que se faça uma pesquisa sobre ele (no Google e sites similares) antes de parar ou desativar um serviço suspeito ou não.
    Ao entrarmos nas propriedades de um serviço, vemos o caminho do executável ao qual ele se refere além de uma caixa drop-down para alterar o tipo de inicialização, como mostra a imagem abaixo.

    Com este básico conhecimento, muitos vírus podem ser removidos mas é claro que não basta. Recomendamos sempre um scan com um bom antivírus atualizado e com um anti-spy, mesmo após a remoção manual.
    Existem alguns programas que podem ajudar na identificação de vírus e na remoção manual. Abaixo segue uma lista com descrição:
    Process Explorer – monitora os processos em execuçao em tempo real, o que permite identificarmos se algum processo suspeito está sendo executado. O Process Explorer também mostra o que o processo está fazendo ou tentou fazer (quando bloqueado pelo SO). HiJackThis – gera uma lista e um arquivo de log com todos os processos que inicializam junto ao sistema, podendo ser utlizado inclusive para remover o que sejam julgados suspeitos (muito cuidado com seu julgamento). NOTA: O projeto original foi descontinuado, mas o usuário Polshyn Stanislav da Ucrânia o continuou. Gmer - uma aplicação que detecta e remove rootkits (dentro de um limite, claro). A ideia é procurar por uma lista de coisas escondidas, tais como processos, threads, serviços, arquivos etc. MSCONFIG – utilitário presente no Windows XP mas que pode ser copiado a partir do arquivo msconfig.exe para outros sitemas Windows. Ele mostra de forma interativa o que está sendo inicializado junto ao sistema além de permitir a consulta de outras informações. Você pode chamá-lo a partir do menu executar.
    Fernando Mercês

    Sniffing com o Wireshark

    Por Fernando Mercês, em Redes,

    O Wireshark é um dos sniffers eanalisadores de tráfego de rede mais conhecidos atualmente. Ficou muito famoso com seu antigo nome, Ethereal. Além de ter uma ótima interface gráfica, também possui uma interface em linha de comando muito poderosa. Neste artigo vamos ver como são frágeis os sistemas de login em texto puro. Sniffaremos uma tentativa de login num servidor FTP e num site HTTP, que inclusive, é o nosso.  
    Um sniffer coloca a interface de rede da máquina onde está instalado em modo promíscuo, neste modo a interface capturará qualquer pacote que receba, mesmo os não destinados a ela. Normalmente as interfaces de rede descartam os pacotes que não são destinados à elas. É o famoso broadcasting de pacotes.
    Há também sniffers que não colocam a interface em modo promíscuo (para não serem detectados) mas neste caso, a máquina com o sniffer instalado tem que ficar entre os comunicantes e não só na mesma estrutura de rede.
    Outro detalhe é que um hub sempre manda o pacote que recebe por uma porta para todas as outras portas, o que facilita o sniffing. Já os switchs, não fazem isso (na verdade fazem só na primeira vez em que são ligados na rede e estão escrevendo sua tabela ARP. Depois mantêm tal tabela até ser desligado da energia). Mas não é impossível sniffar numa rede só com switchs, só é mais difícil.
    O primeiro passo é saber onde instalar o Wireshark. Este passo é muito importante pois definirá o sucesso na captura de pacotes. Atente para as disposições da máquina onde estará o Wireshark. Se for uma rede Ethernet concentrada por um hub, a máquina que rodará o Wireshark poderá ficar em qualquer lugar, basta ser conectada ao hub:

    Já que o hub envia todo o tráfego em broadcast, qualquer máquina recebe todo o tráfego da rede, então basta que a interface de uma delas esteja em modo promíscuo (Wireshark instalado e rodando) para que o sniffing tenha sucesso.
    Se o concentrador central de sua rede for um switch, você poderá colocar um hub entre o servidor e o switch e conectar uma máquina com o Wireshark neste hub. Assim, toda comunicação entre servidor e rede passará pela máquina com o Wireshark. Veja a imagem a seguir:

    Há outras maneiras de se fazer o sniffing com switchs, principalmente se o switch for configurável (que possibilita port spanning). Mas deixaremos tal discussão para outra hora. Pode-se discutir sobre assunto em nosso fórum também.
    Instalação do Wireshark
    Depois de escolhida a máquina onde será instalado o Wireshark, vamos para sua instalação, que pode ser feita de várias maneiras (baixando e compilando seu código-fonte, baixando sua instalação, instalando via repositório para sistemas baseados em Linux, etc).
    Como sempre, utilizei o Ubuntu para escrever este tutorial. No Ubuntu a instalação é fácil, basta comandar:
    $ sudo apt-get install wireshark
    Abra o Wireshark e clique no primeiro botão, entitulado "List available capture interfaces...". A janela que abrir mostrará uma lista com as interfaces de rede da máquina. Aqui a minha disposição na rede é como mostra a figura abaixo:

    Perceba que tenho o Wireshark instalado na máquina que dá acesso ao servidor. As outras duas máquinas estão conectadas ao servidor principal através dela.
    Captura dos pacotes
    Uma das máquinas tem o IP 192.168.0.23, e é através dela que vou acessar a internet e abrir um site FTP e um HTTP para que a máquina com o Wireshark capture os pacotes de tais conexões.
    Voltando ao Wireshark, escolhi a minha conexão eth1 (192.168.0.5) que é a placa de rede da máquina onde o Wireshark está instalado, que está ligada ao switch do esquema acima.

    Ao clicar em "Start", inicia-se a captura dos pacotes. Então, a partir da máquina 192.168.0.23, acessei o site FTP da Asus (ftp.asus.com) para uma tentativa de login. Fui pelo próprio comando FTP do Windows 98:
    c:\> ftp ftp.asus.com
    E inseri o nome de usuário fernando e password 3966lop98. Obviamente recebi um erro de falha no login. Neste momento podemos clicar no botão Stop (quarto botão da barra do Wireshark).
    Vamos analisar o que o Wireshark capturou:

    Perceba que no pacote de número 14, há menção ao meu nome de usuário no comando USER do FTP. É importante conhecer o protocolo que será analisado para obter bons resultados com o sniffing.
    No pacote 16 o servidor da Asus me informa que preciso informar um password. E nos pacotes 18 e 19, abro uma conexão TCP e envio meu password com um comando PASS, respectivamente.
    Veja que o argumento do comando PASS é 3966lop98, que é justamente o password que informei através da máquina 192.168.0.23!
    O protolo FTP transmite os comandos e argumentos em texto puro. É extremamente inseguro e em seu lugar é recomendável utilizar o SFTP (Secure File Transfer Protocol).
    Claro que foi uma transmissão pequena e premeditada. Se fôssemos analisar diante de vários milhares de pacotes, seria difícil achar manualmente o pacote que se relaciona com o login. Para isso existem os filtros personalizados e montados com expressões regulares pelo próprio Wireshark. Usaremos um filtro no próximo sniffing, que será HTTP.
    Sniffing em login do Mente Binária
    Agora vamos acessar um site a partir da máquina 192.168.0.23 para analisarmos os pacotes. Seguindo a mesma lógica do item anterior, vamos capturar os pacotes até que o login seja efetuado. Loguei com um usuário. Vamos descobrir quem é (e sua senha) através do Wireshark.
    A análise de pacotes retornou 742 pacotes até eu clicar em Stop. Não vamos olhar um a um e sim usar um filtro.
    No campo "Filter", digite: "http matches POST" (sem aspas, respeitando a caixa). E clique em "Apply".
    Vamos ver o resultado:

    Veja que filtramos só para pacotes HTTP que contenham o comando POST. Este é um comando de formulário HTTP (comumente usado em logins). É o comando dado pelo botão "Enviar" do nosso site. No pacote de número 150, vemos o nome de usuário e a senha sendo enviados para o servidor de nosso site!
    Conclusão
    Espero que o propósito deste artigo tenha sido atingido: mostrar que alguns protocolos são facilmente vulneráveis. Com um rápido sniffing, podemos reunir informações que seriam suficientes para um invasor se apossar de um conta da vítima. Teste o Wireshark em sua rede, veja como ele se comporta capturando pacotes HTTPS, SFTP, SSH, etc, que são protocolos seguros. Veja que as informações estarão encriptadas.
    Fernando Mercês

    Extensões perigosas no Windows

    Por Fernando Mercês, em Tudo,

    Apesar de ser um assunto que já foi tratado em muitos sites e fóruns, continuo a observar que alguns usuários do Windows devem ter mais atenção com o tipo de arquivo que aplica o famoso duplo-clique. Identificar se o arquivo é inofensivo ou se é uma ameaça pode ser mais fácil do que se imagina. Este artigo tem como intenção desmistificar as lendas sobre as extensões de arquivos maliciosos e alertar sobre as extensões perigosas.
    O sistema operacional Windows reconhece (deduz o conteúdo) dos arquvios por sua extensão. Mas o que é extensão de arquivo?
    Extensão de arquivo para o MS-Windows, comumente são os três caracteres após o ponto, no nome completo do arquivo. Por exemplo, documento001.txt, é um arquivo com extensão .TXT, logo, o Windows deduzirá que é um documento de texto e associará este documento à um certo programa, que poderá abrí-lo (recebendo seu caminho como parâmetro) mediante um duplo-clique neste documento.
    Confundiu? Bom, em termos práticos, cada extensão de arquivo que mereça, possui um determinado programa responsável por interpretar um duplo-clique num arquivo que possua tal extensão. Essas informações (quais extensões são abertas por qual programa) ficam no registro do Windows.
    Ainda com o exemplo do documento001.txt, vamos analisar sua associação: ao dar um duplo-clique nele, vemos que ele é aberto pelo Bloco de Notas (notepad.exe).
    A chave do registro responsável por armazenar as informações desta associação é, no Windows XP: HKEY_CLASSES_ROOT\txtfile\shell\open\command. Veja a imagem:

    Perceba que na coluna "Dados" há o caminho completo do notepad.exe (usando uma variável de sistema sim, mas não deixa de ser o caminho absoluto), seguido de %1. Já sabemos que é o Bloco de Notas (notepad.exe) que abrirá arquivos de texto, agora vamos entender o parâmetro.
    Eu escrevi mais acima que o caminho do arquivo a ser aberto era passado por parâmetro. É justamente isso que o "%1" faz. Essa variável armazena o caminho absoluto do arquivo que está sendo acessado, no instante do acesso. Portanto, se você clicou no arquivo documento001.txt e ele está em C:\docs\, esta variável conterá o valor C:\docs\documento001.txt. Isso informa ao Bloco de Notas onde está o arquivo.
    Agora que já sabemos o que é e como funciona a extensão, vamos aos riscos.
    Um arquivo executável precisa ter uma extensão de executável para ser executado. As extensões mais comuns de arquivos executáveis são: EXE, COM, BAT, VBS, MSI, SCR, arquivos do Office (porque podem conter macros, que são executáveis).
    Um vírus, obrigatoriamente, tem que ter uma dessas extensões. Ou seja, ele tem que ser um executável.
    O problema é que há certos disfarces utilizados pelos disseminadores de vírus. Um deles é colocar um nome de arquivo do tipo: "arquivo.jpg .exe". Assim mesmo, com vários espaços entre o .jpg e o .exe. A extensão deste arquivo de exemplo é .EXE e ele será executado como tal! Não é .jpg! O texto ".jpg" neste caso faz parte do nome do arquivo e não da extensão. A "técnica" de colocar espaços é para que os programas de email e webmail identifiquem um nome muito grande e exibam reticências após o .jpg, dando a impressão que é um arquivo de imagem.
    Detalhe que o ícone de um executável pode ser facilmente alterado para o ícone de uma imagem, o que aumenta as chances da vítima de ser enganada.
    Os vírus são programas. Logo, repito, são executáveis. Um arquivo de áudio puro, por exemplo, não pode ser vírus! A extensão .mp3 estaria associada ao Windows Media Player, ou Winamp, ou qualquer outro. Esses software não executam rotinas de executáveis. Só entendem fluxo de mídia, portanto, não executam as rotinas virais diretamente. Mas eles podem conter falhas que sejam exploradas através de payloads maliciosos de arquivos de mídia ou playlists (como os .m3u).
    Tenha certeza da extensão do arquivo e de sua procedência, e estará praticamente livre de ser infectado por um vírus anexo à um e-mail ou disponível para download. Mas lembre-se que os arquivos podem também estar zipados (.ZIP) ou compactados com outro compactador (RAR, LZIP, GZIP, LHA, JAR, etc). Dentro deles é que você deve examinar a extensão do arquivo.
×
×
  • Criar Novo...