방망이
[프로젝트]UEFI DXE 바이너리 취약점 분석기 7주차 - Ghidra Script 작성 본문
내가 맡은 DXE Dispatcher & DEPEX 부분의 취약점 탐지 스크립트를 작성하기 위해, 먼저 DEPEX를 가져오는 자바 코드를 만들었다.
기존에는 UEFITool만 사용해서 GUID랑 트리 구조 같은 정보 부분만 확인 했었는데, UEFIExtract 툴을 사용해서 UEFITool에서 보던 트리 구조가 폴더 형식(.dump)으로 결과물이 나오고, 그 폴더를 기반으로 DEPEX를 쉽게 가져올 수 있었다.
UEFITool, UEFIExtract는 아래 링크에서 다운받을 수 있다.
https://github.com/LongSoft/UEFITool
코드가 길어서 파일 형태로 공유한다.
- GhidraDepexCounter.java
- 기드라 스크립트 O
- DXE Driver 개수, DEPEX 개수 카운트
- DepexHunter_v1.java
- 기드라 스크립트 X
- 카운터 + 무조건 True인 DEPEX 탐지 (폴더 경로 -> 잘 탐지 되었는지 확인하기 위함)
- GhidraDepexHunter_v1.java
- 기드라 스크립트 O
- DepexHunter_v1 기능에서 Apriori 파일 찾고 우선순위 드라이버 GUID 나열 기능 추가
일단 여기까지 했을 때, 아래와 같은 기능이 완성 되었다.
- DXE Driver 개수
- DEPEX 개수
- Apriori 파일 탐색 및 우선순위대로 GUID 나열
- 무조건 True인 DEPEX 탐지
추가적으로 취약점 탐지 로직과 더불어 자동화 하는 방향으로 발전시켰다.
- GhidraDepexHunter_v2.java
- v2에서는 아래 4가지 기능을 추가하였다.
- 각 DXE Driver가 요구하는 Protocol 그래프화 기능 추가
- GUID를 NAME으로 변환하는 기능 추가
- 무조건 TRUE 반환 DEPEX -> TRUE OR ANYTHING일 때로 변경
- 취약점 탐지 로직 추가(FALSE AND ANYTHING, NOT TRUE, NOT FASLE)
- v2에서는 아래 4가지 기능을 추가하였다.
- GhidraDepexHunter_v3.java
- v3에서는 아래 6가지 기능을 추가하고, 코드가 길어짐에 따라 코드 리팩토링을 완료하였다.
- provider 기능 추가 - "누가 시스템에 제공(Install)하는가?"를 역추적하는 로직
- Dependency graph 기능에 대한 출력을 dependency_graph.txt 파일로 저장
- provider 기능에 대한 출력을 protocol_providers.txt 파일로 저장
- 누락된 프로토콜 (Missing Protocol) 취약점 탐지 기능 추가
- 무한 루프 (Dependency Cycle) 취약점 탐지 기능 추가
- 세밀한 버그 픽스
- 논리 오류 교정: v2의 Dead Code 탐지에서 누락되었던 AND FALSE 케이스 추가되었습니다.
- 통계 카운터 세분화: 각 취약점의 개수를 세분화하여 산출
- v3에서는 아래 6가지 기능을 추가하고, 코드가 길어짐에 따라 코드 리팩토링을 완료하였다.
- GhidraDepexHunter_v4.java
- v4에서는 Json 파일로 결과 산출 하였고(팀원들과 결과 산출 방식을 맞추기 위함), 기존 txt 파일을 바탕화면으로 저장하여 따로 폴더 선택하는 로직을 지웠다.
- GhidraDepexHunter_v5.java
- v5에서는 기존에 UEFIExtract.exe 툴로 먼저 덤프파일을 생성해놓고 그 파일을 선택하는 방식으로 진행 했었는데, 이 과정을 자동화 하기 위해 환경 변수에 UEFIExtract 툴이 있는 폴더의 경로를 추가하여 진행하는 방식으로 변경하였다.
- 환경변수 설정 필요 (시스템 변수 - path - UEFIExtract.exe 파일 경로 추가)
- GhidraDepexHunter_v6.java
- v6에서는 GUID를 불러오는 과정도 자동화 하고자 이전에 사용했던 GUID 사전 링크를 가지고 다운로드 하여 사용할 수 있게 변경하였다. 또한, 기존 txt 파일 전부 같은 폴더로 도출되는 것이 좋을 것 같아서 경로를 변경하였다.
- GhidraDepexHunter_v7.java
- v7에서는 Apriori 메모리 주소와 문제가 있는 DEPEX를 가진 DXE Driver의 메모리 주소를 기드라 콘솔에 출력하는 기능을 추가하였다.
- 원본 .fd 펌웨어 파일은 내부가 LZMA 방식으로 압축되어 있어 기드라의 메모리 스캔(바이트/텍스트 매칭)이 불가능하다. 따라서 .fd 파일이 아닌, LZMA 압축을 푼 상태의 파일에서 실행해야 한다.
- 아래 사진처럼 .fd 파일에서 DXE Driver가 모여있는 FV파일을 Extract as is로 가져와 사용한다.
- v7에서는 Apriori 메모리 주소와 문제가 있는 DEPEX를 가진 DXE Driver의 메모리 주소를 기드라 콘솔에 출력하는 기능을 추가하였다.

