ggfuchsi-oss/spectrida-reverse_engineering_stackParallele IDA Pro Binäranalyse mit KI-gestützter Funktionsbenennung, Neo4j-Wissensgraph und Phantomrt-Emulations-/Hooking-/Fuzzing-Engine für automatisiertes Reverse Engineering über PE-, ELF- und NSO-Formate hinweg.
Geist durch Binaries.
Ein lokaler, KI-gestützter Reverse-Engineering-Assistent: parallele IDA-Pro-Analyse, KI-Funktionsbenennung, ein Terminal, das nicht nervt, ein Neo4j-Wissensgraph von allem, was er je herausgefunden hat, und ein MCP-Server, damit Claude direkt in diesem Graphen suchen und verketten kann.
Und jetzt — mit phantomrt — liest er nicht nur die Wände. Er geht durch sie hindurch: emuliert, hookt und fuzzt die von ihm benannten Funktionen und schreibt das, was tatsächlich passiert, zurück in den Graphen.
✓ 00 ✓ 01 ✓ 02 ✓ 03 ▸ 04 · 05 · 06 · 07 ✓ 08 ✓ 09 ✓ 10 ✓ 11 ✓ 12 ✓ 13 ▸ 14 · 15
14/16 shards │ 141,203 functions found ████████████████████████████░░░░ 89% ~4s remaining
---
## Was es ist
Die Autoanalyse von IDA Pro ist single-threaded. Bei einer 34 MB il2cpp DLL sind das *Minuten*. spectrIDA teilt die Binärdatei in N Shards auf, führt sie parallel via idalib aus, führt sie zu einer `.i64` zusammen und lässt dann ein feinabgestimmtes 8B-Modell **jede Funktion benennen** — alles aus einem Terminal-UI mit einem Cyberpunk-Theme und genau der richtigen Menge an Sarkasmus.
Das ist Kapitel 1, und es steht für sich allein: reine Geschwindigkeit, kein KI erforderlich, wenn Sie sie nicht wollen.
Kapitel 2 verwandelt die Ausgabe in etwas, das die Sitzung überdauert — einen Neo4j-Graphen, in dem ein MCP-Client (Claude, [pi](https://pi.dev), was auch immer MCP spricht) tatsächlich leben kann, anstatt dass Sie Decompiler-Ausgabe Funktion für Funktion in ein Chat-Fenster kopieren und einfügen:```
Binary ─▶ Parallel IDA Analysis ─▶ Demangle ─▶ AI Naming ─▶ Neo4j Graph ─▶ MCP Server ─▶ Claude
(N idalib shards) (free, real) (stripped (persists, (search/chain/
leftovers forever, rename, live)
only) across sessions)
Kapitel 3 (phantomrt) fügt die Hälfte hinzu, die statische Werkzeuge niemals haben: es führt den Code aus. Emuliert eine Funktion ohne Betriebssystem (funktioniert mit Binärdateien, die du nicht einmal starten kannst, wie einer Switch .nso), oder hakt sich in den Live-Prozess ein, oder fuzzt ihn – und prägt das Urteil (crashes / needs live state / clean) auf denselben Graphknoten wie den Namen.
Eine vollständige Übersicht, einschließlich dessen, was noch auf der To-do-Liste steht, findest du in Kapitel 2 und Kapitel 3.
Es ist nicht Ghidra. Es erledigt eine nervige Sache (langsame Analyse + Benennung) schnell, und es macht tatsächlich Spaß, es zu benutzen. 199 Downloads sprechen für sich.
Keine Cloud. Keine Telemetrie. Läuft vollständig auf deinem Rechner.
| Aufgabe | Zeit |
|---|---|
| Among Us DLL — Single-Threaded IDA | ~4 Stunden |
| Among Us DLL — spectrIDA (16 Arbeiter) | 67 Sekunden |
| 153.649-Funktionen-Binärdatei — vollständiger Benennungsdurchlauf | über Nacht |
| Binärübersicht (Was macht dieses Ding?) | ~30 Sekunden |
Hardware, auf der diese gemessen wurden: AMD Ryzen 7 5800X3D (8C/16T), 32 GB RAM, RTX 4070 12 GB.
Andere Hardware verschiebt die Parallel-Analyse-Zahlen (mehr Kerne, mehr Shards, schneller); die
Benennungszahlen sind größtenteils GPU-gebunden. Die 4-Stunden/67-Sekunden-Werte für Among Us stammen aus der Zeit vor Kapitel 2 und
werden nicht in jeder Version unabhängig überprüft – führe spectrida analyze selbst aus, wenn du
eine Zahl für deine eigene Maschine und Binärdatei haben möchtest; die Ergebnisse variieren je nach Shard-Dichte und Binärgröße.
Tatsächlich während der Entwicklung von Kapitel 2 auf derselben Hardware überprüfte Zahlen:
| Binärdatei | Funktionen | Aufgabe | Zeit / Ergebnis |
|---|---|---|---|
| test_small.dll (PE) | 189 | Parallele Analyse, 4 Arbeiter, CLI | 6,4s |
| test_small.dll (PE) | 164 | Vollständige MCP-Pipeline (Analyse + Demanglen + Graphschreiben) | 9,8s |
| main.nso — Mario Odyssey (NSO), 16 Arbeiter | 28.038 Seed-Funktionen | Parallele geschardete Scan-Phase | 54,5s |
| main.nso — Mario Odyssey (NSO), 16 Arbeiter | 74.790 Gesamtfunktionen | + Mergen/Vollanalyse-Phase | 143,1s |
| main.nso — Mario Odyssey (NSO), 16 Arbeiter | 74.790 Gesamtfunktionen | End-to-End-Wandzeit | 197,6s |
| main.nso — Mario Odyssey (NSO) | 74.790 | Über Demangling allein aufgelöst (Itanium ABI, kostenlos, kein KI) | 67.300 (90,0%) |
Diese NSO-Zeile ist das eigentliche Äquivalent zur alten Among-Us-Behauptung "4 Stunden → 67 Sekunden", die frisch
in dieser Version an einer 74.790-Funktionen-Switch-Binärdatei gemessen wurde, ohne KI-Benennung (nur Demangling —
populate=False). Die Parallelphase (16 Kerne, ~55s) führt die anfängliche geschardete Erkennung durch; die
Merge-Phase (~143s) ist von Natur aus Single-Threaded – eine IDA-Datenbank, ein Schreiber – wenn du also während dieses Teils
den Task Manager beobachtest und 15 Kerne schlafen siehst, ist das kein Fehlerbericht, sondern Physik.
Eine ehrliche Zahl hier zu bekommen, war eine eigene kleine Horrorgeschichte. Die erste Version des NSO-Supports lief sauber, beendete sich mit Exit 0, und meldete stolz 727 Funktionen für eine Binärdatei, die ungefähr 75.000 davon hat – kein Absturz, nur spektakulär, selbstbewusst falsch, was irgendwie schlimmer ist. Es stellt sich heraus, dass IDA keinen nativen NSO-Loader hat, also wurde die Datei stillschweigend als normales x86 ("metapc") geladen, obwohl die Switch seit dem Launch ARM64 ist. Jeder Shard führte einen x86-Prolog-Scanner gegen reine AArch64-Anweisungen aus und nannte, was immer er zufällig als "Funktion" erkannte, so. Die Korrektur der Architektur behob nichts von allein, denn die Binärdatei war auch noch LZ4-komprimiert im Speicher – also war die Hälfte von dem, was gescannt wurde, großzügig gesagt, Rauschen. Und selbst nachdem sie ordnungsgemäß dekomprimiert und als AArch64 markiert war, suchte jeder Shard nur nach Call-Targets innerhalb seines eigenen winzigen Ausschnitts der Binärdatei und übersah jeden Call, der eine Shard-Grenze überschritt – was in einer Binärdatei dieser Größe die meisten sind. Drei Fehler, eine Zahl, und keiner von ihnen hatte die Anstand, eine Ausnahme zu werfen. (Wir haben auch versucht, die Merge-Phase zu verkürzen, indem wir IDAs Stack-Frame-Analyse übersprungen haben – bekamen eine schöne Beschleunigung und eine Datenbank, in der Hex-Rays höflich ablehnte, die Hälfte davon zu dekompilieren. Das wurde schnell rückgängig gemacht. Behalten haben wir stattdessen das viel kleinere, viel sicherere Überspringen der FLIRT-Signaturen, das einen achselzuckenden ~3% bringt und nichts kaputt macht – was sich zu diesem Zeitpunkt wie eine Persönlichkeitseigenschaft anfühlte, die man behalten sollte.)
Zur Benennungsgenauigkeit: es ist keine Ghidra-Grundwahrheit, es ist ein 8B-Modell, das aus Pseudocode rät.
Allgemeine Helfer/Getter landen meist gut; tief spielspezifische Logik ist eher ein Münzwurf.
Benenne alles um, was es falsch macht – deshalb bleibt rename_function direkt im Graph bestehen.