เปิดตัวบน HN: ส่วนขยาย Ghidra สำหรับส่งออกบางส่วนของโปรแกรมเป็นอ็อบเจกต์ไฟล์

 (github.com/boricj)
1 คะแนน โดย GN⁺ 2024-08-24 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ส่วนขยาย Ghidra นี้ส่งออกบางส่วนของโปรแกรมเป็น อ็อบเจกต์ไฟล์ โดยไฟล์ที่ส่งออกมี metadata ที่ถูกต้อง เช่น symbol และ relocation table ทำให้ toolchain นำไปประมวลผลต่อได้
  • การใช้งานหลักคือ binary patching ขั้นสูง, การพอร์ตซอฟต์แวร์, การแปลงรูปแบบไฟล์, การสร้างไลบรารี และงานในโปรเจกต์ decompile ที่แบ่งโปรแกรมออกเป็นหลายอ็อบเจกต์ไฟล์เพื่อนำไป reimplement ใหม่
  • ชุดที่รองรับคือ COFF x86/x86_64, ELF x86/x86_64/MIPS, OMF x86 และไม่รองรับ COFF MIPS, OMF x86_64, OMF MIPS
  • ผู้ใช้เลือกช่วง address ที่ต้องการดึงออกจาก Ghidra Listing จากนั้นรัน analyzer Relocation table synthesizer แล้วเรียก exporter สำหรับอ็อบเจกต์ไฟล์แบบ relocatable ผ่าน File > Export Program…
  • การ synthesize relocation table ขึ้นกับ ความถูกต้องของฐานข้อมูล Ghidra ดังนั้นหากมีข้อมูลผิดพลาดหรือขาดหาย relocation อาจเสียหายหรือหายไปได้ และควรรัน analyzer อีกครั้งทันทีก่อน export เพื่อความปลอดภัย

ส่วนขยายนี้ทำอะไร

  • Object file exporter extension for Ghidra คือส่วนขยาย Ghidra ที่ทำให้สามารถส่งออกบางส่วนของโปรแกรมเป็นอ็อบเจกต์ไฟล์ได้
  • อ็อบเจกต์ไฟล์ที่สร้างขึ้นมี metadata ที่ถูกต้อง เช่น symbol และ relocation table
  • ด้วย metadata เหล่านี้ อ็อบเจกต์ไฟล์ที่ส่งออกจึงนำกลับไปใช้โดยตรงใน toolchain เพื่อประมวลผลต่อได้

ตัวอย่างการใช้งาน

  • Advanced binary patching
    • แทนที่จะปรับส่วนต้นฉบับกับส่วนที่แก้ไขด้วยมือ สามารถใช้ linker ช่วยให้ทั้งสองส่วนประกบกันได้
  • Software ports
    • สามารถแยกโค้ดที่ไม่ขึ้นกับระบบออกจากโปรแกรม แล้วแทนที่ส่วนที่เหลือได้
  • สามารถแปลง โปรแกรม หรืออ็อบเจกต์ไฟล์จากรูปแบบไฟล์หนึ่งไปเป็นอีกรูปแบบหนึ่งได้
  • การดึงบางส่วนของโปรแกรมออกมา และ การสร้างไลบรารี
    • สามารถดึงบางส่วนของโปรแกรมออกมาเพื่อนำไปใช้ซ้ำในบริบทอื่นได้
  • ในโปรเจกต์ decompile สามารถแบ่งโปรแกรมออกเป็นหลายอ็อบเจกต์ไฟล์ แล้ว reimplement ด้วยแนวทางแบบ Ship of Theseus ได้

สถาปัตยกรรมและรูปแบบอ็อบเจกต์ไฟล์ที่รองรับ

  • ตารางการรองรับมีดังนี้
    • COFF: รองรับ x86, x86_64 / ไม่รองรับ MIPS
    • ELF: รองรับ x86, x86_64, MIPS
    • OMF: รองรับ x86 / ไม่รองรับ x86_64, MIPS

