ghidra 딥다이브
— 실행 파일을 읽는 법에서 분석 도구를 설계하는 법까지

1프로젝트 한줄 요약

Ghidra는 컴파일된 프로그램을 읽고, 그 동작에 대한 가설을 쌓아 가는 분석 작업대입니다. README에 따르면 NSA의 Research Directorate가 개발·유지하는 프로젝트이며, Windows·Linux·macOS에서 사용할 수 있습니다. 실행 파일을 불러온 뒤 명령어를 읽고, 함수 사이의 관계를 따라가고, 변수 이름과 타입을 수정하며 이해를 구체화합니다.

Ghidra가 만드는 의사 코드는 원본 소스의 복원본이 아니라, 기계어의 동작을 사람이 읽도록 다시 표현한 분석 결과입니다. 컴파일 과정에서 사라진 주석·원래 변수 이름·코드 배치는 일반적으로 되돌릴 수 없습니다. 최적화가 심하면 여러 소스 표현이 같은 기계어가 되기도 합니다.

입력과 출력으로 이해하기

예를 들어 문자열을 출력하는 작은 프로그램을 가져오면, 문자열을 참조하는 명령어에서 호출 함수를 찾을 수 있습니다. 그 함수를 선택하면 디컴파일 창에서 조건과 호출 순서를 확인합니다. 의미를 알아낸 함수에 이름을 붙이면 다른 호출 지점에서도 이해가 쉬워집니다.

분석 흐름을 설명하는 개념 예시이며 실제 출력은 환경에 따라 달라집니다.
실행 파일의 바이트
    → 어셈블리 명령어
    → p-code 연산
    → 제어 흐름·데이터 흐름 분석
    → C 형태 의사 코드
    → 분석가의 이름·타입 보정

2왜 주목받는가

2-1. 공개된 분석 엔진 자체가 큰 학습 자산이다

TrendShift MONTHLY #24 선정과 2026-10-23 GitHub 기준 스타 93,306개, 포크 10,469개는 관심의 규모를 보여 줍니다. 다만 이 숫자만으로 특정 기능이 이번 달 상승을 이끌었다고 판단할 수는 없습니다. 다음은 저장소 구조와 공식 기능에서 해석할 수 있는 관심 요인입니다.

먼저, 디스어셈블과 디컴파일의 핵심을 소스로 공부할 수 있습니다. Ghidra/Features/Decompiler/src/decompile/cpp/에는 타입 추론·제어 흐름 복구·출력 코드가, Ghidra/Processors/에는 CPU 언어 정의가 있습니다. 결과 화면 뒤의 알고리즘까지 추적할 수 있다는 점이 교육 자료로서 강점입니다.

이 저장소의 학습 가치는 분석 결과를 얻는 데서 끝나지 않고, 그 결과가 만들어지는 경로를 끝까지 따라갈 수 있다는 데 있습니다.

2-2. GUI에서 익힌 작업을 자동화로 이어 갈 수 있다

README는 대화형 사용과 자동 실행을 함께 지원한다고 설명합니다. 소스에도 AnalyzeHeadless·HeadlessAnalyzer와 Java 스크립트 기반 클래스 GhidraScript가 있습니다. PyGhidra는 CPython에서 JVM을 시작하고 Java 분석 객체를 사용하도록 연결합니다. 따라서 작은 GUI 실습에서 시작해 함수 목록 추출이나 여러 파일의 반복 분석으로 확장할 수 있습니다.

이것을 “AI가 자동으로 모든 의미를 알아낸다”고 해석하면 곤란합니다. 여기서 설명하는 분석 경로는 파일 로더, 명령어 의미 정의, 분석기, 디컴파일러의 조합입니다. 이름과 타입이 부족한 지점에서는 사람의 검토가 여전히 중요합니다.

2-3. 비교할 때는 가격표보다 학습 목적을 먼저 정한다

비교 범위의 출처는 IDA Free 공식 안내, Binary Ninja 공식 소개, radare 공식 도구 목록입니다(2026-10-23 기준). 에디션별 기능과 이용 조건은 달라질 수 있습니다. 위 표는 속도·정확도 순위를 매긴 벤치마크가 아닙니다.

2-4. 최신 릴리스와 개발 코드는 다른 기준이다

2026-10-23 GitHub 기준 최신 공개 릴리스는 Ghidra_12.2_build이며 공개일은 2026-10-22입니다. 반면 커밋 16400303의 Ghidra/application.properties에는 application.version=12.3, application.release.name=DEV가 적혀 있습니다.

즉, “최신 릴리스 12.2”와 “분석 코드 12.3 DEV”는 서로 다른 대상을 가리킵니다. 아래 API와 의존성 버전은 모두 후자를 기준으로 읽어야 합니다. 특정 최신 기능이 12.2 배포판에도 그대로 들어 있다고 가정하지 않습니다.

3기술 스택 전체 지도

Ghidra의 중심은 Java 데스크톱 애플리케이션입니다. 여기서 프론트엔드는 분석 창과 상호작용, 백엔드는 분석 모델과 엔진을 뜻합니다. 브라우저와 HTTP 서버로 나뉘는 일반적인 웹앱 구성을 떠올리면 구조를 잘못 읽기 쉽습니다.

