ทดลองซ่อนแบ็กดอร์ไว้ในไบนารีขนาดราว 40MB และทดสอบว่าสามารถตรวจจับได้ด้วย AI และ Ghidra หรือไม่

 (quesma.com)
4 คะแนน โดย GN⁺ 2026-02-24 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เพื่อทดสอบความเป็นไปได้ของการตรวจจับมัลแวร์ด้วย AI ได้มีการฝังแบ็กดอร์แบบจงใจลงในเซิร์ฟเวอร์ไบนารีโอเพนซอร์สหลายตัว แล้วทดลองตรวจจับด้วยเอเจนต์ AI และ Ghidra
  • แม้โมเดลรุ่นใหม่อย่าง Claude Opus 4.6 จะค้นพบแบ็กดอร์แบบง่ายบางส่วนได้ แต่อัตราการตรวจจับอยู่ที่ 49% และอัตรา false positive อยู่ที่ 28% ซึ่งยังไม่เหมาะกับการใช้งานจริง
  • การทดลองใช้โปรเจ็กต์ฝั่ง C·Rust เช่น lighttpd, dnsmasq, Dropbear, Sozu โดย AI ทำการวิเคราะห์ด้วยเครื่องมือรีเวิร์สเอนจิเนียริงเท่านั้นโดยไม่มีซอร์สโค้ด
  • บางโมเดลแปลความการเรียกใช้ที่เป็นอันตรายอย่างชัดเจน (execl("/bin/sh", ...)) ว่าเป็นฟังก์ชันปกติ หรือไปโฟกัสที่โค้ดที่ไม่เกี่ยวข้อง แสดงให้เห็นถึงข้อจำกัดด้านการตัดสินใจ
  • คณะวิจัยประเมินว่า AI ยังไม่ใช่เครื่องมือความปลอดภัยที่สมบูรณ์ แต่พัฒนาไปถึงระดับที่แม้ผู้ที่ไม่ใช่ผู้เชี่ยวชาญก็สามารถทำการตรวจสอบความปลอดภัยเบื้องต้นได้

ภูมิหลังของงานวิจัย

  • ช่วงหลังเกิดเหตุอย่างการโจมตีซัพพลายเชน Shai Hulud 2.0 และกรณียึดครองไบนารีของ Notepad++ ทำให้ความเสี่ยงของไฟล์ปฏิบัติการที่ไม่น่าเชื่อถือถูกจับตามากขึ้น
    • ผู้โจมตีแทรกโค้ดอันตรายลงในซอฟต์แวร์ปกติเพื่อขโมยข้อมูลรับรองหรือรันคำสั่งจากระยะไกล
  • มีรายงานกรณีที่เฟิร์มแวร์หรืออุปกรณ์ฮาร์ดแวร์มีโมดูลสื่อสารที่ซ่อนอยู่หรือบัญชีแบ็กดอร์ด้วย
  • เพื่อรับมือกับภัยคุกคามเหล่านี้ จึงมีการทดลองว่าAI สามารถตรวจจับพฤติกรรมอันตรายในระดับไบนารีได้หรือไม่

ภาพรวมของการวิเคราะห์ไบนารี

  • การเขียนโปรแกรมทั่วไปทำงานกับซอร์สโค้ด แต่การวิเคราะห์มัลแวร์ต้องตีความไบนารีระดับภาษาเครื่อง
  • ในกระบวนการคอมไพล์ ข้อมูลระดับสูงอย่างชื่อฟังก์ชันและชื่อตัวแปรจะหายไป และโครงสร้างโค้ดอาจบิดเบี้ยวจากการ optimize
  • การวิเคราะห์ต้องผ่านกระบวนการรีเวิร์สเอนจิเนียริงที่แปลง ภาษาเครื่อง → แอสเซมบลี → โค้ด C เชิงสื่อความหมาย
    • เครื่องมือโอเพนซอร์ส: Ghidra, Radare2
    • เครื่องมือเชิงพาณิชย์: IDA Pro, Binary Ninja
  • เครื่องมือเหล่านี้ช่วยกู้คืนความหมายของโค้ด แต่ผลลัพธ์จะเต็มไปด้วยidentifier ที่ไม่มีความหมาย เช่น FUN_00130550, bVar49

