Detours icon indicating copy to clipboard operation
Detours copied to clipboard

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

Open number201724 opened this issue 4 years ago • 24 comments

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

number201724 avatar Dec 24 '20 17:12 number201724

influence function: DetourUpdateProcessWithDll/DetourUpdateProcessWithDllEx

number201724 avatar Jan 05 '21 12:01 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.

sonyps5201314 avatar Jan 10 '21 15:01 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.

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.

number201724 avatar Jan 12 '21 10:01 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

sonyps5201314 avatar Jan 13 '21 11:01 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

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

number201724 avatar Jan 13 '21 11:01 number201724

DetourUpdateProcessWithDll/DetourUpdateProcessWithDllEx is just an internal call of DetourCreateProcessWithDll.

sonyps5201314 avatar Jan 15 '21 14:01 sonyps5201314

DetourUpdateProcessWithDll/DetourUpdateProcessWithDllEx is just an internal call of DetourCreateProcessWithDll.

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

number201724 avatar Jan 16 '21 14:01 number201724

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

sonyps5201314 avatar Jan 16 '21 15:01 sonyps5201314

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.

number201724 avatar Jan 16 '21 15:01 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.

sonyps5201314 avatar Jan 16 '21 16:01 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.

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.

number201724 avatar Jan 16 '21 16:01 number201724

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

sonyps5201314 avatar Jan 18 '21 00:01 sonyps5201314

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

bgianfo avatar Mar 04 '21 22:03 bgianfo

Rebase

number201724 avatar Mar 05 '21 08:03 number201724

Rebase

number201724 avatar Mar 05 '21 08:03 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.

number201724 avatar Mar 05 '21 08:03 number201724

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 avatar Mar 13 '21 11:03 ghost

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

jaykrell avatar Jun 08 '21 09:06 jaykrell

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

Yes, NtWow64WriteVirtualMemory64 can only be available from Windows Vista.

sonyps5201314 avatar Jun 08 '21 15:06 sonyps5201314

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 avatar Jun 15 '21 17:06 ghost

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.

jaykrell avatar Oct 02 '22 10:10 jaykrell

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 avatar Oct 09 '22 11:10 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 avatar Oct 31 '22 23:10 ghost

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.

number201724 avatar Nov 01 '22 05:11 number201724