วิธี Reverse Engineer อะไรก็ได้ด้วย Opus 5.5

หากต้องการรีเวิร์สเอนจิเนียร์สิ่งใดก็ตามด้วย Opus 5.5 ให้เชื่อมต่อโมเดลเข้ากับเอนจินดิสแอสเซมเบลผ่าน REA จากนั้นทำงานเป็นขั้นตอน: กำหนดเส้นทางเป้าหมาย แผนผังเป้าหมาย ดีคอมไพล์ฟังก์ชันที่ถูกเรียกใช้บ่อยที่สุด ให้ Opus ตั้งชื่อและอธิบายฟังก์ชันเหล่านั้น เขียนสเปกที่อิงเฉพาะพฤติกรรม และสร้างใหม่จากสเปกนั้นในบริบทแยกต่างหาก จับคู่ระดับความพยายาม (effort level) ให้เหมาะสมกับแต่ละขั้นตอน และพิสูจน์การสร้างใหม่ด้วยการทดสอบความเทียบเท่า (parity tests)

นั่นคือเวอร์ชันย่อของคู่มือที่กลายเป็นไวรัลบน X เมื่อวันที่ 12 ตุลาคม 2026 นักสร้าง Movez ได้เผยแพร่หลักสูตร 11 ขั้นตอนเกี่ยวกับการรีเวิร์สเอนจิเนียร์ด้วย Claude Opus 5.5 หลักสูตรนี้มียอดชมเกิน 1 ล้านครั้ง และถูกบุ๊กมาร์ก 2,800 ครั้ง บทความนี้ตรวจสอบข้อกล่าวอ้างของหลักสูตรเทียบกับแหล่งข้อมูล แก้ไขรายละเอียดเกี่ยวกับ benchmark สองจุด และเพิ่มขั้นตอนที่คู่มือส่วนใหญ่ข้ามไป นั่นคือการทดสอบ API ที่เป้าหมายสื่อสารด้วย

ใช้สิ่งนี้กับซอฟต์แวร์ที่คุณเป็นเจ้าของหรือได้รับอนุญาตให้ตรวจสอบเท่านั้น README ของ REA จำกัดการใช้งานเครื่องมือนี้ไว้สำหรับ "การวิจัยที่ถูกกฎหมาย การศึกษา การทำงานร่วมกัน (interoperability) การอนุรักษ์ซอฟต์แวร์ และการวิเคราะห์ซอฟต์แวร์ที่คุณเป็นเจ้าของหรือได้รับอนุญาตให้ตรวจสอบ"

ทำไม Opus 5.5 ถึงต้องมีเครื่องมืออ่านไบนารี

Opus 5.5 อ่านและเขียนข้อความได้ แต่ไม่สามารถโหลดไฟล์ Mach-O หรือ ELF ได้ด้วยตัวเอง REA เป็น MCP server ที่ทำหน้าที่เป็นตัวกลางระหว่างเอเจนต์ของคุณกับเอนจินวิเคราะห์ (Hopper, Ghidra หรือ IDA สำหรับโค้ดเนทีฟ) รันการวิเคราะห์ในเครื่อง และส่งคืนผลการค้นพบพร้อมหลักฐาน ได้แก่ แอดเดรส pseudocode สตริง และจุดเรียกใช้ (call sites) โมเดลอ่านผลการค้นพบเหล่านั้นแล้วถามคำถามถัดไป

REA มียอดดาว GitHub เกิน 393,000 ดวงภายในวันที่ 27 ตุลาคม 2026 เพิ่มขึ้นจากประมาณ 115,000 ดวงในวันที่ 12 ตุลาคม เราได้เขียนถึง REA คืออะไรและทำงานอย่างไร และ ลูป 6 ขั้นตอนสำหรับการสร้างฟีเจอร์ของแอปหนึ่งอย่างขึ้นใหม่ ตอนที่มันเริ่มเป็นกระแสครั้งแรก คู่มือนี้เน้นด้านโมเดล ได้แก่ พรอมต์ การตั้งค่าความพยายาม และข้อจำกัดต่าง ๆ

ขั้นตอนที่ 1: ติดตั้ง REA และเขียนกฎประจำบ้าน

REA ต้องใช้ Node.js 22.23.4 หรือใหม่กว่าบนสาย 22 (24.22.1+ หรือ 26.12.1+ ก็ใช้ได้เช่นกัน) พร้อมกับ npm เวอร์ชัน npm ปัจจุบันคือ 6.8.0 ลงทะเบียนกับเอเจนต์ของคุณ:

npx rea-agents setup
npm install --global rea-agents
rea --help

การตั้งค่าจะแสดงตัวอย่างการเปลี่ยนแปลงคอนฟิก สำรองข้อมูลสิ่งที่มันแตะต้อง และรองรับ Claude Code, Codex, Cursor, Gemini CLI และ Grok Build การวิเคราะห์แบบเนทีฟต้องใช้ Hopper, Ghidra หรือ IDA ส่วนการตรวจสอบ JavaScript, Electron และ .NET ไม่ต้องใช้เอนจิน

จากนั้นกำหนดกฎประจำบ้านให้เอเจนต์ บล็อก CLAUDE.md ในหลักสูตรคือส่วนที่ดีที่สุดของเธรดนี้:

# Reverse-engineering house rules
- Only analyze targets I own or am authorized to examine. State the basis once.
- Tag every claim: observation, inference, or unknown.
- Cite the evidence: address, bytes, pseudocode or call site.
- Start with the smallest overview. Expand only on a concrete gap.
- Separate static facts from runtime facts.
- Build from behavior and public specs, never from copied code or assets.
- Every recovered behavior needs a passing test before "done".

ขั้นตอนที่ 2: เลือกระดับความพยายามสำหรับแต่ละขั้นตอน

Opus 5.5 รองรับระดับความพยายาม 5 ระดับ: low, medium, high, xhigh และ max ตาม เอกสารเรื่อง effort ของ Anthropic Opus 5.5 ใช้ค่าเริ่มต้นที่ medium ส่วน xhigh มุ่งเป้าไปที่การรันแบบเอเจนต์ที่ยาวนาน และ max จะลบข้อจำกัดทั้งหมดเกี่ยวกับการใช้โทเคน คุณตั้งค่าได้ด้วย output_config.effort บน API หรือผ่านการตั้งค่า effort ของเอเจนต์คุณ

การแบ่งระดับของหลักสูตรเป็นจุดเริ่มต้นที่สมเหตุสมผล ไม่ใช่กฎที่ผ่านการวัดผล:

เพิ่ม effort ต่อฟังก์ชัน ไม่ใช่ต่อเซสชัน

ขั้นตอนที่ 3: กำหนดเส้นทางเป้าหมายก่อนเปิดอะไรทั้งนั้น

ความผิดพลาดที่พบบ่อยที่สุดของมือใหม่คือการเปิดดิสแอสเซมเบลอร์กับแอป Electron ที่โค้ด JavaScript เปิดเผยให้เห็นอยู่ตรง ๆ REA ครอบคลุมการติดตั้งบนเดสก์ท็อป ไบนารีเนทีฟ แอป JavaScript และ Electron แอสเซมบลี .NET APK ของ Android, WASM เว็บไซต์ และไฟล์บันทึกเครือข่ายที่เซฟไว้ โดยแต่ละประเภทมีเครื่องมือเข้าถึงของตัวเอง พรอมต์แรกของคุณควรระบุเป้าหมายเท่านั้น:

I want to understand how [FEATURE] works in [APP] at [ABSOLUTE PATH].
First tell me what kind of target this is (native, Electron/JS, .NET, APK, WASM)
and which REA tool opens it. Don't start deep analysis yet.
Then give me a one-paragraph map and where you'd look first for [FEATURE].
Keep observations, inferences and unknowns separate.

เป้าหมายแบบ Electron จะไปที่ analyze-javascript-application (โมดูล, อิมพอร์ต, ขอบเขต IPC, ไม่ใช้เอนจิน) เป้าหมายแบบเนทีฟจะไปที่ open_binary

ขั้นตอนที่ 4: ทำแผนผังสตริงและจัดอันดับฟังก์ชันตาม cross-references

ยังไม่ต้องอ่านโค้ด สำหรับเป้าหมายแบบเนทีฟ ให้เริ่มด้วยการทำรายการสำรวจ:

rea inspect /absolute/path/to/program --provider ghidra --json
rea search /absolute/path/to/program entry --kind procedures --provider ghidra --json

สตริงคือเบาะแสที่เร็วที่สุดของคุณ: URL ข้อความแสดงข้อผิดพลาด และชื่อฟีเจอร์ base URL หรือสตริง Authorization: Bearer ยังบอกคุณว่าไบนารีสื่อสารกับ API ซึ่งสำคัญในขั้นตอนที่ 9

จากนั้นจัดอันดับฟังก์ชันตาม cross-references (จำนวนตำแหน่งที่เรียกใช้ฟังก์ชันนั้น) ฟังก์ชันที่มีผู้เรียก 147 จุดน่าจะเป็นโครงสร้างพื้นฐานหลัก เช่น ตัวโหลดคอนฟิก ส่วนฟังก์ชันที่มีผู้เรียก 2 จุดรอได้ อ่านจากบนลงล่าง

ขั้นตอนที่ 5: ดีคอมไพล์หนึ่งฟังก์ชัน แล้วให้ Opus ตั้งชื่อ

ดีคอมไพล์ฟังก์ชันร้อนเพียงหนึ่งฟังก์ชัน:

rea function /absolute/path/to/program parseConfig --provider ghidra --json
rea decompile /absolute/path/to/program --procedure=parseConfig --provider ghidra --json

ผลลัพธ์ออกมาหยาบ ๆ (var_28 มีการแคสต์เต็มไปหมด) ส่งให้ Opus 5.5 ที่ effort ระดับ high พร้อมเช็กลิสต์ตายตัว:

Here is decompiled pseudocode for a function with 147 cross-references.
1. Rename every variable based on how it is used.
2. State the function's purpose in one sentence.
3. List the data structures it reads and writes.
4. Name the pattern (singleton, factory, state machine, observer).
5. Flag missing error handling, validation or security checks.
Mark anything you're unsure of instead of guessing.

ดีคอมไพเลอร์มักให้รายละเอียดผิดพลาด ใน โชว์เคส DX-Ball ของ REA pseudocode แรกแสดงฟังก์ชันปรับแพนเสียงที่รับอินพุตเป็นศูนย์ มีเพียงมุมมองคำสั่ง (instruction view) เท่านั้นที่เปิดเผยพารามิเตอร์ การสร้าง C ใหม่ครั้งสุดท้ายผ่านกรณีทดสอบ x86 ต้นฉบับ 3,205 กรณี และสร้างไบต์ของฟังก์ชันที่คอมไพล์แล้วทั้ง 63 ฟังก์ชันขึ้นมาใหม่ได้ครบ เพราะเอเจนต์ตรวจสอบ pseudocode เทียบกับแอสเซมบลีและผู้เรียกไขว้กัน ขอ rea instructions เมื่อลายเซ็นดูแปลก ๆ

ขั้นตอนที่ 6: ตั้งงบประมาณให้โค้ดที่ถูกทำให้สับสน อย่าไปบดขยี้มัน

นี่คือจุดที่หลักสูตรไวรัลต้องได้รับการแก้ไข หลักสูตรอ้างถึง benchmark การทำให้สับสนของ Elastic Security Labs ว่าเป็นการทดสอบ "Claude Opus" การศึกษาของ Elastic ที่เผยแพร่เมื่อวันที่ 21 เมษายน 2026 ทดสอบ Claude Opus 4.6 ไม่ใช่ Opus 5.5 ตัวเลขมีดังนี้:

โดยรวมแล้ว Opus 4.6 แก้เป้าหมายที่ประเมินได้ 8 จาก 20 รายการ (40%) ความสำเร็จใช้จ่ายเฉลี่ย $2.39 และความล้มเหลว $4.83 ดังนั้นความล้มเหลวมีต้นทุนประมาณสองเท่าของความสำเร็จ มองตัวเลขเหล่านี้เป็นขอบล่าง ไม่ใช่การวัด Opus 5.5 เราไม่พบข้อมูลเทียบเท่าที่เผยแพร่สำหรับ 5.5

