This repository has been archived by the owner on Jan 21, 2021. It is now read-only.
Add support for Windows 10 v1803 to Invoke-ReflectivePEInjection #289
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This change adds support for Windows 10 v1803 April 2018 Update to Invoke-ReflectivePEInjection.
Description
The latest update to Windows 10, RS4 (also called Windows 10 1803 or Windows 10 build 17134), introduced some changes that breaks Invoke-ReflectivePEInjection.
First, the GetMethod() lookup here to find GetProcAddress in kernel32.dll no longer works. It fails with the following error:
Exception calling "GetMethod" with "1" argument(s): "Ambiguous match found."
If you run GetMethods() on $UnsafeNativeMethods, you'll see there are two GetProcAddress results on Windows 10 v1803.
The only apparent difference between the two is ExactSpelling. The solution here that appears to work on Windows 7 SP1 and newer and Windows Server 2k8 R2 and newer is to always select the first method to avoid the ambiguous match exception.
$GetProcAddress = $UnsafeNativeMethods.GetMethods() | Where {$_.Name -eq "GetProcAddress"} | Select-Object -first 1
The second issue is here. $Kern32Handle must be of type System.IntPtr instead of System.Runtime.InteropServices.HandleRef. This can be observed in the following exception:
The solution to this problem is to try System.Runtime.InteropServices.HandleRef and fall back to System.IntPtr if there's an exception.
How was it tested?
I tested this on the following versions of Windows, but would definitely welcome more testing and validation that this is the best solution.