---
title: "REA: engenharia reversa com IA e limites de desempenho"
locale: pt
category: knowledge_base
category_name: "Base de Conhecimento"
translation_status: reviewed
license: cc_by
author: "injoys"
source_url: https://injoys.com/en/articles/rea-ai-reverse-engineering-performance-and-limits
published_at: 2026-10-19T05:55:51+09:00
---

# REA: engenharia reversa com IA e limites de desempenho

> O REA é uma ferramenta que conecta agentes de IA a ferramentas de engenharia reversa para investigar o comportamento de softwares. Distingue o alcance da verificação dos casos publicados das limitações da análise de servidores e explica questões de segurança, direitos autorais e reprodutibilidade dos resultados da análise.

## Key Points

- O REA permite que agentes de IA acionem ferramentas de engenharia reversa por meio do MCP.
- Entender o funcionamento de um arquivo executável não é o mesmo que recuperar o código-fonte original.
- O caso divulgado de DX-Ball apresenta o resultado da verificação de uma função específica e não significa que a reconstrução do jogo inteiro foi concluída.
- Código de servidor ou modelos privados que não estejam incluídos no app não podem ser obtidos apenas pela análise do app.
- Os resultados da análise devem registrar as evidências e o que não foi verificado, além de passar por uma comparação de comportamento com o original.

REA conecta a AI a ferramentas de engenharia reversa para investigar o funcionamento de aplicativos. Os casos públicos mostram a análise de funções específicas e a possibilidade de reimplementá-las. É difícil tratá-los como prova do fim da indústria de software ou da reprodução integral de serviços.

Os números de validação do DX-Ball se baseiam no registro do caso oficial de 7 de outubro de 2026.

## O que é REA

REA é a sigla de Reverse Engineer Anything. É um projeto que conecta ferramentas de análise de software a agentes de AI. Não é um único modelo de AI que realiza todas as análises por conta própria.

Engenharia reversa é o trabalho de rastrear a estrutura e o funcionamento de um software pronto. O objetivo é identificar o que é necessário para explicar suas funções ou garantir compatibilidade.

Compilação é o processo de transformar o código escrito por uma pessoa em uma forma executável. Nesse processo, comentários e algumas informações sobre nomes podem desaparecer. A otimização também pode alterar a aparência de funções e expressões.

Isso não significa que todos os aplicativos contenham apenas código de máquina sem nomes. Algumas distribuições incluem código JavaScript ou informações de depuração. Por isso, o método de análise depende do formato dos arquivos e das informações que ainda estão disponíveis.

| Termo | Explicação simples | Cuidado ao interpretar o resultado |
| --- | --- | --- |
| Desmontagem | Representa código de máquina como instruções de assembly | A finalidade das instruções exige interpretação adicional |
| Descompilação | Representa código executável em uma forma semelhante ao código-fonte | Não há garantia de que seja igual ao código-fonte original |
| Análise estática | Examina arquivos sem executar o programa | É preciso distingui-la dos caminhos realmente executados |
| Análise dinâmica | Observa o comportamento durante a execução do programa | O comportamento fora das condições observadas não foi verificado |
| Reimplementação | Escreve um novo código com o comportamento identificado | Exige validação por comparação com o original |

## Como a AI se conecta ao Ghidra

REA encaminha as solicitações de análise do agente às ferramentas por meio do MCP. MCP é um padrão de conexão para a troca de solicitações e resultados entre a AI e ferramentas externas. Ghidra é uma ferramenta de engenharia reversa usada para examinar arquivos executáveis.

O README oficial também apresenta integrações com Hopper e IDA, além do Ghidra. A análise estática de JavaScript não precisa de um mecanismo de análise nativo. Portanto, descrever as funções do REA apenas como automação do Ghidra reduz seu alcance.

A análise costuma seguir esta sequência.

1. Definir o aplicativo e a função a investigar.
2. Localizar trechos relacionados por meio de strings ou chamadas de função.
3. Interpretar o comportamento acompanhando as instruções e o fluxo de dados.
4. Conferir as evidências que faltam com chamadas adicionais às ferramentas.
5. Comparar o resultado reimplementado com o comportamento do original.

O Ghidra já dispõe de recursos de análise automática. REA permite que o agente dê continuidade às solicitações de análise. A precisão real depende do alvo, do mecanismo de análise, do modelo e da forma de validação.

## Alcance da análise conforme as condições

O que pode ser verificado com REA depende dos arquivos e do ambiente de execução acessíveis. Um aplicativo local pode conter código que se comunica com um servidor. Isso não significa que ele contenha também a implementação interna do servidor.

| Alvo da análise | O que pode ser verificado | O que não pode ser afirmado apenas com a análise |
| --- | --- | --- |
| Arquivo executável local | Expressões de cálculo, strings, relações entre chamadas de função | Todos os comentários originais e toda a intenção do projeto |
| Aplicativo JavaScript·Electron | Estrutura dos módulos, ligação entre a interface e o processamento interno | Lógica de processamento presente apenas no servidor |
| Página web e registros de comunicação | Scripts baixados, solicitações e respostas observadas | Todo o código-fonte do servidor e todo o banco de dados |
| Arquivo de modelo incluído localmente | Estrutura e informações do arquivo acessível | Modelo privado usado apenas no servidor |
| Função observada durante a execução | Comportamento com aquelas entradas e naquele ambiente | Comportamento com todas as entradas e em todas as situações de falha |

Reimplementar um serviço exige atender também a requisitos além das funções observadas. Permissões de contas e tratamento de erros são exemplos. Mesmo que a interface funcione de forma semelhante, não se pode concluir que todo o serviço seja igual.

## Alcance da validação do experimento da calculadora de 8 minutos e 41 segundos

O número de 8 minutos e 41 segundos vem de uma alegação apresentada em uma demonstração cujo registro original não foi confirmado. O número de chamadas à ferramenta informado junto com ela é 17. Também não foi possível confirmar de forma independente a alegação de que foram encontradas 4 regras de cálculo.

É preciso conferir as condições do teste no vídeo original e no registro de execução. O tempo necessário varia conforme o modelo e o tamanho do programa. Um único sucesso não basta para avaliar a velocidade ou a precisão da análise em geral.

Na análise de uma calculadora, ler as fórmulas não encerra a validação. A ordem de aplicação de descontos e cupons pode mudar o resultado. O descarte da parte fracionária na divisão de inteiros também precisa ser verificado separadamente.

- A ordem de aplicação de descontos e cupons
- O valor usado como base para calcular os impostos
- O ponto em que os cálculos intermediários são arredondados ou têm a parte fracionária descartada
- A saída nos valores-limite em que as condições mudam
- O registro da comparação usando as mesmas entradas no original e no código reimplementado

Para demonstrar uma análise rápida, também são necessários registros além da resposta bem-sucedida. Execuções que falharam e o número de novas tentativas afetam a comparação. Com as evidências verificadas até agora, é difícil fazer uma avaliação geral de que a ferramenta supera uma pessoa.

## Resultados confirmados nos casos públicos

Os casos oficiais mostram o caminho da área de transferência do Notion e uma função de cálculo do DX-Ball. Ambos delimitam as funções investigadas. Também é preciso considerar que os registros foram publicados pelo projeto REA.

| Caso | Trabalho confirmado na documentação pública | O que não deve ser extrapolado |
| --- | --- | --- |
| Notion Desktop 7.6.1 | Rastreamento do caminho entre uma chamada interna do aplicativo e a área de transferência do sistema | Reprodução de todo o serviço Notion |
| DX-Ball 1.07 | Reimplementação da função que converte a posição na tela em valores de áudio dos canais esquerdo e direito | Conclusão da restauração de todo o jogo |
| Aplicativo alternativo leve ao Razer Synapse | Nesta verificação, não foi encontrado um registro específico de validação com o original | Afirmar que é um resultado do REA oficialmente validado |
| Editor de slides relacionado ao Claude | Nesta verificação, o alvo e o alcance da reimplementação não foram confirmados | Interpretá-lo como restauração do modelo privado do Claude |

O caso do Notion rastreia como uma chamada da interface passa pela comunicação interna. Ao final, ela se conecta à função de escrita na área de transferência do Electron. É um caso que explica o caminho de processamento de uma função específica.

No caso do DX-Ball, foram verificados no arquivo executável os dados de entrada da função e as constantes usadas nos cálculos. Foram feitos **3,205 testes** de comparação dessa função. Após considerar o tratamento de realocação examinado, 63 bytes do resultado compilado coincidiram.

