How to get a Driver name and file full path by its address in memory

Hi,

I want to get driver’s name and its file full path by its address (where is loaded in memory).
(The end goal is to write independent code so I wont depend on any syscalls).
I came across functions like ObpCaptureObjectName, but I don’t how they work due to lack of information.

[My first wdm driver]

Tnx

What problem are you really trying to solve? The statement " The end goal
is to write independent code so I won’t depend on any syscalls" is pretty
nonsensical. There are undocumented calls that will enumerate the drivers
in the kernel, and there is PsSetLoadImageNotifyRoutine that will provide a
callback for all drivers loaded after yours.

Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Saturday, December 30, 2017 9:57 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] How to get a Driver name and file full path by its address
in memory

Hi,

I want to get driver’s name and its file full path by its address (where is
loaded in memory).
(The end goal is to write independent code so I wont depend on any
syscalls).
I came across functions like ObpCaptureObjectName, but I don’t how they work
due to lack of information.

[My first wdm driver]

Tnx


NTDEV is sponsored by OSR

Visit the list online at:
http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at
http:</http:></http:></http:>

I do a rootkit detection driver for study purposes.

One of the things I want to do is check for SSDT hooks.
So I want to get the real ntoskrnl address from a syscall independent function and check if the functions in the table are in this driver.

any call that depends on syscall can return false answer

Once there is a piece of malware in the kernel, any call can return a false
answer whether it is invoked by a syscall or not. You need to see if the
Windows versions you care about export NtQuerySystemInformation, note
ZwQuerySystemInformation will go through your dreaded SSDT so you don’t want
that.

Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Saturday, December 30, 2017 10:15 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to get a Driver name and file full path by its
address in memory

I do a rootkit detection driver for study purposes.

One of the things I want to do is check for SSDT hooks.
So I want to get the real ntoskrnl address from a syscall independent
function and check if the functions in the table are in this driver.

any call that depends on syscall can return false answer


NTDEV is sponsored by OSR

Visit the list online at:
http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at
http:</http:></http:></http:>

[The driver is meant to be used on Windows 7 32-bit]

I know that once a malware infected the kernel, there is a possibility to get false answer for almost everything I would do, but my plan is to depend as little as I can on windows functions and information - the malware can do inline hooking as well (which I intend to check as well) and hide entries from lists etc.