การ build และติดตั้ง

  • ขั้นตอน build ผ่าน CLI
    • clone repository
    • กำหนด environment variable GHIDRA_INSTALL_DIR ให้ชี้ไปยังไดเรกทอรีที่ติดตั้ง Ghidra
    • รัน gradle buildExtension
    • archive ของส่วนขยาย Ghidra ที่สร้างขึ้นจะอยู่ในไดเรกทอรี dist/
  • หากต้องการดาวน์โหลดแพ็กเกจจาก GitHub Maven repository จะต้องมี การยืนยันตัวตน
    • สร้าง GitHub classic token ที่มีสิทธิ์ read:packages แล้วเพิ่ม githubToken=ghp_xxx ใน ${GRADLE_USER_HOME}/gradle.properties
    • หรือรัน gradle installStandaloneDeps เพื่อ build และติดตั้ง vendored dependency ของ submodule
  • ขั้นตอนติดตั้ง
    • ดาวน์โหลดส่วนขยายจาก releases page หรือ build ในเครื่อง
    • ติดตั้งส่วนขยายใน Ghidra ผ่าน File > Install Extensions…
    • เปิดใช้ปลั๊กอิน RelocationTableSynthesizedPlugin ที่ File > Configure > Experimental ในหน้าต่าง CodeBrowser

ลำดับการใช้งานและข้อควรระวัง

  • ขั้นตอนใช้งานพื้นฐาน
    • เลือก ชุด address ที่ต้องการดึงออกมาในมุมมอง Listing
    • รัน analyzer Relocation table synthesizer ซึ่งทำงานแบบ one-shot mode
    • เรียก exporter สำหรับอ็อบเจกต์ไฟล์แบบ relocatable ผ่าน File > Export Program…
  • สามารถดู relocation ที่สร้างขึ้นใหม่ได้จาก Window > Relocation table (synthesized)
  • สามารถเปิดใช้รายงานการประเมินโดยละเอียดได้ โดยตั้งค่า option Evaluation report policy ของ analyzer Relocation table synthesizer ใน dialog Analysis > Auto Analyze...
  • ไม่จำเป็นต้อง reverse engineer ทั้งโปรแกรมไว้ล่วงหน้าทั้งหมดก่อนใช้ส่วนขยายนี้
  • การ delinking ให้สำเร็จโดยทั่วไปขึ้นกับ metadata ของส่วนที่จะ export และ reference ภายนอกเป็นอย่างมาก
    • ฟังก์ชันและ pointer ที่ใช้เป็นตำแหน่ง relocation
    • symbol footprint ที่ใช้เป็นเป้าหมาย relocation
    • reference ระหว่างสองส่วนนี้
  • analyzer Relocation table synthesizer ขึ้นกับความถูกต้องของฐานข้อมูล Ghidra
    • ข้อมูลที่ไม่ถูกต้องหรือขาดหายอาจทำให้ relocation เสียหายหรือ relocation หายไประหว่างการวิเคราะห์
  • exporter อ็อบเจกต์ไฟล์ขึ้นกับผลการวิเคราะห์ของ Relocation table synthesizer
    • หากไม่แน่ใจ ควรรัน analyzer ทันทีก่อนส่งออกอ็อบเจกต์ไฟล์ เพื่อให้แน่ใจว่า relocation table เป็นข้อมูลล่าสุด

