Actual process ID

NTDEV
1

Is there any way to determine the owning process when a callback executes within the context of the system thread?

2

> Is there any way to determine the owning process when a callback executes

within the context of the system thread?

One of the important questions is “Why do you care?”. What information do
you think this is going to make available to you? It is worth pointing out
that process IDs do not in and of themselves convey anything useful, and
if you think you are going to see what executable is running in the
process, be aware that this is so trivially spoofable that if there is
some intention of imposing some kind of security using this technique, you
won’t get it. Most home-grown security “solutions” are not solutions at
all, and the main question is to what degree they fool the people who
asked for them into believing that they have actually achieved security.
Most of these home-grown solutions ignore all kinds of basic principles in
Windows which allows them to be cracked in less than half an hour by
non-experts (the last one I saw proposed here, I had cracked it before I
finished reading the sentence that described what it did).
joe

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

3

No, unless you have explicitly passed it to your work item structure.

If the work item is related to an IRP - then IoGetRequestorProcessId helps, and FltMgr IIRC has the same kind of call.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntdev…
> Is there any way to determine the owning process when a callback executes within the context of the system thread?
>
>

4

I wasn’t looking to be flamed, although I probably should have specified that given the nature of this list. The number of assumptions you make are staggering but you really shouldn’t assume you know or understand my requirements from a simple and valid question.

Please don’t respond to my questions anymore unless you provide something constructive. Reading your little rant just wastes my time.

5

Thanks Maxim.

6

> Please don’t respond to my questions anymore unless you provide something constructive.

Reading your little rant just wastes my time.

I guess you should go to some university and learn everything about the word “respect” - it does not seem to be in your vocabulary. Look - you are new here, and you are asking for help, right. Therefore, I think it would be
quite reasonable in your position to keep a low profile if you want to get some help…

Anton Bassov

7

Without all the abrasiveness of Dr Joe, the real issue is that to give the right answer, we need to know the actual problem you’re trying to solve.
“getting the process ID” is the (possibly wrong) solution to the bigger problem. What problem are you solving by finding the process ID?

8

For over the entire life of the old MFC newsgroup, we were treated to some
p-baked “copy protection” scheme about once every two weeks (generally, p
< 0.03). Although this group generally is smart enough to know that
security is hard, we are still treated to the bizarre notions of security
wannabes who propose the most insane–and trivially hackable–“security”
schemes. Usually by someone thinking that you solve the problem with a
minifilter. Of course, they are all completely delusional, and I get
tired of people asking for information that almost always is the first
step in trying to build some p-baked (p < 0.001) “security” solution.
Since the process ID provides absolutely nothing of value to a driver,
except in the context of security or auditing software, where it gives the
illusion that something has been accomplished. Yes, I’m abrasive. I’m
tired of people with no security experience thinking they have The World’s
Best Security Solution. I’ve not seen one yet that I couldn’t crack in
five minutes. I consider such questions, which are almost always couched
as “How do I get the process ID” or “How can I read the CPU serial number”
or any number of similar irrelevant pieces of information that will either
cause valid software to break or be crackable by a skilled 13-year-old, to
be offensive in the extreme. A question of this form which does not say
what the purpose is are usually giveaways that we have a security newbie
in the mix.

I don’t mind people reinventing the wheel, but I do wish they would avoid
quadrilateral wheels with offset shafts (for many years, this was the only
hit you would get if you googled my name; somebody liked it and put it up
with a bunch of other quotes). In 50 years, I not only see the same
mistakes being done, but being repeated every few weeks. That’s the
depressing part.
jor

Without all the abrasiveness of Dr Joe, the real issue is that to give the
right answer, we need to know the actual problem you’re trying to solve.
“getting the process ID” is the (possibly wrong) solution to the bigger
problem. What problem are you solving by finding the process ID?

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

9

I’m not exactly sure we agree on what a “system thread” is in this situation… but does PsGetCurrentProcessId() not work for you?

To be sure we’re both using the term “system thread” the same way, can you please give an example of a callback from which you’re attempting to determine the process context?

As far as Dr. Newcomer’s lectures… I agree they tend to be overly long, sometimes abrasive, and sometimes ill-informed. They are also sometimes very insightful.

Regardless: If you have a post count of 1, you have neither right nor reason to complain about ALMOST any answer you get here. You don’t like somebody’s answer? Just say thank you and ignore it.

Peter
OSR

10

Peter, Alex,

