Re: [PATCH 1/2] ntoskrnl.exe: Implement IoGetCurrentProcess and KeGetCurrentThread.

[Dmitry Timoshkov]

Christian Costa <titan.costa(a)gmail.com> wrote:
> PEPROCESS WINAPI IoGetCurrentProcess(void)
>  {
> -    FIXME("() stub\n");
> -    return NULL;
> +    TRACE("()\n");
> +
> +    /* Return current process id since PEPROCESS is opaque and drivers should not access the struct directly */
> +    return (PEPROCESS)PsGetCurrentProcessId();
>  }

The returned pointer is supposed to be passed to various other ntoskrnl APIs,
and it's needs to be a valid pointer to the kernel object. Besides many not
trivial kernel drivers (if not all) really dig into internal kernel structures.

Same for KeGetCurrentThread.

-- 
Dmitry.

[PATCH 1/2] ntoskrnl.exe: Implement IoGetCurrentProcess and KeGetCurrentThread.

[Paul Chitescu]

On Thursday 04 October 2012 08:25:13 am Dmitry Timoshkov wrote:
> Christian Costa <titan.costa(a)gmail.com> wrote:
> > PEPROCESS WINAPI IoGetCurrentProcess(void)
> >  {
> > -    FIXME("() stub\n");
> > -    return NULL;
> > +    TRACE("()\n");
> > +
> > +    /* Return current process id since PEPROCESS is opaque and drivers
> > should not access the struct directly */ +    return
> > (PEPROCESS)PsGetCurrentProcessId();
> >  }
>
> The returned pointer is supposed to be passed to various other ntoskrnl
> APIs, and it's needs to be a valid pointer to the kernel object. Besides
> many not trivial kernel drivers (if not all) really dig into internal
> kernel structures.
>
> Same for KeGetCurrentThread.

AFAIK the structure differs for each major version of Windows and some SP too.

At the minimum I saw some drivers expecting that at the returned pointer to be 
a "System" C-style string.

I tried submitting a patch before but was not accepted.

[PATCH 1/2] ntoskrnl.exe: Implement IoGetCurrentProcess and KeGetCurrentThread.

[Christian Costa]

2012/10/4 Paul Chitescu <paulc(a)voip.null.ro>
> On Thursday 04 October 2012 08:25:13 am Dmitry Timoshkov wrote:
> > Christian Costa <titan.costa(a)gmail.com> wrote:
> > > PEPROCESS WINAPI IoGetCurrentProcess(void)
> > >  {
> > > -    FIXME("() stub\n");
> > > -    return NULL;
> > > +    TRACE("()\n");
> > > +
> > > +    /* Return current process id since PEPROCESS is opaque and drivers
> > > should not access the struct directly */ +    return
> > > (PEPROCESS)PsGetCurrentProcessId();
> > >  }
> >
> > The returned pointer is supposed to be passed to various other ntoskrnl
> > APIs, and it's needs to be a valid pointer to the kernel object. Besides
> > many not trivial kernel drivers (if not all) really dig into internal
> > kernel structures.
> >
> > Same for KeGetCurrentThread.
>
> AFAIK the structure differs for each major version of Windows and some SP
> too.

I was expecting something like this. :(
> At the minimum I saw some drivers expecting that at the returned pointer
> to be
> a "System" C-style string.

Which windows version it is ? In Vista definition the first basic element
can be either an UCHAR or an ULONG. Not a char buffer.
> I tried submitting a patch before but was not accepted.

[PATCH 1/2] ntoskrnl.exe: Implement IoGetCurrentProcess and KeGetCurrentThread.

[Thomas Faber]

On 2012-10-04 13:07, Christian Costa wrote:
> 2012/10/4 Paul Chitescu <paulc(a)voip.null.ro>
> > AFAIK the structure differs for each major version of Windows and some SP
> > too.
>
> I was expecting something like this. :(
> > At the minimum I saw some drivers expecting that at the returned pointer
> > to be
> > a "System" C-style string.
>
> Which windows version it is ? In Vista definition the first basic element
> can be either an UCHAR or an ULONG. Not a char buffer.

What all versions have in common is that processes are dispatcher
objects. Thus the EPROCESS/KPROCESS structure starts with a
DISPATCHER_HEADER.

[PATCH 1/2] ntoskrnl.exe: Implement IoGetCurrentProcess and KeGetCurrentThread.

[Christian Costa]

2012/10/4 Thomas Faber <thfabba(a)gmx.de>
> On 2012-10-04 13:07, Christian Costa wrote:
> > 2012/10/4 Paul Chitescu <paulc(a)voip.null.ro>
> > > AFAIK the structure differs for each major version of Windows and some
> > > SP
> > > too.
> >
> > I was expecting something like this. :(
> > > At the minimum I saw some drivers expecting that at the returned pointer
> > > to be
> > > a "System" C-style string.
> >
> > Which windows version it is ? In Vista definition the first basic element
> > can be either an UCHAR or an ULONG. Not a char buffer.
>
> What all versions have in common is that processes are dispatcher
> objects. Thus the EPROCESS/KPROCESS structure starts with a
> DISPATCHER_HEADER.

I known. And in DISPATCHER_HEADER, the first type can be either an UCHAR or
an ULONG.

That said I found why your patch works for you :
> The process name offset can be founded form peprocess but you should
> write a simple code.
> First of all call PsGetCurrentProcess() to achieve the address of
> peprocess of current process then search for the string "System"
> in the increasing offsets form peprocess. If you find "System " string ,
> the related offset is the name offset.

Found at http://www.osronline.com/showthread.cfm?link=157240

So "system" should be elsewhere in the structure. Probably ImageFileName.