I worked on Fuchsia for about 5 years. Somewhere maybe around half way through, I think it was during a Christmas vacation, someone wrote in that they were still away from their desk, and they'd not bricked their test device, but nearly - they could no longer install new software via the regular path as they'd done something to one of the filesystem runtimes or the like and that broke some of the components. Along the way they'd also bricked the alternate boot path, so they couldn't use the regular "paving" strategy (like a flash, but for regular disks and a bit faster/higher level).<p>I'd been working on the system bootstrap and verified execution chain, and often had to cobble stuff together in our shell. The shell on Fuchsia is a bit weird though (also my doing, largely), we'd avoid installing most software, and instead most of the programs in the shell are little stubs containing e.g. `#!resolve fuchsia-pkg://fuchsia.com/vim#bin/vim`. If you have bricked your update system you can't run those programs, as you can't resolve an up to date and safe version of vim. What was there though, was always a very small number of utilities from sbase. If you were to pick between sbase, toybox, busybox and so on, I'm not necessarily sure you'd pick sbase, but for Fuchsia it was definitely one of the easier to port for a variety of reasons.<p>So you have basically a hexdump tool, cat, and a hacked up version of dash as a shell (a POSIX shell, essentially, on a system without fork, ttys, signals or sessions, so it worked a little differently). A similar set of constraints to this article.<p>I sent them an email which looked something like: run lsblk on target and capture the output. mount the efi device to /mnt, assuming it's good that's fine. copy files using the pattern "cat file | ssh target 'cat - > target-path'". Copy the following files in build-name:target-path form: zircon.bin:/mnt/zircon.bin bootx64.efi:/mnt/EFI/BOOT/bootx64.efi ramdisk.bin:/mnt/ramdisk.bin. umount /mnt. On target do 'for i in {1..4096}; do echo -n a > /dev/{path-to-minfs}; done`, the system will crash and reboot shortly after, and should boot into your new ramdisk.<p>At the time there was a bug that'd trigger the final reboot when a mounted but broken partition had its magic header overwritten. A couple of months later I made this way harder to recover from, but we also added an A/B/R partition scheme so that there was essentially always a recovery strategy even if you send really broken software.<p>If you're on a Linux system though, I think some of this gets in some ways easier. There's some ABI junk to deal with, but you can get really far with disgusting behavior in a posix shell that has a tty and signals, as you can write a bunch of not very feature complete, but very functional programs quickly in shell. A quick editor - probably 20 lines or so, and each time you make it better it gets easier to be better. Already got some read/write loop going on in that editor, great, plain text http isn't far off.<p>This is all a bit of an interesting set of trivialities though, not to discount the idea. DNS is a good example as in the article, but if you have no DNS tools you are missing ip(1) and friends, and you need to go implement netlink first - otherwise having a DNS client doesn't matter, you don't have configured network interfaces! If you have ip(1) then you likely also have ss(1) and you can trick the latter into acting as a dns client. If you have to hand roll netlink without headers, a compiler and a linker though, that's not really a from-memory job there, and the netlink part is far worse than the DNS part really. If you're on a systemd system, and all you have is systemd a shell and ip tools, you're basically completely set from the get-go, as you can jump straight to `machinectl pull-tar` and you're off to the races.<p>Of course if you're on an EFI system that hasn't trimmed down much from the reference tianocore build, then you can probably reboot into an efi shell and get network configuration and pull an image from there, which is likely easier than escalating from a zero compiler zero network environment against the linux abi.<p>Fun idea, I'm just not totally sure how to put a good modern bound around "minimal linux system".<p>It feels like a CTF, but kind of in reverse. Following that theme perhaps it should be "escape the pot", modelling the stripped down system as a honeypot.