
AI를 사용하여 컴파일된 프로그램에서 C/C++ 코드를 재구성하고 검증합니다.
자율 리버스 엔지니어링 에이전트 — 소스 인지 리버서/검사 루프, 목표 검증기, 패리티 엔진, Ghidra 백엔드.
데모: YouTube
re-agent는 ghidra-ai-bridge를 통한 Ghidra 디컴파일과 리버서/검사 루프를 결합하여 리버스 엔지니어링 워크플로를 자동화합니다. 현재 파이프라인은 또한 생성 중에 인접한 프로젝트 소스 컨텍스트를 검색하고 체커 패스를 수락하기 전에 보수적인 구조 검증기를 실행합니다.
re-agent reverse --class CTrain
│
├── Config (re-agent.yaml + env + CLI)
│ └── project_profile (stub_markers, hook_patterns, source_layout)
│
├── Orchestrator (single / class runner)
│ ├── Function Picker (ranks by caller count, filters completed)
│ ├── Context Gatherer (decompile + xrefs + structs + source retrieval)
│ │
│ ├── Agent Loop (reverser → checker → fix, max N rounds)
│ │ ├── LLM Providers: Claude | OpenAI-compatible APIs | Codex CLI
│ │ └── Prompt Templates (customizable .md files)
│ │
│ ├── Objective Verifier (call-count + control-flow sanity checks)
│ │
│ ├── Parity Engine (GREEN/YELLOW/RED verification gate)
│ │ ├── Source Indexer (C++ body parser)
│ │ ├── 11 Heuristic Signals (all configurable/toggleable)
│ │ └── Semantic Rules + Manual Approvals
│ │
│ └── Session State (JSON progress file)
│
└── RE Backend: ghidra-ai-bridge
└── Capability flags → graceful degradation
re-agent reverse를 실행하기 전에 설치하고 Ghidra 프로젝트를 가리키도록 설정하세요.ANTHROPIC_API_KEYOPENAI_API_KEYcodex CLI 로그인pip install auto-re-agent
# 1. Initialize project config
re-agent init
# 2. Edit re-agent.yaml with your project settings
# 3. Reverse a single function
re-agent reverse --address 0x6F86A0
# 4. Reverse all functions in a class
re-agent reverse --class CTrain --max-functions 10
# 5. Run parity checks
re-agent parity --address 0x6F86A0
# 6. Check progress
re-agent status
re-agent는 계층형 구성 시스템을 사용합니다(우선순위 높은 순): CLI 플래그 > 환경 변수(RE_AGENT_*) > re-agent.yaml > 기본값.
llm:
provider: claude # claude | openai | openai-compat | codex
model: claude-sonnet-4-5-20250929
# api_key: set via RE_AGENT_LLM_API_KEY env var
timeout_s: 1800
backend:
type: ghidra-bridge
cli_path: ~/ghidra-tools/ghidra
orchestrator:
max_review_rounds: 4
max_functions_per_class: 10
objective_verifier_enabled: true
project_profile:
source_root: ./source/game_sa
hook_patterns:
- 'RH_ScopedInstall\s*\(\s*(\w+)\s*,\s*(0x[0-9A-Fa-f]+)'
stub_markers: ["NOTSA_UNREACHABLE"]
stub_call_prefix: "plugin::Call"
모든 옵션은 docs/configuration.md를 참조하세요.
| 명령 | 설명 |
|---|---|
re-agent init | re-agent.yaml 구성 파일 생성 |
re-agent reverse --address ADDR | 단일 함수 리버스 |
re-agent reverse --class CLASS | 클래스의 모든 함수 리버스 |
re-agent reverse --dry-run | 리버스할 항목 표시 |
re-agent parity --address ADDR | 함수에 대한 패리티 검사 실행 |
re-agent parity --filter REGEX | 패턴과 일치하는 패리티 검사 실행 |
re-agent status | 리버스 진행 상황 표시 |
re-agent status --class CLASS | 특정 클래스의 진행 상황 표시 |
ANTHROPIC_API_KEY 설정OPENAI_API_KEY 설정, 선택적으로 base_url 설정codex exec 사용, API 키 불필요패리티 엔진은 리버스된 코드가 원본 바이너리와 일치하는지 확인하기 위해 11개의 구성 가능한 휴리스틱 신호를 실행합니다:
| Signal | 수준 | 설명 |
|---|---|---|
| Missing source | RED | 후킹된 함수에 대한 소스 본문을 찾을 수 없음 |
| Stub markers | RED | 소스에 스텁 마커가 포함됨 (예: NOTSA_UNREACHABLE) |
| Trivial stub | RED | 플러그인 호출이 많고 본문이 아주 작으며 제어 흐름이 없음 |
| Large ASM tiny source | RED | ASM이 80개 이상의 명령어인데 소스는 12줄 이하 |
| Plugin-call heavy | YELLOW | 플러그인 호출이 함수 본문을 지배함 |
| Short body | YELLOW | 본문이 6줄 미만 |
| Low call count | YELLOW | 디컴파일에는 피호출자가 많지만 소스에는 적음 |
| FP sensitivity | YELLOW | ASM에 부동소수점 연산이 있는데 소스에는 없음 |
| Call count mismatch | YELLOW | 소스 호출 수가 ASM과 크게 다름 |
| NaN logic | YELLOW | 디컴파일에 NaN 처리가 있는데 소스에는 없음 |
| Inline wrapper | INFO | 함수가 얇은 인라인 래퍼임 |
리버스 루프는 LLM 체커가 통과한 후에도 보수적인 구조 검증기를 실행합니다. 후보 코드와 디컴파일/ASM 사이의 강한 불일치가 있을 때만 수락을 차단합니다. 예를 들면:
이는 완전한 동등성 검사보다 의도적으로 좁은 범위지만, 성공적인 리버스로 기록되기 전에 명백한 오탐을 잡아냅니다.
이는 실제로 중요합니다. LLM 체커는 그럴듯해 보이는 코드에 대해 여전히 오탐을 낼 수 있으며 바이너리의 실제 분기나 호출 구조를 놓칠 수 있기 때문입니다.
git clone https://github.com/dryxio/auto-re-agent.git
cd auto-re-agent
python -m venv .venv && source .venv/bin/activate
pip install -e ".[dev]"
pytest tests/
ruff check src/
mypy src/re_agent/
MIT