mcuee
commented
1 year ago As of now no way -- as per the comments from the above two issues.
Open NullYing opened 1 year ago
mcuee
commented
1 year ago As of now no way -- as per the comments from the above two issues.
fansID512
commented
1 year ago 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.
Success picture (https://github.com/pbatard/libwdi/assets/103017881/de547711-cbd3-4246-800c-a2ea9c37c3dc)
phantomski77
commented
11 months ago 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:
pbatard
commented
11 months ago 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
commented
11 months ago 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.
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
commented
11 months ago 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
commented
10 months ago 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:
Either the rules were changed, and we need to adapt, or win11-arm64 completely disabled the self-signing feature.
pbatard
commented
10 months ago 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
commented
10 months ago 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
commented
10 months ago 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...
mcuee
commented
10 months ago Let me ask in OSR ntdev mailing list.
mcuee
commented
10 months ago @pbatard and @dontech
OSR thread posted here. Let's see if we get some comments from the experts there and hopefully from Microsoft developers. https://community.osr.com/discussion/294199/windows-11-on-arm64-driver-signing-requirement
pbatard
commented
10 months ago Much appreciated, Xiaofan. At this stage, I feel that short of someone from Microsoft shedding light on the difference in behaviour, not much progress will be made on the issue.
mcuee
commented
10 months ago Much appreciated, Xiaofan. At this stage, I feel that short of someone from Microsoft shedding light on the difference in behaviour, not much progress will be made on the issue.
I agree.
I tend to believe that Windows on ARM64 follows Windows S mode requirement. https://learn.microsoft.com/en-us/windows-hardware/drivers/install/windows10sdriverrequirements
To install on Windows 10 in S mode, driver packages must meet the following requirements:
jkunkee
commented
10 months ago Caveat: I do work for Microsoft, but I don't represent Microsoft. I don't even work adjacent to driver signing bits, but I care a lot about ARM64 [edit: for professional as well as personal reasons] and look forward to one day using libwdi with my IoT hobby projects.
Last I dove into it, ARM64's driver signing requirements are the same as x64 except that no attestation-signed drivers for it can exist since it shipped after new signatures were disallowed even on x64.[edit: This is the wrong term for what I remember. I will add a comment later in the thread correcting this. Attestation signing for ARM64 Client is supported.] At least, that's what I gathered.
My first guess is based on the...learning curve for a few issues at work: a combination of shiny features in ARM64 hardware and OEMs enabling OS features that rely on that hardware might trigger an extra harsh driver signing policy somewhere. (How much easier is it to attack Device Guard, HyperVisor-enforced Code Integrity, or Secure Kernel if it's trivial to load arbitrary kernel-mode code? Counterpoint, as a device owner and administrator, don't I get to decide whom I trust? What fun. Enabled OS security features can take a lot of the guesswork out of the first question by answering the second question 'no' [edit: more like "no, you asked us to run security"], so they often do.)
I'd look through msinfo32 and bcdedit to see which OS security features are enabled that might impact signing policy. [edit: Other config surfaces may bear inspection as well;] For example, Device Guard has a registry value named RequireHardwareSecurityFeatures set to (docs page) that can force Secure Kernel to not start if Secure Boot is not enabled. I think there are some knock-on effects of this as well. Is it non-zero on the affected systems?
I'll poke at my Lenovo X13s a bit to see what I can see.
dontech
commented
10 months ago Last I dove into it, ARM64's driver signing requirements are the same as x64 except that no attestation-signed drivers for it can exist since it shipped after new signatures were disallowed even on x64. At least, that's what I gathered.
Thanks @jkunkee, the attestation signing is being totally deprecated. But that means I have to go through HLK every time I want to publish a new driver? Or have you seen other, newer ways to fast-sign a valid driver?
pbatard
commented
10 months ago @jkunkee, thanks a lot for looking into it. We appreciate all the help we can get on this, regardless of where it comes from.
In case that's needed to help you understand our issue better, I'm just going to point out that we're not trying to self sign the drivers themselves for installation (i.e., we're not doing attestation-signing for driver binaries) as, for all intents and purposes, you can consider that the driver we are trying to install is the (unmodified) Microsoft-signed WinUSB driver, which is already present as a system driver, and that we are repackaging to tell the system "Hey, you should also apply that driver to USB device XXXX:YYYY".
So, all we are signing as part of libwdi, using a locally created certificate and key, is the driver package, i.e. the .inf and a list of files. Basically, it boils down to signing:
.inf file, that references the Microsoft signed (and usually already installed) WinUSB.sys driver.cat file that is essentially the list of files that should go into the driver package (i.e. the name of the custom .inf and the Microsoft provided WinUSB.sys dependencies/DLLs)(NB: technically, since the .cat contains the hashes of everything else, it's really only the .cat that is signed, but for all intents and purposes, we can consider that we are signing both the .cat and the .inf as part of the driver package).
In other words, at no stage is libwdi trying to sign binary executables, and especially, it's not ever trying to sign kernel binaries to try to get them installed on the system.
And it is the certificate that was used to sign the driver package that libwdi installs in Trusted Publishers, so that, as has been the case on all versions of Windows until Windows 11 ARM64 (including current Windows 11 x64), the system will agree that the driver package can be trusted to start driver installation (and, as part of the installation process, can now perform a completely separate binary driver signature validation, on any kernel binary files that are to be installed).
So, the only logic that makes sense to try to restrict signed driver packages not to be trusted unless they use a non locally vetted certificate is if Microsoft now (or at least on ARM64) considers that .inf files can be exploited on their own (since again the binaries being installed will be vetted independently) to compromise a system, which, since AFAIK .inf files cannot execute commands, means that Microsoft is considering that a system can be exploited through registry alteration (since this is pretty much all a malicious .inf can do to try to alter a system)...
Oh, and I searched for RequireHardwareSecurity* keys on an affected ARM64 system, but did not find any...
jkunkee
commented
10 months ago Last I dove into it, ARM64's driver signing requirements are the same as x64 except that no attestation-signed drivers for it can exist since it shipped after new signatures were disallowed even on x64. At least, that's what I gathered.
Thanks @jkunkee, the attestation signing is being totally deprecated. But that means I have to go through HLK every time I want to publish a new driver? Or have you seen other, newer ways to fast-sign a valid driver?
I had this wrong. I'm told attestation signing is fine for ARM64 Client and is not deprecated. (I really need to find good external docs to point to about this; I can't be a source of truth for this, and anyways, I've already gotten it wrong once.) I'll write more on this thread when I find it.
RequireHardwareSecurityFeatures is a Value, not a Key, if that helps any. The docs I linked provide exact paths. Sorry this is so terse.
Bradavvon
commented
9 months ago 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.
Thanks so much for this. I wasn't able to find an answer and so would differ that this isn't well known and is a workaroud. By it's very nature is safe "for technically minded people", the option is very hidden in Windows and on my Surface Pro X even had to enter my Bitlocker Recovery Key to get to this option.
I'm pleased to add you only need to do this "to install the driver" and "if you change the physical device". Once installed it continues to work even with Driver Signature Enforcement re-enabled.
Thanks again.
dontech
commented
9 months ago I'm pleased to add you only need to do this "to install the driver" and "if you change the physical device". Once installed it continues to work even with Driver Signature Enforcement re-enabled.
This is fairly interesting. This means they did not change the signing rules for ARM64, but merely changed the driver installation rules which is not even in kernel space, but probably in some installation DLL (setupapi.dll or similar).
It still is a killer for Zadig, so it would be great if MS could fix this, as this does make self-signing stuff not work at all, which looks more like a bug than a deliberate decision due to the point you just made.
pbatard
commented
9 months ago as this does make self-signing stuff not work at all
Not exactly. It forces self-signing to be accomplished using an Authenticode certificate rather than a locally created one because (as far as I can tell) Microsoft restricted the driver package signature validation rules on ARM64 to no longer validate signatures whose certificate chain ends up in the system's "trusted" publishers (which encompasses both the Trusted Publishers store and the Trusted Root Certification Authorities, because validation breaks on ARM64 even if you install the cert in Trusted Root Certification Authorities) but instead only validate against a different internal trust chain, that includes Authenticode providers, but that the user no longer has any control on.
In short, it appears that, with the default Windows configuration settings of ARM64, Microsoft has done away with any form of trust chain where the user could exert some form of local control, to instead force everyone into the hand of third party trust only which, from a security standpoint, is quite the jump as we are talking about trust, and, in effect, Microsoft has taken away the ability for users to have any say about who they decide to trust (or not to trust), whereas this ought to be a fundamental freedom that any OS (or pre-OS environment) should always grant its users. Heck, even Secure Boot, which is a pre-OS environment, does not take away this kind of freedom as a proper implementation allows its user to use Setup Mode to install their own keys if they wish, which can be/usually are locally generated ones (and since you can still install the Microsoft Secure Boot certs, Windows will happily run with Secure Boot enabled in such an environment. And even better, at this stage, it is the user who chose whether they decided to trust Microsoft enough to run Windows on the hardware they own, rather than the other way around). Yet, when it comes to driver installation on ARM64, it appears that Microsoft has decided that removing the ability, for Windows users, of deciding who they trust was ultimately better... for them?
Anyway, to get back to the point, I don't believe this is a bug (especially as we have seen this behaviour appear in x64 Windows 11 Insider releases before, even as it's never made it to a formal x64 release yet), which seems to indicate that this is a deliberate restriction that Microsoft has been wanting/planning to introduce for some time, and ultimately decided that ARM64 was the best place to do. I am also pretty sure that the people who pushed to introduce this "feature" consider that there is no much of an issue with it, since people should "just" be able to sign their driver packages with third party Authenticode credentials (which of course, software like Zadig will never ever be able to do).
mcuee
commented
9 months ago I am more hopeful that Microsoft may change this policy once Windows on ARM64 gains some level of popularity. Right now I consider it as a failure in terms of market share. Once Microsoft ends exclusive relationship with Qualcomm and allows more vendors to come into the market, they may have to change the policy.
But maybe it is just my wishful thinking...
dontech
commented
9 months ago Not exactly. It forces self-signing to be accomplished using an Authenticode certificate rather than a locally created one because (as far as I can tell) Microsoft restricted the driver package signature validation rules on ARM64 to no longer validate signatures whose certificate chain ends up in the system's "trusted" publishers (which encompasses both the Trusted Publishers store and the Trusted Root Certification Authorities, because validation breaks on ARM64 even if you install the cert in Trusted Root Certification Authorities) but instead only validate against a different internal trust chain, that includes Authenticode providers, but that the user no longer has any control on.
Maybe. But why would they leave it open in the kernel driver loader, and then only restrict things when installing new drivers? That is why i concluded it was a bug, but you might be right.
It just seems odd from a security perspective to not allow something, but then still allow it if someone sneaks it in while your not looking (e.g. by temporarily disabling the enforcement).
mcuee
commented
9 months ago If Microsoft wants enterprise customers to use Windows on ARM64, they have to allow this method in the end.
Reference: https://community.osr.com/discussion/comment/302735
PeterViscarola(OSR) said in the above thread.
Just a side note (I have no experience to add about Win 11 and self-signed certs).
It’s easy for a lot of us to ignore this method of signing as a bad work-around for avoiding getting a “real” signature. But there are a significant number of Enterprise-level ISVs and (particularly) IHVs who use this method of driver signing. So, if a self-signed certs placed in the trusted publisher store no longer work, there a “a lot” of folks who are gonna be surprised come release time.
Bradavvon
commented
9 months ago It just seems odd from a security perspective to not allow something, but then still allow it if someone sneaks it in while your not looking (e.g. by temporarily disabling the enforcement).
The user has to actively jump through several hoops to do this I suppose. It's always been a buried option.
If Microsoft wants enterprise customers to use Windows on ARM64, they have to allow this method in the end.
Agreed with this. To many businessse and enterprises will expect this.
Right now whilst WoA numbers are low it's not hurting Microsoft but I expect numbers to grow eventually.
dontech
commented
9 months ago 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.
Done.
pbatard
commented
7 months ago For those looking for some kind of (not ideal) workaround for this situation, please see this entry from #288.
livinitwarrior
commented
4 months ago For those looking for some kind of (not ideal) workaround for this situation, please see this entry from #288.
Same, currently unable to do anything with my switch on my new Surface Laptop 7 :/
mcuee
commented
4 months ago Indeed with the new generation of Qualcomm Copilot+ laptops, Windows on ARM64 will be more popular (but I am not going to buy this generation of Qualcomm laptop). Let's see if Microsoft is willing to change the policy but looks not easy.
jkunkee
commented
4 months ago If Microsoft wants enterprise customers to use Windows on ARM64, they have to allow this method in the end.
A couple of thoughts around this (though I must stress I do not speak for Microsoft, my employer):
Really, this sounds like a bug to me since the aim I've generally seen is x64==ARM64 and "it's just Windows". (Windows RT is long, long dead; I helped bury its bones.) The first place to file a (concise, detailed, actionable) report is, yes, Feedback Hub. It may be helpful to share a Feedback Hub shortlink here so others can upvote it. It's even possible there's already an item for it; either way, I'd love to see it.
If you're an enterprise customer that wants to use Windows on ARM64 and one of your applications doesn't seem to be fully compatible (like, say, Zadig hitting the issue described here) or an enterprise feature is not working (like self-signed driver deployment via device management), ask your sales team about the App Assure program. They tend to get stuff fixed if it's anywhere in Microsoft code, and they'll even attempt to work with third-party software vendors if that's where the issue is. (Also, Parallels is a supported platform as of IIRC last year.)
If you're not an enterprise customer that can leverage App Assure and/or you have questions about ARM64 Windows, there's also the email address mentioned at the end of this page staffed by a handful of folks who know a few things and are pretty helpful.
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: https://github.com/pbatard/libwdi/issues/288 https://github.com/pbatard/libwdi/issues/155