Binärdiff (Binary Diff)
AKTION ERFORDERLICH (Nach dem Lesen sofort ausführen)
NOW: Lese../field-journal/precedent-reverse.md– bestätige, dass die Verwendung dieses Skills eine autorisierte Routineoperation istNOW: Stelle fest, ob die aktuelle Aufgabe in den Anwendungsbereich dieses Skills fälltNEXT: Lese../tool-index.md, überprüfe die Verfügbarkeit der Tools und die tatsächlichen PfadeNEXT: Bei fehlenden Tools rufebootstrapauf, rate keine PfadeACT: Beginne mit Schritt 1 des Arbeitsablaufs und führe ihn aus, bleibe nicht im Bestätigungsstatus hängen
Anwendungsbereich
Dieses Skill wird verwendet, wenn die Aufgabe zu folgenden Szenarien gehört:
- Kernel-/Treiber-PDB fehlt – Symbole für eine alte Version von
ntoskrnl.exesind vorhanden, die neue PDB wurde von Microsoft entfernt, und es müssen Adressen von nicht exportierten Funktionen in der neuen Version mit Hilfe der alten Symbole abgeleitet werden - Symbolmigration nach Programmupdate – Ein Programm wurde bereits rekonstruiert (reversed), aber es wurde aktualisiert. Um nicht alles erneut rekonstruieren zu müssen, werden die alten Ergebnisse in einer Massenmigration übertragen
- Schutzmechanismus-Updates – Die alte Version hat vollständige Reverse-Engineering-Ergebnisse, für die neue Version müssen schnell die neuen Offsets derselben Funktionen lokalisiert werden
- Jegliche Binärvergleiche, bei denen „alte Symbole + neue Version ohne Symbole" vorliegen
Aufgabenteilung mit anderen Skills
| Szenario | Verwendetes Tool |
|---|---|
| Rekonstruktion einer Binärdatei von Grund auf | ida-reverse/ oder radare2/ |
| Migrieren von alten Ergebnissen zur neuen Version | Dieses Skill |
| Vergleich zweier vollständig unterschiedlicher Binärdateien | BinDiff / Diaphora (traditionelle Tools) |
Kernvorteile
Vergleich mit traditionellen Ansätzen:
| Ansatz | Kosten für 200 Funktionen | Zeit | Genauigkeit |
|---|---|---|---|
| Manueller Vergleich mit zwei IDA-Fenstern | Kostenlos, aber zeitaufwändig | Stunden | Hoch |
| Automatischer Abgleich mit BinDiff | Kostenlos | Schnell | Mittel (versagt bei großen Strukturänderungen) |
| Vollständig an Agent (CC/Codex) übergeben | 50-100 Yuan | Langsam | Hoch |
| Dieses Skill (LLM-Massenvergleich) | ~1 Yuan | ~10 Sek./Funktion | Hoch |
Kernprinzip
Alte Funktion (mit Symbolen) Neue gleiche Funktion (ohne Symbole)
↓ ↓
Export von Disassembly + Pseudocode Export von Disassembly + Pseudocode
↓ ↓
└──────── LLM-strukturierter Vergleich ────────┘
↓
Ausgabe YAML (Symbol-Abbildungstabelle)
↓
Programmatisches Parsen → Massenanwendung auf neue IDB
Wichtige Punkte:
- Der Prompt ist eine feste Vorlage, die programmatisch gefüllt wird
- Das Eingabe- und Ausgabeformat ist festgelegt und wird programmatisch geparst
- Das LLM ist nur für den Schritt „Zwei Codeblöcke ansehen und die Beziehung finden" zuständig
- Zeit- und Token-Kosten sind extrem niedrig
Prompt-Vorlage
Standard-Vergleichs-Prompt
I have disassembly outputs and procedure code of the same function.
This is the function for reference:
**Disassembly for Reference**
```c
{disasm_for_reference}
Procedure code for Reference
{procedure_for_reference}
This is the function you need to reverse-engineering:
Disassembly to reverse-engineering
{disasm_code}
Procedure code to reverse-engineering
{procedure}
What you need to do is to collect all references to "{symbol_name_list}" in the function you need to reverse-engineering and output those references as YAML.
Example:
found_vcall: # This is for indirect call to virtual function or virtual function pointer fetching.
- insn_va: '0x180777700' # Always be the instruction with displacement offset
insn_disasm: call [rax+68h] # Always be the instruction with displacement offset
vfunc_offset: '0x68'
func_name: ILoopMode_OnLoopActivate
- insn_va: '0x180777778' # Always be the instruction with displacement offset
insn_disasm: mov rax, [rax+80h] # Always be the instruction with displacement offset
vfunc_offset: '0x80'
func_name: INetworkMessages_GetNetworkGroupCount
found_call: # This is for direct call to non-virtual regular function.
- insn_va: '0x180888800'
insn_disasm: call sub_180999900
func_name: CLoopMode_RegisterEventMapInternal
- insn_va: '0x180888880'
insn_disasm: call sub_180555500
func_name: CLoopMode_SetSystemState
found_funcptr: # This is for non-virtual regular function pointer.
- insn_va: '0x180666600' # Must load/reference the function pointer target address
insn_disasm: lea rdx, sub_15BC910 # Must load/reference the function pointer target address
funcptr_name: CLoopMode_OnClientPollNetworking
found_gv: # This is for reference to global variable.
- insn_va: '0x180444400'
insn_disasm: mov rcx, cs:qword_180666600 # Must load/reference the global variable
gv_name: g_pNetworkMessages
- insn_va: '0x180333300'
insn_disasm: lea rax, unk_180222200 # Must load/reference the global variable
gv_name: s_EventManager
found_struct_offset: # This is for reference to struct offset. NOTE THAT virtual function pointer should not be here! virtual function pointer should ALWAYS be in found_vcall !
- insn_va: '0x1801BA12A' # Always be the instruction with displacement offset
insn_disasm: mov rcx, [r14+58h] # Always be the instruction with displacement offset
offset: '0x58'
size: 8
struct_name: CResourceService
member_name: m_pEntitySystem
If nothing found, output an empty YAML. DO NOT output anything other than the desired YAML. DO NOT collect unrelated symbols.
### Variablenbeschreibung
| Variable | Quelle | Beschreibung |
| -------- | ------ | ------------ |
| `{disasm_for_reference}` | Export aus alter IDA | Disassembly mit Symbolen |
| `{procedure_for_reference}` | Export aus alter IDA | Pseudocode mit Symbolen |
| `{disasm_code}` | Export aus neuer IDA | Disassembly ohne Symbole |
| `{procedure}` | Export aus neuer IDA | Pseudocode ohne Symbole |
| `{symbol_name_list}` | Extraktion aus alter Version | Liste der Symbole, die in der neuen Version lokalisiert werden sollen |
## Arbeitsablauf
### Vollständiger Ablauf
```text
Schritt 1: Daten vorbereiten
- Alte Binärdatei in IDA laden (mit PDB/Symbolen)
- Neue Binärdatei in IDA laden (ohne Symbole)
- Gleiche Ankerfunktionen in beiden Versionen finden (exportierte Funktionen, String-Referenzen usw.)
Schritt 2: Massenexport
- Aus der alten Version exportieren: Disassembly + Pseudocode der Ankerfunktionen (mit Symbolnamen)
- Aus der neuen Version exportieren: Disassembly + Pseudocode der gleichen Ankerfunktionen (ohne Symbolnamen)
Schritt 3: LLM-Vergleich
- Die Daten mit der Prompt-Vorlage füllen
- LLM-API aufrufen (Empfehlung: DeepSeek für große Mengen und niedrige Kosten, sehr große Funktionen mit GPT)
- Das zurückgegebene YAML parsen
Schritt 4: Ergebnisse anwenden
- Die Symbolabbildungen aus dem YAML massenhaft auf die neue IDB anwenden
- Mit idapro_rename oder einem IDAPython-Skript massenhaft umbenennen
Schritt 5: Iterieren
- Die in der ersten Runde migrierten Funktionen werden zu neuen Ankern
- In diese Funktionen einsteigen und die internen Aufrufe weiter vergleichen
- Wiederholen, bis alle Zielfunktionen abgedeckt sind
Ankerauswahlstrategie
| Ankertyp | Zuverlässigkeit | Beschreibung |
|---|---|---|
| Exportierte Funktion | Höchste | Name ändert sich nicht, Adresse kann sich ändern |
| String-Referenz | Hoch | String-Inhalt ändert sich nicht, Referenzposition kann sich ändern |
| Konstante/Magische Zahl | Mittel | Merkmalswert ändert sich nicht |
| Code-Muster | Mittel | Funktion ist strukturell ähnlich, aber alle Adressen ändern sich |
Batch-Verarbeitungsempfehlungen
- Pro Vergleich nur 1 Funktion (um Kontextexplosion zu vermeiden)
- Mittlere Funktionen (<200 Zeilen) mit DeepSeek
- Sehr große Funktionen (>500 Zeilen) mit GPT-4o oder Claude
- Gleichzeitige Aufrufe zur Geschwindigkeitssteigerung (10-20 parallel)
- Zwischenergebnisse cachen, um wiederholte Aufrufe zu vermeiden
Ausgabeformat
5 Symboltypen im YAML-Ausgabeformat
| Typ | Bedeutung | Wichtige Felder |
|---|---|---|
found_vcall | Virtueller Funktionsaufruf (indirekter Call) | vfunc_offset, func_name |
found_call | Direkter Funktionsaufruf | insn_va, func_name |
found_funcptr | Funktionszeiger-Referenz | insn_va, funcptr_name |
found_gv | Referenz auf globale Variable | insn_va, gv_name |
found_struct_offset | Referenz auf Strukturoffset | offset, struct_name, member_name |
Anwendungsaktionen nach dem Parsen
found_call → idapro_rename(addr=call_target, name=func_name)
found_vcall → idapro_set_comments(addr=insn_va, comment="vcall: {func_name} @ +{offset}")
found_funcptr → idapro_rename(addr=funcptr_target, name=funcptr_name)
found_gv → idapro_rename(addr=gv_addr, name=gv_name)
found_struct_offset → idapro_set_comments(addr=insn_va, comment="{struct_name}.{member_name}")
Typische Anwendungsbeispiele
Szenario 1: ntoskrnl.exe ohne PDB
Vorhanden: ntoskrnl.exe 10.0.26100.2000 + vollständige PDB
Ziel: ntoskrnl.exe 10.0.26100.2605 (PDB entfernt)
Bedarf: Neue Adresse von PspSetCreateProcessNotifyRoutine lokalisieren
Schritte:
1. Beide Versionen in IDA laden
2. Exportierte Funktion PsSetCreateProcessNotifyRoutine finden (in beiden Versionen vorhanden)
3. In der alten Version ruft sie PspSetCreateProcessNotifyRoutine auf (mit Symbol)
4. In der neuen Version ruft sie sub_140822108 auf (ohne Symbol)
5. LLM erkennt sofort: sub_140822108 = PspSetCreateProcessNotifyRoutine
6. Massenanwendung
Szenario 2: Migration nach Anwendungsupdate
Vorhanden: Vollständige Reverse-Engineering-Ergebnisse von target.exe v1.0 (200+ Funktionen benannt)
Ziel: target.exe v1.1 (alle Symbole verloren)
Bedarf: Massenmigration von 200 Funktionsnamen
Schritte:
1. Aus der alten Version alle benannten Funktionen (Disassembly+Pseudocode) exportieren
2. In der neuen Version über exportierte Funktionen/Strings die entsprechenden Anker finden
3. Massenhaft LLM-Vergleiche aufrufen
4. YAML parsen, massenhaft umbenennen
5. Iterativ vertiefen
LLM-Auswahlempfehlungen
| Modell | Geeignet für | Kosten | Geschwindigkeit |
|---|---|---|---|
| DeepSeek V3 | Kleine bis mittlere Funktionen (<200 Zeilen), Batch-Verarbeitung | Sehr niedrig | Schnell |
| GPT-4o | Sehr große Funktionen, komplexer Kontrollfluss | Mittel | Schnell |
| Claude Sonnet | Mittlere bis große Funktionen, die Deduktion erfordern | Mittel | Schnell |
| Claude Opus | Extrem komplexe Funktionen, die tiefes Verständnis erfordern | Hoch | Langsam |
Empfohlene Strategie: Standardmäßig DeepSeek, bei Überschreitung des Kontextlimits oder ungenauen Ergebnissen automatisch upgraden.
Hinweise
- Gib nicht die gesamte Binärdatei an das LLM – vergleiche immer nur eine Funktion auf einmal
- Anker müssen zuverlässig sein – wenn der Anker selbst falsch ist, ist die gesamte weitere Arbeit umsonst
- Ergebnisse manuell stichprobenartig prüfen – das LLM ist nicht 100% genau, wichtige Symbole müssen verifiziert werden
- Zwischenergebnisse cachen – vermeide wiederholte Aufrufe, um Tokens zu sparen
- Kontextlimit beachten – sehr große Funktionen (>1000 Zeilen Disassembly) müssen aufgeteilt oder mit einem Modell mit großem Kontext analysiert werden
Bootstrap bei Bedarf (On-Demand Bootstrap)
Tool-Abhängigkeiten
| Tool | Zweck | Automatisch installierbar |
|---|---|---|
| IDA Pro | Disassembly/Pseudocode exportieren | ✗ (kommerzielle Software) |
| Python | Skriptausführung, API-Aufrufe | ✓ |
| PyYAML | YAML aus LLM-Antwort parsen | ✓ (pip install pyyaml) |
| LLM API | Vergleich durchführen | API-Key erforderlich |
Erläuterung
Dieses Skill ist nicht auf die Installation schwerer Tools angewiesen. Hauptabhängigkeiten:
- IDA Pro ist bereits vorhanden (wird mit dem Skill
ida-reverse/verwaltet) - Python + requests/httpx (für API-Aufrufe)
- Ein LLM-API-Endpunkt
Routing-Kontext
Upstream-Eingang: skills/SKILL.md (Hauptsteuerung), routing.md
Auslösebedingung: Vorhandensein alter Symbole/Reverse-Engineering-Ergebnisse, die auf eine neue Version migriert werden müssen
Downstream-Ausgang:
- Binärdatei muss zuerst geöffnet werden →
ida-reverse/ - Schnelle Erkundung zur Bestätigung von Versionsunterschieden →
radare2/
Gleichgeordnete Module: ida-reverse/ (Datencxport und Symbolanwendung erfolgen über IDA)
Selbstprüfung bei Aufgabenerledigung (MUSS vor der Behauptung der Fertigstellung bestanden werden)
- Habe ich jeden Schritt des Arbeitsablaufs ausgeführt (und nicht nur gelesen)?
- Habe ich die tatsächlichen Tool-Pfade basierend auf dem
tool-indexverwendet? - Habe ich reproduzierbare Beweise erzeugt (Befehle/Skripte/Screenshots/Berichte)?
- Habe ich die von RULES geforderten Checklistenpunkte abgeschlossen und zurückgemeldet?