CreateProcessNotifyEx on Windows XP, Vista and 2003 Server

NTFSD
1

Hi,

I’m experimenting with the PsSetLoadImageNotifyRoutine and PsSetCreateProcessNotifyRoutinEx Hook APIs in kernel mode. I spend some hours to figure out if there are a documented way to get the commande line parameters of the starting process in this callback. CreatProcessNotifyEx works great on Windows 2008 server because it supports PS_CREATE_NOTIFY_INFO with the CommandLine property. Is their any similar things for lower platforms which is documented.

I found some samples which are based on the PEB and ZwQueryInformationProcess, but it’s not documented.

Thanks for your help
regards
Dirk

2

No - traditionally, the kernel has no concept of - and nothing to do with - the idea of a program command line.

It is simply stored at a “well known” place in the user address space (PEB -> PRTL_USER_PROCESS_PARAMETERS), written to and read from entirely by user mode.

Be aware that both of those structures are user mode writable and must never be trusted to contain well-formed (or otherwise valid or correct) data. You must not trust them for any security-sensitive decisions, and you must guard against malformed data structures if you indeed decide to grovel around in them.

Why do you think that you need to munge with the command line in kernel mode? What are you trying to accomplish? There may be a better way.

  • S

-----Original Message-----
From: xxxxx@gmail.com
Sent: Sunday, November 02, 2008 13:02
To: Windows File Systems Devs Interest List
Subject: [ntfsd] CreateProcessNotifyEx on Windows XP, Vista and 2003 Server

Hi,

I’m experimenting with the PsSetLoadImageNotifyRoutine and PsSetCreateProcessNotifyRoutinEx Hook APIs in kernel mode. I spend some hours to figure out if there are a documented way to get the commande line parameters of the starting process in this callback. CreatProcessNotifyEx works great on Windows 2008 server because it supports PS_CREATE_NOTIFY_INFO with the CommandLine property. Is their any similar things for lower platforms which is documented.

I found some samples which are based on the PEB and ZwQueryInformationProcess, but it’s not documented.

Thanks for your help
regards
Dirk

—
NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@valhallalegends.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

but they wouldn’t add the ability to get command line in NT6, if it were
just sick and useless ?

–PA

Skywing wrote:

No - traditionally, the kernel has no concept of - and nothing to do with - the idea of a program command line.

It is simply stored at a “well known” place in the user address space (PEB -> PRTL_USER_PROCESS_PARAMETERS), written to and read from entirely by user mode.

Be aware that both of those structures are user mode writable and must never be trusted to contain well-formed (or otherwise valid or correct) data. You must not trust them for any security-sensitive decisions, and you must guard against malformed data structures if you indeed decide to grovel around in them.

Why do you think that you need to munge with the command line in kernel mode? What are you trying to accomplish? There may be a better way.

  • S

-----Original Message-----
From: xxxxx@gmail.com
> Sent: Sunday, November 02, 2008 13:02
> To: Windows File Systems Devs Interest List
> Subject: [ntfsd] CreateProcessNotifyEx on Windows XP, Vista and 2003 Server
>
>
> Hi,
>
> I’m experimenting with the PsSetLoadImageNotifyRoutine and PsSetCreateProcessNotifyRoutinEx Hook APIs in kernel mode. I spend some hours to figure out if there are a documented way to get the commande line parameters of the starting process in this callback. CreatProcessNotifyEx works great on Windows 2008 server because it supports PS_CREATE_NOTIFY_INFO with the CommandLine property. Is their any similar things for lower platforms which is documented…
>
> I found some samples which are based on the PEB and ZwQueryInformationProcess, but it’s not documented.
>
> Thanks for your help
> regards
> Dirk
>
> —

4

There was some consolidation of process creation interfaces in the Vista timeframe with the introduction of NtCreateUserProcess. This new interface adds a generic extensibility mechanism (property lists), so that we don’t continue having yet another new process creation system service added with every other kernel release.

NtCreateUserProcess moves some of the things that have traditionally been user mode only conventions into the realm of more formally codified kernel-defined interfaces.

