$ cat writeup.md…
$ cat writeup.md…
d3c2026
Task: Exploit a custom Linux kernel message bus that retains file-backed pages and appends CRC32C trailers. Solution: Invert CRC32C for chosen page-cache writes, patch BusyBox poweroff, and trigger it from root init.
$ cat /etc/rate-limit
Rate limit reached (20 reads/hour per IP). Showing preview only — full content returns at the next hour roll-over.
No separate organizer prose was retained in the solved workspace. The supplied challenge archive contained a Linux kernel, a protected QCOW2 root filesystem, a QEMU launcher, and an image associated with the task.
The goal was to escape a UID 1000 shell, exploit the world-accessible /dev/d3kbus kernel module, and disclose the root-only /flag. This is the d3kbus-revenge challenge, not the earlier d3kbus task: it has its own normalized identity, exploit artifacts, remote transcript, and independently verified result.
The archive contained:
bzImage;run.sh, which starts an x86-64 QEMU guest;media.png, which proved unrelated to the exploit.The launcher enabled the major kernel hardening features:
-cpu kvm64,+smep,+smap -append "console=ttyS0 root=/dev/sda rw rdinit=/sbin/init quiet kaslr pti=on oops=panic panic=1"
The guest initialized /dev/d3kbus, dropped into a shell as ctf, and resumed the root-owned rcS script after that shell exited. The next meaningful action in rcS was BusyBox poweroff. This gave a useful escalation target: alter executable page-cache data while unprivileged, then let an existing root process execute it.
The module was stored as /root/d3kbus.ko inside a filesystem that was inconvenient to mount directly on the host. The reliable extraction method was:
init=/bin/sh;/root/d3kbus.ko to it;The recovered module was 1,249,640 bytes and, crucially, retained symbols and DWARF. That converted a blind kernel attack into protocol and control-flow recovery.
...
$ grep --similar