LLM4Decompile - LLM kullanan ikili kod decompile teknolojisi

 (github.com/albertan017)
2 puan yazan GN⁺ 2024-03-18 | 1 yorum | WhatsApp'ta paylaş
  • LLM4Decompile, Linux x86_64 ikililerini GCC O0~O3 optimizasyon seviyelerinde insanların okuyabileceği C kaynak koduna geri döndüren açık kaynaklı bir büyük dil modeli projesidir
  • Yaklaşımı, ikiliyi Objdump ile assembly’ye dönüştürdükten sonra LLM’in bunu C koduna decompile etmesi şeklindedir; ayrıca Ghidra çıktısı pseudo-code’u iyileştiren LLM4Decompile-Ref serisini de sunar
  • Modeller 1.3B~22B ölçeğinde yayımlanmıştır ve llm4decompile-9b-v2, Decompile benchmark’ında %64,9 yeniden çalıştırılabilirlik oranı kaydetmiştir
  • Değerlendirme metriği, decompile edilmiş kodun önceden tanımlanmış testleri geçerek düzgün çalışıp çalışmadığını ölçen yeniden çalıştırılabilirlik oranıdır; benchmark olarak HumanEval-Decompile’daki 164 C fonksiyonu ve ExeBench’teki 2.621 fonksiyon kullanılır
  • Proje 2025’te decompile-bench ve SK²Decompile’ı yayımlamış olup daha fazla mimari, ayar ve decompile aracı entegrasyonunu hedefleyerek genişlemektedir

LLM4Decompile’ın hedefi ve destek kapsamı

  • LLM4Decompile, decompile işlemine özelleşmiş açık kaynaklı bir büyük dil modeli projesidir
  • Mevcut sürüm, Linux x86_64 ikililerini GCC optimizasyon seviyesi O0~O3 aralığında insanların okuyabileceği C kaynak koduna decompile eder
  • Proje, daha geniş mimari ve ayarları desteklemek için genişletilmektedir
  • İki ana kullanım biçimi vardır
    • LLM4Decompile-End: İkilileri doğrudan decompile eden model ailesi
    • LLM4Decompile-Ref: Ghidra’nın decompile ettiği pseudo-code’u LLM ile iyileştiren model ailesi

Decompile eğitim ve değerlendirme akışı

  • Derleme süreci C kaynak kodundan başlar; önişleme, derleme, assembly’ye çevirme ve linkleme aşamalarından geçerek çalıştırılabilir dosya üretir
  • Decompile işlemi bu süreci tersinden izler ve ikili kodu yeniden kaynak dosyaya dönüştürür
  • LLM ikili verileri doğrudan işleyemediğinden ikilinin önce Objdump ile assembly diline disassemble edilmesi gerekir
  • README, ikili ile disassemble edilmiş ASM’nin birbirine dönüştürülebildiği için eşdeğer kabul edildiğini açıklar
  • Eğitimde decompile edilmiş kod ile özgün kaynak kod arasındaki kayıp hesaplanır; değerlendirmede ise test assertion’larını geçip geçmediğine bakılarak işlevsellik doğrulanır

Değerlendirme metrikleri ve benchmark’lar

  • Temel metrik Re-executability’dir
    • Decompile edilmiş kodun düzgün çalışıp çalışmadığını kontrol eder
    • Önceden tanımlanmış tüm test vakalarını geçip geçmediğini değerlendirir
  • HumanEval-Decompile, yalnızca standart C kütüphanesine bağımlı 164 C fonksiyonundan oluşan bir koleksiyondur
  • ExeBench, gerçek projelerden alınmış 2.621 fonksiyonluk bir koleksiyondur
    • Kullanıcı tanımlı fonksiyonlar, struct’lar ve macro’lar içerir

Yayımlanan modeller ve performans

  • LLM4Decompile, 1.3B~33B parametre ölçeğinde modeller içerir ve modeller Hugging Face’te yayımlanmıştır
  • Başlıca modellerin yeniden çalıştırılabilirlik oranları şöyledir
  • V1.5 serisinin 15B token’lık daha büyük bir veri kümesi ve 4.096 maksimum token uzunluğu ile eğitildiği, önceki modellere kıyasla %100’den fazla performans artışı sağladığı belirtilir
  • V2 serisi Ghidra tabanlıdır ve Ghidra’nın ürettiği decompile pseudo-code’unu iyileştirmek üzere 2B token ile eğitilmiştir
  • 22B-V2’nin 6.7B-V1.5’e göre ek olarak %40,1 daha yüksek performans gösterdiği belirtilir

Yakın zamanda yayımlananlar

  • 4 Ekim 2025’te SK²Decompile yayımlandı
      1. aşama Structure Recovery, yani Skeleton aşaması, ikiliyi veya pseudo-code’u obfuscate edilmiş bir ara temsile dönüştürür
      1. aşama Identifier Naming, yani Skin aşaması, anlamlı identifier’lara sahip, insanların okuyabileceği kaynak kod üretir
    • Model bağlantıları: sk2decompile-struct-6.7b, sk2decompile-ident-6.7
  • 20 Mayıs 2025’te decompile-bench yayımlandı
    • Eğitim için 2 milyon ikili-kaynak fonksiyon çifti içerir
    • Değerlendirme için 70 bin fonksiyon çifti içerir
    • Ayrıntılar decompile-bench klasöründe bulunur
  • 17 Ekim 2024’te decompile-ghidra-100k yayımlandı
    • Her optimizasyon seviyesi için 25.000 olmak üzere toplam 100.000 eğitim örneği içerir
    • Tek bir A100 40G GPU’da yaklaşık 3,5 saatte çalışan bir eğitim betiği sunar
    • Hızlı yeniden üretim maliyeti toplamda 20 doların altındadır ve 0,26 yeniden çalıştırılabilirlik oranına ulaşır
  • 23 Eylül 2024’te LLM4Decompile-9B-v2 yayımlandı
    • Yi-Coder-9B temel alınarak fine-tune edilmiştir
    • Decompile benchmark’ında 0,6494 yeniden çalıştırılabilirlik oranına ulaşmıştır

Kullanım akışı

  • Hızlı başlangıç; depoyu klonlama, Conda ortamı oluşturma ve requirements.txt kurulumundan oluşur
  • Önişleme aşaması, C kodunu GCC ile ikiliye derledikten sonra objdump -d ile assembly komutlarını çıkarır
  • Fonksiyon adı, örnekteki func0 yerine decompile edilecek fonksiyon adıyla değiştirilmelidir
  • Girdi assembly’sinin şu biçimde olması beklenir
    • <FUNCTION_NAME>:
    • Ardından gelen birden çok satır assembly komutu
  • Decompile aşaması, transformers içindeki AutoTokenizer ve AutoModelForCausalLM ile Hugging Face modelini yükleyip assembly prompt’unu C koduna dönüştürür
  • Docker kullanımı da mümkündür
    • İmaj derlendikten sonra container GPU seçenekleriyle çalıştırılır
    • ghidra dizininde demo.py çalıştırma akışı sunulur

HumanEval-Decompile veri biçimi

  • HumanEval-Decompile verileri llm4decompile/decompile-eval/decompile-eval-executable-gcc-obj.json içinde JSON listesi biçiminde saklanır
  • Örnek sayısı, 164 fonksiyon ile O0, O1, O2, O3 optimizasyon seviyelerinin çarpımı olan 164*4 adettir
  • Her örnekte 5 anahtar bulunur
    • task_id: problem ID’si
    • type: O0, O1, O2, O3’ten biri olan optimizasyon aşaması
    • c_func: HumanEval probleminin C çözümü
    • c_test: C test assertion’ı
    • input_asm_prompt: assembly komutları ve prompt
  • Değerlendirme betiği evaluation klasöründe bulunur

Devam eden işler ve lisans

  • Devam eden işler arasında daha büyük eğitim veri kümesi ve temizleme süreci, popüler dil/platform/ayar desteği, çalıştırılabilir dosya desteği ve Ghidra/Rizin gibi decompile araçlarıyla entegrasyon yer alır
  • Daha büyük eğitim veri kümesi ve çalıştırılabilir dosya desteği, 13 Mayıs 2024’te tamamlanan maddeler olarak işaretlenmiştir
  • Kod deposu MIT License ve DeepSeek License ile lisanslanmıştır
  • Makale arXiv:2403.05286 adresindedir; proje ayrıca Colab ve YouTube materyalleri de sunar

İlgili okumalar

1 yorum

 
GN⁺ 2024-03-18
Hacker News görüşleri

  • İlginç bir fikir, ancak sonuçların güvenilir olup olmayacağı merak konusu
    Yeniden derlendiğinde farklı makine kodu ortaya çıkabileceği için halüsinasyonları tespit etmek zor olabilir; özellikle de kodun özünü oluşturan yeni yapılarda sessizce başarısız olmasından endişe ediliyor
    Üretici şekilde çalışırken LLM’in belirli bölümler için güven skorunu da verip veremeyeceği merak ediliyor ve sonuçta insan doğrulaması gerekecek gibi görünüyor

    • Bu yüzden gidiş-dönüş dönüşümü önemli
      İkili dosya kaynak koda decompile edildikten sonra yeniden ikiliye derlendiğinde orijinal ikili dosyanın çıkması gerekir; kayıp kabul edilebilir seviyeye inene kadar bu süreç tekrarlanabilir
      Bu tür sorunlara pekiştirmeli öğrenme çok iyi uyuyor ve gerçekten de bu tip alanlarda olağanüstü etkili olduğu biliniyor
    • LLM’ler özünde olasılıksal olduğundan, doğal dil işleme gibi yüksek hassasiyet gerektirmeyen alanlarda oldukça iyi çalışsalar da, bunları decompilation ya da disassembly için kullanmak bana göre “yanlış araç seçimi”ne daha yakın
      Günümüzde yaygın olan “LLM kullanalım gitsin” mem’ini keşfetmeye yönelik bir deney olabilir, ancak daha güçlü karşı argüman şu: mevcut decompiler’lar zaten çok daha az hesaplama ile daha iyi iş çıkarıyor
    • Girdi, çıktı ve girdinin çıktının anlamıyla uyumlu olduğuna dair biçimsel kanıt alan bir biçimsel doğrulama aracı kullanılıp, LLM’in çıktıyla birlikte bu kanıtı da üretmesi sağlanabilir
      Sonrasında doğrulama aracıyla, LLM’in sunduğu kanıta göre sonucun doğru olup olmadığı kontrol edilebilir
      Elbette böyle bir kanıt üretebilen bir LLM kurup eğitmek daha da büyük bir zorluk olurdu, ama halüsinasyonları güvenli biçimde yakalamanın bir yolu olabilir
    • Diferansiyel fuzzing de kullanılabilir
    • Tam anlamıyla güvenilir olmasa bile, ikili dosyaları değiştirirken genelde yalnızca birkaç fonksiyonu değiştirmek yeterli olur
      Dolayısıyla sadece o birkaç fonksiyonu yeniden derlemek yeterlidir

  • Uygulamayı geliştiren kişileri biliyorsanız, onların geçmiş kodlarını eğitim verisi olarak kullanıp bir decompilation modülü eğitmenin mümkün olup olmayacağı ilginç
    Örneğin Super Mario 64 ve Zelda 64 tamamen decompile edildi, başka N64 oyunlarında da çalışmalar sürüyor; bu iki oyunda çalışan geliştiricileri eşleyip kimin hangi modülü yazdığını tahmin ederek bunu başka oyunların decompile edilmesinde kullanmak mümkün mü diye merak ediliyor
    Bu iş gerçekten iyi seviyeye gelirse, PC içindeki tüm ikili blob’ları çözmek, sürücüleri açığa çıkarmak ve hatta işletim sistemlerini bile açmak mümkün olabilir
    Linux’la yetinmeyip Windows XP’yi yeniden canlandırıp modern güvenliği ve uygulama uyumluluğunu geri taşımak, Microsoft’un Windows 11’ini ise olduğu gibi bırakmak bile hayal edilebilir

    • Decompiler’lar zaten var ve performansları da iyi
      Eğer LLM mevcut decompiler’larla aynı işi yapabiliyorsa, hukukçular bunu büyük olasılıkla eşdeğer bir süreç olarak değerlendirecektir
      Asıl sorun teknik değil, hukuki ve politik
    • Lisans tezinde benzer bir konu işlenmişti; belirli koşullarda, sadece derlenmiş ikili dosyalara bakarak programı kimin yazdığını tahmin eden bir yazar tanıma sınıflandırıcısı eğitilebildiğini gösteren araştırmalar vardı
      Bunun gerçekten faydalı kullanıldığı örnekleri çok bilmiyorum, ama kişinin kodlama stilinin derleme sürecinden sonra da iz bırakması ve bu sayede derlenmiş programların birbirinden ayırt edilebilmesi etkileyici
    • Gerçekte yazılmış kodun kendisini tespit etmek mümkün görünmüyor
      Sonuç orijinale çok benzeyecektir ama birçok kod stili unsuru kaybolur; görünürde kalan stil de çoğunlukla halüsinasyona yakın olur

  • Açık C koduyla büyük miktarda girdi/çıktı çifti veri kümesi oluşturmak kolay olduğundan, bu LLM ince ayarı için çok iyi bir kullanım örneği

    • DeepSeek gibi bir kodlama LLM’iyle çok fazla C kodu üretip derlenip derlenmediğini doğrulayarak bunu sentetik eğitim verisi olarak kullanmak da bu durumda oldukça avantajlı olabilir
      Normalde sentetik eğitim verisinin kalitesi büyük bir endişe kaynağıdır, ama burada esas önemli nokta kodun derlenebilmesidir

  • Sonuç görselindeki yeniden çalıştırılabilirlik değerlerini doğru okuyorsam, fikir harika ama pratikte pek iyi çalışmıyor gibi görünüyor
    https://raw.githubusercontent.com/albertan017/LLM4Decompile/...
    Ek bilgi olarak, yeniden çalıştırılabilirlik anlamsal doğruluğu ölçen temel metrik
    Decompile edilen sonuç yeniden derlenip test vakaları çalıştırılarak program mantığının ve davranışının korunup korunmadığı değerlendiriliyor; yeniden derlenebilirlik ve yeniden çalıştırılabilirlik sırasıyla sözdizimsel geri kazanımı ve anlamın korunmasını ifade ediyor

  • Bu problem en az iki açıdan ilgi çekici
    Birincisi, ideal bir decompiler tescilli kaynak kodun önemini azaltabilir
    İkincisi, herkese açık C kodu bol olduğu için assembly ile kaynak kodun eşleştirilmiş veri kümelerini oluşturmak kolay; ayrıca optimizasyon seviyesi, derleyici ve platform çeşitliliği de var
    Yine de yazarların neden DeepSeek-Coder üzerinde ince ayar yaptığı merak ediliyor
    Benzer bir veri kümesiyle bir LLM’i sıfırdan eğitmenin mümkün olup olmadığı, ne kadar büyüklüğe ihtiyaç duyulacağı ve yerelde çalıştırmanın mümkün olup olmadığı da merak konusu

    • Tescilli kodların çoğu güvenlik duvarlarının arkasında çalıştığından, bu yaklaşım bunları büyük ölçüde etkilemeyebilir
      İstenen görev başlangıç modeline tam yakın olmasa bile, rastgele başlatma yerine önceden eğitilmiş bir modelden başlamak neredeyse her zaman daha iyidir
    • İdeal bir decompiler diye bir şey yoktur
      Derleyici bilgi kaybettirdiği için bir anlamda asla var olamaz; hatta bunu “çıktı kodunun yüksek seviyeli anlaşılması” gibi daha esnek bir açıdan ele alsanız bile bu, bilgisayar güvenliği alanında AGI düzeyinde bir sorun
      Henüz hiç kimse buna yaklaşabilmiş değil
    • Bir dil modelini sıfırdan eğitmek çok veri gerektirir
      Llama2 2 trilyon token ile geliştirildi, oysa bu veri kümesi yaklaşık 4 milyar token düzeyinde
      Uygun model boyutunu belirlemek de kolay değil; deneylerde 7 milyar parametreli model %21 çalıştırılabilirlik gösterirken 1 milyar parametreli model %10’da kaldı
      Buna karşılık yeniden derlenebilirlik açısından ikisi birbirine epey yakın
      1 milyar parametreli model en az 2GB GPU belleği istiyor, bu yüzden çoğu GPU’da çalışabilir; 7 milyarlık model ise 14GB gerektiriyor ve 3090/4090 sınıfına daha uygun
      33 milyarlık model için tek kartta seçenek A100 80GB; teknik olarak MacBook’ta da mümkün olabilir ama pratikte kimsenin bunu istemesi beklenmez
    • Bunun nedeni muhtemelen eğitim maliyeti ile ince ayar maliyeti arasındaki fark
      Ayrıca bu, fikri doğrulamak için bir başlangıç noktası da olabilir

  • Python bayt kodu için LLM tabanlı bir geri derleyici üzerinde çalışılıyor: https://github.com/kukas/deepcompyle
    Bu araştırma yönünde çalışan çok kişi yok gibi görünüyor, ancak özellikle uzun attention context mümkün hale gelmişken bunun oldukça ilginç olabileceğini düşünüyorum
    Bu alanda çalışan bir ekip bilen varsa iş birliğiyle ilgileniyorum

    • Python bayt kodunda LLM kullanmanın bir avantajı olup olmadığını merak ediyorum
      Deneyimime göre Python bayt kodu yeterince yüksek seviyeli; kaynak koda doğrudan dönüştürülebilir
    • Neden Python olduğunu merak ediyorum
      Python'un büyük bir açık kaynak kütüphane ekosistemi var, ancak ikili biçimde dağıtılan yazılımlarda çok kullanıldığını düşünmüyorum
    • PyLingual var ama ne yazık ki açık kaynak değil
      LLM tabanlı olup olmadığı da net değil
    • Geri derleme işi daha çok C tarafında gibi görünüyor
      İkiliye derlenen Python projesi çok fazla yok gibi

  • Ben de böyle bir şey denemeyi planlıyordum
    Bir gün birileri ikili girdi → iyi kaynak kod çıktısı hattını çözecek, ancak bunun için hâlâ birkaç yıl var gibi görünüyor
    Bunu böyle düşünmemin nedeni, bu problemin sonunda devasa bir para yığını görünmemesi; ama yanılıyor olabilirim
    İyi bir geçici yaklaşım, Ghidra'yı headless modda çalıştıran bir geri derleme hattı kurmak ve geri derleyicinin katı sözdizimsel doğruluğunu LLM'nin sezgisel yetenekleriyle birleştirmek olurdu
    AlphaGeometry'de olduğu gibi geri derleyici ile LLM birbirinin zayıf yönlerini telafi etmeli: https://deepmind.google/discover/blog/alphageometry-an-olymp...
    Ayrıca C kaynak üretimini orkestre etmek için AICI gibi bir şeyi yapıştırıcı olarak kullanmak gerekir: https://github.com/microsoft/aici
    LLM'nin ağırlıklarını dilbilgisel olarak doğru C kaynak üretmek için kullanmak yerine, değişken adları, snippet kalıpları ve mimari seçimleri üzerine düşündürmek; geri kalanını ise Ghidra veya LLVM gibi araçlara bırakmak daha doğru olur
    Biraz el kol hareketiyle anlatılan eski bir yüksek lisans öğrencisinin koltuk yorumuna benziyor olabilir, ama bu araştırmacıların bu işe girişmiş olması etkileyici ve yazarların gelecekteki çalışmalarda Ghidra entegrasyonundan bahsetmesi, yönün doğru olduğunu düşündürüyor

  • 6 milyarlık modelin 33 milyarlık modelden daha iyi olduğu noktalar olması ilginç
    Bunun, 33 milyarlık modelin daha fazla eğitim verisine ihtiyaç duyduğu anlamına gelip gelmediğini merak ediyorum
    Yaklaşık 1 milyon C programıyla ön eğitim almış bir modeli, trilyonlarca token üzerinde eğitilmiş DeepSeek-Coder ile karşılaştırınca veri miktarında birkaç basamak fark var
    LLM olmayan çözümlerle kıyaslandığında durumun nasıl olduğunu da merak ediyorum

    • Bu eğilim LLM tarafında bir süredir görülüyor
      Çoğu LLM ciddi biçimde eksik eğitilmiş durumda ve 7 milyarlık modeller, ana akım modeller arasında nispeten daha az eksik eğitilmiş oldukları için LLM fine-tuning topluluğunda yaygınlaştı
    • 33 milyarlık modeli eğitmek kolay değil
      Standart yöntemle yapılan basit naif fine-tuning yaklaşımında büyük modelleri eğitmek zordur; yalnızca veri miktarı değil, veri temizleme, öğrenme oranı ve decay gibi tüm unsurlar nihai performansı etkiler
    • Yaklaşık 1 milyon C programı ile 2 trilyon token'ı bu kadar doğrudan karşılaştırmanın mümkün olup olmadığından emin değilim
      Bunun için söz konusu C programlarının ortalama boyutunun 2 milyon token'dan birkaç basamak küçük olduğunu varsaymak gerekir; pratikte bu mümkün olsa da kulağa epey iyimser bir varsayım gibi geliyor

  • Başarılı olursa bunun, derleyicinin makine kodunu 1:1 kopyalamak anlamına gelip gelmediğini merak ediyorum
    Eğer öyleyse bu, tam kodun latent uzay içinde olasılık dağılımı olarak var olabileceği anlamına gelir
    Ya da daha muhtemel olarak yalnızca mantığı kopyalayıp sonra hedef dile çeviren bir yapı olabilir
    Derleme için anahtar veya hash gibi deterministik olmayan girdiler gerektiren ikililer muhtemelen bozulacaktır
    Gerçekten çok ilginç

  • GPT-4'ün karşılaştırmada hâlâ oldukça iyi performans göstermesi şaşırtıcı
    Bu modelden çok daha iyi derlenebilir kod üretebiliyor, ancak davranışı doğru olan kodu yeniden üretme doğruluğu daha düşük
    Yine de oldukça etkileyici

    • GPT-4, geri derleme için doğrudan eğitilmiş bir model olmamasına rağmen çok etkileyici
      Modeli geliştiriyoruz, o yüzden güncellemeleri takip etmeye devam edin
    • Bu yöntem C kadar C++ için de iyi çalışsaydı etkileyici olurdu, ama burada öyle görünmüyor