Do you find yourself with a piece a computer hardware that is locked via the BIOS with an unchangeable secure boot setting, but you want run a non-Microsoft-approved Linux on it? Then you found the right place, because that’s exactly what this is about.

This piece is a cautionary tale about security and ‘if there’s a will there’s a way’. It is explicitly not about hacking, since no reverse engineering or exploits have been used to perform this parasitic (software) transmutation. However, first things first.

How did this situation come about?#

A recent malheur on my side (salted water) caused my beloved second-hand 2016 ThinkPad X1C’s keys to stop working, at least partially, however annoyingly enough so that I was only able to use the laptop with an external keyboard and mouse. And before you ask, I did replace the keyboard before “giving up” on the machine. My best guess was a short on the motherboard and I am quite certain about that being ultimately the cause, as my local maker/hacker/repair space (shoutout to TuDo) also came to that conclusion.

That meant, I was in for a new laptop. Exciting, I know. So obviously, I scavenged my local second-hand resource options and I stumbled upon an offer for another (almost) equivalent ThinkPad X1C, but a newer generation and more importantly, cheaper than what I got my old one for. Also, the guy who sold it lived only a few blocks away from me. And if he hadn’t I probably wouldn’t have been inclined to even bother with this option because it most definitely seemed to be too good to be true.

Once we agreed on a time, I walked over to the sellers place. He was a nice fellow, repairing computers and laptops as a hobby. He seemed to know what he was talking about when it came to computer hardware and Windows. The moment I mentioned that the Windows install would most definitely not survive in my hands and quickly be overwritten by Linux, he became very humble and midway stopped explaining to me where to find Word and Excel on the desktop. He told me that he had no real experience with Linux, but he’s sure that I’ll manage to deal with it. As a precaution I brought along with me an Ubuntu USB stick that I had lying around, just to check if anything might be wrong. The BIOS had a supervisor password that the seller knew and also shared with me. Everything seemed to just work and I happily exchanged a fair (as in fairly priced) amount of money for the little machine.

So far, so good. Where did it go wrong?

You must imagine my confusion after 3 attempts (dd/gparted, Gnome Disks & Rufus on Windows, in that order) of creating a boot partition for the NixOS installer image on my USB stick and none of them would be bootable. And Ubuntu was just happy to announce to me that it’s ready to be installed every time I tried the same method. Right about that moment, I had the realization that it must be a BIOS setting, and lo and behold, I found out that NixOS does not support secure boot on a fresh install.

‘Easy enough’, I thought, ‘I don’t need secure boot. Let me turn it off.’

How to open Pandora’s (Secure Boot) Box#

As you can imagine, disabling secure boot turned out to be not only a major, but also an insurmountable obstacle. In this section, I will illuminate on the experience and the inevitable surrender. In the next section, I present an option on how to perform an unconventional install of NixOS that manages to succeed even though secure boot was never disabled on the target machine.

Let me state the condition that I found my machine in:

BIOS is accessible via supervisor password
settings in the SECURITY & TIME/DATE sections were grayed out and unchangeable

This resulted in an awkward situation, where even though I know the supervisor password, I was and still am unable to change the supervisor password or any other security related setting. Some kind of BIOS lock was set into place from the previous owner. This is the exact moment I found about what CompuTrace and its parent company Absolute software are (definition from the Wikipedia article):

CompuTrace is a proprietary laptop theft recovery software (laptop tracking software). The persistent security features are built into the firmware of devices. Absolute Home & Office has services of an investigations and recovery team who partners with law enforcement agencies to return laptops to their owners.

I highly recommend reading the Vulnerabilities section on Wikipedia, to understand the implications of this practice. However, long story short, Lenovo basically agreed to ship a Trojan horse in professional grade BIOSes to prevent device and data theft. Since the trojan communicates via Windows with the outside world, Absolute software has direct access from their centralized server to any BIOS that is registered via their program. In case of theft, Absolute software is able to remotely lock down laptops that have been reported as stolen.

