Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (seongtaejeong at gmail.com)
홈페이지
첨부 파일
 
(연관된 글이 1개 있습니다.)
(시리즈 글이 3개 있습니다.)
디버깅 기술: 213. Windbg - swapgs 명령어와 (Ring 0 커널 모드의) FS, GS Segment 레지스터
; https://www.sysnet.pe.kr/2/0/13853

디버깅 기술: 214. Windbg - syscall 단계까지의 Win32 API 호출 (예: Sleep)
; https://www.sysnet.pe.kr/2/0/13856

디버깅 기술: 215. Windbg - syscall 이후 실행되는 KiSystemCall64 함수 및 SSDT 디버깅
; https://www.sysnet.pe.kr/2/0/13859




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에 대해 정리가 끝난 것 같군요. ^^




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 12/26/2024]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13883정성태2/12/2025189닷넷: 2317. C# - Memory Mapped I/O를 이용한 PCI Configuration Space 정보 열람파일 다운로드1
13882정성태2/10/2025584스크립트: 70. 파이썬 - oracledb 패키지 연동 시 Thin / Thick 모드
13881정성태2/7/2025897닷넷: 2316. C# - Port I/O를 이용한 PCI Configuration Space 정보 열람파일 다운로드1
13880정성태2/5/2025870오류 유형: 947. sshd - Failed to start OpenSSH server daemon.
13879정성태2/5/20251107오류 유형: 946. Ubuntu - N: Updating from such a repository can't be done securely, and is therefore disabled by default.
13878정성태2/3/2025987오류 유형: 945. Windows - 최대 절전 모드 시 DRIVER_POWER_STATE_FAILURE 발생 (pacer.sys)
13877정성태1/25/20251082닷넷: 2315. C# - PCI 장치 열거 (레지스트리, SetupAPI)파일 다운로드1
13876정성태1/25/20251274닷넷: 2314. C# - ProcessStartInfo 타입의 Arguments와 ArgumentList파일 다운로드1
13875정성태1/24/20251264스크립트: 69. 파이썬 - multiprocessing 패키지의 spawn 모드로 동작하는 uvicorn의 workers
13874정성태1/24/20251212스크립트: 68. 파이썬 - multiprocessing Pool의 기본 프로세스 시작 모드(spawn, fork)
13873정성태1/23/20251107디버깅 기술: 217. WinDbg - PCI 장치 열거
13872정성태1/23/20251089오류 유형: 944. WinDbg - 원격 커널 디버깅이 연결은 되지만 Break (Ctrl + Break) 키를 눌러도 멈추지 않는 현상
13871정성태1/22/20251201Windows: 278. Windows - 윈도우를 다른 모니터 화면으로 이동시키는 단축키 (Window + Shift + 화살표)
13870정성태1/18/20251275개발 환경 구성: 741. WinDbg - 네트워크 커널 디버깅이 가능한 NIC 카드 지원 확대
13869정성태1/18/20251329개발 환경 구성: 740. WinDbg - _NT_SYMBOL_PATH 환경 변수에 설정한 경로로 심벌 파일을 다운로드하지 않는 경우
13868정성태1/17/20251233Windows: 277. Hyper-V - Windows 11 VM의 Enhanced Session 모드로 로그인을 할 수 없는 문제
13867정성태1/17/20251396오류 유형: 943. Hyper-V에 Windows 11 설치 시 "This PC doesn't currently meet Windows 11 system requirements" 오류
13866정성태1/16/20251359개발 환경 구성: 739. Windows 10부터 바뀐 device driver 서명 방법
13865정성태1/15/20251477오류 유형: 942. C# - .NET Framework 4.5.2 이하의 버전에서 HttpWebRequest로 https 호출 시 "System.Net.WebException" 예외 발생
13864정성태1/15/20251427Linux: 114. eBPF를 위해 필요한 SELinux 보안 정책
13863정성태1/14/20251320Linux: 113. Linux - 프로세스를 위한 전용 SELinux 보안 문맥 지정
13862정성태1/13/20251283Linux: 112. Linux - 데몬을 위한 SELinux 보안 정책 설정
13861정성태1/11/20251792Windows: 276. 명령행에서 원격 서비스를 동기/비동기로 시작/중지
13860정성태1/10/20251740디버깅 기술: 216. WinDbg - 2가지 유형의 식 평가 방법(MASM, C++)
13859정성태1/9/20251850디버깅 기술: 215. Windbg - syscall 이후 실행되는 KiSystemCall64 함수 및 SSDT 디버깅
[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...