REA: Reverse Engineer Anything: Từ câu hỏi của AI agent đến bằng chứng, mã giả và bản tái tạo hành vi

Bài viết này giải thích REA (Reverse Engineer Anything) ở góc nhìn kỹ thuật: nó là gì, hoạt động ra sao, cài đặt như thế nào, những bài toán nào có thể áp dụng, và vì sao “phân tích cục bộ” không đồng nghĩa với “an toàn tuyệt đối”. Nội dung ưu tiên các thông tin có thể kiểm chứng từ repository và tài liệu chính thức của dự án.

Mục lục

• 1. REA là gì và giải quyết vấn đề nào?
• 2. Kiến trúc và luồng hoạt động
• 3. Cài đặt từ con số 0
• 4. Feature map: REA phân tích được gì?
• 5. Case study và bài toán có thể áp dụng
• 6. Quy trình triển khai thực tế
• 7. Rủi ro, giới hạn và kiểm soát
• 8. Những câu hỏi cần đặt ra
• 9. Kết luận
• Tài liệu tham khảo

1. REA là gì và giải quyết vấn đề nào?

REA là một MCP server mã nguồn mở kết nối AI agent với các công cụ phục vụ reverse engineering trên nhiều lớp: tệp nhị phân native, ứng dụng JavaScript/Electron, assembly .NET, trang web và hành vi runtime. Mục tiêu không chỉ là “decompile ra mã”, mà là biến câu hỏi tự nhiên của người dùng thành một cuộc điều tra có phạm vi, có bằng chứng và có giới hạn được nêu rõ.

Ví dụ, thay vì tự mò trong một ứng dụng đóng gói, người dùng có thể yêu cầu agent: “Hãy tìm hiểu cách tính năng tìm kiếm trong ứng dụng Notes hoạt động, cho tôi xem bằng chứng, rồi xây dựng một phiên bản tương tự”. Agent gọi REA qua MCP, nhận các phát hiện về module, import, IPC, hàm, tham chiếu hoặc trace, sau đó dùng chúng để giải thích và triển khai. Đây là điểm khác biệt quan trọng: REA cung cấp “hạ tầng quan sát”; agent chịu trách nhiệm đặt câu hỏi, tổng hợp và viết mã.

README của dự án nhấn mạnh ba đặc tính: phân tích chạy cục bộ; kết quả đi kèm Evidence và limitations; và cùng một workflow có thể được gọi qua MCP hoặc CLI. Vì vậy REA phù hợp với các nhóm muốn đưa reverse engineering vào quy trình có thể lặp lại, thay vì chỉ dựa vào một phiên làm việc thủ công trong IDE hoặc disassembler.

2. Kiến trúc và luồng hoạt động

Hình 2 — Mô hình khái niệm: agent → MCP → provider/công cụ phân tích cục bộ → Evidence → giải thích và tái tạo.

2.1. MCP là lớp điều phối, không phải “AI đọc mọi thứ”

MCP (Model Context Protocol) là giao diện để agent khám phá tool, gửi input có schema và nhận output có cấu trúc. Trong REA, binary_session cung cấp identity, catalog và tool availability của phiên; open_binary chọn provider; các tool phân tích trả về structured result cùng Evidence. Nếu tool không khả dụng, kết quả nên nói rõ reason và remediation thay vì để agent đoán.

Thiết kế này giúp tách bốn trách nhiệm: agent định hướng câu hỏi; REA quản lý session và hợp đồng dữ liệu; provider thực hiện phân tích; còn người dùng xác nhận phạm vi và diễn giải kết quả. REA không tự động chuyển sang provider khác sau khi provider đang chọn bị lỗi; đó là một chủ ý để tránh thay đổi ngầm chất lượng hoặc ngữ nghĩa của kết quả.

2.2. Evidence và snapshot tạo thành “chuỗi kiểm toán”

