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:

but this code return is FALSE:

Here is my procedure:

P.S.: My next goal is to get import-table of DllProj.exe (where Sample.dll is) and hiijack dll's function call

| Сообщение посчитали полезным:

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

-----
все багрепорты - в личные сообщения

| Сообщение посчитали полезным:

HandMill
tguglanaklona пишет:
I have a foreign process

-----
От многой мудрости много скорби, и умножающий знание умножает печаль

| Сообщение посчитали полезным:

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.

| Сообщение посчитали полезным:

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

?? ??? ?? ????? ?? ??? ??????? main, ? ?????, ??????????? ? ???????. ??? ? ???-?? ?? ??????? ? ?????? GetModuleHandle..

ajax writes:
HandMill
tguglanaklona ?????:
I have a foreign process

?? ??-?? ??))

tomac writes:
32. shortName(szModName);

short name - ??? ???????, ?????????? ??? ????? (??????, ?????? ????????):

void shortName(LPSTR strToChange)
{
std::string path(strToChange);
std::string filename;

size_t pos = path.find_last_of("\");
if (pos != std::string::npos)
filename.assign(path.begin() + pos + 1, path.end());
else
filename = path;

lstrcpy(strToChange, filename.data());
}

? ?????????
GetModuleFileNameEx(ProcHandle, hMod[j], szModName, sizeof(szModName))) // Get the module name
?????????? ?????? ??? exe-????????, ? DOS-????? ??? ????? ? ?????????? ????????????. ????? ??? ???????? ??? ?????? ?????? ??-???????? ?? ???????.

| Сообщение посчитали полезным:

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

Yyyyyyes))

tomac writes:
32. shortName(szModName);

short name - its my function, its return is OK:

void shortName(LPSTR strToChange)
{
std::string path(strToChange);
std::string filename;

size_t pos = path.find_last_of("\");
if (pos != std::string::npos)
filename.assign(path.begin() + pos + 1, path.end());
else
filename = path;

lstrcpy(strToChange, filename.data());
}

Also (see prog listing)

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'?

| Сообщение посчитали полезным:

tomac writes:
You can modify the function to try and send NULL as the module handle.

If I sent NULL and for not victim but my procwss - everything is OK!

| Сообщение посчитали полезным:

So, may be this example will help you: http://msdn.microsoft.com/en-us/library/windows/desktop/ms686701(v=vs.85).aspx
Look to the MODULEENTRY32.modBaseAddr
when you will list all modules you will also list main process module(exe)

-----
все багрепорты - в личные сообщения

| Сообщение посчитали полезным:

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.

| Сообщение посчитали полезным:

tguglanaklona
Check --> Link <--. Delphi code, but easy to port to C
function LoadedModulesList(const List: TStrings; ProcessID: DWORD; HandlesOnly: Boolean): Boolean;

-----
От многой мудрости много скорби, и умножающий знание умножает печаль

| Сообщение посчитали полезным:

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

Anyway I'll go to analyse it further

| Сообщение посчитали полезным: