Process's file object or handle

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.

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.

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

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.

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

That is simply not an option.
It would have been done as a first choice were it acceptable.

Then you are sunk. Change the requirements

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.

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.

1 Like

@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.

“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.

1 Like

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

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 …

I am a in a driver. I presumed that much was clear on a driver forum :slight_smile:

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,

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?

1 Like

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