Windbg - 윈도우 핸들 테이블 (3) - Windows 10 이상인 경우
예전에는,
Windbg - 윈도우 핸들 테이블
; https://www.sysnet.pe.kr/2/0/935
Handle 테이블의 주소와, 그로부터 Handle 정보를 windbg를 통해 알아내는 것이 가능했는데요, 어느 순간 Handle 테이블에 있는 값의 Object Address 주소가 인코딩되기 시작해,
Windbg - 윈도우 핸들 테이블 (2)
; https://www.sysnet.pe.kr/2/0/1476
보이지 않게 되다가, (정확히 어떤 버전인지는 알 수 없으나, 적어도) Windows 10 22H2 이상부터는 Handle 테이블의 주소도 모호해졌습니다. 다시 한번 정리하는 의미로 한번 알아볼까요? ^^
자, 우선 원하는 프로세스를 하나 선정하고,
// Windows 10 x64 (10.0.19045)에서 Local Kernel Debug로 실행 + notepad.exe 하나 띄워 놓고!
lkd> !process 0 0 notepad.exe
PROCESS ffffd282e5c43080
SessionId: 2 Cid: 1c60 Peb: b36d554000 ParentCid: 1438
DirBase: 159851000 ObjectTable: ffffe00425998040 HandleCount: 255.
Image: notepad.exe
결과에 나온 ObjectTable 주소를 덤프해 보면,
lkd> dt _HANDLE_TABLE ffffe00425998040
nt!_HANDLE_TABLE
+0x000 NextHandleNeedingPool : 0x800
+0x004 ExtraInfoPages : 0n0
+0x008 TableCode : 0xffffe004`24cf9001
+0x010 QuotaProcess : 0xffffd282`e5c43080 _EPROCESS
+0x018 HandleTableList : _LIST_ENTRY [ 0xffffe004`23876318 - 0xffffe004`275b52d8 ]
+0x028 UniqueProcessId : 0x1c60
+0x02c Flags : 0
+0x02c StrictFIFO : 0y0
+0x02c EnableHandleExceptions : 0y0
+0x02c Rundown : 0y0
+0x02c Duplicated : 0y0
+0x02c RaiseUMExceptionOnInvalidHandleClose : 0y0
+0x030 HandleContentionEvent : _EX_PUSH_LOCK
+0x038 HandleTableLock : _EX_PUSH_LOCK
+0x040 FreeLists : [1] _HANDLE_TABLE_FREE_LIST
+0x040 ActualEntry : [32] ""
+0x060 DebugInfo : (null)
원래는 TableCode의 주소가 Handle 테이블의 주소였는데, 뭔가 값이 이상합니다. 눈치채셨나요? ^^ 끝에 1이 붙어 있는 것인데요, 일반적인 정렬로 볼 수 없습니다.
그런데, 왠지 ^^ 저건 뭔가 offset은 아니고 flag 비슷한 값으로 쓰이는 듯하다는 느낌이 듭니다. 따라서 그냥 1을 절삭해 출력해 보면,
lkd> dq 0xffffe004`24cf9000 L4
ffffe004`24cf9000 ffffe004`253ff000 ffffe004`201ff000
ffffe004`24cf9010 00000000`00000000 00000000`00000000
만약 저게 Handle 테이블이었다면 첫 번째 16바이트가 0으로 채워졌어야만 하는데 예상치 않게 저런 값이 나왔습니다. 그렇다면 혹시 ffffe004`253ff000 값이 Handle 테이블이 아닐까요? ^^
lkd> dq ffffe004`253ff000
ffffe004`253ff000 00000000`00000000 00000000`00000000
ffffe004`253ff010 d282e5f8`0630fffb 00000000`001f0003
ffffe004`253ff020 d282e5f8`07b0fff9 00000000`001f0003
ffffe004`253ff030 d282e51a`d440fffb 00000000`00000001
ffffe004`253ff040 d282e620`b890ffd9 00000000`001f0003
ffffe004`253ff050 d282e4c6`8530ff8f 00000000`000f00ff
ffffe004`253ff060 d282e62e`01a0fffb 00000000`00100002
ffffe004`253ff070 d282e51a`e210fffb 00000000`00000001
오호~~~ 첫 번째 16바이트가 0이므로, 왠지 이번에는 제대로 들어온 것 같습니다. 그렇다면 저게 정말 올바른 핸들 테이블인지 비교를 위해 "Process Explorer"를 실행해 저 notepad.exe의 Handle을 조회했더니 다음과 같은 값이 나옵니다.
Handle Object Address Access
0x00000034 0xFFFFE00418928B00 0x00000003
0x00000040 0xFFFFD282E6273AF0 0x00100020
...[생략]...
보는 바와 같이 0x34, 0x40에 해당하는 Handle의 Access 정보가 나오는데요, 이것을 windbg에서 조회해 보면,
lkd> dq ffffe004`253ff000 + (0x34 / 4 * 0x10) L2
ffffe004`253ff0d0 e0041892`8ad0ffa3 00000000`00000003
lkd> dq ffffe004`253ff000 + (0x40 / 4 * 0x10) L2
ffffe004`253ff100 d282e627`3ac0fffb 00000000`00100020
정확히 일치합니다. ^^ 물론 우연일 수 있지만 다른 것들을 조회해 봐도 일치하는 것으로 봐서 일단 Handle 테이블의 위치는 저런 식으로 (현재는) 구할 수 있습니다.
물론 여전히 Object Address의 값은 인코딩돼 있어 구할 수 없습니다. 가령 Process Explorer에서 0x34 핸들의 주소가 0xFFFFE00418928B00인데, windbg의 출력은 e0041892`8ad0ffa3으로 나옵니다.
대신, 그냥 !handle 명령어를 사용해 구하는 것이 현재로서는 가장 편리할 것 같습니다. ^^
// _EPROCESS == ffffca88d229e080인 프로세스의 0x34 핸들을 조회
lkd> !handle 0x34 1 ffffca88d229e080
// 또는 현재 문맥이 동일하다면 _EPROCESS 생략 가능
// .process /p ffffca88d229e080
// 로컬 커널 디버깅이 아닌 라이브 디버깅이라면 .process /i ffffca88d229e080
PROCESS ffffca88d229e080
SessionId: 2 Cid: 1c30 Peb: e16ccdf000 ParentCid: 1438
DirBase: 5e25f000 ObjectTable: ffffe004275b52c0 HandleCount: 290.
Image: windbg.exe
Handle table at ffffe004275b52c0 with 290 entries in use
0034: Object: ffffe00418928b00 GrantedAccess: 00000003 (Protected) (Audit)
보는 바와 같이 Process Explorer의 값과 정확히 일치합니다.
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]