3-1. 백엔드: Java 모델과 C++ 분석 엔진

버전은 저장소의 선언값이며, 전체 전이 의존성을 해석한 결과는 아닙니다. C++의 언어 표준이나 모든 컴파일러 버전은 위 파일 하나만으로 고정된다고 말할 수 없습니다.

3-2. 프론트엔드: Swing과 Docking

Ghidra/Framework/Docking/과 Ghidra/Framework/Gui/가 창·패널·액션 같은 기반을 제공합니다. PluginTool은 AbstractDockingTool을 확장합니다. 함수 목록, 바이트 보기, 디컴파일 창을 하나의 도구 안에서 연결하는 방식입니다.

그래서 React·Vue·Electron 버전을 찾는 것이 이 프로젝트의 UI를 이해하는 출발점은 아닙니다. 중요한 것은 어느 플러그인이 패널을 만들고, 어느 서비스가 현재 프로그램을 제공하며, 어떤 이벤트로 선택 위치를 공유하는가입니다.

Swing의 화면 이벤트는 이벤트 디스패치 스레드에서 처리합니다. 오래 걸리는 분석을 이 스레드에서 기다리면 창의 입력과 다시 그리기가 밀립니다. 실제로 AutoAnalysisManager.scheduleWorker()는 Swing 스레드에서 호출하는 경우를 검사합니다. 기본 원리는 Oracle의 Swing 스레드 설명과 연결해서 읽을 수 있습니다.

3-3. 스크립팅: Java와 CPython을 잇는 PyGhidra

패키지의 허용 버전 범위와 배포판에 동봉하는 파일의 버전은 다른 정보입니다. api.py의 start()는 JVM과 Headless 환경을 초기화합니다. 즉, PyGhidra는 Ghidra 분석 엔진을 Python으로 새로 구현한 라이브러리가 아닙니다.

3-4. 인프라·빌드·CI

Ghidra/application.properties의 실제 설정 일부
application.version=12.3
application.release.name=DEV
application.gradle.min=9.1
application.java.min=25
application.java.compiler=25
application.python.supported=3.15, 3.14, 3.13, 3.12, 3.11, 3.10, 3.9

README.md는 빌드에 Gradle 9.1.0 이상을 안내하고, Ghidra/RuntimeScripts/support/gradle/gradle-wrapper.properties는 배포 URL에 Gradle 9.8.0을 지정합니다. 최소 요구와 래퍼가 선택한 버전을 구별해야 합니다. settings.gradle은 Framework·Features·Processors 등 여러 하위 프로젝트를 포함합니다.

gradle/support/fetchDependencies.gradle에는 Maven 밖에서 받는 파일의 URL·SHA-256·목적지가 있습니다. 예를 들어 Z3_VER="4.13.0", postgresql-15.18.tar.gz를 확인할 수 있습니다. 이들은 특정 기능과 배포 준비를 위한 의존성이며, 모든 분석에서 함께 실행되는 서비스 목록은 아닙니다.

4아키텍처 심화 분석

4-1. 시스템을 데이터 흐름으로 펼쳐 보기

이 그림의 화살표는 학습용 요약입니다. 자동 분석이 모든 함수를 미리 디컴파일한다는 뜻은 아닙니다. DecompInterface.decompileFunction()은 특정 함수를 요청하는 별도의 API이고, 분석기 가운데 디컴파일 결과를 활용하는 구성도 있습니다.

Headless와 자동 가져오기 API의 중심은 Ghidra/Features/Base/src/main/java/ghidra/app/util/importer/ProgramLoader.java입니다. 내부 Builder.getLoadSpec()은 LoaderService.getSupportedLoadSpecs()로 후보를 받고, 언어·컴파일러 힌트가 있으면 해당 선택기를 사용합니다. 힌트가 없으면 CHOOSE_THE_FIRST_PREFERRED를 사용합니다. GUI의 단일 파일 가져오기는 별도로 ImporterDialog에서 선택한 LoadSpec을 Ghidra/Features/Base/src/main/java/ghidra/plugin/importer/ImporterUtilities.java의 importSingleFile()에 전달해 로더를 호출합니다.

Ghidra/Features/Base/src/main/java/ghidra/app/util/opinion/ElfLoader.java의 findSupportedLoadSpecs()는 ELF 헤더에서 기계 종류·비트 수·엔디언 정보를 읽어 후보를 좁힙니다. 파일 확장자가 같다고 항상 같은 언어로 해석하는 구조가 아닙니다. 잘못된 CPU나 엔디언 선택은 다음 분석 전체를 흔들 수 있습니다.

4-2. 패턴 ①: 플러그인과 서비스 조회로 기능을 연결한다

큰 프로그램에서 모든 창이 서로의 구체 클래스를 직접 호출하면 결합이 급격히 커집니다. Ghidra는 PluginTool에 기능을 올리고, 서비스 인터페이스를 통해 필요한 능력을 찾는 구조를 사용합니다. 이를 플러그인 구조와 서비스 로케이터로 읽을 수 있습니다.

PluginTool.java의 실제 메서드
public <T> T getService(Class<T> c) {
    return serviceMgr.getService(c);
}

Ghidra/Framework/Project/src/main/java/ghidra/framework/plugintool/PluginManager.java의 addPlugins(Plugin[])는 플러그인의 initServices()를 먼저 호출합니다. 이어 resolveDependencies()로 미해결 의존성을 확인하고, 서비스 순서를 고려한 뒤 init()에서 서비스를 획득하게 합니다.

여기서 중요한 것은 “클래스를 동적으로 읽는다”보다 서비스 공개 → 의존성 확인 → 초기화의 생명주기입니다. 플러그인 파일만 추가한다고 기능이 완성되는 것이 아니라, 필요한 서비스가 언제 준비되는지까지 설계해야 합니다.

배울 점: 생성자 인자만으로 의존성을 주입하는 방식과 비교해 보세요. 서비스 조회는 실행 중 기능 구성을 유연하게 하지만, 누락된 의존성을 실행 시점에 발견할 수 있으므로 검증 경로가 중요합니다.

4-3. 패턴 ②: CPU별 의미를 공통 중간 표현으로 옮긴다

프로세서가 바뀔 때마다 디컴파일러 전체를 새로 만들면 유지보수가 어렵습니다. Ghidra는 SLEIGH로 명령어의 비트 패턴과 의미를 정의하고, p-code라는 공통 표현을 사용합니다. CPU마다 다른 명령어를 공통 의미 표현으로 바꾸면, 여러 분석 기능이 같은 기반을 공유할 수 있습니다.

입문용으로는 Ghidra/Processors/Toy/data/languages/toyInstructions.sinc가 좋습니다. 다음은 그 파일의 add 정의에서 공백과 줄바꿈을 정리한 것입니다.

:add rs, rt is $(INSTR_PHASE)
    op1215=0xc & op0811=0x0 & rs & rt {
    addflags(rs, rt);
    rs = rs + rt;
    resultflags(rs);
}

콜론 뒤는 표시할 명령어와 피연산자이고, is 뒤는 어떤 비트 패턴에서 이 정의가 선택되는지를 나타냅니다. 중괄호 안은 명령어의 동작을 정의합니다. 덧셈뿐 아니라 플래그 변화도 포함하므로, rs = rs + rt만 보면 명령어의 효과를 놓치게 됩니다.

toy_le.slaspec은 ENDIAN="little", SIZE="4"를 정하고 공통 정의를 포함합니다. toy.sinc에는 ram·register 주소 공간과 r0부터 pc까지의 레지스터가 있습니다. 언어 정의는 단순한 명령어 이름 사전보다 훨씬 넓은 모델입니다.

Java 쪽 연결 지점은 Ghidra/Framework/SoftwareModeling/src/main/java/ghidra/app/plugin/processors/sleigh/SleighLanguage.java의 parse()와, 같은 디렉토리의 SleighInstructionPrototype.java의 getPcode()입니다. 후자는 의미 템플릿을 바탕으로 PcodeEmitObjects를 구성하고, 상대 주소와 후속 흐름을 정리해 연산을 반환합니다.

GUI와 DecompInterface를 통한 디컴파일에서는 C++ 엔진이 명령어의 p-code를 Java에 요청할 수 있습니다. DecompileCallback의 getPcode()는 명령어 프로토타입의 getPcodePacked()를 호출해 응답을 만듭니다. C++ 쪽에도 SLEIGH 번역 구현이 있지만, 공유되는 의미 정의와 실제 요청·응답 경로를 구분해 읽어야 합니다.

4-4. 패턴 ③: 변경 이벤트를 모아 우선순위 작업으로 처리한다

AutoAnalysisManager는 분석기들을 ClassSearcher.getInstances(Analyzer.class)로 찾고, canAnalyze(program)을 통과한 분석기를 종류별 목록에 둡니다. Analyzer 인터페이스에는 getPriority()·added()·removed()·analysisEnded()가 정의되어 있습니다.

같은 관리자의 createDomainObjectListener()는 함수 추가·함수 시그니처 변경·코드 추가 등의 이벤트를 받아 해당 분석 목록에 알립니다. 이어 AnalysisScheduler가 주소 집합을 모으고, AnalysisTask를 우선순위 큐에 예약합니다. 이를 관찰자 방식의 변경 감지와 명령 객체 기반 작업 처리의 조합으로 이해할 수 있습니다.

AnalysisScheduler.java의 핵심 조건을 그대로 발췌
if (!scheduled && (!addSet.isEmpty() || !removeSet.isEmpty())) {
    analysisMgr.schedule(
        new AnalysisTask(this, analysisMgr.getMessageLog()),
        getPriority());
    scheduled = true;
}

이 조건의 의미는 “알림 한 번마다 새 작업을 무조건 만들지 않는다”입니다. added()는 addSet.add(set)으로 범위를 누적하고, 이미 예약되어 있으면 중복 예약을 피합니다. 변경을 모아 처리하는 방식은 편집기·검색 색인·데이터 동기화에도 응용할 수 있습니다.

AutoAnalysisManager.schedule()은 queue.add(cmd, priority) 후 백그라운드 분석 시작을 요청합니다. 이 관리자의 설명에서 숫자가 작을수록 높은 우선순위라고 명시합니다. “우선순위가 크다”는 일상 언어를 그대로 수치 비교로 옮기지 마세요.

