Có thể dùng REA mà không cài Ghidra, Hopper hoặc IDA không?

Có, với một số target. Phân tích tĩnh JavaScript, Electron và .NET không cần native analysis engine. Phân tích sâu native binary cần Hopper, Ghidra hoặc IDA.

REA khác một MCP server bọc quanh decompiler ở đâu?

REA có contract cho Evidence, unknown, target identity, provider binding, retained session records, cancellation và cleanup. Nó còn đi kèm skill hướng dẫn agent chọn workflow theo loại target thay vì chỉ đưa ra một danh sách tool.

Điểm cần kiểm tra trước khi dùng REA là gì?

Xác nhận bạn có quyền phân tích target, phân biệt static analysis với runtime observation, chọn đúng provider và giữ nguyên giới hạn hoặc unknown trong kết quả thay vì biến suy luận thành sự thật.

October 13, 2026 · Analysis · MCP · Coding Agents · Vietnamese

REA: Khi coding agent biết reverse engineer cả binary lẫn ứng dụng

Q: REA có thay thế Ghidra, Hopper hoặc IDA không?

Không. REA dùng các engine này làm provider cho phân tích native, rồi chuẩn hóa kết quả, bằng chứng, session và workflow để CLI hoặc AI agent có thể sử dụng nhất quán.

Q: REA có gửi binary lên cloud không?

REA phân tích target trên máy local. Tuy nhiên kết quả tool được gửi cho coding agent, vì vậy dữ liệu đó vẫn chịu chính sách của model provider mà bạn đang dùng.

Q: REA phù hợp nhất với tác vụ nào?

REA phù hợp khi câu trả lời phụ thuộc vào binary, package đã phát hành, JavaScript hoặc Electron đã bundle, hành vi runtime, firmware, Android APK, browser capture hoặc sự khác biệt giữa hai artifact mà source code hiện có không chứng minh được.

Phân tích kiến trúc REA: một MCP và CLI biến Hopper, Ghidra, IDA, JavaScript, Electron, Android và browser thành workflow reverse engineering có bằng chứng cho AI agent.

REA: Khi coding agent biết reverse engineer cả binary lẫn ứng dụng

Cách mặc định để dùng AI cho reverse engineering thường là ném một đống assembly hoặc pseudocode vào model rồi hỏi: “đoạn này làm gì?”

Context dài hơn. Prompt chi tiết hơn. Model mạnh hơn.

Cách đó có thể giúp với một function nhỏ. Nó hỏng rất nhanh khi câu hỏi đi qua binary, resource, JavaScript bundle, IPC, runtime behavior và nhiều tool phân tích khác nhau — vì model không biết bằng chứng đến từ đâu, phần nào chỉ là suy luận, và phần nào chưa từng được quan sát.

Đây là điểm làm REA — Reverse Engineer Anything đáng chú ý. REA không chỉ đưa decompiler cho AI agent. Nó biến reverse engineering thành một workflow có target, bằng chứng, giới hạn và trạng thái rõ ràng.[1]

Repo này có hơn 160.000 GitHub stars khi bài viết được xuất bản, phát hành dưới giấy phép MIT và đang ở bản rea-agents 6.4.0.[1][8] Nhưng con số đó không phải phần thú vị nhất. Phần đáng học nằm ở cách REA thiết kế một harness cho công việc vốn rất dễ trượt từ “đã quan sát” sang “nghe có vẻ đúng”.

REA thực sự là gì?

REA là một CLI và MCP server chạy local. Nó nối coding agent với nhiều lớp phân tích khác nhau: Hopper, Ghidra hoặc IDA cho native binary; static analysis cho JavaScript và Electron; metadata và CIL cho .NET; JADX cho Android; CDP và Playwright cho website; cùng các workflow cho firmware, network capture, process behavior và artifact extraction.[1][2]

Luồng cơ bản trông như sau:

Câu hỏi của người dùng
        ↓
Coding agent chọn workflow theo loại target
        ↓
REA định tuyến tới provider hoặc analyzer phù hợp
        ↓
Tool trả về kết quả + Evidence + unknown + limitations
        ↓
Agent tiếp tục trace, so sánh, giải thích hoặc dựng lại tính năng

Điểm quan trọng là REA không cố trở thành một decompiler mới. Nó đứng phía trên các engine và format-specific analyzer, rồi chuẩn hóa cách agent mở target, chọn provider, đặt câu hỏi, giữ bằng chứng và dọn tài nguyên.

Trong kiến trúc của repo, CLI và MCP chỉ là hai adapter đầu vào. Workflow dùng chung nằm ở application layer. Hopper, Ghidra, IDA, browser, Android, firmware và JavaScript là các provider layer. Bên dưới nữa là contracts và domain semantics cho Evidence, comparison, session và error.[2]

Model không phải trung tâm của hệ thống. Evidence mới là trung tâm.

Một MCP server tốt không phải là một túi tool

Một MCP server ngây thơ thường làm việc này:

Ghidra có 40 thao tác
  → expose 40 tool qua MCP
  → để model tự đoán nên gọi cái nào

REA chọn hướng khác. Tài liệu tool design yêu cầu bắt đầu từ câu hỏi của analyst, không bắt đầu từ API của provider. Tool được chia theo intent như inspect, search, trace, compare, workflow và capture. Mỗi kết quả phải giữ target identity, source location, Evidence, confidence, limitation và phần coverage còn thiếu.[7]

Điều này tạo ra khác biệt lớn.

Một string xuất hiện trong binary không chứng minh feature đã chạy. Một call graph tĩnh không chứng minh nhánh đó được thực thi. Không tìm thấy một edge trong phạm vi đã quét cũng không chứng minh edge đó không tồn tại.

REA buộc các trạng thái này tách nhau:

Observed — tool đã đọc hoặc capture trực tiếp.
Derived — kết quả được tính từ observation.
Inferred — cách diễn giải có cơ sở nhưng chưa được quan sát trực tiếp.
Unknown — dữ liệu thiếu, provider không hỗ trợ hoặc phạm vi chưa đủ.

Đây không phải chuyện đặt tên cho đẹp. Nó là cách ngăn agent biến một chuỗi hợp lý thành một kết luận giả.

Bốn quyết định kiến trúc đáng copy

1. Route target trước, chọn tool sau

Skill đi kèm REA không bảo agent “hãy gọi thử vài tool”. Nó yêu cầu phân loại target trước.

ASAR hoặc thư mục Electron đi vào analyze_javascript_application. APK cần code analysis đi vào Android workflow. Native executable đi qua open_binary. HAR đã lưu dùng network-capture workflow. Browser đang mở và binary trên disk là hai authority khác nhau.[4]

Loại target quyết định workflow. Tên tool không quyết định workflow.

Đây cũng là pattern áp dụng được cho coding agent trong repository. Nếu agent chưa biết thay đổi thuộc subsystem nào, source of truth nằm ở đâu và validation nào có authority, thêm tool chỉ làm bề mặt sai lớn hơn. Repository harness giải quyết đúng bài toán đó ở phía source code; REA giải quyết nó ở phía shipped artifact.

2. Evidence là một object có identity

Tool tạo bằng chứng của REA không chỉ trả text. Nó trả một canonical Evidence record với normalized_result, evidence_id, provider identity và analysis profile. Record đó còn được giữ trong session để tool sau có thể trace, compare hoặc tạo view nhỏ hơn mà không chạy lại producer.[3]

Điều này giải quyết hai vấn đề cùng lúc.

Thứ nhất, agent có thể nói kết luận nào dựa trên record nào. Thứ hai, workflow không phải nhét toàn bộ kết quả lớn qua một MCP response mỗi lần.

REA đặt response trong giới hạn receive buffer 10 MiB của MCP client mà project pin. Nếu kết quả quá lớn, analysis đầy đủ vẫn nằm trong Evidence ledger; agent dùng inspect_analysis_view để lấy summary, section, module hoặc page ổn định, hoặc export bundle ra file.[3]

Đây là một bài học rất thực dụng cho mọi agent tool: đừng coi context window là database. Giữ dữ liệu đầy đủ ở nơi có identity và provenance. Chỉ đưa phần cần thiết vào lượt suy luận hiện tại.

3. Provider binding không tự đổi khi lỗi

Khi mở native target, REA chọn một provider cụ thể và giữ binding đó bất biến cho session. Nếu Ghidra timeout, REA không âm thầm chuyển sang Hopper rồi trộn hai loại kết quả như thể chúng tương đương.[3]

Một provider failure cần được báo với nguyên nhân và cách recovery riêng. Session phải đóng đúng tài nguyên nó sở hữu trước khi mở lại. Unknown vẫn là unknown.

Quy tắc này nghe có vẻ bảo thủ. Nhưng reverse engineering cần sự bảo thủ đó. Nếu nguồn bằng chứng đổi giữa chừng mà agent không biết, mọi so sánh sau đó đều mất nền.

4. Skill mang theo phương pháp, không chỉ hướng dẫn cài đặt

