Skip to content
KitploitKITPLOIT
उपकरणब्लॉग
जमा करें
उपकरणब्लॉग
जमा करें

हैकिंग, पेनटेस्ट और साइबर सुरक्षा उपकरण आपके सुरक्षा शस्त्रागार के लिए!

Kitploit हैकिंग, साइबर सुरक्षा और पेंटेस्टिंग टूल्स की एक निर्देशिका है। कमजोरियों को खोजने, सिस्टम का विश्लेषण करने, परीक्षण को स्वचालित करने और अपनी सुरक्षा को मजबूत करने के लिए नवीनतम प्रोजेक्ट अपडेट खोजें।

··फ़ीड·संपर्क·गोपनीयता·© 2026 Kitploit

टूल निर्देशिका

श्रेणियाँ

सभी श्रेणियाँ देखें
Loading categories
windbg-decompile-ext — WinDbg x64 एक्सटेंशन जो लाइव फ़ंक्शंस को डिसअसेंबल करता है और सत्यापित स्यूडोकोड उत्पन्न करने के लिए LLM का उपयोग करता है। | Kitploit
उपकरण/GitHubGitHub/kernullist/windbg-decompile-ext
स्थैतिक विश्लेषणगतिशील विश्लेषण (सैंडबॉक्सिंग)कोड विश्लेषणरिवर्स इंजीनियरिंगडीबगर्समालवेयर विश्लेषणबाइनरी विश्लेषणलर्निंग और शिक्षाAI-सहायित रिवर्सिंगफर्मवेयर विश्लेषणबाइनरी शोषण
112112 महीने पहलेKitploit द्वारा समीक्षित

सबसे लोकप्रिय

सभी देखें →

हमारे समुदाय द्वारा सबसे अधिक उपयोग किए जाने वाले उपकरण खोजें।

सभी उपकरण खोजें

हमारे उपकरणों का संग्रह ब्राउज़ करें

सभी उपकरण देखें →
साझा करें
GitHub
kernullist/windbg-decompile-ext

windbg-decompile-ext

WinDbg x64 एक्सटेंशन जो लाइव फ़ंक्शंस को डिसअसेंबल करता है और सत्यापित स्यूडोकोड उत्पन्न करने के लिए LLM का उपयोग करता है।

रिपॉजिटरी देखें

एलएलएम के माध्यम से Windbg डीकंपाइल एक्सटेंशन

native decompile viewer

screenshot

यह प्रोजेक्ट एक Windows x64 WinDbg एक्सटेंशन स्केलेटन है जो नाम या पते से फ़ंक्शन का पता लगाता है, एक नियतात्मक नियंत्रण-प्रवाह दृश्य का पुनर्निर्माण करता है, और स्यूडोकोड उत्पन्न करने के लिए सीधे एक्सटेंशन से LLM से पूछता है।

लेआउट

  • src/extension: WinDbg एक्सटेंशन DLL और !decomp कमांड।
  • src/shared: JSON, विश्लेषक, प्रोटोकॉल, और वेरिफ़ायर कोड जो एक्सटेंशन द्वारा साझा किया जाता है।
  • scripts: बिल्ड और वेंडर-कॉपी सहायक स्क्रिप्ट।
  • third_party/dbgeng: वैकल्पिक वेंडर की गई dbgeng.h और dbgeng.lib प्रति।
  • third_party/zydis: वेंडर की गई स्थिर Zydis स्रोत ट्री जो उपस्थित होने पर डिफ़ॉल्ट रूप से उपयोग होती है।

वर्तमान दायरा

  • केवल x64 मान्यताएँ
  • DbgEng के माध्यम से लाइव-मेमोरी विश्लेषण
  • स्थिर mnemonic/operand पुनर्प्राप्ति के लिए Zydis-समर्थित संरचित डिसअसेंबली
  • प्रतीक-क्षेत्र, अनवाइंड, और अनुमानित फ़ंक्शन-सीमा पुनर्प्राप्ति
  • इनकमिंग रजिस्टर तर्कों, स्टैक-स्लॉट लोकल्स, मर्ज उम्मीदवारों, और सामान्यीकृत शाखा स्थितियों के लिए SSA-lite शैली पुनर्प्राप्ति
  • निम्न-स्तरीय IR मान तथ्य जिनमें def-use संकेत, कैनोनिकलाइज़्ड कॉपी/कॉन्स्टेंट अभिव्यक्तियाँ, और मृत-परिभाषा चिह्नक शामिल हैं
  • ब्लॉक-स्तरीय मान स्थिति तथ्य जो रजिस्टरों और स्टैक लोकल्स में अभिसारित live-in/live-out पहुँच परिभाषाओं के लिए होते हैं
  • प्राकृतिक लूप, if/else उम्मीदवार, switch उम्मीदवार, लूप इंडक्शन मेटाडेटा, और switch रेंज/डिफ़ॉल्ट मेटाडेटा के लिए dominator-समर्थित नियंत्रण-प्रवाह क्षेत्र तथ्य
  • shadow/home स्लॉट्स, स्टैक पॉइंटर डेल्टा, prolog/epilog पहचान, no-return कॉल, टेल कॉल, थंक्स, इम्पोर्ट-रैपर उम्मीदवार, और पुनर्प्राप्त रजिस्टर/स्टैक कॉल तर्कों के लिए x64 ABI तथ्य
  • xmm0 से xmm3 तक के लिए SIMD/FP-जागरूक Microsoft x64 तर्क पुनर्प्राप्ति, जिसमें गलत इनकमिंग तर्कों से बचने हेतु वेक्टर शून्य-मुहावरा गार्ड शामिल हैं
  • पॉइंटर-जैसे मान, स्टैक लोकल्स, फ़ील्ड ऑफ़सेट, स्केल्ड-इंडेक्स ऐरे, एनम-जैसी तुलना, बिटफ़्लैग परीक्षण, और vtable उम्मीदवारों के लिए प्रकार पुनर्प्राप्ति संकेत
  • मेमोरी/स्ट्रिंग हेल्पर्स, सुरक्षा कुकीज़, स्टैक प्रोब्स, आवंटक, एग्रीगेट इनिशियलाइज़र, और RIP-सापेक्ष ग्लोबल/इम्पोर्ट लोड के लिए मुहावरा और लाइब्रेरी-पैटर्न तथ्य
  • प्रत्यक्ष कॉल, रजिस्टर/मेमोरी अप्रत्यक्ष कॉल, वर्चुअल-कॉल/vtable-ऑफ़सेट उम्मीदवार, रिटर्न प्रकार, पैरामीटर मॉडल, साइड इफेक्ट्स, मेमोरी प्रभाव, स्वामित्व संकेत, और विश्वास स्तर के लिए कॉल-टार्गेट तथ्य
  • नियंत्रण-प्रवाह फ़्लैटनिंग डिस्पैचर्स, पुनर्प्राप्त अर्थपूर्ण किनारों, अपारदर्शी-प्रेडिकेट डेड किनारों, और स्केलर इंस्ट्रक्शन-प्रतिस्थापन मुहावरों के लिए OLLVM-शैली अस्पष्टता तथ्य
  • डीऑबफस्केशन तत्परता तथ्य और /deobf:on|off नियंत्रण कि क्या पुनर्प्राप्त अस्पष्टता तथ्य pseudo-C पुनर्लेखन का मार्गदर्शन कर सकते हैं
  • साक्ष्य ग्राफ़ तथ्य जो उच्च-संकेत विश्लेषक, PDB, और अवलोकित व्यवहार तथ्यों को निर्देश/ब्लॉक आधार से जोड़ते हैं
  • विश्लेषक-जनित स्यूडोकोड स्केलेटन के साथ refine-first प्रॉम्प्टिंग, CFG क्षेत्रों, स्थितियों, और महत्वपूर्ण ब्लॉकों के लिए ग्राफ़-जागरूक सारांश, रैंक किए गए उच्च-संकेत तथ्य चयन, और बड़े तथ्य सेटों के लिए स्प्रेड सैंपलिंग