또한 Analyzer.java는 클래스 이름이 Analyzer로 끝나야 검색된다고 설명합니다. 인터페이스 구현만 확인하고 끝내지 말고, 확장 지점을 찾는 규약도 확인해야 한다는 사례입니다.

4-5. 패턴 ④: 외부 프로세스를 감싸는 파사드와 재초기화

Ghidra/Features/Decompiler/src/main/java/ghidra/app/decompiler/DecompInterface.java는 디컴파일러 프로세스를 사용하는 상위 인터페이스입니다. openProgram()으로 프로그램을 연결하고, decompileFunction()으로 함수를 요청하며, dispose()로 정리합니다.

파사드는 복잡한 하위 절차를 소수의 사용 지점으로 감싼다는 뜻입니다. 여기서는 실행 파일 경로·파이프 통신·초기 설정·콜백·취소 같은 세부 절차가 API 뒤에 있습니다. 같은 인스턴스의 요청 메서드는 synchronized이므로, 하나를 공유하면 무제한으로 병렬 처리된다고 생각하면 안 됩니다.

DecompInterface.decompileFunction() 내부의 요청 호출
decompProcess.sendCommandTimeout("decompileAt", timeoutSecs, activeSet);

DecompileProcess.setup() 내부의 프로세스·파이프 준비
nativeProcess = runtime.exec(exepath);
nativeIn = nativeProcess.getInputStream();
nativeOut = nativeProcess.getOutputStream();

즉, 핵심 디컴파일 연결을 단순히 “JNI로 C++ 함수를 직접 호출한다”고 설명하면 틀립니다. DecompileProcess는 별도의 실행 파일을 시작하고 표준 입출력 파이프를 사용합니다. 분석 도중 C++ 쪽이 프로그램의 바이트·타입 등 추가 정보를 요청하면 Java의 콜백 경로가 응답합니다.

C++ 수신부는 Ghidra/Features/Decompiler/src/decompile/cpp/ghidra_process.cc의 DecompileAt::rawAction()입니다. 요청 주소의 함수를 찾아 현재 분석 액션의 reset()·perform()을 수행하고, 설정에 따라 분석 구조와 C 형태의 출력을 직렬화합니다.

분석 패스 구성은 같은 디렉토리의 coreaction.cc, ActionDatabase::universalAction()에서 볼 수 있습니다. ActionHeritage, ActionDeadCode, ActionInferTypes 같은 작업과 반복 적용 그룹을 조립합니다. 디컴파일을 문자열 치환으로 이해하기보다 여러 분석을 순서와 반복 조건에 맞춰 적용하는 과정으로 보게 되는 지점입니다.

DecompInterface.initializeProcess()는 프로세스 준비 상태를 확인하고 필요하면 다시 확보해 언어·컴파일러·타입 설정을 등록합니다. 이 구조는 네이티브 도구 실패 후 다음 요청을 준비하는 데 도움이 됩니다. 다만 실패했던 함수의 결과까지 자동으로 성공 처리한다는 의미는 아닙니다. 호출자는 완료 상태와 오류를 확인해야 합니다.

분석 지식은 어디에 남는가

Ghidra/Framework/SoftwareModeling/src/main/java/ghidra/program/database/ProgramDB.java의 createManagers()는 MemoryMapDB·CodeManager·FunctionManagerDB 등을 만듭니다. 모델의 메모리·명령어·함수를 한 프로그램 객체 아래에 묶는 구조입니다.

변경의 경계는 DomainObjectAdapterDB.startTransaction()·endTransaction()으로 관리합니다. 아래의 자체 저장 계층 Ghidra/Framework/DB/src/main/java/db/DBHandle.java에도 트랜잭션 API가 있습니다. 함수 이름을 고치거나 타입을 정의하는 작업이 단순한 화면 문자열 편집으로 끝나지 않는 이유입니다.

5디렉토리 구조 해부

5-1. 세 축을 먼저 구분한다

settings.gradle은 이 디렉토리들을 Gradle 하위 프로젝트로 포함합니다. 따라서 디렉토리 이름은 단순한 정리 방식에 그치지 않고 빌드 경계와 연결됩니다. 모듈의 build.gradle에서 api project(':Base') 같은 선언을 보면 다른 모듈과의 의존 관계를 확인할 수 있습니다.

Ghidra/Processors/ 바로 아래 디렉토리는 39개입니다. 이는 폴더 수이며, 지원 CPU·명령어 집합·변형 언어의 정확한 개수가 아닙니다. 한 모듈에 여러 비트 수·엔디언·컴파일러 구성이 들어갈 수 있습니다.

5-2. 모듈 안에서도 목적별로 갈라진다

• Ghidra/Features/Base/src/main/java/: JVM에서 실행되는 구현의 예입니다. 클래스 이름에서 시작해 인터페이스와 호출자를 찾습니다.
• Ghidra/Features/Base/src/main/resources/: 이미지·기본 도구 구성 등 실행 시 읽는 자원입니다. Java 파일만 읽으면 초기 설정을 놓칠 수 있습니다.
• Ghidra/Processors/Toy/data/languages/: 프로세서 언어 정의의 예입니다. .ldefs는 언어 목록과 명세 파일의 연결을, .cspec은 호출 규약 등 컴파일러 명세를 정의합니다.
• Ghidra/Features/Base/ghidra_scripts/: 도구 안에서 사용하는 스크립트 예제입니다. 전체 프레임워크보다 짧은 진입점입니다.
• Ghidra/Features/Base/src/test/·Ghidra/Features/Base/src/test.slow/: 테스트와 통합 환경이 필요한 검증입니다. 공통 Gradle 설정도 함께 봅니다.
• Ghidra/Features/Decompiler/src/decompile/cpp/: 네이티브 엔진입니다. 일반 Java 모듈 구조 안에 다른 언어의 큰 구현이 들어 있는 사례입니다.

5-3. 처음 읽을 파일 다섯 개

1. Ghidra/Features/Base/ghidra_scripts/HelloWorldScript.java — 상속과 run()만으로 실행 진입점을 이해합니다.
2. Ghidra/Features/Base/src/main/java/ghidra/app/services/Analyzer.java — 분석기가 지켜야 하는 계약을 읽습니다.
3. Ghidra/Features/Base/src/main/java/ghidra/app/plugin/core/analysis/AnalysisScheduler.java — 변경 범위 누적과 중복 예약 방지를 읽습니다.
4. Ghidra/Processors/Toy/data/languages/toyInstructions.sinc — 간단한 명령어의 비트 패턴과 의미를 연결합니다.
5. Ghidra/Features/Decompiler/src/main/java/ghidra/app/decompiler/DecompInterface.java — Java 코드에서 네이티브 분석을 사용하는 경계를 읽습니다.

6학습 포인트 (기술별)

6-1. Java: 상속보다 먼저 계약과 생명주기를 읽는다

GhidraScript는 스크립트의 실행 환경을 제공하고, 작성자는 run()에 작업을 넣습니다. HelloWorldScript.java는 이 구조를 가장 짧게 보여 줍니다. 다음 예제는 그 진입 방식에 함수 목록 순회를 더한 학습용 코드입니다. 파일 이름은 클래스와 같은 ListFunctions.java로 둡니다.

import ghidra.app.script.GhidraScript;
import ghidra.program.model.listing.Function;
import ghidra.program.model.listing.FunctionIterator;

public class ListFunctions extends GhidraScript {
    @Override
    public void run() throws Exception {
        if (currentProgram == null) {
            println("프로그램을 먼저 여세요.");
            return;
        }

        FunctionIterator functions = currentProgram
            .getFunctionManager().getFunctions(true);
        int count = 0;
        while (functions.hasNext() && !monitor.isCancelled()) {
            Function function = functions.next();
            println(function.getEntryPoint() + "\t" + function.getName());
            count++;
        }
        println("순회한 함수 수: " + count);
    }
}

currentProgram은 현재 분석 프로그램, monitor는 진행·취소 확인 객체입니다. getFunctions(true)는 외부 함수를 제외하고 진입 주소의 오름차순으로 순회합니다. 여기서 얻는 함수는 현재 모델에 정의된 함수이며, 파일에 존재할 가능성이 있는 모든 함수를 완전하게 찾았다는 보장은 아닙니다.

실습 아이디어: 이름이 FUN_으로 시작하는 함수 수와 전체 수를 따로 출력하세요. 단, 이름 규칙은 분석 상태에 영향을 받습니다. “이름이 기본값이다”와 “악성이다” 같은 결론을 연결하지 마세요.

6-2. 자료구조: 주소 범위와 우선순위 큐를 제품 안에서 이해한다

AddressSet은 관련 주소 범위를 모으는 데 쓰이고, AnalysisScheduler는 추가·삭제 범위를 따로 유지합니다. 단순한 정수 목록 대신 주소 공간과 범위 개념을 다루는 이유를 생각해 보세요. 서로 다른 주소 공간에 있는 같은 수치가 같은 위치를 뜻하지 않을 수 있습니다.

실습 아이디어: 종이에 주소 범위 0x1000~0x100f와 0x1008~0x1017를 겹쳐 그려 보세요. 이어 같은 분석기에 알림이 두 번 왔을 때 범위를 합쳐 처리하는 것과 작업 두 개를 따로 만드는 것의 비용을 비교합니다. 이는 실제 실행 결과를 주장하는 예제가 아니라 범위 누적의 원리를 익히는 연습입니다.

읽을 질문: 작업의 순서가 필요한 이유는 무엇인가요? 명령어가 아직 정의되지 않았는데 함수 분석이 먼저 실행되면 어떤 정보가 부족할까요? 스케줄러를 읽을 때는 큐의 구현뿐 아니라 생산되는 정보 사이의 선후 관계를 확인하세요.

6-3. 컴파일러: 제어 흐름과 데이터 흐름을 구분한다

coreaction.cc의 ActionHeritage와 ActionInferTypes를 한 번에 완독하려 하지 마세요. 먼저 “같은 레지스터가 여러 번 덮어써질 때 각각의 값을 어떻게 구분할까?”, “어떤 연산이 타입 추론의 단서가 될까?”라는 질문을 만듭니다. 그다음 관련 액션이 전체 순서 어디에 놓이는지 확인합니다.

값의 버전을 구분하는 학습용 개념 예시
원래 표현:  r = 1; r = r + 2;
값을 구분:  r_1 = 1; r_2 = r_1 + 2;

