Skip to content
KitploitKITPLOIT
ToolsBlog
Einreichen
ToolsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
spectrIDA-Reverse_Engineering_Stack — Parallele 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. | Kitploit
Tools/GitHubGitHub/ggfuchsi-oss/spectrida-reverse_engineering_stack
Statische AnalyseDynamische Analyse (Sandboxing)ExploitationReverse EngineeringDebuggerFuzzingMalware-AnalyseCTFBinäranalyse

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen
KI-gestütztes Reverse Engineering
Firmware-Analyse
GitHubggfuchsi-oss/spectrida-reverse_engineering_stack

spectrIDA-Reverse_Engineering_Stack

Parallele 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.

Repository anzeigen
499vor 1 MonatVon Kitploit geprüft

👻 spectrIDA

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.

``` spectrida analyze GameAssembly.dll --workers 16 ``` [Kein Eingabetext bereitgestellt.]``` ◈ spectrIDA ▸ GameAssembly.dll

✓ 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

root@kitploit:~
---

## 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.


Zahlen

AufgabeZeit
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:

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.


Funktionen

  • Parallele geschardete Analyse – teilt den Adressraum in Shards auf, führt N idalib-Instanzen aus, führt sie zu einer .i64 zusammen. Anzahl der Arbeiter über Flag, Konfiguration oder Umgebungsvariable konfigurierbar.
  • Plug-in-fähige Formatunterstützung – PE, NSO (Switch) und ELF (.so/Linux) sind eingebaut; das Hinzufügen eines neuen Formats erfolgt mit einer einzigen Datei, ohne Kernänderungen. spectrida formats listet auf, was registriert ist. Siehe Hinzufügen eines neuen Binärformats.
  • KI-Funktionsbenennung – das feinabgestimmte Qwen3-8B läuft lokal über Ollama, streamt Namen Token für Token. Drücke N. Sieh zu, wie es denkt. Der Name erscheint.
  • Batch-Benennung – B, um jede sub_*-Funktion in der Liste zu benennen. Geh weg. Komm zurück.
  • Binärübersicht – drücke O oder führe spectrida overview datei.i64 aus. Das Modell liest 120 beispielhafte Funktionsnamen und sagt dir, was die Binärdatei tut, welche Subsysteme sie hat, und alles Sicherheitsrelevante. Hat korrekt eine 153k-Funktionen-IL2CPP-Laufzeit in 30 Sekunden identifiziert.
  • Call-Chain-Explorer – C zeigt Aufrufer und Aufgerufene. Das Modell verwendet diese als Kontext beim Benennen – eine Funktion, die von aufgerufen wird, wird besser benannt als eine isolierte.

Installation```bash

pip install spectrida

root@kitploit:~
Anforderungen: **IDA Pro 9.x** mit idalib · **Python 3.10+** · **Ollama**```bash
# install Ollama (Windows)
winget install Ollama.Ollama

# pull the model (8.7 GB — go get coffee)
ollama pull hf.co/gdfhhjk/spectrida-re-gguf:latest

# first run — detects your IDA install and sets everything up
spectrida onboard

# or just try the demo right now
spectrida --demo

Befehle```bash

analyze a binary from scratch

spectrida analyze GameAssembly.dll spectrida analyze GameAssembly.dll --workers 8 # custom worker count

open an existing .i64 in the browser

spectrida open file.i64

ask the AI what this binary is

spectrida overview file.i64 spectrida overview file.i64 --addr 0x10001000 --addr 0x10353fd0 # include specific functions

export function names

spectrida export file.i64 -f idc # IDA script — apply names to any install spectrida export file.i64 -f json # full dump with addresses + sizes spectrida export file.i64 -f csv # spreadsheet spectrida export file.i64 -f symbols # addr name pairs spectrida export file.i64 --named-only # skip sub_* functions

check Ollama + model status

spectrida serve

re-run the setup wizard

spectrida onboard

root@kitploit:~
---

## TUI-Tasten

| Taste | Aktion |
|-------|--------|
| `N` | Ausgewählte Funktion benennen – KI streamt das Ergebnis live |
| `R` | Umbenennen – mit KI-Vorschlag vorausgefüllt |
| `D` | Dekompilierten Pseudocode umschalten (Hex-Rays) |
| `C` | Aufrufkette – Aufrufer und Aufgerufene |
| `B` | Alle `sub_*`-Funktionen in der aktuellen Liste stapelweise benennen |
| `O` | Übersicht – KI-Zusammenfassung der gesamten Binärdatei |
| `/` | Unscharfe Suche |
| `?` | Hilfe |
| `Q` | Beenden |

