Quibble – Custom Windows Bootloader

(github.com)

156 points | by Fnoord 142 days ago

7 comments

  • rock_artist 141 days ago

    One use case that would be amazing is actually be able to get 64bit Windows on those 64bit atoms with no 64bit bootloaders :(

    https://superuser.com/questions/1055305/installing-windows-x...

    • monocasa 141 days ago

      Neat. ReactOS has a similar piece of code called "freeldr".

      https://github.com/reactos/reactos/tree/master/boot/freeldr

      • HeckFeck 141 days ago

        I wonder if any of this code might be of use to ReactOS. Even just to extend its bootloader to cover other Windows versions, if it can't already.

        • torh 141 days ago

          If so it goes both ways, because some files have referances to ReactOS. Like peloaddef.h

    • shawnz 141 days ago

      One interesting use for this could be signing it with your own secure boot keys. This could let you lock a machine to only boot your system image and not others.

      • p_l 141 days ago

        Standard Windows bootloader already does that, it's part of supported deployment flow in highest security setting - in fact part of why MS requires that computers with certain Windows-related branding (the part about stickers "designed for windows" etc., I just don't remember which one) have to enable end users to replace platform keys.

        • rekoil 141 days ago

          Except the same keys have been used to sign some EFI loaders from other vendors, namely Kaspersky Rescue Disk 18, so it isn't really as locked down as they would have us believe.

          https://habr.com/en/post/446238/

          • p_l 141 days ago

            There are two keys distributed by MS - one for Windows, one for third party applications. The latter one is used by Linux shim bootloader and the like. MS also requires that all devices that are supposed to be "full featured" support replacing all keys and loading user keys, and the highest security deployment setup for Windows Enterprise requires that you sign windows bootloader (or, more likely, sign the hash of the specific binary you are using) yourself.

            • shawnz 141 days ago

              > the highest security deployment setup for Windows Enterprise requires that you sign windows bootloader (or, more likely, sign the hash of the specific binary you are using) yourself.

              To my knowledge that's not possible with the Microsoft bootloader, you need to use Microsoft's keys, hence why I am suggesting that this open source bootloader could be useful. Can you provide some more information about such a setup?

              • jedieaston 141 days ago

                This document is aimed at OEMs, but they specifically say that high-security environments can generate Secure Boot keys and use them on their devices in conjunction with their own Windows image. (I’d imagine that you need the Windows SDK and some know how/MS consulting to get it working, though)

                https://docs.microsoft.com/en-us/windows-hardware/manufactur...

                • shawnz 141 days ago

                  This document is about generating the platform key, but changing the platform key alone doesn't allow you to do what I'm suggesting. Even after setting your own platform key you would still need to trust the key for Microsoft's bootloader. See section 1.4.1:

                  > The Microsoft Windows Production PCA 2011 with a SHA-1 Cert Hash of 58 0a 6f 4c c4 e4 b6 69 b9 eb dc 1b 2b 3e 08 7b 80 d0 67 8d must be included in db in order to allow the Windows OS Loader to load.

                  • p_l 141 days ago

                    For OEM to allow reinstall done "normally", yes.

                    But DB entries can also contain SHA-256 hashes of the image to load (with the image stripped of the signature, which btw allows you to also resign it).

                    https://blog.hansenpartnership.com/the-meaning-of-all-the-ue...

                    https://www.nsa.gov/Portals/70/documents/what-we-do/cybersec...

                    • shawnz 141 days ago

                      > which btw allows you to also resign it

                      Are you sure? I havent tried, but this disagrees: https://docs.microsoft.com/en-us/previous-versions/windows/i...

                      "Windows boot components: BootMgr, WinLoad, Windows Kernel Startup. Windows boot components verify the signature on each component. Any non-trusted components will not be loaded and instead will trigger Secure Boot remediation. "

                      > DB entries can also contain SHA-256 hashes

                      OK, fair enough, but it still doesn't really solve the problem because an attacker could just copy your modified bootmgr to be able to steal and use your workstation. In order for this to work you'd also have to add some kind of additional checks which we can now do with an open source version of the bootloader.

                      • p_l 139 days ago

                        The signatures are, IIRC, checked in order, so a resigned BootMgr won't impact verification of WinLoad, etc.

                        As for abusing signed bootloader, the full process depends on verifying that the signed bootloader appropriately handles TPM, which is then also coupled with an encrypted disk, which in turn works to prevent loading unsanctioned code.

                        Of course, it's possible to defeat this, but the idea is to frustrate the efforts and raise the cost of an attack, as well as give you a longer timeframe to deal with an attack.

                        • shawnz 138 days ago

                          Those mechanisms only prevent an attacker from decrypting the disk. The scenario I'm envisioning is where the attacker steals your workstation, wipes the disk and reinstalls Windows.

                          • p_l 136 days ago

                            That's not part of the threat model - the encrypted data is lost, the point of the defences are to prevent damage to things accessible from that specific machine, not to prevent stealing the machine.

                            • shawnz 136 days ago

                              That's not part of Microsoft's threat model. Which is exactly the problem! It could be done, if only Microsoft supported that use case. But with an open source bootloader, we could make the necessary changes ourselves.

                              • p_l 134 days ago

                                No, that's the threat model that most clients that require high security have (the machine is often nigh-infinitely cheaper than the data and access rights), and MS, surprise, explicitly insists (in difference to secure boot spec) that owner of the physical machine is, well, it's owner and can reinstall, resell, etc.

                                • shawnz 133 days ago

                                  I don't see how any of this is relevant. All I said was that it's an interesting possibility which has now been made feasible. Who cares about the threat model that most high security clients have? If they don't want it then I'm not talking about those clients.

                                  Besides: the prevalence of terrible software like Lojack/CompuTrace in the enterprise just goes to show that many clients actually do care about physical theft scenarios. Also consider how basically every modern mobile device now provides factory reset protection.

                • p_l 141 days ago

                  The basic procedure is as follows:

                  - Remove all keys (switch to Setup mode) - Setup your own PKI and platform keys - Sign hash of specific EFI files and load those signatures into EFI

                  The last part doesn't require modifying files themselves, as you're locking specific files. The firmware will make a hash of the file, and verify that it's on permitted list (the list is signed)

                  • shawnz 141 days ago

                    If I'm not mistaken it's actually a hash of the file's signature that you have to register, not a hash of the file itself. And Bootmgr will not allow you to change its signature. Thus any computer that is configured to boot Windows with secure boot will be able to boot any copy of Windows.

              • beojan 141 days ago

                Not if you replace the keys with your own.

                • rekoil 141 days ago

                  Sure, and I do that, but most users will not, they will select Secure Boot and think that their boot is now secure.

          • shanemhansen 141 days ago

            That's super cool. I would be much more likely to keep windows around if it could boot from a btrfs volume.

            • djsumdog 141 days ago

              I thought about that too, but looking through the README, there are some considerable complications (and funny bugs). The author has tested this on a lot of Windows versions!

              I feel like this was a toy/thought experiment that turned into learning a lot about Windows, EFI, bootstraping, etc.

              • londons_explore 141 days ago

                It looks like windows can't copy some in-use files, and Linux can't copy some attributes.

                Why not copy as many files as possible with windows, and then go to Linux to copy the last few?

                • omgtehlion 141 days ago

                  Most of funny bugs arise from not-really-exact filesystem copying during install. But making a perfect duplication tool seems to be out of scope of this project.

                  Nice experiment, anyway.

                  • my123 141 days ago

                    Issues would be solved as soon as you'd be able to install a WIM image directly, which should actually be possible.

                    • rekoil 141 days ago

                      I thought about that as well, can't we just load the WinBtrfs driver from the installer?

              • appleflaxen 141 days ago

                This looks like an awesome project; if the author is here: well done!

                • jhallenworld 141 days ago

                  How do you prevent Windows Update from replacing it?