So when I say “system thread” PsGetCurrentProcessId = 0 or 4 and PsIsSystemThread = TRUE

Maybe I should have just said arbitrary thread context instead. I suppose it’s the same issue either way.

For an example, the classifyFn callback in a WFP driver runs in an arbitrary context (a lot seem to be in the system thread though which is why I originally worded it the way I did). When receiving callbacks on the INBOUND/OUTBOUND IPPACKET layer, there is no pID associated with the packet. You can only get that using the ALE layer but if the driver loads after connections are established, there is no way to associate the packet with the process that created it. And other than dropping all connections for them to re-establish to build the {pID=>ip, port} mapping I was thinking the next best way was to determine who owned the originating process.

So it’s not security related but meant for profiling so spoofed pID’s, skilled 13 year olds and abrasively smart guys that hack things in 5 minutes do not concern me.

Thank you.

11

You need to load your WFP driver earlier and create a database using ALE
callbacks. Basically, if you miss the connections as they are created, then
you are toast. (Unless there is some WFP magic that I’m not aware of…).

To start “fairly early” install your driver with start type
SYSTEM_SERVICE_START. Use FwpmBfeStateSubscribeChanges0 to detect when the
BFE engine comes online and start ALE tracking as soon as you detect
FWPM_SERVICE_RUNNING.

There may be ways to begin logging earlier, but I haven’t gone down that
road.

Good luck!

Thomas F. Divine

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Tuesday, January 14, 2014 1:38 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Actual process ID

Peter, Alex,

So when I say “system thread” PsGetCurrentProcessId = 0 or 4 and
PsIsSystemThread = TRUE

Maybe I should have just said arbitrary thread context instead. I suppose
it’s the same issue either way.

For an example, the classifyFn callback in a WFP driver runs in an arbitrary
context (a lot seem to be in the system thread though which is why I
originally worded it the way I did). When receiving callbacks on the
INBOUND/OUTBOUND IPPACKET layer, there is no pID associated with the packet.
You can only get that using the ALE layer but if the driver loads after
connections are established, there is no way to associate the packet with
the process that created it. And other than dropping all connections for
them to re-establish to build the {pID=>ip, port} mapping I was thinking the
next best way was to determine who owned the originating process.

So it’s not security related but meant for profiling so spoofed pID’s,
skilled 13 year olds and abrasively smart guys that hack things in 5 minutes
do not concern me.

Thank you.

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

12

Thanks Thomas. I’ll definitely do the BFE detection route. I was also playing with enumerating the existing ALE endpoints using FwpsAleEndpointEnum0. This gives you the image name, among other things, of the existing endpoint but doesn’t help in differentiating between instances of the same app. Still better than nothing though.

13

You don’t have to wait for BFE to start. Set up boot time filters. These will cover the time before BFE starts.

 

Bill Wandel

 

on Jan 14, 2014, Thomas F. Divine wrote:

You need to load your WFP driver earlier and create a database using ALE
callbacks. Basically, if you miss the connections as they are created, then
you are toast. (Unless there is some WFP magic that I’m not aware of…).

To start “fairly early” install your driver with start type
SYSTEM_SERVICE_START. Use FwpmBfeStateSubscribeChanges0 to detect when the
BFE engine comes online and start ALE tracking as soon as you detect
FWPM_SERVICE_RUNNING.

There may be ways to begin logging earlier, but I haven’t gone down that
road.

Good luck!

Thomas F. Divine

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Tuesday, January 14, 2014 1:38 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Actual process ID

Peter, Alex,

So when I say “system thread” PsGetCurrentProcessId = 0 or 4 and
PsIsSystemThread = TRUE

Maybe I should have just said arbitrary thread context instead. I suppose
it’s the same issue either way.

For an example, the classifyFn callback in a WFP driver runs in an arbitrary
context (a lot seem to be in the system thread though which is why I
originally worded it the way I did). When receiving callbacks on the
INBOUND/OUTBOUND IPPACKET layer, there is no pID associated with the packet.
You can only get that using the ALE layer but if the driver loads after
connections are established, there is no way to associate the packet with
the process that created it. And other than dropping all connections for
them to re-establish to build the {pID=>ip, port} mapping I was thinking the
next best way was to determine who owned the originating process.

So it’s not security related but meant for profiling so spoofed pID’s,
skilled 13 year olds and abrasively smart guys that hack things in 5 minutes
do not concern me.

Thank you.

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer


—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer