560674e2de
* feat(native): report binary hardening for ELF, PE and Mach-O Documents inspect_binary_hardening and its CLI equivalent, including per-property states, supporting evidence, read budgets, and one report per Mach-O slice. Explains that missing protection imports remain unknown, signature presence does not establish validity, and hardened runtime requires inspect_signature. Adds hardening links throughout the documentation. The supplied diff also removes the advanced CodeQL workflow and configuration, along with snapshot-binding mismatch guidance. * fix(native): validate declared payloads and dynamic tables before hardening rows Run the shared range checks for ELF, read imports from the dynamic tables rather than section metadata, and keep an unresolved symbol count apart from an absent table. Check every Mach-O command before building rows and retain only the offsets the rows need. Make the verifier's readelf output wide, check the emitted format before parsing Mach-O, and place the sources before the libraries in the link. * fix(native): share Mach-O segment admission with hardening reads A segment with a section count its cmdsize cannot hold passed the hardening reader and could enable restrict_segment. Move the size, section count and file range checks to a shared admission that readMachoImage and the hardening reader both use, and pin the ELF load-size case with a regression test. * fix(hardening): reject Mach-O section payloads past the slice and empty ELF interpreters Segment admission never checked each section's payload range, so a file-backed section past the slice still produced rows. Decode sections with the section header owner and mark the slice malformed when a payload leaves it; zero-fill and empty sections own no file bytes and are exempt. admitInterp accepted a NUL first byte in a longer extent, which counted an empty interpreter as PIE evidence. It now requires a nonempty path. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KuWHGvzJkrhCqjtEHUwqyH * fix(native): read CFG instrumentation from decoded GuardFlags Use the IMAGE_GUARD_CF_INSTRUMENTED flag that guardFlagRecord already decodes instead of masking the raw GuardFlags word a second time. * fix(native): reject ELF table spans a second PT_LOAD remaps The hardening reader mapped DT_STRTAB, DT_SYMTAB and hash tables through the one PT_LOAD containing the table's first address. A second PT_LOAD starting inside the table could map the rest of it from other file bytes and the reader still reported parsed import evidence. Cap each mapping at the next PT_LOAD that starts inside it, reject a requested range that crosses that boundary, and stop hash reads at the same limit, matching the conflicting-mapping refusal in readElfSymbols. * fix(native): dedupe ELF note tables only on shared boundaries The hardening reader dropped any note table whose bytes another table already covered. A covering SHT_NOTE can hold a non-GNU note whose descriptor is itself a complete GNU property note, while PT_NOTE names that inner note directly. Walking only the outer stream missed the GNU marker and reported CET disabled. Drop an alias only when it starts and ends on boundaries of admitted tables, which are note boundaries of the walked streams. Any other covered alias leaves the feature rows unknown, as a partial overlap already does. * fix(native): admit every Mach-O symbol record after a canary match The Mach-O stack protector scan returned as soon as it found an undefined ___stack_chk_fail, so a later undefined symbol whose n_strx lay outside the string table was never checked. The same damaged table parsed or failed as malformed depending only on record order. Keep the match and finish the bounded record walk. Records after the match are only checked against the string table bounds, so their names are not read or charged to the scan budget. The ELF reader already admits its whole symbol table before matching names. * fix(native): accept ELF load aliases with the same file translation The hardening reader treated every PT_LOAD that starts inside a table, or that also contains the table's address, as a conflicting mapping. A load with the same address-to-file translation names the same file bytes, so tables it overlaps still have one interpretation, and the canonical ElfLoadMap already merges such spans. Treat equivalent loads as one interpretation. A load with a different translation, or the zero-filled tail of an equivalent load, still ends the usable range, so a remapped table is still rejected. * fix(native): keep same-span ELF note tables with different alignments unknown A section and a program header that share endpoints were treated as one note stream even when their effective note alignments differed. Walking the same bytes at 4 and 8 can frame different notes, so dropping the second table could hide a GNU property word and report CET or BTI as disabled. Require matching effective alignment at both endpoints, and no alignment change inside the covered span, before treating a table as an alias. Otherwise mark the feature rows unknown. The fixture's .note.gnu.property section now declares the class's note alignment, as toolchains emit it. * refactor(native): read LC_SYMTAB through the shared fixed-word decoder Move the Mach-O fixed uint32 command layouts out of MachoCommandNames into domain/apple/machoLoadCommands so there is one owner of those offsets. MachoCommandNames and the hardening reader now both decode through it; the hardening reader keeps its own bounds and import policy. * fix(native): skip Mach-O common definitions in canary imports A common definition sets N_UNDF|N_EXT like an import but stores its allocation size in n_value. An object holding only `int __stack_chk_fail;` therefore reported stack_protector: enabled. Require a zero n_value before an undefined external counts as an import, for both nlist widths. * refactor(native): read linkedit data commands through the shared fixed-word decoder readMachoLinkeditDataCommand reproduced the dataoff/datasize offsets that FIXED_WORD_FIELDS already owns. Take the command and decode through decodeMachoFixedWordFields, as readMachoSymtabCommand does, keeping the truncation and endianness behavior. * fix(native): skip empty SHT_NOTE sections in ELF hardening A zero-sized SHT_NOTE owns no bytes, so the section directory marks it not file-backed and the hardening reader rejected the whole image as malformed, while readElfImage accepted the same bytes. Skip empty note sections before the file-backing check; they have nothing to walk. * fix(scripts): run hardening verifier commands through the shared owner The binary hardening verifier started its probes and compiler drivers with raw spawnSync, which bypassed the src/process/ supervision that AGENTS.md requires. Every launch now goes through createVerifierCommands, and the temporary root is removed only after the owner closes cleanly. * fix(scripts): clean up hardening verifier commands on Ctrl-C SIGINT or SIGTERM ended Node before withVerifierCleanup ran, so detached compiler trees and the temporary root could outlive the verifier. The verifier now turns those signals into an abort that every owned command receives, so cleanup closes the owner and removes the root before exit. * fix(scripts): fail the hardening verifier when a signal lands outside a command Only the owned commands read the interruption signal, so a SIGINT or SIGTERM during the final cleanup or between commands was recorded and then dropped, and the verifier exited 0. After cleanup settles, the verifier now throws the interruption reason. A failure the operation or its cleanup already raised still leaves first and is not replaced. * fix(native): fail Mach-O slices with a malformed encryption command The hardening reader turned every malformed status from the shared encryption reader into an unknown `encrypted` row, so a short LC_ENCRYPTION_INFO_64 or an encrypted range past the slice still left the slice parsed with a full report. Only two conflicting encryption commands stay an unknown row now. Any other encryption defect fails the slice like other structural command failures. * fix(native): ignore STB_LOCAL undefined ELF symbols as imports A local undefined __stack_chk_fail or __memcpy_chk is never resolved against another object, so it does not establish an external import. Skip STB_LOCAL bindings when reading protector signs, and give the fixture's positive symbols STB_GLOBAL binding. --------- Co-authored-by: Matt Van Horn <455140+mvanhorn@users.noreply.github.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
32 KiB
English · 简体中文 · 繁體中文 · 日本語 · 한국어 · Türkçe · Русский · Tiếng Việt · ไทย · Deutsch · Español · Français · Українська · Polski · Português (Brasil) · العربية · فارسی · Bahasa Indonesia · Italiano · Ελληνικά · മലയാളം · Roman Urdu · Română
REA: Faça engenharia reversa de qualquer coisa
Um único MCP para engenharia reversa de binários, aplicativos e comportamento em execução.
Viu uma funcionalidade de que gostou? Entenda como ela funciona, até o nível binário.
Site · Guias · Casos de uso
Início rápido · Como o REA funciona · O que você pode analisar · Casos de uso · Criar ambientes de RL · Perguntas frequentes · Documentação
npx rea-agents setup
Important
Fontes oficiais do REA: morluto/rea, rea.tools, rea-agents (npm). Use os links de instalação e de versões dessas fontes oficiais. Um nome de repositório parecido ou um README copiado não comprova que um download seja oficial.
 Participe da comunidade de engenharia reversa Discord · Perguntas e respostas · Compartilhe seus resultados |
Viu uma funcionalidade em um aplicativo que gostaria de ter no seu próprio produto? Peça ao seu agente para investigá-la com o REA. Ele pode inspecionar o aplicativo sem o código-fonte, explicar como a funcionalidade funciona, apresentar as evidências e criar uma versão para o seu projeto.
O REA conecta seu agente a ferramentas para inspecionar binários nativos, aplicativos JavaScript e Electron, assemblies .NET e sites. Você também pode usar as mesmas ferramentas pelo terminal. A análise acontece localmente, e os resultados incluem as evidências e limitações por trás de cada conclusão.
A configuração registra o REA no seu agente e instala as instruções de trabalho correspondentes. A análise nativa pode usar Hopper, Ghidra, IDA ou Kuna já instalados; o Hopper pode ser instalado após sua aprovação. A análise estática de JavaScript não precisa de um mecanismo de análise nativa.
Visite o site do REA para instruções de configuração, guias ilustrados e estudos de caso reais.
Início rápido
No Linux, iniciar Ghidra, JADX e ferramentas de firmware e analisar JavaScript/Electron estaticamente exige um ps compatível com procps no PATH do REA para verificar a propriedade dos processos. Veja o pré-requisito do Linux.
Configure seu agente
Com Node.js e npm instalados, execute:
npx rea-agents setup
Escolha seus agentes, revise as alterações propostas e aprove-as. A configuração adiciona o servidor MCP do REA e as instruções de fluxo de trabalho correspondentes, com backups das configurações existentes. Reinicie seu agente depois.
A configuração oferece suporte ao Claude Code, Codex, Cursor, Gemini CLI, Grok Build e outros agentes. Consulte instalação e configuração para configurar provedores e registrar o MCP manualmente.
O MCP usa esquemas de entrada compactos por padrão. Para obter todas as orientações de campos e validação aninhada, defina REA_MCP_INPUT_SCHEMA_PROFILE=full no registro MCP. Ambos os perfis mantêm todas as ferramentas e a mesma validação canônica do servidor; veja o guia dos contratos MCP.
Peça ao seu agente
Investigue como a busca funciona no aplicativo Notes, mostre as evidências e crie uma funcionalidade semelhante para o meu projeto.
Substitua Notes pelo aplicativo alvo e indique a funcionalidade que deseja entender.
Use o terminal
Inspecione um diretório extraído de um aplicativo JavaScript/Electron ou um arquivo ASAR:
npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --json
O resultado inclui módulos, importações, limites do Electron e suas evidências. Substitua o caminho pelo do seu alvo, como "D:/apps/example" no Windows.
Para instalar o comando rea e usá-lo regularmente:
npm install --global rea-agents
rea --help
Para análise nativa, configure primeiro um provedor. Consulte o guia de CLI e Evidence para comandos nativos, seleção de provedores, snapshots e uso em scripts.
Atualize o REA
O REA muda rapidamente, e novas versões incluem correções frequentes de bugs. Mantenha sua instalação atualizada.
Para uma CLI instalada pelo npm install --global / bun add --global:
rea update
rea --update é um alias de rea update com as mesmas opções globais de saída. Os comandos de atualização guardam no máximo 4 MiB de stdout/stderr combinados. Metadados grandes demais são rejeitados após a saída; instalações detalhadas mantêm diagnósticos limitados. O progresso respeita a contrapressão do terminal e espera as gravações enviadas.
Atualizações globais com Bun exigem Bun 1.2.17 ou posterior. Atualize versões antigas manualmente antes de executar rea update.
Para atualizar os registros dos agentes e a skill, execute o comando de configuração exibido pela atualização.
Se você usa npx, atualize a configuração do agente com:
npx rea-agents@latest setup
Revise as alterações de configuração e reinicie seu agente. Para comandos avulsos da CLI, use npx rea-agents@latest seguido do comando.
Com Bun, use bunx rea-agents@latest no lugar de npx rea-agents@latest.
Como o REA funciona
Seu agente chama o REA por MCP para inspecionar o alvo e rastrear o código relevante. O REA retorna os resultados com suas evidências. O agente usa esses resultados para fazer novas perguntas, explicar o comportamento ou escrever e testar uma implementação. Os comandos da CLI usam os mesmos fluxos de trabalho.
Abra a figura em tamanho completo.
O que você pode analisar
O REA requer Node.js 22.x (>=22.23.4), 24.x (>=24.22.1) ou 26+ (>=26.12.1), além do npm. As ferramentas adicionais e os sistemas anfitriões compatíveis dependem do alvo:
| Alvo | O que o REA retorna | Requisitos e guia |
|---|---|---|
| Binários nativos | Pseudocódigo, assembly, strings, símbolos, chamadas e referências | Hopper, Ghidra, IDA ou Kuna; análise nativa |
| Estrutura ELF sem execução | Seções, segmentos, símbolos/relocações originais e possíveis mecanismos de mitigação identificados por análise estática | pwntools fornecido pelo chamador no Linux x64; diagnóstico de binários |
| PE certificates | Authenticode WIN_CERTIFICATE entries and PKCS#7 signer/X.509 identity fields | Built-in static PE inspection; PE certificates |
| PE imports | Import and delay-load DLL names, ordinals, IAT RVAs and pefile import hash | Built-in static PE inspection; PE imports |
| Bytecode EVM | Seletores de despacho, offsets de bytes, argumentos inferidos e mutabilidade | Entrada local com bytes brutos ou representação hexadecimal no Linux x64; guia de EVM sem execução |
| Rust binaries | Embedded cargo-auditable dependency list | Rust binaries |
| ELF notes | PT_NOTE/SHT_NOTE owners, types, GNU build-id and ABI-tag fields | Built-in static ELF inspection; ELF notes |
| Binary hardening | PIE, NX, RELRO, CFG and related header flags for ELF, PE and Mach-O | Built-in static header inspection; binary hardening |
| Linux kernel modules | .modinfo keys, __versions CRCs, this_module presence, and signature trailer | Built-in static ELF inspection; kernel modules |
| Erlang BEAM | IFF chunks, atoms, exports, and tables | Built-in static BEAM inspection; Erlang BEAM |
| Apple IPS crashes | .ips metadata, threads, images, registers and crash classes | Built-in static JSON inspection; Apple IPS |
| Falhas do Linux registradas | Registros note brutos, registradores/sinais de cada thread registrada e candidatos opcionais a mapeamentos | pwntools fornecido pelo chamador no Linux x64; GDB/pwndbg opcionais; falhas registradas |
| Instalações desktop | Ambientes candidatos, arquivos de evidência, componentes e próximos passos | Inspeção limitada de diretórios e cabeçalhos；Aplicações desktop |
| JavaScript / Electron | Módulos, importações, source maps, rotas, IPC e relações com complementos nativos | Node.js e npm; análise de aplicativos; Linux: procps ps |
| Sites | Estrutura da página, scripts, observações de rede e capturas de tela solicitadas | Um navegador da família Chrome; análise do navegador |
| Capturas de rede salvas | Requisições, respostas, payloads acessíveis e localizações de origem | HAR / Fiddler Everywhere SAZ; mitmdump no Linux para capturas no formato nativo do mitmproxy; guia de capturas |
| Capturas de pacotes | Endpoints, DNS, TLS SNI, distribuição de protocolos e requisições HTTP | tshark e capinfos fornecidos pelo chamador; guia pcap |
| Assemblies .NET | Metadados, instruções CIL, dependências nativas declaradas e comparações de builds | Inspeção estática; guia de código gerenciado |
| PyInstaller | CArchive, PYZ, Python bytecode | Static inspection; Python packaged applications |
| APKs Android | Declarações do manifesto, classes, métodos descompilados e referências | JADX sem interface gráfica e um JDK completo no Linux/macOS/Windows x64; guia de Android |
| Dispositivos Android | Dispositivos, pacotes, processos, logs, despejos, capturas de tela e transferências de APK/arquivos | adb fornecido pelo chamador (emulador ou aparelho); guia de ADB |
| Projetos JEB | Unidades de projeto do motor, hashes de artefatos e pseudocódigo de tipos/métodos | Um cliente JEB iniciado pelo chamador servindo MCP, selecionado com REA_JEB_MCP_URL; guia de JEB |
| Recursos do Android | Manifesto decodificado, tabelas de strings, idiomas e fatos de versão | Lançador do Apktool fornecido pelo chamador; guia de recursos |
| Aplicativos Flutter | Hash de snapshot Dart, hashes de bibliotecas por ABI e procedência de build do motor | Nenhuma (análise estática de APK); guia Flutter |
| Firmware | Regiões, resultados de extração e encaminhamentos à análise nativa | Binwalk / Unblob no Linux; guia de firmware |
| Pacotes gravados | Campos selecionados, valores repetidos, filtros e regras de decodificação | Linux: TShark 4.x + prlimit; guia de capturas |
| Sinais lógicos gravados | Anotações do decodificador, intervalos de amostras e diagnósticos | Linux: sigrok-cli 0.7.2 + prlimit; guia de sinais |
| Pacotes e recursos | Inventários de arquivos, digests, plists, estrutura de bundles Apple e recursos extraídos | Guia de artefatos e JavaScript, aplicativos Apple |
| Comportamento de processos | Saída do terminal, interações, observações de encerramento e do sistema de arquivos, e comparações entre execuções | Linux/macOS com PTY nativo; captura de processos |
| Binários Go | Versão do compilador embutida, módulos, substituições e configurações de compilação | Inspeção estática integrada ELF/PE/thin Mach-O; Não precisa instalar Go |
| Bancos SQLite | Tabelas, colunas, índices, views, gatilhos e linhas selecionadas de tabelas comuns | Snapshot local do banco/WAL; Node.js 24.x >=24.15 ou 26+ com limites nativos do SQLite |
| Objetos de código GPU | Alvos CUDA/HIP, parâmetros e recursos de kernels selecionados, texto PTX preservado | Inspeção estática integrada ELF/PE/fatbin/CUBIN/PTX; GPU |
| Arquivos de modelos | Metadados GGUF / safetensors, declarações de tensores e totais derivados | Inspeção de cabeçalhos; hash completo opcional; GGUF / safetensors |
| Metadados IL2CPP | Imagens de assemblies Unity global-metadata.dat, nomes de tipos/métodos e intervalos de índices | Decodificação estática das versões 24, 27, 29, 31, 39; sem Unity |
| Godot PCK | Inventário e extração, cabeçalhos/diretórios originais e identidade do conteúdo selecionado | Formatos estáticos 2, 3, 4; sem Godot |
| Artefatos WASM | Validação, seções, formas WAT exatas de importação/exportação e WAT decodificado | Fornecido pelo usuário WABT 1.0.42; inspect_wasm_artifact |
| Assinaturas APK | Signatários v1/v2/v3/v3.1, impressões digitais de certificados, rotação de chaves e consistência interna dos resumos | Inspeção estática integrada; inspect_apk_signature |
A inspeção estática de JavaScript e .NET lê os arquivos fornecidos sem executar o aplicativo. A captura em execução inicia o alvo selecionado ou interage com ele usando as permissões do seu usuário; cada guia descreve seus efeitos.
Para inspecionar binários nativos offline, o REA também oferece suporte ao GNU objdump e ao Rizin, que você deve fornecer por conta própria. O guia de ferramentas de engenharia reversa descreve a configuração dos provedores, os comandos da CLI e as limitações de Evidence. O REA não instala nem atualiza nenhum desses provedores.
Para binários grandes, aumente o prazo de inicialização com REA_GHIDRA_STARTUP_TIMEOUT_MS ou REA_HOPPER_STARTUP_TIMEOUT_MS.
Os formatos nativos e os sistemas anfitriões compatíveis variam por provedor. Consulte configuração do Hopper e Ghidra, o guia do IDA, Kuna e o suporte experimental ao Ghidra no Windows. O Ghidra também oferece análise de DOS de 16 bits. Para selecionar um provedor, consulte o guia da CLI. Verifique a disponibilidade nas versões das funcionalidades adicionadas após a versão mais recente no npm.
Casos de uso
DX-Ball: reconstruir um cálculo de panorâmica de áudio
Siga uma chamada de áudio até a função auxiliar que converte posição em panorâmica, inspecione as instruções e transforme pseudocódigo incompleto em C. A reconstrução passa em 3.205 casos com o x86 original e reproduz todos os 63 bytes da função compilada.
Leia o estudo de caso · Repositório da reconstrução
Notion: rastrear a ponte da área de transferência do Electron
Encontre a API da área de transferência do renderizador, siga-a por preload e IPC até o processo principal e inspecione o formato da área de transferência com seus dados de formatação.
TH04: recuperar o cálculo de um anel de projéteis no DOS
Inspecione as instruções de 16 bits do jogo original para PC-98, recupere os cálculos de ângulos fixos e direcionados e compare o C++ reconstruído com a saída do compilador da época.
Leia o estudo de caso · Repositório da reconstrução
Criar ambientes de RL com o REA
Grave uma sessão de aplicativo web, transforme sua API em ferramentas e exporte um ambiente que um agente de IA possa usar. Execute com o AgentEnv e adicione tarefas e verificações de recompensa para treinamento RL ou avaliação.
Guia para criar um ambiente · Veja a demonstração no X
Se você usou o REA em algo interessante, gostaríamos de conhecer. Compartilhe seu caso em uma issue ou um pull request, incluindo o alvo, sua pergunta, como o REA ajudou e o que descobriu.
Criar ambientes de RL
Crie um ambiente local onde um agente de IA possa praticar tarefas como encontrar uma issue ou criar uma pasta, sem executar o aplicativo original. Use para aprendizado por reforço (RL) ou para testar como o agente conclui tarefas.
O REA transforma requisições e respostas de API gravadas em ferramentas que o agente pode chamar. O ambiente usa os dados gravados e só aceita alterações cujos efeitos sejam confirmados pela gravação.
Configure o REA no agente e substitua a URL e as tarefas de pastas do exemplo pelas suas:
Use o REA para criar um ambiente de RL a partir do meu aplicativo web de teste em
http://127.0.0.1:3000.
Inclua listar, criar, renomear e excluir pastas. Pode criar e remover
pastas de teste, mas não altere os dados existentes.
Salve em uma pasta chamada my-env, verifique quais operações funcionam e diga como executar.
Usar a linha de comando
Use estes comandos se já tiver um arquivo com as requisições e respostas do aplicativo gravadas no navegador. Para executar o resultado, você também precisa do AgentEnv e do Docker.
rea environment-build ./session.har ./my-env --name my-env --json
agent-env run ./my-env
O REA exporta um ambiente executável com um teste básico para verificar se ele inicia e responde. Use com seu framework de RL para definir objetivos, adicionar verificações de recompensa e executar o treinamento.
Guia para criar um ambiente · Referência de ambientes · Veja a demonstração no X
Perguntas frequentes
Quais agentes podem usar o REA?
Qualquer agente que ofereça suporte a servidores MCP locais. A configuração prepara os agentes compatíveis; outros clientes podem usar o registro manual do MCP.
Preciso do Hopper, Ghidra, IDA ou Kuna?
A análise nativa aprofundada usa um desses motores. A inspeção estática de JavaScript e .NET funciona sem um motor de análise nativa. A configuração pode instalar o Hopper após aprovação; Ghidra, IDA e Kuna usam as instalações existentes. Consulte configuração dos provedores.
Preciso iniciar o Hopper antes?
O REA inicia o Hopper quando uma operação precisa dele. No macOS, um diálogo na primeira execução pode pedir que você escolha o modo de demonstração ou ative a licença. Consulte inicialização do Hopper e solução de problemas.
O que faz a instalação da skill pelo skills.sh?
A skill fornece instruções de investigação ao seu agente. Use npx rea-agents setup para registrar o servidor MCP do REA e instalar as instruções correspondentes, depois reinicie seu agente. Consulte instalação apenas da skill.
Que código o REA retorna?
A análise nativa retorna pseudocódigo e assembly. A análise de JavaScript/Electron recupera módulos e suas relações. Seu agente usa esses resultados para escrever e testar uma implementação; os casos de uso apresentam exemplos completos.
O REA envia meu aplicativo para algum servidor?
O REA analisa os alvos localmente. Seu agente recebe os resultados das ferramentas, e o provedor do modelo tem sua própria política de dados.
O que devo fazer se encontrar um bug?
Atualize primeiro; uma versão recente pode já ter corrigido o problema.
Para uma CLI instalada pelo npm:
rea update
Para configurar o agente por npx:
npx rea-agents@latest setup
Se você usa um agente, conclua a atualização da configuração e reinicie-o. Tente executar a mesma tarefa novamente. Se o problema persistir, abra uma issue com sua versão do REA, o tipo de alvo, os passos para reproduzir e a saída do erro.
Documentação
Comece pelos guias práticos do site. Para opções exatas, pré-requisitos e contratos dos resultados:
- Instalação e configuração: registro de agentes, configuração de provedores, atualizações e desinstalação.
- Prontidão e solução de problemas: diagnóstico de um agente ou motor de análise específico.
- CLI e Evidence: comandos, seleção de provedores, snapshots, importação/exportação e status de saída.
- Contratos MCP e prompts para agentes: resultados das ferramentas, sessões e investigações guiadas.
- Catálogo de ferramentas: inventário de ferramentas, provedores e comandos da CLI gerado durante o build.
- Roadmap: trabalho planejado e acompanhamento das capacidades.
Relate vulnerabilidades conforme SECURITY.md.
Histórico de estrelas
🎉 400.000 estrelas no GitHub — muito obrigado!
Obrigado a todos que usam o REA, relatam bugs, sugerem funcionalidades, testam builds e contribuem com correções.
Aviso legal
Consulte DISCLAIMER.md para orientações sobre o uso responsável.
O REA destina-se à pesquisa, à educação, à interoperabilidade, à preservação de software e à análise de software que você possui ou está autorizado a examinar, dentro da lei.
The project's position on illegal or unauthorized use covers all REA versions, distribution channels, and platforms; each copy retains its applicable licenses.
Contribuir
Sua ajuda com o REA é bem-vinda! Abra uma issue para relatar um bug ou sugerir uma funcionalidade, ou envie um pull request para melhorar o código ou a documentação.
Consulte CONTRIBUTING.md para configurar o ambiente de desenvolvimento e as verificações, o guia de testes para os fluxos de verificação e o mapa da arquitetura para a estrutura do projeto.
Licença
REA-authored code is licensed under MIT. Third-party material retains its own licenses and copyright notices; see Third-party notices for the dependency inventory, preserved license texts, and external-tool terms.
You must legally obtain and be authorized to use commercial tools, including IDA Pro / Hex-Rays decompilers, Hopper, and JEB, under their applicable licenses. REA grants no tool license, key, or activation entitlement. Trials and demos remain subject to vendor terms, including user, feature, automation, and output sharing restrictions. Cracked copies, stolen keys, unauthorized key sharing, and bypassing license restrictions are not authorized. This guidance does not amend MIT or third-party licenses.