WinDbg उपयोग

बिल्ड आउटपुट से एक्सटेंशन लोड करें, फिर किसी सिंबल या पते के विरुद्ध !decomp चलाएँ:```text .load C:\path\to\decomp.dll !decomp /doctor !decomp module!FunctionName !decomp 0x7ffb`12345678

root@kitploit:~
जब सेटअप गलत लगे या LLM प्रदाता सक्षम करने से पहले `/doctor` का उपयोग करें:```text
!decomp /doctor
!decomp /doctor:net
  • /doctor को किसी target की आवश्यकता नहीं होती और यह provider को कॉल नहीं करता। यह config path/load status, provider/model/endpoint सारांश, secrets के बिना auth उपस्थिति, timeout/token/chunking सेटिंग्स, DML समर्थन, session class/qualifier, processor प्रकार, और PDB caveats की रिपोर्ट करता है।
  • /doctor:net को एक स्पष्ट network-check अनुरोध के रूप में स्वीकार किया जाता है, लेकिन वर्तमान में यह रिपोर्ट करता है कि provider ping छोड़ दिया गया है। एक्सटेंशन doctor मोड से network probe नहीं करता है।
  • API keys, bearer tokens, refresh tokens, और URL query strings जैसे गोपनीय मान प्रिंट नहीं किए जाते।

Targets सार्वजनिक/निजी symbols, exported function names, या addresses हो सकते हैं। यदि target किसी function के अंदर किसी address पर resolve होता है, तो एक्सटेंशन symbols, unwind data, और control-flow heuristics से containing function range को पुनर्प्राप्त करने का प्रयास करता है। रिक्त स्थान वाले targets के चारों ओर quotes लगाएं:```text !decomp "my module!Function With Spaces"

root@kitploit:~
सामान्य कमांड पथ स्थानीय विश्लेषण करता है, विश्लेषक तथ्यों का निर्माण करता है, वैकल्पिक रूप से कॉन्फ़िगर किए गए LLM एंडपॉइंट को कॉल करता है, पुनर्प्राप्त साक्ष्य के विरुद्ध प्रतिक्रिया को सत्यापित करता है, और pseudo-C के साथ आत्मविश्वास, चेतावनियाँ और अनिश्चितता नोट्स प्रिंट करता है:```text
!decomp ntdll!RtlAllocateHeap
!decomp kernel32!Sleep
!decomp game.exe!CheckIntegrity

सामान्य, 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

root@kitploit:~
- `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 लोकल स्टेजेस प्रिंट करता है जैसे target resolution, function range recovery, byte reads, disassembly, analyzer fact construction, PDB/session enrichment, pseudo-code tokenization, और verifier results।
  • LLM मोड में, /verbose प्रॉम्प्ट साइज़, request token budgets, HTTP connection/send/receive स्टेजेस, response chunk sizes, finish reason, extracted model JSON preview, retry attempts, और verifier-feedback retry decisions भी प्रिंट करता है।
  • API key प्रिंट नहीं होती। Request/response लॉग पूरे हेडर या पूरे प्रॉम्प्ट बॉडी के बजाय साइज़ और छोटे प्रीव्यू दिखाते हैं।
  • /verbose कॉम्पैक्ट प्रोग्रेस स्ट्रीम को पूरी ट्रेस से बदल देता है। इसका उपयोग तब करें जब कॉम्पैक्ट प्रोग्रेस लाइनें यह जानने के लिए पर्याप्त न हों कि समय कहाँ जा रहा है।
  • लंबे समय तक चलने वाले !decomp कमांड के दौरान, WinDbg में Ctrl+Break दबाकर रद्द करने का अनुरोध करें। एक्सटेंशन लोकल एनालिसिस स्टेजेस के बीच और LLM वर्कर की प्रतीक्षा के दौरान इंटरप्ट्स की जाँच करता है, फिर सक्रिय सिंक्रोनस HTTP I/O को रुकने के लिए कहता है।

लिगेसी aliases जैसे /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