---

## Programmatische API

Kein TUI erforderlich – steuern Sie spectrIDA von Skripten, Claude Code, Notebooks, was auch immer:```python
import asyncio
from spectrida.api import open_i64

async def main():
    async with open_i64("GameAssembly.i64") as db:

        # list all 153k functions
        funcs = await db.list_functions()

        # name one function — returns name + reasoning + confidence
        result = await db.name_function(0x10001000)
        print(result["new_name"])     # init_atexit_handler
        print(result["reasoning"])    # allocates array of 3 fn ptrs, calls _atexit...

        # batch name everything (with live progress)
        async def on_progress(done, total, r):
            print(f"  {done}/{total}  {r['old_name']} -> {r['new_name']}")

        await db.batch_name(limit=500, rename=True, progress_cb=on_progress)

        # ask what the binary does
        overview = await db.overview()
        print(overview)

        # export to IDA script
        await db.export("names.idc", fmt="idc", named_only=True)

asyncio.run(main())

Das Modell

hf.co/gdfhhjk/spectrida-re-gguf — Qwen3-8B feinabgestimmt für Reverse Engineering.

Trainiert auf:

  • x86/x64 Assembly → Funktionsnamen-Paare mit Aufrufkettenkontext
  • Tool-Call-Traces von jtsylve/ida-mcp — headless IDA mit idalib
  • Erweiterte Kontext-Reasoning-Traces von einem Codebase-Kontextserver

Trainingsansatz: neuron-targeted SFT + GRPO. Nur die RE-relevanten Neuronen werden angepasst — das Basiswissen von Qwen3 bleibt intakt, du hast lediglich eine sehr spezifische Fähigkeit oben drauf hinzugefügt.

Läuft lokal über Ollama. GGUF — funktioniert auf CPU, GPU oder beidem.


Für wen ist das gedacht

Du reverse-engineerst etwas. Du hast eine Binary mit 150.000 Funktionen. Vielleicht 2.000 haben Namen aus Metadaten. Die anderen 148.000 sind sub_XXXXXXXX. Du willst den Netzwerkcode finden. Du kannst nicht danach greppen, weil noch nichts einen Namen hat.

Ein menschlicher RE kann etwa 50-100 Funktionen pro Stunde benennen, wenn er schnell ist. Bei dieser Rate entsprechen 150k Funktionen = 3 Jahren.

spectrIDA benennt sie über Nacht. Nicht perfekt — vielleicht 70% Genauigkeit bei generischen Funktionen, viel höher bei Mustern, die das Modell erkennt. Aber jetzt hast du statt 148k sub_-Funktionen network_send_packet, serialize_player_state, validate_checksum — und du weißt, wo du suchen musst.

Es ersetzt keinen erfahrenen Reverse Engineer. Es erledigt die langweiligen 80%, sodass du dich auf die interessanten 20% konzentrieren kannst. Es ist die Orientierungsschicht.

Reale Anwendungsfälle:

  • Game Modding — Finde das Physiksystem in einer Binary mit 150k Funktionen in Minuten, nicht Tagen
  • Sicherheitsforschung — Malware-Triage, die Architektur einer Binary schnell verstehen
  • CTF — Zeitdruck, sofort wissen müssen, worum es sich handelt
  • Jeder, der 20 Minuten lang auf sub_140001234 gestarrt hat und dachte es muss doch einen besseren Weg geben

Konfiguration

~/.spectrida/config.toml:```toml [ida] idalib = "C:/Program Files/IDA Professional 9.1" output_dir = "~/.spectrida/output"

[ollama] base_url = "http://localhost:11434" model = "spectrida-re" # any ollama model name works

[pipeline] workers = 16

root@kitploit:~
Überschreibungen von Umgebungsvariablen: `SPECTRIDA_IDALIB` · `SPECTRIDA_MODEL` · `SPECTRIDA_WORKERS` · `SPECTRIDA_OLLAMA_URL`

---

## Hinzufügen eines neuen Binärformats

