방망이

[프로젝트]UEFI DXE 바이너리 취약점 분석기 16주차 - 스크립트 업데이트를 위하여..

망구입니다 — Thu, 23 Jul 2026 17:31:10 +0900

왜 업그레이드가 필요한가

기존에 작성한 DepexHunter 스크립트는 UEFI 펌웨어 이미지를 UEFIExtract로 풀어놓은 덤프 폴더를 순회하면서, 각 DXE 드라이버의 DEPEX(Dependency Expression) 섹션을 파싱해 "이 드라이버가 요구하는 프로토콜이 이미지 안의 어떤 드라이버로도 제공되지 않는" 경우를 찾아내는 스크립트다. 이 스크립트는 GhidraScript를 상속하고 있음에도 정작 Ghidra의 핵심 기능인 디스어셈블/디컴파일/P-code 분석은 전혀 쓰지 않는다. 실제 동작은 info.txt와 body.bin을 텍스트·바이너리 레벨에서 직접 파싱하는 파일 시스템 순회에 가깝다.

프로토콜을 "누가 제공하는가"를 판단하는 로직도 마찬가지로 코드 분석이 아니라 이름 매칭에 의존한다. 1단계로 약 200개 프로토콜을 하드코딩해둔 switch-case 테이블(knownProtocolProvider)을 먼저 확인하고, 여기서 못 찾으면 2단계로 프로토콜 이름에서 "Protocol", "Guid", "Efi" 같은 접두·접미사를 제거한 뒤 그 문자열이 드라이버 이름에 부분 문자열로 포함되는지를 본다. 이 방식은 두 방향으로 오류가 난다. 이름이 우연히 겹치면 실제로는 관련 없는 드라이버를 provider로 오인하고, 이름이 표준 명명 규칙을 따르지 않는 벤더 커스텀 드라이버라면 실제로 프로토콜을 제공하고 있어도 놓친다. 하드코딩 테이블도 EDK2 표준 프로토콜에만 대응하기 때문에 새로운 펌웨어나 벤더 특화 프로토콜이 나올 때마다 사람이 계속 추가해줘야 하는 구조다.

이걸 근본적으로 고치려면, "이름이 비슷한가"가 아니라 "그 드라이버의 코드가 실제로 해당 GUID로 프로토콜을 install하는가"를 코드 레벨에서 직접 확인해야 한다. (이게 P-code를 공부하는 이유)

필요한 개념 1: 간접 호출 해석 (EFI_BOOT_SERVICES 구조체)

UEFI 드라이버 코드에서 프로토콜을 등록하는 호출은 대부분

gBS->InstallProtocolInterface(...)
gBS->InstallMultipleProtocolInterfaces(...)

위 두 형태로, EFI_BOOT_SERVICES 구조체 포인터를 통한 간접 호출로 나타난다. 어셈블리 레벨에서는 이게 CALLIND(간접 호출) PcodeOp으로 표현되고, 타겟 주소는 특정 함수 심볼이 아니라 어떤 레지스터나 메모리 위치에서 LOAD된 값이다.

이걸 식별하려면 CALLIND의 타겟 Varnode를 역추적해서, 그것이 gBS 전역 포인터에서 구조체 필드 오프셋만큼 떨어진 위치를 LOAD한 결과인지 확인해야 한다. EFI_BOOT_SERVICES 구조체에서 InstallProtocolInterface는 정해진 오프셋에 위치하므로, Ghidra에 이 구조체 타입을 데이터 타입으로 씌워두면 오프셋 기반 필드 매칭이 훨씬 수월해진다. 이 부분을 중점으로 앞으로 공부하지 않을까 싶다.

필요한 개념 2: CALL 인자 추적 (Use-Def 체인)

호출 대상이 InstallProtocolInterface라는 것을 확인했다면, 다음은 그 두 번째 인자인 GUID 포인터를 추적할 차례다. 이 인자로 쓰인 Varnode에서 getDef()를 통해 정의 지점을 거슬러 올라가면, 결국 .data 섹션의 어떤 고정 주소(보통 gEfiXxxProtocolGuid 심볼)를 가리키는 CONST Varnode에 도달하게 된다 "이 인자가 어떤 고정된 상수인가"를 확인하는 것이므로 Use-Def체인을 사용한다.

필요한 개념 3: GUID 상수 추출

CONST Varnode로 가리켜지는 주소를 찾았다면, 그 주소에서 16바이트를 읽어 실제 GUID 값을 얻어야 한다. 이 값을 기존에 갖고 있는 GUID 데이터베이스(guids.csv)와 대조하면, 이름 문자열이 아니라 실제 바이트 값으로 어떤 프로토콜인지 확정할 수 있다. 이렇게 하면 기존에 ~~똥멍청이스크립트에서~~ 사용하던 하드코딩된 switch-case 테이블도, 이름 유사도 기반 substring 매칭도 모두 필요 없어진다. 드라이버 이름이 표준 명명 규칙을 따르든 따르지 않든, 코드가 실제로 그 GUID를 install하기만 하면 잡아낼 수 있다.

학습 순서

우선 EFI_BOOT_SERVICES 구조체를 Ghidra 데이터 타입으로 적용하고 CALLIND의 타겟을 오프셋 기반으로 식별하는 연습부터 시작하는 게 좋을 것 같다. 이게 되면 InstallProtocolInterface 호출 지점을 코드에서 자동으로 찾아낼 수 있는 상태가 된다고 한다(클로드가). 그다음은 CALL 인자 추적으로 GUID 포인터의 Use-Def 체인을 따라가 실제 상수 주소를 특정하고, 마지막으로 그 주소에서 GUID 바이트를 읽어 기존 GUID DB와 매칭하는 순서로 진행하면 좋을 것 같다.

이 세 단계가 완성되면 provider 추정 로직 전체를 이름 기반 휴리스틱에서 코드 기반 검증으로 교체할 수 있고, 이후 알려진 CVE가 있는 실제 펌웨어 바이너리에 적용해보면서 하드코딩 테이블 없이도 정확히 동작하는지 검증하는 단계로 넘어갈 수 있다.

[프로젝트]UEFI DXE 바이너리 취약점 분석기 15주차 - P-code Phase3

망구입니다 — Thu, 2 Jul 2026 15:54:35 +0900

- 오늘의 주제 및 키워드

> 데이터 흐름 기초

> [Reaching Def, Def-Use, Live Variable]

데이터 흐름 (Data Flow Analysis)

P-code로 취약점을 분석할 때 핵심 포인트는 "외부에서 들어온 값이 위험한 함수까지 도달할 수 있는가?"에 대한 것.

이 질문에 대한 답을 하기 위해서는 코드를 실행하지 않고도 값이 어디서 왔고, 어디로 흘러가는지 파악할 수 있어야 함.

1. Def-Use Chain

변수의 정의(Def)와 사용(Use)을 연결한 체인

Def - 변수에 값이 처음 할당되는 지점(의미 있는 값이 처음 들어오는 시점)
Use - 그 값이 입력으로 읽히는 지점

아래 코드를 예시로 들어보자.

void func(int sock) {
    char buf[64];
    recv(sock, buf, 64, 0);  // 외부에서 데이터 수신 (Def 지점)
    strcpy(dst, buf);        // buf를 그대로 복사 (Use 지점)
}

recv() → buf 정의(Def)
- recv()가 외부 네트워크에서 데이터를 읽어서 buf에 저장. 이 순간 buf라는 변수에 값이 처음 할당됨. 이 부분이 Def(정의) 지점.
→ strcpy에 전달(Use)
- buf에 담긴 값이 strcpy의 두 번째 인자로 전달. 이 순간 buf의 값이 읽힘. 이 부분이 Use(사용) 지점.
→ 취약점!
- strcpy는 길이 검사를 하지 않음. buf에 외부에서 온 데이터가 담겨 있는데, 그 길이를 확인하지 않고 그대로 복사하면 버퍼 오버플로가 발생할 수 있음.

Ghidra에서는 API로 접근 가능

varnodeAST.getDef()          // 이 Varnode의 값이 어떤 op에 의해 만들어졌는가 (역방향)
varnodeAST.getDescendants()  // 이 Varnode의 값이 어떤 op들에서 사용되는가 (순방향)