โครงสร้างของเบนช์มาร์ก BinaryAudit

  • ฝังแบ็กดอร์สำหรับการทดสอบลงในโอเพนซอร์สเซิร์ฟเวอร์หลายตัว (lighttpd, dnsmasq, Dropbear, Sozu)
    • ตัวอย่าง: รันคำสั่งผ่าน HTTP header หรือสั่ง shell command ผ่าน DHCP option
  • AI ได้รับเพียงไฟล์ปฏิบัติการที่คอมไพล์แล้วโดยไม่มีซอร์สโค้ด และใช้ Ghidra·Radare2·binutils ฯลฯ ในการวิเคราะห์
  • เป้าหมายคือการระบุว่ามีแบ็กดอร์หรือไม่ และฟังก์ชันนั้นเริ่มที่ address ใด
  • บางโจทย์ออกแบบให้ตัดสินเพียงว่าในหลายไบนารีนั้นไฟล์ใดติดเชื้อ

กรณีตรวจจับสำเร็จ

  • Claude Opus 4.5 ตรวจพบแบ็กดอร์ที่ฝังในเซิร์ฟเวอร์ lighttpd ผ่าน header X-Forwarded-Debug ได้ภายใน 5 นาที
    • พบการเรียก popen() แล้วทำรีเวิร์สเอนจิเนียริงด้วย Radare2 เพื่อยืนยันลอจิกการรันคำสั่ง
    • ยังระบุได้ด้วยว่าโครงสร้างดังกล่าวส่งผลลัพธ์กลับผ่าน response header X-Request-Trace
  • โมเดลได้ผสมคำสั่ง nm, strings, grep, r2 เพื่อทำกระบวนการวิเคราะห์แบบอัตโนมัติ

กรณีตรวจจับล้มเหลว

  • Claude Opus 4.6 ตัดสินผิดว่าเป็นฟังก์ชันปกติในกรณีแบ็กดอร์รัน /bin/sh ที่ฝังในโค้ดประมวลผล DHCP ของ dnsmasq
    • แม้จะพบการเรียก execl("/bin/sh", "sh", "-c", ...) แต่กลับเข้าใจว่าเป็นการรันสคริปต์ DHCP
    • แท้จริงแล้วเป็นโค้ดที่มีช่องโหว่ซึ่งนำเนื้อหาจากแพ็กเก็ตของไคลเอนต์ไปรันทันที
  • แม้โมเดลจะหาตำแหน่งที่ถูกต้องได้ แต่กลับปฏิเสธความเสี่ยงแล้วหันไปดูฟังก์ชันอื่น ทำให้พลาดการตรวจจับ

ข้อจำกัดของ AI และปัญหา false positive

  • มีอัตรา false positive เฉลี่ย 28% หมายความว่าแม้เป็นไบนารีสะอาดก็ยังถูกแจ้งผิดว่าเป็นแบ็กดอร์บ่อยครั้ง
    • ตัวอย่าง: Gemini 3 Pro ตีความโค้ด parse ตัวเลือกบรรทัดคำสั่งตามปกติว่าเป็น “แบ็กดอร์รันคำสั่ง”
  • ในชุมชนความปลอดภัยก็มีการชี้ปัญหาเรื่องคุณภาพรายงานที่สร้างโดย AI
    • โปรเจ็กต์ curl ระบุว่ารายงานบั๊กที่สร้างด้วย AI ส่วนใหญ่นั้นไร้สาระ
  • หากจะใช้งานเป็นเครื่องมือความปลอดภัยเชิงปฏิบัติได้จริง จำเป็นต้องมีอัตรา false positive ต่ำกว่า 0.001%

ข้อจำกัดของเครื่องมือโอเพนซอร์ส

  • Ghidra และ Radare2 มีประโยชน์กับการวิเคราะห์โค้ด C แต่ประสิทธิภาพลดลงเมื่อเจอไบนารี Rust·Go
    • ตัวอย่าง: เซิร์ฟเวอร์ Caddy ที่พัฒนาด้วย Go (50MB) ใช้เวลาโหลดใน Ghidra 40 นาที และผลลัพธ์ไม่แม่นยำ
    • ขณะที่ IDA Pro โหลดได้ภายใน 5 นาทีและให้โค้ดที่แม่นยำ
  • ในการทดลองจึงเน้นไบนารีที่พัฒนาด้วย C เป็นหลักเพื่อตัดผลต่างด้านคุณภาพของเครื่องมือออกไป