분기 뒤에는 어느 경로의 값인지 합치는 표현이 필요할 수 있습니다.
경로 A: x_A = 10
경로 B: x_B = 20
합류점: x_C = 경로에 따라 x_A 또는 x_B

위 표기는 실제 Ghidra 출력이 아니라 SSA를 이해하기 위한 설명입니다. SSA는 각 값의 정의를 한 번으로 구분하는 표현 방식입니다. 같은 화면 변수 이름을 여러 값으로 추적할 수 있어 상수 전파나 사용 관계 분석에 도움이 됩니다.

실습 아이디어: 직접 작성한 조건문 함수의 원본과 의사 코드를 나란히 놓고, 어떤 분기가 합쳐지거나 사라졌는지 표시하세요. 코드 모양이 다르다는 이유만으로 틀렸다고 판단하지 말고, 가능한 입력별 동작을 비교합니다.

6-4. Python 연동: 실행 환경과 자원 소유권을 함께 읽는다

Ghidra/Features/PyGhidra/src/main/py/src/pyghidra/api.py의 program_context()는 프로그램과 소비자 객체를 얻고, finally에서 program.release(consumer)를 호출합니다. Python의 with가 Java 객체의 사용 종료와 이어지는 사례입니다.

이미 만든 Study 프로젝트와 /sample 프로그램을 여는 학습 예제
PyGhidra 설치 및 Ghidra 설치 경로 설정이 먼저 필요합니다.
import pyghidra

pyghidra.start()
project = pyghidra.open_project("study-projects", "Study")
try:
    with pyghidra.program_context(project, "/sample") as program:
        print(program.getName())
        print(program.getFunctionManager().getFunctionCount())
finally:
    project.close()

open_project()는 기본적으로 기존 프로젝트를 엽니다. 위 예제는 실행 파일 가져오기를 대신하지 않으며, 프로젝트 내부 경로도 실제 이름에 맞춰야 합니다. 학습 중에는 편의 함수가 자동으로 처리하는 일과 직접 관리하는 일을 표로 적어 보세요.

실습 아이디어: consume_program()과 program_context()를 비교해서, 예외가 발생해도 어느 코드가 프로그램 참조를 놓아주는지 설명해 보세요. Python의 가비지 컬렉션만 믿고 외부 실행 환경의 생명주기를 생략하면 안 되는 이유를 배울 수 있습니다.

6-5. 동시성·트랜잭션: 빠른 분석보다 먼저 일관성을 생각한다

확장 기능을 잘 만드는 첫 조건은 정상 결과뿐 아니라 취소·실패·정리의 경계를 정확하게 다루는 것입니다. 분석 도중 사용자가 취소할 수 있고, 네이티브 프로세스가 실패할 수 있으며, 모델 변경이 중간에 멈출 수도 있습니다.

모델을 수정하는 일반 Java 코드에서는 트랜잭션의 성공 여부를 명시해야 합니다. 아래는 이미 트랜잭션을 관리하는 스크립트 실행 틀과 구분해서 읽을 개념 예제입니다. 전제는 program이 열려 있고, 호출자가 변경 경계를 관리하는 환경이라는 것입니다.

int tx = program.startTransaction("분석 메모 갱신");
boolean commit = false;
try {
    // 여기에서 프로그램 모델을 수정합니다.
    commit = true;
}
finally {
    program.endTransaction(tx, commit);
}

핵심은 finally와 성공 플래그입니다. 실제 기능을 작성할 때는 상위 실행 틀이 이미 트랜잭션을 열었는지도 확인해야 합니다. 이 예제의 빈 본문만 복사하는 것으로 변경·되돌리기 동작이 검증되지는 않습니다.

6-6. 테스트: 무엇을 보장하는지 문장으로 바꿔 읽는다

Ghidra/Features/Decompiler/src/test.slow/java/ghidra/app/decompiler/component/DecompilerCachingTest.java는 새 함수로 이동하면 캐시 미스가 증가하는지, 이전 함수로 돌아오면 히트가 증가하는지 검사합니다. 성능과 관련된 기능도 시간 측정만으로 검증할 필요는 없다는 사례입니다.

Ghidra/Framework/SoftwareModeling/src/test/java/ghidra/sleigh/grammar/SleighPreprocessorTest.java의 testExternal()은 입력·기대 출력 파일을 연결하고 결과를 줄 단위로 비교합니다. 파서 주변 기능에서는 사람이 읽을 수 있는 작은 기대 결과가 중요한 자산이 됩니다.

실습 아이디어: 두 테스트에서 각각 하나의 검증 문장을 골라 “어떤 사전 상태에서, 어떤 행동 뒤에, 무엇이 같아야 하는가”로 다시 적어 보세요. 이름에 테스트가 들어간 파일을 세는 것보다 기능의 계약을 이해하는 데 도움이 됩니다.

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

7-1. 기본 실행의 공식 요구사항

다음 하한은 커밋 16400303의 GhidraDocs/GettingStarted.md 기준입니다. 운영체제 목록에 적힌 하한만으로 최신 JDK와 모든 네이티브 구성 요소의 호환성이 보장되는 것은 아닙니다. 실제 배포판의 안내도 함께 확인해야 합니다.

