[PATCH v4 0/5] find_fast_cwd_pointer rewrite

[Jeremy Drake]

On Sat, 29 Mar 2025, Jeremy Drake via Cygwin-patches wrote:

>     ++#if defined (__i386__)
>      +  static const BYTE thunk[] = "\x8b\xff\x55\x8b\xec\x5d\x90\xe9";
>     -+#elif defined(__x86_64__)
>     ++  static const BYTE thunk2[0];
>     ++#elif defined (__x86_64__)
>      +  /* see
>      +     https://learn.microsoft.com/en-us/windows/arm/arm64ec-abi#fast-forward-sequences */
>      +  static const BYTE thunk[] = "\x48\x8b\xc4\x48\x89\x58\x20\x55\x5d\xe9";
>     ++  /* on windows 11 22000 the thunk is different than documented on that page */
>     ++  static const BYTE thunk2[] = "\x48\x8b\xff\x55\x48\x8b\xec\x5d\x90\xe9";

I noticed that in 22000 the x86_64 "thunk" is the same as the i386 one had
been in every version I tested, except with the 0x48 "REX" prefix added
to two of the instructions.
I guess they found a different sequence had better compatibility with API
hooking software.

I just did some wandering on the internet and came across someone who
seems to confirm this:

http://www.emulators.com/docs/abc_arm64ec_explained.htm#FFS
> This sequence is not the original FFS we shipped in Windows 11 SV1
> (build 22000) back in 2021.  We had a simpler sequence but as it turned
> out this broke some video games because we used x64 instructions that
> their hotpatchers were not used to seeing.  After a constructive email
> exchange with the folks at Valve we zeroed in on this much more
> compatible code sequence.  Pro tip: This is why Windows 11 SV2 (build
> 22621) is the minimum version of Windows on ARM you should be using your
> ARM64 device.  If your device came with build 22000 or even Windows 10
> build 19041, or you are building using a Windows SDK prior to build
> 22621, upgrade it!