REA (Engenharia Reversa Automatizada)

REA

Use o REA quando uma afirmação depende de um binário ou pacote enviado, descompilação, evidência de runtime de aplicação passiva ou comparação com comportamento não estabelecido pelo código-fonte disponível. Para análise comum de um repositório de código-fonte completo, use as ferramentas normais de repositório e não execute comandos de prontidão ou provedor REA.

Conecte apenas quando necessário

A instalação desta skill fornece instruções; ela não registra o servidor MCP do REA, instala mecanismos de análise ou adiciona ferramentas a um agente já em execução.

Se as ferramentas REA estiverem disponíveis e seu registro não for conhecido como desatualizado, prossiga diretamente para o alvo. Não execute diagnósticos ou configuração antes de toda investigação. Use a lista real de ferramentas e esquemas de entrada do servidor conectado; uma skill instalada do branch principal do repositório pode descrever capacidades ausentes em uma versão npm mais antiga. Mantenha evidências inline completas quando esse servidor não anunciar referências retidas.

Se as ferramentas estiverem ausentes, uma chamada for bloqueada pelo cliente ou um provedor necessário estiver indisponível, leia conexão e recuperação. Diagnostique o bloqueador observado, continue o trabalho útil suportado e retome a tarefa original após o reparo. A aprovação do cliente, o PATH do shell, o registro e a disponibilidade do mecanismo têm remediações diferentes; evite repetir a configuração para todos eles.

1. Diagnostique sem alterar a configuração do REA ou do cliente. npx pode baixar o pacote e escrever no cache do npm. Para Codex, execute npx -y [email protected] doctor --client codex --json. Substitua pelo cliente suportado atual: claude_code, claude_desktop, codex, cursor, gemini_cli, windsurf, devin, opencode, antigravity, copilot_cli, commandcode, vscode, grok_build, omp ou grok_bot. grok_bot não tem registro de arquivo local: o doctor relata a etapa de chat do Grok Bot, e a configuração não escreve mcp.json. Se o cliente for desconhecido, use doctor --json e inspecione seus resultados de registro antes de escolher um escopo de configuração.
2. Distinga o motivo. Um registro ausente, malformado ou desatualizado precisa de um reparo de configuração com escopo. Um registro alinhado sem ferramentas na sessão ativa precisa de uma reinicialização/reconexão; o doctor não pode provar que o agente atual se conectou. Um provedor ausente afeta apenas tarefas que exigem esse provedor: inspeção JavaScript estática não precisa de Hopper nem Ghidra, e inspeção Android tem pré-requisitos separados de JADX/Java trazidos pelo usuário.
3. Para um reparo de configuração, prepare o plano somente leitura: npx -y [email protected] setup --client codex --dry-run --json. Use o ID do cliente atual, mostre seus caminhos propostos exatos, backups e alterações, e obtenha aprovação antes que a configuração escreva a configuração ou instale o Hopper. A configuração normalmente instala também a skill agrupada correspondente; inclua essa substituição no plano revisado. Após a aprovação, aplique o mesmo escopo com npx -y [email protected] setup --client codex --yes. Adicione --install-hopper apenas se essa instalação separada for necessária e explicitamente aprovada.
4. Reinicie/reconecte o agente afetado. Verifique se as ferramentas REA realmente aparecem na sessão, depois retome a investigação original. Se elas permanecerem ausentes, inspecione o erro de inicialização MCP do cliente em vez de repetir a configuração.

A configuração do REA nunca instala ou atualiza Node.js, npm, Homebrew, Java, Ghidra, IDA, JADX, Binwalk ou Unblob. Use os pré-requisitos existentes; não instale software não relacionado para reparar registro MCP. Para um cliente não suportado, use o registro stdio manual com um pacote rea-agents com versão fixa ou continue através da CLI.

Um fallback CLI concreto para uma árvore JavaScript ou ASAR fornecida pelo operador é:

npx -y [email protected] analyze-javascript-application /absolute/path/to/app --json

Nenhum registro MCP ou mecanismo nativo é necessário. Leia a Evidência retornada, gráfico, limitações e desconhecidos com o mesmo cuidado que um resultado MCP; a CLI retorna o registro de Evidência diretamente. Este fallback não estabelece que MCP esteja configurado. Tarefas CLI nativas ainda exigem seu mecanismo selecionado. Prefira um rea CLI existente. Quando nenhum estiver instalado e a aquisição do pacote REA estiver dentro do escopo autorizado, use npx -y [email protected] em seu lugar. O reparo de configuração começa com um plano de configuração somente leitura; mostre caminhos, backups e substituição de skill antes de aplicar alterações autorizadas. Preserve a aprovação existente e os limites de execução de destino. A configuração do REA nunca instala ou atualiza software não relacionado, incluindo Node.js, npm, Homebrew, Java, Ghidra, IDA, JADX, Binwalk ou Unblob.