Esse registro sustenta a reimplementação de uma função específica. A documentação oficial informa que a restauração executável do jogo inteiro ainda está em andamento. É preciso distinguir a validação de algumas funções da conclusão do produto inteiro.

## O que os marcadores de observação e inferência garantem

Os marcadores de evidência servem para distinguir a origem das conclusões. A documentação do REA diferencia observações, inferências e informações não verificadas. Isso não significa que todas as ferramentas usem os mesmos quatro rótulos.

Os documentos oficiais apresentam estados e formas de expressar o grau de confiança que variam conforme o tipo de análise. Ao lê-los, pode ser útil separar os significados como na tabela abaixo. A classificação da tabela serve para facilitar o entendimento.

| Categoria | Significado | O que examinar |
| --- | --- | --- |
| Observação | Verificado diretamente em um arquivo ou no resultado de uma execução | Versão do alvo e localização da evidência |
| Conclusão derivada | Conclusão calculada a partir de valores e relações observados | Cálculo e premissas |
| Estimativa | Interpretação que precisa de confirmação adicional | Possibilidade de outras explicações |
| Não verificado | Parte para a qual não foi possível obter evidências | Alcance da investigação e motivo da falta de confirmação |

O arquivo oficial DISCLAIMER.md explicita os limites dos resultados da análise.

> A descompilação, a reconstrução, as heurísticas e a análise com auxílio de AI podem ser incompletas ou incorretas.
>
> Fonte: REA DISCLAIMER.md

Isso significa que a descompilação e a análise por AI podem ser incompletas ou estar erradas. Um marcador de observação não elimina a possibilidade de erro da ferramenta. O valor dos marcadores de evidência está em indicar onde fazer uma nova verificação.

## Erros comuns

O equívoco mais comum é considerar validado um resultado que pode ser explicado. Um código fácil de ler pode se comportar de maneira diferente do original. Os caminhos não investigados precisam continuar identificados separadamente.

| Equívoco | Interpretação mais precisa |
| --- | --- |
| A descompilação recupera o código-fonte original | Muitas vezes, ela produz uma representação semelhante ao código-fonte |
| O código contém um caminho, portanto ele foi executado | Uma ligação identificada por análise estática é diferente de uma execução observada |
| A função não foi encontrada, portanto não existe | O alcance da investigação ou o suporte da ferramenta pode ter sido insuficiente |
| A ferramenta terminou com sucesso, portanto a análise está completa | Mesmo um resultado bem-sucedido pode deixar itens sem verificação |
| O resultado apresenta evidências, portanto não há alucinação | É preciso examinar tanto as evidências quanto sua interpretação |

A documentação da CLI do REA também distingue a conclusão bem-sucedida de uma tarefa da completude da análise. Mesmo após o término da tarefa, algumas evidências ou perguntas podem continuar sem solução. É preciso verificar as limitações do resultado, não apenas a mensagem de conclusão.

## Registros que permitem validar novamente os resultados da análise

Uma análise reproduzível precisa registrar também as condições em que as conclusões foram obtidas. O código pode mudar com uma atualização, mesmo que o aplicativo mantenha o mesmo nome. Anotar apenas o endereço de uma função dificulta encontrá-la em outra versão.

Os registros de Evidence do REA preservam as informações de identificação do alvo e a localização das evidências. Os snapshots permitem reutilizar resultados de análises quando as condições correspondem. Isso não significa que o resultado salvo tenha sido validado também para a versão mais recente.

Para manter um registro de validação, siga esta sequência.

1. Registre a versão e o hash do arquivo analisado.
2. Registre as versões do REA e do mecanismo de análise.
3. Associe cada conclusão a uma localização no arquivo ou a um endereço de função.
4. Guarde as entradas e saídas do original e do código reimplementado.
5. Anote separadamente as condições que não foi possível investigar e os testes que falharam.

Um hash é um valor de identificação usado para comparar se os arquivos são iguais. Registrá-lo permite rastrear a qual distribuição a explicação se refere. Também permite distinguir o alcance dos resultados quando a AI os citar mais tarde.

## Análise local e envio de dados para fora do ambiente

