วิธี Reverse Engineer ทุกอย่างด้วย Opus 5.5 (คอร์สเต็ม)

คนส่วนใหญ่ที่พยายามทำ reverse-engineer ไฟล์ binary จะเปิดมันใน hex editor เลื่อนดูอยู่ยี่สิบนาที แล้วก็เลิก

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

คอร์ส 11 ขั้นตอนนี้จะเปลี่ยน Claude Opus 5.5 ให้กลายเป็นเครื่องจักรโอเพนซอร์สที่ทำได้ทุกอย่าง

ติดตาม Substack ของผมเพื่อรับข้อมูล AI alpha ใหม่ล่าสุด:

movez.substack.com

Reverse engineering ไม่ใช่เรื่องการแคร็ก แต่คือการทำความเข้าใจสิ่งใดสิ่งหนึ่งให้ดีพอจนคุณสร้างมันขึ้นมาเองได้

เมื่อวันที่ 7 ตุลาคม 2026 Amjad Masad ซีอีโอของ Replit ได้โพสต์ข้อความสั้นๆ เพียงบรรทัดเดียว:

https://x.com/amasad/status/2107671204639465961

ใต้โพสต์นั้น นักพัฒนาที่ชื่อ @morluto ได้ตอบกลับพร้อมหลักฐานยืนยัน: ชุดเครื่องมือที่เปิดทางให้ agent สั่งงาน Hopper และ Ghidra ได้ และไปได้ไกลมาก

โปรเจกต์นั้นมีชื่อว่า REA ซึ่งพุ่งทะยานไปถึง 110,000 GitHub stars ภายในไม่กี่วัน

https://github.com/morluto/rea

นี่ไม่ใช่การโม้เกินจริง เพราะในสัปดาห์เดียวกัน โปรเจกต์โอเพนซอร์สชื่อ WordCraft ก็ได้ปล่อย clean-room rebuild ของ Microsoft & Adobe ที่เขียนด้วย Rust ล้วนๆ ออกมา:

https://getartcraft.com/apps

มันถูกสร้างขึ้นจากการสังเกตพฤติกรรมของ Word & Adobe และอ่าน spec ของรูปแบบไฟล์ที่เป็นสาธารณะ โดยไม่เคยแตะต้องโค้ดต้นฉบับเลยแม้แต่นิดเดียว

คอร์สนี้จะพาคุณไปดูเส้นทางทั้งหมด ตั้งแต่ไฟล์ binary ปิดตาย ไปจนถึงการสร้างใหม่แบบนั้น โดยมี Opus 5.5 เป็นคนอ่านให้

01. เครื่องยนต์ - วิธีที่ agent อ่านไฟล์ binary

Opus 5.5 ไม่สามารถรัน disassembler ด้วยตัวเองได้ มันอ่านได้แค่ text และเขียน text

การทำ reverse engineering ด้วย agent นั้นเวิร์กเพราะมีเครื่องมือคั่นกลางระหว่าง model กับ binary อยู่: มันโหลดไฟล์เข้าสู่ disassembly engine จริงๆ แปลงผลลัพธ์ออกมาเป็น function ที่เรียกใช้ได้ และปล่อยให้ model ตั้งคำถาม

เครื่องมือนั้นคือ REA ส่วนเครื่องยนต์ข้างใต้คือ Hopper, Ghidra หรือ IDA

วงจรการทำงานนั้นเรียบง่ายและวนซ้ำไปเรื่อยๆ: model สั่งให้ REA ตรวจสอบเป้าหมาย REA ส่งคืนผลลัพธ์พร้อมหลักฐานอ้างอิงที่ชัดเจน (address, byte, pseudocode, call site) แล้ว model ก็ใช้ข้อมูลเหล่านั้นเพื่อตั้งคำถามถัดไป หรือเขียนและทดสอบ reimplementation

ทุกอย่างรันบนเครื่องของคุณแบบ local ไม่มีอะไรถูกอัปโหลดขึ้นไปเลยนอกจากข้อมูลที่ model ต้องใช้ในการคิดวิเคราะห์ และข้อสรุปทุกข้อจะถูกแท็กไว้ว่าเป็น observation (สิ่งที่สังเกตเห็น), inference (สิ่งที่อนุมานได้) หรือ unknown (สิ่งที่ไม่ทราบ)

**

02. การติดตั้ง - rea-agents บวกกับ disassembler หนึ่งตัว

ขั้นตอนการตั้งค่าจะลงทะเบียน MCP server ของ REA เข้ากับ agent ของคุณ และติดตั้ง workflow instructions ที่เข้าคู่กัน