Debugger와 PyGhidra를 함께 쓰려면 두 범위의 공통 부분을 확인해야 합니다. 문서상 Python 지원 범위와 선택한 JPype·디버거 패키지가 실제 환경에 설치 가능한지는 별도로 확인할 문제입니다.

7-2. 공부를 위한 현실적인 준비

위 권장은 공식 최소 사양과 구분한 학습 환경 제안입니다. GPU는 인용한 최소 요구 목록에 없습니다. 기본 실습을 위해 특정 GPU 성능이나 CUDA 환경을 준비할 근거는 없습니다. CPU 코어 수에 비례해 모든 분석 단계가 같은 비율로 빨라지는 것도 아닙니다.

7-3. JVM 힙과 전체 메모리는 다르다

Ghidra/RuntimeScripts/support/analyzeHeadless는 MAXMEM_DEFAULT=2G를 지정합니다. 환경변수 GHIDRA_MAXMEM 또는 Headless 전용 GHIDRA_HEADLESS_MAXMEM으로 바꿀 수 있습니다. launch.sh가 이 값을 JVM의 -Xmx로 전달합니다.

JVM 힙 상한을 2GB로 설정해도, C++ 디컴파일러와 운영체제를 포함한 전체 메모리 사용량이 2GB로 제한되지는 않습니다. 별도 프로세스와 JVM의 다른 메모리 영역도 있기 때문입니다. GUI의 ghidraRun은 MAXMEM_DEFAULT가 비어 있으므로 Headless의 기본값을 GUI에도 그대로 적용하면 안 됩니다.

배포판에서 쓰는 Headless 실행 옵션의 학습 예시
mkdir -p study-projects
GHIDRA_HEADLESS_MAXMEM=4G ./support/analyzeHeadless \
  study-projects Study \
  -import samples/sample \
  -analysisTimeoutPerFile 120 \
  -max-cpu 2

-analysisTimeoutPerFile은 파일별 자동 분석 시간 제한 옵션이고, -max-cpu는 분석에서 사용할 CPU 수를 제한하는 옵션입니다. 모든 스크립트·입출력·전체 프로세스에 대한 강제 종료 시간으로 해석하지 마세요. 작은 실습부터 완료 상태와 로그를 읽으며 값을 조정합니다.

7-4. 사용과 개발은 준비물이 다르다

공식 배포판을 사용하는 실습은 전체 소스 빌드를 요구하지 않습니다. 자체 빌드에는 README 기준 GCC 또는 Clang과 make가 필요하고, Windows에는 Visual Studio 2017 이상 또는 C++ Build Tools의 MSVC·Windows SDK·C++ ATL 구성이 안내되어 있습니다.

일부 빌드 타깃이 FreeBSD·OpenBSD를 포함한다는 사실과, 시작 안내가 공식 지원 플랫폼으로 Windows·Linux·macOS를 나열한다는 사실도 구분해야 합니다. 빌드 정의에 타깃 문자열이 있다는 것만으로 모든 환경에서 배포·실행이 검증되었다고 결론 내리지 않습니다.

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

연습 대상은 직접 작성한 작은 프로그램으로 통일합니다. 실행 파일 자체를 실행하지 않아도 가져오기·함수 탐색·디컴파일을 공부할 수 있습니다. 아래 명령과 스크립트는 학습 환경에서 수행할 예시이며, 사용하는 배포판의 JDK·API 요구사항을 먼저 맞춥니다.

실습의 완료 기준은 도구가 한 번 실행되는 것이 아니라, 입력이 어떤 분석 결과로 바뀌었는지 근거를 들어 설명하는 것입니다.

#include <stdio.h>

int adjust(int value) {
    if (value < 10) {
        return value + 3;
    }
    return value * 2;
}

int main(int argc, char **argv) {
    printf("%d\n", adjust(argc));
    return 0;
}

gcc -O0 -g -o sample-debug sample.c
gcc -O2 -o sample-opt sample.c

import ghidra.app.script.GhidraScript;
import ghidra.app.decompiler.DecompInterface;
import ghidra.app.decompiler.DecompileResults;
import ghidra.program.model.listing.Function;

public class DecompileSelection extends GhidraScript {
    @Override
    public void run() throws Exception {
        if (currentProgram == null || currentAddress == null) {
            println("프로그램과 함수 안의 주소를 선택하세요.");
            return;
        }
        Function function = getFunctionContaining(currentAddress);
        if (function == null) {
            println("선택한 주소를 포함하는 함수가 없습니다.");
            return;
        }

        DecompInterface decompiler = new DecompInterface();
        try {
            if (!decompiler.openProgram(currentProgram)) {
                println(decompiler.getLastMessage());
                return;
            }
            DecompileResults result = decompiler
                .decompileFunction(function, 30, monitor);
            if (result.decompileCompleted() &&
                    result.getDecompiledFunction() != null) {
                println(result.getDecompiledFunction().getC());
            }
            else {
                println("완료되지 않음: " + result.getErrorMessage());
                println("시간 초과: " + result.isTimedOut());
                println("취소 여부: " + result.isCancelled());
            }
        }
        finally {
            decompiler.dispose();
        }
    }
}

