Guia de prompts para o REA

Um repositório classificado pelo GitHub apenas como Batchfile e composto basicamente por texto em Markdown acumulou 3.416 estrelas e 620 forks em exatos 13 dias, entre 19 de outubro e 2 de novembro de 2026, com apenas 10 commits na branch principal. O projeto JoasASantos/REA-Prompts (abre em nova aba), batizado de REAP pelo desenvolvedor Joas A. Santos, não traz um novo descompilador nem um modelo de linguagem ajustado para código de máquina. Ele entrega algo que se provou muito mais urgente após a explosão do conjunto de ferramentas REA (Reverse Engineer Anything) (abre em nova aba), cujo repositório morluto/rea somou 95,7 mil estrelas em uma única semana: um contrato epistêmico que proíbe agentes de codificação de inventar respostas quando analisam um software fechado.⁠​‌​​‌​​‌​‌​​​​​‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌​​‌​‌‌‌​​‌‌​​​‌​​‌‌‌​​‌​​‌‌‌‌‌​​​​‌‌‌​​​​‌‌​​‌‌​​‌‌​​‌‌​​‌‌​​‌‌​​‌‌​​‌‌​​​‌‌​​​‌​‌‌​​​‌​​​‌‌​​​​​​‌​‌‌​‌​​‌‌‌​​‌​​‌‌​​​‌​​‌‌​​‌‌​​‌‌‌​​​​​‌​‌‌​‌​​‌‌​‌​​​​‌‌​​‌‌​​‌‌​​‌​​​‌‌‌​​​​​‌​‌‌​‌​‌‌​​​‌​​‌‌​​​‌‌​​‌‌‌​​​​​‌‌​​​‌​​‌​‌‌​‌​‌‌​​​‌​​​‌‌​‌‌​​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌‌​​‌‌​​‌​​​​‌‌‌​​‌​‌‌​​‌‌​​​‌‌‌​​‌​​‌‌​‌​​​‌‌​​​‌‌​​‌‌​​​‌⁠

Qualquer engenheiro que já conectou um LLM a ferramentas de inspeção binária sabe qual é o comportamento padrão do modelo diante de uma árvore de chamadas complexa ou de símbolos ausentes: ele tenta agradar. Se o agente encontra três funções claras e uma quarta ofuscada, ele deduz o que a quarta faz pelo contexto e apresenta a suposição com a mesma confiança de um fato verificado. Na criação de um aplicativo web, esse otimismo estatístico gera um bug fácil de rastrear; na engenharia reversa de um firmware, de um módulo de kernel ou de um binário nativo, uma única inferência tratada como certeza invalida horas de investigação.

O que torna o REAP fascinante do ponto de vista de engenharia de prompts é a simplicidade do seu mecanismo de contenção. Distribuído sob licença MIT, o repositório reúne mais de 16 categorias de templates prontos para colar no agente conectado ao REA, cobrindo desde rastreamento de funcionalidades (feature tracing) e triagem de firmware até análise de pacotes Android (APKs), aplicativos Electron, jogos, extração de protocolos, portabilidade para WebAssembly (WASM) e reimplementação em sala limpa (clean-room). Em todos eles, a regra de ouro não está no vocabulário técnico de baixo nível, mas na exigência estrutural de dividir a saída em três gavetas inegociáveis: o que é fato confirmado (com citação obrigatória de arquivo, função e endereço de memória), o que é inferência e o que permanece desconhecido.

O contrato epistêmico por trás do REAP: por que texto puro resolve um problema de binários

Costumo repetir que os melhores artefatos da era dos agentes de codificação raramente são frameworks pesados de orquestração; quase sempre são restrições bem escritas em linguagem natural que mudam o modo de operação do modelo. O REAP funciona como uma camada de cola entre a capacidade bruta de inspeção do REA e o raciocínio do LLM. Quando você dá ao agente acesso a ferramentas que inspecionam binários, kernels ou sites, o gargalo deixa de ser a coleta de dados e passa a ser a disciplina metodológica.

