O REA pode mapear um app JavaScript ou Electron local usando arquivos que você tem autorização para inspecionar, mesmo sem a árvore do código-fonte. O resultado útil é uma trilha de evidências para um comportamento: qual módulo o expõe, onde uma chamada cruza uma fronteira entre processos e quais partes ainda exigem outra verificação. Este guia usa a documentação atual do projeto REA, conferida em 14 de outubro de 2026. A BIG CHANGE não executou o REA em um app.

A grande mudança

  • O que mudou: O REA oferece a um agente de programação um mapa estruturado de módulos, imports, source maps, rotas e IPC do Electron a partir de um diretório de app ou ASAR fornecido. Cada achado pode apontar para os arquivos que o produziram.
  • Por que importa: Ao investigar um recurso, o desenvolvedor pode seguir uma API identificada ou um canal IPC pelo app empacotado antes de decidir o que examinar manualmente. Isso torna a pergunta mais específica e as evidências mais fáceis de conferir.
  • O que observar: Caminhos de código estáticos são possibilidades, não provas de que o app os percorre durante o uso. Uma alegação sobre um comportamento específico ainda precisa de observação ou teste independente no alvo autorizado.

Antes de começar

Este passo a passo é para quem possui um app JavaScript ou Electron local ou tem autorização para inspecioná-lo. Você precisa do diretório extraído do app ou do arquivo app.asar e de um caminho absoluto até ele. O manifesto do pacote lista rea-agents versão 6.4.0 e requer Node.js 22.19 ou posterior na linha 22.x, 24.11 ou posterior na 24.x, ou a versão 26 ou posterior. Também é necessário ter npm. No Linux, a análise estática de JavaScript/Electron do REA requer um processo compatível com procps ps no REA PATH para verificar a propriedade dos processos, conforme explica o guia de instalação. Esses são requisitos do host do REA, separados dos requisitos do app-alvo.

O fluxo estático de JavaScript não precisa de Hopper, Ghidra, IDA, navegador nem de um processo Electron em execução. Essas ferramentas pertencem a outros fluxos do REA. Confirme que você pode inspecionar o alvo e mantenha uma cópia dos arquivos originais para identificar exatamente qual artefato gerou cada resultado. Use o morluto/rea repositório oficial ou o pacote npm vinculado por ele; um repositório de nome parecido não comprova a procedência.

1. Configure o REA ou use a CLI pontual

Para um agente de programação conectado, o comando de configuração documentado é:

Terminal
npx rea-agents setup

Revise as alterações propostas para a configuração do agente, aprove as que quiser e reinicie-o. Se precisar apenas de uma inspeção no terminal, o comando documentado abaixo chama o pacote nessa execução. @latest seleciona a versão atual no momento da execução; registre a versão resolvida junto das evidências, pois os detalhes da saída podem mudar. A versão 6.4.0 acima era a indicada pelo manifesto consultado em 14 de outubro para este artigo.

2. Analise os arquivos fornecidos

Troque o caminho de exemplo pelo caminho absoluto da pasta autorizada do app ou do ASAR:

Terminal
npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --json > app-evidence.json

O guia da CLI alerta que a Evidence completa pode ser muito grande. Salve-a em um arquivo e leia um resumo ou a visualização de módulos selecionados. Evite colar todo o resultado em um prompt. Se o comando falhar, guarde o erro e o caminho do alvo para diagnóstico; código de saída zero ainda pode vir acompanhado de cobertura parcial, avisos ou achados não resolvidos. No Windows, o README mostra um caminho como "D:/apps/example".

A referência de reconstrução de artefatos diz que a operação lê os arquivos selecionados como dados, sem executar o app. Ela inventaria caminhos e hashes dos artefatos, analisa JavaScript e TypeScript disponíveis e informa possíveis pontos de entrada, imports, source maps, rotas, endpoints de rede, conexões entre preload e renderer do Electron, contextBridge APIs, chamadas e handlers IPC, além de solicitações de add-ons nativos. O resultado esperado é um registro Evidence com grafo, resumo estático do Electron, cobertura e limitações. Um .node binding é uma relação a inspecionar, não uma decodificação desse módulo nativo.

3. Siga um recurso específico

Escolha um recurso cujo nome seja possível localizar, como uma ação de menu ou um método de API exposto. Anote o nome visível ao usuário e procure no resultado do REA o módulo correspondente, o canal IPC literal ou a rota. Siga as localizações reportadas na ordem: chamada do renderer ou da página, ponte preload, transmissão IPC, handler correspondente no processo principal e, então, a operação de arquivo ou serviço invocada pelo handler. O exemplo CSV do Electron do REA mostra esse padrão com notes.exportCsv() , o canal notes:export e um gravador no processo principal. Esses nomes são do app de exemplo; o seu alvo terá outros.

Para cada ligação, registre o hash do artefato, caminho do arquivo, localização e o que o código realmente mostra. Diferencie um canal literal associado a um handler de um canal calculado ou de um pareamento ambíguo. Confira os campos de cobertura e limitações antes de considerar ausente um módulo ou handler. Segundo o REA, arquivos malformados ou indisponíveis, bytes auxiliares de ASAR ausentes, expressões não resolvidas e análise limitada podem deixar relações desconhecidas. Um source map pode revelar nomes do código original, mas a ferramenta não promete recuperar a árvore-fonte original.

4. Verifique o comportamento de forma independente

Escreva uma afirmação falsificável a partir da trilha estática, por exemplo: “esta ação chama este canal e o handler grava este tipo de arquivo”. Depois, em um ambiente de teste aprovado, execute apenas essa ação e observe diretamente o resultado: o arquivo criado, um estado alterado ou um rastreamento coletado com suas próprias permissões. Registre a versão do app, hash do artefato, etapas do teste e resultado observado. Se você não estiver autorizado a executar o app, limite a afirmação ao caminho estático do código. O exemplo do REA diz explicitamente que a rota inferida pode ser conferida com captura em tempo de execução; o grafo estático, sozinho, não mostra qual ramo foi executado.

A verificação é bem-sucedida quando outro desenvolvedor consegue localizar os mesmos trechos de código, entender os limites do pareamento estático e repetir sua checagem específica. Um comando de análise concluído com sucesso, por si só, não verifica o comportamento em execução nem comprova uma reimplementação fiel do app.

Se o resultado estiver incompleto

Primeiro, confirme se o caminho aponta para um diretório extraído completo ou ASAR e se os .asar.unpacked arquivos complementares necessários estão presentes. Revise a cobertura e os diagnósticos do REA; uma fonte ausente ou com falha é desconhecida, não uma conclusão negativa. Para um aplicativo grande, a referência documenta seleções --source-path exatas, mas arquivos não selecionados ficam fora do escopo da análise. Se uma correspondência IPC literal for ambígua ou o canal for calculado, examine os arquivos citados e delimite melhor a pergunta. Se a ambiguidade continuar, mantenha-a nas notas finais.

O código do REA é licenciado pelo MIT, mas o software-alvo e qualquer mecanismo externo de análise têm licenças e termos próprios. A análise estática processa os arquivos-alvo localmente. Se você enviar achados do REA a um agente de programação, o provedor do modelo tem sua própria política de dados; não envie segredos ou resultados proprietários antes de a organização liberar esse uso. Confira termos e custos do agente e de qualquer mecanismo opcional. O procedimento e a versão do pacote foram conferidos em 14 de outubro de 2026 e se baseiam na documentação.