Invasores de Corpos: como hackers tomam o controle de programas em execução
Por Fábio Maia |
Em Invasion of the Body Snatchers, clássico da ficção científica de 1956 (com várias regravações ao longo das décadas), uma espécie alienígena invade a Terra de uma forma particularmente ardilosa: ao invés de chegar com naves de guerra e raios desintegradores, ela vai substituindo silenciosamente os habitantes humanos por cópias idênticas, porém controladas por uma inteligência estranha. Por fora, o seu vizinho continua sendo o mesmo João da padaria. Por dentro, ele agora trabalha para os invasores. Pois algo curiosamente análogo — e real — acontece o tempo todo dentro da memória dos seus dispositivos eletrônicos. E entender como isso funciona é entender uma das classes mais antigas e, ainda assim, mais persistentes de ataques cibernéticos da história da computação.
- Antivírus cego: novo malware se esconde em imagens PNG e domina o Windows
- Cibersegurança em 2026: a transição para um ecossistema de confiança autônoma
O ponto de partida é uma característica fundamental dos computadores modernos, herdada da arquitetura de von Neumann: código e dados moram na mesma memória. Quando você executa um programa, tanto as instruções a serem processadas pela CPU quanto os dados sobre os quais essas instruções operam são apenas sequências de bytes guardadas na RAM, lado a lado, sem nenhuma marca distintiva sinalizando "atenção, isto aqui é um verbo, e aquilo ali é um substantivo". A diferença entre "isto é código" e "isto é dado" depende exclusivamente do contexto em que o processador está acessando aquele byte. Se ele está buscando uma instrução para executar, é código. Se está lendo o valor de uma variável, é dado. Os mesmos bytes podem desempenhar qualquer um dos dois papéis — basta que o processador seja convencido a tratá-los como tal. É aí que mora o perigo.
Imagine a memória do seu sistema como um imenso e antiquado hotel de enormes corredores. Cada quarto (um endereço de memória) tem capacidade para acomodar exatamente um hóspede (um byte). Quando um programa entra em execução, o sistema operacional, atuando no papel de um prestativo gerente, reserva um bloco contínuo desses quartos para armazenar informações temporárias — por exemplo, o nome de usuário que você digita em uma tela de login. Essa região restrita e reservada é o que chamamos de buffer. Além disso, existe um zelador-robô (a CPU) que segue, religiosamente, uma ordem de visita: vai ao apartamento 1, executa o que estiver escrito lá (código), vai ao apartamento 2, lê o que estiver escrito lá (dados), e assim por diante. Detalhe crucial: as paredes entre os apartamentos são finas. Na verdade, elas só existem na cabeça do programador. Para a CPU, o prédio é apenas uma fileira contínua de espaços numerados.
Aqui entra a falha fatal. Se o programa reservou 64 bytes para o nome e o usuário decide enviar 200, o que acontece? Em um mundo ideal, o programa rejeita o excesso e segue a vida. Mas em um número assustador de programas reais, o que acontece é o que nós brasileiros chamaríamos de “penetras" na festa: os 136 bytes excedentes simplesmente transbordam (overflow) para os apartamentos vizinhos, sobrescrevendo o que estiver lá.
E é aqui, finalmente, que encontramos os Invasores de Corpos. Se o atacante consegue calcular exatamente onde, na memória, está o "apartamento" ao qual o zelador-robô vai se dirigir em seguida (tipicamente, o tal endereço de retorno salvo na pilha de execução), basta que ele preencha sua entrada propositalmente sobredimensionada com bytes que correspondam a instruções de máquina maliciosas (código contrabandeado como dado!), seguidos pelo endereço calculado para fazer o ponteiro de execução saltar justamente para o início daquele código injetado. O resultado: a CPU, obediente como sempre, para de executar o código original e passa a executar o código do invasor — que herda todos os privilégios do processo hospedeiro. Por fora, é o mesmo app, o mesmo servidor, o mesmo João da padaria. Por dentro, é um alienígena. You are pwned.
Segurança vs. performance: o dilema contínuo
A pergunta que fica é: por que, em pleno 2026, ainda lidamos com bugs descritos pela primeira vez no Morris Worm de 1988?
Algumas respostas: (a) bilhões de linhas de código legacy em C/C++ continuam rodando em sistemas críticos — sistemas operacionais, browsers, firmwares de roteadores, controladores industriais — e ninguém vai reescrever tudo amanhã; (b) mitigações como ASLR, DEP/NX e stack canaries tornaram a exploração mais difícil, mas pesquisadores criativos sempre encontram maneiras de contorná-las (Return-Oriented Programming, Jump-Oriented Programming e variantes ainda mais barrocas); (c) linguagens que fazem verificações automáticas de limites de memória em tempo de execução consomem ciclos preciosos de processamento e, no mundo das plataformas com recursos severamente limitados (como os Sistemas de Automação Industrial e Controle), cada microssegundo de atraso e cada kilobyte de sobrecarga importam; e (d) a pressão por desempenho costuma vencer, na vida real, a pressão por segurança nas decisões de engenharia.
A moral da história, mais uma vez, é a velha conhecida: abstrações mentem — ou, sendo mais generoso, abstrações escondem. O programador que escreve char nome[64] enxerga uma "variável", uma entidade lógica bem-comportada e isolada do resto do mundo. A máquina, por baixo, enxerga apenas mais um pedacinho de RAM, indistinguível dos pedaços vizinhos exceto pelo número que rotula sua porta de entrada. Quem ignora essa dualidade entre o modelo mental e o substrato físico, cedo ou tarde, vai descobrir, do jeito mais traumático possível, que o seu programa virou um zumbi — e que o vizinho da padaria nunca mais foi o mesmo.
Para se aprofundar mais no mundo de hardware e cibersegurança, você pode se interessar em saber o que acontece quando ligamos o computador e o que é uma vulnerabilidade de dia zero (Zero-Day).