Sem um prompt restritivo, pedir para um agente "explicar como o aplicativo autentica a sessão" resulta em um resumo narrativo que mistura strings encontradas no binário com padrões genéricos de mercado que o modelo viu no treinamento. Os templates do REAP bloqueiam esse atalho cognitivo por meio de duas travas principais:

1. Escopo cirúrgico de funcionalidade única: cada prompt é desenhado para investigar um único comportamento por vez. Perguntas amplas geram respostas vagas; perguntas estreitas forçam o agente a buscar provas nas ferramentas do REA antes de responder.
2. Separação estrita de evidências: toda afirmação técnica precisa vir acompanhada do endereço de memória, nome de função ou caminho do arquivo inspecionado. Se o agente precisou ligar dois pontos sem ver a instrução exata de transição, ele é forçado pelo prompt a rebaixar aquela conclusão para a seção de hipóteses (inferências) e listar explicitamente quais lacunas faltam preencher.

Quando vale a pena usar o REA-Prompts (e quando não faz sentido)

Antes de clonar o repositório e configurar seu fluxo de trabalho, convém avaliar onde essa abordagem brilha e onde ela é apenas atrito desnecessário. Na cobertura diária que fazemos no IA.com.br sobre agentes aplicados a engenharia de software, fica claro que coleções de prompts só entregam valor quando acopladas ao ferramental certo.

Quando vale a pena:

• Compreensão de sistemas legados sem código-fonte: quando sua equipe precisa manter, integrar ou substituir um executável antigo cujos fontes originais se perderam, mapeando entradas, saídas e efeitos colaterais com precisão de endereço.
• Reimplementação clean-room e interoperabilidade: quando você precisa documentar o comportamento de um protocolo ou funcionalidade em uma especificação formal (CLONE_SPEC.md) para reescrevê-lo do zero na sua própria stack, sem copiar código ou ativos de terceiros.
• Portabilidade cirúrgica para WebAssembly (WASM): especialmente quando você quer extrair o núcleo lógico de um programa nativo, isolá-lo da interface gráfica e validar a fidelidade da conversão comparando hashes de estado.
• Auditoria de segurança autorizada, CTFs e Bug Bounties: para acelerar a triagem de binários, firmwares e APKs em ambientes de pesquisa, separando rapidamente superfícies de ataque reais de alarmes falsos gerados por alucinação do modelo.

Quando não vale a pena:

• Você ainda não tem o ecossistema REA configurado: o próprio diagnóstico da comunidade sobre o repositório é direto: se você não tem um agente de IA conectado às ferramentas do REA, o REAP é apenas o cardápio de um restaurante no qual você ainda não consegue entrar. Os prompts dependem de que o agente possa executar inspeções reais no alvo.
• O código-fonte original está disponível e limpo: se você tem o repositório completo em C++, Rust ou TypeScript à mão, ferramentas tradicionais de análise estática (AST, LSP, grep estruturado) somadas ao seu agente de código padrão resolvem o problema com custo de tokens muito menor.
• Tentativas de análise monolítica ("explique tudo"): se a sua expectativa é colar um único prompt e receber a arquitetura inteira de um jogo ou sistema operacional pronta em cinco minutos, o fluxo do REAP vai parecer lento, pois ele exige iteração função por função.

Pré-requisitos para rodar os fluxos do REA-Prompts

Para colocar os templates em produção no seu terminal ou IDE, você precisa preparar a bancada de inspeção. O repositório em si não exige compilação complexa, mas o agente precisa de braços para trabalhar.

Passo a passo: aplicando os prompts de investigação na prática

Abaixo, estruturamos o fluxo prático de trabalho com o REAP cobrindo os cenários mais valiosos do repositório: configuração inicial, rastreamento de funcionalidade com prova de evidência, clonagem em sala limpa (clean-room) e portabilidade para WASM.

Passo 1: Clonar o repositório e preparar a estrutura de templates

Comece trazendo o repositório para a sua máquina de trabalho para ter acesso rápido às mais de 16 categorias documentadas no arquivo principal e aos scripts auxiliares:

git clone https://github.com/JoasASantos/REA-Prompts.git
cd REA-Prompts

