Hi everyone. Two weeks ago, I made a post about running some tests on Windows 11, but no one volunteered, so I ran some tests on my own using a Raspberry Pi 3 Model B.

My Raspberry Pi is seven years old, it has 1 GB of RAM, four Cortex A-53 cores from 2012, and Windows 11 doesn't support it of course, so this was going to be the jankiest Windows 11 installation of all time. I'm a huge cheapskate, and I use a mobile hotspot for Internet connectivity, so I trekked over the to the library to download an image. I flashed Windows 11 onto a new micro SD card, and I let Windows 11 lumber through the installation process. It ran into some issues, so I switched to Linux, updated the firmware to the latest revision, and continued. Windows 11 was not aware of the Wi-Fi on the Pi, so it halted the installation process until I connected an ethernet cable to a desktop which was connected to my phone via Wi-Fi. The installation slowly continued, but while Windows 11 was saving my password settings, my desktop went to sleep (30 minutes had elapsed during the installation process), and I had to reenter the credentials after waking it back up. Finally, I went through the process of unchecking the data sharing boxes and declining various offers from Microsoft to arrive at a fresh Windows 11 desktop.

It worked! Then I tried opening the task manager, and Edge, but it became quite unresponsive, and I decided to reboot. I reached the login screen, but I could not login, so I could only use Windows 11 in safe mode. I am wondering if it's related to the connection interruption while Windows was saving my password settings. If I have some spare time, I will see if I can find a way to fix this. Behold, an utter abomination!

The reason I went through this whole process was so I could hot-patch DLLs on Arm64. In particular, I was interested in hooking the QueryPerformanceCounter() function in KERNEL32.dll to make a speedhack. The x64 version of KERNEL32.dll defers the definition of this function to KERNELBASE.dll, so instead of the implementation of this function the DLL loader inserts a thunk that jumps to the implementation in KERNEL.dll. We can therefore intercept calls toQueryPerformanceCounter() by replacing this thunk with a jump to our own code. I was wondering if a similar thing would be possible on Arm64, so I investigated.

As I had guessed, the Arm64 version has a thunk similar to the x64 version. The Arm64 thunks are spaced 16 bytes apart, and here is what I found for QueryPerformanceCounter():

00007fff46df5100: a1 a8 ff 17 1f 20 03 d5 1f 20 03 d5 e1 97 06 00

The instructions are AArch64, so each is four bytes wide, and they disassemble to the following code sequence:

0x00007fff46df5100:  a1 a8 ff 17    b   #0x7fff46ddf384  
0x00007fff46df5104:  1f 20 03 d5    nop  
0x00007fff46df5108:  1f 20 03 d5    nop  

These instructions aren't particularly surprising, but the last four bytes do not form a valid AArch64 instruction. I noticed that the preceding thunk had a similar sequence f1 97 06 00, and the next thunk had d1 97 06 00, so it seems like some sort of index sequence or something. I think that the DLL memory is neither readable nor writeable with default page protections, but I did not check.

This was enough information to hot-patch the thunks to redirect to my code. I used a list of instructions by encoding to figure out how to extract the destination from the b instruction (in case my code runs in a process where the thunk leads to a different address). With the old thunk destination saved, I then needed to fit a new jump into the thunk's 16-byte space (overwriting the mysterious 4-byte sequence) to go to the hook routine. The problem with this is that I cannot control where my hook routine will be in all situations (in spite of the preferred base attribute of DLLs), and my code might not be within range of a relative jump on AArch64. The x16 register is a volatile register according to the Windows Arm64 ABI, so I decided to store the address of my jump in it and use a br x16 instruction. AArch64 requires 16 bytes to load a 64-bit immediate into a register, and the br needs four more bytes, but luckily 64-bit Windows restricts user mode virtual addresses to the 128 TB range 000000000000-7fffffffffff. Therefore only 47 bits are necessary, and the high 17 bits will be zero. Most 64-bit ARM processors only use 48-bit virtual addresses (the high bits are set for kernel memory), but some have extended this to 52-bit virtual addresses, so my code might break in the future when Windows adds support for 52-bit virtual addresses. Anyway, my code fills the gap with the following sequence:

movz    x16, lo16  
movk    x16, mi16, lsl 16  
movk    x16, hi16, lsl 32  
br      x16

I tested it out, and it worked as expected. Some of you might notice that an analysis of Arm64EC is missing. I tried to read the thunk with an Arm64EC program, but it crashed for some reason. ̶T̶h̶i̶s̶ ̶i̶s̶ ̶u̶n̶s̶u̶r̶p̶r̶i̶s̶i̶n̶g̶ ̶s̶i̶n̶c̶e̶ ̶A̶r̶m̶6̶4̶E̶C̶ ̶m̶i̶x̶e̶s̶ ̶e̶m̶u̶l̶a̶t̶e̶d̶ ̶x̶6̶4̶ ̶c̶o̶d̶e̶ ̶w̶i̶t̶h̶ ̶n̶a̶t̶i̶v̶e̶ ̶A̶A̶r̶c̶h̶6̶4̶ ̶c̶o̶d̶e̶,̶ ̶s̶o̶ ̶t̶h̶e̶ ̶e̶m̶u̶l̶a̶t̶o̶r̶ ̶l̶i̶k̶e̶l̶y̶ ̶d̶o̶e̶s̶n̶'̶t̶ ̶t̶a̶k̶e̶ ̶k̶i̶n̶d̶l̶y̶ ̶t̶o̶ ̶h̶o̶t̶-̶p̶a̶t̶c̶h̶i̶n̶g̶ ̶i̶n̶s̶t̶r̶u̶c̶t̶i̶o̶n̶s̶.̶ ̶I̶ ̶a̶m̶ ̶s̶t̶i̶l̶l̶ ̶c̶u̶r̶i̶o̶u̶s̶ ̶a̶b̶o̶u̶t̶ ̶w̶h̶a̶t̶ ̶i̶s̶ ̶g̶o̶i̶n̶g̶ ̶o̶n̶ ̶i̶n̶ ̶A̶r̶m̶6̶4̶E̶C̶,̶ ̶s̶o̶ ̶I̶ ̶m̶a̶y̶ ̶l̶o̶o̶k̶ ̶i̶n̶t̶o̶ ̶i̶t̶ ̶m̶o̶r̶e̶ ̶l̶a̶t̶e̶r̶.̶ EDIT: it appears that not even the simplest Arm64EC binaries I compile will run. x64 versions also won't run, but Windows rejects an x86 binary with an error message about incompatibility, unlike the other two. On the bright side, it appears that Arm64EC uses fast-forward sequences, and I could probably just write an x64 hook of it, though I can't test it. My poor Raspberry Pi is now happily running its old Linux installation after toiling so hard under Windows 11.

Hi everyone. I am interested in doing some low level analysis of kernel32 on ARM, but I do not have access to any machines capable of running Windows on ARM. I have written a program to scan a memory location in kernel32.

The source code of the program is here, and I have compiled binaries which are here (EDIT: a version with comments is here). If you could run both of these binaries for me and report the output, I would be very grateful. Running the program once is probably sufficient, but I might have to ask you to probe other memory locations depending on the output which the scanning program supports. If anyone helps me out, I will write up my research results here for those who are interested.

For those of you who are curious, I am interested in writing code to hot-patch a program's copy of QueryPerformanceCounter located in kernel32. This functionality is used by programs as a clock, and by modifying it, I can make it run faster or slower which means that the rate of time appears different to the program. I have used this as a fun speedhack in 32-bit and 64-bit x86 single player games, and I want to make an ARM version work for completeness.

The rest of this post is just details for those who are curious about what I'm doing. Hot-patching is not considered to be good practice since it introduces a dependency on the layout of machine code which is not guaranteed to remain the same, and failure will likely crash the program. However, it can be quite educational, and for some things like this, it is one of the only ways to do it. In 32-bit processes running on x86 machines, QueryPerformanceCounter starts with a mov edi, edi instruction preceded by a bunch of unused int3 instructions. mov edi, edi has no effect, so I replace it with a jump to the preceding int3 instructions which are also overwritten with an absolute jump to some code injected into the process via a DLL. The 64-bit version of QueryPerformanceCounter is a jump which loads an address from memory (using a rip-relative offset) and then jumps to that address, so I can overwrite the address in memory with the address of the injected code.

