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

Home NTDEV

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Before Posting...

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

Process's file object or handle

Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 443
Hi.

I am looking for the least undocumented way of getting the file object or file handle of the main executable of a running process.
So far that seems to be PsReferenceProcessFileObject.

Any better ideas? TIA.

Regards.

Comments

  • MDHMDH Member Posts: 41

    At what point in time? PsCreate callback gives you the FO. Otherwise, just add it to a linked list and look it up using the PID. Of course you have to be in the process context generally to get the current PID (unless you are sending it up from user-mode) but your question is lacking a lot of detail so tough to actually help.

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 443
    via Email
    The question is about random times, but definitely not in the process
    create callback (that is easy to handle obviously).
    So I need to get the handle of a random process, for which I did not have a
    create notification callback (driver cannot load at boot).

    Kind regards, Dejan Maksimovic.
    FS Lead: http://www.alfasp.com
  • Don_BurnDon_Burn Member - All Emails Posts: 1,739

    The safe way to do this is to have a helper driver that does load at boot and keeps a table of the data you want about the process versus the process ID. I've done this for clients before, the helper driver exposes either a device object or a device interface, that the primary driver then uses once loaded to do get the information it needs.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,568

    The safe way to do this is to have a helper driver that does load at boot and keeps a table of the data you want about the process versus the process ID

    This. Definitely. It's "the way" it's done.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 443
    via Email
    That is simply not an option.
    It would have been done as a first choice were it acceptable.
  • MBond2MBond2 Member Posts: 347

    Then you are sunk. Change the requirements

  • MDHMDH Member Posts: 41

    Well, not quite. Although I'm not familiar with PsReferenceProcessFileObject, there's EPROCESS->SectionObject->???->FILE_OBJECT

    Lot's of bad, undocumented steps in between there so not sure if it's worse than 1 undocumented API. But not going to do your homework for you.

  • Don_BurnDon_Burn Member - All Emails Posts: 1,739

    The second I see EPROCESS-> I know run don't walk from that POS. Microsoft over the years has changes EPROCESS more often than some programmers I know change socks.

  • MDHMDH Member Posts: 41

    @Don_Burn said:
    The second I see EPROCESS-> I know run don't walk from that POS. Microsoft over the years has changes EPROCESS more often than some programmers I know change socks.

    Just providing another perspective Don. Not saying it's the right way to do things but some times it is still helpful (would be nice if more of the experts on this board took the same opinion). I have no idea what Dejan's use case is but hard coding SectionObject offsets may be his thing. I'm assuming it's security related, and because Microsoft likes to hide all the good security bits behind "opaque" structures, a little disassembly may not hurt in the right circumstances. Lot of "production" ready drivers do the same.

  • Don_BurnDon_Burn Member - All Emails Posts: 1,739

    "Not saying it's the right way to do things but some times it is still helpful (would be nice if more of the experts on this board took the same opinion)."

    A lot of the experts on the board have been bitten by this type of garbage. I spent months for a client who biggest customer was convinced my clients (i.e. my code) had a serious bug only to find in the end the customer was using a systems management tool that cut the corners in ways such as you suggest. Of course it turned out my clients system was valid, but did not live well with the hacks in that code.

    There are valid ways to do what this thread wanted but they require things that the OP does not want to do. The Windows kernel is one address space, one bad actor such as your suggestion hurts everyone who works there.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,568
    edited July 10

    It’s the responsibility of the “experts on this board” to point out that groping undocumented structures with random offsets is not a viable plan outside the lab environment, in a single, fixed, version of the OS.

    I could bore you all day with stories about this, from any perspective you desire: customers being screwed by ignorant devs, MSFT dev owners getting blamed for crashes that are the result of 3rd party devs reaching into opaque structures, whatever.

    As for the OP, well…. I suppose he can hope for a miracle?

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • craig_howardcraig_howard Member Posts: 126

    Most unfortunately, I think the OP is running into the "grumpy overlord" aspect of Windows ... the way I describe it to clients that wonder why X that works in Linux doesn't work in Windows I tell them that Linux is like a bunch of kids playing the sandbox, whoever gets to the dumptruck first wins, much like MadMax. With Windows all of the kids are told to sit quietly in a corner of the sandbox and get the dumptruck handed to them when it's their turn and get pulled out of the sandbox if they don't behave ...

    The OP is attempting to do something that the OS simply doesn't allow a usermode program to do (I'm actually surprised that KernelMode can do it, it's a recipe for killing processes you don't like ... like an AV scanner, some DRM process, some game anti-cheat monitor, etc.) ... it allows a KernelMode program to do that, but not a Usermode, simple as that. You can try to grab for the dumptruck but all you're going to be doing is getting pulled out of the sandbox as soon as the OS changes (which it does every six months these days) ...

    @DonBurns and @Peter had it right: do it in KernelMode, get it signed, etc. If that's not an option then the target product is also not an option ...

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 443
    via Email
    I am a in a driver. I presumed that much was clear on a driver forum :)


    Some are missing the point, I think. I can get a file object, but not one I
    can read the data with, at least not without risking a hang (post cleanup
    FO).
    Nor a file handle (FO would require IRPs, since it is not inside a
    minifilter).

    Dejan.

    @DonBurns and @Peter had it right: do it in KernelMode, get it signed,
  • craig_howardcraig_howard Member Posts: 126
    edited July 10

    Hmm ... you say that you're in a driver, but you say that a "helper driver" loaded on boot that is going to collect the data as @DonBurns suggests is not an option ... are you thinking you can load a driver at some arbitrary time and have it rumble through the EPROCESS list collecting nuggets of knowlege?

    That's not going to work, period ... aside from needing to synchronize your reads with whatever writes the OS is going to do with the EPROCESS list at the same time, all you are gathering is a snapshot of processes at the instant that you take the snapshot; any processes that came and went before your driver loaded are lost, and (unless you're going to be continually gathering info) any processes starting after your snapshot is complete will be lost ...

    I think we're back to a "I am trying to glue wings onto my pig but they keep falling off, should I rivet them on" question rather than a "I would like to move my pig quickly from point A to point B, what's the best way to do that" question ...

    What exact specific problem are you trying to solve, what is the target OS to solve it on and what is the target audience that is having the specific problem you're trying to address?

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 443
    via Email
    I don't want to rummage through EPROCESS, that is part of the point.
    It is the getting a usable file object or handle to the backing image that
    I want (for reading only, nothing else required).
    That should be possible as long as the process is active, since the backing
    image will still exist.

    But most of the time, those are Post Cleanup state FOs, and thus I cannot
    even issue a read (I can "issue" a paging I/O read, but that's a recipe for
    a hang).

    For testing purposes, I even tried enumerating the handles in WinDBG, but
    got the same result. A running process, no handles (post cleanup FO).
    Process Explorer doesn't find any handles to the backing image either.

    Note the difference between handles and file objects in my post.

    Kind regards, Dejan.
    https://www.alfasp.com
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!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Developing Minifilters 24 May 2021 Live, Online
Writing WDF Drivers 14 June 2021 Live, Online
Internals & Software Drivers 27 September 2021 Live, Online
Kernel Debugging 15 November 2021 Live, Online