REA: Reverse Engineer Ứng Dụng Bằng AI Agent

Bạn thấy một tính năng hay trong một ứng dụng khác và muốn biết nó được xây dựng ra sao. Nhưng bạn không có source code, không có tài liệu, chỉ có file cài đặt và giao diện trước mắt. Đây là tình huống quen thuộc của developer, sysadmin và DevOps khi đối mặt với ứng dụng legacy.

Cách truyền thống là mở binary bằng Hopper, Ghidra hay IDA rồi đọc assembly. Cách này hiệu quả nhưng chậm và đòi hỏi kỹ năng chuyên sâu.

REA — Reverse Engineer Anything — giải quyết đúng điểm này. Nó cho AI agent gọi trực tiếp công cụ phân tích qua MCP (Model Context Protocol), rồi trả về kết quả kèm bằng chứng và giới hạn.

Lưu ý thẳng thắn: mình chưa chạy thử REA trên máy thật; phần cài đặt dưới đây là luồng kỳ vọng theo tài liệu chính thức của dự án.

REA là gì và dành cho ai

REA là dự án mã nguồn mở của tài khoản morluto trên GitHub, viết bằng TypeScript, cấp phép MIT. Tính đến ngày 2026-10-29, repository ghi nhận khoảng 404.159 star và 101.287 fork, bản mới nhất là rea-agents 6.8.0 ra ngày 2026-10-25, và dự án đứng đầu GitHub Trending trong ngày 2026-10-29.

Điều quan trọng nhất cần hiểu: REA không phải là một decompiler mới. Nó là lớp điều phối. Agent của bạn — Claude Code, Codex, Cursor, Gemini CLI, Grok Build hay các agent khác được hỗ trợ — gọi tool qua MCP, tool gọi tiếp tới engine hoặc parser có sẵn, rồi trả evidence có cấu trúc về cho agent suy luận.

Với binary native, engine đó là Hopper, Ghidra, IDA hoặc Kuna bạn đã cài. Với app JavaScript/Electron, REA dùng parser tĩnh tích hợp, không cần engine native.

REA phân tích được những gì

Bảng sau tóm tắt các loại target mà tài liệu của dự án liệt kê.

Loại target	REA trả về những gì
Native binary	Pseudocode, assembly, string, symbol, call, tham chiếu
Go/Rust, PE/ELF, WASM, EVM	Kiểm tra tĩnh, certificate, import, bytecode
.NET, IL2CPP, Godot PCK, GPU	Cấu trúc assembly, metadata, nội dung gói
GGUF/safetensors, SQLite	Metadata model, cấu trúc và dữ liệu database
JavaScript/Electron	Module, import, source map, route, IPC
Website, HAR/SAZ	Phân tích qua trình duyệt họ Chrome, dấu vết mạng

JavaScript/Electron là điểm vào rẻ nhất: phân tích tĩnh không cần engine native, và kết quả dễ đối chiếu vì bạn có thể mở lại source đã bundle để kiểm tra. Native binary là phần khó nhất, vì REA phụ thuộc hoàn toàn vào engine gốc.

Điểm khác biệt lớn nhất so với hỏi LLM chay, theo mình, nằm ở evidence và limitation đi kèm kết quả. Không có tool, model chỉ trả lời dựa trên những gì nó đã học, và bạn không thể kiểm tra câu trả lời bám vào đâu trong ứng dụng thật. Có REA, mỗi kết luận đáng lẽ phải đi kèm bằng chứng trích từ target và giới hạn nói rõ phần nào chưa chắc chắn.

Kiến trúc và cơ chế hoạt động

Kiến trúc REA gồm ba lớp. Lớp trên là agent: bạn đặt câu hỏi, agent quyết định gọi tool nào, với phạm vi nào. Lớp giữa là rea-agents MCP: nó expose công cụ phân tích cho agent, nhận truy vấn hẹp, gọi xuống engine, rồi chuẩn hóa kết quả thành evidence có cấu trúc.

