LLM4Decompile - LLM का उपयोग करने वाली बाइनरी कोड decompilation तकनीक

 (github.com/albertan017)
2 पॉइंट द्वारा GN⁺ 2024-03-18 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • LLM4Decompile Linux x86_64 बाइनरी को GCC O0~O3 optimization स्तरों पर इंसानों द्वारा पढ़े जा सकने वाले C source code में वापस बदलने वाला एक open source large language model project है
  • इसका approach यह है कि पहले बाइनरी को Objdump से assembly में बदला जाता है, फिर LLM उसे C code में decompile करता है; साथ ही Ghidra output pseudocode को refine करने वाली LLM4Decompile-Ref श्रृंखला भी उपलब्ध है
  • मॉडल 1.3B~22B आकार में उपलब्ध हैं, और llm4decompile-9b-v2 ने Decompile benchmark में 64.9% re-executability दर्ज की है
  • evaluation metric re-executability है, जिसमें देखा जाता है कि decompiled code पहले से परिभाषित tests पास करके सही तरह चलती है या नहीं; HumanEval-Decompile की 164 C functions और ExeBench की 2,621 functions benchmark के रूप में उपयोग होती हैं
  • project ने 2025 में decompile-bench और SK²Decompile जारी किए, और अब अधिक architectures, settings और decompilation tool integration की दिशा में विस्तार कर रहा है

LLM4Decompile का लक्ष्य और support scope

  • LLM4Decompile decompilation के लिए विशेषीकृत एक open source large language model project है
  • मौजूदा version Linux x86_64 binaries को GCC optimization स्तर O0~O3 की range में इंसानों द्वारा पढ़े जा सकने वाले C source code में decompile करता है
  • project व्यापक architecture और settings support के लिए विस्तार पर काम कर रहा है
  • इसके दो मुख्य उपयोग तरीके हैं
    • LLM4Decompile-End: बाइनरी को सीधे decompile करने वाली model श्रृंखला
    • LLM4Decompile-Ref: Ghidra द्वारा decompile किए गए pseudocode को LLM से refine करने वाली model श्रृंखला

decompilation training·evaluation flow

  • compilation process C source code से शुरू होकर preprocessing, compilation, assembly और linking से गुजरते हुए executable बनाता है
  • decompilation इस process को उल्टा follow करती है और binary code को फिर से source file में बदलती है
  • क्योंकि LLM binary data को सीधे process नहीं कर सकता, इसलिए बाइनरी को पहले Objdump से assembly language में disassemble करना पड़ता है
  • README बताता है कि binary और disassembled ASM एक-दूसरे में बदले जा सकते हैं, इसलिए उन्हें समकक्ष माना जाता है
  • training में decompiled code और original source code के बीच loss calculate किया जाता है, और evaluation में test assertions पास करने के आधार पर functionality जांची जाती है

evaluation metrics और benchmarks

  • मुख्य metric Re-executability है
    • यह जांचता है कि decompiled code सही तरह से चलती है या नहीं
    • यह evaluate करता है कि सभी pre-defined test cases पास होते हैं या नहीं
  • HumanEval-Decompile standard C library पर ही निर्भर 164 C functions का संग्रह है
  • ExeBench वास्तविक projects से ली गई 2,621 functions का संग्रह है
    • इसमें user-defined functions, structs और macros शामिल हैं

public models और performance

  • LLM4Decompile में 1.3B~33B parameters वाले models शामिल हैं, और models Hugging Face पर उपलब्ध हैं
  • प्रमुख models की re-executability इस प्रकार है
  • V1.5 श्रृंखला को 15B tokens के बड़े dataset और 4,096 तक की maximum token length पर train किया गया, और project के अनुसार इसने पिछले models की तुलना में 100% से अधिक performance improvement दिखाया
  • V2 श्रृंखला Ghidra आधारित है, और Ghidra द्वारा बनाए गए decompiled pseudocode को refine करने के लिए 2B tokens पर train की गई है
  • project के अनुसार 22B-V2 ने 6.7B-V1.5 की तुलना में अतिरिक्त 40.1% अधिक performance दिखाई