คำสั่งเดียวจบ มันจะแสดงการเปลี่ยนแปลงทั้งหมดให้คุณดูก่อนที่จะเขียนอะไรลงไปจริงๆ และสำรองข้อมูลส่วนที่มันเข้าไปยุ่งไว้ให้

คุณต้องเตรียม disassembler มาเอง: Hopper บน macOS คือทางเลือกที่ง่ายที่สุด, Ghidra ฟรีและรองรับหลายแพลตฟอร์ม, ส่วน IDA ก็ใช้ได้เลยถ้าคุณมีอยู่แล้ว

1# 1. ลงทะเบียน REA กับ agent ของคุณ (Claude Code, Codex, Cursor, Gemini CLI...)
2npx rea-agents setup            # แสดงการเปลี่ยนแปลงที่วางแผนไว้ และถามก่อนเขียน
3
4# 2. ตัวให้บริการ deep-analysis Hopper ใช้งานลื่นไหลที่สุดบน macOS;
5#    ระบบ setup สามารถติดตั้งให้ได้หลังได้รับอนุมัติ ส่วน Ghidra และ IDA คุณต้องเตรียมมาเอง
6# 3. ติดตั้ง rea CLI เพื่อใช้ใน terminal และเขียน script
7npm install --global rea-agents
8rea --help
9
10# 4. รีสตาร์ท agent ของคุณ แล้วยืนยันว่าเครื่องมือพร้อมใช้งานแล้ว
11claude
12> /mcp
13  rea: connected
14    open_binary, binary_overview, analyze_function, decompile,
15    list_procedures, search, xrefs, trace, inspect_artifact,
16    analyze_javascript_application, inspect_managed_artifact ...

ความต้องการระบบไม่ได้สูงอะไรมาก: Node.js 22 ขึ้นไป และ npm การวิเคราะห์แบบ native ต้องการหนึ่งในสามเครื่องยนต์ที่ว่ามา ส่วนการตรวจสอบ static JavaScript และ .NET ไม่ต้องใช้เครื่องยนต์ใดๆ เลย อย่าลืมอัปเดต REA ให้เป็นเวอร์ชันล่าสุดเสมอ เพราะแต่ละ release มักจะมี patch แก้ไขออกมาบ่อย

1# กฎเหล็กในการทำ reverse-engineering ( CLAUDE.MD )
2
3## อำนาจในการดำเนินการ
4- วิเคราะห์เฉพาะเป้าหมายที่ผมเป็นเจ้าของหรือได้รับอนุญาตให้ตรวจสอบเท่านั้น ระบุเหตุผลประกอบครั้งเดียว
5- ข้อกล่าวอ้างทุกครั้งต้องมีแท็กกำกับ: observation (เห็นมาแล้ว), inference (อนุมานเอา) หรือ unknown (ไม่รู้)
6- อ้างอิงหลักฐานเสมอ: address, byte, pseudocode หรือ call site ห้ามกล่าวอ้างลอยๆ โดยไม่มีแหล่งอ้างอิง
7
8## ขั้นตอนการทำงาน
9- เริ่มจากภาพรวมเล็กๆ ก่อน อย่าเพิ่ง dump ทั้งหมด ขยายผลเฉพาะเมื่อเจอช่องว่างที่ชัดเจนเท่านั้น
10- ใช้ session ที่เปิดค้างอยู่ต่อไป ห้ามรันการวิเคราะห์เดิมซ้ำอีก
11- แยกข้อเท็จจริงแบบ static ออกจากข้อเท็จจริงตอน runtime ห้ามทึกทักเอาเองว่าการอ่านแบบ static คือการ execute โปรแกรม
12
13## การสร้างใหม่
14- สร้างจาก "พฤติกรรม" และ spec สาธารณะเท่านั้น ห้ามใช้โค้ดหรือ asset ที่คัดลอกมาเด็ดขาด
15- ทำบัญชีรายการภาระผูกพันไว้: ทุกพฤติกรรมที่กู้คืนมาได้จะต้องมี test ผ่านก่อนถึงจะนับว่า "เสร็จ"

Opus 5.5 มีระดับ effort มาให้ 5 ระดับ: low, medium, high, xhigh และ max ให้เลือกใช้ตามนี้:

• Medium สำหรับตรวจสอบและสำรวจโครงสร้าง
• High สำหรับใส่คำอธิบายประกอบ function ทั่วไป
• Max สำหรับโค้ดที่ถูก obfuscate และอะไรก็ตามที่มีการคำนวณ pointer หนักๆ

Effort คือปุ่มปรับคุณภาพที่สำคัญที่สุดในคอร์สนี้เลยก็ว่าได้

03. ตัวนำทาง - เป้าหมาย 20 ประเภท ใช้เครื่องมืออย่างละตัว

ความผิดพลาดแรกที่มือใหม่มักทำคือคว้า disassembler มาใช้ ทั้งๆ ที่เป้าหมายเป็นแอป Electron ที่มี JavaScript วางอยู่ตรงหน้าโต้งๆ

REA จะส่งต่อเป้าหมายไปยังเครื่องมือที่เหมาะสม และ prompt แรกของคุณก็ควรทำแบบเดียวกัน บอกชื่อไฟล์ บอกฟีเจอร์ที่ต้องการ แล้วปล่อยให้ agent เลือกเครื่องมือเริ่มต้นเอง

1ฉันอยากเข้าใจว่า [FEATURE] ทำงานอย่างไรใน [APP] ซึ่งอยู่ที่ [ABSOLUTE PATH]
2
3ขั้นแรก บอกฉันก่อนว่าเป้าหมายนี้เป็นประเภทไหน (native, Electron/JS, .NET, Go, APK, WASM)
4แล้วเลือกเครื่องมือ REA ที่เหมาะสมมาเปิดมัน ยังไม่ต้องเริ่มวิเคราะห์เชิงลึก
5
6จากนั้นทำแผนที่สรุปมาให้ฉันหนึ่งย่อหน้า: แอปนี้สร้างด้วยอะไร ขนาดใหญ่แค่ไหน และ
7คุณจะเริ่มมองหา [FEATURE] ตรงไหนก่อน แยก observation, inference และ unknown ออกจากกันให้ชัดเจน
8และอ้างอิงหลักฐานสำหรับทุกสิ่งที่คุณกล่าวอ้าง

การชี้ REA ไปที่แอป Electron จะส่งคืน module, import และขอบเขต IPC กลับมาภายในไม่กี่วินาทีโดยไม่ต้องพึ่ง disassembler เลย

แต่ถ้าชี้ไปที่ไฟล์ Mach-O หรือ ELF แบบ native มันจะเปิดฐานข้อมูล Hopper และพาคุณเข้าสู่เส้นทาง native ที่ยากกว่าแต่ลงลึกได้มากกว่า การรู้ว่าคุณกำลังอยู่กับแบบไหนจะช่วยประหยัดเวลาไปได้หลายชั่วโมง

https://x.com/_vmlops/status/2106690704244420687

04. การลาดตระเวน - ภาพรวม, string และ call graph

อย่าเพิ่งเปิดดูโค้ดใดๆ ขั้นแรกให้สั่ง REA ทำแผนที่ของทั้งไฟล์มาก่อน คำสั่งเดียวจะบอกคุณว่ามันรันบนเครื่องประเภทไหน มี function อยู่ข้างในกี่ตัว และมี text ที่อ่านออกซ่อนอยู่ตรงไหนบ้าง

Text เหล่านั้นคือเบาะแสที่เร็วที่สุดที่คุณมี: ที่อยู่เว็บ, ข้อความ error และชื่อฟีเจอร์ จะบอกคุณว่าแอปนี้ทำอะไรได้บ้างก่อนที่คุณจะได้อ่านโค้ดแม้แต่บรรทัดเดียว

1rea.open_binary        { path: "/Applications/Target.app/Contents/MacOS/Target" }
2rea.binary_overview    {}
3  arch:        arm64
4  functions:   1,284 identified
5  segments:    __TEXT __DATA __LINKEDIT
6  entry:       _main @ 0x1000051c0
7
8rea.search             { query: "http" }  # strings + code refs
9  0x10004a2c0  "https://api.target.app/v3/sync"
10  0x10004a300  "Authorization: Bearer "
11  0x10004a330  "offline cache miss, falling back"
12
13rea.xrefs              { address: "0x100012ab0" }  # ใครเรียกใช้ตัวนี้?
14  147 references  ->  core config loader, called everywhere

REA ยังนับให้ด้วยว่าแต่ละ function ถูกเรียกใช้กี่ครั้ง (ตัวเลขนี้เรียกว่า cross-references หรือ xrefs)

Function ที่ถูกเรียก 147 ครั้งคือหัวใจของแอป และสมควรได้รับความพยายามสูงสุดจากคุณ ส่วนตัวที่ถูกเรียกแค่สองครั้งก็เป็นแค่ helper เล็กๆ ที่ข้ามไปได้จนกว่ามันจะจำเป็นจริงๆ ให้เริ่มจากรายการบนสุดของลิสต์นั้นแล้วไล่ลงมา

05. Decompile - เปลี่ยนหนึ่ง function ให้เป็น pseudocode

ทีนี้ให้เลือก function ที่ยุ่งเหยิงเหล่านั้นมาสักตัว แล้วแปลงมันเป็นอะไรที่คุณอ่านรู้เรื่อง Decompiler จะรับคำสั่ง machine ดิบๆ มาเขียนใหม่ให้เป็นโค้ดที่ใกล้เคียงภาษา C

มันอาจจะดูขรุขระ: ชื่อตัวแปรอย่าง var_28, logic พันกันยุ่งเหยิง, มี cast เต็มไปหมด แต่คุณก็ยังอ่านมันออก และการอ่านออกคือสิ่งเดียวที่ Opus 5.5 ต้องการ

รันผ่าน command line เพื่อบันทึกผลลัพธ์ หรือจะสั่งผ่านแชทก็ได้

1# Decompile หนึ่ง function ตาม address ออกมาเป็น JSON เพื่อ pipe หรือบันทึก
2rea decompile /Applications/Target.app/.../Target 0x100012ab0 \
3  --provider hopper --json > fn_config_loader.json
4
5# หรือค้นหา function ตามชื่อแล้วตามดู reference
6rea function /path/to/Target parseConfig --provider hopper --json
7rea xrefs    /path/to/Target 0x100012ab0 --provider hopper --json
8rea trace    /path/to/Target "sync" --provider hopper --json

1// 0x100012ab0  xrefs: 147
2void sub_100012ab0(void* arg0) {
3    void* var_20 = objc_msgSend(cls_NSJSONSerialization,
4        sel_JSONObjectWithData_options_error, arg0, 0x0, 0x0);
5    if (var_20 != 0x0) {
6        void* var_28 = objc_msgSend(var_20, sel_objectForKey, @"endpoints");
7        void* var_30 = objc_msgSend(var_20, sel_objectForKey, @"auth_mode");
8        void* var_38 = objc_msgSend(var_20, sel_objectForKey, @"retry_count");
9        objc_msgSend(g_sharedConfig, sel_setEndpoints, var_28);
10        objc_msgSend(g_sharedConfig, sel_setAuthMode, var_30);
11        objc_msgSend(g_sharedConfig, sel_setRetryCount,
12            objc_msgSend(var_38, sel_intValue));
13    }
14}

โชว์เคสของ REA เองก็ไล่ตามเสียงในเกมเก่าอย่าง DX-Ball ลงไปจนถึง helper ที่คอยตัดสินใจบาลานซ์เสียงซ้าย-ขวา แล้วเปลี่ยน pseudocode ครึ่งๆ กลางๆ นั้นให้กลายเป็นภาษา C

ผลลัพธ์ที่ได้ผ่านการทดสอบ original test cases ทั้ง 3,205 เคส และทำซ้ำได้ทุก byte จาก 63 compiled bytes

ดูขั้นตอนทั้งหมดได้ที่ rea.tools/showcase

06. ใส่คำอธิบายประกอบ - ให้ Opus ตั้งชื่อทุกตัวแปร

โค้ดขรุขระนั่นเป็นแค่ครึ่งหนึ่งของงาน ทีนี้โยนมันให้ Opus 5.5 แล้วสั่งให้อธิบายและจัดระเบียบให้หน่อย

มันจะเปลี่ยนชื่อตัวแปรปริศนาให้เป็นชื่อที่มีความหมายจริง สรุปให้ในประโยคเดียวว่า function นี้มีไว้ทำไม มองเห็น pattern ที่มันใช้อยู่ และแม้แต่ชี้จุดบักที่แอปต้นฉบับทิ้งเอาไว้ให้ด้วย

วาง prompt นี้ลงใน Claude:

1นี่คือ pseudocode ที่ decompile มาจาก function ซึ่งมี 147 cross-references
2
3สำหรับ function นี้:
41. เปลี่ยนชื่อทุกตัวแปรให้เป็นชื่อที่มีความหมาย โดยดูจากวิธีที่มันถูกใช้งาน
52. ระบุวัตถุประสงค์ของมันในหนึ่งประโยค
63. ลิสต์ data structure ที่มันอ่านและเขียน
74. ระบุชื่อ pattern (singleton, factory, state machine, observer...)
85. เขียนใหม่ให้เป็น Swift (หรือภาษาที่ calling convention บ่งบอก) ที่สะอาดและเป็นธรรมชาติ พร้อม doc comment
96. ชี้จุดที่ขาด error handling, input validation หรือ security check
10
11คิดให้รอบคอบในระดับ xhigh ก่อนตอบ: วิเคราะห์ให้ชัดว่าค่าแต่ละตัวคืออะไรก่อนจะตัดสินใจตั้งชื่อ
12ทำเครื่องหมายไว้ตรงไหนก็ตามที่คุณยังไม่แน่ใจ
13
14[วาง pseudocode]

Decompilation บอกคุณว่าโค้ดทำ อะไร ส่วน Opus 5.5 จะบอกคุณว่า ทำไม พร้อมชื่อตัวแปรที่คุณต้องใช้สร้างมันขึ้นมาใหม่

https://x.com/0x0SojalSec/status/2108389060192706674

https://x.com/0x0SojalSec/status/2108031166502896035

ไม่ใช่ทุกเป้าหมายที่ต้องใช้ disassembler โชว์เคส Notion ของ REA ค้นหาฟีเจอร์ clipboard ใน JavaScript ของแอป ไล่ตามมันผ่านเลเยอร์ Electron เข้าไปใน main process และแสดงให้เห็นชัดๆ ว่ามันสร้าง rich clipboard ขึ้นมาอย่างไร เป็นการ trace แบบครบถ้วนโดยไม่ต้องแตะ assembly เลยสักนิด ดูเพิ่มเติมที่

07. Obfuscation - บททดสอบ Tigress benchmark

บางแอปถูกสร้างมาเพื่อต้านทานสิ่งที่คุณกำลังทำโดยเฉพาะ โค้ดของมันถูกปั่นให้ยุ่งเหยิงอย่างตั้งใจ: logic ถูกสลับที่, text ถูกเข้ารหัส, และมีการเพิ่ม branch ปลอมๆ เข้ามาเพื่อถ่วงเวลาคุณ

สิ่งนี้เรียกว่า obfuscation และเป็นจุดเดียวที่แม้แต่ model เก่งๆ ก็ยังเหนื่อย Elastic Security Labs เคยวัดผลเรื่องนี้โดยให้ Claude Opus ทดสอบกับตัวปั่นรหัส Tigress ใน 20 งาน จำตัวเลขเหล่านี้ไว้ให้ดี

มีบทเรียนเชิงปฏิบัติ 2 ข้อซ่อนอยู่ในตัวเลขเหล่านั้น

• ข้อแรก ความพยายามที่ล้มเหลวจะเสียค่าใช้จ่ายประมาณสองเท่าของครั้งที่สำเร็จ เพราะ model จะพยายามหนักขึ้นเรื่อยๆ ก่อนจะยอมแพ้ ดังนั้นให้ตั้งวงเงินจำกัดต่อ function ไว้ และหยุดตั้งแต่เนิ่นๆ
• ข้อสอง ให้ลอกขยะออกจากโค้ดที่ decompile แล้วก่อนส่งไป (เครื่องมือฟรีชื่อ Caveman ช่วยกำจัดออกไปได้ราวๆ 75%) เพื่อให้ model โฟกัสความสนใจไปที่ logic จริงๆ ไม่ใช่พวกตัวเติมเต็ม

กลลวง 5 แบบที่คุณจะได้เจอจริงๆ และหน้าตาของแต่ละแบบเมื่อคุณเปิดโค้ดดู:

1function นี้ดูเหมือนถูก obfuscate มา ให้ทำงานในระดับ max effort
2
31. ระบุว่าใช้เทคนิคอะไรบ้าง (control-flow flattening, opaque predicates,
4   dead code, string encryption, function splitting) และชี้ให้เห็นว่าแต่ละอย่างโผล่มาตรงไหนในโค้ดชุดนี้
52. แก้ไขมัน: ลบ dead branch, ประเมิน opaque predicates, คลี่ dispatch ที่ถูก flatten, ถอดรหัส inline string ถ้าหากหา key เจอ
63. แสดง function ที่ทำความสะอาดแล้วที่เหลืออยู่
74. ให้คะแนนความมั่นใจของคุณ 1-10 ถ้าต่ำกว่า 6 บอกฉันให้ชัดว่าส่วนไหนที่ยังไม่แน่ใจ
8   และ context ข้างเคียงแบบไหนที่จะช่วยคลี่คลายมันได้ อย่าเดาเงียบๆ คนเดียว
9
10[วาง pseudocode ที่ถูก obfuscate]

08. ฝูง swarm - controller ที่คอยสั่งงาน worker

แชทเดียวไม่สามารถอ่าน 500 function ได้ดีหรอก มันจะลืมสิ่งที่เคยเห็น เรียกสิ่งเดียวกันด้วยสามชื่อที่แตกต่างกัน และเริ่มพูดขัดแย้งกับตัวเอง

