fuzz

Windbg Postmortem

TESTING — Tue, 20 Jan 2026 14:19:50 +0900

windbg /I 로 켤 수 있지만, 이걸 끄려면 별도의 명령어가 없다. (;;;)
registry를 통해서 꺼야하는데, 매번 검색하고 뭐 하기 귀찮아서 저장용..

reg edit을 매번 키는것도 귀찮지만...

64-bit: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug
32-bit(WoW64): HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug

위 경로를 찾아서 Auto를 0으로, Debugger의 string값을 삭제하여 꺼주면 된다. 아래는 disable.reg로 저장해서 실행하면 되는 방식

; Disable postmortem debugger (64-bit)
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug]
"Auto"="0"
"Debugger"=-
"UserDebuggerHotKey"=dword:00000000

; Disable postmortem debugger (32-bit apps on 64-bit Windows)
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug]
"Auto"="0"
"Debugger"=-
"UserDebuggerHotKey"=dword:00000000

이건 prompt 버전

:: Disable postmortem debugger (64-bit)
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug" /v Auto /t REG_SZ /d 0 /f
reg delete "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug" /v Debugger /f
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug" /v UserDebuggerHotKey /t REG_DWORD /d 0 /f

:: Disable postmortem debugger (32-bit apps on 64-bit Windows)
reg add "HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug" /v Auto /t REG_SZ /d 0 /f
reg delete "HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug" /v Debugger /f
reg add "HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug" /v UserDebuggerHotKey /t REG_DWORD /d 0 /f

확인 방법은 다음과 같음

reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug" /v Auto
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug" /v Debugger

Lighthouse Plugin for IDA 9.2+

TESTING — Mon, 5 Jan 2026 16:25:23 +0900

IDA에서 가장 즐겨쓰는 플러그인은 Lighthouse인데, IDA 9.2로 넘어가면서부터 Qt5를 버리고 Qt6로 갈아탄다고 한다.
그래서 pyside6로 코드를 수정하거나, qt5 호환이 가능하도록 configuration파일을 수정하면 되는데... 다음과 같은 이슈들을 고려해보게 되었다.

1. IDA Pro 9.0버전에서도 잘 동작하지 않아서 코드를 바꿔 쓴 경험

2. pyside6로 넘어가고 나서는 다시 Qt5로 돌아오기는 어려울 것 같다는 생각

3. 최신 버전에서 구 버전 레러시 지원하는 기능이 언제 종료일지 모른다는 공지

4. 이제 우리에겐 LLM이 있다(제일 중요..)

위와 같은 이슈들로 인해 pyside6로 변경하기로 했다.

물론 선구자들도 있었으나, 내 버전이 문제인지 내가 무언가 잘못한건지는 모르겠지만 잘 안돼서 이걸 사용하지는 못했다.
https://github.com/gaasedelen/lighthouse/pull/157/commits/c5cc03d7dc96adc762b2761c9b9d791a67419f53

IDA 9.2 fixes by 0xdea · Pull Request #157 · gaasedelen/lighthouse

I have put together a quick patch to make lighthouse work on IDA 9.2. I've tested it on both IDA 9.2 and 9.1 on macOS aarch64. See also #145, #146, and #156.

github.com

그래서 그냥 LLM으로 코드를 수정했고, 프롬포트는 크게 신경 슬 필요도 없었다.

한 번 pyside6로 변경하면 아마 쭉 쓸 가능성이 높기 때문에, 호환성과 더불어 내가 필요한 부분을 좀 더 개선시키면서 필요없는 부분을 쳐내는게 중점이었다.

먼저 코드를 다양하게 훑어볼텐데, 나는 바이너리 닌자를 사용하지 않기에 추후에도 그쪽에 토큰 낭비되는게 싫어서 바이너리 닌자관련 코드를 전부 삭제하고 시작했다. 이후 불필요한 코드를 삭제하고 IDA Docs를 전달하여 변경된 API들을 적절히 변환했다.

이후 가장 중요한 Qt5로 작성되어있는 코드를 Qt6에 해당하는 pyside6로 변경해달라고 요청했고, 생각보다 금방 코드를 전부 바꿔주었다. 코드가 그리 복잡한 편은 아니기도 하고, LLM의 발전 속도가 워낙 빨라서 그런지... 정상적으로 동작하는 코드를 생성하기까지 대충 20분 정도 걸린 것 같다.