หลักการทำงาน

  • อ็อบเจกต์ไฟล์ประกอบด้วยสามส่วน
    • byte ของ section ที่ relocate ได้

    • symbol table

      • relocation table
      • งานที่ linker ทำเมื่อสร้างไฟล์ executable จากอ็อบเจกต์ไฟล์หลายไฟล์
      • วาง section ลงใน memory
      • คำนวณ address ของ symbol ใน virtual address space
      • ใช้ relocation กับ byte ของ section โดยอิงจาก address สุดท้ายของ symbol
      • โดยทั่วไปเมื่อกระบวนการนี้จบลง relocation table จะถูกทิ้ง
      • หากไม่ได้เก็บ debugging symbol ไว้ symbol table ก็จะถูกทิ้งด้วย เหลือเพียง byte ของ section ที่ relocate ไม่ได้
      • ส่วนขยายนี้สามารถสร้างข้อมูลดังกล่าวขึ้นมาใหม่ได้ด้วยการวิเคราะห์อย่างรอบคอบ และทำให้สามารถ delink โปรแกรมกลับไปเป็นอ็อบเจกต์ไฟล์ได้

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

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

 
GN⁺ 2024-08-24
ความคิดเห็นจาก Hacker News

  • ดีใจที่ได้เห็นที่นี่ คิดว่าเป็นโปรเจกต์ที่ยอดเยี่ยมจริง ๆ และผมได้ช่วยเพิ่ม การรองรับ MS COFF
    อย่างไรก็ตาม PR แรกของผมยังขาดไปพอสมควรเมื่อเทียบกับการรองรับ ELF ที่มีอยู่แล้ว ดังนั้นถ้ามีปัญหาเกิดขึ้นก็คงอาจเป็นความผิดผมเอง แต่ก็เห็นว่ามันกำลังดีขึ้น
    ยังไม่ได้ลองใช้กับงานใหญ่ ๆ แต่สิ่งที่สนุกที่สุดคือการ delink ไฟล์ปฏิบัติการ Hello World ที่คอมไพล์ด้วย Visual Studio 2003 แล้วลิงก์กลับใหม่ด้วย GCC+glibc บน Linux x86 จากนั้นลิงก์ใหม่อีกครั้งด้วย MinGW+msvcrt
    อะไรที่ใหญ่กว่า Hello World ยังทำได้ยาก และโดยเฉพาะผมไม่ค่อยรู้จัก Ghidra ดีเท่าไร เลยยังไม่พบวิธีดี ๆ ในการเลือกช่วงที่จะ delink จากไบนารีขนาดใหญ่
    บังเอิญว่าแพ็กเกจ Nixpkgs derivation ของเครื่องมือนี้เพิ่งถูก merge วันนี้พอดี ดังนั้นบน NixOS unstable จึงติดตั้งได้ด้วย ghidra.withExtensions ตำแหน่งคือ ghidra-extensions.ghidra-delinker-extension
    แต่มีเวอร์ชันใหม่ออกมาเมื่อไม่กี่วันก่อน และผมไม่ได้ rebase PR ตอนนี้เลยยังเป็นเวอร์ชันเก่าอยู่ ตั้งใจว่าจะส่งอัปเดตเร็ว ๆ นี้

    • วิธีหนึ่งในการติดตามสิ่งที่จะ delink คือใช้ โฟลเดอร์และแฟรกเมนต์ ใน program tree
      ตัวอย่างเช่น ถ้ามีโปรแกรม Ghidra ที่รู้ชื่อและช่วงของไฟล์ออบเจ็กต์หลายตัวซึ่งประกอบเป็นไฟล์ปฏิบัติการเดิม ก็สามารถคลิกขวาที่โฟลเดอร์หรือแฟรกเมนต์นั้น > Select Addresses เพื่อเลือกทั้งก้อนได้
      relocation synthesis analyzer และการ export ต่างก็สามารถทำเป็นสคริปต์ หรือทำให้เป็นอัตโนมัติผ่าน tree manager ของโปรแกรมได้เช่นกัน จึงลดความจำเป็นในการเลือกช่วงที่ต้องการด้วยมือ แล้วรัน analyzer และ export เองแบบ manual

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

  • สงสัยว่าต้องใช้แรงแค่ไหนในการหาว่าควร export ส่วนไหนของไฟล์ปฏิบัติการ
    เป็นไปได้จริงไหมที่จะ export เกม Win32 ที่ค่อนข้างสมัยใหม่ในช่วงราว ๆ ปี 2008~2015 ออกมาเป็นไฟล์ออบเจ็กต์ แล้วคอมไพล์/ลิงก์กลับเป็นไฟล์ปฏิบัติการสมบูรณ์ได้ภายในไม่กี่ชั่วโมง?

    • ถ้าไม่ตัดกลางตัวแปรหรือฟังก์ชัน ก็สามารถ export ได้ค่อนข้างอิสระ และไม่จำเป็นต้องยึดตามขอบเขตไฟล์ออบเจ็กต์เดิมเสมอไป
      ส่วนจะ export อะไรนั้นเป็นอีกปัญหาหนึ่ง และต้องอาศัยความรู้เกี่ยวกับโปรแกรมนั้น ๆ ถ้ามี debug symbol ก็จะง่ายขึ้นมาก และแม้ไม่มี เมื่อทำฐานข้อมูล Ghidra ให้แม่นพอที่จะ export ได้แล้ว โดยปกติก็จะเริ่มพอเดาได้ว่าอะไรอยู่ตรงไหน
      ในกรณีใช้งานของโพสต์ที่ส่งมา ผู้ใช้เปิด issue ครั้งแรกเมื่อต้นเดือนกรกฎาคม และราวกลางเดือนสิงหาคมก็ได้ไฟล์ปฏิบัติการที่ลิงก์ใหม่ซึ่งทำงานเหมือนเดิมในเชิงฟังก์ชัน
      อย่างไรก็ตาม ตอนนั้น export เป็น COFF ยังมีบั๊กที่ต้องแก้จำนวนมาก และ analyzer สำหรับ i386 ก็ยังมีจุดที่ต้องปรับปรุง ดังนั้นตอนนี้หวังว่าคนอื่นจะเจอปัญหาเดียวกันน้อยลง
      ไม่รู้ว่าจะใช้เวลานานเท่าไร แต่ถ้าไม่มี debug symbol และไม่ได้โชคดีจริง ๆ ก็น่าจะใช้เวลามากกว่าสองสามชั่วโมง วิศวกร reverse engineering ที่ชำนาญอาจทำให้ได้ระดับที่รันอะไรบางอย่างได้ภายในเวลานั้น แต่ก็อาจตายกลางหน้าจอโหลดแรก และโดยรวมเป็นงานประเภทที่ไม่รู้ว่าจะเสร็จเมื่อไรจนกว่าจะเสร็จจริง ๆ

  • ดูเจ๋งดี สักวันหนึ่งมันอาจช่วยให้แยกชิ้นส่วนโปรแกรมเดิมเพื่อนำไปใช้ตามที่ต้องการได้ง่ายขึ้น
    มีงานวิจัยอย่าง LLM Compiler ของ Meta หรือการ decompile ด้วย LLM อยู่แล้ว และงานแยกโปรแกรมเป็นส่วน ๆ แล้วแทนที่บางส่วนอาจเป็นพื้นที่ที่น่าสนใจและมีข้อมูลอุดมสมบูรณ์ให้ LLM สำรวจและปรับปรุงตัวเองได้
    ในมุมมองด้านการเรียนรู้ก็น่าจะมีโทเคนที่น่าสนใจซ่อนอยู่มากมาย และดูเหมือนว่าจะทำอะไรกับมันได้อีกเยอะ

  • พูดตรง ๆ ฟังดูเหมือนเวทมนตร์ ต้องลองทำความเข้าใจว่ามันเป็นไปได้อย่างไร

    • พูดแบบย่อ ๆ ไฟล์ออบเจ็กต์ประกอบด้วยสามส่วน: ไบต์ของเซกชันที่ย้ายตำแหน่งได้, ตาราง relocation และตารางสัญลักษณ์
      เมื่อ linker สร้างไฟล์ปฏิบัติการจากไฟล์ออบเจ็กต์หลายไฟล์ มันจะวางเซกชันลงในหน่วยความจำ คำนวณที่อยู่ของสัญลักษณ์ในพื้นที่ที่อยู่เสมือน แล้วใช้ relocation กับไบต์ของเซกชันตามที่อยู่สุดท้ายของสัญลักษณ์
      เคล็ดลับของ delinking คือการหาให้ได้ว่า relocation เหล่านั้นถูกใช้ตรงไหน แล้วย้อนกลับมัน เพื่อให้ได้ไบต์ที่ย้ายตำแหน่งได้กลับมา จากนั้นสร้างตาราง relocation และตารางสัญลักษณ์จากสิ่งที่ย้อนกลับมา แล้วแพ็กเข้าไป ก็จะได้ไฟล์ออบเจ็กต์
      ส่วนที่ยากจริง ๆ คือการวิเคราะห์เพื่อหาจุด relocation ส่วนใหญ่โยนให้ Ghidra จัดการ แต่ต้องมีงานแปลง reference ให้เป็นจุด relocation ด้วย บน x86 ทำได้ค่อนข้างง่าย ส่วนบน MIPS ยากราวฝันร้าย ส่วนขยายนี้ถูกสร้างขึ้นเพื่อทำให้การรวบรวมข้อมูลที่จำเป็นตรงนี้ รวมถึงการ serialize ไฟล์ออบเจ็กต์ เป็นอัตโนมัติ
    • คงไม่ได้ง่ายกับทุกสถาปัตยกรรม CPU แต่ก็ไม่ได้ไร้สาระอย่างที่เห็น โดยพื้นฐานแล้วความแตกต่างระหว่าง ไฟล์ออบเจ็กต์ กับไฟล์ปฏิบัติการหรือ shared library ไม่ได้มากนัก
      ถ้าไม่นับแพลตฟอร์ม Microsoft หลายกรณีรูปแบบไฟล์จริงก็เหมือนกัน เช่น ELF
      ความแตกต่างใหญ่คือ relocation ไฟล์ออบเจ็กต์มีข้อมูล relocation ที่ละเอียด แต่ไฟล์ปฏิบัติการมักไม่มี ใน executable image ของ Windows มีเพียง relocation ขั้นต่ำที่ชี้ไปยังที่อยู่ของโค้ดและข้อมูลที่ต้องแก้เมื่อไฟล์ปฏิบัติการถูกย้ายตำแหน่ง และตัว image เองก็ย้ายตำแหน่งได้เฉพาะทั้งก้อนตาม image base address เท่านั้น
      ในทางกลับกัน ไฟล์ออบเจ็กต์มี relocation ระดับสัญลักษณ์ อยู่ด้วย หากจะสร้างข้อมูลนี้กลับมาให้ถูกต้อง ต้องผูกข้อมูลเกี่ยวกับสัญลักษณ์ที่ค่อนข้างแม่นยำเข้ากับ disassembly
      ความแตกต่างใหญ่อีกอย่างคือไฟล์ออบเจ็กต์ยังไม่ถูกลิงก์ สัญลักษณ์ใด ๆ ก็ยังไม่ถูก resolve เรื่องนี้กลับแก้ได้ง่ายกว่า เพราะระหว่าง delinking หากเป็นสัญลักษณ์ที่อยู่นอกขอบเขตปัจจุบัน โดยมากก็แปลงเป็น unresolved symbol ได้ จากนั้นตอน relink ภายหลัง ไฟล์ออบเจ็กต์หรือไลบรารีอื่นต้องเป็นผู้ให้สัญลักษณ์นั้นจึงจะเชื่อมกลับได้
      ยังมีความแตกต่างเล็ก ๆ อย่างการไม่มี entry point แต่ไม่ได้มีนัยสำคัญมาก
      ดังนั้นขอบเขตที่จะตัดไฟล์ออบเจ็กต์ออกจาก executable image หรือ shared object จึงแทบจะกำหนดได้ตามใจ เดิมตอนคอมไพล์น่าจะแบ่งตาม translation unit แต่ในขั้นตอนลิงก์ไม่ได้สนใจขอบเขตนั้นมากนัก แน่นอนว่าถ้าต้องการ decompile ให้ตรงกัน ถ้าขอบเขตไฟล์ออบเจ็กต์ผิดก็อาจยากมาก ดังนั้นถ้าหาได้ก็ควรหา
      ผมเคยจัดการปัญหานี้จริง ๆ แต่รายละเอียดอาจคลาดเคลื่อนเล็กน้อย จึงควรอ่านไว้เป็นข้อมูลประกอบ ผมเคยพยายามเขียนบล็อกโพสต์เกี่ยวกับไฟล์ออบเจ็กต์ และก็มีบทความดี ๆ อยู่แล้วหลายชิ้น

  • สงสัยว่ากระบวนการนี้ปลอดภัยสมบูรณ์หรือไม่ อยากรู้ว่ารับประกันว่าสำเร็จเสมอไหม หรือการวิเคราะห์ทำงานแบบ conservative
    เช่น ถ้า ELF ขาดชิ้นส่วน ข้อมูล หรือฟังก์ชันบางอย่าง delinking จะล้มเหลวหรือเปล่า?

    • ตอบซับซ้อนอยู่
      analyzer ของผมพึ่งพา ฐานข้อมูล Ghidra ที่ถูกต้อง อย่างน้อยก็สำหรับส่วนที่จะ export ผมพยายามค่อนข้างมากที่จะ log ปัญหาหลายอย่างที่ต้องแก้ แต่สิ่งที่ไม่มีอยู่ก็ย่อมมองไม่เห็น
      โดยเฉพาะ reference ที่หายไปและตัวแปรที่ถูกตัดขาดจะตรวจไม่พบ และอาจนำไปสู่ undefined behavior แปลก ๆ
      มีวิธีติดตามปัญหาบางส่วนเหล่านี้อยู่ วิธีที่ดีที่สุดที่พบจนถึงตอนนี้คือ relink ไฟล์ปฏิบัติการไปยัง base address อื่น และไม่ map ช่วงที่อยู่ของโปรแกรมเดิมไว้ แบบนั้นจุด absolute relocation ที่พลาดไปจะทำให้เกิด segmentation fault และดีบักได้ แต่ทำได้ก็ต่อเมื่อ target มี MMU เท่านั้น
      ตัวแปรที่ถูกตัดขาดติดตามยากมากเป็นพิเศษถ้าไม่ได้สงสัยไว้ก่อน เพราะสิ่งที่เสียหายคือหน่วยความจำถัดจากตัวแปรที่ถูกตัดขาดนั้น กรณีเข้าใจ integer ผิดว่าเป็น pointer ก็ติดตามยากเช่นกัน เพราะค่าจำนวนเต็มจะเปลี่ยนไปตามที่อยู่ที่สัญลักษณ์เป้าหมายถูกวาง ทำให้พฤติกรรมของโปรแกรมขึ้น ๆ ลง ๆ โดยเฉพาะในโปรแกรมที่ถูกโหลดในบริเวณต่ำมากของ address space จะเป็นปัญหามาก
      ถึงอย่างนั้น หากฐานข้อมูล Ghidra แม่นยำพอ และ export กลับไปเป็นรูปแบบไฟล์ออบเจ็กต์เดียวกับที่ใช้เดิม แล้วใช้แพลตฟอร์มเดียวกันและ toolchain เดียวกัน ก็สามารถ delink โค้ดและข้อมูลของโปรแกรมระดับหลายเมกะไบต์ได้สำเร็จ ผมมองว่าถ้า linker ทำไว้ได้ ก็ต้องย้อนกลับได้เช่นกัน
      ในทางกลับกัน หากเริ่มทำ cross-delinking ที่ไม่ตรงกับแพลตฟอร์มและ toolchain เดิมของโปรแกรม เช่น delink จากไฟล์ปฏิบัติการ Linux i386 ELF ไปเป็นไฟล์ออบเจ็กต์ COFF เพื่อใช้กับ toolchain ของ i386 Windows เรื่องก็จะต่างออกไป หาก export สามารถแสดง relocation ได้ ก็อาจได้ไฟล์ออบเจ็กต์ที่ย้ายตำแหน่งได้และทำงานได้ แต่ก็ยังต้องสู้กับความไม่ตรงกันของ ABI ด้วย เป็นไปได้ แต่ไม่แนะนำให้เป็นโปรเจกต์แรก
      สรุปคือ ขึ้นอยู่กับว่าคุณกำลังทำอะไรและฐานข้อมูล Ghidra ถูกต้องแค่ไหน มีตั้งแต่ระดับ “ใช้งานได้เลย” ไปจนถึง “อ้อนวอนขอความเมตตาจากคธูลู”
    • ถ้าตามเจตนาของคำถาม ก็ไม่ปลอดภัยสมบูรณ์ และเป็นแบบนั้นไม่ได้ด้วย
      ตัวอย่างเช่นลองคิดถึงฟังก์ชันอย่าง int getSpecialArrayElement(char *array, uint64 key) { i = computeOffset(key); return array[i]; }
      computeOffset อาจซับซ้อนตามอำเภอใจได้ และถ้าต้องการทำ obfuscation ก็อาจจงใจทำให้วิเคราะห์ยากได้ ไม่มีอะไรป้องกันไม่ให้ฟังก์ชันนี้เข้าถึงตำแหน่งใด ๆ ในหน่วยความจำ
      ถ้าไม่ลองอินพุตที่เป็นไปได้ทั้งหมด ก็ไม่มีทางรู้ได้ว่ามันเข้าถึงสัญลักษณ์ที่ linker นิยามไว้ในหน่วยความจำแล้วหรือไม่ และใน computeOffset ก็อาจใส่ กับดักทัวริง ที่ขัดขวางความพยายามแบบนั้นได้

  • น่าจะน่าสนใจถ้าเชื่อมโยงกับไอเดียที่เคยแค่จินตนาการไว้แต่ไม่ได้สร้างจริง นั่นคือการสร้าง ไฟล์เฮดเดอร์จากข้อมูลดีบัก แล้วถ้าจำเป็นก็ให้ LLM ช่วยจัดระเบียบ

    • จริง ๆ แล้วมีความพยายามแบบนั้นอยู่บ้าง สำหรับ Microsoft Program Database มีตัวนี้
      https://github.com/wbenny/pdbex
      ส่วนที่ให้ LLM ช่วยจัดระเบียบนั้น ยังดูเหมือนมีกรณีที่นำโมเดล LLM ไปใช้กับงาน reverse engineering แล้วประสบความสำเร็จอย่างมากไม่มากนัก บางทีนี่อาจเป็นพื้นที่ที่เผยให้เห็นข้อจำกัดของโครงสร้าง LLM ก็ได้
      ผมไม่ใช่ผู้เชี่ยวชาญ แต่ถ้าต้องเดิมพัน สำหรับ use case ด้าน reverse engineering หลายอย่าง ผมคิดว่าแนว diffusion model น่าจะน่าสนใจกว่า
      ถึงจะไม่เหมือนกันเป๊ะ แต่ Binary Ninja มีฟีเจอร์ชื่อ Sidekick ที่พยายามใช้ LLM จัดระเบียบ disassembly โดยส่วนตัวผมไม่ค่อยประทับใจ แต่สำหรับบางคนอาจมีประโยชน์ก็ได้
    • pahole สร้างไฟล์เฮดเดอร์ C ที่คอมไพล์ได้จาก ข้อมูล ELF DWARF
      ในกรณีนี้ LLM ดูไม่ค่อยเกี่ยวข้อง ไฟล์เฮดเดอร์จะต้องบรรจุ type ทั้งหมดที่ executable ส่งออกมาอย่างถูกต้องพร้อมค่าดั้งเดิมจนใช้งานได้ ไม่เช่นนั้นก็ผิดหรือไม่สมบูรณ์ การให้ LLM แต่งอะไรเพิ่มขึ้นมาไม่ได้ช่วยอะไร
      Ghidra เองก็มีฟีเจอร์พื้นฐานสำหรับ export โครงสร้างข้อมูล และสามารถสร้างจากโครงสร้าง DWARF ได้ คลิกขวา -> Export to C header
    • เมื่อไม่กี่ปีก่อน ผมสร้างเครื่องมือที่สร้างและแทรก type-aware fuzzer สำหรับ C API โดยอัตโนมัติจากข้อมูล DWARF: https://github.com/intel/fffc
      การสร้างเฮดเดอร์ และการสร้าง mutator ที่ภายหลังสามารถปรับแก้ให้สอดคล้องกับข้อจำกัดของ type ได้ ก็เป็นส่วนหนึ่งของงานนั้นด้วย
      ถ้าเสริมฝั่ง LLM เข้าไป อาจทำได้ในระดับตั้งชื่อให้สิ่งอย่าง anonymous struct แต่ผมไม่แน่ใจว่าเป็นไอเดียที่ดีไหม สิ่งที่น่าสนใจกว่าน่าจะเป็นการให้ LLM อธิบายและสรุปข้อจำกัดของ type ที่รู้จักเป็นภาษาคนเพื่อจุดประสงค์ด้านเอกสาร
    • พูดเรื่องที่ต่างออกไปเล็กน้อย ผมเคยคิดถึงวิธีสร้าง debugging symbol สำหรับ object file ที่ export ออกมา โดยอิงจากเนื้อหาในฐานข้อมูลของ Ghidra เพื่อปรับปรุงประสบการณ์การดีบัก
      เหตุผลที่ยังไม่ได้ implement ก็เพราะจนถึงตอนนี้ยังพออยู่ได้โดยไม่มีมัน แถมฟังดูเหมือนหลุมกระต่ายที่ลึกทีเดียว และหลุมกระต่ายที่กำลังอยู่ตอนนี้ก็ใหญ่พออยู่แล้ว

  • ดูเจ๋งมากจริง ๆ และยังเกี่ยวข้องกับไอเดีย game modding ที่เคยคิดไว้ด้วย ซีรีส์บล็อก decompile Tenchu ก็ยอดเยี่ยมเช่นกัน

    • สักวันต้องกลับไปทำโปรเจกต์นี้ต่อ ผมทำ version tracking session ต่อเนื่องกันเยอะเกินไปจนต้องพัก และระหว่างนั้น side quest เรื่อง delinking ก็ขยายตัวจนคุมไม่อยู่เรื่อย ๆ

  • งานที่ทำอยู่ตอนนี้ยังไม่มีที่ให้ใช้ทันที แต่ดูเป็นเครื่องมือที่ถ้าเป็นเมื่อก่อนคงมีประโยชน์มากจริง ๆ
    หวังว่าจะมีเวลาหรือโอกาสได้ลองใช้เร็ว ๆ นี้