One of the many features of Kernel Detective is the possibility to retrieve the original addresses of the native apis functions implemented in the driver win32k.sys and checking if they are hooked. What are the possible ways to achieve the same ?
-
You might be also interested in HookShark. I know this is not the place for guessing, but I think it works the same. "It scans through the code-section of every loaded module of each running process and compares it with the file-image"– Dominik AntalMar 17, 2014 at 2:54
Add a comment
|
2 Answers
For conventional inline hooks (that just replace the first few bytes of the function), you can simply read the first few bytes of each function to check if it is hooked. Deeper inline hooks will be difficult to detect.
Apart from inline hooks, someone may also hook the SSDT. The SSDT is a table that sits between syscalls from WINAPI's and the kernelmode functions that implement them. The SSDT is indexed by syscall ID and maps each ID to the address of the kernelmode function. This mapping remains static for any given service pack for a Windows OS. So it is very easy to figure out what function each syscall ID corresponds to, and thus what function each entry in the SSDT should correspond to.
To detect SSDT hooks and restore original addresses, you could try any of the following:
You could load your program/driver once before the SSDT is hooked, and grab the original addresses. This would be fairly reliable, as long as you load your driver before the hook is in place.
Alternatively, you could download the .pdb file from Microsoft's symbol store and get the original addresses from it using the DIA SDK or DbgHelp API's. This is very reliable as long as a connection is present and nothing is interfering with it. However, this would be quite slow for a .pdb as big as the one for ntoskrnl or win32k.
There are actually two SSDT's, a regular SSDT and a Shadow SSDT. If only the first SSDT is hooked, you could check the values with those in the Shadow SSDT. Or vice versa.
You can check if any entries in the SSDT point to addresses outside the kernel/win32k. This is a very reliable way of detecting the hooks, but it won't easily get you the original address.
Scanning for a byte signature is a somewhat reliable and stealthy way you could locate the original addresses.
There's also a similar question here
-
1An alternative way to read the original SSDT entries is from the kernel image on disk. It's a PE file, and
KeServiceDescriptorTableis an exported entry. Mar 18, 2014 at 7:19
I think you should read from original file (exe, dll) of exported API function and compare with the data in the loading memory. To avoid the fake result in which the read API functions are also hooked, you should use some tricks to get the original read API function from memory.
Hope this help!