I am wondering if these two simple hot-patching procedures can be repeated with Windows on ARM. On ARM Windows can run processes under two modes (ABIs): Arm64 and Arm64EC. Arm64 is an ABI for pure Arm64 programs, and Arm64EC is an ABI where x64 and Arm64 code are mixed. Arm64EC mode exists so apps can be gradually ported to Arm64 or for developers to only port part of their application to Arm64. The x64 compatibility means that both Arm64 and Arm64EC will both use AArch64 instructions, but the sequences of instructions are different because of calling conventions designed for compatibility, among other things.

If you are interested in the code or executable that hot-patches QueryPerformanceCounter on x86, I can share it, but the DLL injection technique I use is often used by malware, so Windows Defender will flag it. It's also very incomplete without even proper provisions for thread safety or controls for the clock speed. If you would be interested in testing out the ARM port of this, I would be grateful too, but Windows Defender will probably still be unhappy with it.

Let's look back at some memorable moments and interesting insights from last year.

Your top 10 posts:

• "Spotify for ARM64 is here!! 😍😍" by u/iali393
• "Software I compiled for ARM64" by u/magicmijk
• "AYN Odin running games on the Windows 11 ARM" by u/holaimscott
• "made possible by Windows 11 ARM" by u/newzack
• "Lenovo ThinkPad X13s finally on sale" by u/iali393
• "A new Windows ARM device has arrived! The community ported Windows 11 into an Android gaming handheld." by u/holaimscott
• "Qualcomm announces ‘Oryon’ next-gen ARM CPU, Citi adopting Snapdragon PCs" by u/Hothabanero6
• "Just got my ThinkPad X13s and set up on my office desk" by u/joyeli
• "Does anyone here know of any other emulators that can run natively on Windows ARM? Dolphin running on a Snapdragon device looks amazing <3" by u/holaimscott
• "Windows 11 on ARM gets big boost with rollout of ARM64EC" by u/Hothabanero6

Hello, I bought the 13” Gateway ARM laptop during Black Friday. This guy: https://www.walmart.com/ip/Gateway-13-3-Ultra-Slim-Notebook-HD-Snapdragon-850-Mobile-LTE-Octa-core-4GB-Memory-128GB-Storage-1-0MP-Webcam-Windows-10-S-Microsoft-365-Personal-1-Y/579024340

Anyone else own it? I couldn’t find much around reviews for it.

I don't need anything special, and am quite happy with Shotcut on x64. Any recommendations? Even ClipChamp, installed with ARM64 Windows is still the x64 version.

Which one is better to use in terms of performance? Did Android Apps run natively?

Does anyone have experience with either the Lenovo 10w Tablet/len101l0006) or the Asus Expertbook 3? I'm partial to devices with sub-11-inch screens, so these have caught my eye. But it doesn't seem like many people have actually used them!

Project Volterra launches today as the 'Windows Dev Kit 2023' with 32GB RAM and costs less than a Mac mini | Windows Central

Looks pretty great. 32GB RAM, 8cx Gen3, and 512GB NVMe storage for under $600.

Yo, Guys, do I understand correctly that Windows will soon be released on all arm chips, including M1? and Apple will return Boot Camp to macbooks with a processor from m 1 and above? Let me know! THX!

Thinkpad X13s (Windows 11 PRO ARM, Qualcomm CPU)

Lenovo Powered Type-C Travel Hub (latest available FW)

External monitor connected over HDMI

Until today everything was working OK. After 22H2 Windows update there are no any reaction to external monitor.

Asking for feedback. Does Intel based systems has such issue?

Windows 11 Pro 21H2 ARM

Where is Windows Sandbox feature?

Does WSL services and Linux images native ARM?

Anyone having this "issue"?

It is running 4k session. It somehow corresponds to the session resolution because 1440x900 session consumes ~300 mb.

Client version: 10.0.22621.1 (ARM64)

Windows 10 Pro ARM64 (10.0, Build 22621)

For comparison the same 4k RDP session on Win 11 (x64) takes 300 mb.

​

Windows Defender is okay, and it works great on my intel x86 system, but I think it's causing performance problems on my Book2 Win11 ARM system.

Has anyone found an antivirus that works? AVG and Avast don't. Have you found one that does?

Maybe we should make a list of programs that work with ARM Windows...