ggfuchsi-oss/spectrida-reverse_engineering_stackAnalisi binaria parallela con IDA Pro, naming di funzioni basato su AI, grafo di conoscenza Neo4j e motore di emulazione/hooking/fuzzing phantomrt per reverse engineering automatizzato su formati PE, ELF e NSO.
Fantasma attraverso i binari.
Un assistente di reverse engineering locale e basato su IA: analisi parallela di IDA Pro, denominazione delle funzioni tramite IA, un terminale che non fa schifo, un grafo di conoscenza Neo4j di tutto ciò che ha mai scoperto, e un server MCP così Claude può cercare e concatenare attraverso quel grafo direttamente.
E ora — con phantomrt — non solo legge i muri. Li attraversa: emula, hooka e fuzza le funzioni che ha denominato, e scrive ciò che effettivamente accade di nuovo sul grafo.
✓ 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
---
## Cos'è
L'analisi automatica di IDA Pro è a thread singolo. Su una DLL il2cpp da 34 MB ci vogliono *minuti*. spectrIDA divide il binario in N frammenti, li esegue in parallelo tramite idalib, li unisce in un unico `.i64`, e poi lascia che un modello 8B messo a punto **dia un nome a ogni funzione** — tutto da un'unica interfaccia terminale con tema cyberpunk e la giusta dose di sarcasmo.
Questo è il Capitolo 1, e regge da solo: pura velocità, nessuna IA richiesta se non la si vuole.
Il Capitolo 2 trasforma l'output in qualcosa che sopravvive alla sessione — un grafo Neo4j in cui un client MCP (Claude, [pi](https://pi.dev), qualunque cosa parli MCP) può realmente vivere, invece di dover copiare e incollare l'output del decompilatore in una finestra di chat una funzione alla volta:```
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)
Capitolo 3 (phantomrt) aggiunge la metà che gli strumenti statici non hanno mai: esegue il codice.
Emula una funzione senza OS (funziona su binari che non puoi nemmeno lanciare, come un .nso di Switch), oppure aggancia il processo live, o lo fuzza — e appone il verdetto (crashes / needs live state / clean) sullo stesso nodo del grafo del nome.
Il resoconto completo, compreso ciò che è ancora nella lista delle cose da fare, si trova nel Capitolo 2 e nel Capitolo 3.
Non è Ghidra. Fa una cosa fastidiosa (analisi lenta + naming) velocemente, ed è davvero divertente da usare. 199 download parlano da soli.
Niente cloud. Niente telemetria. Funziona interamente sulla tua macchina.
| compito | tempo |
|---|---|
| DLL di Among Us — IDA single-thread | ~4 ore |
| DLL di Among Us — spectrIDA (16 worker) | 67 secondi |
| Binario da 153.649 funzioni — passaggio di naming completo | durante la notte |
| Panoramica del binario (cosa fa questa cosa?) | ~30 secondi |
Hardware su cui sono state misurate: AMD Ryzen 7 5800X3D (8C/16T), 32 GB RAM, RTX 4070 12 GB.
Hardware diverso sposta i numeri dell'analisi parallela (più core, più shard, più veloce); i numeri del naming sono per lo più vincolati alla GPU.
I dati di Among Us di 4 ore/67 secondi precedono il Capitolo 2 e non vengono verificati indipendentemente in ogni release — esegui di nuovo spectrida analyze tu stesso se vuoi un numero per la tua macchina e il tuo binario, i risultati variano con la densità degli shard e la dimensione del binario.
Numeri effettivamente riverificati durante lo sviluppo del Capitolo 2, stesso hardware:
| binario | funzioni | compito | tempo/risultato |
|---|---|---|---|
| test_small.dll (PE) | 189 | analisi parallela, 4 worker, CLI | 6.4s |
| test_small.dll (PE) | 164 | pipeline MCP completa (analyze + demangle + graph write) | 9.8s |
| main.nso — Mario Odyssey (NSO), 16 worker | 28.038 funzioni seed | fase di scansione parallela con shard | 54.5s |
| main.nso — Mario Odyssey (NSO), 16 worker | 74.790 funzioni totali | + fase di merge/analisi completa | 143.1s |
| main.nso — Mario Odyssey (NSO), 16 worker | 74.790 funzioni totali | tempo totale end-to-end | 197.6s |
| main.nso — Mario Odyssey (NSO) | 74.790 | risolto tramite solo demangling (ABI Itanium, gratuito, nessuna AI) | 67.300 (90.0%) |
Quella riga NSO è il vero equivalente della vecchia affermazione di Among Us "4 ore → 67 secondi", misurata fresca in questa release su un binario Switch da 74.790 funzioni, senza coinvolgere AI nel naming (solo demangling — populate=False).
La fase parallela (16 core, ~55s) esegue la scoperta iniziale con shard; la fase di merge (~143s) è single-threaded per progettazione — un database IDA, uno scrittore — quindi se guardi il Task Manager durante quella parte e vedi 15 core che dormono, non è un bug report, è fisica.
Ottenere un numero onesto qui è stata una piccola storia dell'orrore a sé stante. La prima versione del supporto NSO girava pulita, usciva con codice 0, e restituiva orgogliosamente 727 funzioni per un binario che ne ha circa 75.000 — non un crash, solo spettacolarmente, fiduciosamente sbagliato, che in qualche modo è peggio. Si scopre che IDA non ha un loader NSO nativo, quindi il file veniva caricato silenziosamente come x86 normale ("metapc") anche se Switch è ARM64 fin dal lancio della console. Ogni shard eseguiva uno scanner di prologo x86 su istruzioni puramente AArch64 e chiamava "funzione" qualsiasi cosa corrispondesse accidentalmente. Sistemare l'architettura non ha risolto nulla da solo, perché il binario era anche ancora compresso in LZ4 in memoria — quindi metà di ciò che veniva scansionato era, generosamente, rumore. E anche una volta decompresso correttamente e contrassegnato come AArch64, ogni shard cercava solo i target delle chiamate all'interno della propria piccola fetta del binario, perdendo ogni chiamata che attraversava il confine dello shard — che in un binario di queste dimensioni sono la maggior parte. Tre bug, un numero, e nessuno di loro ha avuto la decenza di lanciare un'eccezione. (Abbiamo anche provato a ridurre la fase di merge saltando l'analisi dello stack frame di IDA — abbiamo ottenuto un bellissimo speedup e un database in cui Hex-Rays si è gentilmente rifiutato di decompilare metà di esso. Questo è stato rapidamente annullato. Abbiamo invece tenuto il salto della firma FLIRT, molto più piccolo e sicuro, che vale un trascurabile ~3% e non ha rotto nulla, il che a questo punto sembrava un tratto della personalità da mantenere.)
Sulla precisione del naming: non è la verità di base di livello Ghidra, è un modello 8B che indovina dallo pseudocodice.
Helper/getter generici tendono a funzionare bene; la logica profondamente specifica del gioco è più un lancio di moneta. Rinomina qualsiasi cosa sbagli — ecco perché rename_function persiste direttamente nel grafo.