And guess what, my BIOS showed me that Computrace is activated, however not triggered. The internet told me that it meant most likely that my machine was not previously stolen. People also wrote that you could reach out to the company to potentially deactivate the BIOS lock. This seemed a little bit far fetched, but maybe worth a shot if nothing else sticks.

My approach of dealing with this situation was first trying out the low hanging fruits and increasingly upping the complexity. I sketched out a plan, where I hoped that earlier points would work out magically what is going on:

Solve it within Windows

Reinstalling Windows 11 again via Recovery Mode and then using the Lenovo Help Center to install drivers and BIOS updates.

Solve from a USB live Linux environment

Using fwupdmgr from the Ubuntu Live Disk to potentially update drivers & BIOS that are specific for Linux.

Hardware BIOS reset

Disconnecting the CMOS battery for some time to potentially reset the BIOS (which I knew was most likely not gonna work with these newer ThinkPad models).

There are more involved ways to try and reset the BIOS, however none are officially supported by Lenovo. Before trying those methods, please consider first all other options before potentially damaging a machine that otherwise could easily run Ubuntu, Fedora or Windows.

Contact manufacturers

The interaction with both Absolute Software as well Lenovo were both pleasantly surprising. As it turns out, calling customer service (even tough you’re not really a customer) still works with certain places in 2025.

The answer I got from Absolute was that my device was never registered in their system. So they had no means to deactivate anything hadn’t been activated in the first place. At least now I knew that my device had not been reported stolen and most likely was a genuine resell. Unfortunately, Lenovo confirmed my fear that this BIOS lock down was not error, and the previous owner (likely a company) enabled certain settings in the BIOS that made it impossible to change any security settings. In hindsight, I should have called Lenovo in the first place. Lesson learned, I guess… However, that leaves me with two options:

The only way forward would be to change the motherboard or accept that secure boot is to stay.

An Infectious Idea#

While I was waiting for Lenovo’s customer support to get back to me, I befriended myself with the thought that I might have to figure out a way to solve this problem from the NixOS perspective. What is the reason that I can’t boot into it anyway?

Major distributions like Ubuntu (and it’s derivatives, but don’t quote me on that) as well as Fedora do seem to ship with signed Microsoft keys for a boot process called shim. Here’s a definition from the Gentoo wiki:

Shim is an alternative method of managing accepted Secure Boot keys without touching the UEFI firmware settings. In its simplest configuration, shim will just chainload any EFI executable.

This is how Ubuntu uses it in production:

Shim is the pre-bootloader that runs on UEFI systems, meant to be a bit of code signed by Microsoft, that embeds our own certificate (which signs our grub binaries), so that it can load the “real” bootloader: GRUB.

So let’s take note. In a secure boot environment, UEFI will only successfully grant permission to load a (pre-)bootloader if the keys within the TPM memory match a SHA256 hash of the binary’s signature. The following loader(s) as well as the kernel later on must match the same signature, otherwise it can’t be loaded:

secure boot environment                                            
┌──────────────────────────────────────────────────────────────────┐
│                                                                  │
│ ┌──────┐verify┌────────────┐verify┌────────────┐verify┌────────┐ │
│ │ UEFI ┼──────►  shim.efi  ┼──────►  grub.efi  ┼──────► UBUNTU │ │
│ └──────┘ only └────────────┘ MS & └────────────┘ MS & └────────┘ │
│          MS                  MOK                 MOK             │
│          keys                keys                keys            │
│                                                                  │
└──────────────────────────────────────────────────────────────────┘

Fig. 1: Ubuntu boot sequence in secure boot mode

There are projects that try this exact approach for NixOS like this repo. However, advancement seems slow or non-existent as of writing this. Since NixOS does not have their own Microsoft-signed keys to present via shim, we can’t go down this road (yet).

