• REA (Reverse Engineer Anything)
  • 0. 요약
  • 1. REA?
  • 2. 리버스 엔지니어링?
    • 2.1 정의
    • 2.2 정적 분석과 동적 분석
    • 2.3 원래 용도
    • 2.4 엔진들이 만들어진 목적
  • 3. 전체 동작 흐름
    • 3.1 12단계 표
    • 3.2 요청 흐름
    • 3.3 대상 라우팅과 엔진 바인딩 분기
  • 4. MCP 서버 내부
    • 4.1 stdio 통신
    • 4.2 요청 처리 파이프라인
    • 4.3 도구 카테고리
    • 4.4 MCP prompt 6종
    • 4.5 Evidence와 원장, 결과 크기 제어
    • 4.6 세션 관리
  • 5. 엔진과 연결 방식
    • 5.1 엔진 요약
    • 5.2 연결 방식 5종
    • 5.3 연결 방식 정리
    • 5.4 엔진 선택 가이드
  • 6. 보안 모델
    • 6.1 호출 승인은 에이전트 클라이언트 몫
    • 6.2 annotation은 힌트일 뿐
    • 6.3 프롬프트 인젝션
  • 7. 한계와 비판
  • 8. REA MCP 설계 분석
    • 8.1 실사용 시 고려할 점
    • 8.2 MCP 설계 사례로서의 강점
    • 8.3 소프트웨어를 배포하는 쪽의 보안 함의
    • 8.4 클린룸과 EULA
  • 부록 A. 엔진별 상세
    • A.1 Ghidra
    • A.2 IDA Pro
    • A.3 Hopper Disassembler
    • A.4 JADX
    • A.5 JEB Decompiler
    • A.6 Apktool
    • A.7 Binwalk / Unblob
    • A.8 objdump / Rizin
  • 부록 B. 용어 정리
  • Reference

REA (Reverse Engineer Anything)

• 기준: GitHub main 커밋 7375ab6 + npm rea-agents 6.5.0, 확인일 2026-10-15
• 대상: github.com/morluto/rea, npm rea-agents
• 근거: 1차 출처 위주. 2차 출처(블로그/기사)는 문장마다 따로 표시.
  • 저장소 README, docs/, AGENTS.md, SECURITY.md, DISCLAIMER.md, CHANGELOG.md
  • npm 6.4.0 패키지(dist/, bridge/, skills/)
  • npm 6.5.0 패키지(skills/, dist/, 파일 목록)
  • GitHub main 브랜치 소스(커밋 7375ab6, 2026-10-14). main의 package.json 버전 표기는 6.4.0
• 버전 표기 규칙
  • “6.4.0”: 2026-10-11 릴리스 기준
  • “6.5.0부터 포함”: 6.5.0 패키지에 포함된 항목(skill 메타데이터 tool_count: 207, untrusted_content 서버 지침/표시, Frida 관련 파일)
  • “main”: main 7375ab6 소스 기준. 파일 경로:라인은 전부 main 기준
  • 6.4.0 대비 추가된 도구 37개의 개별 이름은 main 소스에서 확인. 6.5.0은 도구 수(207)가 같다는 것만 확인했고 개별 구성 동일성은 확인 못 함
• 표기: “확인 못 함” = 1차 출처에서 확인 못 한 항목, “(추측)” = 필자 추정, “(2차)” = 블로그/기사 출처
• 가격 등 변동 정보는 확인일(2026-10-14)과 출처를 병기

0. 요약

REA는 모델이 아니라 기존 리버스 엔지니어링 엔진(Hopper/Ghidra/IDA/JADX/JEB 등)을 LLM 에이전트에 하나의 MCP 도구 인터페이스로 묶어 주는 로컬 stdio MCP 서버 겸 CLI. 분석 판단은 연결된 에이전트가 담당하고 REA는 엔진 결과를 Evidence 레코드로 정규화해 반환.

핵심 수치

핵심 결론

1. REA는 로컬 stdio MCP 서버 겸 CLI.
   • 분석 판단: 연결된 LLM 에이전트 담당
   • REA: 기존 RE 엔진을 띄워 결과를 Evidence 레코드(내용 해시 ID + 엔진/프로파일 + 작업/인자 + 원본/정규화 결과 + 신뢰도 + 한계 + 연결 Evidence)로 정규화해 반환. 커버리지와 미확인 항목은 도구별 normalized_result 안의 값(4.5)
2. 도구 수는 6.4.0 기준 170개, 6.5.0/main 기준 207개.
   • 6.4.0: 번들 skill 메타데이터 tool_count: 170, 6.4.0 dist/contracts/toolEffects.js 키 170개
   • main: Frida/GDB/Rizin/Cutter/PCAP/SQLite/WASM 등 37개 추가. 6.5.0 skill tool_count도 207
   • 가이드형 MCP prompt 6개(4.4)
   • 도구 이름은 엔진과 무관하게 동일(open_binary, analyze_function, analyze_javascript_application, inspect_android_package 등)
3. 엔진 연결 방식은 크게 세 가지에 자체 파서와 Frida가 더해진 구조(5.2).
   • (a) 엔진 안에서 REA 브리지 스크립트 실행, Unix 소켓 + 세션 토큰으로 통신(Hopper, Ghidra headless)
   • (b) 엔진 쪽 MCP 서버에 REA가 MCP 클라이언트로 접속(IDA는 ida-pro-mcp, JEB는 사용자가 띄운 JEB MCP)
   • (c) 외부 CLI 프로세스를 소유/감독(JADX, Binwalk/Unblob, pwntools, TShark, adb 등)
   • JS/.NET 메타데이터(main에서는 Go/Rust 포함) 등 일부는 자체 TypeScript 파서로 처리
   • (d) Frida Node 바인딩 직접 로드 방식(6.4.0에는 없고 6.5.0부터 포함)
4. 설계 1순위는 컨텍스트 절약(“Agent tokens and context”가 최적화 우선순위 1번, AGENTS.md). 단 프로젝트 스스로 토큰 절감 효과는 주장하지 않는다(7).
   • summary 모드
   • 세션에 보관한 Evidence의 페이지 단위 조회
   • 응답이 클라이언트 수신 한도(기본 10 MiB)를 넘으면 결과를 자르지 않고 이어 읽기 요청 반환(4.1)
5. 샌드박스가 아님(SECURITY.md, docs/process-capture.md에 명시).
   • 런타임 캡처는 사용자 권한으로 대상을 실제 실행
   • REA 자체에는 호출별 승인이 없고 승인은 에이전트 클라이언트 몫(6.1)
   • setup은 MCP 등록과 skill을 사용자 전역 범위에 기록(6)

1. REA?

• 기존에 있던 도구들 잘 엮은 MCP 서버

2. 리버스 엔지니어링?

엔진별 “주 사용처”와 연혁은 부록 B 참고. 이 장은 개념/용도/법적 맥락/AI 시대 변화만 요약.

2.1 정의

완성된 결과물(소프트웨어에서는 실행 파일/바이너리)에서 출발해 설계와 동작 원리를 거꾸로 알아내는 작업. Wikipedia 정의는 “a process or method through which one attempts to understand through deductive reasoning how a previously made device, process, system, or piece of software accomplishes a task”. 기원은 상업/군사 목적의 하드웨어 분석(제2차 세계대전과 냉전기 사례 다수)이며 이후 소프트웨어로 확장.

