How a Pi‑powered cyberdeck rabbit hole led me to rediscover boot media, Secure Boot’s guardrails, and a new way to carry my security tooling around.

It is funny how one thing often leads to another. I happened to catch some videos on very cool, Pi‑based cyberdecks and it hit my geek button. I spent the next several days abusing my very limited free time exploring hardware and software I had not seen before. The state of the art today is miles beyond my first Raspberry Pi project: OLED screens, integrated keyboards, multiple radios, flexible power options, and truly portable builds. The more I looked, though, the more I realized they still are not quite where I would need them to be to justify building or buying one.

So I shifted my gaze to the software toolsets. I started looking at the current state of penetration testing platforms, privacy and anonymity tools, and data recovery and forensic preservation. Many of the same groups custom building interesting cyberdecks also sell USB or SSD drives with Kali, ParrotOS, or BlackArch, sometimes all three, preinstalled with custom tools and scripts. They are often priced far higher than you would want to pay if you are capable of building something similar yourself. That realization sent me back down a road I had not travelled in a while.

Along the way, the one unexpected thing I relearned is that all the work done with Secure Boot to keep untrusted code out of the boot path on enterprise‑grade machines, whether that is a rogue operating system, a custom toolkit on a USB stick, or full‑blown bootloader malware has made it very challenging to boot Linux from a portable drive unless you stay within a narrow set of rules. In practice, many of the security‑focused live distros I wanted to use are not signed in a way that typical enterprise firmware will trust by default, even with Microsoft’s third‑party UEFI CA enabled, which means Secure Boot quietly kills them before they ever get to a GRUB menu. While this is irritating when you are trying to do something fun, it is remarkable how far we have come in preventing a workforce from being easily victimized by a threat actor with a USB stick, some basic know‑how, and physical access to a laptop.

That experience also punctuated a basic operational point. Without access to firmware settings, to either turn Secure Boot off or configure it to accept specific third‑party signatures, booting the kind of portable toolkit I wanted to build was a non‑starter on most enterprise systems. It also made clear that anyone not locking their firmware down with a password, either administratively or as an end user, should seriously consider doing so. If you are going to rely on these protections, you need to make sure the controls that guard them are not wide open.

Ventoy, where were you when I needed you? Long ago, my job required me to carry a bunch of burned OS install CDs for repairing or reinstalling machines that had problems or needed upgrades. I had those big black binders of discs that I hated having to carry around. Once USB boot became practical and thumb drives became affordable, you could hack them to replace a boot CD. Over time, those hacks became codified into tools like Rufus so you could have a USB stick per operating system. USB thumb drives were easier to carry than binders of discs, but if you had enough of them, keeping them organized for regular use was a greater chore than you might imagine.

Multiboot tools were a revelation. YUMI, Your Universal Multiboot Installer, and tools like it allowed you to boot multiple ISOs from a single USB stick. Earlier utilities and home‑rolled GRUB configurations did similar things, but YUMI and its peers made it approachable. The tradeoff was that these tools generated or modified a bootloader configuration and often unpacked or specially integrated each ISO into the structure they created. When new ISOs were released, you typically had to rebuild your multiboot USB to add or update entries. It was a burden we were more than willing to carry, given where we had been, but still a burden.

Ventoy changed the ergonomics of that process. Instead of constantly rebuilding the stick, you install Ventoy once, then copy ISO, WIM, or IMG files to it and boot them through a generic ISO boot mechanism. You do not have to re‑generate the stick every time you want to add or update an image. For someone who used to drag binders of discs through airports, that feels almost luxurious.

“Nice story, bro.” I know. That is usually what people say when someone goes way deeper than the audience signed up for. A walk down memory lane is my prerogative at this stage of my career, but there is a point to it.

What I set out to build this time was a multi‑boot USB SSD toolkit. My requirements were simple in concept. I wanted an SSD in a small format that could connect to USB‑A or USB‑C and had enough storage for tools, drive images, virtual machines, and investigative artifacts. I wanted the usual suspects, the security testing platforms you see encapsulated in distributions like Kali Linux, ParrotOS, and BlackArch. I wanted a base, stable Linux install I could treat as “home.” I also wanted a dedicated, encrypted data partition I could trust.

My plans changed when I ran head‑first into the Secure Boot reality I had been rediscovering. Kali, ParrotOS, and a few others simply would not boot reliably under Secure Boot on the kinds of systems I care about. My original idea was to have dedicated boot options into each of those operating systems from the SSD, all sharing the same encrypted data partition. On paper that looked elegant. In practice it was not very versatile, because it depended on being able to change firmware settings on every system I might want to use.

So I changed direction. I settled on a single operating system partition built on Ubuntu. With Kali, ParrotOS, and friends out of the picture as native boot options, I made a list of the most important tools I actually needed and installed them on Ubuntu, being careful not to create conflicts or a maintenance nightmare. To keep things sane, I wrapped the whole toolkit in a small utility I call “secmenu.”

secmenu is a root‑run, plain text security toolkit launcher that installs a curated set of security, forensics, networking, and recovery tools on top of Ubuntu and then gives you a simple terminal menu to reach them. From that menu you can get to examples, disk imaging and cloning workflows, rescue tasks, and a combined tool and version dashboard. Under the hood, it drops a small configuration file at /etc/secmenu.conf, keeps notes under /usr/local/share/secmenu-notes.txt, and puts its main executable at /usr/local/bin/secmenu, where it logs activity, supports debug or plain mode, and wraps common commands like nmap, ffuf, tcpdump, dc3dd, and gddrescue behind an easier interactive interface. The “why” is straightforward. It gives you a faster, safer front door into a broad security toolkit that happens to run on Ubuntu. Instead of memorizing commands or rebuilding the same workflows every time, secmenu centralizes the tools, surfaces command examples, and walks you through higher‑risk tasks like disk imaging or cloning with confirmations and logging.

The end result is not what I originally intended, but that turned out to be fine. Now I have a portable Linux environment that enables me to do a lot of what I care about in a flexible way. More than that, the process forced me to catch up on a lot of things that had quietly moved on while I was focused elsewhere. It felt like a homecoming of sorts, and a practical example of something I often tell others. No matter where you are in your career journey, it is sometimes rewarding to go back down roads that are now less travelled, not just to see what has changed, but to rebuild a sense of perspective you can carry into the next thing you decide to explore.

Editorial Note – June 21, 2026

After I wrote this, Wired picked up a piece written by Dan Goodin and published in Ars Technica about a looming deadline for updating the cryptographic keys used by Secure Boot on Windows and Linux systems (“A Critical Deadline is Approaching for Windows and Linux Security”). The premise is simple but important: those keys are there to make sure only trusted bootloaders and kernels run, so that UEFI‑level malware and bootkits cannot silently wedge themselves into the boot sequence. Some of the certificates in that chain are expiring and need to be updated, or you risk either breaking boot or weakening the protection you think you have.

I am not going to rewrite this article around that news, but it is a timely reminder. Secure Boot is not just there to annoy people trying to boot an unauthorized operating system from USB. It is meant to stop entire classes of bootloader and firmware‑level attacks, and it has to evolve, rotate keys, and ship updates to keep doing that job effectively.