Windbg - swapgs 명령어와 (Ring 0 커널 모드의) FS, GS Segment 레지스터
지난 글에서,
Windbg - (Ring 3 사용자 모드의) FS, GS Segment 레지스터
; https://www.sysnet.pe.kr/2/0/13852
사용자 모드 레벨의 FS, GS 세그먼트 레지스터가 TEB를 가리키고 있다는 것과 실제 선형 주소 계산 시의 base 주소가 MSR_GS_BASE(0xc0000101)에 저장돼 있다는 것을 설명했습니다.
하지만, 커널 모드(Ring 0) 단계로 접어들면 FS, GS 세그먼트 레지스터는 PCR 영역을 가리키게 바뀝니다.
Windbg - KPCR, KPRCB
; https://www.sysnet.pe.kr/2/0/13842
이렇게 바뀌는 이유는, Windows 운영체제의 경우 syscall을 호출해 커널 모드로 전환한 후 실행되는 KiSystemCall64 함수에서 swapgs 명령어를 실행하기 때문입니다. (혼동하지 말아야 할 것은, segment selector인 GS, FS 값이 변경되는 것이 아닌, 그것의 base 주소가 변경된다는 점입니다.)
swapgs의 동작을 pseudo 코드로 나타내면 다음과 같은데요,
// SWAPGS (Intel x86/64 assembly instruction)
// https://modoocode.com/en/inst/swapgs
IF CS.L != 1 (* Not in 64-Bit Mode *)
THEN
#UD; FI;
IF CPL != 0
THEN #GP(0); FI;
tmp <- GS.base;
GS.base <- IA32_KERNEL_GS_BASE;
IA32_KERNEL_GS_BASE <- tmp;
간단하게 정리하면, IA32_GS_BASE에 해당하는 값과 IA32_KERNEL_GS_BASE 값에 해당하는 MSR 레지스터의 값을 서로 교환하는 것으로, 결국 다음과 같은 절차의 코드가 단 하나의 swapgs 명령어로 제공되는 것입니다.
user_gs_base = __readmsr(0xc0000101)
kernel_gs_base = __readmsr(0xc0000102)
__writemsr(0xc0000101, kernel_gs_base)
__writemsr(0xc0000102, user_gs_base)
WinDbg를 이용해 직접 저 과정을 확인해 볼까요? ^^ 이를 위해
지난번 예제 코드를 사용할 텐데요,
#include <stdio.h>
#include <windows.h>
extern "C"
{
void FuncInThread1()
{
Sleep(1000);
}
void FuncInThread2()
{
Sleep(1000);
}
void PrintThreadInfo()
{
DWORD tid = GetCurrentThreadId();
printf("\nThread ID: %d (0x%x)\n", tid, tid);
for (int i = 0; i < 8 * 8; i += (8 * 2))
{
unsigned __int64 dqValue1 = __readgsqword(i);
unsigned __int64 dqValue2 = __readgsqword(i + 8);
printf("gs:[%04x] %016I64x %016I64x\n", i, dqValue1, dqValue2);
}
printf("\n");
{
unsigned __int64* gsBaseAddress = (unsigned __int64*)__readgsqword(0x30);
printf("GS base address (MSR_GS_BASE, rdmsr 0xc0000101): 0x%p\n", gsBaseAddress);
}
}
void ThreadProc1()
{
PrintThreadInfo();
while (true)
{
FuncInThread1();
}
}
void ThreadProc2()
{
PrintThreadInfo();
while (true)
{
FuncInThread2();
}
}
int main()
{
DWORD pid = ::GetProcessId(::GetCurrentProcess());
printf("PID: %d (0x%x)\n", pid, pid);
::CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)ThreadProc1, NULL, 0, NULL);
Sleep(1000);
::CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)ThreadProc2, NULL, 0, NULL);
Sleep(-1);
}
}
이것을 실행하면 대충 아래와 같은 출력을 확인할 수 있습니다.
PID: 9304 (0x2458)
Thread ID: 9272 (0x2438)
gs:[0000] 0000000000000000 0000007d2ed00000
gs:[0010] 0000007d2ecfd000 0000000000000000
gs:[0020] 0000000000001e00 0000000000000000
gs:[0030] 0000007d2e757000 0000000000000000
GS base address (MSR_GS_BASE, rdmsr 0xc0000101): 0x0000007D2E757000
Thread ID: 10244 (0x2804)
gs:[0000] 0000000000000000 0000007d2ee00000
gs:[0010] 0000007d2edfd000 0000000000000000
gs:[0020] 0000000000001e00 0000000000000000
gs:[0030] 0000007d2e759000 0000000000000000
GS base address (MSR_GS_BASE, rdmsr 0xc0000101): 0x0000007D2E759000
저 응용 프로그램을 WinDbg로 연결할 텐데요, 지난번과는 달리 이번에는
라이브 커널 디버깅 모드로 연결해 MSR_GS_BASE(0xc0000101) 값을 확인해 보겠습니다.
// 프로세스 문맥으로 연결
// !process 0 0 ConsoleApplication1.exe
// .process /i ffffdd8c743be080
// .reload /user
// 0x2438 스레드 문맥에서 MSR_GS_BASE 확인
6: kd> rdmsr 0xc0000101
msr[c0000101] = ffff9a81`a65b0000
// 0x2804 스레드 문맥에서 MSR_GS_BASE 확인
4: kd> rdmsr 0xc0000101
msr[c0000101] = ffff9a81`a64d2000
응용 프로그램에서 출력한 GS base 주소는 각각 0x0000007D2E757000, 0x0000007D2E759000인데, 예상했던 것과는 달리 그 값들이 "rdmsr 0xc0000101" 결과로 나오지 않고 있습니다.
왜냐하면, 커널 모드로 연결한 WinDbg는 Ring 0 상태에서 실행한 결과를 반환하기 때문인데요, (애당초 rdmsr 명령어는 Ring 3 특권에서 실행이 안 됩니다.) 달리 말하면 이미 swapgs 명령어가 실행된 환경에서의 결과라고 보면 됩니다. 따라서 오히려 커널 디버깅 모드의 WinDbg에서 응용 프로그램이 출력한 MSR_GS_BASE 값을 확인하려면 (swapgs 명령어로 교환이 되었으므로) MSR_KERNEL_GS_BASE 값을 확인해야 합니다.
// 0x2438 스레드 문맥에서 MSR_KERNEL_GS_BASE 확인
6: kd> rdmsr 0xc0000102
msr[c0000102] = 0000007d`2e757000 // C/C++에서 출력한 GS base 값과 동일
// 0x2804 스레드 문맥에서 MSR_KERNEL_GS_BASE 확인
4: kd> rdmsr 0xc0000102
msr[c0000102] = 0000007d`2e759000 // C/C++에서 출력한 GS base 값과 동일
따라서 이렇게 정리할 수 있습니다.
[사용자 모드로 실행 중]
msr[c0000101] = _TEB 주소
msr[c0000102] = _KPCR 주소
[커널 모드로 진입해 swapgs가 발생 후]
msr[c0000101] = _KPCR 주소
msr[c0000102] = _TEB 주소
결국, WinDbg의 커널 모드 디버깅에서는 (MSR_KERNEL_GS_BASE가 아닌) MSR_GS_BASE(0xc0000101) MSR 값을 기준으로 _KPCR을 확인할 수 있습니다.
// 0x2438 스레드 문맥에서 확인
4: kd> dt _KPCR ffff9a81`a65b0000
ntdll!_KPCR
+0x000 NtTib : _NT_TIB
+0x000 GdtBase : 0xffff9a81`a65c0fb0 _KGDTENTRY64
+0x008 TssBase : 0xffff9a81`a65bf000 _KTSS64
+0x010 UserRsp : 0x0000007d`2ecffa98
+0x018 Self : 0xffff9a81`a65b0000 _KPCR
+0x020 CurrentPrcb : 0xffff9a81`a65b0180 _KPRCB
+0x028 LockArray : 0xffff9a81`a65b0870 _KSPIN_LOCK_QUEUE
+0x030 Used_Self : 0x0000007d`2e757000 Void
+0x038 IdtBase : 0xffff9a81`a65be000 _KIDTENTRY64
+0x040 Unused : [2] 0
+0x050 Irql : 0 ''
+0x051 SecondLevelCacheAssociativity : 0x10 ''
+0x052 ObsoleteNumber : 0x6 ''
+0x053 Fill0 : 0 ''
+0x054 Unused0 : [3] 0
+0x060 MajorVersion : 1
+0x062 MinorVersion : 1
+0x064 StallScaleFactor : 0xe10
+0x068 Unused1 : [3] (null)
+0x080 KernelReserved : [15] 0
+0x0bc SecondLevelCacheSize : 0x400000
+0x0c0 HalReserved : [16] 0xd691f650
+0x100 Unused2 : 0
+0x108 KdVersionBlock : (null)
+0x110 Unused3 : (null)
+0x118 PcrAlign1 : [24] 0
+0x180 Prcb : _KPRCB
// 0x2804 스레드 문맥에서 확인
4: kd> dt _KPCR ffff9a81`a64d2000
ntdll!_KPCR
+0x000 NtTib : _NT_TIB
+0x000 GdtBase : 0xffff9a81`a64e2fb0 _KGDTENTRY64
+0x008 TssBase : 0xffff9a81`a64e1000 _KTSS64
+0x010 UserRsp : 0x0000009f`9effe168
+0x018 Self : 0xffff9a81`a64d2000 _KPCR
+0x020 CurrentPrcb : 0xffff9a81`a64d2180 _KPRCB
+0x028 LockArray : 0xffff9a81`a64d2870 _KSPIN_LOCK_QUEUE
+0x030 Used_Self : 0x0000007d`2e759000 Void
+0x038 IdtBase : 0xffff9a81`a64e0000 _KIDTENTRY64
+0x040 Unused : [2] 0
+0x050 Irql : 0 ''
+0x051 SecondLevelCacheAssociativity : 0x10 ''
+0x052 ObsoleteNumber : 0x4 ''
+0x053 Fill0 : 0 ''
+0x054 Unused0 : [3] 0
+0x060 MajorVersion : 1
+0x062 MinorVersion : 1
+0x064 StallScaleFactor : 0xe10
+0x068 Unused1 : [3] (null)
+0x080 KernelReserved : [15] 0
+0x0bc SecondLevelCacheSize : 0x400000
+0x0c0 HalReserved : [16] 0xd691f650
+0x100 Unused2 : 0
+0x108 KdVersionBlock : (null)
+0x110 Unused3 : (null)
+0x118 PcrAlign1 : [24] 0
+0x180 Prcb : _KPRCB
정말 gs:0 위치에 있는 값이 _KPCR 값인지 확인해 볼까요? ^^ 예를 들어, 0x2438 스레드 문맥에서 _KPCR.GdtBase 필드의 값이 0xffff9a81`a65c0fb0으로 나오는데요, WinDbg로 GDT 주소를 확인해 보면,
4: kd> ? gdtr
Evaluate expression: -111593345110096 = ffff9a81`a64e2fb0
정확히 일치하는군요. ^^
참고로, _TEB처럼 _KPCR도 Self 필드가 있는데요, 마찬가지로 커널 모드에서의 gs:0 주솟값을 가리키는 것과 같습니다.
// 0x2804 스레드 문맥에서 확인
4: kd> dt _KPCR ffff9a81`a64d2000
ntdll!_KPCR
+0x000 NtTib : _NT_TIB
+0x000 GdtBase : 0xffff9a81`a64e2fb0 _KGDTENTRY64
+0x008 TssBase : 0xffff9a81`a64e1000 _KTSS64
+0x010 UserRsp : 0x0000009f`9effe168
+0x018 Self : 0xffff9a81`a64d2000 _KPCR
+0x020 CurrentPrcb : 0xffff9a81`a64d2180 _KPRCB
+0x028 LockArray : 0xffff9a81`a64d2870 _KSPIN_LOCK_QUEUE
+0x030 Used_Self : 0x0000007d`2e759000 Void
...[생략]...
또한, _KPCR의 Used_Self 필드에는 사용자 모드에서의 gs:0 주솟값이 저장돼 있는 것을 확인할 수 있습니다.
4: kd> rdmsr 0xc0000101
msr[c0000101] = ffff9a81`a64d2000 // 0x2804 스레드 문맥의 MSR_GS_BASE 값 (실제로는 Kernel 모드의 gs base 주소)
4: kd> rdmsr 0xc0000102
msr[c0000102] = 0000007d`2e759000 // C/C++에서 출력한 GS base 값과 동일
4: kd> dq gs:0 L8
002b:00000000`00000000 ffff9a81`a64e2fb0 ffff9a81`a64e1000
002b:00000000`00000010 0000009f`9effe168 ffff9a81`a64d2000 // gs:[0x18] 위치에 Self 필드 (커널 모드의 gs base 주소)
002b:00000000`00000020 ffff9a81`a64d2180 ffff9a81`a64d2870
002b:00000000`00000030 0000007d`2e759000 ffff9a81`a64e0000 // gs:[0x30] 위치에 Used_Self 필드 (사용자 모드의 gs base 주소)
4: kd> dq ffff9a81`a64d2000 L8 // gs:[x018] 주소의 덤프는 gs:0의 덤프와 동일
ffff9a81`a64d2000 ffff9a81`a64e2fb0 ffff9a81`a64e1000
ffff9a81`a64d2010 0000009f`9effe168 ffff9a81`a64d2000
ffff9a81`a64d2020 ffff9a81`a64d2180 ffff9a81`a64d2870
ffff9a81`a64d2030 0000007d`2e759000 ffff9a81`a64e0000
휴~~~ 이제야 대충 gs, fs에 대해 정리가 끝난 것 같군요. ^^
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]