windbg-decompile-ext — WinDbg x64-Erweiterung, die Live-Funktionen disassembliert und ein LLM nutzt, um verifizierten Pseudocode zu erzeugen. | Kitploit

dbgeng.lib

x64-only Annahmen
Live-Speicheranalyse über DbGEng
Zydis-gestützte strukturierte Disassemblierung zur stabilen Mnemonic/Operanden-Wiederherstellung
Symbolbereiche, Unwind und heuristische Funktionsbereichswiederherstellung
SSA-lite-Wiederherstellung für eingehende Registerargumente, Stack-Slot-Lokale, Merge-Kandidaten und normalisierte Bedingungszweige
Low-Level-IR-Wertfakten mit Def-Use-Hinweisen, kanonisierten Kopier-/Konstantausdrücken und Markern für tote Definitionen
Block-Level-Wertzustandsfakten für konvergierte Live-In/Live-Out erreichende Definitionen über Register und Stack-Lokale
Dominator-gestützte Kontrollflussbereichsfakten für natürliche Schleifen, If/Else-Kandidaten, Switch-Kandidaten, Schleifeninduktionsmetadaten und Switch-Bereichs-/Default-Metadaten
x64-ABI-Fakten für Shadow/Home-Slots, Stack-Pointer-Deltas, Prolog/Epilog-Erkennung, No-Return-Aufrufe, Tail Calls, Thunks, Import-Wrapper-Kandidaten und wiederhergestellte Register-/Stack-Aufrufargumente
SIMD/FP-bewusste Microsoft x64-Argumentwiederherstellung für xmm0 bis xmm3 mit Vector-Zero-Idiom-Guards zur Vermeidung falscher eingehender Argumente
Typwiederherstellungshinweise für zeigerähnliche Werte, Stack-Lokale, Feldversätze, skalierte Index-Arrays, enum-ähnliche Vergleiche, Bitflag-Tests und vtable-Kandidaten
Idiom- und Bibliotheksmuster-Fakten für Speicher-/String-Helfer, Sicherheits-Cookies, Stack-Probes, Allokatoren, aggregierte Initialisierer und RIP-relative Global-/Import-Ladevorgänge
Call-Target-Fakten für direkte Aufrufe, Register-/Speicher-indirekte Aufrufe, Virtual-Call/Vtable-Offset-Kandidaten, Rückgabetyp, Parametermodell, Seiteneffekte, Speichereffekte, Ownership-Hinweise und Konfidenz
OLLVM-ähnliche Obfuskationsfakten für Control-Flow-Flattening-Dispatcher, wiederhergestellte semantische Kanten, Opaque-Predicate-Totkanten und skalare Instruktionssubstitutions-Idiome
Deobfuskationsbereitschaftsfakten plus /deobf:on|off-Steuerung, ob wiederhergestellte Obfuskationsfakten die Pseudo-C-Umschreibung leiten dürfen
Evidenzgraph-Fakten, die High-Signal-Analyzer-, PDB- und beobachtete Verhaltensfakten mit der Instruktions-/Block-Verankerung verknüpfen
Refine-First-Prompting mit einem vom Analyzer generierten Pseudocode-Gerüst, graph-bewussten Zusammenfassungen für CFG-Bereiche, Bedingungen und wichtige Blöcke, ranghoher High-Signal-Faktauswahl und gestreutem Sampling für große Faktenmengen
WinDbg-DML-Links für Entry/Basic-Block/Evidence/Call-Target-Navigation, wenn der Ausgabe-Callback DML unterstützt
Getrennte Ergebnis-Modi für Kurz, Evidenzerklärung, Nur-Fakten, Debug-Prompt, JSON und Data-Model-Ausgabe
Benutzerkorrektur-Schalter für No-Return-, Typ-, Feld- und Umbenennungshinweise
Sitzungsbewusste Analyse-Richtlinienfakten für Live-, Dump-, Kernel- und TTD-ähnliche Sitzungen
Beobachtete Verhaltensfakten aus dem aktuellen Debugger-Kontext, einschließlich Registerargument-Samples, Speicher-Hotspots und TTD-Abfragevorschläge, falls verfügbar
RIP-relative String/Global/IAT-Klassifikation und Call-Target-Signaturhinweise für LLM-Prompting
Geladene-PDB-bewusste Prototyp-, Geltungsbereich-Parameter/Lokal-, Feld-, Enum- und Quellzeilen-Hinweise für LLM-Prompting
Direkte In-Prozess-LLM-Aufrufe aus der Erweiterung
OpenAI-kompatibler HTTP-Adapter oder deterministischer Mock-Fallback
Verifier-Durchlauf über LLM-Ausgabe

