C पुनःकार्यान्वयन के लिए नियतात्मक PyGhidra निष्कर्षण, ट्राइएज, और स्थानीय LLM कंपाइलर-बैकएंड पाइपलाइन।
मेरा Ghidra + LLM पाइपलाइन डाउनलोड करने के लिए धन्यवाद।
यह मेरा पहला README है। ASL (अमेरिकन साइन लैंग्वेज) मेरी पहली भाषा है, इसलिए मेरी अंग्रेज़ी परफेक्ट नहीं है। मैंने अपनी पूरी कोशिश की है।
मुझे एक पुराना PC सिमुलेशन बहुत पसंद है जिसे मैं बचपन से खेलता आ रहा हूँ, और मैं इसे अंदर से बेहतर बनाना चाहता हूँ।
OpenRA और OpenTTD जैसे ओपन-सोर्स गेम्स को देखकर मैंने यह सीखा: किसी शौकिया द्वारा पुनर्निर्माण का मतलब मूल सोर्स कोड प्राप्त करना नहीं है। इसका मतलब है गेम का एक नया ओपन-सोर्स संस्करण बनाना जो मूल गेम की एसेट्स को लोड कर सके। तब कोई भी इसे बढ़ा सकता है या इसमें योगदान दे सकता है।
यह काम करने के लिए मैं दो तरह के AI को साथ में इस्तेमाल करता हूँ:
हर फ़ंक्शन को एक लेबल मिलता है। इससे बहुत समय बचता है, क्योंकि मैं OS और रनटाइम के बड़े ढेर पर मेहनत बर्बाद नहीं करता।
|-----------|------------------------------------------------------------------------------------------------------------------
| लेबल | अर्थ |
|---|---|
| KEEP | गेम का अपना लॉजिक (उदाहरण के लिए फ्लाइट मॉडल, डैमेज मॉडल, TrackIR) |
| WRAP | Java की ओर का ग्लू जो OS या इनपुट APIs को कॉल करता है: सिग्नेचर रखें, नया बॉडी लिखें। |
| (IL-2 1946 एक दिलचस्प इंजन है: C++ और Java साथ में।) | |
| REPLACE | पुराना C रनटाइम, एलोकेटर, थंक्स: इन्हें कंपाइलर या OS प्रदान करता है, इसलिए नए 64-बिट संस्करण को इनकी ज़रूरत नहीं होती |
| UNKNOWN | स्पष्ट नहीं: इसे हाथ से देखें |
| ----------- | ------------------------------------------------------------------------------------------------------------------ |
मेरे टेस्ट प्रोग्राम में, लगभग 44% फ़ंक्शन REPLACE थे, इसलिए उन्हें कभी कन्वर्ट करने की ज़रूरत नहीं पड़ी।
शुरुआत में मुझे भरोसा था कि C स्यूडोकोड में सारे जवाब होंगे। वह भोलापन था। यह असेंबली की Ghidra द्वारा की गई व्याख्या है, और यह अनुमान लगाती है (वेरिएबल टाइप, खोए हुए आर्ग्युमेंट्स)।
असेंबली ही असली सच्चाई है। इसमें वेरिएबल टाइप नहीं होते, लेकिन यह हर फ़ंक्शन का सटीक व्यवहार रखती है। इसलिए स्क्रिप्ट्स असेंबली पढ़ती हैं, और इसे C जैसे रूप में एक ब्लूप्रिंट में बदल देती हैं। Ghidra का C केवल एक संकेत के रूप में रखा जाता है।
मेरे शुरुआती टेस्ट में लोकल LLMs (Qwen 2.5 Coder, DeepSeek Coder V2 Lite, Mellum 2) का उपयोग असेंबली को सीधे पढ़ने के लिए किया गया था। यह कभी भी भरोसेमंद तरीके से काम नहीं किया। उन्होंने भ्रम पैदा किया, क्योंकि उन्हें कोड लिखने के लिए बनाया गया है, कच्चे मशीन कोड को पढ़ने के लिए नहीं।
कई असफल प्रयोगों के बाद मैंने काम को बाँट दिया:
नोट: Python जवाब की जाँच कैसे करता है
टेक्स्ट जाँच: फ़ंक्शन का नाम, ब्लूप्रिंट से हर कॉल, ग्लोबल और स्ट्रिंग, लूप्स, स्टेप साइज़, तुलना किए गए कॉन्स्टेंट्स, रिटर्न वैल्यू, और यह कि कोई रजिस्टर नाम या गढ़े हुए नाम न बचे हों।
gcc कंपाइल जाँच: कोड को gcc के साथ कंपाइल किया जाता है (केवल सिंटैक्स, कुछ भी रन नहीं होता)। इससे बहुत मदद मिली। एक शुरुआती रन में टेक्स्ट जाँचों ने Mellum 2 के उत्तरों को पास कर दिया, लेकिन उनमें से कोई भी कंपाइल नहीं हुआ, क्योंकि एक हेडर टिप्पणी टिप्पणी के बाहर लिखी गई थी। gcc वह पकड़ता है जो टेक्स्ट जाँचें नहीं देख सकतीं: अपघोषित या पुनःघोषित चर, गलत प्रकार, और टूटे हुए ब्रेसिज़ या सेमीकोलन। कोई फ़ंक्शन तभी PASS गिना जाता है जब टेक्स्ट जाँचें और कंपाइल दोनों ठीक हों। gcc यह सिद्ध नहीं करता कि तर्क सही है, इसलिए मैं अब भी कोड को ब्लूप्रिंट के सामने पढ़ता हूँ।
यदि कोई जाँच विफल होती है, तो LLM को विफल चीज़ों की सूची मिलती है और वह एक बार और प्रयास करता है।
Python छोटी चूकों को स्वयं ठीक करता है, LLM के बिना: यह प्रत्येक चर को एक बार घोषित करता है, ढीली हेडर पंक्तियों को एक टिप्पणी में लपेटता है, अंतिम return को सही परिणाम लौटाने देता है, और includes तथा declarations जोड़ता है।
चेकलिस्ट तब आई जब मैंने देखा कि LLM बहुत लंबे फ़ंक्शनों पर विफल हो रहे थे। यह उसी तरह काम करती है जैसे एक पायलट टेक-ऑफ और लैंडिंग से पहले उपयोग करता है। Python इसे फ़ंक्शन से लिखता है, और उत्तर को इसके विरुद्ध जाँचता है। मेरे परीक्षणों में लंबे फ़ंक्शन पास होने लगे, और रन तेज़ हो गए।
|-------------------|---------------------------------------|---------------------------------------------
| फ़ोल्डर | यह क्या करता है | पढ़ें |
|---|---|---|
ghidra_pipeline | Dump, grouping, triage, roles | ghidra_pipeline/INSTRUCTION.txt |
llm_pipeline | Blueprints और LLM runner (v3) | llm_pipeline/INSTRUCTION_BLUEPRINT_LLM.txt |
| ------------------- | --------------------------------------- | --------------------------------------------- |
ghidra_pipeline से शुरू करें, फिर जब आप अपने स्थानीय LLM का उपयोग करने के लिए तैयार हों तो llm_pipeline पर जाएँ।
पहले, PyGhidra में अपने प्रोग्राम का विश्लेषण करें और PyGhidra Scripts/decompile_full_dump.py चलाएँ।
दोनों INSTRUCTION फ़ाइलें फ़ोल्डर सेटअप की व्याख्या करती हैं। फिर:
पहले, PyGhidra में अपने प्रोग्राम का विश्लेषण करें और PyGhidra Scripts/decompile_full_dump.py चलाएँ।
दोनों INSTRUCTION फ़ाइलें फ़ोल्डर सेटअप की व्याख्या करती हैं। फिर:
python .\make_full_lite_v2.py --in . --out .\OUT
python .\triage_evidence_v2.py --lite .\OUT\LITE_AC
python .\build_roles_v2.py --triage .\OUT\TRIAGE
python .\blueprint_v3.py --group ".\SOURCE\LITE_AC\<GroupName>" --out ".\G_<GroupName>\BLUEPRINT_v3"
python .\run_blueprint_llm_v3.py --bp ".\G_<GroupName>\BLUEPRINT_v3" --out ".\G_<GroupName>\RUN1_v3_<model>" --model <model name>
आपको PyGhidra के साथ Ghidra, Python 3, LM Studio (एक मॉडल लोड किया हुआ), और gcc (अनुशंसित, कंपाइल जाँच के रूप में उपयोग किया जाता है) की आवश्यकता होगी।