Extensión de Descompilación de Windbg vía LLM

visor de descompilación nativa

captura de pantalla

Este proyecto es un esqueleto de extensión de WinDbg para Windows x64 que resuelve una función por nombre o dirección, reconstruye una vista de flujo de control determinista, y solicita directamente a un LLM desde la extensión para producir pseudocódigo.

Diseño

src/extension: DLL de extensión de WinDbg y comando !decomp.
src/shared: código JSON, analizador, protocolo y verificador compartido por la extensión.
scripts: ayudantes de compilación y copia de proveedor.
third_party/dbgeng: copia opcional de dbgeng.h y dbgeng.lib incluida.
third_party/zydis: árbol fuente estable de Zydis incluido, usado por defecto cuando está presente.

Alcance Actual

Suposiciones solo x64
Análisis de memoria en vivo a través de DbgEng
Desensamblado estructurado basado en Zydis para recuperación estable de mnemónicos/operandos
Recuperación de rango de función por región de símbolo, desenrollado y heurística
Recuperación estilo SSA-lite para argumentos de registro entrantes, locales en pila, candidatos de fusión y condiciones de rama normalizadas
Hechos de valor IR de bajo nivel con sugerencias de uso-def, expresiones canónicas de copia/constante y marcadores de definición muerta
Hechos de estado de valor a nivel de bloque para definiciones alcanzantes convergidas de entrada/salida en registros y locales de pila
Hechos de región de flujo de control respaldados por dominadores para bucles naturales, candidatos if/else, candidatos switch, metadatos de inducción de bucle y metadatos de rango/predeterminado de switch
Hechos ABI x64 para slots de sombra/hogar, deltas de puntero de pila, reconocimiento de prólogo/epílogo, llamadas sin retorno, llamadas de cola, thunks, candidatos de envoltorio de importación y argumentos de llamada recuperados en registro/pila
Recuperación de argumentos x64 de Microsoft consciente de SIMD/FP para xmm0 a xmm3, con protecciones de idioma vector cero para evitar argumentos entrantes falsos
Sugerencias de recuperación de tipo para valores tipo puntero, locales de pila, desplazamientos de campo, arrays de índice escalado, comparaciones tipo enum, pruebas de bitflag y candidatos a vtable
Hechos de modismo y patrón de biblioteca para ayudantes de memoria/cadena, cookies de seguridad, sondas de pila, asignadores, inicializadores de agregados y cargas globales/de importación RIP-relativas
Hechos de destino de llamada para llamadas directas, llamadas indirectas por registro/memoria, candidatos de llamada virtual/desplazamiento vtable, tipo de retorno, modelo de parámetros, efectos secundarios, efectos de memoria, sugerencias de propiedad y confianza
Hechos de ofuscación estilo OLLVM para despachadores de aplanamiento de flujo de control, aristas semánticas recuperadas, aristas muertas de predicado opaco y modismos de sustitución de instrucciones escalares
Hechos de preparación para desofuscación más control /deobf:on|off sobre si los hechos de ofuscación recuperados pueden guiar la reescritura pseudo-C

Uso en WinDbg

Cargue la extensión desde la salida de compilación, luego ejecute !decomp contra un símbolo o una dirección:```text .load C:\path\to\decomp.dll !decomp /doctor !decomp module!FunctionName !decomp 0x7ffb`12345678

Usa `/doctor` cuando la configuración parezca incorrecta o antes de habilitar un proveedor de LLM:```text
!decomp /doctor
!decomp /doctor:net

/doctor no requiere un objetivo y no llama al proveedor. Reporta la ruta/estado de configuración, resumen del proveedor/modelo/punto final, presencia de autenticación sin secretos, configuración de tiempo de espera/token/fragmentación, soporte DML, clase/cualificador de sesión, tipo de procesador y advertencias de PDB.
/doctor:net se acepta como una solicitud explícita de verificación de red, pero actualmente informa que el ping del proveedor se omite. La extensión no realiza un sondeo de red desde el modo doctor.
Los valores secretos como claves API, tokens de portador, tokens de actualización y cadenas de consulta de URL no se imprimen.

Los objetivos pueden ser símbolos públicos/privados, nombres de funciones exportadas o direcciones. Si el objetivo se resuelve a una dirección dentro de una función, la extensión intenta recuperar el rango de la función contenedora a partir de símbolos, datos de desenredo y heurísticas de flujo de control. Coloque comillas alrededor de los objetivos que contengan espacios:```text !decomp "my module!Function With Spaces"

La ruta de comando normal realiza análisis local, construye hechos del analizador, opcionalmente llama al endpoint LLM configurado, verifica la respuesta contra la evidencia recuperada, e imprime pseudo-C más confianza, advertencias y notas de incertidumbre:```text
!decomp ntdll!RtlAllocateHeap
!decomp kernel32!Sleep
!decomp game.exe!CheckIntegrity

Normal, brief, y explain output incluye un flujo de progreso compacto incluso sin /verbose. Las ejecuciones largas de LLM muestran finalización del análisis local, progreso de fragmentos, avisos de reintento, inicio de fusión, verificación y la sugerencia de cancelación con Ctrl+Break. Los modos legibles por máquina como /view:json, /view:facts, /view:prompt, y /view:data suprimen las líneas de progreso y los enlaces auxiliares DML para que los scripts reciban solo la carga útil solicitada.

Use /view:* para elegir lo que desea ver. Esto mantiene la superficie de comandos pequeña: una opción controla todos los modos de salida.```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` imprime objetivo, confianza, resumen y la primera advertencia de incertidumbre o de verificador.
- `explain` añade evidencia, flujo de control, tipo de sugerencia, comportamiento observado y secciones de destino de llamada.
- `json` imprime la solicitud y respuesta JSON en formato legible por máquina.
- `facts` imprime solo los hechos del analizador y deshabilita la ruta de LLM.
- `prompt` imprime el prompt exacto del sistema, el prompt del usuario y los hechos del prompt. Deshabilita la llamada al LLM.
- `data` imprime una instantánea JSON estable destinada a la automatización tipo WinDbg JavaScript/NatVis.
- `analyzer` renderiza la ruta de pseudo-código exclusiva del analizador determinista sin llamar al LLM.
- `plan` realiza un análisis local e imprime un plan previo sin llamar al LLM ni actualizar la caché de resultados. Incluye recuentos de objetivo/módulo/rango, disponibilidad de PDB, política de sesión, fragmentación estimada, recuentos relevantes para el tamaño del prompt y recomendaciones prácticas.

Use `/verbose` cuando un comando parezca atascado o cuando quieras ver el flujo completo de progreso:```text
!decomp /verbose module!SlowFunction
!decomp /verbose /view:json module!SlowFunction

/verbose imprime etapas locales como resolución de destino, recuperación de rango de funciones, lecturas de bytes, desensamblado, construcción de hechos del analizador, enriquecimiento de PDB/sesión, tokenización de pseudocódigo y resultados del verificador.
En modo LLM, /verbose también imprime tamaños de prompt, presupuestos de tokens de solicitud, etapas de conexión/envío/recepción HTTP, tamaños de fragmentos de respuesta, motivo de finalización, vista previa JSON del modelo extraído, intentos de reintento y decisiones de reintento con retroalimentación del verificador.
La clave de API no se imprime. Los registros de solicitud/respuesta muestran tamaños y vistas previas cortas en lugar de encabezados completos o cuerpos de prompt completos.
/verbose reemplaza el flujo de progreso compacto con el seguimiento completo. Úselo cuando las líneas de progreso compacto no sean suficientes para diagnosticar dónde se está gastando el tiempo.
Durante un comando !decomp de larga duración, presione Ctrl+Break en WinDbg para solicitar la cancelación. La extensión verifica interrupciones entre etapas de análisis local y mientras espera al trabajador LLM, luego solicita al I/O HTTP síncrono activo que se detenga.

Los alias heredados como /brief, /explain, /json, /facts-only, /debug-prompt, /data-model, /dx y /no-llm aún funcionan para scripts antiguos, pero los nuevos ejemplos usan /view:*.

Visor de ventana:```text !decomp /view:window module!FunctionName !decomp /view:window /view:explain module!FunctionName

- `/view:window` ejecuta la ruta de resultado normal de `!decomp` para el objetivo y abre el resultado completo renderizado en un visor separado.
- El visor utiliza el mismo renderizador de respuesta que la ruta de consola, luego abre una ventana de herramienta sin modo nativa de Win32 propiedad de la ventana del depurador cuando se puede encontrar una.
- La salida del depurador informa el identificador de la ventana del visor nativo. Si no se puede crear la ventana del visor, el comando imprime una advertencia y recurre al resultado normal de consola.
- Los enlaces solo DML se renderizan como etiquetas de texto con sus cadenas de comando en el visor. Cuando RichEdit está disponible, la ventana utiliza un diseño RTF estilo GitHub con encabezados de sección, estilo de metadatos y resaltado de pseudocódigo; de lo contrario, recurre a texto plano.
- Cuando la sesión actual tiene resultados almacenados en caché previos, el visor muestra una lista de historial en el lado izquierdo para que puedas cambiar entre la salida actual y resultados de descompilación anteriores sin volver a ejecutar el análisis.
- `/view:json`, `/view:facts`, `/view:prompt` y `/view:data` permanecen como salidas de consola legibles por máquina y no se redirigen al visor.

Funciones grandes:```text
!decomp /limit:deep module!LargeFunction
!decomp /limit:huge module!VeryLargeFunction
!decomp /limit:12000 module!VeryLargeFunction
!decomp /timeout:120000 module!SlowFunction

/limit:deep eleva el límite de instrucciones a 8192.
/limit:huge eleva el límite de instrucciones a 16384.
/limit:N establece un límite de instrucciones explícito.
/timeout:MS anula el tiempo de espera de la solicitud para esta invocación.
El chunking del LLM está controlado por decomp.llm.json; el límite de instrucciones de la línea de comandos controla cuánto código local intenta recuperar la extensión antes de realizar la solicitud.
Las opciones heredadas /deep, /huge y /maxinsn:N siguen siendo compatibles.

Descompilación consciente de ofuscación:```text !decomp /deobf:on module!FlattenedFunction !decomp /deobf:off module!FlattenedFunction !decomp /view:facts /deobf:off module!FlattenedFunction

- `/deobf:on` es el predeterminado. El analizador aún emite hechos en bruto, pero la recuperación de dispatcher estilo OLLVM de alta confianza, prueba de bordes muertos opacos, modismos de sustitución y superposiciones semánticas de CFG pueden guiar los hechos rápidos, la política de fusión, la política de conflictos del verificador y la recuperación de pseudo-C estructurado.
- `/deobf:off` mantiene visibles los hechos `obfuscation`, `semantic_control_flow` y `deobfuscation_readiness`, pero deshabilita las acciones seguras de reescritura, mantiene la estructuración del flujo de control en el CFG sin procesar, y le indica a las rutas de prompt/fusión/verificador que preserven la forma ofuscada sin procesar.
- Use `/deobf:off` cuando quieras inspeccionar el dispatcher, las ramas falsas o la superficie de sustitución directamente en lugar de pedirle a la extensión que recupere una estructura desofuscada.
- `/deobfuscation:on|off` se acepta como un alias más largo.

Ayudantes de caché y repetición:```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 imprime el JSON de la solicitud/respuesta anterior sin volver a ejecutar el análisis.
/last:explain vuelve a representar el resultado completo anterior con la sección de explicación sin volver a ejecutar el análisis ni llamar al LLM.
/last:facts imprime los hechos del analizador del resultado anterior sin volver a ejecutar el análisis.
/last:data imprime la instantánea del modelo de datos anterior sin volver a ejecutar el análisis.
/last:prompt imprime el volcado de prompt anterior sin volver a ejecutar el análisis.
/history lista el búfer circular de resultados en memoria. El índice 1 es el resultado más reciente.
/refresh <target> omite la reproducción de artefactos persistentes para ese objetivo, ejecuta un análisis local nuevo y análisis LLM, y reemplaza el artefacto guardado tras un resultado exitoso respaldado por LLM.
/last:N:explain, /last:N:json, /last:N:facts, y reproducen un resultado en caché más antiguo por índice de historial sin volver a ejecutar el análisis local ni llamar al LLM.

Navegación DML:

Cuando WinDbg informa que la devolución de llamada de salida actual es compatible con DML, el pseudocódigo se resalta con ranuras de color DML configuradas.
La salida normal incluye una fila de actions con enlaces en los que se puede hacer clic para explain, json, facts, prompt, data-model e history para el mismo objetivo.
La salida normal también incluye una fila nav con enlaces a desensamblado de entrada, punto de interrupción de entrada y reproducción del último artefacto.
Las direcciones de entrada, bloques básicos, bloques de evidencia, regiones de flujo de control, sitios de sugerencias de tipo, sitios de puntos calientes de memoria observados, sugerencias de consulta TTD y destinos de llamadas directas se convierten en enlaces en los que se puede hacer clic cuando la extensión tiene suficiente información de dirección.
Las incertidumbres y advertencias del verificador se vinculan a la mejor ubicación de evidencia recuperada cuando la causa se puede asignar a una rama, bucle, switch, llamada sin retorno, instrucción de retorno o entrada de función.
Si la ruta de salida actual no es compatible con DML, la extensión recurre automáticamente a texto sin formato. El resultado del análisis es el mismo; solo cambia la presentación.

Detalles de sesión y comportamiento observado:

/view:json, /view:facts, /view:prompt y el modo LLM normal incluyen session_policy.
session_policy registra la clase de depuración, calificador, tipo de ejecución, estrategia de análisis, indicadores de volcado/en vivo/kernel y si la compatibilidad con TTD parece estar cargada.
observed_behavior registra el rip actual, rsp, dirección de retorno cuando es legible, muestras de argumentos de registro x64 de Microsoft (rcx, rdx, r8, r9), puntos calientes de acceso a memoria repetidos y comandos TTD sugeridos.
Las muestras de argumentos del marco actual son de alta confianza solo cuando el puntero de instrucción actual está dentro de la función analizada. De lo contrario, se mantienen como sugerencias contextuales.
Si ttdext.dll o está cargado en el proceso del depurador, la extensión agrega consultas sugeridas en lugar de fingir silenciosamente que ya se recopilaron datos de seguimiento.

- `/fix:noreturn:name` trata las llamadas coincidentes como sin retorno para el desensamblado de respaldo, recuperación de CFG, hechos ABI y comprobaciones de verificador.
- `/fix:type:expr=TYPE` añade una pista de tipo de usuario de alta confianza.
- `/fix:field:expr=TYPE` añade una pista de campo de usuario de alta confianza.
- `/fix:rename:old=new` añade una pista de renombrado y aplica el renombrado a los identificadores finales del pseudocódigo.
- `/fix:clear` limpia todas las anulaciones de corrección persistentes de la sesión.

La variable de entorno `DECOMP_NORETURN_OVERRIDES` sigue siendo compatible. Los valores de línea de comandos `/fix:noreturn:` se superponen al valor original de la variable de entorno para la sesión actual de WinDbg.

Los interruptores de corrección son persistentes en la sesión:

- `/fix:noreturn:`, `/fix:type:`, `/fix:field:`, y `/fix:rename:` son recordados por la extensión cargada y reutilizados en ejecuciones posteriores de `!decomp`.
- `/fix:clear` limpia todas las correcciones persistentes de la sesión y restaura la anulación de entorno sin retorno a su valor original desde el momento de carga de la extensión.
- Los heredados `/noreturn:`, `/type:`, `/field:`, `/rename:`, y `/clear-overrides` siguen siendo compatibles.

Los valores de corrección mal formados se ignoran y se reportan en `uncertainties` en lugar de almacenarse en caché. Por ejemplo, `/fix:type:rcx` se ignora porque no contiene un par `expr=TYPE`.

Flujo de trabajo de investigación recomendado:

1. Comience con `!decomp /view:facts target` para confirmar que el rango de la función, los bloques, las llamadas, las importaciones, los datos de PDB y los hechos de la sesión se vean razonables.
2. Use `!decomp /view:plan target` para estimar la fragmentación, el tamaño del prompt, el riesgo de tiempo de espera y la calidad de los símbolos antes de realizar una solicitud LLM.
3. Use `!decomp /view:prompt target` cuando el tamaño del prompt, el idioma o la selección de evidencia parezcan incorrectos.
4. Ejecute `!decomp target` para obtener el resultado completo de pseudo-C verificado.
5. Use `!decomp /refresh target` cuando se esté reproduciendo un artefacto persistente existente pero necesite un análisis nuevo.
6. Si el resultado parece incorrecto, ejecute `!decomp /view:explain target` e inspeccione las advertencias del verificador, la cobertura de evidencia y las correcciones sugeridas.
7. Agregue correcciones enfocadas como `/fix:noreturn:`, `/fix:type:`, `/fix:field:`, o `/fix:rename:` y vuelva a ejecutar el mismo objetivo.
8. Use `/history` y la reproducción indexada `/last:N:*` al comparar varios resultados recientes.
9. Capture `/view:json` o `/last:json` al reportar errores o comparar el comportamiento entre versiones.

## Superficie de Hechos del Analizador

Los hechos recientes del analizador se transfieren intencionalmente a través de `/view:json`, `/view:facts`, `/view:prompt`, y el modo LLM normal. Campos de alto valor a inspeccionar primero:

- `stack_pointer` registra deltas de pila por instrucción, alias relativos al marco y confianza.
- `call_arguments` registra los argumentos de registro y pila recuperados en los sitios de llamada, incluyendo almacenes de pila cercanos a través de bloques cuando la evidencia es suficientemente sólida.
- `pdb.prototype_parameters` registra nombres de parámetros de prototipo estructurados, tipos, ordinales, ubicaciones ABI y confianza de fuente.
- `control_flow` incluye variables de inducción de bucle, valores iniciales, pasos, límites, dirección, dirección de tabla de interruptores, objetivos de caso, objetivo predeterminado, límites de rango, signo y expresión de índice cuando se recuperan.
- `callee_summaries` y hechos de destino de llamada incluyen candidatos directos, indirectos y de llamada virtual/vtable, además de semánticas conocidas de memoria, asignación, liberación y estado de Win32/NT/Rtl.
- `obfuscation` expone candidatos de despachador de aplanamiento estilo OLLVM, variables de estado, bordes semánticos recuperados, predicados opacos y modismos de sustitución escalar.
- `semantic_control_flow` expone bordes vivos/muertos recuperados que se derivan de hechos de ofuscación y permanecen disponibles para inspección incluso cuando se usa `/deobf:off`.
- `deobfuscation_readiness` expone `enabled`, acciones de reescritura seguras, suposiciones bloqueadas, rutas de hechos prioritarias, recuentos y confianza. Cuando está deshabilitado, registra la decisión de política y bloquea la reescritura del flujo de control desofuscado.
- La selección de hechos en el prompt clasifica primero las entradas de alta señal, luego preserva la distribución con muestreo disperso para que las funciones grandes no pierdan toda la evidencia de baja frecuencia.

## Configuración Recomendada de dbgeng

La ruta más rápida es incluir el encabezado y la biblioteca de importación en el proyecto.

Diseño esperado del proveedor:
``````text
third_party\dbgeng\inc\dbgeng.h
third_party\dbgeng\lib\dbgeng.lib

Puede copiarlos manualmente, o usar el script auxiliar.

Preparar copia del proveedor desde una raíz del depurador```powershell

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

### Preparar copia del proveedor desde rutas de archivo explícitas```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'

Una vez que exista third_party\dbgeng, Build.ps1 lo preferirá automáticamente y normalmente no necesitarás DEBUGGERS_ROOT.

Configuración recomendada de Zydis

El repositorio puede usar:

código fuente de third_party\zydis vendored
FetchContent de CMake

El comportamiento predeterminado es auto, que prefiere third_party\zydis cuando está presente y recurre a obtener Zydis durante la configuración de CMake.

Disposición esperada del vendor:```text third_party\zydis\CMakeLists.txt third_party\zydis\include\Zydis\Zydis.h third_party\zydis\dependencies\zycore\CMakeLists.txt

Actualizar o crear la copia del proveedor:```powershell
powershell -ExecutionPolicy Bypass -File .\scripts\Prepare-ZydisVendor.ps1

También puedes hacer vendor desde un árbol fuente local ya descargado:```powershell powershell -ExecutionPolicy Bypass -File .\scripts\Prepare-ZydisVendor.ps1 ` -SourcePath 'C:\path\to\zydis'

## Compilación

La ruta recomendada es una Visual Studio Developer PowerShell o un Developer Command Prompt.

El `decomp.dll` compilado ahora incluye una versión de archivo de Windows tomada de `version.txt`.

### Compilación normal```powershell
powershell -ExecutionPolicy Bypass -File .\scripts\Build.ps1 -Reconfigure

