Open tonymeehan opened 6 years ago
GetMethod
has an overload that lets you tell it which function overload you want by supplying an array of types.
Changing line #1002 to this is a better fix.
$GetProcAddress = $UnsafeNativeMethods.GetMethod('GetProcAddress', [Type[]]@([System.Runtime.InteropServices.HandleRef], [String]))
Thanks @mr64bit I'll update the PR with your suggestion.
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.