11 ms·

Quibble – Custom Windows Bootloader

156 points by Fnoord 7y ago

shanemhansen 7y ago
That's super cool. I would be much more likely to keep windows around if it could boot from a btrfs volume.
- djsumdog 7y 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.
  - omgtehlion 7y 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 7y ago
      Issues would be solved as soon as you'd be able to install a WIM image directly, which should actually be possible.
      - rekoil 7y ago
        I thought about that as well, can't we just load the WinBtrfs driver from the installer?
  - londons_explore 7y 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?
monocasa 7y ago
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 7y 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 7y ago
    If so it goes both ways, because some files have referances to ReactOS. Like peloaddef.h
    - ComputerGuru 7y ago
      And the configuration file is freeldr.ini
shawnz 7y 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 7y 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 7y 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/ https://habr.com/en/post/446238/
    - beojan 7y ago
      Not if you replace the keys with your own.
      - rekoil 7y ago
        Sure, and I do that, but most users will not, they will select Secure Boot and think that their boot is now secure.
    - p_l 7y 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.
rock_artist 7y 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-x64-on-32-bit-uefi-efi-ia32-via-grub https://superuser.com/questions/1055305/installing-windows-x...
deleted 7y ago
[deleted]
appleflaxen 7y ago
This looks like an awesome project; if the author is here: well done!
jhallenworld 7y ago
How do you prevent Windows Update from replacing it?

156 points by Fnoord 7y ago

shanemhansen 7y ago

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

djsumdog 7y 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.
- omgtehlion 7y 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 7y ago
    Issues would be solved as soon as you'd be able to install a WIM image directly, which should actually be possible.
    - rekoil 7y ago
      I thought about that as well, can't we just load the WinBtrfs driver from the installer?
- londons_explore 7y 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?

monocasa 7y ago

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 7y 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 7y ago
  If so it goes both ways, because some files have referances to ReactOS. Like peloaddef.h
  - ComputerGuru 7y ago
    And the configuration file is freeldr.ini

shawnz 7y 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 7y 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 7y 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/ https://habr.com/en/post/446238/
  - beojan 7y ago
    Not if you replace the keys with your own.
    - rekoil 7y ago
      Sure, and I do that, but most users will not, they will select Secure Boot and think that their boot is now secure.
  - p_l 7y 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.

rock_artist 7y 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-x64-on-32-bit-uefi-efi-ia32-via-grub https://superuser.com/questions/1055305/installing-windows-x...

deleted 7y ago

[deleted]

appleflaxen 7y ago

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

jhallenworld 7y ago

How do you prevent Windows Update from replacing it?