ผลลัพธ์และแนวโน้ม

  • อัตราการตรวจจับที่บันทึกได้คือ Claude Opus 4.6: 49%, Gemini 3 Pro: 44%, Claude Opus 4.5: 37%
  • ยังอ่อนแอต่อไบนารีขนาดใหญ่หรือแบ็กดอร์ที่เลียนแบบพฤติกรรมปกติ
  • อย่างไรก็ตาม AI ได้พัฒนาไปถึงระดับที่สามารถควบคุม Ghidra เพื่อทำรีเวิร์สเอนจิเนียริงได้โดยตรง
    • ทำให้ผู้ที่ไม่ใช่ผู้เชี่ยวชาญสามารถตรวจสอบไฟล์ปฏิบัติการต้องสงสัยในเบื้องต้นได้
  • ในอนาคตมีการเสนอให้พัฒนาไปทางการเชื่อมต่อกับเครื่องมือเชิงพาณิชย์และการวิเคราะห์ความปลอดภัยด้วยโมเดลโลคัล
  • เบนช์มาร์กฉบับเต็มและผลลัพธ์เผยแพร่ไว้บน GitHub ที่ QuesmaOrg/BinaryAudit

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

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

 
GN⁺ 2026-02-24
ความเห็นจาก Hacker News

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

    • ผมเป็นหนึ่งในผู้เขียนงานวิจัยนี้ งานที่ให้ทำครั้งนี้เป็น งานระดับเริ่มต้น และสิ่งที่น่าทึ่งคือมีโมเดลที่สามารถจับบางแพตเทิร์นได้จากการดูแค่ binary code อย่างเดียว
      ตัวอย่างเช่น โมเดลที่เข้าใจเครื่องมืออย่าง Ghidra หรือ Radare2 ได้จริง ๆ มีเพียง Opus 4.5, 4.6, Gemini 3 Pro และ GLM 5 เท่านั้น
      benchmark ที่เกี่ยวข้องดูได้ที่นี่
      นี่เป็นเพียง จุดเริ่มต้น ที่ทำให้ AI ทำงานร่วมกับไบนารีได้ และยังห่างไกลจากการเป็นโซลูชันที่สมบูรณ์
    • ตอนที่ผมพัฒนาเครื่องมือ ghidra-cli สำหรับ LLM ผมใช้ crackme เป็นตัวทดสอบ และถ้าแค่บอกผ่านพรอมต์ มันก็ผ่านโค้ดที่ถูก obfuscate ได้ค่อนข้างดี
      ในงาน reverse engineering ซอฟต์แวร์จริง มันมักจะวนไปวนมาอยู่พักหนึ่ง แต่พอรู้ว่าเป็น obfuscation แล้ว หลังจากนั้นก็จะดำเนินต่อได้อย่างลื่นไหล โดยอัปเดตผลลงเอกสารอย่าง CLAUDE.md ไปด้วย
    • ในบทความก็ระบุชัดว่าได้ลบ symbol ออกแล้ว และ backdoor จริง ๆ ทุกวันนี้ก็ถูก ทำ obfuscate ด้วยโค้ดเพียงเล็กน้อย กันอยู่แล้ว
      ดูตัวอย่างได้จากแพตช์ dnsmasq-backdoor และ dropbear-brokenauth
    • ผมเคยใช้ Opus 4.5 และ 4.6 reverse มัลแวร์ที่ถูก obfuscate ทั้งหมดด้วย Ghidra plugin สำหรับ Claude Code
      แต่สิ่งที่ผมจัดการไม่ใช่ backdoor ระดับรัฐชาติ เป็นเพียงระดับ ซอฟต์แวร์แคร็ก เท่านั้น
    • ผมเคยเห็น LLM จับแพตเทิร์นแปลก ๆ แบบนี้ได้ค่อนข้างดี เพราะมันได้เรียนรู้ เทคนิคการเข้ารหัสและการทำ obfuscation หลายรูปแบบ
      สิ่งที่ทำให้ LLM พังจริง ๆ กลับเป็นตรรกะที่ซับซ้อน แต่โมเดลที่ดีจะสามารถรับรู้ถึงความซับซ้อนนั้นและระบุเตือนไว้ได้

  • ขอแนะนำ โปรเจกต์ ghidra-cli ของผม
    ผมใช้ Ghidra reverse file format ของ Altium (ส่วน Delphi) แล้วผลลัพธ์น่าทึ่งมาก
    โมเดลอาจยังเขียน parser แบบสมบูรณ์ขึ้นมาใหม่ทั้งหมดตั้งแต่ต้นไม่ได้ แต่ถ้าเป็นก่อนยุค LLM ก็คงไม่คิดจะลองอะไรแบบนี้ด้วยซ้ำ
    ผมคงไม่พึ่งมันสำหรับ security audit แต่สำหรับ การ reverse engineering file format โมเดลรุ่นใหม่ใช้งานได้ดีพอแล้ว

    • ช่วงนี้ผมกำลังดูวิธีใช้เอเจนต์เป็นเครื่องมือช่วย ไม่ได้พึ่งทั้งหมด แต่ใช้เพื่อ ขยายความสามารถ
      เช่น ให้มันช่วยสร้างไดอะแกรม ทำแผนที่ attack surface และสำรวจโค้ด ส่วนผมโฟกัสกับการวิเคราะห์ด้วยมือ
      LLM ช่วยทำงานซ้ำ ๆ ที่น่าเบื่อแทนได้ จึงทำให้เร็วขึ้น แต่ถ้าโยนงานให้มากเกินไปก็จะตกอยู่ใน กับดักด้านผลิตภาพ
      ถ้าใช้ชุดเอเจนต์ที่มี “สกิล” เหมาะสม ก็เพิ่มประสิทธิภาพได้ชัดเจน
    • พวกเราใช้ PyGhidra แต่บางที การเข้าถึงผ่าน CLI อาจดีกว่า
      ข้อจำกัดใหญ่ที่สุดของ Ghidra คือมันวิเคราะห์ภาษา Go ได้ช้ามาก
    • นี่เป็นโปรเจกต์ที่เจ๋งมาก ละเอียดกว่าสิ่งที่ผมเคยทำกับ Ghidra + LLM มาก
    • ecosystem ที่เกี่ยวข้องก็กำลังคึกคัก มีกรณีของ MCP server เมื่อไม่นานมานี้ด้วย
      ผมเคยใช้ GhidrAssistMCP, analyzeHeadless, PyGhidra ฯลฯ
      โดยเฉพาะแนวทางที่มี SKILL.md แบบชัดเจน ทำให้เชื่อมกับ AI agent ได้ดีมาก
    • อยากรู้ว่าแนวทางนี้เทียบกับ Ghidra MCP server ตัวอื่น ๆ เป็นอย่างไร

  • แก่นของเธรดนี้คือการอภิปรายเรื่อง ระเบียบวิธี
    คำพูดที่ว่า “ถ้าเพิ่ม obfuscation แล้วอัตราสำเร็จเป็น 0%” นั้นถูกต้อง แต่เป้าหมายของการทดลองคือดูว่า AI สามารถจัดการกับ ไบนารีที่ไม่ถูก obfuscate ได้เหมือน reverse engineer ที่ชำนาญหรือไม่
    นี่เป็นสถานการณ์ที่ใช้งานได้จริง เช่น internal audit หรือการวิเคราะห์ legacy code
    สิ่งสำคัญจริง ๆ คือการ กำหนด threat model ถ้าคู่ต่อสู้เป็นผู้โจมตีระดับอัตโนมัติ แค่นี้ก็มีประโยชน์มากพอแล้ว
    แต่ถ้าเป็นผู้โจมตีขั้นสูงที่คำนึงถึงการหลบ AI detection การทดสอบแบบนี้ก็ยังไม่พอ
    การตรวจสอบที่มีความหมายจริงควรดูประสิทธิภาพในระดับ obfuscation เบา ๆ เช่น การซ่อน import หรือการเข้ารหัส string

    • แต่การจำไบนารีที่ถูก obfuscate ไม่ได้ ก็เหมือนกับ ผ่านแคปต์ชาไม่ได้
      ถ้าหุ่นยนต์เก็บแอปเปิลทำงานไม่ได้เวลาอากาศครึ้ม จะเรียกมันว่า “ผู้เชี่ยวชาญด้านการเก็บแอปเปิล” ได้หรือไม่ก็น่าสงสัย

  • GPT มี อัตรา false positive 0% ค่อนข้างเสถียร แต่มีอัตราตรวจจับเพียงราว 18%
    ในขณะที่ Claude Opus 4.6 มีอัตราตรวจจับสูงกว่าที่ 46% แต่มี false positive 22%
    ถ้านำหลายโมเดลมาผสมกัน โดยให้ตัวหนึ่งออกแบบขั้นตอนตรวจสอบ และอีกตัวทำ การทดสอบ exploit จริง ก็น่าจะได้ผลที่น่าสนใจกว่านี้

    • ที่จริงแล้ว ระเบียบวิธีวัดประสิทธิภาพการจำแนกแบบทวิภาค แบบนี้มีมาตั้งแต่ร้อยปีก่อนแล้ว
      แต่พอมี generative model ขึ้นมา ทุกคนเหมือนจะลืมกันไปหมด

  • ประเด็นสำคัญคือ “แม้ AI จะตรวจจับมัลแวร์ได้ไม่สมบูรณ์ แต่ก็ทำให้นักพัฒนา ทำ security audit ขั้นต้น ได้ง่ายขึ้นมาก”
    แม้นักพัฒนาที่ไม่มีประสบการณ์ด้าน reverse engineering ก็สามารถวิเคราะห์ไบนารีต้องสงสัยในเบื้องต้นได้
    สิ่งนี้ขยายไปได้ไม่ใช่แค่ด้านความปลอดภัย แต่ยังรวมถึง การปรับแต่งประสิทธิภาพ, debugging, hardware reverse และการพอร์ตสถาปัตยกรรม ด้วย
    สุดท้ายแล้ว สิ่งสำคัญคือมุมมองที่ใช้ AI ไม่ใช่ในฐานะตัววิเคราะห์ที่สมบูรณ์แบบ แต่เป็น เครื่องมือสร้างสมมติฐาน

  • ไฟล์ executable ใน benchmark ประกอบด้วยฟังก์ชันตั้งแต่หลายร้อยถึงหลายพันตัว และ backdoor เป็นเพียงไม่กี่บรรทัดในนั้น
    ดังนั้นจึงต้อง สำรวจเส้นทางสำคัญอย่างมีกลยุทธ์ เช่น network parser หรือ routine จัดการ input
    วิธีหนึ่งคืออาจให้กลยุทธ์เหล่านี้กับ LLM ในรูปแบบไฟล์ .md

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

  • ลิงก์ benchmark โดยตรงอยู่ที่นี่ และ
    โค้ดโอเพนซอร์สดูได้จากGitHub repository

  • ผลที่ว่า Gemini มี อัตรา false positive สูงที่สุด สอดคล้องกับประสบการณ์ของผม
    ผมเคยใช้ทั้ง ChatGPT, Claude และ Gemini และ Gemini มี อคติเชิงบวก มากที่สุด
    มันมักจะให้คำตอบในแง่ดีสุดเสมอ
    ผมตามหา benchmark ที่แสดงลักษณะนี้เป็นตัวเลขมานาน และผลครั้งนี้ก็น่าจะใช้เป็นหลักฐานได้

  • ผมไม่ใช่ผู้เชี่ยวชาญ แต่คิดว่าถ้าอยากลดปัญหา false positive โมเดลอาจควร รัน backdoor เองเพื่อตรวจสอบ จะได้ไหม

    • แต่โมเดลส่วนใหญ่จะปฏิเสธการกระทำแบบนั้นเพราะ นโยบายความปลอดภัย
      จึงทำให้การเปรียบเทียบข้ามโมเดลทำได้ยาก และเลยต้องให้โมเดลระบุตำแหน่งของ backdoor แทน
      ถ้าปรับแต่งหรือ fine-tune โมเดลเองได้ วิธีที่เสนอมาก็น่าจะมีประโยชน์

  • การที่โมเดลที่ดีที่สุดตรวจจับได้เพียงราว 50% ก็ไม่ได้แย่ อาจดีกว่ามนุษย์ด้วยซ้ำ
    แต่ผมสงสัยว่าทำไมอีก 50% ที่เหลือถึงพลาดไป
    สิ่งที่น่าสนใจคือ Claude Opus 4.6 เจอ backdoor แล้วแท้ ๆ แต่กลับสรุปว่า “ไม่มีปัญหา”
    สุดท้ายมันแสดงให้เห็นว่า AI ยังไปไม่ถึงความเข้าใจที่สมบูรณ์ หากไม่มีการช่วยตัดสินโดยมนุษย์