root@kitploit:~
- `/view:window` लक्ष्य के लिए सामान्य `!decomp` परिणाम पथ चलाता है और पूर्ण रेंडर किया गया परिणाम एक अलग व्यूअर में खोलता है।
- व्यूअर कंसोल पथ के समान प्रतिक्रिया रेंडरर का उपयोग करता है, फिर एक नेटिव Win32 मॉडल रहित टूल विंडो खोलता है जो डीबगर विंडो के स्वामित्व में होती है, जब एक मिल सकती है।
- डीबगर आउटपुट नेटिव व्यूअर विंडो हैंडल की रिपोर्ट करता है। यदि व्यूअर विंडो नहीं बनाई जा सकती, कमांड एक चेतावनी प्रिंट करता है और सामान्य कंसोल परिणाम पर वापस आ जाता है।
- केवल DML लिंक व्यूअर में उनके कमांड स्ट्रिंग्स के साथ टेक्स्ट लेबल के रूप में प्रस्तुत किए जाते हैं। जब RichEdit उपलब्ध होता है, विंडो GitHub-शैली RTF लेआउट का उपयोग करती है जिसमें सेक्शन हेडिंग, मेटाडेटा स्टाइलिंग और pseudo-code हाइलाइटिंग होती है; अन्यथा यह सादे टेक्स्ट पर वापस आ जाती है।
- जब वर्तमान सत्र में पिछले कैश किए गए परिणाम होते हैं, तो व्यूअर बाईं ओर एक इतिहास सूची दिखाता है ताकि आप विश्लेषण को दोबारा चलाए बिना वर्तमान आउटपुट और पहले के डीकंपाइलेशन परिणामों के बीच स्विच कर सकें।
- `/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

root@kitploit:~
- `/deobf:on` डिफ़ॉल्ट है। विश्लेषक अभी भी कच्चे तथ्य उत्सर्जित करता है, लेकिन उच्च-विश्वास OLLVM-शैली डिस्पैचर पुनर्प्राप्ति, अपारदर्शी डेड-एज प्रमाण, प्रतिस्थापन मुहावरे, और सिमेंटिक CFG ओवरले प्रॉम्प्ट तथ्यों, मर्ज नीति, सत्यापनकर्ता संघर्ष नीति, और संरचित छद्म-सी पुनर्प्राप्ति का मार्गदर्शन कर सकते हैं।
- `/deobf:off` `obfuscation`, `semantic_control_flow`, और `deobfuscation_readiness` तथ्यों को दृश्यमान रखता है, लेकिन पुनर्लेखन सुरक्षित क्रियाओं को अक्षम करता है, कच्चे CFG पर नियंत्रण-प्रवाह संरचना बनाए रखता है, और प्रॉम्प्ट/मर्ज/सत्यापनकर्ता पथों को कच्चे अस्पष्ट आकार को संरक्षित रखने के लिए कहता है।
- `/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 पिछले पूर्ण परिणाम को explain अनुभाग के साथ विश्लेषण दोबारा चलाए बिना या LLM को कॉल किए बिना पुनः प्रस्तुत करता है।
  • /last:facts पिछले परिणाम से विश्लेषक facts को विश्लेषण दोबारा चलाए बिना प्रिंट करता है।
  • /last:data पिछले डेटा-मॉडल स्नैपशॉट को विश्लेषण दोबारा चलाए बिना प्रिंट करता है।
  • /last:prompt पिछले prompt डंप को विश्लेषण दोबारा चलाए बिना प्रिंट करता है।
  • /history इन-मेमोरी रिज़ल्ट रिंग बफर की सूची दिखाता है। इंडेक्स 1 सबसे नया परिणाम है।
  • /refresh <target> उस target के लिए persistent artifact replay को बायपास करता है, ताज़ा स्थानीय विश्लेषण और LLM विश्लेषण चलाता है, और सफल LLM-समर्थित परिणाम के बाद सहेजे गए artifact को बदल देता है।
  • /last:N:explain, /last:N:json, /last:N:facts, /last:N:data, और पुराने कैश किए गए परिणाम को history इंडेक्स द्वारा स्थानीय विश्लेषण दोबारा चलाए बिना या LLM को कॉल किए बिना रीप्ले करते हैं।

DML navigation:

  • जब WinDbg रिपोर्ट करता है कि वर्तमान output callback DML-aware है, तो pseudo-code को कॉन्फ़िगर किए गए DML color slots के साथ syntax-highlight किया जाता है।
  • सामान्य आउटपुट में उसी target के लिए क्लिक करने योग्य explain, json, facts, prompt, data-model, और history links के साथ एक actions row शामिल होती है।
  • सामान्य आउटपुट में entry disassembly, entry breakpoint, और last-artifact replay links के साथ एक nav row भी शामिल होती है।
  • Entry addresses, basic blocks, evidence blocks, control-flow regions, type-hint sites, observed memory-hotspot sites, TTD query suggestions, और direct call targets उन स्थानों पर क्लिक करने योग्य links बन जाते हैं जहाँ extension के पास पर्याप्त address जानकारी होती है।
  • Uncertainties और verifier warnings उस सर्वोत्तम पुनर्प्राप्त evidence स्थान से जुड़ी होती हैं जब कारण को branch, loop, switch, no-return call, return instruction, या function entry पर मैप किया जा सकता है।
  • यदि वर्तमान output path DML-aware नहीं है, तो extension स्वचालित रूप से सादे पाठ पर वापस चला जाता है। विश्लेषण परिणाम वही होता है; केवल प्रस्तुति बदलती है।

Session-aware and observed-behavior details:

  • /view:json, /view:facts, /view:prompt, और सामान्य LLM mode में session_policy शामिल होता है।
  • session_policy debug class, qualifier, execution kind, analysis strategy, dump/live/kernel flags, और यह दर्ज करता है कि TTD support लोड दिखता है या नहीं।
  • observed_behavior वर्तमान rip, rsp, return address जब पठनीय हो, Microsoft x64 register argument samples (rcx, rdx, r8, r9), repeated memory-access hotspots, और suggested TTD commands दर्ज करता है।
  • Current-frame argument samples केवल तभी उच्च विश्वास वाले होते हैं जब वर्तमान instruction pointer विश्लेषित function के अंदर हो। अन्यथा उन्हें contextual hints के रूप में रखा जाता है।
  • यदि डिबगर प्रोसेस में ttdext.dll या लोड है, तो extension चुपचाप यह दिखावा करने के बजाय कि trace data पहले ही एकत्र किया जा चुका है, suggested queries जोड़ता है।
root@kitploit:~
- `/fix:noreturn:name` मेल खाने वाले कॉल्स को no-return मानता है फ़ॉलबैक डिसअसेंबली, CFG रिकवरी, ABI तथ्यों, और वेरिफ़ायर जाँच के लिए।
- `/fix:type:expr=TYPE` उच्च-विश्वास वाला उपयोगकर्ता टाइप संकेत जोड़ता है।
- `/fix:field:expr=TYPE` उच्च-विश्वास वाला उपयोगकर्ता फ़ील्ड संकेत जोड़ता है।
- `/fix:rename:old=new` एक rename संकेत जोड़ता है और अंतिम pseudocode पहचानकर्ताओं पर rename लागू करता है।
- `/fix:clear` सभी सत्र-स्थायी सुधार ओवरराइड को साफ़ करता है।

पर्यावरण चर `DECOMP_NORETURN_OVERRIDES` समर्थित बना हुआ है। कमांड-लाइन `/fix:noreturn:` मान वर्तमान WinDbg सत्र के लिए मूल पर्यावरण मान के ऊपर परत (layered) किए जाते हैं।

सुधार स्विच सत्र-स्थायी होते हैं:

- `/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. फ़ंक्शन रेंज, ब्लॉक, कॉल्स, इम्पोर्ट्स, PDB डेटा और सत्र तथ्य उचित दिखते हैं यह पुष्टि करने के लिए `!decomp /view:facts target` से शुरू करें।
2. LLM अनुरोध खर्च करने से पहले chunking, prompt आकार, टाइमआउट जोखिम और प्रतीक गुणवत्ता का अनुमान लगाने के लिए `!decomp /view:plan target` का उपयोग करें।
3. जब prompt आकार, भाषा, या साक्ष्य चयन गलत लगे, तो `!decomp /view:prompt target` का उपयोग करें।
4. पूर्ण सत्यापित pseudo-C परिणाम के लिए `!decomp target` चलाएँ।
5. जब कोई मौजूदा स्थायी आर्टिफैक्ट पुनः चलाया जा रहा हो लेकिन आपको नया विश्लेषण चाहिए, तो `!decomp /refresh target` का उपयोग करें।
6. यदि परिणाम गलत लगे, तो `!decomp /view:explain target` चलाएँ और वेरिफ़ायर चेतावनियों, साक्ष्य कवरेज और सुझाए गए सुधारों का निरीक्षण करें।
7. `/fix:noreturn:`, `/fix:type:`, `/fix:field:`, या `/fix:rename:` जैसे केंद्रित सुधार जोड़ें और उसी target को पुनः चलाएँ।
8. कई हालिया परिणामों की तुलना करते समय `/history` और अनुक्रमित `/last:N:*` पुनर्चालन का उपयोग करें।
9. बग दर्ज करते समय या विभिन्न buildों में व्यवहार की तुलना करते समय `/view:json` या `/last:json` कैप्चर करें।

## विश्लेषक तथ्य सतह

हाल के विश्लेषक तथ्य जानबूझकर `/view:json`, `/view:facts`, `/view:prompt`, और सामान्य LLM मोड के माध्यम से ले जाए जाते हैं। पहले निरीक्षण करने योग्य उच्च-मूल्य वाले फ़ील्ड:

- `stack_pointer` प्रति-निर्देश स्टैक डेल्टा, फ्रेम-सापेक्ष उपनाम (aliases), और आत्मविश्वास (confidence) रिकॉर्ड करता है।
- `call_arguments` कॉल साइटों पर पुनर्प्राप्त रजिस्टर और स्टैक तर्क रिकॉर्ड करता है, जिसमें पास के क्रॉस-ब्लॉक स्टैक स्टोर शामिल हैं जब साक्ष्य पर्याप्त मजबूत हो।
- `pdb.prototype_parameters` संरचित प्रोटोटाइप पैरामीटर नाम, प्रकार, क्रमांक (ordinals), ABI स्थान, और स्रोत आत्मविश्वास रिकॉर्ड करता है।
- `control_flow` में लूप इंडक्शन वेरिएबल, प्रारंभिक मान, चरण (steps), सीमाएँ, दिशा, स्विच टेबल पता, केस लक्ष्य, डिफ़ॉल्ट लक्ष्य, रेंज सीमाएँ, signedness, और पुनर्प्राप्त होने पर इंडेक्स एक्सप्रेशन शामिल होते हैं।
- `callee_summaries` और कॉल-लक्ष्य तथ्यों में प्रत्यक्ष, अप्रत्यक्ष, और वर्चुअल-कॉल/vtable उम्मीदवारों के साथ-साथ ज्ञात Win32/NT/Rtl मेमोरी, आवंटन, रिलीज़, और स्थिति (status) सेमेंटिक्स शामिल हैं।
- `obfuscation` OLLVM-शैली फ़्लैटनिंग डिस्पैचर उम्मीदवारों, स्थिति चर, पुनर्प्राप्त सिमेंटिक किनारों, opaque predicates, और scalar substitution अभिव्यक्तियों को उजागर करता है।
- `semantic_control_flow` पुनर्प्राप्त live/dead किनारों को उजागर करता है जो obfuscation तथ्यों से व्युत्पन्न होते हैं और `/deobf:off` उपयोग करने पर भी निरीक्षण के लिए उपलब्ध रहते हैं।
- `deobfuscation_readiness` `enabled`, सुरक्षित पुनर्लेखन क्रियाएँ, अवरुद्ध धारणाएँ, प्राथमिकता वाले तथ्य पथ, गणनाएँ, और आत्मविश्वास उजागर करता है। जब अक्षम होता है, तो यह नीति निर्णय रिकॉर्ड करता है और deobfuscated नियंत्रण-प्रवाह पुनर्लेखन को अवरुद्ध करता है।
- Prompt तथ्य चयन उच्च-सिग्नल प्रविष्टियों को पहले क्रमबद्ध करता है, फिर स्प्रेड सैंपलिंग के साथ वितरण संरक्षित करता है ताकि बड़े फ़ंक्शन सभी कम-आवृत्ति साक्ष्य न खो दें।

## अनुशंसित dbgeng सेटअप

सबसे तेज़ तरीका है हेडर और इम्पोर्ट लाइब्रेरी को प्रोजेक्ट में vendor करना।

अपेक्षित vendor लेआउट:```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'

root@kitploit:~
### स्पष्ट फ़ाइल पथों से विक्रेता प्रति तैयार करें```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 की आवश्यकता नहीं होती है।

अनुशंसित Zydis सेटअप

रिपॉज़िटरी निम्न में से किसी एक का उपयोग कर सकती है:

  • वेंडर किया गया third_party\zydis स्रोत
  • CMake FetchContent

डिफ़ॉल्ट व्यवहार auto है, जो मौजूद होने पर third_party\zydis को प्राथमिकता देता है और CMake कॉन्फ़िगर के दौरान Zydis प्राप्त करने पर वापस गिर जाता है।

अपेक्षित वेंडर लेआउट:```text third_party\zydis\CMakeLists.txt third_party\zydis\include\Zydis\Zydis.h third_party\zydis\dependencies\zycore\CMakeLists.txt

root@kitploit:~
विक्रेता कॉपी को रीफ्रेश करें या बनाएं:```powershell
powershell -ExecutionPolicy Bypass -File .\scripts\Prepare-ZydisVendor.ps1

आप पहले से डाउनलोड किए गए स्थानीय स्रोत ट्री से भी वेंडर कर सकते हैं:```powershell powershell -ExecutionPolicy Bypass -File .\scripts\Prepare-ZydisVendor.ps1 ` -SourcePath 'C:\path\to\zydis'

root@kitploit:~
## निर्माण

अनुशंसित मार्ग Visual Studio Developer PowerShell या Developer Command Prompt है।

निर्मित `decomp.dll` अब `version.txt` से लिया गया Windows फ़ाइल संस्करण एम्बेड करता है।

### सामान्य निर्माण```powershell
powershell -ExecutionPolicy Bypass -File .\scripts\Build.ps1 -Reconfigure

प्रतिगमन परीक्षण```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

root@kitploit:~
`decomp_snapshot_tests` पुनर्प्राप्त स्टैक तर्कों, SIMD/FP ABI इनपुट, वेक्टर शून्य-इडियम दमन, लूप इंडक्शन वरीयता, स्विच मेटाडेटा, वर्चुअल-कॉल मेटाडेटा, OLLVM-शैली ऑबफस्केशन तथ्यों, `/deobf:off` नीति, ज्ञात API सारांश, प्रॉम्प्ट तथ्य चयन, और सत्यापनकर्ता आधार (verifier grounding) जाँचों के लिए analyzer/protocol/verifier अनुबंधों को कवर करता है।

### लीगेसी dbgeng बिल्ड```powershell
powershell -ExecutionPolicy Bypass -File .\scripts\Build-Legacy.ps1 -Reconfigure