Another notable project from BeardedTek tried the lanzaboote approach that would place self-signed keys in its own boot stub and chainloads a self-signed GRUB and Linux kernel from there. However, we get a Catch 22, since it only works if a working NixOS system is already present on the system. And to get a working NixOS on the system, one has to disable secure boot… Which makes it clear that this is only really viable as a post installation method (and also only if you can even access the keys within the TPM chip and change them).

Then I finally found the missing piece for this puzzle: Yigong Liu’s take, which was primed by nixos-infect, a non-secure-boot-related transmutation of desktop Linux OSes into NixOS on hosted server platforms.

The basic idea is to install nix, the package manager, on a foreign Linux system and then slowly but surely transform that OS into NixOS that finally boots into GRUB pointing at all the NixOS generations. This is how Yigong Liu successfully did the experiment with the aspect of transmuting Ubuntu into NixOS while leaving the shim with the Microsoft-signed keys in place. One key aspect that we have understand, though, is that GRUB and the kernel distributed by nixpkgs are not signed with those Microsoft keys. Wouldn’t that interrupt the boot process? Exactly. That’s where the MOK (Machine Owned Keys) manager comes into play.

MOK is the interface between the shim and post-shim loader. It is designed so that the user can place their own (or someone else’s) keys within shim, so that the post-shim loaders can trust those keys as well. This is often used to get i.e. NVIDIA kernel drivers to work. However, there is also the possibility to disable validation. You can probably anticipate what comes next. Exactly, this puts the shim loader into insecure mode and makes it completely disregard any signature from any loader or kernel thereafter.

secure boot environment          insecure boot environment          
┌─────────────────────┐ ┌──────────────────────────────────────────┐
│                     │ │                                          │
│ ┌──────┐verify┌─────┴─┴────┐ignore┌────────────┐ignore┌────────┐ │
│ │ UEFI ┼──────►  shim.efi  ┼──────►  grub.efi  ┼──────► UBUNTU │ │
│ └──────┘ only └─────┬─┬────┘ keys └────────────┘ keys └────────┘ │
│          MS         │ │                                          │
│          keys       │ │                                          │
│                     │ │                                          │
└─────────────────────┘ └──────────────────────────────────────────┘

Fig. 2: Ubuntu boot sequence + shim with disabled validation

Let’s recap. Starting from Fig 1. we are able to hijack the Ubuntu shim loader by telling it to ignore all signatures, meaning sudo mokutil --disable-validation as seen in Fig. 2. The next step involves copying all the files except grub.efi from /boot/EFI/ubuntu/ to a new folder called /boot/EFI/NixOS-boot/. Since they all reside on the same boot partition, we can now mess with the EFI boot scheme, by creating a new entry sudo efibootmgr -c -L "NixOS" -d <partition> -l "\\EFI\\NixOS-boot\\shimx64.efi" and changing the boot order, so that it chooses NixOS per default. I would highly recommend keeping the Ubuntu entry around and confirming that everything works as expected before removing both the EFI entry and the /boot/EFI/ubuntu/ folder! Take a look at Fig. 3 for the full configuration.

secure boot environment          insecure boot environment          
┌─────────────────────┐ ┌──────────────────────────────────────────┐
│                     │ │                                          │
│ ┌──────┐ENTRY0┌─────┴─┴────┐      ┌────────────┐      ┌────────┐ │
│ │ UEFI ┼──────►  shim.efi  ┼──────►  grub.efi  ┼──┬───►  GEN1  │ │
│ └────┬─┘      └─────┬─┬────┘      └────────────┘  │   └────────┘ │
│      │              │ │               NixOS       │   ┌────────┐ │
│      │              │ │                           ├───►  GEN2  │ │
│      │              │ │                           │   └────────┘ │
│      │              │ │                           │   ┌────────┐ │
│      │              │ │                           └───►  GEN3  │ │
│      │              │ │                               └────────┘ │
│      │  ENTRY1┌─────┴─┴────┐      ┌────────────┐      ┌────────┐ │
│      └────────►  shim.efi  ┼──────►  grub.efi  ┼──┬───► KERNEL │ │
│               └─────┬─┬────┘      └────────────┘  │   └────────┘ │
│                     │ │               Ubuntu      │   ┌────────┐ │
│                     │ │                           └───► KERNEL │ │
│                     │ │                               └────────┘ │
│                     │ │                                          │
└─────────────────────┘ └──────────────────────────────────────────┘

Fig. 3: Parasitic boot sequence where NixOS takes over the first boot entry and effectively knocks Ubuntu off the thrown

With all of this is place, it’s theoretically time to reboot and see if everything worked out. However, I was obviously scared shit-less and wanted to test this sequence of events before somehow soft-locking my precious laptop.

That’s why I took Yigong Liu’s instructions and chained them together.

A Leap of Faith#

Before going down into the nitty-gritty, one of the nice things about nix and NixOS: all the relevant packages are placed in /nix/store/ which means that the creation of the parasitical infection is completely orthogonal to the host OS. The goal is to install nixos-install-tools which comes with the very handy nixos-generate-config command. It looks at the current setup, figures out all hardware related specifics and writes them to a file that NixOS can use to generate a working configuration. Once the system is ready to perform the host-OS switch, it calls the NixOS command to place a new root which preserves the old_root as well.

With all of that in mind, I tested all of these principles in a KVM (kernel-based virtual machine), which worked shockingly well. I don’t have much experience with virtual machines, but I’m just blown away by the accuracy that these emulators can (I assume nowadays) reproduce behavior compared to the real deal. So let’s see how that went:

It’s possible to start the guest in a secure boot environment and I also confirmed that I could not install NixOS in that scenario. So far so good. Now, with a fresh install, I created snapshots in virt-manager to easily roll back in case something went wrong (which happened often enough).
I had to hunt down the specific bugs that I ran into during script execution which for example involved the recent sudo-rs addition of Ubuntu 25.10. When installing nix (at least up to the point of writing this), its runtime lies in a path that will not be part of the /etc/sudoers file. You have to manually add it, which I assume will likely be fixed soon.
A prerequisites script became necessary, since I had to roll back so many times. I needed to sanity check myself that some binaries must be be installed and found in $PATH. After successfully booting into NixOS on the virtual machine (and yes I checked, secure boot was still enabled), I slowly refined the script to account for some corner cases and building my confidence on performing the ritual on my real hardware.
The only caveat I had to confirm was that I was able to disable MOK validation, since I read online that this sometimes does not work with locked down BIOSes. Lucky for me, for the first time in this whole ordeal, I was able to disable secure boot (only in Linux, but who cares?).

This gave me immense hope and I ran the script for real and drumroll…

I am currently writing this blog post on the working NixOS laptop with an eternal secure booted BIOS. The bash script ran flawlessly (at least) for me.

Disclaimer#

The caveats and descriptions for a Ubuntu deployment (for a secure boot enabled VM and real metal) of this method are available in this repository. However, I want to point out that if you run my script on a real machine:

I shall not be liable for any indirect, incidental, special, consequential, or punitive damages, including loss of profits, revenue, data, or use, incurred by the user of this bash script. The risks have been made clear, in case of deployment on bare metal.

Please use common sense and only try this out on a fresh Ubuntu install or “throw-away” machine. At the very least, please back up your data.

Final Thoughts#

This was a very fun adventure and deepened my understanding of the general Linux as well as the NixOS boot process. I hope I was able to provide a good explanation of this process and hopefully help a soul or two that got stuck in the same situation as me.

I chose NixOS as my non-Microsoft-approved Linux, however I think this serves only as an example and should be applicable to many other non-standard flavours. Also, technically Ubuntu does not need to be the base for the parasitic host, and any other secure boot enabled Linux can take this role. I chose it because Yigong Liu used it in his instructions and it was my first Linux experience, so there’s also the familiarity factor.

NixOS is also a Parasite - A Secure Boot Story