정상적으로 로딩된 Code Coverage file 옵션

포함된 예제 파일

Lighthouse plugin in Hex-ray

적어도 지금 나에게 LLM의 활용은 무궁무진 한 것 같고, 빠르게 툴링하는데 있어서 이만한게 없다. 굳

Windbg Commands / Tips

TESTING — Thu, 25 Apr 2024 19:13:42 +0900

Useful Windbg Command

Check Instruction

Memory View

dq
dd
db
? poi rcx+420h
dq poi rcx+420h
dq poi(poi(rcx+420h))

Break Point

Conditional Break Point

ba w1 address
ba w2 address
ba r1 address
ba r2 address
bu

General Break Point

bp [address | symbol]
bd [num]
bc [num]
be [num]
bc *
bd *

Exceptions

sx
sxe 0xC0000420
sxe 0xc0000002
sd *

sxe ld test.dll

Execution

g / p / t / u
pc / pt / tt / ta
g- / g-u / g-p / gu

F11, F10, Shift+F11

Modifying Memory or Register

e 0x40000000 0x41414141
eb 0x40000000 0x41

eb 0x40000000 41 41 41 41 43 42 42 41 42 43 53 63 31 42 53 63 00 00 42 12 45 12

r rax=0x4141414141

Check Symbol

x test!TESTING*

Searching Strings

ANSI

s -sa [range]

Unicode

s -su fffff880`01370100 fffff880`01371100

s 810c7000 L10000000 50 00 50 00 43 00 32 00 3a 00

Systematic Command

.reload
.restart
.sympath

For Coverage

pt
bp
.restart
g
ta

Postmortem

Turn on
windbgx /I
windbg -I

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug" /v Debugger /t REG_SZ /d "\"C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\windbg.exe\" -p %ld -e %ld -g" /f
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug" /v Auto /t REG_SZ /d "1" /f
reg add "HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug" /v Debugger /t REG_SZ /d "\"C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\windbg.exe\" -p %ld -e %ld -g" /f
reg add "HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug" /v Auto /t REG_SZ /d "1" /f

Turn off
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug
Auto == 0

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug" /v Auto /t REG_SZ /d "0" /f
reg add "HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug" /v Auto /t REG_SZ /d "0" /f

Windbg Extension

- TTD(Time Travel Debugging)

Windbg: Windows Kernel Debugging

TESTING — Sat, 16 Mar 2024 00:34:28 +0900

Commands

1. Find out target binary EPROCESS address

!process 0 0 calc.exe

2. Context Swiching

.process /i EPROCESS_ADDRESS

3. Load symbols

.sympath

!sym noisy

.reload /f /user

4. Set break point

sxe ld test.sys

bm calc!*

ba w8 ADDRESS

bp /p @$proc calc!blabla~

[bp/bm/bc/bd/be]

5. Unload symbol

bc *

.reload /u /user

.process /r /p

ETC

- Comment

bp TEST!execute; $$ before executing

Another way

1. Target PC

windbgx -server tcp:port=41414

And then open or attach to the target process.

2. Host PC

windbgx -remote tcp:server=192.168.0.41,port=41414

sxe -c "gn" 0xC0000420

sxe -c "gn" 0xC0000095

Visual Studio Tips

TESTING — Wed, 13 Mar 2024 00:59:55 +0900

단축키

코드 정리: Ctrl + k + f

주석: Ctrl + k + c

주석 제거: Ctrl + k + u

함수 이름 일괄 변경: Ctrl + r + r

Disable warning

#pragma warning( disable : 4996)
#define _CRT_SECURE_NO_WARNING

LPWSTR

- 프로젝트 속성 -> C/C++ -> 언어 -> 준수 모드 -> "아니오"로 변경

사실 이게 글 쓴 원인

- 프로젝트 속성 -> 구성 속성 -> 고급 -> 문자 집합 -> "멀티바이트 문자 집합 사용"으로 변경

예제 코드의 경우에 이 설정이 대부분 필요했음

_bstr_t

_bstr_t(L"BLA~BLA")

Winpcap

WpdPack_4.1.3.zip

0.74MB

- Preprocessor

#include <stdio.h>
#include <pcap.h>
#include <stdint.h>
#include <winsock2.h>
#include <ws2tcpip.h>

#define HAVE_REMOTE
#include "pcap.h"

#pragma comment(lib , "ws2_32.lib")
#pragma comment(lib , "wpcap.lib")
#pragma comment(lib, "ws2_32.lib")