쉽게 말하면:

• 소스 코드 없이 실행 파일만 보고 “이 버튼을 누르면 어떤 함수가 호출되고 어떤 파일이나 서버에 무엇을 보내는지” 알아내기
• 문서가 없는 파일 포맷/네트워크 프로토콜의 규칙을 실제 데이터와 통신을 관찰해 정리하기
• 악성코드 샘플이 감염 후 어떤 조건에서 무엇을 하는지 밝혀내기

2.2 정적 분석과 동적 분석

실무에서는 둘을 병행. 디스어셈블/디컴파일 등 세부 용어는 부록 D 참고.

2.3 원래 용도

2.4 엔진들이 만들어진 목적

정리: 확인한 범위에서 “다른 서비스를 베끼기 위해” 만들었다고 밝힌 엔진은 없다. 공개 목적이 명시된 Ghidra는 사이버보안/교육, IDA는 분석 효율 개선이 출발점. 다만 도구 자체는 용도 중립이라 무엇을 분석하고 결과를 어떻게 쓰는지는 사용자 책임.

3. 전체 동작 흐름

그림 읽는 법:

• 위 줄: 요청 방향
• 오른쪽 열: 대상별 엔진 분기
• 아래 줄: 결과 방향
• 에이전트 해석에서 “추가 질의”로 되돌아가는 루프와 별도의 검증 분기 존재

3.1 12단계 표

단계 번호는 참조용.

3.2 요청 흐름

아래 블록은 요청 흐름의 텍스트 구조도. 블록 안 “main” 표기는 6.4.0 대비 추가분을 뜻한다.

[사용자] ─ 자연어 요청 ─> [LLM 에이전트: Claude Code / Codex / Cursor / Gemini CLI ...]
                              │  (setup이 주입한 skill "reverse-engineer-anything"이 라우팅·절차를 지시)
                              │  MCP tools/call  (로컬 stdio, JSON-RPC)
                              ▼
┌──────────────────────── REA MCP 서버 (npx rea-agents@<고정버전> mcp) ────────────────────────┐
│ src/server     : 도구 등록, 입력 검증(Zod, SDK), 결과를 Evidence로 포장, 응답 예산 관리           │
│ src/application: CLI·MCP 공통 워크플로, BinarySession(대상 1개 ↔ 엔진 바인딩 1개, 자동 대체 없음)│
│                  EvidenceLedger(세션 보관 Evidence), Unknown 원장, 스냅샷 캐시                 │
│ src/process    : 소유 프로세스 그룹, 전용 임시 디렉터리, 기한, 정리(소유 증명된 것만 종료)      │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
  ├ 네이티브     → Hopper (Hopper 내부 Python 브리지, Unix 소켓 + 토큰)
  │               Ghidra (analyzeHeadless + HeadlessScript 브리지, 임시 프로젝트)
  │               IDA    (외부 ida-pro-mcp에 MCP 클라이언트로 접속, 읽기 전용)
  │               objdump / Rizin (사용자 제공, 에이전트가 직접 부르는 별도 도구, main. 엔진 폴백 아님)
  │               → 의사코드, 어셈블리, 문자열, 심볼, 호출자·피호출자, 참조, CFG
  ├ Android      → JADX(headless, JDK) / JEB(사용자 기동 JEB MCP) / Apktool / adb
  ├ JS·Electron  → 자체 파서(Babel AST, ASAR, source map). 모듈·import·IPC·라우트·네이티브 애드온
  ├ 기타 정적    → .NET(메타데이터·CIL), Go/Rust 빌드 메타데이터, WASM(WABT), EVM(EVMole),
  │               펌웨어(Binwalk/Unblob), SQLite, ELF 레이아웃·코어덤프(pwntools/pwndbg),
  │               PCAP(TShark), 로직 신호(sigrok), PE 리소스, Apple 번들·plist
  └ 런타임 관찰  → PTY 프로세스 캡처(node-pty), macOS 네이티브 UI·LLDB 호출 관찰,
                  웹/Electron은 CDP(playwright-core)·V8 Inspector, HAR/mitmproxy 캡처
                              │
                              ▼
            Evidence(evidence_id + provider/analysis_profile + normalized_result + confidence + limitations)
                              │
                              ▼
         에이전트가 해석 → 설명 / 구현 / 원본과 비교 테스트 (compare_*, verify_reconstruction)

참고:

• 입력 검증
  • 기본 경로: Zod 계약 스키마를 SDK가 Standard Schema로 검사
  • 예외: 일부 도구(inspect_analysis_view, 조사 도구, PCAP, HAR 캡처)는 SDK 검증을 통과시키고 애플리케이션이 직접 검증(src/server/toolRegistrationOptions.ts:9-17, applicationValidatedInputSchema)
  • AJV: HAR 스키마 검증(src/browser/history/HarSchema.ts:2-16)에만 사용하고 도구 입력 검증에는 미사용. 도구 스키마 관련 AJV 사용은 테스트(src/contracts/toolInputReferences.test.ts:1-2)에서만
• Evidence: 위 괄호는 봉투 필드 일부. 커버리지(coverage), 면별 관찰 여부(facet_availability), 남은 미확인 항목(residual_unknowns)은 봉투 최상위가 아니라 도구별 normalized_result 안의 값(4.5).
• 응답 예산: 비교값은 최대 응답 바이트 - 1,024이고 Node 단일 문자열 길이 한도도 별도 제약(4.1).
• objdump/Rizin: 깊은 분석 레지스트리 후보는 Hopper/Ghidra/IDA 3개뿐(src/composition/binary.ts:29-30). objdump/Rizin은 실패 시 자동으로 넘어가는 대체 경로가 아니라 에이전트가 명시적으로 부르는 별도 도구.
• 블록 안 WASM(WABT), SQLite, PCAP(TShark), 로직 신호(sigrok), Go/Rust 메타데이터는 6.4.0에 없는 범주.

근거: docs/architecture.mermaid, README “What you can analyze”, npm 6.4.0 dist/ 디렉터리 구성(hopper/, ghidra/, ida/, jeb/, android/, apktool/, adb/, javascript/, dotnet/, browser/, inspector/, firmware/, evm/, process/ 등).

3.3 대상 라우팅과 엔진 바인딩 분기

skill의 대상별 첫 도구 라우팅(SKILL.md)

• ASAR/JS: analyze_javascript_application
• APK 코드: inspect_android_package
• .NET: inspect_managed_artifact
• 네이티브: open_binary 후 필요한 분석 도구 등

대상별 엔진 분기(3.1의 4~7단계 상세)

근거: 3.2/5.2, docs/architecture.mermaid:28-48, docs/android-analysis.md:1-13, docs/jeb-analysis.md:3-11, docs/reverse-engineering-tools.md:1-14.

엔진 바인딩 규칙(open_binary)

• provider_id: 특정 엔진 ID 또는 auto. 환경변수 REA_ANALYSIS_PROVIDER로도 지정
• auto는 사용 가능 후보가 정확히 1개일 때만 선택. 2개 이상이면 ambiguous 오류, 0개면 미바인딩
• 성공하면 엔진/버전/선택 근거/분석 프로파일 고정
• 런타임 실패가 나도 다른 엔진으로 자동 전환하지 않는다(“no failure fallback”)
• 엔진 미설치는 흐름 분기가 아니라 도구 가용성 문제(binary_session의 tool_availability)
• 6.4.0에서 auto 선택 규칙이 main과 동일한지는 확인 못 함(main 소스만 확인)

