Расширение WinDbg для декомпиляции через LLM

собственный просмотрщик декомпиляции

снимок экрана

Этот проект представляет собой шаблон расширения WinDbg для Windows x64, который определяет функцию по имени или адресу, восстанавливает детерминированное представление потока управления и напрямую обращается к LLM из расширения для генерации псевдокода.

Структура

src/extension: DLL расширения WinDbg и команда !decomp.
src/shared: общий код для JSON, анализатора, протокола и верификатора, используемый расширением.
scripts: вспомогательные сценарии сборки и копирования сторонних библиотек.
third_party/dbgeng: опциональная копия поставляемых dbgeng.h и dbgeng.lib.
third_party/zydis: поставляемое стабильное дерево исходного кода Zydis, используемое по умолчанию при наличии.

Текущий объем

предположения только для x64
анализ активной памяти через DbgEng
структурированная дизассемблеризация на основе Zydis для стабильного восстановления мнемоник/операндов
восстановление области символа, развертывание и эвристическое восстановление диапазона функций
восстановление в стиле SSA-lite для входящих регистровых аргументов, локальных переменных стековых слотов, кандидатов слияния и нормализованных условий ветвления
низкоуровневые факты значений IR с подсказками определения-использования, каноническими копиями/константными выражениями и маркерами мертвых определений
факты состояния значений на уровне блоков для сходящихся достигающих определений live-in/live-out по регистрам и локальным переменным стека
факты областей потока управления на основе доминаторов для естественных циклов, кандидатов if/else, кандидатов switch, метаданных индукции циклов и метаданных диапазона/по умолчанию switch
факты ABI x64 для теневых/домашних слотов, дельт указателя стека, распознавания пролога/эпилога, невозвратных вызовов, хвостовых вызовов, thunk'ов, кандидатов оберток импорта и восстановленных регистровых/стековых аргументов вызовов
восстановление аргументов Microsoft x64 с учетом SIMD/FP для xmm0 – xmm3 с защитой от нулевых идиом векторов для предотвращения ложных входящих аргументов
подсказки восстановления типов для указателеподобных значений, локальных переменных стека, смещений полей, массивов с масштабированным индексом, сравнений по типу перечислений, проверок битовых флагов и кандидатов vtable
факты идиом и библиотечных шаблонов для помощников по памяти/строкам, cookies безопасности, проб стеков, аллокаторов, агрегатных инициализаторов и RIP-относительных загрузок глобальных/импортных значений
факты целей вызовов для прямых вызовов, косвенных вызовов через регистр/память, кандидатов виртуальных вызовов/смещений vtable, типа возврата, модели параметров, побочных эффектов, эффектов памяти, подсказок владения и уверенности
факты обфускации в стиле OLLVM для диспетчеров уплощения потока управления, восстановленных семантических ребер, мертвых ребер непрозрачных предикатов и идиом замены скалярных инструкций
факты готовности деобфускации, а также управление /deobf:on|off (включено/выключено) для указания, могут ли восстановленные факты обфускации направлять перезапись псевдокода на C

Использование в WinDbg

Загрузите расширение из выходных данных сборки, затем выполните !decomp для символа или адреса:```text .load C:\path\to\decomp.dll !decomp /doctor !decomp module!FunctionName !decomp 0x7ffb`12345678

Используйте `/doctor`, если настройка выглядит неверно или перед включением LLM-провайдера:```text
!decomp /doctor
!decomp /doctor:net

/doctor не требует цели и не вызывает провайдера. Он сообщает о конфигурации (путь/статус загрузки), сводку по провайдеру/модели/конечной точке, наличие аутентификации без секретов, настройки таймаута/токенов/разбиения на чанки, поддержку DML, класс/квалификатор сессии, тип обработчика и предупреждения PDB.
/doctor:net принимается как явный запрос проверки сети, но в настоящее время сообщает, что пинг провайдера пропущен. Расширение не выполняет сетевой зонд из режима doctor.
Секретные значения, такие как ключи API, токены носителя, токены обновления и строки запроса URL, не выводятся.

Целями могут быть публичные/приватные символы, имена экспортируемых функций или адреса. Если цель разрешается в адрес внутри функции, расширение пытается восстановить диапазон содержащей функции из символов, данных развертывания и эвристик управления потоком. Помещайте цели, содержащие пробелы, в кавычки:```text !decomp "my module!Function With Spaces"

Обычный путь команды выполняет локальный анализ, строит факты анализа, при необходимости вызывает настроенную конечную точку LLM, проверяет ответ на соответствие восстановленным доказательствам и выводит псевдо-C с указанием уверенности, предупреждений и примечаний о неопределенности:```text
!decomp ntdll!RtlAllocateHeap
!decomp kernel32!Sleep
!decomp game.exe!CheckIntegrity

Normal, brief и explain выводят компактный поток прогресса даже без /verbose. Длинные запуски LLM показывают завершение локального анализа, прогресс по фрагментам, уведомления о повторных попытках, начало слияния, проверку и подсказку об отмене с помощью Ctrl+Break. Машиночитаемые режимы, такие как /view:json, /view:facts, /view:prompt и /view:data, подавляют строки прогресса и вспомогательные ссылки DML, чтобы скрипты получали только запрошенные данные.

Используйте /view:*, чтобы выбрать, что вы хотите видеть. Это позволяет сохранить небольшой набор команд: одна опция управляет всеми режимами вывода.```text !decomp /view:brief module!HotPath !decomp /view:explain module!BranchyFunction !decomp /view:json module!FunctionName !decomp /view:facts module!FunctionName !decomp /view:prompt module!FunctionName !decomp /view:data module!FunctionName !decomp /view:analyzer module!FunctionName !decomp /view:plan module!FunctionName

- `brief` выводит цель, уверенность, сводку и первое предупреждение о неопределенности или верификаторе.
- `explain` добавляет разделы: доказательства, поток управления, подсказка типа, наблюдаемое поведение и цель вызова.
- `json` выводит машиночитаемый JSON запроса и ответа.
- `facts` выводит только факты анализатора и отключает путь LLM.
- `prompt` выводит точный системный промпт, пользовательский промпт и факты промпта. Он отключает вызов LLM.
- `data` выводит стабильный JSON снимок, предназначенный для автоматизации в стиле WinDbg JavaScript/NatVis.
- `analyzer` отображает детерминированный путь псевдокода только анализатора без вызова LLM.
- `plan` выполняет локальный анализ и выводит предварительный план без вызова LLM или обновления кэша результатов. Он включает количество целей/модулей/диапазонов, доступность PDB, политику сессии, предполагаемую разбивку, количество, влияющее на размер промпта, и практические рекомендации.

Используйте `/verbose`, когда команда кажется зависшей или когда вы хотите увидеть полный поток выполнения:```text
!decomp /verbose module!SlowFunction
!decomp /verbose /view:json module!SlowFunction

/verbose выводит локальные этапы, такие как разрешение цели, восстановление диапазона функций, чтение байтов, дизассемблирование, построение фактов анализатора, обогащение PDB/сессии, токенизация псевдокода и результаты верификатора.
В режиме LLM /verbose также выводит размеры подсказок, бюджеты токенов запроса, этапы HTTP-соединения/отправки/получения, размеры чанков ответа, причину завершения, предварительный просмотр извлечённой JSON-модели, попытки повторных запросов и решения о повторных запросах с обратной связью от верификатора.
Ключ API не выводится. Логи запросов/ответов показывают размеры и короткие превью, а не полные заголовки или полные тела подсказок.
/verbose заменяет компактный поток прогресса полным трассировочным выводом. Используйте его, когда компактных строк прогресса недостаточно, чтобы понять, на что уходит время.
Во время длительного выполнения команды !decomp нажмите Ctrl+Break в WinDbg для запроса отмены. Расширение проверяет прерывания между этапами локального анализа и во время ожидания воркера LLM, после чего запрашивает остановку активного синхронного HTTP-ввода-вывода.

Устаревшие псевдонимы, такие как /brief, /explain, /json, /facts-only, /debug-prompt, /data-model, /dx и /no-llm, по-прежнему работают для старых скриптов, но в новых примерах используется /view:*.

Окно просмотра:```text !decomp /view:window module!FunctionName !decomp /view:window /view:explain module!FunctionName

- `/view:window` запускает обычный путь результата `!decomp` для цели и открывает полный отформатированный результат в отдельном окне просмотра.
- Окно просмотра использует тот же модуль отрисовки ответов, что и консольный путь, затем открывает нативное немодальное окно инструмента Win32, принадлежащее окну отладчика, если таковое найдено.
- Вывод отладчика сообщает дескриптор окна просмотра. Если окно просмотра не может быть создано, команда выводит предупреждение и возвращается к обычному консольному результату.
- Ссылки только для DML отображаются как текстовые метки с их командными строками в окне просмотра. Если доступен RichEdit, окно использует RTF-макет в стиле GitHub с заголовками разделов, стилизацией метаданных и псевдо-подсветкой кода; в противном случае используется обычный текст.
- Когда текущий сеанс содержит ранее кэшированные результаты, окно просмотра показывает список истории слева, чтобы вы могли переключаться между текущим выводом и более ранними результатами декомпиляции без повторного запуска анализа.
- `/view:json`, `/view:facts`, `/view:prompt` и `/view:data` остаются машиночитаемыми консольными выводами и не перенаправляются в окно просмотра.```text
!decomp /limit:deep module!LargeFunction
!decomp /limit:huge module!VeryLargeFunction
!decomp /limit:12000 module!VeryLargeFunction
!decomp /timeout:120000 module!SlowFunction

/limit:deep повышает лимит инструкций до 8192.
/limit:huge повышает лимит инструкций до 16384.
/limit:N устанавливает явный лимит инструкций.
/timeout:MS переопределяет тайм-аут запроса для данного вызова.
Разбиение на чанки LLM управляется файлом decomp.llm.json; лимит инструкций в командной строке определяет, сколько локального кода расширение пытается восстановить перед запросом.
Устаревшие /deep, /huge и /maxinsn:N по-прежнему поддерживаются.

Декомпиляция с учётом обфускации:```text !decomp /deobf:on module!FlattenedFunction !decomp /deobf:off module!FlattenedFunction !decomp /view:facts /deobf:off module!FlattenedFunction

- `/deobf:on` установлен по умолчанию. Анализатор по-прежнему выдает сырые факты, но высоконадежное восстановление диспетчера в стиле OLLVM, доказательства тупиковых ветвей, идиомы подстановки и семантические наложения CFG могут направлять подсказки фактов, политику слияния, политику разрешения конфликтов верификатора и структурированное восстановление псевдо-кода.
- `/deobf:off` оставляет факты `obfuscation`, `semantic_control_flow` и `deobfuscation_readiness` видимыми, но отключает безопасные действия по переписыванию, оставляет структурирование потока управления на основе исходного CFG и указывает путям prompt/merge/verifier сохранять исходную обфусцированную форму.
- Используйте `/deobf:off`, чтобы напрямую исследовать диспетчер, ложные ветви или поверхность подстановки, вместо того чтобы просить расширение восстановить деобфусцированную структуру.
- `/deobfuscation:on|off` принимается как более длинный псевдоним.

Помощники кэширования и повторного воспроизведения:```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 выводит предыдущий запрос/ответ JSON без повторного запуска анализа.
/last:explain повторно отображает предыдущий полный результат с разделом объяснения без повторного запуска анализа или вызова LLM.
/last:facts выводит факты анализатора из предыдущего результата без повторного запуска анализа.
/last:data выводит предыдущий снимок модели данных без повторного запуска анализа.
/last:prompt выводит предыдущий дамп подсказки без повторного запуска анализа.
/history выводит кольцевой буфер результатов в памяти. Индекс 1 — самый новый результат.
/refresh <target> обходит воспроизведение постоянного артефакта для указанной цели, выполняет свежий локальный анализ и анализ LLM, и заменяет сохранённый артефакт после успешного результата с LLM.
/last:N:explain, /last:N:json, /last:N:facts, /last:N:data и воспроизводят более старый кешированный результат по индексу истории без повторного запуска локального анализа или вызова LLM.

Навигация DML:

Когда WinDbg сообщает, что текущий обратный вызов вывода поддерживает DML, псевдокод подсвечивается синтаксически с использованием настроенных цветовых слотов DML.
Обычный вывод включает строку actions с кликабельными ссылками explain, json, facts, prompt, data-model и history для той же цели.
Обычный вывод также включает строку nav со ссылками на дизассемблер точки входа, точку останова на входе и воспроизведение последнего артефакта.
Адреса точек входа, базовые блоки, блоки доказательств, области потока управления, участки подсказок типов, замеченные участки горячих точек памяти, предложения по запросам TTD и прямые цели вызовов становятся кликабельными ссылками, если расширение располагает достаточной адресной информацией.
Неопределённости и предупреждения верификатора связываются с наилучшим восстановленным местоположением доказательства, если причина может быть сопоставлена с ветвью, циклом, переключателем, вызовом без возврата, инструкцией возврата или точкой входа функции.
Если текущий путь вывода не поддерживает DML, расширение автоматически переключается на обычный текст. Результат анализа остаётся тем же; меняется только представление.

Сведения об осведомлённости о сеансе и наблюдаемом поведении:

/view:json, /view:facts, /view:prompt и обычный режим LLM включают session_policy.
session_policy записывает класс отладки, квалификатор, вид выполнения, стратегию анализа, флаги дампа/живого/ядра и информацию о том, загружена ли поддержка TTD.
observed_behavior записывает текущий rip, rsp, обратный адрес (если читается), образцы регистровых аргументов x64 Microsoft (rcx, rdx, r8, r9), повторяющиеся горячие точки доступа к памяти и предложенные команды TTD.
Образцы аргументов текущего кадра имеют высокую достоверность только тогда, когда текущий указатель инструкции находится внутри анализируемой функции. В противном случае они сохраняются как контекстные подсказки.
Если ttdext.dll или загружены в процесс отладчика, расширение добавляет предложенные запросы вместо молчаливого предположения, что данные трассировки уже собраны.

Переключатели пользовательских исправлений позволяют изменять факты анализатора из командной строки, когда отладчику не хватает достаточной семантической информации:```text !decomp /fix:noreturn:FatalError module!FunctionName !decomp /fix:type:rcx=MY_TYPE* module!FunctionName !decomp /fix:field:[rcx+18h]=uint32_t module!FunctionName !decomp /fix:rename:v3=request module!FunctionName !decomp /fix:clear

- `/fix:noreturn:name` обрабатывает соответствующие вызовы как не возвращающие управление для запасной дизассемблерной обработки, восстановления CFG, фактов ABI и проверок верификатора.
- `/fix:type:expr=TYPE` добавляет подсказку типа пользователя с высокой степенью доверия.
- `/fix:field:expr=TYPE` добавляет подсказку поля пользователя с высокой степенью доверия.
- `/fix:rename:old=new` добавляет подсказку переименования и применяет его к конечным идентификаторам псевдокода.
- `/fix:clear` очищает все переопределения коррекций, сохраняемые в сеансе.

Переменная среды `DECOMP_NORETURN_OVERRIDES` по-прежнему поддерживается. Значения `/fix:noreturn:` из командной строки накладываются поверх исходного значения переменной среды для текущего сеанса WinDbg.

Ключи коррекции являются постоянными для сеанса:

- `/fix:noreturn:`, `/fix:type:`, `/fix:field:` и `/fix:rename:` запоминаются загруженным расширением и повторно используются в последующих запусках `!decomp`.
- `/fix:clear` очищает все постоянные для сеанса коррекции и восстанавливает исходное значение переопределения среды для no-return на момент загрузки расширения.
- Устаревшие `/noreturn:`, `/type:`, `/field:`, `/rename:` и `/clear-overrides` по-прежнему поддерживаются.

Некорректные значения коррекции игнорируются и сообщаются в `uncertainties`, а не кэшируются. Например, `/fix:type:rcx` игнорируется, так как не содержит пары `expr=TYPE`.

Рекомендуемый порядок исследования:

1. Начните с `!decomp /view:facts target`, чтобы убедиться, что диапазон функции, блоки, вызовы, импорт, данные PDB и факты сеанса выглядят разумно.
2. Используйте `!decomp /view:plan target`, чтобы оценить разбиение на части, размер запроса, риск тайм-аута и качество символов, прежде чем тратить запрос LLM.
3. Используйте `!decomp /view:prompt target`, когда размер запроса, язык или выбор доказательств выглядят неверно.
4. Запустите `!decomp target` для полного проверенного результата псевдо-C.
5. Используйте `!decomp /refresh target`, когда воспроизводится существующий постоянный артефакт, но вам нужен свежий анализ.
6. Если результат выглядит неправильным, запустите `!decomp /view:explain target` и проверьте предупреждения верификатора, охват доказательств и предлагаемые исправления.
7. Добавьте целенаправленные коррекции, такие как `/fix:noreturn:`, `/fix:type:`, `/fix:field:` или `/fix:rename:`, и повторно запустите ту же цель.
8. Используйте `/history` и индексированное воспроизведение `/last:N:*` при сравнении нескольких недавних результатов.
9. Захватите `/view:json` или `/last:json` при сообщении об ошибках или сравнении поведения между сборками.

## Поверхность фактов анализатора

Недавние факты анализатора намеренно переносятся через `/view:json`, `/view:facts`, `/view:prompt` и обычный режим LLM. Поля высокой ценности для первоначальной проверки:

- `stack_pointer` записывает поинструкционные изменения стека, псевдонимы относительно кадра и степень уверенности.
- `call_arguments` записывает восстановленные регистровые и стековые аргументы в точках вызова, включая ближайшие межблочные сохранения в стек, если доказательства достаточно сильны.
- `pdb.prototype_parameters` записывает структурированные имена параметров прототипа, типы, порядковые номера, расположение ABI и степень доверия к источнику.
- `control_flow` включает переменные индукции циклов, начальные значения, шаги, границы, направление, адрес таблицы переключения, целевые метки case, цель по умолчанию, границы диапазона, знак и выражение индекса, когда они восстановлены.
- `callee_summaries` и факты о целях вызовов включают прямые, косвенные и виртуальные вызовы/кандидаты vtable, а также известные семантики Win32/NT/Rtl для памяти, выделения, освобождения и статуса.
- `obfuscation` раскрывает кандидаты диспетчера упрощения в стиле OLLVM, переменные состояния, восстановленные семантические ребра, непрозрачные предикаты и идиомы скалярной подстановки.
- `semantic_control_flow` раскрывает восстановленные живые/мертвые ребра, которые получены из фактов обфускации и остаются доступными для проверки, даже если используется `/deobf:off`.
- `deobfuscation_readiness` предоставляет `enabled`, безопасные действия по перезаписи, заблокированные предположения, пути приоритетных фактов, счетчики и степень уверенности. Когда отключено, записывает решение политики и блокирует перезапись разархивированного потока управления.
- Выбор фактов для подсказки ранжирует записи с высоким сигналом первыми, а затем сохраняет распределение с распространенной выборкой, чтобы большие функции не теряли все низкочастотные свидетельства.

## Рекомендуемая настройка dbgeng

Самый быстрый путь - включить заголовочный файл и библиотеку импорта в проект.

Expected vendor layout:```text
third_party\dbgeng\inc\dbgeng.h
third_party\dbgeng\lib\dbgeng.lib

Вы можете скопировать их вручную или воспользоваться вспомогательным скриптом.

Подготовка копии поставщика из корня отладчика```powershell

powershell -ExecutionPolicy Bypass -File .\scripts\Prepare-DbgengVendor.ps1 ` -SourceRoot 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x64'

### Подготовить копию поставщика из явных путей к файлам```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'

Как только third_party\dbgeng существует, Build.ps1 автоматически отдаст ему предпочтение, и обычно вам не нужен DEBUGGERS_ROOT.

Совместимость с устаревшим dbgeng

Если ваш dbgeng.h слишком старый и сборка падает на GetSymbolEntryOffsetRegions или GetSymbolEntryString, используйте Build-Legacy.ps1 или передайте опцию CMake вручную.

С DECOMP_USE_SYMBOL_ENTRY_APIS=OFF расширение возвращается к:

GetFunctionEntryByOffset для восстановления диапазона на основе unwind в x64
GetNameByOffset плюс эвристическая дизассемблерная обработка, если метаданные unwind отсутствуют

Использование PDB

Расширение автоматически потребляет символы и информацию о типах, которые WinDbg уже загрузил для целевых модулей.

Существует два практических уровня обогащения PDB:

типизированные факты на уровне модуля: имена функций, прототипы, типы возврата, имена глобальных символов, смещения полей, имена констант перечислений и подсказки исходного кода
факты на уровне области: имена и типы параметров/локальных переменных из активной области отладчика, когда целевая функция соответствует текущей области или когда расширение может переключить область на точку входа функции

Как это влияет на генерацию псевдокода:

восстановленные аргументы регистров могут быть переименованы из эвристических имен, таких как arg1, в имена PDB, такие как ctx
локальные переменные стека могут быть обновлены с общих имен слотов на именованные и типизированные локальные переменные области, если они доступны
доступ к памяти на основе указателей может получить подсказки полей, такие как ctx->State
сравнения, подобные перечислениям, могут получить символические имена, такие как state == StateRunning
прямые сводки вызываемых функций могут повторно использовать прототипы и типы возврата, полученные из PDB

Важные ограничения:

публичные PDB могут предоставлять имена функций и некоторые данные типов, но часто не включают локальные переменные области
оптимизированные сборки могут сделать значения и местоположения локальных переменных области неполными или неоднозначными
расширение обрабатывает данные PDB как семантические подсказки, а не как разрешение переопределять поток управления, противоречащий дизассемблированию

Текущее поведение автоматическое. Нет отдельного переключателя конфигурации для использования PDB; качество зависит от того, что WinDbg уже загрузил, и от того, можно ли сопоставить текущую область с целевой функцией.

Конфигурация

Поместите decomp.llm.json рядом с decomp.dll.

Этот файл предназначен не только для настроек сетевой LLM.

provider, endpoint, model, бюджеты токенов и настройки разбиения на чанки влияют на путь LLM.
display_language влияет на естественный язык, используемый в сводках и неопределенностях.
syntax_highlighting влияет на отображение псевдокода в WinDbg, когда доступен вывод с поддержкой DML.
display_language и syntax_highlighting по-прежнему используются для вывода /view:analyzer и mock-провайдера.

Пример:```json { "provider": "openai-compatible", "endpoint": "https://api.openai.com/v1/chat/completions", "model": "gpt-5.4-2026-03-05", "api_key_env": "OPENAI_API_KEY", "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, "display_language": { "mode": "auto", "tag": "en-US", "name": "English" }, "syntax_highlighting": { "keyword_color": "warnfg", "type_color": "emphfg", "function_name_color": "srcid", "identifier_color": "wfg", "number_color": "changed", "string_color": "srcstr", "char_color": "srcchar", "comment_color": "subfg", "preprocessor_color": "verbfg", "operator_color": "srcannot", "punctuation_color": "srcpair" } }

Пример подписки на ChatGPT:```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"
}

Для provider: "chatgpt" параметр endpoint необязателен и по умолчанию равен https://chatgpt.com/backend-api/codex/responses. Базовый URL, такой как https://chatgpt.com/backend-api/codex, также принимается и нормализуется до /responses. Расширение читает tokens.access_token и tokens.refresh_token из настроенного файла аутентификации, обновляет истекшие JWT-токены доступа через OAuth OpenAI и записывает обновлённый набор токенов обратно в этот файл. Файл аутентификации по умолчанию — %USERPROFILE%\.codex\auth.json, поэтому можно напрямую повторно использовать вход в Codex CLI ChatGPT. Расширение не запускает браузер и не начинает процесс OAuth-логина внутри WinDbg; если файл аутентификации отсутствует, недействителен или больше не подлежит обновлению, выполните codex login вне WinDbg и повторите !decomp. Для одноразовых тестов используйте access_token или access_token_env вместо файла аутентификации. Параметры , , и зарезервированы для провайдеров, использующих API-ключи, совместимые с OpenAI, и игнорируются провайдером ChatGPT.

Поддерживаемые ключи:

provider
endpoint
model
api_key
api_key_env
access_token
access_token_env
chatgpt_auth_file
reasoning_effort
timeout_ms
max_completion_tokens
force_chunked
chunk_trigger_instructions
chunk_trigger_blocks

Поддерживаемые ключи display_language:

mode
tag
name

display_language.mode принимает значения:

auto
fixed

Поддерживаемые ключи syntax_highlighting:

keyword_color
type_color
function_name_color
identifier_color
number_color
string_color
char_color
comment_color
preprocessor_color
operator_color
punctuation_color

Как работают значения цветов syntax_highlighting:

Эти значения — имена цветовых слотов DML WinDbg, а не фиксированные RGB или CSS-цвета.
Расширение передаёт их в DML WinDbg как <col fg="...">.
WinDbg разрешает каждое имя слота в соответствии с текущей темой и настройками цветов окна команд.
По этой причине такие имена, как verbfg, warnfg, emphfg, srcid, не соответствуют одному универсальному цвету на всех машинах.
В настоящее время на стороне расширения нет конфигурации для произвольных RGB-значений, таких как #FF8800. Фактический цвет берётся из WinDbg, а не из decomp.llm.json.

Практическое следствие:

Если цвет символа выглядит слишком тёмным на одной тёмной теме, тот же слот может выглядеть приемлемо на другой машине или другой теме WinDbg.
Если два слота в вашей текущей теме выглядят почти одинаково, измените имена слотов в syntax_highlighting, а не предполагайте, что расширение игнорирует вашу настройку.
Если вам нужен действительно другой конечный цвет, измените тему WinDbg или настройки цветов окна команд, чтобы сам слот разрешался иначе.

Когда подсветка видна:

Расширение генерирует псевдокод с DML-раскраской, когда WinDbg сообщает, что текущие обратные вызовы вывода поддерживают DML.
Если текущий путь вывода отладчика не поддерживает DML, расширение автоматически переключается на обычный текстовый псевдокод.
Вывод /view:json не отображается через DML. Вместо этого он содержит pseudo_c_tokens, чтобы внешние инструменты могли применять свою собственную подсветку синтаксиса.

Общие слоты переднего плана DML:

wfg Текст окна по умолчанию.
normfg Обычный текст окна команд.
emphfg Выделенный текст. Microsoft документирует этот слот как светло-голубой по умолчанию, но точный вид всё равно зависит от темы.
warnfg Текст предупреждения.
errfg Текст ошибки.
verbfg Подробный текст.
changed Изменённые данные. Microsoft документирует этот слот как красный по умолчанию.

Общие слоты переднего плана DML для исходного кода:

srcnum Числовые константы.
srcchar Символьные константы.
srcstr Строковые константы.
srcid Идентификаторы.
srckw Ключевые слова.
srcpair Скобки или пары совпадающих символов.
srccmnt Комментарии.
srcdrct Директивы.
srcspid Специальные идентификаторы.
srcannot Аннотации исходного кода или элементы, похожие на аннотации.

Примеры:

verbfg означает «слот подробного текста», а не «конкретный именованный синий».
warnfg означает «слот предупреждения», а не «всегда жёлтый или оранжевый».
function_name_color: "srcid" означает «отображать имена функций с использованием слота идентификаторов WinDbg».

Если вы настраиваете цвета для тёмной темы:

Начните с function_name_color: "emphfg" или function_name_color: "verbfg", если имена функций выглядят слишком тусклыми с srcid.
Используйте identifier_color: "normfg" или identifier_color: "wfg" для обычных символов, которые должны оставаться читаемыми, но не перебивать ключевые слова.
Оставьте comment_color: "subfg", если хотите, чтобы комментарии были не на первом плане, но не исчезали полностью.

Официальная справка:

Поведение цветовых слотов DML и примеры: Настройка вывода отладчика с помощью DML
Классы сообщений окна команд, такие как normal, warning, error и verbose: .printf (WinDbg)

Прилагаемый decomp.llm.json.example содержит только допустимые настройки верхнего уровня, которые расширение действительно читает.

Примеры только для справки:

Следовать языку интерфейса ПК:```json { "display_language": { "mode": "auto" } }

Принудительный английский:```json
{
  "display_language": {
    "mode": "fixed",
    "tag": "en-US",
    "name": "English"
  }
}

Принудительно корейский:```json { "display_language": { "mode": "fixed", "tag": "ko-KR", "name": "Korean" } }

Тёмный пресет подсветки синтаксиса:```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"
  }
}

Предустановка светлой подсветки синтаксиса:```json { "syntax_highlighting": { "keyword_color": "emphfg", "type_color": "warnfg", "function_name_color": "srcid", "identifier_color": "normfg", "number_color": "changed", "string_color": "verbfg", "char_color": "srcchar", "comment_color": "subfg", "preprocessor_color": "srcannot", "operator_color": "wfg", "punctuation_color": "subfg" } }

Пример деталей ответа `/view:json`:

- Ответ JSON включает `pseudo_c` и `pseudo_c_tokens`.
- `pseudo_c_tokens` — это детерминированный поток токенов, подходящий для внешней подсветки синтаксиса.
- Сериализованный запрос включает `preferred_natural_language_tag` и `preferred_natural_language_name`, которые отражают разрешённый язык отображения после применения `display_language.mode`.
- Факты анализатора теперь включают поля качества P0:
  `ir_values`, `block_value_states`, `control_flow` и `abi`.
- `ir_values` предоставляет идентификаторы значений, подобные SSA, места определения, цели, канонические выражения, ссылки на использование, флаги констант/копий и подсказки о мёртвых определениях.
- `block_value_states` предоставляет для каждого базового блока живущие/входящие/исходящие достигающие определения, канонические значения, класс хранения, состояние конвергенции и уверенность.
- `stack_pointer` предоставляет поинструкционные дельты стека, псевдонимы относительно кадра, необработанные базы/смещения и уверенность.
- `control_flow` предоставляет кандидаты структурированных регионов, таких как `natural_loop`, `if_else_candidate` и `switch_candidate`, с доказательствами блоков, метаданными индукции цикла, метаданными таблицы перехода/по умолчанию/диапазона, знаковостью, индексными выражениями и уверенностью.
- `abi` предоставляет предположения о теневом пространстве Microsoft x64, доказательства слотов дома, распознавание кадра/пролога/эпилога, доказательства невозвратных вызовов, кандидаты хвостовых вызовов, кандидаты заглушек (thunk), кандидаты обёрток импорта и восстановленные аргументы вызова из регистров и сохранений в стеке.
- Факты анализатора теперь также включают P1 семантические поля:
  `type_hints`, `idioms` и `callee_summaries`.
- `type_hints` предоставляет доказательства указателей, локальных переменных, смещений полей, массивоподобных структур, перечислений, битовых флагов и кандидатов vtable с источником и уверенностью. Когда доступны данные PDB, в этот унифицированный поток подсказок типов также продвигаются параметры/локальные переменные с областями видимости, подсказки полей и константы перечислений.
- `idioms` предоставляет замены более высокого уровня для распознанных вспомогательных вызовов и шаблонов компилятора, таких как копирование/заполнение памяти, копирование строк, проверки охранных куки, пробники стека, вспомогательные функции выделения/освобождения, инициализаторы агрегатов и загрузки глобальных/импортных RIP-относительных переменных.
- `callee_summaries` предоставляет прямые и косвенные подсказки типа возврата вызываемого, модели параметров, побочных эффектов, эффектов памяти, владения, источника и уверенности; обогащённые символами/типами цели вызовов заменяют начальные эвристические сводки, когда WinDbg может их разрешить, а кандидаты виртуальных вызовов включают целевые выражения плюс смещения vtable, если они восстановлены.
- Известные сводки API Win32/NT/Rtl описывают поведение копирования/заполнения/обнуления памяти, выделения, освобождения, статуса и ошибок, когда доступны имена символов.
- Подсказки промпта включают `analyzer_skeleton` и `graph_summary`, чтобы модель уточняла черновик, основанный на доказательствах, вместо того чтобы начинать с чистого листа.
- `graph_summary` предоставляет начальный блок, регионы потока управления, нормализованные условия и репрезентативные блоки с высоким сигналом с явной политикой усечения. Выбор подсказок промпта теперь ранжирует записи с высоким сигналом и использует разреженную выборку, чтобы большие наборы фактов оставались репрезентативными.
- `evidence_graph` предоставляет узлы фактов с высоким сигналом и рёбра происхождения, чтобы значения IR, состояния значений блоков, обращения к памяти, цели вызовов, подсказки типов, подсказки PDB и наблюдаемое поведение можно было проследить до доказательств инструкций и блоков.
- `obfuscation`, `semantic_control_flow` и `deobfuscation_readiness` предоставляют факты восстановления в стиле OLLVM и информацию о том, включено ли руководство по переписыванию деобфускации для текущей команды.
- Ответ верификатора включает устаревшие `warnings` плюс структурированные записи `issues`. Каждая проблема содержит `severity`, `code`, `message` и необязательный `evidence`, чтобы инструменты могли фильтровать такие ошибки, как `branch.true_target_not_successor`, отдельно от предупреждений более низкого риска.
- Проверки верификатора теперь сравнивают нормализованные true/false цели ветвлений с преемниками CFG, сравнивают плотность псевдокодовых ветвлений с восстановленными условными ветвлениями, перекрестно проверяют сводки прямых вызываемых на предмет эффектов псевдокодовых вызовов, проверяют связь узлов/рёбер графа доказательств и проверяют ссылки состояний значений блоков на восстановленные блоки и значения IR.
- Нормальный вывод и вывод explain могут включать краткий раздел `suggested fixes`. Это консервативные команды `/fix:*`, полученные из проблем верификатора, возможностей переименования на основе PDB или повторяющихся наблюдаемых горячих точек памяти. Осведомлённый о DML вывод отображает немедленно применимые предложения как кликабельные ссылки для повторного запуска для той же цели; предложения полей-заполнителей остаются в виде обычного текста, пока `TYPE` не будет заменён.
- В режиме LLM расширение автоматически подаёт проблемы верификатора обратно в один повторный промпт. Повтор сохраняется, если он сохраняет или улучшает качество верификации; в противном случае исходный ответ сохраняется с добавленным примечанием о неопределённости.
- `session_policy` и `observed_behavior` предоставляют контекст, специфичный для WinDbg, такой как политика live/dump/kernel/TTD, выборки аргументов регистров текущего кадра, горячие точки памяти и предлагаемые запросы трассировки.
- Сериализованный запрос теперь также включает объект `pdb`, когда доступны данные символов/типов.
- `pdb.availability` сообщает уровень обогащения, такой как `none`, `symbols`, `typed` или `scoped`.
- `pdb.params`, `pdb.locals`, `pdb.field_hints`, `pdb.enum_hints` и `pdb.source_locations` предназначены как машиночитаемые семантические подсказки для внешних инструментов или автономного анализа.

Необязательные переопределения окружения:

- `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`
  Разделённые запятыми или точкой с запятой фрагменты имён функций, рассматриваемые как цели без возврата во время резервной дизассемблеровки, восстановления преемников CFG, фактов ABI и проверок верификатора. Пример: `DECOMP_NORETURN_OVERRIDES=MyAbort;PanicAndExit`.

Примечание о качестве в первую очередь:

- Расширение теперь поддерживает многоэтапный анализ с разбиением на чанки для больших функций.
- Анализатор отправляет факты значений IR, состояния значений блоков, регионы потока управления, факты графа доказательств и доказательства ABI x64/без возврата в LLM перед уточнением, поэтому `/view:analyzer`, `/view:json` и обычный режим LLM все используют одну и ту же базу доказательств P0.
- Верификатор перекрестно проверяет циклы, переключатели, отсутствие возврата, цели ветвлений, поведение возврата, эффекты вызовов вызываемых, привязку графа доказательств, согласованность состояний значений блоков, покрытие доказательств и подозрительные утверждения идентификаторов на основе доказательств анализатора. Он снижает доверие, когда уверенный текст опережает восстановленные факты, и помечает каждую проблему стабильной парой severity/code.
- Когда обратная связь верификатора обнаруживает ошибки схемы, конфликты фактов или очень низкую скорректированную уверенность, путь LLM выполняет одну автоматическую повторную попытку, добавляя проблемы верификатора в промпт.
- Хорошая отправная точка для облачных моделей — `max_completion_tokens=12000`, `chunk_completion_tokens=6000` и `merge_completion_tokens=12000`, с `force_chunked=false` и триггерами чанков около `900 instructions` или `36 blocks`.
- Оставляйте `force_chunked=true` только для стресс-тестов конвейера чанков. Качественная декомпиляция сплющенных функций или функций с большим количеством диспетчеров обычно требует одного промпта, пока функция не станет достаточно большой, чтобы превысить настроенные триггеры чанков.
- Оставляйте `timeout_ms` высоким для облачных моделей. `120000` — более безопасная отправная точка, чем `15000`.
- Если качество все ещё слабое для огромных функций, увеличьте `chunk_count_limit` перед уменьшением `/limit:N`.
- Если конечная точка не настроена, расширение возвращается к детерминированному провайдеру-заглушке.
- Даже когда расширение использует `/view:analyzer` или провайдера-заглушку, `display_language` и `syntax_highlighting` все ещё влияют на то, что видит пользователь.

## Дымовое тестирование WinDbg

1. Соберите с помощью `Build.ps1` или `Build-Legacy.ps1`.
2. Поместите `decomp.llm.json` рядом с собранным `decomp.dll`.
3. Запустите WinDbg. Переменные окружения являются только необязательными переопределениями.
4. Загрузите расширение.
5. Проверьте режим только анализатора перед включением пути LLM.```text
.load C:\path\to\decomp.dll
!decomp /view:analyzer ntdll!RtlAllocateHeap
!decomp /view:facts kernel32!Sleep

Затем проверьте режим LLM:```text !decomp ntdll!RtlAllocateHeap !decomp /view:json ntdll!RtlAllocateHeap !decomp 0x7ffb`12345678

Ожидаемые проверки:

- `target`, `entry` и `module` должны разрешаться согласованно
- `regions` должны быть ненулевыми для обычных функций
- `/view:analyzer` должен по-прежнему выводить уверенность анализатора и заглушку псевдокода
- Режим LLM должен заполнять `summary`, `pseudo_c`, `pseudo_c_tokens` и `verified`
- Вывод `/view:json` должен включать `preferred_natural_language_tag` и `preferred_natural_language_name` в сериализованном запросе
- когда загружены приватные или обогащённые PDB, `/view:json` также должен включать `pdb.prototype`, `pdb.params` и, возможно, `pdb.locals`
- для типизированных структур и перечислений `/view:json` может включать `pdb.field_hints` и `pdb.enum_hints`

## Пример подписки ChatGPT```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"

Если файл аутентификации содержит токен обновления, расширение обновляет устаревший токен доступа перед отправкой запроса. DECOMP_LLM_CHATGPT_ACCESS_TOKEN можно использовать для временного токена-носителя, но путь к файлу аутентификации лучше подходит для обычных сеансов WinDbg, так как он переживает срок действия токена. Расширение никогда не открывает браузер во время !decomp; выполните codex login за пределами WinDbg, когда требуется интерактивный вход в ChatGPT.

Примеры конечных точек локальных LLM

Ollama```powershell

$env:DECOMP_LLM_ENDPOINT = "http://127.0.0.1:11434/v1/chat/completions" $env:DECOMP_LLM_MODEL = "qwen2.5-coder:14b" $env:DECOMP_LLM_API_KEY = "ollama"

### LM Studio```powershell
$env:DECOMP_LLM_ENDPOINT = "http://127.0.0.1:1234/v1/chat/completions"
$env:DECOMP_LLM_MODEL = "local-model"
$env:DECOMP_LLM_API_KEY = "lm-studio"

vLLM или OpenAI-совместимый локальный сервер```powershell

$env:DECOMP_LLM_ENDPOINT = "http://127.0.0.1:8000/v1/chat/completions" $env:DECOMP_LLM_MODEL = "Qwen/Qwen2.5-Coder-14B-Instruct" $env:DECOMP_LLM_API_KEY = "local"

Популярное

windbg-decompile-ext