Dizer que a análise é local não significa que nenhuma parte do trabalho seja enviada para fora do ambiente. Segundo o README oficial, a análise do alvo pelo REA ocorre localmente. O agente de AI conectado recebe os resultados das ferramentas.

Se um modelo externo for usado, os resultados da análise poderão ser enviados ao fornecedor do modelo. A política de dados aplicável depende do serviço conectado. No caso de aplicativos da empresa ou arquivos privados, verifique primeiro o caminho de transmissão dos dados.

- O alcance do código e das strings enviados ao modelo
- Informações de contas e tokens de acesso incluídos nos logs
- Dados pessoais presentes nos registros de comunicação
- Local de armazenamento dos resultados da análise e política de retenção

Também é preciso distinguir o exame estático de arquivos da execução de um programa. A observação durante a execução pode afetar arquivos ou o estado de uma conta. Trate programas não confiáveis em um ambiente de testes isolado.

## Segurança e direitos que desenvolvedores devem verificar

Informações secretas incluídas em um aplicativo podem ser expostas por engenharia reversa. A OWASP descreve o problema de incluir informações sensíveis em pacotes distribuídos. Esse risco já existia antes do REA.

Em especial, chaves secretas de API com permissões de servidor não devem ser incluídas no aplicativo. A OWASP orienta manter valores secretos estáticos no servidor. A ofuscação pode dificultar a extração, mas não garante o sigilo.

- Verifique as senhas e chaves secretas incluídas nos arquivos distribuídos.
- Limite as permissões e a validade dos tokens de autenticação.
- Valide no servidor as permissões de quem faz a solicitação.
- Substitua as credenciais expostas.

O que é permitido em engenharia reversa varia conforme o país, os contratos e o trabalho realizado. Não se pode afirmar que qualquer atividade seja permitida por ter como objetivo a compatibilidade. A análise e a redistribuição de código e imagens devem ser examinadas separadamente.

A licença MIT do REA não concede direitos sobre o software analisado. Os princípios de uso do projeto podem ser consultados no arquivo oficial DISCLAIMER.md. Confira o que é efetivamente permitido na legislação aplicável e nos termos do software analisado.

## Que mudanças podem ocorrer na indústria de software

REA mostra a possibilidade de reduzir o custo do trabalho de entender funções existentes. Essa é uma perspectiva que pode ser extraída dos casos públicos de análise. Não há números confirmados sobre a dimensão da redução de custos em toda a indústria.

Conhecer a implementação de algumas funções é diferente de ter capacidade para operar um serviço. A qualidade dos dados e a resposta a falhas não são reproduzidas apenas pela análise de arquivos executáveis. Por isso, é preciso avaliar separadamente a facilidade de imitar funções e a competitividade de um negócio.

| Elemento do negócio | Implicação extraída do alcance da análise do REA |
| --- | --- |
| Uma função interna do aplicativo | Possibilidade de reduzir o esforço para investigar a implementação e reimplementá-la |
| Processamento exclusivo do servidor | Difícil de obter apenas com a análise do cliente |
| Dados e permissões de acesso | Precisam ser obtidos e administrados independentemente da compreensão do código |
| Estabilidade e confiança na operação | Testes, manutenção e resposta a falhas continuam necessários |
| Preservação de software existente | Possibilidade de restaurar pequenas funções primeiro, mantendo registros das evidências |

Os casos públicos do REA mostram uma mudança na maneira de compreender software. Não são prova do desaparecimento da demanda por desenvolvimento. Mesmo após reimplementar uma função, ainda é necessário validar a compatibilidade e a qualidade da operação.

## FAQ

### REA é um modelo de IA próprio?
REA é um projeto que conecta agentes de IA a ferramentas de análise de software. As solicitações de análise e os resultados podem ser transmitidos por meio do MCP.

### É obrigatório ter o Ghidra para usar REA?
Depende do que será analisado. A análise nativa utiliza mecanismos como o Ghidra. A análise estática de JavaScript é possível sem um mecanismo de análise nativa.

### REA restaura o código-fonte original exatamente como era?
Não há garantia de que o código restaurado seja idêntico ao original. Comentários e informações sobre nomes podem se perder durante a compilação. O resultado da descompilação deve ser entendido como uma representação que ajuda a compreender o funcionamento.

### Ao analisar um aplicativo, também é possível obter o código do servidor?
O código do servidor que não está incluído no aplicativo não pode ser obtido apenas pela análise do aplicativo. É possível observar as solicitações e respostas da comunicação. Esses registros não revelam toda a implementação interna do servidor.

### É possível analisar outros programas em 8 minutos e 41 segundos?
Não há fundamento para generalizar dessa forma. Também não foi possível verificar o registro original daquela demonstração com a calculadora. O tempo necessário varia conforme o tamanho do alvo, o modelo e o ambiente de análise.

### REA elimina as alucinações da IA?
As alucinações não desaparecem. Indicar as evidências e o que ainda não foi confirmado facilita a revisão das conclusões. Os resultados das ferramentas e a interpretação da IA devem ser verificados separadamente.

### O caso do DX-Ball representa a restauração do jogo inteiro?
Os números citados são resultados da validação de uma função específica de cálculo de som. O caso oficial descreve 3,205 testes comparativos. Ele informa que a restauração executável do jogo inteiro ainda está em andamento.

### Toda a análise feita pelo REA ocorre offline?
A análise do alvo pelo REA é feita localmente. O agente que recebe os resultados das ferramentas pode usar um modelo externo. O escopo completo da transmissão de dados deve ser verificado no serviço conectado.

### Posso incluir em um produto comercial código analisado com REA?
O simples fato de obter os resultados da análise não confere direitos de uso. É preciso verificar os direitos e a licença do software analisado. Verifique também a legislação aplicável e as condições de uso da ferramenta de análise.

### Se REA é de código aberto, a análise também é gratuita?
A licença do código do REA e o custo total do trabalho são coisas distintas. O modelo conectado ou as ferramentas comerciais de análise podem gerar custos. Consulte os preços e as condições de uso de cada fornecedor para verificar os valores.

### O que devo registrar para citar os resultados da análise?
Registre a versão do alvo, o hash do arquivo e a localização das evidências. A versão da ferramenta de análise e os resultados dos testes comparativos também são necessários. Registrar as condições não verificadas ajuda a delimitar o alcance das conclusões.

## Sources

- [README do repositório oficial do REA: como funciona, o que é compatível, análise local e política de dados dos modelos](https://github.com/morluto/rea)
- [Documentação oficial de treinamento do Ghidra: Introduction to Ghidra](https://ghidra.re/ghidra_docs/GhidraClass/Beginner/Introduction_to_Ghidra_Student_Guide.html)
- [Caso oficial do REA: análise do fluxo da área de transferência do Electron no Notion](https://rea.tools/showcase/notion/)
- [Caso oficial do REA: reimplementação do cálculo da posição do som no DX-Ball e validação comparativa](https://rea.tools/showcase/dx-ball/)
- [REA Tool Design: distinção entre observação, derivação, inferência e limitações](https://github.com/morluto/rea/blob/main/docs/tool-design.md)
- [REA JavaScript Application Graph: evidências, estado, grau de confiança e localização do alvo](https://github.com/morluto/rea/blob/main/docs/javascript-application-graph.md)
- [REA JavaScript Application Workflows: distinção entre relações estáticas e verificação durante a execução](https://github.com/morluto/rea/blob/main/docs/javascript-application-workflows.md)
- [REA CLI and Evidence: preservação dos registros, snapshots e status de saída](https://raw.githubusercontent.com/morluto/rea/main/docs/cli.md)
- [REA Disclaimer: limitações da análise, autorização de uso e direitos sobre os resultados](https://raw.githubusercontent.com/morluto/rea/main/DISCLAIMER.md)
- [OWASP MASWE-0004: informações sensíveis incluídas no pacote do aplicativo e formas de lidar com elas](https://mas.owasp.org/MASWE-0004/)

## Images

![Um desenvolvedor compara duas telas de teste de bola e raquete em tablets ao lado de um notebook.](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6Mjk5NzksInB1ciI6ImJsb2JfaWQifX0=--2b1213d9736d5cae1ff35ed8e5e7db570784612e/ai-ab7036b9.webp)
![Um engenheiro de suéter cinza-escuro desconecta um cabo de rede azul de um computador compacto.](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6Mjk5ODUsInB1ciI6ImJsb2JfaWQifX0=--1f2adeb39e8cbbe1342eb9e3c6b1d619bea6e20f/ai-ccb48b79.webp)