A real puzzle about Regmon( win98 version)?

NTDEV
1

Hello all,

When windows open a key, it calls RegOpenKey(Ex) or RegCreateKey(Ex).

Now I want to know the exact key, for example
“HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSec”, which is
opened by Windows.

In win98, I hook some system services including RegOpenKey and
RegCreateKey. (By the way, it seems that there is NO way to hook
RegOpenKeyEx and RegCreateKeyEx in win98?)

The prototype of RegOpenKey is:

LONG RegOpenKey(
HKEY hKey,
LPCTSTR lpSubKey,
PHKEY phkResult
);

I can get the full key path by strcat hKey and lpSubKey. But sometimes
hKey is just a HANDLE not the predefined
keys(HKEY_CLASSES_ROOT,HKEY_CURRENT_CONFIG,HKEY_CURRENT_USER,HKEY_LOCAL_MACH
INE,HKEY_USERS)

I do NOT know the way to translate the Handle to the key path.
Forturnately, I find Regmon can do it. And I ask Mr.Mark Russinovich for
help, but he told me “I am really busy, so…”. Now I fell in the puzzle
hole.

Anyone could give me some tips here?

Anthony

2

Anthony:

In win98, I hook some system services including RegOpenKey and
RegCreateKey. (By the way, it seems that there is NO way to hook
RegOpenKeyEx and RegCreateKeyEx in win98?)

From my experience there is no need to worry about hooking
RegOpenKeyEx/RegCreateKeyEx.

I can get the full key path by strcat hKey and lpSubKey. But sometimes
hKey is just a HANDLE not the predefined
keys(HKEY_CLASSES_ROOT,HKEY_CURRENT_CONFIG,HKEY_CURRENT_USER,HKEY_
LOCAL_MACH
INE,HKEY_USERS)

The reason you are seeing RegOpenKey called with an hKey that does not match
one of the root hives is because of the fact that you can use the resultant
HKEY from RegOpenKey and RegCreateKey as the root HKEY, like the root hives,
for further RegOpenKey/RegCreateKey calls.

Example snippet:

HKEY key, subKey;

RegOpenKey(HKEY_LOCAL_MACHINE, “System\CurrentControlSet\Services\IPSec”,
&key);
RegOpenKey(key, “Security”, &subKey);

I do NOT know the way to translate the Handle to the key path.
Forturnately, I find Regmon can do it. And I ask Mr.Mark Russinovich for
help, but he told me “I am really busy, so…”. Now I fell in the puzzle
hole.

There are a few ways to translate the HKEY to a path. The easiest is likely
to be making use of a hash that translates an HKEY, since HKEY’s are
globally unique, into its full ASCII path.

This requires you to do something a little more fancy in that you have to be
able to save the resultant HKEY from calls to RegOpenKey and RegCreateKey in
order to insert them into the hash.

When you insert them into the hash you simply use the hash to resolve the
ASCII name of the root HKEY (the first parameter to RegOpenKey/RegCreateKey)
and concatenate that with the base key (the second parameter to
RegOpenKey/RegCreateKey).

Finally, when RegCloseKey is called you should remove the provided HKEY from
the hash. You have to be careful here, though. Sometimes applications are
written poorly and try to close the root hives.

Hope that helps. I’m pretty sure this is the method that regmon uses on
Windows 9x.

Matt

3

> The reason you are seeing RegOpenKey called with an hKey that does not
match

one of the root hives is because of the fact that you can use the
resultant
HKEY from RegOpenKey and RegCreateKey as the root HKEY, like the root
hives,
for further RegOpenKey/RegCreateKey calls.

Example snippet:

HKEY key, subKey;

RegOpenKey(HKEY_LOCAL_MACHINE,
“System\CurrentControlSet\Services\IPSec”,
&key);
RegOpenKey(key, “Security”, &subKey);

