SSDT Checker

I’m new to device drivers and would like to create a GUI application using MFC with a kernel mode driver which does the low level work. What I want to the driver to do is to traverse the SSDT table get the address of the system call map to it the actual name of the function and if hooked that is if the address is outside the range of the kernel address space then find out which process has hooked it. I would like to do this for all exports of ntdll and ntoskrnl.exe modules. Present it in a nice GUI to the user. I’ve done the GUI and have a basic idea on how to forward data from the driver to the user mode GUI. I am having trouble figuring out how to get the low level information.

Can anyone point me toward some resources or sample code or anything that might help me out ?

Thanks again

Victor

> What I want to the driver to do is to traverse the SSDT table get the address of the system call

map to it the actual name of the function and if hooked that is if the address is outside the range of
the kernel address space then find out which process has hooked it.

This description does not seem too make sense in itself, does it - after all, it is not a process but kernel module who hooks, so that the function address will always lie in the kernel address space anyway. The only thing you can do is to detect a hooking module, but this is not always possible either - just consider what happens if the actual hooking code resides, say, in module X, but the corresponding SSDT entry points to non-paged pool, i.e. SSDT points to few handcrafted instructions that make a jump to the actual hooking code…

Anton Bassov

Sorry if I sounded confusing because that was not my intention. Maybe I can show you some code which might help. What I need is to locate the name of the handler and the number of parameters it takes. Another words I would like to find the function name that is associated with the address of the service handler. I hope it sounds a little more clearer but I am new to device driver never written one before.

for(i=0;i<keservicedescriptortable.numberofservices>{
ServiceHandlerAddr = KeServiceDescriptorTable.ServiceDispatchTableBase[i];
DbgPrint(“Index %d: Handler 0x%08X,\n”, i,
ServiceHandlerAddr) ;
}</keservicedescriptortable.numberofservices>

Is there some reason why you chose this as your first driver? The thing is,
this sort of thing - SSDT access - is frowned upon, if only for read only
purposes, because it changes from version to version.

mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Thursday, April 07, 2011 4:32 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] SSDT Checker

Sorry if I sounded confusing because that was not my intention. Maybe I can
show you some code which might help. What I need is to locate the name of
the handler and the number of parameters it takes. Another words I would
like to find the function name that is associated with the address of the
service handler. I hope it sounds a little more clearer but I am new to
device driver never written one before.