Roteie o destino primeiro

Escolha a primeira ferramenta do destino que o usuário forneceu. Use open_binary para fluxos de trabalho ativos de destino nativo ou arquivo; ferramentas sem destino recebem seu próprio caminho ou endpoint explícito e não precisam dele.

• ASAR ou árvore JavaScript/Electron extraída: analyze_javascript_application.

• Inventário de membros de arquivo/pacote (ZIP/APK/IPA/MSIX/AppX ou DMG): open_binary com o caminho local fornecido; use inspect_artifact quando seu gráfico e descobertas ajudarem a responder à pergunta.

• Código APK Android, classes, métodos ou referências de entrada: inspect_android_package, depois ferramentas Android focadas quando anunciadas. O inventário de membros do arquivo ainda usa a rota de arquivo acima.

• Assembly gerenciado PE/CLI: inspect_managed_artifact.

• Imagem de firmware: inspect_firmware_regions quando anunciado. Use extract_firmware quando a extração for solicitada, com um novo diretório de saída absoluto selecionado pelo chamador. Essas ferramentas usam Binwalk/Unblob fornecido pelo chamador no Linux; consulte o guia de firmware.

• .NET NativeAOT PE/ELF: análise nativa Ghidra. Código nativo pode produzir pseudocódigo; consulte o fluxo de trabalho NativeAOT em references/native-and-artifacts.md para recuperação opcional de metadados e seu limite de host/layout suportado.

• Página de navegador de propriedade do usuário já aberta: list_browser_targets.

• Ação do navegador que o agente deve executar (clicar, digitar, navegar): capture_browser_scenario com ações declaradas. Consulte observação de runtime para conectar/iniciar e as ferramentas de navegador de acompanhamento focadas.

• Tráfego do Fiddler Everywhere ou uma captura .saz nativa: leia o fluxo de trabalho do Fiddler. Inspecione SAZ salvo com inspect_web_network_capture e format: "saz"; conecte o servidor MCP separado do Everywhere para tráfego ao vivo.

• Captura HAR/SAZ/mitmproxy nativa/aioquic qlog retida: inspect_web_network_capture. Selecione ordinais de registro originais quando útil; inspecione campos do produtor e sidecars de byte/número sem buscar URLs registrados ou reivindicar atribuição ao vivo. Consulte capturas históricas para o perfil upstream exato e exclusões de credenciais. O suporte Qlog começa com aioquic 1.5.0 JSON 0.3; a cobertura de fluxo e as declarações de perda de endpoint não recuperam corpos ou estabelecem perda de rede. Prefira resumo de detalhes, depois tipo qlog trace/páginas de fluxo; selecione um trace, ID de fluxo e direção para páginas de contribuição/intervalo. Fatos retêm escopo de todos os eventos registrados antes da seleção. Outros layouts qlog e correlação PCAP não são suportados.

• Runtime Electron de propriedade do usuário já aberto: list_electron_targets. Antes de uma tentativa de Inspector electron-main, verifique fusíveis empacotados com inspect_electron_fuses; EnableNodeCliInspectArguments desabilitado significa que o aplicativo ignora --inspect.

• Descoberta de campos de pacote: inspect_packet_fields pesquisa protocolos instalados e nomes/tipos de campo antes de escolher campos para inspect_packet_capture. Consulte/pagina os registros relevantes; registros não estabelecem tráfego observado.

• Capturas de pacotes gravadas: inspect_packet_capture com campos TShark selecionados, filtros de exibição e regras de decodificação como. Requer Linux, util-linux prlimit e REA_TSHARK_COMMAND; consulte guia de captura. Limites de pacote contam pacotes de entrada antes da filtragem. A saída padrão é 50 quadros correspondentes; use match_offset / match_limit para páginas posteriores, ou limite nulo explícito para saída correspondente completa. Preserve o digest da fonte entre páginas. Isso não realiza captura ao vivo. Para resumos de endereço/DNS/SNI/protocolo use inspect_pcap_capture com MCP resumo de detalhes, depois páginas pcap de tipo retido. Requer Wireshark 4.x tshark e capinfos, com Linux prlimit ou Windows Job Objects; consulte resumos de pacote. Selecione uma pergunta DNS exata para páginas de endereço; exaustão de página não prova completude de rede. Isso lê gravações e não adquire tráfego.

• Descoberta de decodificador: inspect_signal_decoders pesquisa IDs de decodificador instalados ou ajuda de decodificador selecionado, incluindo canais e opções. Consulte e página os detalhes relevantes antes de escolher configurações; isso não escaneia hardware.