> I do NOT know the way to translate the Handle to the key path.
> Forturnately, I find Regmon can do it. And I ask Mr.Mark Russinovich for
> help, but he told me “I am really busy, so…”. Now I fell in the puzzle
> hole.

There are a few ways to translate the HKEY to a path. The easiest is
likely
to be making use of a hash that translates an HKEY, since HKEY’s are
globally unique, into its full ASCII path.

Thax.
But I am NOT sure about your comment — “HKEY’s are globally unique.”.

HKEY key, subKey;
RegOpenKey(HKEY_LOCAL_MACHINE, “System\CurrentControlSet\Services\IPSec”,
&key);
RegOpenKey(key, “Security”, &subKey);

For example, two processes open “System\CurrentControlSet\Services\IPSec”
at the same time. The returned key must be different values.

Moreover, it seems I have to record ALL of the RegOpenKey calls to build
HKEY — LPSTR matrix. Whenever the HKEY is NOT one of the root hives, I
have to go through the matrix to rebuild certain HKEY–LPSTR. Is it right?
If so, I can’t imagine the code efficient, never forget WINDOWS is built on
Regitry.

In Win2k or winXP, by calling “ObQueryNameString” maybe can resolve it. So I
want to fhind certain magic CALL in win98(DDK or vtools).

Any more comment is deeply welcome!

Anthony

4

This works so long as all the keys you’re interested in are opened after
the hooks are in place. One would have to be prepared for the case that
some keys may be opened before the hooks are in place, and therefore the
paths of those keys cannot be known. One would also have to handle the
case of key handle duplication, e.g. via RegOpenKeyEx().

Chuck

----- Original Message -----
From: “Matt Miller”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, February 17, 2004 10:51 PM
Subject: RE: [ntdev] A real puzzle about Regmon( win98 version)?

> Anthony:
>
> > In win98, I hook some system services including RegOpenKey and
> > RegCreateKey. (By the way, it seems that there is NO way to hook
> > RegOpenKeyEx and RegCreateKeyEx in win98?)
>
> >From my experience there is no need to worry about hooking
> RegOpenKeyEx/RegCreateKeyEx.
>
> > I can get the full key path by strcat hKey and lpSubKey. But
sometimes
> > hKey is just a HANDLE not the predefined
> > keys(HKEY_CLASSES_ROOT,HKEY_CURRENT_CONFIG,HKEY_CURRENT_USER,HKEY_
> > LOCAL_MACH
> > INE,HKEY_USERS)
>
> The reason you are seeing RegOpenKey called with an hKey that does not
match
> one of the root hives is because of the fact that you can use the
resultant
> HKEY from RegOpenKey and RegCreateKey as the root HKEY, like the root
hives,
> for further RegOpenKey/RegCreateKey calls.
>
> Example snippet:
>
> HKEY key, subKey;
>
> RegOpenKey(HKEY_LOCAL_MACHINE,
“System\CurrentControlSet\Services\IPSec”,
> &key);
> RegOpenKey(key, “Security”, &subKey);
>
> > I do NOT know the way to translate the Handle to the key path.
> > Forturnately, I find Regmon can do it. And I ask Mr.Mark Russinovich
for
> > help, but he told me “I am really busy, so…”. Now I fell in the
puzzle
> > hole.
>
> There are a few ways to translate the HKEY to a path. The easiest is
likely
> to be making use of a hash that translates an HKEY, since HKEY’s are
> globally unique, into its full ASCII path.
>
> This requires you to do something a little more fancy in that you have
to be
> able to save the resultant HKEY from calls to RegOpenKey and
RegCreateKey in
> order to insert them into the hash.
>
> When you insert them into the hash you simply use the hash to resolve
the
> ASCII name of the root HKEY (the first parameter to
RegOpenKey/RegCreateKey)
> and concatenate that with the base key (the second parameter to
> RegOpenKey/RegCreateKey).
>
> Finally, when RegCloseKey is called you should remove the provided
HKEY from
> the hash. You have to be careful here, though. Sometimes
applications are
> written poorly and try to close the root hives.
>
> Hope that helps. I’m pretty sure this is the method that regmon uses
on
> Windows 9x.
>
> Matt
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@cbatson.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

