Создано: 19 сентября 2012 15:39 New! Цитата · Личное сообщение · #1
I have a foreign process (exe-file DllProj.exe is running), that has SampleDll.dll linked to it (implicit linking). I can find the base address of the linked dll with the help of my function imageBase(), but not the base address of the process itself! What is the difference and why it's not working as is?
I mean, this code returns pBase with correct DOS/NT-headers:
Создано: 19 сентября 2012 19:25 New! Цитата · Личное сообщение · #4
Isn't the process started as suspended and scanned before resuming? If not, try to debug this line: 32. shortName(szModName); And look which modules it actually enumerates. Maybe shortName does not handle exe files properly. Basically, the function is not intended to find process base address, it uses APIs that are designed to enumerate DLLs. For instance, msdn claims that you should pass NULL as module handle to GetModuleFileNameEx in order to obtain main executable file name. You can modify the function to try and send NULL as the module handle.
Создано: 19 сентября 2012 20:06 New! Цитата · Личное сообщение · #6
HandMill writes: You can more easy find base address of loaded module:
GetModuleHandle(TEXT("SampleDll.dll")) - you will find the base of loaded DLL file GetModuleHandle(NULL) - you will find the base of main executable file
No it's not my process, but another program (victim) process. And it states that GetModuleHandle(NULL) returns a handle to the file used to create the calling process... Or there s something I can't understand
ajax writes: HandMill tguglanaklona ?????: I have a foreign process
GetModuleFileNameEx(ProcHandle, hMod[j], szModName, sizeof(szModName))) // Get the module name
returns correct name of the victim exe-file. Perhaps some shifting inside ??? Understand nothing - nothing already in my head Please, help me, what to do Must it works as an idea, or something wrong 'ideologically'?
Создано: 20 сентября 2012 00:36 New! Цитата · Личное сообщение · #9
HandMill EnumProcessModules effectively uses CreateToolhelp32Snapshot. I do not think it will be much different from the used solution.
tguglanaklona What if you send NULL as module handle for the foreign process? Does it work?
A few days ago I was solving a similar problem, I needed to inject a library into another process. But I created the process as suspended, and it was impossible to get modules info using CreateToolhelp32Snapshot for this process. You did not reply whether you create the process suspended and do not resume it before analyzing.
tguglanaklona writes: short name - its my function, its return is OK:
I advised you to debug this line, not the function. Toggle a breakpoint at this line and look what names the program iterates through. If there is no exe file name, something's wrong with EnumProcessModules, consider using CreateToolhelp32Snapshot. If there is the exe file name, something wrong elsewhere. Maybe in GetModuleInformation. Consider using CreateToolhelp32Snapshot, again.
Создано: 22 сентября 2012 18:20 New! Цитата · Личное сообщение · #11
tomac writes: A few days ago I was solving a similar problem, I needed to inject a library into another process. But I created the process as suspended, and it was impossible to get modules info using CreateToolhelp32Snapshot for this process. You did not reply whether you create the process suspended and do not resume it before analyzing.
I think it is the reason. I already come to the same thought. And exe file name and the image base address is really correct (I've catched it with NULL handle), but this tguglanaklona writes: ::IsBadReadPtr(pDosHeader, sizeof(IMAGE_DOS_HEADER)) || IMAGE_DOS_SIGNATURE != pDosHeader->e_magic is not.
Perhaps, the real possibility for the running exe-process is to make an assembler insertion, isn't it