Fix: Allows 64-bit processes to modify the import table of 32-bit processes.

[number201724]

Allows 64bit process to inject 32bit DLLs into 32bit process.
Since the modification is IAT, it seems that there is no problem.

[number201724]

influence function: DetourUpdateProcessWithDll/DetourUpdateProcessWithDllEx

[sonyps5201314]

In fact, on a 64-bit system, 32-bit processes can also read and write the memory of 64-bit processes. Through the NtWow64WriteVirtualMemory64/NtWow64ReadVirtualMemory64/NtWow64QueryInformationProcess64 series of APIs, rundll32 and this direct memory read and write operation are all ways to access memory across processes. So you can also implement UpdateImports64 from a 32-bit process, if you want.

[number201724]

In fact, on a 64-bit system, 32-bit processes can also read and write the memory of 64-bit processes. Through the NtWow64WriteVirtualMemory64/NtWow64ReadVirtualMemory64/NtWow64QueryInformationProcess64 series of APIs, rundll32 and this direct memory read and write operation are all ways to access memory across processes. So you can also implement UpdateImports64 from a 32-bit process, if you want.

This is not a documented API and may be changed in future versions.

detours will automatically detect the size of IMAGE_NT_HEADERS(32/64), so this patch is not a problem.

[sonyps5201314]

What I mean is that you tried to remove the use of rundll32 in this way, but you did not completely remove it. Presumably the official team knew that it can be done like this. Maybe considering the undocumented API, they decided to use rundll32. Realize reading and writing the memory of non-current architecture processes

[number201724]

What I mean is that you tried to remove the use of rundll32 in this way, but you did not completely remove it. Presumably the official team knew that it can be done like this. Maybe considering the undocumented API, they decided to use rundll32. Realize reading and writing the memory of non-current architecture processes

Its main modification is not DetourCreateProcessWithDll, but an improvement to DetourUpdateProcessWithDll/DetourUpdateProcessWithDllEx.

[sonyps5201314]

DetourUpdateProcessWithDll/DetourUpdateProcessWithDllEx is just an internal call of DetourCreateProcessWithDll.

[number201724]

DetourUpdateProcessWithDll/DetourUpdateProcessWithDllEx is just an internal call of DetourCreateProcessWithDll.

Some third-party programs may directly call DetourUpdateProcessWithDll/DetourUpdateProcessWithDllEx, such as anti-virus software.

[sonyps5201314]

After the process is started, it is useless to update its import table.

[number201724]

After the process is started, it is useless to update its import table.

e.g.: Set PsCreateProcessNotifyRoutine in the kernel, and then notify the user-level program.

[sonyps5201314]

So since you have used the kernel-level modification, why not do the UpdateImports64 from 32bit process as well, so that the dependency on rundll32 is completely removed. Now you only remove one situation, which is incomplete. The kernel should It is easy to access the memory of a 32-bit process.

[number201724]

So since you have used the kernel-level modification, why not do the UpdateImports64 from 32bit process as well, so that the dependency on rundll32 is completely removed. Now you only remove one situation, which is incomplete. The kernel should It is easy to access the memory of a 32-bit process.

Under normal circumstances, a 32-bit process cannot access the address space of a 64-bit process. On the contrary, 64-bit can easily access the 32-bit address space. Of course, there is an exception. The use of undocumented APIs is not reliable. Another reason is that the 32-bit operating system may not provide the Wow64 API you mentioned. Because the driver needs to notify the user-level program to do some related operations, and the kernel does not provide VirtualProtect-related APIs, you cannot safely modify the user-level memory protection.

So for 64-bit processes you need to consider two cases, the child is 32-bit or 64-bit.

[sonyps5201314]

Another reason is that the 32-bit operating system may not provide the Wow64 API you mentioned

32-bit systems do not have 64-bit processes at all, so there is no need to use these WOW64 API functions

[bgianfo]

@number201724 can you rebase and add a test case to cover this scenario? (maybe in the new tests\ unit tests?)

[number201724]

Rebase

[number201724]

Rebase

[number201724]

@number201724 can you rebase and add a test case to cover this scenario? (maybe in the new tests\ unit tests?)

It seems that the test is more troublesome, because I use the software that drives the notification application layer to call DetourUpdateProcessWithDll/DetourUpdateProcessWithDllEx, I did not test other cases.
Maybe can try CreateProcess to create a 32-bit process and then test DetourUpdateProcessWithDll/DetourUpdateProcessWithDllEx. I will add it when I have time.

[ghost]

This pull request has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 7 days.

[jaykrell]

Separately, please change to C++ template.
And yes good idea imho.
Even 32bit to 64bit. Too bad the Win32 API is so limited.

[sonyps5201314]

Even 32bit to 64bit. Too bad the Win32 API is so limited.

Yes, NtWow64WriteVirtualMemory64 can only be available from Windows Vista.

[ghost]

This pull request has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 7 days.

[jaykrell]

I added those NtWow64ReadVirtualMemory64 functions, way back when.
At the time, whether we had 32bit tlist or 64bit tlist first in %PATH% varied and I wanted whatever was first to work, so I added them for 32bit tlist to use.
Again, it is unfortunate how limited the public Win32 API is.

Keep in mind, Detours does not patch IAT.
It patches code. IAT patching is so much easier and almost as effective.. and both are kinda hacky.

[ghost]

This pull request has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 7 days.

[ghost]

This pull request has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 7 days.

[number201724]

Separately, please change to C++ template. And yes good idea imho. Even 32bit to 64bit. Too bad the Win32 API is so limited.

I think if it is modified as a C++ template, a lot of code needs to be modified.
This functionality can currently be accomplished with minimal changes.