Windbg - 윈도우 핸들 테이블 (2)
지난번 글에서 부모/자식 간에 상속되는 핸들 문제를 살펴보았는데요.
프로세스가 종료된 후에도 소켓이 살아있다면?
; https://www.sysnet.pe.kr/2/0/1475
실습 겸 해서 이것을 windbg/Process Explorer를 통해서 확인해 보았습니다. 우선, 소켓의 핸들값은 Socket.Handle 속성으로부터 쉽게 구할 수 있습니다.
Socket srvSocket =
new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
Console.WriteLine("Socket Handle: 0x" + srvSocket.Handle.ToString("X"));
실제로 이 값을 Process Explorer에서 살펴보면 File 타입의 \Device\Afd 항목으로 확인이 가능합니다.
Type: File
Name: \Device\Afd
Handle: 0x298
Object Address: 0xFFFFFA8020907330
Acces: 0x0016019F
자... 그럼, 이걸 windbg로 탐험해 볼까요? 다음은 User-mode에서 소켓 핸들 정보를 얻어온 결과입니다.
0:003> !handle 0x298 f
Handle 298
Type File
Attributes 0
GrantedAccess 0x16019f:
ReadControl,WriteDac,Synch
Read/List,Write/Add,Append/SubDir/CreatePipe,ReadEA,WriteEA,ReadAttr,WriteAttr
HandleCount 3
PointerCount 786420
No Object Specific Information available
아쉽게도 소켓이라는 것을 알 수 있는 방법이 없군요. ^^ 자식 프로세스로 내려와서 핸들을 살펴보면 상속을 받았기 때문에 예상했던 대로 부모 프로세스의 핸들값과 동일한 값이 나오는 것을 확인할 수 있습니다.
Type, Name, Handle, Object Address, Access 값이 모두 똑같습니다.
실습하다 보니 예전에 써놓은 글이 생각났습니다. ^^
Windbg - 윈도우 핸들 테이블
; https://www.sysnet.pe.kr/2/0/935
커널 모드로 확인해 보면 좀 더 많은 정보를 얻을 수 있을까요? (아래의 실습에서는 프로세스를 새로 실행했기 때문에 pid == 0x1274가 되었습니다.)
우선, windbg에서 Live 커널 디버깅으로 진입합니다.
0:004> .attach -k
Attach will occur on next execution
||0:0:004> g
Connected to Windows 7 9200 x64 target at (Tue Aug 13 00:22:35.078 2013 (UTC + 9:00)), ptr64 TRUE
Symbol search path is: SRV*d:\Symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Kernel Version 9200 MP (2 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 9200.16628.amd64fre.win8_gdr.130531-1504
Machine Name:
Kernel base = 0xfffff800`7627b000 PsLoadedModuleList = 0xfffff800`76547a20
Debug session time: Tue Aug 13 00:22:35.438 2013 (UTC + 9:00)
System Uptime: 0 days 1:15:52.418
위의 메시지에서는 "Windows 7"이라고 나왔지만, 실제로 테스트 머신은 Windows 8 x64였습니다.
다음으로, EPROCESS 주소를 얻기 위해 !process 명령을 수행하고,
||1:lkd> !process 0 0
**** NT ACTIVE PROCESS DUMP ****
PROCESS fffffa8001888040
SessionId: none Cid: 0004 Peb: 00000000 ParentCid: 0000
DirBase: 00187000 ObjectTable: fffff8a000003000 HandleCount: <Data Not Accessible>
Image: System
... [생략] ...
PROCESS fffffa800425e940
SessionId: 2 Cid: 0888 Peb: 7f5ffeed000 ParentCid: 03e4
DirBase: 5b7eb000 ObjectTable: fffff8a00571a580 HandleCount: <Data Not Accessible>
Image: ConsoleApplication3.exe
PROCESS fffffa800426d600
SessionId: 2 Cid: 0344 Peb: 7f694e7a000 ParentCid: 0888
DirBase: 5c090000 ObjectTable: fffff8a005397f00 HandleCount: <Data Not Accessible>
Image: notepad.exe
기본 디버깅 프로세스를 ConsoleApplication3.exe로 변경합니다.
||1:lkd> .process fffffa800425e940
Implicit process is now fffffa80'0425e940
"!process 0 0"의 결과에서 출력된 ObjectTable을 주소를 통해 _HANDLE_TABLE을 덤프하고,
||1:lkd> dt _HANDLE_TABLE fffff8a00571a580
nt!_HANDLE_TABLE
+0x000 NextHandleNeedingPool : 0x400
+0x004 ExtraInfoPages : 0n0
+0x008 TableCode : 0xfffff8a0`05884000
+0x010 QuotaProcess : 0xfffffa80`0425e940 _EPROCESS
+0x018 HandleTableList : _LIST_ENTRY [ 0xfffff8a0`05397f18 - 0xfffff8a0`03ef3758 ]
+0x028 UniqueProcessId : 0x888
+0x02c Flags : 8
+0x02c StrictFIFO : 0y0
+0x02c EnableHandleExceptions : 0y0
+0x02c Rundown : 0y0
+0x02c Duplicated : 0y1
+0x030 HandleContentionEvent : _EX_PUSH_LOCK
+0x038 HandleTableLock : _EX_PUSH_LOCK
+0x040 FreeLists : [1] _HANDLE_TABLE_FREE_LIST
+0x040 ActualEntry : [32] ""
+0x060 DebugInfo : (null)
TableCode 속성 값이 핸들 테이블 주소이므로 이를 덤프해 봅니다.
||1:lkd> dq 0xfffff8a0`05884000
fffff8a0`05884000 00000000`00000000 00000000`00000000
fffff8a0`05884010 d400212c`2407fff9 0000001f`0012019f
fffff8a0`05884020 c50003b0`1207ffd9 00000003`00000003
fffff8a0`05884030 d400210d`aa87fff7 0000001f`00100020
fffff8a0`05884040 d40013fc`f787ffe9 0000001f`0012019f
fffff8a0`05884050 c5002ba8`c887fff7 00000026`00020019
fffff8a0`05884060 d4001326`4a07fff5 00000027`001f0001
fffff8a0`05884070 d400211e`1707fffb 0000000e`001f0001
... [생략] ...
fffff8a0`058848c0 d40013fc`6ea7ffef 0000001f`0016019f
fffff8a0`058848d0 00000000`00000000 fffff8a0`05884930
fffff8a0`058848e0 d4002136`ae87fff9 00000007`001fffff
fffff8a0`058848f0 00000000`00000000 fffff8a0`05884940
fffff8a0`05884900 00000000`00000000 fffff8a0`058848f0
fffff8a0`05884910 c5002b9d`a807fff9 00000026`00000008
fffff8a0`05884920 c5002942`4c07fff9 00000026`00000008
fffff8a0`05884930 00000000`00000000 00000000`00000000
비교를 위해 pid == 2184(0x888)에 포함된 핸들을 나열해 볼까요?
||1:lkd> !handle 0 f 888
Searching for Process with Cid == 888
PROCESS fffffa800425e940
SessionId: 2 Cid: 0888 Peb: 7f5ffeed000 ParentCid: 03e4
DirBase: 5b7eb000 ObjectTable: fffff8a00571a580 HandleCount: <Data Not Accessible>
Image: ConsoleApplication3.exe
Handle table at fffff8a005884000 with 0 entries in use
0004: Object: 1a800425878 GrantedAccess: 0012019f (Locked) Entry: fffff8a005884010
(object paged out)
0008: Object: 18a00076050 GrantedAccess: 00000003 (Locked) (Audit) Entry: fffff8a005884020
(object paged out)
... [생략] ...
0230: Object: 1a80027f908 GrantedAccess: 0016019f (Audit) Entry: fffff8a0058848c0
(object paged out)
... [생략] ...
보시는 바와 같이 dq 결과값의 한 줄은 !handle 0 f 888 출력 하나와 매핑되는 것을 볼 수 있습니다.
fffff8a0`05884010 d400212c`2407fff9 0000001f`0012019f
0004: Object: 1a800425878 GrantedAccess: 0012019f (Locked) Entry: fffff8a005884010
(object paged out)
fffff8a0`058848c0 d40013fc`6ea7ffef 0000001f`0016019f
0230: Object: 1a80027f908 GrantedAccess: 0016019f (Audit) Entry: fffff8a0058848c0
(object paged out)
문제는 출력 결과에 ObjectHeader 값이 아닌, Object 값이 나온다는 점입니다. 게다가 그나마 출력되는 Object의 값이 64비트 주소가 아닌 1a800425878 같은 식별자에 해당하는데요.
이 정보만으로는 어떻게 ObjectHeader를 접근해야 하는지 알 수가 없습니다. (2020-01-03 업데이트: Object Header는 _OBJECT_HEADER 커널 구조체의 크기가 0x30이므로 "Object Address"로부터 "- 0x30" 연산을 하면 구할 수 있습니다.)
윈도우 7에서 수행했던 지난번 실습(Windbg - 윈도우 핸들 테이블:
https://www.sysnet.pe.kr/2/0/935)에서는 "dq [TableCode]"로 출력된 덤프를 통해
_OBJECT_HEADER를 구할 수 있었지만, 윈도우 8에서는 해당 주솟값으로 알 수 없었습니다.
||1:lkd> dq 0xfffff8a0`05884000
fffff8a0`05884000 00000000`00000000 00000000`00000000
fffff8a0`05884010 d400212c`2407fff9 0000001f`0012019f
fffff8a0`05884020 c50003b0`1207ffd9 00000003`00000003
fffff8a0`05884030 d400210d`aa87fff7 0000001f`00100020
fffff8a0`05884040 d40013fc`f787ffe9 0000001f`0012019f
fffff8a0`05884050 c5002ba8`c887fff7 00000026`00020019
fffff8a0`05884060 d4001326`4a07fff5 00000027`001f0001
fffff8a0`05884070 d400211e`1707fffb 0000000e`001f0001
||1:lkd> dt _OBJECT_HEADER (d400212c`2407fff9 - 1)
nt!_OBJECT_HEADER
+0x000 PointerCount : ??
+0x008 HandleCount : ??
+0x008 NextToFree : ????
+0x010 Lock : _EX_PUSH_LOCK
+0x018 TypeIndex : ??
+0x019 TraceFlags : ??
+0x019 DbgRefTrace : ??
+0x019 DbgTracePermanent : ??
+0x01a InfoMask : ??
+0x01b Flags : ??
+0x01c Spare : ??
+0x020 ObjectCreateInfo : ????
+0x020 QuotaBlockCharged : ????
+0x028 SecurityDescriptor : ????
+0x030 Body : _QUAD
Memory read error d400212c`24080024
원인은 저도 모르겠습니다. ^^; 혹시 windbg를 통해 TableCode 덤프에서 _OBJECT_HEADER를 구할 수 있는 방법을 아시는 분은 덧글 부탁드립니다.
windbg에서 _OBJECT_HEADER 주소를 알 수는 없었지만, Process Explorer의 핸들 목록을 보면 "Object Address"라는 필드로 핸들 주소가 제공됩니다. 예제의 경우 0x230 소켓 핸들에 대한 "Object Address" 주솟값은 fffffa80027f8e00로 확인이 되었습니다. 이 값으로 windbg에서 !object 명령을 내려 보면 다음과 같은 출력 결과를 얻을 수 있습니다.
||1:lkd> !object fffffa80027f8e00
Object: fffffa80027f8e00 Type: (fffffa80018abf20) File
ObjectHeader: fffffa80027f8dd0 (new version)
HandleCount: 2 PointerCount: 524280
Directory Object: 00000000 Name: \Endpoint {Afd}
출력값을 통해서 이제서야 _OBJECT_HEADER를 조사할 수 있게 되었습니다.
||1:lkd> dt nt!_OBJECT_HEADER fffffa80027f8dd0
+0x000 PointerCount : 0n524280
+0x008 HandleCount : 0n2
+0x008 NextToFree : 0x00000000`00000002 Void
+0x010 Lock : _EX_PUSH_LOCK
+0x018 TypeIndex : 0x1f ''
+0x019 TraceFlags : 0 ''
+0x019 DbgRefTrace : 0y0
+0x019 DbgTracePermanent : 0y0
+0x01a InfoMask : 0xc ''
+0x01b Flags : 0 ''
+0x01c Spare : 0x5c003a
+0x020 ObjectCreateInfo : 0xfffffa80`037698c0 _OBJECT_CREATE_INFORMATION
+0x020 QuotaBlockCharged : 0xfffffa80`037698c0 Void
+0x028 SecurityDescriptor : (null)
+0x030 Body : _QUAD
아래의 글을 읽어 보면,
ObCreateObjectType & ObjectType
; http://ezbeat.tistory.com/421
Windows 7부터 _OBJECT_HEADER 구조체에 OBJECT_TYPE 멤버가 없다고 해서 OBJECT_TYPE_INITIALIZER 추적을 멈추고 있는데요. "
Windbg - 윈도우 핸들 테이블" 글에 보면 프로세스의 모든 핸들을 나열하는 "!handle 0 2 [pid]" 명령을 통해 출력되는 결과에서 Type 필드를 통해 _OBJECT_TYPE_INITIALIZER까지 추적할 수 있습니다. 하지만, 이번에 제가 실습한 윈도우 8 x64의 경우에는 "!handle 0 f 888" 명령어를 수행한 결과에서 Type 필드마저도 보이지 않았습니다.
그래서 다른 방법을 찾아야 했는데, 마침 이에 대해 상세하게 설명한 글을 발견할 수 있었습니다.
Windows 7 Object Headers
; http://www.codemachine.com/article_objectheader.html
즉, Type 정보가 _OBJECT_HEADER의 TypeIndex 필드로 대체되었고 이 값을 통해 ObTypeIndexTable 커널 변수가 가리키고 있는 타입 정보 목록에서 _OBJECT_TYPE 정보를 구할 수가 있습니다.
따라서, "dt nt!_OBJECT_HEADER fffffa80027f8dd0"를 통해 덤프한 결과의 TypeIndex가 0x1f이므로 그와 관련된 타입 정보는 다음의 명령어로 찾아낼 수 있습니다.
||1:lkd> dt nt!_OBJECT_TYPE poi(nt!ObTypeIndexTable + (1f * @$ptrsize ))
+0x000 TypeList : _LIST_ENTRY [ 0xfffffa80`018abf20 - 0xfffffa80`018abf20 ]
+0x010 Name : _UNICODE_STRING "File"
+0x020 DefaultObject : 0x00000000`0000009b Void
+0x028 Index : 0x1f ''
+0x02c TotalNumberOfObjects : 0x1761
+0x030 TotalNumberOfHandles : 0x5f6
+0x034 HighWaterNumberOfObjects : 0x17a3
+0x038 HighWaterNumberOfHandles : 0x634
+0x040 TypeInfo : _OBJECT_TYPE_INITIALIZER
+0x0b8 TypeLock : _EX_PUSH_LOCK
+0x0c0 Key : 0x656c6946
+0x0c8 CallbackList : _LIST_ENTRY [ 0xfffffa80`018abfe8 - 0xfffffa80`018abfe8 ]
따라서 _OBJECT_TYPE_INITIALIZER를 확인할 수 있게 되었습니다.
||1:lkd> dt !_OBJECT_TYPE_INITIALIZER (poi(nt!ObTypeIndexTable + (1f * @$ptrsize )) + 0x40)
nt!_OBJECT_TYPE_INITIALIZER
+0x000 Length : 0x78
+0x002 ObjectTypeFlags : 0x11 ''
+0x002 CaseInsensitive : 0y1
+0x002 UnnamedObjectsOnly : 0y0
+0x002 UseDefaultObject : 0y0
+0x002 SecurityRequired : 0y0
+0x002 MaintainHandleCount : 0y1
+0x002 MaintainTypeList : 0y0
+0x002 SupportsObjectCallbacks : 0y0
+0x002 CacheAligned : 0y0
+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 : 0xfffff800`9fc438c0 void nt!IopCloseFile+0
+0x048 DeleteProcedure : 0xfffff800`9fc3a200 void nt!IopDeleteFile+0
+0x050 ParseProcedure : 0xfffff800`9fc8f380 long nt!IopParseFile+0
+0x058 SecurityProcedure : 0xfffff800`9fc831b8 long nt!IopGetSetSecurityObject+0
+0x060 QueryNameProcedure : 0xfffff800`9fc6f14c long nt!IopQueryName+0
+0x068 OkayToCloseProcedure : (null)
+0x070 WaitObjectFlagMask : 0x10000000
+0x074 WaitObjectFlagOffset : 0x50
+0x076 WaitObjectPointerOffset : 0x20
다시 _OBJECT_TYPE으로 돌아가 Type == File이기 때문에 _OBJECT_HEADER의 _QUAD Body는 _FILE_OBJECT 형식을 따르므로 보다 상세한 정보를 다음과 같이 구할 수 있습니다.
||1:lkd> dt !_FILE_OBJECT (fffffa80027f8dd0 + 0x30)
ntdll!_FILE_OBJECT
+0x000 Type : 0n5
+0x002 Size : 0n216
+0x008 DeviceObject : 0xfffffa80`02c7da20 _DEVICE_OBJECT
+0x010 Vpb : (null)
+0x018 FsContext : 0xfffffa80`0263e370 Void
+0x020 FsContext2 : (null)
+0x028 SectionObjectPointer : (null)
+0x030 PrivateCacheMap : 0xffffffff`ffffffff Void
+0x038 FinalStatus : 0n0
+0x040 RelatedFileObject : (null)
+0x048 LockOperation : 0 ''
+0x049 DeletePending : 0 ''
+0x04a ReadAccess : 0 ''
+0x04b WriteAccess : 0 ''
+0x04c DeleteAccess : 0 ''
+0x04d SharedRead : 0 ''
+0x04e SharedWrite : 0 ''
+0x04f SharedDelete : 0 ''
+0x050 Flags : 0x40000
+0x058 FileName : _UNICODE_STRING "\Endpoint"
+0x068 CurrentByteOffset : _LARGE_INTEGER 0x0
+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 [ 0xfffffa80`027f8ec0 - 0xfffffa80`027f8ec0 ]
+0x0d0 FileObjectExtension : (null)
이하 나머지는 실습 삼아서 좀 더 해본 것입니다.
ObTypeIndexTable 커널 변수에 대한 덤프를 ^^ 할 일 없이 떠봤습니다.
||1:lkd> dq nt!ObTypeIndexTable
fffff800`76516d80 00000000`00000000 00000000`bad0b0b0
fffff800`76516d90 fffffa80`01904390 fffffa80`019014d0
fffff800`76516da0 fffffa80`019203d0 fffffa80`01903080
fffff800`76516db0 fffffa80`0190ab40 fffffa80`01920da0
fffff800`76516dc0 fffffa80`0191fea0 fffffa80`0191d480
fffff800`76516dd0 fffffa80`018edf20 fffffa80`0186c990
fffff800`76516de0 fffffa80`018b0800 fffffa80`0190e080
fffff800`76516df0 fffffa80`0186c830 fffffa80`01916a10
그리고, Process Explorer에 나타난 소켓의 Name == "\Device\Afd"을 기준으로 !object 출력을 살펴봤는데요.
||1:lkd> !object \Device\Afd
Object: fffffa8002c7da20 Type: (fffffa80018f6080) Device
ObjectHeader: fffffa8002c7d9f0 (new version)
HandleCount: 0 PointerCount: 3
Directory Object: fffff8a000011670 Name: Afd
||1:lkd> !object fffffa8002c7da20
Object: fffffa8002c7da20 Type: (fffffa80018f6080) Device
ObjectHeader: fffffa8002c7d9f0 (new version)
HandleCount: 0 PointerCount: 3
Directory Object: fffff8a000011670 Name: Afd
원래의 0x230 소켓 핸들은 Type이 File이었지만 위의 결과에서는 Device로 나옵니다. 즉, 다른 결과라는 이야기인데 양쪽이 어떻게 매칭이 되는지는 현재로써는 잘 모르겠습니다.
검색하다가 다음의 글을 보게 되었는데,
WinDbg 명령] !object
; http://greemate.tistory.com/entry/WinDbg-%EB%AA%85%EB%A0%B9-object
아래는 그와 관련해서 실습해 본 것입니다.
||1:lkd> !object \
Object: fffff8a0000092e0 Type: (fffffa80018f05b0) Directory
ObjectHeader: fffff8a0000092b0 (new version)
HandleCount: 0 PointerCount: 50
Directory Object: 00000000 Name: \
Hash Address Type Name
---- ------- ---- ----
01 fffffa8002cc3810 Mutant PendingRenameMutex
fffff8a00000c060 Directory ObjectTypes
03 fffffa8003949c40 Event NETLOGON_SERVICE_STARTED
fffffa800254b820 FilterConnectionPort MicrosoftMalwareProtectionRemoteIoPortWD
05 fffff8a000012a90 SymbolicLink SystemRoot
06 fffff8a000640080 Directory Sessions
fffffa800254c820 FilterConnectionPort MicrosoftMalwareProtectionVeryLowIoPortWD
08 fffff8a0000161a0 Directory ArcName
09 fffff8a0000865f0 Directory NLS
10 fffffa800387d3b0 Event LanmanServerAnnounceEvent
fffffa8002ad6560 ALPC Port ThemeApiPort
fffffa8002bc7520 Device UdfsCdRom
fffff8a00060bb90 Directory Windows
fffff8a00000c840 Directory GLOBAL??
11 fffff8a000671eb0 Directory RPC Control
fffffa8001da0e40 ALPC Port PdcPort
13 fffffa8002ef95e0 Event EFSInitEvent
14 fffff8a000134650 SymbolicLink Dfs
fffffa8002551060 Device clfs
15 fffffa8002e2bc60 Event DSYSDBG.Debug.Trace.Memory.284
fffffa80033f1c00 Event CsrSbSyncEvent
fffffa8002cd72e0 ALPC Port SeRmCommandPort
16 fffff8a00000ce10 SymbolicLink DosDevices
17 fffff8a00e333670 Directory KnownDlls32
18 fffff8a0000107a0 Key \REGISTRY
19 fffff8a00124bc90 Directory BaseNamedObjects
20 fffffa8001900070 ALPC Port PowerPort
21 fffffa80019c4db0 ALPC Port SmSsWinStationApiPort
fffffa8002fe6fe0 Event UniqueInteractiveSessionIdEvent
fffff8a00005cd00 Directory UMDFCommunicationPorts
22 fffff8a00075dd10 Directory KnownDlls
fffffa8001915070 ALPC Port PowerMonitorPort
23 fffffa80025556b0 Device Ntfs
fffff8a00005c630 Directory FileSystem
fffff8a000009a30 Directory KernelObjects
24 fffffa800251f820 FilterConnectionPort MicrosoftMalwareProtectionControlPortWD
26 fffffa8002ebb9b0 ALPC Port SeLsaCommandPort
fffff8a00000d820 Directory Callback
28 fffff8a00000eeb0 Directory Security
29 fffffa8002bc9520 Device UdfsDisk
30 fffffa800254a820 FilterConnectionPort MicrosoftMalwareProtectionAsyncPortWD
fffff8a0000105a0 Directory Device
34 fffff8a0005aa420 Section LsaPerformance
fffffa80037341a0 Event UniqueSessionIdEvent
fffffa8002cc38e0 ALPC Port SmApiPort
35 fffffa800254e820 FilterConnectionPort MicrosoftMalwareProtectionPortWD
36 fffffa8002e96fe0 Event SAM_SERVICE_STARTED
fffff8a00005c7e0 Directory Driver
위의 결과에서 Type == Directory로 나온 항목은 다음과 같이 열람하는 것을 반복할 수 있다고 합니다. ^^
||1:lkd> !object \ObjectTypes
Object: fffff8a00000c060 Type: (fffffa80018f05b0) Directory
ObjectHeader: fffff8a00000c030 (new version)
HandleCount: 0 PointerCount: 49
Directory Object: fffff8a0000092e0 Name: ObjectTypes
Hash Address Type Name
---- ------- ---- ----
00 fffffa80018b6f20 Type TmTm
01 fffffa8001892080 Type Desktop
fffffa80018fbf20 Type Process
03 fffffa80018d7f20 Type DebugObject
04 fffffa8001881da0 Type TpWorkerFactory
05 fffffa8001919080 Type Adapter
fffffa80018ef5c0 Type Token
06 fffffa8002be8600 Type DxgkSharedResource
08 fffffa80018f8f20 Type EventPair
09 fffffa80025c6580 Type PcwObject
fffffa80018edcf0 Type WmiGuid
11 fffffa80018ab600 Type EtwRegistration
12 fffffa80018a1670 Type Session
fffffa800191dea0 Type Timer
13 fffffa800189bf20 Type Mutant
14 fffffa8001896f20 Type IRTimer
16 fffffa800190f080 Type IoCompletion
17 fffffa8002be0600 Type DxgkSharedSyncObject
fffffa80018e4670 Type WindowStation
fffffa80018b7f20 Type Profile
18 fffffa800191d500 Type File
21 fffffa8001908740 Type Semaphore
23 fffffa80018ef110 Type EtwConsumer
fffffa8001903480 Type CompositionSurface
25 fffffa8001916bb0 Type TmTx
fffffa8001901550 Type SymbolicLink
26 fffffa800252f510 Type FilterConnectionPort
fffffa8001903750 Type Key
fffffa80018b5080 Type KeyedEvent
fffffa80018b5550 Type Callback
27 fffffa8001915840 Type WaitCompletionPacket
28 fffffa80018a6080 Type UserApcReserve
fffffa8001919e00 Type Job
29 fffffa8001919490 Type Controller
fffffa80018b29c0 Type IoCompletionReserve
30 fffffa80018ecf20 Type Device
fffffa80018f05b0 Type Directory
31 fffffa80018efaa0 Type Section
fffffa8001913f20 Type TmEn
fffffa800191dc50 Type Thread
32 fffffa800189f080 Type Type
33 fffffa8002543d00 Type FilterCommunicationPort
fffffa80018b25d0 Type PowerRequest
35 fffffa80019099c0 Type TmRm
fffffa8001910490 Type Event
36 fffffa80018829e0 Type ALPC Port
fffffa80018f5f20 Type Driver
끝~~~~!
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]