mkdir -p study-projects
./support/analyzeHeadless study-projects BatchStudy \
  -import samples \
  -recursive \
  -scriptPath study-scripts \
  -postScript ListFunctions.java \
  -analysisTimeoutPerFile 120 \
  -max-cpu 2

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

주당 4~6시간을 공부하는 입문자를 가정한 제안입니다. Java와 C가 모두 처음이라면 앞의 두 주를 늘리세요. 한 번에 전체 엔진을 읽기보다, 매주 설명 가능한 작은 결과물 하나를 남기는 편이 학습의 진척을 확인하기 쉽습니다.

배경 지식이 다르면 입구도 바꾼다

• Java 경험이 있다면: 서비스 조회와 스케줄러를 먼저 읽고, 주소·명령어 모델로 내려갑니다. 문법보다 도메인 모델이 새 학습 대상입니다.
• Python 경험이 있다면: PyGhidra의 프로젝트 열기·프로그램 참조 해제를 먼저 익힙니다. JVM 초기화와 Java 객체 생명주기도 함께 배웁니다.
• C/C++ 경험이 있다면: 작은 바이너리에서 출발해 SLEIGH와 p-code를 연결합니다. 이어 ghidra_process.cc의 요청 처리와 분석 액션 조립을 읽습니다.
• 웹 개발 경험이 있다면: API 요청·응답 대신 이벤트·작업 큐·서비스·프로그램 모델이라는 축으로 시스템을 다시 그려 봅니다.

10핵심 키워드 사전

용어를 외운 뒤에는 짝을 만들어 설명해 보세요. “SLEIGH는 의미를 정의하고 p-code는 그 의미를 공통 연산으로 표현한다”, “ProgramDB는 지식을 저장하고 Analyzer는 지식을 더한다”처럼 관계로 말하면 소스 구조가 더 잘 기억됩니다.

11참고 링크

11-1. 공식 저장소와 시작 문서

• 공식 저장소 — NationalSecurityAgency/ghidra
• Ghidra 12.2 릴리스 — 공개 배포판 확인
• README — 기능 범위와 설치·빌드 안내
• GettingStarted — 실행 환경·지원 플랫폼·설치 구분
• 개발자 안내 — 빌드와 IDE 개발 환경
• 공식 GhidraClass 교육 자료
• SLEIGH와 p-code 언어 문서
• 공식 보안 권고 — 배포판별 공지 확인

11-2. 본문의 핵심 코드로 바로 가기

• ProgramLoader — 가져오기 구성과 LoadSpec 선택
• ElfLoader — ELF 헤더와 언어 후보 연결
• PluginManager — 서비스 공개와 의존성 해결
• ProgramDB — 분석 모델의 관리자 구성
• AutoAnalysisManager — 이벤트와 작업 실행 연결
• AnalysisScheduler — 주소 범위 누적과 중복 예약 방지
• Toy SLEIGH — 명령어 패턴과 의미 정의
• DecompInterface — 함수 단위 디컴파일 요청
• DecompileProcess — 네이티브 프로세스·파이프·프로토콜
• ghidra_process.cc — C++ 요청 처리
• coreaction.cc — 분석 액션과 반복 그룹 조립
• PyGhidra API — JVM 초기화·프로그램 참조·트랜잭션

11-3. 빌드 설정과 관련 기술

• application.properties — 개발 버전과 실행 요구사항
• Generic 의존성 — 라이브러리의 실제 선언 버전
• PyGhidra 의존성 — Python·JPype의 허용 범위
• 외부 의존성 다운로드 목록 — 버전·URL·SHA-256
• 기본 CI — JDK 선택과 배포 빌드
• Dockerfile — 릴리스용 이미지와 JDK 설정 대조
• Oracle Swing 문서 — 이벤트 디스패치 스레드의 원리 (JDK 8 시대의 기초 설명)
• JPype 공식 문서 — Python과 Java 객체 연결
• Gradle 공식 문서 — 여러 프로젝트를 묶는 빌드
• TrendShift — 트렌딩 프로젝트 탐색

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

11-5. 언어별 규모와 집계 범위

커밋 16400303 기준 파일의 줄바꿈 문자 수를 합산한 값입니다. 주석·빈 줄·테스트·예제·생성된 소스·저장소 안의 타사 코드를 포함합니다. XML 형태의 .cspec·.ldefs 등은 확장자가 다르므로 XML 행에 포함하지 않습니다. 위 합계를 순수 구현량이나 기능 수, 품질의 척도로 해석하면 안 됩니다.

집계 원리는 다음과 같습니다. 읽기 전용으로 파일 내용을 세는 예제이며, 저장소 루트를 현재 디렉토리로 두는 것을 전제로 합니다.

from pathlib import Path
from collections import defaultdict

extensions = {".java", ".c", ".cc", ".cpp", ".h", ".hh", ".hpp",
              ".py", ".sinc", ".slaspec", ".gradle", ".xml"}
counts = defaultdict(lambda: [0, 0])
for path in Path(".").rglob("*"):
    if ".git" in path.parts or not path.is_file():
        continue
    if path.suffix in extensions:
        counts[path.suffix][0] += 1
        counts[path.suffix][1] += path.read_bytes().count(b"\n")
for extension, result in sorted(counts.items()):
    print(extension, result)