Pruebas de regresión```powershell

cmake --build build --config Debug ctest --test-dir build -C Debug --output-on-failure cmake --build build --config Release ctest --test-dir build -C Release --output-on-failure

`decomp_snapshot_tests` cubre los contratos de analizador/protocolo/verificador para argumentos de pila recuperados, entradas ABI SIMD/FP, supresión de vector zero-idiom, preferencia de inducción de bucle, metadatos de switch, metadatos de llamada virtual, hechos de ofuscación estilo OLLVM, política /deobf:off, resúmenes de API conocidos, selección de hechos de prompt y comprobaciones de fundamentación del verificador.

### Compilación heredada dbgeng```powershell
powershell -ExecutionPolicy Bypass -File .\scripts\Build-Legacy.ps1 -Reconfigure

Compilación de lanzamiento con versión de archivo DLL autoincrementada```powershell

powershell -ExecutionPolicy Bypass -File .\scripts\Invoke-ReleaseBuild.ps1

Este script incrementa el último componente en `version.txt` en `1`, fuerza una reconfiguración y luego compila la DLL en Release. Por ejemplo, `1.0.0.7` se convierte en `1.0.0.8`.

### Opciones comunes

- `-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'`

### Ejemplo con prioridad del proveedor```powershell
powershell -ExecutionPolicy Bypass -File .\scripts\Build.ps1 `
    -Configuration Release `
    -ZydisSource Vendor `
    -Reconfigure `
    -Verbose

Ejemplo explícito de inclusión y biblioteca```powershell

powershell -ExecutionPolicy Bypass -File .\scripts\Build.ps1 -Configuration Release -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' -Reconfigure

El script de compilación intenta automáticamente localizar:

- `cmake.exe` desde PATH, CMake independiente o CMake incluido con Visual Studio
- `third_party\dbgeng` bajo la raíz del proyecto
- `DEBUGGERS_ROOT` desde variables de entorno o ubicaciones comunes de Windows Kits

La selección de la fuente de Zydis funciona así:

- `Auto`: prefiere `third_party\zydis`, de lo contrario descarga `Zydis` durante la configuración
- `Vendor`: requiere un árbol usable de `third_party\zydis` o la ruta proporcionada por `-ZydisVendorDir`
- `Fetch`: ignora el árbol del proveedor y siempre permite que CMake descargue `Zydis`

`DEBUGGERS_ROOT` puede apuntar a una raíz del depurador que use uno de estos diseños:

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

Si su instalación no coincide con esos diseños, pase las rutas de CMake directamente:```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

Compatibilidad con dbgeng heredado

Si tu dbgeng.h es demasiado antiguo y la compilación falla en GetSymbolEntryOffsetRegions o GetSymbolEntryString, usa Build-Legacy.ps1 o pasa la opción de CMake manualmente.

Con DECOMP_USE_SYMBOL_ENTRY_APIS=OFF, la extensión recurre a:

GetFunctionEntryByOffset para recuperación de rangos basada en unwind x64
GetNameByOffset más desensamblado heurístico si faltan metadatos de unwind

Uso de PDB

La extensión consume automáticamente los símbolos e información de tipos que WinDbg ya ha cargado para los módulos objetivo.

Hay dos niveles prácticos de enriquecimiento de PDB:

hechos tipados a nivel de módulo: nombre de función, prototipo, tipo de retorno, nombres de símbolos globales, desplazamientos de campos, nombres de constantes de enumeración y pistas de línea de origen
hechos a nivel de ámbito: nombres/tipos de parámetros y locales del ámbito activo del depurador cuando la función objetivo coincide con el ámbito actual o cuando la extensión puede cambiar al ámbito de entrada de la función

Cómo afecta esto a la generación de pseudocódigo:

los argumentos de registro recuperados pueden renombrarse de nombres heurísticos como arg1 a nombres de PDB como ctx
las variables locales de pila pueden mejorarse de nombres de ranura genéricos a nombres y tipos de ámbito local cuando estén disponibles
los accesos a memoria basados en punteros pueden obtener pistas de campo como ctx->State
las comparaciones tipo enum pueden obtener nombres simbólicos como state == StateRunning
los resúmenes de llamados directos pueden reutilizar prototipos y tipos de retorno derivados de PDB

Limitaciones importantes:

las PDB públicas pueden proporcionar nombres de función y algunos datos de tipo, pero a menudo no incluyen locales de ámbito
las compilaciones optimizadas pueden hacer que los valores y ubicaciones de ámbito local sean incompletos o ambiguos
la extensión trata los datos de PDB como pistas semánticas, no como permiso para anular el flujo de control que contradice el desensamblado

El comportamiento actual es automático. No hay un interruptor de configuración separado para el uso de PDB; la calidad depende de lo que WinDbg ya ha cargado y de si el ámbito actual puede coincidir con la función objetivo.

Configuración

Coloca decomp.llm.json junto a decomp.dll.

Este archivo no es solo para configuraciones de LLM de red.

provider, endpoint, model, presupuestos de tokens y configuración de fragmentación afectan la ruta de LLM.
display_language afecta el lenguaje natural utilizado en resúmenes e incertidumbres.
syntax_highlighting afecta el renderizado de pseudocódigo en WinDbg cuando la salida compatible con DML está disponible.
display_language y syntax_highlighting también se utilizan para la salida de /view:analyzer y mock-provider.

