rwfpl / rewolf-wow64ext

Helper library for x86 programs that runs under WOW64 layer on x64 versions of Microsoft Windows operating systems.

rewolf-wow64ext

WOW64Ext is a helper library for x86 programs that runs under WOW64 layer on x64 versions of Microsoft Windows operating systems. It enables x86 applications to read, write and enumerate memory of a native x64 applications. There is also possibility to call any x64 function from 64-bits version of NTDLL through a special function called X64Call(). As a bonus, wow64ext.h contains definitions of some structures that might be useful for programs that want to access PEB, TEB, TIB etc.

rewolf-wow64ext's Issues

Some structures' addresses refered by some NtFuncs need to be aligned to 8 bytes, how to solve it

For instance, the arguments to NtCreateFile include a pointer to struct OBJECT_ATTRIBUTE and a pointer to struct IO_STATUS_BLOCK, when I prepare these structs before x64call without modifying esp, NtCreateFile will return STATUS_DATATYPE_MISALIGNMENT or STATUS_INVALID_PARAMETER if esp ≡ 4(mod 8). So I have to wrap NtCreateFile32 with full inline assembly. Quite inconvenient for me. Is there an alternative to fix this issue?

Strange crash when run outside of debugger on Windows 10

Hello, thanks for your project. This is really great.

I'm trying to use the library on Windows 10 64-bit. Under Visual Studio's debugger or WinDbg, the program runs fine. When I run it from explorer or cmd, it crashes. To test, I am using the sample program provided, compiled with VS 2017 build tools. It also crashes when compiled with VS 2015 build tools. I tried compiling it myself and using the precompiled dll.

Interestingly, GetModuleHandle64 seems to work fine, but other functions like ReadProcessMemory64 or WriteProcessMemory64 cause a crash.

Some example code:

	printf("hello world\n");
	DWORD64 ntdll = GetModuleHandle64(L"ntdll.dll"); // OK
	printf("ntdll 64 = %llx\n", ntdll);
	HANDLE hProcess = GetCurrentProcess();
	char mem[10];
	BOOL succ = ReadProcessMemory64(hProcess, ntdll, mem, sizeof(mem), NULL); // crash

My Windows version is 10 Enterprise LTSC / 10.0.17763 Build 17763

I attached an compiled exe that is causing the crash here. This is the sample program. main.zip

how can running x86 code inside 64-bits process?

how to use this macro?can you give a sample?
`X86_Start MACRO
LOCAL xx, rt
call $+5
xx equ $
mov dword ptr [rsp + 4], 23h
add dword ptr [rsp], rt - xx
retf
rt:
ENDM

X86_End MACRO
db 6Ah, 33h ; push 33h
db 0E8h, 0, 0, 0, 0 ; call $+5
db 83h, 4, 24h, 5 ; add dword ptr [esp], 5
db 0CBh ; retf
ENDM`

Error in xstring when adding wow64ext.

Hey,
I wanted to add wow64ext to my other project. Now after including I get xstring errors on assign, and ntdll error on malloc.
Also I didn't call any function, I just included lib file(statically compiled) and it shows error on compile.

Why there is no 64bit woe64ext.dll for x64 program to call x86 dlls

can anyone write one?

Compile Errors

There is a lot of errors:
Error 3 error C3861: ‘offsetof’: identifier not found C:\Users\home\Desktop\rewolf-wow64ext-master\rewolf-wow64ext-master\src\wow64ext.cpp 300 1 wow64ext
Error 2 error C2065: ‘InLoadOrderModuleList’ : undeclared identifier C:\Users\home\Desktop\rewolf-wow64ext-master\rewolf-wow64ext-master\src\wow64ext.cpp 300 1 wow64ext
Error 1 error C2275: ‘PEB_LDR_DATA64’ : illegal use of this type as an expression C:\Users\home\Desktop\rewolf-wow64ext-master\rewolf-wow64ext-master\src\wow64ext.cpp 300 1 wow64ext
How can i solve this ?

how to load 64bit modules into WOW64 processes?

if i use x64call LdrLoadDll func
What will happen?
if can not
how i can do load 64bit dll into wow64?
thanks.have nice day

Pre-build .dll broken

Hi,
when getting the current release (1.0.0.9) the pre-build .dll seams to be broken.
Works fine in the beginning, but after running a project multiple times in Visual Studio 2019 (only tested it with this version) that utilizes ReadProcessMemory64, the function stops working.
It still returns false and 0 bytes read. Still it does not recover till a restart of Visual Studio is done.
Since this happened in a VSIX it would be annoying for every user to restart Visual Studio every now and then.

Why I think the .dll has issues.
After building the project/dll myself, I never again ran into the issue

Crash on Windows 8

Calling to GetModuleHandle64 causes the crash.
I think, M$ changed something in Windows 8 64.

