(imported topic written by SystemAdmin)
How about adding pathname so we can use it against registry keys?
See http://forum.bigfix.com/viewtopic.php?pid=4377
-Paul
(imported comment written by BenKus)
Hey Paul,
I have been asking for years for this… but after extensive research, we have found that there really isn’t any reasonable way to do this because the underlying Windows registry APIs don’t support it. The problems appear because of all the weird mirroring and redirection that the registry does.
Maybe we can check it out again soon, but I continue to occasionally run into this problem and wish there was some way to get the path of a registry key.
Ben
(imported comment written by SystemAdmin)
I wonder if it’s just a case that at the moment of examining the registry key, it’s really just an open key using RegOpenKey() or RegOpenKeyEx(). I don’t see an API either for getting the full path, or enumerating back to the parent.
I’d suspect the only way to do it is either (1) track it internally rather than via an API, or (2) hook the OS to monitor the registry access, much like SysInternals’ RegMon.
Paul
(imported comment written by SystemAdmin)
FYI…
After Google’ing for a few nights, this might be in the right direction to get the path…
http://msdn2.microsoft.com/en-us/library/ms804350.aspx
-Paul
(imported comment written by SystemAdmin)
Hi Paul,
I took a quick peek at that documentation and didn’t immediately see anything that looked like it returned the full path. In any case, it looks like that’s a kernel-mode API, which wouldn’t be accessible from a user-mode application like the BES client anyway.
The issue with registry paths is that not every registry key necessarily has a unique path or even a path at all. To give you a few examples:
When working with the HKEY_CLASSES_ROOT branch of the registry, Windows is actually providing a merged view of the HKEY_LOCAL_MACHINE\Software\Classes and HKEY_CURRENT_USER\Software\Classes branches. Any apparent HKEY_CLASSES_ROOT path is actually a path to one of these branches.
Under WOW64, the compatibility mode for 32-bit applications running on a 64-bit OS, accesses to certain registry keys are transparently redirected to a different location in the registry (see http://msdn2.microsoft.com/en-us/library/aa384235.aspx). As the BES client is a 32-bit process, the path of these registry keys is ambiguous – should it be the actual redirected path or the pre-redirection path?
The RegOpenCurrentUser API retrieves a handle to the HKEY_CURRENT_USER key for the user the current thread is impersonating (BES 7.0 provides a new inspector that uses this API). Because RegOpenCurrentUser provides access to the HKEY_CURRENT_USER branch for
other
users, rather than the current HKEY_CURRENT_USER branch, the keys it returns don’t even really have a path.
Because of these complexities and the fact that the Win32 API doesn’t try to provide this functionality either, we elected not to provide it in the relevance language directly.
John
(imported comment written by SystemAdmin)
Hey John…
Eliminating the possibility of asking the OS to return some path to an open hKey, couldn’t this be something manually tracked within the BES client itself?
As each “of key” is evaluated, couldn’t the BES client internally build and maintain a string containing the parent’s complete path – based on how it was originally entered in the relevance? So if you wrote the relevance based on HKEY_CLASSES_ROOT, that should be returned. If you wrote the relevance to use HKEY_LOCAL_MACHINE\Software\Classes, that should be returned.
If you used “of keys”, then that object would have to maintain an array of parent key paths for each subkey so you wouldn’t get lost in "of keys
_
of keys
_
"
Paul
(imported comment written by SystemAdmin)
That would work for the HKEY_CLASSES_ROOT case, but it still leaves open the ambiguity regarding WOW64 redirection and the fact that there are ways to obtain key objects using relevance that doesn’t specify the path. For example, in BES 7.0 you can write “current user key (current user) of registry”, which uses the RegOpenCurrentUser API I mentioned. The resulting key does not have a well-defined path (it’s not the same as HKEY_CURRENT_USER).
Note that in cases where you do know how the path you are interested in should be constructed it is possible to keep track of it in the relevance expression (tuples can help with this).
(imported comment written by SystemAdmin)
I think the WOW64 redirection should be left up to Windows to decide. If the BES client runs as a 32bit process, then your only getting the reflected data anyhow. Unless your planning to write some portions as 64bit and others as 32bit and converse between the two. (Boy that sure sounds like the old days of thunking 16bit32bit).
From what I read in the RegOpenCurrentUser API, it appears it’s supposed to return the HKEY_USERS subkey for user of the impersonated thread. So it sounds the same as the trick we’re doing today to determine the HKEY_USERS subkey for the currently logged on user. In that case, the true path is to HKEY_USERS*. For most of what I’ve needed to do, I don’t care if it’s HKEY_CURRENT_USER or HKEY_USERS\sid. It’s the same place where I need to write to in the action.
So in BES 7, could you return “name of current user key (current user) of registry” ?
I’d think that should return the name of the sid under HKEY_USERS. “pathname of current user key (current user) of registry” should return “HKEY_USERS\sid”
I don’t know. I think if I’m constructing the path or if you can do it internally, it’s no better or no worse. It just makes it easier for me not to have to complicate the relevance if it’s done internally.