Hello NTDEV,
I am working on some new functionality in my Windows debugging extension(for kernel targets) that deals with listing info about all objects on the system. I know how to traverse the Object Manager’s namespace, but am concerned that unnamed objects may not reside there. For instance, if I dump out the root directory, all I see are named objects. What about the unnamed ones, would they be listed directly under the root directory? Or should I be looking elsewhere? I would think that the Object Manager would keep one list to track all objects(both named and unnamed). Is this correct?
kd> !object e1000110
Object: e1000110 Type: (8a7a8330) Directory
ObjectHeader: e10000f8
HandleCount: 0 PointerCount: 40
Directory Object: 00000000 Name: \
269 symbolic links snapped through this directory
Hash Address Type Name
00 8a6aac10 Device Ntfs
e100d748 Directory ArcName
01 e1afae48 Port SeLsaCommandPort
03 e1011490 Key \REGISTRY
05 e1af86e8 Port ThemeApiPort
06 e2c0a5a0 Port XactSrvLpcPort
09 e1f57168 Directory NLS
10 e1008688 SymbolicLink DosDevices
13 e100fb88 Port SeRmCommandPort
14 8a6caa90 Device Dfs
e1a7a2a0 Port LsaAuthenticationPort
8a649888 Event LanmanServerAnnounceEvent
16 e1000388 Directory Driver
19 e100d670 Directory Device
20 e1e94828 Directory Windows
21 e1b85d50 Directory Sessions
8a6f1138 Event SAM_SERVICE_STARTED
22 e1f14340 Directory RPC Control
e1e9f1e8 Port SmApiPort
23 e1f0f488 Directory BaseNamedObjects
e10011c8 Directory KernelObjects
24 e176c288 Directory FileSystem
e1004460 Directory GLOBAL??
25 8a4a5750 WaitablePort NLAPublicPort
26 e21ca9d0 Port SmSsWinStationApiPort
e10010e0 Directory ObjectTypes
27 e100a550 Directory Security
8a270ff0 Event NETLOGON_SERVICE_STARTED
e20d4b20 Port ErrorLogPort
31 e100a450 SymbolicLink SystemRoot
8a07ea80 Device Cdfs
32 899e7c20 WaitablePort NLAPrivatePort
e1008540 Directory Callback
33 8a4c2d38 Event SeLsaInitEvent
8a649210 Event UniqueSessionIdEvent
35 e1f08510 Directory KnownDlls
I would appreciate any insights you may have.
Thanks,
Ron
> I would think that the Object Manager would keep one list to track all
objects(both named and unnamed). Is this correct?
Nope…
There is no such thing as a single object list. Furthermore, unless an appropriate flag (which is not specified by default) is explicitly specified in boot options, Object Manager does not maintain even an object type list.
Why??? Simply because Object Manager does not really need it - all necessary info (for example, pointer and handle reference count, as well as a pointer to the object’s security descriptor,etc) is available from the object header that is always always located immediately before the object’s body.
If you need object’s name, Object Manager can find it in one of 2 ways:
-
If NameInfo field of object header is non-zero, by substracting this value from the beginning of object header (it is either 16 or 32 bytes) you arrive to OBJECT_NAME structure that holds a pointer to object’s directory and UNICODE_STRING with object name.
-
Object header has a pointer to object type structure that describes and object of a given type.
This structure keeps a pointer to object initializer structure, and this structure keeps pointers to functions that may be invoked on a given object type (in fact, pretty much like methods in OO languages) - QueryName() is one of them. Therefore, by calling this function Object Manager can arrive to the name of an object. For example, this is how it works with file objects - QueryName()
gets its related DEVICE_OBJECT, and then obtains DEVICE_OBJECT’s name in a way explained in (1), because (the name is the same for both device and file objects.
Or should I be looking elsewhere?
As you must have already understood, there is no generic way of finding unnamed object - you can find it only via the list that is specific for all objects of a given type. For example, you can enumerate all DEVICE_OBJECTs by walking the list of all DRIVER_OBJECTs (this list is available via DRIVER_OBJECT’s undocumented DriverSection field), and enumerating all devices that every driver has created. Similarly, you can enumerate all ETHREADs, EPROCESSs, etc, but the way it can be done is specific for a given type of objects…
Anton Bassov
You can call ZwQuerySystemInformation with SystemObjectInformation class
which returns objects in the system. But this functionality relies on
objects being registered in a linked list which Anton also explained, this
only works if the MaintainTypeList field in the OBJECT_TYPE_INITIALIZER
structure is set to true. This type initializer structure is a per object
type structure which has effect on all objects of the same type. By default
this is set to true only for certain types of objects, you can enable this
functionality for all object types by enabling a global flags (a registry
setting which requires a reboot) but this may bring along a memory and
performance impact.
Note that changing type initializers manually is not allowed anymore on
Vista x64 because of the infamous Patchguard. The global flag trick may work
but you are likely not allowed to touch or change anything else. This should
not be a problem on any previous version of Windows including XP x64
edition.
There are many other ways to find about the existence of objects but they
are all type specific, they will not work as one generic way to find objects
of every type.
/Daniel
wrote in message news:xxxxx@ntdev…
> Hello NTDEV,
>
> I am working on some new functionality in my Windows debugging
> extension(for kernel targets) that deals with listing info about all
> objects on the system. I know how to traverse the Object Manager’s
> namespace, but am concerned that unnamed objects may not reside there.
> For instance, if I dump out the root directory, all I see are named
> objects. What about the unnamed ones, would they be listed directly under
> the root directory? Or should I be looking elsewhere? I would think that
> the Object Manager would keep one list to track all objects(both named and
> unnamed). Is this correct?
>
> kd> !object e1000110
> Object: e1000110 Type: (8a7a8330) Directory
> ObjectHeader: e10000f8
> HandleCount: 0 PointerCount: 40
> Directory Object: 00000000 Name: <br>> 269 symbolic links snapped through this directory
>
> Hash Address Type Name
> ---- ------- ---- ----
> 00 8a6aac10 Device Ntfs
> e100d748 Directory ArcName
> 01 e1afae48 Port SeLsaCommandPort
> 03 e1011490 Key \REGISTRY
> 05 e1af86e8 Port ThemeApiPort
> 06 e2c0a5a0 Port XactSrvLpcPort
> 09 e1f57168 Directory NLS
> 10 e1008688 SymbolicLink DosDevices
> 13 e100fb88 Port SeRmCommandPort
> 14 8a6caa90 Device Dfs
> e1a7a2a0 Port LsaAuthenticationPort
> 8a649888 Event LanmanServerAnnounceEvent
> 16 e1000388 Directory Driver
> 19 e100d670 Directory Device
> 20 e1e94828 Directory Windows
> 21 e1b85d50 Directory Sessions
> 8a6f1138 Event SAM_SERVICE_STARTED
> 22 e1f14340 Directory RPC Control
> e1e9f1e8 Port SmApiPort
> 23 e1f0f488 Directory BaseNamedObjects
> e10011c8 Directory KernelObjects
> 24 e176c288 Directory FileSystem
> e1004460 Directory GLOBAL??
> 25 8a4a5750 WaitablePort NLAPublicPort
> 26 e21ca9d0 Port SmSsWinStationApiPort
> e10010e0 Directory ObjectTypes
> 27 e100a550 Directory Security
> 8a270ff0 Event NETLOGON_SERVICE_STARTED
> e20d4b20 Port ErrorLogPort
> 31 e100a450 SymbolicLink SystemRoot
> 8a07ea80 Device Cdfs
> 32 899e7c20 WaitablePort NLAPrivatePort
> e1008540 Directory Callback
> 33 8a4c2d38 Event SeLsaInitEvent
> 8a649210 Event UniqueSessionIdEvent
> 35 e1f08510 Directory KnownDlls
>
>
> I would appreciate any insights you may have.
>
> Thanks,
>
> Ron
>
>
> Note that changing type initializers manually is not allowed anymore on
Vista x64 because of the infamous Patchguard.
Actually, changing MaintainTypeList field in the OBJECT_TYPE_INITIALIZER structure alone is not going to lead you anywhere (probably, apart from BSOD) unless FLG_MAINTAIN_OBJECT_TYPELIST in GlobalFlags is enabled. Why? Look - let’s say you have set it to TRUE. What happens to all objects of a given type that have been created before you have changed MaintainTypeList field??? They are not going to turn up on the list, are they??? Therefore, in order for this step to be meaningfull, it has to be done *before* any objects of a given type are created, and objects of most types (device,driver, ETHREAD,etc) get created before your driver is loaded. Therefore, in practical terms, this step is *at the very best* meaningless - in fact, I don’t exclude the possibility that the system may “misunderstand” this bold move and show you a blue screen even on a 32-bit system, despite the lack of PatchGuard…
Anton Bassov
Sure this is not going to help reveal objects created in the past. What I
wanted to mention in general is that writing to type initializers is not
anymore allowed from Vista x64 on.
/Daniel
wrote in message news:xxxxx@ntdev…
>> Note that changing type initializers manually is not allowed anymore on
>> Vista x64 because of the infamous Patchguard.
>
> Actually, changing MaintainTypeList field in the OBJECT_TYPE_INITIALIZER
> structure alone is not going to lead you anywhere (probably, apart from
> BSOD) unless FLG_MAINTAIN_OBJECT_TYPELIST in GlobalFlags is enabled. Why?
> Look - let’s say you have set it to TRUE. What happens to all objects of a
> given type that have been created before you have changed MaintainTypeList
> field??? They are not going to turn up on the list, are they??? Therefore,
> in order for this step to be meaningfull, it has to be done before any
> objects of a given type are created, and objects of most types
> (device,driver, ETHREAD,etc) get created before your driver is loaded.
> Therefore, in practical terms, this step is at the very best
> meaningless - in fact, I don’t exclude the possibility that the system may
> “misunderstand” this bold move and show you a blue screen even on a 32-bit
> system, despite the lack of PatchGuard…
>
>
> Anton Bassov
>
>
If I recall correctly, the dev is writing a WinDbg extension. If so, then PatchGuard should not be an issue, as it is disabled when there is a kd connection.
mm
That’s correct, it is a debugging extension. I had only planned to gather data about waitable objects, so I’ll just traverse the wait blocks for every thread running in every process(since there’s no master object list).
Thanks for the info,
Ron
Date: Sat, 22 Sep 2007 17:13:55 -0400> From: xxxxx@evitechnology.com> To: xxxxx@lists.osr.com> Subject: RE:[ntdev] Where to find the Object Manager’s list of all objects> > If I recall correctly, the dev is writing a WinDbg extension. If so, then PatchGuard should not be an issue, as it is disabled when there is a kd connection.> > mm > > —> NTDEV is sponsored by OSR> > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars\> > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Can you find the hidden words?? Take a break and play Seekadoo!
http://club.live.com/seekadoo.aspx?icid=seek_wlmailtextlink
wrote in message news:xxxxx@ntdev…
> If I recall correctly, the dev is writing a WinDbg extension. If so, then
> PatchGuard should not be an issue, as it is disabled when there is a kd
> connection.
>
If that were true it would create a lot of confusion and probably a very
useful security hole.
/Daniel
There is a master object list but you need to enable it first. Start the gflags.exe utility from your windbg installation directory and select ‘maintain a list of objects for each type’ and reboot.
/Daniel
“Ronald Riddle” wrote in message news:xxxxx@ntdev…
That’s correct, it is a debugging extension. I had only planned to gather data about waitable objects, so I’ll just traverse the wait blocks for every thread running in every process(since there’s no master object list).
Thanks for the info,
Ron
> Date: Sat, 22 Sep 2007 17:13:55 -0400
> From: xxxxx@evitechnology.com
> To: xxxxx@lists.osr.com
> Subject: RE:[ntdev] Where to find the Object Manager’s list of all objects
>
> If I recall correctly, the dev is writing a WinDbg extension. If so, then PatchGuard should not be an issue, as it is disabled when there is a kd connection.
>
> mm
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
------------------------------------------------------------------------------
Can you find the hidden words? Take a break and play Seekadoo! Play now!
>> PatchGuard should not be an issue, as it is disabled when there is a kd connection.
If that were true it would create a lot of confusion and probably a very useful security hole.
Actually, Martin’s statement is absolutely correct - it is well-known fact that PatchGuard is disabled when kernel debugger is around. If kernel debugger was not allowed to modify kernel memory, how on Earth would you set a breakpoint on execution of some given ntoskrnl.exe’s export??? It never occured to you to think this way??? Therefore, I really don’t know what you are arguing about…
Anton Bassov
Sorry, checking the docs, it appears you are righ and I was spreading wrong
information. I assumed Patchguard would know its way around the debugger. In
any case it looks like lots of things are still not allowed or Patchguard is
only partially disabled. I have witnessed lots of 0x109 bugchecks and they
are not caused by some memory corruption, they came as soon as I crossed
some Patchguard observed border and I always had the debugger attached. I
will look into this deeper as it leaves me with many questions.
/Daniel
wrote in message news:xxxxx@ntdev…
> Actually, Martin’s statement is absolutely correct - it is well-known fact
> that PatchGuard is disabled when kernel debugger is around. If kernel
> debugger was not allowed to modify kernel memory, how on Earth would you
> set a breakpoint on execution of some given ntoskrnl.exe’s export??? It
> never occured to you to think this way??? Therefore, I really don’t know
> what you are arguing about…
>
In addition to the reasons that Anton cited, presumably one other reason that PatchGuard is disabled when there is a KD connection is to prevent reverse engineering it. While I certainly can not make any statement about this necessarily being the case, I would say there is some circumstantial evidence in that the mechanism that enables/disables it is certainly obfuscated. I can’t say that I have seen any evidence of residual PatchGuard activity with a KD attached, and I think the obfuscation is a good reason why there wouldn’t be, but you never know.
Thanks Daniel, but I would like the debugging extension to work for customer dump files too(i.e. where I may not be able to enable the master list before hand). I think have an alternative now.
Thanks all, for the replies.
Ron
From: xxxxx@resplendence.comSubject: Re:[ntdev] Where to find the Object Manager’s list of all objectsDate: Sun, 23 Sep 2007 09:00:57 +0200To: xxxxx@lists.osr.com
There is a master object list but you need to enable it first. Start the gflags.exe utility from your windbg installation directory and select ‘maintain a list of objects for each type’ and reboot.
/Daniel
“Ronald Riddle” wrote in message news:xxxxx@ntdev…That’s correct, it is a debugging extension. I had only planned to gather data about waitable objects, so I’ll just traverse the wait blocks for every thread running in every process(since there’s no master object list). Thanks for the info, Ron > Date: Sat, 22 Sep 2007 17:13:55 -0400> From: xxxxx@evitechnology.com> To: xxxxx@lists.osr.com> Subject: RE:[ntdev] Where to find the Object Manager’s list of all objects> > If I recall correctly, the dev is writing a WinDbg extension. If so, then PatchGuard should not be an issue, as it is disabled when there is a kd connection.> > mm > > —> NTDEV is sponsored by OSR> > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars> > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Can you find the hidden words? Take a break and play Seekadoo! Play now! — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
_________________________________________________________________
Gear up for Halo? 3 with free downloads and an exclusive offer. It?s our way of saying thanks for using Windows Live?.
http://gethalo3gear.com?ocid=SeptemberWLHalo3_WLHMTxt_2
Martin,
In addition to the reasons that Anton cited, presumably one other reason that
PatchGuard is disabled when there is a KD connection is to prevent reverse
engineering it.
Actually, I heard that Authentium developed a working method to bypass PatchGuard (that’s in addition to 3 well-known documents by Skape and Skywing on uninformed.org). Therefore, prevention of reverse engineering does not really lead MSFT anywhere. What they can do to annoy
those who attempt to disable PatchGuard is to change the “protection” (I intentionally put this word in quotation marks) scheme all the time, and install the update on the target machine behind the scenes whenever the user connects to the Internet (not really a cricket, but I would not get surprized at all -after all, this is MSFT)…
Anton Bassov