4. MCP 서버 내부

4.1 stdio 통신

사실 관계

• stdio 전용. dist/main.js가 @modelcontextprotocol/server/stdio의 serveStdio 사용.
  • 서버 쪽 HTTP transport는 6.4.0 패키지에 없다.
  • main도 동일(src/main.ts:7,26에서 serveStdio만 사용, src/에 HTTP 서버 transport 부재).
• StreamableHTTPClientTransport는 클라이언트로서 외부 엔진 MCP(IDA의 ida-pro-mcp, JEB MCP)에 접속할 때만 사용(dist/ida/IdaMcpConnection.js, dist/jeb/JebMcpConnection.js).
  • 단 IDA는 HTTP만이 아니다. 등록 방식별로 갈린다(src/ida/IdaMcpConnection.ts:402-422, docs/ida-provider.md).
    • legacy attached 등록/headless(idalib-mcp --stdio) 등록: REA가 등록된 명령을 StdioClientTransport로 실행
    • url 등록/native 플러그인: HTTP
  • JEB는 HTTP만(src/jeb/JebMcpConnection.ts).

• 등록 형태(MCP Registry 이름 io.github.morluto/rea). 아래는 6.4.0 시점 예시이며 setup은 실행한 버전으로 고정해 기록(docs/installation.md MCP Registry):

    { "mcpServers": { "rea": { "command": "npx", "args": ["-y", "rea-agents@6.4.0", "mcp"] } } }
  

• 응답 예산: 결과(text + structuredContent + JSON-RPC 봉투)가 클라이언트 수신 한도(기본 10 MiB) 안에 들어가도록 생성. 넘으면 결과를 자르지 않고 원장 참조와 이어 읽기 요청으로 대체(4.5). 클라이언트 버퍼가 더 크면 REA_MCP_MAX_RESPONSE_BYTES로 상향 가능(docs/mcp-contracts.md).
• 서버 instructions: MCP initialize 때 대상 유무에 따라 짧은 사용 지침 2종을 전달. 6.5.0부터 신뢰 불가 콘텐츠 지침이 추가(6.3).

쉽게 말하면: “stdio로만 통신한다”는 뜻

• stdio(표준 입출력): 모든 프로세스가 시작 시점부터 갖는 세 개의 기본 스트림.
  • stdin: 입력 수신
  • stdout: 결과 출력
  • stderr: 로그/오류 출력
  • 터미널에서 cat file | grep foo처럼 파이프로 프로그램을 잇는 것도 이 스트림을 사용.
• MCP의 stdio transport(MCP 사양 Transports):
  • 클라이언트(Claude Code 등)가 MCP 서버를 자기 자식 프로세스로 직접 실행
  • 클라이언트가 서버의 stdin에 JSON-RPC 요청을 한 줄씩 쓰고 서버가 stdout에 쓴 응답을 한 줄씩 읽는다
  • 메시지는 줄바꿈으로 구분. 서버는 stdout에 MCP 메시지 외에는 아무것도 쓰면 안 된다(로그는 stderr)
  • 종료 시 클라이언트가 stdin을 닫고 프로세스를 종료
  • REA 등록 설정의 "command": "npx", "args": [..., "mcp"]가 바로 “이 명령으로 자식 프로세스를 띄워라”라는 뜻

[Claude Code 프로세스]
   │ (1) npx rea-agents@6.4.0 mcp 실행 → 자식 프로세스 생성
   │
   ├── stdin  ──>  {"jsonrpc":"2.0","id":7,"method":"tools/call",...}\n   ──> [REA 서버 프로세스]
   └── stdout <──  {"jsonrpc":"2.0","id":7,"result":{...}}\n             <──      │
                                                       stderr(로그) <──────────────┘
   (네트워크 포트 없음. 두 프로세스 사이의 파이프만 존재)

Streamable HTTP transport와 비교

근거: MCP 사양 Transports(2025-06-18). 사양은 “Clients SHOULD support stdio whenever possible”이라고 적는다.

• 한 줄 요약
  • stdio: 서버를 실행한 클라이언트 프로세스 하나만 파이프로 통신. 외부에서 접속할 주소나 포트가 없다.
  • HTTP: 엔드포인트 주소를 아는 누구나 요청을 보낼 수 있다. 그래서 인증과 Origin 검증이 필요.
• REA에서의 의미
  • 원격 서버로 띄워 여러 사람이 공유하는 구성은 공식 미지원
  • 노출면이 작다고 “안전하다”는 뜻은 아니다. 서버가 클라이언트와 같은 OS 사용자 권한으로 돌기 때문에 그 사용자가 할 수 있는 일은 REA 도구도 할 수 있다(6장 샌드박스 항목)

4.2 요청 처리 파이프라인

그림은 3장 그림의 “REA MCP 서버” 박스를 펼친 것(main 7375ab6).

tools/call 요청 하나는 다음 순서로 처리된다.

1. 입력 검증: 도구 이름으로 등록된 핸들러를 찾고 입력 스키마로 인자를 검사한다. 통과하지 못하면 핸들러를 실행하지 않는다.
2. 세션 입장: 진행 중인 대상 전환(open/close)이 끝날 때까지 기다린다. 모든 도구가 거친다.
3. 실행: 경로를 직접 받는 도구(JS/Electron, Android, .NET 등)는 해당 서비스가 바로 실행한다. 바인딩 도구(analyze_function, xrefs 등)는 활성 대상과 엔진을 확인한 뒤 엔진을 호출한다(첫 호출 때 엔진 기동). 같은 대상과 프로파일이면 분석 스냅샷을 재사용한다.
4. Evidence 생성과 원장 기록: 결과를 Evidence 레코드로 정규화하고 내용 해시 ID를 붙여 세션 원장에 기록한다. 같은 내용이면 중복으로 처리한다.
5. 응답 구성: 응답 크기 상한 안에 들어가는지 확인한다. 넘으면 결과를 자르지 않고 원장 참조와 이어 읽기 요청으로 대체한다(4.5). 분석 대상에서 나온 콘텐츠에는 신뢰 불가 표시를 붙인다(6.3).

근거: 저장소 docs/mcp-contracts.md, src/server/.

4.3 도구 카테고리

docs/mcp-contracts.md Identity and discovery 기준:

• tools/list는 지금 쓸 수 없는 도구까지 포함한 전체 카탈로그를 항상 반환
• 대상을 열거나 닫아도 list_changed 알림을 보내지 않는다
• 실제 호출 가능 여부는 binary_session을 {}로 호출해 result.tool_availability(가용성, 이유, 해결 방법)로 확인

도구 개수 확인 방법:

• 도구 목록의 단일 출처: src/contracts/toolContracts.ts:39의 TOOL_CONTRACTS(카테고리별 계약 배열 36개를 이어 붙인 것). 서버는 src/server/createServer.ts에서 이를 카테고리별 register*Tools로 등록.
• 도구별 효과(effects) 정의: src/contracts/toolEffects.ts:55의 TOOL_EFFECTS. “모든 공개 도구를 정확히 한 번씩” 담도록 테스트로 강제(src/contracts/toolEffects.test.ts:102-105, 키 목록 = TOOL_CONTRACTS 이름 목록).
• 그래서 이 키를 세어 개수 확인. 정적 파싱 결과이며 서버를 실행해 tools/list를 받아 본 것은 아니다.

