Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting... Please check out the Community Guidelines in the
Announcements and Administration Category.

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

Comments

  • Don_BurnDon_Burn Posts: 1,623
    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 <xxxxx@lists.osr.com>
    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://www.osronline.com/showlists.cfm?list=ntdev>;

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
    drivers!
    Details at <http://www.osr.com/seminars>;

    To unsubscribe, visit the List Server section of OSR Online at
    <http://www.osronline.com/page.cfm?name=ListServer>;
  • 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
  • Don_BurnDon_Burn Posts: 1,623
    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 <xxxxx@lists.osr.com>
    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://www.osronline.com/showlists.cfm?list=ntdev>;

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
    drivers!
    Details at <http://www.osr.com/seminars>;

    To unsubscribe, visit the List Server section of OSR Online at
    <http://www.osronline.com/page.cfm?name=ListServer>;
  • [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 :) and if you know other ways to get the names, I'll be happy if you'll write them.
  • Don_BurnDon_Burn Posts: 1,623
    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 <xxxxx@lists.osr.com>
    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 :) 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://www.osronline.com/showlists.cfm?list=ntdev>;

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
    drivers!
    Details at <http://www.osr.com/seminars>;

    To unsubscribe, visit the List Server section of OSR Online at
    <http://www.osronline.com/page.cfm?name=ListServer>;
  • 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!
  • Doron_HolanDoron_Holan Posts: 10,360
    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:

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

    To unsubscribe, visit the List Server section of OSR Online at
  • 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 :)
  • Tim_RobertsTim_Roberts Posts: 12,622
    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.

    Tim Roberts, [email protected]
    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 :)
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!