Evidence lưu identity của artifact, vị trí nguồn, quan sát, suy luận và các phát hiện chưa giải quyết. Người dùng có thể import, export canonical form và compare hai bundle. Snapshot chỉ tái sử dụng kết quả khi target bytes, operation, parameters, provider và settings khớp chính xác; đây là cache quan sát, không phải một cơ sở dữ liệu provider đầy đủ.

Với ứng dụng lớn, Evidence có thể rất lớn. Tài liệu CLI khuyến nghị lưu kết quả rồi chiếu ra summary, module page hoặc một module cụ thể thay vì đưa toàn bộ bundle vào context của agent. Đây là một nguyên tắc vận hành quan trọng: context window không nên trở thành nơi chứa mọi byte của mục tiêu.

3. Cài đặt từ con số 0

3.1. Điều kiện nền

REA yêu cầu Node.js 22.x từ 22.19 trở lên, 24.x từ 24.11 trở lên hoặc 26+; Node.js 23 và 25 không được hỗ trợ theo tài liệu cài đặt. Cách nhanh nhất là dùng npm/npx. Phân tích JavaScript/Electron tĩnh không cần Hopper hay Ghidra; phân tích native cần một provider tương ứng như Hopper, Ghidra hoặc IDA, cùng giấy phép hợp lệ cho công cụ thương mại.

3.2. Thiết lập agent có hướng dẫn

npx rea-agents setup

# hoặc dùng bản mới nhất một cách tường minh

npx rea-agents@latest setup

Trình setup phát hiện các agent được hỗ trợ, hiển thị đường dẫn và thay đổi dự kiến, sau đó yêu cầu chấp thuận trước khi ghi cấu hình. Nó có thể đăng ký MCP server, cài workflow instruction tương ứng và sao lưu cấu hình cũ. Sau khi hoàn tất, khởi động lại agent. Cài package của npm và chấp thuận thay đổi cấu hình REA là hai bước approval khác nhau.

3.3. Cài CLI toàn cục hoặc chạy một lần

npm install –global rea-agents

rea –help

# Phân tích ứng dụng JavaScript/Electron đã giải nén hoặc ASAR

npx -y rea-agents@latest analyze-javascript-application \

/absolute/path/to/app –json

Nếu chỉ muốn thử trong một pipeline, có thể dùng npx mà không cài global. Nếu cần lệnh rea trên PATH, dùng npm install –global. Tài liệu cũng có curl wrapper, nhưng wrapper chỉ cài npm package; nó không tự biến một shell không tương tác thành quyền chấp thuận cài dependency bên ngoài. [4]

3.4. Đăng ký MCP thủ công

{

“mcpServers”: {

“rea”: {

“command”: “npx”,

“args”: [“-y”, “rea-agents@6.4.0”, “mcp”]

}

}

}

Đăng ký bền vững nên pin một phiên bản cụ thể thay vì luôn dùng latest. Khi cập nhật, chạy lại setup, xem diff cấu hình rồi khởi động lại client. Ví dụ trên phản ánh shape trong tài liệu; phiên bản nên được điều chỉnh theo release mà nhóm đã kiểm thử.

3.5. Kiểm tra readiness trước khi phân tích

rea doctor –json

rea providers –json

rea capabilities –json

Đối với native target, provider có thể cần thời gian khởi động đáng kể. Khi client timeout, không nên kết luận ngay rằng target hỏng; cần đọc diagnostic, kiểm tra provider và cân nhắc close/reopen với deadline phù hợp. REA báo riêng provider_unavailable, ambiguous selection và cleanup_incomplete để phân biệt lỗi phân tích với lỗi dọn dẹp tài nguyên.

4. Feature map: REA phân tích được gì?

Feature map dưới đây tóm lược các nhóm target được README và catalog của dự án mô tả. “Có thể phân tích” không có nghĩa là mọi artifact đều đạt coverage như nhau; provider, platform, format và chất lượng input quyết định độ sâu của kết quả.