Ao abrir o README.md, você verá que os prompts seguem um padrão de preenchimento de lacunas. Cada template traz marcadores delimitados que devem ser substituídos pelos dados concretos do seu alvo antes de enviar a instrução ao agente. A regra operacional mais importante está logo no topo da documentação: substitua todos os marcadores do template e mantenha cada requisição focada em uma única funcionalidade.

Passo 2: Rastreamento de funcionalidade (Feature Tracing) e triagem de binário

Em vez de pedir ao agente para "descompilar o programa", escolha um comportamento observável específico: por exemplo, como o programa valida o formato de um arquivo de configuração ao iniciar, ou como um aplicativo Electron processa um atalho de teclado específico.

Ao adaptar o template de rastreamento ou triagem nativa do REAP para o seu agente, estruture o pedido exigindo a separação epistêmica. Veja como parametrizar a chamada ao agente mantendo as travas do repositório:⁠​‌​​‌​​‌​‌​​​​​‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌​​‌​‌‌‌​​‌‌​​​‌​​‌‌‌​​‌​​‌‌‌‌‌​​​​‌‌‌​​​​‌‌​​‌‌​​‌‌​​‌‌​​‌‌​​‌‌​​‌‌​​‌‌​​​‌‌​​​‌​‌‌​​​‌​​​‌‌​​​​​​‌​‌‌​‌​​‌‌‌​​‌​​‌‌​​​‌​​‌‌​​‌‌​​‌‌‌​​​​​‌​‌‌​‌​​‌‌​‌​​​​‌‌​​‌‌​​‌‌​​‌​​​‌‌‌​​​​​‌​‌‌​‌​‌‌​​​‌​​‌‌​​​‌‌​​‌‌‌​​​​​‌‌​​​‌​​‌​‌‌​‌​‌‌​​​‌​​​‌‌​‌‌​​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌‌​​‌‌​​‌​​​​‌‌‌​​‌​‌‌​​‌‌​​​‌‌‌​​‌​​‌‌​‌​​​‌‌​​​‌‌​​‌‌​​​‌⁠

Alvo: [caminho/para/seu/binario_ou_apk]
Funcionalidade em foco: [descreva APENAS UMA ação, ex: rotina de validação do cabeçalho do arquivo de save]

Use as ferramentas do REA para investigar exclusivamente a funcionalidade acima.
Não adivinhe comportamentos que você não inspecionou diretamente.
Estruture sua resposta obrigatoriamente nas três seções abaixo:

1. CONFIRMADO (Fatos verificados):
   - Liste o fluxo de execução real encontrado.
   - Para cada afirmação, cite a evidência exata: arquivo, nome da função (ou símbolo gerado) e endereço de memória/offset.

2. INFERIDO (Hipóteses baseadas em evidência parcial):
   - Descreva o que parece acontecer nas partes onde o fluxo não é 100% explícito.
   - Explique qual indício levou a essa hipótese e por que ela ainda não é um fato confirmado.

3. DESCONHECIDO (Lacunas abertas):
   - Aponte chamadas indiretas, ponteiros dinâmicos ou estruturas de dados que não puderam ser resolvidos nesta passada.
   - Sugira o próximo passo exato de inspeção no REA para fechar cada lacuna.

Observe o que acontece quando você executa um prompt com esse formato: se o binário tiver chamadas indiretas (como tabelas de métodos virtuais em C++ ou despachantes dinâmicos), o agente não vai inventar qual função é chamada. Ele vai parar no endereço da chamada indireta, registrar o endereço na seção Confirmado, colocar a provável função de destino em Inferido e pedir permissão para rodar uma análise dinâmica ou buscar referências cruzadas na seção Desconhecido.

Passo 3: Reimplementação ética com o fluxo Clean-Room (CLONE_SPEC.md)

Um dos destaques mais inteligentes do REAP é a seção dedicada a clonar ou reconstruir programas sem cair na armadilha de copiar código descompilado ou ativos protegidos. Na indústria de software, a metodologia clean-room (sala limpa) clássica divide o trabalho em duas equipes: uma analisa o sistema original e escreve uma especificação funcional; a outra lê apenas a especificação e escreve o código novo do zero.