- 코드가 복잡해져 코드 리팩토링을 하였다.
여기까지 만들었을 때 기능을 정리해보자.
- DXE Driver 개수
- DEPEX 개수 (DEPEX를 가진 DXE Driver 개수)
- Apriori 파일 탐색 및 우선순위대로 GUID 나열
- UEFIExtract 자동 연동 (환경 변수 설정 필요)
- GUID 사전 자동 로드
- Bypass(OR TRUE), Dead(AND FALSE), AlwaysTrue(NOT FALSE), AlwaysFalse(NOT TRUE) 취약점 탐
- Missing Protocol 탐지(드라이버가 요구하는 프로토콜이 펌웨어 내의 다른 어떤 드라이버에서도 제공되지 않는 상태)
- Dependency cycle 탐지(드라이버들이 서로를 무한정 기다리며 데드락(Deadlock)에 빠질 수 있는 의존성 순환 구조)
- BEFORE/AFTER 오용 탐지(존재하지 않는 드라이버의 GUID를 참조하여 BEFORE/AFTER 스케줄링을 시도하는 논리적 오류)
- 기드라 메모리 트래킹(문제 있는 DEPEX를 가진 DXE Driver의 메모리 주소, Apriori 메모리 주소)
- 플랜 A (GUID 스캔): UEFI의 혼합 엔디안을 고려하여 16바이트 File GUID로 1차 탐색을 진행
- 플랜 B (유니코드 스캔): 압축 등의 이유로 GUID를 찾지 못할 경우, UI 섹션의 UTF-16LE 텍스트 이름으로 2차 탐색을 진행
- dependency_graph.txt, protocol_providers.txt를 생성하여 전체 의존성 지도 작성
- 취약점 카운트, 논리 수식, 경로 정보 등이 구조화된 _report.json 파일 생성
여기서 추가/수정할 것은
- 취약점 탐지 추가 -> (박사님의 말씀을 참고하여) 악성 코드가 들어있는 드라이버를 하나 정의하고, DEPEX에 그 드라이버의 GUID가 존재한다면 잡아내는 로직
- 자잘하게 탐지 로직 수정
이 정도가 될 것 같다.
'2026_졸업프로젝트' 카테고리의 다른 글
| [프로젝트]UEFI DXE 바이너리 취약점 분석기 9주차 - 취약점 선정 및 Ghidra Script 수정 (0) | 2026.03.18 |
|---|---|
| [프로젝트]UEFI DXE 바이너리 취약점 분석기 8주차 - Ghidra Script 로직 보강 (0) | 2026.03.16 |
| [프로젝트]UEFI DXE 바이너리 취약점 분석기 6주차 - DXE Dispatcher 취약점 및 Ghidra Script 작성 (0) | 2026.02.26 |
| [프로젝트]UEFI DXE 바이너리 취약점 분석기 5주차 - DEPEX 확인법/Ghidra Script 기본 틀 (0) | 2026.02.26 |
| [프로젝트]UEFI DXE 바이너리 취약점 분석기 4주차 - Ghidra Script 실습 (0) | 2026.02.26 |