ประการที่สอง หลักสูตรกล่าวว่าเครื่องมือชื่อ Caveman "กำจัดขยะจากการดีคอมไพล์ได้ประมาณ 75%" Elastic อธิบายว่า Caveman เป็นปลั๊กอินที่ลดความยาวเยิ่นเย้อของโมเดลเองได้สูงสุด 75% ไม่ใช่ตัวกรองโค้ดที่ถูกดีคอมไพล์

บทเรียนยังใช้ได้: จำกัดการใช้จ่ายต่อฟังก์ชันที่ถูกทำให้สับสน ขอคะแนนความมั่นใจ 1 ถึง 10 และพักสิ่งที่ต่ำกว่า 6 ไว้จนกว่าฟังก์ชันข้างเคียงจะถูกไขได้

ขั้นตอนที่ 7: แยกเป้าหมายใหญ่เป็นคอนโทรลเลอร์และเวิร์กเกอร์

แชทเดียวรับ 500 ฟังก์ชันไม่ไหว มันลืมชื่อและขัดแย้งตัวเอง วิธีแก้ของหลักสูตรคือคอนโทรลเลอร์ที่ไม่วิเคราะห์โค้ดเลย และเวิร์กเกอร์ที่รับผิดชอบฟังก์ชันละหนึ่งตัว:

Controller: The function map is in functions.json (address, name, size, xrefs).
Cluster functions by call-graph proximity, order clusters by xref count,
send each cluster to a worker, inject already-resolved struct names into every
brief, and queue a second pass for any result with confidence below 6.
Report token spend after each cluster.

เวิร์กเกอร์แต่ละตัวส่งคืนแอดเดรส จุดประสงค์ คะแนนความมั่นใจ 1 ถึง 10 สตรัคต์ที่มันใช้หรือค้นพบ และซอร์สโค้ดที่สะอาด โดยใช้ชื่อสตรัคต์ของคอนโทรลเลอร์ซ้ำ benchmark ของ Elastic ก็ใช้รูปแบบคอนโทรลเลอร์และเวิร์กเกอร์แบบเดียวกัน

ขั้นตอนที่ 8: เขียนสเปกที่อิงเฉพาะพฤติกรรมในบริบทที่สะอาด

การสร้างใหม่แบบ clean-room คัดลอกสิ่งที่ซอฟต์แวร์ทำ ไม่ใช่โค้ดของมัน ขอสเปกที่อิงเฉพาะพฤติกรรมจาก Opus: อินเทอร์เฟซสาธารณะ โมเดลข้อมูล แต่ละฟีเจอร์ในรูปข้อกำหนดที่ทดสอบได้ รูปแบบไฟล์ตามมาตรฐานสาธารณะ และการจัดการข้อผิดพลาด ห้ามมีแอดเดรส ชื่อที่ได้จากการดีคอมไพล์ และสิ่งใดที่คัดลอกมา

จากนั้นนำไปสร้างจริงจากสเปกนั้นในบริบทที่ แตกต่าง ซึ่งไม่เคยเห็นการวิเคราะห์เลย การแยกส่วนนี้คือขอบเขต clean-room นี่คือแนวปฏิบัติทางวิศวกรรม ไม่ใช่คำแนะนำทางกฎหมาย

ขั้นตอนที่ 9: กู้คืนสัญญา API และทดสอบด้วย Apidog CLI

สตริงในขั้นตอนที่ 4 มักเปิดเผย base URL และเฮดเดอร์ยืนยันตัวตน ดังนั้นส่วนหนึ่งของพฤติกรรมจึงอยู่หลัง API การสร้างใหม่ของคุณจะตรงกันก็ต่อเมื่อมันทำตามสัญญานั้นด้วย และทราฟฟิกเปิดเผยสิ่งนี้ได้เร็วกว่าแอสเซมบลี

บันทึก HAR บนบัญชีทดสอบที่คุณเป็นเจ้าของ แล้วให้ REA สรุปมัน:

rea inspect-web-network-capture /absolute/session.har har --json

จากนั้นให้เอเจนต์ของคุณเปลี่ยนการบันทึกนั้นให้เป็นสัญญาที่ผ่านการทดสอบด้วย Apidog CLI ตั้งค่าครั้งเดียว:

npm install -g apidog-cli@latest
apidog auth login --with-token <YOUR_TOKEN>
apidog skill install

ให้พรอมต์เดียวกับเอเจนต์:

Import session.har into Apidog project <id>. List the endpoints it created,
remove anything that isn't part of [FEATURE], and write one test case per
endpoint that asserts status code, required fields and response schema.
Run them against the original-service environment, then against my rebuild's
environment, and report every endpoint where the two disagree.

เอเจนต์จะรันการอิมพอร์ต ตรวจสอบรูปร่างของเพย์โหลดก่อนเขียน และรันทั้งสองสภาพแวดล้อม:

apidog import --project <id> --format har --file ./session.har
apidog endpoint list --project <id>
apidog cli-schema get test-case-create
apidog cli-schema validate test-case-create --file case.json
apidog test-case create --project <id> --file case.json
apidog test-case run --project <id> --endpoint <endpointId> -e <originalEnvId> -r cli,json
apidog test-case run --project <id> --endpoint <endpointId> -e <rebuildEnvId> -r cli,json

เคสเดียวกัน สองสภาพแวดล้อม หนึ่ง diff รันซ้ำได้ทุกคอมมิตด้วย -r junit (ดูคู่มือ Apidog CLI CI/CD ของเรา) หากคุณอยากขับเคลื่อนมันจาก Claude Code แทน ดูApidog CLI ใน Claude Code แผนฟรีของ Apidog ครอบคลุมผู้ใช้สูงสุด 4 คน สำหรับวิธีทำด้วยมือ ดูการรีเวิร์สเอนจิเนียร์ API

ขั้นตอนที่ 10: พิสูจน์ความเทียบเท่าก่อนปล่อย

"ฉันคิดว่ามันตรงกัน" ไม่ใช่หลักฐาน สำหรับพฤติกรรมภายในเครื่อง ให้ขอให้ Opus สร้างฮาร์เนสที่ป้อนอินพุตเดียวกันให้ทั้งต้นฉบับและการสร้างใหม่:

Generate 50 inputs: 30 normal, 10 edge (empty, max size, unicode), 10 error
(malformed, missing fields, corrupt). Run each through both programs. Compare
byte-for-byte where possible, semantically otherwise. Report the match rate and
every divergence as cosmetic, behavioral or critical.

ด้วยการรัน API ในขั้นตอนที่ 9 คุณจะได้ตัวเลขสองตัวให้แสดงกับใครก็ได้: อัตราความตรงกันภายในเครื่อง และอัตราความตรงกันของ API ทดสอบไปพร้อมกับที่สร้าง ไม่ใช่ทดสอบตอนท้าย

คำถามที่พบบ่อย

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

ควรใช้ระดับ effort ใดสำหรับการรีเวิร์สเอนจิเนียร์? เริ่มที่ medium สำหรับการกำหนดเส้นทางและการสำรวจ high สำหรับการใส่คำอธิบายให้ฟังก์ชัน และสงวน max ไว้สำหรับโค้ดที่ถูกทำให้สับสนพร้อมงบประมาณต่อฟังก์ชัน Opus 5.5 ใช้ค่าเริ่มต้นที่ medium

Claude จัดการไบนารีที่ถูกทำให้สับสนได้ดีแค่ไหน? benchmark สาธารณะเพียงหนึ่งเดียว จาก Elastic Security Labs ทดสอบ Opus 4.6: แก้เป้าหมาย Tigress ได้ 40% จาก 20 รายการ และ 0% ของเป้าหมายแบบหลายชั้นที่หนักหนา ยังไม่มีการเผยแพร่การทดสอบเทียบเท่าสำหรับ Opus 5.5

จะทดสอบ API ที่แอปที่ผ่านการรีเวิร์สเอนจิเนียร์ใช้ได้อย่างไร? บันทึก HAR บนบัญชีทดสอบ อิมพอร์ตด้วย apidog import --format har สร้างเคสทดสอบด้วย Apidog CLI และรันกับทั้งบริการต้นฉบับและการสร้างใหม่ของคุณ

REA อัปโหลดไบนารีของฉันหรือไม่? REA รันการวิเคราะห์ในเครื่อง เฉพาะผลการค้นพบที่เอเจนต์ของคุณส่งให้โมเดล (สตริง, pseudocode) เท่านั้นที่ไปถึงผู้ให้บริการโมเดลของคุณ