Prova de Conceito de Buffer Overflow x86 no Windows para Iniciantes

Este é um tutorial simples e autocontido sobre exploits de buffer overflow baseados em pilha para Windows 32 bits. Nenhum guia externo é necessário — tudo que você precisa está aqui.

O que é este repositório?

• vulnerable.c: Um programa simples com uma função gets() insegura.
• messageBox.asm: Um pequeno payload em assembly que executaria após o overflow.
• exploit.c: Um exemplo de como o overflow pode ser acionado.

Este projeto ensina uma ideia central: a leitura insegura de entrada pode permitir que um atacante sobrescreva o endereço de retorno e redirecione a execução.

A Vulnerabilidade: gets() não tem limite de tamanho

Em vulnerable.c, o programa faz isto:

char buffer[32];
gets(buffer);

O programa reserva 32 bytes para buffer e então chama gets() para ler a entrada. O problema: gets() não verifica o tamanho do buffer. Ele continua lendo caracteres até encontrar uma nova linha. Se o usuário digitar 40 ou 50 caracteres, os caracteres extras transbordam para além do buffer de 32 bytes.

Como a memória é organizada na pilha

Quando uma função C é executada, a pilha (uma região de memória) armazena:

1. Variáveis locais (como buffer)
2. O EBP salvo (ponteiro base da função chamadora)
3. O endereço de retorno salvo (onde a CPU deve saltar quando a função retorna)

Visualize assim:

Lower addresses (top of stack as drawn)
[  buffer (32 bytes)  ]
[    saved EBP (4 bytes)     ]
[  return address (4 bytes)  ]
Higher addresses (bottom)

Quando gets() transborda buffer com muita entrada, os bytes extras sobrescrevem o EBP salvo e depois o endereço de retorno.

Se criarmos cuidadosamente o overflow para colocar um endereço específico no campo do endereço de retorno, a CPU saltará para esse endereço quando a função tentar retornar.

Como o exploit funciona: Passo a passo

1. O programa inicia e aloca buffer[32] na pilha.
2. Ele chama gets(buffer) para ler uma linha de entrada do usuário.
3. Enviamos uma string com mais de 32 bytes (por exemplo, 50 bytes).
4. gets() não tem verificação de tamanho, então escreve todos os 50 bytes no buffer.
5. Os 18 bytes extras transbordam para além de buffer e sobrescrevem o EBP salvo e o endereço de retorno.
6. Construímos cuidadosamente o overflow para que o endereço de retorno aponte para o shellcode na pilha.
7. Quando a função retorna, a CPU lê o endereço de retorno sobrescrito.
8. A CPU salta para o shellcode.
9. O shellcode é executado com as permissões do programa.

Esta é a forma mais simples de execução de código através de um buffer overflow.

O que acontece no shellcode: O payload

messageBox.asm é um pequeno trecho de código projetado para executar após o overflow.

Ele faz o seguinte:

1. Carregar USER32.DLL: Chama LoadLibraryA com a string "USER32.DLL" para garantir que a biblioteca esteja na memória.
2. Preparar argumentos para MessageBoxA: Empurra quatro argumentos na pilha (identificador da janela, texto da mensagem, título, tipo de botão).
3. Chamar MessageBoxA: Chama a função da API do Windows para exibir uma caixa de mensagem com o texto "CAN I HACK THE PC?".
4. Sair limpo: Chama ExitProcess para encerrar o programa com segurança.

O ponto chave: este é um código executável que é executado após o overflow redirecionar a execução para ele. Quando a caixa de mensagem aparece na tela, ela prova três coisas:

1. O buffer overflow funcionou e reescreveu o endereço de retorno.
2. A execução saltou para o shellcode na pilha.
3. O shellcode foi executado com sucesso e fez chamadas à API do Windows.

Em um ataque real, esse payload poderia fazer qualquer coisa: roubar dados, criar um usuário, baixar malware, etc. A caixa de mensagem é apenas uma forma visível e segura de demonstrar que a execução de código arbitrário ocorreu.

Este payload específico usa endereços de memória fixos para MessageBoxA (0x751D8830) e ExitProcess (0x7437ADB0). Esses endereços são específicos de um sistema. O payload precisaria ser ajustado para uma versão ou sistema Windows diferente.

Como compilar e executar a demonstração

Passo 1: Desabilitar proteções

O Windows moderno possui vários recursos de segurança que impedem este exploit:

• Stack Canaries (flag GS): detecta sobrescrições na pilha.
• ASLR (DYNAMICBASE): randomiza endereços de memória para que endereços fixos não funcionem.
• DEP/NX (NXCOMPAT): marca a pilha como não executável para impedir a execução de código nela.

Para este exercício de aprendizado, desabilitamos todos eles.

Passo 2: Compilar no Windows

Use o MSVC (Microsoft Visual C++) com flags específicas:

cl /c /GS- /W3 /Zl vulnerable.c
link /SUBSYSTEM:CONSOLE /DYNAMICBASE:NO /NXCOMPAT:NO vulnerable.obj /OUT:vulnerable.exe

Significado das flags:

• /GS- desabilita a proteção contra estouro de buffer na pilha.
• /DYNAMICBASE:NO desabilita a Randomização de Layout do Espaço de Endereço (ASLR).
• /NXCOMPAT:NO desabilita o DEP, permitindo que o código na pilha seja executado.

Se você já possui o executável, pode desabilitar as proteções com editbin:

editbin /NXCOMPAT:NO /DYNAMICBASE:NO vulnerable.exe

Passo 3: Executar

1. Inicie vulnerable.exe.
2. Quando solicitado, insira uma string longa (mais de 32 caracteres).
3. Se o overflow funcionar, o endereço de retorno salvo é sobrescrito.
4. O programa pode travar, saltar para memória aleatória ou (em um exploit real com shellcode adequado) executar o payload.

Por que o README é completo

Este README explica:

1. O que é gets() e por que é inseguro (sem limite de tamanho).
2. Como a pilha armazena variáveis locais, registros salvos e endereços de retorno.
3. Como um overflow pode sobrescrever o endereço de retorno.
4. Como a CPU usa o endereço de retorno quando uma função retorna.
5. Como o shellcode pode executar quando o endereço de retorno aponta para ele.
6. Quais proteções existem e por que as desabilitamos.
7. Como compilar e executar o exemplo.

Agora você entende todo o fluxo do exploit de buffer overflow. Leia os arquivos de código e compare-os com esta explicação para solidificar seu entendimento.

Aviso importante de segurança

Este exemplo é apenas para aprendizado. Não use esta técnica contra sistemas que você não possui ou para os quais não tem permissão explícita para testar. O acesso não autorizado a sistemas de computador é ilegal.