วันที่ 8 ตุลาคม REA ขึ้นอันดับหนึ่งบนหน้า Trending ของ GitHub แต่ผ่านไปอีกสิบวัน คนส่วนใหญ่ที่กดดาวให้โปรเจกต์ก็ยังใช้งานมันผ่านหน้าต่างแชตเดียว
บันทึกบทความนี้ไว้ เพราะไฟล์เอเจนต์ พรอมป์ต์ และคำสั่งทั้งหมดด้านล่างแสดงไว้ครบ สามารถนำทั้งทีมไปใส่ใน Repository ของคุณได้เลย
Matthew Berman สรุปการเปิดตัวด้วยคำสั้น ๆ เพียงสามคำ และตอนนี้โพสต์นั้นมียอดดู 3.8 ล้านครั้งแล้ว
9 ต.ค.
Reverse Engineer Anything 😂 ซอฟต์แวร์จบแล้ว
REA เป็น MCP Server และ CLI แบบโอเพนซอร์สของ morluto ซึ่งทำให้ Coding Agent ใช้เครื่องมือ Disassembler จริง ๆ ได้ จึงตรวจสอบแอปได้ลึกลงไปถึงระดับไบนารี
เวอร์ชันแรกเปิดตัววันที่ 12 กรกฎาคม ส่วน v6.7 เพิ่งออกในเช้าวันที่ผู้เขียนกล่าวถึง โดยมี Pull Request ที่ Merge แล้ว 236 รายการจากผู้ร่วมพัฒนามากกว่า 120 คน
ก่อนหน้านั้นสองวัน Perplexity ได้เพิ่ม REA เป็น Skill ในตัวของ Computer Agent สะท้อนว่าโปรเจกต์นี้เปลี่ยนจากการทดลองบน GitHub ไปเป็นเครื่องมือพร้อมใช้อย่างรวดเร็ว
16 ต.ค.
REA (Reverse Engineer Anything) ของ @morluto กลายเป็น Skill ใน Computer แล้ว เพียงขอให้ Computer ทำ Reverse Engineering แอป ระบบจะตรวจสอบการทำงานโดยไม่ต้องมี Source Code จากนั้นสร้างเวอร์ชันที่ทำงานได้ขึ้นมาใหม่ งานที่ใช้
/reverse-engineerฟรีถึงวันที่ 31 ตุลาคม โดยข้อความต้นฉบับระบุจำนวนสูงสุดไว้เพียง “10,000” โดยไม่มีรายละเอียดต่อ
ก่อนเริ่ม: ทำไมการใช้แชตเดียวจึงเกิดปัญหา
เซสชันเดียวอาจวิเคราะห์ฟังก์ชันหนึ่งได้ดี แต่เมื่อไปถึงประมาณฟังก์ชันที่ 40 งานมักเริ่มคลาดเคลื่อน เพราะโมเดลกำลังแบกข้อสันนิษฐานทั้งหมดที่สะสมมาตลอดทาง
มันอาจตั้งชื่อ Struct ที่เคยตั้งไปแล้วใหม่ นำข้อคาดเดาเก่ามาปฏิบัติเหมือนเป็นข้อเท็จจริง และเมื่อสั่งให้สร้างโปรแกรมใหม่ ก็อาจกลับไปหยิบโค้ดที่เพิ่ง Decompile มาใช้โดยตรง
หลังจากนั้นมันยังตรวจงานที่ตัวเองสร้าง แล้วสรุปเองว่าดูถูกต้อง ซึ่งเป็นวิธีตรวจสอบโค้ดที่อ่อนแอมาก
ทางแก้มีอยู่แล้วใน Claude Code เพราะ Subagent แต่ละตัวภายใต้ .claude/agents/ มี Context ของตัวเอง มีพรอมป์ต์เฉพาะ และกำหนดชุดเครื่องมือที่อนุญาตให้ใช้แยกกันได้
คู่มือนี้จึงแบ่งเอเจนต์ 4 ตัว ให้แต่ละตัวรับผิดชอบคนละหน้าที่:
- Analyst — เปิดโปรแกรมเป้าหมายผ่าน REA สำรวจโครงสร้าง และติดป้ายแต่ละข้อค้นพบว่าเป็นสิ่งที่สังเกตพบ (observation), ข้ออนุมาน (inference) หรือสิ่งที่ยังไม่ทราบ (unknown)
- Spec Writer — เปลี่ยนผลวิเคราะห์เป็นข้อกำหนดเชิงพฤติกรรม โดยไม่ใส่ Address, Offset หรือชื่อที่ได้จากการ Decompile
- Rebuilder — เขียนโค้ดใหม่โดยอาศัยสเปกเท่านั้น และไม่มีสิทธิ์ใช้เครื่องมือ REA ในการตั้งค่า
- Verifier — ส่งอินพุตเดียวกันให้ทั้งโปรแกรมต้นฉบับและโปรแกรมที่สร้างใหม่ แล้วรายงานอัตราความตรงกัน (Match Rate)
ข้อที่สามสำคัญกว่าที่หลายคนคิด เพราะกฎที่เขียนไว้ในพรอมป์ต์อาจถูกละเลยได้ แต่เครื่องมือที่ไม่เคยอนุญาตให้เอเจนต์ใช้ จะเรียกใช้งานโดยตรงไม่ได้
แนวคิด Clean Room กำลังได้รับความนิยม มีโพสต์หนึ่งที่อธิบายเทคนิคสร้างโปรแกรมใหม่ด้วย REA และได้ยอดบันทึกมากกว่า 1,900 ครั้งในสองวัน
16 ต.ค.
นี่คือขุมทองจริง ๆ เทคนิค REA ที่ดีที่สุดซึ่งแทบไม่มีใครใช้ คือให้ REA แยกวิเคราะห์แอป ให้ Jev เก็บเฉพาะสิ่งที่พิสูจน์ได้ แล้วใช้ Opus 5.5 ตัวใหม่สร้างฟีเจอร์นั้นกลับขึ้นมาจากข้อมูลที่พิสูจน์แล้วเพียงอย่างเดียว วิธีนี้ไม่ต้องคัดลอกโค้ด และไม่ปล่อยให้ข้อเดากลายเป็นโค้ด เพราะตัวสร้าง... (ข้อความต้นฉบับถูกตัดจบไว้ตรงนี้)
แต่โพสต์เหล่านั้นไม่ได้แจกไฟล์ที่ใช้จริง คู่มือนี้จึงรวบรวมการทำงานเป็น 7 ขั้นตอน ตั้งแต่โฟลเดอร์ .claude/agents ที่ยังว่าง ไปจนถึงฟีเจอร์ที่สร้างใหม่พร้อมตัวเลข Match Rate
01. ติดตั้ง REA แล้วแยกสภาพแวดล้อมออกเป็นสองส่วน
ขั้นตอนทั้งหมดเริ่มจากการติดตั้ง REA เพียงชุดเดียว ซึ่งตามบทความใช้เวลาประมาณห้านาที หาก Node.js เป็นเวอร์ชันที่รองรับ
เวอร์ชันที่บทความระบุคือ Node 22.19 ขึ้นไปในสาย 22, Node 24.11 ขึ้นไปในสาย 24 หรือ Node 26 ขึ้นไป ควรตรวจเวอร์ชันก่อนเริ่มแก้ปัญหาอื่น
node -v # 22.19+, 24.11+ or 26+
npx rea-agents@latest setup # pick Claude Code, review the plan, approve
npm install --global rea-agents # the short rea command
npx -y rea-agents@latest doctor --client claude_code --skill --json
ขั้นตอน Setup จะแสดงรายการไฟล์ที่กำลังจะเปลี่ยนก่อนเขียนจริง สำหรับ Claude Code จะลงทะเบียนเซิร์ฟเวอร์ชื่อ rea ใน ~/.claude.json และติดตั้ง Workflow Skill ใน ~/.claude/skills
ชื่อเซิร์ฟเวอร์นี้สำคัญ เพราะเครื่องมือ REA ทุกตัวจะถูกนำเสนอให้ Claude Code ภายใต้คำนำหน้า mcp__rea__ ซึ่งไฟล์เอเจนต์ใช้เป็นตัวกำหนดว่าใครได้รับสิทธิ์ใช้ Disassembler
REA มีการแก้ไขบั๊กแทบทุกวัน และตามช่วงเวลาที่บทความกล่าวถึง v6.7 เพิ่งออกพร้อม Pull Request ที่ Merge แล้ว 236 รายการ จึงแนะนำให้อัปเดตก่อนเริ่มวิเคราะห์เป้าหมายจริง
18 ต.ค.
rea v6.7 เปิดตัวแล้ว มีผู้ร่วมพัฒนากว่า 120 คน และ Merge PR แล้ว 236 รายการ (ยังมีการแก้ใน Commit อีกมาก) น่าจะเสถียรและเร็วขึ้นมากหลังจากช่วยกันแก้บั๊กจำนวนมาก!
rea update
จากนั้นติดตั้ง Engine เฉพาะประเภทไฟล์ที่ต้องวิเคราะห์: แอป Electron และ Assembly ของ .NET ไม่ต้องใช้ Native Engine เพิ่ม แต่ไบนารี Native ต้องใช้ Ghidra, Hopper หรือ IDA
# native apps and games
export GHIDRA_INSTALL_DIR=/absolute/path/to/ghidra
export JAVA_HOME=/absolute/path/to/jdk
npx -y rea-agents@latest doctor --provider ghidra --json
ต่อไปคือประเด็นที่หลายบทความเกี่ยวกับ Clean Room มักข้าม ทั้งที่ระบุไว้ในคู่มือติดตั้ง REA เอง
การซ่อนเซิร์ฟเวอร์ rea จากเอเจนต์ เปลี่ยนแค่รายการเครื่องมือที่เอเจนต์ค้นพบผ่าน MCP เท่านั้น หากเอเจนต์ยังเข้าถึง Shell ได้ ก็อาจเรียก rea ผ่าน PATH หรือ npx รวมถึงอ่านไฟล์วิเคราะห์ที่หลงเหลืออยู่บนดิสก์ได้
เอกสารจึงระบุว่าการแยกอย่างแท้จริงต้องใช้บัญชีผู้ใช้ระบบปฏิบัติการแยก หรือ Container ที่มีข้อจำกัดด้าน Filesystem และเครือข่ายของตัวเอง นั่นหมายความว่า Rebuilder ไม่ควรแชร์โฟลเดอร์กับทีมที่วิเคราะห์ต้นฉบับ
จึงแบ่งทีมออกเป็นสองพื้นที่:
rea-team/
lab/ # Analyst, Spec Writer, Verifier. REA allowed
.claude/agents/analyst.md
.claude/agents/spec-writer.md
.claude/agents/verifier.md
target/ # the app you own
analysis/ # evidence, xrefs, notes
handoff/SPEC.md # the only file that crosses the wall
clean/ # Rebuilder. Own container, no REA
.claude/agents/rebuilder.md
SPEC.md # copied in, read-only
src/
Clean Room ทำงานใน Container ของตัวเอง โดย Mount เฉพาะ clean/ เท่านั้น ตัวอย่าง Devcontainer ของ Claude Code เป็นจุดตั้งต้นที่ดี เพราะจำกัดการเชื่อมต่อออกภายนอกด้วย Allowlist อยู่แล้ว
ติดตั้ง Dependency ที่จำเป็นให้ครบก่อน แล้วนำ npm Registry ออกจาก Allowlist เพื่อไม่ให้ Rebuilder ดึง rea-agents กลับเข้ามาผ่าน npx ระหว่างการ Build ได้
เมื่อจบขั้นตอนนี้ คำสั่ง doctor ของ REA ต้องผ่านใน lab/ ส่วน clean/ ต้องเป็น Container แยกที่มี Firewall และอนุญาตให้ส่งผ่านไฟล์สเปกเพียงเส้นทางเดียว
02. Analyst: หนึ่งเอเจนต์ หนึ่งไบนารี หนึ่งไฟล์หลักฐาน
Analyst เป็นเอเจนต์ตัวเดียวที่ได้รับหน้าที่เข้าถึงโปรแกรมเป้าหมาย จึงมีสิทธิ์ใช้เครื่องมือมากที่สุด แต่ต้องปฏิบัติตามรูปแบบผลลัพธ์ที่เข้มงวดที่สุดด้วย
เริ่มจากถาม REA ก่อนว่ามีเครื่องมืออะไรให้ใช้จริง เพราะชื่อเครื่องมือขึ้นกับเวอร์ชัน และเอกสารแนะนำคำสั่งนี้สำหรับดูรายการเครื่องมือที่เป็นมาตรฐานของเวอร์ชันที่ติดตั้ง
rea doctor --json > analysis/doctor.json
นำชื่อเครื่องมือ REA จากไฟล์ที่ได้มาใส่ในบรรทัด tools ด้านล่าง โดยเติมคำนำหน้า mcp__rea__ ซึ่ง Claude Code ใช้กับเครื่องมือของเซิร์ฟเวอร์ rea
สร้างไฟล์ lab/.claude/agents/analyst.md:
---
name: analyst
description: Investigates one feature of one target through REA and writes an evidence file. Use first, before any spec or rebuild work.
tools: Read, Grep, Glob, Write, mcp__rea__<tool names from doctor.json>
model: opus
---
You are a reverse engineering analyst. You work on one feature of one target
that the user owns or is authorized to examine.
Process:
1. Identify the target type (native, Electron/JS, .NET, Go, APK, WASM) and
pick the matching REA tool. Do not start deep analysis yet.
2. Map the target in one paragraph: what it is built with, how big it is,
where the feature most likely lives. Search strings before opening any function.
3. Rank candidate functions by cross-reference count and work from the top.
Never read in file order.
4. For each function: purpose in one sentence, data it reads and writes,
structures it uses, and a confidence from 1 to 10.
5. Under confidence 6, give the function a second pass using its already
resolved neighbors. Still under 6, mark it unknown and move on.
Every claim carries a tag and its evidence:
- observation: directly seen, with the address or call site
- inference: reasoned from observations, with the observations it rests on
- unknown: needed for the feature and not yet proven
Write everything to analysis/evidence.md. Do not write code for the
feature and do not write a spec. Those are other agents' jobs.
มีหลักการสำคัญสี่อย่างในไฟล์นี้
บรรทัด description เป็นข้อมูลที่ Claude Code ใช้ตัดสินใจว่าจะมอบงานให้ Subagent ตัวใด จึงต้องบอกทั้งสถานการณ์ที่ควรเรียกใช้และผลลัพธ์ที่ต้องส่งออก
บรรทัด tools ตั้งใจให้สั้น เพราะ Subagent ที่ไม่มีสิทธิ์ใช้ Bash และ Edit จะไม่สามารถแก้ไขหรือรันโปรแกรมเป้าหมายโดยไม่ตั้งใจ ประเด็นนี้สำคัญมากเมื่อเป้าหมายเป็นไบนารีที่เราต้องการเพียงอ่าน
ผู้สร้าง REA อธิบายแนวคิดนี้ในประโยคเดียวตอนเผยแพร่ครั้งแรก ซึ่งช่วยให้เห็นเหตุผลว่าทำไมเครื่องมือของ Analyst จึงมีเครื่องมือ REA และอย่างอื่นเพียงเล็กน้อย
7 ต.ค.
ผมเขียนชุดเครื่องมือให้เอเจนต์ทำ Reverse Engineering ได้อย่างมีประสิทธิภาพ :) พวกมันทำอะไรได้ลึกมากเมื่อใช้ Hopper, Ghidra และเครื่องมืออื่นร่วมกัน
หลักการจัดอันดับด้วย Cross-reference อ้างอิงจากวิธีนับความเชื่อมโยงของ REA เช่น ฟังก์ชันที่ถูกเรียก 147 ครั้งอาจเป็นตัวโหลด Config ที่หลายส่วนของแอปพึ่งพา ส่วนฟังก์ชันที่ถูกเรียกเพียงสองครั้งอาจเป็น Helper ที่ค่อยตรวจภายหลังก็ได้
ป้าย unknown คือสิ่งที่คนมักลืม แต่เป็นตัวช่วยให้ Spec Writer ไม่เผลอแต่งข้อมูล เพราะทุกสิ่งที่ยังไม่ทราบจะกลายเป็นช่องว่างที่ระบุชัดในสเปก แทนที่จะเป็นข้อคาดเดาที่ดูเหมือนข้อเท็จจริง
มีอีกโพสต์หนึ่งในสัปดาห์เดียวกันที่กล่าวถึงช่องว่างแบบนี้จากอีกมุมหนึ่ง ซึ่งตรงกับปัญหาที่ป้าย unknown พยายามแก้
15 ต.ค.
REA เมื่อใช้ร่วมกับ Opus 5.5 ทรงพลังมาก ทำให้เอเจนต์ตรวจสอบแอปที่ไม่มี Source Code ได้ แต่การหาโค้ดเจอไม่ได้แปลว่าพิสูจน์พฤติกรรมได้แล้ว ผมจึงอธิบายวิธีเปลี่ยน Black Box ให้เป็นโปรแกรมที่ Build และทดสอบได้จริง ↓
ต่อไปลองมอบงานจริงจากโฟลเดอร์ lab:
cd rea-team/lab
claude
> Use the analyst agent on target/Notes.app. Feature: how search ranks results.
ตัวอย่างไฟล์หลักฐานที่ได้มีหน้าตาลักษณะนี้ และรูปแบบนี้จะเป็นข้อมูลตั้งต้นให้เอเจนต์ตัวถัดไป:
## F-014 rank_results (confidence 8)
observation Called from 3 sites, 147 xrefs, reads the query index and a weight table [0x100012ab0]
observation Sorts descending by score, ties broken by modified date [0x100012c40]
inference Weights are loaded at startup, based on the config loader call at entry
unknown Where the weight table gets its default values
ให้ทดลองกับฟีเจอร์เดียวก่อน โดยกำหนดขอบเขตให้สรุปได้ในหนึ่งประโยค เพราะการวิเคราะห์ทั้งแอปในรอบเดียวอาจทำให้ความพยายามที่ล้มเหลวมีต้นทุนประมาณสองเท่าของรอบที่สำเร็จ
งานของ Analyst จบเมื่อมีไฟล์ evidence.md และทุกฟังก์ชันที่เกี่ยวข้องกับฟีเจอร์มีคะแนนความเชื่อมั่น ซึ่งเป็นข้อมูลที่ Spec Writer จะอ่านต่อ
03. Spec Writer: สร้างไฟล์เดียวที่ส่งข้ามกำแพงได้
Spec Writer อ่าน evidence.md แล้วผลิต handoff/SPEC.md ซึ่งเป็นเอกสารเพียงฉบับเดียวที่ Rebuilder จะได้รับ
สร้างไฟล์ lab/.claude/agents/spec-writer.md:
---
name: spec-writer
description: Turns analysis/evidence.md into a behavior-only specification. Use after the analyst finishes and before any rebuild.
tools: Read, Write
model: opus
---
Read analysis/evidence.md and write handoff/SPEC.md.
Describe behavior only: every public interface, the data model, each
user-visible feature as a testable requirement, the file formats read and
written, and error handling.
Never include addresses, offsets, decompiled names, assembly or any code
from the original. A developer who has never seen the binary must be able
to implement a compatible version from this document alone.
Every unknown in the evidence becomes an item under "Open questions".
Never turn an unknown into a requirement.
Sections: Architecture, Data Model, Public API, File Formats, Errors,
Test Cases, Open questions.
บรรทัด tools ไม่มี Bash และไม่มี REA ทำให้เอเจนต์ตัวนี้ทำได้เพียงอ่านหลักฐานและเขียนไฟล์สเปก
ส่วน Test Cases ต้องตรวจเป็นพิเศษ เพราะแต่ละเคสประกอบด้วยอินพุตและผลลัพธ์ที่คาดหวัง และ Verifier ในขั้นตอนที่ 05 จะใช้เคสเดียวกันทดสอบทั้งสองเวอร์ชัน
ส่วน Open questions ช่วยให้ Rebuilder ไม่แต่งคำตอบขึ้นเอง เพราะสิ่งที่ระบุชัดว่าเป็นช่องว่างจะไม่ถูกเปลี่ยนเป็นข้อสันนิษฐานที่ดูมั่นใจในโค้ด
อย่างไรก็ตาม ไฟล์หลักฐานยังมี Address อยู่ จึงต้องตรวจไฟล์สเปกก่อนส่งออกจาก lab
grep -nEi '0x[0-9a-f]{5,}|sub_[0-9a-f]+|var_[0-9a-f]+|FUN_[0-9a-f]+' handoff/SPEC.md
# no output means nothing leaked
หาก grep ไม่แสดงผล ให้คัดลอกไฟล์ข้ามไปแล้วตั้งเป็นอ่านอย่างเดียว:
cp handoff/SPEC.md ../clean/SPEC.md && chmod a-w ../clean/SPEC.md
04. Rebuilder: เอเจนต์ใหม่ที่รู้เฉพาะสิ่งที่อยู่ในสเปก
Rebuilder ทำงานใน Clean Container จากขั้นตอน 01 โดยเห็นเพียง SPEC.md และโฟลเดอร์สำหรับเขียนโค้ดของตัวเอง
มีหลายคนอธิบายกระบวนการลักษณะเดียวกันในสัปดาห์นั้น โดยให้สเปกเป็นจุดส่งต่องานเพียงจุดเดียวระหว่างการอ่านโปรแกรมกับการสร้างใหม่
17 ต.ค.
นี่เริ่มทรงพลังจนน่าตกใจ... ผู้สร้าง REA เพิ่งเผยแพร่ GitHub Repo 20 รายการสำหรับสร้างสตูดิโอ Reverse Engineering ครอบคลุม [01] การวิเคราะห์แกนหลัก [02] มือถือและแอป [03] ไบนารีและระดับล่าง [04] เครือข่ายและ Runtime [05] การสร้างใหม่และตรวจสอบ ลำดับคือ binary → REA → SPEC.md → rebuild → oracle → retry ชี้ไปที่แอปหนึ่งแล้วดูระบบอธิบายการทำงานของมัน
แต่โพสต์เหล่านั้นไม่ได้แสดง Config ของ Rebuilder โดยตรง บทความนี้จึงเตรียมไว้ให้
สร้างไฟล์ clean/.claude/agents/rebuilder.md:
---
name: rebuilder
description: Implements a feature from SPEC.md alone. Use only inside the clean container.
tools: Read, Write, Edit, Bash
model: opus
---
Your only source of truth is SPEC.md.
1. Choose the language and structure that fit your own project. Do not
try to match the original's internals.
2. Implement each requirement and write a test for every case under Test Cases.
3. Open questions are not yours to answer. Write each one to QUESTIONS.md
and keep going on everything else.
4. File formats come from public standards named in the spec.
Every icon, font and sound is drawn in code or openly licensed,
with a row in ATTRIBUTION.md.
5. If you notice you know something about the original that the spec does
not say, stop and report it. Do not use it.
ในขั้นตอนนี้อนุญาตให้ใช้ Bash เพราะ Container เป็นขอบเขตป้องกันอยู่แล้ว เอเจนต์จึง Build และรัน Test ได้โดยไม่แตะต้องสิ่งที่อยู่ใน lab
ก่อนเริ่มรันครั้งแรก ต้องตรวจว่าขอบเขตดังกล่าวใช้งานจริง โดยทดลองสามคำสั่งด้านล่าง ซึ่งควรล้มเหลวทั้งหมด:
which rea
npx --no-install rea-agents --version
ls /lab /target 2>&1
เมื่อ Build ผ่านการทดสอบของตัวเองแล้ว จึงนำ src/ ส่งกลับไปยัง lab เพื่อให้ Verifier ทดสอบ ซึ่งถือเป็นข้อมูลชิ้นที่สองที่ส่งข้ามขอบเขตนี้
05. Verifier: ใช้อินพุตชุดเดียวกันทดสอบทั้งสองเวอร์ชัน
Verifier อยู่ฝั่ง lab เพราะเป็นเอเจนต์ตัวเดียวที่ต้องเห็นทั้งโปรแกรมต้นฉบับและโปรแกรมที่สร้างใหม่พร้อมกัน
คัดลอก src/ ออกจาก Clean Container ก่อน และรันโปรแกรมต้นฉบับภายใน VM หรือ Sandbox เพราะเอเจนต์นี้จำเป็นต้อง Execute โปรแกรมจริง
สร้างไฟล์ lab/.claude/agents/verifier.md:
---
name: verifier
description: Runs the original and the rebuild on the same inputs and reports where they differ. Use after the rebuilder passes its own tests.
tools: Read, Write, Bash
model: opus
---
Compare the original at target/ with the rebuild at rebuild/.
1. Start with every case under Test Cases in handoff/SPEC.md.
2. Add generated inputs for three groups: ordinary use, edge values
(empty, maximum size, unicode) and malformed or corrupt input.
3. Run each input through both builds. Compare bytes where output is
deterministic and meaning where it is not.
4. Label every divergence: compatible (the spec allows it), wrong, or crash.
5. Write report.md with the match rate per group and every divergence
as input, original output, rebuild output.
Never edit the rebuild. Never edit the spec. Only report.
Verifier มีหน้าที่อ่านและรันทดสอบ แต่ไม่แก้ไขอะไร ดังนั้นผู้ที่พบข้อบกพร่องจึงไม่สามารถแก้ไขหรือทำให้ปัญหาหายไปจากรายงานด้วยตัวเอง
หน้าตารายงานจะประมาณนี้ (ตัวเลขเป็นเพียงตัวอย่างเพื่ออธิบายรูปแบบ):
ordinary 140 / 140 100%
edge 36 / 40 90%
malformed 22 / 32 69%
total 198 / 212 93.4%
D-007 wrong input: empty query
original: returns all items rebuild: returns nothing
ตัวอย่างนี้แสดงช่องว่างที่โปรแกรมต้นฉบับมีพฤติกรรมบางอย่างซึ่งยังไม่ได้อธิบายไว้ในสเปก
อย่าแก้โค้ดโดยตรง เพราะจะเท่ากับส่งรายละเอียดที่อ่านจากไบนารีให้ Rebuilder ผ่านตัวเราเอง ให้เปลี่ยนทุกกรณีที่ไม่ตรงกันเป็น Test Case ใหม่ในสเปก ส่งผ่านขอบเขตที่แยกไว้ แล้วรัน Rebuilder อีกรอบ
REA เคยสาธิตวิธีนี้กับฟังก์ชันเสียงของเกม DX-Ball โดยผ่าน Test Case ของโปรแกรม x86 ต้นฉบับ 3,205 เคส และสร้างไบนารีที่มี 63 ไบต์ตรงกับต้นฉบับทั้งหมด
06. คำสั่งเดียวสำหรับขับเคลื่อนทั้งทีม
ขอบเขตที่แยกสองฝั่งคือ Container ทำให้ Subagent ไม่สามารถข้ามไปมาเองได้ จึงต้องมีสคริปต์สั้น ๆ ควบคุมลำดับการทำงาน
สคริปต์นี้เรียกเอเจนต์ฝั่ง lab บน Host ส่ง SPEC.md เข้า Container นำ src/ กลับมาตรวจ แล้ววนซ้ำจนกว่า Verifier จะไม่พบผลลัพธ์ที่ผิดอีก
ก่อนอื่น เพิ่มหนึ่งบรรทัดท้ายพรอมป์ต์ Verifier ในขั้นตอน 05 เพื่อให้สคริปต์อ่านผลลัพธ์ได้:
End report.md with a single line: RESULT wrong=<n> crash=<n>
จากนั้นสร้างไฟล์ run-team.sh ไว้ระดับเดียวกับ lab/ และ clean/:
#!/usr/bin/env bash
set -euo pipefail
TARGET="$1"; FEATURE="$2"; MAX_ROUNDS=3
cd "$(dirname "$0")/lab"
claude -p "Use the analyst agent on $TARGET. Feature: $FEATURE"
claude -p "Use the spec-writer agent to write handoff/SPEC.md from analysis/evidence.md"
for round in $(seq 1 "$MAX_ROUNDS"); do
if grep -nEi '0x[0-9a-f]{5,}|sub_[0-9a-f]+|var_[0-9a-f]+|FUN_[0-9a-f]+' handoff/SPEC.md; then
echo "spec leaks decompiled names, stopping"; exit 1
fi
docker cp handoff/SPEC.md rea-clean:/work/SPEC.md
docker exec rea-clean claude -p "Use the rebuilder agent on /work/SPEC.md"
rm -rf rebuild && docker cp rea-clean:/work/src ./rebuild
claude -p "Use the verifier agent."
tail -n 1 report.md
grep -q 'RESULT wrong=0 crash=0' report.md && { echo "parity reached in round $round"; exit 0; }
claude -p "Use the spec-writer agent to add every wrong or crash divergence in report.md as a case under Test Cases in handoff/SPEC.md"
done
echo "no parity after $MAX_ROUNDS rounds, read report.md"; exit 2
รันสคริปต์โดยระบุโปรแกรมเป้าหมายและชื่อฟีเจอร์เป็นข้อความธรรมดา:
./run-team.sh target/Notes.app "how search ranks results"
ในสคริปต์มีรายละเอียดสำคัญสามข้อที่อาจดูเล็กน้อย
การตรวจการรั่วไหลของข้อมูล (grep) ทำก่อนส่งงานทุกครั้ง ไม่ใช่แค่รอบแรก เพราะ Spec Writer จะแก้ไขสเปกใหม่ทุกครั้งที่ผลทดสอบไม่ผ่าน
ลูปจำกัดไว้สามรอบ เพราะถ้าสร้างใหม่แล้วยังไม่ตรงหลังผ่านไปสามรอบ ปัญหามักอยู่ที่หลักฐานยังไม่ครบ และการวนต่อไปจะเพิ่มการใช้ Token เท่านั้น
สิ่งเดียวที่ส่งจากรายงานกลับไปหา Rebuilder คือ Test Case ใหม่ในสเปก พฤติกรรมของโปรแกรมต้นฉบับจึงเข้าถึง Clean Room ในรูปของข้อกำหนดพฤติกรรม ไม่ใช่โค้ด
07. ลองกับหนึ่งฟีเจอร์ของโปรแกรมที่คุณมีสิทธิ์ตรวจสอบ และรู้ข้อจำกัดของวิธีนี้
เลือกโปรแกรมที่คุณเขียนเองหรือได้รับอนุญาตให้ตรวจสอบ และเลือกฟีเจอร์ที่อธิบายขอบเขตได้ในหนึ่งประโยค เช่น วิธีจัดอันดับผลค้นหา หรือโครงสร้างไฟล์ Export
แอป Electron และ .NET Assembly เป็นเป้าหมายเริ่มต้นที่ง่าย เพราะ REA อ่านได้โดยไม่ต้องใช้ Native Engine และค่อยเพิ่ม Ghidra ในการทดลองครั้งถัดไปก็ได้
ผู้สร้าง REA กล่าวในวันที่ 11 ว่ามีคนนำเครื่องมือนี้ไปตรวจสอบตั้งแต่อุปกรณ์การเกษตร รถยนต์ ไปจนถึงโดรนแล้ว
12 ต.ค.
สิ่งที่เจ๋งที่สุดของ REA สำหรับผมคือการที่ทุกคนมีส่วนร่วมและแชร์สิ่งที่กำลังทำ ผมเห็นคนทำงานเกี่ยวกับเทคโนโลยีการเกษตร รถยนต์ โดรน และเครื่องเล่นเกมสารพัดชนิด วันนี้ REA ยังไม่สมบูรณ์แบบ แต่พวกเรากำลังช่วยกันพัฒนามันให้ดีขึ้น ขอบคุณผู้ร่วมพัฒนาทุกคน!
หลังรันงานแล้ว ให้อ่านไฟล์สามไฟล์ตามลำดับนี้: evidence.md เพื่อดูสิ่งที่ยังไม่ทราบ จากนั้นส่วน Open questions ของ SPEC.md แล้วจึงอ่าน report.md
./run-team.sh target/YourApp.app "how search ranks results"
หากนำผลลัพธ์ไปเผยแพร่ ให้ระบุตัวเลขที่วัดได้จริงไว้ด้านบน ได้แก่ Match Rate, จำนวนรอบที่ใช้ และจำนวน Token ที่ใช้ไป
ข้อจำกัดของแนวทางนี้มีไม่มาก และเกิดจากธรรมชาติการทำงานของ REA:
- REA อ่านสิ่งที่อยู่ในเครื่องของเราเท่านั้น โค้ดที่รันอยู่บนเซิร์ฟเวอร์ของบริษัทไม่ได้ถูกส่งมาพร้อมตัวแอป จึงไม่สามารถอ่านได้ด้วยวิธีนี้
- โค้ดที่ได้จากการ Decompile เป็นการสร้างโค้ดกลับขึ้นมาโดยประมาณ ขั้นตอน 05 จึงเปรียบเทียบพฤติกรรม ไม่ใช่เปรียบเทียบ Source Code
- ไบนารี Native ที่ถูกตัด Symbol ออก (Stripped Binary) ยังวิเคราะห์ยากกว่า Electron หรือ .NET
- ฟังก์ชันที่มีคะแนน Confidence ต่ำกว่า 6 แม้ตรวจครั้งที่สองแล้ว จะถูกทำเครื่องหมาย
unknownและข้ามไปทำส่วนอื่น
ข้อผิดพลาดห้าข้อที่ทำให้เสียเวลามากที่สุด:
- ให้ REA และ Rebuilder ทำงานภายใต้บัญชี OS เดียวกัน
- ข้ามขั้นตอน
grepตรวจข้อมูลรั่วไหล เพราะคิดว่าสเปก “ดูสะอาดแล้ว” - ส่งไฟล์
evidence.mdให้ Rebuilder อ่านเพื่อเพิ่ม Context - แก้โค้ดที่สร้างใหม่ด้วยมือหลัง Verifier แจ้งว่าทดสอบไม่ผ่าน
- สั่ง Analyst วิเคราะห์ทั้งแอป แทนที่จะจำกัดไว้เพียงฟีเจอร์เดียว
คำชี้แจงของ REA กำหนดขอบเขตการใช้เพื่อการวิจัยที่ถูกกฎหมาย การทำงานร่วมกันได้ระหว่างระบบ (Interoperability) การอนุรักษ์ซอฟต์แวร์ และซอฟต์แวร์ที่เราเป็นเจ้าของหรือได้รับอนุญาตให้ตรวจสอบ
ข้อตกลงการใช้งานซอฟต์แวร์อาจห้าม Reverse Engineering แม้กฎหมายไม่ได้ห้ามโดยตรง จึงควรอ่าน License Agreement ของโปรแกรมเป้าหมาย และถือว่าบทความนี้เป็นคู่มือทางวิศวกรรม ไม่ใช่คำแนะนำทางกฎหมาย
หนึ่งในความเห็นที่ถูกพูดถึงมากมาจาก CEO ของ Replit ซึ่งมองว่าซอฟต์แวร์กำลังมุ่งไปสู่ภาวะที่เปิดเผย Source Code โดยปริยาย
7 ต.ค.
สิ่งที่กำลังเกิดขึ้นกับ Reverse Engineering และ Decompilation ที่ใช้ AI น่าทึ่งมาก อีกไม่นานซอฟต์แวร์แทบทั้งหมดอาจกลายเป็นโอเพนซอร์สโดยพฤตินัย AI กำลังเข้ามาเปลี่ยนแปลงทุกอย่างและทุกคน
อย่างไรก็ตาม การคาดการณ์นั้นมีข้อจำกัดด้านสิทธิ์ของเจ้าของซอฟต์แวร์ จึงควรระบุในกฎของโปรเจกต์ (claude-md) ตั้งแต่บรรทัดแรกว่าโปรแกรมเป้าหมายต้องเป็นของเราหรือได้รับอนุญาตให้ตรวจสอบ
มีนักพัฒนาคนหนึ่งรวบรวมกรณีสาธารณะที่เอเจนต์ใช้วิเคราะห์ซอฟต์แวร์และฮาร์ดแวร์ โดยในสัปดาห์ที่บทความกล่าวถึงมี 286 กรณี และ 119 กรณีใช้ REA
17 ต.ค.
นี่เหมือนสูตรลัดสำหรับสาย Reverse Engineering 🔓🔥 นักพัฒนาคนหนึ่งกำลังรวบรวมกรณีที่ AI Agent แยกวิเคราะห์ซอฟต์แวร์และฮาร์ดแวร์ พบแล้ว 286 กรณี โดย 119 กรณีทำด้วยเครื่องมือ MCP แบบโอเพนซอร์สชื่อ REA ซึ่งช่วยให้... (ข้อความต้นฉบับถูกตัดจบไว้ตรงนี้)
สรุปการติดตั้งทั้งหมดในหน้าเดียว
เจ็ดขั้นตอนนี้จะได้ไฟล์ Agent สี่ไฟล์ สภาพแวดล้อมแยกสองฝั่ง และสคริปต์หนึ่งไฟล์สำหรับควบคุมการทำงาน
- 01 ติดตั้ง REA ใน
lab/และให้ Rebuilder อยู่ใน Container ของตัวเองโดยไม่มี REA - 02 Analyst จัดอันดับฟังก์ชันจาก Cross-reference และติดป้ายข้อค้นพบเป็น
observation,inferenceหรือunknown - 03 Spec Writer เปลี่ยนหลักฐานเป็นสเปกเชิงพฤติกรรม จากนั้นใช้
grepตรวจข้อมูลรั่วไหล - 04 Rebuilder เขียนโค้ดใหม่โดยอ้างอิง
SPEC.mdเท่านั้น และบันทึกทุกประเด็นที่ยังไม่มีคำตอบ - 05 Verifier ทดสอบต้นฉบับและเวอร์ชันสร้างใหม่ด้วยอินพุตเดียวกัน แล้วรายงาน Match Rate
- 06 run-team.sh ควบคุมการทำงานของทั้งสองฝั่ง วนทดสอบสูงสุดสามรอบ
- 07 ทดลองตั้งแต่ต้นจนจบกับหนึ่งฟีเจอร์ของโปรแกรมที่คุณเป็นเจ้าของ
หลังการรันครั้งแรก คุณจะได้รายงานที่แสดง Match Rate ไว้ด้านบน ตัวเลขนี้ใช้บอกว่าโปรแกรมที่สร้างใหม่มีพฤติกรรมตรงกับต้นฉบับมากน้อยเพียงใด
ผมเผยแพร่ผลงานและการทดลอง AI พร้อม Config ทั้งหมดและตัวเลขเบื้องหลัง หากอยากติดตามผลงานต่อไป ติดตาม @Gyome1_ ได้เลย
บันทึกบทความนี้ไว้ เพราะไฟล์เอเจนต์และสคริปต์ด้านบนคือส่วนที่คุณน่าจะกลับมาเปิดใช้งานอีกครั้ง