search

microsoft / Detours

Detours is a software package for monitoring and instrumenting API calls on Windows. It is distributed in source code form.
MIT License
5.18k stars 1.01k forks source link

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

Open number201724 opened 3 years ago

number201724 commented 3 years ago

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

number201724 commented 3 years ago

influence function: DetourUpdateProcessWithDll/DetourUpdateProcessWithDllEx

sonyps5201314 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

DetourUpdateProcessWithDll/DetourUpdateProcessWithDllEx is just an internal call of DetourCreateProcessWithDll.

number201724 commented 3 years ago

DetourUpdateProcessWithDll/DetourUpdateProcessWithDllEx is just an internal call of DetourCreateProcessWithDll.

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

sonyps5201314 commented 3 years ago

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

number201724 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

number201724 commented 3 years ago

Rebase

number201724 commented 3 years ago

Rebase

number201724 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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

sonyps5201314 commented 3 years ago

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

Yes, NtWow64WriteVirtualMemory64 can only be available from Windows Vista.

ghost commented 3 years ago

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 commented 2 years ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.