Referencing a RegKey Object from handle

NTDEV
1

I need to take a reference to a Key object to insure there is no Object name
removal until I deref the object. It’s trivial to use ObReferenceObjectByHandle
for other ObjectTypes (i.e. MmSectionObjectType, IoAdapterObjectType) that are
exported from the kernel, but how to get a reference to a RegKey Object?

The only suggestion I’ve had to find the CmpRegObjectType address is to look in
the Object Header, but this seems like a chicken-and-egg problem, since the only
way I see to get an object pointer so I can use it’s header needs the ObjectType
(CmpRegObjectType) in the function call.

Any suggestions? I don’t mind a “grey-documented” solution as long as it’s not
a hack like scanning memory for some bit pattern.

TIA

Jerry

2

From what I understood… why dont you use ObReferenceObjectByHandle?,
“ObjectType
Pointer to the object type. ObjectType can be either *IoFileObjectType or *ExEventObjectType. This parameter can also be NULL if
AccessMode is KernelMode.”

ObjectType = 0, and AccessMode = KernelMode

To validate if the object is really a key you can try use some Registry function with the handle (REGMON does that)
and validate its status returned, or use the undocumented ZwQueryObject.

Funny in DDK they say:
"[Failure to validate Object Handles] (…)
To avoid such problems, a driver should check for valid data, as follows:

  • Check the object type to make sure it is what the driver expects.(…)"
    But they dont say how to do this…

Dunno if thats what you looking for…

Jean F.

“Jerry Schneider” wrote in message news:xxxxx@ntdev…
I need to take a reference to a Key object to insure there is no Object name
removal until I deref the object. It’s trivial to use ObReferenceObjectByHandle
for other ObjectTypes (i.e. MmSectionObjectType, IoAdapterObjectType) that are
exported from the kernel, but how to get a reference to a RegKey Object?

The only suggestion I’ve had to find the CmpRegObjectType address is to look in
the Object Header, but this seems like a chicken-and-egg problem, since the only
way I see to get an object pointer so I can use it’s header needs the ObjectType
(CmpRegObjectType) in the function call.

Any suggestions? I don’t mind a “grey-documented” solution as long as it’s not
a hack like scanning memory for some bit pattern.

TIA

Jerry

3

Use undocumented means of getting the KeyObjectType, like
ZwOpenKey+ObReferenceObjectByHandle+digging into the undocumented object
header. It holds a type pointer.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Jean F.”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Friday, August 05, 2005 5:05 PM
Subject: Re:[ntdev] Referencing a RegKey Object from handle

> From what I understood… why dont you use ObReferenceObjectByHandle?,
> “ObjectType
> Pointer to the object type. ObjectType can be either *IoFileObjectType or
*ExEventObjectType. This parameter can also be NULL if
> AccessMode is KernelMode.”
>
> ObjectType = 0, and AccessMode = KernelMode
>
> To validate if the object is really a key you can try use some Registry
function with the handle (REGMON does that)
> and validate its status returned, or use the undocumented ZwQueryObject.
>
> Funny in DDK they say:
> “[Failure to validate Object Handles] (…)
> To avoid such problems, a driver should check for valid data, as follows:
> - Check the object type to make sure it is what the driver expects.(…)”
> But they dont say how to do this…
>
> Dunno if thats what you looking for…
>
> Jean F.
>
> ----
> “Jerry Schneider” wrote in message news:xxxxx@ntdev…
> I need to take a reference to a Key object to insure there is no Object name
> removal until I deref the object. It’s trivial to use
ObReferenceObjectByHandle
> for other ObjectTypes (i.e. MmSectionObjectType, IoAdapterObjectType) that
are
> exported from the kernel, but how to get a reference to a RegKey Object?
>
> The only suggestion I’ve had to find the CmpRegObjectType address is to look
in
> the Object Header, but this seems like a chicken-and-egg problem, since the
only
> way I see to get an object pointer so I can use it’s header needs the
ObjectType
> (CmpRegObjectType) in the function call.
>
> Any suggestions? I don’t mind a “grey-documented” solution as long as it’s
not
> a hack like scanning memory for some bit pattern.
>
> TIA
>
> Jerry
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

4