Der normale Befehlspfad führt eine lokale Analyse durch, erstellt Analyzer-Fakten, ruft optional den konfigurierten LLM-Endpunkt auf, überprüft die Antwort anhand der wiederhergestellten Beweise und gibt Pseudo-C plus Konfidenz, Warnungen und Unsicherheitshinweise aus:```text
!decomp ntdll!RtlAllocateHeap
!decomp kernel32!Sleep
!decomp game.exe!CheckIntegrity

- `brief` gibt Ziel, Konfidenz, Zusammenfassung und die erste Unsicherheit oder Verifier-Warnung aus.
- `explain` fügt Abschnitte für Beweise, Kontrollfluss, Typ-Hinweis, beobachtetes Verhalten und Call-Target hinzu.
- `json` gibt maschinenlesbares JSON der Anfrage und Antwort aus.
- `facts` gibt nur Analyzer-Fakten aus und deaktiviert den LLM-Pfad.
- `prompt` gibt den genauen System-Prompt, User-Prompt und Prompt-Fakten aus. Es deaktiviert den LLM-Aufruf.
- `data` gibt einen stabilen JSON-Snapshot aus, der für WinDbg JavaScript/NatVis-ähnliche Automatisierung gedacht ist.
- `analyzer` gibt den deterministischen Analyzer-only-Pseudocode-Pfad aus, ohne den LLM aufzurufen.
- `plan` führt eine lokale Analyse durch und gibt einen Preflight-Plan aus, ohne den LLM aufzurufen oder den Ergebniscache zu aktualisieren. Es enthält Ziel/Modul/Bereich-Anzahlen, PDB-Verfügbarkeit, Sitzungsrichtlinie, geschätztes Chunking, promptgrößenrelevante Zählungen und praktische Empfehlungen.

Verwenden Sie `/verbose`, wenn ein Befehl hängt oder Sie den vollständigen Fortschrittsstrom sehen möchten:```text
!decomp /verbose module!SlowFunction
!decomp /verbose /view:json module!SlowFunction

- `/view:window` führt den normalen `!decomp`-Ergebnispfad für das Ziel aus und öffnet das vollständig gerenderte Ergebnis in einem separaten Viewer.
- Der Viewer verwendet denselben Antwort-Renderer wie der Konsolenpfad und öffnet dann ein natives Win32-modelloses Werkzeugfenster, das dem Debugger-Fenster gehört, wenn eines gefunden werden kann.
- Die Debugger-Ausgabe meldet das Handle des nativen Viewer-Fensters. Wenn das Viewer-Fenster nicht erstellt werden kann, gibt der Befehl eine Warnung aus und fällt auf das normale Konsolenergebnis zurück.
- DML-only-Links werden als Textbeschriftungen mit ihren Befehlstrings im Viewer dargestellt. Wenn RichEdit verfügbar ist, verwendet das Fenster ein GitHub-ähnliches RTF-Layout mit Abschnittsüberschriften, Metadaten-Styling und Pseudo-Code-Hervorhebung; andernfalls fällt es auf Klartext zurück.
- Wenn die aktuelle Sitzung zwischengespeicherte Ergebnisse enthält, zeigt der Viewer eine Verlaufsliste auf der linken Seite, sodass Sie zwischen der aktuellen Ausgabe und früheren Dekompilierungsergebnissen wechseln können, ohne die Analyse erneut auszuführen.
- `/view:json`, `/view:facts`, `/view:prompt` und `/view:data` bleiben maschinenlesbare Konsolenausgaben und werden nicht an den Viewer umgeleitet.```text
!decomp /limit:deep module!LargeFunction
!decomp /limit:huge module!VeryLargeFunction
!decomp /limit:12000 module!VeryLargeFunction
!decomp /timeout:120000 module!SlowFunction

- `/deobf:on` ist die Voreinstellung. Der Analyzer gibt weiterhin rohe Fakten aus, aber die Wiederherstellung des Dispatchers mit hoher Konfidenz im OLLVM-Stil, undurchsichtige Dead-Edge-Nachweise, Substitutionsidiome und semantische CFG-Overlays können Prompt-Fakten, Merge-Policy, Verifier-Conflict-Policy und strukturierte Pseudo-C-Wiederherstellung leiten.
- `/deobf:off` behält `obfuscation`, `semantic_control_flow` und `deobfuscation_readiness`-Fakten sichtbar, deaktiviert aber sichere Rewrite-Aktionen, behält die Kontrollfluss-Strukturierung auf dem rohen CFG bei und weist Prompt-/Merge-/Verifier-Pfade an, die rohe verschleierte Form beizubehalten.
- Verwenden Sie `/deobf:off`, wenn Sie den Dispatcher, den Bogus-Branch oder die Substitutionsoberfläche direkt inspizieren möchten, anstatt die Erweiterung aufzufordern, eine entschleierte Struktur wiederherzustellen.
- `/deobfuscation:on|off` wird als längeres Alias akzeptiert.

Cache und Replay-Helfer:```text
!decomp /view:json module!FunctionName
!decomp /last:json
!decomp /view:explain module!FunctionName
!decomp /last:explain
!decomp /view:facts module!FunctionName
!decomp /last:facts
!decomp /view:data module!FunctionName
!decomp /last:data
!decomp /view:prompt module!FunctionName
!decomp /last:prompt
!decomp /history
!decomp /refresh module!FunctionName
!decomp /last:2:explain
!decomp /last:2:json

/last:json gibt die vorherige Anfrage/Antwort im JSON-Format aus, ohne die Analyse erneut durchzuführen.
/last:explain rendert das vorherige vollständige Ergebnis mit dem Erklärungsteil neu, ohne die Analyse oder das LLM erneut aufzurufen.
/last:facts gibt die Analyse-Fakten aus dem vorherigen Ergebnis aus, ohne die Analyse erneut durchzuführen.
/last:data gibt den vorherigen Datenmodell-Schnappschuss aus, ohne die Analyse erneut durchzuführen.
/last:prompt gibt den vorherigen Prompt-Dump aus, ohne die Analyse erneut durchzuführen.
/history listet den arbeitsspeicherinternen Ergebnis-Ringpuffer auf. Index 1 ist das neueste Ergebnis.
/refresh <target> umgeht die persistente Artefakt-Wiedergabe für dieses Ziel, führt eine frische lokale Analyse und LLM-Analyse durch und ersetzt das gespeicherte Artefakt nach einem erfolgreichen LLM-gestützten Ergebnis.
/last:N:explain, /last:N:json, /last:N:facts, /last:N:data und /last:N:prompt spielen ein älteres, zwischengespeichertes Ergebnis nach Historienindex ab, ohne die lokale Analyse oder das LLM erneut aufzurufen.
/last:*-Modi sind Terminal-Wiedergabebefehle. Wenn ein Ziel im selben Befehl vorhanden ist, wird das zwischengespeicherte Artefakt abgespielt und es wird keine lokale Analyse oder LLM-Anfrage für dieses Ziel gestartet.
Im Arbeitsspeicher zwischengespeicherte Artefakte existieren nur in der geladenen Erweiterungsinstanz. Der Ergebnisverlauf behält die neuesten 8 Ergebnisse und verschwindet, wenn WinDbg die Erweiterung entlädt oder der Prozess beendet wird.
Erfolgreiche LLM-gestützte Ergebnisse werden auch automatisch in einem artifact-Ordner neben der geladenen decomp.dll gespeichert. Der Bediener benötigt keinen separaten Speicherbefehl.
Persistente Artefakte umfassen request, response, data_model, debug_prompt und ein kernel_build-Objekt mit Win32/KD-Versionswerten, Build-String, optionalem NtBuildLab und einem Build-Fingerabdruck.
In einer späteren Sitzung prüft die Ausführung desselben !decomp <target>-Befehls automatisch den Pfad artifact\<kernel_build>\... nach der Zielauflösung und Wiederherstellung der Funktions-RVA. Wenn der gespeicherte kernel_build mit dem aktuellen Betriebssystem-Build übereinstimmt, spielt die Erweiterung das Artefakt ab, ohne Funktionsbytes zu lesen, lokale Analyseschritte durchzuführen oder das LLM aufzurufen.
Fehlende, nicht lesbare oder nicht übereinstimmende persistente Artefakte werden als Cache-Fehler behandelt. Der Befehl fällt auf eine frische Analyse zurück und überschreibt das Artefakt nur nach einem erfolgreichen LLM-gestützten Ergebnis.
DML-Aktionslinks in der normalen Ausgabe verwenden diese zwischengespeicherten /last:*-Ansichten, sodass ein Klick auf explain, json, facts, prompt oder data-model keinen neuen Decompilierungsdurchlauf startet.
Legacy-/last-json, /last-explain, /last-facts, /last-data-model, /last-dx und /last-prompt bleiben unterstützt.

- `/fix:noreturn:name` behandelt übereinstimmende Aufrufe als keine Rückkehr für Fallback-Disassemblierung, CFG-Wiederherstellung, ABI-Fakten und Verifier-Prüfungen.
- `/fix:type:expr=TYPE` fügt einen High-Confidence-Benutzertyphinweis hinzu.
- `/fix:field:expr=TYPE` fügt einen High-Confidence-Benutzerfeldhinweis hinzu.
- `/fix:rename:old=new` fügt einen Umbenennungshinweis hinzu und wendet die Umbenennung auf die finalen Pseudocode-Bezeichner an.
- `/fix:clear` löscht alle sitzungspersistenten Korrekturüberschreibungen.

Die Umgebungsvariable `DECOMP_NORETURN_OVERRIDES` wird weiterhin unterstützt. Die Befehlszeilenwerte von `/fix:noreturn:` werden für die aktuelle WinDbg-Sitzung über den ursprünglichen Umgebungsbefehl gelegt.

Korrekturschalter sind sitzungspersistent:

- `/fix:noreturn:`, `/fix:type:`, `/fix:field:` und `/fix:rename:` werden von der geladenen Erweiterung gemerkt und bei späteren `!decomp`-Ausführungen wiederverwendet.
- `/fix:clear` löscht alle sitzungspersistenten Korrekturen und stellt den no-return-Umgebungsoverride auf seinen ursprünglichen Wert zum Zeitpunkt des Ladens der Erweiterung zurück.
- Die veralteten `/noreturn:`, `/type:`, `/field:`, `/rename:` und `/clear-overrides` werden weiterhin unterstützt.

Fehlerhafte Korrekturwerte werden ignoriert und in `uncertainties` gemeldet, anstatt zwischengespeichert zu werden. Beispielsweise wird `/fix:type:rcx` ignoriert, da es kein `expr=TYPE`-Paar enthält.

Empfohlener Untersuchungsablauf:

1. Starten Sie mit `!decomp /view:facts target`, um zu bestätigen, dass der Funktionsbereich, Blöcke, Aufrufe, Importe, PDB-Daten und Sitzungsfakten sinnvoll aussehen.
2. Verwenden Sie `!decomp /view:plan target`, um die Aufteilung, Prompt-Größe, Zeitüberschreitungsrisiko und Symbolqualität abzuschätzen, bevor Sie eine LLM-Anfrage starten.
3. Verwenden Sie `!decomp /view:prompt target`, wenn Prompt-Größe, Sprache oder Evidenzauswahl falsch aussehen.
4. Führen Sie `!decomp target` für das vollständige verifizierte Pseudo-C-Ergebnis aus.
5. Verwenden Sie `!decomp /refresh target`, wenn ein vorhandenes persistentes Artefakt wiedergegeben wird, Sie aber eine frische Analyse benötigen.
6. Wenn das Ergebnis falsch aussieht, führen Sie `!decomp /view:explain target` aus und prüfen Sie Verifier-Warnungen, Evidenzabdeckung und vorgeschlagene Korrekturen.
7. Fügen Sie gezielte Korrekturen wie `/fix:noreturn:`, `/fix:type:`, `/fix:field:` oder `/fix:rename:` hinzu und führen Sie dasselbe Target erneut aus.
8. Verwenden Sie `/history` und indizierte `/last:N:*`-Wiedergaben, wenn Sie mehrere aktuelle Ergebnisse vergleichen.
9. Erfassen Sie `/view:json` oder `/last:json`, wenn Sie Fehler melden oder das Verhalten über Builds hinweg vergleichen.

## Analyzer Fact Surface

Aktuelle Analyzer-Fakten werden absichtlich über `/view:json`, `/view:facts`, `/view:prompt` und den normalen LLM-Modus mitgeführt. Hochwertige Felder, die zuerst überprüft werden sollten:

- `stack_pointer` zeichnet per-Instruction-Stack-Deltas, frame-relative Aliase und Vertrauenswürdigkeit auf.
- `call_arguments` zeichnet wiederhergestellte Register- und Stack-Argumente an Aufrufstellen auf, einschließlich nahegelegener Cross-Block-Stack-Speicherungen, wenn die Evidenz stark genug ist.
- `pdb.prototype_parameters` zeichnet strukturierte Prototyp-Parameternamen, Typen, Ordinalzahlen, ABI-Positionen und Quellvertrauenswürdigkeit auf.
- `control_flow` enthält Schleifeninduktionsvariablen, Startwerte, Schritte, Grenzen, Richtung, Switch-Tabellenadresse, Fall-Ziele, Standardziel, Bereichsgrenzen, Vorzeichen und Indexausdruck, falls wiederhergestellt.
- `callee_summaries` und Aufrufziel-Fakten enthalten direkte, indirekte und virtuelle Aufruf-/Vtable-Kandidaten sowie bekannte Win32/NT/Rtl-Speicher-, Allokations-, Freigabe- und Statussemantiken.
- `obfuscation` legt OLLVM-artige Flattening-Dispatcher-Kandidaten, Zustandsvariablen, wiederhergestellte semantische Kanten, opake Prädikate und Skalar-Substitutionsidiome offen.
- `semantic_control_flow` legt wiederhergestellte lebende/tote Kanten offen, die aus Obfuscation-Fakten abgeleitet wurden und auch dann zur Überprüfung verfügbar bleiben, wenn `/deobf:off` verwendet wird.
- `deobfuscation_readiness` legt `enabled`, sichere Rewrite-Aktionen, blockierte Annahmen, Prioritätsfaktpfade, Zählungen und Vertrauenswürdigkeit offen. Wenn deaktiviert, zeichnet es die Richtlinienentscheidung auf und blockiert den deobfuscierten Kontrollfluss-Rewrite.
- Die Prompt-Faktauswahl ordnet Signale mit hohem Wert zuerst ein, bewahrt dann die Verteilung mit Spread-Sampling, sodass große Funktionen nicht alle niederfrequenten Evidenzen verlieren.

## Empfohlenes dbgeng-Setup

Der schnellste Weg besteht darin, den Header und die Importbibliothek in das Projekt zu übernehmen.
Erwartetes Vendor-Layout:```text
third_party\dbgeng\inc\dbgeng.h
third_party\dbgeng\lib\dbgeng.lib

### Vendor-Kopie aus expliziten Dateipfaden vorbereiten```powershell
powershell -ExecutionPolicy Bypass -File .\scripts\Prepare-DbgengVendor.ps1 `
    -HeaderPath 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\sdk\inc\dbgeng.h' `
    -LibraryPath 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\dbgeng.lib'

## Build

Empfohlener Weg ist eine Visual Studio Developer PowerShell oder Developer-Eingabeaufforderung.

Die erstellte `decomp.dll` bettet nun eine Windows-Dateiversion aus `version.txt` ein.

### Normaler Build```powershell
powershell -ExecutionPolicy Bypass -File .\scripts\Build.ps1 -Reconfigure

`decomp_snapshot_tests` umfasst die Analyzer/Protocol/Verifier-Verträge für wiederhergestellte Stack-Argumente, SIMD/FP ABI-Eingaben, Nullidiom-Unterdrückung für Vektoren, Schleifeninduktionspräferenz, Switch-Metadaten, Metadaten virtueller Aufrufe, Obfuskationsfakten im OLLVM-Stil, die `/deobf:off`-Richtlinie, bekannte API-Zusammenfassungen, Prompt-Faktenauswahl und Verifier-Verankerungsprüfungen.
### Legacy dbgeng Build```powershell
powershell -ExecutionPolicy Bypass -File .\scripts\Build-Legacy.ps1 -Reconfigure

Dieses Skript erhöht die letzte Komponente in `version.txt` um `1`, erzwingt eine Neukonfiguration und erstellt dann die Release-DLL. Zum Beispiel wird aus `1.0.0.7` `1.0.0.8`.

### Common options

- `-Configuration Release|Debug`
- `-Clean`
- `-Reconfigure`
- `-ConfigureOnly`
- `-Verbose`
- `-ZydisSource Auto|Vendor|Fetch`
- `-ZydisVendorDir 'C:\path\to\zydis'`
- `-DebuggersRoot 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x64'`
- `-DbgengIncludeDir 'E:\works\windbg_llm_decomp_2\windbg_llm_decomp\third_party\dbgeng\inc'`
- `-DbgengLibrary 'E:\works\windbg_llm_decomp_2\windbg_llm_decomp\third_party\dbgeng\lib\dbgeng.lib'`

### Vendor-first-Beispiel```powershell
powershell -ExecutionPolicy Bypass -File .\scripts\Build.ps1 `
    -Configuration Release `
    -ZydisSource Vendor `
    -Reconfigure `
    -Verbose

Das Build-Skript versucht automatisch, Folgendes zu finden:

- `cmake.exe` aus PATH, eigenständigem CMake oder dem in Visual Studio gebündelten CMake
- `third_party\dbgeng` unter dem Projektstammverzeichnis
- `DEBUGGERS_ROOT` aus Umgebungsvariablen oder üblichen Windows Kits-Speicherorten

Die Zydis-Quellauswahl funktioniert wie folgt:

- `Auto`: bevorzugt `third_party\zydis`, andernfalls wird `Zydis` während der Konfiguration abgerufen
- `Vendor`: erfordert einen nutzbaren `third_party\zydis`-Baum oder den mit `-ZydisVendorDir` übergebenen Pfad
- `Fetch`: ignoriert den Vendor-Baum und lässt CMake immer `Zydis` herunterladen

`DEBUGGERS_ROOT` kann auf ein Debugger-Rootverzeichnis verweisen, das eines dieser Layouts verwendet:

- `sdk\inc\dbgeng.h` und `sdk\lib\dbgeng.lib`
- `sdk\inc\dbgeng.h` und `sdk\lib\amd64\dbgeng.lib`
- `sdk\inc\dbgeng.h` und `sdk\lib\x64\dbgeng.lib`
- `sdk\inc\dbgeng.h` und `dbgeng.lib`
- `inc\dbgeng.h` und `lib\dbgeng.lib`
- `inc\dbgeng.h` und `lib\amd64\dbgeng.lib`
- `inc\dbgeng.h` und `lib\x64\dbgeng.lib`
- `dbgeng.h` und `dbgeng.lib`

Wenn Ihre Installation keinem dieser Layouts entspricht, übergeben Sie die CMake-Pfade direkt:```powershell
cmake -S . -B build-manual -G "Visual Studio 17 2022" -A x64 `
    -DDBGENG_INCLUDE_DIR='E:\works\windbg_llm_decomp_2\windbg_llm_decomp\third_party\dbgeng\inc' `
    -DDBGENG_LIBRARY='E:\works\windbg_llm_decomp_2\windbg_llm_decomp\third_party\dbgeng\lib\dbgeng.lib'
cmake --build build-manual --config Release

ChatGPT-Abonnementbeispiel:```json
{
  "provider": "chatgpt",
  "model": "gpt-5.5",
  "chatgpt_auth_file": "%USERPROFILE%\\.codex\\auth.json",
  "timeout_ms": 120000,
  "max_completion_tokens": 12000,
  "force_chunked": false,
  "chunk_trigger_instructions": 900,
  "chunk_trigger_blocks": 36,
  "chunk_block_limit": 24,
  "chunk_count_limit": 16,
  "chunk_completion_tokens": 6000,
  "merge_completion_tokens": 12000,
  "reasoning_effort": "medium"
}

Dunkles Syntax-Highlighting-Voreinstellung:```json
{
  "syntax_highlighting": {
    "keyword_color": "warnfg",
    "type_color": "emphfg",
    "function_name_color": "srcid",
    "identifier_color": "wfg",
    "number_color": "changed",
    "string_color": "verbfg",
    "char_color": "srcchar",
    "comment_color": "subfg",
    "preprocessor_color": "normfg",
    "operator_color": "srcannot",
    "punctuation_color": "srcpair"
  }
}

Beispiel für `/view:json`-Antwortdetails:

- Die JSON-Antwort enthält `pseudo_c` und `pseudo_c_tokens`.
- `pseudo_c_tokens` ist ein deterministischer Token-Stream, der sich für externes Syntax-Highlighting eignet.
- Die serialisierte Anfrage enthält `preferred_natural_language_tag` und `preferred_natural_language_name`, die die aufgelöste Anzeigesprache nach Anwendung von `display_language.mode` widerspiegeln.
- Analysatorfakten enthalten jetzt P0-Qualitätsfelder: `ir_values`, `block_value_states`, `control_flow` und `abi`.
- `ir_values` legt SSA-ähnliche Wert-IDs, Definitionsstellen, Ziele, kanonische Ausdrücke, Nutzungsverknüpfungen, Konstanten/Kopier-Flags und Hinweise auf tote Definitionen offen.
- `block_value_states` legt pro Basisblock lebendige Eingangs-/Ausgangs-Reaching-Definitionen, kanonische Werte, Speicherklasse, Konvergenzzustand und Konfidenz offen.
- `stack_pointer` legt pro Anweisung Stack-Deltas, frame-relative Aliase, rohe Basis/Offsets und Konfidenz offen.
- `control_flow` legt strukturierte Bereichskandidaten wie `natural_loop`, `if_else_candidate` und `switch_candidate` mit Blocknachweisen, Schleifeninduktionsmetadaten, Switch-Tabellen/Default/Bereichsmetadaten, Vorzeichen, Indexausdrücken und Konfidenz offen.
- `abi` legt Microsoft-x64-Shadow-Space-Annahmen, Home-Slot-Nachweise, Frame/Prolog/Epilog-Erkennung, No-Return-Call-Nachweise, Tail-Call-Kandidaten, Thunk-Kandidaten, Import-Wrapper-Kandidaten und wiederhergestellte Aufrufargumente aus Registern und Stack-Speichern offen.
- Analysatorfakten enthalten jetzt auch P1-semantische Felder: `type_hints`, `idioms` und `callee_summaries`.
- `type_hints` legt Zeiger-, lokal-, Feld-Offset-, arrayartige, enumartige, bitflagartige und Vtable-Kandidaten-Nachweise mit Quelle und Konfidenz offen. Wenn PDB-Daten verfügbar sind, werden auch bereichsbezogene Parameter/Lokale, Feldhinweise und Enum-Konstanten in diesen vereinheitlichten Typ-Hint-Stream aufgenommen.
- `idioms` legt Ersetzungen auf höherer Ebene für erkannte Hilfsaufrufe und Compilermuster offen, wie Speicherkopieren/Füllen, Zeichenfolgenkopieren, Security-Cookie-Prüfungen, Stack-Probes, Allokations/Free-Helfer, Aggregatinitialisierer und RIP-relativierte globale/Import-Ladevorgänge.
- `callee_summaries` legt direkte und indirekte Aufgerufene-Rückgabetyp-, Parameter-Modell-, Seitenwirkungs-, Speicherwirkungs-, Eigentums-, Quellen- und Konfidenzhinweise offen; symbol-/typanreicherte Aufrufziele ersetzen die anfänglichen heuristischen Zusammenfassungen, wenn WinDbg sie auflösen kann, und virtuelle Aufrufkandidaten enthalten Zielausdrücke sowie Vtable-Offsets, wenn diese wiederhergestellt wurden.
- Bekannte Win32/NT/Rtl-API-Zusammenfassungen beschreiben Speicherkopieren/Füllen/Nullen, Allokation, Freigabe, Status- und Fehlerverhalten, wenn Symbolnamen verfügbar sind.
- Prompt-Fakten enthalten `analyzer_skeleton` und `graph_summary`, sodass das Modell einen evidenzgestützten Entwurf verfeinert, anstatt von einer leeren Seite zu beginnen.
- `graph_summary` liefert Eintrittsblock, Kontrollflussregionen, normalisierte Bedingungen und repräsentative hochsignalisierende Blöcke mit einer expliziten Abschneideregel. Die Prompt-Faktenauswahl ordnet jetzt hochsignalisierende Einträge und verwendet Spread-Sampling, um große Faktenmengen repräsentativ zu halten.
- `evidence_graph` legt hochsignalisierende Faktenknoten und Herkunftskanten offen, sodass IR-Werte, Blockwertzustände, Speicherzugriffe, Aufrufziele, Typ-Hinweise, PDB-Hinweise und beobachtetes Verhalten auf Anweisungs- und Blocknachweise zurückverfolgt werden können.
- `obfuscation`, `semantic_control_flow` und `deobfuscation_readiness` legen OLLVM-artige Wiederherstellungsfakten offen und ob die Deobfuskations-Umschreibungsanleitung für den aktuellen Befehl aktiviert ist.
- Die Verifiziererantwort enthält legacy `warnings` sowie strukturierte `issues`-Einträge. Jeder Issue trägt `severity`, `code`, `message` und optional `evidence`, sodass Tools Fehler wie `branch.true_target_not_successor` getrennt von risikofirmeren Warnungen filtern können.
- Verifiziererprüfungen vergleichen jetzt normalisierte Branch-True/False-Ziele mit CFG-Nachfolgern, vergleichen die Pseudocode-Branchdichte mit wiederhergestellten bedingten Verzweigungen, gleichen direkte Aufgerufene-Zusammenfassungen mit Pseudocode-Aufrufeffekten ab, validieren die Verankerung von Evidence-Graph-Knoten/Kanten und überprüfen Blockwertzustandsreferenzen auf wiederhergestellte Blöcke und IR-Werte.
- Normale und Explain-Ausgaben können einen prägnanten Abschnitt `suggested fixes` enthalten. Dabei handelt es sich um konservative `/fix:*`-Befehle, die aus Verifiziererproblemen, PDB-gestützten Umbenennungsmöglichkeiten oder wiederholten beobachteten Speicher-Hotspots abgeleitet werden. DML-bewusste Ausgabe rendert sofort anwendbare Vorschläge als anklickbare Wiederholungslink für dasselbe Ziel; Platzhalter-Feldtypvorschläge bleiben Klartext, bis `TYPE` ersetzt wird.
- Im LLM-Modus speist die Erweiterung Verifiziererprobleme automatisch in einen erneuten Prompt ein. Der erneute Versuch wird beibehalten, wenn er die Verifiziererqualität bewahrt oder verbessert; andernfalls wird die ursprüngliche Antwort mit einer hinzugefügten Unsicherheitsnotiz beibehalten.
- `session_policy` und `observed_behavior` legen WinDbg-spezifischen Kontext offen, wie Live/Dump/Kernel/TTD-ähnliche Richtlinie, Registerargument-Stichproben des aktuellen Frames, Speicher-Hotspots und vorgeschlagene Trace-Abfragen.
- Die serialisierte Anfrage enthält jetzt auch ein `pdb`-Objekt, wenn Symbol-/Typdaten verfügbar sind.
- `pdb.availability` meldet die Anreicherungsstufe wie `none`, `symbols`, `typed` oder `scoped`.
- `pdb.params`, `pdb.locals`, `pdb.field_hints`, `pdb.enum_hints` und `pdb.source_locations` sind als maschinenlesbare semantische Hinweise für externe Werkzeuge oder Offline-Analyse gedacht.

Optionale Umgebungsüberschreibungen:

- `DECOMP_LLM_PROVIDER`
- `DECOMP_LLM_ENDPOINT`
- `DECOMP_LLM_MODEL`
- `DECOMP_LLM_API_KEY`
- `OPENAI_API_KEY`
- `DECOMP_LLM_CHATGPT_ACCESS_TOKEN`
- `DECOMP_LLM_CODEX_ACCESS_TOKEN`
- `KERNFORGE_CODEX_ACCESS_TOKEN`
- `DECOMP_LLM_CHATGPT_AUTH_FILE`
- `DECOMP_LLM_CODEX_AUTH_FILE`
- `KERNFORGE_CODEX_AUTH_FILE`
- `DECOMP_LLM_REASONING_EFFORT`
- `DECOMP_LLM_TIMEOUT_MS`
- `DECOMP_LLM_MAX_COMPLETION_TOKENS`
- `DECOMP_LLM_FORCE_CHUNKED`
- `DECOMP_LLM_CHUNK_TRIGGER_INSTRUCTIONS`
- `DECOMP_LLM_CHUNK_TRIGGER_BLOCKS`
- `DECOMP_LLM_CHUNK_BLOCK_LIMIT`
- `DECOMP_LLM_CHUNK_COUNT_LIMIT`
- `DECOMP_LLM_CHUNK_COMPLETION_TOKENS`
- `DECOMP_LLM_MERGE_COMPLETION_TOKENS`
- `DECOMP_NORETURN_OVERRIDES`
  Komma- oder Semikolon-getrennte Funktionsnamenfragmente, die während der Fallback-Disassemblierung, CFG-Nachfolger-Wiederherstellung, ABI-Fakten und Verifiziererprüfungen als No-Return-Ziele behandelt werden. Beispiel: `DECOMP_NORETURN_OVERRIDES=MyAbort;PanicAndExit`.

Hinweis zur Qualitätspriorität:

- Die Erweiterung unterstützt jetzt eine mehrstufige Analyse in Blöcken für große Funktionen.
- Der Analysator sendet IR-Wertfakten, Blockwertzustände, Kontrollflussregionen, Evidence-Graph-Fakten und x64-ABI/No-Return-Nachweise vor der Verfeinerung an das LLM, sodass `/view:analyzer`, `/view:json` und der normale LLM-Modus alle dieselbe P0-Evidenzbasis teilen.
- Der Verifizierer gleicht Schleifen-, Switch-, No-Return-, Branch-Ziele, Rückgabeverhalten, Aufgerufene-Aufrufeffekte, Evidence-Graph-Verankerung, Blockwertzustandskonsistenz, Evidenzabdeckung und verdächtige Identifikatorbehauptungen mit Analysatornachweisen ab. Er senkt das Vertrauen, wenn selbstbewusste Prosa wiederhergestellte Fakten überholt, und kennzeichnet jedes Problem mit einem stabilen Schweregrad-/Code-Paar.
- Wenn Verifiziererrückmeldungen Schemafehler, Faktenkonflikte oder sehr niedriges angepasstes Vertrauen feststellen, führt der LLM-Pfad einen automatischen erneuten Versuch durch, wobei die Verifiziererprobleme an den Prompt angehängt werden.
- Ein guter Ausgangspunkt für Cloud-Modelle ist `max_completion_tokens=12000`, `chunk_completion_tokens=6000` und `merge_completion_tokens=12000`, mit `force_chunked=false` und Blockauslösern um `900 instructions` oder `36 blocks`.
- Behalten Sie `force_chunked=true` nur für Belastungstests der Blockpipeline bei. Qualitätsorientierte Dekompilation von abgeflachten oder dispatcher-lastigen Funktionen benötigt normalerweise einen einzelnen Prompt, bis die Funktion groß genug ist, um die konfigurierten Blockauslöser zu überschreiten.
- Halten Sie `timeout_ms` für Cloud-Modelle hoch. `120000` ist ein sichererer Ausgangspunkt als `15000`.
- Wenn die Qualität bei riesigen Funktionen immer noch schwach ist, erhöhen Sie `chunk_count_limit` vor dem Verkleinern von `/limit:N`.
- Wenn kein Endpunkt konfiguriert ist, fällt die Erweiterung auf den deterministischen Mock-Provider zurück.
- Selbst wenn die Erweiterung `/view:analyzer` oder den Mock-Provider verwendet, wirken sich `display_language` und `syntax_highlighting` immer noch auf das aus, was der Benutzer sieht.

## WinDbg Smoke Test

1. Erstellen Sie mit `Build.ps1` oder `Build-Legacy.ps1`.
2. Platzieren Sie `decomp.llm.json` neben der erstellten `decomp.dll`.
3. Starten Sie WinDbg. Umgebungsvariablen sind nur optionale Überschreibungen.
4. Laden Sie die Erweiterung.
5. Validieren Sie den Nur-Analysator-Modus, bevor Sie den LLM-Pfad aktivieren.```text
.load C:\path\to\decomp.dll
!decomp /view:analyzer ntdll!RtlAllocateHeap
!decomp /view:facts kernel32!Sleep

Erwartete Überprüfungen:

- `target`, `entry` und `module` sollten konsistent aufgelöst werden
- `regions` sollten für normale Funktionen nicht null sein
- `/view:analyzer` sollte weiterhin die Analyzer-Konfidenz und den Pseudocode-Stub ausgeben
- Der LLM-Modus sollte `summary`, `pseudo_c`, `pseudo_c_tokens` und `verified` ausfüllen
- Die `/view:json`-Ausgabe sollte `preferred_natural_language_tag` und `preferred_natural_language_name` in der serialisierten Anfrage enthalten
- Wenn private oder umfangreiche PDBs geladen sind, sollte `/view:json` auch `pdb.prototype`, `pdb.params` und möglicherweise `pdb.locals` enthalten
- Bei typisierten Strukturen und Enums kann `/view:json` `pdb.field_hints` und `pdb.enum_hints` enthalten

## ChatGPT-Abonnement-Beispiel```powershell
$env:DECOMP_LLM_PROVIDER = "chatgpt"
$env:DECOMP_LLM_MODEL = "gpt-5.5"
$env:DECOMP_LLM_CHATGPT_AUTH_FILE = "$env:USERPROFILE\.codex\auth.json"
$env:DECOMP_LLM_TIMEOUT_MS = "120000"

