LLM4Decompile - Teknologi dekompilasi kode biner dengan LLM

 (github.com/albertan017)
2 poin oleh GN⁺ 2024-03-18 | 1 komentar | Bagikan ke WhatsApp
  • LLM4Decompile adalah proyek model bahasa besar sumber terbuka yang mengembalikan biner Linux x86_64 menjadi kode sumber C yang dapat dibaca manusia pada tingkat optimisasi GCC O0~O3
  • Pendekatannya adalah mengubah biner menjadi assembly dengan Objdump, lalu LLM mendekompilasinya menjadi kode C; tersedia juga seri LLM4Decompile-Ref yang menyempurnakan pseudocode keluaran Ghidra
  • Model tersedia secara publik dalam skala 1.3B~22B, dan llm4decompile-9b-v2 mencatat tingkat re-executability 64,9% pada benchmark Decompile
  • Metrik evaluasinya adalah re-executability, yang melihat apakah kode hasil dekompilasi dapat berjalan dengan benar dengan lolos pengujian yang telah ditentukan; benchmark yang digunakan adalah HumanEval-Decompile berisi 164 fungsi C dan ExeBench berisi 2.621 fungsi
  • Pada 2025 proyek ini merilis decompile-bench dan SK²Decompile, dan sedang diperluas dengan target integrasi lebih banyak arsitektur, konfigurasi, dan alat dekompilasi

Tujuan dan cakupan dukungan LLM4Decompile

  • LLM4Decompile adalah proyek model bahasa besar sumber terbuka yang dikhususkan untuk dekompilasi
  • Versi saat ini mendekompilasi biner Linux x86_64 menjadi kode sumber C yang dapat dibaca manusia dalam rentang tingkat optimisasi GCC O0~O3
  • Proyek ini sedang diperluas untuk mendukung arsitektur dan konfigurasi yang lebih luas
  • Ada dua cara penggunaan utama
    • LLM4Decompile-End: seri model yang mendekompilasi biner secara langsung
    • LLM4Decompile-Ref: seri model yang menyempurnakan pseudocode hasil dekompilasi Ghidra dengan LLM

Alur pelatihan dan evaluasi dekompilasi

  • Proses kompilasi dimulai dari kode sumber C, lalu melalui praproses, kompilasi, assembly, dan linking untuk menghasilkan file executable
  • Dekompilasi mengikuti proses ini secara terbalik, mengubah kode biner kembali menjadi file sumber
  • Karena LLM tidak dapat memproses data biner secara langsung, biner harus terlebih dahulu di-disassemble menjadi bahasa assembly dengan Objdump
  • README menjelaskan bahwa biner dan ASM hasil disassembly dapat dikonversi satu sama lain, sehingga diperlakukan setara
  • Dalam pelatihan, loss dihitung antara kode hasil dekompilasi dan kode sumber asli, sementara evaluasi memeriksa fungsionalitas berdasarkan apakah kode lolos test assertion

Metrik evaluasi dan benchmark

  • Metrik inti adalah Re-executability
    • Memeriksa apakah kode hasil dekompilasi berjalan dengan benar
    • Mengevaluasi apakah kode lolos semua test case yang telah ditentukan
  • HumanEval-Decompile adalah kumpulan 164 fungsi C yang hanya bergantung pada pustaka standar C
  • ExeBench adalah kumpulan 2.621 fungsi yang diambil dari proyek nyata
    • Mencakup fungsi kustom, struct, dan makro

Model yang dirilis dan performanya

  • LLM4Decompile mencakup model berskala 1.3B~33B parameter, dan modelnya dirilis di Hugging Face
  • Tingkat re-executability model utama adalah sebagai berikut
  • Seri V1.5 dilatih dengan dataset yang lebih besar berisi 15B token dan panjang token maksimum 4.096, dan disebut mengalami peningkatan performa lebih dari 100% dibanding model sebelumnya
  • Seri V2 berbasis Ghidra, dan dilatih dengan 2B token untuk menyempurnakan pseudocode dekompilasi yang dibuat Ghidra
  • Disebutkan bahwa 22B-V2 menunjukkan performa tambahan 40,1% lebih tinggi dibanding 6.7B-V1.5

Rilis terbaru

  • Pada 4 Oktober 2025, SK²Decompile dirilis
    • Tahap 1 Structure Recovery, yaitu tahap Skeleton, mengubah biner atau pseudocode menjadi representasi antara yang terobfuskasi
    • Tahap 2 Identifier Naming, yaitu tahap Skin, menghasilkan kode sumber yang dapat dibaca manusia dengan identifier yang bermakna
    • Tautan model: sk2decompile-struct-6.7b, sk2decompile-ident-6.7
  • Pada 20 Mei 2025, decompile-bench dirilis
    • Mencakup 2 juta pasangan fungsi biner-sumber untuk pelatihan
    • Mencakup 70 ribu pasangan fungsi untuk evaluasi
    • Rincian ada di folder decompile-bench
  • Pada 17 Oktober 2024, decompile-ghidra-100k dirilis
    • Mencakup total 100.000 sampel pelatihan, masing-masing 25.000 untuk setiap tingkat optimisasi
    • Menyediakan skrip pelatihan yang berjalan sekitar 3,5 jam pada satu GPU A100 40G
    • Biaya reproduksi cepat totalnya kurang dari 20 dolar, dan mencapai re-executability 0,26
  • Pada 23 September 2024, LLM4Decompile-9B-v2 dirilis
    • Di-fine-tune berdasarkan Yi-Coder-9B
    • Mencapai re-executability 0,6494 pada benchmark Decompile

Alur penggunaan

  • Quick start terdiri dari cloning repository, membuat environment Conda, dan menginstal requirements.txt
  • Tahap praproses mengompilasi kode C menjadi biner dengan GCC, lalu mengekstrak instruksi assembly dengan objdump -d
  • Nama fungsi harus diganti dari func0 pada contoh menjadi nama fungsi yang ingin didekompilasi
  • Assembly input diharapkan berbentuk sebagai berikut
    • <FUNCTION_NAME>:
    • Beberapa baris instruksi assembly berikutnya
  • Tahap dekompilasi memuat model Hugging Face dengan AutoTokenizer dan AutoModelForCausalLM dari transformers, lalu menghasilkan kode C dari prompt assembly
  • Penggunaan Docker juga tersedia
    • Setelah membangun image, jalankan container dengan opsi GPU
    • Proyek menyediakan alur menjalankan demo.py di direktori ghidra

Format data HumanEval-Decompile

  • Data HumanEval-Decompile disimpan sebagai daftar JSON di llm4decompile/decompile-eval/decompile-eval-executable-gcc-obj.json
  • Jumlah sampel adalah 164*4, yaitu 164 fungsi dikalikan tingkat optimisasi O0, O1, O2, O3
  • Setiap sampel memiliki 5 kunci
    • task_id: ID masalah
    • type: tahap optimisasi, salah satu dari O0, O1, O2, O3
    • c_func: jawaban C untuk masalah HumanEval
    • c_test: test assertion C
    • input_asm_prompt: instruksi assembly dan prompt
  • Skrip evaluasi ada di folder evaluation

Item yang sedang dikerjakan dan lisensi

  • Item yang sedang dikerjakan mencakup dataset pelatihan yang lebih besar dan proses pembersihannya, dukungan untuk bahasa, platform, dan konfigurasi populer, dukungan file executable, serta integrasi dengan alat dekompilasi seperti Ghidra dan Rizin
  • Dataset pelatihan yang lebih besar dan dukungan file executable ditandai sebagai item yang selesai pada 13 Mei 2024
  • Repository kode dilisensikan dengan MIT License dan DeepSeek License
  • Makalahnya tersedia di arXiv:2403.05286, dan proyek ini juga menyediakan materi Colab dan YouTube

Bacaan terkait

