자료 조사랑 런처2.0 제작을 해보자

우리 프로젝트는 다른 프로그램들에 비해서 어떤 점이 좋은지를 조사해보았다.

일단, 조사 후보군을 추렸다.

 

ghidra를 기반으로 한 유사해 보이는 프로젝트

• efiSeek
• UEFI_Surveyor

非 ghidra 기반 프로젝트

• efiXplorer
• efi_fuzz
• UEFI_RETool

각 프로젝트와우리 프로젝트를 비교하기 위한 특징들을 생각해 보았고, 아래와 같은 특징들을 생각해볼 수 있었다.

• 유/무료
• 펌웨어 전체 취약점 탐색
• CLI 지원
• 커스텀 여부
• 주용도(우리 프로젝트는 취약점 탐지)

본격적으로 조사와 비교를 시작해보자

대부분의 정보는 공식 github과 github문서에서 찾아봤다.

---

 

각 특징들을 기반으로 각 프로젝트를 표로 만들어봤다.

우선, ghidra를 사용하는

 

UEFI_Surveyor (Ghidra Script Collection)

관점	내용
무료	무료 오픈소스
펌웨어 전체 탐색 지원	스크립트 컬렉션으로 .fd 전체를 대상으로 한 언팩+분석 파이프라인 구성 가능
CLI 지원	Ghidra headless에서 각 스크립트 runHeadless로 실행, 전체 워크플로 자동화 가능
커스텀 여부	JavaScript 기반으로 스크립트 단위 수정/추가 매우 쉬움
주용도	UEFI 모듈 구조 분석, 취약점 후보 식별, SMM 런타임 분석
특징	SMM 런타임 핸들러 탐지, DXE 호출 그래프 생성, Depex 파싱 지원, 취약점 패턴 스캔

 

efiSeek (Ghidra Analyzer)

관점	내용
무료	무료 오픈소스
펌웨어 전체 탐색 지원	개별 .efi 모듈을 Ghidra 프로젝트에 로드 후 Analyzer 실행, 전체 자동화는 파이프라인 필요
CLI 지원	Ghidra headless 모드에서 AnalyzeHeadless + efiSeek analyzer 호출로 완전 CLI 가능
커스텀 여부	Java (Ghidra 스크립트)로 작성되어 커스텀 analyzer/script 추가 매우 쉬움
주용도	Ghidra 내에서 UEFI GUID, 프로토콜, 서비스 함수 자동 라벨링 및 구조 복구
특징	EDK2 타입 라이브러리 적용, Boot/DXE/Runtime 서비스 자동 식별, SMM 관련 함수 탐지, 크로스레퍼런스 개선

 

非 ghidra 기반

 

efiXplorer

관점	내용
무료	GitHub에 공개된 오픈소스 플러그인으로 자체는 무료지만, 사용을 위해서는 유료인 IDA/Hex‑Rays 제품이 必
펌웨어 전체 탐색 지원	전용 로더(efiLoader)로 .fd 같은 펌웨어 이미지를 통째로 로드하고, 그 안의 DXE/PEI/SMM 모듈 전체에 대해 GUID, 프로토콜, 서비스 호출, SMM 핸들러 등을 한 번에 분석하도록 설계
CLI 지원	본질적으로 IDA GUI 플러그인이며, 별도 스크립팅으로 IDA를 배치/헤드리스로 돌리면 반자동 CLI 파이프라인을 만들 수 있을 것으로 추측, 독립적인 단일 CLI 툴 형태로 설계된 것은 아님
커스텀 여부	C++로 작성된 IDA 플러그인으로, 사용자가 직접 확장·수정하려면 C++/IDA SDK 기반 개발이 必 분석 결과를 토대로 추가 IDA 스크립트를 붙이는 식의 간접 커스터마이즈는 가능
주용도	UEFI 펌웨어 전체를 로드해 프로토콜/서비스/테이블(ST, BS, RT 등)을 자동 복구 NVRAM·SMM·변수 처리 등과 관련된 잠재적 취약 지점을 빠르게 찾아내는 정적 분석·리버스 엔지니어링 보조 도구
특징	IDA 전용 플러그인 및 로더, C++ 기반 고성능 구현, 최신 Hex‑Rays SDK 기능 활용, GUID·프로토콜·서비스 자동 식별, ARM(AArch64) 포함 멀티 아키텍처 지원, SMM/부트 서비스/런타임 서비스 호출 복구 및 시각화를 제공해 대규모 펌웨어에서 취약 후보를 효율적으로 필터링

 