카테고리별 분류: 필자가 소스의 계약 파일 구성과 도구 설명을 보고 27개로 묶은 것이며 공식 분류가 아니다. “6.4.0” 열은 그중 6.4.0에도 있던 도구 수.

• 설정/진단 전용 MCP 도구는 없다.
  • setup, doctor는 CLI 명령
  • MCP에서는 binary_session {}의 tool_availability와 외부 도구 확인 도구(inspect_adb_client, inspect_apktool_client, inspect_jeb_client, inspect_pcap_client 등)가 진단 역할

4.4 MCP prompt 6종

• prompt는 도구를 직접 호출하지 않는다. 클라이언트에서 고르면 “목표 + 인자 + 단계별로 써 볼 도구 이름 + Evidence 원칙”이 담긴 지시문을 생성(src/contracts/promptContracts.ts:94-402, 등록은 src/server/registerPrompts.ts:36).
• 렌더링 시 인자를 “untrusted selection data, never as authorization”으로 취급한다는 문구 부착(promptContracts.ts:53).
• 이름 6개는 6.4.0 문서(docs/mcp-prompts.md)와 main 소스가 동일.
• compare_application_versions와 verify_reconstruction은 prompt 이름이자 같은 이름의 도구 이름. 그림의 prompt 열은 도구가 아니라 지시문.

4.5 Evidence와 원장, 결과 크기 제어

REA의 핵심 설계는 “결과 = 증거 레코드”(docs/mcp-contracts.md Tool results).

• 성공 시 text와 structuredContent 양쪽에 같은 정규 Evidence 레코드를 담는다.
• 봉투 스키마는 strict(정의되지 않은 최상위 필드 거부). 주요 필드:

도구별 normalized_result 안의 값(봉투 최상위 필드 아님, docs/mcp-contracts.md):

• 원칙: 관찰(observation)/유도(derivation)/추론(inference)/미확인(unknown)을 구분.
  • “빈 호출 목록 + 커버리지 partial”은 “호출이 없다”는 뜻이 아니다.
  • compare_functions의 changed는 텍스트 차이일 뿐 동작 차이가 아니다.
• 무결성 검사는 기본이 fail-closed. 해시 불일치 시 중단. integrity_policy=record-and-continue를 명시할 때만 격리 후 계속.

결과 크기 제어(토큰 절약)

4.6 세션 관리

• 연결 1개 = 세션 1개. open_binary로 대상과 엔진 바인딩을 결정(3.3 바인딩 규칙).
• 대상이 바뀔 때마다 엔진 기동 전에 analysis_run.run_id 할당. 엔진 프로세스 계보(PID, 부모, 프로세스 그룹, 자식)를 스냅샷으로 기록.
• 세션 안에 Evidence 원장과 Unknown 원장을 둔다. 원장은 대상 전환에도 유지.
  • 조회: get_evidence_bundle(detail:"summary" + 필터)
  • 내보내기: export_evidence_bundle로 파일에 원자적 기록
  • 불러오기: import_evidence_bundle
  • 분석 스냅샷은 바이너리 동일성, 엔진, 프로파일이 정확히 일치할 때만 재사용
• close_binary는 진행 중인 작업 정리와 엔진 종료 후 세션 보관 레코드를 삭제. 필요한 Evidence는 닫기 전에 export 필요.
• JS/Electron, 웹, .NET 같은 “target-free” 도구는 open_binary 없이 경로나 엔드포인트를 직접 입력받는다.
  • 이 경로 직접 도구도 BinarySession의 세션 입장 관문(대상 전환 대기, 취소 확인)은 거친다. 건너뛰는 것은 활성 대상/엔진 바인딩 검사와 스냅샷 캐시뿐.

5. 엔진과 연결 방식

5.1 엔진 요약

상용 도구(IDA, Hopper, JEB)는 라이선스 직접 확보 필요(REA README 명시). REA는 도구 라이선스/키/활성화 권한을 제공하지 않는다. 체험판/데모도 벤더 약관(사용자 수, 기능, 자동화, 출력 공유 제한)을 따른다.⁵

5.2 연결 방식 5종

REA가 MCP 클라이언트가 되는 엔진은 IDA와 JEB뿐이다. Hopper/Ghidra는 기동 기한이 클라이언트 기본 호출 기한(60초)보다 길어 첫 질의가 클라이언트에서 먼저 끊길 수 있다.

엔진별 브리지 상세:

브리지 토큰은 프로세스 인자나 환경변수가 아니라 비공개 세션 디스크립터로 전달(SECURITY.md).

5.3 연결 방식 정리

“Hopper 안에서 브리지 스크립트를 실행”

• Hopper: macOS/Linux용 상용 디스어셈블러/디컴파일러 GUI 앱(상세는 부록 B.3). 사람이 창을 보며 함수 목록, 의사코드, 참조를 탐색하는 도구.
• 문제: Hopper에는 외부 프로그램이 네트워크나 소켓으로 접속해 “이 함수 의사코드 줘”라고 요청할 수 있는 원격 API가 없다. 대신 Hopper 안에서 실행되는 Python 스크립트는 Hopper 내부 객체(문서, 세그먼트, 함수)에 접근할 수 있다.
• 해결: REA는 Hopper 기동 시 중계 스크립트(bridge) bridge/hopper_bridge.py를 Hopper 내장 Python으로 실행.
  • 이 스크립트가 Hopper 프로세스 내부에서 Unix 소켓 서버를 연다.
  • 외부의 REA는 그 소켓으로 요청을 보낸다.
  • 브리지가 요청을 받아 Hopper 내부 API를 호출하고 결과를 소켓으로 반환.

[REA MCP 서버(Node)]                                  [Hopper 프로세스]
  (1) 세션 디렉터리에 bootstrap.py 작성(0600)            ┌──────────────────────────────┐
      REA_SOCKET=<소켓 경로>, REA_TOKEN=<무작위 토큰>    │ 내장 Python 스레드             │
  (2) Hopper 실행: ... -Y bootstrap.py --executable <대상>│  bootstrap.py → hopper_bridge.py│
                                                        │  Unix 소켓 열기(0600, 1클라이언트)│
  (3) 소켓 접속 ───── 한 줄 JSON {id, token, method, params} ──>  토큰 검사(hmac 비교)    │
                <──── {id, result} / 진행 이벤트 ──────  Hopper API 호출(이 스레드에서만) │
                                                        └──────────────────────────────┘

근거:

• 부트스트랩 생성: src/hopper/BridgeLauncher.ts:343-356(세션 디렉터리의 bootstrap.py, 권한 0600, 실패 시 삭제), :397-411(REA_SOCKET, REA_TOKEN, REA_RUN_ID 등을 기록한 뒤 hopper_bridge.py를 exec).
• Hopper 실행 인자: src/hopper/BridgeLauncher.ts:206-215(-analysis -Y <bootstrap> --executable|--database <대상>). 브리지 docstring(bridge/hopper_bridge.py:1-6)은 이를 Hopper의 -python 실행 옵션으로 지칭. Y와 -python이 같은 옵션인지는 Hopper 공식 문서로 확인 못 함.
• 소켓 서버: bridge/hopper_bridge.py:1143-1166(AF_UNIX 소켓, chmod 0o600, listen(1)).
• 요청 검증: bridge/hopper_bridge.py:1044-1057(요청 키가 정확히 id, token, method, params인지, 토큰을 hmac.compare_digest로 비교).
• 스레드 제약: bridge/hopper_bridge.py:1169-1173. Hopper 객체는 전용 Python 스레드에 묶여 있어 다른 스레드로 옮기면 교착될 수 있다.
• 토큰을 명령줄 인자나 환경변수로 넘기지 않는 이유: 같은 머신의 다른 프로세스가 ps 등으로 명령줄을 볼 수 있기 때문(추측: 일반적인 이유. 프로젝트 문서는 “private session descriptor”로 전달한다고만 적는다, SECURITY.md).

“headless 모드”

• headless: GUI 창을 띄우지 않고 명령줄에서 엔진의 분석 기능만 실행하는 방식(“head” = 화면).
• Ghidra 예: Ghidra는 원래 GUI 앱이지만 support/analyzeHeadless 스크립트를 함께 제공.
  • 형식: analyzeHeadless <프로젝트 위치> <프로젝트 이름> -import <파일> [-postScript <스크립트>] ...
  • 동작: 파일 임포트 → 자동 분석 → 지정 스크립트 실행 → 종료
  • 출처: Ghidra 배포본의 support/analyzeHeadlessREADME.html, 웹 사본 ghidradocs.com 12.0(비공식 미러)
• REA가 실제로 넘기는 인자(src/ghidra/GhidraLauncher.ts:606-718): <임시 프로젝트 루트> rea-project -import <대상> -readOnly -deleteProject -log ... -scriptPath <브리지 디렉터리> [-preScript ...] -postScript ReaGhidraNoReturnFix.java -postScript ReaGhidraBridge.java <세션 디스크립터>
  • readOnly/deleteProject: 사용자 프로젝트를 남기거나 변경하지 않음을 보장
  • 마지막 postScript로 실행된 브리지가 분석이 끝난 프로그램을 유지한 채 REA의 요청을 소켓으로 수신
• 자동화에 필요한 이유:
  1. 에이전트는 창을 클릭할 수 없다. 화면 없이 명령으로 시작/종료할 수 있어야 한다.
  2. 서버/CI/원격 셸처럼 디스플레이가 없는 환경에서도 실행되어야 한다.
  3. 매번 같은 인자로 실행하면 결과 재현이 쉽다. 종료 후 임시 프로젝트를 지워 흔적을 남기지 않는다.
  4. 사용자가 열어 둔 GUI 작업 상태와 섞이지 않는다.
     • JADX도 같은 이유로 headless로 실행(README).

5.4 엔진 선택 가이드

REA 관점의 실무 팁: 상용 엔진 없이도 Ghidra + JADX + Apktool + Binwalk/Unblob + objdump/Rizin 조합으로 대부분의 영역을 오픈소스만으로 커버 가능.

6. 보안 모델

6.1 호출 승인은 에이전트 클라이언트 몫

MCP의 역할 분담

• REA가 하지 않는 것: REA 서버는 호출마다 사용자에게 묻거나 승인 토큰을 요구하지 않는다.
  • 요청이 오면 바로 실행(“REA does not require permission grants or per-call approval flags… MCP clients control their own confirmation UI”, docs/mcp-contracts.md:472-474)
  • 예외는 setup(계획을 보여 주고 확인 요청)뿐

6.2 annotation은 힌트일 뿐

• REA는 도구마다 효과를 선언하고(src/contracts/toolEffects.ts:55) 여기서 MCP 힌트를 기계적으로 계산(:714-737).
• destructiveHint = true 조건(하나라도 해당 시): 데이터 폐기 가능(mayDiscardData), REA가 소유하지 않은 코드 실행(executesForeignCode), Android 기기 변경(mutatesDevice)
• 필자가 toolEffects.ts를 정적으로 파싱한 결과 main 207개 중 31개가 destructiveHint: true(예: capture_process_scenario, load_frida_script, gdb_console, cutter_command, install_adb_package, close_binary, set_comment).
• 하지만 MCP 사양상 annotation은 서버가 스스로 붙이는 설명이라 클라이언트가 믿거나 따를 의무가 없다(문서도 “hints, not authorization controls”라고 명시, docs/mcp-contracts.md:476-477). MCP 사양 2025-11-25 Tools: “clients MUST consider tool annotations to be untrusted unless they come from trusted servers”.
• 힌트가 위험을 전부 담지도 않는다. 예: start_frida_session은 프로세스를 spawn하고 대상을 바꿀 수 있지만(mutatesTarget, launchesProcess) 위 세 조건에 해당하지 않아 destructiveHint는 false(toolEffects.ts:204-210).

Claude Code에서 통제하는 방법(일반론, 출처: Claude Code permissions, Claude Code MCP)

• 권한 규칙: settings 파일의 permissions.allow / ask / deny.
  • MCP 도구 이름 형식은 mcp__<서버 이름>__<도구 이름>. setup이 등록하는 서버 이름이 rea이므로 mcp__rea__capture_process_scenario처럼 표기.
  • mcp__rea 또는 mcp__rea__*는 REA 도구 전체에 매칭
  • 평가 순서는 deny → ask → allow이고 먼저 매칭된 규칙이 결정. 좁은 allow로 넓은 deny를 무효화할 수 없다.
• 권한 모드: defaultMode로 시작 모드 지정.

• MCP 인자 단위 제한은 settings로 불가: settings 파일의 mcp__ 규칙에 괄호 인자를 붙이면 무시된다. 인자까지 걸러야 하면 -disallowedTools 또는 PreToolUse hook 사용. hook의 차단은 allow 규칙보다 우선.
• 항상 묻게 만드는 서버 측 표시: 서버가 tools/list에 _meta["anthropic/requiresUserInteraction"]: true를 넣으면 Claude Code는 auto/bypass 모드에서도 매번 질문.
  • REA 소스(main src/)에는 이 표시가 없다.
  • Claude Code 문서에서 readOnlyHint/destructiveHint를 승인 판단에 쓴다는 설명은 확인 못 함.
• 설정 예시(필자 제안. 실제 적용 전 조직 정책에 맞게 조정): REA는 분석 전용 프로필(CLAUDE_CONFIG_DIR=~/.claude-rea, 부록 A)에서만 쓰고 그 프로필의 settings에 아래처럼 둔다. "mcp__rea__*"를 allow에 넣으면 프로세스 실행/기기 변경 도구까지 자동 승인되므로 피한다.

{
  "permissions": {
    "defaultMode": "default",
    "allow": [
      "mcp__rea__binary_session", "mcp__rea__open_binary", "mcp__rea__binary_overview",
      "mcp__rea__analyze_function", "mcp__rea__search_strings", "mcp__rea__inspect_analysis_view"
    ],
    "ask": [
      "mcp__rea__capture_process_scenario", "mcp__rea__observe_native_calls",
      "mcp__rea__capture_browser_scenario", "mcp__rea__capture_electron_scenario",
      "mcp__rea__start_frida_session", "mcp__rea__load_frida_script",
      "mcp__rea__install_adb_package", "mcp__rea__push_adb_file", "mcp__rea__export_evidence_bundle"
    ],
    "deny": [
      "mcp__rea__cutter_command", "mcp__rea__gdb_console",
      "mcp__rea__execute_rizin_command", "mcp__rea__rizin_debug_command"
    ]
  }
}