स्वतः बढ़ते DLL फ़ाइल संस्करण के साथ रिलीज़ बिल्ड```powershell

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

root@kitploit:~
यह स्क्रिप्ट `version.txt` में अंतिम घटक को `1` से बढ़ाता है, पुन: कॉन्फ़िगरेशन को बल देता है, और फिर Release DLL बनाता है। उदाहरण के लिए, `1.0.0.7` `1.0.0.8` हो जाता है।

### सामान्य विकल्प

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

### वेंडर-प्रथम उदाहरण```powershell
powershell -ExecutionPolicy Bypass -File .\scripts\Build.ps1 `
    -Configuration Release `
    -ZydisSource Vendor `
    -Reconfigure `
    -Verbose

स्पष्ट include और library उदाहरण```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

root@kitploit:~
बिल्ड स्क्रिप्ट स्वचालित रूप से इन्हें खोजने का प्रयास करती है:

- `cmake.exe` PATH, स्टैंडअलोन CMake, या Visual Studio के साथ बंडल किए गए CMake से
- प्रोजेक्ट रूट के अंतर्गत `third_party\dbgeng`
- पर्यावरण चर या सामान्य Windows Kits स्थानों से `DEBUGGERS_ROOT`

Zydis स्रोत चयन इस प्रकार काम करता है:

- `Auto`: `third_party\zydis` को प्राथमिकता दें, अन्यथा कॉन्फ़िगरेशन के दौरान `Zydis` प्राप्त करें
- `Vendor`: एक उपयोग योग्य `third_party\zydis` ट्री या `-ZydisVendorDir` द्वारा पारित पथ की आवश्यकता होती है
- `Fetch`: वेंडर ट्री को अनदेखा करें और हमेशा CMake को `Zydis` डाउनलोड करने दें

`DEBUGGERS_ROOT` एक डिबगर रूट की ओर इशारा कर सकता है जो इनमें से किसी एक लेआउट का उपयोग करता है:

- `sdk\inc\dbgeng.h` और `sdk\lib\dbgeng.lib`
- `sdk\inc\dbgeng.h` और `sdk\lib\amd64\dbgeng.lib`
- `sdk\inc\dbgeng.h` और `sdk\lib\x64\dbgeng.lib`
- `sdk\inc\dbgeng.h` और `dbgeng.lib`
- `inc\dbgeng.h` और `lib\dbgeng.lib`
- `inc\dbgeng.h` और `lib\amd64\dbgeng.lib`
- `inc\dbgeng.h` और `lib\x64\dbgeng.lib`
- `dbgeng.h` और `dbgeng.lib`

यदि आपका इंस्टॉलेशन उन लेआउट से मेल नहीं खाता है, तो CMake पथ सीधे पास करें:```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

पुरानी dbgeng संगतता

यदि आपका dbgeng.h बहुत पुराना है और GetSymbolEntryOffsetRegions या GetSymbolEntryString पर बिल्ड विफल हो जाता है, तो Build-Legacy.ps1 का उपयोग करें या CMake विकल्प मैन्युअल रूप से पास करें।

DECOMP_USE_SYMBOL_ENTRY_APIS=OFF के साथ, एक्सटेंशन निम्न पर वापस आ जाता है:

  • x64 अनवाइंड-आधारित रेंज पुनर्प्राप्ति के लिए GetFunctionEntryByOffset
  • अनवाइंड मेटाडेटा गायब होने पर GetNameByOffset के साथ-साथ ह्यूरिस्टिक डिसअसेंबली

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-provider आउटपुट के लिए उपयोग किए जाते हैं।

