Hi,
I am calling ZWEnumerateKey from my kernel module on windows 2000,
Which gets failed since NtEnumerateKey is hooked, through SSDT.
Please help me to resolve following questions:
1- Can we directly call ntoskrnl.exe functions from a kernel module, i.e skipping SSDT.
A method to bypass SSDT hooks in kernel.
Thanks,
Amit.
Before writing to the SSDT you should read the original value of the hook
you are replacing. This does not get the original pointer necessarily
pointing into ntoskrnl.exe (in the case of multiple hooks in a chain), but
the original pointer you obtain will at least prevent reentrancy in your
module. When you are done, download and run my hook analyzer:
http://www.resplendence.com/download/hookanlz.exe .
New version 3 will test the quality of your hooks by calling the system
services with garbage pointers and will crash if you do not do proper
parameter checking inside your hooks. It is shocking to see how many
commercial products have kernel hooks and how little of them survive this
test. I built this because NtCrash is no longer there since Sysinternals got
acquired.
/Daniel
wrote in message news:xxxxx@ntdev…
> Hi,
>
> I am calling ZWEnumerateKey from my kernel module on windows 2000,
> Which gets failed since NtEnumerateKey is hooked, through SSDT.
>
> Please help me to resolve following questions:
>
> 1- Can we directly call ntoskrnl.exe functions from a kernel module, i.e
> skipping SSDT.
>
> A method to bypass SSDT hooks in kernel.
>
> Thanks,
> Amit.
>
But the function is hooked by a rootkit
xxxxx@yahoo.com wrote:
Hi,
I am calling ZWEnumerateKey from my kernel module on windows 2000,
Which gets failed since NtEnumerateKey is hooked, through SSDT.Please help me to resolve following questions:
1- Can we directly call ntoskrnl.exe functions from a kernel module, i.e skipping SSDT.
A method to bypass SSDT hooks in kernel.
In kernel mode, entry points named NtXxxXxx are the original unhooked
addresses directly in ntoskrnl.exe. When you call those, SSDT hooking
does not affect you, but the “PreviousMode” global state still reflect
the state in your code, so if your code was called from user mode, the
entry point will validate parameters as if IT was called from user mode.
Also in kernel mode, entry points named ZwXxxXxx reenter the system call
dispatcher, sets PreviousMode to “KernelMode” and then obeys any SSDT hooks.
In user mode on the other hand NtXxxXxx and ZwXxxXxx are exactly the
same code address in ntdll.dll, which goes through INT
2E/SYSCALL/SYSENTER, sets PreviousMode to “UserMode” and obeys any SSDT
hooks.
To Unpatch the SSDT to its original values (unwise if hooking was done
by friendly code doing something useful), simply assign the NtXxxXxx
addresses directly back into the SSDT.
Another detail: Although all of the NtXxxXxx and ZwXxxXxx addresses
exist in both user and kernel mode, only a “random” subset of these
names is listed in the export tables of ntoskrnl and ntdll. Finding the
remaining addresses is left as a hard exercise for the developer.
–
Jakob Bøhm, M.Sc.Eng. * xxxxx@danware.dk * direct tel:+45-45-90-25-33
Danware Data A/S * Bregnerodvej 127 * DK-3460 Birkerod * DENMARK
http://www.netop.com * tel:+45-45-90-25-25 * fax tel:+45-45-90-25-26
Information in this mail is hasty, not binding and may not be right
If you have malicious code running in kernel mode, you’ve already lost.
–
Ken Johnson (Skywing)
Windows SDK MVP
http://www.nynaeve.net
wrote in message news:xxxxx@ntdev…
> But the function is hooked by a rootkit
>
Very true. Your pretty much hosed but any restoration *attempts* by
anti-rootkit tools usually use the kernel image on disk to get
KiServiceTable via the export KeServiceDescriptorTable. I believe you
can find source online for a utility called SDTRestore that does this.
RAIDE from rootkit.com is also a tool that will do this pointer
restoration for you.
Skywing wrote:
If you have malicious code running in kernel mode, you’ve already lost.
you can also check out .chkimg ntoskrnl -f from windbg
which simply fetches a brandnew ntoskrnl from symbol server parses it
shadowtable and resotres pristing entries
.chkimg is available in local kernel debugging session too
i dont know if it is persistent across memory never had reason to hunt rootkit
by using this feature but ive seen articles which claim to use .chkimg
to fix ssdt hooks
On 4/27/07, xxxxx@bugcheck.org wrote:
> Very true. Your pretty much hosed but any restoration attempts by
> anti-rootkit tools usually use the kernel image on disk to get
> KiServiceTable via the export KeServiceDescriptorTable. I believe you
> can find source online for a utility called SDTRestore that does this.
> RAIDE from rootkit.com is also a tool that will do this pointer
> restoration for you.
>
> Skywing wrote:
> > If you have malicious code running in kernel mode, you’ve already lost.
> >
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>