Windows 실행 파일 및 바이너리 포맷을 리버스 엔지니어링하기 위한 MCP 서버입니다. 정적 트라이지, Ghidra 기반 함수 복구, 플러그인 기반 도구, 아티팩트 관리, 그리고 선택적 격리된 Windows 런타임 실행을 결합합니다.
Rikune은 Windows 실행 파일 및 관련 바이너리 형식을 리버스 엔지니어링하기 위한 MCP 서버입니다. 샘플 수집, 정적 트리어지, Ghidra 기반 함수 복구, 플러그인 기반 전문 도구, 아티팩트 관리, 선택적 격리 Windows 런타임 실행을 Model Context Protocol 인터페이스 뒤에 결합합니다.
현재 AI 지향 서버 워크플로는 최소한의 게이트웨이 표면으로 구성됩니다:
workflow.search를 사용하여 파일 유형과 사용자 목표에 일치하는 프로필, 워크플로, 전문 기능을 순위화합니다.workflow.run action=request_upload를 사용하거나, workflow.search가 레거시 클라이언트를 숨겨진 샘플 수집 호환 도구로 안내하도록 합니다.sample_id와 함께 workflow.run action=start를 사용합니다.workflow.run action=status와 workflow.run action=promote를 사용하여 스테이지 실행을 모니터링하고 심화합니다.artifact.read를 사용하여 완전한 지속 아티팩트를 읽습니다.sample.*, , , , 는 호환성 또는 저수준 검사를 위해 계속 등록되어 있지만, 새 클라이언트는 , , 를 선호해야 합니다.
workflow.analyze.*workflow.triagetools.discovertask.statusworkflow.searchworkflow.runartifact.read원격 rikune-agent 게이트웨이를 통해 연결할 때 MCP 클라이언트는 다음과 같은 안정적인 전송 이름을 볼 수 있습니다:
workflow_search, workflow_run, artifact_read, rikune_tool_call, 그리고
rikune_connection_* 컨트롤. rikune_connection_refresh는 내부 업스트림
기능 캐시만 업데이트하며, MCP 도구 목록을 확장하지 않습니다. rikune_tool_call은
workflow_search가 기본 워크플로 또는 아티팩트 게이트웨이에 포함되지 않은 특정 내부 분석기 서브도구를
식별한 후에만 사용하십시오.
workflow.search는 샘플 유형, 결과, 프로필 메타데이터를 사용하여 모든 도구를 처음부터 노출하지 않고 전문 기능으로 라우팅합니다.정적 Docker가 가장 안전한 기본값입니다. 샘플을 실행하지 않습니다.
.\rikune.ps1 install -Profile static -DataRoot "D:\Docker\rikune"
./rikune.sh install --profile static --data-root "$HOME/.rikune"
수동 동등 명령:
npm install
npm run build
npm run docker:generate:all
docker compose --env-file .docker-runtime.env -f docker-compose.analyzer.yml up -d --build analyzer
하이브리드 모드는 Docker에서 Analyzer를 실행하고 라이브 Windows 작업을 Windows Host Agent에 위임합니다. Host Agent는 요청 시 Windows Sandbox를 시작하거나 구성된 Hyper-V VM을 제어할 수 있습니다.
.\rikune.ps1 install -Profile hybrid -InstallRuntime
Linux/macOS에서 원격 Windows 런타임 호스트로:
./rikune.sh install --profile hybrid --windows-host <windows-host> --windows-user <windows-user>
MCP 클라이언트를 연결해도 Windows Sandbox가 시작되거나 샘플이 실행되지 않습니다. 라이브 런타임 작업은 runtime.debug.session.start, runtime.debug.command, sandbox.execute 또는 승격된 동적 실행 단계와 같이 도구에서 명시적으로 요청할 때만 시작됩니다.
npm install
npm run build
npm test
node dist/index.js
루트 패키지는 Node.js 22 이상이 필요합니다. 일부 런타임 서브패키지는 이전 Node 버전에서 실행될 수 있지만, 리포지토리 개발 및 게시된 루트 CLI는 Node 22+를 사용해야 합니다.
요청된 워크플로, 파일 유형 또는 백엔드가 불명확할 때마다 workflow.search로 시작하세요. 숨겨진 전문 도구를 활성화하지 않고 일치하는 프로필을 순위화하고 간결한 준비/라우팅 힌트를 반환합니다.
호스트 파일의 경우, workflow.run action=request_upload를 호출하고 반환된 업로드 URL에 원시 바이트를 POST한 다음 HTTP 응답에서 sample_id를 읽으십시오. sample.request_upload 및 sample.ingest는 일반적인 AI 지향 경로가 아닌 호환성 도우미입니다.
원격 분석기 또는 rikune-agent 배포의 경우 API_PUBLIC_BASE_URL, RIKUNE_API_PUBLIC_BASE_URL 또는 RIKUNE_ANALYZER_PUBLIC_URL을 클라이언트가 접근 가능한 HTTP API 베이스(예: http://159.195.136.226:18080)로 설정하십시오. 그러면 업로드 세션이 컨테이너 로컬 localhost URL 대신 공개 upload_url / status_url 값을 반환합니다. 원격 게이트웨이는 또한 이전 분석기의 localhost 업로드 URL을 구성된 분석기 엔드포인트로 정규화합니다.
HTTP API가 활성화된 경우 POST /api/v1/samples는 비MCP 통합에 계속 사용할 수 있습니다. 성공적인 수집은 sample_id를 반환합니다. 가져오기 후에는 로컬 경로가 아닌 sample_id를 사용하여 분석해야 합니다.
sample_id와 함께 workflow.run action=start를 호출하십시오. 첫 번째 단계는 빠른 프로필을 수행하고 분석 실행을 생성하거나 재사용합니다. 반환된 plan_id는 지속된 분석 실행에 매핑됩니다.
workflow.run action=promote를 사용하여 더 깊은 단계를 요청하십시오. 파이프라인은 현재 다음 단계를 모델링합니다:
fast_profileenrich_staticfunction_mapreconstructsemantic_reviewsdynamic_plandynamic_executesummarize장기 실행 작업은 작업 시스템을 통해 대기열에 추가됩니다. workflow.run action=status를 사용하여 간결한 스테이지 상태를 폴링하십시오.
workflow.run action=status는 주요 스테이지 실행 뷰입니다. 큰 기록 스테이지 페이로드는 최상위 경고와 함께 정리될 수 있습니다. 전체 아티팩트는 artifact.read를 사용하십시오. task.status는 원시 대기열/프로세스 호환성 뷰이며 분석기 하위 프로세스에 대한 external_active_* 메모리 텔레메트리를 포함합니다.
유용한 후속 표면:
workflow.searchworkflow.runanalysis.context.getartifact.read 및 호환성 아티팩트 도우미: artifact.list, artifact.diff, artifact.downloadreport.summarize, report.generate, workflow.summarizeworkflow.semantic_name_reviewworkflow.function_explanation_reviewworkflow.module_reconstruction_reviewtool.help, tool.readiness, tools.discover현재 코드 경로는 다음과 같습니다:
src/index.ts
-> loadConfig()
-> WorkspaceManager / DatabaseManager / PolicyGuard / CacheManager / StorageManager / JobQueue
-> optional RuntimeClient or Windows sandbox bootstrap
-> registerAllTools()
-> MCP stdio server
핵심 서버 모듈은 src/core/ 아래에 있습니다:
| 영역 | 현재 파일 |
|---|---|
| MCP 서버 래퍼 | src/core/server.ts |
| MCP 도구/프롬프트/리소스 레지스트리 | src/core/mcp-registry.ts |
| 도구 실행, 검증, 훅 | src/core/tool-executor.ts |
| 레지스트리 오케스트레이션 | src/core/tool-registry.ts |
| 내장 레지스트리 슬라이스 | src/core/tool-registry/*.ts |
| 플러그인 관리자 퍼사드 | src/core/plugins.ts |
| 플러그인 검색/로딩 | src/core/plugin-orchestrator.ts |
| 점진적 도구 노출 | src/core/tool-surface-manager.ts |
src/server.ts, src/tool-registry.ts, src/plugins.ts와 같은 일부 루트 레벨 파일은 호환성 전달자로 남아 있습니다. 새 코드는 src/core/*를 대상으로 해야 합니다.
| 평면 | 목적 | 주요 코드 |
|---|---|---|
| Analyzer | MCP stdio 서버, HTTP API, 스토리지, 작업, 정적 도구, 플러그인 오케스트레이션 | src/index.ts, src/core/* |
| Runtime Node | 샌드박스 또는 VM 내에서 격리된 작업 실행기 | packages/runtime-node/* |
| Windows Host Agent | Windows Sandbox 또는 Hyper-V 런타임을 시작/중지하고 런타임 제어 엔드포인트 노출 | packages/windows-host-agent/* |
| Agent Gateway | 분석기/런타임 연결 관리를 위한 MCP 게이트웨이/프록시 | src/rikune-agent-gateway.ts |
런타임 모드는 runtime.mode 또는 환경 변수를 통해 구성됩니다:
disabled: 런타임 위임 없음.manual: 제공된 런타임 엔드포인트에 연결.remote-sandbox: Windows Host Agent에 위임.auto-sandbox: Windows 네이티브 분석기가 로컬에서 Windows Sandbox를 시작.Docker/WSL 분석기는 auto-sandbox가 아닌 remote-sandbox를 사용해야 합니다.
Rikune은 현재 src/plugins/<id>/ 아래에 111개의 내장 플러그인을 포함합니다. 플러그인은 도구를 등록하고, 종속성을 선언하고, 구성 스키마를 노출하고, 라이프사이클 훅에 참여하고, Docker 메타데이터를 제공하고, workerBackend 메타데이터를 통해 경계를 갖춘 Worker 기반 도구를 선언할 수 있습니다.
프론티어 Worker 제품군은 계획 전용 도구를 트리어지 및 핸드오프 표면으로 유지하면서 그 옆에 명시적 실행 도구를 추가합니다. restringer.deobfuscation.run, jsimplifier.pipeline.run, jsir.cascade.normalize, gtirb.ir.generate, remill.lift.run, manifold.fact.extract, qbdi.trace.run, culifter.gpu.artifact.inventory는 workflow.search, plugin.list, tool.help, tool.readiness를 통해 Worker 계약을 노출합니다. tools.discover는 저수준 호환성 포털로 남아 있습니다. 검색 및 준비 상태는 수동적으로 유지됩니다: REstringer, JSIMPLIFIER, JSIR/CASCADE, GTIRB, Remill, Manifold, QBDI, GPU 드라이버, Node/V8, 브라우저 또는 런타임 계측을 시작하지 않고 백엔드 메타데이터와 설정 지침을 보고합니다.
Docker 생성은 플러그인 systemDeps 및 Worker 패키징 메타데이터를 직접 읽습니다. 기본 이미지는 REstringer, JSIMPLIFIER, Manifold, WABT, LIEF 검증과 같은 저위험 정적 래퍼를 설치합니다. 선택적 프로필은 JSIR/CASCADE, JSVMP, GTIRB, radare2, Triton 스타일 정적 경로를 활성화할 수 있습니다. 대량/런타임/GPU/라이선스 민감 백엔드는 프로필 게이트, BYO 또는 사이드카로 유지됩니다.
node scripts/generate-docker.mjs --dry-run
node scripts/generate-docker.mjs --profile=full --backend-profile=optional
node scripts/generate-docker.mjs --all-profiles --dry-run
플러그인 로딩은 PLUGINS에 의해 제어됩니다:
PLUGINS=* # 모든 내장 플러그인
PLUGINS=pe-analysis,yara # 선택된 플러그인
PLUGINS=-dynamic # 동적 플러그인을 제외한 모든 플러그인
런타임 시 다음 MCP 도구를 사용하십시오:
workflow.searchworkflow.runplugin.listplugin.enableplugin.disabletools.discover 및 tool.readinessdocs/PLUGINS.md 및 packages/plugin-sdk/README.md를 참조하십시오.
api.enabled가 true이면 임베디드 파일 서버가 다음을 노출합니다:
| 엔드포인트 | 목적 |
|---|---|
/dashboard 및 / | 대시보드 UI |
/api/v1/health | 활성 상태 |
/api/v1/ready | 데이터베이스, 대기열, 런타임, 플러그인 백엔드 전반의 준비 상태 |
/api/v1/events | SSE 이벤트 |
/api/v1/samples | 직접 샘플 업로드 |
/api/v1/samples/:id | 샘플 메타데이터 |
/api/v1/samples/:id/download | 원본 샘플 다운로드 |
/api/v1/artifacts | 아티팩트 목록 |
/api/v1/artifacts/:id | 아티팩트 읽기/삭제 |
/api/v1/uploads/:token | 지속 업로드 세션 POST/상태 |
API 키 인증, 속도 제한, 보안 헤더, 제한된 CORS는 HTTP 계층에서 처리됩니다.
최소 개발 기준:
선택적 도구는 플러그인별로 다릅니다. 특정 환경에서 누락된 것을 확인하려면 system.health, system.setup.guide, tool.readiness, plugin.list를 실행하십시오.
src/
index.ts 메인 서버 진입점
core/ MCP 서버, 레지스트리, 실행기, 플러그인 오케스트레이션
core/tool-registry/ 내장 도구/프롬프트/리소스 등록 슬라이스
tools/ 핵심 도구 구현
workflows/ 스테이지 분석, 트리어지, 재구성, 검토 워크플로
analysis/ 실행 상태 및 백그라운드 작업 실행기
plugins/ 111개의 내장 플러그인
persistence/ SQLite 및 작업 공간 지속성
sample/ 샘플 최종화 및 작업 공간 검사
storage/ 아티팩트, 업로드, 보존
runtime-client/ 분석기 측 런타임 위임 클라이언트
worker/ Ghidra 및 Python 워커 오케스트레이션
packages/
plugin-sdk/ 공개 플러그인 SDK
shared/ 런타임 및 도구 계약 유형
runtime-node/ 격리된 런타임 실행기
windows-host-agent/ Windows Sandbox / Hyper-V 호스트 에이전트
workers/ Python 워커 스크립트 및 YARA 규칙
docker/ 생성된 Dockerfile 템플릿 및 프로필 파일
docs/ 아키텍처, 플러그인, 런타임, 배포 문서
tests/ 단위, 통합, e2e 테스트
npm install
npm run build
npm test
npm run typecheck
npm run validate
npm run docker:generate:all
유용한 집중 검사:
npm run test:unit
npm run test:integration
npm run test:e2e
npm run build:runtime
로컬 빌드:
{
"mcpServers": {
"rikune": {
"command": "node",
"args": ["D:/Playground/windows-exe-decompiler-mcp-server/dist/index.js"],
"env": {
"API_ENABLED": "true",
"API_PORT": "18080",
"API_PUBLIC_BASE_URL": "http://127.0.0.1:18080",
"PLUGINS": "*"
}
}
}
}
Docker stdio:
{
"mcpServers": {
"rikune": {
"command": "docker",
"args": ["exec", "-i", "rikune-analyzer", "node", "dist/index.js"]
}
}
}
게시된 패키지:
npm install -g rikune
rikune
rikune docker-stdio
rikune agent
기본적으로 Rikune은 사용자 수준 Rikune 루트 아래에 영구 데이터를 저장합니다. Docker 설치 프로그램은 일반적으로 해당 루트를 D:\Docker\rikune과 같은 호스트 디렉토리에 매핑합니다.
일반적인 하위 디렉토리:
samples/artifacts/uploads/cache/logs/샘플 작업 공간은 SHA-256으로 버킷팅되어 경로 충돌을 방지하고 변경 불가능한 원본을 유지합니다.
Rikune은 맬웨어 및 신뢰할 수 없는 바이너리 분석을 위해 설계되었지만, 그 자체로 마법의 안전 경계는 아닙니다.
PolicyGuard에 의해 보호됩니다.SECURITY.md 및 TROUBLESHOOTING.md를 참조하십시오.
MIT