22f28644fe
* feat(artifacts): inventory and extract Deno compile executables Adds Deno standalone artifact support for Mach-O, ELF, and PE carriers, exposing virtual files, entry points, recorded options, and file digests without running the executable. Extraction uses the existing safe output tree, preserves symlink targets as metadata, and assigns indexed paths to unsafe or oversized names. Environment-file values and certificate bytes remain in local Evidence; npm snapshots are reported by length without decoding. The documentation describes supported layouts, parsing limits, and refusal behavior. * fix(artifacts): resolve nested Intel Deno carriers to the enclosing app The backward trailer search stopped at the first confirmed sentinel, so an Intel app storing another Intel Deno executable as a virtual file reported the inner app. Search to the slice start, drop sentinels inside a confirmed payload, and fail closed on side-by-side trailers that differ. Correct the docs on retained environment values and generated regions. * fix(artifacts): keep Deno coverage, remote paths and PE resources truthful Report unknown coverage when the virtual filesystem cannot be listed, keep resolved specifiers when another remote ID is missing, and percent-encode characters in remote paths that a Windows destination would refuse. Reject a directory at the PE resource language level, and correct the guide's description of colliding generated regions. * fix(artifacts): normalize Deno remote escapes so hex case cannot collide Uppercase every percent escape in a generated remote path, so specifiers that differ only in escape case reach the path registry as one name and the second gets an indexed path instead of colliding on a case-insensitive disk. * fix(artifacts): fail closed on truncated enclosing Deno trailers and encode reserved remote path characters The Intel trailer scan rejected an overlong sentinel before reading its marker, so a truncated enclosing app vanished and the nested app was reported. Read the marker first and fail closed when a confirmed overlong trailer encloses another trailer. encodeURIComponent leaves `*` alone and the sanitizer covered only part of the Windows reserved set. remoteDestination now encodes the whole set once as uppercase percent hex; source_path keeps the original. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KuWHGvzJkrhCqjtEHUwqyH * fix(artifacts): defer truncated Intel Deno trailer failure until enclosing trailers resolve A damaged Intel asset stored before a valid one inside a valid app made the backward trailer search fail before it reached the outer trailer. Hold that failure until the search ends and drop it when a confirmed enclosing trailer holds the sentinel as data. * fix(pe): fail closed when a resource type branch is unreadable beside a found name namedResourceTargets skipped a type branch whose names directory, or a name entry whose string, could not be read. A duplicate RT_RCDATA entry pointing out of bounds therefore vanished once another branch matched, and locatePeResourcePayloads returned only the readable ranges while parsePeResources rejected the same tree. The walk now records unresolved branches. hasPeResourceName still reports false for a tree that never reaches the name, but once locatePeResourcePayloads finds the name it raises a format failure if any branch was left unresolved. * fix(artifacts): skip Intel Deno sentinels that a native segment maps A non-Deno x86_64 Mach-O that stores an Intel Deno executable in __DATA had the asset's trailer promoted to the root application, because the backward sentinel search never checked who owned the bytes it scanned. locateMachOSlice now records the file ranges of every segment other than __SUI and __LINKEDIT (libsui extends __LINKEDIT over the trailer), and the Intel search skips any sentinel inside one of them. A slice whose load commands do not frame stays with native inventory, since ownership cannot be shown there. * fix(artifacts): reject a universal Deno image with an unreadable sibling slice The universal Mach-O locator skipped any slice whose load commands could not be read or framed, and any slice with a FAT range issue. When another slice confirmed Deno, that slice was reported as the whole image, so a sibling declaring a different Deno application went unexamined. locateMachOSlice now reports why part of a slice was not examined (unreadable or unframed load commands, a truncated slice, or the Intel sentinel allowance). locateMachO collects those reasons for every declared and hidden slice and fails closed once any slice confirms a Deno section. With none confirmed, the image stays with native inventory as before. * fix(scripts): supervise the Deno verifier version check Run `deno --version` through the verifier command owner with a deadline instead of raw execFile, and close the owner when the version is refused. * fix(artifacts): keep unconfirmed Deno carriers native and fail truncated Intel trailers An ELF SUI note whose descriptor is too short for the full d3n0l4nd name now stays unconfirmed instead of failing closed; failures after the name matches still fail closed. Every marker-confirmed Intel trailer whose payload runs past the slice is now kept until the backward search ends and fails unless an enclosing payload contains it, so an Intel Deno app missing its last byte reports a Deno failure instead of native inventory. The Deno MCP boundary test now calls open_binary and inspect_artifact through artifactMcpCall, as docs/testing.md requires. * test(deno): drop source-text checks from verifier pin test Keep the wrong-version subprocess check, which covers the pinned release through behavior, and stop asserting on the verifier script's source spelling. * test(deno): close readers in finally in symlink and cancellation tests A failed assertion or read error in either test skipped reader.close(), leaving the file open while temp-directory cleanup ran. Both tests now close the reader in finally, as CONTRIBUTING.md requires. The closed-reader assertion in the symlink test stays after the finally. * docs(specs): add deno-standalone spec, plan and tasks Add docs/specs/artifacts/deno-standalone/ with spec.md, plan.md and tasks.md for the Deno compile executable reader, as AGENTS.md requires for a feature, and list them in the specifications index. * docs: list the Deno compile guide in the documentation sidebar * fix(deno): confirm the d3n0l4nd section before claiming Mach-O damage A __SUI segment alone no longer makes later load-command damage Deno's. A Mach-O whose __SUI segment holds only a differently named section now stays absent and keeps native inventory, while damage seen before or beside a confirmed d3n0l4nd section still fails closed. * fix(deno): keep a slice with an unparsed segment command unread A Mach-O segment command that frames but cannot be parsed may be the __SUI segment, so the slice is no longer treated as fully examined. A universal image whose other slice confirms Deno now fails closed instead of letting that sibling supply the whole inventory, and with no confirmed sibling the image still keeps native inventory. * fix(deno): confirm an ELF SUI note before rejecting its length A SUI note whose descsz runs past its note table was recorded as plain damage before its descriptor name was read, so a malformed Deno carrier fell back to native inventory. The owner and the d3n0l4nd name prefix are now read within the table apart from the claimed extent, and a confirmed note with an oversized extent fails closed. * fix(deno): confirm a truncated __SUI section record by its name A section record cut short after its 16-byte name was skipped, so a damaged Deno carrier fell back to native inventory. The name is now read apart from the rest of the record, and a truncated record that names d3n0l4nd fails closed. The range checks for a confirmed record move into their own helper. * fix(deno): reject nonzero bytes after the last ELF note When fewer than 12 bytes remained in a note table after its last note, the walk stopped without looking at them, so a Deno note was selected with complete coverage beside unaccounted data. The remainder is now read: zero padding is accepted, and nonzero bytes are recorded as damage, which fails closed once a SUI note is confirmed and otherwise leaves the ELF to native inventory, matching the native note parser. * fix(deno): validate FAT slice identity before choosing the search The locator took a universal slice's CPU type from its FAT row, so a row that called an x86_64 slice arm64 skipped that slice's Intel trailer and let the arm64 payload stand for the whole image. Each slice's header is now checked against its row with validateFatSliceIdentity. A mismatch leaves the slice unread, so a universal image whose other slice confirms Deno fails closed. The Intel fixture header now states CPU_SUBTYPE_X86_64_ALL so its FAT rows can match it exactly. * fix(deno): check the Intel trailer marker before judging its length A trailer length word of 2^53 or more was dropped before its d3n0l4nd marker was read, so an enclosing app with that length was skipped and a nested app's range stood for the whole image. The marker is now read first, and a marker-confirmed trailer whose length runs past the slice, safe or not, joins the deferred truncated candidates and fails closed unless an enclosing trailer holds it as data. * fix(deno): count short ELF note tables against the note allowance A note table shorter than one note header made a read of its trailing bytes but counted no note, so many distinct tiny tables could force one sequential read each past the 256-note allowance. Every nonempty table now counts at least one entry, both in the up-front estimate and while scanning, so an image past the allowance records the limit instead of reading every table. The trailing-byte check moves into its own helper. * fix(deno): fail closed on ELF extended section numbering beside a SUI note A zero e_shnum with a nonzero e_shoff moves the section count into section zero, so the section table was skipped and its SHT_NOTE tables were never compared. Record it as damage, as PN_XNUM already is, so a confirmed SUI note fails closed instead of reporting full coverage. * fix(deno): keep undersized Intel trailers until enclosing ownership is known A trailer length word below 8 was dropped before its d3n0l4nd marker was read, so an enclosing app with a length of 0 to 7 was skipped and a nested app's trailer was selected as the root. The marker is now read first, and a marker-confirmed trailer too short to hold it is kept as malformed and fails closed unless an enclosing trailer holds it as data. * fix(pe): treat non-directory RT_RCDATA branches as unresolved A duplicate typeId root entry whose target is a data entry was skipped without marking the walk unresolved, so locatePeResourcePayloads returned the readable named resource as complete. Route non-directory type branches through the same unresolved path as unreadable names directories so the Deno reader fails closed. * fix(deno): fail closed on a zero-fill d3n0l4nd Mach-O section denoSectionRange admitted the declared offset and size of a confirmed __SUI,d3n0l4nd record without checking its section type, so a S_ZEROFILL, S_GB_ZEROFILL or S_THREAD_LOCAL_ZEROFILL section could be read as a file payload while MachoImage reports it as not file backed. Reject zero-fill types with the shared isMachoZeroFillSection predicate before assigning a physical range. * fix(deno): bound the d3n0l4nd Mach-O section by its segment file extent denoSectionRange checked a confirmed __SUI,d3n0l4nd record only against the slice and file bounds, so a section reaching past its segment's fileoff/filesize was still read as a complete payload while MachoImage reports the same section as not file backed. Reject a section outside its enclosing segment's file extent before admitting the physical range. * style(deno): apply oxfmt to the DenoStandaloneLocation embedding union * fix(artifacts): preserve Deno carrier ownership * fix(artifacts): admit Deno parent segments * fix(deno): preserve native segment ownership * test(deno): cover mismatched Mach-O segment widths --------- Co-authored-by: Matt Van Horn <455140+mvanhorn@users.noreply.github.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: morluto <76467478+morluto@users.noreply.github.com>
34 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: Ingeniería inversa de cualquier cosa
Un solo MCP para la ingeniería inversa de binarios, aplicaciones y comportamiento en ejecución.
¿Ves una función que te gusta? Entiende cómo funciona, hasta el nivel binario.
Sitio web · Guías · Casos prácticos
Inicio rápido · Cómo funciona REA · Qué puedes analizar · Casos prácticos · Crear entornos de RL · Preguntas frecuentes · Documentación
npx rea-agents setup
Important
Fuentes oficiales de REA: morluto/rea, rea.tools, rea-agents (npm). Usa los enlaces de instalación y de versiones publicados en estas fuentes oficiales. Un nombre de repositorio parecido o un README copiado no demuestra que una descarga sea oficial.
 Únete a la comunidad de ingeniería inversa Discord · Preguntas y respuestas · Comparte tus resultados |
