GhidraMCP 딥다이브
— 바이너리 분석 도구에 AI의 손을 연결하는 법

1프로젝트 한줄 요약

GhidraMCP는 Ghidra의 바이너리 분석 기능을 MCP 클라이언트가 호출할 수 있게 만드는 연결 계층입니다. AI가 실행 파일을 이해하는 데 필요한 근거를 Ghidra에서 가져오고, 분석 결과를 이름과 주석으로 다시 남기게 해줍니다.

예를 들어 AI에게 “이 프로그램의 계산 흐름을 설명해 줘”라고 요청하면, 클라이언트는 함수 목록을 조회하고, 특정 함수를 디컴파일하고, 그 함수가 호출하는 다른 함수를 조사할 수 있습니다. 적절한 이름을 찾았다면 rename_function_by_address로 Ghidra의 함수 이름도 바꿀 수 있습니다.

어디까지 하는가

src/ghidra_mcp/server.py에는 @mcp.tool() 선언이 30개 있습니다. 이 중 현재 GUI 주소·함수 조회 2개는 조건부라, headless에서는 28개가 등록됩니다. list_methods 같은 호환용 별칭도 포함된 숫자이므로 독립적인 분석 알고리즘 30개라는 뜻은 아닙니다.

2왜 주목받는가

2-1. 복사하고 설명하고 이름 붙이는 반복을 줄입니다

분석 중에는 함수 목록을 훑고, 문자열을 찾고, 호출자를 확인한 뒤, 발견한 의미를 이름과 주석으로 남기는 작업이 이어집니다. 의사 코드를 대화창에 수동으로 옮기는 방식에서는 다음 조사에 필요한 주소와 주변 정보가 빠지기 쉽습니다. GhidraMCP는 그 과정을 작은 도구 호출로 나누어, 클라이언트가 필요한 정보를 추가로 요청할 수 있게 합니다.

이 프로젝트의 매력은 검증 가능한 분석 도구를 AI의 작업 흐름에 연결한다는 데 있습니다. 조회 결과에 주소·호출 위치·오류 코드를 남기는 구현도 이 연결을 뒷받침합니다.

GitHub Trending Java Monthly #3 선정과 스타 11,495개는 관심의 크기를 보여줍니다. 다만 순위나 스타만으로 분석 정확도와 실사용 성능을 판단할 수는 없습니다. 반복 탐색의 자동화, MCP 클라이언트 연결, GUI·headless 공유 구조는 코드에서 읽을 수 있는 매력 요인이며, 순위 상승의 인과관계가 검증되었다는 뜻은 아닙니다.

2-2. 다른 선택지와 비교하면 무엇이 남는가

제품 기능의 근거는 Ghidra 공식 저장소, Hex-Rays 디컴파일러 개요, Binary Ninja MCP 공식 문서입니다. 이 비교는 워크플로와 공개된 연결 기능에 관한 것이며 디컴파일 정확도의 순위표는 아닙니다.

2-3. 작은 코드에서 큰 시스템 문제를 만납니다

3기술 스택 전체 지도

3-1. 백엔드는 Python MCP 서버와 Java 분석 확장의 두 층입니다

버전 범위는 설치할 때 허용하는 후보이고, 잠금 파일의 버전은 이 스냅샷에서 실제 선택한 결과입니다. 예를 들어 mcp>=1.30,<2를 언제나 1.30.0만 쓴다는 뜻으로 읽으면 안 됩니다. extension/build.gradle의 dependencies·repositories 블록은 비어 있으며, Gson과 Ghidra API의 개별 버전은 이 저장소에서 따로 고정하지 않습니다.

3-2. 프론트엔드: 자체 웹 화면은 없습니다

package.json이나 React·Vue 코드, 별도 프론트엔드 빌드는 없습니다. 사용자 화면은 Ghidra의 기존 GUI와 외부 MCP 클라이언트가 제공합니다. extension/src/main/java/com/lauriewired/GhidraMCPPlugin.java는 포트 설정과 서버 생명주기를 연결하며, 새 대화 화면을 그리지 않습니다.