उदाहरण:```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" } }

root@kitploit:~
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 उपयोग होता है। https://chatgpt.com/backend-api/codex जैसा बेस URL भी स्वीकार किया जाता है और /responses में सामान्यीकृत किया जाता है। एक्सटेंशन कॉन्फ़िगर की गई auth फ़ाइल से tokens.access_token और tokens.refresh_token पढ़ता है, OpenAI OAuth के माध्यम से समाप्त (expired) JWT access tokens को रीफ़्रेश करता है, और रीफ़्रेश किए गए token सेट को उसी फ़ाइल में वापस लिखता है। डिफ़ॉल्ट auth फ़ाइल %USERPROFILE%\.codex\auth.json है, इसलिए Codex CLI ChatGPT लॉगिन को सीधे पुनः उपयोग किया जा सकता है। एक्सटेंशन WinDbg के अंदर से ब्राउज़र नहीं खोलता और न ही OAuth लॉगिन प्रवाह शुरू करता है; यदि auth फ़ाइल गायब है, अमान्य है, या अब रीफ़्रेश करने योग्य नहीं है, तो WinDbg के बाहर codex login चलाएँ और !decomp को पुनः प्रयास करें। एक बार के परीक्षणों के लिए, auth फ़ाइल के बजाय access_token या का उपयोग करें। , , , और OpenAI-संगत API-key प्रदाताओं के लिए आरक्षित हैं और 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 रंग मान कैसे काम करते हैं:

  • ये मान WinDbg DML रंग स्लॉट नाम हैं, निश्चित RGB या CSS रंग नाम नहीं।
  • एक्सटेंशन इन्हें <col fg="..."> के रूप में WinDbg DML को भेजता है।
  • WinDbg प्रत्येक स्लॉट नाम को अपनी वर्तमान थीम और कमांड विंडो रंग सेटिंग्स के विरुद्ध हल करता है।
  • इस कारण, verbfg, warnfg, emphfg, srcid, और समान नाम हर मशीन पर एक सार्वभौमिक रंग से मेल नहीं खाते।
  • वर्तमान में #FF8800 जैसे मनमाने RGB मानों के लिए कोई एक्सटेंशन-पक्षीय कॉन्फ़िगरेशन नहीं है। प्रभावी रंग WinDbg से आता है, न कि decomp.llm.json से।

व्यावहारिक परिणाम:

  • यदि किसी प्रतीक का रंग एक डार्क थीम पर बहुत गहरा दिखता है, तो वही स्लॉट किसी अन्य मशीन या किसी अन्य WinDbg थीम पर स्वीकार्य दिख सकता है।
  • यदि आपकी वर्तमान थीम में दो स्लॉट लगभग समान दिखते हैं, तो यह मानने के बजाय कि एक्सटेंशन आपकी सेटिंग को अनदेखा कर रहा है, syntax_highlighting में स्लॉट नाम बदलें।
  • यदि आपको वास्तव में भिन्न अंतिम रंग चाहिए, तो WinDbg की थीम या कमांड विंडो रंग सेटिंग्स बदलें ताकि स्लॉट स्वयं अलग ढंग से हल हो।

हाइलाइटिंग कब दिखाई देती है:

  • एक्सटेंशन DML-रंगीन स्यूडो-कोड उत्सर्जित करता है जब WinDbg रिपोर्ट करता है कि वर्तमान आउटपुट कॉलबैक DML-जागरूक हैं।
  • यदि वर्तमान डीबगर आउटपुट पथ DML-जागरूक नहीं है, तो एक्सटेंशन स्वचालित रूप से सादे टेक्स्ट स्यूडो-कोड पर वापस आ जाता है।
  • /view:json आउटपुट DML-रेंडर नहीं होता। इसके बजाय, यह pseudo_c_tokens रखता है ताकि बाहरी उपकरण अपना स्वयं का सिंटैक्स हाइलाइटिंग लागू कर सकें।

सामान्य DML अग्रभूमि स्लॉट:

  • wfg डिफ़ॉल्ट विंडो अग्रभूमि टेक्स्ट।
  • normfg सामान्य कमांड विंडो टेक्स्ट।
  • emphfg ज़ोरदार (emphasized) टेक्स्ट। Microsoft इसे डिफ़ॉल्ट रूप से हल्के नीले रंग के रूप में दस्तावेज़ित करता है, लेकिन सटीक रूप थीम पर निर्भर करता है।
  • warnfg चेतावनी टेक्स्ट।
  • errfg त्रुटि टेक्स्ट।
  • verbfg विस्तृत (verbose) टेक्स्ट।
  • changed बदला हुआ डेटा। Microsoft इसे डिफ़ॉल्ट रूप से लाल रंग के रूप में दस्तावेज़ित करता है।

सामान्य स्रोत-उन्मुख DML अग्रभूमि स्लॉट:

  • srcnum संख्यात्मक स्थिरांक।
  • srcchar वर्ण स्थिरांक।
  • srcstr स्ट्रिंग स्थिरांक।
  • srcid पहचानकर्ता।
  • srckw कीवर्ड।
  • srcpair ब्रेस या मिलान प्रतीक जोड़े।
  • srccmnt टिप्पणियाँ।
  • srcdrct निर्देश।
  • srcspid विशेष पहचानकर्ता।
  • srcannot स्रोत एनोटेशन या एनोटेशन-समान तत्व।

उदाहरण:

  • verbfg का अर्थ है "वर्बोज़ अग्रभूमि स्लॉट", न कि "कोई विशेष नामित नीला रंग"।
  • warnfg का अर्थ है "चेतावनी अग्रभूमि स्लॉट", न कि "हमेशा पीला या नारंगी"।
  • function_name_color: "srcid" का अर्थ है "WinDbg के पहचानकर्ता स्लॉट का उपयोग करके फ़ंक्शन नाम प्रस्तुत करें"।

यदि आप डार्क थीम पर रंग ट्यून कर रहे हैं:

  • यदि srcid के साथ फ़ंक्शन नाम बहुत धुंधले दिखते हैं, तो function_name_color: "emphfg" या function_name_color: "verbfg" से शुरू करें।
  • सामान्य प्रतीकों के लिए identifier_color: "normfg" या identifier_color: "wfg" का उपयोग करें जो पठनीय बने रहें लेकिन कीवर्ड को हावी न करें।
  • यदि आप चाहते हैं कि टिप्पणियाँ पीछे हट जाएँ लेकिन पूरी तरह गायब न हों, तो comment_color: "subfg" रखें।

आधिकारिक संदर्भ:

  • DML रंग स्लॉट व्यवहार और उदाहरण: Customizing Debugger Output Using DML
  • कमांड-विंडो संदेश वर्ग जैसे सामान्य, चेतावनी, त्रुटि, और वर्बोज़: .printf (WinDbg)

चेक-इन किया गया decomp.llm.json.example केवल मान्य शीर्ष-स्तरीय सेटिंग्स रखता है जिन्हें एक्सटेंशन वास्तव में पढ़ता है।

केवल संदर्भ हेतु उदाहरण:

PC UI भाषा का अनुसरण करें:```json { "display_language": { "mode": "auto" } }

root@kitploit:~
अंग्रेज़ी अनिवार्य करें:```json
{
  "display_language": {
    "mode": "fixed",
    "tag": "en-US",
    "name": "English"
  }
}

कोरियाई बाध्य करें:```json { "display_language": { "mode": "fixed", "tag": "ko-KR", "name": "Korean" } }

