1

I try to extract the object type of notepad.exe in windbg but the nt!_object_type is showing it as Desktop object instead of Process object.

Any idea why is it so?

4: kd> !process 0 0 notepad.exe
PROCESS ffffc80bc92d7080
    SessionId: 1  Cid: 07c0    Peb: 4c99481000  ParentCid: 2b48
    DirBase: 147205000  ObjectTable: ffffa30d80327d40  HandleCount: 233.
    Image: notepad.exe

4: kd> !object ffffc80bc92d7080
Object: ffffc80bc92d7080  Type: (ffffc80bb02a9220) Process
    ObjectHeader: ffffc80bc92d7050 (new version)
    HandleCount: 6  PointerCount: 196490
4: kd> ?? (nt!_object_header*)0xffffc80bc92d7050
struct _OBJECT_HEADER * 0xffffc80b`c92d7050
   +0x000 PointerCount     : 0n196490
   +0x008 HandleCount      : 0n6
   +0x008 NextToFree       : 0x00000000`00000006 Void
   +0x010 Lock             : _EX_PUSH_LOCK
   +0x018 TypeIndex        : 0x19 ''
   +0x019 TraceFlags       : 0 ''
   +0x019 DbgRefTrace      : 0y0
   +0x019 DbgTracePermanent : 0y0
   +0x01a InfoMask         : 0x88 ''
   +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 : 0xffffc80b`ba32dc40 _OBJECT_CREATE_INFORMATION
   +0x020 QuotaBlockCharged : 0xffffc80b`ba32dc40 Void
   +0x028 SecurityDescriptor : 0xffffa30d`7cd0d369 Void
   +0x030 Body             : _QUAD
4: kd> ?? ((nt!_object_header*)0xffffc80bc92d7050)->TypeIndex
unsigned char 0x19 ''
4: kd> ?? ((nt!_object_type**)@@(nt!ObTypeIndexTable))[((nt!_object_header*)0xffffc80bc92d7050)->TypeIndex]
struct _OBJECT_TYPE * 0xffffc80b`b02d3980
   +0x000 TypeList         : _LIST_ENTRY [ 0xffffc80b`b02d3980 - 0xffffc80b`b02d3980 ]
   +0x010 Name             : _UNICODE_STRING "Desktop"
   +0x020 DefaultObject    : (null) 
   +0x028 Index            : 0x19 ''
   +0x02c TotalNumberOfObjects : 0xc
   +0x030 TotalNumberOfHandles : 0xf7
   +0x034 HighWaterNumberOfObjects : 0xd
   +0x038 HighWaterNumberOfHandles : 0xff
   +0x040 TypeInfo         : _OBJECT_TYPE_INITIALIZER
   +0x0b8 TypeLock         : _EX_PUSH_LOCK
   +0x0c0 Key              : 0x6b736544
   +0x0c8 CallbackList     : _LIST_ENTRY [ 0xffffc80b`b02d3a48 - 0xffffc80b`b02d3a48 ]
Improve this question
1
  • it is not a direct index in latest windows 10 it is a xorred with a cookie and another bit in the header that was introduced find nt!obHeaderCookie if i remebercorrect itshould be 0x6e for your case
    – blabb
    May 22, 2021 at 17:44

1 Answer 1

Reset to default
2

as i commented in latest windows type index has been randomised

it is a xor of the index with nt!obHeaderCookie and the second byte of OBJECT_HEADER Address

see below

0: kd> ?? (char *)@$proc->ImageFileName
char * 0xffffa083`398ab4d0
 "conhost.exe"
0: kd> ?? ((nt!_object_header *) @@masm( @$proc - @@c++(#FIELD_OFFSET(nt!_OBJECT_HEADER , Body))))->TypeIndex
unsigned char 0x58 'X'
0: kd> ? ((@$proc - @@c++(#FIELD_OFFSET(nt!_OBJECT_HEADER, Body))) >> 8 & 0xff)  ^ by(nt!ObHeaderCookie)
Evaluate expression: 95 = 00000000`0000005f
0: kd> ? 0x58 ^ 0x5f
Evaluate expression: 7 = 00000000`00000007 << Process 
0: kd>
Improve this answer
2
  • Is there an explanation behind why they did that?
    – caramel1995
    May 23, 2021 at 0:52
  • Not sure if you can expect an explanation for an implementation change in a closed source proprietory codebase but obviously it can be nothing better than obscurity through security model
    – blabb
    May 23, 2021 at 4:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.