efi_fuzz

관점	내용
무료	무료 오픈소스
펌웨어 전체 탐색 지원	기본 설계는 개별 UEFI 모듈 + 특정 NVRAM 변수 단위 퍼징 ∴ 직접 제작
CLI 지원	python efi_fuzz.py <target> <nvram> <varname> <seed> 형태로 직접 실행하고, AFL++와도 CLI로 연동
커스텀 여부	Python 스크립트(Qiling 호출부, 입력 인코딩, 종료 조건 등)를 직접 수정·확장할 수 있어 커스터마이즈가 용이
주용도	에뮬레이션된 UEFI 환경에서 NVRAM 변수 값을 AFL++로 퍼징해 취약한 드라이버(오버플로우·crash)를 찾는 연구/PoC용 도구
특징	Qiling 에뮬레이터 + AFL++ 기반 coverage-guided fuzzing, NVRAM pickle을 사용한 유연한 변수 환경, dry-run 지원, 타임아웃·end address·trace/disasm/debug 출력 등 디버깅 옵션 제공

 

uefi retool

관점	내용
무료	무료 오픈소스
펌웨어 전체 탐색 지원	.fd 같은 펌웨어 이미지를 넣으면, 내부의 모든 UEFI 모듈을 대상으로 GUID·프로토콜·모듈 메타데이터를 분석하는 --all, --pp_guids 등의 옵션을 제공해 펌웨어 전체를 탐색 기능을 지원
CLI 지원	python analyse_fw_ida.py --all <firmware_path> 형태로 실행하는 커맨드라인 인터페이스를 제공하며, radare2용 analyse_fw_r2.py도 유사한 CLI 옵션 有
커스텀 여부	Python 스크립트 기반이라, 분석 로직을 직접 수정하거나 추가 스크립트등 커스터마이즈 용이
주용도	IDA Pro 또는 radare2와 연동하여 UEFI 펌웨어 구조를 자동 분석하고, 모듈·프로토콜·GUID 관계를 정리하는 리버스 엔지니어링 보조 도구
특징	IDA 플러그인 + 분석 스크립트 조합, --get_efi_images로 모든 PE 이미지를 추출, --pp_guids로 proprietary protocol GUID 리스트 생성, EDk2 소스로부터 GUID 리스트를 자동 갱신하는 update_edk2_guids.py 제공 등, GUID/프로토콜 중심의 펌웨어 매핑에 특화

 

 

---

위 표를 요약하면

이름	무료	펌웨어 전체 취약점탐색 지원	Cli 지원	커스텀 여부	주용도	특징
우리꺼	O	O	O	O	취약점 탐색
efiXplorer	X	O	△	△	취약점 탐색·리버스 엔지니어링 보조 도구	UEFI 펌웨어 전체를 로드해 프로토콜/서비스/테이블(ST, BS, RT 등)을 자동 복구하고, NVRAM·SMM·변수 처리 등과 관련된 잠재적 취약 지점을 빠르게 찾아냄
efi_fuzz	O	X	O	O	퍼징	개별 UEFI 모듈 + 특정 NVRAM 변수 단위 퍼징
UEFI_RETool	O	X	△	O	UEFI 펌웨어 구조 분석	IDA Pro 또는 radare2와 연동하여 UEFI 펌웨어 구조를 자동 분석하고, 모듈·프로토콜·GUID 관계를 정리
efiSeek	O	△	O	O	리버스 엔지니어링 보조 도구	Ghidra 내에서 UEFI GUID, 프로토콜, 서비스 함수 자동 라벨링 및 구조 복구
UEFI_Surveyor	O	△	O	O	Ghidra script 컬렉션	UEFI 모듈 구조 분석, 취약점 후보 식별, SMM 런타임 분석

