Hacker News new | comments | show | ask | jobs | submitlogin
Quibble – Custom Windows Bootloader (github.com)
156 points by Fnoord 5 months ago | hide | past | web | 32 comments | favorite





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


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

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


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.

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

And the configuration file is freeldr.ini

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.

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.

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/


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.

> 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?


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


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)


Not if you replace the keys with your own.

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

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

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.


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?


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.


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

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

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

How do you prevent Windows Update from replacing it?



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: