I have Enumulate all the running process,
How can I get the baseaddress of the running
process？

base adrress ?? imagebase of the process ?? GetModuleHandle() returns the imagebase
hope thats what you are looking for ??

I use GetModuleHaneleA(FProcessEntry32.szExeFile);
return value of the first Process and the lasr process
is right,the others is null.Why?
Have any other way to get the baseaddress

hi,

if you use Process32First() and Process32Next() to enumerate the process, the structure filled by these APIs have a member that hold the base address

if you use GetModuleHandleA(), only the base address of modules mapped in your current process show

ancev

Of all the 32-bit PEs I have seen, the base address is 400000. Safe assumption to make. Of course, you can always open the file on the disk and read the PE header...

True for almost every PE, except "dll one" and some .exe in system32 directory '-'

Not necessarily, take a look at the attached nspacked file, base address of 10000000. What's interesting, besides the packer itself, is that PE tools such as LordPE etc., when viewing running processes, as well as OllyDbg *when attaching to the process*, report the WRONG base address of 400000.

This may indicate that psapi itself makes the *assumption* that all exe modules will be loaded at 400000 (I'm assuming that most of these PE editors use psapi). If this is the case, why in hell doesn't psapi just read the friggin' PE header?

I'm not sure which of the other methods would be more reliable, maybe you can test with this file. In fact, the file itself could make a nice mini-project (moderator?)

Kayaker

So are there any circumstances under which the operating system will load an exe at a base address different to that specified in the PE header?

well almost all exes dont have reloc section or have those reloc sections stripped so it would invariably fail to load
or would crash in runtime if it loaded

Question: What would be the USE of an exe that load with a base address different from 40000000?

What happens when you load two exe files (not simultanously, one loads the other) in the same memory context? do they share the base address or one of them gets relocated.

well best kind of example would be to create a standalone exe insted of plugin to ollydbg (no dllinit blah blah)
and then when you try to debug it you will see ollydbg would vie for the same address viz 0x4000000 and since it was occupied already the loader would try to relocate it and during relocation you will see a debug message
saying since blah blah is not dll failed to relocate the image and then would crash miserably and actually while debugging such an application
the crash is in very very early stages (not even peb is filled and exactly no memory sections are initialised (uses some LoaderLock Acquire blah blah code in ntdll if you set a break here it would never break in the normal course of things )

Now I know why they call you blabberer

they ? who ?

I think that "0x400000" is just one choice of image base, (any???%64k o_o''') other are possible. If the loader can load at the image base (and for ".exe" file it always happen i think) no relocation is needed.

If a pe "load" somehow (usually a dll via LoadLibrary) another pe file and base addresses clash the second pe must be relocated using information in the relocation directory of the pe file.

'-'

Small edit to fix the any?? above ^^

Under Windows Xp every base address between 0x10000<=base<=0x7ffd0000 (in 64k multiple of course) is "valid" (the small application used as a test linked and ran successfully)

But for value between 0x10000 and 0x400000 the linker complained

C:\masm32\src>..\bin\LINK.EXE /base:0x10000 b.obj /subsystem:windows
Microsoft (R) Incremental Linker Version 5.12.8078
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

LINK : warning LNK4096: /BASE value "10000" is invalid for Windows 95; image may not run

o_o''

Yes, and just like blabberer possibly tries to convey above , if the second exe file lacks relocation info (as is often the case for normal exe files) the loading will fail if the recommended address range of the second module intersects with the address range of the first one.

The little red men that live inside my computer screen.
They tell me what to write and what to think

What do you mean by "load"? If you mean one .exe runs the other .exe (via CreateProcess(...), etc.), then they use two different process-space memory contexts, so there's not even a chance for a collision within a single process. If you mean "load" as in LoadLibrary(...), then yes, they are relocated just like DLLs.

POC code:



Output:

haha the blah blah does have its effect powerfully it seems

instead of possibly trying to convey
i would try to state as facts

loading as in using CreateProcess,WinExec,ShellExecute,and other
variation does not count for image relocation problems because a new process is spawned and the clashes do not occur

an exe compiled normally does not have relocation information

an exe can have export section and it can export functions (plugins architecture relies on these export function from an exe)
a dll also has export sections and it also exports functions

so a .lib can be produced for both of them

and in simple masm terms
includelib "//yourpath//yourthuscreatedlib"

start
push params
call the exported function from exe
end start

would
assemble without problems

now running this without the exe in path would say the application is
linked to some such dll that cannot be found so cannot continue
because of missing application now you would drag and drop the exe
to the path and double clicking it would eliminate the missing dll problem
but would exit silently (not even the standard windows need to terminate
the application box that would appear normally on misbehaving application would be shown)

and if you try to debug it to find the cause of mysterious disaapperance
you can easily find the imagebase address clash as the exe is loaded in 0x4000000 already and during import resolution the windows loader tries to load the application find a clash of address tries to relocate would map it successfully to a different address but since there is no relocation information it would emit a debug message which basically would mean

yeah i have relocated this clashing crap but it doesnt have full info to help me rehabilitate it so i just reloacted it to a mental hospital runnning under social security may bite if you go near so take care while dealing with it have your prods ready and easily accesible

whereas the dll having reloc info would be successfully relocated
and would work flawlessly

i actually created some plugin to ollydbg as standalone exe because
it was easier for me to debug them at some stages
a standlone didnt need to load ollydbg on ollydbg and then set break on action and have the comments erased becuse a new compiled exe has a different crc and time stamp so the udd is discarded