Repo đóng gói một skill reverse-engineer-anything dài hơn một trang quickstart rất nhiều. Skill hướng dẫn agent khi nào nên dùng REA, khi nào không nên dùng, cách chọn target, cách reuse Evidence, cách xử lý response bị truncate, khi nào static analysis chưa đủ và cách kết thúc investigation.[4]

Đây là điểm REA chạm trực tiếp vào harness engineering.

MCP cung cấp capability. Skill cung cấp operating procedure. Evidence contract cung cấp khả năng kiểm chứng. Session semantics giữ continuity.

Thiếu một trong bốn phần này, model vẫn có thể gọi tool. Nhưng nó chưa có một hệ thống làm việc đáng tin cậy.

Hai case study cho thấy Evidence quan trọng thế nào

DX-Ball: từ 63 byte assembly tới một function C kiểm chứng được

Case study DX-Ball bắt đầu từ một function 63 byte trong executable Windows i386. REA dùng Ghidra để lấy instruction view, caller và các byte constant liên quan tới phép tính sound pan.[5]

Từ evidence đó, reconstruction diễn giải phép tính thành:

pan = x * 1.5625 - 500.0
pan = pan * dxball_pan_scale

Nhưng project không dừng ở pseudocode “trông hợp lý”. Function dựng lại được kiểm tra với 3.205 input cases trên original x86 và tái tạo đủ 63 byte sau khi compile bằng toolchain lịch sử cùng relocation đã review.[5]

Đây là ranh giới giữa “AI đọc assembly” và “AI hỗ trợ reverse engineering”. Phần đầu tạo lời giải thích. Phần sau tạo một claim có thể bác bỏ.

Notion: biết rõ phần nào chưa chứng minh được

Case study clipboard của Notion còn hay hơn vì nó không cố kể một câu chuyện hoàn hảo.

REA phân tích preload JavaScript và quan sát được context bridge cùng lời gọi IPC động. Sau đó người phân tích đọc thêm packaged API object và main-process wrapper để nối channel notion:clipboard:write tới Electron clipboard.[6]

Feature trace theo API seed tạo 17 nodes và 16 edges nhưng vẫn chỉ có partial coverage. Trace theo channel literal không tìm thấy graph match. Tài liệu nói thẳng rằng không trace nào chứng minh một clipboard graph hoàn chỉnh, và source reading không phải một captured desktop execution.[6]

Một tool tốt không chỉ trả lời câu hỏi. Nó giữ nguyên giới hạn của câu trả lời.

Đây là phần nhiều AI demo bỏ qua. Demo thường tối ưu cho khoảnh khắc model tìm ra tên function. REA tối ưu cho câu hỏi khó hơn: evidence nào cho phép khẳng định điều gì?

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

Bề mặt hiện tại khá rộng:[1]

Native binaries: pseudocode, assembly, strings, symbols, calls và references qua Hopper, Ghidra hoặc IDA.
JavaScript và Electron: modules, imports, source maps, routes, IPC và native add-on relationships.
Websites: DOM, scripts, network observations, screenshots và runtime scenarios qua Chrome-family browser.
.NET assemblies: PE/CLI metadata, members, CIL và native dependencies ở chế độ static.
Android: manifest, classes, decompiled methods, resources, thiết bị, process, logs và file transfer qua các workflow khác nhau.
Firmware, ELF layout, recorded Linux crashes, EVM bytecode, HAR hoặc mitmproxy captures, Apple bundles và process behavior.

Danh sách dài này dễ tạo cảm giác “reverse engineer anything” theo nghĩa tuyệt đối. Không phải vậy.

Mỗi target có prerequisite và coverage khác nhau. Native analysis cần engine phù hợp. Android code analysis cần JADX và JDK. Browser analysis cần Chrome-family runtime. Một số workflow chỉ hỗ trợ host hoặc architecture cụ thể. REA giữ các khác biệt đó trong catalog và tool availability thay vì giả vờ mọi provider ngang nhau.[1][3]

Những giới hạn cần hiểu trước khi cài

REA chạy local, nhưng model provider vẫn thấy tool result

Binary và artifact được phân tích trên máy local. REA không upload app như một dịch vụ SaaS. Tuy nhiên coding agent nhận kết quả của tool, nên dữ liệu được gửi vào model vẫn chịu data policy của provider bạn chọn.[1]

Local analysis không đồng nghĩa với toàn bộ investigation nằm ngoài cloud.

Static analysis không phải runtime observation

Nếu REA tìm thấy một handler trong bundle, điều đó không chứng minh handler đã chạy trong session của người dùng. Nếu câu hỏi phụ thuộc vào behavior, skill yêu cầu dùng browser, Electron hoặc process capture workflow phù hợp thay vì nâng một static finding thành runtime claim.[4]

