Reverse-Engineering-Tutorial VS uefi-ntfs

Thank you so kindly! Yes it is if someone is lost I would suggest the larger course here to get greater background https://github.com/mytechnotalent/Reverse-Engineering.

Because we use UEFI:NTFS to ensure that:

Indeed, that 1 MB volume is the UEFI:NTFS partition that is described here.

> Can you please link me some articles/references?

Well explained here: https://gabrielsieben.tech/2022/07/29/remote-assertion-is-co...

So the issue is not the SecureBoot itself, but the ways it can and has been and will be leveraged against the user. If a desktop computer example is not enough, look at how Android phones have increasingly tightened down everything. You can't just take any model and install a custom OS (aka ROM in Android community). It was universally easy 10 years ago, that's why Cyanogenmod became so popular. Now your choices are very limited.

> \> > But that is besides the fact that these acts of aggression

A great thread and arguments provided here, how Microsoft (who love open source, according to own PR) will not sign anything GPLv3 for SecureBoot: https://github.com/pbatard/uefi-ntfs/issues/20#issuecomment-...

Microsoft has the defacto monopoly over the signature process, because nobody embeds any CAs in UEFI except for Microsoft's. What would be a user-friendly way? To preload UEFI with major Linux distros' keys, disabled by default, with an easy first-time setup menu to select what to do.

My laptop came with SecureBoot enabled by default although being "OS: FreeDOS" on paper. I had to figure out to disable it to boot into a live distro else it fell into an EFI shell.

> Vote with your wallet, don't buy the hardware.

> ... I am much more concerned about Intel ME and AMD PSP, where's the outrage about that?

With this I just want to say the wallet argument doesn't work when something slowly becomes the status quo and it takes experts/activists to fight back (a minority by numbers).

> I still can't easily utilise a TPM [...] and nobody bothered to integrate the functionality?

I agree, I'd have liked to enforce SecureBoot post-installation but it is too much hassle for me, I think only RedHat made good improvements in this area where it's actually easily usable (auto signing the kernel image etc.)

> Security isn't about what's unlikely, it's about the entire chain.

... But if I followed through, then still the weakest point is/becomes the keyboard. It would be trivial for an evil maid to add a keylogging device between your desktop and the physical keyboard. Do you check the rear IO on each boot? The considerations differ for laptops where you can't just plug something inbetween and need to disassemble it (time required: over night or airport luggage).

Please see here or here.

I am the developer of Rufus, and I have spent an inordinate amount of time making sure that, YES, EVEN UEFI COMPUTERS THAT ARE "ALLEGEDLY" ONLY MEANT TO SUPPORT FAT32 FOR BOOT CAN ACTUALLY BOOT FROM THE NTFS PARTITION CREATED BY RUFUS (through the magic of a little solution called UEFI:NTFS). See also this entry from our FAQ.

For more details about the second UEFI:NTFS partition, see https://github.com/pbatard/uefi-ntfs.

Rufus dev here. That's the UEFI:NTFS partition, needed to boot computers that don't have a native NTFS driver and it is completely harmless (and uses a negligible amount of space since it's just 1 MB). So, yes, this is meant to happen.

So if you want to copy the contents of the ISO as is, you need to extract them to exFAT or NTFS (which are file systems that the Windows installer can also read outside of FAT), but this means that you may have to install an exFAT or NTFS UEFI driver to chain load the Windows installer, which is why utilities like Rufus and WoeUSB add a 1 MB UEFI:NTFS partition at the end of the drive, that takes care of that.

Rufus uses UEFI:NTFS, and therefore WILL allow your firmware to boot from NTFS. So, no, you don't have to use FAT32, and you should let Rufus create the drive with NTFS, as, even when using NTFS, it will create a drive that can be booted from UEFI.

If it's because Rufus creates 2 partitions, then you should read about this (UEFI:NTFS is what Rufus uses to boot drives that are NOT compatible with UEFI, such as ones where you cannot use FAT32 because they contain a file that is larger than 4 GB), and understand that the data on the NTFS partition is exactly the same as the one you'd have found on a FAT32 drive, if your data was suitable for FAT32.