[Source] accessing x64 from WOW64

[DarthTon]

I was playing around with WOW64 subsystem for a while - calling 64bit code from x86 mode and shit. Inspired by wow64ext project by ReWolf https://code.google.com/p/rewolf-wow64ext/, I created somewhat improved version of his library. Basically I fixed handling of addresses beyond 4GB and added some new functions, so credits go to him.

Library allows you to do the following (only for WOW64 process, for native x64 this will be obsolete):
- Access 64 bit TEB and PEB of arbitrary processes and threads
- 64bit versions of Read/Write ProcessMemory, VirtualProtectEx, VirualAllocEx, VirtualFreeEx
- 64bit version of Get/Set ThreadContext
- 64bit version of CreateRemoteThread (can be used to create threads in both WOW64 and x64 processes)
- Enumeration of x64 modules in WOW64 process
- Injection of x64 dll into arbitrary WOW64 or x64 process(yeap, you can inject x64 dll into x86 process)

There is also a managed wrapper around major functions. I'm not very good with all that Marshalling stuff, so probably it's far from optimal.

I believe it is possible to hook x86 functions using x64 dll, haven't tried it yet though.
Also after some manipulations with VAD entry describing 8TB memory region reserved by kernel it is possible to use address space beyond 4GB freely. I'll now try to manually map x64 dll somewhere beyond 4GB and try to hook something from there :crazy:

Code - https://github.com/DarthTon/wow64dm

[MaiN]

Cool, but when injecting x64 modules into a WOW64 process, how does it handle imports? If I recall correctly, there were huge problems with imports because only few of the core 64-bit dll's are loaded into WOW64 processes.

[_Mike]

The main problem with imports is that the PE loader allocates a private page where the x64 kernel32 should be mapped, preventing it from being loadable. This can be worked around simply by freeing said page before attempting to load a dll which depends on kernel32.

There's also an issue where if the application is a console app the x64 kernel32's dllmain destroys the existing console and allocates a new one, preventing all output from the 32-bit apis. It can probably be solved but I didn't spend much time on it.
But most other crt and winapi functions I tested seemed to work fine-ish.

But overall I don't see much use for it beyond as a proof of concept unless you find a way to link 32 and 64-bit object files together. Using inline assembly and emit's is fine for a PoC, but not very user friendly for bigger projects

Edit: correction; It's kernel32 which destroys the console, not the crt.

[DarthTon]

Cool, but when injecting x64 modules into a WOW64 process, how does it handle imports? If I recall correctly, there were huge problems with imports because only few of the core 64-bit dll's are loaded into WOW64 processes.

Yeap, on Win7 kernel32.dll and user32.dll must be loaded at preferred base, which is occupied. I failed at freeing those pages from usermode, so I presume you can´t rely on system loader. Win8 however doesn´t have such problem and I easily injected a dll with kernrel32, user32 and CRT dependencies.

But overall I don't see much use for it beyond as a proof of concept unless you find a way to link 32 and 64-bit object files together

I think I saw somewhere an exmple of such linking, can´t find the source though.

[Jadd]

Many thanks for this, and couldn't have had better timing, this is exactly what I needed.

[DarthTon]

Added direct syscall invocation (without fs:[0xC0] call gate).