Will you also install the new binary when the customer upgrades server X
from NT build N to N+1, and the machine bugchecks on boot because your
driver is now doing the wrong thing? Will you document the fragility of
your driver – will you tell your customer? Will you check the OS version
in DriverEntry and refuse to start if you are not running on the OS that you
reverse engineered? Can you guarantee that OS patches don’t alter the
behavior or data structures you are relying on?

Verifying that this particular object pointer is a registry key.

This was already discussed, and there are easy and reliable ways to
accomplish this. Peeking into the object header is not necessary.

Issues like this are the difference between software *engineering* and just
*programming*.

– arlie

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Monday, August 08, 2005 12:09 PM
To: Windows System Software Devs Interest List
Subject: SPAM-LOW: Re: SPAM-LOW: Re: SPAM-LOW: Re: SPAM-LOW: Re: Re:[ntdev]
Referencing a RegKey Object from handle

I can’t believe this is even up for discussion.

It hasn’t changed – YET. Do you want to bet on it never changing?
Do you want to bet on [random data structure X] never changing?

OK, I will create the new build of the binary to support the next Windows
version :slight_smile: is this bad?

Show me a solid example of a *common* problem that you simply cannot
solve without relying on undocumented structures.

Verifying that this particular object pointer is a registry key.

BTW - using undocumented functions seems to be absolutely fine in most
cases (especially in the cases when any other way is too complex).

For instance, PsLookupProcessByProcessId never changed since NT4. Some of
these functions are documented in IFS kit :slight_smile: why not copy-paste this
definition from the IFS kit to my own source and build it? or just require
ntifs.h for building?

Sometimes using the undocumented stuff is really bad. NDIS internals, for
instance, or EPROCESS - it is too huge and thus changes from SP to SP.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@stonestreetone.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

5

— “Maxim S. Shatskih”
wrote:

> > I can’t believe this is even up for discussion.
> >
> > It hasn’t changed – YET. Do you want to bet on
> it never changing? Do you
> > want to bet on [random data structure X] never
> changing?
>
> OK, I will create the new build of the binary to
> support the next Windows
> version :slight_smile: is this bad?

Depends on the volume and your customer. Believe me,
that really sucks if your clients are some major PC
OEMs (not to name them). At least, warn them you’ve
used such a hack and see if they agree with you.
otherwise, they can be VERY VERY NASTY on your company
when they received mass amount of support calls for
this. Do this a couple of times may effectively get
yourself out of business, easily.

Calvin Guan (Windows DDK MVP)
NetXtreme Longhorn Miniport Prime
Broadcom Corp. www.broadcom.com

__________________________________________________________
Find your next car at http://autos.yahoo.ca

6

Any chances that OBJECT_HEADER will change? Very, very minor.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Arlie Davis”
To: “Windows System Software Devs Interest List”
Sent: Monday, August 08, 2005 8:48 PM
Subject: Re:[ntdev] Referencing a RegKey Object from handle

> Will you also install the new binary when the customer upgrades server X
> from NT build N to N+1, and the machine bugchecks on boot because your
> driver is now doing the wrong thing? Will you document the fragility of
> your driver – will you tell your customer? Will you check the OS version
> in DriverEntry and refuse to start if you are not running on the OS that you
> reverse engineered? Can you guarantee that OS patches don’t alter the
> behavior or data structures you are relying on?
>
> >Verifying that this particular object pointer is a registry key.
>
> This was already discussed, and there are easy and reliable ways to
> accomplish this. Peeking into the object header is not necessary.
>
> Issues like this are the difference between software engineering and just
> programming.
>
> – arlie
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
> Sent: Monday, August 08, 2005 12:09 PM
> To: Windows System Software Devs Interest List
> Subject: SPAM-LOW: Re: SPAM-LOW: Re: SPAM-LOW: Re: SPAM-LOW: Re: Re:[ntdev]
> Referencing a RegKey Object from handle
>
> > I can’t believe this is even up for discussion.
> >
> > It hasn’t changed – YET. Do you want to bet on it never changing?
> > Do you want to bet on [random data structure X] never changing?
>
> OK, I will create the new build of the binary to support the next Windows
> version :slight_smile: is this bad?
>
> > Show me a solid example of a common problem that you simply cannot
> > solve without relying on undocumented structures.
>
> Verifying that this particular object pointer is a registry key.
>
> BTW - using undocumented functions seems to be absolutely fine in most
> cases (especially in the cases when any other way is too complex).
>
> For instance, PsLookupProcessByProcessId never changed since NT4. Some of
> these functions are documented in IFS kit :slight_smile: why not copy-paste this
> definition from the IFS kit to my own source and build it? or just require
> ntifs.h for building?
>
> Sometimes using the undocumented stuff is really bad. NDIS internals, for
> instance, or EPROCESS - it is too huge and thus changes from SP to SP.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@stonestreetone.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

