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: Alles reverse-engineeren
Ein MCP für das Reverse Engineering von Binärdateien, Anwendungen und Laufzeitverhalten.
Eine Funktion gefällt dir? Verstehe, wie sie funktioniert – bis hinunter auf die Binärebene.
Website · Anleitungen · Fallstudien
Schnellstart · So funktioniert REA · Was du analysieren kannst · Fallstudien · RL-Umgebungen erstellen · Häufige Fragen · Dokumentation
npx rea-agents setup
Important
Offizielle Quellen für REA: morluto/rea, rea.tools, rea-agents (npm). Folge den Installations- und Release-Links aus diesen offiziellen Quellen. Ein ähnlicher Repository-Name oder eine kopierte README belegt nicht, dass ein Download offiziell ist.
Du hast in einer App eine Funktion entdeckt, die du in dein eigenes Produkt übernehmen möchtest? Lass deinen Agenten sie mit REA untersuchen. Er kann die App ohne ihren Quellcode analysieren, die Funktionsweise erklären, Belege zeigen und eine passende Umsetzung für dein Projekt entwickeln.
REA verbindet deinen Agenten mit Werkzeugen zum Untersuchen nativer Binärdateien, von JavaScript- und Electron-Apps, .NET-Assemblies und Websites. Dieselben Werkzeuge kannst du auch im Terminal nutzen. Die Analyse läuft lokal; die Ergebnisse enthalten die Belege und Einschränkungen hinter jeder Schlussfolgerung.
Die Einrichtung registriert REA bei deinem Agenten und installiert passende Workflow-Anweisungen. Native Analysen nutzen eine vorhandene Installation von Hopper, Ghidra, IDA oder Kuna; nach Zustimmung kann die Einrichtung Hopper installieren. Statische JavaScript-Analysen benötigen keine native Analyse-Engine.
Besuche die REA-Website für Einrichtungshinweise, bebilderte Anleitungen und echte Fallstudien.
Schnellstart
Unter Linux benötigen Starts von Ghidra, JADX und Firmware-Werkzeugen sowie statische JavaScript/Electron-Analysen ein procps-kompatibles ps in REAs PATH, um die Prozesseigentümerschaft zu prüfen. Abhilfe beschreibt die Linux-Voraussetzung.
Deinen Agenten einrichten
Wenn Node.js und npm installiert sind, führe diesen Befehl aus:
npx rea-agents setup
Wähle deine Agenten aus, prüfe die geplanten Änderungen und bestätige sie. Die Einrichtung fügt den MCP-Server von REA und passende Workflow-Anweisungen hinzu und sichert vorhandene Konfigurationen. Starte deinen Agenten anschließend neu.
Die Einrichtung unterstützt Claude Code, Codex, Cursor, Gemini CLI, Grok Build und weitere Agenten. Informationen zur Provider-Konfiguration und manuellen MCP-Registrierung findest du unter Installation und Einrichtung.
MCP verwendet standardmäßig kompakte Eingabeschemas. Für vollständige Feldhinweise und Details zur verschachtelten Validierung setze REA_MCP_INPUT_SCHEMA_PROFILE=full in der MCP-Registrierung. Beide Profile behalten alle Tools und dieselbe kanonische Servervalidierung; siehe MCP-Vertragsleitfaden.
Deinen Agenten fragen
Untersuche, wie die Suche in der Notes-App funktioniert, zeige mir die Belege und entwickle eine ähnliche Funktion für mein Projekt.
Ersetze Notes durch deine Ziel-App und benenne die Funktion, die du verstehen möchtest.
Das Terminal verwenden
Untersuche ein entpacktes JavaScript-/Electron-App-Verzeichnis oder eine ASAR-Datei:
npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --json
Das Ergebnis enthält Module, Imports, Electron-Grenzen und die zugehörigen Belege. Ersetze den Pfad durch dein Ziel, beispielsweise "D:/apps/example" unter Windows.
Für die regelmäßige Nutzung kannst du den Befehl rea installieren:
npm install --global rea-agents
rea --help
Konfiguriere für native Analysen zuerst einen Provider. Native Befehle, Provider-Auswahl, Snapshots und Skriptnutzung beschreibt der CLI- und Evidence-Leitfaden.
REA aktualisieren
REA entwickelt sich schnell weiter; neue Versionen enthalten häufig Fehlerbehebungen. Halte deine Installation aktuell.
Für eine über npm install --global / bun add --global installierte CLI:
rea update
rea --update ist ein Alias für rea update mit denselben globalen Ausgabeoptionen. Update-Befehle behalten insgesamt höchstens 4 MiB stdout/stderr. Zu große Metadatenantworten werden nach Befehlsende abgelehnt; ausführliche Installationen behalten begrenzte Diagnosen. Fortschrittsausgabe berücksichtigt Terminal-Rückstau und wartet auf bereits übergebene Schreibvorgänge.
Globale Bun-Updates erfordern Bun 1.2.17 oder neuer. Aktualisiere ältere Bun-Versionen manuell, bevor du rea update ausführst.
Um die Agentenregistrierungen und den Skill zu aktualisieren, führe den Einrichtungsbefehl aus, den das Update ausgibt.
Wenn du npx verwendest, aktualisiere die Agenteneinrichtung mit:
npx rea-agents@latest setup
Prüfe die Änderungen und starte deinen Agenten neu. Für einzelne CLI-Aufrufe verwende npx rea-agents@latest, gefolgt vom gewünschten Befehl.
Mit Bun verwendest du bunx rea-agents@latest statt npx rea-agents@latest.
So funktioniert REA
Dein Agent ruft REA über MCP auf, um das Ziel zu untersuchen und relevanten Code zu verfolgen. REA liefert Ergebnisse mit ihren Belegen zurück. Der Agent nutzt sie für weitere Fragen, Erklärungen oder zum Schreiben und Testen einer Implementierung. CLI-Befehle verwenden dieselben Workflows.
Abbildung in voller Größe öffnen.
Was du analysieren kannst
REA benötigt Node.js 22.x (>=22.23.4), 24.x (>=24.22.1) oder 26+ (>=26.12.1) sowie npm. Zusätzliche Werkzeuge und unterstützte Hostsysteme hängen vom Ziel ab:
| Ziel | Was REA zurückgibt | Voraussetzungen und Anleitung |
|---|---|---|
| Native Binärdateien | Pseudocode, Assemblercode, Zeichenketten, Symbole, Aufrufe und Verweise | Hopper, Ghidra, IDA oder Kuna; native Analyse |
| Offline-ELF-Struktur | Sektionen, Segmente, ursprüngliche Symbole/Relokationen und mögliche Schutzmaßnahmen aus statischer Analyse | Vom Aufrufer bereitgestelltes pwntools unter Linux x64; Binärdiagnostik |
| 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 |
| EVM-Bytecode | Dispatch-Selektoren, Byte-Offsets, abgeleitete Argumente und Veränderbarkeit des Zustands | Lokale Eingabe mit Rohbytes oder Hexdarstellung unter Linux x64; Offline-EVM-Leitfaden |
| 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 |
| Aufgezeichnete Linux-Abstürze | Unverarbeitete Note-Einträge, Register/Signale aller aufgezeichneten Threads und optionale Zuordnungskandidaten | Vom Aufrufer bereitgestelltes pwntools unter Linux x64; optional GDB/pwndbg; aufgezeichnete Abstürze |
| Desktop-Installationen | Laufzeitkandidaten, Quelldateien, Komponenten und nächste Schritte | Begrenzte Verzeichnis- und Headerprüfung；Desktop-Anwendungen |
| JavaScript / Electron | Module, Imports, Source Maps, Routen, IPC und Beziehungen zu nativen Add-ons | Node.js und npm; Anwendungsanalyse; Linux: procps ps |
| Websites | Seitenstruktur, Skripte, Netzwerkbeobachtungen und angeforderte Screenshots | Ein Browser aus der Chrome-Familie; Browseranalyse |
| Gespeicherte Netzwerkaufzeichnungen | Anfragen, Antworten, zugängliche Nutzdaten und Quellpositionen | HAR / Fiddler Everywhere SAZ; mitmdump unter Linux für Aufzeichnungen im nativen mitmproxy-Format; Leitfaden zu Netzwerkaufzeichnungen |
| Paketerfassungen | Endpunkte, DNS, TLS SNI, Protokollverteilung und HTTP-Anfragen | Vom Aufrufer bereitgestellte tshark- und capinfos-Binaries; pcap-Leitfaden |
| .NET-Assemblies | Metadaten, CIL-Anweisungen, deklarierte native Abhängigkeiten und Build-Vergleiche | Statische Untersuchung; Leitfaden für verwalteten Code |
| 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 |
| Android-APKs | Manifest-Deklarationen, Klassen, dekompilierte Methoden und Verweise | JADX ohne grafische Oberfläche und ein vollständiges JDK unter Linux/macOS/Windows x64; Android-Leitfaden |
| Android-Geräte | Geräte, Pakete, Prozesse, Logs, Dumps, Bildschirmaufnahmen sowie APK- und Dateiübertragungen | Vom Aufrufer bereitgestelltes adb (Emulator oder Gerät); ADB-Leitfaden |
| JEB-Projekte | Engine-gestützte Projekteinheiten, Artefakt-Prüfsummen und Pseudokode von Typen/Methoden | Ein vom Aufrufer gestarteter JEB-Client mit MCP, ausgewählt über REA_JEB_MCP_URL; JEB-Leitfaden |
| Android-Ressourcen | Dekodiertes Manifest, String-Tabellen, Sprachen und Versionsfakten | Vom Aufrufer bereitgestellter Apktool-Starter; Ressourcen-Leitfaden |
| Flutter-Apps | Dart-Snapshot-Hash, Per-ABI-Bibliotheksprüfsummen und Engine-Build-Provenienz | Keine (statische APK-Analyse); Flutter-Leitfaden |
| Firmware | Bereiche, Extraktionsergebnisse und Übergaben an die native Analyse | Binwalk / Unblob unter Linux; Firmware-Leitfaden |
| Aufgezeichnete Pakete | Ausgewählte Felder, wiederholte Werte, Filter und Decode-as-Regeln | Linux: TShark 4.x + prlimit; Mitschnitt-Anleitung |
| Aufgezeichnete Logiksignale | Decoder-Anmerkungen, Sample-Bereiche und Diagnosen | Linux: sigrok-cli 0.7.2 + prlimit; Signalaufzeichnungen |
| Pakete und Ressourcen | Dateiinventare, Hashwerte, plists, Aufbau von Apple-Bundles und extrahierte Ressourcen | Artefakt- und JavaScript-Leitfaden, Apple-Anwendungen |
| Prozessverhalten | Terminalausgabe, Interaktionen, Beobachtungen zu Prozessende und Dateisystem sowie Laufvergleiche | Linux/macOS mit nativer PTY; Prozessaufzeichnung |
| Go-Binärdateien | Eingebettete Compilerversion, Module, Ersetzungen und Build-Einstellungen | Integrierte statische Prüfung ELF/PE/thin Mach-O; Keine Go-Installation nötig |
| SQLite-Datenbanken | Tabellen, Spalten, Indizes, Views, Trigger und ausgewählte Zeilen gewöhnlicher Tabellen | Lokaler Datenbank/WAL-Snapshot; Node.js 24.x >=24.15 oder 26+ mit nativen SQLite-Grenzen |
| GPU-Codeobjekte | CUDA/HIP-Ziele, ausgewählte Kernelparameter und Ressourcen, gespeicherter PTX-Text | Integrierte statische Prüfung ELF/PE/fatbin/CUBIN/PTX; GPU |
| Modelldateien | GGUF-/safetensors-Metadaten, Tensordeklarationen und abgeleitete Summen | Headerprüfung; optionaler Hash der gesamten Datei; GGUF / safetensors |
| IL2CPP-Metadaten | Unity global-metadata.dat: Assembly-Images, Typ-/Methodennamen und Indexbereiche | Statische Dekodierung der Versionen 24, 27, 29, 31, 39; kein Unity nötig |
| Godot PCK | Archivinventar und Extraktion, originale Header-/Verzeichnisdaten und ausgewählte Inhaltsidentitäten | Statische Formate 2, 3, 4; kein Godot nötig |
| WASM-Artefakte | Validierung, Sektionen, exakte Import-/Export-WAT-Formen und dekodiertes WAT | Vom Aufrufer bereitgestellt WABT 1.0.42; inspect_wasm_artifact |
| APK-Signaturen | v1/v2/v3/v3.1-Signer, Zertifikatfingerabdrücke, Schlüsselrotation und Digest-Selbstkonsistenz | Integrierte statische Prüfung; inspect_apk_signature |
Statische JavaScript- und .NET-Untersuchungen lesen die bereitgestellten Dateien, ohne die Anwendung auszuführen. Laufzeitaufzeichnungen führen das gewählte Ziel mit deinen Benutzerrechten aus oder interagieren damit; die jeweiligen Anleitungen beschreiben die Auswirkungen.
Für die Offline-Untersuchung nativer Binärdateien unterstützt REA auch GNU objdump und Rizin, die du selbst bereitstellst. Der Leitfaden zu Reverse-Engineering-Tools beschreibt die Einrichtung der Provider, CLI-Befehle und Einschränkungen der Evidence. REA installiert oder aktualisiert keinen der beiden Provider.
Bei großen Binärdateien kannst du die Startfrist mit REA_GHIDRA_STARTUP_TIMEOUT_MS oder REA_HOPPER_STARTUP_TIMEOUT_MS erhöhen.
Native Formate und unterstützte Hostsysteme unterscheiden sich je nach Provider. Siehe Hopper- und Ghidra-Einrichtung, den IDA-Leitfaden, Kuna und die experimentelle Ghidra-Unterstützung unter Windows. Ghidra unterstützt auch 16-Bit-DOS-Analyse. Die Provider-Auswahl beschreibt der CLI-Leitfaden. Prüfe die Verfügbarkeit in Releases für Funktionen, die seit der neuesten npm-Version hinzugekommen sind.
Fallstudien
DX-Ball: Eine Stereo-Panning-Berechnung rekonstruieren
Verfolge einen Sound-Aufruf zur Hilfsfunktion, die Positionen in Panning-Werte umrechnet, untersuche die Anweisungen und überführe unvollständigen Pseudocode in C. Die Rekonstruktion besteht 3.205 Tests mit dem ursprünglichen x86-Code und reproduziert alle 63 Bytes der kompilierten Funktion.
Fallstudie lesen · Rekonstruktionsrepository
Notion: Die Electron-Zwischenablagebrücke verfolgen
Finde die Zwischenablage-API des Renderers, verfolge sie über preload und IPC bis zum Hauptprozess und untersuche das Zwischenablageformat samt Formatierungsdaten.
TH04: Eine DOS-Geschossring-Berechnung wiederherstellen
Untersuche die 16-Bit-Anweisungen des ursprünglichen PC-98-Spiels, rekonstruiere die festen und zielgerichteten Winkelberechnungen und vergleiche das rekonstruierte C++ mit der Ausgabe des damaligen Compilers.
Fallstudie lesen · Rekonstruktionsrepository
RL-Umgebungen mit REA erstellen
Zeichne eine Webanwendungssitzung auf, verwandle ihre API in Werkzeuge und exportiere eine Umgebung für einen KI-Agenten. Starte sie mit AgentEnv und ergänze Aufgaben und Belohnungsprüfungen für RL-Training oder Bewertung.
Anleitung zum Erstellen einer Umgebung · Demo auf X ansehen
Wenn du mit REA etwas Interessantes untersucht hast, würden wir es gern sehen. Teile deine Fallstudie in einem Issue oder Pull Request und beschreibe das Ziel, deine Frage, wie REA geholfen hat und was du herausgefunden hast.
RL-Umgebungen erstellen
Erstelle eine lokale Umgebung, in der ein KI-Agent Aufgaben wie das Finden eines Issues oder das Anlegen eines Ordners üben kann, ohne die ursprüngliche App auszuführen. Nutze sie für Reinforcement Learning (RL) oder um zu testen, wie gut ein Agent Aufgaben erledigt.
REA wandelt aufgezeichnete API-Anfragen und Antworten in Werkzeuge um, die der Agent aufrufen kann. Die Umgebung nutzt die aufgezeichneten Daten und unterstützt Änderungen nur, wenn die Aufzeichnung deren Wirkung bestätigt.
Richte REA in deinem Agenten ein und ersetze die Beispiel-URL und die Ordneraufgaben durch deine eigenen:
Erstelle mit REA eine RL-Umgebung aus meiner Test-Web-App unter
http://127.0.0.1:3000.
Decke das Auflisten, Erstellen, Umbenennen und Löschen von Ordnern ab.
Du darfst Testordner anlegen und entfernen. Lass bestehende Daten unverändert.
Speichere sie in einem Ordner namens my-env, prüfe die verfügbaren Operationen und erkläre mir den Start.
Stattdessen die Befehlszeile verwenden
Nutze diese Befehle, wenn du bereits eine Datei mit aufgezeichneten Browseranfragen und Antworten der App hast. Zum Ausführen des Ergebnisses brauchst du außerdem AgentEnv und Docker.
rea environment-build ./session.har ./my-env --name my-env --json
agent-env run ./my-env
REA exportiert eine lauffähige Umgebung mit einem einfachen Test, der prüft, ob sie startet und antwortet. Nutze sie mit deinem RL-Framework, um Aufgabenziele und Belohnungsprüfungen festzulegen und das Training auszuführen.
Anleitung zum Erstellen einer Umgebung · Umgebungsreferenz · Demo auf X ansehen
Häufige Fragen
Welche Agenten können REA verwenden?
Jeder Agent, der lokale MCP-Server unterstützt. Die Einrichtung konfiguriert die unterstützten Agenten; andere Clients können die manuelle MCP-Registrierung nutzen.
Brauche ich Hopper, Ghidra, IDA oder Kuna?
Für tiefgehende native Analysen wird eines dieser Programme verwendet. Statische JavaScript- und .NET-Untersuchungen funktionieren ohne native Analyse-Engine. Die Einrichtung kann Hopper nach Zustimmung installieren; Ghidra, IDA und Kuna nutzen deine vorhandenen Installationen. Siehe Provider-Einrichtung.
Muss ich Hopper vorher starten?
REA startet Hopper, wenn eine Operation es benötigt. Unter macOS kann beim ersten Start ein Dialog erscheinen, in dem du den Demomodus auswählst oder deine Lizenz aktivierst. Siehe Hopper-Start und Fehlerbehebung.
Was bewirkt die Installation des Skills über skills.sh?
Der Skill stellt Untersuchungsanweisungen für deinen Agenten bereit. Verwende npx rea-agents setup, um den MCP-Server von REA zu registrieren und passende Anweisungen zu installieren. Starte deinen Agenten anschließend neu. Siehe Installation nur des Skills.
Welchen Code liefert REA zurück?
Native Analysen liefern Pseudocode und Assemblercode. JavaScript-/Electron-Analysen rekonstruieren Module und ihre Beziehungen. Dein Agent nutzt diese Ergebnisse zum Schreiben und Testen einer Implementierung; die Fallstudien zeigen konkrete Beispiele.
Lädt REA meine App hoch?
REA analysiert Ziele lokal. Dein Agent erhält die Werkzeugergebnisse; sein Modellanbieter hat eine eigene Datenrichtlinie.
Was soll ich tun, wenn ich einen Fehler finde?
Aktualisiere zuerst; eine neuere Version könnte den Fehler bereits behoben haben.
Für eine über npm installierte CLI:
rea update
Für die Agenteneinrichtung über npx:
npx rea-agents@latest setup
Wenn du einen Agenten verwendest, schließe die Aktualisierung der Einrichtung ab und starte ihn neu. Wiederhole dieselbe Aufgabe. Besteht das Problem weiterhin, öffne ein Issue mit deiner REA-Version, dem Zieltyp, den Reproduktionsschritten und der Fehlerausgabe.
Dokumentation
Beginne mit den praxisnahen Anleitungen auf der Website. Genaue Optionen, Voraussetzungen und Ergebniskontrakte findest du hier:
- Installation und Einrichtung: Agentenregistrierung, Provider-Konfiguration, Updates und Deinstallation.
- Bereitschaft und Fehlerbehebung: Diagnose eines bestimmten Agenten oder einer Analyse-Engine.
- CLI und Evidence: Befehle, Provider-Auswahl, Snapshots, Import/Export und Exit-Status.
- MCP-Kontrakte und Agenten-Prompts: Werkzeugergebnisse, Sitzungen und geführte Untersuchungen.
- Werkzeugkatalog: Beim Build erzeugtes Inventar von Werkzeugen, Providern und CLI-Befehlen.
- Roadmap: Geplante Arbeiten und Fortschrittsübersichten zu Fähigkeiten.
Melde Sicherheitslücken gemäß SECURITY.md.
Sternverlauf
🎉 400.000 GitHub-Sterne – vielen Dank!
Danke an alle, die REA nutzen, Fehler melden, Funktionswünsche äußern, Builds testen und Fehlerbehebungen beitragen.
Haftungsausschluss
Hinweise zur verantwortungsvollen Nutzung findest du in DISCLAIMER.md.
REA dient der rechtmäßigen Forschung, Bildung, Interoperabilität, Softwareerhaltung und Analyse von Software, die dir gehört oder die du mit entsprechender Genehmigung untersuchen darfst.
The project's position on illegal or unauthorized use covers all REA versions, distribution channels, and platforms; each copy retains its applicable licenses.
Mitwirken
Wir freuen uns über deine Hilfe bei REA! Öffne ein Issue, um einen Fehler zu melden oder eine Funktion vorzuschlagen, oder sende einen Pull Request, um Code oder Dokumentation zu verbessern.
Die Entwicklungsumgebung und Prüfungen beschreibt CONTRIBUTING.md, die Verifikationspfade der Testleitfaden und die Projektstruktur die Architekturübersicht.
Lizenz
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.