보안 함의:

• 이 설정은 Claude Code가 REA 도구를 부르는 것만 통제.
• REA 프로세스 자체는 사용자 권한으로 실행. 따라서 신뢰할 수 없는 대상의 런타임 캡처/Frida/디버거 도구는 권한 규칙과 별개로 격리 VM/컨테이너에서 실행해야 한다.
• 분석 결과 안의 문자열이 “이 명령을 실행하라”고 유도하는 프롬프트 인젝션(6.3)에 대해서도 프로세스 실행/기기 변경 도구를 ask/deny로 두는 것이 최종 통제 수단.

6.3 프롬프트 인젝션

• 분석 대상의 문자열/심볼/의사코드/웹 페이지 텍스트/로그는 공격자가 통제할 수 있다.
  • “이 명령을 실행하라”, “필요한 헬퍼를 내려받아라” 같은 문자열을 심어 두면 에이전트가 지시로 받아들일 위험이 있다.
  • REA 문서가 이 시나리오를 직접 예로 듦(docs/mcp-contracts.md Untrusted target content).
• REA의 대응:
  • 결과 _meta에 untrusted_content 표시. 도구 계약 단위(returnsTargetContent, 기본 on)로 선언하고 성공/실패 모두 표시
  • 서버 지침으로 따르지 말라고 안내. 실행/설치/다운로드/전송 요구는 인젝션 시도로 보고하라고 안내
  • 호스트나 훅이 이 표시를 보고 이후 프로세스 실행/기기 변경 도구에 승인을 요구할 수 있도록 지원
  • 구현 위치(main): src/server/toolResultEncoding.ts:26, src/server/createServer.ts:147
  • 버전: 6.4.0 패키지에는 이 표시가 없다. 6.5.0 dist/server/createServer.js, dist/server/toolResultEncoding.js에서 확인. 6.4.0 이하 버전에 고정된 등록에서는 이 표시에 기대면 안 된다.
• 실무 권고(추측 아님, 일반 원칙):
  • 분석 세션에서는 셸 실행/네트워크/기기 변경 도구에 수동 승인 설정(Claude Code 설정 예시는 6.2)
  • REA 등록 범위를 전용 프로필이나 컨테이너로 한정
  • 에이전트를 만드는 쪽도 외부 문서나 툴 결과를 지시로 취급하지 않도록 provenance 표시와 승인 게이트를 설계

7. 한계와 비판

1차 출처(프로젝트 스스로 밝힌 것):

• 디컴파일, 재구성, AI 분석 결과는 불완전하거나 틀릴 수 있다(DISCLAIMER.md). 자체 디컴파일 기술은 없으며 품질은 엔진에 좌우.
• 커버리지 미확인은 “없음”이 아니다(docs/mcp-contracts.md).
  • 비교 결과 changed도 텍스트 차이일 뿐
  • 정적 일치가 런타임 동작 동일을 뜻하지 않는다
• 난독화된 managed 코드 비교, 간접 호출, 아키텍처 확장은 로드맵 과제(docs/roadmap.md).
• Windows: Ghidra 실험적 지원(읽기 전용), PTY 캡처 미지원.
• 대형 바이너리: Ghidra 콜드 스타트가 클라이언트 60초 기한을 넘길 수 있다.
• 토큰 절감 효과는 미입증(프로젝트 실험 기록 experiments/analysis-efficiency/README.md:49):
  • summary/선택 뷰로 응답 바이트는 크게 감소
  • 실제 Codex 시행에서는 모델 입력 토큰이 오히려 늘거나 시간이 엇갈려 “model-token savings are not claimed”라고 기록
  • 작은 함수에서는 선택 응답 4번이 전체 dossier 1번보다 바이트가 많았던 사례도 존재
• 스키마 크기: 전체 카탈로그가 일부 클라이언트(Kimi/Moonshot, WorkBuddy, pi-web-ui, strict-depth 클라이언트)의 크기/깊이 제한에 걸려 compact 프로파일을 별도로 둔다(docs/mcp-contracts.md:675-721).

2차 출처 비판:

• macOS Preview 재구축 비교는 제작자가 아니라 YouTuber Nick Saraev가 한 비공식 시연.
  • REA 없는 에이전트가 먼저 끝났다. REA 쪽이 Preview에 더 가까워 보였다는 것은 진행자의 주관적 관찰
  • 반복 실행/기능 체크리스트/동일 프롬프트/비용 기록/독립 평가자가 모두 없다(joaoqueiros.com 분석)
  • mindstudio.ai는 REA 결과물이 “a bit laggier”했다고 전한다
• REA는 새로운 RE 기술이 아니라 기존 도구의 커넥터이며 이 능력은 결국 범용 코딩 에이전트에 흡수될 것이라는 전망(mindstudio.ai).
• 스타 수가 실제 사용을 크게 웃돈다는 지적(ringozzt, 10-11 시점 npm 주간 약 1.3k). 다만 npm API로는 10-12 하루에만 103,109회가 나와 이후 사용이 급증한 것으로 보인다.
• 기사(Decrypt)의 우려:
  • 기기에서 돌아가는 모든 SW를 에이전트가 읽을 수 있게 되어 “가장 오래된 복제 방지책(비용)”이 약해진다
  • 복제와 해적판이 쉬워지고 보안 결함이 발견되지 않은 채 남기 어려워진다
  • Activision의 AI 디컴파일 영상 삭제 요청, Bethesda의 경고장 사례도 함께 언급(REA와 직접 관련 여부는 기사에 언급되지 않는다)
• 환각/오탐에 대한 정량 평가(정확도 벤치마크)는 확인 못 함. kingy.ai의 독립 재현(14개 테스트 통과)이 있다는 언급이 ringozzt 보고서에 있으나 원문은 확인 못 함. 외부 사용자 연구(NDSS 2026)에서는 LLM 보조 RE 세션의 약 20%가 거짓 가설을 추적(8.3).

8. REA MCP 설계 분석

8.1 실사용 시 고려할 점

평가 방법

• REA의 측정 원칙(AGENTS.md): src/evaluation/(에이전트 세션 기록 채점)과 experiments/analysis-efficiency/에서 다음을 지킨다.
  • 토큰, 경과 시간, CPU, 최대 메모리를 콜드/웜으로 나눠 측정
  • 추정치에는 표시 부착
  • 측정하지 않은 비용은 “측정 안 함”으로 기재
  • “Count the whole task, including schemas, extra calls and retries”, “Fewer bytes alone do not establish fewer tokens”(AGENTS.md Performance)