हाल में जारी की गई चीजें

  • 4 अक्टूबर 2025 को SK²Decompile जारी किया गया
    • चरण 1 Structure Recovery, यानी Skeleton चरण, binary या pseudocode को obfuscated intermediate representation में बदलता है
    • चरण 2 Identifier Naming, यानी Skin चरण, अर्थपूर्ण identifiers के साथ इंसानों द्वारा पढ़े जा सकने वाले source code को बनाता है
    • model links: sk2decompile-struct-6.7b, sk2decompile-ident-6.7
  • 20 मई 2025 को decompile-bench जारी किया गया
    • training के लिए binary-source function pairs की 20 लाख जोड़ियाँ शामिल हैं
    • evaluation के लिए 70,000 function pairs शामिल हैं
    • विवरण decompile-bench folder में है
  • 17 अक्टूबर 2024 को decompile-ghidra-100k जारी किया गया
    • हर optimization स्तर के लिए 25,000, यानी कुल 100,000 training samples शामिल हैं
    • single A100 40G GPU पर लगभग 3.5 घंटे में चलने वाली training script उपलब्ध है
    • तेज reproduction cost कुल 20 डॉलर से कम है, और इसने 0.26 re-executability हासिल की
  • 23 सितंबर 2024 को LLM4Decompile-9B-v2 जारी किया गया
    • इसे Yi-Coder-9B के आधार पर fine-tune किया गया
    • इसने Decompile benchmark में 0.6494 re-executability हासिल की

उपयोग flow

  • quick start में repository clone करना, Conda environment बनाना और requirements.txt install करना शामिल है
  • preprocessing चरण में C code को GCC से binary में compile करने के बाद objdump -d से assembly instructions निकाले जाते हैं
  • function name को उदाहरण के func0 की जगह decompile किए जाने वाले actual function name से बदलना होगा
  • input assembly से निम्न form अपेक्षित है
    • <FUNCTION_NAME>:
    • इसके बाद assembly instructions की कई lines
  • decompilation चरण में transformers के AutoTokenizer और AutoModelForCausalLM से Hugging Face model लोड करके assembly prompt से C code generate किया जाता है
  • Docker का उपयोग भी किया जा सकता है
    • image build करने के बाद GPU option के साथ container चलाया जाता है
    • ghidra directory में demo.py चलाने का flow दिया गया है

HumanEval-Decompile data format

  • HumanEval-Decompile data llm4decompile/decompile-eval/decompile-eval-executable-gcc-obj.json में JSON list format में stored है
  • samples की संख्या 164 functions को O0, O1, O2, O3 optimization स्तरों से गुणा करने पर 164*4 है
  • हर sample में 5 keys होती हैं
    • task_id: problem ID
    • type: optimization चरण, जो O0, O1, O2, O3 में से एक है
    • c_func: HumanEval problem का C solution
    • c_test: C test assertion
    • input_asm_prompt: assembly instructions और prompt
  • evaluation script evaluation folder में है

प्रगति में चल रहे आइटम और license

  • ongoing items में बड़े training datasets और cleanup process, लोकप्रिय languages·platforms·settings support, executable support, और Ghidra·Rizin जैसे decompilation tools के integration शामिल हैं
  • बड़े training datasets और executable support को 13 मई 2024 को पूरे हुए आइटम के रूप में चिह्नित किया गया है
  • code repository MIT License और DeepSeek License के तहत licensed है
  • paper arXiv:2403.05286 पर उपलब्ध है, और project Colab तथा YouTube सामग्री भी प्रदान करता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-03-18
Hacker News की राय

  • विचार दिलचस्प है, लेकिन नतीजे कितने भरोसेमंद होंगे, यह सवाल है
    दोबारा compile करने पर अलग machine code आ सकता है, इसलिए hallucination की पहचान करना मुश्किल हो सकता है, और खासकर यह चिंता है कि कहीं यह किसी नए structure पर, जो असल में code का core हो सकता है, चुपचाप fail न हो जाए
    यह जानना दिलचस्प होगा कि generative तरीके से चलाते समय LLM किसी खास हिस्से पर अपनी confidence भी साथ में रिपोर्ट कर सकता है या नहीं, और अंत में शायद इंसानी verification की ज़रूरत होगी

    • इसलिए round-trip conversion अहम है
      binary को source में decompile करने के बाद अगर उसे फिर binary में compile किया जाए, तो मूल binary ही निकलनी चाहिए; और loss स्वीकार्य स्तर तक घटने तक इस प्रक्रिया को दोहराया जा सकता है
      ऐसी समस्याओं के लिए reinforcement learning बहुत उपयुक्त है, और वास्तव में इस तरह के मामलों में इसके असामान्य रूप से प्रभावी होने की बात जानी जाती है
    • LLM मूलतः probabilistic होते हैं, इसलिए natural language processing जैसे कम-सटीकता वाले क्षेत्रों में ये काफ़ी अच्छा काम करते हैं, लेकिन decompilation या disassembly में इनका उपयोग करना मुझे व्यक्तिगत रूप से “गलत tool चुनने” के क़रीब लगता है
      हो सकता है यह आजकल के आम “बस LLM लगा दो” meme को परखने वाला एक प्रयोग हो, लेकिन बड़ा प्रतिवाद यह है कि मौजूदा decompiler बहुत कम compute में पहले से ही इससे बेहतर काम करते हैं
    • input, output, और इस बात का formal proof लेने वाला formal verification tool रखा जा सकता है कि output का अर्थ input से मेल खाता है, और LLM से output के साथ वही proof भी बनवाया जा सकता है
      इसके बाद verification tool के ज़रिए यह जाँचा जा सकता है कि LLM द्वारा दिया गया proof सही है या नहीं
      बेशक ऐसा proof बना सकने वाला LLM तैयार करना और train करना उससे भी बड़ी चुनौती होगी, लेकिन hallucination को सुरक्षित रूप से पकड़ने का यह एक तरीका हो सकता है
    • differential fuzzing भी इस्तेमाल किया जा सकता है
    • भले ही यह पूरी तरह भरोसेमंद न हो, binary को modify करते समय अक्सर सिर्फ़ कुछ functions बदलना काफ़ी होता है
      इसलिए सिर्फ़ उन्हीं कुछ functions को फिर से compile करना होगा

  • अगर application बनाने वाले developers के बारे में पता हो, तो उनके पुराने code को training data की तरह इस्तेमाल करके decompilation module train किया जा सकता है या नहीं, यह दिलचस्प है
    उदाहरण के लिए Super Mario 64 और Zelda 64 पूरी तरह decompile हो चुके हैं और दूसरे N64 games पर भी काम चल रहा है, इसलिए यह जानना रोचक होगा कि क्या उन दोनों games पर काम करने वाले developers को map करके, किसने कौन-सा module बनाया इसका अनुमान लगाकर, दूसरे games की decompilation में इसका उपयोग किया जा सकता है
    अगर यह सचमुच बहुत अच्छा हो जाए, तो PC के अंदर के सारे binary blobs को decode करना, drivers को public करना, और यहाँ तक कि OS को भी खोल देना—ऐसी ज़िंदगी की कल्पना की जा सकती है
    Linux पर संतोष न करके Windows XP को फिर से जीवित करना, उसमें modern security और app compatibility backport करना, और Microsoft के Windows 11 को वैसे ही छोड़ देना—ऐसी कल्पना भी संभव है

    • decompiler पहले से मौजूद हैं और अच्छा प्रदर्शन भी करते हैं
      अगर LLM मौजूदा decompiler जैसा ही काम कर सकता है, तो वकील शायद इसे equivalent process मानेंगे
      मूल समस्या तकनीकी नहीं, बल्कि क़ानूनी और राजनीतिक है
    • मैंने अपने bachelor thesis में इससे मिलता-जुलता विषय लिया था, और कुछ शोध ऐसे थे जिनमें खास परिस्थितियों में सिर्फ़ compiled binary देखकर यह पहचानने वाला author identification classifier train किया जा सकता है कि प्रोग्राम किसने लिखा
      यह मुझे नहीं पता कि इसका कोई वास्तव में उपयोगी इस्तेमाल हुआ या नहीं, लेकिन यह दिलचस्प है कि किसी व्यक्ति की coding style compile होने के बाद भी इतनी बची रह सकती है कि compiled programs को एक-दूसरे से अलग पहचाना जा सके
    • मुझे नहीं लगता कि वास्तव में लिखे गए code को खुद पहचान पाना संभव होगा
      नतीजा मूल के बहुत क़रीब होगा, लेकिन बहुत से code style elements गायब हो जाएँगे, और जो style बची हुई दिखेगी वह भी ज़्यादातर hallucination के क़रीब होगी

  • public C code से बड़ी मात्रा में input/output pair dataset बनाना आसान है, इसलिए यह LLM fine-tuning के लिए बहुत अच्छा use case है

    • coding LLM, जैसे DeepSeek जैसे models से बहुत सारा C code generate करवाकर, उसके compile होने की जाँच करके, उसे synthetic training data की तरह इस्तेमाल करना भी इस स्थिति में काफ़ी फ़ायदेमंद लग सकता है
      आम तौर पर synthetic training data की quality बड़ी चिंता होती है, लेकिन यहाँ code का compile हो जाना ही मुख्य बात है

  • अगर मैं result figure के re-executability metric को सही पढ़ रहा हूँ, तो विचार शानदार है, लेकिन व्यवहार में यह अच्छा काम करता नहीं दिखता
    https://raw.githubusercontent.com/albertan017/LLM4Decompile/...
    जोड़कर कहें तो, re-executability semantic accuracy मापने का एक मुख्य metric है
    decompilation के नतीजे को फिर से compile करके test cases चलाए जाते हैं ताकि यह आँका जा सके कि program logic और behavior सुरक्षित रहे या नहीं, और recompilability तथा re-executability क्रमशः syntax reconstruction और semantic preservation को दर्शाते हैं

  • यह समस्या कम-से-कम दो मायनों में दिलचस्प है
    पहला, आदर्श decompiler proprietary source code के महत्व को कम कर सकता है
    दूसरा, public C code प्रचुर मात्रा में उपलब्ध है, इसलिए assembly और source code के pair dataset आसानी से बनाए जा सकते हैं, और optimization level, compiler, platform भी विविध हैं
    लेकिन यह जानना दिलचस्प है कि लेखकों ने DeepSeek-Coder को ही fine-tune क्यों किया
    क्या मिलते-जुलते dataset से LLM को scratch से train किया जा सकता है, इसके लिए कितना आकार चाहिए होगा, और क्या इसे local में चलाना संभव होगा—यह भी सवाल है

    • ज़्यादातर proprietary code firewall के पीछे चलता है, इसलिए इस तरीके का उस पर बहुत बड़ा असर नहीं पड़ेगा
      भले ही वांछित काम शुरुआती model से बहुत क़रीब न हो, फिर भी random initialization की तुलना में pretrained model से शुरू करना लगभग हमेशा बेहतर होता है
    • आदर्श decompiler जैसी कोई चीज़ मौजूद नहीं है
      compiler जानकारी खो देता है, इसलिए एक अर्थ में यह कभी अस्तित्व में आ ही नहीं सकता; और “नतीजे के code की high-level understanding” जैसी उदार परिभाषा से देखें तो भी यह computer security के क्षेत्र का AGI-स्तर का प्रश्न है
      अभी तक कोई भी इसके क़रीब नहीं पहुँचा है
    • language model को scratch से train करने के लिए बहुत data चाहिए
      Llama2 को 2 trillion tokens पर विकसित किया गया था, जबकि यह dataset लगभग 4 billion tokens का है
      उपयुक्त model size तय करना भी आसान नहीं है, और प्रयोगों में 7 billion parameter model ने 21% executability दिखाई, जबकि 1 billion parameter model 10% पर रहा
      हालाँकि recompilability दोनों में काफ़ी समान है
      1 billion parameter model के लिए कम-से-कम 2GB GPU memory चाहिए, इसलिए यह ज़्यादातर GPUs पर संभव है, और 7 billion model के लिए 14GB चाहिए, इसलिए यह 3090/4090 श्रेणी के लिए उपयुक्त है
      33 billion model के लिए single card पर A100 80GB एक विकल्प है, और तकनीकी रूप से यह MacBook पर भी संभव हो सकता है, लेकिन व्यवहार में शायद आप ऐसा नहीं करना चाहेंगे
    • शायद training cost और fine-tuning cost के अंतर की वजह से
      यह idea को validate करने के लिए एक शुरुआती बिंदु भी हो सकता है

  • Python bytecode के लिए LLM-आधारित decompiler https://github.com/kukas/deepcompyle बनाया जा रहा है
    ऐसा लगता है कि इस रिसर्च दिशा पर काम करने वाले लोग ज़्यादा नहीं हैं, लेकिन खासकर अब जब लंबा attention context संभव हो रहा है, यह काफ़ी दिलचस्प हो सकता है
    अगर कोई इस क्षेत्र में काम करने वाली टीम को जानता हो, तो सहयोग में रुचि है

    • यह जानने की जिज्ञासा है कि Python bytecode पर LLM इस्तेमाल करने का कोई फ़ायदा है या नहीं
      अनुभव के आधार पर Python bytecode काफ़ी high-level होता है, इसलिए उसे सीधे source code में बदला जा सकता है
    • यह भी जिज्ञासा है कि Python ही क्यों
      Python का large-scale open source library ecosystem है, लेकिन यह नहीं लगता कि binary रूप में वितरित होने वाले software में इसका बहुत इस्तेमाल होता है
    • PyLingual है, लेकिन अफ़सोस कि यह open source नहीं है
      यह भी स्पष्ट नहीं है कि वह LLM-आधारित है या नहीं
    • ऐसा लगता है कि ज़्यादातर decompilation काम C की तरफ़ होता है
      binary में compile होने वाले Python project ज़्यादा नहीं दिखते

  • मैं खुद भी ऐसा कुछ करने की योजना बना रहा था
    कभी न कभी कोई binary input → अच्छा source code output pipeline ज़रूर बना लेगा, लेकिन लगता है कि उसमें अभी कुछ साल लगेंगे
    मुझे ऐसा इसलिए लगता है क्योंकि इस समस्या के अंत में बहुत बड़ा पैसा जमा नहीं दिखता, हालांकि मैं ग़लत भी हो सकता हूँ
    एक अच्छा अस्थायी तरीका यह होगा कि Ghidra को headless mode में चलाने वाली decompilation pipeline बनाई जाए और decompiler की सख़्त syntactic accuracy को LLM की intuitive क्षमता के साथ जोड़ा जाए
    AlphaGeometry की तरह, decompiler और LLM को एक-दूसरे की कमज़ोरियाँ पूरी करनी होंगी: https://deepmind.google/discover/blog/alphageometry-an-olymp...
    और AICI जैसी किसी चीज़ को glue की तरह इस्तेमाल करके C source generation को orchestrate करने का तरीका भी चाहिए: https://github.com/microsoft/aici
    LLM के weights का इस्तेमाल grammatically सही C source बनाने में करने के बजाय, उससे variable names, snippet patterns, और architecture choices पर सोचने दिया जाए, और Ghidra या LLVM जैसे tools बाकी काम संभालें, तो यह ज़्यादा बेहतर होगा
    यह कुछ हद तक हाथ हिलाकर की गई एक पूर्व graduate student की armchair टिप्पणी जैसी बात है, लेकिन इन शोधकर्ताओं का इसमें कूदना वाकई शानदार है, और authors ने future work में Ghidra integration का ज़िक्र किया है, तो दिशा सही लगती है

  • यह दिलचस्प है कि 6B model ने 33B model से बेहतर किया
    जिज्ञासा है कि क्या इसका मतलब है कि 33B model को और ज़्यादा training data चाहिए
    लगभग 10 लाख C programs पर pretrain किए गए model की तुलना, खरबों tokens पर train किए गए DeepSeek-Coder से करने पर, data की मात्रा में कई orders of magnitude का फ़र्क है
    यह भी जानने की जिज्ञासा है कि non-LLM solutions की तुलना में यह कैसा है

    • ऐसा रुझान LLM में काफ़ी समय से दिखता रहा है
      ज़्यादातर LLM काफ़ी undertrained होते हैं, और 7B model mainstream models में अपेक्षाकृत कम undertrained रहा है, इसलिए LLM fine-tuning community में यह काफ़ी फैला
    • 33B model को train करना आसान नहीं है
      standard approach के तहत सीधी naive fine-tuning में बड़े models को train करना मुश्किल होता है, और सिर्फ data की मात्रा ही नहीं बल्कि data curation, learning rate, और decay जैसे सभी तत्व final performance को प्रभावित करते हैं
    • लगभग 10 लाख C programs और 2 trillion tokens की इतनी सीधी तुलना की जा सकती है या नहीं, इस पर संदेह है
      उसके लिए यह मानना पड़ेगा कि उन C programs का औसत आकार 20 लाख tokens से कई orders of magnitude छोटा है, जो वास्तव में संभव तो हो सकता है, लेकिन काफ़ी आशावादी धारणा लगती है

  • अगर यह सफल होता है, तो क्या इसका मतलब होगा कि compiler के machine code को 1:1 में replicate किया जा रहा है
    अगर हाँ, तो इसका मतलब होगा कि पूरा code latent space के भीतर probability distribution के रूप में मौजूद हो सकता है
    या फिर, ज़्यादा संभव यह हो सकता है कि यह सिर्फ logic को replicate करे और फिर उसे target language में translate करे
    जिन binaries को compile करने के लिए non-deterministic inputs, जैसे key या hash, चाहिए होते हैं, वे शायद टूट जाएँगे
    यह सचमुच बहुत दिलचस्प है

  • यह चौंकाने वाला है कि GPT-4 तुलना में अभी भी काफ़ी अच्छा कर रहा है
    यह model compile होने वाला code तो इससे कहीं बेहतर बना देता है, लेकिन सही तरह काम करने वाले code को reproduce करने में इसकी accuracy कम है
    फिर भी यह काफ़ी प्रभावशाली है

    • GPT-4 decompilation के लिए सीधे train किया गया model नहीं है, फिर भी यह बहुत प्रभावशाली है
      model को बेहतर बनाया जा रहा है, इसलिए updates पर नज़र बनाए रखें
    • अगर यह तरीका C जितना ही C++ पर भी अच्छा काम करे, तो वह प्रभावशाली होगा, लेकिन यहाँ ऐसा नहीं है