
Quibble – Custom Windows Bootloader - Fnoord
https://github.com/maharmstone/quibble
======
rock_artist
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...](https://superuser.com/questions/1055305/installing-
windows-x64-on-32-bit-uefi-efi-ia32-via-grub)

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

[https://github.com/reactos/reactos/tree/master/boot/freeldr](https://github.com/reactos/reactos/tree/master/boot/freeldr)

~~~
HeckFeck
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
If so it goes both ways, because some files have referances to ReactOS. Like
peloaddef.h

~~~
ComputerGuru
And the configuration file is freeldr.ini

------
shawnz
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
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
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/](https://habr.com/en/post/446238/)

~~~
p_l
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
> 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
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...](https://docs.microsoft.com/en-us/windows-
hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-
guidance#2-key-management-solutions)

~~~
shawnz
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
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://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/)

[https://www.nsa.gov/Portals/70/documents/what-we-
do/cybersec...](https://www.nsa.gov/Portals/70/documents/what-we-
do/cybersecurity/professional-resources/csi-uefi-lockdown.pdf)

~~~
shawnz
> 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...](https://docs.microsoft.com/en-us/previous-
versions/windows/it-
pro/windows-8.1-and-8/dn747883\(v=win.10\)?redirectedfrom=MSDN)

"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
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
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
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
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
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
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.

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

~~~
djsumdog
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.

~~~
omgtehlion
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
Issues would be solved as soon as you'd be able to install a WIM image
directly, which should actually be possible.

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

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

------
jhallenworld
How do you prevent Windows Update from replacing it?

