Hi All,
Please tell me How to use ZwRestoreKey?
I want the significance of arguments, and various flags that I can pass as last parameter to it.
Is there any good documentation available?
Thanks & Regards,
Amit.
The most obvious source of info is RegRestoreKey() documentation - this function is closely related
to ZwRestoreKey() (in fact, this is just win32 wrapper around it), so that all flags that you pass to it
end up in underlying ZwRestoreKey() call. Certainly, it does not mean that all flags that may be passed to ZwRestoreKey() are necessarily documented in RegRestoreKey() documentation, but, in such case, it is better to think of these undocumented flags simply as of non-existent ones - as all undocumented parameters, they may possibly have a different meaning for different OS versions…
Anton Bassov
I never used this from kernel mode but you must hold the SE_RESTORE_NAME
privilege and open your key using RegCreateKeyEx (not RegOpenKey/Ex) with
REG_OPTION_BACKUP_RESTORE specified in the options parameter. For
RegRestoreKey some flags are documented that you can use. I have been using
this API for long and I can say that just like RegSaveKey and RegLoadKey
these are among the most quirky APIs I have ever seen, on various OS they
may fail because you are using a long file name, you are not restoring a
file from the same volume as where the system resides or it may return
STATUS_INSUFFICIENT_RESOURCES or other errors for reasons that I think not
even the author understands. The least they could do is give us the source
so we could find our way through this mess.
/Daniel
wrote in message news:xxxxx@ntdev…
> Hi All,
>
> Please tell me How to use ZwRestoreKey?
>
> I want the significance of arguments, and various flags that I can pass as
> last parameter to it.
>
> Is there any good documentation available?
>
> Thanks & Regards,
> Amit.
>
actually I want to rename a key.
And I have two options
1> Enumarating sub keys and values recursively and making copy of them.
2> Using ZwSaveKey and ZwRestoreKey to make copy.
Which is better and reliable?
If you use RegRestoreKey and any process has any handles open to any subkeys
of where you want to restore, the restore function also fails but at least
this is mentioned by the doc.
Enumerating and copying keys and values is definitely more reliable. It has
the advantage that you can also copy volatile registry keys, the RegSaveKey
api does not save volatile keys. However do not forget that if you copy this
way your security descriptors and class information are not automatically
copied along like with the RegSaveKey apis, you need to write code for this
also if this is desired. If you do this from kernelmode remember most of the
registry does not become available until late in the boot process. I also
want to add a warning when recursively copying in kernel mode because you
can easily run out of stack space, you can call IoGetRemainingStackSize but
then if there’s not enough stack still the copy fails. Why not just do this
from usermode ?
/Daniel
wrote in message news:xxxxx@ntdev…
> actually I want to rename a key.
>
> And I have two options
> 1> Enumarating sub keys and values recursively and making copy of them.
> 2> Using ZwSaveKey and ZwRestoreKey to make copy.
>
> Which is better and reliable?
>
The problem is that these key are hidden by rootkits.
I am developing an AntiRootkit.
and it is not possible in usermode.
Well, if your kernel APIs are hooked, you are not going to get anywhere
anyway, whether you are in kernel or in user mode. The RootKit Revealer of
Sysinternals is suffering from the safe problem. Although its documentation
talks about “a level of sophistication not seen before”, it is really just
an easy snack to include also the RegSaveKey / RegRestoreKey apis if they
are on the hook anyway so if it’s up to me this tool is pretty worthless.
Another approach that I am going to take in the next version of RootKit Hook
Analyzer is enable the global flag which makes sure that all objects are
going to be registered in a linked list. I am not sure if this is going to
work out for registry objects but this is surely revealing hidden processes
and kernel modules (by enumerating driver objects). You can cycle through
the linked list of kernel objects of a certain type and see if those are
reported by the kernel APIs. If you take this approach there is no API the
bad guys can hook which can prevent you from obtaining this information,
they will need heavy duty kernel patching if they want to stop you from
doing this. The downside of all this is that you need to rely on
undocumented object structures but the good news is that most of this stuff
has maybe not been touched by anyone for some tweny years or so, so you can
probably use the same structures and the same code all the way from NT4 to
Vista.
I had hoped the AuxKLib… was going to be of help but this appears to be
just a wrapper around NtQuerySystemInformation.
/Daniel
wrote in message news:xxxxx@ntdev…
> The problem is that these key are hidden by rootkits.
> I am developing an AntiRootkit.
> and it is not possible in usermode.
>
I dont care of services are hooked or not. I have the tecnique to bypass the hooks, which I can not disscuss with you because of our company policy.
I can successfully do it even if rootkit is protecting it’s keys.
I need help from expirienced one as I dont have much experience.
wrote in message news:xxxxx@ntdev…
> I need help from expirienced one as I dont have much experience.
>
Then I suggest you drop this project because a lot of the bad guys are.
/Daniel
> Well, if your kernel APIs are hooked, you are not going to get anywhere
anyway, whether you are in kernel or in user mode. The RootKit Revealer of
Sysinternals is suffering from the safe problem. Although its documentation
talks about “a level of sophistication not seen before”, it is really just
an easy snack to include also the RegSaveKey / RegRestoreKey apis if they
are on the hook anyway so if it’s up to me this tool is pretty worthless.
Actually, I thought it is more sophisticated that that - I thought that it reads registry info from the phyical disk, i.e. obtains the target sector numbers from MFT, reads regsitry files as a raw data, and then compares the results with the ones that it obtains by calling registry functions. Therefore, I believe it is not as simplistic as you think…
Certainly, it still can be defeated - after all, even if you send IRP_MJ_READ to the disk, it does not mean that the data you see is identical to the one that is actually stored on the disk. However, in order to do something like that, rootkit developers need to know everything about NTFS and registry internals. AFAIK, *CURRENTLY* there is no *known* rootkit of that high level of sophistication…
Anton Bassov
> ----------
From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Daniel Terhell[SMTP:xxxxx@resplendence.com]
Reply To: Windows System Software Devs Interest List
Sent: Friday, July 20, 2007 1:30 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] How to use ZwRestoreKey?Another approach that I am going to take in the next version of RootKit Hook
Analyzer is enable the global flag which makes sure that all objects are
going to be registered in a linked list. I am not sure if this is going to
work out for registry objects but this is surely revealing hidden processes
and kernel modules (by enumerating driver objects). You can cycle through
the linked list of kernel objects of a certain type and see if those are
reported by the kernel APIs. If you take this approach there is no API the
bad guys can hook which can prevent you from obtaining this information,
they will need heavy duty kernel patching if they want to stop you from
doing this.
Interesting. What stops bad guys from using the same technique and unlink their objects from the linked list? I mean direct manipulation with linked entries.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
This of course needs consideration but once you are inside the object
manager anyway there are really many ways to find out about the existence of
objects. Theoretically it’s of course a lost battle but it doesn’t mean we
can’t do a very good job.
/Daniel
“Michal Vodicka” wrote in message
news:xxxxx@ntdev…
> ----------
Interesting. What stops bad guys from using the same technique and unlink
their objects from the linked list? I mean direct manipulation with linked
entries.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
wrote in message news:xxxxx@ntdev…
> Actually, I thought it is more sophisticated that that - I thought that it
> reads registry info from the phyical disk, i.e. obtains the target sector
> numbers from MFT, reads regsitry files as a raw data, and then compares
> the results with the ones that it obtains by calling registry functions.
> Therefore, I believe it is not as simplistic as you think…
>
> Certainly, it still can be defeated - after all, even if you send
> IRP_MJ_READ to the disk, it does not mean that the data you see is
> identical to the one that is actually stored on the disk. However, in
> order to do something like that, rootkit developers need to know
> everything about NTFS and registry internals. AFAIK, CURRENTLY there is
> no known rootkit of that high level of sophistication…
>
>
I may have remembered the wrong thing about it, I downloaded the latest
version to see what it exactly does but cannot get it to run on any of my
machines. If it’s true what you say it means it needs to understand the
format of registry hive files, I admit that would be not so trivial.
/Daniel