• Traços de sinal/lógica gravados: decode_signal_recording com decodificador explícito, configurações de canal e protocolo. No Linux com util-linux prlimit, forneça sigrok-cli 0.7.2 através de REA_SIGROK_COMMAND; consulte guia de gravação. A saída padrão é 50 linhas literais; selecione classes de anotação e página com line_offset / line_limit, ou nulo explícito para toda a saída restante. Contagens de janela são linhas de exibição, não anotações ou amostras. Preserve digests da fonte entre páginas. Isso lê arquivos existentes; não adquire sinais de hardware.

• Artefato WebAssembly local explícito: inspect_wasm_artifact. Forneça WABT 1.0.42 através de REA_WABT_BIN_DIRECTORY; retenha identidade exata de byte/ferramenta e WAT decodificado. Selecione cola JavaScript e caminhos candidatos explicitamente e preserve URL/caminho ambiguidade. Nenhum fetch implícito ou execução de destino; WAT não é fonte original. Consulte o guia WASM.

• Portador de bytecode EVM local explícito: inspect_evm_interface com codificação raw ou hex selecionada pelo chamador. Preserve digests do portador/decodificado e trate seletores, strings de argumento e mutabilidade como candidatos inferidos; isso não realiza consulta de cadeia ou execução de destino. Para a interface inferida completa sem hex ou stdout duplicado, descubra suporte e selecione detail: "summary"; Evidência completa permanece retida sob sua identidade original. Use o parent_evidence_id retornado para função exata ou bytecode_hex/stdout/stderr páginas. Cobertura candidata não estabelece completude de interface. Consulte o guia de bytecode EVM.

• Metadados de compilador Go, módulo ou configuração de build incorporados: inspect_go_binary com o arquivo local explícito. Esta inspeção embutida sem destino não requer instalação do Go ou desmontador. Preserve bytes de módulo brutos e intervalos de fonte; metadados ausentes não provam que um binário não é Go, e registros de texto não analisados permanecem explícitos. Consulte o guia de binários Go.

• Metadados de dependência Rust cargo-auditable incorporados: inspect_rust_binary com o arquivo ELF, PE ou thin Mach-O local explícito. Esta inspeção embutida sem destino não requer instalação do Rust ou desmontador. Preserve ordem do pacote, índices de dependência e o intervalo de arquivo da seção. Uma seção .dep-v0 ausente é metadados nulos, não prova que o binário não tem dependências. Um hash de commit rustc é uma inferência de um caminho /rustc/<40-hex>/ somente leitura. Consulte o guia de binários Rust.

• Snapshot de banco de dados SQLite local explícito: inspect_sqlite_database. Inspecione com Node.js 24.x >=24.15 ou 26+ fornecendo limites SQLite nativos. Leia o esquema primeiro (inventário compacto por padrão) ou selecione uma tabela comum exata e columns quando linhas forem necessárias. Os padrões são esquema de tabela selecionada e 20 linhas; solicite schema_scope: "database" para o esquema armazenado completo. Preserve a identidade do banco de dados e do WAL irmão existente; amostras de linha relatam truncamento e têm ordem não especificada. Use um snapshot quiescente em vez de assumir que um par banco de dados/WAL ao vivo foi copiado atomicamente. Consulte o guia SQLite.

• Arquivo Linux ELF explícito para layout offline, símbolos, realocações ou evidência de mitigação estática: inspect_binary_layout. Esta operação sem destino usa pwntools fornecido pelo chamador sem abrir um banco de dados de desmontador. Preserve seus locais brutos e limites de inferência/cobertura; consulte o guia de binários offline.

• Core Linux x86-64 ELF fornecido: inspect_recorded_crash. Leia cada thread gravado, nota bruta e registro vinculado à fonte sem abrir um destino ao vivo. PIDs históricos não selecionam processos ao vivo. Solicite include_debugger_context apenas quando candidatos de mapeamento somente core ajudarem; consulte o guia de crash gravado.

• Árvores de tipo/nome/idioma de recurso PE e referências de grupo de ícone estático: inspect_pe_resources com um caminho explícito. Esta operação portátil não requer destino ativo ou mecanismo; cargas úteis opacas retêm intervalos de arquivo e SHA-256.

• Executável nativo, biblioteca ou banco de dados de análise: open_binary, depois use ferramentas de análise focadas diretamente; chame binary_overview quando metadados ou contexto de inventário for útil e disponível do provedor selecionado.

Para uma configuração IDA MCP existente, use open_binary com o binário de entrada original e provider_id: "ida"; não passe um banco de dados .idb ou .i64. O perfil anexado legado vincula a entrada GUI já aberta por SHA-256 e deixa seu banco de dados aberto. O headle moderno

…

[truncado para tradução]