However, the old process creation system services still function; in kernel mode, they are wrappers around the new interface. If user mode calls one of the old system services, however, you have the same lack of information as with older kernel versions. (Try writing a program that calls NtCreateProcess and looking at the different data that you get in your PsSetCreateProcessNotifyRoutine callout.)

The bottom line is that much of the extended information accessible from the new-style callouts is only present if the process was created via NtCreateProcess. You must still support callers of the legacy system services, and for those, the story is pretty much the same as it has always been with respect to the new data you get in your notification routine.

  • S

-----Original Message-----
From: Pavel A.
Sent: Monday, November 03, 2008 08:15
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] CreateProcessNotifyEx on Windows XP, Vista and 2003 Server

but they wouldn’t add the ability to get command line in NT6, if it were
just sick and useless ?

–PA

Skywing wrote:
> No - traditionally, the kernel has no concept of - and nothing to do with - the idea of a program command line.
>
> It is simply stored at a “well known” place in the user address space (PEB -> PRTL_USER_PROCESS_PARAMETERS), written to and read from entirely by user mode.
>
> Be aware that both of those structures are user mode writable and must never be trusted to contain well-formed (or otherwise valid or correct) data. You must not trust them for any security-sensitive decisions, and you must guard against malformed data structures if you indeed decide to grovel around in them.
>
> Why do you think that you need to munge with the command line in kernel mode? What are you trying to accomplish? There may be a better way.
>
> - S
>
> -----Original Message-----
> From: xxxxx@gmail.com
> Sent: Sunday, November 02, 2008 13:02
> To: Windows File Systems Devs Interest List
> Subject: [ntfsd] CreateProcessNotifyEx on Windows XP, Vista and 2003 Server
>
>
> Hi,
>
> I’m experimenting with the PsSetLoadImageNotifyRoutine and PsSetCreateProcessNotifyRoutinEx Hook APIs in kernel mode. I spend some hours to figure out if there are a documented way to get the commande line parameters of the starting process in this callback. CreatProcessNotifyEx works great on Windows 2008 server because it supports PS_CREATE_NOTIFY_INFO with the CommandLine property. Is their any similar things for lower platforms which is documented…
>
> I found some samples which are based on the PEB and ZwQueryInformationProcess, but it’s not documented.
>
> Thanks for your help
> regards
> Dirk
>
> —

—
NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@valhallalegends.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

5

Sorry, that should read:

The bottom line is that much of the extended information accessible from the new-style callouts is only present if the process was created via NtCreateUserProcess.

Phone mail client autocompleted the wrong thing.

  • S

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Monday, November 03, 2008 11:25 AM
To: Windows File Systems Devs Interest List
Subject: RE: Re:[ntfsd] CreateProcessNotifyEx on Windows XP, Vista and 2003 Server

There was some consolidation of process creation interfaces in the Vista timeframe with the introduction of NtCreateUserProcess. This new interface adds a generic extensibility mechanism (property lists), so that we don’t continue having yet another new process creation system service added with every other kernel release.

NtCreateUserProcess moves some of the things that have traditionally been user mode only conventions into the realm of more formally codified kernel-defined interfaces.

However, the old process creation system services still function; in kernel mode, they are wrappers around the new interface. If user mode calls one of the old system services, however, you have the same lack of information as with older kernel versions. (Try writing a program that calls NtCreateProcess and looking at the different data that you get in your PsSetCreateProcessNotifyRoutine callout.)

The bottom line is that much of the extended information accessible from the new-style callouts is only present if the process was created via NtCreateProcess. You must still support callers of the legacy system services, and for those, the story is pretty much the same as it has always been with respect to the new data you get in your notification routine.

  • S

-----Original Message-----
From: Pavel A.
Sent: Monday, November 03, 2008 08:15
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] CreateProcessNotifyEx on Windows XP, Vista and 2003 Server

but they wouldn’t add the ability to get command line in NT6, if it were
just sick and useless ?

–PA

Skywing wrote:
> No - traditionally, the kernel has no concept of - and nothing to do with - the idea of a program command line.
>
> It is simply stored at a “well known” place in the user address space (PEB -> PRTL_USER_PROCESS_PARAMETERS), written to and read from entirely by user mode.
>
> Be aware that both of those structures are user mode writable and must never be trusted to contain well-formed (or otherwise valid or correct) data. You must not trust them for any security-sensitive decisions, and you must guard against malformed data structures if you indeed decide to grovel around in them.
>
> Why do you think that you need to munge with the command line in kernel mode? What are you trying to accomplish? There may be a better way.
>
> - S
>
> -----Original Message-----
> From: xxxxx@gmail.com
> Sent: Sunday, November 02, 2008 13:02
> To: Windows File Systems Devs Interest List
> Subject: [ntfsd] CreateProcessNotifyEx on Windows XP, Vista and 2003 Server
>
>
> Hi,
>
> I’m experimenting with the PsSetLoadImageNotifyRoutine and PsSetCreateProcessNotifyRoutinEx Hook APIs in kernel mode. I spend some hours to figure out if there are a documented way to get the commande line parameters of the starting process in this callback. CreatProcessNotifyEx works great on Windows 2008 server because it supports PS_CREATE_NOTIFY_INFO with the CommandLine property. Is their any similar things for lower platforms which is documented…
>
> I found some samples which are based on the PEB and ZwQueryInformationProcess, but it’s not documented.
>
> Thanks for your help
> regards
> Dirk
>
> —

—
NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@valhallalegends.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

6

Thanks, Ken, your comments are so eye opening!

So, on systems that don’t have these new properties, or if they are not
present, we’re up to ZwReadVirtualMemory to get hold of the child
process command line (with due precautions)?

  • PA

Skywing wrote:

Sorry, that should read:

The bottom line is that much of the extended information accessible from the new-style callouts is only present if the process was created via NtCreateUserProcess.

Phone mail client autocompleted the wrong thing.

  • S

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Monday, November 03, 2008 11:25 AM
To: Windows File Systems Devs Interest List
Subject: RE: Re:[ntfsd] CreateProcessNotifyEx on Windows XP, Vista and 2003 Server

There was some consolidation of process creation interfaces in the Vista timeframe with the introduction of NtCreateUserProcess. This new interface adds a generic extensibility mechanism (property lists), so that we don’t continue having yet another new process creation system service added with every other kernel release.

NtCreateUserProcess moves some of the things that have traditionally been user mode only conventions into the realm of more formally codified kernel-defined interfaces.

However, the old process creation system services still function; in kernel mode, they are wrappers around the new interface. If user mode calls one of the old system services, however, you have the same lack of information as with older kernel versions. (Try writing a program that calls NtCreateProcess and looking at the different data that you get in your PsSetCreateProcessNotifyRoutine callout.)

The bottom line is that much of the extended information accessible from the new-style callouts is only present if the process was created via NtCreateProcess. You must still support callers of the legacy system services, and for those, the story is pretty much the same as it has always been with respect to the new data you get in your notification routine.

  • S

-----Original Message-----
From: Pavel A.
> Sent: Monday, November 03, 2008 08:15
> To: Windows File Systems Devs Interest List
> Subject: Re:[ntfsd] CreateProcessNotifyEx on Windows XP, Vista and 2003 Server
>
>
> but they wouldn’t add the ability to get command line in NT6, if it were
> just sick and useless ?
>
> --PA
>
>
> Skywing wrote:
>> No - traditionally, the kernel has no concept of - and nothing to do with - the idea of a program command line.
>>
>> It is simply stored at a “well known” place in the user address space (PEB -> PRTL_USER_PROCESS_PARAMETERS), written to and read from entirely by user mode.
>>
>> Be aware that both of those structures are user mode writable and must never be trusted to contain well-formed (or otherwise valid or correct) data. You must not trust them for any security-sensitive decisions, and you must guard against malformed data structures if you indeed decide to grovel around in them.
>>
>> Why do you think that you need to munge with the command line in kernel mode? What are you trying to accomplish? There may be a better way.
>>
>> - S
>>
>> -----Original Message-----
>> From: xxxxx@gmail.com
>> Sent: Sunday, November 02, 2008 13:02
>> To: Windows File Systems Devs Interest List
>> Subject: [ntfsd] CreateProcessNotifyEx on Windows XP, Vista and 2003 Server
>>
>>
>> Hi,
>>
>> I’m experimenting with the PsSetLoadImageNotifyRoutine and PsSetCreateProcessNotifyRoutinEx Hook APIs in kernel mode. I spend some hours to figure out if there are a documented way to get the commande line parameters of the starting process in this callback. CreatProcessNotifyEx works great on Windows 2008 server because it supports PS_CREATE_NOTIFY_INFO with the CommandLine property. Is their any similar things for lower platforms which is documented…
>>
>> I found some samples which are based on the PEB and ZwQueryInformationProcess, but it’s not documented.
>>
>> Thanks for your help
>> regards
>> Dirk
>>
>> —
>