- Project Property

- 포함 디렉터리(Include Directories) / 라이브러리 디렉터리(Library Directories)에 각각 Include와 Lib 경로 넣어줌

글씨체

https://github.com/naver/d2codingfont

https://github.com/microsoft/cascadia-code

Instrumentation for Windows

TESTING — Mon, 4 Mar 2024 17:28:05 +0900

DBI(Dynamic Binary Instrumentation) Tools

DynamoRio

무겁지만 대부분의 시스템에서 안정적으로 잘 도는 도구
정상적으로 동작하지 않는 문제가 있다면, 다른 버전의 Release를 사용해보는 방법이 있음

URL: https://dynamorio.org/

무거운 편에 속함
나름 안정적으로 동작하고, 일반적인 경우에 LightHouse에서 제공하는 CodeCoverage[64].dll를 사용하면 효율이 좋음
- CodeCoverage.dll은 직접 컴파일 해도 되지만, lighthouse에서 컴파일 된 바이너리도 제공하고 있음
- 직접 컴파일 하려면 [Link]를 따라하면 됨
- 중요한 점은 LightHouse에서 받는 CodeCoverage.dll이 Pin의 버전과 맞는 버전으로 받아야 함
Pin은 일반적으로 "Windows* (MSVC)"라고 되어있는 버전을 받으면 됨

URL: https://www.intel.com/content/www/us/en/developer/articles/tool/pin-a-dynamic-binary-instrumentation-tool.html

TinyInst

가벼워서 사용하기 편하고, 코드가 간결해서 수정이 용이함
~~구글에서 관리중이기 때문에 나름 신뢰성이 있는 도구~~
정상적으로 Coverage가 측정되지 않는 문제가 있음. Multi-Thread에 취약함(사실 이건 대부분..)
특정 상황에서 함수 end point를 잘 짚지 못하는 문제가 있는 듯
- 아직까진 특별한 이슈가 없는 것으로 보아 인지를 하지 못하고 있는 것 같기는 한데, 누군가 이슈를 올려주길 기다리고 있음.
- 이 말인 즉슨 TinyInst를 사용하는 Fuzzer들도 경우에 따라서는 문제가 있을 수 있다는 점...? (TinyAFL / Jackalope)

URL: https://github.com/googleprojectzero/TinyInst

Support Tool

LightHouse

IDA Pro Plugin으로 Coverage를 시각적으로 잘 보여주는 툴
처음에는 IDA Pro Plugin으로 등장했지만, 현재는 Binary Ninja에서도 지원이 가능함
DynaoRio / Pin 지원, TinyInst는 공식적으로 지원한다고 되어있지는 않으며 사용은 가능하나 정상적으로 동작하지 않는 문제가 있음. 이 이슈는 LightHouse가 아니라 TinyInst의 문제임

URL: https://github.com/gaasedelen/lighthouse

Windows Application Fuzzing 기본 세팅

TESTING — Fri, 7 Apr 2023 13:12:13 +0900

Windows Application Fuzzer

Windows Application 퍼징을 위해 일반적으로 WinAFL, TinyAFL, Jackalope와 같은 퍼저들을 사용한다.

이 퍼저들은 윈도우를 기반으로 하고 있어서, 유용한 시스템콜을 지원하는 리눅스와는 다르게 제약 사항들이 존재한다.

또, 상황에 따라 코어를 제대로 사용하지 못하기도 하고, 윈도우에서 제공하는 기능 때문에 속도가 느려지기도 한다.

가장 기본적으로 윈도우 시스템상에서 세팅하고 설치해 주면 좋은 것들은 다음과 같다.

Improving Fuzzing Speed

1. Windows Defender AV Scanning

AV Scanning 중 Real-time protection 기능은 파일 생성 시 많은 리소스를 차지하므로 꼭 꺼줘야 한다.

기본 윈도우가 아닌 다른 AV가 설치되어 있는 경우에도 마찬가지로 종료한 뒤 퍼저를 실행하는 것이 유리하다.

gpedit.msc 수정

- Computer Configuration → Administrative Templates → Windows Components → Microsoft Defender Antivirus → "Turn off Microsoft Defender Antivirus" → Enabled

- Computer Configuration → Administrative Templates → Windows Components → Microsoft Defender Antivirus → Real-time Protection → "Turn off real-time protection" → Enabled

