Hầu hết những người thử dịch ngược (reverse-engineer) một file binary đều mở nó bằng hex editor, cuộn chuột suốt hai mươi phút rồi bỏ cuộc.
Họ không biết công cụ nào dùng để nạp file. Họ không biết prompt nào để trích xuất logic. Họ cũng chẳng biết cách biến một "bức tường" mã assembly thành thứ mà họ thực sự có thể xây dựng lại.
Khóa học 11 bước này sẽ biến Claude Opus 5.5 thành một cỗ máy mã nguồn mở vạn năng.
Theo dõi Substack của tôi để cập nhật những insight AI mới nhất:
Dịch ngược không phải là bẻ khóa. Đó là việc hiểu một thứ đủ sâu để tự tay xây dựng lại phiên bản của riêng bạn.
Vào ngày 7 tháng 10 năm 2026, Amjad Masad, CEO của Replit, đã đăng một dòng duy nhất:
https://x.com/amasad/status/2107671204639465961
Bên dưới bài đăng đó, một lập trình viên tên @morluto đã phản hồi kèm theo "minh chứng": một bộ công cụ cho phép các agent điều khiển Hopper và Ghidra để tiến rất xa trong quá trình phân tích.
Dự án đó chính là REA, và nó đã vượt mốc 110.000 sao GitHub chỉ trong vài ngày.
https://github.com/morluto/rea
Đây không phải là lời quảng cáo thổi phồng. Cũng trong tuần đó, một dự án mã nguồn mở mang tên WordCraft đã tung ra bản tái tạo clean-room của Microsoft & Adobe viết hoàn toàn bằng Rust:
Nó được xây dựng bằng cách quan sát hành vi của Word & Adobe và đọc các tài liệu đặc tả định dạng file công khai, chứ tuyệt đối không đụng đến mã nguồn gốc.
Khóa học này sẽ chỉ cho bạn toàn bộ lộ trình từ một file binary đóng kín đến một bản tái tạo như vậy, với Opus 5.5 đảm nhiệm phần đọc hiểu.
01. Engine - cách một agent đọc file binary
Opus 5.5 không thể tự chạy một trình disassembler. Nó chỉ đọc văn bản và ghi văn bản.
Việc dịch ngược bằng agent khả thi là nhờ có một công cụ đứng giữa model và file binary: công cụ này nạp file vào một engine disassembly thực thụ, chuyển kết quả thành các hàm có thể gọi, và cho phép model đặt câu hỏi.
Công cụ đó là REA, còn engine bên dưới là Hopper, Ghidra hoặc IDA.
Vòng lặp rất đơn giản và cứ thế lặp lại: model yêu cầu REA kiểm tra mục tiêu, REA trả về kết quả kèm theo bằng chứng chính xác (địa chỉ, byte, pseudocode, call site), và model dùng những phát hiện đó để đặt câu hỏi tiếp theo hoặc viết và kiểm thử bản triển khai lại.
Mọi thứ đều chạy cục bộ trên máy của bạn. Không có gì bị tải lên ngoài những dữ liệu mà model cần để suy luận, và mọi kết luận đều được gắn nhãn là quan sát (observation), suy luận (inference) hoặc chưa rõ (unknown).
**
02. Cài đặt - rea-agents cộng thêm một disassembler
Quá trình thiết lập sẽ đăng ký MCP server của REA với agent của bạn và cài đặt các hướng dẫn workflow tương ứng.
Chỉ cần một lệnh duy nhất, nó sẽ hiển thị mọi thay đổi trước khi ghi bất cứ thứ gì, đồng thời sao lưu những phần nó can thiệp.
Bạn tự chọn disassembler cho mình: Hopper trên macOS là lựa chọn dễ nhất, Ghidra miễn phí và đa nền tảng, còn IDA thì dùng nếu bạn đã có sẵn.
1# 1. Đăng ký REA với agent của bạn (Claude Code, Codex, Cursor, Gemini CLI...)2npx rea-agents setup # hiển thị các thay đổi dự kiến, hỏi ý kiến trước khi ghi34# 2. Một nhà cung cấp phân tích chuyên sâu. Hopper hoạt động mượt nhất trên macOS;5# quá trình setup có thể cài đặt nó sau khi bạn phê duyệt. Ghidra và IDA thì bạn tự chuẩn bị.6# 3. Cài đặt CLI rea để dùng trong terminal và viết script7npm install --global rea-agents8rea --help910# 4. Khởi động lại agent, sau đó xác nhận các công cụ đã hoạt động11claude12> /mcp13 rea: connected14 open_binary, binary_overview, analyze_function, decompile,15 list_procedures, search, xrefs, trace, inspect_artifact,16 analyze_javascript_application, inspect_managed_artifact ...
Yêu cầu cấu hình khá nhẹ nhàng: Node.js 22 trở lên và npm. Phân tích native cần một trong ba engine; còn kiểm tra tĩnh JavaScript và .NET thì không cần engine nào cả. Hãy luôn cập nhật REA vì các bản phát hành thường xuyên có bản vá lỗi.
1# Nội quy dịch ngược ( CLAUDE.MD )23## Thẩm quyền4- Chỉ phân tích các mục tiêu mà tôi sở hữu hoặc được phép kiểm tra. Nêu rõ cơ sở một lần.5- Mọi nhận định đều phải gắn nhãn: observation (đã thấy), inference (đã suy luận) hoặc unknown.6- Trích dẫn bằng chứng: địa chỉ, byte, pseudocode hoặc call site. Không đưa ra nhận định vô căn cứ.78## Quy trình9- Bắt đầu với tổng quan nhỏ nhất, không dump toàn bộ. Chỉ mở rộng khi có khoảng trống cụ thể.10- Tận dụng phiên đang mở; không bao giờ chạy lại một phân tích giống hệt.11- Tách biệt dữ kiện tĩnh khỏi dữ kiện runtime. Không bao giờ ngụ ý rằng code đang thực thi chỉ từ việc đọc tĩnh.1213## Tái tạo14- Xây dựng dựa trên HÀNH VI và tài liệu đặc tả công khai, không bao giờ dùng code hay tài nguyên sao chép.15- Duy trì sổ theo dõi nghĩa vụ: mọi hành vi khôi phục được đều cần một test case đạt yêu cầu trước khi coi là "hoàn tất".
Opus 5.5 có năm mức effort (mức độ nỗ lực): low, medium, high, xhigh và max. Hãy dùng:
- Medium để kiểm tra và điều hướng
- High để chú thích các hàm thông thường
- Max cho code bị làm rối (obfuscated) và những phần tính toán con trỏ phức tạp.
Effort chính là "núm vặn" chất lượng quan trọng nhất trong toàn bộ khóa học này.
03. Bộ định tuyến - 20 loại mục tiêu, mỗi loại một công cụ
Sai lầm đầu tiên của người mới là lao ngay vào dùng disassembler trong khi mục tiêu lại là một ứng dụng Electron với mã JavaScript nằm sờ sờ ra đó.
REA định tuyến mục tiêu đến đúng công cụ, và prompt đầu tiên của bạn cũng nên như vậy. Hãy nêu tên file, nêu tên tính năng, và để agent tự chọn công cụ khởi đầu.
1Tôi muốn hiểu cách [TÍNH NĂNG] hoạt động trong [ỨNG DỤNG], nằm tại [ĐƯỜNG DẪN TUYỆT ĐỐI].23Trước tiên, hãy cho tôi biết đây là loại mục tiêu gì (native, Electron/JS, .NET, Go, APK, WASM)4và chọn công cụ REA phù hợp để mở nó. Đừng bắt đầu phân tích sâu vội.56Sau đó, hãy cho tôi một đoạn tóm tắt: ứng dụng được xây dựng bằng gì, dung lượng bao nhiêu, và7bạn sẽ tìm [TÍNH NĂNG] ở đâu trước tiên. Tách riêng các quan sát, suy luận và điểm chưa rõ,8đồng thời trích dẫn bằng chứng cho mọi nhận định bạn đưa ra.
Chĩa REA vào một ứng dụng Electron sẽ trả về các module, import và ranh giới IPC chỉ trong vài giây mà không cần đến disassembler.
Chĩa nó vào một file Mach-O hoặc ELF native sẽ mở cơ sở dữ liệu Hopper và đưa bạn vào con đường native khó hơn nhưng sâu hơn. Biết mình đang ở trường hợp nào sẽ giúp bạn tiết kiệm hàng giờ đồng hồ.
https://x.com/_vmlops/status/2106690704244420687
04. Trinh sát - tổng quan, chuỗi ký tự và đồ thị gọi hàm
Đừng mở bất kỳ đoạn code nào vội. Trước tiên, hãy yêu cầu REA vẽ bản đồ toàn bộ file. Một lệnh duy nhất sẽ cho bạn biết nó chạy trên kiến trúc máy nào, có bao nhiêu hàm bên trong, và toàn bộ văn bản có thể đọc được ẩn trong đó.
Phần văn bản này là manh mối nhanh nhất bạn có: địa chỉ web, thông báo lỗi và tên tính năng sẽ cho bạn biết ứng dụng làm gì trước cả khi bạn đọc một dòng code.
1rea.open_binary { path: "/Applications/Target.app/Contents/MacOS/Target" }2rea.binary_overview {}3 arch: arm644 functions: 1,284 identified5 segments: __TEXT __DATA __LINKEDIT6 entry: _main @ 0x1000051c078rea.search { query: "http" } # strings + code refs9 0x10004a2c0 "https://api.target.app/v3/sync"10 0x10004a300 "Authorization: Bearer "11 0x10004a330 "offline cache miss, falling back"1213rea.xrefs { address: "0x100012ab0" } # ai gọi hàm này?14 147 references -> core config loader, called everywhere
REA cũng đếm số lần mỗi hàm được gọi (con số này gọi là cross-references, hay xrefs).
Một hàm được gọi 147 lần chính là trái tim của ứng dụng và xứng đáng để bạn dồn tâm sức. Hàm chỉ được gọi hai lần là một hàm phụ trợ nhỏ mà bạn có thể bỏ qua cho đến khi nó thực sự quan trọng. Hãy bắt đầu từ đầu danh sách đó và đi dần xuống.
05. Decompile - biến một hàm thành pseudocode
Bây giờ hãy chọn một trong những hàm bận rộn đó và biến nó thành thứ bạn có thể đọc được. Trình decompiler sẽ lấy các chỉ thị máy thô và viết lại thành code gần giống C.
Trông nó khá lộn xộn: những cái tên như var_28, logic rối rắm, ép kiểu khắp nơi. Nhưng bạn vẫn đọc được, và chỉ cần đọc được là đủ để Opus 5.5 xử lý.
Bạn có thể chạy từ command line để lưu kết quả, hoặc chạy ngay trong khung chat.
1# Decompile một hàm theo địa chỉ, xuất ra JSON để pipe hoặc lưu2rea decompile /Applications/Target.app/.../Target 0x100012ab0 \3 --provider hopper --json > fn_config_loader.json45# Hoặc tìm kiếm hàm theo tên và theo dõi các tham chiếu6rea function /path/to/Target parseConfig --provider hopper --json7rea xrefs /path/to/Target 0x100012ab0 --provider hopper --json8rea trace /path/to/Target "sync" --provider hopper --json
1// 0x100012ab0 xrefs: 1472void 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}
Showcase của chính REA đã theo dõi một lệnh gọi âm thanh trong tựa game cũ DX-Ball xuống tận hàm phụ trợ quyết định cân bằng âm thanh trái-phải, sau đó biến đoạn pseudocode dang dở kia thành C.
Kết quả vượt qua toàn bộ 3.205 test case gốc và tái tạo chính xác từng byte trong số 63 byte đã biên dịch.
Xem hướng dẫn chi tiết tại rea.tools/showcase.
06. Chú thích - để Opus đặt tên cho mọi biến
Đoạn code thô ráp đó mới chỉ là nửa chặng đường. Giờ hãy giao nó cho Opus 5.5 và yêu cầu giải thích cũng như dọn dẹp lại.
Nó sẽ đổi tên các biến khó hiểu thành tên có ý nghĩa, tóm tắt mục đích của hàm trong một câu, nhận diện pattern đang được sử dụng, và thậm chí chỉ ra cả những bug mà ứng dụng gốc bỏ sót.
Hãy dán prompt này vào Claude:
1Đây là pseudocode đã decompile từ một hàm có 147 cross-reference.23Với hàm này:41. Đổi tên mọi biến thành tên có ý nghĩa dựa trên cách nó được sử dụng.52. Nêu mục đích của hàm trong một câu.63. Liệt kê các cấu trúc dữ liệu mà nó đọc và ghi.74. Gọi tên pattern (singleton, factory, state machine, observer...).85. Viết lại thành Swift sạch sẽ, chuẩn idiomatic (hoặc ngôn ngữ mà calling9 convention ngụ ý), kèm doc comment.106. Đánh dấu mọi phần thiếu xử lý lỗi, kiểm tra đầu vào hoặc kiểm tra bảo mật.1112Hãy suy nghĩ thật kỹ ở mức effort xhigh trước khi trả lời: phân tích xem mỗi13giá trị là gì trước khi chốt tên. Đánh dấu bất cứ điều gì bạn không chắc chắn.1415[dán pseudocode vào đây]
Decompile cho bạn biết code làm gì. Opus 5.5 cho bạn biết tại sao, cùng những cái tên để xây dựng lại nó.
https://x.com/0x0SojalSec/status/2108389060192706674
https://x.com/0x0SojalSec/status/2108031166502896035
Không phải mục tiêu nào cũng cần disassembler. Showcase Notion của REA tìm thấy tính năng clipboard trong mã JavaScript của ứng dụng, theo dõi nó qua các lớp Electron vào main process, và chỉ ra chính xác cách nó xây dựng rich clipboard — một luồng vết hoàn chỉnh mà không cần đến một dòng assembly nào. Xem
07. Obfuscation - benchmark Tigress
Một số ứng dụng được tạo ra để chống lại chính xác những gì bạn đang làm. Code của chúng bị làm rối một cách có chủ đích: logic bị xáo trộn, văn bản bị mã hóa, và các nhánh giả được thêm vào để câu giờ của bạn.
Đây gọi là obfuscation (làm rối code), và là nơi duy nhất mà ngay cả model giỏi nhất cũng chật vật. Elastic Security Labs đã đo lường điều này bằng cách chĩa Claude Opus vào trình làm rối Tigress qua 20 tác vụ. Hãy ghi nhớ những con số này.
Có hai bài học thực tế rút ra từ những con số đó.
- Thứ nhất, một lần thử thất bại tốn gấp đôi một lần thành công, vì model sẽ cố gắng ngày càng mạnh hơn trước khi bỏ cuộc, nên hãy đặt giới hạn chi tiêu cho mỗi hàm và dừng sớm.
- Thứ hai, hãy lọc bỏ rác khỏi code đã decompile trước khi gửi đi (một công cụ miễn phí tên Caveman loại bỏ được khoảng 75% rác) để model dồn sự tập trung vào logic thực sự, chứ không phải phần thừa thãi.
Năm thủ thuật bạn sẽ thực sự gặp phải, và biểu hiện của chúng khi bạn mở code:
1Hàm này trông có vẻ bị obfuscate. Hãy làm việc ở mức effort max.231. Xác định các kỹ thuật đang được sử dụng (control-flow flattening, opaque predicates,4 dead code, string encryption, function splitting) và chỉ ra vị trí của từng kỹ thuật5 trong đoạn code cụ thể này.62. Xử lý chúng: loại bỏ các nhánh chết, đánh giá opaque predicates, gỡ phẳng7 luồng dispatch, giải mã các chuỗi inline nếu có thể khôi phục được key.83. Hiển thị hàm sạch sẽ còn lại.94. Tự đánh giá độ tin cậy từ 1-10. Nếu dưới 6, hãy nói chính xác phần nào chưa chắc chắn10 và ngữ cảnh lân cận nào sẽ giúp giải quyết nó. Đừng tự đoán mò trong im lặng.1112[dán pseudocode đã obfuscate vào đây]
08. Swarm - một controller điều phối các worker
Một khung chat duy nhất không thể đọc tốt 500 hàm. Nó sẽ quên những gì đã thấy, gọi cùng một thứ bằng ba cái tên khác nhau, và bắt đầu tự mâu thuẫn với chính mình.
Giải pháp là một đội ngũ nhỏ: một khung chat controller phân chia công việc, và nhiều khung chat worker, mỗi khung xử lý một hàm.
Controller nắm giữ bức tranh toàn cảnh và ghép các mảnh lại với nhau.
Bạn không cần xây dựng gì đặc biệt cho việc này, hai prompt dưới đây là toàn bộ thiết lập.
1Bạn là một controller dịch ngược. Bản đồ hàm nằm trong functions.json2(address, name, size, xref_count).341. Nhóm các hàm theo độ gần gũi trong đồ thị gọi hàm; sắp xếp các nhóm theo xref count.52. Phân công mỗi nhóm cho một worker. Tuyệt đối không tự phân tích bất kỳ hàm nào.63. Đưa các struct đã được xử lý vào bản tóm tắt của mỗi worker để tên gọi luôn nhất quán.74. Khi một worker trả về độ tin cậy dưới 6, hãy xếp hàng vòng lặp thứ hai kèm ngữ cảnh8 từ các hàm lân cận đã được xử lý.95. Theo dõi tổng token đã tiêu thụ và báo cáo sau mỗi nhóm.
1Bạn là một worker. Bạn nhận được một hàm đã decompile và các struct đã xử lý cho đến nay.2Trả về chính xác: address, purpose, confidence (1-10), structs_used, structs_new,3clean_source, flags. Tái sử dụng tên struct hiện có; đừng bao giờ tự bịa ra tên thứ hai cho4một struct mà controller đã cung cấp. Chỉ xử lý một hàm. Dừng lại khi xong.
https://x.com/victor_explore/status/2109466356454510612
09. Clean room - bốn quy tắc để luôn hợp pháp
Tái tạo clean-room nghĩa là bạn sao chép những gì ứng dụng làm, chứ không bao giờ sao chép code bên trong nó. Làm đúng thì sản phẩm bạn tung ra hoàn toàn thuộc về bạn. Làm sai thì bạn đang mang trên vai bản quyền của người khác.
Bốn quy tắc giúp bạn luôn an toàn, và đội ngũ WordCraft tự động kiểm tra cả bốn quy tắc này trong mỗi lần build.
- Quan sát, không sao chép. Chạy mục tiêu dạng black-box, xem nó làm gì, chỉ chụp ảnh màn hình cửa sổ của chính nó. Không bao giờ đọc, disassemble hay dán code của nó. Không sao chép câu chữ ngoài tên tính năng thông thường.
- Dùng spec, không dùng source. Định dạng file lấy từ các tiêu chuẩn công khai (OOXML là ECMA-376 / ISO 29500, cộng thêm các tài liệu RTF và ODF đã công bố), không bao giờ lấy từ việc đọc parser của đối thủ hay bất kỳ code GPL/LGPL nào.
- Chỉ dùng tài nguyên gốc. Mọi icon, font, template và âm thanh đều được vẽ bằng code, thuộc phạm vi công cộng, hoặc có giấy phép mở, kèm một dòng trong file ghi công. Nếu không, CI check sẽ làm fail bản build.
- Tách biệt hai công việc. Một agent khôi phục hành vi và viết spec. Một context khác triển khai chỉ dựa trên spec, không bao giờ nhìn vào bản phân tích gốc. Sự tách biệt này chính là ranh giới clean-room.
1Từ bản phân tích đã hoàn tất, hãy viết một tài liệu đặc tả clean-room cho việc triển khai lại.23CHỈ mô tả HÀNH VI. Bao gồm: mọi interface công khai, data model, từng4tính năng người dùng nhìn thấy dưới dạng một yêu cầu có thể kiểm thử, các định dạng file đọc và ghi5(dựa trên hành vi quan sát được và tài liệu công khai), cùng hành vi xử lý lỗi.67KHÔNG bao gồm: địa chỉ hoặc offset, tên biến từ bản decompile, assembly,8hay bất cứ thứ gì sao chép từ bản gốc. Một lập trình viên chưa từng thấy file binary phải9có thể triển khai một phiên bản tương thích chỉ dựa vào tài liệu này.1011Xuất ra markdown với các phần: Architecture, Data Model, Public API, File Formats,12Test Cases.
Làm việc từ một bản mô tả không chỉ là lá chắn pháp lý. Nó cho phép bạn đưa ra những lựa chọn đúng đắn cho ngôn ngữ và nhu cầu của riêng mình, thay vì kế thừa các quyết định mà tác giả gốc đã đưa ra từ nhiều thập kỷ trước.
WordCraft nhanh hơn Word ở một số điểm chính xác là vì nó không sao chép ruột gan của Word.
10. Crafting Apps - mười hai công cụ chuyên nghiệp, một phương pháp
WordCraft không phải là ngoại lệ duy nhất. Nó là một trong mười hai ứng dụng trên kệ của đội ngũ ArtCraft, mỗi ứng dụng là một bản tái tạo clean-room của một công cụ mà bạn vẫn đang trả tiền để dùng, tất cả đều được viết từ đầu bằng Rust và phát hành miễn phí, mã nguồn mở trên GitHub.
Câu slogan của họ là "Twelve apps. One craft" (Mười hai ứng dụng. Một nghệ thuật), và "nghệ thuật" đó chính là phương pháp từ bước 9: quan sát bản gốc, đọc tài liệu công khai, xây dựng phiên bản mới chỉ dựa trên hành vi.
Lợi ích của phương pháp chung đó thể hiện đồng nhất ở mọi nơi. Không dùng Electron: mỗi ứng dụng đều native trên macOS, Windows và Linux, và tất cả trừ FilmCraft còn chạy được trên tab trình duyệt thông qua WebAssembly.
Và bởi vì mọi hành động bên trong chúng đều là một lệnh có tên, cả mười hai ứng dụng đều có thể được điều khiển ngay lập tức bởi một AI agent.
Mọi ứng dụng Craft đều được xây dựng theo cùng một cách, và cấu trúc đó rất đáng để học hỏi. Mỗi ứng dụng được xếp thành các lớp, mỗi lớp chỉ sử dụng lớp ngay bên dưới nó, từ các phép đo cơ bản ở dưới cùng đến cửa sổ hiển thị trên màn hình ở trên cùng.
Dưới đây là các lớp của WordCraft:
Và mọi hành động chỉ là một lệnh có tên, nên dù một người click chuột, dùng phím tắt, hay một AI agent ra lệnh thì đều kích hoạt chính xác cùng một thứ. Đó là điều khiến bất kỳ ứng dụng nào trong số chúng cũng có thể được điều khiển bởi agent.
1điều khiển WordCraft qua MCP23# Tự động hóa tài liệu headless4claude mcp add wordcraft -- wordcraft-cli mcp56# Hoặc điều khiển ứng dụng desktop đang chạy7wordcraft --control 7981 &8claude mcp add wordcraft-app -- wordcraft-cli mcp --connect 127.0.0.1:7981910# Công cụ: list_commands, execute, batch, type_text, select_text,11# inspect_document, render_page, save_document (+ screenshot/click/key trực tiếp)12> Mở report.docx, in đậm tất cả tiêu đề cỡ 14pt, xuất ra PDF13 ✓ select.all-headings -> 12 selected14 ✓ format.font-size 14 · format.bold15 ✓ export report.pdf (selectable text, bookmarks kept)
https://x.com/yuhasbeentaken/status/2109235513102057828
11. Kiểm thử và phát hành - chứng minh sự tương đương, phơi bày MCP
Bạn chưa bao giờ có mã nguồn gốc, nên không thể so sánh từng dòng.
Thay vào đó, bạn so sánh hành vi: đưa cùng một đầu vào cho cả bản gốc và bản tái tạo của bạn, rồi kiểm tra xem chúng có cho ra cùng một kết quả không.
1Xây dựng một bộ kiểm thử hành vi để so sánh file binary gốc và bản tái tạo của tôi.23Tạo 50 đầu vào: 30 bình thường, 10 biên (rỗng, kích thước tối đa, unicode, ký tự đặc biệt),410 lỗi (sai định dạng, thiếu trường, hỏng). Chạy từng đầu vào qua cả hai. So sánh đầu ra5từng byte nếu có thể, nếu không thì so sánh theo ngữ nghĩa. Báo cáo tỷ lệ khớp, danh sách6các điểm sai lệch và mức độ nghiêm trọng của từng điểm (thẩm mỹ / hành vi / nghiêm trọng). Lưu vào report.md.
Đây cũng là bằng chứng thuyết phục nhất mà bạn có thể cho bất kỳ ai xem (phần RE ở ngay đầu bài viết).
Sau đó, hãy phát hành bản tái tạo của bạn giống cách REA và WordCraft đã làm: dưới dạng một MCP server, để agent của người tiếp theo có thể điều khiển nó y như cách bạn đã điều khiển REA.
Đặt cho mỗi hàm một cái tên và mô tả rõ ràng, bọc nó trong một công cụ command line đơn giản, và cho phép cài đặt chỉ bằng một dòng lệnh.
https://x.com/0xMovez/status/2108884063515746410
Và hãy kiểm thử trong quá trình làm, chứ đừng đợi đến cuối, vì một lỗi sai được phát hiện sau khi bạn đã xây ba lớp chồng lên nó sẽ tốn kém hơn rất nhiều để sửa.
Sáu sai lầm ngốn trọn cả một ngày cuối tuần
- Mở disassembler cho một ứng dụng Electron. Nếu mã JavaScript nằm ngay đó, hãy định tuyến sang analyze_javascript_application và bỏ qua hoàn toàn con đường native.
- Dump mọi thứ trước khi đọc bất cứ thứ gì. Hãy yêu cầu REA tóm tắt trước. Kéo toàn bộ ứng dụng ra cùng lúc sẽ chôn vùi logic thực sự trong đống nhiễu và làm đội chi phí của bạn.
- Đọc các hàm theo thứ tự trong file. Hãy sắp xếp theo cross-reference count. Hàm có 147 xref chính là kiến trúc; hàm phụ trợ 2 xref có thể đợi.
- Cày cuốc với obfuscation cấp độ 3. Benchmark cho thấy tỷ lệ giải quyết multi-layer là 0%. Hãy đặt ngân sách, lưu lại ngữ cảnh từ các hàm lân cận, và quay lại sau.
- Để model sao chép code vào bản tái tạo của bạn. Điều đó phá vỡ nguyên tắc clean-room. Viết spec trước trong một context, rồi triển khai từ spec đó trong một context khác.
- Phát hành mà không có báo cáo parity. "Tôi nghĩ nó khớp" không phải là bằng chứng. 50 bài kiểm thử hành vi và một tỷ lệ khớp mới là bằng chứng.
Kết luận:
Cài đặt REA. Đọc file binary. Tái tạo nó thành của riêng bạn.
Định tuyến mục tiêu, vẽ bản đồ bề mặt, decompile các hàm nóng, để Opus 5.5 đặt tên cho mọi thứ, phá vỡ những lớp obfuscation đáng phá, mở rộng quy mô bằng swarm, sau đó viết spec sạch sẽ và phát hành bản tái tạo qua MCP.
Mười một bước. Một model. Không một dòng code sao chép.