for(i=0;i<keservicedescriptortable.numberofservices>{
ServiceHandlerAddr = KeServiceDescriptorTable.ServiceDispatchTableBase[i];
DbgPrint(“Index %d: Handler 0x%08X,\n”, i,
ServiceHandlerAddr) ;
}


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer</keservicedescriptortable.numberofservices>

xxxxx@hotmail.com wrote:

Sorry if I sounded confusing because that was not my intention. Maybe I can show you some code which might help. What I need is to locate the name of the handler and the number of parameters it takes. Another words I would like to find the function name that is associated with the address of the service handler. I hope it sounds a little more clearer but I am new to device driver never written one before.

The phrase is “In other words”, not “Another words”.

for(i=0;i<keservicedescriptortable.numberofservices>> {
> ServiceHandlerAddr = KeServiceDescriptorTable.ServiceDispatchTableBase[i];
> DbgPrint(“Index %d: Handler 0x%08X,\n”, i,
> ServiceHandlerAddr) ;
> }

That code does not print the function name, nor does it print the number
of parameters. In the general case, it is impossible to get either the
function name or the number of parameters programmatically.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.</keservicedescriptortable.numberofservices>

I don’t think that he was saying that that code does. I think he provided
it as an example of what he had already done, and was asking how to take the
next step of getting function names and parameter counts.

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Thursday, April 07, 2011 5:10 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] SSDT Checker

xxxxx@hotmail.com wrote:

Sorry if I sounded confusing because that was not my intention. Maybe I
can show you some code which might help. What I need is to locate the name
of the handler and the number of parameters it takes. Another words I would
like to find the function name that is associated with the address of the
service handler. I hope it sounds a little more clearer but I am new to
device driver never written one before.

The phrase is “In other words”, not “Another words”.

for(i=0;i<keservicedescriptortable.numberofservices>> {
> ServiceHandlerAddr = KeServiceDescriptorTable.ServiceDispatchTableBase[i];
> DbgPrint(“Index %d: Handler 0x%08X,\n”, i,
> ServiceHandlerAddr) ;
> }

That code does not print the function name, nor does it print the number
of parameters. In the general case, it is impossible to get either the
function name or the number of parameters programmatically.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer</keservicedescriptortable.numberofservices>

Thanks for all replies.

MM the reason I was interested in designing a SSDT Checker as my first driver application is because I am fascinated by the world of rootkits and keyloggers and primarily their stealth techniques they employ. I have become interested in the area of detection and along the way I became also interested with the the unknown and sometimes undocumented depths of the OS. But with the lack of availability of source code for detection I decided to venture out on my own. I am aware of a couple of application found while researching on the internet that what I am trying to do can be done. I plan on taking it further as Anton mentioned that some applications and technologies use inline hooking where a jmp statement is inserted at the first few bytes of a function. Microsoft introduced hot patching and code injection as another method used by these same technologies. There are many more methods with some undocumented because there is not enough research in these areas.

Best Regards

Victor

Actually there is a lot of research in this area. Take a look at the
number of books on rootkits at Amazon let alone the number of papers on
the subject. The problem is people keep running down the same dumb
paths. One of those paths is that you cannot really catch rootkits or
clean them up on a running system, you really need to boot a different
image from something like a DVD and then clean the disk. Note:
Microsoft gives you the tools to create that boot image, with the
Windows Automated Installation Kit, but of course then if you do it
right you don’t need a driver, since a user space application can open
the disk.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

xxxxx@hotmail.com” wrote in message
news:xxxxx@ntdev:

> Thanks for all replies.
>
> MM the reason I was interested in designing a SSDT Checker as my first driver application is because I am fascinated by the world of rootkits and keyloggers and primarily their stealth techniques they employ. I have become interested in the area of detection and along the way I became also interested with the the unknown and sometimes undocumented depths of the OS. But with the lack of availability of source code for detection I decided to venture out on my own. I am aware of a couple of application found while researching on the internet that what I am trying to do can be done. I plan on taking it further as Anton mentioned that some applications and technologies use inline hooking where a jmp statement is inserted at the first few bytes of a function. Microsoft introduced hot patching and code injection as another method used by these same technologies. There are many more methods with some undocumented because there is not enough research in these areas.
>
> Best Regards
>
> Victor

All true, but if the op is just interested in learning, I don’t see a
problem.

That being said, to the best of my knowledge, the symbols for the ssdt
tables are private, so you’d be down to developing heuristics based on
disaasembly, which is probably not the best place to start.

What else interests you?

mm
On Apr 8, 2011 3:50 PM, “Don Burn” wrote:
> Actually there is a lot of research in this area. Take a look at the
> number of books on rootkits at Amazon let alone the number of papers on
> the subject. The problem is people keep running down the same dumb
> paths. One of those paths is that you cannot really catch rootkits or
> clean them up on a running system, you really need to boot a different
> image from something like a DVD and then clean the disk. Note:
> Microsoft gives you the tools to create that boot image, with the
> Windows Automated Installation Kit, but of course then if you do it
> right you don’t need a driver, since a user space application can open
> the disk.
>
>
> Don Burn (MVP, Windows DKD)
> Windows Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
>
>
>
>
> “xxxxx@hotmail.com” wrote in message
> news:xxxxx@ntdev:
>
>> Thanks for all replies.
>>
>> MM the reason I was interested in designing a SSDT Checker as my first
driver application is because I am fascinated by the world of rootkits and
keyloggers and primarily their stealth techniques they employ. I have become
interested in the area of detection and along the way I became also
interested with the the unknown and sometimes undocumented depths of the OS.
But with the lack of availability of source code for detection I decided to
venture out on my own. I am aware of a couple of application found while
researching on the internet that what I am trying to do can be done. I plan
on taking it further as Anton mentioned that some applications and
technologies use inline hooking where a jmp statement is inserted at the
first few bytes of a function. Microsoft introduced hot patching and code
injection as another method used by these same technologies. There are many
more methods with some undocumented because there is not enough research in
these areas.
>>
>> Best Regards
>>
>> Victor
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Don your absolutely right about the availability of information on rootkit technology but I’ve yet to find research in the area of detection and removing thats sound and complete. I agree that you can boot from a CD image and view the file system and OS from a different light but in how many cases will this technique work and then not work ? I’ve read that rootkits can hide themselves, at least in concept, in the BIOS, PCI BIOSes and even modify the Windows Boot loader and go undetected by passing a checksum verifier test.

MM I am not an experienced programmer by far but enjoy working with mostly C\C++ and Visual C++ and now driver development. My knowledge of Assembly is at a novice level but am willing to try to learn new things.

BTW I have been fortunate and have found some open source code on checking the SSDT along with other tables here at http://www.security.org.sg/code/kproccheck.html for anyone interested.
Part of the code is written in user mode and the part as a device driver. Maybe I can learn a few things from its open source availability.

Victor

For learning: names and parameters of system calls can be found here:
http://dev.metasploit.com/users/opcode/syscalls.html

The OP may want to join that or other project, instead of rolling yet
another one.

– pa

Good idea.

Mm
On Apr 8, 2011 6:52 PM, “Pavel A.” wrote:
> For learning: names and parameters of system calls can be found here:
> http://dev.metasploit.com/users/opcode/syscalls.html
>
> The OP may want to join that or other project, instead of rolling yet
> another one.
>
> – pa
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Thanks Pavel A.

I’ll add that link to my existing set of resources. Best Regards

Victor

>I agree that you can boot from a CD image and view the file system and OS from a different light but in how many

cases will this technique work and then not work ?

In any case, this is by far better technique then trying to find rootkit in already booted Windows.

I’ve read that rootkits can hide themselves, at least in concept, in the BIOS, PCI BIOSes

And? your SSDT hooker will be able to find this? :slight_smile:


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com