REA verbindet Claude Code und Cursor mit Tools für Reverse Engineering
Das Kommandozeilen-Tool REA ermöglicht Coding-Agenten wie Claude Code und Cursor Reverse Engineering: So können sie etwa Windows-Assembler-Code analysieren und erklären, warum eine Prozentrechnung in der Windows-Rechner-App ein bestimmtes Ergebnis liefert.
Veröffentlicht am 10. Oktober • Zuerst erschienen auf elsolitario.org
Ein Code-Agent kann inzwischen den Assembler-Code der Windows-Rechnung öffnen, den Sprung finden, der das Addieren von 10 Prozent vom Multiplizieren unterscheidet, und auf Spanisch erklären, warum 200 + 10 % 220 ergibt. Genau das macht REA, ein Werkzeug, das Claude Code, Cursor und andere Agents mit dem klassischen Stack des Reverse Engineerings verbindet: Decompiler, Debugger und Speicherabbilder.
Das Projekt, veröffentlicht auf rea.tools, automatisiert die Arbeit, die früher Stunden mit einem Debugger erforderte: Verzweigungen dekodieren, Aufrufe nachverfolgen und die Regel hinter einem Programm rekonstruieren. Das Interessante ist dabei nicht der Einzelfall mit dem Taschenrechner. Derselbe Ablauf eignet sich, um ein Spiel, eine Firmware oder eine Bibliothek ohne verfügbaren Quellcode zu überprüfen.
REA ist ein Open-Source-Werkzeug, das Code-Agents wie Claude Code oder Cursor mit den klassischen Bausteinen des Reverse Engineerings verbindet: Decompilern, Debuggern und Speicherabbildern, damit das Modell eine Funktion eines Programms erklären, verändern oder rekonstruieren kann, ohne dass eine Person von Hand Assembler lesen muss.
Anders als ein Plugin für Ghidra oder ein Frida-Skript, das automatische Analysen ausführt, interpretiert REA die Binärdatei nicht selbst. Es liefert dem Agenten dieselben Daten, die ein menschlicher Analyst verwenden würde (CPU-Instruktionen, dekompilierter Code, Funktionsaufrufe, Werte im Speicher), und lässt das Modell in natürlicher Sprache darüber nachdenken. Das Ergebnis ähnelt eher einem Assistenten, der das Disassemblierte für einen liest und erzählt, was er gefunden hat, als einer Blackbox, die fertige Antworten ausspuckt.
Es wird im bereits genutzten Agenten installiert und ersetzt kein anderes Werkzeug: Es fügt sich als eine Schicht hinzu, die dem Agenten Augen für kompilierte Programme, laufende Prozesse oder in eine Webseite geladene Skripte gibt. Ghidra, 2019 von der NSA veröffentlicht, ist einer der Decompiler, mit denen REA arbeiten kann.
Jahrzehntelang erforderte das Verstehen eines Programms ohne Quellcode Jahre der Praxis mit einem Disassembler. Reverse Engineering mit Agents beseitigt diese Lernkurve nicht, verkleinert sie aber: Jemand, der noch nie x64dbg geöffnet hat, kann seinen Agenten bitten, den Assembler-Code in eine überprüfbare Hypothese zu übersetzen, und sich darauf konzentrieren, diese Hypothese zu prüfen, statt sie von Grund auf zu erstellen.
Dasselbe Prinzip gilt für Software ohne Dokumentation: aufgegebene Videospiele, die jemand bewahren möchte, Treiber ohne Handbuch, geschlossene Netzwerkprotokolle oder Schadsoftware, die verstanden werden muss, bevor man sie blockieren kann. In all diesen Fällen existiert der Quellcode nicht oder ist nicht zugänglich, und der einzige Weg besteht darin, die Binärdatei so zu untersuchen, wie sie läuft.
Hinweis: Die Analyse von Software ohne Autorisierung des Eigentümers oder außerhalb der gesetzlichen Grenzen der eigenen Rechtsordnung (Ausnahmen für Interoperabilität, autorisierte Sicherheitsforschung, eigene Software) kann rechtliche Konsequenzen haben. REA ändert an dieser Regel nichts.
Es gibt einen größeren Hintergrund: Code-Agents lesen und schreiben bereits Dateien, durchsuchen das Web und führen Befehle aus. Ihnen Zugriff auf laufende Prozesse und Decompiler zu geben ist der logische nächste Schritt derselben Entwicklung, keine eigene Kategorie.
REA fungiert als Brücke zwischen dem Agenten und dem Zielprogramm. Wenn man es bittet, etwas zu untersuchen, verbindet sich REA mit der Binärdatei, dem Prozess im Speicher oder der Webseite (über eine lokale Debug-Verbindung), extrahiert die Instruktionen, den dekompilierten Code oder das geladene Skript und gibt dieses Material als Text an den Agenten zurück, den das Modell lesen und darüber nachdenken kann.
flowchart TD A [ "Entwickler" ] -- > B [ "Code-Agent" ] B -- > C [ "REA" ] C -- > D [ "Binärdatei oder Skript in Ausführung" ] D -- > C C -- > B B -- > A Enter fullscreen mode Exit fullscreen mode Der Agent erhält keine magische Antwort: Er bekommt dieselben rohen Eingabedaten, die ein menschlicher Reverse Engineer verwenden würde. Was sich ändert, ist die Frage, wer das Lesen Zeile für Zeile übernimmt.
sequenceDiagram participant D as Entwickler participant A as Agent participant R as REA participant P as Zielprogramm D -> > A: warum ergibt 200 plus 10 Prozent 220 A -> > R: die Binärdatei untersuchen R -> > P: Instruktionen und Aufrufe lesen P -- >> R: Assembler und Werte R -- >> A: dekompilierter Code A -- >> D: Erklärung der Regel Enter fullscreen mode Exit fullscreen mode Diese Trennung der Zuständigkeiten ist der Schlüssel: REA übernimmt die Mechanik der Verbindung zum Prozess (sich an ihn anhängen, eine Funktion dekompilieren, eine Variable lesen), und der Agent interpretiert diese Daten, formuliert eine Hypothese und erklärt sie oder wandelt sie in neuen Code um.
Das Beispiel, das das Projekt selbst verwendet, ist der Windows-Rechner: 200 + 10 % ergibt 220, und die Frage ist warum. Ein menschlicher Analyst würde drei Schritte folgen: dekodieren, welcher Programmpfad der Prozenttaste entspricht, nachverfolgen, welche Funktionen dieser Pfad aufruft, und die Formel aus den Werten rekonstruieren, die er vorbeiziehen sieht. Mit REA ist der Prompt direkt: Use REA to inspect Windows Calculator. Why does 200 + 10% give 220? Der Agent führt diese drei Schritte selbstständig aus und liefert die Regel als Text zurück.
Die Regel, die er rekonstruiert, in eigens zur Veranschaulichung erstelltem Pseudocode, sieht so aus:
double percent_button ( double accumulator, double operand ) { double delta = accumulator * operand / 100. 0; return accumulator + delta; } // percent_button(200, 10) ergibt 220 // weil 200 * 10 / 100 = 20, und 200 + 20 = 220 Enter fullscreen mode Exit fullscreen mode Das zweite Beispiel ist spektakulärer: das Dinosaurier-Spiel, das im Fehlerbildschirm von Chrome läuft, wenn keine Verbindung besteht. Der gestellte Prompt lautet Use REA to inspect this dinosaur game. Why does it get faster? REA liest die index.js, die der Browser zu diesem Zeitpunkt geladen hat, und liefert die tatsächliche Bedingung zurück, die die Geschwindigkeit steuert: Sie startet bei 6, erhöht sich pro Aktualisierung ohne Kollision um 0,001 und stoppt beim Erreichen von 13.
let speed = 6; const ACCELERATION = 0.001; const MAX_SPEED = 13; function tick () { if ( speed [ Frida ]( https: //frida.re/), 2013 veröffentlicht, ermöglicht es, eine laufende App zu instrumentieren, ohne sie neu zu kompilieren. ## Häufige Fehler und bewährte Praktiken - ** Analysieren ohne Autorisierung **, die Grundregel ändert sich nicht, nur weil ein Agent im Spiel ist: Wenn die Software einem nicht gehört oder keine Erlaubnis vorliegt, sollte man sie nicht analysieren. - ** Der Hypothese vertrauen, ohne sie zu überprüfen **, ein Modell kann auch beim Lesen von Assembler-Code halluzinieren. Die Regel, die REA zurückliefert, ist ein Ausgangspunkt, keine bewiesene Schlussfolgerung. - ** Rohdaten mit Inferenz vermischen **, was REA liefert ( Instruktionen, dekompilierter Code ), ist eine Tatsache; was der Agent daraus schließt, ist eine Hypothese, die man am realen Programm prüfen muss. - ** Anti-Debugging-Schutz oder Packung ignorieren **, eine obfuszierte Binärdatei verwirrt den menschlichen Analysten ebenso wie den Agenten; eine saubere Antwort sollte man dort nicht erwarten. - ** Gefundenes nicht dokumentieren **, ohne ein Protokoll der Sitzung muss man bei der nächsten Gelegenheit die gesamte Analyse von Grund auf neu aufbauen. ## Vergleich mit Alternativen OptionWann sie verwendenVorteilEinschränkungGhidra oder IDA manuellTiefgehende Analyse einer komplexen Binärdatei oder von MalwareVollständige Kontrolle über jede InstruktionLernkurve von MonatenFrida ( dynamische Instrumentierung ) Funktionen einer laufenden App hooken, ohne sie neu zu kompilierenBeobachtet echtes Verhalten in EchtzeitMan muss vorher wissen, welche Funktion man suchtBinary Ninja mit eigenen SkriptenWiederholende Analysen automatisierenAusgereifte Scripting-APIVerlangt ebenfalls, die Binärdatei zuerst zu verstehenREA plus ein Code-AgentEin Programm schnell erkunden ohne Vorerfahrung mit RENatürliche Sprache, iteriert in MinutenHängt vom Urteilsvermögen des Agenten ab, ersetzt kein formales Audit Der Vorteil von REA liegt in der Erkundungsgeschwindigkeit: In wenigen Minuten hat man eine Hypothese darüber, was eine Funktion tut. Die Einschränkung ist dieselbe wie bei jeder Analyse mit Unterstützung eines Sprachmodells: Die Antwort kann sicher klingen und trotzdem falsch sein, deshalb ersetzt sie kein formales Audit, wenn es um Kritisches geht. ## Vertiefung ( fortgeschritten ) Im Inneren durchläuft das Dekodieren einer Binärdatei klar definierte Etappen: Zuerst übersetzt der Disassembler Bytes in CPU-Instruktionen ( das Beispiel des Rechners, mit `CMP` und `JZ`, die den Code der gedrückten Taste vergleichen ), danach hebt der Dekompiler diese Instruktionen auf eine Zwischendarstellung und von dort zu C-ähnlichem Pseudocode an, und schließlich rekonstruiert jemand ( oder etwas ) den Kontrollflussgraphen, um zu verstehen, welche Verzweigung zu welchem Ergebnis führt.
Enter fullscreen mode Exit fullscreen mode flowchart LR A["Verzweigungen dekodieren"] --> B["Aufrufe nachverfolgen"] B --> C["Die Regel rekonstruieren"]
Ein Sprachmodell liest C-ähnlichen Pseudocode besser als rohen x64-Assembler-Code, weil er dem ähnelt, was es während seines Trainings gesehen hat. Das erklärt, warum REA dekompilierten Code liefert statt nur Adressen und Opcodes: Das ist keine Frage der Ästhetik, sondern genau das, was den Agenten mit weniger Fehlern denken lässt. Die statische Analyse (das ruhig liegende Binary lesen) und die dynamische Analyse (es während der Ausführung beobachten) beantworten unterschiedliche Fragen.
Der Fall des Taschenrechners ist statisch: Die Logik wird gelesen, ohne sie auszuführen. Der Fall des Dinosauriers ist dynamisch: Die echte Spielfunktion wird in einem kontrollierten Browser aufgerufen, um zu messen, wie sich die Geschwindigkeit verändert. Ein vollständiger Reverse-Engineering-Workflow kombiniert in der Regel beides, und ein an REA angebundener Agent kann je nachdem, was er bestätigen muss, jedes der beiden Verfahren anfordern.
Die Schutzmechanismen, die diese Arbeit am stärksten erschweren (Packaging, Obfuscation des Kontrollflusses, Debugger-Erkennung, Adressrandomisierung) verschwinden nicht, nur weil ein Agent im Spiel ist. Sie bleiben die tatsächliche Grenze zwischen einer Analyse, die Minuten dauert, und einer, die Wochen dauert, mit oder ohne KI. > **💡 Tipp:** Wenn der Agent dir eine Regel liefert, die zu einfach klingt, bitte ihn, sie an einem zweiten Fall mit anderen Zahlen zu testen, bevor du sie akzeptierst. Dein nächster Schritt: Installiere REA mit `npx rea-agents@latest setup` in einem Testprojekt und bitte deinen Agenten, die einfachste Funktion einer Binärdatei zu erklären, die du bereits kennst, um seine Hypothese mit dem echten Code zu vergleichen. 📖 Zusammenfassung auf Telegram: [Zusammenfassung ansehen](https://telegra.ph/REA-el-CLI-que-da-ingeniería-inversa-a-Claude-Code-y-Cursor-10-10) ## Häufige Fragen ### Was genau tut REA für einen Coding-Agenten?
Er gibt ihm Zugriff auf CPU-Instruktionen, dekompilierten Code und Funktionsaufrufe eines laufenden Programms, damit der Agent über diese Daten in natürlicher Sprache reasoning betreiben kann. ### Ist Reverse Engineering mit Agenten legal? Es hängt davon ab, was du analysierst und mit welcher Erlaubnis. Eigene Software, autorisierte Sicherheitsforschung oder die Interoperabilitätsausnahmen, die mehrere Rechtsordnungen anerkennen, sind übliche Fälle; etwas ohne Recht darauf zu analysieren, ändert seinen rechtlichen Status nicht dadurch, dass ein Agent beteiligt ist. ### Ersetzt REA Ghidra oder Frida?
Nein. Es stützt sich auf diese Art von Werkzeugen (Dekompilierer, Debugger, dynamische Instrumentierung), um die Daten zu erhalten; der Agent ist es, der interpretiert und erklärt. ### Welche Coding-Agenten funktionieren mit REA? Das Projekt ist für Agenten wie Claude Code oder Cursor ausgelegt und wird über `npx rea-agents@latest setup` direkt auf dem bereits konfigurierten Agenten installiert. ### Eignet sich REA zur Analyse von Malware?
Mit denselben Vorsichtsmaßnahmen wie immer: isolierte Umgebung, die Probe niemals außerhalb einer Sandbox ausführen, und niemals auf einer Maschine, die mit echten Daten verbunden ist. ### Was passiert, wenn der Agent sich beim Erklären einer Binärdatei irrt? Dasselbe, was passiert, wenn er sich beim Schreiben von Code irrt: Die Hypothese muss gegen das echte Programm verifiziert werden, bevor man sich auf sie verlässt oder etwas darauf aufbaut. ## Referenzen - [REA](https://rea.tools/): offizielle Website des Projekts, mit der Installationsanleitung und den Beispielen des Windows-Taschenrechners und des Dinosaurierspiels.- [Ghidra](https://ghidra-sre.org/): Open-Source-Reverse-Engineering-Framework der NSA, verwendet als Referenz für klassische Dekompilierer.- [Frida](https://frida.re/): Toolkit zur dynamischen Instrumentierung, um laufende Prozesse zu inspizieren.- [Reverse engineering](https://en.wikipedia.org/wiki/Reverse_engineering): historischer und technischer Kontext des Fachgebiets auf Wikipedia. 📱 **Gefällt dir dieser Inhalt?** Tritt unserem Telegram-Kanal [@programacion](https://t.me/programacion) bei, wo wir täglich das Wichtigste aus Technologie, KI und Entwicklung veröffentlichen. Kurze Zusammenfassungen, frische Inhalte jeden Tag.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Posted on Oct 10 • Originally published at elsolitario.org
Un agente de código ya puede abrir el ensamblador de la calculadora de Windows, encontrar el salto que distingue sumar un 10% de multiplicarlo, y explicarte en español por qué 200 + 10% da 220. Eso es lo que hace REA, una herramienta que conecta a Claude Code, Cursor y otros agentes con el stack clásico de la ingeniería inversa con agentes: decompiladores, debuggers y volcados de memoria.
El proyecto, publicado en rea.tools, automatiza el trabajo que antes exigía horas con un debugger: decodificar ramas, rastrear llamadas y reconstruir la regla detrás de un programa. Lo interesante no es el truco puntual de la calculadora. El mismo flujo sirve para auditar un juego, un firmware o una librería de la que no tenés el código fuente.
REA es una herramienta de código abierto que conecta agentes de código, como Claude Code o Cursor, con las piezas clásicas de la ingeniería inversa con agentes: decompiladores, debuggers y volcados de memoria, para que el modelo explique, modifique o reconstruya una función de un programa sin que la persona lea ensamblador a mano.
A diferencia de un plugin para Ghidra o un script de Frida que corre análisis automático, REA no interpreta el binario por su cuenta. Le entrega al agente los mismos datos que usaría un analista humano (instrucciones de la CPU, código decompilado, llamadas a funciones, valores en memoria) y deja que el modelo razone sobre ellos en lenguaje natural. El resultado se parece más a tener un asistente que lee el desensamblado por vos y te cuenta qué encontró, que a una caja negra que escupe respuestas.
Se instala en el agente que ya usás, no reemplaza ninguna herramienta: se suma como una capa que le da ojos sobre programas compilados, procesos corriendo o scripts cargados en una página web. Ghidra, publicado por la NSA en 2019, es uno de los decompiladores con los que REA puede trabajar.
Durante décadas, entender un programa sin su código fuente exigió años de práctica con un desensamblador. La ingeniería inversa con agentes no borra esa curva de aprendizaje, pero la achica: alguien que nunca abrió x64dbg puede pedirle a su agente que traduzca el ensamblador a una hipótesis verificable, y dedicarse a revisar esa hipótesis en lugar de construirla desde cero.
El mismo principio aplica a software sin documentación: videojuegos abandonados que alguien quiere preservar, drivers sin manual, protocolos de red cerrados o malware que hay que entender antes de poder bloquearlo. En todos esos casos el código fuente no existe o no es accesible, y la única vía es examinar el binario tal cual corre.
📌 Nota: analizar software sin autorización del dueño o fuera de los límites legales de tu jurisdicción (excepciones de interoperabilidad, investigación de seguridad autorizada, software propio) puede tener consecuencias legales. REA no cambia esa regla.
Hay un trasfondo más amplio: los agentes de código ya leen y escriben archivos, navegan la web y ejecutan comandos. Darles acceso a procesos en ejecución y a decompiladores es el siguiente paso lógico de esa misma tendencia, no una categoría aparte.
REA actúa como un puente entre el agente y el programa objetivo. Cuando le pedís que inspeccione algo, REA se conecta al binario, al proceso en memoria o a la página web (vía una conexión de depuración local), extrae las instrucciones, el código decompilado o el script cargado, y le devuelve ese material al agente como texto que el modelo puede leer y razonar.
flowchart TD A [ "Desarrollador" ] -- > B [ "Agente de código" ] B -- > C [ "REA" ] C -- > D [ "Binario o script en ejecución" ] D -- > C C -- > B B -- > A Enter fullscreen mode Exit fullscreen mode El agente no recibe una respuesta mágica: recibe los mismos insumos crudos que usaría un reverse engineer humano. Lo que cambia es quién hace la lectura línea por línea.
sequenceDiagram participant D as Desarrollador participant A as Agente participant R as REA participant P as Programa objetivo D -> > A: por qu é 200 m á s 10 por ciento da 220 A -> > R: inspeccionar el binario R -> > P: leer instrucciones y llamadas P -- >> R: ensamblador y valores R -- >> A: c ó digo decompilado A -- >> D: explicaci ó n de la regla Enter fullscreen mode Exit fullscreen mode Esa separación de responsabilidades es la clave: REA se encarga de la mecánica de conectar con el proceso (atacharse a él, decompilar una función, leer una variable), y el agente se encarga de interpretar esos datos, formular una hipótesis y explicártela o convertirla en código nuevo.
El ejemplo que usa el propio proyecto es la calculadora de Windows: 200 + 10% da 220, y la pregunta es por qué. Un analista humano seguiría tres pasos: decodificar qué rama del programa corresponde al botón %, rastrear a qué funciones llama esa rama, y reconstruir la fórmula a partir de los valores que ve pasar. Con REA, el prompt es directo: Use REA to inspect Windows Calculator. Why does 200 + 10% give 220? El agente hace esos tres pasos por su cuenta y devuelve la regla en texto.
La regla que reconstruye, en pseudocódigo propio para ilustrarla, es así:
double percent_button ( double accumulator, double operand ) { double delta = accumulator * operand / 100. 0; return accumulator + delta; } // percent_button(200, 10) devuelve 220 // porque 200 * 10 / 100 = 20, y 200 + 20 = 220 Enter fullscreen mode Exit fullscreen mode El segundo ejemplo es más vistoso: el juego del dinosaurio que corre en la pantalla de error de Chrome cuando no hay conexión. El prompt pedido es Use REA to inspect this dinosaur game. Why does it get faster? REA lee el index.js que el navegador tiene cargado en ese momento y devuelve la condición real que mueve la velocidad: arranca en 6, suma 0.001 por cada actualización sin choque, y se detiene al llegar a 13.
let speed = 6; const ACCELERATION = 0.001; const MAX_SPEED = 13; function tick () { if ( speed [ Frida ]( https: //frida.re/), publicado en 2013, permite instrumentar una app en ejecución sin recompilarla. ## Errores comunes y buenas prácticas - ** Analizar sin autorización **, la regla básica no cambia porque haya un agente de por medio: si no es tuyo o no tenés permiso, no lo analices. - ** Confiar la hipótesis sin verificarla **, un modelo puede alucinar también leyendo ensamblador. La regla que devuelve REA es un punto de partida, no una conclusión probada. - ** Mezclar datos crudos con inferencia **, lo que REA entrega ( instrucciones, código decompilado ) es un hecho; lo que el agente concluye a partir de eso es una hipótesis que hay que poner a prueba contra el programa real. - ** Ignorar protecciones anti - depuración o empaquetado **, un binario ofuscado confunde tanto al analista humano como al agente; no esperes una respuesta limpia ahí. - ** No documentar lo encontrado **, sin un registro de la sesión, la próxima vez hay que reconstruir todo el análisis desde cero. ## Comparativa con alternativas OpciónCuándo usarlaVentajaLimitaciónGhidra o IDA manualAnálisis profundo de un binario complejo o malwareControl total sobre cada instrucciónCurva de aprendizaje de mesesFrida ( instrumentación dinámica ) Hookear funciones de una app en ejecución sin recompilarlaObserva comportamiento real en vivoHay que saber qué función buscar de antemanoBinary Ninja con scripts propiosAutomatizar análisis repetitivoAPI de scripting maduraIgual exige entender el binario primeroREA más un agente de códigoExplorar rápido un programa sin experiencia previa en RELenguaje natural, itera en minutosDepende del criterio del agente, no sustituye una auditoría formal La ventaja de REA es la velocidad para explorar: en minutos tenés una hipótesis sobre qué hace una función. La limitación es la misma que tiene cualquier análisis asistido por un modelo de lenguaje: la respuesta puede sonar segura y estar mal, así que no reemplaza una auditoría formal cuando lo que está en juego es crítico. ## Profundizando ( avanzado ) Por dentro, decodificar un binario pasa por etapas bien definidas: primero el desensamblador traduce bytes a instrucciones de la CPU ( el ejemplo de la calculadora, con `CMP` y `JZ` comparando el código del botón presionado ), después el decompilador levanta esas instrucciones a una representación intermedia y de ahí a pseudocódigo parecido a C, y por último alguien ( o algo ) reconstruye el grafo de control para entender qué rama lleva a qué resultado.
Enter fullscreen mode Exit fullscreen mode flowchart LR A["Decodificar ramas"] --> B["Rastrear llamadas"] B --> C["Recuperar la regla"]
Un modelo de lenguaje lee mejor el pseudocódigo tipo C que el ensamblador x64 crudo, porque se parece más a lo que vio durante su entrenamiento. Eso explica por qué REA entrega código decompilado en vez de solo direcciones y opcodes: no es una cuestión de estética, es lo que hace que el agente razone con menos errores. El análisis estático (leer el binario quieto) y el dinámico (observarlo mientras corre) responden preguntas distintas.
El caso de la calculadora es estático: se lee la lógica sin ejecutarla. El del dinosaurio es dinámico: se llama a la función real del juego en un navegador controlado para medir cómo cambia la velocidad. Un flujo de RE completo suele combinar ambos, y un agente conectado a REA puede pedir cualquiera de los dos según lo que necesite confirmar.
Las protecciones que más complican este trabajo (empaquetado, ofuscación de control de flujo, detección de depuradores, aleatorización de direcciones) no desaparecen porque haya un agente de por medio. Siguen siendo el límite real entre un análisis que toma minutos y uno que toma semanas, con o sin IA de por medio. > **💡 Tip:** si el agente te da una regla que suena demasiado simple, pedile que la pruebe contra un segundo caso con números distintos antes de aceptarla. Tu próximo paso: instalá REA con `npx rea-agents@latest setup` en un proyecto de prueba y pedile a tu agente que explique la función más simple de un binario que ya conozcas, para comparar su hipótesis contra el código real. 📖 Resumen en Telegram: [Ver resumen](https://telegra.ph/REA-el-CLI-que-da-ingeniería-inversa-a-Claude-Code-y-Cursor-10-10) ## Preguntas frecuentes ### ¿Qué hace exactamente REA por un agente de código?
Le da acceso a instrucciones de CPU, código decompilado y llamadas a funciones de un programa en ejecución, para que el agente razone sobre esos datos en lenguaje natural. ### ¿La ingeniería inversa con agentes es legal? Depende de qué analices y con qué permiso. Software propio, investigación de seguridad autorizada o las excepciones de interoperabilidad que reconocen varias jurisdicciones son casos habituales; analizar algo sin derecho a hacerlo no cambia de estatus legal porque haya un agente de por medio. ### ¿REA reemplaza a Ghidra o Frida?
No. Se apoya en ese tipo de herramientas (decompiladores, debuggers, instrumentación dinámica) para obtener los datos; el agente es quien interpreta y explica. ### ¿Qué agentes de código funcionan con REA? El proyecto está pensado para agentes como Claude Code o Cursor, instalado mediante `npx rea-agents@latest setup` directamente sobre el agente que ya tengas configurado. ### ¿Sirve REA para analizar malware?
Con las mismas precauciones de siempre: entorno aislado, sin ejecutar la muestra fuera de una sandbox, y nunca sobre una máquina conectada a datos reales. ### ¿Qué pasa si el agente se equivoca al explicar un binario? Lo mismo que si se equivoca escribiendo código: la hipótesis hay que verificarla contra el programa real antes de confiar en ella o de construir algo encima. ## Referencias - [REA](https://rea.tools/): sitio oficial del proyecto, con la guía de instalación y los ejemplos de la calculadora de Windows y el juego del dinosaurio.- [Ghidra](https://ghidra-sre.org/): framework de ingeniería inversa de código abierto publicado por la NSA, usado como referencia de decompilador clásico.- [Frida](https://frida.re/): toolkit de instrumentación dinámica para inspeccionar procesos en ejecución.- [Reverse engineering](https://en.wikipedia.org/wiki/Reverse_engineering): contexto histórico y técnico general del campo en Wikipedia. 📱 **¿Te gusta este contenido?** Únete a nuestro canal de Telegram [@programacion](https://t.me/programacion) donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.