ทางแก้คือการใช้ทีมเล็กๆ: แชท controller หนึ่งตัวคอยแจกจ่ายงาน และแชท worker หลายตัวที่แต่ละตัวรับผิดชอบ function เดียว

Controller จะกุมภาพรวมใหญ่ไว้และนำชิ้นส่วนต่างๆ มาปะติดปะต่อกัน

คุณไม่ต้องสร้างอะไรพิเศษสำหรับเรื่องนี้เลย prompt สองตัวด้านล่างนี้คือ setting ทั้งหมดแล้ว

1คุณคือ reverse-engineering controller แผนที่ function อยู่ใน functions.json
2(address, name, size, xref_count)
3
41. จัดกลุ่ม function ตามความใกล้ชิดใน call-graph เรียงลำดับกลุ่มตาม xref count
52. ส่งแต่ละกลุ่มไปให้ worker ห้ามวิเคราะห์ function ด้วยตัวเองเด็ดขาด
63. แทรก struct ที่ resolve แล้วเข้าไปใน brief ของ worker แต่ละตัว เพื่อให้ชื่อสอดคล้องกัน
74. เมื่อ worker ส่งคืนความมั่นใจกลับมาต่ำกว่า 6 ให้เข้าคิวรอบที่สองพร้อม context
8   จากเพื่อนบ้านที่ resolve แล้ว
95. ติดตาม token ที่ใช้สะสมไปเรื่อยๆ และรายงานหลังจบแต่ละกลุ่ม

1คุณคือ worker คุณจะได้รับ function ที่ decompile แล้วหนึ่งตัว และ struct ที่ resolve ไปแล้ว
2ส่งคืนข้อมูลดังนี้เท่านั้น: address, purpose, confidence (1-10), structs_used, structs_new,
3clean_source, flags ให้ใช้ชื่อ struct ที่มีอยู่แล้วซ้ำ ห้ามตั้งชื่อที่สองให้กับ
4struct ที่ controller ให้คุณมาเด็ดขาด ทำทีละ function เท่านั้น หยุดเมื่อทำเสร็จ

https://x.com/victor_explore/status/2109466356454510612

09. Clean room - กฎ 4 ข้อที่ทำให้คุณปลอดภัยทางกฎหมาย

Clean-room rebuild หมายถึงการที่คุณก็อปปี้อะไรที่แอปทำ ไม่ใช่โค้ดที่อยู่ข้างใน ถ้าทำถูก สิ่งที่คุณปล่อยออกไปจะเป็นของคุณ 100% แต่ถ้าทำผิด คุณกำลังแบกรับลิขสิทธิ์ของคนอื่นอยู่

กฎ 4 ข้อนี้จะช่วยให้คุณอยู่ในโซนปลอดภัย และทีม WordCraft ก็เช็กทั้ง 4 ข้อนี้โดยอัตโนมัติในทุก build

1. สังเกต แต่ห้ามก็อปปี รันเป้าหมายแบบ black-box ดูว่ามันทำอะไร แคปหน้าจอเฉพาะหน้าต่างของมันเท่านั้น ห้ามอ่าน, disassemble หรือแปะโค้ดของมัน ห้ามก็อปปีข้อความเกินกว่าชื่อฟีเจอร์พื้นฐาน
2. ใช้ spec ไม่ใช่ source code รูปแบบไฟล์ต้องมาจากมาตรฐานสาธารณะ (OOXML คือ ECMA-376 / ISO 29500 บวกกับ spec RTF และ ODF ที่เผยแพร่แล้ว) ห้ามมาจากการแกะ parser ของคู่แข่งหรือโค้ด GPL/LGPL ใดๆ
3. ใช้ asset ต้นฉบับของตัวเองเท่านั้น ไอคอน, ฟอนต์, เทมเพลต และเสียงทุกอย่าง ต้องวาดด้วยโค้ด, เป็น public-domain หรือมีไลเซนส์แบบเปิด พร้อมระบุแถวไว้ในไฟล์ attribution ไม่งั้น CI check จะทำให้ build พัง
4. แยกสองงานนี้ออกจากกัน Agent ตัวหนึ่งกู้คืนพฤติกรรมและเขียน spec อีก context หนึ่งที่ต่างออกไปจะ implement จาก spec นั้นเพียงอย่างเดียว โดยไม่หันกลับไปมองการวิเคราะห์ต้นฉบับเลย การแบ่งแยกนี้แหละคือเส้นแบ่งของ clean-room

1จากการวิเคราะห์ที่เสร็จสมบูรณ์ ให้เขียน clean-room specification สำหรับการ implement ใหม่
2
3อธิบายเฉพาะ "พฤติกรรม" เท่านั้น ประกอบด้วย: public interface ทุกตัว, data model,
4ฟีเจอร์ที่ผู้ใช้มองเห็นแต่ละอย่างในรูปแบบ requirement ที่ทดสอบได้, รูปแบบไฟล์ที่อ่านและเขียน
5(จากพฤติกรรมที่สังเกตและ spec สาธารณะ) และพฤติกรรมการจัดการ error
6
7ห้ามรวม: address หรือ offset, ชื่อตัวแปรจาก decompile, assembly,
8หรืออะไรก็ตามที่คัดลอกจากต้นฉบับ นักพัฒนาที่ไม่เคยเห็น binary นี้เลยต้อง
9สามารถ implement เวอร์ชันที่ใช้งานร่วมกันได้จากเอกสารนี้เพียงอย่างเดียว
10
11ส่งออกเป็น markdown แบ่งหัวข้อ: Architecture, Data Model, Public API, File Formats,
12Test Cases

การทำงานจากคำอธิบายไม่ใช่แค่เกราะป้องกันทางกฎหมาย แต่มันยังช่วยให้คุณตัดสินใจเลือกสิ่งที่เหมาะกับภาษาและความต้องการของคุณเองได้ แทนที่จะต้องรับมรดกการตัดสินใจที่ผู้เขียนต้นฉบับทำไว้เมื่อหลายสิบปีก่อน

WordCraft เร็วกว่า Word ในบางจุด ก็เพราะมันไม่ได้ก็อปปีไส้ในของ Word มานั่นเอง

10. Crafting Apps - เครื่องมือระดับโปร 12 ตัว วิธีเดียว

WordCraft ไม่ใช่โปรเจกต์ที่ทำครั้งเดียวจบ มันเป็นแค่แอปหนึ่งใน 12 ตัวบนชั้นวางของทีม ArtCraft ซึ่งแต่ละตัวคือ clean-room rebuild ของเครื่องมือที่คุณจ่ายเงินซื้ออยู่แล้ว ทั้งหมดเขียนขึ้นใหม่ตั้งแต่ศูนย์ด้วย Rust และปล่อยฟรีแบบโอเพนซอร์สบน GitHub

สโลแกนของพวกเขาคือ "Twelve apps. One craft" และ the one craft นั้นก็คือวิธีการจากขั้นตอนที่ 9: ดูต้นฉบับ, อ่าน spec สาธารณะ, แล้วสร้างเวอร์ชันใหม่จากพฤติกรรมเพียงอย่างเดียว

ผลตอบแทนจากวิธีการที่ใช้ร่วมกันนี้เหมือนกันทุกที่ ไม่มี Electron: แต่ละแอปเป็น native บน macOS, Windows และ Linux และยกเว้น FilmCraft แล้ว ตัวอื่นๆ ยังรันในแท็บเบราว์เซอร์ผ่าน WebAssembly ได้อีกด้วย

และเนื่องจากทุก action ข้างในมันคือ named command แอปทั้ง 12 ตัวจึงสั่งงานด้วย AI agent ได้ทันที

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

นี่คือเลเยอร์ของ WordCraft:

และทุก action ก็เป็นแค่ named command ดังนั้นไม่ว่าจะเป็นคนที่คลิก, คีย์ลัด, หรือ AI agent ก็จะทริกเกอร์สิ่งเดียวกันเป๊ะ นั่นแหละคือสิ่งที่ทำให้แอปเหล่านี้สั่งงานด้วย agent ได้

1drive WordCraft over MCP
2
3# Headless document automation
4claude mcp add wordcraft -- wordcraft-cli mcp
5
6# Or drive the running desktop app
7wordcraft --control 7981 &
8claude mcp add wordcraft-app -- wordcraft-cli mcp --connect 127.0.0.1:7981
9
10# Tools: list_commands, execute, batch, type_text, select_text,
11#        inspect_document, render_page, save_document (+ screenshot/click/key live)
12> Open report.docx, make every heading 14pt bold, export to PDF
13  ✓ select.all-headings -> 12 selected
14  ✓ format.font-size 14 · format.bold
15  ✓ export report.pdf (selectable text, bookmarks kept)

https://x.com/yuhasbeentaken/status/2109235513102057828

11. ตรวจสอบและปล่อยของ - พิสูจน์ความเหมือน เปิดใช้งาน MCP