1 komentar

 
GN⁺ 2024-03-18
Opini Hacker News

  • Idenya menarik, tetapi saya penasaran apakah hasilnya bisa dipercaya
    Jika dikompilasi ulang, kode mesin yang dihasilkan bisa berbeda, sehingga sulit mengidentifikasi halusinasi; saya khawatir terutama pada struktur baru yang mungkin menjadi inti kode, kegagalannya terjadi diam-diam
    Saya juga penasaran apakah saat dijalankan dengan cara generatif, ada metode agar LLM ikut melaporkan tingkat keyakinan untuk bagian tertentu; pada akhirnya sepertinya tetap perlu pemeriksaan manusia

    • Karena itu konversi bolak-balik penting
      Setelah biner didekompilasi balik menjadi sumber, lalu dikompilasi lagi menjadi biner, hasilnya harus sama dengan biner asli; cukup ulangi sampai kehilangan turun ke tingkat yang dapat diterima
      Reinforcement learning sangat cocok untuk masalah seperti ini, dan memang dikenal luar biasa efektif pada tipe semacam ini
    • LLM pada dasarnya bersifat probabilistik, jadi cukup bekerja baik di ranah yang tidak menuntut presisi seperti pemrosesan bahasa alami, tetapi secara pribadi saya melihat penggunaannya untuk dekompilasi atau disassembly lebih mendekati kasus “salah memilih alat”
      Ini mungkin eksperimen untuk menjajaki meme yang umum belakangan ini, “pakai saja LLM”, tetapi argumen tandingannya yang lebih besar adalah decompiler yang sudah ada telah bekerja lebih baik dengan komputasi jauh lebih sedikit
    • Gunakan alat verifikasi formal yang menerima input, output, serta bukti formal bahwa input konsisten dengan makna output, lalu minta LLM membuat bukti itu bersama outputnya
      Setelah itu, alat verifikasi dapat memeriksa apakah hasilnya benar berdasarkan bukti yang diberikan LLM
      Tentu, membangun dan melatih LLM yang mampu membuat bukti semacam itu adalah tantangan yang lebih besar, tetapi ini bisa menjadi cara aman untuk menangkap halusinasi
    • Bisa juga memakai differential fuzzing
    • Meski tidak sepenuhnya bisa dipercaya, saat memodifikasi biner biasanya cukup mengubah beberapa fungsi saja
      Jadi cukup kompilasi ulang beberapa fungsi itu saja

  • Jika kita tahu developer yang membuat aplikasinya, menarik untuk melihat apakah kode mereka di masa lalu bisa digunakan sebagai data latih untuk melatih modul dekompilasi
    Misalnya Super Mario 64 dan Zelda 64 sudah sepenuhnya didekompilasi, dan gim N64 lain juga sedang dikerjakan; saya penasaran apakah kita bisa memetakan developer yang terlibat dalam dua gim itu, bahkan memperkirakan siapa membuat modul apa, lalu memanfaatkannya untuk mendekompilasi gim lain
    Jika ini benar-benar menjadi bagus, kita bisa bermimpi tentang kehidupan di mana semua binary blob di dalam PC diuraikan, driver dibuka, bahkan OS pun dibongkar
    Kita juga bisa membayangkan tidak puas dengan Linux, lalu menghidupkan kembali Windows XP, mem-backport keamanan modern dan kompatibilitas aplikasi, sementara Windows 11 milik Microsoft dibiarkan begitu saja

    • Decompiler sudah ada dan kinerjanya juga bagus
      Jika LLM dapat melakukan hal yang sama seperti decompiler yang sudah ada, para pengacara kemungkinan besar akan melihatnya sebagai prosedur yang setara
      Masalah intinya bukan teknis, melainkan hukum dan politik
    • Dalam tesis sarjana saya, saya membahas topik serupa; ada penelitian bahwa dalam kondisi tertentu, hanya dengan melihat biner yang sudah dikompilasi, kita dapat melatih classifier identifikasi penulis yang menebak siapa yang menulis program tersebut
      Saya tidak terlalu tahu contoh penggunaannya yang benar-benar berguna, tetapi menarik bahwa gaya coding individu tetap tersisa setelah proses kompilasi, sehingga program terkompilasi milik masing-masing orang dapat dibedakan
    • Sepertinya kode asli yang benar-benar ditulis tidak bisa diidentifikasi
      Hasilnya akan sangat mirip dengan aslinya, tetapi banyak elemen gaya kode hilang, dan gaya yang tampak tersisa pun umumnya lebih dekat ke halusinasi

  • Karena mudah membuat dataset pasangan input/output dalam jumlah besar dari kode C publik, ini adalah kasus penggunaan yang sangat bagus untuk fine-tuning LLM

    • Menghasilkan sangat banyak kode C dengan coding LLM, misalnya model seperti DeepSeek, lalu memverifikasi apakah kode itu dapat dikompilasi dan menggunakannya sebagai data latih sintetis juga tampaknya cukup menguntungkan dalam situasi ini
      Biasanya kualitas data latih sintetis menjadi kekhawatiran besar, tetapi di sini fakta bahwa kodenya dapat dikompilasi adalah hal kuncinya

  • Jika saya membaca angka re-executability pada gambar hasil dengan benar, idenya memang bagus, tetapi tampaknya tidak bekerja dengan baik dalam praktik
    https://raw.githubusercontent.com/albertan017/LLM4Decompile/...
    Sebagai tambahan, re-executability adalah metrik utama untuk mengukur akurasi semantik
    Hasil dekompilasi dikompilasi ulang dan test case dijalankan untuk menilai apakah logika dan perilaku program dipertahankan; recompilability dan re-executability masing-masing menunjukkan pemulihan sintaks dan pelestarian semantik

  • Masalah ini menarik setidaknya dari dua sisi
    Pertama, decompiler ideal dapat melemahkan makna kode sumber proprietari
    Kedua, karena kode C terbuka melimpah, mudah membuat dataset pasangan assembly dan kode sumber, dengan beragam tingkat optimisasi, compiler, dan platform
    Namun saya penasaran mengapa para penulis melakukan fine-tuning DeepSeek-Coder
    Saya juga penasaran apakah LLM bisa dilatih dari awal dengan dataset serupa, seberapa besar ukurannya, dan apakah bisa dijalankan secara lokal

    • Sebagian besar kode proprietari berjalan di balik firewall, jadi tidak akan terlalu terdampak oleh pendekatan seperti ini
      Meski pekerjaan yang diinginkan tidak terlalu dekat dengan model awal, hampir selalu lebih baik memulai dari model pralatih daripada dari inisialisasi acak
    • Decompiler ideal tidak ada
      Karena compiler kehilangan informasi, dalam suatu pengertian ia tidak akan pernah bisa ada; bahkan jika dilihat dari sudut pandang yang longgar sebagai “pemahaman tingkat tinggi atas kode hasil”, ini adalah masalah setara AGI di bidang keamanan komputer
      Belum ada siapa pun yang mendekatinya
    • Melatih model bahasa dari awal membutuhkan banyak data
      Llama2 dikembangkan dengan 2 triliun token, tetapi dataset ini hanya sekitar 4 miliar token
      Ukuran model yang tepat juga tidak mudah ditentukan begitu saja; dalam eksperimen, model 7 miliar parameter menunjukkan executability 21%, sedangkan model 1 miliar parameter hanya 10%
      Namun recompilability keduanya cukup mirip
      Model 1 miliar parameter membutuhkan minimal 2GB memori GPU, sehingga mungkin di sebagian besar GPU; model 7 miliar membutuhkan 14GB, cocok untuk kelas 3090/4090
      Untuk model 33 miliar, opsi satu kartu adalah A100 80GB; secara teknis mungkin juga di MacBook, tetapi kemungkinan besar Anda tidak ingin benar-benar memakainya
    • Sepertinya karena perbedaan biaya antara pelatihan dan fine-tuning
      Bisa juga itu titik awal untuk memvalidasi idenya

  • Sedang membuat decompiler berbasis LLM untuk bytecode Python https://github.com/kukas/deepcompyle
    Sepertinya tidak banyak orang yang mengerjakan arah riset ini, tetapi menurut saya ini bisa cukup menarik, terutama sekarang ketika konteks perhatian yang panjang menjadi memungkinkan
    Jika ada yang tahu tim yang menangani bidang ini, saya tertarik untuk berkolaborasi

    • Saya penasaran apakah ada manfaat memakai LLM untuk bytecode Python
      Berdasarkan pengalaman, bytecode Python sudah cukup tingkat tinggi sehingga bisa langsung dikonversi menjadi kode sumber
    • Saya penasaran mengapa Python
      Python memang memiliki ekosistem pustaka open-source yang besar, tetapi saya tidak melihatnya banyak dipakai untuk perangkat lunak yang didistribusikan dalam bentuk biner
    • Ada PyLingual, tetapi sayangnya bukan open-source
      Juga belum jelas apakah berbasis LLM
    • Sepertinya pekerjaan dekompilasi lebih banyak di sisi C
      Tampaknya tidak banyak proyek Python yang dikompilasi menjadi biner

  • Saya sempat berencana mencoba hal seperti ini
    Suatu saat nanti seseorang akan menembus pipeline input biner → output kode sumber yang bagus, tetapi rasanya masih butuh beberapa tahun lagi
    Saya melihatnya begitu karena tampaknya tidak ada uang besar yang menumpuk di ujung masalah ini, meski saya bisa saja salah
    Pendekatan sementara yang baik adalah membuat pipeline dekompilasi yang menjalankan Ghidra dalam mode headless, lalu menggabungkan ketepatan sintaksis decompiler yang ketat dengan kemampuan intuitif LLM
    Seperti AlphaGeometry, decompiler dan LLM harus saling menutupi kelemahan masing-masing: https://deepmind.google/discover/blog/alphageometry-an-olymp...
    Selain itu, diperlukan cara seperti memakai sesuatu semacam AICI sebagai perekat untuk mengoordinasikan pembuatan sumber C: https://github.com/microsoft/aici
    Daripada memakai bobot LLM untuk menghasilkan sumber C yang benar secara tata bahasa, lebih baik membuatnya memikirkan nama variabel, pola snippet, dan pilihan arsitektur, lalu menyerahkan sisanya kepada alat seperti Ghidra atau LLVM
    Ini memang komentar ala kursi malas dari mantan mahasiswa pascasarjana yang agak banyak hand-waving, tetapi hebat bahwa para peneliti ini terjun ke sana, dan melihat para penulis menyebut integrasi Ghidra dalam pekerjaan mendatang, arahnya tampak benar

  • Menarik bahwa model 6 miliar lebih baik daripada model 33 miliar
    Saya penasaran apakah itu berarti model 33 miliar membutuhkan lebih banyak data pelatihan
    Jika membandingkan pralatih dengan sekitar 1 juta program C dan DeepSeek-Coder yang dilatih pada skala triliunan token, jumlah datanya berbeda beberapa orde magnitudo
    Saya juga penasaran bagaimana hasilnya jika dibandingkan dengan solusi non-LLM

    • Tren seperti ini sudah cukup lama berlangsung di LLM
      Sebagian besar LLM sangat kurang terlatih, dan model 7 miliar termasuk yang relatif tidak terlalu kurang terlatih di antara model arus utama, sehingga banyak menyebar di komunitas fine-tuning LLM
    • Melatih model 33 miliar tidak mudah
      Dalam fine-tuning naif yang sekadar mengikuti cara standar, pelatihan model besar itu rumit, dan bukan hanya jumlah data, melainkan semua faktor seperti kurasi data, learning rate, dan decay memengaruhi performa akhir
    • Saya ragu apakah sekitar 1 juta program C dan 2 triliun token bisa dibandingkan begitu saja
      Untuk itu, harus diasumsikan bahwa ukuran rata-rata program C tersebut beberapa orde magnitudo lebih kecil dari 2 juta token; meski sebenarnya bisa saja begitu, ini terdengar seperti asumsi yang cukup optimistis

  • Saya penasaran apakah, jika berhasil, ini berarti mereplikasi 1:1 kode mesin dari compiler
    Jika demikian, artinya kode lengkap bisa ada sebagai distribusi probabilitas di dalam ruang laten
    Atau, yang lebih mungkin, bentuknya mungkin hanya mereplikasi logikanya lalu menerjemahkannya ke bahasa target
    Biner yang memerlukan input non-deterministik saat kompilasi, misalnya kunci atau hash, tampaknya akan rusak
    Benar-benar menarik

  • Mengejutkan bahwa GPT-4 masih cukup bagus dalam perbandingan
    Model ini menghasilkan kode yang bisa dikompilasi jauh lebih baik, tetapi akurasinya lebih rendah dalam mereproduksi kode yang perilakunya benar
    Tetap saja cukup mengesankan

    • GPT-4 sangat mengesankan meski bukan model yang dilatih langsung untuk dekompilasi
      Kami sedang meningkatkan modelnya, jadi terus pantau pembaruannya
    • Akan mengesankan jika pendekatan ini juga sebaik C++ seperti pada C, tetapi di sini tidak demikian