4

I did a simple SSDT Hooks detector that iterates through all entries and checks if any address is outside the Kernel module. If so, I can even go back and using the syscall find out what function was supposed to be there. I suppose that at this point I could also try to undo the hook, but I haven't tried yet.

I use ZwQuerySystemInformation to get a list of modules and I always assume that the first module is the kernel. How safe is this approach? Is there a chance that the kernel module would not be the first? I could search by name, but it's not always the same so I tried to avoid that; I can make it to search for one of the names the kernel module could have. I also need that list to see from what module comes the hook. Is there a way that I can get a list of the loaded modules without ZwQuerySystemInformation? It can hide information from me if it is hooked.

Regarding inline hooks, right now I iterate through all the exports from the kernel module and check each function's code to see if it begins with a relative jump or a push offset & ret. Should I also check if the address to which the jump / ret is made is outside the kernel module or it's redundant? If I don't check for the jump address I get a false positive (I think) for KePollFreezeExecution which jumps inside the kernel module. u nt!KePollFreezeExecution in WinDbg gives the following output

jmp nt!KeIpiGenericCall+0x132
int 3

Seems ok.

I know this isn't perfect (someone could place the hook anywhere inside the function code or maybe find a place inside the kernel module where to put his functions and so on), but I'm just doing it to understand how all of this works.

Also, I'm aware that on x64 this methods won't be so simple to implement, but at the moment I'm experimenting with x86.

More of a "how should I approach this" question than "how should I code this".

  • 1
    See this and this – 0xec Sep 10 '14 at 15:51
  • 1
    Whether it's outside the kernel module is only going to catch the simplest hook methods. Like every PE file when loaded into memory the NT kernel will have "gaps". Basically the remainder of a section up to its logical size or even just when functions are aligned with more than necessary NOPs. Those gaps can be (ab)used to store the trampolines and your detection code won't even consider them hooks. – 0xC0000022L Oct 15 '14 at 8:10
2

If your looking for SSDT hooking with WinDbg, have tried the SwishDbgExt.dll?

Here is the link to the author's page - http://www.msuiche.net/2014/07/16/thats-so-swish

Update: http://www.msuiche.net/2014/08/19/swishdbgext-update-0-6-20140817/

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.