5

> For example, two processes open
“System\CurrentControlSet\Services\IPSec”

at the same time. The returned key must be different values.

That’s exactly what “globally unique” means.

Moreover, it seems I have to record ALL of the RegOpenKey calls to
build
HKEY — LPSTR matrix. Whenever the HKEY is NOT one of the root hives,
I
have to go through the matrix to rebuild certain HKEY–LPSTR. Is it
right?
If so, I can’t imagine the code efficient, never forget WINDOWS is
built on
Regitry.

Why would it not be efficient? Just an associative array look-up to
translate a key handle to a path. Should take no more than O(log n)
time.

Chuck

6

“Chuck Batson” ??? news:xxxxx@ntdev…
> This works so long as all the keys you’re interested in are opened after
> the hooks are in place. One would have to be prepared for the case that
> some keys may be opened before the hooks are in place, and therefore the
> paths of those keys cannot be known. One would also have to handle the
> case of key handle duplication, e.g. via RegOpenKeyEx().
>
> Chuck
>

Pretty right --“some keys may be opened before the hooks are in place”. Then
how to translate this handle the a readable path?

7

On Tue, 2004-02-17 at 20:52, Chuck Batson wrote:

> If so, I can’t imagine the code efficient, never forget WINDOWS is
built on
> Regitry.

Why would it not be efficient? Just an associative array look-up to
translate a key handle to a path. Should take no more than O(log n)
time.

You can do even better in the average case with a decent hash table, if
you give it enough memory and a good enough hash function to work with.
Maybe do a binary search inside each bucket. Insertion is a little slow
(O(n) where n = number of items in each bucket, plus hashing time), but
as you add buckets, this impact drops fast. You should be able to get
info on this in any basic data structures book…

In practice: try running regmon; it’s not that bad.

-sd

8

> Pretty right --"some keys may be opened before the hooks are in

place". Then
how to translate this handle the a readable path?

If you notice that when running regmon on Windows 9x it will occassionaly
prepend the handle to the front of the base key name. This is because it
could not resolve it in its hash table due to the fact that the key was
opened before regmon hooked the registry functions.

If you do some hacking you may be able to figure out a way around this, but
depending on your needs this may functionality may or may not be acceptable.
Keep in mind that you can control the load order of your driver thus making
it less probable that you will run into un-resolvable keys.

Matt

(PS: The regmon observations were from older versions, but I’m assuming they
still apply to any newer ones.)

9

“Matt Miller” ??? news:xxxxx@ntdev…

> If you notice that when running regmon on Windows 9x it will occassionaly
> prepend the handle to the front of the base key name. This is because it
> could not resolve it in its hash table due to the fact that the key was
> opened before regmon hooked the registry functions.

If you run the latest Regmon, you will find everything is fine. The author
has fixed it in regmon(win98).

So there must be some ways to do it. I just wonder this technology. Of coz,
I can build a hash bucket, but I want to find a much easier way to do it.

> If you do some hacking you may be able to figure out a way around this,
but
> depending on your needs this may functionality may or may not be
acceptable.
> Keep in mind that you can control the load order of your driver thus
making
> it less probable that you will run into un-resolvable keys.
>

"control the load order of your driver " maybe it will work. But I trace
advapi.dll by Softice in win98. I find system call RegOpenKeyEx and
RegCreateKeyEx sometimes. So it maybe useless to just watch RegOpenKey and
RegCreateKey. If a key is opened by RegOpenKeyEx, what I will do? What I can
do!

> (PS: The regmon observations were from older versions, but I’m assuming
they
> still apply to any newer ones.)
>
>

Thax for your help.