• 도구 노출 방식을 바꿀 때(docs/tool-design.md): “넓은 / 직접 / 부정”(broad/direct/negative) 과제를 실제 호스트/모델로 돌려 도구 선택/인자/오류/재시도/결과를 기록하도록 요구. “스키마가 유효하다”는 사실이 “모델이 도구를 잘 고른다”를 보장하지 않는다고 명시(“Schema validity and keyword heuristics do not establish successful tool selection”).
• MCP/에이전트 평가 일반에도 그대로 적용 가능. 응답 바이트가 아니라 모델 입력 토큰과 과제 성공률로 비교하고 반복 측정해야 한다.
• 디컴파일/재구성 결과의 정확도는 독립 정량 평가가 없으므로 결과 검증 단계(compare_*, verify_reconstruction)를 생략하지 않는 운영이 필요(추측: 운영 권고).

비용

운영 주의

• 등록 범위: setup은 사용자 전역에 등록. 분석 전용 프로필이나 별도 계정/컨테이너로 한정(6, 부록 A).
• 버전 고정: 등록은 설치 버전에 고정. 6.4.0에 고정된 등록은 untrusted_content 표시와 Frida 등 추가 도구가 없다. 업그레이드는 명시 행위로 다시 setup.
• 타임아웃: 큰 바이너리는 REA_GHIDRA_STARTUP_TIMEOUT_MS/REA_HOPPER_STARTUP_TIMEOUT_MS 연장과 클라이언트 호출 기한 조정 필요.
• 격리: 런타임 캡처/Frida/디버거는 격리 VM/컨테이너에서만.
• 데이터 경계: 결과가 외부 모델 제공사로 전송되므로 조직의 데이터 정책을 사전에 확인.
• Evidence 보존: close_binary가 세션 원장을 삭제하므로 필요한 Evidence는 먼저 export_evidence_bundle.
• 설치 출처: 유사 이름 저장소/zip 배포에 주의(README:28-33, 1.2).

8.2 MCP 설계 사례로서의 강점

대조에 쓴 외부 원칙(1차 자료, 원문 확인)

강점 표

강점 표에 없는 설계 패턴(docs/tool-design.md 등):

외부 원칙 대조 요약(일치 / 차이 / REA가 더 나아간 점)

다른 리버스 엔지니어링 MCP 서버와의 비교: 각 저장소 README/소스로 확인(2026-10-15). 스타는 GitHub API 같은 날 조회.

비교 요점:

• REA는 단일 엔진 MCP 위의 계층. IDA는 ida-pro-mcp(또는 idalib-mcp)에, JEB는 사용자가 띄운 JEB MCP에 REA가 MCP 클라이언트로 접속(5.2). 즉 경쟁이라기보다 단일 엔진 래퍼를 공통 계약으로 감싸는 구조.
• 단일 엔진 래퍼는 엔진 API를 거의 1:1로 노출(디컴파일/xref/이름 변경). REA는 엔진 중립 이름 + Evidence 계약 + 커버리지/미확인 원장으로 “결과를 어떻게 믿을지”까지 표준화. 이 차이가 도구 수(30 vs 207)와 결과 형식 차이의 근원.
• 단일 엔진 래퍼 쪽도 컨텍스트 문제를 인식: ida-pro-mcp의 페이지네이션 상한, 디버거 도구 기본 숨김, Hex-Rays의 “다른 IDA MCP 서버 비활성화” 권고(도구 중복이 에이전트를 혼란시킨다는 인식). REA는 반대로 카탈로그를 고정하고 가용성은 binary_session {}의 tool_availability로 조회하게 한다.
• 단일 엔진 래퍼의 흔한 약점인 원격 바인딩 무인증(jadx-mcp-server README 경고)은 REA에서는 stdio 전용 + 브리지 토큰으로 회피.
• 수치 비교 주의: 도구 수는 저장소마다 세는 기준이 다르다(리소스, 조건부 등록, 확장 노출). 표의 수치는 각 README/소스 기준이며 서버를 실행해 tools/list로 센 값이 아니다.
• 엔진별 기존 MCP 서버 목록(GhidraMCP, HopperPyMCP, jadx-ai-mcp, jeb-mcp 등)은 부록 B 각 절.

약점과 트레이드오프

8.3 소프트웨어를 배포하는 쪽의 보안 함의

전제: 배포된 클라이언트 바이너리/모바일 앱/데스크톱 앱/웹 번들은 공개된 것으로 간주.

• REA 같은 도구는 이 분석을 에이전트 한 번의 요청으로 묶어 준다(4.3, CHANGELOG 6.4.0 “RPC discovery”).
  • 문자열 검색, 함수 dossier, Electron IPC 그래프, APK 디컴파일, source map 복원
  • tRPC/GraphQL 연산명까지 호출 인식
• 대상 범위: Electron 앱(ASAR, 모듈, IPC), .NET 어셈블리, APK, 네이티브 바이너리, 웹 번들의 RPC 경로.

위험 / 권고 표

방어 측 활용(권고):

• 같은 도구로 배포물을 사전 점검 가능(비밀값, source map, 디버그 엔드포인트, Electron fuse).
• 단 런타임 캡처/Frida/디버거는 격리 VM/컨테이너에서만.
• 결과가 외부 모델 제공사로 전송된다는 점(README FAQ)을 조직의 데이터 정책과 대조.

AI 에이전트가 위험을 어떻게 바꾸는가

정리:

• 배포물 분석의 비용 하락은 “숙련자의 속도”보다 “분석 가능한 사람의 수”에서 크게 나타난다(NDSS 2026).
• 비밀값 하드코딩/클라이언트 측 권한 판단/공개 source map은 원래도 OWASP가 금지하던 항목. AI는 새 취약점 유형을 만들기보다 기존 금지 항목이 실제로 악용될 확률을 올린다(추측이 섞인 해석. 확률 상승의 정량 근거는 확인 못 함).
• 난독화는 여전히 비용을 올리지만(Elastic) 보안 경계가 아니다(MASVS-RESILIENCE). 경계는 서버 측 인증/권한/입력 검증.

8.4 클린룸과 EULA

• REA 문서 자체의 클린룸 조건(docs/installation.md):
  • 구현 환경이 REA, 대상, 분석 결과를 읽거나 가져올 수 없도록 별도 계정이나 컨테이너로 강제해야 한다.
  • 같은 OS 계정 안에서 프로필만 나누는 것으로는 부족.
  • 즉 “에이전트가 분석하고 같은 에이전트가 구현”하는 구조는 문서 기준으로도 클린룸이 아니다. 일반적인 클린룸 설계 정의는 2.6.
• 분석 결과나 소스와 비슷한 산출물을 얻었다고 원 프로그램이나 산출물에 대한 권리가 생기지 않는다(DISCLAIMER.md).
  • 상용 SW의 EULA 역공학 금지 조항, 국가별 상호운용성 예외 범위는 법무 확인 필요
  • 이 문서는 법적 판단을 하지 않는다
• 상용 엔진의 체험판/데모도 자동화와 출력 공유 제한을 포함한 벤더 약관을 따른다(README).

부록 A. 엔진별 상세

A.1 Ghidra

출처: Wikipedia: Ghidra, GitHub: NationalSecurityAgency/ghidra

REA에서의 사용: 선택(optional). (REA README)

• 이미 설치된 Ghidra를 REA가 headless로 기동
• Linux/macOS 지원, Windows는 실험적. 16비트 DOS 분석도 지원
• 큰 바이너리는 REA_GHIDRA_STARTUP_TIMEOUT_MS로 기동 대기 시간 연장

기존 MCP 서버: GhidraMCP(LaurieWired, Apache-2.0)