작성하고 보니 프로젝트 이름이 정해지지않아 상당히 별로인 느낌이다

O : 가

X : 불가

△ : 자체적인 지원 기능은 없으나 구현 가능

 

가장 주용도가 유사한 efiXplorer와 비교했을 때, 아래와 같은 장점이 있다

 

1. 완전 자동·헤드리스 파이프라인

• efiXplorer는 IDA plugin이기에 별도로 파이프라인을 만들어주어야함
• 우리 프로젝트는 파이프라인이 이미 존재함

2. 스캐닝 로직을 커스터마이즈 가능

• efiXplorer는 자체적인 커스터마이즈를 지원하지는 않음

3. depex까지 포함한 전역분석 가능

• dependency graph를 만들어 주기는 하지만 의존성 취약점을 알려주는 기능은 없음

3.1 missing protocol 관련

• efiXplorer가 어떤 프로토콜을 설치하는지 리스트를 빌드해주지만, 취약점을 찾아주지는 않음(수동 탐색은 가능)

4. JSON 결과·도구 연계성

• 우리 도구는 이전 빌드와의 차이점 등을 찾기도 쉽고 다른 도구와 연계성이 좋은 json을 사용할 수 있음

5. 라이선스·배포 관점의 이점

 

---

런처도 업데이트 맞이했다. 강제로

depexhunter는 로직이 dump와 efi를 참조하는 방향으로 바뀌었기에 analyze가 반드시 선행 되어야만 한다

따라서 파이프라인이 아래와 같이 바뀌게 되었다.

 fd -> UEFIExtract -> 전체 efi에 대해서 analyze -> depexhunter -> oobhunter -> smmcallouthunter -> 결과 json

 

 또한, 한가지 변화가 추가적으로 생겼는데, UEFIExtract로 뽑아낸 bin파일들의 확장자를 바꿔 주는 것 만으로도 정상 .efi로 인식된다는 것을 팀장의 자료 조사덕분에 알게 되었고, 7zip을 사용하던 로직을 제외하고 실행기에 아래와 같은 로직을 추가하여 efi를 추출하게 하였다.

1. 출력 폴더(efiCollectPath) 생성
2. 출력 폴더의 기존 .efi 파일 전부 삭제
3. dump 폴더를 재귀 탐색하면서 body.bin 찾기
4. 상위 폴더명이 PE32 image section인 경우만 후보로 채택
5. 같은 드라이버 폴더에 PE32가 여러 개면 정렬 기준으로 첫 번째 1개만 선택
6. 드라이버 이름은 UI 섹션(unicode.txt/body.bin)에서 추출, 실패 시 폴더명 fallback
7. 파일명 충돌 시 _1, _2 같은 suffix 붙여 저장
8. 선택된 body.bin을 .efi로 복사

 

oobhunter와 smmcallouthunter는 크게 바뀐 것 없이 (괄호는 반복되는 처리과정)

( 단일 .efi import → oobhunter → smmcallouthunter→ 중간 결과 json 생성 ) ... 최종 결과 .json 생성

의 과정을 그대로 따르게 제작하였다.

 

실행옵션도 아래와 같이 설정하였다.

a  : 통합실행
s  : 스크립트만 실행
d  : DepexHunter만 실행
f  : OobHunter + SmmCalloutHunter만 실행
q  : 나가기
v  : 경로 및 스크립트 버전확인
e  : 경로 편집
1  : UEFIExtract 덤프 + EFI 추출
2  : 전체 EFI import only

 

total_launcher_v2.0.0.py

0.07MB

 

 

근데 depexhunter가 모든 프로토콜을 다 잡는 문제가 있어서 해당 부분은 조원이 수정해줘서 2.0.1이 될 예정