LLM4Decompile: LLM के साथ बाइनरी कोड का डी-कम्पाइलेशन
शोधकर्ता compiled binaries को वापस C code में बदलने के लिए fine-tuned LLMs के साथ प्रयोग कर रहे हैं, जिससे अधिक शक्तिशाली, आंशिक रूप से स्वचालित decompilation tools की संभावना बनती है। टिप्पणीकारों का कहना है कि GPT‑4 जैसे मॉडल पहले से assembly से compilable code बना सकते हैं, लेकिन program semantics को faithfully reproduce करने में संघर्ष करते हैं, और मौजूदा benchmarks (re-compilability बनाम re-executability) में बड़ा अंतर दिखता है। यह चर्चा reverse engineering, deobfuscation, और security analysis में संभावित उपयोगों की पड़ताल करती है, साथ ही legal, reliability, और evaluation चुनौतियों तथा LLMs को traditional decompilers और formal verification के साथ जोड़ने की संभावित आवश्यकता पर जोर देती है.
मॉडल प्रदर्शन और प्रशिक्षण
- बताया गया है कि छोटा 6B मॉडल 33B मॉडल से बेहतर प्रदर्शन करता है; टिप्पणीकार इसे बड़े मॉडलों के अपर्याप्त प्रशिक्षण और डेटा गुणवत्ता, LR शेड्यूल आदि के प्रति संवेदनशीलता से जोड़ते हैं।
- डी-कम्पाइलर मॉडल को DeepSeek-Coder से fine-tune किया गया है; केवल लगभग 4B टोकन उपलब्ध होने के कारण, जबकि सामान्य LLMs के लिए ट्रिलियनों टोकन होते हैं, शुरुआत से प्रशिक्षण को अव्यावहारिक माना जाता है।
- अनुमानित हार्डवेयर आवश्यकताएँ: 1B parameters के लिए ~2GB VRAM, 7B के लिए ~14GB, 33B के लिए ~80GB।
GPT‑4 और अन्य LLMs से तुलना
- GPT‑4 डी-कम्पाइलेशन में, बिना किसी task-specific training के, आश्चर्यजनक रूप से अच्छा प्रदर्शन करता है।
- यह विशेष मॉडल की तुलना में अधिक बार syntactically valid (recompilable) C बनाता है, लेकिन semantic correctness (re-executability) में कमजोर है।
- लोग JavaScript के deobfuscation और code beautifying के लिए GPT‑4/3.5 का उपयोग करने की भी रिपोर्ट करते हैं, जिसमें आंशिक लेकिन पूर्ण नहीं सफलता मिलती है।
पारंपरिक decompilers और reverse engineering से संबंध
- कई लोग नोट करते हैं कि आधुनिक native-code decompilers (IDA, Ghidra, Binja, rev.ng, आदि) मजबूत baselines हैं और उन्हें benchmarks का हिस्सा होना चाहिए, जिसमें gotos, cyclomatic complexity, और graph-edit distance जैसे पहले के metrics का उपयोग किया जाए।
- कुछ practitioners का तर्क है कि complex binaries का decompilation, खासकर hand-written assembly या भारी optimization वाले code का, संभवतः पूरी तरह automatic नहीं हो सकता; tools मुख्यतः expert effort को amplify करते हैं।
- अन्य लोग बताते हैं कि compiler diversity, non-determinism, और binaries तथा source code के बीच bijection की कमी कठिन सीमाएँ हैं; exact round-tripping अक्सर असंभव होता है।
मूल्यांकन, correctness, और “hallucinations”
- प्रोजेक्ट वर्तमान में यह मापता है:
- Re-compilability: क्या generated C compile होता है?
- Re-executability: क्या recompiled binary test cases पास करता है?
- Re-executability rates कम हैं (≈10–15%), भले ही recompilability काफ़ी अधिक हो, जो semantic gaps को उजागर करता है।
- इस पर बहस है कि round-tripping या identical binaries एक यथार्थवादी metric है या नहीं; कई लोग test quality और fuzzing को अधिक व्यावहारिक checks मानते हैं।
- कुछ लोग formal verification का प्रस्ताव रखते हैं: LLM code के साथ एक proof आउटपुट करे; एक non-LLM verifier equivalence की जाँच करे। अन्य लोग feasibility और undecidability सीमाओं पर सवाल उठाते हैं।
उपयोग, दायरा, और भविष्य की दिशाएँ
- सुझाए गए उपयोग: reverse engineering में सहायता, security analysis, malware और obfuscated JS analysis, toolchain detection, intermediate representations (जैसे RzIL) में lifting, और author attribution experiments।
- कई लोगों की राय है कि LLMs को standalone decompilers के बजाय मौजूदा disassemblers/IRs के ऊपर “copilots” की तरह उपयोग किया जाएगा।
- open-source C (और संभवतः synthetic code) से dataset generation को इस शोध दिशा का एक प्रमुख लाभ माना जाता है।