Ejemplo:```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" } }

Ejemplo de suscripción a 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"
}

Para provider: "chatgpt", endpoint es opcional y por defecto es https://chatgpt.com/backend-api/codex/responses. Una URL base como https://chatgpt.com/backend-api/codex también es aceptada y normalizada a /responses. La extensión lee tokens.access_token y tokens.refresh_token del archivo de autenticación configurado, renueva los tokens JWT de acceso caducados a través de OAuth de OpenAI, y escribe el conjunto de tokens renovados de vuelta a ese archivo. El archivo de autenticación predeterminado es %USERPROFILE%\.codex\auth.json, por lo que un inicio de sesión de Codex CLI ChatGPT puede reutilizarse directamente. La extensión no abre un navegador ni inicia un flujo de inicio de sesión OAuth desde dentro de WinDbg; si el archivo de autenticación falta, es inválido o ya no se puede renovar, ejecute codex login fuera de WinDbg y vuelva a intentar !decomp. Para pruebas únicas, use access_token o en lugar de un archivo de autenticación. , , y están reservados para proveedores compatibles con API key de OpenAI y son ignorados por el proveedor ChatGPT.

Claves admitidas:

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

Claves admitidas de display_language:

mode
tag
name

display_language.mode acepta:

auto
fixed

Claves admitidas de 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

Cómo funcionan los valores de color de syntax_highlighting:

Estos valores son nombres de ranuras de color DML de WinDbg, no nombres de color RGB fijos o CSS.
La extensión los pasa a WinDbg DML como <col fg="...">.
WinDbg resuelve cada nombre de ranura según su tema actual y la configuración de color de la ventana de comandos.
Debido a esto, verbfg, warnfg, emphfg, srcid y nombres similares no se asignan a un color universal en todas las máquinas.
Actualmente no hay configuración en la extensión para valores RGB arbitrarios como #FF8800. El color efectivo proviene de WinDbg, no de decomp.llm.json.

Consecuencia práctica:

Si un color de símbolo se ve demasiado oscuro en un tema oscuro, la misma ranura puede verse aceptable en otra máquina o en otro tema de WinDbg.
Si dos ranuras se ven casi idénticas en su tema actual, cambie los nombres de las ranuras en syntax_highlighting en lugar de asumir que la extensión ignora su configuración.
Si necesita un color final realmente diferente, cambie el tema de WinDbg o la configuración de color de la ventana de comandos para que la ranura misma se resuelva de manera diferente.

Cuándo el resaltado es visible:

La extensión emite pseudocódigo con color DML cuando WinDbg informa que las devoluciones de llamada de salida actuales son compatibles con DML.
Si la ruta de salida actual del depurador no es compatible con DML, la extensión vuelve automáticamente al pseudocódigo de texto plano.
La salida /view:json no se renderiza con DML. En su lugar, lleva pseudo_c_tokens para que herramientas externas puedan aplicar su propio resaltado de sintaxis.

Ranuras DML de primer plano comunes:

wfg Texto de primer plano predeterminado de la ventana.
normfg Texto normal de la ventana de comandos.
emphfg Texto enfatizado. Microsoft lo documenta como azul claro por defecto, pero la apariencia exacta aún depende del tema.
warnfg Texto de advertencia.
errfg Texto de error.
verbfg Texto detallado.
changed Datos modificados. Microsoft lo documenta como rojo por defecto.

Ranuras DML de primer plano orientadas a código fuente:

srcnum Constantes numéricas.
srcchar Constantes de caracter.
srcstr Constantes de cadena.
srcid Identificadores.
srckw Palabras clave.
srcpair Pares de llaves o símbolos coincidentes.
srccmnt Comentarios.
srcdrct Directivas.
srcspid Identificadores especiales.
srcannot Anotaciones de código fuente o elementos similares.

Ejemplos:

verbfg significa "ranura de primer plano detallada", no "un azul con nombre específico".
warnfg significa "ranura de primer plano de advertencia", no "siempre amarillo o naranja".
function_name_color: "srcid" significa "renderizar nombres de funciones usando la ranura de identificadores de WinDbg".

Si está ajustando colores en un tema oscuro:

Comience con function_name_color: "emphfg" o function_name_color: "verbfg" si los nombres de funciones se ven demasiado tenues con srcid.
Use identifier_color: "normfg" o identifier_color: "wfg" para símbolos generales que deben permanecer legibles pero sin dominar las palabras clave.
Mantenga comment_color: "subfg" si desea que los comentarios se retiren sin desaparecer por completo.

Referencia oficial:

Comportamiento de las ranuras de color DML y ejemplos: Customizing Debugger Output Using DML
Clases de mensajes de la ventana de comandos como normal, advertencia, error y detallado: .printf (WinDbg)

El archivo incluido decomp.llm.json.example contiene solo configuraciones válidas de nivel superior que la extensión realmente lee.

Ejemplos de referencia:

Siga el idioma de la interfaz de PC:```json { "display_language": { "mode": "auto" } }

Para forzar el inglés:```json
{
  "display_language": {
    "mode": "fixed",
    "tag": "en-US",
    "name": "English"
  }
}

Forzar coreano:```json { "display_language": { "mode": "fixed", "tag": "ko-KR", "name": "Korean" } }

Preselección de resaltado de sintaxis oscura:```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"
  }
}

Preset de resaltado de sintaxis claro:```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" } }

Ejemplo de detalles de la respuesta `/view:json`:

- La respuesta JSON incluye `pseudo_c` y `pseudo_c_tokens`.
- `pseudo_c_tokens` es un flujo de tokens determinista adecuado para el resaltado de sintaxis externo.
- La solicitud serializada incluye `preferred_natural_language_tag` y `preferred_natural_language_name`, que reflejan el idioma de visualización resuelto después de aplicar `display_language.mode`.
- Los hechos del analizador ahora incluyen campos de calidad P0:
  `ir_values`, `block_value_states`, `control_flow` y `abi`.
- `ir_values` expone identificadores de valor tipo SSA, sitios de definición, destinos, expresiones canónicas, enlaces de uso, banderas de constante/copia e indicios de definiciones muertas.
- `block_value_states` expone, por bloque básico, las definiciones alcanzables live-in/live-out, valores canónicos, clase de almacenamiento, estado de convergencia y confianza.
- `stack_pointer` expone deltas de pila por instrucción, alias relativos al marco, base/desplazamientos sin procesar y confianza.
- `control_flow` expone candidatos de región estructurada como `natural_loop`, `if_else_candidate` y `switch_candidate` con evidencia de bloques, metadatos de inducción de bucle, metadatos de tabla de salto/predeterminado/rango, signo, expresiones de índice y confianza.
- `abi` expone suposiciones de espacio sombra x64 de Microsoft, evidencia de ranura de inicio, reconocimiento de marco/prólogo/epílogo, evidencia de llamadas sin retorno, candidatos de llamada final, candidatos de thunk, candidatos de envoltorio de importación y argumentos de llamada recuperados de registros y almacenes de pila.
- Los hechos del analizador ahora también incluyen campos semánticos P1:
  `type_hints`, `idioms` y `callee_summaries`.
- `type_hints` expone evidencia de puntero, local, desplazamiento de campo, tipo arreglo, tipo enumeración, tipo bandera de bits y candidato de vtable con origen y confianza. Cuando hay datos PDB disponibles, los parámetros/locales con ámbito, las sugerencias de campo y las constantes de enumeración también se promueven a este flujo unificado de sugerencias de tipo.
- `idioms` expone reemplazos de nivel superior para llamadas a funciones auxiliares reconocidas y patrones de compilador como copia/relleno de memoria, copia de cadenas, comprobaciones de cookies de seguridad, sondas de pila, asistentes de asignación/liberación, inicializadores agregados y cargas de global/importación relativas a RIP.
- `callee_summaries` expone, para llamadas directas e indirectas, tipo de retorno, modelo de parámetros, efectos secundarios, efectos de memoria, propiedad, origen y sugerencias de confianza; los destinos de llamada enriquecidos con símbolos/tipos reemplazan los resúmenes heurísticos iniciales cuando WinDbg puede resolverlos, y los candidatos de llamada virtual incluyen expresiones de destino más desplazamientos de vtable cuando se recuperan.
- Los resúmenes de API conocidas de Win32/NT/Rtl describen comportamiento de copia/relleno/cero de memoria, asignación, liberación, estado y error cuando los nombres de símbolos están disponibles.
- Los hechos de aviso incluyen `analyzer_skeleton` y `graph_summary` para que el modelo refine un borrador basado en evidencia en lugar de comenzar desde una página en blanco.
- `graph_summary` proporciona bloque de entrada, regiones de flujo de control, condiciones normalizadas y bloques representativos de alta señal con una política de truncamiento explícita. La selección de hechos de aviso ahora clasifica las entradas de alta señal y utiliza muestreo disperso para mantener representativos los conjuntos de hechos grandes.
- `evidence_graph` expone nodos de hechos de alta señal y aristas de procedencia para que los valores IR, estados de valor de bloque, accesos a memoria, destinos de llamada, sugerencias de tipo, sugerencias PDB y comportamiento observado puedan rastrearse hasta la evidencia de instrucción y bloque.
- `obfuscation`, `semantic_control_flow` y `deobfuscation_readiness` exponen hechos de recuperación de estilo OLLVM y si la guía de reescritura de desofuscación está habilitada para el comando actual.
- La respuesta del verificador incluye `warnings` heredados más entradas `issues` estructuradas. Cada problema lleva `severity`, `code`, `message` y `evidence` opcional para que las herramientas puedan filtrar errores como `branch.true_target_not_successor` por separado de advertencias de menor riesgo.
- Las comprobaciones del verificador ahora comparan los destinos verdadero/falso de rama normalizados con los sucesores de CFG, comparan la densidad de rama del pseudocódigo con las ramas condicionales recuperadas, cotejan los resúmenes de llamada directa con los efectos de llamada del pseudocódigo, validan la conexión a tierra de nodos/aristas del grafo de evidencia y verifican las referencias de estado de valor de bloque de vuelta a los bloques recuperados y valores IR.
- La salida normal y de explicación puede incluir una sección concisa de `suggested fixes`. Estos son comandos `/fix:*` conservadores derivados de problemas del verificador, oportunidades de renombrado respaldadas por PDB o puntos calientes de memoria observados repetidamente. La salida compatible con DML muestra las sugerencias aplicables de inmediato como enlaces de re-ejecución con clic para el mismo destino; las sugerencias de tipo de campo con marcador de posición permanecen en texto plano hasta que se reemplace `TYPE`.
- En modo LLM, la extensión alimenta automáticamente los problemas del verificador en un aviso de reintento. El reintento se conserva cuando preserva o mejora la calidad del verificador; de lo contrario, se retiene la respuesta original con una nota de incertidumbre añadida.
- `session_policy` y `observed_behavior` exponen contexto específico de WinDbg como política en vivo/volcado/núcleo/TTD, muestras de argumentos de registro del marco actual, puntos calientes de memoria y consultas de seguimiento sugeridas.
- La solicitud serializada ahora también incluye un objeto `pdb` cuando hay datos de símbolos/tipos disponibles.
- `pdb.availability` informa el nivel de enriquecimiento como `none`, `symbols`, `typed` o `scoped`.
- `pdb.params`, `pdb.locals`, `pdb.field_hints`, `pdb.enum_hints` y `pdb.source_locations` están pensados como sugerencias semánticas legibles por máquina para herramientas externas o análisis fuera de línea.

