Log in

View Full Version : Enumerating 32-bit modules from an x64 application


TiGa
February 22nd, 2008, 02:16
I'm trying to enumerate the modules of a remote 32-bit process running under WoW64 emulation from an x64 application.
On their respective architecture, everything is fine.

I tried with EnumProcessModules and CreateToolhelp32Snapshot but both only list the WoW64 modules (ntdll.dll, wow64.dll, wow64win.dll, wow64cpu.dll) and my goal is to get the same results I would get from the 32-bit build.

Is there any way to break through that WoW64 barrier?
The real modules should be kept somewhere if the 32-bit version can get them.

TiGa

Squallsurf
February 22nd, 2008, 03:11
Why not try to see how WoW64 emulate the EnumProcessModules api call to where he searchs these modules ? May this be a good clue to find how you can do the same


Good luck


Regards.

jstorme
February 22nd, 2008, 04:00
Use EnumProcessModulesEx (Vista or Windows Server 2008)
hxxp://msdn2.microsoft.com/en-us/library/ms682633(VS.85).aspx

regards,
jstorme

TiGa
February 22nd, 2008, 06:44
Thanks for the suggestions.

I was keeping this option as a last-resort.
It works as I want to but not on previous x64 platforms.
It's annoying to have a feature that would work only on Vista x64.

It must be possible to emulate it like Wow64GetThreadContext:
http://www.nynaeve.net/?p=191

TiGa

TiGa
February 25th, 2008, 13:31
I've successfully made an emulation of EnumProcessModulesEx to return the real HMODULE values but it is not that helpful.

Every other APIs like GetModuleFileNameEx or GetModuleInformation that would use those values would need to be emulated too to go through the WoW64 barrier.

TiGa

Nacho_dj
February 26th, 2008, 03:02
Hello Tiga:

For the case of GetModuleFileNameEx API, it your goal is extracting the full path of a module, have you tried for each Process32Next (after Process32First) the use of Module32First? It gives you a MODULEENTRY32 structure where there is the field TCHAR szExePath[MAX_PATH] providing you that info.

I have used this method for 32-bit systems and it works fine, being compliant even with old Win9X systems.

Anyway, I haven't access to any 64-bit system, so I cannot test by myself what I suggest you...

Cheers

Nacho_dj

TiGa
February 26th, 2008, 03:38
The problem is that calling GetModuleFileNameEx from an x64 process toward another 32-bit process is that it always returns the same 4 modules for every file.

I know it's hard to figure out unless you really see it.
I see it and it's still foggy sometimes.
Maybe this picture will help a little:
http://img177.imageshack.us/img177/8422/wow64kz1.th.png
(http://img177.imageshack.us/my.php?image=wow64kz1.png)

My emulation of EnumProcessModulesEx was faulty and in fact really EnumProcessModules.

I noticed that there is only a minor difference between the 2 APIs.
EnumProcessModules:
Code:
mov edi, edi
push ebp
mov ebp, esp
push 1 ; int
push [ebp+arg_C] ; int
push [ebp+arg_8] ; int
push [ebp+arg_4] ; int
push [ebp+hProcess] ; hProcess
call _EnumProcessModulesInternal@20 ; EnumProcessModulesInternal(x,x,x,x,x)
jmp loc_51401FE5

EnumProcessModulesEx:
Code:
push 0Ch
push offset dword_514026B8
call __SEH_prolog4
and [ebp+ms_exc.disabled], 0
push 1 ; int
push [ebp+arg_C] ; int
push [ebp+arg_8] ; int
push [ebp+arg_4] ; int
push [ebp+hProcess] ; hProcess
call _EnumProcessModulesInternal@20 ; EnumProcessModulesInternal(x,x,x,x,x)
mov [ebp+ms_exc.disabled], 0FFFFFFFEh
jmp short loc_514026AD

Some doodad or thingamajig is turned off and on.
Probably something like Wow64DisableWow64FsRedirection.

TiGa

aionescu
March 16th, 2008, 17:11
No, that's just SEH being turned off and on (__try and exiting the __try block)