이 구조는 “UI가 없으니 미완성”이 아니라 기존 앱의 확장으로 제품 범위를 정한 사례입니다. GuiProgramProvider.getCurrentAddress()가 기존 코드 뷰어의 선택 위치를 읽어오는 것이 대표적입니다.

3-3. 인프라·빌드·검증

CI는 main에 대한 push·pull request에서 실행되도록 선언되어 있습니다. 설정 파일은 검사 의도를 보여주며, 특정 실행이 성공했다는 증거는 아닙니다. 별도 Dockerfile, Node·Rust·Go 의존성 파일은 없고, 이 워크플로에 Python·운영체제 버전 행렬도 없습니다.

# pyproject.toml의 실행 경로와 빌드 범위
[project.scripts]
ghidra-mcp = "ghidra_mcp.cli:main"

[tool.hatch.build.targets.wheel]
packages = ["src/ghidra_mcp"]

# Java 확장은 Ghidra 설치 위치에서 빌드 규칙을 가져옵니다.
# extension/build.gradle: GHIDRA_INSTALL_DIR가 없으면 예외 발생

4아키텍처 심화 분석

4-1. 전체 시스템 구조

MCP 연결과 Java 백엔드 HTTP 연결을 구분해야 합니다. 클라이언트용 HTTP 모드의 기본 주소는 127.0.0.1:8081/mcp이고, Ghidra GUI 백엔드의 기본 주소는 127.0.0.1:8080입니다. --mcp-port와 --ghidra-server는 서로 다른 연결을 설정합니다.

MCP 전송 규격은 표준 입출력과 Streamable HTTP를 설명합니다. 이 저장소의 Java HTTP 응답은 success/data/error 봉투를 쓰는 내부 API이며, 외부 MCP 메시지 처리는 Python SDK가 맡습니다.

4-2. 패턴 ① 어댑터와 파사드: 복잡한 도구를 작은 함수로 감쌉니다

src/ghidra_mcp/server.py의 create_server()는 Python 함수에 @mcp.tool()을 붙여 도구를 공개합니다. decompile_function_by_address(address)는 내부 경로 decompile_function을 GET으로 호출하고, Java의 registerRoutes()는 이를 service.decompileByAddress()에 연결합니다.

# src/ghidra_mcp/server.py의 실제 도구 연결
@mcp.tool()
def decompile_function_by_address(address: str) -> Result:
    # 도구 설명 문자열은 생략했습니다.
    return get("decompile_function", address=address)

# 호출 입력 예시. 주소는 실제 함수 목록에서 얻습니다.
{"address": "0x401000"}

어댑터는 서로 다른 인터페이스 사이를 번역하는 부품이고, 파사드는 복잡한 내부 기능의 간단한 입구입니다. Python 도구 함수가 MCP 입력을 HTTP 파라미터로 번역하고, Java 서비스가 여러 Ghidra API를 “함수 하나 디컴파일”이라는 작업으로 묶는 모습에서 두 역할을 읽을 수 있습니다.

GhidraBackend.request()는 값이 None인 파라미터를 제거하고, GET에서는 params=, POST에서는 data=를 사용합니다. Java의 Request.parse()는 쿼리 문자열과 폼 본문을 합칩니다. 따라서 이 내부 API를 JSON 본문을 받는 API라고 설명하면 실제 계약과 어긋납니다.

4-3. 패턴 ② 전략과 의존성 주입: 환경 차이를 바깥으로 밀어냅니다

extension/src/main/java/com/lauriewired/ghidramcp/core/ProgramProvider.java는 getProgram(), mode(), capabilities(), runWrite()를 정의합니다. GUI 구현은 ProgramManager의 현재 프로그램을 얻고, headless 구현은 생성 시 받은 하나의 Program을 반환합니다.

