The PEB layout is fairly stable now, although technically you should
never make assumptions about it -- it's strictly an OS internal
structure, and you are tying your driver to an OS version, in a manner
that will likely cause problems later, if the layout changes.
Personally, I would go ahead and use the CommandLine stuff from the PEB.
However, you're doing it wrong. If you are writing this function to run
in k-mode, you must first attach to the process (in order to map its VM
address space), and you must use appropriate means to safely lock and
probe user-mode pages. All of the PEB, including the CommandLine field
and the string data that CommandLine.Buffer refers to, are stored in
user-mode data pages, not in kernel-mode. Simply dereferencing a
user-mode pointer in kernel-mode gets you an automatic F. There are
lots of references on how to safely read user-mode data.
If you do this, you MUST do some strict validation on the string length,
etc., so that you stand a chance of being a well-behaved driver, if your
driver gets loaded on a platform where CommandLine has changed or moved.
-- arlie
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of System
Sent: Friday, September 19, 2003 2:51 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: Peb is zero .. even if PsLookupProcessByProcessId
returns ok ..
Dan
the PID I am passing to this function is of a user mode process, that is
why I expected a pointer to the user mode Ped to be returned.
>Also, you should treat an EPROCESS as a opaque data type and not reads
directly from it.
ok .. but I really need the command line (long story) .. any other
suggestion .. or tip on how I should proceed?
thanks,
Marco
System ( S_1_5_18 at hotmail.com )
"Dan Partelly" wrote in message
news:xxxxx@ntdev...
>
> A system thread is created in context of system process. Which dont
> have
any
> kind of user mode control structures, hence not PEB. There are not
> documented ways to do what you want from kernel mode. Also, you should
treat
> an EPROCESS as a opaque data type and not reads directly from it.
>
> Dan
>
> ----- Original Message -----
> From: "System"
> Newsgroups: ntdev
> To: "Windows System Software Devs Interest List"
> Sent: Friday, September 19, 2003 2:05 AM
> Subject: [ntdev] Peb is zero .. even if PsLookupProcessByProcessId
> returns ok ..
>
>
> > Hi everybody,
> >
> > this is my second attempt at getting some help in extracting the
> > command line parameters from a running process, this time with code.
> > I have done
> my
> > homework but I am a new to systems programming .. and I am stuck!
> >
> > The following code gets invoked from a thread
> > (PsCreateSystemThread). PsLookupProcessByProcessId seems to succeed
> > but the Peb is set to zero
..
> > any idea?
> >
> > ps: when PsLookupProcessByProcessId returns the value of "proc" is
struct
> > _EPROCESS * 0xffa32880
> >
> > void GetCommandLineFromPID (void p)
> > {
> > PIDex * const pid = (PIDex)p; (PIDex is a simple struct )
> >
> > WCHAR* cmd;
> > PEPROCESS proc = 0;
> > PPEB peb = 0;
> >
> > pid->st = PsLookupProcessByProcessId ((PVOID)pid->pid, &proc);
> >
> > if (NT_SUCCESS(pid->st)) // st returns ok
> > {
> > peb = proc->Peb;
> >
> > if (peb != 0) // this is NOK -- peb is always zero
> > {
> > cmd = (WCHAR *)peb->ProcessParameters->CommandLine.Buffer;
> >
> > if (cmd != 0)
> > DbgPrint( "[%lxh] Command Line: %ws\n", CT, cmd );
> > }
> >
> > ObDereferenceObject(proc);
> > }
> >
> > KeSetEvent(&pid->evt, 6, FALSE); PsTerminateSystemThread(0);
> > }
> >
> > --
> > Marco
> >
> >
> >
> > ---
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@rdsor.ro To
> > unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
>
---
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@sublinear.org To
unsubscribe send a blank email to xxxxx@lists.osr.com