Lớp dưới là engine và parser: Hopper, Ghidra, IDA hoặc Kuna với native binary; parser tĩnh với JavaScript/Electron; trình duyệt họ Chrome với website. REA không thay thế các engine này; nó chỉ giúp agent gọi chúng có hệ thống.

Luồng làm việc điển hình: bạn đặt câu hỏi theo tính năng, agent chọn target, gọi tool với phạm vi hẹp, nhận evidence, suy luận, rồi trả lời kèm limitation hoặc gọi tiếp một truy vấn hẹp hơn. Vòng lặp này — truy vấn hẹp, evidence, kết luận kèm giới hạn, truy vấn tiếp — theo mình chính là giá trị thực của REA.

Vòng lặp này cũng là điểm yếu lớn nhất. Truy vấn quá rộng sẽ làm output tràn context, khiến agent tóm tắt, cắt bớt hoặc suy đoán. Truy vấn quá hẹp sẽ làm agent bỏ sót luồng điều khiển quan trọng. Vì vậy, đừng ra lệnh “phân tích app này”. Hãy chia nhỏ câu hỏi theo tính năng và bắt agent trích dẫn evidence cho mỗi khẳng định.

Cài đặt REA và rea-agents MCP

Yêu cầu hệ thống

Kiểm tra ba thứ trước khi cài. Thứ nhất, Node.js phải nằm trong dải được hỗ trợ: 22.x từ 22.23.4 trở lên, 24.x từ 24.22.1 trở lên, hoặc 26.12.1 trở lên, kèm npm. Hãy kiểm tra bằng node --version trước. Thứ hai, trên Linux, các tác vụ Ghidra, JADX và phân tích tĩnh JavaScript/Electron cần lệnh ps tương thích procps trên PATH. Thứ ba, phân tích native binary cần có sẵn Hopper, Ghidra, IDA hoặc Kuna; phân tích JavaScript/Electron thì không cần engine native. Trước khi setup, hãy sao lưu file cấu hình của agent bạn định gắn MCP vào.

Cài đặt nhanh và cài đặt toàn cục

Cách nhanh nhất, theo tài liệu của dự án, là chạy:

npx rea-agents setup

Lệnh này mở quy trình tương tác: chọn agent, xem trước các thay đổi cấu hình được đề xuất, phê duyệt rồi khởi động lại agent để MCP server được nạp. Đừng bỏ qua bước xem trước, và đừng quên khởi động lại agent.

Để dùng CLI trực tiếp từ terminal, cài package toàn cục:

npm install --global rea-agents
rea --help
rea update

rea --help cho thấy các subcommand khả dụng, còn rea update cập nhật rea-agents lên bản mới. Nên chạy rea update định kỳ.

Phân tích JavaScript/Electron và kiểm chứng

Đây là lệnh mẫu để phân tích một ứng dụng JavaScript/Electron, và cũng là điểm bắt đầu mình khuyên bạn thử đầu tiên:

npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --json

Đường dẫn phải là tuyệt đối, không dùng đường dẫn tương đối. Cờ --json yêu cầu output JSON có cấu trúc, tiện đối chiếu bằng script. Output kỳ vọng chứa module, import, route, IPC, cùng evidence và limitation — tức là bạn nhận được cả dữ liệu thô để tự kiểm chứng, không chỉ một bản tóm tắt.

Sau đó, quay lại agent với câu hỏi theo tính năng. Ví dụ mẫu mà tài liệu đưa ra: “Hiểu cách tìm kiếm hoạt động trong ứng dụng Notes, cho tôi xem evidence, rồi xây tính năng tương tự cho dự án của tôi.” Thay Notes bằng ứng dụng của bạn, và giữ hai yêu cầu trong prompt: show evidence, và chỉ kết luận trong phạm vi evidence cho phép.