이후에 직접 Defender를 켜서 Real-time protection이 켜져있는지 확인하고, 켜져있다면 끄면 다시 안켜진다. 재부팅하면 다시 켜지기 때문에, 재부팅을 한다면 다시 꺼줘야 한다.

Virus & treat protection setting - Real-time Protection

2. RamDisk

M.2 NVMe SSD 기준으로 2GB/s~5GB/s의 전송속도를 갖고, DDR4 RAM은 2133~3200 MHz(10GB/s~)의 속도를 가진다.

M.2 NVMe PCIe4.0 SSD은 8GB/s정도의 전송 속도를 갖고, DDR5 RAM은 최대 76GB/s 정도의 전송 속도를 제공한다.

따라서 일반적으로 Ram Disk를 활용한다면 보다 빠른 퍼징을 할 수 있다. (Ram Disk 프로그램에 따라 차이가 있을 수 있음)

주의할 점은 간혹 가다 컴퓨터가 재부팅되는 경우가 있는데, 이때 램 디스크 내용이 모두 휘발된다.

따라서, 크래시가 저장되는 폴더는 로컬 디스크 경로로 설정해야 한다. (일반적으로 퍼저 코드를 수정해야 함)

3. Shared Memory

앞서 언급한 WinAFL, TinyAFL, Jackalope와 같은 퍼저들은 Shared Memory를 통한 파일 입력을 지원하고 있다.

파일을 무조건 받아야 하는게 아니라면 RamDisk보다 Shared Memory가 보다 낫다.

하네스를 만들 때 공유메모리를 통해 파일을 전송하는 것은 파일 I/O를 제거하여 속도 향상에 유리하다.

코드 예제는 이곳 저곳 있으니 참고.

Improving Performance

gflags.exe

gflags.exe는 Windows SDK의 Debugging Tools를 설치하면 같이 설치되는 프로그램 중 하나이다.

Windows에서 퍼징 할 때는 보통 DLL과 같이 바이너리 상태인 데다가, close source이기 때문에 ASan 적용이 어렵다.

일반적으로 Heap 관련 버그들은 탐지하기 쉽지 않지만, gflags.exe의 Full-page Heap 기능을 통해 보완할 수 있다.

조금은 느려질 순 있지만, 속도와 Trade-off 치고는 큰 이득이니 일반적으로는 켜는 것이 좋다.

- gflags.exe /i [aaaa.exe] +hpa +ust

Disabled Error Reporting

1. services.msc

- Windows Error Reporting Service → Disabled → Apply → OK

2. Registry Setting

- regedit->HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting → Disabled(DWORD) value: 1

3. gpedit.msc

- Computer Configuration → Administrative Templates → All settings → Disable Windows Error Reporting → Enabled

Microsoft Store App Debugging

plmdebug

- plmdebug /enableDebug [PackageFullName] [Windbg Full Path]

- plmdebug /disableDebug [PackageFullName] [Windbg Full Path]

Ex)
plmdebug.exe /enableDebug Microsoft.ZuneVideo_10.19071.19011.0_x64__8wekyb3d8bbwe "C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\WinDbg.exe"

Useful Tools for Fuzzing and Debugging

1. Visual Studio

Fuzzer, Harness Compile시 필요함. 개인적으로 2019 버전이 가장 보편화되어 많이 사용되고 있어서 2019 버전을 추천한다.

2. Windows SDK(Debugger)

SDK에서 Debugger를 설치하면 gflags.exe, windbg, plmdebug.exe, kdnet.exe 등이 같이 설치되어 디버깅에 필수적이다.

3. Python3

4. Sublime Text

Visual Studio Code 등을 사용해도 괜찮음, 손에 익은 거 쓰면 된다.

5. Git Client

6. TeamViewer

7. Wub(Windows Update Blocker)

윈도우 업데이트를 막아주는 프로그램으로 업데이트를 통한 강제 재부팅을 막아주는데 유용하다.

8. 010 Editor

Hex Editor, 손에 맞는 에디터 쓰면 된다.

9. Everything

빠르게 파일을 찾아줄 수 있는 최고의 윈도우 툴 중 하나, 정규식도 지원한다.

10. Windbg Preview

TTD는 정말 좋은 기능이다.

11. Process Explorer(+Hacker)

12. Terminal(From Microsoft App)

13. IDA Pro

- BinDiff, LightHouse

14. PowerToys

화면 분할을 자유롭게 해주는 FancyZones 때문에 사용하고 있다.

IDA Hex-ray Plugins

TESTING — Wed, 8 Mar 2023 16:40:10 +0900

범용 Plugin

LazyIDA: https://github.com/L4ys/LazyIDA

- Return type 지우는 기능으로 가독성을 챙길 수 있고, Copy기능은 디버깅 시 유용함

HexRays CodeXplorer: https://github.com/REhints/HexRaysCodeXplorer

- 구조체 역추적, 메모리 주소에 변수 이름 할당

Diaphora: https://github.com/joxeankoret/diaphora

- Code diffing Plugin, bindiff도 좋음 간간히 먹통될 때 번갈아가면서 사용

LightHouse: https://github.com/gaasedelen/lighthouse

- Code Coverage Plugin, 단독 사용은 안되고 DynamoRio, Tinyinst와 같은 DBI 툴과 같이 사용

hexraysIDAPlus: https://github.com/Byzero512/hexraysIDAplus

- 코드 Folding 기능, 가독성 향상

Funcap: https://github.com/deresz/funcap

- Flow에서의 인자를 기록해주는 일종의 taint인데, 조금 애매함

펌웨어 분석용 Plugin

펌웨어 분석용 플러그인은 아래 세개를 제외하고는 직접 코드 작성해서 작업하는게 편함

rbasefind: https://github.com/sgayou/rbasefind

- 펌웨어 base address를 휴리스틱으로 찾아줌, 방법론은 다른 툴과 비슷한데 rust로 병렬 처리가 잘 되어있어 속도가 빠름

Karta: https://github.com/CheckPointSW/Karta

- 프로젝트 내 "thumbs_up.py"가 유용, 사용하기 전에 Segment를 따로 지정해줘야 함

Codatify: https://github.com/tacnetsol/ida/tree/master/plugins/codatify

- Auto analysis로 잡히지 않은 code, data를 define 해줌

For Advanced Fuzzing

TESTING — Tue, 3 Jan 2023 14:11:18 +0900

User-Mode Application Fuzzing

1. Strategy

1.1. Mutation Strategy

- Deterministic: bitflip, byteflip, arithmetic in/decrease, interesting value, special charactor

- Havoc: Same Deterministic, random byte, delete byte, insert byte, overwrite byte

- Custom: ?

- Radamsa [Github]

- AFLSmart: Smart Greybox Fuzzing [PDF, Github]

- Redqueen: Fuzzing with Input-to-State Correspondence, NDSS '19 [PDF, Slide, Video, Github]

1.2. Mutation Scheduling

- MOPT: Optimized Mutation Scheduling for Fuzzers, USENIX '19 [PDF, Slide, Video, Github]

- AFL++: EXPLORE, EXPLOIT, COE, FAST, LINEAR, QUAD, mmopt, rare, seek

1.3. Coverage

- DynamoRio[Github], Tinyinst[Github], QEMU[Github], IntelPT[Github]

- LLVM, GCC

2. Speed

2.1. 부하 제거를 통한 속도 향상

- peAFL, Make static instrumentation great again, High performance fuzzing for Windows system, BlueHatIL '19 [Slide, Video, Github]

- peafl64 [Github]

- Designing New Operating Primitives to Improve Fuzzing Performance, ACM CCS '17 [PDF, Video, Github]

2.2. 퍼저 성능 향상

- Nyx: Greybox Hypervisor Fuzzing using Fast Snapshots and Affine Types, USENIX '21 [PDF, Slide]

- Persistent mode on WinAFL [Github], Jackalope [Github]

- AFL++, USENIX '20 Woot [PDF, Github]

2.3. Distribute Fuzzing

- Network를 이용한 distribute fuzzing 수행, share seeds

- UltraFuzz: Towards Resource-saving in Distributed Fuzzing, TSE '22 [PDF, Git]

3. Seed Pool

3.1. 시드 풀이 많을 수록 유리함

- 시드 풀이 많을수로 다양한 커버리지를 테스트해볼 확률이 높음

- 같은 커버리지를 갖는 시드에 대해서는 퍼저가 처냄(Pre-Processing)

3.2. Quality of seed set

- regression test set과 일반 seed의 차이 존재: Targeted

3.3. Seed Selection

- Optimizing Seed Selection for Fuzzing, USENIX '14 [PDF, Video]

JavaScript Fuzzing

