697 ฟังก์ชันใน 12 วัน และบั๊กหนึ่งตัวที่ผ่านทุกการทดสอบ - เรื่องจริงของคลื่น Reverse Engineering ด้วย AI

เมื่อต้นเดือนตุลาคม 2026 เกิดคลื่นใหญ่ในวงการ dev และ AI agents หลัง CEO ของ Replit โพสต์ว่า "เร็วๆ นี้ซอฟต์แวร์ทุกตัวจะกลายเป็น open-source โดยพฤตินัย" และตามด้วยโพสต์ของ Matthew Berman ที่เขียนสั้นๆ ว่า "Software is done" ใต้ screenshot ของ GitHub repo หนึ่งที่มีดาวพุ่งทะลุแสน

repo นั้นคือ REA (Reverse Engineer Anything) - เครื่องมือที่ให้ coding agent "มองเข้าไปข้างใน" โปรแกรมที่ไม่มี source code ลงไปถึงระดับ machine code โดยทำงานแบบ local ไม่ได้อัปโหลดโปรแกรมขึ้นเซิร์ฟเวอร์ แต่เรื่องราวที่น่าสนใจจริงๆ ไม่ใช่จำนวนดาว แต่เป็น บั๊กหนึ่งตัวที่หลุดผ่านทุกการทดสอบ

REA คืออะไรใน 60 วินาที

REA เป็น MCP server + CLI (MIT license) ที่ให้ agent สอบถามเกี่ยวกับโปรแกรมบนเครื่องคุณ แล้วมันจะโหลดเข้า engine ที่เหมาะสม (Hopper, Ghidra, IDA สำหรับ native หรือตัววิเคราะห์ของตัวเองสำหรับ JS/Electron, .NET, APK ฯลฯ) แล้วคืนผลพร้อมหลักฐาน: ฟังก์ชัน ไฟล์ call และสิ่งที่ยังไม่รู้ รองรับ Claude Code, Cursor, Codex, VS Code, Grok Build และอื่นๆ ทำงานได้ทั้งกับ Electron app, native binary, เกม, เว็บไซต์ ไปจนถึง firmware

จุดสำคัญคือมันออกแบบมาเพื่อ security research, interoperability, education และ auditing ซอฟต์แวร์ที่คุณมีสิทธิ์ตรวจ แต่มีเส้นแบ่งชัดเจน: ไม่ช่วย bypass DRM, anti-cheat, license check หรือคัดลอก proprietary code

ตำนานที่ว่า "decompile Adobe ทั้งชุด"

ในช่วงที่ REA ฮิต มีเรื่องเล่าว่ามีคน decompile Adobe suite แล้วทำ open-source ทดแทน แต่ความจริงไม่ใช่แบบนั้น ทีม ArtCraft สร้างแอป native ด้วย Rust แบบ clean-room (PhotoCraft, LightCraft, FilmCraft ฯลฯ) โดยเขียนกฎใน AGENTS.md ชัดเจนว่าห้ามอ่าน ห้าม disassemble หรือคัดลอกอะไรจาก Adobe application bundles และอนุญาตแค่สังเกตพฤติกรรมจากภายนอก

นี่คือหลัก clean-room แบบคลาสสิกที่ Compaq เคยใช้สร้าง BIOS ของ IBM PC ในยุค 80s และศาลเคยยืนยันหลายครั้งว่า "การทำความเข้าใจ" ได้รับการปกป้องมากกว่า "การคัดลอก"

Oracle - ตัวตรวจสอบที่ตัดสินว่าอะไร "จริง"

สิ่งที่สำคัญที่สุดในการ reverse engineering ด้วย agent ไม่ใช่แค่การอ่านโค้ด แต่คือ Oracle หรือตัวตรวจสอบที่ตัดสินว่าผลงาน rebuild ของ agent "จริง" หรือไม่ Oracle มีหลายแบบ

• Byte oracle: เปรียบเทียบ machine code ทีละไบต์
• Behaviour oracle: ป้อน input เดียวกันแล้วเทียบ output
• Runtime oracle: รันโปรแกรมจริงแล้วดูพฤติกรรม

ตัวอย่างที่ชัดเจนคือกรณี DX-Ball ที่ agent สร้างฟังก์ชัน balance เสียงซ้าย-ขวา ผ่านการทดสอบ 3,205 เคส และตรงกันทุกไบต์ (63 ไบต์)

แต่เรื่องที่น่าสนใจกว่าคือ บั๊กที่หลอก Oracle จากงาน rebuild เกม Touhou (TH08) โดย N0zoM1z0 - ฟังก์ชันหนึ่งผ่านการเปรียบเทียบไบต์แบบ exact แล้ว แต่ต่อมาพบบั๊กในระบบ auto-collect item: ต้นฉบับเช็คค่า power ที่ 128.0 ในขณะที่โค้ดที่สร้างใหม่เช็คที่ 0.0 ทำไมถึงผ่าน? เพราะเครื่องมือเปรียบเทียบปรับ address ก่อนเทียบ instruction แต่ไม่ได้ตรวจค่า floating-point ที่เก็บอยู่จริง ผลคือ instruction ตรง แต่ความหมายผิด

บทเรียนที่ได้คือ ต้องทดสอบ Oracle ด้วย เพราะถ้าตัวตรวจสอบมีจุดบอด มันจะอนุมัติฟังก์ชันผิดๆ เป็นร้อยๆ ตัวโดยเงียบๆ

โรงงาน Reverse Engineering - ทำไมเกมที่สองใช้เวลาแค่ 12 วัน

จากประสบการณ์ของ N0zoM1z0: TH08 เริ่มจากงานของชุมชน ใช้เวลาประมาณ 11 วันได้ source ครบ 1,107 ฟังก์ชัน พร้อมพอร์ต Linux ที่เล่นได้ ส่วน TH095 เริ่มจากศูนย์ ใช้เวลาประมาณ 12 วันได้ source ครบ 697 ฟังก์ชัน และเล่นได้ ทำไมเร็วขึ้น? เพราะมีการสะสม checks, notes และบทเรียนจากเกมก่อนหน้าไว้ใน repo

กฎ 4 ข้อของ "โรงงาน" นี้:

1. ให้ agent มีอิสระในการสำรวจ ตั้ง goal และเกณฑ์การยอมรับไว้ชัด
2. ใช้ repo + git เป็นความจำระยะยาว (บทสนทนาจบ แต่ repo ยังอยู่)
3. ให้หลักฐานเป็นผู้ตัดสิน - "unknown" ก็เป็นคำตอบที่ถูกต้อง
4. ทดสอบ Oracle ด้วย

สถาปัตยกรรม multi-agent ที่ขับเคลื่อนโรงงาน

อนาคตของวิศวกรรมด้วย AI ไม่ได้อยู่ที่แค่ "ใช้โมเดลที่ใหญ่ขึ้น" แต่อยู่ที่การ orchestrate ระบบ multi-agent ที่แบ่งความเชี่ยวชาญตามความเร็ว ประสิทธิภาพต่อ context และความสามารถด้าน reasoning แทนที่จะโยนทุก token ใส่โมเดลตัวเดียวราคาแพง การทำงานลักษณะนี้ (ตามแนวทาง sub-agents ของ Claude Code) ใช้ทีมย่อยหลายตัว:

• Sonnet 5.5 (The Builder): เป็น session lead คุม workflow เขียนโค้ด และ apply การเปลี่ยนแปลงลง codebase
• Haiku 5.5 (The Swarm): รัน sub-agents ใน context ที่ทิ้งได้ ทำหน้าที่ search (ทำแผนที่ repo), grep (หา call sites) และ audit (ตรวจ diff) โดยไม่รบกวน context หลัก
• Opus 5.5 (The Advisor): นั่งรอเฉพาะจุดเสี่ยงสูง - ก่อนล็อกแผน หลังเจอบั๊กซ้ำ หรือก่อน sign-off สุดท้าย
• JEV (The Router): ตัดสิน micro-forks (เลือก tool, path, retry) ในหลักมิลลิวินาที ส่งขึ้นสู่โมเดลหลักเฉพาะ decisions ที่มีหลายทางแยกจริงๆ

ประโยชน์เชิงเทคนิคคือ context window hygiene (ผลลัพธ์ tool ที่ noisy ถูกกักไว้ใน context ย่อย) ความคุ้มค่า (token ระดับ Opus ใช้เฉพาะการตัดสินใจสำคัญ ไม่ใช่อ่านไฟล์ทั่วไป) และ การตรวจสอบที่ปลอดภัย (audit agent รันใน git worktree แยก ไม่แตะ branch ที่กำลังพัฒนา)

วิธีทำงานแบบ Clean Room ด้วย agent

แบ่งเป็นสองห้อง: ห้อง A (Reader) ใช้ REA วิเคราะห์ แล้วเขียน SPEC.md (พฤติกรรม input/output edge cases) โดยไม่ส่งโค้ดหรือ address ออกไป ส่วน ห้อง B (Builder) เป็น session ใหม่ในโฟลเดอร์แยก ได้รับแค่ SPEC.md แล้วสร้างโค้ดใหม่ ใช้ /goal ของ Claude Code เพื่อให้ agent ทำงานวนจนกว่าเงื่อนไขจะผ่าน และปลูก "ความล้มเหลว" ไว้ 3 อย่างใน oracle เพื่อทดสอบว่าตัวตรวจสอบยังทำงานถูกต้อง

ข้อจำกัดและเส้นแบ่งที่สำคัญ

• มันอ่านได้เฉพาะโค้ดที่อยู่บนเครื่องคุณ (ไม่ถึง server-side)
• ผลลัพธ์เป็น reconstruction ไม่ใช่ source ต้นฉบับ
• โมเดลอย่าง Opus 5.5 มี safeguard ด้าน cybersecurity และจะปฏิเสธงานที่ดูเหมือนการ crack หรือ bypass
• การทำความเข้าใจ + สร้างเวอร์ชันของตัวเอง = ทางที่ถูกกฎหมาย (clean room) ส่วนการเอาฟีเจอร์ของคนอื่นมาใช้โดยไม่จ่ายเงิน หรือคัดลอกโค้ด = ไม่ใช่

สรุป

Berman พูดถูกครึ่งหนึ่ง - แนวคิดที่ว่า "ซอฟต์แวร์ปิดหมายความว่าไม่สามารถรู้ได้" กำลังจบลง คุณสามารถอธิบายฟีเจอร์ใดๆ บนเครื่องตัวเองพร้อมหลักฐานได้ภายในบ่ายเดียว แต่สิ่งที่ยังไม่จบคือความแตกต่างระหว่าง "การอ่าน" กับ "การเอาไป" และสิ่งที่ตัดสินว่าการ rebuild จะใช้งานได้จริงหรือไม่ ไม่ใช่โมเดล AI แต่คือ Oracle และการที่คุณยอมทดสอบ Oracle ด้วย

สร้างระบบตรวจสอบก่อน แล้วค่อยอ่านอะไรก็ได้