// BackendHttpServer 생성자의 핵심 두 줄
this.provider = provider;
this.service = new GhidraAnalysisService(provider::runWrite);

// ProgramProvider의 쓰기 실행 계약
<T> T runWrite(Supplier<T> action);

분석 서비스는 GUI 객체를 직접 찾지 않습니다. 필요한 프로그램은 메서드 인자로 받고, 쓰기 실행 방식은 생성자로 받습니다. 이 덕분에 GUI와 headless를 위해 함수 목록·디컴파일·이름 변경 알고리즘을 두 벌 만들 필요가 없습니다.

4-4. 패턴 ③ 작업 실행기와 트랜잭션: 어느 스레드에서, 어디까지 바꿀지 정합니다

GuiProgramProvider.runWrite()는 이미 Swing 이벤트 스레드라면 바로 실행하고, 그렇지 않으면 SwingUtilities.invokeAndWait()로 작업을 전달합니다. HeadlessProgramProvider.runWrite()는 직접 실행합니다. headless HTTP 요청은 BackendHttpServer의 단일 실행기에서 처리됩니다.

그 위에서 GhidraAnalysisService.write()가 수정의 성공·실패 범위를 관리합니다. 이름 변경, 데이터 라벨, 주석, 함수 원형, 변수 타입 변경이 이 공통 경로를 사용합니다.

// GhidraAnalysisService.write()의 흐름을 줄인 의사 코드
return writeExecutor.execute(() -> {
    int tx = program.startTransaction(transactionName);
    boolean commit = false;
    try {
        T result = action.run();
        commit = true;
        return result;
    } finally {
        program.endTransaction(tx, commit);
    }
});

수정이 안전하려면 올바른 실행 스레드와 성공했을 때만 확정되는 트랜잭션을 함께 설계해야 합니다. 실제 메서드는 중복 이름을 NAME_CONFLICT로, 잘못된 입력을 INVALID_PARAMETER로 번역하는 예외 처리도 포함합니다.

여기서 확정되는 것은 Ghidra 프로그램의 트랜잭션입니다. 디스크에 프로젝트를 저장하는 일은 별도입니다. headless의 종료 시 저장 여부는 HeadlessSession.close()와 _should_save()가 결정합니다.

4-5. 패턴 ④ 준비 상태를 가진 프록시: 느린 시작을 도구 오류로 표현합니다

cli.run_headless()는 JVM을 시작한 뒤 MCP 서버를 별도 Python 스레드에 띄우고, 메인 스레드에서 HeadlessSession.run()으로 프로그램을 열고 분석합니다. 소스 주석은 JVM을 시작한 스레드와 다른 스레드에서 프로젝트 API를 처음 사용하면 멈출 수 있다는 제약을 설명합니다.

DeferredBackend는 threading.Event로 준비 완료 또는 실패를 알립니다. HeadlessSession._serve()가 Java 서버의 실제 포트를 얻어 set_ready()에 전달합니다. 기본 --ready-timeout은 30초이며, 분석 전체를 30초 뒤 취소하는 옵션은 아닙니다.

기능 공개도 환경에 맞춥니다. GUI의 /health에는 gui_context가 들어가고, headless에서는 빈 기능 집합을 넘겨 현재 GUI 위치 도구를 숨깁니다. GUI 백엔드가 시작 시 응답하지 않아 기능이 None이면 모든 도구를 우선 등록합니다. 이후 자동으로 도구 목록을 다시 협상하는 코드는 없습니다.

4-6. 데이터 계약: 페이지, 주소, 실패도 API의 일부입니다

# Java 백엔드 응답 형식 예시. 수치는 설명용입니다.
{
  "success": true,
  "data": {
    "items": [{"name": "compute", "address": "00401000"}],
    "offset": 0, "limit": 100, "total": 1, "has_more": false
  }
}

# 실패는 코드와 설명을 분리합니다.
{"success": false,
 "error": {"code": "NO_PROGRAM", "message": "프로그램이 열려 있지 않습니다"}}

extension/src/main/java/com/lauriewired/ghidramcp/http/Json.java는 Gson의 LOWER_CASE_WITH_UNDERSCORES 정책을 써서 Java의 hasMore를 JSON의 has_more로 내보냅니다. Page.Builder.offer()는 요청 범위의 항목만 객체로 만들지만 전체 항목을 세기 위한 순회는 계속합니다. 응답을 작게 만든다고 검색 시간까지 항상 작아지는 것은 아닙니다.

4-7. 시간 제한과 로컬 경계

GhidraAnalysisService는 디컴파일 60초, 결과 문자열 200,000자(Java의 UTF-16 코드 단위), 메모리 읽기 4,096바이트 상한을 둡니다. 결과가 길면 truncated=true를 반환하고, withDecompiler()는 finally에서 DecompInterface.dispose()를 호출합니다.

src/ghidra_mcp/backend.py의 연결 제한은 5초, 읽기 제한은 90초입니다. 90초는 60초 디컴파일보다 길지만, 요청 대기와 준비 대기까지 포함한 전체 작업의 완료 보장은 아닙니다. Java 요청이 직렬 처리되므로 느린 디컴파일 뒤의 조회도 기다릴 수 있습니다.

BackendHttpServer.start()는 루프백 주소에 바인딩합니다. dispatch()는 Origin 헤더가 있거나 허용하지 않은 Host이면 403을 반환합니다. Python 세션은 trust_env=False로 환경 프록시를 사용하지 않습니다. Java 내부 API에는 토큰 인증이 구현되어 있지 않아, 로컬 프로세스 간 신뢰까지 해결한 구조는 아닙니다.

5디렉토리 구조 해부

5-1. 폴더 경계가 곧 책임 경계입니다

extension/src/main/java/com/lauriewired/ghidramcp/core/에는 HTTP 요청 객체나 Swing 화면 코드가 들어가지 않습니다. extension/src/main/java/com/lauriewired/ghidramcp/http/는 경로와 파라미터를 분석 메서드에 연결하고, extension/src/main/java/com/lauriewired/ghidramcp/gui/·extension/src/main/java/com/lauriewired/ghidramcp/headless/는 실행 환경 차이를 담당합니다. Python도 도구 선언, 네트워크 호출, 생명주기를 서로 다른 파일에 둡니다.

bridge_mcp_ghidra.py는 별도의 구형 분석 엔진이 아닙니다. 패키지의 cli.main을 가져오고, 가져오기에 실패하면 저장소의 Python 소스 경로를 추가하는 20줄짜리 호환 진입점입니다.

5-2. 코드 규모를 숫자로 읽기

줄 수는 공백·주석을 포함하는 물리 줄 수이며 문서·잠금 파일·실행 파일·Git 내부 파일은 제외했습니다. 가장 큰 파일은 extension/src/main/java/com/lauriewired/ghidramcp/core/GhidraAnalysisService.java 880줄이고, Python의 src/ghidra_mcp/server.py는 263줄입니다. Java·Python 구현 합계는 2,600줄이라 호출 경로 하나를 끝까지 읽기에도 부담이 비교적 작습니다.

6학습 포인트 (기술별)

6-1. Python: 도구 계약과 오류 번역

src/ghidra_mcp/server.py의 도구 입력에는 str | None 같은 선택형과 Literal["both", "callers", "callees"] 같은 제한된 선택지가 등장합니다. get_function_calls()의 방향 값은 Java에서도 다시 검사합니다. 외부 입력을 받는 각 경계가 자신의 계약을 검증하는 사례입니다.

학습 실습으로 get_function_xrefs()를 읽고, 이름·주소가 둘 다 없을 때 왜 HTTP 요청 전에 MISSING_PARAMETER를 내는지 설명해 보세요. 이어 BackendError의 코드·설명·HTTP 상태가 어느 계층까지 유지되는지 표로 정리해 보세요.

6-2. Java: 제네릭·레코드·지연 생성

extension/src/main/java/com/lauriewired/ghidramcp/core/Model.java는 결과를 record로 선언합니다. FunctionRef는 이름과 주소만, FunctionInfo는 서명·본문 범위 등 자세한 정보를 담습니다. 모든 조회가 무거운 객체 하나를 반환하게 만들지 않은 점을 눈여겨보세요.

// extension/src/main/java/com/lauriewired/ghidramcp/core/Page.java: 요청 범위에 있을 때만 항목을 만듭니다.
public void offer(Supplier<T> item) {
    if (total >= offset && items.size() < limit) {
        items.add(item.get());
    }
    total++;
}

Supplier<T>는 “필요할 때 T를 만드는 함수”입니다. offset 10, limit 2인 목록에 15개 항목을 넣으면 항목 객체는 두 개만 생성하지만 total은 15까지 증가합니다. 종이에 이 흐름을 추적한 뒤 객체 생성 비용과 전체 순회 비용을 따로 설명해 보세요.

6-3. HTTP: 상태 코드와 업무 오류를 함께 다루기

Request.required()는 빈 문자열도 거부하지만 present()는 존재 여부만 봅니다. 주석을 지울 때는 comment=""가 유효하기 때문입니다. 누락과 빈 값의 의미가 다를 수 있다는 API 설계의 작은 사례입니다.

연습으로 “연결 실패”, “유효한 JSON이지만 실패 봉투”, “JSON이 아닌 응답”을 구분해 보세요. tests/test_backend.py가 각 경우의 기대 동작을 어떻게 표현하는지 함께 읽으면 좋습니다.

6-4. Ghidra: 이름보다 주소, 원본보다 근거

functionByName()는 단순 이름과 네임스페이스가 붙은 이름을 모두 비교합니다. 이름은 수정될 수 있고 중복될 수도 있으므로, 도구 안내문 INSTRUCTIONS는 수정 시 주소 사용을 권합니다. 주소도 다른 바이너리에서는 의미가 달라지므로 get_program_info로 대상을 먼저 확인해야 합니다.

getFunctionCalls()는 재귀적으로 모든 경로를 복구하지 않고 한 단계의 호출 관계를 반환합니다. callees()는 함수 본문의 명령어를 걷고, calleeThroughPointer()는 포인터를 통한 호출을 일부 해석합니다. 해석할 수 없는 간접 호출은 목적지가 null일 수 있습니다.

좋은 분석 도구는 알아낸 사실과 아직 해석하지 못한 빈칸을 구분해서 돌려줍니다. readMemory()가 읽을 수 없는 영역을 0으로 꾸미지 않고 ??와 gaps로 표현하는 것도 같은 교훈을 줍니다. 이 메모리는 Ghidra에 로드된 Program의 메모리이며, 실행 중인 프로세스의 실시간 메모리를 읽는 기능은 아닙니다.

6-5. 프로세스·스레드: 로그 한 줄도 통신을 깨뜨릴 수 있습니다

cli.main()은 로그를 stderr로 보냅니다. headless.protect_stdout()는 원래 stdout을 복제한 뒤, 파일 디스크립터 1은 stderr로 향하게 하고 Python의 sys.stdout은 복제본을 사용하게 합니다.

이렇게 하면 JVM의 일반 출력이 MCP stdio 메시지에 섞이는 일을 막을 수 있습니다. MCP stdio 규격도 stdout에 유효한 MCP 메시지 외의 내용을 쓰지 않도록 요구합니다. 실습으로 로그와 프로토콜 출력을 같은 채널에 섞었을 때 생기는 문제를 도식화해 보세요.

6-6. 테스트: 대역 검사와 실제 도구 검사를 구분합니다

