Hi Guys,
I have searched the lists for a solution for this and I could not find a documented way of doing it (even if a documented way is possible).
I have a particular driver that is guaranteed to be within the calling process context. I wan’t to be able to get the current processe’s base address using documented DDK methods. I know that most processes start at 0x4000000 but this is not always the case as im sure you are already aware that the PE header contains the prefered base address. I know that the PEB contains this information, but the PEB is an undocumented struct which I dont not want to use.
Thanks guys,
Joe
How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos. Get Yahoo! Photos
There is no such thing as “process base address”. There is only EXE base address, which is irrelevant for drivers at all.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: Joe Public
To: Windows System Software Devs Interest List
Sent: Monday, June 06, 2005 5:50 PM
Subject: [ntdev] Process base address from driver
Hi Guys,
I have searched the lists for a solution for this and I could not find a documented way of doing it (even if a documented way is possible).
I have a particular driver that is guaranteed to be within the calling process context. I wan’t to be able to get the current processe’s base address using documented DDK methods. I know that most processes start at 0x4000000 but this is not always the case as im sure you are already aware that the PE header contains the prefered base address. I know that the PEB contains this information, but the PEB is an undocumented struct which I dont not want to use.
Thanks guys,
Joe
How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos. Get Yahoo! Photos — Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 You are currently subscribed to ntdev as: xxxxx@storagecraft.com To unsubscribe send a blank email to xxxxx@lists.osr.com
Well you could do it with PsSetLoadImageNotify which will give you the base
address of modules as they load. But the real question here is what are you
trying to do. Using an executable name for secutity is a bad idea (this has
been discussed extensively on this list and ntfsd0 so why do you care what
executable is calling you?
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply
“Joe Public” wrote in message news:xxxxx@ntdev…
> Hi Guys,
>
> I have searched the lists for a solution for this and I could not find a
> documented way of doing it (even if a documented way is possible).
>
> I have a particular driver that is guaranteed to be within the calling
> process context. I wan’t to be able to get the current processe’s base
> address using documented DDK methods. I know that most processes start at
> 0x4000000 but this is not always the case as im sure you are already aware
> that the PE header contains the prefered base address. I know that the
> PEB contains this information, but the PEB is an undocumented struct which
> I dont not want to use.
>
> Thanks guys,
> Joe
>
>
> ---------------------------------
> How much free photo storage do you get? Store your holiday snaps for FREE
> with Yahoo! Photos. Get Yahoo! Photos
I am not interested in analyzing the process name, but I am interested in analyzing the contents of the executable from memory for various reasons. Out of interest being the main one.
But I would prefer to use a legitimate method. I’ll look into the PsSetLoadImageNotify.
Thanks
How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos. Get Yahoo! Photos
Joe Public wrote:
I am not interested in analyzing the process name, but I am
interested in analyzing the contents of the executable from memory
for various reasons. Out of interest being the main one.
If you’re just doing it for educational purposes, you should assume that
all executables start at 0x00400000. This assumption is correct for
approximately 100% of Win32 processes, to at least three decimal places.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Tim Roberts wrote:
> I am not interested in analyzing the process name, but I am
> interested in analyzing the contents of the executable from memory
> for various reasons. Out of interest being the main one.
>
If you’re just doing it for educational purposes, you should assume that
all executables start at 0x00400000. This assumption is correct for
approximately 100% of Win32 processes, to at least three decimal places.
Wow… that’s so wrong I don’t even know where to start. Among other
things, a brief survey with dumpbin shows me that a large majority of
Windows XP’s .exe files are based at 0x01000000.
Mind you, I’m not sure *why* people would choose to rebase a 32-bit
executable (as opposed to a DLL, which is still misguided but
understandable), but a *lot* of them do.
…/ray..
Please remove “.spamblock” from my email address if you need to contact
me outside the newsgroup.
> ----------
From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Ray Trent[SMTP:xxxxx@synaptics.spamblock.com]
Reply To: Windows System Software Devs Interest List
Sent: Tuesday, June 07, 2005 7:29 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Process base address from driver
Wow… that’s so wrong I don’t even know where to start. Among other
things, a brief survey with dumpbin shows me that a large majority of
Windows XP’s .exe files are based at 0x01000000.
Yes, most of EXE files in system32 directory. But there are also strange addresses as 0x4ad00000. Just try:
for %a in (*.exe) dumpbin /headers %a | find “image base”
Mind you, I’m not sure *why* people would choose to rebase a 32-bit
executable
I guess it can be because of some build environment defaults or because of habit when base addresses are stored in one file and people set them for both DLLs and EXEs.
(as opposed to a DLL, which is still misguided but
understandable), but a *lot* of them do.
Why it is misguided? It avoids conflicts and runtime relocation which makes sense for me.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
Ray Trent wrote:
Tim Roberts wrote:
>
> If you’re just doing it for educational purposes, you should assume
> that all executables start at 0x00400000. This assumption is correct
> for approximately 100% of Win32 processes, to at least three decimal
> places.
Wow… that’s so wrong I don’t even know where to start. Among other
things, a brief survey with dumpbin shows me that a large majority of
Windows XP’s .exe files are based at 0x01000000.
Hmmm, you are quite correct. Almost all of the XP system32 exes from
Microsoft start at 0x01000000. That’s a significant change from past
systems.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
On Jun 7, 2005, at 1:20 PM, Michal Vodicka wrote:
> (as opposed to a DLL, which is still misguided but
> understandable), but a *lot* of them do.
>
>
Why it is misguided? It avoids conflicts and runtime relocation
which makes sense for me.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
Questions? First check the Kernel Driver FAQ at http://
www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
On Jun 7, 2005, at 1:20 PM, Michal Vodicka wrote:
> (as opposed to a DLL, which is still misguided but
> understandable), but a *lot* of them do.
>
>
Why it is misguided? It avoids conflicts and runtime relocation
which makes sense for me.
[sorry about the blank post earlier; happy hotkey]
I agree with Michal - any product that ships multiple DLLs would be
wise to keep its own DLLs separate at least - you can’t be sure what
Windows will do with the system DLLs, but at least you can save
yourself guaranteed relocations from your own conflicts. This is
especially important if your DLLs are going to be shared - relocated
DLLs can’t share code pages.
Steve Dispensa wrote:
>> (as opposed to a DLL, which is still misguided but
>> understandable), but a *lot* of them do.
>>
> Why it is misguided? It avoids conflicts and runtime relocation which
> makes sense for me.
Did you ever have one of those days where nothing you say comes out
right? That was a pretty off-hand comment. There’s certainly nothing
wrong with wanting to avoid having your DLLs relocate in circumstances
where you have control over it.
Anyway, I’ll stand by my main point, which is that there’s little reason
to rebase executables that I can see. That doesn’t stop people, though…
I *am* kind of surprised that Microsoft chose the default DLL base
address to rebase all their XP exes to… that seems kind of pessimal,
though I suspect there’s a clever reason for it that I just can’t think of.
There’s at least one case where rebasing your DLLs is especially useful,
which is global hook DLLs. If you think you can find a random unlikely
location to stow one of those, that can be quite beneficial. That’s
annoyingly hard to do, unfortunately. I wish Windows had an install-time
“register me as a common DLL and rebase me to a unique location for this
machine” interface (another off the cuff comment, BTW… I suppose
people would start abusing that if it were there…).
…/ray..
Please remove “.spamblock” from my email address if you need to contact
me outside the newsgroup.
Ray Trent wrote:
I *am* kind of surprised that Microsoft chose the default DLL base
address to rebase all their XP exes to… that seems kind of pessimal,
though I suspect there’s a clever reason for it that I just can’t
think of.
Those EXEs are at the 16 megabyte mark: 0x01000000. DLLs default to the
256 megabyte mark: 0x10000000. No overlap.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.