¿Has visto una función en una aplicación que quieres incorporar a tu producto? Pide a tu agente que la investigue con REA. Puede inspeccionar la aplicación sin su código fuente, explicar cómo funciona la función, mostrar las pruebas y crear una versión para tu proyecto.
REA conecta tu agente con herramientas para inspeccionar binarios nativos, aplicaciones JavaScript y Electron, ensamblados .NET y sitios web. También puedes usar las mismas herramientas desde la terminal. El análisis se ejecuta localmente y los resultados incluyen las pruebas y limitaciones que sustentan cada conclusión.
La configuración registra REA con tu agente e instala las instrucciones de trabajo correspondientes. El análisis nativo puede usar Hopper, Ghidra, IDA o Kuna ya instalados; la configuración puede instalar Hopper con tu aprobación. El análisis estático de JavaScript no requiere un motor de análisis nativo.
Visita el sitio web de REA para encontrar instrucciones de configuración, guías ilustradas y casos reales.
Inicio rápido
En Linux, iniciar Ghidra, JADX y herramientas de firmware, y analizar JavaScript/Electron estáticamente, requiere un ps compatible con procps en el PATH de REA para comprobar la propiedad de los procesos. Consulta el requisito de Linux.
Configura tu agente
Con Node.js y npm instalados, ejecuta:
npx rea-agents setup
Elige tus agentes, revisa los cambios propuestos y apruébalos. La configuración añade el servidor MCP de REA y las instrucciones de trabajo correspondientes, con copias de seguridad de la configuración existente. Reinicia tu agente al terminar.
La configuración admite Claude Code, Codex, Cursor, Gemini CLI, Grok Build y otros agentes. Consulta instalación y configuración para configurar proveedores y registrar MCP manualmente.
MCP usa esquemas de entrada compactos por defecto. Para ver todas las instrucciones de campos y la validación anidada, establece REA_MCP_INPUT_SCHEMA_PROFILE=full en el registro MCP. Ambos perfiles conservan todas las herramientas y la misma validación canónica del servidor; consulta la guía de contratos MCP.
Pregunta a tu agente
Investiga cómo funciona la búsqueda en la aplicación Notes, muéstrame las pruebas y crea una función similar para mi proyecto.
Sustituye Notes por la aplicación objetivo y especifica la función que quieres entender.
Usa la terminal
Inspecciona un directorio extraído de una aplicación JavaScript/Electron o un archivo ASAR:
npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --json
El resultado incluye módulos, importaciones, límites de Electron y sus pruebas. Sustituye la ruta por la de tu objetivo, por ejemplo "D:/apps/example" en Windows.
Para instalar el comando rea y usarlo habitualmente:
npm install --global rea-agents
rea --help
Para el análisis nativo, configura primero un proveedor. Consulta la guía de CLI y Evidence para los comandos nativos, la selección de proveedores, las instantáneas y el uso en scripts.
Actualiza REA
REA cambia rápidamente y las nuevas versiones incluyen correcciones frecuentes. Mantén tu instalación actualizada.
Para una CLI instalada mediante npm install --global / bun add --global:
rea update
rea --update es un alias de rea update con las mismas opciones globales de salida. Los comandos de actualización conservan como máximo 4 MiB de stdout/stderr combinados. Los metadatos demasiado grandes se rechazan al terminar; las instalaciones detalladas conservan diagnósticos acotados. El progreso respeta la contrapresión del terminal y espera las escrituras enviadas.
Las actualizaciones globales con Bun requieren Bun 1.2.17 o posterior. Actualiza manualmente las versiones anteriores antes de ejecutar rea update.
Para actualizar los registros de tus agentes y la skill, ejecuta el comando de configuración que muestra la actualización.
Si usas npx, actualiza la configuración de tu agente con:
npx rea-agents@latest setup
Revisa los cambios de configuración y reinicia tu agente. Para ejecutar comandos de CLI puntuales, usa npx rea-agents@latest seguido del comando.
Con Bun, usa bunx rea-agents@latest en lugar de npx rea-agents@latest.
Cómo funciona REA
Tu agente llama a REA mediante MCP para inspeccionar el objetivo y seguir el código relevante. REA devuelve los hallazgos junto con sus pruebas. El agente los utiliza para hacer preguntas de seguimiento, explicar el comportamiento o escribir y probar una implementación. Los comandos de CLI usan los mismos flujos de trabajo.
Abre la figura a tamaño completo.
Qué puedes analizar
REA requiere Node.js 22.x (>=22.23.4), 24.x (>=24.22.1) o 26+ (>=26.12.1), además de npm. Las herramientas adicionales y los sistemas anfitriones compatibles dependen del objetivo:
| Objetivo | Qué devuelve REA | Requisitos y guía |
|---|---|---|
| Binarios nativos | Pseudocódigo, ensamblador, cadenas, símbolos, llamadas y referencias | Hopper, Ghidra, IDA o Kuna; análisis nativo |
| Estructura ELF sin ejecutar | Secciones, segmentos, símbolos/reubicaciones originales y posibles medidas de mitigación detectadas mediante análisis estático | pwntools proporcionado por quien llama, en Linux x64; diagnóstico de binarios |
| 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 |
| Windows shortcuts | Shell Link target, arguments, working dir, ExtraData and Tracker droid facts | Built-in static LNK inspection; Windows shortcuts |
| Bytecode EVM | Selectores de despacho, desplazamientos en bytes, argumentos inferidos y mutabilidad | Entrada local con bytes sin procesar o representación hexadecimal, en Linux x64; guía de EVM sin ejecutar |
| 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 |
| Fallos de Linux registrados | Registros note sin procesar, registros/señales de cada hilo registrado y posibles correspondencias de memoria opcionales | pwntools proporcionado por quien llama, en Linux x64; GDB/pwndbg opcionales; fallos registrados |
| Instalaciones de escritorio | Posibles entornos de ejecución, archivos de evidencia, componentes y siguientes pasos | Inspección acotada de directorios y cabeceras；Aplicaciones de escritorio |
| JavaScript / Electron | Módulos, importaciones, mapas de código fuente, rutas, IPC y relaciones con complementos nativos | Node.js y npm; análisis de aplicaciones; Linux: procps ps |
| Sitios web | Estructura de la página, scripts, observaciones de red y capturas de pantalla solicitadas | Un navegador de la familia Chrome; análisis del navegador |
| Capturas de red guardadas | Solicitudes, respuestas, contenido accesible de las cargas útiles y ubicaciones de origen | HAR / Fiddler Everywhere SAZ; mitmdump en Linux para capturas en formato nativo de mitmproxy; guía de capturas |
| Capturas de paquetes | Endpoints, DNS, TLS SNI, distribución de protocolos y solicitudes HTTP | tshark y capinfos suministrados por el autor de la llamada; guía pcap |
| Ensamblados .NET | Metadatos, instrucciones CIL, dependencias nativas declaradas y comparaciones de compilaciones | Inspección estática; guía de código administrado |
| PyInstaller | CArchive, PYZ, Python bytecode | Static inspection; Python packaged applications |
| Deno compile binaries | Virtual files, entry point, recorded options, npm snapshot length | Static inspection; Deno compile executables |
| APK de Android | Declaraciones del manifiesto, clases, métodos descompilados y referencias | JADX sin interfaz gráfica y un JDK completo en Linux/macOS/Windows x64; guía de Android |
| Dispositivos Android | Dispositivos, paquetes, procesos, registros, volcados, capturas de pantalla y transferencias de APK/archivos | adb suministrado por el autor de la llamada (emulador o dispositivo); guía de ADB |
| Proyectos JEB | Unidades de proyecto del motor, resúmenes de artefactos y pseudocódigo de tipos/métodos | Un cliente JEB iniciado por el autor de la llamada que sirve MCP, seleccionado con REA_JEB_MCP_URL; guía de JEB |
| Recursos de Android | Manifiesto decodificado, tablas de cadenas, idiomas y datos de versión | Lanzador de Apktool suministrado por el autor de la llamada; guía de recursos |
| Aplicaciones Flutter | Hash de snapshot de Dart, resúmenes de bibliotecas por ABI y procedencia de compilación del motor | Ninguna (análisis APK estático); guía de Flutter |
| Firmware | Regiones, resultados de extracción y derivaciones al análisis nativo | Binwalk / Unblob en Linux; guía de firmware |
| Paquetes grabados | Campos seleccionados, valores repetidos, filtros y reglas de decodificación | Linux: TShark 4.x + prlimit; guía de capturas |
| Señales lógicas grabadas | Anotaciones del decodificador, rangos de muestras y diagnósticos | Linux: sigrok-cli 0.7.2 + prlimit; guía de señales |
| Paquetes y recursos | Inventarios de archivos, resúmenes criptográficos, plists, estructura de paquetes de Apple y recursos extraídos | Guía de artefactos y JavaScript, aplicaciones de Apple |
| Comportamiento de procesos | Salida de la terminal, interacciones, observaciones de salida y del sistema de archivos, y comparaciones entre ejecuciones | Linux/macOS con una PTY nativa; captura de procesos |
| Binarios Go | Versión del compilador integrada, módulos, reemplazos y ajustes de compilación | Inspección estática integrada ELF/PE/thin Mach-O; No requiere instalar Go |
| Bases de datos SQLite | Tablas, columnas, índices, vistas, disparadores y filas seleccionadas de tablas ordinarias | Instantánea local de base/WAL; Node.js 24.x >=24.15 o 26+ con límites nativos de SQLite |
| Objetos de código GPU | Destinos CUDA/HIP, parámetros y recursos de kernels seleccionados, texto PTX conservado | Inspección estática integrada ELF/PE/fatbin/CUBIN/PTX; GPU |
| Archivos de modelos | Metadatos GGUF / safetensors, declaraciones de tensores y totales derivados | Inspección de cabeceras; hash completo opcional; GGUF / safetensors |
| Metadatos IL2CPP | Imágenes de ensamblado Unity global-metadata.dat, nombres de tipos/métodos y rangos de índices | Decodificación estática de versiones 24, 27, 29, 31, 39; sin Unity |
| Godot PCK | Inventario y extracción, cabeceras/directorios originales e identidad del contenido seleccionado | Formatos estáticos 2, 3, 4; sin Godot |
| Artefactos WASM | Validación, secciones, formas WAT exactas de importación/exportación y WAT decodificado | Aportado por quien llama WABT 1.0.42; inspect_wasm_artifact |
| Firmas APK | Firmantes v1/v2/v3/v3.1, huellas de certificados, rotación de claves y coherencia interna de resúmenes | Inspección estática integrada; inspect_apk_signature |
La inspección estática de JavaScript y .NET lee los archivos suministrados sin ejecutar la aplicación. La captura en ejecución inicia el objetivo seleccionado o interactúa con él con los permisos de tu usuario; cada guía describe sus efectos.
Para inspeccionar binarios nativos sin conexión, REA también admite GNU objdump y Rizin, que debes proporcionar por tu cuenta. La guía de herramientas de ingeniería inversa explica la configuración de los proveedores, los comandos de la CLI y las limitaciones de Evidence. REA no instala ni actualiza ninguno de estos proveedores.
Para binarios grandes, aumenta el plazo de inicio mediante REA_GHIDRA_STARTUP_TIMEOUT_MS o REA_HOPPER_STARTUP_TIMEOUT_MS.
Los formatos nativos y los sistemas anfitriones compatibles varían según el proveedor. Consulta configuración de Hopper y Ghidra, la guía de IDA, Kuna y la compatibilidad experimental de Ghidra en Windows. Ghidra también admite análisis de DOS de 16 bits. Para elegir un proveedor, consulta la guía de CLI. Comprueba la disponibilidad por versión de las funciones añadidas después de la última versión publicada en npm.
Casos prácticos
DX-Ball: reconstruir un cálculo de panoramización de sonido
Sigue una llamada de sonido hasta la función auxiliar que convierte la posición en panoramización, inspecciona las instrucciones y transforma el pseudocódigo incompleto en C. La reconstrucción supera 3.205 casos con el x86 original y reproduce los 63 bytes de la función compilada.
Lee el caso práctico · Repositorio de reconstrucción
Notion: seguir el puente del portapapeles de Electron
Encuentra la API del portapapeles del proceso de renderizado, síguela a través de preload e IPC hasta el proceso principal e inspecciona el formato enriquecido del portapapeles.
TH04: recuperar el cálculo de un anillo de proyectiles en DOS
Inspecciona las instrucciones de 16 bits del juego original para PC-98, recupera los cálculos de ángulos fijos y dirigidos, y compara el C++ reconstruido con la salida del compilador de la época.
Lee el caso práctico · Repositorio de reconstrucción
Crear entornos de RL con REA
Graba una sesión de una aplicación web, convierte su API en herramientas y exporta un entorno que un agente de IA pueda usar. Ejecútalo con AgentEnv y añade tareas y comprobaciones de recompensa para entrenamiento RL o evaluación.
Guía para crear un entorno · Ver la demo en X
Si has usado REA para investigar algo interesante, nos gustaría verlo. Comparte tu caso en una issue o una pull request, incluyendo el objetivo, tu pregunta, cómo te ayudó REA y qué encontraste.
Crear entornos de RL
Crea un entorno local donde un agente de IA pueda practicar tareas como buscar un issue o crear una carpeta, sin ejecutar la aplicación original. Úsalo para aprendizaje por refuerzo (RL) o para comprobar cómo completa las tareas un agente.
REA convierte las solicitudes y respuestas de API grabadas en herramientas que el agente puede llamar. El entorno usa los datos grabados y solo admite cambios cuyos efectos confirma la grabación.
Configura REA en tu agente y sustituye la URL y las tareas de carpetas del ejemplo por las tuyas:
Usa REA para crear un entorno de RL a partir de mi aplicación web de prueba en
http://127.0.0.1:3000.
Incluye listar, crear, renombrar y borrar carpetas. Puedes crear y borrar
carpetas de prueba, pero no modifiques los datos existentes.
Guárdalo en una carpeta llamada my-env, comprueba qué operaciones funcionan y dime cómo ejecutarlo.
Usar la línea de comandos
Usa estos comandos si ya tienes un archivo con las solicitudes y respuestas de la aplicación grabadas en el navegador. Para ejecutar el resultado también necesitas AgentEnv y Docker.
rea environment-build ./session.har ./my-env --name my-env --json
agent-env run ./my-env
REA exporta un entorno ejecutable con una prueba básica que comprueba que arranca y responde. Úsalo con tu framework de RL para definir objetivos, añadir comprobaciones de recompensa y ejecutar el entrenamiento.
Guía para crear un entorno · Referencia de entornos · Ver la demo en X
Preguntas frecuentes
¿Qué agentes pueden usar REA?
Cualquier agente que admita servidores MCP locales. La configuración prepara los agentes compatibles; otros clientes pueden usar el registro manual de MCP.
¿Necesito Hopper, Ghidra, IDA o Kuna?
El análisis nativo en profundidad utiliza uno de ellos. La inspección estática de JavaScript y .NET funciona sin un motor de análisis nativo. La configuración puede instalar Hopper después de tu aprobación; Ghidra, IDA y Kuna usan las instalaciones que ya tienes. Consulta configuración de proveedores.
¿Tengo que iniciar Hopper primero?
REA inicia Hopper cuando una operación lo necesita. En macOS, puede aparecer un diálogo al iniciarlo por primera vez para elegir el modo de demostración o activar tu licencia. Consulta inicio de Hopper y resolución de problemas.
¿Qué hace la instalación de la skill desde skills.sh?
La skill proporciona instrucciones de investigación a tu agente. Usa npx rea-agents setup para registrar el servidor MCP de REA e instalar las instrucciones correspondientes; después reinicia tu agente. Consulta instalación solo de la skill.
¿Qué código devuelve REA?
El análisis nativo devuelve pseudocódigo y ensamblador. El análisis de JavaScript/Electron recupera módulos y sus relaciones. Tu agente utiliza estos hallazgos para escribir y probar una implementación; los casos prácticos ofrecen ejemplos completos.
¿REA sube mi aplicación?
REA analiza los objetivos localmente. Tu agente recibe los resultados de las herramientas, y su proveedor de modelos tiene su propia política de datos.
¿Qué debo hacer si encuentro un error?
Actualiza primero; una versión reciente puede haber solucionado el problema.
Para una CLI instalada mediante npm:
rea update
Para configurar el agente mediante npx:
npx rea-agents@latest setup
Si usas un agente, completa la actualización de la configuración y reinícialo. Repite la misma tarea. Si el problema continúa, abre una issue con tu versión de REA, el tipo de objetivo, los pasos para reproducirlo y la salida del error.
Documentación
Empieza con las guías prácticas del sitio web. Para opciones exactas, requisitos y contratos de resultados:
- Instalación y configuración: registro de agentes, configuración de proveedores, actualizaciones y desinstalación.
- Preparación y resolución de problemas: diagnóstico de un agente o motor de análisis concreto.
- CLI y Evidence: comandos, selección de proveedores, instantáneas, importación/exportación y estados de salida.
- Contratos de MCP y prompts para agentes: resultados de herramientas, sesiones e investigaciones guiadas.
- Catálogo de herramientas: inventario de herramientas, proveedores y comandos de CLI generado durante la compilación.
- Hoja de ruta: trabajo previsto y seguimiento de capacidades.
Informa de vulnerabilidades siguiendo SECURITY.md.
Historial de estrellas
🎉 400.000 estrellas en GitHub: ¡gracias!
Gracias a quienes usan REA, informan de errores, solicitan funciones, prueban compilaciones y contribuyen con correcciones.
Aviso legal
Consulta DISCLAIMER.md para obtener orientación sobre el uso responsable.
REA está destinado a la investigación, la educación, la interoperabilidad, la preservación de software y el análisis de software propio o autorizado, dentro de la ley.
The project's position on illegal or unauthorized use covers all REA versions, distribution channels, and platforms; each copy retains its applicable licenses.
Contribuir
¡Nos encantaría que ayudaras con REA! Abre una issue para comunicar un error o proponer una función, o envía una pull request para mejorar el código o la documentación.
Consulta CONTRIBUTING.md para preparar el entorno de desarrollo y las comprobaciones, la guía de pruebas para los procesos de verificación y el mapa de arquitectura para la estructura del proyecto.
Licencia
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.