tests/conftest.py의 FakeBackend는 작은 HTTP 서버입니다. Python의 요청 인코딩과 오류 변환을 빠르게 검사하지만 Ghidra의 분석 정확도까지 검사하지는 않습니다. 실제 ELF·PE 분석은 tests/test_headless_integration.py가 담당합니다.

테스트 함수 정의는 백엔드 9개, CLI 3개, 서버 6개, 통합 12개입니다. 매개변수화로 실행 사례 수는 더 늘어날 수 있습니다. 통합 검사는 Ghidra 경로나 확장 JAR이 없으면 건너뛰도록 선언되어 있으므로, “테스트 명령이 끝남”과 “실제 Ghidra 검사가 수행됨”을 구분해서 읽어야 합니다.

7하드웨어 / 시스템 요구사항

운영체제 범위는 Ghidra 공식 설명 기준입니다. 모든 운영체제·Python 조합에서 GhidraMCP가 같은 수준으로 검증되었다는 의미는 아닙니다. 작은 연습용 바이너리에는 RAM 8GB 이상, IDE·GUI·AI 클라이언트를 함께 쓰면 16GB 정도를 실습용 출발점으로 권할 수 있습니다. 이 수치는 프로젝트의 공식 최소 사양이나 성능 측정값이 아닙니다.

7-1. GUI와 headless의 준비물 차이

GUI 모드는 Ghidra에서 프로그램을 열고 플러그인을 켜야 합니다. 포트 옵션은 GhidraMCP HTTP Server의 Server Port이며 기본값은 8080입니다. GhidraMCPPlugin의 옵션 설명에 따르면 변경 후 재시작 또는 플러그인 재로딩이 필요합니다.

headless 모드는 PyGhidra 선택 의존성과 확장 클래스가 필요합니다. 설치된 확장 대신 --extension-jar나 GHIDRA_MCP_EXTENSION_JAR로 JAR을 지정할 수도 있습니다. HeadlessSession._start_jvm()은 실제 로드된 클래스의 위치까지 확인해 다른 JAR이 가려지는 문제를 검사합니다.

macOS의 디컴파일러 네이티브 빌드 절차는 README에 별도로 안내되어 있습니다. 플랫폼 준비가 끝났다는 가정 없이, 해당 Ghidra 설치와 네이티브 구성부터 확인하는 편이 좋습니다.

7-2. 저장과 네트워크에서 헷갈리기 쉬운 점

--project가 없으면 임시 프로젝트를 만들고 종료 시 정리합니다. --project를 주면 변경 저장이 기본값이 되며, --save·--discard로 종료 시 변경 저장 여부를 지정할 수 있습니다. 임시 프로젝트에서 --save만 켜도 종료 후 그 임시 디렉터리는 삭제되므로 장기 보관에는 명시적 프로젝트 경로가 필요합니다.

_open_program()은 프로젝트 안에서 바이너리의 파일 이름으로 기존 항목을 찾습니다. 같은 이름의 파일 내용을 바꿨다고 자동으로 새 바이너리를 재가져오는 구조는 아닙니다. 다른 파일·버전을 비교할 때는 프로젝트를 분리하고 해시를 확인하는 습관이 필요합니다.

Java 백엔드는 루프백 전용입니다. Python에 URL 옵션이 있다고 Java 서버가 외부 인터페이스에 열리는 것은 아닙니다. AI 클라이언트가 외부 모델을 사용하면 도구 결과가 그 모델 제공자에게 전달될 수 있으며, 이 저장소는 모델 호출이나 데이터 전송 정책을 직접 관리하지 않습니다.

8직접 해볼 수 있는 실습 과제

실습 대상은 tests/fixtures/sample.c와 동봉된 x86-64 ELF·PE 파일입니다. 직접 만든 프로그램이나 분석 권한이 있는 파일을 사용하세요. 아래 명령은 준비된 학습 환경에서 따라 할 실행 예시입니다.

# 저장소 루트에서 사용하는 Python 서버 실행 예시
uv run ghidra-mcp --ghidra-server http://127.0.0.1:8080/

# URL로 연결하는 클라이언트를 위한 별도 실행 예시
uv run ghidra-mcp --transport streamable-http \
  --mcp-host 127.0.0.1 --mcp-port 8081 \
  --ghidra-server http://127.0.0.1:8080/

# Ghidra 설치·확장을 준비한 뒤 사용하는 예시
# 패키지의 headless 선택 의존성이 필요합니다.
uv run --extra headless ghidra-mcp --headless \
  --binary tests/fixtures/sample_x86_64.elf \
  --project ./practice-project --ready-timeout 300

실습의 완성은 그럴듯한 AI 설명을 얻는 일이 아니라, 주소와 조회 결과로 설명을 다시 확인하는 일입니다.

9관련 기술 심화 학습 로드맵

주당 3~5시간을 기준으로 한 학습 계획입니다. Python·Java가 모두 처음이라면 1~2주를 더 사용해 함수, 클래스, 예외, HTTP 기초를 익히세요. 매주 읽을 파일과 만들 결과물을 함께 정하면 학습 범위를 유지하기 쉽습니다.

6주차 확장 과제: 메모리 영역 하나의 정보를 조회한다면

1. 입력은 주소 하나, 결과는 영역 이름·시작·끝·권한으로 정합니다.
2. Ghidra 서비스에 조회 메서드를 넣되 GUI 화면과 HTTP 객체를 참조하지 않게 설계합니다.
3. Java GET 라우트와 Python MCP 도구를 각각 연결합니다.
4. 정상 주소·영역 밖 주소·잘못된 주소의 계약을 먼저 적습니다.
5. 가짜 백엔드 검사는 연결 계약을, 실제 Ghidra 검사는 영역 정보를 확인하도록 나눕니다.

새 도구 하나를 끝까지 연결해 보면, 언어 문법을 넘어 시스템의 경계를 설계하는 감각을 얻을 수 있습니다.

10핵심 키워드 사전

11참고 링크

저장소 · 릴리스 · 핵심 소스

• GhidraMCP 공식 저장소 · 릴리스 2.0
• 커밋 1e98025의 전체 코드 · 분석 범위를 고정한 기준점
• pyproject.toml · uv.lock · 버전 범위와 해결 결과
• src/ghidra_mcp/server.py · 도구 등록·입력·오류 변환
• src/ghidra_mcp/backend.py · HTTP 계약과 준비 상태
• src/ghidra_mcp/headless.py · JVM·프로젝트·저장 생명주기
• extension/src/main/java/com/lauriewired/ghidramcp/core/GhidraAnalysisService.java · 조회·수정·트랜잭션·디컴파일러 정리
• extension/src/main/java/com/lauriewired/ghidramcp/http/BackendHttpServer.java · 라우트·루프백·입력 경계
• tests/test_headless_integration.py · 실제 Ghidra 결과의 기대 동작
• .github/workflows/build.yml · 빌드 환경과 검사 범위

관련 기술의 공식 자료

• Ghidra 공식 저장소 · 분석 도구와 확장 생태계
• MCP 전송 규격 · stdio와 Streamable HTTP의 계약
• MCP Python SDK · FastMCP 관련 구현과 예제
• PyGhidra · Python에서 Ghidra를 사용하는 패키지
• uv 공식 문서 · Python 프로젝트·의존성 관리
• Hex-Rays 디컴파일러 개요 · 다른 분석 환경의 의사 코드 개념
• Binary Ninja MCP 공식 문서 · 대안 도구의 MCP 연결 방식
• 이 저장소의 Apache-2.0 라이선스 전문
• GitHub Trending Java Monthly · 순위는 조회 시점에 따라 달라집니다.

현재 상태 (2026-10-23 확인)