SSA에서는 변수가 딱 한 번만 정의되므로 getDef()가 항상 하나의 op만 반환.

비SSA 코드라면 같은 변수가 여러 곳에서 정의될 수 있어서 추적이 복잡하지만, High P-code는 SSA form이라 체인 추적이 단순하고 명확함.

getDef()

위에서 예시로 든 C 코드를 기반으로 봤을 때

buf.getDef()

호출시 CALL recv() op 반환 → buf의 값은 recv()가 만들었다는 의미

getDef()가 null을 반환하는 경우도 있는데, 이는 더 이상 거슬러 올라갈 곳이 없다는 뜻으로 아래 두 가지 경우에 해당함.

함수 인자(HighParam) → 호출자가 넘겨준 값 → Taint Source!
전역 변수 → 외부 상태(현재 분석 중인 함수 바깥에서 관리되는 값. 함수 입장에서는 어떤 값이 들어있는지 알 수 없는 외부의 상태라는 뜻) → Taint Source 가능

둘 다 이 함수 안에서 정의된 것이 아니므로 더 이상 역추적할 수 없음. 그래서 탐색을 멈추고 Taint source로 판정하는 조건이 됨.

따라서 이는 역방향 슬라이싱의 탐색 종료 조건이 됨.

getDescendants

이는 하나의 값이 여러 곳에서 쓰일 수 있으므로 Iterator로 반환됨.

VarnodeAST buf = ...;                      // buf Varnode
Iterator<PcodeOp> uses = buf.getDescendants();
while (uses.hasNext()) {
    PcodeOp useOp = uses.next();
    println(useOp.getMnemonic());          // buf를 쓰는 op들 출력
}

getDef와 getDescendants를 함께 쓰는 이유는 아래와 같은 로직을 사용하여 외부 입력으로 인한 위험 함수 경로를 파악.

getDef() → "이 값이 외부 입력에서 왔는가?" 판단 → Taint source 확인
getDescendants() → "이 tainted 값이 어디까지 퍼지는가?" 추적 → sink 도달 여부 확인

2. Reaching Definitions

x = input;       // 정의 d1
if (cond) {
    x = 0;       // 정의 d2
}
use(x);          // 여기서 도달 가능한 정의는?
                 // → d1과 d2 둘 다 가능

특정 지점에서 "어떤 정의가 여기까지 도달 가능한가" 를 분석. 변수의 출처를 판단하는 데 사용.

High P-code는 SSA(Static Single Assignment) 형태라서 Reaching Definition 개념을 곧바로 적용하기 애매함.

SSA에서는 변수가 딱 한 번만 정의됨. 같은 변수를 여러 번 대입하는 코드가 있어도, SSA로 변환되는 과정에서 x#1, x#2, x#3처럼 매번 새로운 이름이 붙음. 그래서 getDef()를 호출하면 언제나 정확히 하나의 op만 반환되고, "여러 정의가 도달 가능하다"는 상황 자체가 애초에 생기지 않게 됨.

분기가 있으면 합류점에서 여러 정의가 동시에 도달할 수 있는데, High P-code에서는 이 상황을 MULTIEQUAL(φ노드) 로 표현.

이건 사실 "이 지점에 x#1과 x#2라는 정의가 동시에 도달 가능하다"는 Reaching Definitions 분석의 결과가 이미 코드 구조에 반영되어 있는 것. 즉, Ghidra가 Raw P-code를 High P-code(SSA)로 변환하는 과정 자체가, 내부적으로 Reaching Definitions와 본질적으로 같은 계산을 수행한 결과물이라는 뜻.

x#3 = MULTIEQUAL(x#1_input, x#2_zero)

그래서 SSA 위에서 GEN/KILL/IN/OUT 알고리즘을 직접 돌리는 건 의미가 없음. — 이미 계산되어 있는 답을 다시 계산하는 셈이기 때문. MULTIEQUAL의 입력 목록을 확인하는 것만으로 "이 지점에 어떤 정의가 도달하는가"에 대한 답을 바로 얻을 수 있음.

컴파일러개론 수업에서 배운 GEN/KILL/IN/OUT 고정점 반복 알고리즘을 직접 구현하고 확인해보려면, 정의가 여러 번 일어날 수 있는 비SSA 코드, 즉 Raw P-code로 내려가야 함. Raw P-code는 명령어 단위 그대로의 저수준 표현이라 같은 레지스터/스택 위치에 값이 여러 번 쓰일 수 있기 때문.

분석 알고리즘은 각 블록의 IN/OUT 집합을 계산하며 변화가 없을 때까지 반복. (고정점 반복)

OUT[B] = GEN[B] ∪ (IN[B] - KILL[B])
IN[B]  = ∪ OUT[pred]  for all predecessors

3. Live Variable Analysis

특정 지점에서 "이후에 사용될 변수가 무엇인가" 를 분석. Reaching Definitions가 과거→현재 방향의 순방향 분석이라면, Live Variable은 미래→현재 방향의 역방향 분석.

x = input;   // x: live (아래에서 쓰임)
y = x + 1;   // x: 이후 dead, y: live
z = 10;      // z: dead (이후 z를 읽는 곳 없음)
use(y);      // y: 이후 dead

z는 이후에 전혀 사용되지 않으므로 Dead Variable. Taint 분석에서 z를 추적하는 것은 불필요.

Live Variable Analysis는 취약점 분석에서 세 가지 역할을 함.

불필요한 Taint 추적 제거 — Dead Variable은 이후 취약점을 유발할 수 없으므로 분석 대상에서 제외해 속도를 높임.
False Positive 감소 — tainted 변수가 sink 이전에 Dead가 된다면 실제로는 위험하지 않음. 이를 걸러내면 잘못된 정보를 줄일 수 있음.
Sanitizer 탐지 — tainted 변수가 검증 함수를 거친 뒤 새 변수에 할당되면 이전 tainted 버전이 Dead가 됨. 이 패턴으로 입력 검증 코드를 자동 인식할 수 있음.

char* sanitize(char* input) {
    // 길이 검사, 특수문자 제거 등
    return cleaned_input;
}

void func(char* input) {       // input: tainted
    char* safe = sanitize(input);  // 검증 후 새 변수에 할당
    strcpy(dst, safe);             // safe를 사용
}

sanitize함수는 사용자 입력을 검증하거나 정제하는 함수.

sanitizer를 거치는 경우 검증 후 새 변수에 할당되므로 sanitizer 호출 이후 이 변수는 Dead variable이 됨.

