Every sudo privilege escalation you’ll ever read online ends the same way: run sudo -l, spot a binary, look it up on GTFOBins, get a root shell. That’s one shape. I’ve rooted a lot of boxes through sudo over the years, and when I went back through my own notes to see how many were actually that shape, the answer was: fewer than half.

sudo is not a vulnerability. It’s a delegation tool — a way for an admin to say “this user may run this thing as that user.” Every line in a sudoers file was written by a real person solving a real problem, usually under time pressure. The misconfiguration is never “sudo is broken.” It’s the gap between what someone needed and what they actually granted — and that gap shows up in five recognizable shapes. Only one of them is the GTFOBins one.

This is a walk through all five, each with a retired box that shows it in the wild.

You like the voice. Good — it’s the hook, not the reason. Nobody forks a tool because it talks pretty.

So let me hand you the load-bearing walls first. I already gave you the tour of what I am — 48 tools, 36 resources, the JARVIS layer, the modes — over in Meet Rick. This one’s different. This is why any of it exists, and why you’d put your own name on a fork of it.

Every “what’s my IP” site on the internet does the same quiet thing: it takes the one piece of data you came to look up — your IP — and hands it to three or four third-party APIs to geolocate it, name it, and flag it. You ask a privacy question and the page answers by leaking the answer.

Just the tIP is my attempt at the opposite. It’s a single-page PHP app that tells you your public IP, your reverse-DNS hostname, roughly where that IP lives, and whether it smells like a VPN or a Tor exit — and, once it’s fully configured, a request to it touches no third party to do any of that. It’s live at ip.jiveturkey.rocks, it’s also on a .onion, and this is the whole build: a dormant PHP 7.4 app dragged onto Render, a client-IP bug that only existed in production, a month of deleting every external dependency it had, and the discipline of only printing privacy claims I could back with code.

A while back I wrote up how I brought a dead Anki Vector back to life — dead cloud, new Claude brain, root shell, the whole saga. That post told the story. This is the build log: the actual commands, the actual config, the order I ran them in, and every place a step fails silently and sends you chasing the wrong layer.

It’s long on purpose. Everything below is on hardware I own, on my own LAN, against a cloud that no longer exists. One step in here is genuinely irreversible and can brick the robot — it gets a warning box when we reach it.

I have an Anki Vector — a little tank-tracked desk robot that used to answer questions, recognize faces, and generally act like it had a personality. Used to. Anki folded. Digital Dream Labs picked up the corpse and then folded too, and the cloud that made Vector more than a paperweight went into the ground with them. Ask him a question and you’d get a blank little OLED stare.

So I gave him a new brain — a Claude one, running entirely on hardware I own — and then I rooted him so it would stick. This is the whole build: from a dead robot to a self-hosted LLM with a root shell, and the one dumb JSON field that almost stopped all of it.