Kiểm chứng như sau: khởi động lại agent và xác nhận agent thấy tool REA trong danh sách MCP tool. Sau đó, chạy lệnh phân tích trên một ứng dụng test mà bạn sở hữu và kiểm tra output có module, route, IPC và limitation hay không.

Lỗi thường gặp, rollback

Bảng sau chỉ liệt kê những lỗi có cơ sở từ yêu cầu hệ thống và luồng setup, không phải lỗi mình đã gặp thực tế vì mình chưa chạy thử công cụ này.

Triệu chứng	Cách xử lý
Setup báo lỗi version	Node không nằm trong dải hỗ trợ; chuyển sang version được hỗ trợ
Lỗi `ps` trên Linux	Thiếu `ps` tương thích procps; cài gói procps rồi chạy lại
Phân tích native không ra kết quả	Chưa cài engine native; cài Hopper, Ghidra, IDA hoặc Kuna
Lỗi đường dẫn	Dùng đường dẫn tương đối; chuyển sang đường dẫn tuyệt đối
Agent không thấy tool	Quên restart agent, hoặc setup sửa nhầm file cấu hình

Nếu workflow vẫn gãy, rollback sạch nhất là: gỡ MCP khỏi cấu hình agent, gỡ package toàn cục bằng npm uninstall --global rea-agents, khôi phục file cấu hình agent từ bản sao lưu, rồi xác minh agent không còn tool REA và không còn tham chiếu nào trong config.

Đánh giá: ưu điểm, nhược điểm và vận hành

Ưu điểm rõ nhất là giảm rào cản tiếp cận reverse engineering. Người không chuyên RE vẫn có thể đi từ con số không tới một bản đồ tính năng có evidence trong thời gian ngắn, thay vì mất nhiều ngày học Ghidra trước khi trả lời được câu hỏi đầu tiên. Ưu điểm thứ hai là workflow có bằng chứng: mỗi kết luận gắn với evidence và limitation, nên người đọc có điểm bám để kiểm chứng thay vì tin vào trí nhớ của model.

Nhược điểm cũng rõ ràng. Thứ nhất, chất lượng bị giới hạn bởi engine gốc và trạng thái binary: REA không làm Ghidra giỏi hơn, nó chỉ giúp agent gọi Ghidra đều tay hơn.

Thứ hai, output dài dễ tràn context: càng nhiều evidence càng chính xác, nhưng càng tốn context và càng dễ bị agent tóm tắt sai. Thứ ba, chưa có benchmark độc lập nào để đối chiếu độ chính xác.

Về hiệu năng, không có con số đã kiểm chứng nào để trích dẫn, và mình sẽ không bịa ra một con số nào. Các yếu tố ảnh hưởng thực tế gồm kích thước binary, lượng symbol còn lại, engine được chọn và phạm vi truy vấn.

Bảo mật và pháp lý

Nguyên tắc đầu tiên: chỉ phân tích phần mềm bạn sở hữu, phần mềm mã nguồn mở, hoặc phần mềm bạn được phép kiểm tra rõ ràng. Phân tích phần mềm không có quyền, sao chép code độc quyền nguyên văn, hay dùng kết quả để bypass license hoặc DRM là những việc bạn không nên làm, bất kể công cụ có cho phép về mặt kỹ thuật hay không.

Nguyên tắc thứ hai: binary có thể chứa secret. Key, token, endpoint nội bộ, chuỗi kết nối đều có thể nằm trong string của binary, và do đó cũng có thể xuất hiện trong output phân tích. Đừng phân tích binary production chứa secret thật trên máy dùng chung, đừng paste output chưa rà soát vào agent chạy model cloud, và đừng commit output phân tích vào repository.

Nguyên tắc thứ ba: phân biệt tool local với model cloud, như đã nói ở phần kiến trúc. Chạy tool trên máy mình không tự động bảo vệ excerpt evidence khỏi việc đi vào prompt của model cloud.

So sánh với Hopper, Ghidra, IDA và cách làm thủ công

