Flaw with the way API set resolution is handled

The current implementation for resolving API sets (used when rebuilding the IAT) will fail if an API set is present in the import directory and uses a patch number not included in the map. Whilst not extremely common, this happens from time to time and will likely result in a mapping failure.

If you look at the way the Windows loader does API set resolution, a binary search is used with the API_SET_HASH_ENTRY structures. The important thing here is the fact that the Hash field of this structure excludes the patch number, meaning all comparisons done during resolution are independent of the patch number.

Following this logic, api-ms-win-core-processthreads-l1-1-0.dll and api-ms-win-core-processthreads-l1-1-3.dll will map to the same DLL. In fact, any API set like api-ms-win-core-processthreads-l1-1-X.dll, will map to the same DLL.

Using the current implementation, a fix is simple enough. Instead of doing an exact match via a key lookup, do a comparison up until the patch number.

As a reference, my library uses a stripped-down version of the same resolution algorithm that the Windows loader uses, which illustrates how the patch number is excluded from lookups during resolution.

[TheWover]

@Dewera Thanks! I will take a look at this along with the Import Table issue.

[TheWover]

@Dewera What DLL would you recommend for testing this edge case? Something that I can load and generate the failure you mentioned.

@TheWover I can't think of one off the top of my head but you could take a look at a few of the core system DLL's i.e. kernel32, kernelbase etc. I'm sure one of them is bound to have this edge case.

You could also simulate one of these by making sure you can handle a resolution where at least one of api-ms-win-X-X-l1-1-X.dll exists in the map and then adjust the patch number to something that doesn't exist in the map.

[TheWover]

This has (finally) been fixed in the separate DInvoke repo for the NuGet. It will eventually be merged back into SharpSploit. TheWover/DInvoke@af9f869