windbg-decompile-ext

Beliebteste

Aktueller Umfang

WinDbg-Verwendung

Vendor-Kopie aus einem Debugger-Stammverzeichnis vorbereiten```powershell

Empfohlene Zydis-Einrichtung

Regressionstests```powershell

Release-Build mit automatisch inkrementierter DLL-Dateiversion```powershell

Explizites Include- und Bibliotheksbeispiel```powershell

Legacy-dbgeng-Kompatibilität

PDB-Verwendung

Konfiguration

Lokale LLM-Endpunkt-Beispiele

Ollama```powershell

vLLM oder OpenAI-kompatibler lokaler Server```powershell

windbg-decompile-ext

Beliebteste

Windbg Decompile-Erweiterung über LLM

Layout

Aktueller Umfang

WinDbg-Verwendung

Vendor-Kopie aus einem Debugger-Stammverzeichnis vorbereiten```powershell

Empfohlene Zydis-Einrichtung

Regressionstests```powershell

Release-Build mit automatisch inkrementierter DLL-Dateiversion```powershell

Explizites Include- und Bibliotheksbeispiel```powershell

Legacy-dbgeng-Kompatibilität

PDB-Verwendung

Konfiguration

Lokale LLM-Endpunkt-Beispiele

Ollama```powershell

vLLM oder OpenAI-kompatibler lokaler Server```powershell