Windows 10 - Process Explorer로 확인한 Handle 정보를 windbg에서 조회
예를 들어 notepad.exe를 하나 실행해 두면,
notepad.exe
Process ID: 10052 (0x2744)
Process Explorer로 해당 프로세스의 핸들 정보를 다음과 같이 볼 수 있고,
그중에서 다음의 핸들 값을 WinDbg에서 좀 더 분석해 보겠습니다.
Type: File
Name: C:\Windows\Fonts\StaticCache.dat
Object Address: 0xFFFFE70CB699F8F0
Access: 0x00120089
Handle: 0x1b0
핸들 값과 함께 나오는 "Object Address"가 커널 영역이기 때문에 아쉽게도 (user mode의) WinDbg에서도 해당 메모리를 접근할 수 없습니다. 이것이 가능하려면 "Local Kernel Debug"가 가능하도록,
Windbg - Local Kernel Debug 모드
; https://www.sysnet.pe.kr/2/0/934
관리자 권한으로 "bcdedit -debug on" 명령을 실행 후 윈도우를 재부팅해야 합니다.
WinDbg를 Local Kernel Debug로 실행했으면 이제 전에 설명한 것처럼,
Windbg - 윈도우 핸들 테이블 (2)
; https://www.sysnet.pe.kr/2/0/1476
"Object Address"에 대해 "!object" 명령어로 직접 조회할 수 있습니다.
lkd> !object 0xFFFFE70CB699F8F0
Object: ffffe70cb699f8f0 Type: (ffffe70ca82cb900) File
ObjectHeader: ffffe70cb699f8c0 (new version)
HandleCount: 1 PointerCount: 32765
Directory Object: 00000000 Name: \Windows\Fonts\StaticCache.dat {HarddiskVolume4}
// Object header == Object Address - sizeof(_OBJECT_HEADER)
// ffffe70cb699f8c0 == 0xFFFFE70CB699F8F0 - 0x30
Handle이 가리키는 객체의 타입을 알려면 Header를 덤프해,
lkd> dt _OBJECT_HEADER ffffe70cb699f8c0
nt!_OBJECT_HEADER
+0x000 PointerCount : 0n32765
+0x008 HandleCount : 0n1
+0x008 NextToFree : 0x00000000`00000001 Void
+0x010 Lock : _EX_PUSH_LOCK
+0x018 TypeIndex : 0x34 '4'
+0x019 TraceFlags : 0 ''
+0x019 DbgRefTrace : 0y0
+0x019 DbgTracePermanent : 0y0
+0x01a InfoMask : 0x4c 'L'
+0x01b Flags : 0 ''
+0x01b NewObject : 0y0
+0x01b KernelObject : 0y0
+0x01b KernelOnlyAccess : 0y0
+0x01b ExclusiveObject : 0y0
+0x01b PermanentObject : 0y0
+0x01b DefaultSecurityQuota : 0y0
+0x01b SingleHandleEntry : 0y0
+0x01b DeletedInline : 0y0
+0x01c Reserved : 0
+0x020 ObjectCreateInfo : 0xffffe70c`aca3da00 _OBJECT_CREATE_INFORMATION
+0x020 QuotaBlockCharged : 0xffffe70c`aca3da00 Void
+0x028 SecurityDescriptor : (null)
+0x030 Body : _QUAD
TypeIndex 값을 알아야 합니다. 그런데, (
지난 글에 설명한 ObTypeIndexTable을 기반으로) TypeIndex 값(위의 경우 0x34)에 따라 타입을 확인해 보면 값이 좀 이상합니다.
lkd> x nt!ObTypeIndexTable
fffff802`4f174d50 nt!ObTypeIndexTable = <no type information>
// dt _OBJECT_TYPE poi(fffff802`4f174d50 + (0x34 * 8))
lkd> dt _OBJECT_TYPE poi(nt!ObTypeIndexTable + (0x34 * @$ptrsize ))
nt!_OBJECT_TYPE
+0x000 TypeList : _LIST_ENTRY [ 0xffffe70c`a82faa60 - 0xffffe70c`a82faa60 ]
+0x010 Name : _UNICODE_STRING "EtwConsumer"
+0x020 DefaultObject : (null)
+0x028 Index : 0x34 '4'
+0x02c TotalNumberOfObjects : 0xb
+0x030 TotalNumberOfHandles : 0xb
+0x034 HighWaterNumberOfObjects : 0xc
+0x038 HighWaterNumberOfHandles : 0xc
+0x040 TypeInfo : _OBJECT_TYPE_INITIALIZER
+0x0b8 TypeLock : _EX_PUSH_LOCK
+0x0c0 Key : 0x43777445
+0x0c8 CallbackList : _LIST_ENTRY [ 0xffffe70c`a82fab28 - 0xffffe70c`a82fab28 ]
분명히 Process Explorer에서는 "File" 타입의 객체에 대한 Handle 값으로 조회한 것인데 생뚱맞게 "EtwConsumer"가 나온 것입니다. 게다가 또 다른 핸들에 대해 조회해 보면 TypeIndex가 허용하는 값을 넘는 경우도 볼 수 있었습니다. (나중에 설명하지만 Windows 10 1909 환경에서 70(0x46) 개가 최대입니다.)
lkd> dt _OBJECT_HEADER ffffa9034a872140 TypeIndex
nt!_OBJECT_HEADER
+0x018 TypeIndex : 0xe4 ''
이에 대해 검색해 보니 다행히 답이 나옵니다. ^^
A Light on Windows 10's "BJECT_HEADER->TypeIndex"
; https://medium.com/@ashabdalhalim/a-light-on-windows-10s-object-header-typeindex-value-e8f907e7073a
위의 글을 정리해 보면, Windows 7/8/8.1에서는 TypeIndex가 ObTypeIndexTable에서의 Index에 해당했지만 Windows 10에서는 직접적인 Index가 아닌 다음과 같이 별도의 연산을 통해 구해야 합니다.
Index = TypeIndex ^ 2nd least significate byte of OBJECT_HEADER address ^ nt!ObHeaderCookie
우선 TypeIndex는 0x34였고, OBJECT_HEADER 주소는 ffffe70cb699f8c0였으므로 그것의 최하위로부터 2번째 위치한 바이트이므로 "f8"이 됩니다. 마지막으로 ObHeaderCookie는 db 명령어를 통해 구하고 나면,
lkd> db nt!ObHeaderCookie L1
fffff802`4f174684 e9
이제 다음과 같이 Index 값을 구할 수 있습니다.
lkd> ? 0x34 ^ f8 ^ e9
Evaluate expression: 37 = 00000000`00000025
마저 확인을 해야죠. ^^
lkd> dt nt!_OBJECT_TYPE poi(nt!ObTypeIndexTable + (0x25 * @$ptrsize ))
+0x000 TypeList : _LIST_ENTRY [ 0xffffe70c`a82cb900 - 0xffffe70c`a82cb900 ]
+0x010 Name : _UNICODE_STRING "File"
+0x020 DefaultObject : 0x00000000`0000009b Void
+0x028 Index : 0x25 'Unknown format characterUnknown format control character
+0x02c TotalNumberOfObjects : 0x7e22
+0x030 TotalNumberOfHandles : 0xb64
+0x034 HighWaterNumberOfObjects : 0xbf2f
+0x038 HighWaterNumberOfHandles : 0x172a
+0x040 TypeInfo : _OBJECT_TYPE_INITIALIZER
+0x0b8 TypeLock : _EX_PUSH_LOCK
+0x0c0 Key : 0x656c6946
+0x0c8 CallbackList : _LIST_ENTRY [ 0xffffe70c`a82cb9c8 - 0xffffe70c`a82cb9c8 ]
lkd> dt _OBJECT_TYPE_INITIALIZER (poi(nt!ObTypeIndexTable + (0x25 * @$ptrsize )) + 0x40)
nt!_OBJECT_TYPE_INITIALIZER
+0x000 Length : 0x78
+0x002 ObjectTypeFlags : 0x111
+0x002 CaseInsensitive : 0y1
+0x002 UnnamedObjectsOnly : 0y0
+0x002 UseDefaultObject : 0y0
+0x002 SecurityRequired : 0y0
+0x002 MaintainHandleCount : 0y1
+0x002 MaintainTypeList : 0y0
+0x002 SupportsObjectCallbacks : 0y0
+0x002 CacheAligned : 0y0
+0x003 UseExtendedParameters : 0y1
+0x003 Reserved : 0y0000000 (0)
+0x004 ObjectTypeCode : 1
+0x008 InvalidAttributes : 0x130
+0x00c GenericMapping : _GENERIC_MAPPING
+0x01c ValidAccessMask : 0x1f01ff
+0x020 RetainAccess : 0
+0x024 PoolType : 200 ( NonPagedPoolNx )
+0x028 DefaultPagedPoolCharge : 0x400
+0x02c DefaultNonPagedPoolCharge : 0x180
+0x030 DumpProcedure : (null)
+0x038 OpenProcedure : (null)
+0x040 CloseProcedure : 0xfffff802`4f1e4130 void nt!IopCloseFile+0
+0x048 DeleteProcedure : 0xfffff802`4f1e73a0 void nt!IopDeleteFile+0
+0x050 ParseProcedure : 0xfffff802`4f2be1b0 long nt!IopParseFile+0
+0x050 ParseProcedureEx : 0xfffff802`4f2be1b0 long nt!IopParseFile+0
+0x058 SecurityProcedure : 0xfffff802`4f2a0bb0 long nt!IopGetSetSecurityObject+0
+0x060 QueryNameProcedure : 0xfffff802`4f246ab0 long nt!IopQueryName+0
+0x068 OkayToCloseProcedure : (null)
+0x070 WaitObjectFlagMask : 0x10000000
+0x074 WaitObjectFlagOffset : 0x50
+0x076 WaitObjectPointerOffset : 0x20
아울러, "File" 객체이므로 Body 영역을 "_FILE_OBJECT" 타입으로 덤프할 수 있습니다.
lkd> dt _FILE_OBJECT 0xFFFFE70CB699F8F0
nt!_FILE_OBJECT
+0x000 Type : 0n5
+0x002 Size : 0n216
+0x008 DeviceObject : 0xffffe70c`a8cb0b80 _DEVICE_OBJECT
+0x010 Vpb : 0xffffe70c`a8f8e8b0 _VPB
+0x018 FsContext : 0xffffa903`495f5940 Void
+0x020 FsContext2 : 0xffffa903`619826e0 Void
+0x028 SectionObjectPointer : 0xffffe70c`b0684dc8 _SECTION_OBJECT_POINTERS
+0x030 PrivateCacheMap : 0xffffe70c`b8b240e0 Void
+0x038 FinalStatus : 0n0
+0x040 RelatedFileObject : (null)
+0x048 LockOperation : 0 ''
+0x049 DeletePending : 0 ''
+0x04a ReadAccess : 0x1 ''
+0x04b WriteAccess : 0 ''
+0x04c DeleteAccess : 0 ''
+0x04d SharedRead : 0x1 ''
+0x04e SharedWrite : 0 ''
+0x04f SharedDelete : 0x1 ''
+0x050 Flags : 0xc0042
+0x058 FileName : _UNICODE_STRING "\Windows\Fonts\StaticCache.dat"
+0x068 CurrentByteOffset : _LARGE_INTEGER 0x3c
+0x070 Waiters : 0
+0x074 Busy : 0
+0x078 LastLock : (null)
+0x080 Lock : _KEVENT
+0x098 Event : _KEVENT
+0x0b0 CompletionContext : (null)
+0x0b8 IrpListLock : 0
+0x0c0 IrpList : _LIST_ENTRY [ 0xffffe70c`b699f9b0 - 0xffffe70c`b699f9b0 ]
+0x0d0 FileObjectExtension : (null)
참고로, Body 영역에 대한 정보는 객체의 "Type"에 따라 다음과 같은 식의 구조체로 덤프하면 됩니다.
File: _FILE_OBJECT
Process: _EPROCESS
SymbolicLink: _OBJECT_SYMBOLIC_LINK
Token: _TOKEN
Thread: _ETHREAD
Mutant: _KMUTANT
Driver: _DRIVER_OBJECT
Key: _CM_KEY_BODY
Type: _OBJECT_TYPE
예를 들어 Process Explorer에서 레지스트리 키 하나를 선택해,
lkd> !object ffffa9034a1b3a70
Object: ffffa9034a1b3a70 Type: (ffffe70ca82cb4e0) Key
ObjectHeader: ffffa9034a1b3a40 (new version)
HandleCount: 1 PointerCount: 32762
Directory Object: 00000000 Name: \REGISTRY\MACHINE\SOFTWARE\MICROSOFT\WINDOWSRUNTIME\ACTIVATABLECLASSID
이 객체의 BODY를 "Key" 타입이니까 _CM_KEY_BODY 구조체로 덤프해 보면 됩니다.
lkd> dt _CM_KEY_BODY ffffa9034a1b3a70
nt!_CM_KEY_BODY
+0x000 Type : 0x6b793032
+0x008 KeyControlBlock : 0xffffa903`470c0360 _CM_KEY_CONTROL_BLOCK
+0x010 NotifyBlock : (null)
+0x018 ProcessID : 0x00000000`00002744 Void
+0x020 KeyBodyList : _LIST_ENTRY [ 0xffffa903`4a2aac90 - 0xffffa903`61595f90 ]
+0x030 Flags : 0y0000000000000000 (0)
+0x030 HandleTags : 0y0000000000000000 (0)
+0x038 Trans : _CM_TRANS_PTR
+0x040 KtmUow : (null)
+0x048 ContextListHead : _LIST_ENTRY [ 0xffffa903`4a1b3ab8 - 0xffffa903`4a1b3ab8 ]
+0x058 EnumerationResumeContext : (null)
테스트했던 notepad.exe의 PID == 0x2744였으니까 _CM_KEY_BODY의 ProcessID와 일치하는 걸로 봐서 정상적으로 덤프가 되었음을 알 수 있습니다.
아울러, 객체의 타입이 "Type"에 속하는 것들을 다음과 같은 명령어로 구할 수 있습니다.
lkd> !object \ObjectTypes
Object: ffffa90343608c30 Type: (ffffe70ca82757a0) Directory
ObjectHeader: ffffa90343608c00 (new version)
HandleCount: 0 PointerCount: 69
Directory Object: ffffa90343608420 Name: ObjectTypes
Hash Address Type Name
---- ------- ---- ----
00 ffffe70ca82cb640 Type TmTm
01 ffffe70ca82b0140 Type Desktop
ffffe70ca82b0560 Type Process
02 ffffe70ca82cb220 Type EnergyTracker
ffffe70ca82cb0c0 Type RegistryTransaction
03 ffffe70ca82af7a0 Type DebugObject
04 ffffe70cac36d640 Type VRegConfigurationContext
ffffe70ca82cb7a0 Type TpWorkerFactory
05 ffffe70ca82cc2a0 Type Adapter
ffffe70ca8275640 Type Token
06 ffffe70ca82fa4e0 Type DxgkSharedResource
07 ffffe70ca82af640 Type PsSiloContextPaged
08 ffffe70ca82fae80 Type NdisCmState
ffffe70ca82af380 Type ActivityReference
09 ffffe70ca82fa0c0 Type PcwObject
ffffe70ca82ccae0 Type WmiGuid
11 ffffe70ca82fb2a0 Type DmaAdapter
ffffe70ca82fa7a0 Type EtwRegistration
12 ffffe70ca82fbda0 Type DxgkSharedBundleObject
ffffe70ca82cba60 Type Session
ffffe70ca82b02a0 Type RawInputManager
ffffe70ca82afa60 Type Timer
13 ffffe70ca82b0f00 Type Mutant
14 ffffe70ca82afd20 Type IRTimer
16 ffffe70ca82fbae0 Type DxgkCurrentDxgProcessObject
ffffe70ca82ccda0 Type IoCompletion
17 ffffe70ca82fbc40 Type DxgkSharedProtectedSessionObject
ffffe70ca82fb820 Type DxgkSharedSyncObject
ffffe70ca82b0820 Type WindowStation
ffffe70ca82b06c0 Type Profile
18 ffffe70ca82cb900 Type File
20 ffffe70ca82af0c0 Type Partition
21 ffffe70ca82fb6c0 Type DxgkSharedKeyedMutexObject
ffffe70ca82cb380 Type ActivationObject
ffffe70ca82b0da0 Type Semaphore
22 ffffe70ca82b0980 Type PsSiloContextNonPaged
23 ffffe70ca82faa60 Type EtwConsumer
ffffe70ca82b0ae0 Type Composition
24 ffffe70ca82fb140 Type CoverageSampler
ffffe70ca82fa220 Type EtwSessionDemuxEntry
ffffe70ca82b0400 Type CoreMessaging
25 ffffe70ca82cc820 Type TmTx
ffffe70ca8275900 Type SymbolicLink
26 ffffe70ca82fad20 Type FilterConnectionPort
ffffe70ca82cb4e0 Type Key
ffffe70ca82afe80 Type KeyedEvent
ffffe70ca82b0c40 Type Callback
27 ffffe70ca82ccc40 Type WaitCompletionPacket
28 ffffe70ca82af220 Type UserApcReserve
ffffe70ca8275a60 Type Job
29 ffffe70ca82fb980 Type DxgkDisplayManagerObject
ffffe70ca82fa900 Type DxgkSharedSwapChainObject
ffffe70ca82cc560 Type Controller
ffffe70ca82afbc0 Type IoCompletionReserve
30 ffffe70ca82cc980 Type Device
ffffe70ca82757a0 Type Directory
31 ffffe70ca82cc6c0 Type Section
ffffe70ca82ccf00 Type TmEn
ffffe70ca82af4e0 Type Thread
32 ffffe70ca82fbf00 Type DxgkCompositionObject
ffffe70ca82754e0 Type Type
33 ffffe70ca82fb560 Type FilterCommunicationPort
ffffe70ca82cbbc0 Type PowerRequest
35 ffffe70ca82cbd20 Type TmRm
ffffe70ca82af900 Type Event
36 ffffe70ca82cc140 Type ALPC Port
ffffe70ca82cc400 Type Driver
출력 결과 중에서 "EtwConsumer"인 객체 주소 == ffffe70ca82faa60를 _OBJECT_TYPE으로 덤프할 수 있습니다.
lkd> dt _OBJECT_TYPE ffffe70ca82faa60
nt!_OBJECT_TYPE
+0x000 TypeList : _LIST_ENTRY [ 0xffffe70c`a82faa60 - 0xffffe70c`a82faa60 ]
+0x010 Name : _UNICODE_STRING "EtwConsumer"
+0x020 DefaultObject : (null)
+0x028 Index : 0x34 '4'
+0x02c TotalNumberOfObjects : 0xb
+0x030 TotalNumberOfHandles : 0xb
+0x034 HighWaterNumberOfObjects : 0xc
+0x038 HighWaterNumberOfHandles : 0xc
+0x040 TypeInfo : _OBJECT_TYPE_INITIALIZER
+0x0b8 TypeLock : _EX_PUSH_LOCK
+0x0c0 Key : 0x43777445
+0x0c8 CallbackList : _LIST_ENTRY [ 0xffffe70c`a82fab28 - 0xffffe70c`a82fab28 ]
그리고 이 결과는 전에 "dt _OBJECT_TYPE poi(nt!ObTypeIndexTable + (0x34 * @$ptrsize ))" 명령어와 정확히 일치합니다. 실제로 ObTypeIndexTable의 주소를 덤프해 보면,
lkd> dq /c1 ObTypeIndexTable L46
fffff802`4f174d50 00000000`00000000 // 0x00
fffff802`4f174d58 ffffbb00`7595b000 // 0x01
fffff802`4f174d60 ffffe70c`a82754e0 // 0x02 == Type
fffff802`4f174d68 ffffe70c`a82757a0 // 0x03 == Directory
fffff802`4f174d70 ffffe70c`a8275900 // 0x04 == SymbolicLink
fffff802`4f174d78 ffffe70c`a8275640 // 0x05 == Token
fffff802`4f174d80 ffffe70c`a8275a60 // 0x06 == Job
fffff802`4f174d88 ffffe70c`a82b0560 // 0x07 == Process
fffff802`4f174d90 ffffe70c`a82af4e0 // 0x08 == Thread
fffff802`4f174d98 ffffe70c`a82af0c0 // 0x09 == Partition
fffff802`4f174da0 ffffe70c`a82af220 // 0x0a == UserApcReserve
fffff802`4f174da8 ffffe70c`a82afbc0 // 0x0b == IoCompletionReserve
fffff802`4f174db0 ffffe70c`a82af380 // 0x0c == ActivityReference
fffff802`4f174db8 ffffe70c`a82af640 // 0x0d == PsSiloContextPaged
fffff802`4f174dc0 ffffe70c`a82b0980 // 0x0e == PsSiloContextNonPaged
fffff802`4f174dc8 ffffe70c`a82af7a0 // 0x0f == DebugObject
fffff802`4f174dd0 ffffe70c`a82af900 // 0x10 == Event
fffff802`4f174dd8 ffffe70c`a82b0f00 // 0x11 == Mutant
fffff802`4f174de0 ffffe70c`a82b0c40 // 0x12 == Callback
fffff802`4f174de8 ffffe70c`a82b0da0 // 0x13 == Semaphore
fffff802`4f174df0 ffffe70c`a82afa60 // 0x14 == Timer
fffff802`4f174df8 ffffe70c`a82afd20 // 0x15 == IRTimer
fffff802`4f174e00 ffffe70c`a82b06c0 // 0x16 == Profile
fffff802`4f174e08 ffffe70c`a82afe80 // 0x17 == KeyedEvent
fffff802`4f174e10 ffffe70c`a82b0820 // 0x18 == WindowStation
fffff802`4f174e18 ffffe70c`a82b0140 // 0x19 == Desktop
fffff802`4f174e20 ffffe70c`a82b0ae0 // 0x1a == Composition
fffff802`4f174e28 ffffe70c`a82b02a0 // 0x1b == RawInputManager
fffff802`4f174e30 ffffe70c`a82b0400 // 0x1c == CoreMessaging
fffff802`4f174e38 ffffe70c`a82cb380 // 0x1d == ActivationObject
fffff802`4f174e40 ffffe70c`a82cb7a0 // 0x1e == TpWorkerFactory
fffff802`4f174e48 ffffe70c`a82cc2a0 // 0x1f == Adapter
fffff802`4f174e50 ffffe70c`a82cc560 // 0x20 == Controller
fffff802`4f174e58 ffffe70c`a82cc980 // 0x21 == Device
fffff802`4f174e60 ffffe70c`a82cc400 // 0x22 == Driver
fffff802`4f174e68 ffffe70c`a82ccda0 // 0x23 == IoCompletion
fffff802`4f174e70 ffffe70c`a82ccc40 // 0x24 == WaitCompletionPacket
fffff802`4f174e78 ffffe70c`a82cb900 // 0x25 == File (0n37)
fffff802`4f174e80 ffffe70c`a82cb640 // 0x26 == TmTm
fffff802`4f174e88 ffffe70c`a82cc820 // 0x27 == TmTx
fffff802`4f174e90 ffffe70c`a82cbd20 // 0x28 == TmRm
fffff802`4f174e98 ffffe70c`a82ccf00 // 0x29 == TmEn
fffff802`4f174ea0 ffffe70c`a82cc6c0 // 0x2a == Section
fffff802`4f174ea8 ffffe70c`a82cba60 // 0x2b == Session
fffff802`4f174eb0 ffffe70c`a82cb4e0 // 0x2c == Key
fffff802`4f174eb8 ffffe70c`a82cb0c0 // 0x2d == RegistryTransaction
fffff802`4f174ec0 ffffe70c`a82cc140 // 0x2e == ALPC Port
fffff802`4f174ec8 ffffe70c`a82cb220 // 0x2f == EnergyTracker
fffff802`4f174ed0 ffffe70c`a82cbbc0 // 0x30 == PowerRequest
fffff802`4f174ed8 ffffe70c`a82ccae0 // 0x31 == WmiGuid
fffff802`4f174ee0 ffffe70c`a82fa7a0 // 0x32 == EtwRegistration
fffff802`4f174ee8 ffffe70c`a82fa220 // 0x33 == EtwSessionDemuxEntry
fffff802`4f174ef0 ffffe70c`a82faa60 // 0x34 == EtwConsumer (0n52)
fffff802`4f174ef8 ffffe70c`a82fb140 // 0x35 == CoverageSampler
fffff802`4f174f00 ffffe70c`a82fb2a0 // 0x36 == DmaAdapter
fffff802`4f174f08 ffffe70c`a82fa0c0 // 0x37 == PcwObject
fffff802`4f174f10 ffffe70c`a82fad20 // 0x38 == FilterConnectionPort
fffff802`4f174f18 ffffe70c`a82fb560 // 0x39 == FilterCommunicationPort
fffff802`4f174f20 ffffe70c`a82fae80 // 0x3a == NdisCmState
fffff802`4f174f28 ffffe70c`a82fa4e0 // 0x3b == DxgkSharedResource
fffff802`4f174f30 ffffe70c`a82fb6c0 // 0x3c == DxgkSharedKeyedMutexObject
fffff802`4f174f38 ffffe70c`a82fb820 // 0x3d == DxgkSharedSyncObject
fffff802`4f174f40 ffffe70c`a82fa900 // 0x3e == DxgkSharedSwapChainObject
fffff802`4f174f48 ffffe70c`a82fb980 // 0x3f == DxgkDisplayManagerObject
fffff802`4f174f50 ffffe70c`a82fbae0 // 0x40 == DxgkCurrentDxgProcessObject
fffff802`4f174f58 ffffe70c`a82fbc40 // 0x41 == DxgkSharedProtectedSessionObject
fffff802`4f174f60 ffffe70c`a82fbda0 // 0x42 == DxgkSharedBundleObject
fffff802`4f174f68 ffffe70c`a82fbf00 // 0x43 == DxgkCompositionObject
fffff802`4f174f70 ffffe70c`ac36d640 // 0x44 == VRegConfigurationContext
fffff802`4f174f78 00000000`00000000 // 0x45
poi(nt!ObTypeIndexTable + (0x34 * @$ptrsize )) == ffffe70c`a82faa60 주솟값이 나옵니다.
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]