voidsec/driverbuddyreloadedDriver Buddy Reloaded는 Windows 커널 드라이버 리버스 엔지니어링 작업 중 일부 지루한 부분을 자동화하는 데 도움을 주는 IDA Pro Python 플러그인입니다.
설치 방법은 사용 중인 IDA 버전에 따라 다릅니다. 내장 플러그인 관리자(따라서 hcli 도구 및 ida-plugin.json 매니페스트)는 IDA 9.0 이상에서만 존재하기 때문입니다. IDA 7.6 및 8.x에는 플러그인 관리자가 없으며, 플러그인 폴더의 최상위 레벨만 스캔합니다.
hcli)리포지토리에는 ida-plugin.json 매니페스트가 포함되어 있으므로, IDA 9.0+는 자체 하위 디렉터리에서 플러그인을 로드합니다. 다음과 같이 설치하세요:```
hcli plugin install DriverBuddyReloaded
이 플러그인을 사용자 플러그인 폴더의 하위 디렉터리(예: `%APPDATA%\Hex-Rays\IDA Pro\plugins\DriverBuddyReloaded\` 또는 `~/.idapro/plugins/DriverBuddyReloaded/`)에 넣되, `DriverBuddyReloaded.py` 진입점은 해당 하위 디렉터리 *안에* 유지합니다. 이것이 의도된 레이아웃입니다. IDA가 매니페스트를 읽고, 선언된 진입점을 하위 디렉터리에서 로드하며, `sys.path`에 하위 디렉터리를 추가하여 진입점이 형제 `DriverBuddyReloaded` 패키지를 임포트할 수 있게 합니다. `DriverBuddyReloaded.py`를 최상위로 이동할 **필요가 없습니다**.
`hcli plugin status`로 설치를 확인한 다음 IDA를 시작하고 플러그인이 `편집 -> 플러그인` 아래에 나타나는지 확인합니다(시작 시 Python 오류가 있는지 출력 창 확인).
로컬 체크아웃에서 테스트를 위해 설치하려면(예: 자체 변경 후) 저장소 루트에서 `hcli plugin install .`을 실행합니다. `hcli plugin lint .`는 먼저 매니페스트/레이아웃의 유효성을 검사합니다.
### IDA 7.6 / 8.x (수동 복사)
이 버전에는 플러그인 관리자가 없으므로 `hcli`로 설치된 하위 디렉터리 플러그인은 인식되지 **않습니다**. `DriverBuddyReloaded` 폴더와 `DriverBuddyReloaded.py` 스크립트 파일을 IDA 플러그인 폴더의 **최상위**에 직접 복사합니다. 예:
- `%APPDATA%\Hex-Rays\IDA Pro\plugins\`
- `C:\Program Files\IDA Pro 8.4\plugins\`
- `~/.idapro/plugins/`
결과 레이아웃은 `plugins\DriverBuddyReloaded.py`와 `plugins\DriverBuddyReloaded\`(패키지 폴더)가 함께 있는 것입니다.
### 참고 사항
IDA가 Python 2로 구성된 경우, `idapyswitch` 바이너리(IDA 폴더에 있음)를 실행하여 Python 3으로 전환하세요.
**참고:** Driver Buddy Reloaded는 Python 3과 함께 IDA 7.6+, 8.x(8.4 포함) 및 9.0+에서 실행됩니다. 모든 버전별 IDA API 차이점(IDA 9.0에서 `get_inf_structure` 제거, `ida_struct` 모듈 및 `idc.*struc*` 헬퍼 제거 등)은 `DriverBuddyReloaded/ida_compat.py` 호환성 계층에서 내부적으로 처리됩니다.
## 빠른 사용법
자동 분석 기능을 사용하려면:
1. IDA를 시작하고 Windows 커널 드라이버를 로드합니다.
2. `편집 -> 플러그인 -> Driver Buddy Reloaded`로 이동하거나 `CTRL+ALT+A`를 눌러 자동 분석을 시작합니다.
3. "출력" 창에서 분석 결과를 확인하고, 실행 종료 시 열리는 **Driver Buddy Reloaded - Findings** 창을 확인합니다(행을 더블클릭하면 해당 주소로 이동합니다).
4. IDA의 DB 디렉터리 아래에 다음 파일들이 기록됩니다(모두 `<DRIVER_NAME>-YYYY-MM-DD-TIMESTAMP-` 접두사):
- `findings.json` - 기계 판독 가능한 결과(IOCTL, 플래그된 함수, 장치 이름, 풀 태그, 호출 체인, 휴리스틱, 장치 ACL 감사, 심볼릭 링크, 내보내기 감사, 특권 명령어)
- `report.html` - 독립 실행형, 심각도별로 그룹화된 HTML 보고서
- `pooltags.txt` - WinDbg용 `pooltags.txt` 형식으로 덤프된 풀 태그
- `autoanalysis.txt` - 전체 텍스트 분석 로그(출력 창 미러)
IOCTL을 디코딩하려면:
1. 의심되는 IOCTL 코드가 있는 줄에 마우스 커서를 놓습니다.
2. 마우스 오른쪽 버튼을 클릭하고 `Driver Buddy Reloaded -> Decode IOCTL`을 선택하거나 `CTRL+ALT+D` 단축키를 누릅니다.
분석을 다시 실행하지 않고도 언제든지 IOCTL 창이나 결과 창을 다시 열려면:
- `CTRL+ALT+I`를 누르면 IOCTL 창이 열립니다.
- `CTRL+ALT+F`를 누르면 결과 창이 열립니다.
### 고급 사용법
- [vulnerable_function_lists](https://github.com/voidsec/driverbuddyreloaded/blob/main/DriverBuddyReloaded/vulnerable_functions_lists) 디렉터리에는 잠재적으로 위험한/문제가 있는 함수, Windows API 및 명령어 목록이 포함되어 있으며, 특정 함수/API가 나열된 이유에 대한 간단한 설명이 제공됩니다. `custom` 목록을 편집하여 드라이버별 함수를 포함할 수 있습니다.
**참고**: `winapi_function_prefixes`는 함수 이름의 시작 부분과 부분 일치합니다(예: `Zw`는 `ZwClose`, `ZwCommitComplete` 등과 일치). 반면 `winapi_functions`는 정확히 일치하는 경우만 수행합니다.
- [find_opcodes.py](https://github.com/voidsec/driverbuddyreloaded/blob/main/DriverBuddyReloaded/find_opcodes.py)에서 `find_opcode_data` 옵션(기본값 `False`)은 데이터 섹션에 있는 명령어 일치를 억제합니다([issue #11](https://github.com/VoidSec/DriverBuddyReloaded/issues/11)). `True`로 전환하면 데이터의 원시 바이트 일치도 표시됩니다. 이 방법으로 실제 명령어가 누락된 경우 보고된 주소로 이동하여 해당 바이트를 코드로 재정의하면 일반적으로 복구됩니다. 일치는 다른 단계와 마찬가지로 보고됩니다(결과 창, `findings.json`, `report.html`).
**주의**: `True`로 전환하면 더 많은 오탐지가 발생합니다!
## Driver Buddy Reloaded 소개
**Driver Buddy Reloaded**는 IDA Pro Python 플러그인으로, Windows 커널 드라이버 리버스 엔지니어링 작업 중 일부 지루한 작업을 자동화하는 데 도움을 줍니다. 다음과 같은 여러 유용한 기능이 있습니다.
* 드라이버 유형 식별 (WDM, KMDF, UMDF, WDF, 미니필터, 스트림 미니드라이버, AVStream, PortCls)
* **모든** 드라이버 유형에 대한 `DispatchDeviceControl` / `DispatchInternalDeviceControl` 함수 찾기
(`MajorFunction[IRP_MJ_DEVICE_CONTROL]` 저장소 스캔은 미니필터/WDF 드라이버에서도 핸들러를 찾고, 할당이 `DriverEntry` 대신 헬퍼에 있는 경우에도 찾습니다.)
* `WDF` 및 `WDM` 드라이버에 대한 공통 구조체 채우기
* `IRP` 및 `IO_STACK_LOCATION`과 같은 구조체 식별 및 레이블링 시도
* 일반적으로 레이블이 지정되지 않을 `WDF` 함수 호출에 레이블 지정
* `IRP_MJ_FUNCTION` IDA 열거형을 생성하고 `DriverEntry`의 `MajorFunction` 배열 슬롯에 적용 (WDM)
* IOCTL 코드 찾기 및 디코딩
* 식별된 디스패처 함수에 대한 자동 다중 전략 스캔 (커서 배치 불필요):
디컴파일러 ctree (점프 테이블이나 이진 검색 디스패치로 숨겨진 코드를 복구하여 즉시 값으로 나타나지 않는 코드), IDA 스위치 테이블 복구, 원시 즉시 피연산자 폴백 (폴백은 실제로 IRP의 IoControlCode를 읽는 함수에서만 실행되므로 잘못 식별된 라이브러리 헬퍼가 내부 상수를 오탐지 IOCTL로 누출할 수 없음)
* NTSTATUS 값이 IDA 타입 데이터베이스에서 동적으로 확인되고 (광범위한 하드코딩된 폴백 사용), 드라이버가 단순히 다운스트림으로 보내는 **출력** IOCTL (`IoBuildDeviceIoControlRequest` / `ZwDeviceIoControlFile` / ...)은 제외되어 드라이버 자체 공격 표면으로 오인되지 않음
* 오용되기 쉬운 함수 플래그 지정
* 잠재적 `DeviceName` 찾기 (mmap 스캔 + IDA 문자열 DB 폴백, 소스 주소 포함)
* `Pooltags` 덤프 (가져오기 기반 기본 + 레지스터 전파 폴백, 태그가 레지스터에 준비된 경우)
* 각 디스패처 및 해당 디스패처가 전이적으로 호출하는 함수에 대한 **휴리스틱 취약점 검사**: 검증되지 않은 사용자 복사, TOCTOU/이중 가져오기, 사용 후 해제 (함수 내 및 해제된 전역 변수를 통한 함수 간), 누락된 권한 게이트, IRQL 불일치, 안전하지 않은 MDL 매핑, 스택 할당 버퍼 (`_alloca`), 크기 검증 없는 풀 할당, 특권 CPU 명령어 (포트 I/O `in`/`out`, `mov cr*`), 임의 쓰기 (write-what-where), 및 `\Device\PhysicalMemory` 참조 (BYOVD 패턴) - [휴리스틱 취약점 검사](#heuristic-vulnerability-checks) 참조
* **장치 ACL 감사 및 심볼릭 링크 추적**: 보안 설명자 없이 생성된 `IoCreateDevice` 장치 (전역 접근 가능) / 약한 `IoCreateDeviceSecure` SDDL 플래그 지정, `IoCreateSymbolicLink` 대상 경로 디코딩
* **내보내기 감사**: 내부 교차 참조가 없는 드라이버 내보내기 플래그 지정 (잠재적 공격 표면)
* IOCTL별 **위험 점수** 디코딩 (`METHOD_NEITHER` / `FILE_ANY_ACCESS` 우선 순위 지정, 그리고 **자체** 케이스 핸들러에서 도달 가능한 위험한 싱크/명령어(`MmMapIoSpace`, `memcpy`, `__writemsr`, 포트 I/O, PCI-구성 액세스)에 대해서만 IOCTL 점수 상향 - 따라서 모놀리식 디스패처에서 양성 코드가 위험한 형제의 싱크로 인해 더 이상 타격을 받지 않으며, 귀속이 부정확한 경우 점수 상향은 강제로 CRITICAL이 아닌 제한됨), 모든 결과를 심각도별로 클릭 가능한 결과 창에 표시 (더블클릭하여 주소로 이동)
* 디스패치 / IOCTL 핸들러에서 위험한 싱크로의 **호출 체인 추적** (휴리스틱, 이름 기반)
* 결과를 기계 판독 가능한 **JSON** 파일 및 독립 실행형 **HTML** 보고서로 내보내기
### DispatchDeviceControl 찾기
이 도구는 자동으로 `DispatchDeviceControl` 루틴을 찾아 식별할 수 있습니다. 이 함수는 들어오는 모든 `DeviceIoControl` 코드를 해당 코드와 연결된 특정 드라이버 함수로 라우팅하는 데 사용됩니다. 이 함수를 자동으로 식별하면 각 드라이버에 대한 유효한 `DeviceIoControl` 코드를 훨씬 빠르게 찾을 수 있습니다. 또한 충돌로 인해 드라이버의 가능한 취약점을 조사할 때 이 함수의 위치를 알면 충돌하는 `DeviceIoControl` 코드와 관련된 특정 함수 호출에 초점을 좁히는 데 도움이 됩니다.
분석이 성공하면 일부 하위 함수는 다음과 같이 이름이 변경됩니다.
- `DriverEntry`: 드라이버가 로드된 후 호출되는 원래 첫 번째 드라이버 제공 루틴입니다. 드라이버 초기화를 담당합니다.
- `Real_Driver_Entry`: 일반적으로 `DriverEntry`에서 실행이 전송된 함수입니다. 일반적으로 `DeviceName`이 초기화되는 곳입니다.
- `DispatchDeviceControl`/`DispatchInternalDeviceControl`: 도구가 특정 오프셋에서 함수를 복구할 수 있는 경우 함수는 적절한 이름으로 이름이 변경됩니다.
- `Possible_DispatchDeviceControl_#`: 도구가 `DispatchDeviceControl` 또는 `DispatchInternalDeviceControl`을 복구할 수 없는 경우, 실험적 검색을 사용하여 실행 흐름을 따라가고 함수가 알려진 `IO_STACK_LOCATION` 및 `IRP` 주소를 로드하는 경우를 확인합니다. 이는 함수가 DispatchDeviceControl일 수 있음을 나타냅니다. 휴리스틱에 기반하므로 둘 이상의 결과를 반환할 수 있으며 오탐지가 발생하기 쉽습니다.