O REAP adapta essa disciplina para agentes de IA em um fluxo de três estágios que evita a contaminação do contexto:

1. Estudo caixa-preta e comportamental: use os prompts de investigação para que o agente mapeie entradas, saídas, máquinas de estado, formatos de dados e casos de borda do programa alvo usando o REA.
2. Geração do artefato CLONE_SPEC.md: instrua o agente a consolidar todo o comportamento descoberto em um documento de especificação chamado CLONE_SPEC.md. A restrição crítica do prompt aqui é explícita: o documento deve conter apenas regras de negócio, contratos de interface, estruturas lógicas e fluxos de estado, sem copiar trechos de código proprietário, assembly descompilado literal ou ativos gráficos/sonoros do programa original.
3. Implementação apenas a partir da especificação: abra uma nova sessão limpa do seu agente de codificação (sem o histórico da sessão de engenharia reversa e sem acesso ao binário original) e forneça exclusivamente o arquivo CLONE_SPEC.md como contexto para que ele implemente o novo software na linguagem desejada.

# Exemplo de estrutura gerada no estágio 2 (CLONE_SPEC.md)

## 1. Visão Geral do Comportamento
Descrição funcional do módulo analisado, focada em entradas, transformações e saídas observadas.

## 2. Máquina de Estados e Regras de Transição
- Estado Inicial: parâmetros esperados e condições de partida.
- Transições Confirmadas: gatilhos lógicos e validações aplicadas aos dados.

## 3. Formato de Dados e Protocolo (Sem código original)
- Descrição dos campos, tamanhos em bytes, endianness e regras de validação de integridade.

## 4. Casos de Borda e Tratamento de Erros
- Como o sistema reage a entradas nulas, timeouts ou payloads fora do padrão.

Passo 4: Portabilidade para WebAssembly (WASM) com comparação de hash de estado

Outro fluxo de alto valor prático presente no repositório é o conjunto de prompts para portar aplicações ou motores de jogos nativos para WebAssembly (WASM). O erro clássico ao tentar portar um binário legado para a web com ajuda de IA é tentar converter tudo de uma vez: janelas do sistema operacional, chamadas de áudio, renderização gráfica e lógica de negócio. O resultado quase sempre não compila.

Os prompts de WASM do REAP impõem uma abordagem chamada headless "logic core first" (núcleo lógico primeiro, sem interface):

1. Isolamento do núcleo lógico: use o prompt de mapeamento para que o agente identifique, via REA, onde termina a lógica pura de estado (cálculos, regras de simulação, processamento de dados) e onde começam as chamadas de plataforma (UI, rede, sistema de arquivos).
2. Extração Headless: o agente extrai e porta primeiramente apenas o loop lógico central para compilar em WASM, substituindo chamadas externas por interfaces vazias (stubs) controladas.
3. Validação por comparação de hash de estado (State-Hash Comparison): em vez de testar a conversão olhando para a tela, o fluxo instrui você a alimentar tanto o binário original quanto o módulo WASM recém-portado com a mesma sequência determinística de entradas (inputs) e calcular um hash do estado da memória do núcleo lógico a cada ciclo (tick).

Se o hash do estado no ciclo 500 do módulo WASM for idêntico ao hash do estado no ciclo 500 do binário nativo inspecionado pelo REA, você tem prova matemática de que a lógica foi portada sem distorções antes mesmo de escrever a primeira linha de código da interface web.

Passo 5: Usando o prompt coringa (Wildcard) e as dicas de escrita do repositório

Nem todo problema cabe perfeitamente nas 16 categorias pré-fabricadas. É por isso que o REAP inclui um prompt coringa (wildcard prompt) e uma seção explicando a mecânica por trás dos templates. Quando precisar criar seu próprio prompt para um alvo incomum (como um driver proprietário antigo ou um script de automação embarcado), aplique os três princípios documentados pelo autor:

• Ancoragem em ferramentas: nunca pergunte "o que esta função faz?"; pergunte "quais evidências as ferramentas do REA retornam sobre as referências cruzadas e strings desta função?".
• Proibição explícita de preenchimento de lacunas: inclua sempre uma instrução dizendo que "não sei ainda, falta inspecionar o endereço X" é uma resposta correta e superior a um palpite plausível.
• Saída orientada a próximos passos: todo prompt de investigação deve terminar exigindo que o agente liste quais comandos ou inspeções específicas do REA devem ser rodados na iteração seguinte para transformar itens Inferidos em Confirmados.

Como verificar se o agente não está alucinando na análise

Mesmo usando os templates do REAP, modelos de linguagem podem escorregar se a janela de contexto ficar poluída após muitas rodadas de execução de ferramentas. Use esta lista de verificação rápida ao final de cada etapa para auditar a saída do seu agente:

1. Auditoria por amostragem de endereços: pegue dois ou três endereços de memória ou nomes de funções listados na seção Confirmado da resposta do agente e peça para o REA exibir o trecho bruto correspondente. Se o endereço não existir ou não contiver a instrução citada, a janela de contexto degradou: reinicie a sessão mantendo apenas o resumo verificado.
2. Teste de pureza da seção Confirmado: leia a seção de fatos confirmados procurando palavras hesitantes como "provavelmente", "parece que", "tipicamente" ou "deve ser". Pela regra do REAP, qualquer frase com esses termos está no lugar errado e deve ser movida imediatamente para a seção de Inferências.
3. Inspeção do CLONE_SPEC.md: antes de passar a especificação para o agente codificador, verifique se não há blocos de código copiados literalmente da saída do descompilador (como variáveis chamadas v1, a2, sub_401000 ou casts aritméticos típicos de descompilação C). A especificação deve ler como um documento de engenharia de software escrito por humanos, não como um dump de memória comentado.
4. Determinismo no State-Hash: em projetos de portabilidade WASM ou reimplementação, verifique se duas execuções seguidas com a mesma semente (seed) e os mesmos inputs produzem exatamente o mesmo hash antes de comparar o original com o portado. Se houver variáveis não inicializadas ou dependência de relógio do sistema (timestamps), o hash vai divergir mesmo com a lógica correta.

Erros comuns ao usar agentes de IA com REA-Prompts

Se as respostas do seu agente continuarem genéricas ou incorretas mesmo usando o repositório, é quase certo que você caiu em uma destas quatro armadilhas operacionais:

• Erro 1: Esquecer de substituir um placeholder ou deixar o escopo aberto demais. Colar um template pedindo para analisar "o sistema de rede do aplicativo" inteiro faz o agente rodar dezenas de buscas superficiais no REA, estourar o limite de tokens da resposta e resumir tudo com chavões. Quebre "sistema de rede" em "função que monta o cabeçalho do pacote de handshake".
• Erro 2: Pular o estágio CLONE_SPEC.md na pressa de gerar código. Pedir para o agente "ler o binário no REA e já ir escrevendo o código equivalente em Rust" mistura duas tarefas cognitivas opostas (investigação cética e geração criativa). O agente acaba traduzindo artefatos de compilação linha por linha em vez de reconstruir a intenção arquitetural do módulo.
• Erro 3: Alimentar o agente com binários empacotados ou ofuscados usando prompts de triagem padrão. Se o executável estiver comprimido com um packer ou protegido por virtualização de código, os prompts comuns de rastreamento de funcionalidade só vão mapear a rotina de desempacotamento, nunca a lógica do aplicativo. Use primeiro os prompts de triagem inicial para identificar a entropia e as seções do binário antes de tentar rastrear funcionalidades.
• Erro 4: Acumular dezenas de funcionalidades na mesma conversa. Conforme o histórico da conversa cresce com dumps de assembly e árvores de chamadas, a atenção do LLM se dilui e ele começa a ignorar as regras do contrato epistêmico. Adote o hábito de encerrar a sessão assim que uma funcionalidade for totalmente documentada em um arquivo Markdown local e inicie uma conversa limpa para a próxima funcionalidade.

Perguntas frequentes