Hi,
Is there a reasonably future proof way of getting the location of the PEB32 within a 32-bit process running under the WoW64 emulator? I need it to access the environment variables of the process. If not, would it be reasonable to assume that the PEB32 is always one page earlier than the PEB64?
>I need it to access the environment variables of the process.
What do you need that for in a driver?
If not, would it be reasonable to assume that the PEB32 is always one page
earlier than the PEB64?
That’s an implementation detail, so it’s subject to change. The PEB is in
user space and thus isn’t something that drivers are supposed to mess around
with (or care about). You also have to worry about security and reliability
issues when dealing with the PEB since it’s in user space, meaning it’s
changeable from UM.
-scott
–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com
wrote in message news:xxxxx@ntdev…
> Hi,
>
> Is there a reasonably future proof way of getting the location of the
> PEB32 within a 32-bit process running under the WoW64 emulator? I need it
> to access the environment variables of the process. If not, would it be
> reasonable to assume that the PEB32 is always one page earlier than the
> PEB64?
>
Are you writing a debugger in user mode?
I know of no strictly documented (== supported and will remain stable) way to do this in a direct fashion.
Furthermore, please keep in mind that the layout of struct _PEB is by no means considered an interface contract of Win32, and can change without warning.
This might be acceptable for a debugger that uses data in type-added PDBs (but this *still* does not make it a supported contract). I would not ship any other type of tool which relied on this information, and even then, understand the fragility you are incurring.
-----Original Message-----
From: xxxxx@gmail.com
Sent: Monday, July 20, 2009 02:15
To: Windows System Software Devs Interest List
Subject: [ntdev] PEB32 of WoW64 process
Hi,
Is there a reasonably future proof way of getting the location of the PEB32 within a 32-bit process running under the WoW64 emulator? I need it to access the environment variables of the process. If not, would it be reasonable to assume that the PEB32 is always one page earlier than the PEB64?
—
NTDEV is sponsored by OSR
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
Actually, I am using environment variables as a kind of marker which the user mode program can set or unset to communicate with the driver, and which is also propagated down the process tree. If anyone knows of a good alternative to this I am willing to use that. Otherwise this is the best solution I have come up with.
> Actually, I am using environment variables as a kind of marker which the
user mode program can set or unset to communicate with the >driver
Define a set of custom IOCTLs and use those instead.
-scott
–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com
wrote in message news:xxxxx@ntdev…
> Actually, I am using environment variables as a kind of marker which the
> user mode program can set or unset to communicate with the driver, and
> which is also propagated down the process tree. If anyone knows of a good
> alternative to this I am willing to use that. Otherwise this is the best
> solution I have come up with.
>
The key though is that the application might not know anything about the driver, and the environment variable setting automatically propagates to child processes.
xxxxx@gmail.com wrote:
The key though is that the application might not know anything about the driver, and the environment variable setting automatically propagates to child processes.
IMHO this sort of relations between drivers and apps
is not supported by any known “device experience” scenarios
(maybe besides of something DRM-ish).
So there is no blessed and supported way to achieve this.
–pa
Maintain the process parent/child relationship in the driver using the create process notify routine.
Anyway this is not a Windows way of doing things. Probably it is much better to update the apps so they will call some IOCTL and pass the proper env vars there just after opening a driver.
You can do this trivially by moving the “open driver” routine to a DLL.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntdev…
> The key though is that the application might not know anything about the driver, and the environment variable setting automatically propagates to child processes.
>
This is neither a supported nor robust approach.
If you must track a process tree for which you do not have code integration for, I would recommend the usage of one of the CreateProcess notification callbacks that PS provides (e.g. PsSetCreateProcessNotifyRoutine).
-----Original Message-----
From: xxxxx@gmail.com
Sent: Monday, July 20, 2009 08:24
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] PEB32 of WoW64 process
Actually, I am using environment variables as a kind of marker which the user mode program can set or unset to communicate with the driver, and which is also propagated down the process tree. If anyone knows of a good alternative to this I am willing to use that. Otherwise this is the best solution I have come up with.
—
NTDEV is sponsored by OSR
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
Sorry, but I do not control the source code of those apps.
If I recall correctly the create process notify routine solution has a limit on the number of handlers. I think for XP that limit is 8, but I can’t find where I read that.
In the end I just chose my solution as it’s more flexible and has been very reliable so far, only needing to be updated for x64 which I’m doing right now. And for that I am locating the PEB32 at PEB64-PAGE_SIZE, which is working fine. The user space path to get the environment only seems to have changed in the transition from 32 to 64 bit anyway.
> Sorry, but I do not control the source code of those apps.
Yes, you have some problems in your team.
Do you understand that, by allowing you to control these apps, your management can reduce the overall man*hours to realize the feature several times? or your management is not concerned about man*hours? sorry, I never saw such management 
Apps must be patched first to implement the feature, just because this is easier in man*hours. Only then the drivers.
In the worst case, you can inject a DLL to all apps in question just to call the documented routines about the environment and then some IOCTL.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Maxim, these apps could be anything. My driver is a minifilter and does some stuff with IO_REPARSE to rewrite the filename. So not even DLL injection is an option.
I think you already know this, but there’s no guarantee that the environment will be inherited by child processes.
This is very fragile.
mm
xxxxx@evitechnology.com wrote:
I think you already know this, but there’s no guarantee that the environment will be inherited by child processes.
This can’t really be what you meant to say. Unless you specifically
provide a replacement environment in the CreateProcess call, your
environment WILL be inherited by child processes.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Apps can trash their PEB or environment block, and these structures and fields are completely undocumented and subject to breakage without notice. Are you even running into the limit on downlevel platforms?
My gut reaction is that you’re making absolutely the wrong tradeoff here, going way off into undocumented land and putting yourself at the mercy of user mode untrusted code.
-----Original Message-----
From: xxxxx@gmail.com
Sent: Monday, July 20, 2009 09:41
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] PEB32 of WoW64 process
Sorry, but I do not control the source code of those apps.
If I recall correctly the create process notify routine solution has a limit on the number of handlers. I think for XP that limit is 8, but I can’t find where I read that.
In the end I just chose my solution as it’s more flexible and has been very reliable so far, only needing to be updated for x64 which I’m doing right now. And for that I am locating the PEB32 at PEB64-PAGE_SIZE, which is working fine. The user space path to get the environment only seems to have changed in the transition from 32 to 64 bit anyway.
—
NTDEV is sponsored by OSR
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
…which follows perfectly with mm’s statement that there’s no *guarantee* that the environmental variables will be inherited.
-----Original Message-----
From: Tim Roberts
Sent: Monday, July 20, 2009 15:34
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] PEB32 of WoW64 process
xxxxx@evitechnology.com wrote:
> I think you already know this, but there’s no guarantee that the environment will be inherited by child processes.
>
This can’t really be what you meant to say. Unless you specifically
provide a replacement environment in the CreateProcess call, your
environment WILL be inherited by child processes.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
—
NTDEV is sponsored by OSR
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
No, that’s what I meant to say - he doesn’t have control over the applications in question, so it’s something he should consider, in my opinion. It’s not likely, but it’s possible and it does happen.
mm
>My gut reaction is that you’re making absolutely the wrong tradeoff here, going way off into >undocumented land and putting yourself at the mercy of user mode untrusted code.
+1
mm
“Skywing” wrote in message
news:xxxxx@ntdev…
> Apps can trash their PEB or environment block, and these structures and
> fields are completely undocumented and subject to breakage without notice.
> Are you even running into the limit on downlevel platforms?
>
> My gut reaction is that you’re making absolutely the wrong tradeoff here,
> going way off into undocumented land and putting yourself at the mercy of
> user mode untrusted code.
>
> - S
But the OP has a minifilter. This changes the sitiuation?
A big percentage of these FS filters are weird creations made to
satisfy weird requirements. So… this is just another one.
One just can’t come with a sane and clean solution when requirements are
insane.
–pa
> -----Original Message-----
> From: xxxxx@gmail.com
> Sent: Monday, July 20, 2009 09:41
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] PEB32 of WoW64 process
>
>
> Sorry, but I do not control the source code of those apps.
> If I recall correctly the create process notify routine solution has a
> limit on the number of handlers. I think for XP that limit is 8, but I
> can’t find where I read that.
> In the end I just chose my solution as it’s more flexible and has been
> very reliable so far, only needing to be updated for x64 which I’m doing
> right now. And for that I am locating the PEB32 at PEB64-PAGE_SIZE, which
> is working fine. The user space path to get the environment only seems to
> have changed in the transition from 32 to 64 bit anyway.
>
> —
> NTDEV is sponsored by OSR
>
> 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
>