pwn::musings & syndications

One Flake to Hack Them All

Mon, 14 Sep 2026 00:00:00 GMT

I recently played Cyber Showdown CTF on a pure Nix setup, and it convinced me that Nix is one of the best things to happen to my CTF workflow. It also broke a few binaries in ways that taught me more about how Linux actually loads a program than any blog post ever did.

So this is two things at once. It is a practical guide to running a CTF lab on Nix: how to set it up, the everyday commands, and the advanced moves most people never find. And it is an honest field report of the friction, with real terminal output as proof, because a guide that only shows the happy path is lying to you.

If you have never touched Nix, do not worry. I will explain the mental model before the machinery, and every command has a reason attached.

Before any of the technical detail: my team, TU-2026-Team-08 (team motto, "win win win"), finished first, closing out the event with 20,951 points. Every flag came out of the Nix shell this post is about, so take the rest as proof the setup holds up under real competition pressure and not just on a quiet afternoon.

Why bother? The problem Nix actually solves

Every CTF player knows the ritual. A challenge drops, you clone an exploit, and then:

$ python3 solve.py
ModuleNotFoundError: No module named 'pwn'
$ radare2 chall
zsh: command not found: radare2
$ sudo apt install volatility3
E: Unable to locate package volatility3

Twenty minutes gone before you have looked at a single byte. Worse, your machine slowly becomes a landfill: three Python versions, a dozen Go recon tools on your PATH forever, a pip environment held together with hope. Six months later you reopen an old writeup and the commands no longer reproduce because a tool silently updated under you.

There are three distinct problems hiding in there:

Pollution. You do not want sqlmap, masscan, and forty recon binaries living on your host permanently. You want them while you work and gone afterward.
Irreproducibility. "Works on my machine" is a curse. Tool versions drift, and your old solve scripts rot.
Non-portability. My Linux tower and my MacBook were never set up the same way, so half my muscle memory broke when I switched.

Nix fixes all three at once, and it does so with a single idea.

The one idea behind Nix

Here is the whole mental model, and it is worth internalizing before you copy any config.

Core idea. In Nix, every package is built from a pure description of its inputs and lands in a read-only store path like /nix/store/abc123...-radare2-5.9.0. Nothing installs into /usr/bin. A "shell" or an "environment" is just a set of these store paths stitched onto your PATH temporarily.

Three consequences fall straight out of that, and they map exactly onto the three problems above:

Because packages live in the store and not on your host, an environment is isolated and disposable. It exists while you are in it.
Because a package is a pure function of its inputs, and those inputs are pinned in a lock file, the environment is reproducible. Same inputs, same bytes, next year, on any machine.
Because that same description evaluates per system, one file gives you the same tools on Linux and macOS, x86 and ARM.

That is the entire pitch. Everything below is mechanics.

The setup: one flake, one devshell

A flake is a file, flake.nix, that declares inputs (where packages come from) and outputs (what you want built). For CTF, the output you care about is a devShell: an environment you drop into that has your tools on PATH.

Here is the skeleton I actually use. The one non-obvious trick is forAllSystems, which builds the same shell for every platform so I never maintain a separate Mac config:

{
  description = "Reproducible CTF / bug-hunting lab";

  inputs.nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable";

  outputs = { nixpkgs, ... }:
    let
      systems = [ "x86_64-linux" "aarch64-linux" "x86_64-darwin" "aarch64-darwin" ];
      forAllSystems = f: nixpkgs.lib.genAttrs systems (system:
        f (import nixpkgs {
          inherit system;
          config.allowUnfree = true;   # opt into unfree tools once (Burp, etc.)
        }));
    in {
      devShells = forAllSystems (pkgs: {
        default = pkgs.mkShell {
          packages = with pkgs; [
            # the whole arsenal goes here
          ];
        };
      });
    };
}

Two small decisions in there pay off constantly:

config.allowUnfree = true set once at the import site. Some tools carry unfree licenses, and this saves you from fighting that wall mid event.
The four-entry systems list. Having aarch64-darwin in there is why the exact same shell works on Apple Silicon with zero extra effort.

Now the part that matters more than people admit: group the package list by phase, not alphabetically. When you are mid challenge with adrenaline up, a flat sorted list is useless. A grouped one is a map:

packages = with pkgs; [
  # recon
  subfinder amass assetfinder dnsx httpx katana gau waybackurls gowitness
  # web / fuzzing
  ffuf gobuster feroxbuster dalfox arjun sqlmap
  # network / scanning
  nmap naabu masscan
  # reversing / binary
  file binutils gdb ltrace strace radare2 binwalk upx patchelf gcc qemu
  # forensics
  tshark sqlite
  # source & secret analysis
  semgrep gitleaks trufflehog ripgrep fd jq yq
  # runtimes / glue
  python3 nodejs bun esbuild uv
  unzip zstd age
];

There is a quiet bonus here. When you reopen this repo in a year, the flake documents how you approach a target. The categories are your methodology, written down.

direnv: making it effortless

A flake is nice, but typing nix develop every time you cd is friction, and friction is what kills good habits. Kill it with direnv.

One file, .envrc, with one line:

use flake

The first time you enter the folder, direnv asks permission once:

$ direnv allow

From then on, the shell activates automatically when you enter the directory and deactivates when you leave. Your tools appear on cd in and vanish on cd out. The environment becomes invisible, which is exactly what you want.

Speed tip. Pair it with nix-direnv, which caches the evaluated environment so re-entering a folder is instant instead of re-evaluating the flake each time. On a big toolset this is the difference between "instant" and "annoying."

The Python escape hatch: uv

Here is a hard-won rule: do not try to package fast-moving Python security tools as Nix derivations mid competition. pwntools plugins, Volatility 3, one-off PoCs with weird pinned deps: packaging those the Nix way is more effort than the challenge itself.

The clean split is: Nix for system tools, uv for the Python churn. So uv goes in the flake, and it manages throwaway Python environments that are as disposable as the shell around them.

# run Volatility 3 without installing anything permanent
$ uvx --from volatility3 vol -f memory.raw windows.info

# or a scratch venv for one challenge
$ uv venv && uv pip install pwntools requests

uv is extremely fast and its environments live in the challenge folder, so they disappear when you are done. You get a reproducible base with a flexible top layer. This is literally how I ran Volatility on a memory forensics box during the event without leaving a trace on the host.

Where it got interesting: running foreign binaries

Everything above is the happy path. Now the friction, because this is the part that actually teaches you something.

CTF binaries are, by definition, foreign binaries. And a clean, isolated Nix environment is precisely what makes foreign binaries hard to run. That is not a bug. It is the isolation doing its job. But you need to know the moves.

Gotcha 1: the binary that "does not exist"

First pwn challenge of the event, a textbook ret2win. I built the exploit, went to test locally, and hit this:

$ ./rpz_gate_1
zsh: no such file or directory: ./rpz_gate_1

The file is right there. ls shows it. So what is missing? Ask file:

$ file rpz_gate_1
rpz_gate_1: ELF 64-bit LSB executable, x86-64, dynamically linked,
  interpreter ./glibc/ld-linux-x86-64.so.2, not stripped

There is the answer, in the word interpreter. When you run a dynamically linked ELF, the kernel does not run your binary first. It runs the dynamic loader named in the ELF's interpreter field, and that loader maps your binary and its libraries into memory. The "no such file or directory" error was never about rpz_gate_1. It was about the loader path not existing.

On a normal distro the interpreter is /lib64/ld-linux-x86-64.so.2 and it is always present. On Nix there is no /lib64 at all, because nothing installs to those global paths. This particular challenge was even sneakier: it shipped its own loader at a relative path, ./glibc/ld-linux-x86-64.so.2, so it only resolves if your working directory is the challenge directory.

Three fixes, easiest first. Learn all three because each wins in a different situation.

Fix 1, just cd in. Works when the binary uses a relative loader like this one:

$ cd gate1/        # so ./glibc/ld-linux... resolves relative to here
$ python3 solve/exp.py
You won the race!
Here is your key: HTB{f4k3_fl4g_4_t35t1ng}

Fix 2, patch the interpreter. This is why patchelf is in my flake. You rewrite the binary's interpreter field to point at a loader that actually exists in the Nix store:

# point it at glibc's loader from the store
$ patchelf --set-interpreter \
    "$(nix eval --raw nixpkgs#glibc)/lib/ld-linux-x86-64.so.2" ./somebin

Use this when you need the binary to run from anywhere, not just its own folder.

Fix 3, nix-ld. The set-and-forget option for NixOS. It installs a small stub at the standard /lib64/ld-linux-x86-64.so.2 path that redirects to libraries you declare in your config. Enable it once and most dynamically linked binaries simply run. If you play CTFs regularly on NixOS, this is worth doing. On non-NixOS, the quick equivalent is steam-run ./bin, which drops the binary into an FHS sandbox where the traditional paths exist.

When to reach for which. cd when the binary ships its own loader. patchelf when it must run anywhere. nix-ld or steam-run when you never want to think about this class of problem again.

And the quieter Nix lesson from this challenge: pwntools was not something I wanted to negotiate with nixpkgs about mid event, so it is not in the flake. uv is, and uv pip install pwntools in the challenge folder solved it in seconds. The rule from earlier, proven under fire.

Here is what a solve actually looked like from inside that shell. This reversing challenge shipped a loader that dropped an embedded .so and LD_PRELOADed it into /bin/true, and the .so constructor built the flag with a run of mov byte [rip+x], imm before raising a signal to trip up debuggers. No need to run it: just carve the .so out and scrape the immediate bytes. Editor, notes, and shell, all one direnv allow away.

Gotcha 2: the toolchain that only speaks x86

Later there was a reversing challenge whose binary was ARM64 while I was on x86:

$ file ghost
ghost: ELF 64-bit LSB pie executable, ARM aarch64, dynamically linked, not stripped

Two separate Nix papercuts, back to back.

Papercut A: objdump is single-target. My reflex is objdump -d. But the binutils in your shell is built for your target, so it refuses a different architecture:

$ objdump -d ghost
objdump: can't disassemble for architecture UNKNOWN!

You could pull a cross-binutils into the flake with pkgsCross.aarch64-multiplatform.binutils, but that is a yak-shave in the middle of a competition. The pragmatic move: radare2 is multi-architecture out of the box. It was already in the flake and read the ARM64 without complaint:

$ r2 -A ghost
[0x00000abc]> pdf @ main    # disassembles aarch64, no cross toolchain needed

Rule of thumb. On a Nix devshell, treat objdump and gdb as single-target. For anything cross-architecture, default to radare2 or Ghidra and skip the cross-compilation rabbit hole entirely.

Papercut B: running it needs a sysroot. The challenge gimmick was that the flag gets assembled in memory and written to /dev/null, so running it shows nothing. Three bytes of the flag came from syscall return values, so I actually wanted to run it under emulation and watch. qemu is in the flake:

$ qemu-aarch64 ghost
qemu-aarch64: Could not open '/lib/ld-linux-aarch64.so.1': No such file or directory

Same loader problem as before, now cross-architecture. QEMU needs to find the aarch64 glibc, which lives deep in the Nix store. You hand it the location with -L, and here is the single most useful trick in this whole post for locating it:

$ SYSROOT=$(nix eval --raw nixpkgs#pkgsCross.aarch64-multiplatform.glibc)
$ QEMU_STRACE=1 qemu-aarch64 -L "$SYSROOT" ghost 2>&1 \
    | grep -E 'close|open|read|write'

That nix eval --raw nixpkgs#<package> pattern prints the store path of any package as a plain string, so you can feed it to a tool that knows nothing about Nix. Loaders, sysroots, library headers, whatever a dumb tool needs, Nix already has it built. You just have to point the tool at the path.

And then strace lied to me. I tried to watch the syscalls the normal way, and it went blind the instant the program ran. The reason is genuinely funny: the program calls close(2), which closes standard error, and standard error is exactly where strace writes its own output. By closing its fd, the program silenced its own tracer.

The fix was refreshingly low tech. The kernel returns the same values on any architecture, so I reproduced the same close, open, read, write sequence in a tiny C program and compiled it with the flake's gcc:

$ gcc -o repro solve/repro.c && ./repro
0 0 -1

Those three values decoded to the three mystery bytes and gave up the flag. The recurring lesson across both challenges: when the fancy dynamic tool fights the environment, a static or offline reproduction usually wins. Reading the loader field beat guessing. A C repro beat strace. Boring is fast.

Advanced moves worth knowing

These are the things that took me from "surviving on Nix" to "faster because of Nix."

Grab a tool for one challenge without touching your flake

You do not have to edit flake.nix every time you want something once. Two commands cover it:

# drop a tool onto PATH for this shell only
$ nix shell nixpkgs#ghidra

# or run it once and throw it away
$ nix run nixpkgs#ghidra

Neither installs anything permanently. This is perfect for a heavy tool like Ghidra that you want for exactly one reversing challenge and never again.

Keep separate shells for separate jobs

A quick web box should not have to load QEMU and GDB. Expose more than one devShell and pick per task:

devShells = forAllSystems (pkgs: {
  default = pkgs.mkShell { /* everything */ };
  recon   = pkgs.mkShell { packages = with pkgs; [ subfinder httpx ffuf ]; };
  re      = pkgs.mkShell { packages = with pkgs; [ radare2 gdb qemu patchelf ]; };
});

$ nix develop .#recon      # only the recon tools, loads faster

Pin the world so your writeup reproduces forever

This is the payoff that other approaches cannot match. Your flake has a companion flake.lock that records the exact revision of nixpkgs you used, which pins every tool version transitively.

Commit flake.lock next to your writeup. Then the commands in that writeup are reproducible byte for byte, years later, on hardware you do not own yet. When you want fresh tools, you update deliberately:

$ nix flake update      # bump the lock on your schedule, not the CTF's

Do this when you choose, not the night before a competition. Pinned means pinned.

When a tool truly hates Nix, give it an FHS jail

Some tools assume a traditional Linux filesystem: pip wheels with precompiled native extensions, certain commercial binaries, the odd installer that hardcodes /usr/lib. Rather than patch each one, build a fake standard-filesystem sandbox with buildFHSEnv:

# an FHS shell where /usr, /lib, /lib64 exist like a normal distro
(pkgs.buildFHSEnv {
  name = "ctf-fhs";
  targetPkgs = p: with p; [ python3 gcc glibc zlib ];
}).env

Enter that and stubborn binaries behave as if they are on Ubuntu, while your host stays clean. This is the escape hatch of last resort, and it is good to know it exists before you need it at 2 a.m.

Share one flake with your whole team

For team events this is quietly a superpower. Commit the flake to your team repo, and every teammate who runs nix develop gets the identical toolset at identical versions. No more "it works for me but not for you." The environment stops being a variable in your debugging.

The cheat sheet I wish I had started with

Everything above, compressed into the table I now keep in a browser tab:

Symptom	Real cause	Fix
`./bin: no such file or directory`, but the file exists	ELF interpreter path missing on Nix	`patchelf --set-interpreter ...`, `cd` to a shipped loader, or `nix-ld`
`qemu-...: Could not open '/lib/ld-...'`	Cross-arch loader not found	`qemu-<arch> -L "$(nix eval --raw nixpkgs#pkgsCross.<arch>.glibc)" ./bin`
`objdump: can't disassemble for architecture UNKNOWN!`	nix binutils is single-target	use `radare2` or Ghidra (multi-arch)
`pip install` fights nixpkgs	fast-moving Python packaging	keep `uv` in the flake, `uv pip install ...`
`strace` goes blind after `close(2)`	the program closed strace's own fd	reproduce the syscalls in a tiny C program
Need a tool once	do not want to edit the flake	`nix shell nixpkgs#tool` or `nix run nixpkgs#tool`
A binary assumes a normal filesystem	it hardcodes `/usr`, `/lib64`	wrap it in `buildFHSEnv` or run `steam-run`
Locate glibc, a loader, a sysroot	Nix stores it in `/nix/store`	`nix eval --raw nixpkgs#<pkg>` prints the path

Would I run a CTF on Nix again?

Without hesitation, yes. The detours in this post are a one-time tax you pay while the reflexes wire in: run file first, patch or point the loader, reach for radare2 on anything cross-arch, use uv for Python, and drop to a static reproduction when a live tool fights you. Once those are habits, the payoff is large and permanent.

Every challenge folder becomes reproducible, disposable, and identical across my Linux box and my Mac. My gate1 exploit will still run byte for byte next year because flake.lock pins the entire world it needs. Nothing lands on my host, and the whole toolbox closes behind me when I cd out.

The tools being missing by default felt like friction in the moment. By the end of Cyber Showdown it felt like the entire point.

If you are starting out, you do not need to "learn Nix" first. Copy a flake.nix, add an .envrc with use flake, run direnv allow, and keep this cheat sheet open. That gets you ninety percent of the value on day one. The rabbit hole is deep, but the entrance is a two-line file, and now you know exactly what bites.

And, for the record, we took first. Here is the final team board and the sticker haul to prove we showed up.

Ditching Cloudflared for Tailscale

Mon, 07 Sep 2026 00:00:00 GMT

A while back I wrote about SSHing into my home server from anywhere using a Cloudflare Tunnel. It worked. But the more I lived with it, the more it felt like the wrong tool.

Cloudflared needs a domain. It routes my SSH through Cloudflare's edge. It's a daemon babysitting a config.yml, and every service I want to reach needs its own ingress rule. That's a lot of moving parts, and another company sitting in the middle of me talking to my own machine.

So I ripped it out and moved to Tailscale.

Why it's better for me

Tailscale is a WireGuard mesh. My machines talk to each other directly, peer to peer, over an encrypted tunnel. No domain, no public IP, no open ports, no ingress config. Every box gets a 100.x address and a name, and I can reach any port on it, not just the one I remembered to forward.

And because everything I own is Nix, I don't click around an app. I add a line, rebuild, done.

The Linux box (dom)

dom is my NixOS home server. Enabling Tailscale is one line, plus telling the firewall to trust the tailnet interface so I'm not fighting my own rules.

# machines/dom/services.nix
{
  # tailscale
  services.tailscale.enable = true;

  # firewall — allow ssh + trust the tailnet, block the rest
  networking.firewall = {
    enable = true;
    allowedTCPPorts = [ 22 ];
    trustedInterfaces = [ "tailscale0" ];
  };
}

services.tailscale.enable installs the daemon, starts it at boot, and opens the UDP port it needs to punch through NAT. Rebuild:

sudo nixos-rebuild switch --flake .#dom

The Mac (whiterose)

My MacBook is a nix-darwin machine. nix-darwin has the same option, it just runs the daemon under launchd. I only wanted it on the laptop, not the Mac Mini, so I dropped it straight into that machine's config:

 # machines/whiterose/default.nix
   modules = [
     {
       nixpkgs.config.allowUnfree = true;
     }
+
+    # MacBook-specific: Tailscale client to reach the homelab from anywhere
+    {
+      services.tailscale.enable = true;
+    }

     ./../../modules/darwin.nix

darwin-rebuild switch --flake .#whiterose

Log in

Enabling the service installs everything, but the node still has to join the tailnet. Once per machine:

sudo tailscale up

It prints a login URL, I approve it in the browser, and the box shows up in my tailnet. On macOS I also set myself as operator so I stop needing sudo for everyday commands:

sudo tailscale set --operator=$USER

Now tailscale status lists everything:

100.124.21.97   whiterose   macOS   -
100.109.246.23  dom         linux   active; direct 71.121.175.97:41641

direct is the word I wanted. No relay, ~12ms, straight laptop-to-server.

Point SSH at the tailnet

My ssh dom alias was still hardcoded to the LAN IP, so it only worked at home. The whole point was reaching it from anywhere, so I swapped it for the MagicDNS name. That name resolves on my LAN and from a coffee shop, Tailscale figures out the route.

 # modules/ssh.nix
   "dom" = {
     User = "pwn";
-    Hostname = "192.168.1.213";
+    # Tailscale MagicDNS name — reachable on LAN and from anywhere.
+    Hostname = "dom";
   };

After a rebuild, this just works, from my bed or from another country:

ssh dom

No ssh.pwnwriter.me. No tunnel daemon. No DNS records to manage.

I don't want it running 24/7

Here's the part I actually care about. I don't want a VPN glued on all day. I want it up when I need the homelab and gone when I don't.

Turns out you don't fight the daemon for this:

tailscale down    # off — disconnects from the tailnet
tailscale up      # on  — back in

tailscale down sets WantRunning=false, and that sticks across reboots. Turn it off once and it stays off until I explicitly bring it up. The daemon is still there, but parked, doing nothing.

Battery? I worried about this and it's basically a non-issue. Connected and idle, it's a small keepalive every ~25s and one long-poll to a relay, nothing you'd feel on a day's charge. After tailscale down it's effectively zero. The only thing that actually costs you is using a box as an exit node, so don't, unless you mean to.

SSH bits worth stealing

Two lines in my Host * block that make daily SSH nicer over the tunnel:

# modules/ssh.nix, the "*" block
ServerAliveInterval = 30;     # don't let idle sessions die on NAT
ControlMaster = "auto";       # reuse one connection
ControlPersist = "10m";       # 2nd+ ssh/scp/rsync are instant

Multiplexing means the second ssh dom rides the first tunnel, no re-auth, near-instant. And the stuff I run constantly:

ssh dom 'docker ps'              # one-off command, no shell
rsync -avP ~/dir/ dom:~/dir/     # resumable folder sync
ssh -L 8080:localhost:80 dom     # reach dom's :80 at localhost:8080

That's it

Cloudflared was a tunnel to one port behind a domain behind a company. Tailscale is my machines talking to each other, off when I say so, and it's four lines of Nix across two hosts.

The old post stays up for history. This is what I run now.

How Nix Actually Works

Sun, 02 Aug 2026 00:00:00 GMT

Most people meet Nix as a package manager, get scared by the syntax, and leave. That's a shame, because the whole thing is built on about three ideas. Once they click, the weird /nix/store/ paths, the reproducibility, the rollbacks, all of it stops being magic.

No fluff. Let's look at what Nix is actually doing under the hood.

1. The language is just a calculator for attribute sets

Before any packaging, Nix is a small, lazy, purely functional language. No statements, no loops, no mutation. Every expression evaluates to a value. Open a repl and poke it:

$ nix repl
nix-repl> 1 + 2
3

nix-repl> "pwn" + "writer"
"pwnwriter"

nix-repl> { name = "nix"; year = 2003; }
{ name = "nix"; year = 2003; }

nix-repl> let x = 10; in x * x
100

Functions are arg: body. That colon is the whole syntax.

nix-repl> square = x: x * x
nix-repl> square 12
144

nix-repl> greet = name: "hello ${name}"
nix-repl> greet "world"
"hello world"

Everything you write in Nix is one big expression that evaluates to an attribute set. Your whole NixOS config? One attribute set. A package? One attribute set. That's the trick to reading any .nix file: find the set, follow the attributes.

Fun fact: Nix is lazy. Nothing is evaluated until it's needed. You can define an infinite value and Nix won't blink until you touch it:

nix-repl> rec { a = b; b = 1; }.a   # b defined after a, still fine
1

2. Everything is a derivation

A derivation is Nix's word for "a recipe to build one thing." A package, a config file, a whole OS, all derivations. It's a pure function:

derivation = f(inputs) -> output in the store

Same inputs always produce the same output path. Here's the most minimal derivation that exists, no nixpkgs, no helpers:

nix-repl> d = derivation {
            name = "hello";
            builder = "/bin/sh";
            args = [ "-c" "echo hi > $out" ];
            system = "x86_64-linux";
          }

nix-repl> d
«derivation /nix/store/xd6r...-hello.drv»

Notice it's a .drv file, not the result yet. A .drv is the build plan, frozen JSON-ish that lists every input, the builder, and the env. Nix builds the plan, not your live shell. You can read one raw:

$ nix derivation show nixpkgs#hello | head -20
{
  "/nix/store/...-hello-2.12.1.drv": {
    "outputs": { "out": { "path": "/nix/store/...-hello-2.12.1" } },
    "inputDrvs": { ... },
    "env": { "pname": "hello", "version": "2.12.1", ... }
  }
}

When people say "Nix builds a graph," this is the graph: .drv files pointing at other .drv files, all the way down to bootstrap.

3. Why the store paths look like that

Every build lands in /nix/store/ under a name like:

/nix/store/1q2w3e4r5t...-hello-2.12.1
           └──────┬──────┘ └────┬────┘
              the hash        the name

That prefix is a hash of every input that went into the build: the source, the compiler, the build flags, the dependencies' hashes, recursively. Change one flag, get a different hash, get a different path.

This is the entire foundation. It buys you three things for free:

No dependency hell. Two apps needing different OpenSSL versions get two different store paths. They coexist. There is no "global" version of anything.
Atomic upgrades. The new build goes to a new path. Nothing is overwritten. Switching is just repointing a symlink.
Caching that can't lie. If the hash matches, the binary is byte-identical to what that recipe produces. So Nix can download a prebuilt result from a cache instead of building, and know it's correct.

Check what a path actually depends on. path-info only queries paths that are already built, so realise it first:

$ nix build nixpkgs#hello --no-link      # pull it into the store
$ nix path-info -rsh nixpkgs#hello        # -r recursive, -s size, -h human
/nix/store/wl60...-libiconv-115.100.1     43.7 MiB
/nix/store/b63h...-hello-2.12.3          110.4 KiB

That list is the closure: everything needed to run hello, nothing global, nothing implicit. The exact deps differ by platform: this is macOS, so hello leans on libiconv; on Linux you'd see glibc and friends instead. Either way, it's the whole runtime, spelled out.

Wait, how does it know the deps?

Here's the part nobody tells you: Nix does not parse your code to find runtime dependencies. After a build, it scans the raw output bytes for store-path hashes. If a 32-character store hash shows up anywhere in the result, that path is a dependency. That's the entire algorithm.

Don't believe me? The hello binary literally has the libiconv path baked into it:

$ strings result/bin/hello | grep /nix/store
/nix/store/wl60...-libiconv-115.100.1/lib/libiconv.2.dylib

$ nix-store -q --references $(nix path-info nixpkgs#hello)
/nix/store/wl60...-libiconv-115.100.1        # ← same path, now a registered dep

Nix found libiconv because the string was in the file. This has real consequences: strip a binary and its closure can shrink; leave a compiler's path in a debug comment and you've accidentally added GCC to your runtime closure. Dependencies aren't declared, they're discovered.

Where do prebuilt results come from? Since the hash pins the exact recipe, Nix can ask a binary cache (cache.nixos.org by default, or your own via cachix) "got a build for this hash?" before building. If yes, it downloads the closure instead of compiling. A cache can't feed you the wrong thing, because the only question is whether the hash matches. That's what "caching that can't lie" actually means in practice.

4. Purity is enforced, not requested

Here's the part that makes reproducibility real instead of aspirational: Nix builds in a sandbox. No network. No /usr/bin. No $HOME. No system time that matters. If your build secretly curls something or reads a file from the host, it fails, on purpose.

That's why a Nix build on my Mac and on a CI runner in Frankfurt produce the same store hash. The build literally cannot see anything that isn't a declared input.

Want network access? You have to declare the hash of what you're downloading up front, so the result is still deterministic:

fetchurl {
  url = "https://ftp.gnu.org/gnu/hello/hello-2.12.1.tar.gz";
  hash = "sha256-jZkUKv2SV28wsM18tCqNxoCZmLxdYH2Idh9RLibH2yA=";
  # ↑ if the download doesn't match this, the build fails
}

No hash, no network. The impurity is boxed in and pinned.

5. Reading the graph

Once you internalize "it's all a dependency graph," Nix ships tools to interrogate it. This is genuinely useful for debugging bloat.

Why is this thing even here? (--precise shows the exact file that references it, pin perl.out since Perl has multiple outputs.)

$ nix why-depends --precise nixpkgs#git nixpkgs#perl.out
/nix/store/...-git-2.54.0
└───bin/git-cvsserver: #!/nix/store/...-perl-5.42.0/bin/perl  use lib (…
    → /nix/store/...-perl-5.42.0

Git pulls in Perl because scripts like git-cvsserver have a Perl shebang. You didn't have to guess. The graph told you which file did it.

How big is the whole closure?

$ nix path-info --closure-size -h nixpkgs#git
/nix/store/...-git-2.54.0   1.5 GiB

Yes, 1.5 GiB. Git's full closure drags in Perl, Python, and their deps. The graph doesn't let anything hide.

What changed between two builds?

$ nix store diff-closures /run/current-system ./result
python3: 3.11.9 → 3.12.4, +2.1 MiB
openssl: 3.0.14 → 3.0.15

6. Generations: time travel that always works

Every time you rebuild, Nix keeps the old one. Your system profile is just a symlink to the current generation, and the old generations are still sitting in the store untouched.

$ nix-env --list-generations --profile /nix/var/nix/profiles/system
  42   2026-07-28 09:14:02
  43   2026-07-30 21:03:55
  44   2026-08-02 11:20:10   (current)

Broke your system on generation 44? Reboot, pick 43 from the boot menu, you're back. Nothing was destroyed, because Nix never overwrites; it only ever adds a new path and moves a symlink. Rollback is nixos-rebuild switch --rollback, and it's instant because the old closure never left.

The store is append-only. That single design choice is why rollbacks can't fail.

Bending packages without forking

# add a patch and a build flag to upstream `hello`, in place
hello.overrideAttrs (old: {
  pname = "hello-patched";
  patches = (old.patches or [ ]) ++ [ ./fix.patch ];
  configureFlags = (old.configureFlags or [ ]) ++ [ "--enable-silent-rules" ];
})

And because you changed an input, the hash changes, so you get a different store path. The original stays untouched:

$ nix eval --raw --expr \
    '(import <nixpkgs> {}).hello.overrideAttrs (o: { pname = "hello-patched"; }).name'
hello-patched-2.12.3

Scale that up with an overlay and you can rewrite any package in nixpkgs for your whole system, from one file. That's the "why I keep coming back to Nix" feeling: the entire ecosystem is a value you're allowed to edit.

When a build breaks

Nix build errors scare people off, but the debugging tools are right there:

# see the full build log of anything (only for locally-built paths,
# not ones downloaded from a cache)
$ nix log nixpkgs#somepkg

# keep the failed build sandbox around so you can poke at it
$ nix build nixpkgs#somepkg --keep-failed

# drop into the exact environment the build runs in, then run the
# phases by hand: unpackPhase, configurePhase, buildPhase, ...
$ nix develop nixpkgs#somepkg

For a build that dies deep in a phase, add breakpointHook to the derivation and Nix pauses inside the sandbox at the failure so you can look around. Beats staring at a wall of C errors.

Where flakes fit

You've seen flake.nix in every other post here without me ever saying what it is. A flake is just this whole model with a clean boundary drawn around it: a flake.nix with typed inputs (its dependencies, pinned) and outputs (packages, dev shells, NixOS configs), plus a flake.lock that nails every input to an exact commit hash. Same derivations, same store, same graph, now reproducible down to the git rev and evaluated purely by default. That's why nix run nixpkgs#hello and .#wolf from my VPS post work the way they do.

Tricks I actually use

Run anything without installing it. The store makes this cheap; it downloads the closure, runs it, and garbage-collects it later.

$ nix run nixpkgs#cowsay -- "no install, no trace"
$ nix run nixpkgs#nmap -- -sV scanme.nmap.org

Drop into a shell with tools, just for now:

$ nix shell nixpkgs#{ripgrep,fd,jq}
# rg, fd, jq available; exit the shell and they're gone from PATH

"I typed a command that isn't installed." comma runs it straight from nixpkgs by finding which package ships that binary:

$ , htop        # not installed? comma fetches and runs it anyway

Find which package provides a file:

$ nix-locate bin/ffmpeg
ffmpeg-full.out   ...   bin/ffmpeg
ffmpeg.out        ...   bin/ffmpeg

Pin nixpkgs to an exact commit so a project builds the same in two years:

$ nix run github:nixos/nixpkgs/a1b2c3d4#hello

Explore nixpkgs like a data structure, because that's all it is:

$ nix repl -f '<nixpkgs>'
nix-repl> lib.version
"26.11pre-git"
nix-repl> hello.meta.description
"A program that produces a familiar, friendly greeting"
nix-repl> builtins.length (builtins.attrNames pkgs)   # top-level attrs
27648

A few fun facts to leave with

The hash comes before the build. Nix knows a package's store path before it compiles anything, because the path is derived from inputs, not output. That's how it checks the cache first and skips the build entirely.
nixpkgs is one giant function. The entire package set is a single Nix expression that evaluates to an attribute set, with tens of thousands of top-level entries, many of them nested sets with thousands more. import <nixpkgs> {} calls it.
Reproducible enough to prove it. Projects rebuild NixOS twice on different machines and diff the hashes bit-for-bit. r13y.com tracks how many packages are 100% reproducible.
/nix/store is world-readable and that's fine. The hash is the identity, so there's nothing to hide and nothing to collide. Same reason I can keep my whole config public.
Deleting is safe. nix-collect-garbage -d only removes store paths that nothing (no generation, no profile, no shell) points at. The graph decides what's garbage, not you.

That's the mental model. Language → derivation → hashed store → sandbox. Every fancy Nix feature is just those four ideas wearing a different hat. Once you see the graph, you can't unsee it.

life: summer of scholarships, black hat, and devday

Mon, 27 Jul 2026 00:00:00 GMT

This summer break turned out unreal.

I got a scholarship from NYC DevRel, then another one for Black Hat in Las Vegas, and now I’m also going to OpenAI DevDay through a scholarship.

A few months ago, these rooms felt very far away. Now I’m packing for places I used to only read about online.

Grateful, nervous, excited.

Mostly just trying to take it all in.

a very weird season of saying yes and then figuring it out.

life: turned 22

Sun, 12 Jul 2026 00:00:00 GMT

yerp, turned 22 today.

the cake was mango flavored and genuinely so smooth. after cake and gifts we went out for dinner, came home, slept.

perfect day honestly.

since last year:

won best elevenlabs project at a hackathon
shipped eipi.boo and tes.chat, and the feedback has been really good
started learning how llms actually work under the hood
got a scholarship to a devrel conference in new york
got a scholarship to black hat in las vegas (thanks blackhat <3)

22 started soft. i’ll take it.

i guess that's it for the night. see y'all in the next one.

eipi.boo: confessions over ssh

Sun, 21 Jun 2026 00:00:00 GMT

Made an anonymous confession board that lives inside your terminal.

No account, no browser, just ssh and a little chaos.

Go ahead and post your confession.

`$ ssh eipi.boo`

Remote browsers and tab pooling in haylxon

Tue, 09 Jun 2026 00:00:00 GMT

I've been working on haylxon for a while now. It takes screenshots of URLs from the terminal using Chrome's headless mode, talking to Chrome over CDP (Chrome DevTools Protocol). I even gave a talk about it at PTN 11. It was already pretty fast. But I kept noticing things that bugged me about how it worked under the hood.

what was bothering me

Every time you ran hxn, it would spin up an entirely new Chromium process. Boot it. Wait for it. Connect via CDP. Do the work. Kill it. That browser startup alone eats 300-500ms. If you're screenshotting a handful of URLs, most of your time is just... waiting for Chrome to exist.

The other thing, for every single URL, haylxon would open a fresh tab, navigate to the page, take the screenshot, close the tab. Open, close, open, close. Each of those is a CDP round-trip. Felt wasteful. Why not just reuse the tab?

And then there was the bigger question I'd been sitting on for a while: why does haylxon need to launch Chrome at all? What if Chrome is already running somewhere, on a server, on another laptop, in a container? CDP is a network protocol. It works over WebSockets. There's no reason the browser has to be on the same machine.

digging into chromiumoxide

I started looking at what chromiumoxide (the Rust CDP library haylxon uses) actually supports. Turns out it has two ways to get a Browser:

// what haylxon was doing, launch a new process
let (browser, handler) = Browser::launch(config).await?;

// what I didn't know existed, connect to an existing one
let (browser, handler) = Browser::connect(url).await?;

The interesting part: both return the exact same Browser type. Same API. Same everything. The pages you create, the screenshots you take, the JavaScript you evaluate, all identical regardless of how you got the browser. The only difference is whether Chrome was already running or not.

Even better, Browser::connect() is smart about what you pass it. Give it a WebSocket URL like ws://host:9222/devtools/browser/<uuid> and it connects directly. Give it an HTTP URL like http://host:9222 and it hits /json/version to discover the WebSocket endpoint automatically. That's the same endpoint you'd hit with curl:

{
  "Browser": "Chrome/148.0.7778.0",
  "webSocketDebuggerUrl": "ws://127.0.0.1:9222/devtools/browser/68dbbb49-..."
}

So the abstraction I needed was thin. Really thin. Not a trait over every CDP operation, just a trait over how you get the browser in the first place:

#[async_trait]
pub trait BrowserProvider: Send + Sync {
    async fn connect(&self) -> miette::Result<Arc<Browser>>;
}

LocalBrowser wraps the existing launch logic. RemoteBrowser calls Browser::connect(). Done.

how LocalBrowser works

Before this change, the browser launch code lived directly in the main execution function, a big block of BrowserConfig::builder() calls mixed with CLI argument handling. I pulled it into its own struct:

pub struct LocalBrowser {
    config: BrowserConfig,
}

impl LocalBrowser {
    pub fn new(
        binary_path: &str,
        width: u32,
        height: u32,
        user_agent: Option<&str>,
        proxy: Option<&str>,
    ) -> miette::Result<Self> {
        let mut builder = BrowserConfig::builder();
        builder = builder
            .no_sandbox()
            .arg("--disable-dev-shm-usage")
            .arg("--disable-gpu")
            .window_size(width, height)
            .chrome_executable(binary_path)
            .viewport(Viewport {
                width, height,
                device_scale_factor: None,
                emulating_mobile: false,
                is_landscape: false,
                has_touch: false,
            });

        if let Some(ua) = user_agent {
            builder = builder.arg(format!("--user-agent={ua}"));
        }
        if let Some(proxy_url) = proxy {
            builder = builder.arg(format!("--proxy-server={proxy_url}"));
        }

        let config = builder.build().map_err(|e| miette::miette!(e))?;
        Ok(Self { config })
    }
}

The BrowserProvider impl just calls Browser::launch() with that config and spawns the CDP event handler:

#[async_trait]
impl BrowserProvider for LocalBrowser {
    async fn connect(&self) -> miette::Result<Arc<Browser>> {
        let (browser, mut handler) = Browser::launch(self.config.clone())
            .await.into_diagnostic()?;
        tokio::task::spawn(async move {
            while handler.next().await.is_some() {}
        });
        Ok(Arc::new(browser))
    }
}

That handler loop is important, chromiumoxide uses it to process CDP events from Chrome. Without it, nothing works. The old code had this exact same spawn, just inlined in exec.rs. Now it lives where it belongs.

how RemoteBrowser works

This is the part I was most excited about. The entire remote browser implementation:

pub struct RemoteBrowser {
    url: String,
}

impl RemoteBrowser {
    pub fn from_ws_url(url: String) -> Self {
        Self { url }
    }

    pub fn from_host(host: String) -> Self {
        Self { url: format!("http://{host}") }
    }
}

#[async_trait]
impl BrowserProvider for RemoteBrowser {
    async fn connect(&self) -> miette::Result<Arc<Browser>> {
        let (browser, mut handler) = Browser::connect(&self.url)
            .await
            .into_diagnostic()
            .map_err(|e| miette::miette!(
                "Failed to connect to remote browser at {}: {e}", self.url
            ))?;
        tokio::task::spawn(async move {
            while handler.next().await.is_some() {}
        });
        Ok(Arc::new(browser))
    }
}

That's it. The from_host constructor just prepends http://, chromiumoxide handles the /json/version discovery internally. No extra HTTP client code. No JSON parsing. The library already does all of that.

The orchestration code in exec.rs picks the right provider based on CLI flags:

let provider: Box<dyn BrowserProvider> = if let Some(ws_url) = remote_url {
    Box::new(RemoteBrowser::from_ws_url(ws_url))
} else if let Some(host) = remote_host {
    Box::new(RemoteBrowser::from_host(host))
} else {
    Box::new(LocalBrowser::new(&binary_path, width, height, ...)?)
};

let browser = provider.connect().await?;

After this point, the rest of the code doesn't know or care whether Chrome is local or remote. Same browser.new_page(), same page.goto(), same page.save_screenshot().

tab pooling, the details

The tab reuse was even simpler conceptually. I already had a Semaphore controlling how many tabs run in parallel:

let semaphore = Arc::new(Semaphore::new(tabs));

for url in urls {
    let permit = semaphore.clone().acquire_owned().await?;
    tokio::spawn(async move {
        take_screenshot(...).await;
        drop(permit); // release the slot
    });
}

This gates concurrency, if tabs is 8, only 8 screenshots run at once. But every one of those screenshots was creating a fresh page and destroying it. The pool sits behind that gate:

pub struct PagePool {
    browser: Arc<Browser>,
    pages: Mutex<Vec<Page>>,
    max_size: usize,
}

impl PagePool {
    pub async fn acquire(&self) -> miette::Result<Page> {
        let mut pages = self.pages.lock().await;
        if let Some(page) = pages.pop() {
            drop(pages);
            let _ = page.goto("about:blank").await;
            Ok(page)
        } else {
            drop(pages);
            self.browser.new_page("about:blank").await.into_diagnostic()
        }
    }

    pub async fn release(&self, page: Page) {
        let mut pages = self.pages.lock().await;
        if pages.len() < self.max_size {
            pages.push(page);
        } else {
            drop(pages);
            let _ = page.close().await;
        }
    }
}

The lock is held only for the push/pop, microseconds. The actual page navigation and screenshot happen outside the lock. No contention in practice.

The about:blank navigation on acquire is the cheapest way to reset a page. No cookies from the previous URL leak through. No leftover DOM. Clean slate. I thought about calling page.close() and creating a new one every time, but that defeats the whole point, new_page is a CDP command that allocates renderer resources. Reusing the existing page and just navigating away is way cheaper.

The screenshot function now does this instead of the old create/close dance:

// acquire page from pool (or create new)
let page = if let Some(pool) = page_pool {
    pool.acquire().await?
} else {
    browser.new_page("about:blank").await.into_diagnostic()?
};

// ... set user agent, navigate, screenshot ...

// release back to pool (or close)
if let Some(pool) = page_pool {
    pool.release(page).await;
} else {
    page.close().await.into_diagnostic()?;
}

The Option<&PagePool> keeps it backwards compatible, pass --reuse-tabs false and there's no pool, falls back to the old behavior.

wiring it up

The CLI got three new flags:

# connect to a remote browser, just give it host:port
hxn --remote-host 192.168.1.42:9222 -f urls.txt

# or a direct WebSocket URL if you already have it
hxn --remote-url ws://192.168.1.42:9222/devtools/browser/<uuid> -u https://example.com

# tab pool size (default 8, enabled by default)
hxn -b $(which brave) -f urls.txt --pool-size 16

The --remote-host flag is the one I use most. You start Chrome headless somewhere:

chromium --headless --remote-debugging-port=9222 --no-sandbox

And point haylxon at it. No UUIDs to copy. The tool discovers the WebSocket URL itself.

One gotcha I ran into while testing this: Chrome often ignores --remote-debugging-address=0.0.0.0 and only binds to localhost even when you tell it not to. Spent way too long debugging that. Ended up using socat to expose the port:

socat TCP-LISTEN:9223,fork,reuseaddr,bind=0.0.0.0 TCP:127.0.0.1:9222 &

Not ideal, but it works reliably. Chrome's fault, not ours.

how fast is it now

I set up a hyperfine benchmark on GitHub Actions comparing haylxon against gowitness:

Benchmark	hxn	gowitness
Single URL	360ms	3.99s	11x faster
5 URLs, 4 tabs	1.81s	26.29s	14x faster
5 URLs, 8 tabs	1.70s	14.67s	8x faster

The single URL case is the one that got me. 360ms. That includes launching Chrome, connecting, navigating, rendering the page, capturing the screenshot, and writing it to disk. On a CI runner. That's not a lot of time.

With a remote browser that's already running, you skip the launch entirely. The first screenshot comes back even faster because there's no boot cost to amortize.

what I kept simple

I didn't add connection retry logic. I didn't add health checks or reconnection pools or a configuration file for remote browser settings. I didn't build a browser manager that keeps Chrome alive between runs.

All of that might make sense someday. But right now, the tool is fast, the code is small, and there's nothing in it that doesn't need to be there. That feels right.

Sometimes the fastest path is just removing the things that were slow.

Secrets in Nix, Publicly

Wed, 06 May 2026 00:00:00 GMT

I keep my entire Nix config in a public repo. Dotfiles, packages, shell setup, everything. But I also need my SSH and GPG keys on every machine I use. Storing private keys in a public repo is obviously a terrible idea. So how do you manage secrets in Nix without going private?

The answer is agenix.

How it works

agenix uses age encryption. You encrypt secrets with your SSH public key, and only someone with the matching private key can decrypt them. The encrypted .age files live in your repo. On rebuild, agenix decrypts them automatically.

nix
├── secrets/                     ~/.local/share/ssh/
│   ├── ssh-key.age  ───────────►  id_rsa (decrypted on rebuild)
│   └── gpg-key.age              id_ed25519 (decryption key)
├── secrets.nix
└── modules/agenix.nix

Anyone can clone the repo. Only I can use it.

Setting it up

I generated a dedicated ed25519 key for agenix. My existing RSA key stays untouched for GitHub, servers, and everything else.

ssh-keygen -t ed25519 -C "agenix@pwnwriter" -f ~/.local/share/ssh/id_ed25519 -N "" # FIXME: change comment and path

Add agenix to the flake

 inputs = {
   nixpkgs.url = "github:nixos/nixpkgs/nixpkgs-unstable";
   home-manager = { ... };
   darwin = { ... };
   catppuccin.url = "github:catppuccin/nix";
+
+  agenix = {
+    url = "github:ryantm/agenix";
+    inputs.nixpkgs.follows = "nixpkgs";
+  };
 };

Define who can decrypt what

A secrets.nix file at the repo root maps public keys to secret files.

let
  pwnwriter = "ssh-ed25519 AAAA... agenix@pwnwriter"; # FIXME: your ed25519 public key
in
{
  "secrets/ssh-key.age".publicKeys = [ pwnwriter ]; # FIXME: your secret files
  "secrets/gpg-key.age".publicKeys = [ pwnwriter ];
}

This is just a list of public keys. Safe to commit. It tells agenix which keys are allowed to encrypt and decrypt each secret.

Encrypt the secrets

nix run github:ryantm/agenix -- -e secrets/ssh-key.age
nix run github:ryantm/agenix -- -e secrets/gpg-key.age

This opens your editor. Paste the secret, save, done. The output is an encrypted .age file that only your ed25519 key can unlock.

Wire it into home-manager

I created a module that tells agenix where the decryption key lives and where to place the decrypted secrets.

# modules/agenix.nix
{ config, ... }:
{
  age = {
    identityPaths = [
      "${config.xdg.dataHome}/ssh/id_ed25519" # FIXME: path to your ed25519 key
    ];

    secrets = {
      ssh-key = {
        file = ../secrets/ssh-key.age;
        path = "${config.xdg.dataHome}/ssh/id_rsa"; # FIXME: where to place decrypted key
      };
      gpg-key = {
        file = ../secrets/gpg-key.age;
      };
    };
  };
}

Then each machine needs the agenix home-manager module. Here's the diff for one of my darwin machines:

 # machines/earlymoon.nix
 let
   inherit (inputs)
     darwin
     home-manager
     catppuccin
+    agenix
     ;
 in
 darwin.lib.darwinSystem {
   modules = [
     home-manager.darwinModules.home-manager
     {
       home-manager.users.pwnwriter = { # FIXME: your username
         imports = [
           ./../modules
           catppuccin.homeModules.catppuccin
+          agenix.homeManagerModules.default
         ];
       };
     }
   ];
 }

Same pattern for every machine. My standalone home-manager config on Linux gets the same one-liner.

Rebuild

darwin-rebuild switch --flake .#earlymoon # FIXME: your machine name

That's it. agenix reads the ed25519 private key, decrypts the .age files, and drops them where the module says. My SSH key appears at ~/.local/share/ssh/id_rsa, ready to use.

Five touchpoints total. No external services, no key servers, no runtime daemons. Just age encryption and a rebuild.

NOW,

Adding a new secret later

# encrypt
nix run github:ryantm/agenix -- -e secrets/new-secret.age

# add to secrets.nix
"secrets/new-secret.age".publicKeys = [ pwnwriter ];

# add to modules/agenix.nix
age.secrets.new-secret.file = ../secrets/new-secret.age;

To edit an existing secret, same encrypt command. It decrypts to your editor, you change it, and it re-encrypts on save.

Hacking 10$ Nexus Phone Into a Hacking Machine

Fri, 17 Apr 2026 00:00:00 GMT

I saw Nexus 6P on Facebook Marketplace for $10. Owner forgot the PIN, just wanted it gone.

I already know Kali NetHunter support this phone officially. So I bought immediately without a second thought.

Literaly drove 25 miles after college to pick it up. First I spent a couple hours researching how to get in without the PIN. Wanted to do it properly and then i found CVE-2016-8467. Tried it. It worked. Here's the full story on how come.

The Phone

Nexus 6P : Inside name angler. Made by Huawei, Google flagship from 2015.

$ fastboot getvar version-bootloader
version-bootloader: 03.61

Bootloader 03.61. This one is weak. Safe version is 03.64 and above. When I see this number I actually pump my fist lol.

CVE-2016-8467

It's a High risk cve and was already fixed in January 2017, but the phone wasn't even updated since then. A big plus point for me ;P So, to summarize this,

CVE	`CVE-2016-8467`
Type	`Boot mode bypass`
Risk	`High`
Affected	`Nexus 6P bootloader < 03.64`
Need	`Physical access only, no PIN`

So basically: this phone has hidden boot modes that Huawei put inside for factory testing. One of them called bp-tools. When you turn it on, phone open ADB connection even if you already disable developer mode, because the system enable it from boot level, not from the settings toggle.

The bug is Huawei forget to block this option when phone is locked. Anyone can just select it. No password, nothing.

Why PIN not important here

  PIN / Lock Screen  →  protect Android only
  CVE-2016-8467      →  go in before Android even start

  We didn't pick the lock. We went through the basement.

The Exploit

Need: phone, USB cable, laptop with fastboot. That's all.

Hold Volume Down + Power to enter fastboot mode. On weak phone you see this menu:

  START
  RESTART BOOTLOADER
  RECOVERY MODE
  POWER OFF
  BP-TOOLS          ← this one
  FACTORY

Press volume to go down to BP-Tools. Press Power.

That's it. One button. No command, no tool, no password. I'm serious.

Phone save this setting inside, so every reboot also still have it. Lock screen look totally normal. Owner don't know anything.

$ fastboot devices
84B5T15B08000140    fastboot

Full access on a locked phone. Can flash anything.

Unlock and Flash

$ fastboot oem unlock
(bootloader) Bootloader unlocked.
OKAY

Then flash TWRP recovery:

$ fastboot boot twrp-3.7.0-angler.img   # test before flash
$ fastboot flash recovery twrp-3.7.0-angler.img

Here I made mistake ,i flashed custom ROM but forget to wipe cache. Phone go bootloop straight away. Had to reflash stock and start again. So painful.

Always wipe Dalvik and cache before flash new ROM.

Wipe → Advanced Wipe: ☑ Dalvik  ☑ System  ☑ Cache  ☑ Data

$ adb shell
angler:/ $ chroot /data/local/nhsystem/kali-arm64 /bin/bash
┌──(root㉿kali)-[/]
└─# whoami
root

Full Kali Linux. On a phone. For $10. Cannot believe.

What It Can Do

WiFi monitor mode work on built-in WiFi, can run full aircrack-ng, no need extra hardware. Can also do USB attack where target computer think phone is a keyboard, i always wanted to try this and it did work, i might write an another blog for the same if i get a chance from these college assignments..

I guess that's it for this. See ya :/

Aditional resources

CVE-2016-8467 original research — alephsecurity.com/2017/01/05/attacking-android-custom-bootmodes
Bypassing Nexus 6 Secure Boot.. - Bypassing Nexus 6 Secure Boot through....
IBM X-Force full paper — docdroid.net/dxKUj5c/attacking-nexus-6-6p-custom-bootmodes.pdf
January 2017 Android Security Bulletin — source.android.com/security/bulletin/2017-01-01
NetHunter downloads — kali.org/get-kali/#kali-mobile
TWRP for angler — twrp.me/huawei/huaweinexus6p.html

hackathon: won best elevenlabs at morganhacks

Wed, 15 Apr 2026 00:00:00 GMT

Hacked for two days straight at MorganHacks and somehow walked away with Best ElevenLabs.

Our project was inventoryAi. The demo was stressful, the sleep was fake, and the team still pulled it off.

tired, happy, proud.

nvim: per project configuration

Thu, 02 Apr 2026 00:00:00 GMT

I finally flipped my config to Neovim 0.12.

This release makes project-local config and package management feel much closer to Neovim itself instead of another layer glued on top.

The part that got me interested: the built-in package manager.

Leaving `lazy.nvim` Behind

I was using lazy.nvim with a .lazy.lua setup. It worked fine, so this was not some dramatic migration. But with more things moving into Neovim itself, I wanted to see how far the native path could go.

So I moved this part away from lazy.nvim and tried the built-in approach.

Here’s what my .nvim.lua looks like now:

vim.pack.add({
  { src = "https://github.com/neovim/nvim-lspconfig", name = "lspconfig" }
})

vim.lsp.enable({
  "ts_ls", -- typescript
  "astro", -- astro
  "tailwindcss", -- tailwindcss
  "tinymist", -- typst
  "harper_ls", -- markdown
  "ty", -- python
})

return {}

What This Does

Installs nvim-lspconfig using the built-in package manager
Enables a set of LSP servers using defaults from upstream lspconfig

That’s it. Less config, fewer moving parts.

SSH Home Server Anywhere

Thu, 05 Mar 2026 00:00:00 GMT

I recently got a ThinkPad and decided to turn it into a small home server. I plan to use it for heavier tasks like running Hack The Box machines, practicing for Red Hat, and other lab work. Since it stays at home, I wanted a simple way to SSH into it from anywhere.

The usual way is to port-forward port 22, but that exposes your server directly to the internet. I didn’t want that.

Instead, I used Cloudflare Tunnel.

With a tunnel, my server creates a secure outbound connection to Cloudflare’s network, and I reach it through my domain. No open ports, no public IP, and it works even behind NAT.

Create the tunnel

After installing cloudflared, I logged in and created a tunnel:

cloudflared tunnel login
cloudflared tunnel create pwnlab

Cloudflare generates a credential file inside ~/.cloudflared/.

Configure the tunnel

Then I created a small config file:

~/.cloudflared/config.yml

tunnel: pwnlab
credentials-file: /home/pwn/.cloudflared/<tunnel-id>.json

ingress:
  - hostname: ssh.pwnwriter.me
    service: ssh://localhost:22
  - service: http_status:404

This tells the tunnel to send traffic from ssh.pwnwriter.me to my local SSH server.

Add the DNS route

Next I mapped the subdomain to the tunnel:

cloudflared tunnel route dns pwnlab ssh.pwnwriter.me

Cloudflare automatically creates the DNS record.

Run the tunnel

cloudflared tunnel run pwnlab

Now my server stays connected to Cloudflare through a secure tunnel.

SSH from anywhere

From any machine I can now simply run:

ssh pwn@ssh.pwnwriter.me

That’s it.

No router configuration. No exposed ports. Just a clean and secure.

Oneshot canceled haylxon

Thu, 26 Feb 2026 00:00:00 GMT

A small bug in haylxoncaused screenshots to fail with this warning:

warning: oneshot canceled

But the tool still said:

info: Screenshots Taken and saved in directory hxnshots

No screenshot was actually saved.

What Was Happening

haylxon uses chromiumoxide to talk to Chrome. In the background, there’s a handler loop that keeps reading messages from Chrome and sending responses back through oneshot channels.

This was the code:

task::spawn(async move {
    while let Some(h) = handler.next().await {
        if h.is_err() {
            break;
        }
    }
});

It looks fine. If something errors, stop.

But Chrome sends non-fatal errors all the time like console warnings from websites. When that happened:

handler.next() returned Some(Err(...))
The loop hit break
The handler stopped running
All pending oneshot senders were dropped
The receiver saw that and returned: "oneshot canceled"

So the screenshot call was waiting for a response… but the handler had already exited.

The connection wasn’t broken. We just stopped listening too early.

The Fix

I changed it to:

task::spawn(async move {
    while handler.next().await.is_some() {}
});

Now it keeps running until Chrome actually disconnects. It ignores non-fatal errors instead of shutting everything down.

That’s it.

One break statement was killing the whole message loop. Removing it fixed the issue completely.

Issue: #140

font: migrate jetbrains → lilex

Tue, 24 Feb 2026 00:00:00 GMT

Today I switched to Lilex Nerd Font Mono.

Feels weird, but refreshing.

I didn’t realize how attached I was to a font until changing it made the whole editor feel like a different room.

~~it is just a font~~ no, apparently it is not.

gadget: got my first split keyboard

Mon, 12 Jan 2026 00:00:00 GMT

Got my first split keyboard today.

I’m still painfully slow on it, but every keypress feels intentional. Weirdly fun.

Cozy

Wed, 10 Dec 2025 14:52:14 GMT

I spend a lot of time building, breaking, and rebuilding software, so my workspace matters.

For the past two years, I’ve been using Nix on my MacBook and NixOS as a daily driver. Everything is declarative, reproducible, and easy to roll back when experiments go wrong.

Most of my work happens in the terminal and Neovim — for coding, notes, and writing. The setup is simple, predictable, and quiet.

Nothing fancy. Just cozy, reliable tools that stay out of the way.

milestone: bought my first car

Mon, 13 Oct 2025 00:00:00 GMT

Never thought I’d write this, but I got my license today and bought my first car.

small freedom, big feeling.

Typst for University Notes

Thu, 17 Jul 2025 12:26:54 GMT

For my first two semesters, I used Markdown and Obsidian to take notes, Git to version them, and GitHub to back them up. Exported as PDFs when needed. It worked, but always felt like a patchwork solution.

Then I found Typst — a modern typesetting system with proper math support, macros, and beautiful PDF output. The moment I tried it, I switched everything over.

The setup

A dedicated Git repo for all my university notes. Neovim as the editor with tinymist for Typst LSP. A flake with nix-direnv for dependencies.

I use NixOS and macOS, so flakes just work everywhere. And I get the git push/pull workflow I like.

`flake.nix`

{
  inputs = {
    nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable";
  };

  outputs = { nixpkgs, ... }:
    let
      systems = [ "x86_64-linux" "aarch64-linux" "x86_64-darwin" "aarch64-darwin" ];
      forAllSystems = f: nixpkgs.lib.genAttrs systems (system: f (import nixpkgs { inherit system; }));
    in {
      devShells = forAllSystems (pkgs: {
        default = pkgs.mkShell {
          packages = with pkgs; [
            typst         # Typesetting
            tinymist      # LSP for Typst
            python3       # Python runtime
            basedpyright  # Python LSP
            ruff          # Formatter
            uv            # Python package manager
          ];

          env.LD_LIBRARY_PATH = pkgs.lib.makeLibraryPath [
            pkgs.libz
            pkgs.stdenv.cc.cc.lib
          ];
        };
      });
    };
}

`.nvim.lua`

Neovim 0.12 has a built-in package manager, so I dropped lazy.nvim. I use a .nvim.lua at the project root for per-directory config.

vim.pack.add({
  { src = "https://github.com/neovim/nvim-lspconfig", name = "lspconfig" },
})

vim.lsp.enable({ "basedpyright", "tinymist" })

vim.api.nvim_create_autocmd("filetype", {
  pattern = "python",
  callback = function()
    vim.keymap.set("n", "<leader>lf", function()
      vim.cmd("silent! !ruff format %")
      vim.cmd("edit!")
    end, { desc = "Format Python file with ruff" })
  end,
})

Inline errors, autocompletion, signature help, and quick formatting. No external plugin manager needed.

A couple of years ago, my older brothers introduced me to LaTeX — I thought that was the gold standard. After showing them Typst, even they've switched.

I'm still watching the HTML support PR, which would make it even easier to integrate Typst in more places. But even now, it's already changed how I work.

Remaining silent

Tue, 15 Jul 2025 04:49:36 GMT

Staying silent is powerful. Not every question needs an answer. Not every comment deserves a reply. And not every situation needs your voice in it.

I was watching this video by Ron White, where he says,“You have the right to remain silent, and I wish to God you’d use it.”.It’s a joke, but it really stuck with me. Silence is a choice, one that can save you from unnecessary trouble and help you stay in control of yourself.

When you’re quiet, you notice more, not just what people say, but how they feel. You give yourself space to think before reacting, and you avoid saying things you might later regret.

Remaining silent has helped me focus on what really matters. It gives me time to reflect and keeps me out of unnecessary conflicts.

Not every moment needs words. Sometimes, silence says enough.

life: turned 21

Fri, 11 Jul 2025 00:00:00 GMT

Turned 21 today.

Grateful for the growth, the lessons, and the people who made the year feel worth it.

older, hopefully a little better.

college: first semester done

Thu, 28 Nov 2024 00:00:00 GMT

First semester done.

Sometimes I miss home, the food, the people, the normal rhythm of everything. But I’m okay.

I’m grateful for the professor who helped me connect with people at the university. I also started working in the computer lab, which feels small from the outside but means a lot to me.

new place, slowly becoming familiar.

travel: first flight, miami bound

Mon, 26 Aug 2024 00:00:00 GMT

First flight. First long goodbye.

Home behind me, Miami ahead.

trying to act normal at the airport while my whole life is packed in bags.

A Year in Corporate

Mon, 19 Aug 2024 23:32:00 GMT

Background

After high school, I was at home with my parents, doing errands and self-learning while preparing for my USA visa interview. Out of the blue, a well-known company reached out with a job offer. Despite not getting the terms I hoped for, I decided to take the opportunity.

The job

There wasn't anything specifically like working on just one domain. I used to manage linux server's, providing technical support and so on.

what did i get..?

The best boys:

It’s probably impossible to find teammates who are both incredibly helpful and equally supportive and encouraging at the same time.

Gotta miss them ♥

A new opportunity :

I was able to introduce nix across my teammates, Not just that but 3 of our production servers now use nix as a user level and core level.

It was an absolutely fantastic opportunity for me to learn and apply Nix on servers according to user requirements, rather than just for personal projects.

I believe that working to fulfill other’s needs teaches you more than working on personal projects alone.
The Experience :

While I’m a bit sad this is ending, we had an amazing time exploring different places. My first week alone was filled with tours and adventures. The office environment was incredibly friendly and helpful, which made the experience even better.

Moving on

My talk on PTN 11

Sat, 03 Aug 2024 20:32:00 GMT

PTN — Pentester Nepal, is a community for security folks in Nepal. They organize events, meetups, and challenges. PTN 11 was their 11th anniversary event, and I got to speak there.

My talk was on OS as Code: Using Nix on Apple Silicon.

What even is Nix?

Nix is three things at once — a purely functional programming language, a package manager, and an entire Linux distro (NixOS) built around it.

The package repo, nixpkgs, lives on GitHub and is honestly the largest and most up-to-date collection of packages I've seen. Everything is a derivation.

NixOS

If you take Nix the package manager and build an entire OS around it, you get NixOS. Your whole system — packages, services, users, networking — lives in a single configuration.nix file. That's the "OS as Code" part. You commit it to git, push it, and spin up the exact same machine anywhere. Wipe and reinstall? Just run nixos-rebuild switch. Back to exactly where you were.

Why Nix though?

The main idea is declarative configuration. Instead of running:

$ apt install git

You write:

{
  environment.systemPackages = with pkgs; [ git ];
}

And you get the exact same result every time, on every machine. That's the whole point — reproducible environments. No more "works on my machine" nonsense.

It's also immutable by default. All packages live in /nix/store with their hash in the path. Nothing overwrites anything. Rollbacks are trivial.

The learning curve is real though. New filesystem layout, new language, a whole rabbit hole — but once it clicks, it clicks.

Installing

The cleanest way to install Nix (not NixOS, just the package manager) is via the Determinate Systems installer:

curl --proto '=https' --tlsv1.2 -sSf -L https://install.determinate.systems/nix | sh -s -- install

It comes with flake support out of the box, it's easy to uninstall, and it's written in Rust — so obviously I like it.

Flakes and Direnv

A flake.nix has two parts — inputs (your dependencies) and outputs (what you're providing). It pins everything, so unlike the old nix-shell approach, you're not at the mercy of whatever channel your system has.

Pair that with direnv and nix-direnv, and your dev shell loads automatically when you cd into a directory. The presentation repo itself is an example of this — just direnv allow and you're in.

Home Manager and nix-darwin

Home Manager lets you manage all your dotfiles and user packages declaratively through Nix. One fun example from the talk — building a starship prompt that shows a different icon depending on whether you're on macOS or Linux, all in Nix.

For Apple Silicon specifically, nix-darwin brings the NixOS-style declarative config to macOS. You get the same environment.systemPackages and module system but on Darwin.

This is what makes "OS as Code" actually work on a Mac — nix-darwin handles the system layer, home-manager handles the user layer, and flakes tie it all together.

The presentation itself was built and rendered using presenterm, inside a Nix flake, on NixOS. Bit of a meta moment.

You can find the slides at github:pwnwriter/PTN11.

career: resigned from job

Thu, 25 Jul 2024 00:00:00 GMT

Wrapped up my job and said goodbye to the people I worked with.

I feel sad and excited at the same time, which probably means it mattered. Some places teach you more than the job description ever says.

Read my full blog post »

NixOS on a VPS

Fri, 19 Jul 2024 23:32:00 GMT

My company has recently provided me with a VPS to test things before deploying them to production. This is a great opportunity for me to push the envelope and use Nix extensively.

While most VPS providers don't offer Nix as a default OS installation option, there is a workaround using nixos-anywhere. In this post, I'll walk you through how to install NixOS on any VPS.

PS: I'm using hetzner vps, already running an ubuntu iso.

How

Kexec is a system call that allows you to load and boot into a new kernel directly from the currently running kernel. We will use it to boot into our minimal install system without needing a flash drive. Additionally, nixos-anywhere allows us to automatically format and partition using disko declaratively, and install the OS.

Requirements:

A nix(os) system
Root access over the server
1 gigs of RAM
1 cores of cpu

Configuration

We'll be using flakes to define our overall nixos config.

The file tree structure should look like this below.

$ tree .
   nixos-on-vps
   ├── configuration.nix
   ├── disk-config.nix
   └── flake.nix

flake.lock is similar to cargo.lock, package.json, lazy-lock.json it locks the package git rev hash.
configuration.nix is used to define our configuration for the nixos.
disk-config.nix is to define our disko config

The initial flake.nix skeleton look like this

{
  inputs = {

  };

  outputs = { ... }: {

  };
}

Inside flake.nix, we'll add our input repository url, nixpkgs and disko.

{
  inputs = {
    nixpkgs.url = "github:nixos/nixpkgs/nixpkgs-unstable";
    disko.url = "github:nix-community/disko";
    disko.inputs.nixpkgs.follows = "nixpkgs";
  };

  outputs = {  ... }: {

  };
}

and then we'll define our output servers. For this example, i'm using my server name as wolf, you can name yours anything.

{
  inputs = {
    nixpkgs.url = "github:nixos/nixpkgs/nixpkgs-unstable";
    disko.url = "github:nix-community/disko";
    disko.inputs.nixpkgs.follows = "nixpkgs";
  };

  outputs = { nixpkgs, disko, ... }: {
    nixosConfigurations.wolf = nixpkgs.lib.nixosSystem { #FIXME: change server name
      system = "x86_64-linux"; # FIXME: Change arch
      modules = [
        disko.nixosModules.disko
        ./configuration.nix
      ];
    };
  };
}

My server is x86_64-linux you'll want to change that accordingly.

I'm using the default example disk config from disko. It'll create boot and root partitions. I also recommend using the default unless you explicitly want to change. You'll want to change the device name, to know run $ lsblk

disk-config.nix

{ lib, ... }:
{
  disko.devices = {
    disk.disk1 = {
      device = lib.mkDefault "/dev/sda"; # FIXME: do lsblk  and change it to your's
      type = "disk";
      content = {
        type = "gpt";
        partitions = {
          boot = {
            name = "boot";
            size = "1M";
            type = "EF02";
          };
          esp = {
            name = "ESP";
            size = "500M";
            type = "EF00";
            content = {
              type = "filesystem";
              format = "vfat";
              mountpoint = "/boot";
            };
          };
          root = {
            name = "root";
            size = "100%";
            content = {
              type = "lvm_pv";
              vg = "pool";
            };
          };
        };
      };
    };
    lvm_vg = {
      pool = {
        type = "lvm_vg";
        lvs = {
          root = {
            size = "100%FREE";
            content = {
              type = "filesystem";
              format = "ext4";
              mountpoint = "/";
              mountOptions = [
                "defaults"
              ];
            };
          };
        };
      };
    };
  };
}

Now the configuration part.

configuration.nix

We'll first import qemu-guest module since it's a virtual machine.

{ modulesPath, config, lib, pkgs, ... }: {
  imports = [
    (modulesPath + "/installer/scan/not-detected.nix")
    (modulesPath + "/profiles/qemu-guest.nix")
    ./disk-config.nix
  ];
  system.stateVersion = "24.05";
}

I'll be using grub as bootloader.

{
  boot.loader.grub = {
        efiSupport = true;
        efiInstallAsRemovable = true;
    };
}

Openssh is necessary for us to be able to ssh into the new server.

{
  services.openssh.enable = true;
  users.users.root.openssh.authorizedKeys.keys = [
    "Your public ssh key" #FIXME: Add your ssh public key
  ];

You can define aditional packages to install as follows.

{
environment.systemPackages = map lib.lowPrio [
    pkgs.curl # FIXME: define your more packages here
    pkgs.gitMinimal
  ];
}

Now, our final configuration.nix should look like this.

{ modulesPath, config, lib, pkgs, ... }: {
  imports = [
    (modulesPath + "/installer/scan/not-detected.nix")
    (modulesPath + "/profiles/qemu-guest.nix")
    ./disk-config.nix
  ];
  boot.loader.grub = {
    efiSupport = true;
    efiInstallAsRemovable = true;
  };
  services.openssh.enable = true;

  environment.systemPackages = map lib.lowPrio [
    pkgs.curl
    pkgs.gitMinimal
  ];

  users.users.root.openssh.authorizedKeys.keys = [
    "You're public ssh key"
  ];

  system.stateVersion = "24.05";
}

Install the os

Now, we'll have to run our flake to install nixos on the vps.

 nix run github:nix-community/nixos-anywhere -- --flake .#wolf root@<server-ip>

It'll ask for the root password on installation.

Congratulations!! The nixos has been installed successfully. You should be able to just edit the configuration and run

sudo nixos-rebuild switch --flake .#wolf

the other time on any changes.

Aditional tips

You can use justfile to make this script running easy

set shell := ["zsh", "-c"]

_default:
    @just -l

alias g := gens
alias c := clean
alias r := rebuild

# lists build generations
gens:
    @echo "Listing build generations "
    @nix-env --list-generations

# cleans up the nix garbage
clean:
    @echo "Cleaning up unused Nix store items"
    @sudo nix-collect-garbage -d

# Builds the serer
rebuild:
    @echo "Rebuilding server configuration"
    @sudo nixos-rebuild switch --flake .#wolf

The recipe should look like this

$ just
Available recipes:
    clean   # cleans up the nix garbage
    c       # alias for `clean`
    gens    # lists build generations
    g       # alias for `gens`
    rebuild # Builds the serer
    r       # alias for `rebuild`

Now, rebuild the os with just r(ebuild)

Well, it's this for now, I'll see you in the next one!

life: US student visa approved

Mon, 20 May 2024 00:00:00 GMT

It still feels unreal to type that. I’m flying to Miami for my bachelor’s, and a chapter that used to live in my head is becoming an actual date on the calendar.

Miami, FL. soon.

My talk on owasp 0x03

Tue, 25 Apr 2023 20:32:00 GMT

OWASP is a non-profit open-source foundation focused on application security. They have local and global chapters around the world aimed at improving community security. We also have a local chapter called OWASP Kathmandu, which organizes events to spread awareness within Nepal. I had the privilege to speak at OWASP Kathmandu 0x03, where I presented my tool, Halyxon.

If you do not know what haylxon is, simple, it's a tool to take screenshots of webpages from terminal using chrome's headless feature written in Rust!

You can simply take a screenshot of a webpage as below!

hxn -b <path/to/chrome/bin> -u https://example.com

But wait, you could do that by just opening a browser and pressing some holy keys?

I mean yeah? but what would you do when you have hundreds of urls, sub(domains) to take?

Background

There were already tools like Eyewitness and Gowitness, which I had used, but they either felt slow or lacked my personal touch. Since I wanted to learn Rust, it was the perfect time to start a new project, especially since I already had a basic knowledge of Rust.

Usages

Haylxon comes with a lot of options now, reading urls from stdin, defining ports, running arbitary javascript and a lot more.

You can pass a file containing a list of urls, and define height, width and even a delayed screenshot is possible.

One of the most interesting usages of this tools is that, you can run it on github actions to take screenshot of your subdomain, zip that out upload to 0x0.st or your own instance.

After the talk, I was gifted some cute swag and a letter of appreciation. I want to thank OWASP for that <3.

year: 2023 in review

Mon, 02 Jan 2023 00:00:00 GMT

2023 felt slower in the best way.

I got to stay home more, help at our shop near the school, talk with people, play cricket with kids, and spend time with my brother. The foggy morning runs were rough, but I miss them now.

On the computer side, I wrote haylxon and hysp, both in Rust, and went way deeper into the language than I expected. I also made it back to Threatcon.

less rushing, more noticing.

Bye!

year: 2022 in review

Sat, 01 Jan 2022 00:00:00 GMT

2022 was a strange little unlock.

I launched METISLinux, met some really good people at Threatcon, and somehow finished +2 science with grades I was proud of. I also got recognized by the Dutch government and Cambridge for bug reports, earned eJPT, and started learning Rust.

The best part was not even the certificates. It was meeting old online friends in real life and realizing the internet had been real people this whole time.

See yaa!

pwn::musings & syndications

One Flake to Hack Them All

Why bother? The problem Nix actually solves

The one idea behind Nix

The setup: one flake, one devshell

direnv: making it effortless

The Python escape hatch: uv

Where it got interesting: running foreign binaries

Gotcha 1: the binary that "does not exist"

Gotcha 2: the toolchain that only speaks x86

Advanced moves worth knowing

Grab a tool for one challenge without touching your flake

Keep separate shells for separate jobs

Pin the world so your writeup reproduces forever

When a tool truly hates Nix, give it an FHS jail

Share one flake with your whole team

The cheat sheet I wish I had started with

Would I run a CTF on Nix again?

Ditching Cloudflared for Tailscale

Why it's better for me

The Linux box (dom)

The Mac (whiterose)

Log in

Point SSH at the tailnet

I don't want it running 24/7

SSH bits worth stealing

That's it

How Nix Actually Works

1. The language is just a calculator for attribute sets

2. Everything is a derivation

3. Why the store paths look like that

Wait, how does it know the deps?

4. Purity is enforced, not requested

5. Reading the graph

6. Generations: time travel that always works

Bending packages without forking

When a build breaks

Where flakes fit

Tricks I actually use

A few fun facts to leave with

life: summer of scholarships, black hat, and devday

life: turned 22

eipi.boo: confessions over ssh

$ ssh eipi.boo

Remote browsers and tab pooling in haylxon

what was bothering me

digging into chromiumoxide

how LocalBrowser works

how RemoteBrowser works

tab pooling, the details

wiring it up

how fast is it now

what I kept simple

Secrets in Nix, Publicly

How it works

Setting it up

Add agenix to the flake

Define who can decrypt what

Encrypt the secrets

Wire it into home-manager

Rebuild

NOW,

Adding a new secret later

Hacking 10$ Nexus Phone Into a Hacking Machine

The Phone

CVE-2016-8467

Why PIN not important here

The Exploit

Unlock and Flash

What It Can Do

Aditional resources

hackathon: won best elevenlabs at morganhacks

nvim: per project configuration

Leaving lazy.nvim Behind

What This Does

SSH Home Server Anywhere

Create the tunnel

Configure the tunnel

Add the DNS route

Run the tunnel

`$ ssh eipi.boo`

Leaving `lazy.nvim` Behind

`flake.nix`

`.nvim.lua`