So what I did so far in that regard, for example, I took IoEnumerateDeviceObjectList function from ReactOS, and I wanted to take NtQuerySystemInformation from there as well (I did’t want that before, because it seems like a lot of work to adjust it, but now that you recommended that function, I probably will use the source code from ReactOS https://doxygen.reactos.org/d1/d26/ndk_2exfuncs_8h.html#a19379528a90550a5ef25744ccb4551ee)

Tnx for the help :slight_smile: and if you know other ways to get the names, I’ll be happy if you’ll write them.

If you think you can take ReactOS functions and use the with Windows
accessing Windows data forget it. ReactOS is mainly based on ripped off
Windows 2000 source, and things have changed.

Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Saturday, December 30, 2017 12:01 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to get a Driver name and file full path by its
address in memory

[The driver is meant to be used on Windows 7 32-bit]

I know that once a malware infected the kernel, there is a possibility to
get false answer for almost everything I would do, but my plan is to depend
as little as I can on windows functions and information - the malware can do
inline hooking as well (which I intend to check as well) and hide entries
from lists etc.

So what I did so far in that regard, for example, I took
IoEnumerateDeviceObjectList function from ReactOS, and I wanted to take
NtQuerySystemInformation from there as well (I did’t want that before,
because it seems like a lot of work to adjust it, but now that you
recommended that function, I probably will use the source code from ReactOS
https://doxygen.reactos.org/d1/d26/ndk_2exfuncs_8h.html#a19379528a90550a5ef2
5744ccb4551ee)

Tnx for the help :slight_smile: and if you know other ways to get the names, I’ll be
happy if you’ll write them.


NTDEV is sponsored by OSR

Visit the list online at:
http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at
http:</http:></http:></http:>

The solution is very simple however not 100% stable. As long as the driver is not being “hidden”, you can enumerate the loaded device drivers via ZwQuerySystemInformation with the SystemModuleInformation class.

This will provide you with the base addresses among many other details for the modules of NTOSKRNL (Windows Kernel - device drivers are of course under the Windows Kernel).

You need to iterate through each entry returned and compare if the base address of the currently checked driver has a base address which is less than the address you are trying to track back to a specific target and if the next entry has a base address which is more than the address you are trying to track.

For example:

  1. Driver X has a routine at address XXXXX
  2. Driver B has a base address of XXXXX and it is less than the address of the routine we have the address for which belongs to Driver X, however, the address for the routine in Driver X is also less than the base address of Driver C (Driver C being the next entry up from the driver we are currently checking).
  3. Now we know that the address we are checking resides within the address space of Driver B.

You can do this with minimal effort really, and despite SystemModuleInformation being undocumented, it can work nicely. Just make sure that the routine exists for the environment, I believe Microsoft removed it as being exported for Windows 8 (I cannot remember) however it exists on Windows 10.

In regards to ReactOS, Don is 100% correct. It has not been updated for many, many years… And a LOT has changed with the modern Windows Kernel. As well as this, it is “open-source” and I doubt your project is, and copy-pasting blatantly will teach you nothing but how to make an awful project which will face many issues which you won’t be able to resolve.

There is no need to “re-invent the wheel”. There are many anti-rootkit scanners already, and you are wasting your time because rootkits have not been “prevalent” in the wild for an extremely long time. Especially since now everyone is moving to 64-bit if they already haven’t due to the benefits, and 64-bit versions of Windows have had PatchGuard for a long time.

Ransomware is prevalent in the wild, it would likely be in your best interest to focus on behavioural analysis for preventing the encryption payload of ransomware instead of making an anti-rootkit scanner nowadays. At-least, if you want to make a project which will be actively used. On that note, you will have access to many documented interfaces for doing such a task, like a File System Mini-Filter device driver with FltRegisterFilter.

Anyway, maybe this will help you. Good luck with your project!

AuxKlibQueryModuleInformation is the supported api for querying loaded module information and works across all versions.

d

Bent from my phone


From: xxxxx@lists.osr.com on behalf of xxxxx@gmail.com
Sent: Monday, January 1, 2018 8:58:28 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to get a Driver name and file full path by its address in memory

The solution is very simple however not 100% stable. As long as the driver is not being “hidden”, you can enumerate the loaded device drivers via ZwQuerySystemInformation with the SystemModuleInformation class.

This will provide you with the base addresses among many other details for the modules of NTOSKRNL (Windows Kernel - device drivers are of course under the Windows Kernel).

You need to iterate through each entry returned and compare if the base address of the currently checked driver has a base address which is less than the address you are trying to track back to a specific target and if the next entry has a base address which is more than the address you are trying to track.

For example:
1. Driver X has a routine at address XXXXX
2. Driver B has a base address of XXXXX and it is less than the address of the routine we have the address for which belongs to Driver X, however, the address for the routine in Driver X is also less than the base address of Driver C (Driver C being the next entry up from the driver we are currently checking).
3. Now we know that the address we are checking resides within the address space of Driver B.

You can do this with minimal effort really, and despite SystemModuleInformation being undocumented, it can work nicely. Just make sure that the routine exists for the environment, I believe Microsoft removed it as being exported for Windows 8 (I cannot remember) however it exists on Windows 10.

In regards to ReactOS, Don is 100% correct. It has not been updated for many, many years… And a LOT has changed with the modern Windows Kernel. As well as this, it is “open-source” and I doubt your project is, and copy-pasting blatantly will teach you nothing but how to make an awful project which will face many issues which you won’t be able to resolve.

There is no need to “re-invent the wheel”. There are many anti-rootkit scanners already, and you are wasting your time because rootkits have not been “prevalent” in the wild for an extremely long time. Especially since now everyone is moving to 64-bit if they already haven’t due to the benefits, and 64-bit versions of Windows have had PatchGuard for a long time.

Ransomware is prevalent in the wild, it would likely be in your best interest to focus on behavioural analysis for preventing the encryption payload of ransomware instead of making an anti-rootkit scanner nowadays. At-least, if you want to make a project which will be actively used. On that note, you will have access to many documented interfaces for doing such a task, like a File System Mini-Filter device driver with FltRegisterFilter.

Anyway, maybe this will help you. Good luck with your project!


NTDEV is sponsored by OSR

Visit the list online at: https:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at https:

To unsubscribe, visit the List Server section of OSR Online at https:</https:></https:></https:>

First of all, thanks for the answers and the constructive notes.

My thought of using ReactOS was strictly for guidance to understand how to get the information I needed for certain actions and not to copy - paste.

The verification of ntoskenl module is one of those actions. Although there are other ways to do the verification (e.g. make a signature of the constant data from the headers of the file and module and compare the signs OR scan the SSDT and see to where the majority of the pointers point to), the method I mentioned now (regardless to its efficiency) is for me to learn better how to do things in the kernel in the limited time I have.

In regard to why rootkits and not ransomware, you are right! but I chose rootkits because it’s easier for me to focus the kernel development and not the research - there are many rootkits detection systems, but it still hard to find one that really tries to detect all (or most) rootkits methods. Another problem is the ransomware is pretty much made of legitimate action - and this is the reason it’s hard to detect, most anti-ransomware I’ve incountred until now is signature based where the emphasis is more on the delivery method and less the files encryption itself OR traps based. the working solution today for ransomware (as far as I know) are backup solutions.

Again, I want to thank you all for the time and answers, it helped me a lot as to how to approach the kernel and how to look at things.

Feel free to add information in regard to this post, I’ll be more than happy to read it :slight_smile:

On Jan 1, 2018, at 9:39 PM, xxxxx@gmail.com wrote:

…there are many rootkits detection systems, but it still hard to find one that really tries to detect all (or most) rootkits methods.

Yes, but not because the authors are incompetent, but rather because the rootkit authors are clever. They HAVE done the research and study that you don’t want to do. As we have tried to say several times, once a rootkit is running in the kernel, it can hide all of its actions from you. There IS no generic detection solution. It’s impossible.

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

I didn’t say the authors are incompetent, and believe it or not, I did my research on rootkits and I know where I’m going with it. And it’s for study purpose only.

All I say is that in my opinion there is a possibility that if I unite some detection methods and implement some detections in other ways, maybe the detection rate will be higher.

I’m not going to search for rootkits in the BIOS or in hardware firmware, but I did my research on userspace rootkits and kernelspace rootkits and my now I’m in the kernel space part of my system. Yes, I do know If a rootkit is running in the kernel, it can control the results I seek, but you can also see how many rootkits works and combine methods (and implement methods diffrently) in attempt to detect as many as you can.

By the way, I didn’t ask about rootkits, just asked what I’ve asked and explained why I’ve asked it, so please lets focus on the question rather on what I want to do.

tnx :slight_smile: