Edição Markdown

AI-translated from English; not yet reviewed by a fluent editor.

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

> O REA mapeia módulos e fronteiras do Electron numa aplicação local. Este guia mostra como seguir uma funcionalidade com base nas evidências e verificar o seu comportamento em separado.

By BIG CHANGE Editorial

Published: 2026-10-14T04:55:21.558Z
Updated: 2026-10-14T04:55:21.558Z
Canonical: https://bigchange.ai/blog/rea-static-electron-app-inspection-guide

![Conceptual charcoal illustration of an external storage drive beside a desktop monitor showing unlabeled file-tree and code-like lines.](https://bigchange.ai/api/media/file/rea-local-artifact-inspection-hero-v1.png)
AI-generated conceptual illustration by BIG CHANGE; no actual REA interface, application finding or runtime result is depicted.

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](https://github.com/morluto/rea/blob/main/README.md), 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](https://github.com/morluto/rea/blob/main/package.json) 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](https://github.com/morluto/rea/blob/main/docs/installation.md#linux-owned-process-prerequisite). 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](https://github.com/morluto/rea) 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](https://github.com/morluto/rea/blob/main/README.md#quick-start) é:

```sh
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:

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

O [guia da CLI](https://github.com/morluto/rea/blob/main/docs/cli.md) 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](https://github.com/morluto/rea/blob/main/docs/javascript-artifact-reconstruction.md) 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](https://rea.tools/guides/javascript/) 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](https://github.com/morluto/rea/blob/main/docs/javascript-artifact-reconstruction.md) 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.

## Sources

- [README do REA](https://github.com/morluto/rea/blob/main/README.md) — Identidade oficial, configuração, comando de análise JS, saída, requisitos de Node e ps no Linux, processamento local e limites de privacidade.
- [Manifesto do pacote REA](https://github.com/morluto/rea/blob/main/package.json) — rea-agents 6.4.0 e faixa de versões do Node exigida.
- [Guia de análise de JavaScript e Electron](https://rea.tools/guides/javascript/) — Exemplo prático de rastreamento do renderer, preload e IPC até um handler do processo principal; os registos de exemplo usam REA 4.1.0.
- [Reconstrução de artefatos JavaScript](https://github.com/morluto/rea/blob/main/docs/javascript-artifact-reconstruction.md) — Escopo estático, seleção da fonte, integridade, cobertura e semântica de caminhos não resolvidos.
- [CLI e Evidence](https://github.com/morluto/rea/blob/main/docs/cli.md) — Comando da CLI, grande volume de Evidence e limites do status de saída.
- [Guia de instalação do REA](https://github.com/morluto/rea/blob/main/docs/installation.md) — O requisito de ps compatível com procps no Linux inclui explicitamente a análise estática JavaScript/Electron e traz orientações de recuperação.