5. Case study và bài toán có thể áp dụng

Hình 3 — Các hướng áp dụng được minh họa trong showcase chính thức: Android, native game, Electron và CTF.

Showcase chính thức của REA có các ví dụ đã được kiểm tra với code, hình và kết quả. Những ví dụ này không phải lời hứa rằng mọi ứng dụng tương tự sẽ cho cùng mức kết quả; chúng cho thấy cách đặt câu hỏi và nối bằng chứng thành một kết luận có thể xác minh.

5.1. Android: truy vết cách authenticator tạo mã

Case study Aegis đi từ APK đến các method sinh mã sáu chữ số, sau đó dùng một “đồng hồ demo” để quan sát vì sao mã thay đổi mỗi 30 giây. Bài toán phù hợp khi cần kiểm tra interoperability, audit logic hoặc hiểu một artifact đã phát hành mà không có source gốc. Đầu ra có giá trị nhất không phải là “một đoạn decompile”, mà là chuỗi: method liên quan → quy tắc suy ra → kiểm tra bằng hành vi.

5.2. Native và game preservation: tái tạo một phép tính nhỏ

Với DX-Ball, REA lần theo instruction, caller reference và numeric constant để khôi phục phép tính sound-pan, rồi kiểm tra C function tái tạo với behavior của chương trình gốc và 63 byte đã compile. Mẫu này có thể áp dụng cho software preservation, porting, compatibility layer và debugging binary mà team sở hữu.

5.3. Electron: lần theo đường đi của dữ liệu rich text

Case study Notion lần từ API phía page qua các wrapper IPC đến system clipboard, rồi giải thích cách một HTML marker giữ quan hệ với dữ liệu block rich text. Đây là hướng hữu ích cho interoperability và migration tooling, nhưng cũng là nơi cần ranh giới pháp lý rõ ràng: hiểu protocol không đồng nghĩa với quyền sao chép code hoặc asset.

5.4. CTF và giáo dục: chuyển checker thành phương trình

Case study DownUnderCTF cho thấy REA có thể tìm checking function, biến mask và sum thành equations, rồi xác minh flag bằng chương trình gốc. Trong lớp học, workflow này giúp người học quan sát cách một hypothesis được nâng thành kết luận: có vị trí code, có phép biến đổi, có test lại trên binary.

5.5. Các use case khác có tính thực dụng

• Vulnerability research và incident analysis: lập bản đồ đường đi của input, quan sát artifact và giữ lại bằng chứng cho báo cáo.
• Interoperability: xác định format, protocol hoặc hành vi cần tương thích mà không phụ thuộc vào source gốc.
• Feature parity có kiểm soát: hiểu một hành vi của ứng dụng đã được cấp quyền, sau đó viết implementation độc lập và test theo behavior.
• Release regression: so sánh Evidence giữa hai phiên bản để nhận diện thay đổi ở module, function hoặc artifact.
• Debugging hệ thống nội bộ: kết hợp static inspection với runtime observation để phân biệt “code có tồn tại” và “code thật sự được gọi”.

6. Quy trình triển khai thực tế

Một quy trình bền vững nên bắt đầu từ câu hỏi nhỏ, không phải từ việc “dump toàn bộ target”. Mỗi vòng điều tra cần có target identity, scope, provider, query, evidence và limitation. Có thể dùng playbook sau:

1. Xác nhận quyền và mục tiêu — Ghi rõ artifact thuộc ai, phạm vi được phép và câu hỏi cần trả lời. Nếu không xác định được authorization, dừng trước khi nạp binary.

2. Chuẩn hóa input — Hash artifact, tách môi trường thử nghiệm, loại secret khỏi HAR/log và ghi runtime/provider version.

3. Chọn workflow rẻ nhất — Bắt đầu bằng inspect metadata, static JS/.NET hoặc SQLite snapshot trước khi bật native provider hay runtime capture.