Die Formatunterstützung ist ein Plugin-System, kein Haufen von if/elif-Zweigen — PE, NSO und ELF sind alle nur Dateien unter `spectrida/analysis/formats/`, die automatisch erkannt werden. Führen Sie `spectrida formats` aus, um zu sehen, was derzeit registriert ist.```bash
$ spectrida formats
ELF        spectrida.analysis.formats.elf.ELFHandler
NSO        spectrida.analysis.formats.nso.NSOHandler
PE         spectrida.analysis.formats.pe.PEHandler
generic    spectrida.analysis.formats.generic.GenericHandler

Die Aufgabe eines Format-Handlers ist eng gefasst — er prüft eine Datei, ob sie zu ihm gehört, und beschreibt dann dessen Code-Layout. Alles andere (Sharding-Strategie, GPU-Prolog-Scanning, Zusammenführen von Shards zu einer .i64) wird einmal, generisch, außerhalb des Format-Pakets behandelt. NSO ist das vollständige Beispiel: Seine LZ4-Dekomprimierung und die mem2base/add_segm-Logik von idaapi befanden sich bereits in nso_loader.py (die Korrektur der falsche-Architektur/noch-komprimiert/lokal-blind-entry-point Fehler aus der Geschichte von Kapitel 2) — formats/nso.py ist ein dünner Adapter, der dieses vorhandene, validierte Modul durch den FormatHandler-Vertrag offenlegt, keine Neuschreibung.

Um ein Format hinzuzufügen, lege eine neue Datei in spectrida/analysis/formats/ ab und sonst nichts. Keine Bearbeitungen an parallel_analyze.py, shard_worker.py oder der Registrierung — es wird durch Scannen des Verzeichnisses nach Modulen, die eine HANDLER-Instanz bereitstellen, automatisch erkannt.```python

spectrida/analysis/formats/myformat.py

from spectrida.analysis.formats.base import FormatHandler, PreparedImage, Section

class MyFormatHandler(FormatHandler): name = "MYFMT"

root@kitploit:~
@staticmethod
def sniff(header: bytes, path: str) -> bool:
    return header[:4] == b"MYF0"          # however you recognize the format

def prepare(self, path: str, workdir: str) -> PreparedImage:
    # Format idalib already loads natively (ELF, PE, Mach-O)? Just parse
    # the section/segment table — return the original path unchanged.
    return PreparedImage(
        binary_path=path,
        image_base=0,
        sections=[Section(name=".text", va=0x1000, raw_off=0x400,
                           raw_size=0x2000, vsize=0x2000, is_code=True)],
        arch=None,        # set "x86_64"/"arm64" only if IDA can't detect it itself
    )

# Only needed if idalib has NO native loader for this format (NSO is the
# example): do any manual idaapi/ida_segment setup here, called right
# after idapro.open_database() succeeds, before analysis starts.
# def post_open(self) -> None: ...

HANDLER = MyFormatHandler()

root@kitploit:~
Das ist der gesamte Vertrag:

| Methode | Erforderlich? | Beschreibung |
|---|---|---|
| `sniff(header, path)` | ja | Magic-Byte/Extension-Prüfung – gehört diese Datei zu diesem Handler? |
| `prepare(path, workdir)` | ja | Gibt ein `PreparedImage` zurück: die Datei, die idalib öffnen soll, plus deren Abschnittstabelle |
| `post_open()` | nein (Standard: keine Aktion) | Manuelle Segment-Einrichtung für Formate ohne nativen IDA-Loader (siehe `nso.py`) |
| `make_shard_binary(image, dst, va_start, va_end)` | nein (Standard funktioniert) | Nur überschreiben, wenn das Nullsetzen von Shard-externen Abschnittsbytes für Ihr Format falsch ist (siehe `nso.py` – niemals eine komprimierte Datei nullen) |
| `code_range(image)` | nein (Standard funktioniert) | Nur überschreiben, wenn "Min/Max der `is_code`-Abschnitte" nicht die richtige Antwort ist |
| `read_bytes(image, va_start, va_end)` | nein (Standard funktioniert) | Überschreiben, wenn `prepare()` die relevanten Bytes bereits im Speicher hält (NSO) statt auf der Festplatte |
| `global_entry_points(image, text_start, text_end)` | nein (Standard: None) | Nur überschreiben, wenn ein lokaler Scan pro Shard echte Entry Points verpassen würde – NSO benötigt dies, weil AArch64-Blattfunktionen nur über BL-Ziele, die an anderer Stelle in der Binärdatei sichtbar sind, auffindbar sind, nicht durch einen lokalen Prolog-Scan |

Schauen Sie sich `formats/pe.py` für den einfachsten möglichen Handler an (reine Header-Parsing, keine Überschreibungen) und
`formats/nso.py` für den vollständigen Fall (umfasst Dekompression + manuelle Segment-Einrichtung + jede Überschreibung).

Drittanbieterpakete können ebenfalls einen Handler registrieren, ohne den Quellcode von spectrIDA zu berühren, über die Einstiegspunktgruppe `spectrida.formats`:```toml
# in a separate package's pyproject.toml
[project.entry-points."spectrida.formats"]
myformat = "spectrida_myformat_plugin:HANDLER"

Test coverage for the format system lives in tests/test_formats.py — pure Python, no IDA/idalib required, so it runs in CI.


Kapitel 2 — der Geist lernt zurückzureden

Kapitel 1 war eine schnellere, lustigere IDA. Kapitel 2 ist spectrIDA als Teamkollege: ein persistenter, durchsuchbarer Wissensgraph jeder Funktion, die es jemals benannt hat, und ein MCP-Server, damit Claude (oder jeder MCP-Client — pi funktioniert auch) direkt darin suchen und Schlussfolgerungen ziehen kann, anstatt dass Sie die Ausgabe des Decompilers in ein Chat-Fenster kopieren und einfügen.```bash spectrida install mcp

root@kitploit:~
Das war's. Es registriert den Server automatisch bei Claude Code und pi (indem es `mcp` + `neo4j` nachzieht, falls eine bloße `pip install spectrida` sie ausgelassen hat), schreibt deren Konfiguration und sagt dir, welchen Neustart du ihm schuldest.

**Was Claude tatsächlich bekommt, sobald Neo4j läuft (`spectrida`-Konfigurationsabschnitt `[graph]` oder einfach auf eine lokale Instanz verweisen):**

- `search_functions` / `get_function` / `get_callees` / `get_callers` / `trace_chain` — schnelle,
  gecachte Graph-Lesevorgänge. `get_function` liefert Pseudocode **und** Disassemblierung (exakte
  Befehlsgrenzen und Operanden – die Schicht, die Pseudocode nicht liefern kann, und die in dem Moment wichtig ist,
  in dem du von „Was macht das?" zu „Wo genau würde ich das patchen?" übergehst) plus Inline-
  Caller/Callees, sodass Claude entscheiden kann, ob es tiefer ketten soll, indem es sieht, ob ein Callee immer noch
  `sub_*` direkt in der Antwort ist – kein zusätzlicher Roundtrip nur um herauszufinden, dass es nichts weiter zu sehen gibt.
- `get_full_pseudocode` / `rename_function` — Live-, autoritative Lese-/Schreibvorgänge direkt in die
  `.i64`, wenn das gecachte Snippet nicht ausreicht oder ein Name endlich gefunden ist.
- `analyze_binary` — gib ihm eine Binärdatei, die es noch nie gesehen hat (PE oder NSO, parallel-sharded auf beide Arten)
  und es führt die gesamte Pipeline aus – analysieren → demanglen (Itanium *und* MSVC) → KI-basiertes Benennen der
  tatsächlich gestrippten Überbleibsel → alles in den Graphen pushen – als einen Hintergrund-Job, den du abfragst,
  damit ein mehrminütiger Lauf das Gespräch nie blockiert.
- `doctor` / `start_all` — überprüfe oder starte llama-server + Neo4j, ohne den Chat zu verlassen.
  Falls llama-server selbst nirgendwo installiert ist, holt `start_all` es zuerst über winget (Windows) oder
  brew (macOS) – kein separater llama.cpp-Download/Setup nötig.

Es ist keine Magie – eine Funktion, die immer noch `sub_140001234` heißt, weil noch niemand hingesehen hat, ist
immer noch `sub_140001234`. Aber der Graph merkt sich alles, was das Modell *jemals* herausgefunden hat, für immer,
über Sitzungen hinweg, und Claude kann ihn durchlaufen wie einen Kollegen, der den Code schon gelesen hat, anstatt
eine Funktion nach der anderen anzustarren.

