Inspecionar o comportamento de uma aplicação Electron com REA

O REA consegue mapear uma aplicação JavaScript ou Electron local a partir dos ficheiros que tem autorização para inspecionar, mesmo que não disponha da árvore de código-fonte. O resultado útil é um rasto de evidências relativo a um comportamento: que módulo o expõe, onde uma chamada atravessa uma fronteira entre processos e que partes ainda precisam de verificação separada. Este guia usa a documentação atual do projeto REA, consultada em 14 de outubro de 2026. A BIG CHANGE não executou o REA numa aplicação.

A grande mudança

• O que mudou: O REA fornece a um agente de programação um mapa estruturado dos módulos, importações, mapas de origem, rotas e IPC do Electron, a partir de um diretório da aplicação ou de um ASAR fornecido. Cada descoberta pode remeter para os ficheiros que a originaram.
• Porque é importante: Ao investigar uma funcionalidade, um programador pode seguir uma API identificada ou um canal IPC na aplicação empacotada antes de decidir o que inspecionar manualmente. Assim, a pergunta fica mais concreta e as evidências são mais fáceis de verificar.
• O que deve ter em conta: Os percursos estáticos no código são possibilidades, não provam que a aplicação os percorre durante a utilização. Uma afirmação sobre um comportamento específico continua a exigir observação ou teste independente no alvo autorizado.

Antes de começar

Este guia destina-se a um programador que possua uma aplicação JavaScript ou Electron local, ou tenha autorização para a inspecionar. É necessário o diretório extraído da aplicação ou o respetivo ficheiro app.asar e um caminho absoluto para o ficheiro. O manifesto do pacote lista rea-agents versão 6.4.0 e exige Node.js 22.19 ou posterior na linha 22.x, 24.11 ou posterior na linha 24.x, ou a versão 26 ou posterior. Também é necessário o npm. Em Linux, a análise estática de JavaScript/Electron do REA requer ainda um processo compatível com procps ps na PATH do REA para verificar a propriedade dos processos, conforme explica o guia de instalação. Estes são requisitos do sistema anfitrião do REA, distintos dos requisitos de execução da aplicação-alvo.

O fluxo de trabalho de análise estática de JavaScript não requer Hopper, Ghidra, IDA, um navegador ou um processo Electron em execução. Essas ferramentas pertencem a outros fluxos de trabalho do REA. Confirme que tem autorização para inspecionar o alvo e guarde uma cópia dos ficheiros originais para identificar exatamente que artefacto produziu cada resultado. Use o morluto/rea repositório oficial ou o pacote npm para o qual este remete; um repositório com nome semelhante não comprova a sua proveniência.

1. Configure o REA ou use a CLI pontual

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

npx rea-agents setup

Reveja as alterações propostas à configuração do agente, aprove as que pretende e, em seguida, reinicie-o. Se precisar apenas de inspecionar a partir do terminal, o comando documentado abaixo invoca o pacote nesta execução. @latest seleciona a versão atual no momento da execução; registe a versão resolvida juntamente com as evidências, pois os detalhes da saída podem mudar. A versão 6.4.0 acima era a indicada no manifesto do projeto consultado para este artigo em 14 de outubro.

2. Analise os ficheiros fornecidos

Troque o caminho de exemplo pelo caminho absoluto da pasta autorizada da aplicação ou do ASAR:

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

O guia da CLI alerta que o Evidence completo pode ser muito extenso. Guarde-o num ficheiro e consulte um resumo ou a vista dos módulos selecionados. Evite colar todo o resultado num pedido. Se o comando falhar, guarde o erro e o caminho do alvo para diagnóstico; um código de saída zero também pode acompanhar cobertura parcial, avisos ou descobertas por resolver. No Windows, o README apresenta um caminho como "D:/apps/example".

A referência de reconstrução de artefactos indica que a operação lê os ficheiros selecionados como dados, sem executar a aplicação. Inventaria os caminhos e resumos criptográficos dos artefactos, analisa o JavaScript e TypeScript disponíveis e assinala possíveis pontos de entrada, importações, mapas de origem, rotas, pontos de ligação de rede, ligações entre preload e renderer do Electron, APIs contextBridge, chamadas e processadores IPC, além de pedidos de extensões nativas. O resultado esperado é um registo Evidence com um grafo, um resumo estático do Electron, cobertura e limitações. Uma contextBridge ligação a um módulo nativo é uma relação a inspecionar, não uma descodificação desse módulo..node binding é uma relação a inspecionar, não uma decodificação desse módulo nativo.

3. Siga uma funcionalidade específica

Escolha uma funcionalidade cujo nome consiga localizar, como uma ação de menu ou um método de API exposto. Registe o nome apresentado ao utilizador e procure no resultado do REA o módulo correspondente, o canal IPC literal ou a rota. Siga as localizações indicadas por ordem: chamada do renderer ou da página, ponte preload, transmissão IPC, processador correspondente no processo principal e, por fim, a operação de ficheiro ou serviço invocada pelo processador. O exemplo CSV do Electron do REA mostra este padrão com notes.exportCsv(), o canal notes:export e um gravador no processo principal. Estes nomes pertencem à aplicação de exemplo; o alvo que inspeciona terá outros.

Para cada ligação, registe o resumo criptográfico do artefacto, o caminho e a localização do ficheiro, bem como aquilo que o código realmente mostra. Distinga um canal literal associado a um único processador de um canal calculado ou de uma associação ambígua. Consulte os campos de cobertura e limitações antes de considerar ausente um módulo ou processador. Segundo o REA, ficheiros malformados ou indisponíveis, bytes auxiliares do ASAR em falta, expressões não resolvidas e uma análise limitada podem deixar relações por determinar. Um mapa de origem pode revelar os nomes do código original, mas a ferramenta não promete recuperar a árvore de código-fonte inicial.

4. Verifique o comportamento de forma independente

Escreva uma afirmação falsificável com base no rasto estático, por exemplo: «esta ação invoca este canal e o processador grava este tipo de ficheiro». Em seguida, num ambiente de teste aprovado, execute apenas essa ação e observe diretamente o resultado: o ficheiro criado, uma alteração de estado ou um registo recolhido com as suas próprias permissões. Registe a versão da aplicação, o resumo criptográfico do artefacto, as etapas de teste e o resultado observado. Se não tiver autorização para executar a aplicação, limite a afirmação ao percurso estático do código. O exemplo do REA diz expressamente que o percurso inferido pode ser verificado através de uma captura em tempo de execução; o grafo estático, por si só, não mostra que ramo foi executado.

A verificação é bem-sucedida quando outro programador consegue localizar os mesmos trechos do código, compreender os limites da associação estática e repetir a verificação específica. A conclusão bem-sucedida de um comando de análise, por si só, não verifica o comportamento em execução nem comprova uma reimplementação fiel da aplicação.

Se o resultado estiver incompleto

Comece por confirmar que o caminho aponta para um diretório extraído completo ou um ASAR e que os ficheiros auxiliares .asar.unpacked necessários também estão presentes. Consulte a cobertura e os diagnósticos do REA; uma fonte em falta ou com falha é desconhecida, não uma conclusão negativa. Para uma aplicação grande, a referência documenta seleções --source-path exatas, mas ficheiros não selecionados ficam fora do âmbito da análise. Se uma correspondência IPC literal for ambígua ou o canal for calculado, examine os ficheiros citados e delimite melhor a pergunta. Se a ambiguidade continuar, mantenha-a nas notas finais.

O código do REA está licenciado sob MIT, mas o software-alvo e quaisquer motores externos de análise têm as suas próprias licenças e condições. A análise estática processa os ficheiros-alvo localmente. Se enviar resultados do REA a um agente de programação, o fornecedor do modelo tem a sua própria política de dados; não envie segredos nem resultados proprietários antes de a organização autorizar essa utilização. Antes de usar, consulte as condições e os custos do agente e de qualquer motor opcional. O procedimento e a versão do pacote foram verificados em 14 de outubro de 2026 e baseiam-se na documentação.