Anulaciones de entorno opcionales:

- `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`
  Fragmentos de nombres de función separados por comas o punto y coma tratados como destinos sin retorno durante el desensamblado de respaldo, recuperación de sucesores de CFG, hechos ABI y comprobaciones de verificación. Ejemplo: `DECOMP_NORETURN_OVERRIDES=MyAbort;PanicAndExit`.

Nota de prioridad de calidad:

- La extensión ahora admite análisis fragmentado de múltiples pasadas para funciones grandes.
- El analizador envía hechos de valor IR, estados de valor de bloque, regiones de flujo de control, hechos de grafo de evidencia y evidencia ABI/sin retorno x64 al LLM antes del refinamiento, por lo que `/view:analyzer`, `/view:json` y el modo LLM normal comparten la misma base de evidencia P0.
- El verificador realiza comprobaciones cruzadas de bucle, switch, sin retorno, destinos de rama, comportamiento de retorno, efectos de llamada a callee, conexión a tierra del grafo de evidencia, consistencia de estado de valor de bloque, cobertura de evidencia y afirmaciones de identificador sospechoso contra la evidencia del analizador. Reduce la confianza cuando la prosa segura supera los hechos recuperados y etiqueta cada problema con un par estable de gravedad/código.
- Cuando la retroalimentación del verificador encuentra errores de esquema, conflictos de hechos o confianza ajustada muy baja, la ruta LLM realiza un reintento automático con los problemas del verificador añadidos al aviso.
- Un buen punto de partida para modelos en la nube es `max_completion_tokens=12000`, `chunk_completion_tokens=6000` y `merge_completion_tokens=12000`, con `force_chunked=false` y disparadores de fragmento alrededor de `900 instrucciones` o `36 bloques`.
- Mantén `force_chunked=true` solo para pruebas de esfuerzo de canalización de fragmentos. La descompilación centrada en calidad de funciones aplanadas o con muchos despachadores generalmente necesita un solo aviso hasta que la función sea lo suficientemente grande como para exceder los disparadores de fragmento configurados.
- Mantén `timeout_ms` alto para modelos en la nube. `120000` es un punto de partida más seguro que `15000`.
- Si la calidad sigue siendo baja en funciones enormes, aumenta `chunk_count_limit` antes de reducir `/limit:N`.
- Si no hay un endpoint configurado, la extensión recurre al proveedor simulado determinista.
- Incluso cuando la extensión está usando `/view:analyzer` o el proveedor simulado, `display_language` y `syntax_highlighting` aún afectan lo que ve el usuario.

## Prueba de Humo de WinDbg

1. Compila con `Build.ps1` o `Build-Legacy.ps1`.
2. Coloca `decomp.llm.json` junto al `decomp.dll` compilado.
3. Inicia WinDbg. Las variables de entorno son solo anulaciones opcionales.
4. Carga la extensión.
5. Valida el modo solo analizador antes de habilitar la ruta LLM.```text
.load C:\path\to\decomp.dll
!decomp /view:analyzer ntdll!RtlAllocateHeap
!decomp /view:facts kernel32!Sleep

Luego valida el modo LLM:```text !decomp ntdll!RtlAllocateHeap !decomp /view:json ntdll!RtlAllocateHeap !decomp 0x7ffb`12345678

Verificaciones esperadas:

- `target`, `entry` y `module` deben resolverse de manera consistente
- `regions` debe ser distinto de cero para funciones normales
- `/view:analyzer` debe seguir imprimiendo la confianza del analizador y el stub de pseudocódigo
- El modo LLM debe llenar `summary`, `pseudo_c`, `pseudo_c_tokens` y `verified`
- La salida de `/view:json` debe incluir `preferred_natural_language_tag` y `preferred_natural_language_name` en la solicitud serializada
- cuando se carguen PDBs privados o enriquecidos, `/view:json` también debe incluir `pdb.prototype`, `pdb.params`, y posiblemente `pdb.locals`
- para estructuras y enumeraciones tipadas, `/view:json` puede incluir `pdb.field_hints` y `pdb.enum_hints`

## Ejemplo de suscripción a 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"

Si el archivo de autenticación contiene un token de actualización (refresh token), la extensión renueva el token de acceso caducado antes de enviar la solicitud. Se puede usar DECOMP_LLM_CHATGPT_ACCESS_TOKEN como token bearer temporal, pero la ruta del archivo de autenticación es mejor para sesiones normales de WinDbg porque sobrevive a la caducidad del token. La extensión nunca abre un navegador durante !decomp; ejecuta codex login fuera de WinDbg cuando se necesite un inicio de sesión interactivo de ChatGPT.

Ejemplos de Endpoints LLM Locales

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 o servidor local compatible con 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"

Más Populares

windbg-decompile-ext