unhiding registry keys

unhiding registry keys

Post by joe flower » Thu, 13 May 2004 22:35:46


Will someone please send me a snippet of C/C++ code to unhide, previously
hidden somehow, registry keys?
I can't see some registry keys in regedit.exe and their subkeys/data/etc.
even when I'm logged on as Administrator.

Thanks!

Joe
 
 
 

unhiding registry keys

Post by John Phill » Fri, 14 May 2004 02:44:50

Are you sure the keys are actually there? :)

If so, it sounds like it might be a permissions problem. Use regedt32 to
check (and correct if necessary) the permissions on the appropriate keys.

As for code, check out RegSetKeySecurity() if it turns out to be a
permissions issue.


--
John Phillips
MVP - Windows SDK

 
 
 

unhiding registry keys

Post by joe flower » Fri, 14 May 2004 03:02:20

Yes John. The keys and data are actually there.

It's the [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services] key in
particular, and besides the services working, I can try to create a
"services" key and it says a key already exists with that name.

Tried regedit.exe, regedt32.exe etc., and those tools don't even see those
keys when I'm logged in as Admininstrator. And, for all keys above it, I
don't see a permissions problem. Administrator has all rights above and
still no luck.

Thanks for the RegSetKeySecurity() pointer! I'll get on looking at it now!
Thanks!

Joe








previously
subkeys/data/etc.
 
 
 

unhiding registry keys

Post by Joe Hage » Fri, 14 May 2004 14:10:05


Joe,

Back in 1998, Mark Russinovich developed code that
uses the Native API to create registry keys that
are inaccessible using the Win32 API by embedding NULs
in the key names. The utility, REGHIDE, includes source
and is available at:

http://www.yqcomputer.com/

The code works because the Native API describes a
name based on the number of Unicode characters,
so NUL is valid. However, the Win32 API treats a
NUL as end of string, rendering the key inaccesible
to regedt32 and regedit.

Based on your description of the problem, this may
not be the issue however.

Joe