1. JsFunFuzz [Github]
2. Fuzzing with Code Fragments(LangFuzz), USENIX '12 [PDF, Slide, Video]
3. CodeAlchemist: Semantics-Aware Code Generation to Find Vulnerabilities in JavaScript Engines, NDSS '19 [PDF, Video, Github]
4. Fuzzilli [Github]
5. Superion: grammar-aware greybox fuzzing, ISEC '19 [PDF, Github]
6. Fuzzing JavaScript Engines with Aspect-preserving Mutation(DIE), S&P '20 [PDF, Slide, Video, Github]
7. JIT-Picking: Differential Fuzzing of JavaScript Engines, ACM CCS '22 [PDF, Github]

Kernel Fuzzing

1. syzkaller [Github]

2. kAFL [Github]

3. NtFuzz [Github]

계속...

kdnet: Windows 10 Kernel Network Debugging Setting

TESTING — Fri, 2 Dec 2022 13:08:46 +0900

일반적인 시리얼 포트로 연결해 커널 디버깅 하는 것은 네트워크에 비해 상대적으로 느리다.

windbg와 함께 설치되는 kdnet.exe를 이용하면 빠른 속도의 네트워크 디버깅이 가능하다.

1. Windows sdk 설치

※ Windows SDK에서는 디버깅 툴만 설치하면 된다.

https://developer.microsoft.com/ko-kr/windows/downloads/windows-sdk/

Windows SDK - Windows 앱 개발

Windows SDK Windows 11용 Windows SDK(10.0.22000)는 Windows 애플리케이션을 빌드할 수 있는 최신 헤더, 라이브러리, 메타데이터, 도구를 제공합니다. 이 SDK를 사용하여 Windows 11 및 이전 Windows 릴리스용 UWP(유

developer.microsoft.com

2. Guest(Target) Windows에 파일 복사 및 실행

C:\Program Files (x86)\Windows Kits\10\Debuggers\x64
C:\Program Files (x86)\Windows Kits\10\Debuggers\x86

kdnet.exe, VerifiedNICList.xml

기본 값으로 설치되었다면 위 경로에 windbg가 존재한다.

windbg가 아닌 kdnet.exe와 VerifiedNICList.xml를 타겟이 되는 Guest 윈도우에 복사해 실행한다.

해당 프로그램은 지원하는 NIC(Network Interface Card)인지를 확인해준다.

3. Guest에서 kdnet.exe 파라미터 세팅 및 실행

kdnet.exe [Host IP Address] [Port]

Host IP 주소를 첫 번째 인자로 넣고, Port는 권장되는 50000~50039중 아무번호나 넣으면 된다.

관리자 권한으로 kdnet.exe의 인자를 맞춰 실행하면 아래와 같이 키가 출력되는데 이를 저장해둔다.

4. Host에서 Windbg 실행

windbg의 환경변수가 등록되어 있다면, 위 3번 사진의 명령어 처럼
windbg -k net:port=50022,key=***를 그대로 실행시킨다.

환경변수가 따로 등록되어 있지 않다면 아래와 같이 GUI 환경을 통해 진행한다.

windbg를 실행시켜 [File]-[Kernel Debug]를 선택해 3.에서 설정한 포트 번호와 Key 값을 넣어서 확인을 누른다.

5. Windows 보안경고 체크 및 windbg 연결 확인

확인을 누르면 보안경고가 창이 팝업되는데, 모든 체크박스를 체크로 변경하여 액세스 허용을 선택한다.

windbg가 실행되고, Waiting to reconnect... 라는 텍스트 문구가 보이며,

Guest에서 shutdown -r -t 0을 통해 재시작하면, 곧바로 Connected 되었다는 문자열이 출력된다.

최종적으로 아래와 같이 디버깅을 할 수 있는 환경이 만들어진다.

※ Windbg Preview로 Kernel Debugging

windbgx의 환경변수가 등록되어 있다면, windbgx -k net:port=50022,key=***를 그대로 실행시킨다.

일반적인 경우에는 Microsoft AppStore를 통해서 windbg Preview를 설치했다면, windbgx는 Path에 등록되어있다.

위에서 Host에서 winDbg를 실행시키는 것과 같이 windbg preivew로 똑같이 커널 디버깅을 할 수 있다.

windbg preview의 [File]-[Start debugging]-[Attach to kernel]에 Port number, Key 설정 및 접속하고 기다린다.

"shutdown -r -t 0" 명령어로 Guest를 리부팅하면 자동으로 연결된다.

※ Reference

https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/setting-up-a-network-debugging-connection-automatically