So sánh dưới đây đặt các công cụ cùng một phạm vi: hiểu một ứng dụng không có source.

Tiêu chí	REA	Hopper/Ghidra/IDA thuần	LLM không có tool	strings, objdump, jadx
Đối tượng	Người dùng AI agent, developer	Chuyên gia RE, phân tích bảo mật	Bất kỳ ai có tài khoản LLM	Người quen dòng lệnh
Tự động hóa	Agent tự gọi tool theo câu hỏi	Thủ công, từng bước	Không có phân tích thật	Thủ công từng lệnh
Evidence	Có, kèm limitation	Có, nhưng bạn tự trích xuất	Không có evidence từ target	Có, nhưng rời rạc
Chi phí	MIT, engine native có thể tốn phí	Ghidra miễn phí, Hopper/IDA trả phí	Tùy gói LLM	Miễn phí, có sẵn
Học tập	Thấp nếu đã dùng AI agent	Cao, cần hiểu assembly	Thấp nhất, độ tin cậy thấp nhất	Trung bình
Tái triển khai	Tốt: evidence sang đặc tả rồi code	Tốt nhưng chậm	Kém: dễ bịa chi tiết	Kém: chỉ cho mảnh rời rạc

Theo mình, cách phân vai hợp lý là như sau. Dùng REA khi cần khám phá nhanh, cần bản đồ tính năng có evidence, và câu hỏi nằm ở mức tính năng chứ chưa tới mức từng lệnh assembly. Mở Ghidra hoặc IDA trực tiếp khi cần phân tích sâu có chủ đích hoặc khi binary chống phân tích.

Use case thực tế

Với doanh nghiệp, use case rõ nhất là audit ứng dụng legacy trước khi thay thế.

Với homelab và self-host, use case là mổ ứng dụng desktop hoặc server trước khi quyết định tự host hay viết bản thay thế. Đây là cùng một mẫu với bài toán tìm kiếm local cho AI agent trong bài về Xerj: đưa AI agent tới gần dữ liệu và công cụ thật trên máy mình, thay vì hỏi model chay.

Với workflow AI, use case là đi từ evidence của app mẫu sang đặc tả tái triển khai, rồi giao đặc tả đó cho coding agent implement.

Với DevOps và IT admin, use case là xác minh hành vi ứng dụng trước khi triển khai hoặc khi troubleshooting: route nào, IPC nào, dependency nào, dữ liệu nào được chạm tới.

Kết luận

REA phù hợp với team đã dùng AI coding agent và đang cần khám phá nhanh một ứng dụng không có source, với yêu cầu rõ ràng là kết quả phải kèm evidence và limitation. Nó đặc biệt đáng thử ở điểm vào rẻ nhất — ứng dụng JavaScript/Electron — nơi bạn không cần engine native và có thể đối chiếu kết quả trực tiếp với source đã bundle.

REA không phù hợp nếu bạn cần phân tích pháp y chuyên sâu, làm việc với binary chống phân tích nặng, hoặc kỳ vọng kết quả tuyệt đối không cần kiểm chứng. Nó cũng không phù hợp nếu bạn chưa có kỷ luật đặt câu hỏi hẹp và bắt agent trích dẫn evidence — vì khi đó REA chỉ giúp bạn nhận được bản tóm tắt sai nhanh hơn, chứ không giúp bạn hiểu đúng hơn.

Bước tiếp theo, theo mình, nên làm theo thứ tự này: sao lưu cấu hình agent, cài REA trong môi trường test, thử phân tích một ứng dụng JavaScript/Electron mà bạn sở hữu, kiểm tra output JSON có đủ module, route, IPC, evidence và limitation hay không.

Tham khảo

Repository chính thức: https://github.com/morluto/rea
Trang chủ dự án: https://rea.tools/
Package npm rea-agents: https://www.npmjs.com/package/rea-agents
GitHub Trending hàng ngày: https://ghtrends.dev/daily/

Tìm kiếm