7

Hi,

thanks for all this great information. In my scenario I want to trace all VB-Script which are performed to execute and normally a cscript.exe or wscript.exe will be started with the right commandline parameter.

What do you think is the best way to get this information? I would prefer a user mode only solution too but currently I see that I have to track the creation of every process.

My first approach was to pass the process id into usermode and resolve the commandline via usermode calls. This idea didn’t worked well, currently I’m not sure why.

thanks again
Dirk

8

Hi Dirk,

there must be a different way to achieve this. Wouldn#t it be possible to set up a mock cscript.exe or even implement those interfaces that are responsible for WSH operation and pass through calls to them?
Or even easier, <hkey_local_machine nt file execution options> and set a REG_SZ or REG_EXPAND_SZ there so the “debugger” gets to see the command line first.

Both of these methods would be pure user mode implementations and the “Image File Execution Options” one is well documented and used, for example, by Process Explorer to replace the Windows Task Manager.

Going into KM seems a bit invasive for such a “trivial” task.

// Oliver

-------- Original-Nachricht --------
> Datum: Mon, 3 Nov 2008 18:01:30 -0500 (EST)
> Von: xxxxx@gmail.com
> An: “Windows File Systems Devs Interest List”
> Betreff: RE:[ntfsd] CreateProcessNotifyEx on Windows XP, Vista and 2003 Server

> Hi,
>
> thanks for all this great information. In my scenario I want to trace all
> VB-Script which are performed to execute and normally a cscript.exe or
> wscript.exe will be started with the right commandline parameter.
>
> What do you think is the best way to get this information? I would prefer
> a user mode only solution too but currently I see that I have to track the
> creation of every process.
>
> My first approach was to pass the process id into usermode and resolve the
> commandline via usermode calls. This idea didn’t worked well, currently
> I’m not sure why.
>
> thanks again
> Dirk

–
---------------------------------------------------
DDKWizard and DDKBUILD: http:

Trunk (potentially unstable) version: http:</http:></http:></hkey_local_machine>

9

Hi Oliver,

thanks for this great idea but I want to get information about batch files also. So my basic idea was to get the information about all process they will be launched. I found the documentation for the KM things.

My goal is to track all process launches and filtering out all launches which are script based this means bat, vbs, python or sth. else.

If there are any usermode ways to figure out this, I will use the usermode way.

Dirk

10

Hi Dirk,

thanks for this great idea but I want to get information about batch files
also. So my basic idea was to get the information about all process they
will be launched. I found the documentation for the KM things.
Does that make a real difference? Since you are matching the “runtime” by name of the executable, there is nothing you couldn’t achieve with setting the “Image Execution Options” and even the argument that an admin could override it wouldn’t work, because an admin could make sure your driver gets never loaded just as well. The difference is that you write one (UM) executable that acts as “debugger” for any and all of the “scripting hosts” you want to cover and register it via a registry key. In KM you make the decision inside your code.

Since it is possible to secure the registry keys from ordinary users I’d know which path to walk :slight_smile:

The only real challenge you may find is, that someone has already registered a “debugger” for the .exe file name you want to register it for.

// Oliver

DDKWizard and DDKBUILD: http:

Trunk (potentially unstable) version: http:</http:></http:>

11

>NT\CurrentVersion\Image File Execution Options\cscript.exe> and set a REG_SZ or

REG_EXPAND_SZ there so the “debugger” gets to see the command line first.

Not this simple, some scripting engines can be in DLLs and not in EXEs.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

12

Maxim,

>NT\CurrentVersion\Image File Execution Options\cscript.exe> and set a
REG_SZ or
>REG_EXPAND_SZ there so the “debugger” gets to see the command line first.
If you read the paragraph before that one, you know that I know :slight_smile:

BTW: In this case the discussed KM approach will be at a loss as well. Which makes it even more questionable to go for it.

// Oliver

DDKWizard and DDKBUILD: http:

Trunk (potentially unstable) version: http:</http:></http:>

13

Filtering out as in blocking, or what?

Have you looked at enabled detailed process tracking auditing in secpol.msc if you just want a record of created processes (goes to the Security event log).

  • S

-----Original Message-----
From: xxxxx@gmail.com
Sent: Tuesday, November 04, 2008 00:31
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] CreateProcessNotifyEx on Windows XP, Vista and 2003 Server

Hi Oliver,

thanks for this great idea but I want to get information about batch files also. So my basic idea was to get the information about all process they will be launched. I found the documentation for the KM things.

My goal is to track all process launches and filtering out all launches which are script based this means bat, vbs, python or sth. else.

If there are any usermode ways to figure out this, I will use the usermode way.

Dirk

—
NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@valhallalegends.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

14

Several points here as to why this isn’t a good idea -IF- you are using this to do a security-sensitive sort of decision:

  • Image File Execution Options is a user mode only construct that is implemented by kernel32. Thus, any process can evade any sort of trouble there by just patching out the logic to handle IFEO in kernel32, or simply creating the process using a different name.
  • By default, you can rename away an executable and swap another in its place while it’s mapped as an image section, as kernel32/ntdll open exe/dll images with FILE_SHARE_DELETE.

Of course, as to how bad these problems are really depends on what the OP is actually trying to accomplish with monitoring script host programs launching.

  • S

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Oliver Schneider
Sent: Tuesday, November 04, 2008 3:03 AM
To: Windows File Systems Devs Interest List
Subject: Re: RE:[ntfsd] CreateProcessNotifyEx on Windows XP, Vista and 2003 Server

Hi Dirk,

thanks for this great idea but I want to get information about batch files
also. So my basic idea was to get the information about all process they
will be launched. I found the documentation for the KM things.
Does that make a real difference? Since you are matching the “runtime” by name of the executable, there is nothing you couldn’t achieve with setting the “Image Execution Options” and even the argument that an admin could override it wouldn’t work, because an admin could make sure your driver gets never loaded just as well. The difference is that you write one (UM) executable that acts as “debugger” for any and all of the “scripting hosts” you want to cover and register it via a registry key. In KM you make the decision inside your code.

Since it is possible to secure the registry keys from ordinary users I’d know which path to walk :slight_smile:

The only real challenge you may find is, that someone has already registered a “debugger” for the .exe file name you want to register it for.

// Oliver

DDKWizard and DDKBUILD: http:

Trunk (potentially unstable) version: http:

—
NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@valhallalegends.com
To unsubscribe send a blank email to xxxxx@lists.osr.com</http:></http:>

15

Skywing has already detailed why this isn’t secure and how it can be circumvented. If you’re just
interested in preventing scripts from running, how about either uninstalling or locking down the
interpreters involved? That is, don’t install perl, et. c. If you can’t control that, then this is
all a waste of time.

Good luck,

mm

xxxxx@gmail.com wrote:

Hi Oliver,

thanks for this great idea but I want to get information about batch files also. So my basic idea was to get the information about all process they will be launched. I found the documentation for the KM things.

My goal is to track all process launches and filtering out all launches which are script based this means bat, vbs, python or sth. else.

If there are any usermode ways to figure out this, I will use the usermode way.

Dirk