SOME OF ASM:
14D821F7 - 8B 4D F8              - mov ecx,[ebp-08]
14D821FA - F7 D9                 - neg ecx
14D821FC - 1B C9                 - sbb ecx,ecx
14D821FE - F7 D1                 - not ecx
14D82200 - 23 4D F4              - and ecx,[ebp-0C]
14D82203 - 8B 41 60              - mov eax,[ecx+60]
14D82206 - 8B 48 18              - mov ecx,[eax+18]
14D82209 - 8B 79 10              - mov edi,[ecx+10] <-- crash 0xC0000005 here
14D8220C - 8D 59 10              - lea ebx,[ecx+10]
14D8220F - 0FB7 4F 58            - movzx ecx,word ptr [edi+58]
14D82213 - 8B 55 08              - mov edx,[ebp+08]
14D82216 - 8B 77 60              - mov esi,[edi+60]
14D82219 - 83 F9 04              - cmp ecx,04
14D8221C - 72 16                 - jb 14D82234
14D8221E - 8B FF                 - mov edi,edi

Original issue reported on code.google.com by [email protected] on 13 Nov 2012 at 8:31

LoadLibrary address ?

As CreateRemoteThread64 was added: #11

I wonder how could one obtain LoadLibrary address for injection ? From what I understand kernel32.dll has too many dependencies and cannot be used.

Any alternatives ?

Tutorial...

Could anyone make a small tutorial how to use this ...

Crash on windows 10 when build with release mode.

When I use any 64 API to operate a 64bits application, the follow exception occrued, but if I press 'continue' again and again, The result seems ok.

Exception thrown at 0x5A180094 in x-studio365.core.dll: 0xC0000005: Access violation writing location 0x08C0A5D8.

Unhandled exception at 0x5A180094 in x-studio365.core.dll: 0xC0000005: Access violation writing location 0x08C0A5D8.

Exception thrown at 0x7703361D (ntdll.dll) in x-studio365.core.dll: 0xC0000005: Access violation reading location 0x00000018.

Unhandled exception at 0x7703361D (ntdll.dll) in x-studio365.core.dll: 0xC0000005: Access violation reading location 0x00000018.

The thread 0x2da8 has exited with code 0 (0x0).
The thread 0x3da8 has exited with code 0 (0x0).
Exception thrown at 0x5A180094 in x-studio365.core.dll: 0xC0000005: Access violation writing location 0x08C0A618.

Unhandled exception at 0x5A180094 in x-studio365.core.dll: 0xC0000005: Access violation writing location 0x08C0A618.

Exception thrown at 0x770403A0 (ntdll.dll) in x-studio365.core.dll: 0xC0000005: Access violation reading location 0x00000030.

Unhandled exception at 0x770403A0 (ntdll.dll) in x-studio365.core.dll: 0xC0000005: Access violation reading location 0x00000030.

Exception thrown at 0x5A180094 in x-studio365.core.dll: 0xC0000005: Access violation writing location 0x08C0A5E8.

Unhandled exception at 0x5A180094 in x-studio365.core.dll: 0xC0000005: Access violation writing location 0x08C0A5E8.

Exception thrown at 0x77048F36 (ntdll.dll) in x-studio365.core.dll: 0xC0000005: Access violation reading location 0x00000030.

Exception thrown at 0x77048F36 (ntdll.dll) in x-studio365.core.dll: 0xC0000005: Access violation reading location 0x00000030.

Unhandled exception at 0x77048F36 (ntdll.dll) in x-studio365.core.dll: 0xC0000005: Access violation reading location 0x00000030.

Allocated memory is not released !

You forgot to free memory allocated by malloc at lines 259, 313, 301, 307 :

Original issue reported on code.google.com by [email protected] on 23 Oct 2013 at 7:15

how to run x64 programs on x86 as exagear is x86

A suggestion about calling convention

Hi ReWolf, I have a suggestion for the project, I can do it and make a pull request if you want:

The exported APIs *64: VirtualFreeEx64, ReadProcessMemory64 etc, are "kind" of binding to Windows APIs. The Windows APIs are stdcall and the lib use other calling convention.

Why the calling convention of the *64 exported functions is not WINAPI stdcall??

We can change this, what you think?

I am using getprocaddress to get some symbols from wow64 lib and kernel32.dll and the declaration is like:

typedef SIZE_T (* VirtualQueryEx64_ptr_f)(HANDLE hProcess, DWORD64 lpAddress, MEMORY_BASIC_INFORMATION64* lpBuffer, SIZE_T dwLength)

typedef SIZE_T (WINAPI * VirtualQueryEx32_ptr_f)(HANDLE hProcess, DWORD lpAddress, MEMORY_BASIC_INFORMATION32* lpBuffer, SIZE_T dwLength)

IMO this makes no sense, maybe is better make all stdcall like Windows API.

PD: Sorry for my english.

Add CreateRemoteThread64

Crash on Windows 11 ARM64

as title.