Windows 11 on ARM64 Support

[NullYing]

I tried to install WinUSB on Huawei's ARM laptop and encountered the same driver signature issue as before. I attempted to restart the computer and start it in a way that disabled driver signature, which allowed me to successfully install it. Is there a way to install WinUSB without disabling driver signature?

link:
#288
#155

[mcuee]

As of now no way -- as per the comments from the above two issues.

• Installing WinUSB (v6.1.7600.16385) - Driver Installation: FAILED (Operation not supported or not implemented)  #288
• Windows 10 on ARM64 support #155

[fansID512]

Hello, I found the arm64 adb and fastboot driver in the relevant Windows of Android group today. After testing, it can connect to the phone and read data normally. The relevant driver accessories have been uploaded.

adb和fastboot驱动arm64(带教程).zip

Success picture
(https://github.com/pbatard/libwdi/assets/103017881/de547711-cbd3-4246-800c-a2ea9c37c3dc)

[phantomski77]

I think I may have found a workaround. You need to disable Driver Signature Enforcement in Windows. To do that, you need to reboot your Windows into a Safe Mode (Start Menu, right click on power button, and hold SHIFT while clicking on Restart). While in the safe mode, go into Troubleshoot / Advanced Options / Startup Settings. Click Restart, select option 7 (Disable Driver Signature Enforcement). Once the Windows reboots, install Zadig drivers as usual.

I'm running Win 11 Pro in Parallels on Mac and it works well.

My setup:

• Apple MacBook Pro M2 Max (Apple Silicon)
• macOS Sonoma 14.1.2
• Parallels Desktop 19.1.1
• Windows 11 Pro 22H2 OS Build 22621.2792 (VM on ARM)
• Zadig 2.8 Build 782

[pbatard]

Please don't spam. Your proposed "workaround" is well know, and is not a real workaround, since it forces the user to disable something that Zadig was designed to prevent them from having to do (since it does put a user's computer at risk).

A proper workaround would be to identify a registry setting , Group Policy or any other Windows configuration parameter that one can enable that doesn't disable signature enforcement altogether and makes Windows 11 on ARM64 behave like Windows 11 on x86, by making the Driver package is considered unsigned, and Code Integrity is enforced. error go away (since the driver package is actually signed, and the certificate for its signature is installed in a certificate store that Windows is supposed to honour when it comes to validating the trust chain).

[NullYing]

Zadig driver has to submit to Mircosoft Hardware Certification, if it want to run in Windows 11. But it deviated from the purpose of users using Zadig.

Starting with Windows 10, version 1607, Windows will not load any new kernel mode drivers which are not signed by the Microsoft through the Hardware Dev Center. Valid signatures can be obtained by either Hardware Certification or Attestation.

link

I purchased the EV certificate required by Microsoft and registered it on Microsoft's hardware Certification. I submitted the driver generated by Zadig to the platform and received a signed driver in return. This driver can be used successfully on Windows 11 ARM.

[pbatard]

Starting with Windows 10, version 1607, Windows will not load any new kernel mode drivers which are not signed by the Microsoft

Except what we are discussing does work on Windows 11 x64.

Also Zadig does installs drivers that have passed the MS Hardware Certification (one of them being WinUSB, which is produced by Microsoft themselves). And Zadig follows Microsoft's own guidelines that one should be able to sign a driver package and, if the driver package's signature certificate can be found in Trusted Publisher (which is the part that Zadig does: it does install a one-time-use certificate under Trusted Publishers), then the system will consider the driver package as trusted and install it.

This works fine on Windows 11 x64.
This doesn't work on Windows 11 ARM64.

Therefore, there is a default system configuration difference between Windows 11 x64 and Windows 11 ARM64, that has nothing to do with using EV certs and whatnot, that needs to be identified, so that Zadig can install drivers on Windows 11 ARM64 the same way it is able to install drivers on Windows 11 x64.

This is not a "kernel driver has not gone through the Hardware Dev Center" or "kernel driver has not been signed with an EV certificate" issue. ALL the drivers that that Zadig installs have.

Instead, this is a "Microsoft has broken a promise it made that one could sign a driver package (which is different from the driver binaries) and that, if the signature's certificate could be found in Trusted Publishers, that package would be installed on systems where signature validation is active".

Your report, which we already know about, only demonstrates that, on ARM64, the default configuration of Windows is that it will only accept for a driver package EV certificates whereas, on x64, it does accept non EV certificates that have set to be trusted by the system. And again, this is different from the default x64 Windows configuration.

[dontech]

1. I have made some patches to support libusb0 in libwdi/zadig under ARM64:
   https://github.com/dontech/libwdi

This adds support for loading libusb0.sys on ARM64.

2. It has the same problem. Only works if i disable driver signing enforcement, which of course is not a solution.

3. It would seem others have faced the same problem:

https://learn.microsoft.com/en-us/answers/questions/650810/windows-11-arm64-driver-install-signature-validati?page=1&orderby=Helpful&comment=answer-1289832#newest-answer-comment

Either the rules were changed, and we need to adapt, or win11-arm64 completely disabled the self-signing feature.

[pbatard]

This adds support for loading libusb0.sys on ARM64.

Thanks. You may want to submit a PR as it's likely to be some time before I can look into adding this, and I may forget about otherwise.

Either the rules were changed, and we need to adapt

To adapt we need to find what is the difference in default configuration (since Windows should use the same codebase, so it has to be a configuration setting) between x64 and ARM64. Until someone can provide some hints on that, there will be no change. Worse, chances are that Microsoft is going to bring this default configuration to x64 in a feature update eventually (because we have seen the exact same issue with Insider releases a couple years ago), so the clock is probably ticking for x64 users as well...

Now, as you may have realised, I have very little time to devote to libwdi these days, so it's very unlikely that I will be able to invest the time required to look into the ARM64 issue, which means that somebody else will probably have to step up...

[mcuee]

To adapt we need to find what is the difference in default configuration (since Windows should use the same codebase, so it has to be a configuration setting) between x64 and ARM64. Until someone can provide some hints on that, there will be no change. Worse, chances are that Microsoft is going to bring this default configuration to x64 in a feature update eventually (because we have seen the exact same issue with Insider releases a couple years ago), so the clock is probably ticking for x64 users as well...

@jkunkee

You mentioned in #155 that you work for Microsoft and you are interested to get libwdi to work for Windows on ARM64. Just wondering if you can help to clarify the direction from Microsoft in this aspect. Thanks a lot in advance.

[pbatard]

For the record, my current guess is that whereas the (current) official documentation states:

If a driver package is signed by a Windows signing authority or a trusted publisher, Windows stages and installs the driver package without prompting the user.

thereby indicating that a driver packages where the signing certificate is present in Trusted Publishers should lead to driver installation, Microsoft might have introduced features of Windows S mode to Windows on ARM64, and especially:

Driver packages must be digitally signed with a Windows, WHQL, ELAM, or Store certificate (...)

thereby excluding self-signed credentials where the certificate part gets installed in Trusted Publishers.

However, as opposed to S Mode vs regular mode driver package installation differences, I have not been able to find any documentation related to x64 vs ARM64 driver package installation differences...