root@kitploit:~
डार्क सिंटैक्स-हाइलाइटिंग प्रीसेट:```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" } }

root@kitploit:~
उदाहरण `/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` प्रति-मूल-खंड live-in/live-out पहुँचने वाली परिभाषाएँ, विहित मान, भंडारण वर्ग, अभिसरण स्थिति, और विश्वास स्तर प्रकट करता है।
- `stack_pointer` प्रति-निर्देश स्टैक डेल्टा, फ्रेम-सापेक्ष उपनाम, कच्चे आधार/ऑफ़सेट, और विश्वास स्तर प्रकट करता है।
- `control_flow` संरचित क्षेत्र उम्मीदवारों को प्रकट करता है जैसे `natural_loop`, `if_else_candidate`, और `switch_candidate`, जिनमें ब्लॉक साक्ष्य, लूप इंडक्शन मेटाडेटा, स्विच तालिका/डिफ़ॉल्ट/रेंज मेटाडेटा, संकेतता (signedness), अनुक्रमणिका अभिव्यक्तियाँ, और विश्वास स्तर शामिल हैं।
- `abi` Microsoft x64 शैडो-स्पेस मान्यताओं, होम-स्लॉट साक्ष्य, फ्रेम/प्रोलॉग/एपिलॉग पहचान, नो-रिटर्न कॉल साक्ष्य, टेल-कॉल उम्मीदवार, थंक उम्मीदवार, इम्पोर्ट-रैपर उम्मीदवार, और रजिस्टरों तथा स्टैक स्टोर्स से प्राप्त कॉल तर्क प्रकट करता है।
- एनालाइज़र तथ्यों में अब P1 सिमेंटिक फ़ील्ड भी शामिल हैं:
  `type_hints`, `idioms`, और `callee_summaries`।
- `type_hints` पॉइंटर, लोकल, फ़ील्ड-ऑफ़सेट, ऐरे-जैसा, एनम-जैसा, बिटफ़्लैग-जैसा, और vtable-उम्मीदवार साक्ष्य को स्रोत और विश्वास स्तर के साथ प्रकट करता है। जब PDB डेटा उपलब्ध होता है, तो स्कोप्ड पैरामीटर/लोकल, फ़ील्ड संकेत, और एनम स्थिरांक को भी इस एकीकृत टाइप-हिंट स्ट्रीम में बढ़ावा दिया जाता है।
- `idioms` मान्यता प्राप्त हेल्पर कॉल और कंपाइलर पैटर्न जैसे मेमोरी कॉपी/फ़िल, स्ट्रिंग कॉपी, सुरक्षा कुकी जाँच, स्टैक प्रोब, आवंटन/मुक्ति हेल्पर, एग्रीगेट इनिशियलाइज़र, और RIP-सापेक्ष ग्लोबल/इम्पोर्ट लोड के लिए उच्च-स्तरीय प्रतिस्थापन प्रकट करता है।
- `callee_summaries` प्रत्यक्ष और अप्रत्यक्ष कैली रिटर्न-टाइप, पैरामीटर-मॉडल, साइड-इफ़ेक्ट, मेमोरी-इफ़ेक्ट, स्वामित्व, स्रोत, और विश्वास स्तर संकेत प्रकट करता है; जब WinDbg उन्हें हल कर सकता है तो प्रतीक/प्रकार-संवर्धित कॉल लक्ष्य प्रारंभिक ह्यूरिस्टिक सारांश को प्रतिस्थापित करते हैं, और वर्चुअल-कॉल उम्मीदवारों में पुनर्प्राप्त होने पर लक्ष्य अभिव्यक्तियाँ तथा vtable ऑफ़सेट शामिल होते हैं।
- ज्ञात Win32/NT/Rtl API सारांश, प्रतीक नाम उपलब्ध होने पर मेमोरी कॉपी/फ़िल/ज़ीरो, आवंटन, रिलीज़, स्थिति, और त्रुटि व्यवहार का वर्णन करते हैं।
- प्रॉम्प्ट तथ्यों में `analyzer_skeleton` और `graph_summary` शामिल हैं, ताकि मॉडल खाली पृष्ठ से शुरू करने के बजाय साक्ष्य-समर्थित मसौदे को परिष्कृत करे।
- `graph_summary` प्रवेश ब्लॉक, नियंत्रण-प्रवाह क्षेत्र, सामान्यीकृत स्थितियाँ, और स्पष्ट ट्रंकेशन नीति के साथ प्रतिनिधि उच्च-सिग्नल ब्लॉक प्रदान करता है। प्रॉम्प्ट तथ्य चयन अब उच्च-सिग्नल प्रविष्टियों को रैंक करता है और बड़े तथ्य समुच्चय को प्रतिनिधि बनाए रखने के लिए स्प्रेड सैंपलिंग का उपयोग करता है।
- `evidence_graph` उच्च-सिग्नल तथ्य नोड्स और प्रोवेनेंस किनारों को प्रकट करता है, ताकि IR मान, ब्लॉक मान स्थितियाँ, मेमोरी एक्सेस, कॉल लक्ष्य, टाइप हिंट, PDB हिंट, और देखा गया व्यवहार निर्देश और ब्लॉक साक्ष्य तक वापस खोजा जा सके।
- `obfuscation`, `semantic_control_flow`, और `deobfuscation_readiness` OLLVM-शैली पुनर्प्राप्ति तथ्यों और वर्तमान कमांड के लिए डीओबफसकेशन पुनर्लेखन मार्गदर्शन सक्षम है या नहीं, प्रकट करते हैं।
- वेरिफ़ायर प्रतिक्रिया में लीगेसी `warnings` के साथ संरचित `issues` प्रविष्टियाँ शामिल हैं। प्रत्येक issue में `severity`, `code`, `message`, और वैकल्पिक `evidence` होता है, ताकि उपकरण `branch.true_target_not_successor` जैसी त्रुटियों को कम-जोखिम वाली चेतावनियों से अलग करके फ़िल्टर कर सकें।
- वेरिफ़ायर जाँच अब सामान्यीकृत शाखा सत्य/असत्य लक्ष्यों की तुलना CFG उत्तराधिकारियों से करती हैं, स्यूडो-कोड शाखा घनत्व की तुलना पुनर्प्राप्त सशर्त शाखाओं से करती हैं, प्रत्यक्ष कैली सारांशों की क्रॉस-चेक स्यूडो-कोड कॉल प्रभावों से करती हैं, एविडेंस-ग्राफ़ नोड/किनारे के आधार को मान्य करती हैं, और ब्लॉक मान स्थिति संदर्भों को पुनर्प्राप्त ब्लॉकों और IR मानों से जाँचती हैं।
- सामान्य और व्याख्या आउटपुट में एक संक्षिप्त `suggested fixes` अनुभाग शामिल हो सकता है। ये वेरिफ़ायर issues, PDB-समर्थित नामकरण अवसरों, या बार-बार देखे गए मेमोरी हॉटस्पॉट से प्राप्त रूढ़िवादी `/fix:*` कमांड हैं। DML-जागरूक आउटपुट तुरंत लागू होने वाले सुझावों को उसी लक्ष्य के लिए क्लिक करने योग्य रीरन लिंक के रूप में प्रस्तुत करता है; प्लेसहोल्डर फ़ील्ड-प्रकार सुझाव तब तक सादा पाठ बने रहते हैं जब तक `TYPE` प्रतिस्थापित नहीं हो जाता।
- LLM मोड में, एक्सटेंशन स्वचालित रूप से वेरिफ़ायर issues को एक रीट्राय प्रॉम्प्ट में वापस फीड करता है। जब रीट्राय वेरिफ़ायर गुणवत्ता को बनाए रखता है या सुधारता है, तो उसे रखा जाता है; अन्यथा मूल प्रतिक्रिया को एक अतिरिक्त अनिश्चितता नोट के साथ बनाए रखा जाता है।
- `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`।

गुणवत्ता-प्रथम नोट:

- एक्सटेंशन अब बड़े फ़ंक्शनों के लिए चंक्ड मल्टी-पास विश्लेषण का समर्थन करता है।
- एनालाइज़र परिष्कार से पहले LLM को IR मान तथ्य, ब्लॉक मान स्थितियाँ, नियंत्रण-प्रवाह क्षेत्र, एविडेंस ग्राफ़ तथ्य, और x64 ABI/नो-रिटर्न साक्ष्य भेजता है, इसलिए `/view:analyzer`, `/view:json`, और सामान्य LLM मोड सभी एक ही P0 साक्ष्य आधार साझा करते हैं।
- वेरिफ़ायर लूप, स्विच, नो-रिटर्न, शाखा लक्ष्य, रिटर्न व्यवहार, कैली कॉल प्रभाव, एविडेंस ग्राफ़ आधार, ब्लॉक मान स्थिति संगति, साक्ष्य कवरेज, और संदिग्ध पहचानकर्ता दावों की एनालाइज़र साक्ष्य के विरुद्ध क्रॉस-चेक करता है। जब आत्मविश्वासपूर्ण गद्य पुनर्प्राप्त तथ्यों से आगे निकल जाता है, तो यह विश्वास कम करता है और प्रत्येक issue को एक स्थिर गंभीरता/कोड जोड़ी के साथ लेबल करता है।
- जब वेरिफ़ायर फ़ीडबैक स्कीमा त्रुटियाँ, तथ्य विरोध, या बहुत कम समायोजित विश्वास पाता है, तो LLM पथ प्रॉम्प्ट में वेरिफ़ायर issues जोड़कर एक स्वचालित रीट्राय करता है।
- क्लाउड मॉडल के लिए एक अच्छा प्रारंभिक बिंदु है `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` की तुलना में एक सुरक्षित प्रारंभिक बिंदु है।
- यदि विशाल फ़ंक्शनों पर गुणवत्ता अभी भी कमजोर है, तो `/limit:N` घटाने से पहले `chunk_count_limit` बढ़ाएँ।
- यदि कोई endpoint कॉन्फ़िगर नहीं है, तो एक्सटेंशन नियतात्मक mock प्रदाता पर वापस आ जाता है।
- यहाँ तक कि जब एक्सटेंशन `/view:analyzer` या mock प्रदाता का उपयोग कर रहा हो, तब भी `display_language` और `syntax_highlighting` प्रभावित करते हैं कि उपयोगकर्ता क्या देखता है।

## WinDbg स्मोक टेस्ट

1. `Build.ps1` या `Build-Legacy.ps1` के साथ बिल्ड करें।
2. बिल्ड किए गए `decomp.dll` के पास `decomp.llm.json` रखें।
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

root@kitploit:~
अपेक्षित जाँचें:

- `target`, `entry`, और `module` लगातार resolve होने चाहिए
- सामान्य फ़ंक्शनों के लिए `regions` गैर-शून्य होना चाहिए
- `/view:analyzer` को अभी भी analyzer confidence और pseudocode stub प्रिंट करना चाहिए
- 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` भी शामिल होने चाहिए
- टाइप किए गए structs और enums के लिए, `/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"

यदि auth फ़ाइल में refresh token होता है, तो एक्सटेंशन अनुरोध भेजने से पहले समाप्त हो चुके access token को रीफ़्रेश करता है। DECOMP_LLM_CHATGPT_ACCESS_TOKEN का उपयोग अस्थायी bearer token के रूप में किया जा सकता है, लेकिन सामान्य WinDbg सत्रों के लिए auth-फ़ाइल पथ बेहतर है क्योंकि यह token समाप्ति के बाद भी बना रहता है। !decomp के दौरान एक्सटेंशन कभी भी ब्राउज़र नहीं खोलता; जब interactive ChatGPT login की आवश्यकता हो, तो WinDbg के बाहर codex login चलाएँ।

Local LLM Endpoint Examples

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"

root@kitploit:~
### 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"

root@kitploit:~
टूल डाउनलोड करें
  • एंट्री/बेसिक-ब्लॉक/साक्ष्य/कॉल-टार्गेट नेविगेशन के लिए WinDbg DML लिंक जब आउटपुट कॉलबैक DML का समर्थन करता है
  • संक्षिप्त, साक्ष्य स्पष्टीकरण, केवल-तथ्य, डीबग प्रॉम्प्ट, JSON, और डेटा-मॉडल शैली आउटपुट के लिए अलग परिणाम मोड
  • no-return, प्रकार, फ़ील्ड, और नाम बदलने के संकेतों के लिए उपयोगकर्ता सुधार स्विच
  • लाइव, डंप, कर्नेल, और TTD-जैसे सत्रों के लिए सत्र-जागरूक विश्लेषण नीति तथ्य
  • वर्तमान डीबगर संदर्भ से अवलोकित व्यवहार तथ्य, जिनमें रजिस्टर तर्क नमूने, मेमोरी हॉटस्पॉट, और जहाँ उपलब्ध हों TTD क्वेरी सुझाव शामिल हैं
  • LLM प्रॉम्प्टिंग के लिए RIP-सापेक्ष स्ट्रिंग/ग्लोबल/IAT वर्गीकरण और कॉल-टार्गेट सिग्नेचर संकेत
  • LLM प्रॉम्प्टिंग के लिए लोडेड-PDB जागरूक प्रोटोटाइप, स्कोप्ड पैरामीटर/लोकल, फ़ील्ड, एनम, और स्रोत-लाइन संकेत
  • एक्सटेंशन से सीधे इन-प्रोसेस LLM कॉल
  • OpenAI-संगत HTTP एडेप्टर या नियतात्मक मॉक फ़ॉलबैक
  • LLM आउटपुट पर वेरिफ़ायर पास
  • /last:N:prompt
  • /last:* मोड टर्मिनल रीप्ले कमांड हैं। यदि उसी कमांड में कोई target मौजूद है, तो कैश किया गया artifact रीप्ले होता है और उस target के लिए कोई स्थानीय विश्लेषण या LLM अनुरोध शुरू नहीं होता।
  • इन-मेमोरी कैश किए गए artifacts केवल लोड किए गए extension इंस्टेंस में रहते हैं। रिज़ल्ट history सबसे नए 8 परिणाम रखती है और जब WinDbg extension को अनलोड करता है या प्रोसेस बाहर निकलता है तो गायब हो जाती है।
  • सफल LLM-समर्थित परिणाम लोड किए गए decomp.dll के पास artifact फ़ोल्डर के अंतर्गत स्वचालित रूप से भी सहेजे जाते हैं। ऑपरेटर को अलग से save कमांड की आवश्यकता नहीं होती।
  • Persistent artifacts में request, response, data_model, debug_prompt, और एक kernel_build object शामिल होता है जिसमें Win32/KD version मान, build string, वैकल्पिक NtBuildLab, और build fingerprint होते हैं।
  • बाद के सत्र में, वही !decomp <target> कमांड चलाने पर target resolution और function RVA recovery के बाद स्वचालित रूप से artifact\<kernel_build>\... पथ की जाँच होती है। यदि सहेजा गया kernel_build वर्तमान OS build से मेल खाता है, तो extension artifact को function bytes पढ़े बिना, स्थानीय analyzer passes चलाए बिना, या LLM को कॉल किए बिना रीप्ले करता है।
  • गायब, अपठनीय, या बेमेल persistent artifacts को cache miss माना जाता है। कमांड ताज़ा विश्लेषण पर वापस जाता है और केवल सफल LLM-समर्थित परिणाम के बाद artifact को अधिलेखित करता है।
  • सामान्य आउटपुट में DML action links इन कैश किए गए /last:* दृश्यों का उपयोग करते हैं, इसलिए explain, json, facts, prompt, या data-model पर क्लिक करने से नया decompile run शुरू नहीं होता।
  • विरासत /last-json, /last-explain, /last-facts, /last-data-model, /last-dx, और /last-prompt समर्थित बने रहते हैं।
  • TTDReplay.dll
    dx @$cursession.TTD.Calls(...)
  • User correction switches आपको कमांड लाइन से analyzer facts को पैच करने देते हैं जब डिबगर के पास पर्याप्त semantic information नहीं होती:```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
  • access_token_env
    api_key
    api_key_env
    DECOMP_LLM_API_KEY
    OPENAI_API_KEY
  • chunk_block_limit
  • chunk_count_limit
  • chunk_completion_tokens
  • merge_completion_tokens
  • display_language
  • syntax_highlighting