คุณไม่เคยมี source code ต้นฉบับ ดังนั้นคุณเทียบมันบรรทัดต่อบรรทัดไม่ได้

คุณต้องเทียบพฤติกรรมแทน: ป้อน input เดียวกันให้ทั้งต้นฉบับและตัวที่คุณสร้างใหม่ แล้วเช็กว่า output ออกมาเหมือนกันไหม

1สร้าง behavioral test harness เพื่อเปรียบเทียบ binary ต้นฉบับกับตัวที่ผมสร้างใหม่
2
3สร้าง input มา 50 ชุด: 30 แบบปกติ, 10 แบบ edge case (ว่างเปล่า, ขนาดสูงสุด, unicode, อักขระพิเศษ),
410 แบบ error (รูปแบบผิด, ขาด field, ข้อมูลเสียหาย) รันแต่ละชุดผ่านทั้งสองตัว เปรียบเทียบ output
5แบบ byte-for-byte เท่าที่ทำได้ นอกนั้นให้เทียบเชิงความหมาย รายงาน match rate, รายการ
6ความแตกต่าง และความรุนแรงของแต่ละจุด (cosmetic / behavioral / critical) บันทึกไปที่ report.md

นี่คือหลักฐานที่น่าเชื่อถือที่สุดที่คุณจะโชว์ใครก็ได้ (ช่อง RE ที่อยู่บนสุดของบทความ)

จากนั้นปล่อยตัว rebuild ของคุณในแบบเดียวกับที่ REA และ WordCraft ทำ: ในฐานะ MCP server เพื่อให้ agent ของคนถัดไปสั่งงานมันได้เหมือนที่คุณสั่งงาน REA

ตั้งชื่อและคำอธิบายแต่ละ function ให้ชัดเจน ห่อหุ้มมันด้วย command-line tool ง่ายๆ และทำให้ติดตั้งได้ด้วยคำสั่งเดียว

https://x.com/0xMovez/status/2108884063515746410

และให้เทสต์ไปเรื่อยๆ ระหว่างทาง ไม่ใช่รอไปเทสต์ตอนท้าย เพราะความผิดพลาดที่เจอหลังจากคุณสร้างทับมันไปแล้วสามเลเยอร์นั้นแพงกว่าจะแก้เยอะมาก

ความผิดพลาด 6 อย่างที่จะทำให้วันหยุดสุดสัปดาห์ของคุณสูญเปล่า

1. เปิด disassembler กับแอป Electron ถ้า JavaScript มันอยู่ตรงนั้นแล้ว ให้ route ไปที่ analyze_javascript_application และข้ามเส้นทาง native ไปเลย
2. Dump ทุกอย่างออกมาก่อนจะได้อ่านอะไรเลย สั่ง REA ทำ summary มาก่อน การดึงทั้งแอปออกมาทีเดียวจะฝัง logic จริงๆ ไว้ใต้กองขยะ และทำให้บิลคุณบานปลาย
3. อ่าน function ตามลำดับไฟล์ ให้เรียงตามจำนวน cross-reference แทน function ที่มี 147 xrefs คือสถาปัตยกรรมหลัก ส่วน helper ที่มี 2 xrefs รอได้
4. ฝืนปั่น stage-3 obfuscation ผล benchmark แก้ multi-layer ได้ 0% ให้ตั้งงบไว้ เก็บ context จาก function ข้างเคียงไว้ แล้วค่อยกลับมาทีหลัง
5. ปล่อยให้ model ก็อปปีโค้ดเข้ามาในตัว rebuild ของคุณ นั่นทำลายกฎ clean-room ให้ทำ spec ก่อนใน context หนึ่ง แล้ว implement จาก spec นั้นในอีก context หนึ่ง
6. ปล่อยของโดยไม่มี parity report "ฉันคิดว่ามันเหมือนกันนะ" ไม่ใช่หลักฐาน แต่ behavioral test 50 เคสพร้อม match rate ต่างหากที่เป็นหลักฐาน

บทสรุป:

ติดตั้ง REA อ่านไฟล์ binary แล้วสร้างมันขึ้นมาใหม่ในแบบของคุณ

Route เป้าหมาย, ทำแผนที่พื้นผิวของมัน, decompile function หลักๆ, ให้ Opus 5.5 ตั้งชื่อทุกอย่าง, แกะ obfuscation เฉพาะที่คุ้มจะแก้, ขยายสเกลด้วย swarm, จากนั้นเขียน spec ให้สะอาดแล้วปล่อย rebuild ผ่าน MCP

สิบเอ็ดขั้นตอน หนึ่ง model ศูนย์โค้ดก็อปปี