• 2계층 구조: Ghidra 플러그인이 HTTP 서버를 띄우고 Python MCP 브리지가 LLM 클라이언트와 중계
• 디컴파일, 함수/데이터 이름 변경, import/export 목록화 지원

A.2 IDA Pro

출처: Wikipedia: Interactive Disassembler, Hex-Rays Pricing

REA에서의 사용: 선택. 사용자가 이미 설치한 IDA를 사용. REA는 IDA 설치/업그레이드/라이선스를 관리하지 않는다. 연동 모드는 2가지.

1. Attached: 실행 중인 IDA GUI에 붙어 분석(원본 바이너리 SHA-256으로 검증)
2. Headless: idb_open/idb_list/idb_close 데이터베이스 감독자 API로 별도 워커 프로세스에서 분석

추가 사항:

• ida-free-mcp 플러그인을 native MCP bridge로 선택 사용 가능(IDA Pro/Free GUI 플러그인, 1.1.3 이상 권장)
• IDA Free의 클라우드 디컴파일러는 네트워크 접근 필요(REA IDA 가이드 docs/ida-provider.md)
• 연결 방식 상세는 5.2

기존 MCP 서버

• ida-pro-mcp(mrexodia, MIT)
  • IDA Pro 8.3 이상 지원, IDA Free 미지원
  • idalib-mcp로 headless 지원
  • 이 저장소는 Hex-Rays 공식 IDA MCP 서버 사용을 권장한다고 공지. 공식 서버의 발표 자료는 확인 못 함
• 그 밖에 idamesh 등 서드파티 구현 존재

A.3 Hopper Disassembler

출처: hopperapp.com, Hopper v4 스토어

REA에서의 사용: 선택. (REA README)

• 사용자 승인 시 REA setup이 설치 가능. REA가 필요할 때 headless로 기동
• macOS는 첫 실행 시 라이선스 대화상자 표시. CLI/MCP 사용 전에 같은 세션에서 완료 필요
• 큰 바이너리는 REA_HOPPER_STARTUP_TIMEOUT_MS로 대기 시간 조정
• 플랫폼은 macOS/Linux, Windows 실험적
• 브리지 구조는 5.3

기존 MCP 서버

• 공식 사이트가 통합 MCP 서버 언급(hopperapp.com)
• 커뮤니티 구현: HopperPyMCP(FastMCP 기반 플러그인)

A.4 JADX

출처: GitHub: skylot/jadx, GitHub API(생성일/릴리스)

REA에서의 사용: 선택(Android APK 분석). (REA README)

• REA가 headless 디컴파일러로 자동 기동
• Linux/macOS/Windows x64에서 전체 JDK 필요
• 반환: 매니페스트, 클래스, 디컴파일된 메서드, 참조

기존 MCP 서버: zinja-coder의 2개 구성 요소를 함께 쓰는 구조

• jadx-ai-mcp: JADX-GUI 플러그인, Apache-2.0
• jadx-mcp-server: Python MCP 서버

A.5 JEB Decompiler

출처: Wikipedia: JEB decompiler, pnfsoftware.com, JebMcpServer API 문서

REA에서의 사용: 선택. (REA README)

• 클라이언트-서버 방식: 사용자가 직접 띄운 JEB 클라이언트가 MCP 서버를 제공하고 REA가 REA_JEB_MCP_URL로 연결
• 실행 중인 JEB 인스턴스 필수
• 반환: 프로젝트 유닛, 아티팩트 다이제스트, 의사코드

기존 MCP 서버

• JEB 내장 JebMcpServer(공식 API)
• 커뮤니티 jeb-mcp(JEB Pro용, JEB 스크립트로 기동)

A.6 Apktool

출처: GitHub: iBotPeaches/Apktool

REA에서의 사용: 선택(Android 리소스 분석).

• 사용자가 런처를 제공하고 REA가 리소스 디코딩에 호출
• 반환: 디코딩된 매니페스트, 문자열 테이블, 로케일, 버전 정보

A.7 Binwalk / Unblob

출처: GitHub: ReFirmLabs/binwalk, GitHub: onekey-sec/unblob

REA에서의 사용: 선택(펌웨어 추출).

• Linux에서 자동 실행(procps 호환 ps 필요). Unblob은 Binwalk의 대안
• 영역/추출 결과를 반환하고 네이티브 분석 엔진으로 전달

A.8 objdump / Rizin

출처: GitHub: rizinorg/rizin, Announcing Rizin

REA에서의 사용: README는 둘 다 선택적 “오프라인 provider”로 설명.

• 대화형 엔진 없이 정적 네이티브 검사를 할 때 사용
• 사용자가 PATH에 제공해야 한다. REA는 설치/업데이트를 하지 않는다
• MCP 도구는 inspect_with_objdump, execute_rizin_command 등 직접 명령 도구. 6.4.0 대비 추가분(4.3)
• 깊은 분석 엔진의 자동 폴백은 아니다(3.2)

부록 B. 용어 정리

• 디스어셈블(disassemble): 기계어를 어셈블리 명령어로 1:1에 가깝게 변환. 결과는 정확하지만 읽기 어렵다.
• 디컴파일(decompile): 기계어/바이트코드에서 C/Java 같은 고수준 의사코드를 복원. 읽기 쉽지만 변수명/타입/구조는 추정치라 틀릴 수 있다.
  • Dalvik/Java 바이트코드: 정보가 많이 남아 디컴파일이 비교적 정확
  • 네이티브 코드: 더 어렵다
• 정적 분석(static): 실행하지 않고 파일 자체를 분석(Ghidra, IDA, JADX 등). 안전하지만 런타임 동작(암호 해제, 동적 로딩)을 놓칠 수 있다.
• 동적 분석(dynamic): 실제로 실행하며 관찰(디버거, adb 로그, 패킷 캡처 등). 실제 동작을 확인할 수 있지만 실행 환경 격리 필요.
• headless: GUI 없이 CLI/API로 엔진을 실행하는 모드. 자동화/CI/LLM 에이전트 연동(REA)의 기반(5.3).
• stdio transport: MCP 클라이언트가 서버를 자식 프로세스로 띄우고 stdin/stdout 파이프로 JSON-RPC를 주고받는 방식(4.1).
• Evidence 레코드: REA 도구 결과의 정규 봉투. 내용 해시 evidence_id, 출처, 신뢰도, 한계 등 16개 필드(4.5).
• 세션 원장(EvidenceLedger): 연결 하나에 하나씩 있는 Evidence 보관소. close_binary 때 삭제(4.6).
• 엔진 바인딩: open_binary가 대상 하나에 깊은 분석 엔진 하나를 고정하는 것. 실패해도 자동 전환하지 않는다(3.3).
• target-free(경로 직접) 도구: open_binary 없이 경로/엔드포인트를 직접 받는 도구. 단 세션 입장 관문은 거친다(4.2).
• annotation(readOnlyHint/destructiveHint): 서버가 도구에 붙이는 MCP 힌트. 권한 통제 수단은 아니다(6.2).
• untrusted_content: 대상 유래 콘텐츠가 담긴 결과의 _meta.provenance 표시. 6.5.0부터 포함(6.3).
• 클린룸 설계: 분석 팀과 구현 팀을 분리해 독립 창작을 보이는 방식(8.4).

Reference