tainted 변수(input#1)가
  → 어떤 함수(sanitize)를 거쳐
  → 새 변수(safe#1)에 할당되고
  → 기존 tainted 변수(input#1)가 Dead가 됨
  → 이 함수가 Sanitizer일 가능성이 높다!
  즉 "tainted 변수가 Dead가 되는 지점에 함수 호출이 있다면" 그 함수를 Sanitizer 후보로 자동 인식할 수 있음.

이런 로직으로 분석기가 Sanitizer를 탐지할 수 있게 됨.

이런식으로 Live Variable Anaysis로 Sanitizer를 탐지하게 되면, 그 이후의 변수를 tainted 목록에서 제거할 수 있으므로 tainted 변수 추적에 도움을 줄 수 있음.

정리

기법	기	방향	역할
Def-Use 체인	값이 어디서 왔고 어디로 가는가	양방향	흐름 추적
Reaching Definitions	어떤 정의가 여기까지 도달 가능한가	순방향	출처 판단
Live Variable	이 변수가 이후에 사용되는가	역방향	분석 범위 축소

위 세가지 기법은 독립적으로 동작하는 것이 아니라 Def-Use로 흐름을 추적하고, Reaching Definitions로 출처를 판단하고, Live Variable로 분석 범위를 좁히는 방식으로 함께 동작.

실습

=> DVRF(Damn Vulnerable Router Firmware)를 다운 받아서 진행

https://github.com/praetorian-inc/DVRF

/DVRF/Firmware/_DVRF_v03.bin.extracted/squashfs-root/pwnable/Intro/stack_bof_01 파일 사용

1. Def-Use 체인

Cluade에서 Def-Use 체인을 실습할 수 있는 스크립트를 생성해서 돌려본 결과

Taint Source: param_2(=argv)가 main의 함수 인자로서 이 함수 안에서 정의되지 않음 → getDef() = null → Taint Source 판정
즉, "함수 인자로 들어온 외부 입력이 검증 없이 strcpy까지 도달"하는 것을 찾아냄.

2. Reaching Definitions

컴파일러개론 수업에서 배웠던 GEN/KILL, IN/OUT을 스크립트로 구해보았다.

수업 때 배웠던 내용을 직접 스크립트로 구해보고 볼 수 있는 것이 굉장히 신기하고 유익하다..

3. Live Variable Analysis

이 스크립트에서는 Dead Variable을 찾는다. 해당 블록에서 벗어나는 순간 Dead 상태가 되는 변수를 찾아내는 스크립트이다.

정리

실습은 간단하게 각 개념을 적용하는 함수를 사용해보는 수준의 실습이지만, 위에서 정리한 개념과 실습 내용을 바탕으로 Taint 분석과 취약점 탐지 스크립트에 적용하면 더 좋은 결과를 낼 수 있을 것 같다.

[프로젝트]UEFI DXE 바이너리 취약점 분석기 14주차 - P-code Phase2

망구입니다 — Sun, 31 May 2026 20:21:22 +0900

[P-code 공부 커리큘럼]

Phase2에서 4, 5번에 대한 내용은 팀원들의 블로그를 참고한다.

Phase2 - 4 (Varnode, PcodeOp) https://ludence8.github.io/%EC%A1%B8%EC%97%85%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8/2026-05-16-PCode-1.html

Ghidra P-Code 알아보기 1

P-Code (사실 P-Code는 다들 너무 잘 알고 있을 것이라 생각한다…) P-Code는 Ghidra가 사용하는 IR로, 다양한 프로그래밍 언어들을 통일하기 위한 목적인 컴파일러 레벨의 IR들과 달리 P-Code는 MIPS, x86, ARM

ludence8.github.io

Phase2 - 4 (SLEIGH, High Pcode vs Raw P-Code)
https://eatrawlife.github.io/posts/2026/05/17

UEFI 스터디 15차 - 기드라 p 코드 공부 (sleigh, high VS low pcode.)

sleigh

eatrawlife.github.io

Phase2 - 5(P-code 연산자)
https://img1244.tistory.com/28

15차 전원회의 - p-code operator를! 공부해보자

p-code 오퍼레이터는 ghidra 공식 문서를 참조https://ghidra.re/ghidra_docs/languages/html/pcodedescription.html#cpui_copy P-Code Operation ReferenceFor each possible p-code operation, we give a brief description and provide a table that lists th

img1244.tistory.com

이번 주에 내가 공부한 내용은 위 커리큘럼에서 Phase2에 6~7부분 중 SSA 정적 단일 할당과 데이터 흐름 추적 파트이다. 이 파트에서는 Varnode와 High Variable, 심볼 분류와 분석 소스 판정, Def-Use 체인에 대한 내용을 다룰 예정이다.

Varnode와 High Variable

Varnode는 P-code에서 모든 값을 표현하는 기본 단위이다. 레지스터든, 메모리든, 상수든간에 전부 (address space, offset, size) 이렇게 세 필드로 표현된다.
Raw P-code에서는 Varnode가 단순히 레지스터 위치((register, 0x0, 8)=RAX)를 가리키는 데 그친다. 하지만 High P-code로 올라오면 High Variable이라는 개념이 추가된다.
High Variable은 SSA 변환 이후 여러 SSA 버전을 하나의 논리적 변수로 묶은 것.
예를 들어, 동일한 변수 x가 코드 흐름에서 세번 재정의되면 SSA에서는 x#0, x#1, x#2로 분리되는데, 이 세 개가 모두 같은 High Variable에 속한다.
Varnode (x#0)  ─┐
Varnode (x#1)  ─┼─→ HighVariable "x"  (이름, 타입, 심볼 종류 보유)
Varnode (x#2)  ─┘
(Ghidra 디컴파일러가 "이 두 SSA 버전은 결국 같은 논리적 변수다"라고 판단)
SSA는 분석을 위해 변수를 쪼개고, HighVariable은 사람이 이해할 수 있도록 다시 합쳐주는 역할
API로는 varnode.getHigh()로 HighVariable에 접근하고, highVar.getInstances()를 호출하면 해당 HighVariable에 속한 모든 SSA 버전 Varnode 목록(x#0, x#1, x#2)이 반환.
- Taint 분석에서 변수의 모든 사용 지점을 빠짐없이 추적할 때 이 메서드 사용.

[참조] SSA

심볼 분류와 분석 소스 판정

High Variable은 getSymbol() 메서드로 심볼 종류를 구분할 수 있음. 취약점 분석에서 이 분류가 중요한 이유는 Taint의 시작점(Taint source)을 정의할 수 있는 기준이 되기 때문.

종류	의미	Taint 관련성
HighParam	함수 선언부의 인자. int func(int a, char* buf)에서 a와 buf	Taint source - 외부 입력 진입점
HighLocal	함수 내부에서 선언된 지역 변수. char buf[64] 같은 것	버퍼 위치 추적
HighGlobal	함수 밖에 선언된 전역/정적 변수	외부 상태 추적
HighOther	디컴파일러가 내부적으로 만들어낸 임시 변수. 소스 코드에 대응하는 변수가 없음	대부분 무시

Taint source 판정 규칙
- HighParam → 즉시 Taint source (함수 인자는 외부 호출자가 넘겨준 값이라 신뢰할 수 없기 때문)
- getDef()를 역추적했을 때 read() / recv() / fgets() 같은 외부 입력 함수의 CALL output Varnode에 닿으면 → Taint source
  - 이 규칙은 함수 인자가 아닌 로컬 변수가 외부 입력을 받는 경우를 잡기 위한 것
  - ex.
    - void func() {
          char buf[64]; // HighLocal — 인자가 아님
          recv(sock, buf, 64, 0); // 여기서 buf에 외부 데이터가 들어옴
          strcpy(dst, buf); // buf가 tainted인지 알아야 함
      }
    - 위와 같은 코드의 경우 buf가 HighParam이 아니기 때문에 규칙 1에서 잡히지 않음. 그래서 getDef()를 따라 역추적.
    - strcpy가 위험한 이유 : strcpy(dst, src)는 src 문자열을 dst 버퍼에 복사하는데, src의 길이를 전혀 확인하지 않음 → 공격자가 64바이트보다 긴 데이터를 보내면 Buffer Overflow
Java코드로는 아래와 같이 판정한다.

HighVariable hv = varnodeAST.getHigh();
if (hv != null && hv.getSymbol() != null) {
    String kind = hv.getSymbol().getClass().getSimpleName();
    if (kind.equals("HighParam")) {
        // Taint source로 등록
    }
}

Def-Use 체인 슬라이싱

SSA의 핵심 장점은 각 변수가 딱 한 번만 정의된다는 것. 이 덕분에 어떤 Varnode든 그것을 만든 op와 그것을 사용하는 op를 바로 추적할 수 있음.
역방향 슬라이싱 - getDef()
- Varnode를 만든 op를 거슬러 올라갑니다. Taint가 어디서 시작됐는지 출처를 사용할 때 사용.
- strcpy의 src 인자
  ← INT_ADD (버퍼 + 오프셋)
  ← LOAD (메모리에서 읽기)
  ← CALL recv() ← [SOURCE] 외부 입력
순방향 슬라이싱 - getDescendant()
- Varnode가 이후 어디서 사용되는지 흐름을 따라감. Taint가 어디까지 전파되는지, 어떤 sink에 도달하는지 추적할 때 사용.

// 역방향
PcodeOp defOp = varnodeAST.getDef();

// 순방향
Iterator<PcodeOp> uses = varnodeAST.getDescendants();
while (uses.hasNext()) {
    PcodeOp use = uses.next();
}

MULTIEQUAL 처리
- 조건 분기가 있으면 합류점에서 MULTIEQUAL op가 생김. Taint 분석에서 이 노드를 처리하지 않으면 false negative가 발생하게 됨.
- 따라서 MULTIEQUAL을 처리하는 방법은 MULTIEQUAL의 입력 중 하나라도 tainted이면 출력도 tainted.

if (op.getMnemonic().equals("MULTIEQUAL")) {
    for (Varnode inp : op.getInputs()) {
        if (tainted.contains(inp)) {
            tainted.add(op.getOutput()); // 전파
        }
    }
}

[프로젝트]UEFI DXE 바이너리 취약점 분석기 13주차 - P-code Phase1

망구입니다 — Tue, 12 May 2026 18:56:37 +0900

01 어셈블리 기초

핵심 레지스터 (x86-64)

RAX
64-bit accumulator
함수 반환값, 산술 연산

RBP
base pointer
스택 프레임 기준점

RSP
stack pointer
현재 스택 탑 위치

RIP
instruction pointer
다음 실행할 명령어 주소

RDI/RSI
1st / 2nd argument
함수 인자 (Linux x64)

RDX/RCX
3rd / 4th argument
함수 인자 (Linux x64)

어셈블리 읽기 — 실제 예제

아래는 int add(int a, int b) { return a + b; } 의 컴파일 결과입니다

0x1129 push rbp ; 호출자 RBP 저장
0x112a mov rbp, rsp ; 새 스택 프레임 설정
0x112d mov [rbp-0x4], edi ; 인자 a 저장
0x1130 mov [rbp-0x8], esi ; 인자 b 저장
0x1133 mov eax, [rbp-0x4] ; a → EAX
0x1136 add eax, [rbp-0x8] ; EAX = a + b
0x1139 pop rbp ; 프레임 해제
0x113a ret ; EAX에 결과 담아 반환

스택 프레임 구조

02 Ghidra 도구

핵심 뷰 & 도구

CodeBrowser
- 메인 분석 뷰. 어셈블리 ↔ P-code 전환, 심볼 레이블링, 참조 추적. 오른쪽 클릭 → "Show Pcode"로 Raw P-code 확인 가능.
Decompiler
- 어셈블리 → C 유사 코드로 변환. 내부적으로 High P-code를 사용. 변수 이름 재지정, 타입 선언 적용 가능.
Script Manager
- Java / Python(Jython) 스크립트 실행 환경. P-code 자동 분석기 개발의 시작점. GhidraScript API 전체 사용 가능.
Function Graph
- 제어 흐름 그래프(CFG) 시각화. 기본 블록 단위로 구조 파악. P-code 분석의 CFG 개념을 시각적으로 확인.
Symbol Tree
- 함수, 심볼, 레이블 전체 목록. 분석 대상 함수를 빠르게 찾고 Import/Export 구조 파악.
Auto Analysis
- 바이너리 최초 임포트 시 실행. Disassembly, Function Discovery, Reference Analysis 등 파이프라인 자동 수행.

P-code 보는 방법 — 12.0 이 버전 기준
1. 함수 열기
Symbol Tree에서 함수 더블클릭 → CodeBrowser에 어셈블리 표시
⇩
2. Low P-code

1단계 — Tool Options에서 먼저 활성화:
- Edit → Tool Options → Listing Fields → Pcode Field → "Display Raw Pcode" 체크 ON
2단계 — Listing 뷰 우상단 "Edit the Listing Fields" 아이콘 클릭:
- Listing 뷰 오른쪽 상단에 있는 ≡ 같은 아이콘 클릭 → PCode 항목 찾아서 우클릭 → "Enable Field" 클릭하여 활성
활성화가 완료되면 각 어셈블리 명령어 아래에 매핑된 Low P-code가 실시간으로 표시

⇩

3. High P-code

Ghidra 12.0은 GUI가 없어서 따로 설정이 필요하다는데, 다양한 방법 공유 부탁드립니다.

03 컴파일러 & IR

왜 IR이 필요한가?

IR(중간 표현, Intermediate Representation) 을 사용하면 분석 알고리즘을 한 번만 구현해도 수십 개의 아키텍처에 적용할 수 있음. P-code가 바로 Ghidra의 IR이며, x86 명령어든 ARM 명령어든 모두 P-code로 변환된 뒤 분석.

SSA Form (단일 정적 대입)

P-code의 High 레이어는 SSA form을 사용. 각 변수는 정확히 한 번만 정의되므로, 데이터 흐름을 추적하기 훨씬 쉬워짐.

Basic Block & CFG

Basic Block은 연속된 명령어의 묶음으로, 중간에 분기가 없음. CFG(Control Flow Graph)는 이 블록들 사이의 분기 관계를 그래프로 표현. P-code 분석기는 CFG를 순회하며 각 블록의 P-code를 처리.

어셈블리 → P-code 변환 예시

같은 동작을 어셈블리와 P-code로 비교

[프로젝트]UEFI DXE 바이너리 취약점 분석기 12주차 - P-code 이론

망구입니다 — Mon, 4 May 2026 20:16:50 +0900

기존에 진행하던 프로젝트의 전반적인 개발은 일단락 되었고, 앞으로 진행할 방향에 대해 고민하는 시간과 함께 스크립트 발전에 대해 목마른 팀원분들과 함께 P-code를 공부해보고자 한다.

P-code 공부는 AI를 활용하고자 한다.

이번주는 P-code에 대해 개념 공부를 하기 보단 커리큘럼을 먼저 설계해보기로 하였다.

이를 위해 내가 주로 쓰는 세 가지 정도의 AI 툴로 테스트 해보았고, 모두 동일한 프롬프트를 사용하였다.

Claude Sonnet 4.6 (무료)
Gemini Pro (유료)
Chat GPT (무료)

P-code에 대해 잘 모르는 사람 입장에서 위 세 가지 툴 모두 시키는거 많고 해야할 거 많고 체계적으로 짜준 것 같긴 하다만 Claude가 로드맵 형식으로 구체적이면서 시각적으로 한눈에 들어오게 만들어준 것 같아서 이걸 사용해 보려고 한다.

사실 세 가지가 사람마다 취향이 갈려서 자신이 편하게 느껴지는 툴을 사용하면 좋을 것 같긴 하지만, 출처나 관련 자료 링크를 쉽게 볼 수 있는 툴(ex. Perplexity)과 1, 2, 3번 중 한가지를 동시에 쓰면 더 수월하고 전문성 있게 공부할 수 있겠다는 생각이 들었다.

아래는 Cluade를 사용한 자료이다.

전체 커리큘럼 로드맵

Phase 1 — 기반 지식 구축 (2~3주)
- P-code는 결국 어셈블리를 추상화한 IR이기 때문에, x86/x64 어셈블리를 읽을 수 있어야 함. 동시에 SSA form, 기본 블록, CFG 같은 컴파일러 이론 개념도 먼저 익혀두는 게 Phase 2 진입을 훨씬 수월하게 함.
Phase 2 — P-code 핵심 이해 (3~4주)
- 커리큘럼의 핵심 단계. Varnode(P-code의 변수 단위), PcodeOp(연산 단위), SLEIGH 명세 언어의 삼각 관계를 이해해야 함. Ghidra는 Raw P-code(어셈블리 1:1 변환)와 High P-code(디컴파일러 내부 최적화 표현) 두 레이어를 제공하는데, 취약점 분석은 주로 High P-code에서 작업함.
Phase 3 — 프로그램 분석 기법 (4~5주)
- Taint analysis가 핵심. 사용자 입력(source) → 위험한 함수(sink)까지의 데이터 흐름을 P-code Def-Use 체인을 따라 추적하는 것이 취약점 분석기의 기본 원리.
Phase 4 — 취약점 분석 패턴 (4~5주)
- Buffer overflow는 LOAD/STORE op의 오프셋 범위 검증, UAF는 COPY op 이후 STORE 추적, 포맷 스트링은 CALL op의 인자 Varnode를 역방향 슬라이싱하는 식으로 각 취약점 유형마다 P-code 레벨의 패턴이 있음. 실제 CVE 바이너리로 직접 연습하는 것을 강력히 권장.
Phase 5 — 분석기 개발 (4~6주)
- Ghidra의 AbstractAnalyzer를 상속해서 플러그인을 만들고, 필요하다면 PcodeEmulator나 AngR 같은 심볼릭 실행 엔진과 연동. Ponce(Ghidra용 taint 분석기)나 Kaiju 같은 오픈소스 플러그인 코드를 참고하면 구조 파악에 큰 도움이 됨.

위 커리큘럼에서 전부를 하는 것은 아니고, 필요한 부분만 골라서 진행하면 좋을 것 같다.

[프로젝트]UEFI DXE 바이너리 취약점 분석기 11주차 - Ghidra Script 수정 및 검증

망구입니다 — Thu, 2 Apr 2026 01:45:37 +0900

[검증 전 확인 및 로직 보강]

검증을 하다보니 이런식으로 드라이버 별 구분이 아니라 프로토콜 별 구분으로 되어서 json 출력 로직을 수정하였다.

수정 전

또한 드라이버 이름 기반으로 먼저 탐지하고 knownProtocolProvider() 함수에 있는 switch-case를 그 다음으로 보는 방법으로 했었는데, 그 두개의 순서를 바꾸어 자기 자신에 대한 프로토콜 제공자를 매칭하는 오탐을 수정하였다.

Bug를 사용할지 Defect를 사용할지 고민했었는데, Defect로 결정하게 되어 이것도 수정하였다. (블로그 작성 이후에 수정함)

DepexHunter_v3_1_0.java

0.04MB

[실행이 안 될 경우 BDS(Boot Device Selection) 페이즈로 넘어가지 못하는 드라이버]

CpuDxe (1A1E4886-9517-440E-9FDE-3BE44CEE2136)
- CPU 초기화 및 인터럽트 처리를 담당하는 CPU 아키텍처 프로토콜을 제공합니다.
Timer (C190FE35-44AA-41A1-8AEA-4947BC60E09D)
- 시스템의 기본 타이머 아키텍처를 제공합니다. 스케줄링 및 딜레이 처리에 필수적입니다.
RuntimeDxe (B601F8C4-43B7-4784-95B1-F4226CB40CEE)
- OS로 진입한 후에도 유지되어야 하는 런타임 서비스 아키텍처 프로토콜을 제공합니다.
SecurityStubDxe (F80697E9-7FD6-4665-8646-88E33EF71DFC)
- 보안(Security) 아키텍처 프로토콜을 제공합니다. 이미지 검증 등의 기반이 됩니다.
VariableSmmRuntimeDxe (9F7DCADE-11EA-448A-A46F-76E003657DD1)
- UEFI 환경 변수(Variable) 읽기/쓰기를 위한 아키텍처 프로토콜입니다. 부팅 순서 등 핵심 정보 접근에 필요합니다.
ResetSystemRuntimeDxe (4B28E4C7-FF36-4E10-93CF-A82159E777C5)
- 시스템 재부팅 및 종료를 담당하는 Reset 아키텍처 프로토콜을 제공합니다.
MonotonicCounterRuntimeDxe (AD608272-D07F-4964-801E-7BD3B7888652)
- 단조 증가 카운터 아키텍처를 제공하며, 보안 및 식별 작업에 필수적입니다.
WatchdogTimer (F099D67F-71AE-4C36-B2A3-DCEB0EB2B7D8)
- 부팅 중 무한 루프에 빠지는 것을 방지하는 워치독 타이머 아키텍처입니다.
Metronome (C8339973-A563-4561-B858-D8476F9DEFC4)
- 매우 짧은 딜레이를 측정하는 Metronome 아키텍처 프로토콜입니다.
BdsDxe (6D33944A-EC75-4855-A54D-809C75241F6C)
- DXE 페이즈의 최종 목적지로, 이 드라이버가 실행되어야 비로소 부팅 가능한 디바이스를 찾고 OS 로더를 실행하는 BDS 페이즈가 시작됩니다.
PcRtc (378D7B65-8DA9-4773-B6E4-A47826A833E1)
RealTimeClockRuntimeDxe (B336F62D-4135-4A55-AE4E-4971BBF0885D)
- UEFI PI(Platform Initialization) 스펙에서 명시한 핵심 아키텍처 프로토콜(Architectural Protocols) 중 하나인 Real Time Clock (RTC) 아키텍처 프로토콜을 시스템에 제공합니다.
  - EFI_REAL_TIME_CLOCK_ARCH_PROTOCOL이 설치 되어야 부팅이 가능
  - QEMU환경 (x86 하드웨어, ARM 등 다른 환경에서는 다름)
    - PcRtc만 있으면 프로토콜이 설치 가능하지만
    - RealTimeClockRuntimeDxe만 있으면 하드웨어를 못읽어서 제대로 동작을 안함. 즉, PcRtc만 필수
ReportStatusCodeRouterRuntimeDxe (D93CE3D8-A7EB-4730-8C8E-CC466A9ECC3C)
- 시스템의 상태와 에러 로깅을 담당하는 상태 코드(Status Code) 아키텍처 프로토콜

위 12개의 드라이버를 앞으로는 '부팅실패드라이버모음'이라고 부르겠다.

[Edk2 v21.02 Depex에서 요구되는 드라이버 및 프로토콜]

드라이버	프로토콜
AcpiTableDxe	EfiAcpiTableProtocolGuid
BdsDxe	EfiBdsArchProtocolGuid
CpuDxe	EfiCpuArchProtocolGuid
CpuDxe	EfiMpServiceProtocolGuid
CpuIo2Dxe	EfiCpuIo2ProtocolGuid
DevicePathDxe	EfiDevicePathUtilitiesProtocolGuid
HiiDatabase	EfiHiiConfigRoutingProtocolGuid
	EfiHiiDatabaseProtocolGuid
	EfiHiiImageExProtocolGuid
	EfiHiiStringProtocolGuid
IoMmuDxe	EdkiiIoMmuProtocol
IoMmuDxe	IoMmuAbsentProtocol
Legacy5259	EfiLegacy8259ProtocolGuid
Metronome	EfiMetronomeArchProtocolGuid
MonotonicCounterRuntimeDxe	EfiMonotonicCounterArchProtocolGuid
PcdDxe	EfiPcdProtocolGuid
PcRtc	EfiRealTimeClockArchProtocolGuid
PiSmmIpl	EfiMmCommunication2Protocol
ReportStatusCodeRouterRuntimeDxe	EfiRscHandlerProtocolGuid
ResetSystemRuntimeDxe	EfiResetArchProtocolGuid
RuntimeDxe	EfiRuntimeArchProtocolGuid
SecurityStubDxe	EfiSecurityArchProtocolGuid
SetupBrowser	EdkiiFormBrowserEx2ProtocolGuid
SetupBrowser	EfiFormBrowser2ProtocolGuid
SmbiosDxe	EfiSmbiosProtocolGuid
SmmAccess2Dxe	EfiSmmAccess2ProtocolGuid
SmmControl2Dxe	EfiSmmControl2ProtocolGuid
SmmLockBox	EfiLockBoxProtocolGuid
Timer	EfiTimerArchProtocolGuid
VariableSmmRuntimeDxe	EfiVariableArchProtocolGuid
VariableSmmRuntimeDxe	EfiVariableWriteArchProtocolGuid
WatchdogTimer	EfiWatchdogTimerArchProtocolGuid

위 표 중에서 부팅실패드라이버모음을 제외하면 아래와 같은 표가 완성된다.

드라이버	프로토콜
AcpiTableDxe	EfiAcpiTableProtocolGuid
CpuIo2Dxe	EfiCpuIo2ProtocolGuid
DevicePathDxe	EfiDevicePathUtilitiesProtocolGuid
HiiDatabase	EfiHiiConfigRoutingProtocolGuid
	EfiHiiDatabaseProtocolGuid
	EfiHiiImageExProtocolGuid
	EfiHiiStringProtocolGuid
IoMmuDxe	EdkiiIoMmuProtocol
IoMmuDxe	IoMmuAbsentProtocol
Legacy5259	EfiLegacy8259ProtocolGuid
PcdDxe	EfiPcdProtocolGuid
PiSmmIpl	EfiMmCommunication2Protocol
SetupBrowser	EdkiiFormBrowserEx2ProtocolGuid
SetupBrowser	EfiFormBrowser2ProtocolGuid
SmbiosDxe	EfiSmbiosProtocolGuid
SmmAccess2Dxe	EfiSmmAccess2ProtocolGuid
SmmControl2Dxe	EfiSmmControl2ProtocolGuid
SmmLockBox	EfiLockBoxProtocolGuid

하지만 이 13개의 드라이버 중 부팅실패드라이버모음에서 요구되는 드라이버가 존재하여, 없을 경우 연쇄작용으로 부팅실패드라이버모음에 있는 드라이버가 실행이 안될 수 있으므로 이 또한 제외할 경우 최종적으로 아래와 같은 표가 완성된다.

드라이버	프로토콜
AcpiTableDxe	EfiAcpiTableProtocolGuid
CpuIo2Dxe	EfiCpuIo2ProtocolGuid
SetupBrowser	EdkiiFormBrowserEx2ProtocolGuid
SetupBrowser	EfiFormBrowser2ProtocolGuid
SmbiosDxe	EfiSmbiosProtocolGuid
SmmLockBox	EfiLockBoxProtocolGuid

즉, 위 표와 같이 총 5개의 드라이버만 남게 된다.

이 중 SmmLockBox는 SMM 드라이버이지만, 이 드라이버가 없을 경우 DXE 드라이버가 영향을 받으므로 포함한다.

UEFITool을 가지고 일부 드라이버를 삭제한 후 진행하려 하는데, NE 버전은 드라이버 삭제가 불가하고 이전 버전은 FV 내부의 체크섬이 깨질 수 있다.

따라서 OVMF.fd 파일을 만드는 방법은

1. UEFITool 0.28.0 버전으로 드라이버를 삭제

2. QEMU로 부팅 확인

이렇게 2단계를 거쳐서 진행하려 한다.

현재 기대되는 결과는 다음과 같다

드라이버	프로토콜	요구한 드라이버
AcpiTableDxe	EfiAcpiTableProtocolGuid	AcpiPlatform
CpuIo2Dxe	EfiCpuIo2ProtocolGuid	PciHostBridgeDxe
SetupBrowser	EdkiiFormBrowserEx2ProtocolGuid	DisplayEngine
SetupBrowser	EfiFormBrowser2ProtocolGuid	SecureBootConfigDxe RamDiskDxe DriverHealthManagerDxe
SmbiosDxe	EfiSmbiosProtocolGuid	SmbiosPlatformDxe
SmmLockBox	EfiLockBoxProtocolGuid	BootScriptExecutorDxe

AcpiTableDxe
1. AcpiPlatform 드라이버에서 요구, Bug로 판정
CpuIo2Dxe
1. PciHostBridgeDxe 드라이버에서 요구, Bug로 판정
SetupBrowser
1. DisplayEngine 드라이버에서 요구, Bug로 판정
2. SecureBootConfigDxe 드라이버에서 요구, Vulnerability로 판정
3. RamDiskDxe 드라이버에서 요구, Bug로 판정
4. DriverHealthManagerDxe 드라이버에서 요구, Bug로 판정
SmbiosDxe
1. SmbiosPlatformDxe 드라이버에서 요구, Bug로 판정
SmmLockBox
1. BootScriptExecutorDxe 드라이버에서 요구, Vulnerability로 판정

1. UEFITool 0.28.0 버전으로 드라이버를 삭제

5가지 드라이버를 각각 삭제한 총 5개의 fd 파일을 만들었다.

2. QEMU로 부팅 확인

Edk2 v21.02 빌드는 Ubuntu 24.02 LTS 환경에서 아래 블로그를 참고하며 진행하였다.

https://manguu.tistory.com/12

아래 사진은 정상적으로 부팅되었을 때 QEMU 화면이다.

AcpiTableDxe, SetupBrowser, SmbiosDxe, SmmLockBox 드라이버에 대해서는 부팅이 잘 완료 되었으나, CpuIo2Dxe 드라이버가 없을 경우 부팅이 완료되지 않았다.

이유를 찾아보니

CpuIo2Dxe가 없으면 PciHostBridgeDxe 실행이 안되는데, PciBusDxe가 Depex에는 PciHostBridgeDxe를 요구하지 않아서 로드는 되지만, PCI 열거(enumeration) 시점에 EfiPciHostBridgeResourceAllocationProtocol을 찾지 못해 동작에 실패한다. 따라서 CpuIo2Dxe 드라이버가 없을 경우 연쇄 작용으로 PciBusDxe의 동작이 실패하여 최종적으로 부팅에 실패하게 되는 것이다.

정리하자면,

CpuIo2Dxe 없음 → PciHostBridgeDxe 로드 실패 → PciBusDxe가 PCI 장치 열거 불가 → 부팅 불가

따라서 CpuIo2Dxe 드라이버를 제외한 4개의 드라이버에 대해 검증을 하도록 한다.

추가로 앞서 소개한 Depex에서 요구되는 모든 드라이버에 대해 존재하지 않을 때 부팅 여부를 확인해본 결과, 위 4가지 드라이버를 제외한 모든 드라이버가 예상했던 대로 부팅이 완료되지 않았다. -> 4개의 드라이버를 검증 대상으로 하는 근거 검증 완료

간단히 정리하자면 아래와 같다. 사용할 OVMF.fd 파일도 같이 올린다.

현재 펌웨어볼륨 환경 : edk2 v21.02버전
DXE 드라이버 개수 : 101개
DEPEX에서 요구되는 (프로토콜을 설치하는) 드라이버(SMM 드라이버 포함) : 25개
삭제될 경우 부팅이 완료되지 않을 드라이버 (SMM 드라이버 포함) : 20개
-> 없어도 부팅이 완료될 드라이버 5개
   1. AcpiTableDxe
   2. CpuIo2Dxe
   3. SetupBrowser
   4. SmbiosDxe
   5. SmmLockBox

OVMF.fd

4.00MB

[검증]

AcpiTableDxe
- AcpiPlatform 드라이버에서 요구, Bug로 판정 => 정탐

SetupBrowser
- DisplayEngine 드라이버에서 요구, Bug로 판정 => 정탐
- SecureBootConfigDxe 드라이버에서 요구, Vulnerability로 판정 => 정탐
- RamDiskDxe 드라이버에서 요구, Bug로 판정 => 정탐
- DriverHealthManagerDxe 드라이버에서 요구, Bug로 판정 => 정탐

SmbiosDxe
- SmbiosPlatformDxe 드라이버에서 요구, Bug로 판정 => 정탐

SmmLockBox
- BootScriptExecutorDxe 드라이버에서 요구, Vulnerability로 판정 => 정탐

검증 결과 4개의 드라이버에 대해 0%의 오탐률을 확인하였다.

Edk2 빌드 (smm 드라이버 포함)

망구입니다 — Thu, 2 Apr 2026 00:57:30 +0900

# 1. 필수 패키지 설치
sudo apt update
sudo apt install build-essential uuid-dev acpica-tools git gcc g++ nasm python3 python3-setuptools

# 2. EDK2 소스코드 다운로드 및 폴더 이동
git clone https://github.com/tianocore/edk2.git
cd edk2

# 3. 안정화 버전 체크아웃 및 서브모듈 업데이트
git checkout edk2-stable202102
git submodule update --init --recursive

# 4. GCC 9 설치 및 기본 컴파일러로 등록 (명령어 분리 완료)
sudo apt update
sudo apt install gcc-9 g++-9
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-9 100
sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-9 100

# 5. BaseTools 컴파일 및 환경 변수 초기화
make -C BaseTools
source edksetup.sh

# 6. 펌웨어 빌드 (SMM 및 Secure Boot 포함)
build -a X64 -p OvmfPkg/OvmfPkgX64.dsc -b RELEASE -t GCC5 -D SECURE_BOOT_ENABLE=TRUE -D SMM_REQUIRE=TRUE

# 7. QEMU 실행
qemu-system-x86_64 \
  -machine q35,smm=on \
  -global ICH9-LPC.disable_s3=1 \
  -global driver=cfi.pflash01,property=secure,value=on \
  -m 1024M \
  -drive if=pflash,format=raw,unit=0,file=Build/OvmfX64/RELEASE_GCC5/FV/OVMF.fd,readonly=on \
  -drive if=pflash,format=raw,unit=1,file=./test_VARS.fd \
  -vga std
  
  위 코드에서 OVMF.fd 부분에 자신이 조작한 fd 파일 넣어서 부팅도 가능

[프로젝트]UEFI DXE 바이너리 취약점 분석기 10주차 - Ghidra Script 수정

망구입니다 — Sun, 29 Mar 2026 22:43:53 +0900

지난주에 Missing Protocol만 가지고 취약점 탐지를 하기로 정했다.

기존에 진행하던 방식인 "기드라 Pcode 분석을 통한" 프로토콜 설치 탐지를 진행했었는데, 정보과학회 논문 작성까지 오탐률 적은 스크립트가 나올 것 같지 않아 급하게 방향을 틀게 되었다.

주말동안 팀원분들께 미리 말씀은 드려 놓았지만, 교수님의 의견이 중요할 것 같아서 상의가 필요하다고 생각했다.

[현재 상황 및 교수님, 팀원분들과 상의하고 싶은 것]

현재 DXE 드라이버가 설치하는 Protocol 탐지가 제대로 되지 않는 상황
- UEFI 특유의 간접 호출 (ex. gBS->InstallProtocolInterface(...))
- GUID 추적이 데이터플로우인 문제 (프로토콜을 찾으려면 InstallProtocolInterface(&Handle, &GUID, ...) 이런걸 해야 하는데 실제로는 GUID가 전역에 있고, 중간에 레지스터를 여러번 거치는 등)
- Protocol Install 자체가 Runtime event이므로 정적 분석만으로는 100% 탐지가 어려움
  - Protocol Install은 “코드 구조”가 아니라 “실행 시점의 상태 변화(Runtime behavior)”이기 때문에, 바이너리만 보고는 확정할 수 없는 경우가 많다.
  - UEFI에서 프로토콜 설치는 보통:
    gBS->InstallProtocolInterface(...)
    gBS->InstallMultipleProtocolInterfaces(...)
    를 통해 이루어짐. 이 호출 자체는 단순 API 호출일 뿐. 실제 의미는 'Handle Database 상태 변경'. 즉,
    Handle X
    └── Protocol GUID 추가됨 (runtime에)
    이건 전역 런타임 객체 변화
    
    정적 분석은 코드 구조만 볼 뿐 실행 후 Handle DB 상태는 못 본다.
- 등등의 여러 이유 때문에 어렵다고 합니다.
그래서 논문에서는 지난번에 했던 것처럼 휴리스틱하게 하더라도, EDK2를 타겟으로 잡고 EDK2에 들어있는 모든 DXE 드라이버가 설치하는 프로토콜을 수기로 정리해서 집어 넣는 방식으로 해서 오탐을 줄이는 것에 대해 어떻게 생각하는지 물어보고 싶습니다.
일광이가 현재 제 스크립트 때문에 헤드리스 스크립트를 갈아 엎은 상태인데, 지금 하던 일이 의미가 없어지는 것이 아니냐 -> 아닙니다. 어차피 확장해야 하고, EDK2 뿐만 아니라 좀 더 general 하게 하려면 이번학기 안에 시도 했어야 할 문제이기 때문에, 의미가 없어지는 것은 아닙니다. 하지만 서두르게 한 점 죄송합니다.
general 하게 하고싶지만 이건 제가 좀 더 깊게 공부를 해야 하는 상황인 것 같고 현재 논문 마감이 약 3주가량 남았기 때문에 3월 안에는 모든 스크립트에 대한 결과가 나와야 한다고 생각해서 내린 결정입니다. 또한 박사님께서 'general은 좀 위험한 발언인 것 같다' 라고 하셔서 EDK2를 타겟으로 하는 게 어떠신지 묻고싶습니다.

그렇다면 현재 저의 스크립트의 방향성에 대한 두가지 방법이 존재하는데,

스크립트 갈아 엎기 전에 사용했던 방식을 EDK2의 모든 드라이버에 대해 적용(휴리스틱)
현재 로직을 EDK2로 한정해서 사용

-> 2번의 방법으로 논문 쓰기 전에 완성할 수 있을지는 미지수임

-> 그래서 일단 1번 스크립트를 완성시키고 2번을 빠르게 진행해보면서, 3월 안(혹은 4월 첫째주까지)에 완성이 되면 논문으로 작성하는 방식으로 진행해야 할 것 같음.

현재 1번 스크립트는 완성 되어 있는 상황.

[로직]

0. edk2 github에서 소스코드 다운 & UEFIExtract 툴로 덤프 폴더 추출

1. 파이썬 스크립트(generate_protocol_switch.py) 맨 아래 부분에 위 두 폴더 경로 설정 후 실행 -> JAVA switch-case문 생성

2. 생성된 switch-case문을 가지고 자바 스크립트(DepexHunter_v3_0_0)에 넣기

3. Headless.py 스크립트로 실행

generate_protocol_switch.py

0.01MB

DepexHunter_v3_0_0.java

0.04MB

Headless.py

0.07MB

Python 파서(generate_protocol_switch.py)

SOMETIME_PRODUCES (오타 포함), SOMETIMES_PRODUCES, PRODUCED 계열 전부 provider로 인정
# 단일 주석 스타일도 파싱 (# PROTOCOL ALWAYS_PRODUCED)
Guid 접미사 제거로 GUID DB 이름과 매칭
dump 폴더 교차검증으로 여러 후보 중 실제 펌웨어에 있는 드라이버 우선 선택
MODULE_TYPE 필터로 라이브러리 .inf 제외

.inf 파일의 [Protocols] 섹션 파싱
↓
PRODUCES tag만 선택
↓
실제 firmware dump driver와 교차검증
↓
provider 결정

heuristic보단 'knowledge-assisted dependency inference'라고 사용하는 것이 어떨지...

Java 스크립트(DepexHunter_v3_0_0.java)

allDiscoveredSmmDrivers 분리로 SMM 드라이버(Subtype: SMM module) 별도 수집
inferAllProviders()에서 DXE + SMM 둘 다 교차검증
knownProtocolProvider()에 Guid 없는 버전과 있는 버전 둘 다 등록
systemProtocols 이름을 GUID DB 형식에 맞게 수정
findDriverNameFromParents()에 Subtype: SMM module 추가
Vulnerability와 Bug 구분 (보안 드라이버 vs 일반 드라이버)
Headless 환경 맞춤으로 수정

Headless 스크립트 (Headless.py)

depex 스크립트 실행 시 필요한 cmd 인자 변경
normalize_depex_report_records함수에 취약점/버그 구분 로직 추가
DepexHunter 스크립트 3_0_0으로 버전 수정

[프로젝트]UEFI DXE 바이너리 취약점 분석기 9주차 - 취약점 선정 및 Ghidra Script 수정

망구입니다 — Wed, 18 Mar 2026 15:30:07 +0900

저번주에 언급했던 부분 중 취약점 개수를 줄이는 방향으로 가는 것이 좋을 것 같다는 의견을 주셔서 1개로 줄여보았다.

[선정된 취약점]

Missing Protocol Vulnerability
- 취약점 정의
  - 핵심 원인 : DXE 드라이버의 DEPEX가 요구하는 특정 프로토콜의 GUID를 제공(Install)하는 드라이버가 펌웨어 내에 존재하지 않는 상태.
  - 상태 정의 : 해당 드라이버는 실행 준비 단계인 Scheduled로 전이되지 못하고, 무한히 Dependent(대기) 상태에 머물게 됨.
- 일반 결함(Bug)과의 차별점
  - 일반 드라이버 : 주변 장치(마우스, 오디오 등) 작동 불능 → 가용성 저하(기능적 결함).
  - 보안 드라이버 : 인증 및 검증 로직 생략 → 기밀성 및 무결성 파괴(보안 취약점).
- 취약점 성립 근거 (보안 드라이버 중심)
  - 보안 체인(Chain of Trust) 단절 : Secure Boot, TPM 초기화, 암호화 엔진 등 보안 필수 드라이버가 로드되지 않음으로써 전체 시스템 보호막이 형성되지 않음.
  - Fail-Open 구조 : 시스템이 보안 검사 실패 시 부팅을 중단(Fail-Safe)하는 것이 아니라, 검사 드라이버 자체의 누락을 무시하고 부팅을 강행(Fail-Open)하기 때문에 취약점이 됨.
  - 권한 상승(Privilege Escalation) : 보안 드라이버가 부재한 틈을 타 공격자가 커널 권한으로 악성 코드를 실행하거나 보안 설정을 임의로 조작할 수 있음.
- 예시
  - 상황 : SecureBootVerify라는 드라이버가 실행되려면 HashProtocol 필요.
  - 문제 : 펌웨어 내에 HashProtocol을 설치해주는 드라이버 누락.
  - 결과 : SecureBootVerify는 영원히 실행되지 않고 대기(Dependent) 상태가 됨. DXE Dispatcher는 이 드라이버를 건너뛰고 다음 부팅 단계로 넘어가 버릴 수 있으며, 결국 서명되지 않은 악성 코드가 실행될 수 있는 환경이 조성됨.
~~Cycle Vulnerability~~
- ~~취약점 정의~~
  - 핵심 원인 : 두 개 이상의 DXE 드라이버가 DEPEX(의존성 식별자)를 통해 서로를 참조하거나(A→B, B→A), 복잡한 경로를 거쳐 자기 자신에게 돌아오는 순환 구조를 형성하는 상태.
  - 상태 정의 : DXE Dispatcher가 의존성 그래프를 해석할 때 Deadlock에 빠져, 관련 드라이버들이 결코 Scheduled 상태로 전이되지 못함.

- Cycle 취약점의 경우 Deadlock이 발생하는 것이 아니라, Cycle을 생성하는 드라이버가 실행되지 않는 문제로, 결국 1번 Missing Protocol 취약점으로 귀결되기 때문에 삭제

[선정되지 않은 취약점]

bypass, dead, alwaystrue, alwaysfalse Vulnerability
- 이 경우 단순한 정적 분석 수준으로, UEFITool 등을 사용하게 되면 쉽게 눈으로도 직접 찾아낼 수 있기 때문에 이번 우선순위에서는 밀리게 됨.
Before/After Vulnerability
- Missing Protocol의 탐지 로직과 유사하여, 이를 구현하면서 부가적으로 처리될 수 있는 취약점이라고 생각함.
Malicious Vulnerability
- 현재 수준은 단순한 '블랙리스트 매칭'이므로, 선정된 취약점을 처리하고 난 다음 단계에서 직접 드라이버를 분석하여 악성 드라이버인지 확인하는 로직을 추가하여 탐지할 예정.

[현재 진행 상태]

Missing Protocol 취약점을 탐지하기 위해 기존에 작성되어 있던 사용하지 않을 취약점 탐지 로직을 전부 삭제하고 두 취약점에 대한 로직은 기존대로 진행하려 하였으나, 기존 로직이 휴리스틱하게 탐지하는 것이 맘에 들지 않아 전부 수정에 들어감.
Missing protocol의 경우, 각 드라이버가 생성하는 Protocol을 pcode 분석을 통해 알아내고, 그 설치되는 Protocol목록과 DEPEX에 적혀 있는 Protocol을 매칭하며, 리스트에 없는 Protocol이 없을 경우 탐지하는 로직을 생성중.

현재 edk2를 빌드할 때 생성된 OVMF.fd 파일에서 HiiDatabaseDxe 드라이버를 삭제하고 스크립트를 돌려보았을 때, 위와 같이 HiiDatabaseDxe 드라이버가 생성하는 EfiHiiDatabaseProtocol, EfiHiiStringProtocol, EfiHiiConfigRoutingProtocol, EfiHiiImageExProtocol이 존재하지 않다고 잘 잡아냈고, 보안 관련 드라이버가 필요한 Protocol이 없을 경우 취약점이 아니라 버그로 잡기로 로직을 생성해놔서 위와 같은 결과물이 나와있다.

맨 위의 EfiFirmwareVolumeBlock2Protocol은 FvbServicesRuntimeDxe 드라이버가 생성하는 프로토콜인 것 같은데, 잘못 탐지 된 것 같다. 왜 탐지 되었는지 좀 더 알아봐야 할 것 같다.

완성된 스크립트가 아니고, 로직 수정도 더 필요해서 코드 공유는 안할 예정이다.

다음주에도 로직 보강에 힘을 써볼 예정이다.

[프로젝트]UEFI DXE 바이너리 취약점 분석기 8주차 - Ghidra Script 로직 보강

망구입니다 — Mon, 16 Mar 2026 09:10:03 +0900

이번 주에는 지난 주에 여러 취약점을 추가한 기드라 스크립트에 필요한 로직 보강과 추가 취약점 분석을 추가하는 방향으로 진행하였다.

[수정 사항]

논리식 평가 고도화
빈 DEPEX (Empty DEPEX) 조기 탐지 로직 추가 및 Apriori 파일에 존재하는 드라이버일 경우 제외 처리 추가
OP_SOR 오프코드 처리 방식 수정
프로토콜 제공자(Provider) 추론 로직 경량화
악성 코드가 들어있는 드라이버를 하나 정의하고, DEPEX에 그 드라이버의 GUID가 존재한다면 잡아내는 취약점 추가
취약점 탐지라는 핵심 목적과 무관하게 폴더에 생성되던 dependency_graph.txt 및 protocol_providers.txt 관련 변수 (graphWriter, protocolWriter)와 생성 메서드 삭제
이 외의 자잘하게 로직 보강

GhidraDepexHunter_v8.java

0.05MB

위 수정 사항 외에 필요한 부분은 아래와 같다. 다음주부터 보강할 계획이다.

[수정 예정 사항]

SOR 연산 로직 보강 필요 ( -> 굉장히 까다로움)
bypass (TRUE OR), dead (FALSE AND)에 대해 좀 더 알아보기
simplifyExpression 함수 로직 보강 필요 (AST 기반 parser 필요할듯)
Missing protocol 로직 보강 필요 -> 많은 protocol이 DXE Driver가 제공하는 것은 맞지만, SMM core, PEI phase, Platform code 등에서 제공되는 경우도 존재. 이에 대한 보강 필요.
currentProgram.getMemory().findBytes(...) 로직 보강 필요 (GUID Search 로직)
Malicious GUID detection 로직 보강 필요(Protocol GUID와 Driver GUID 구분 필요 -> 일반적인 AND/OR 조합에서 쓰는 guid는 protocol, before/after 조함에서 쓰는 guid는 driver)
protocol provider inference 로직 보강 필요 (휴리스틱함)

현재 8개의 취약점을 탐지하고 있는데, 가장 치명적이고 중요한 취약점을 소량 정하여 집중적으로 탐지하면서 오탐률을 줄이는 것이 좋을 것 같다는 생각이 들었다.

이제 앞으로 진행할 부분에 대해 정리를 해보자면,

성능 실험
위 [수정 예정 사항] 부분 로직 보강 및 조사
탐지하면 좋을만한 취약점 추가 조사 및 CVE 조사
취약점 조사를 마치고, 그 중 4~5개정도 추려서 기준을 잡은 후 집중적으로 로직 보강 및 정확도 올려나가기
타임스탬프 찍기

[교수님, 팀원분들과 상의할 내용]

지난주에 protocol_providers.txt 파일(protocol을 제공해주는 driver 정리)과 dependency_graph.txt 파일(DEPEX를 기반으로 한 의존성 그래프)을 생성 했었는데, "취약점 탐지 스크립트"라는 주제와는 살짝 멀어진 것 같아서 이번주에는 뺀 상황. 이를 복구시키는 것이 좋을지, 아니면 유지하는 것이 좋을지
취약점 4~5개에 집중하는 것이 괜찮을지
JSON 파일 형식 정확히 정하기

dependency_graph.txt

protocol_providers.txt