7

But not zero, and you provide absolutely no protection for your clients
if/when the change does occur.

And again, you have not provided any evidence that you *need* direct access
to the object header. Everything in object header is exposed through
documented, supported APIs, all of which give an indication of what sort of
semantic change you want to occur (such as changing the reference count on
an object).

Do you think data encapsulation is a bad thing? Should the DDK just be a
list of #defines of variable addresses?

– arlie

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Monday, August 08, 2005 2:15 PM
To: Windows System Software Devs Interest List
Subject: SPAM-LOW: Re: Re:[ntdev] Referencing a RegKey Object from handle

Any chances that OBJECT_HEADER will change? Very, very minor.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

8

Not everything. For example, the reference count on the object is not
available. The usual trick I’ve seen used is to call
ObReferenceObject/ObDereferenceObject, which are documented as VOID
functions in the DDK but actually return LONG_PTR values (side note: I
actually logged a bug against the DDK documentation and was told that
they wouldn’t fix it because the developer didn’t want to tell people
what the meaning of the values returned by these functions was!)

Sometimes some of this information is obscured and results in bugs,
which is not a good thing (but not justification for using undocumented
features). For example, a general rule here is that inside a filter you
should NOT call ObReferenceObject and ObDereferenceObject in the
IRP_MJ_CLEANUP handler before passing the request to the underlying
driver - that triggers the IRP_MJ_CLOSE call!

But the bottom line is: if you can do it in a documented and supported
fashion, do it that way. If you have no choice, log a bug. If you
can’t wait for a bug fix, fix it and make damned sure you handle the
failure case gracefully (refuse to load, disable your functionality, log
a nice message, send an e-mail to yourself, whatever…)

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Arlie Davis
Sent: Monday, August 08, 2005 2:30 PM
To: ntdev redirect
Subject: Re:[ntdev] Referencing a RegKey Object from handle

But not zero, and you provide absolutely no protection for your clients
if/when the change does occur.

And again, you have not provided any evidence that you *need* direct
access
to the object header. Everything in object header is exposed through
documented, supported APIs, all of which give an indication of what sort
of
semantic change you want to occur (such as changing the reference count
on
an object).

Do you think data encapsulation is a bad thing? Should the DDK just be
a
list of #defines of variable addresses?

– arlie

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
Shatskih
Sent: Monday, August 08, 2005 2:15 PM
To: Windows System Software Devs Interest List
Subject: SPAM-LOW: Re: Re:[ntdev] Referencing a RegKey Object from
handle

Any chances that OBJECT_HEADER will change? Very, very minor.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

9

>But the bottom line is: if you can do it in a documented and supported

fashion, do it that way.

Exactly.

Sorry, I was wrong in the original response in this thread - using
ObOpenObjectByPointer+ZwQueryKey+ZwClose on the suspicious object pointer
allows us to avoid digging inside the OBJECT_HEADER.

If you have no choice, log a bug. If you
can’t wait for a bug fix, fix it and make damned sure you handle the
failure case gracefully

Exactly. With such a thing, lots of validation checks are a good idea.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

10

> But not zero, and you provide absolutely no protection for your clients

if/when the change does occur.

If I would do this - I would a) wrap this into the OS version check b) do
several steps of data validation including things like __try/__catch on PASSIVE
or MmIsAddressValid on DISPATCH, and try to gracefully degrade if something
will be wrong.

BTW - do you know how to get the EXE filename of the current process without
using undocumented things? what about the full path to EXE? with such a task,
we have a sad choice of either digging into the undocumented structures or
hooking the syscalls (NtCreateSection and NtCreateProcess).

It is very, very interesting how the SP2’s firewall does this. Maybe this is
undocumented too :slight_smile:

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com