**Noch in Arbeit:**

- **Deep Context Naming** — Aufrufbäume N Ebenen tief verfolgen, die gesamte Kette dem Modell füttern.
  Eine Funktion, die 3 Hops von `encrypt_block` entfernt ist, sollte wissen, dass sie sich im Crypto-Pfad befindet.
- **Deobfuskation** — TigressVM-Mustererkennung und Handlerverfolgung
- **Echtes Patchen** — die Disassemblierung ist jetzt im Graphen, sodass ein Agent *kann* einen Patch auf Byte-Ebene
  planen; „Hier ist der genaue Befehl, der geändert werden muss" in „und hier ist der Schreibvorgang" umzuwandeln, kommt als Nächstes.

---

## Kapitel 3 — der Geist geht durch Wände

Kapitel 1 und 2 lesen die Binärdatei und merken sie sich. Aber eine Funktion zu lesen sagt dir, was sie *ist*,
nie, was sie *tut*, wenn du den Abzug betätigst. Kapitel 3 — [**phantomrt**](https://pypi.org/project/phantomrt/) —
betätigt den Abzug.```bash
pip install "spectrida[atlas]"

Es nimmt eine bereits benannte Funktion spectrIDA und führt eine von drei unheimlichen Dingen damit aus:

  • Emulieren (Unicorn, kein OS, beliebige Architektur) — die einzige Tür, die bei Binaries funktioniert, die du nicht starten kannst, wie eine Switch .nso oder ein Android .so.
  • Live-Instrumentierung (Frida) — an den laufenden Prozess anhängen und echte Argumente und Rückgabewerte beobachten, für Funktionen, bei denen Emulation nur mit den Schultern zucken kann, weil sie echten Zustand benötigen.
  • Fuzzen — mutierte Eingaben (Seeds, die du mitbringst, oder solche, die es aus der Binärdatei selbst herausschneidet), fange die Abstürze ein, behalte die reproduzierende Eingabe.

Dann stempelt es das Urteil auf denselben Neo4j-Knoten als dyn_*-Eigenschaften, sodass der Agent, der den Graphen durchläuft, den Namen und das Verhalten an einem Ort sieht. Sechs neue MCP-Tools — emulate_function, hunt_crashes, live_trace, dynamic_overview, risk_functions, learn_vm — alle unterstützen den einen Graphen. Die Denkecke ist das LLM, das gerade treibt; phantomrt stellt nur sicher, dass es echte Laufzeitfakten zum Nachdenken hat, anstatt Vibes.``` spectrIDA (names it) ─▶ phantomrt (runs it) ─▶ graph (dyn_status / crash / live args) ─▶ the agent reasons

root@kitploit:~
**Und, im Geiste der obigen NSO-Horror-Geschichte:** die erste echte Fehlersuche fand ehrlich gesagt
*nichts* — und der Grund war interessanter als ein Absturz gewesen wäre. Auf einen
wirklich alten, wirklich verwundbaren FreeType gerichtet, brachte blindes Fuzzing null. Coverage-geführtes Fuzzing meldete
dann triumphierend **64.000 Kanten** abgedeckt — was eine Lüge war, weil die Binärdatei PIE war und
ASLR leise die Adressen bei jedem Durchlauf neu randomisierte, sodass "neue Coverage" größtenteils das Mischen
des Decks durch den Lader war. ASLR deaktivieren, die ehrliche Zahl sinkt auf *echte* 727 Kanten, und sie bleibt dort
konstant — weil jeder Seed eine TrueType-Schriftart war, sodass der Fuzzer in einem Parser gefangen war
und sich nicht strukturell in den CFF/Type1/BDF-Code mutieren konnte, wo die Fehler tatsächlich leben. Der
Fix war kein klügerer Mutator, sondern bessere Seeds: der Agent holte echte OpenType/Type1/BDF-
Beispiele, die Coverage sprang von 727 auf 4.013 vor einer einzigen Fuzz-Iteration, und er erkundete richtig.
Immer noch kein Absturz im Budget — was der ehrliche Zustand eines 3-Minuten-Laufs auf einem Kern im Vergleich zu einem
Job ist, der normalerweise Stunden dauert. Die Maschinerie ist real. Sie hat ihre *eigene* gefälschte Zahl erwischt, anstatt
sie zu melden. Das ist der springende Punkt.

**Ehrlicher Geist-Haftungsausschluss:** phantomrt ist `0.1.0`. Alpha. Es ist eine solide dynamische Schicht, kein magisches
Fehler-Orakel — es fand gepflanzte Fehler in einem Spielzeugziel sofort, und bei echten Zielen sagt es dir
ehrlich, wenn es feststeckt (`needs_state`), wenn ein Absturz nur ein *Kandidat* ist (geh und überprüfe, ob der Pointer
tatsächlich eingabegesteuert ist), und wenn es einfach mehr Zeit und bessere Seeds braucht. Switch-
Binärdateien laufen nicht live — Frida braucht etwas, das es starten kann — also dort ist Emulation die einzige
Tür und es wird oft `needs_state` sagen. Das ist ehrlich, nicht kaputt.

Es ist absichtlich das schwere Extra (`torch`, `unicorn`, `frida`) — die Basis `pip install spectrida`
zieht nichts davon. Der Quellcode lebt in [`phantomrt/`](https://github.com/ggfuchsi-oss/spectrida-reverse_engineering_stack/blob/HEAD/phantomrt/); seine eigene geistgeschmackte README ist
[gleich dort](https://github.com/ggfuchsi-oss/spectrida-reverse_engineering_stack/blob/HEAD/phantomrt/README.md).

*Der statische Geist nennt deine Funktionen. Dieser bringt sie zum Geständnis.* 👻

---

## Lizenz

MIT. Mach damit, was du willst. Wenn es funktioniert, cool.
Wenn nicht, gib der GGUF-Quantisierung die Schuld.

Gebaut mit Bosheit, Kaffee und einer RTX 4070.
Das Modell hat 199 Downloads bei null Marketing. Jeder Download erhöht die Entwicklungsgeschwindigkeit um 0,01 %.
(Das stimmt nicht. Aber es ist nah dran.) 👻
Tool herunterladen
BinärdateiFunktionenAufgabeZeit / Ergebnis
test_small.dll (PE)189Parallele Analyse, 4 Arbeiter, CLI6,4s
test_small.dll (PE)164Vollständige MCP-Pipeline (Analyse + Demanglen + Graphschreiben)9,8s
main.nso — Mario Odyssey (NSO), 16 Arbeiter28.038 Seed-FunktionenParallele geschardete Scan-Phase54,5s
main.nso — Mario Odyssey (NSO), 16 Arbeiter74.790 Gesamtfunktionen+ Mergen/Vollanalyse-Phase143,1s
main.nso — Mario Odyssey (NSO), 16 Arbeiter74.790 GesamtfunktionenEnd-to-End-Wandzeit197,6s
main.nso — Mario Odyssey (NSO)74.790Über Demangling allein aufgelöst (Itanium ABI, kostenlos, kein KI)67.300 (90,0%)
Player$$TakeDamage
  • Decompiler-Ansicht – D schaltet Hex-Rays-Pseudocode um.
  • Export – alles nach JSON, CSV, IDA .idc-Skript oder einer Symboldatei ausgeben. Das .idc-Skript wendet alle KI-generierten Namen mit einem Klick in jeder IDA-Installation an.
  • Programmatische API – from spectrida.api import open_i64. Steuere alles aus Skripten, Notebooks oder Claude Code, ohne die TUI zu berühren.
  • MCP-Server – spectrida install mcp verbindet es direkt mit Claude Code und/oder pi, keine manuelle JSON-Bearbeitung erforderlich. Claude kann dann einen Neo4j-gestützten Funktionsgraphen (Name, Pseudocode, Disassembly, Aufrufer/Aufgerufene) durchsuchen/lesen/verketten und eine frische Analyse einer neuen Binärdatei selbst starten – analyze_binary führt die gesamte Pipeline (parallele Analyse → Demangling → KI-Benennung → Graph) mit einem Tool-Aufruf aus, als Hintergrundjob, den es abfragt. Funktioniert mit PE und NSO. Siehe Kapitel 2 unten.
  • Demo-Modus (spectrida --demo) – probiere das Ganze mit null Einrichtung aus. Kein IDA, kein Ollama.
  • Ein Ersteinrichtungsassistent – hilft dir, Ollama + das Modell zu installieren, erkennt deine IDA-Installation automatisch und fragt dann nie wieder.