Native engine vẫn là dependency thật

REA không thay thế Hopper, Ghidra hoặc IDA. Nó cung cấp adapter, lifecycle, contract và workflow phía trên. Static JavaScript và .NET có thể chạy không cần native engine, nhưng deep native analysis vẫn cần một engine tương thích.[1]

Project thay đổi rất nhanh

Version 6.4.0 có nhiều breaking changes liên quan tới WebSocket result, resource ownership, saved graph provenance, semantic identity và capture comparison.[8] Repo yêu cầu Node.js 22.19+, 24.11+ hoặc 26+ ở thời điểm viết bài.[1]

Nếu dùng trong một workflow nghiêm túc, pin version. Đừng để latest âm thầm đổi contract của evidence bundle giữa hai investigation.

Reverse engineering vẫn cần quyền hợp pháp

REA là công cụ. Người dùng vẫn phải có quyền phân tích target, tuân thủ license và luật áp dụng. Repo cũng nêu rõ phạm vi là lawful research, analysis và reconstruction.[1]

Cách thử REA mà không tự lừa mình

Cài REA cho một agent được hỗ trợ:

npx rea-agents setup

Setup cho phép chọn agent, hiển thị các thay đổi dự kiến, backup config cũ rồi mới ghi sau khi được duyệt. REA hỗ trợ các client như Claude Code, Codex, Cursor, Gemini CLI, Grok Build và Hermes; MCP client khác có thể đăng ký thủ công.[1][8]

Đừng bắt đầu bằng một câu hỏi quá rộng như “reverse engineer app này”. Chọn một feature có ranh giới rõ:

Trong app này, thao tác Copy đi từ renderer qua IPC tới native clipboard như thế nào?
Hãy tách observation, inference và unknown, rồi dẫn Evidence cho từng kết luận.

Sau đó kiểm tra bốn thứ:

1. Target identity — đúng binary, package, version và digest chưa?

2. Evidence type — đây là static observation, runtime capture hay inference?

3. Coverage — tool đã kiểm tra toàn bộ phạm vi cần thiết hay mới có partial result?

4. Verification — nếu dựng lại behavior, có test hoặc differential check với artifact gốc không?

Nếu agent không trả lời được bốn câu này, vấn đề chưa chắc nằm ở model. Có thể workflow chưa buộc nó giữ bằng chứng.

Góc đáng học nhất từ REA

REA có rất nhiều tool. Nhưng số tool không phải lợi thế bền nhất.

Lợi thế nằm ở việc project coi reverse engineering như một hệ thống điều tra: target được định danh, provider được bind, observation được lưu, inference được gắn giới hạn, unknown không bị xóa, output lớn có nơi lưu, và cleanup có ownership.

Đó cũng là lý do repo này liên quan trực tiếp tới agent-ready repository. Một coding agent đáng tin không chỉ cần thêm capability. Nó cần một harness quyết định capability nào được dùng, evidence nào phải quay về, và claim nào chưa đủ điều kiện để nói.

Nếu muốn áp dụng bài học đó cho source repository của mình, bắt đầu từ cách audit repo cho agent-readiness và repository-harness. Sau đó nhìn lại từng MCP server đang dùng và hỏi một câu đơn giản:

Tool đang trả lời cho agent, hay đang trả bằng chứng để agent có thể chịu trách nhiệm cho câu trả lời?

FAQ

REA có thay thế Ghidra, Hopper hoặc IDA không?

Không. REA dùng các engine này làm provider cho native analysis, rồi chuẩn hóa lifecycle, session, Evidence và workflow ở phía trên.

REA có gửi binary lên cloud không?

REA phân tích target trên máy local. Kết quả được gửi cho coding agent, nên vẫn cần kiểm tra data policy của model provider.

Có thể dùng REA mà không cài native analysis engine không?

Có với static JavaScript, Electron và .NET. Deep native analysis cần Hopper, Ghidra hoặc IDA.

REA khác một MCP wrapper quanh decompiler ở đâu?

REA có Evidence identity, retained session records, explicit unknowns, immutable provider binding, cancellation, cleanup ownership và một skill định nghĩa operating procedure cho agent.

REA phù hợp nhất với tác vụ nào?

Khi câu trả lời phụ thuộc vào shipped artifact hoặc runtime behavior mà source repository hiện có không chứng minh được: binary, package, bundle, APK, firmware, website, capture hoặc khác biệt giữa hai version.

Nên kiểm tra gì trước khi dùng?

Quyền phân tích target, prerequisite của provider, ranh giới static/runtime, version contract và cách model provider xử lý tool result.

Sources