Normalmente, chamamos de arquivos executáveis os arquivos que quando clicados duas vezes (no caso do Windows) executam. Os mais famosos no Windows são os de extensão .exe, que serão o foco do nosso estudo. Para entender como estes arquivos são criados, é preciso notar os passos:
Escrita do código-fonte na linguagem escolhida num arquivo de texto.
Compilação.
Linking.
O compilador cria os chamados arquivos objeto a partir do código-fonte (em texto). Estes objetos contém instruções de máquina e dados.
O linker serve para juntar todos os objetos num único arquivo, realocar seus endereços e resolver seus símbolos (nomes de função importadas, por exemplo).
O processo de compilação (transformação do código-fonte em texto em código de máquina) gera como saída um arquivo chamado de objeto.
No que diz respeito ao processo de linking, estes executáveis podem ser de dois tipos:
Todo o código das funções externas ao executável principal é compilado junto a ele. O resultado é um executável livre de dependências, porém grande. É raro encontrar executáveis assim para Windows.
O executável vai depender de bibliotecas externas (DLL's, no caso do Windows) para funcionar, como estudamos na seção Tabela de Importações.
O nosso binário CRACKME.EXE, que usamos em vários momentos deste livro é dinâmico. Nós já vimos isso ao analisar sua Imports Table com o DIE, mas agora vamos utilizar novamente a ferramenta dumpbin para checar suas dependências:
Existem vários parsers de executáveis alternativos ao dumpbin. Consulta o apêndice Ferramentas para ver uma lista.
Para impedir que os programas do usuário acessem ou modifiquem dados críticos do sistema operacional, o Windows suporta dois níveis de execução de código: modo de usuário e modo de kernel, mais conhecidos por suas variante em inglês: user mode e kernel mode.
Os programas comuns rodam em user mode, enquanto os serviços internos do SO e drivers rodam em kernel mode.
Apesar de o Windows e outros sistemas operacionais modernos trabalharem com somente estes dois níveis de privilégios de execução, os processadores Intel e compatíveis suportam quatro níveis, também chamado de anéis (rings), numerados de 0 a 3. Para kernel mode é utilizado o ring 0 e para user mode, o ring 3.
Programas rodando em user mode tampouco possuem acesso ao hardware do computador. Essencialmente, todos estes fatores combinados fazem com que os programas rodando neste privilégio de execução não gerem erros fatais como a famosa "tela azul da morte" (ou BSOD - Blue Screen Of Death).
Passa que toda a parte legal acontece em kernel mode, sendo assim, um processo (na verdade uma thread) rodando em user mode pode executar tarefas em kernel mode através da API do Windows, que funciona como uma interface para tal. Essa comunicação é ilustrada no diagrama a seguir:
Quando um programador cria um programa, em muitos casos ele utiliza funções de bibliotecas (ou libraries em inglês), também chamadas de DLL (Dynamic-Link Library). Sendo assim, analise o seguinte simples programa em C:
Este programa utiliza a função printf(), que não precisou ser implementada pelo programador. Ao contrário, ele simplesmente a chamou, já que esta está definida no arquivo stdio.h.
Quando compilado, este programa terá uma dependência da biblioteca de C (arquivo msvcrt.dll no Windows) pois o código para a printf() está nela.
Tudo isso garante que vários programadores usem tal função, que tenha sempre o mesmo comportamento se usada da mesma forma. Mas já parou para pensar como a função printf() de fato escreve na tela? Como ela lidaria com as diferentes placas de vídeo, por exemplo?
O fato é que a printf() não escreve diretamente na tela. Ao contrário, a biblioteca de C pede ao kernel através de uma função de sua API que seja feito. Sendo assim, temos, neste caso um EXE que chama uma função de uma DLL que chama o kernel. Estudaremos mais a frente como isso é feito.
Quando um programa é executado (por exemplo, com um duplo-clique no Windows), ele é copiado para a memória e um processo é criado para ele. Dizemos então que um processo está rodando, mas esta afirmação não é muito precisa: na verdade, todo processo no Windows possui pelo menos uma thread e ela sim é que roda. O processo funciona como um "container" que contém várias informações sobre o programa rodando e suas threads.
Quem cria esse processo em memória é um componente do sistema operacional chamado de image loader, presente na biblioteca ntdll.dll.
O código do loader roda antes do código do programa a ser carregado. É um código comum a todos os processos executados no sistema operacional.
Dentre as funções do loader estão:
Ler os cabeçalhos do arquivo PE a ser executado e alocar a memória necessária para a imagem como um todo, suas seções, etc.
As seções são mapeadas para a memória, respeitando-se suas permissões.
Ler a tabela de importações do arquivo PE a fim de carregar as DLLs requeridas por este e que ainda não foram carregadas em memória. Esse processo também é chamado de resolução de dependências.
Preencher a IAT com os endereços das funções importadas.
Carregar módulos adicionais em tempo de execução, se assim for pedido pelo executável principal (também chamado de módulo principal).
Manter uma lista de módulos carregados por um processo.
Transferir a execução para o entrypoint (EP) do programa.
Processo é um objeto que representa uma instância de um executável rodando. No Windows, processos não rodam. Quem roda mesmo são as threads de um processo.
Um processo possui um PID (Process IDentificator), uma tabela de handles abertos (será explicado no capítulo sobre a Windows API), um espaço de endereçamento virtual, e outras informações associadas a ele.
Para ver os processos ativos no seu sistema Windows neste momento, você pode usar o Gerenciador de Tarefas (aba "Detalhes") ou o comando tasklist:
Na imagem anterior, a coluna Image Name define o nome do arquivo executável (o arquivo no disco) associado ao processo. Perceba que há vários processos do svchost.exe por exemplo. É normal.
As bibliotecas, ou DLLs no Windows, são também arquivos PE, mas sua intenção é ter suas funções utilizadas (importadas e chamadas) por arquivos executáveis. Elas também importam funções de outras bibliotecas, mas além disso, exportam funções para serem utilizadas.
Novamente, é possível utilizar o DIE para ver as funções importadas e exportadas por uma DLL, mas no exemplo a seguir, utilizamos novamente o dumpbin contra a biblioteca Shell32.dll, nativa do Windows:
Utilizamos o comando findstr do Windows para filtrar a saída por funções que criam caixas de mensagem. Este comando é como o grep no Linux. A sua opção /i faz com que o filtro de texto ignore o case (ou seja, funciona tanto com letras maiúsculas quanto com minúsculas).
Para chamar uma função desta DLL, teríamos que criar um executável que a importe. No entanto, o próprio Windows já oferece um utilitário chamado rundll32.exe, capaz de chamar funções de uma biblioteca. A maneira via linha de comando é como a seguir:
Como a função ShellAboutA() recebe um texto ASCII para ser exibido na tela "Sobre" do Windows, podemos testá-la da seguinte forma:
Utilizar o rundll32.exe para chamar funções de biblioteca não é a maneira mais adequada de fazê-lo e não funciona com todas as funções, principalmente as que precisam de parâmetros que não são do tipo string. Somente o utilizamos aqui para fins de compreensão do conteúdo.
Em breve também aprenderemos como debugar uma DLL, mas por hora o conhecimento reunido aqui é suficiente.
