views:

674

answers:

3

I created a child process from within my process with CreateProcess() (in C++) I then continue on using ReadProcessMemory to read through the memory and search for a specific something.

I would like to start my search from the entry point of that process , since the process is loaded into it's own virtual space I have no idea at this point how to find out the entry point for the code itself(I dont care about other sections of the PE file), I am aware of the 'AddressOfEntryPoint' field of the PE format and I already have it but since I have no idea at what address that process would be loaded how can I calculate the entry point itself?

to demonstrate what I want , if you open a process with OllyDbg for example you immediately reach the entry point for the code , I want to have that address

remember that this is a child process that I created if it helps

let me mention that I do not want to inject any code or DLL into that application the find out that address

A: 

I don't know exactly BUT...As far as i know can you finde the EntryPoint Address in the PE header of the .exe/.dll

or .... it is a fixed one

that's all i remenber

A: 

AddressOfEntryPoint is relative to image base address (ImageBase member of same IMAGE_OPTIONAL_HEADER struct). For executables image base is almost always whatever is set in PE header, since every executable has its own virtual address space.

In fact exes with stripped relocation sections can be loaded only at base that is in PE.

I'm not sure if there are exceptions and if it is possible to retrieve image base of running process...

Eugene
I was aware of that fact but I have tested against some processes , mainly the one I am trying to work on as the image base is:00400000 and the entry point is at :0000311DI would expect it to be at 0040311Dbut when I use ollydbg to view the real entry point of code I get:010E311Dhow was that accomplished?
Hm, tested on random executable in ollydbg and it works. Maybe only for some exes though...
Eugene
Does ollydbg says image base is 00400000?
Eugene
Funny you mention it , I just checked as OllyDbg says the ImageBase is: 010E0000 while any other PE editing file or just a code I use for checking specify ImageBase as : 00400000 If I could calculate as Ollydoes that would be helpful but how does it know what the other software dont?I just checked with a few other dissassemblers they all start the EP as 0040311D which is correct based on the PE header , problem is when I try to read that address with my code I get an error but when I read 010E311D which is Olly's address I get the write bytes that are present at the EP.
Check some other debugger (not dissassembler), and see where will it enter. I wonder if exe is packed and ollydbg is smart enough to show you entry point after unpacking is complete? If other debugger enters at 0040311D, trace through a bit and see if it will jump to 010E311D after doing stuff...
Eugene
(Although I think this is opposite of what you should see with packed exes, entry point should be something weird and then jump to 0400000-something, I'm not sure though)
Eugene
The file is not packed , I have checked. The Entry Point points to 00400000 , something else I have checked , I have used LordPE again to check for the PE Header, when the EXE file itself is loaded I see the ImageBase is 00400000 , when I open the process and I look in LordPE's process list the ImageBase is 00A40000(notice the address has changed , I have checked in Olly and it is 00A40000 as well), when I open the EXE file the desired ImageBase is 00400000 but when the process opens it allocates at this address , how does OllyDbg and LordPE now that address , how can I find it out?
I forgot to mention , and I know it's a big detail , that I am running Vista , I just remembered about ASLR and as I suspected my compiler was compiling the test exe with ASLR enabled , I disabled it and it loaded into 00400000 every time , but when ASLR was enabled OllyDbg still knew the real address , I want to find out the address even if ASLR is enabled , any suggestions?
You might have to use some debug API since those apparently do work. Not sure if it would work for you purpose.
Eugene
+1  A: 

Use PSAPI's GetModuleInformation with an HMODULE of NULL. This will give you executable's entry point as well as total size in memory (unfortunately, the base address is not set.)

Note that the entry point isn't necessarily the main() function - it is probably the CRT's entry point which in turn calls your main().

You can also use EnumProcessModules to get all modules in the process and their base addresses.

Michael
+1. Note however that `GetModuleInformation` won't return the base address of the module (I didn't even find any documentation stating that you can pass 0 as HMODULE. Is it guaranteed to work?). You'll probably have to call `EnumProcessModules`.
avakar
@avakar - It appears to work, at least on my machine and version of Windows. EnumProcessModules first would help guarantee it is working.
Michael
I tried both GetModuleInformation and EnumProcessModules , both did not work , EnumProcessModules returned as an error with no specific information , something that did not seem related to the function,when I used GetModuleInformation with the HMODULE as NULL I recieved a structure that was filled with 0xccccccc values which are not very helpful
@ratata, please post your code trying to use GetModuleInformation, this should work.
Michael
<pre> if (!CreateProcess(NULL,"c:\\test.exe",NULL,NULL,TRUE,CREATE_SUSPENDED,NULL,NULL, return 0; } HANDLE hProcess = pi.hProcess; MODULEINFO mi; GetModuleInformation(hProcess,NULL,</pre>I have skipped all the CreateProcess related stuff , the process is created I am sure of that , for my needs I need it to be created as suspended by I tried creating it to open regulary and got the same results, I get an error 6 which says: "Invalid Handle Value" , maybe im getting something wrong
Actually, you might need the process to be running a bit for this to work - GetModuleInformation needs to inspect the loaded modules list which is probably initialized in-process.
Michael
thx but it did not help