A REA disponibiliza um ponto de acesso MCP local e um catálogo de fluxos de trabalho para agentes, que convertem os objetivos de uma investigação em sequências de chamadas a ferramentas. Agentes como Claude Code, Codex, Cursor, Gemini CLI e Grok Build ligam-se ao servidor MCP da REA; durante a configuração, são instaladas instruções de competências no lado do agente para ensinar ao modelo como pedir capturas, análises estáticas e execuções através de fornecedores nativos. Quando um agente solicita um rastreio aprofundado, a REA seleciona o fornecedor nativo configurado — Ghidra, Hopper ou IDA —, inicia-o se necessário, executa scripts de descompilação direcionada e devolve resultados estruturados: cadeias de texto, referências cruzadas de símbolos, excertos de pseudocódigo e evidências ao nível dos ficheiros.

O valor da REA está no processo: os agentes começam por artefactos observáveis — capturas de ecrã, capturas de rede, rastos de IPC ou execuções de processos registadas — e a REA ajuda a relacionar esses sinais com o código. Por exemplo, um agente pode pesquisar a exportação de uma aplicação Electron para encontrar um processador da área de transferência, seguir as ligações de preload e IPC e, em seguida, pedir uma análise nativa do binário do processo principal para inspecionar a implementação. A REA reúne os caminhos de chamadas e referências, as rotinas descompiladas e elementos de evidência concisos, para que o agente possa explicar por que acredita que uma função implementa determinada funcionalidade e apresentar os bytes ou o pseudocódigo exatos que sustentam essa conclusão.

A REA privilegia a análise local: as ferramentas são executadas no computador do investigador, os artefactos em bruto permanecem armazenados localmente e as evidências devolvidas podem ser incluídas pelo agente num registo de sessão reproduzível. Esta abordagem ajuda a proteger a confidencialidade e a cumprir os requisitos de conformidade, mas também significa que as equipas têm de gerir as licenças das ferramentas nativas e os limites de recursos. A REA disponibiliza adaptadores de fornecedores e a configuração de tempos limite de arranque para binários grandes, scripts para recorrer offline a objdump/rizin e avisos opcionais para instalar o Hopper. Antes de aumentarem a escala das investigações conduzidas por agentes, os operadores devem automatizar as verificações de estado dos fornecedores e definir políticas de gravação e de conservação de evidências.

A REA destaca-se em tarefas concretas: compreender o comportamento de sistemas legados quando o código-fonte não está disponível, comparar versões para identificar regressões, documentar formatos de ficheiro ou semânticas de protocolos não documentados e automatizar reconstruções para migrações ou compatibilidade. As equipas podem criar scripts para que um agente recolha exemplos, execute rastreios estáticos e dinâmicos, gere pseudocódigo anotado e prepare a estrutura de uma implementação de substituição. As demonstrações incluídas na REA ilustram fluxos completos — recolha de evidências, reconstrução orientada por testes unitários e validação com conjuntos de dados de entrada originais —, tornando-a uma ferramenta prática de implementação, e não apenas um brinquedo de investigação.

A engenharia reversa situa-se na intersecção entre as possibilidades técnicas e as restrições legais. A REA inclui avisos claros e incentiva a análise local para reduzir o risco de partilha inadvertida, mas a responsabilidade pelo licenciamento, pela autorização e pelo âmbito permitido continua a ser das equipas. A interoperabilidade autorizada, a investigação de segurança e a preservação de software são justificações comuns; já copiar literalmente código protegido ou utilizar chaves pirateadas de ferramentas é proibido. Para reduzir a exposição legal, são essenciais controlos operacionais como verificações jurídicas prévias, restrições de acesso privilegiado, registos de auditoria dos alvos analisados e regras rigorosas sobre os resultados reconstruídos.