Is there a way of getting CWD from a process without needing to deal with PEB?

NTDEV
1

Hi there!

I am dealing with a requirement that I need to get the current working directory of a running process from the context of a pre operation callback of a minifilter, so I was thinking if there is a way of getting this information without using PEB stuff maybe just by using documented and no opaque things. By using PEB is complicated because of the lack of backward compatibility, in my state of things, for example, my winternl.h does not define DLCurrentDirectory as people expects on their proposed solutions out there.

My feeling with this initial incompatibility even at compile time is something like the compiler screaming “do not use opaque stuff, avoid future headaches, find a better general solution”. Thus, I would appreciate any tip, clue or help. Have anyone ever faced this kind of requirement? Here goes one more general/philosophical question: when facing this kind of requirement, that push us to use undocumented or opaque stuff, how we could keep the code sane, stable, compatible and general? how can we proceed to get the thing done? Personally, I do not see a way of doing this in a (really) right way, opaque and undocumented stuff is kernel developers business, maybe device drivers developers should keep it alone. Thanks in advance!

2

I think that this is one of those ‘what larger problem are you trying to solve’ questions because I don’t think that anyone can help you very much without more context. It is highly unusual for any KM component to care about the current directory of the process that is making any kind of call.

3

Well, it is for AV stuff.

4

Well, in my opinion, most AV software is worse that the malware that they pretend to protect against but anyways.

In your case, I would not worry about getting data from undocumented fields in the PEB. You are going to do a whole bunch of highly questionable things anyways, and this structure is partially documented by MSFT. That makes it impossible that the opaque parts will change in size because then the documented parts would move - violating the ABI. This structure has also been extensively studied and reversed engineered - which also makes it unlikely that the usage of the opaque members will change much. It has happened before - CRITICAL_SECTION is a great example - but it is rare