4. Chạy một câu hỏi hẹp — Ví dụ: “module nào gọi API clipboard?” hoặc “hàm nào tạo chuỗi 6 chữ số?”. Mỗi câu trả lời làm cơ sở cho query tiếp theo.

5. Lưu và chiếu Evidence — Lưu bundle/snapshot ở thư mục quyền hạn chế; tạo summary hoặc module page để agent đọc thay vì nhét toàn bộ kết quả vào context.

6. Xác minh độc lập — Viết test, chạy lại trên input khác, so sánh với behavior gốc hoặc đối chiếu bằng provider thứ hai nếu được phép.

7. Báo cáo phần chưa biết — Phân biệt “không thấy edge” với “edge không tồn tại”; ghi rõ provider limitation, timeout, missing symbol và cleanup status.

7. Rủi ro, giới hạn và kiểm soát

7.1. Rủi ro pháp lý và quyền sử dụng

Reverse engineering có thể bị giới hạn bởi luật tại từng quốc gia, EULA, license và điều khoản dịch vụ. Disclaimer của REA cho phép các hướng như nghiên cứu bảo mật, phân tích malware/incident, CTF, giáo dục, interoperability, preservation và phần mềm do bạn sở hữu hoặc được ủy quyền. Dự án không hỗ trợ bypass DRM, license check, anti-cheat, authentication, bot protection, access control, phát triển cheat hay sao chép code/asset độc quyền.

Biện pháp kiểm soát: lưu authorization cùng ticket; xác định artifact và mục đích; tách “hiểu behavior” khỏi “copy implementation”; tham vấn pháp chế khi phân phối kết quả hoặc khi license có điều khoản reverse engineering đặc biệt.

7.2. Rủi ro thực thi artifact không tin cậy

Security policy nêu rõ REA dùng current-user Unix socket và capability token để xác thực provider bridge, tạo project Ghidra tạm và giới hạn một số tài nguyên. Nhưng REA không phải sandbox. Mở một binary không tin cậy vẫn ủy quyền parsing/analysis cho provider với quyền của user hiện tại; các kiểm soát này không bảo vệ khỏi process độc hại đã chạy cùng user.

Biện pháp kiểm soát: dùng VM hoặc user riêng với quyền tối thiểu; không phân tích artifact nhạy cảm trên máy đang chứa production credential; tắt mount không cần thiết; giới hạn network; giữ provider cập nhật; coi output như dữ liệu chưa tin cậy.

7.3. Rủi ro rò rỉ dữ liệu qua agent/model

REA phân tích mục tiêu cục bộ, nhưng tool result được chuyển cho agent và model provider có data policy riêng. “Local analysis” vì vậy không đồng nghĩa “mọi byte đều ở lại máy”. Trước khi dùng cloud model, cần biết Evidence chứa gì, có source path, secret, PII hay proprietary code không.

Biện pháp kiểm soát: redact trước khi gửi; dùng model/provider phù hợp chính sách; giới hạn output bằng view; lưu bundle với owner-only permissions; tách dữ liệu nghiên cứu khỏi dữ liệu khách hàng.

7.4. Rủi ro diễn giải sai và coverage ảo

Decompilation là một diễn giải. Symbol thiếu, obfuscation, compiler optimization, dynamic loading, provider limitation hoặc timeout có thể tạo ra kết luận không đầy đủ. MCP contract cũng quy định rằng call graph rỗng kèm limitation không phải bằng chứng rằng function không có call; trace bị truncate phải được đọc cùng residual unknowns.

Biện pháp kiểm soát: yêu cầu Evidence cho mỗi kết luận; test hypothesis trên behavior; đọc limitations; không biến “not observed” thành “does not exist”; pin provider và version khi so sánh.

7.5. Rủi ro vận hành và dependency

REA phụ thuộc vào Node runtime, agent client, browser, disassembler, JDK, JADX, adb hoặc các tool khác tùy target. Native cold start có thể lâu; provider có thể yêu cầu license hoặc permission. Việc dùng @latest trong automation cũng làm giảm tính tái lập.

Biện pháp kiểm soát: pin version, chạy doctor trong CI, lưu catalog/provider identity, đặt timeout theo target, dùng snapshot khi có thể, và cập nhật theo release policy. Security policy của dự án chỉ hỗ trợ security fixes cho latest published version.

8. Những câu hỏi cần đặt ra

Tôi có quyền phân tích artifact này không? Ai sở hữu, phạm vi authorization là gì, và output sẽ được dùng hay phân phối ra sao?

Câu hỏi kỹ thuật thật sự là gì? Tôi cần biết một function, một protocol, một dữ liệu runtime hay chỉ cần metadata?

Static evidence đã đủ chưa? Có cần chạy target hoặc capture network/process không? Runtime có làm phát sinh dữ liệu nhạy cảm hay thay đổi state không?

Provider nào là nguồn sự thật cho phiên này? Phiên bản, profile, license và khả năng của provider có được ghi lại không?

Kết luận nào là quan sát, kết luận nào là suy luận? Mỗi bước có source location, hash, test hoặc reproduction tương ứng không?

Tôi xử lý unknown thế nào? Có limitation, residual unknown, truncated trace hay cleanup_incomplete nào cần đưa vào báo cáo không?

Bằng chứng có thể tái lập không? Người khác có thể dùng cùng artifact bytes, query, provider và settings để nhận kết quả tương đương không?

Có nên đưa output vào model cloud không? Evidence có chứa source code độc quyền, credential, PII, private path hoặc dữ liệu khách hàng không?

Bản tái tạo có độc lập không? Implementation mới có dựa trên behavior/API cần tương thích hay đã sao chép code/asset được bảo hộ?

Khi nào nên dừng? Nếu authorization không rõ, provider không đáng tin, artifact quá nhạy cảm hoặc coverage không đủ để hỗ trợ quyết định, câu trả lời đúng có thể là không tiếp tục.

9. Kết luận

REA đáng chú ý vì nó đưa reverse engineering vào một workflow mà agent có thể điều khiển bằng ngôn ngữ tự nhiên nhưng vẫn phải trả về bằng chứng, trạng thái và giới hạn. Giá trị lớn nhất không nằm ở việc thay thế chuyên gia disassembler; nó nằm ở việc rút ngắn khoảng cách giữa “tôi muốn hiểu hành vi này” và “tôi có một chuỗi quan sát có thể kiểm tra để tiếp tục”.

Cách bắt đầu an toàn là chọn một artifact bạn sở hữu hoặc được ủy quyền, một câu hỏi nhỏ và một target tĩnh. Chạy setup, kiểm tra readiness, lưu Evidence, rồi xác minh bằng test độc lập. Khi workflow đã ổn định, mới mở rộng sang native provider, runtime capture, comparison và automation. Với reverse engineering, tốc độ của agent chỉ có ý nghĩa khi đi cùng phạm vi hợp pháp, dữ liệu được bảo vệ và kết luận được phân biệt rõ giữa điều đã quan sát với điều mới chỉ suy ra.

Tài liệu tham khảo

[1] morluto/rea — README và mô tả dự án — https://github.com/morluto/rea

[2] REA — CLI and Evidence — https://github.com/morluto/rea/blob/main/docs/cli.md

[3] REA — MCP runtime contracts — https://github.com/morluto/rea/blob/main/docs/mcp-contracts.md

[4] REA — Installation and setup — https://github.com/morluto/rea/blob/main/docs/installation.md

[5] REA — Case studies / Showcases — https://rea.tools/showcase/

[6] REA — Responsible-use disclaimer — https://github.com/morluto/rea/blob/main/DISCLAIMER.md

[7] REA — Security policy — https://github.com/morluto/rea/blob/main/SECURITY.md

Vui lòng đăng nhập để bình luận.