LLM4Decompile - เทคโนโลยีถอดคอมไพล์ไบนารีโค้ดด้วย LLM

 (github.com/albertan017)
2 คะแนน โดย GN⁺ 2024-03-18 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • รีเวิร์สเอนจิเนียริงด้วยโมเดลภาษาขนาดใหญ่

1. แนะนำ LLM4Decompile และ Decompile-Eval

  • เป้าหมายคือการสร้างและเผยแพร่โอเพนซอร์ส LLM ตัวแรกที่ออกแบบมาเพื่อการถอดคอมไพล์โดยเฉพาะ และสร้างเบนช์มาร์กการถอดคอมไพล์ตัวแรกที่เน้นความสามารถในการคอมไพล์ใหม่และความสามารถในการรันใหม่เพื่อใช้ประเมินประสิทธิภาพของมัน
  • รวบรวมตัวอย่างโค้ด C จำนวนหนึ่งล้านรายการจาก AnghaBench แล้วคอมไพล์เป็นแอสเซมบลีโค้ดด้วย GCC เพื่อนำมาสร้างชุดข้อมูลคู่แอสเซมบลี-ซอร์สขนาด 4 พันล้านโทเค็น
  • ใช้ชุดข้อมูลนี้เพื่อทำ fine-tune โมเดลโค้ด LLM ชั้นนำอย่าง DeepSeek-Coder และสร้าง Decompile-Eval ซึ่งเป็นเบนช์มาร์กสำหรับการประเมินโดยอิงจากคำถาม HumanEval และตัวอย่างทดสอบ
  • การประเมินทำจากสองมุมมอง คือโค้ดที่ถอดคอมไพล์แล้วสามารถคอมไพล์ใหม่ได้สำเร็จหรือไม่ และสามารถผ่าน assertion ทั้งหมดใน test case ได้หรือไม่

2. ผลการประเมิน

เมตริก

  • ความสามารถในการคอมไพล์ใหม่ และ ความสามารถในการรันใหม่ เป็นตัวชี้วัดสำคัญในการตรวจสอบประสิทธิผลของกระบวนการถอดคอมไพล์
  • หากโค้ดที่ถอดคอมไพล์แล้วสามารถคอมไพล์ใหม่ได้ ก็เป็นหลักฐานที่ชัดเจนของความถูกต้องสมบูรณ์ทางไวยากรณ์
  • แต่ไวยากรณ์เพียงอย่างเดียวไม่สามารถรับประกันได้ว่าโค้ดจะมีความหมายเหมือนกับโปรแกรมต้นฉบับ ดังนั้นความสามารถในการรันใหม่จึงเป็นตัวชี้วัดสำคัญสำหรับประเมินความถูกต้องเชิงความหมาย
  • ความสามารถในการคอมไพล์ใหม่และความสามารถในการรันใหม่สะท้อนถึงการกู้คืนไวยากรณ์และการคงไว้ซึ่งความหมาย ซึ่งเป็นสิ่งจำเป็นสำหรับการถอดคอมไพล์ที่ใช้งานได้จริงและมีความทนทาน

3. วิธีใช้งานโมเดล

  • LLM4Decompile มีโมเดลตั้งแต่ 1.3 พันล้านถึง 33 พันล้านพารามิเตอร์ และสามารถใช้งานได้บน Hugging Face
  • ตัวอย่างโมเดล: llm4decompile-1.3b, llm4decompile-6.7b, llm4decompile-33b, llm4decompile-6.7b-nsp, llm4decompile-6.7b-uo
  • โมเดล NSP ถูกฝึกด้วยแอสเซมบลีโค้ด และมีค่าเฉลี่ยความสามารถในการรันใหม่ประมาณ 0.17
  • โมเดล UO ถูกฝึกโดยไม่มีความรู้ล่วงหน้าเกี่ยวกับระดับการเพิ่มประสิทธิภาพ (O0~O3) และมีค่าเฉลี่ยความสามารถในการรันใหม่ประมาณ 0.21
  • ตัวอย่างการใช้งานโมเดล: คอมไพล์โค้ด C เป็นไบนารี, ทำ disassemble ไบนารีเป็นคำสั่งแอสเซมบลี, แล้วใช้ LLM4Decompile แปลคำสั่งแอสเซมบลีกลับเป็น C

4. วิธีใช้ Decompile-Eval

  • ข้อมูลถูกจัดเก็บเป็นรายการ JSON ใน llm4decompile/decompile-eval/decompile-eval.json
  • มีทั้งวิธีรันการประเมินบน GPU เดี่ยวและโปรเซสเดียว รวมถึงวิธีใช้งาน TGI (เร็วขึ้น 10 เท่า รองรับหลาย GPU และหลายโปรเซส)

5. สิ่งที่กำลังดำเนินการ

  • LLM4Binary: มีแผนจะเพิ่มชุดข้อมูลขนาดใหญ่ขึ้นเพื่อ pre-train โมเดลด้วยแอสเซมบลีโค้ดและโค้ด C
  • Decompiler-ALL: มีแผนรองรับภาษา/แพลตฟอร์มและการตั้งค่าเพิ่มเติมมากขึ้น (เช่น การถอดคอมไพล์หลายฟังก์ชัน)

6. ใบอนุญาต

  • ใบอนุญาต MIT

ความเห็นของ GN⁺

  • LLM4Decompile นำเสนอแนวทางที่พลิกโฉมเมื่อเทียบกับวิธีถอดคอมไพล์ไบนารีแบบเดิม โดยเฉพาะการใช้โมเดลภาษาขนาดใหญ่เพื่อให้การถอดคอมไพล์มีความแม่นยำและมีประสิทธิภาพมากขึ้น
  • เทคโนโลยีนี้อาจมีประโยชน์มากในด้านความปลอดภัยซอฟต์แวร์ และช่วยในการวิเคราะห์มัลแวร์หรือการบำรุงรักษาระบบเลกาซีได้
  • การที่ความสามารถในการรันใหม่ของโค้ดที่ถอดคอมไพล์แล้วยังไม่สมบูรณ์ บ่งชี้ว่าเทคโนโลยีนี้ยังมีพื้นที่ให้พัฒนา และยังต้องมีการวิจัยเพิ่มเติมเพื่อเพิ่มความแม่นยำและประสิทธิภาพในสภาพแวดล้อมจริง
  • เครื่องมือเดิมที่มีความสามารถคล้ายกันมีทั้งดีคอมไพเลอร์เชิงพาณิชย์และโอเพนซอร์สอย่าง Ghidra และ IDA Pro แต่ LLM4Decompile นำเสนอแนวทางใหม่ที่อิงกับแมชชีนเลิร์นนิง
  • เมื่อนำเทคโนโลยีนี้มาใช้ ควรพิจารณาคุณภาพและขอบเขตของข้อมูลฝึก ความแม่นยำของโมเดล ความเร็วในการทำงาน เป็นต้น โดยข้อดีคือความแม่นยำและความยืดหยุ่นที่สูง แต่ข้อเสียอาจเป็นความซับซ้อนของโมเดลขนาดใหญ่และความต้องการทรัพยากรคอมพิวต์ที่สูง

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-03-18
ความคิดเห็นบน Hacker News

  • ความเห็นเกี่ยวกับผลลัพธ์ด้าน "ความสามารถในการรันซ้ำ":

    • ความสามารถในการรันซ้ำเป็นวิธีสำคัญในการวัดความถูกต้องเชิงความหมาย โดยจะนำผลลัพธ์ที่ดีคอมไพล์ได้ไปคอมไพล์ใหม่และรันชุดทดสอบเพื่อประเมินว่าตรรกะและพฤติกรรมของโปรแกรมยังคงถูกรักษาไว้หรือไม่ ความสามารถในการคอมไพล์ใหม่และรันซ้ำสะท้อนถึงการกู้คืนไวยากรณ์และการคงไว้ซึ่งความหมาย ซึ่งเป็นสิ่งจำเป็นสำหรับการดีคอมไพล์ที่ใช้งานได้จริงและมีความทนทาน

  • คำถามเกี่ยวกับความน่าเชื่อถือของผลลัพธ์ที่ดีคอมไพล์:

    • เป็นคำถามสำคัญว่าผลลัพธ์ที่ดีคอมไพล์นั้นเชื่อถือได้หรือไม่ การคอมไพล์ใหม่อาจสร้าง machine code ที่แตกต่างออกไป และอาจทำให้ยากต่อการระบุโครงสร้างใหม่ ๆ โดยเฉพาะในส่วนที่อาจเป็นแกนสำคัญของโค้ด จึงสงสัยว่ามีวิธีที่ LLM จะรายงานระดับความเชื่อมั่นต่อบางส่วนโดยเฉพาะระหว่างการสร้างผลลัพธ์หรือไม่ ดูแล้วน่าจะยังต้องอาศัยการตรวจสอบโดยมนุษย์

  • กรณีใช้งานที่ยอดเยี่ยมสำหรับการ fine-tune LLM:

    • นี่เป็นกรณีใช้งานที่ยอดเยี่ยมสำหรับการ fine-tune LLM เพราะสามารถสร้างชุดข้อมูลขนาดใหญ่ของคู่ข้อมูลอินพุต/เอาต์พุตจากโค้ด C ที่เปิดเผยต่อสาธารณะได้ง่าย

  • ความสนใจเกี่ยวกับการฝึกโมดูลดีคอมไพล์ตามฐานนักพัฒนา:

    • น่าสนใจว่าจะสามารถฝึกโมดูลดีคอมไพล์โดยอิงจากแอปพลิเคชันที่นักพัฒนารายใดรายหนึ่งเคยทำงานได้หรือไม่ ตัวอย่างเช่น Super Mario 64 และ Zelda 64 ถูกดีคอมไพล์เสร็จสมบูรณ์แล้ว และเกม N64 อื่น ๆ ก็ยังอยู่ระหว่างดำเนินการ จึงสงสัยว่าจะทำให้การดีคอมไพล์เกมอื่นที่นักพัฒนาเหล่านั้นเคยสร้างทำได้ง่ายขึ้นหรือไม่

  • ความสนใจเกี่ยวกับกรณีใช้งานในอุดมคติของดีคอมไพเลอร์และการสร้างชุดข้อมูล:

    • ดีคอมไพเลอร์ในอุดมคติจะช่วยลบข้อจำกัดจากการไม่มีซอร์สโค้ดที่เป็นกรรมสิทธิ์ ด้วยความอุดมสมบูรณ์ของโค้ด C ที่เปิดให้ใช้งานสาธารณะ จึงสามารถสร้างชุดข้อมูลที่เป็นคู่ของ ASM กับซอร์สโค้ดได้อย่างง่ายดาย

  • การแนะนำโปรเจกต์ดีคอมไพเลอร์แบบ LLM ที่กำลังพัฒนาโดยบุคคลหนึ่ง:

    • กำลังพัฒนาดีคอมไพเลอร์แบบ LLM สำหรับ Python bytecode อยู่ แม้จะมีคนทำงานในทิศทางการวิจัยนี้ไม่มากนัก แต่คิดว่าน่าสนใจได้มากขึ้นเมื่อมี long attention context หากมีทีมที่เหมาะจะร่วมงานก็สนใจความร่วมมือ

  • ความกังวลเกี่ยวกับ benchmark ที่ไม่มีการเปรียบเทียบกับแนวทางที่ใช้ AI:

    • การได้เห็นแนวทางหลากหลายเป็นเรื่องดี แต่ถ้าไม่มีการเปรียบเทียบกับแนวทางที่ไม่ใช้ AI เช่น IDA Pro benchmark อาจไม่มีความหมายมากนัก น่าสนใจที่จะเห็นว่าโมเดลนี้ทำผลงานได้อย่างไรตามเมตริกในงานวิจัยด้านความปลอดภัย

  • ความสนใจต่อความต่างอย่างมากระหว่างคะแนนความสามารถในการคอมไพล์ใหม่และการรันซ้ำ:

    • GPT4 ทำคะแนนความสามารถในการคอมไพล์ใหม่ได้ระดับ 8x% (ถูกต้องตามไวยากรณ์) แต่กลับได้เพียง 1x% ที่ย่ำแย่ในด้านความสามารถในการรันซ้ำ (ถูกต้องตามแนวคิด) ซึ่งแสดงให้เห็นอีกครั้งถึงความสามารถในการเลียนแบบที่มากเกินไปของมัน

  • ความสงสัยเกี่ยวกับการเปรียบเทียบกับดีคอมไพเลอร์ที่ไม่ใช่ LLM:

    • สงสัยว่าเมื่อเทียบกับดีคอมไพเลอร์ที่ไม่ใช่ LLM อย่าง IDA, Binja เป็นต้น จะเป็นอย่างไร เพราะเห็นแต่การเปรียบเทียบกับ LLM อื่นเท่านั้น

  • ความอยากรู้ว่าทำไมโมเดล 6b จึงทำได้ดีกว่าโมเดล 33b:

    • น่าสนใจที่โมเดล 6b ทำผลงานได้ดีกว่าโมเดล 33b จึงสงสัยว่าโมเดล 33b ต้องการข้อมูลฝึกมากกว่านี้หรือไม่ โดยโมเดล 33b ถูก pre-train ด้วยโปรแกรม C ราว 1 ล้านโปรแกรม ขณะที่ DeepSeek-Coder ถูกฝึกด้วย 2 ล้านล้านโทเค็น ซึ่งมากกว่าหลายลำดับขั้น