DEV Community: v. Splicer

I Open-Sourced a Free YouTube Shorts Factory. The Money Isn't in the Shorts.

v. Splicer — Mon, 02 Nov 2026 17:48:13 +0000

The pipeline costs nothing. The audience costs everything. Here's the math the faceless-channel gurus skip.

There's a particular genre of video that haunts the recommended feed after midnight. A guy in a rented penthouse, or more often no guy at all, just a synthetic voice over stock footage, explaining that he makes $14,000 a month from a channel he hasn't touched in weeks. Faceless. Automated. Passive. Link in bio for the course.

The course is the business. The channel is the ad for the course. That's been true for years, and nobody running the funnel has any reason to tell you.

I built the machine those courses describe and put it on GitHub for free. It's called ffmpeg-ai, it lives at https://github.com/numbpill3d/ffmpeg-ai, and it turns a single line of text into a finished, captioned, voiced vertical video using almost entirely free services. Giving it away makes it easy to tell the truth about what it can and can't do for your bank account, because there's nothing to upsell on the far side of the repo.

The short version: the factory works. The economics of what it produces are nothing like the thumbnails.

What the Machine Actually Does

ffmpeg-ai is a Python CLI. You give it a topic and it runs an eight-stage pipeline:

1. script     OpenRouter, with fallback across 6 free LLMs
2. voice      edge-tts, hook + segments + CTA synthesized in parallel
3. pacing     expands the visual timeline so no image overstays
4. images     AI images synced per segment, cascading across 7 providers
5. render     Ken Burns motion or fast storyboard cuts
6. captions   local faster-whisper transcription, burned in
7. music      optional bed with sidechain ducking under narration
8. encode     H.264 + AAC, 9:16 for Shorts or 16:9 for landscape

Setup is the usual ritual:

$ git clone https://github.com/numbpill3d/ffmpeg-ai.git
$ cd ffmpeg-ai
$ uv pip install -e ".[dev]"
$ cp .env.example .env    # add your OpenRouter key, free tier works

Then:

$ ffmpeg-ai generate "why your router's admin page is still on port 80"

What comes out is a 9:16 video up to 58 seconds long, with a voiceover, karaoke-style captions, paced visuals, a thumbnail and a run report. The free image path uses Pollinations (no key), Stable Horde (guest key built in), and the free tiers on Hugging Face and Together. Paid providers like BFL, fal.ai and Prodia are optional slots, never requirements.

Batch mode is where the "passive" fantasy starts to feel real:

$ ffmpeg-ai batch topics.txt -o out/

Fifty topics in a text file, fifty videos in a folder by morning. Your marginal cost per video rounds to zero. That sentence is the hook every faceless-channel course is built on, and it's completely true.

It also stops mattering the moment you look at the other side of the ledger.

The Math They Leave Out

Start with what YouTube pays for Shorts. Public RPM estimates (what a creator actually takes home per thousand views) cluster around $0.02 to $0.10 across most niches. Finance and tech sit near the top of that band. Memes and text-message stories sit at the floor. Long-form in the same niches typically lands between $2 and $15 per thousand. That's up to two orders of magnitude more per view for the format the guru videos never mention.

Now run it:

10,000,000 Shorts views x $0.02 per 1k  =  $200
10,000,000 Shorts views x $0.10 per 1k  =  $1,000

Ten million views is a lot of human attention. It's roughly the number of people who live in Sweden. Monetized as Shorts, it buys you somewhere between a nice dinner and a month of rent in a cheap town.

And you have to earn the right to collect even that. The current Partner Program bar for full revenue sharing is 1,000 subscribers plus either 4,000 public watch hours in a year or 10 million Shorts views in 90 days. In August 2026 YouTube announced that from February 1, 2027, new applicants need double that: 8,000 qualified watch hours or 20 million qualified Shorts views in 90 days. Existing partners keep their status but need to accept the new terms by January 31, and they need to hold 10 million qualified Shorts views on a rolling 90-day window to keep earning from Shorts at all. Drop under the line and Shorts revenue stops until you climb back over it.

So the bar for getting paid just doubled for anyone who isn't already in. The pay rate didn't move.

The Policy That Eats Slop Farms

The bigger threat to the automated channel is the review.

YouTube's old "repetitious content" policy now goes by inauthentic content, and the clarified guidance from July 2026 is blunt about what it targets: generic, template-built videos, content that's unsatisfying or off-putting, and AI personas posing as experts on health, legal, finance or political topics. The detail that matters most is that reviewers judge the channel's overall pattern, not individual videos. One templated upload doesn't sink you. Three hundred that share a skeleton will.

Picture a channel built by running batch on a scraped list of trending topics with the default style, default voice and default captions, every single day. That channel is a pattern, and patterns are exactly what this policy was written to catch.

Disclosure is a separate rule. Realistic synthetic content that could be mistaken for something real needs the "altered or synthetic content" toggle in Studio, and realistic AI voices fall inside that line. Disclosing doesn't throttle reach or monetization on its own. Skipping it when it's required can get you demonetized. Flip the toggle and move on.

What this policy kills is the lazy way of using the tool.

Where the Money Actually Lives

The faceless-channel gurus are right about one thing: the business model works. They just put it in the wrong place on the diagram. The course sellers make their money from the course. The channel is top-of-funnel, a machine for turning strangers into people who recognize your name.

You can run the same play honestly. Treat Shorts as distribution and treat a product you own as the business. A digital guide, a template pack, a config bundle, anything with margins you control and a price that isn't set by an ad auction. One $35 sale is worth the Shorts payout on somewhere between 350,000 and 1.75 million views at the RPM band above. Ten sales a month and the ad revenue is a rounding error.

There's one plumbing problem. Since August 2023, links in Shorts descriptions and comments aren't clickable. YouTube killed them to fight spam. What you have left:

The channel page. Links in your channel header still work, and that's where curious viewers go after a Short lands.
Related video links. A Short can point to a long-form video or livestream on your channel. Long-form descriptions do have clickable links.
Everything off-platform. Your Medium posts, your newsletter, your own site. Shorts are the billboard. The shop needs a front door somewhere else.

So the structure that makes sense looks like this. Shorts pull attention. A handful of longer videos (ffmpeg-ai has a landscape mode up to ten minutes with --mode landscape -d 300) catch the people who want more. Those videos and your channel page point at something you sell.

If you want a worked map of this pattern applied to automation projects that actually invoice somebody, AI Automation Playbook covers seven monetizable builds and a 30-day plan. It's the long version of "stop selling attention by the thousand and start selling outcomes."

Running the Factory Without Building a Slop Farm

The tool has the flags you need to stay on the right side of "inauthentic." Use them.

Edit the script before it renders. The --edit-script flag stops the pipeline after the LLM writes and before anything gets voiced. Rewrite the hook. Kill the filler. Add the one detail only you know. A video that contains your judgment isn't template content, whatever generated the first draft.

$ ffmpeg-ai generate "how cheap ESP32 boards became aircraft trackers" \
    --edit-script --style dramatic --caption-style bold-center

Use your own visuals. --images-dir path/ swaps the AI image providers for a folder you supply. Screenshots of your terminal, photos of your bench, diagrams you drew. This one change does more for the "is a human here" question than anything else in the pipeline.

Script-only dry runs. --dry-run generates the script without rendering. Run fifty dry runs, keep the five worth making, and render those. Curation is the human layer, and it's cheap.

Vary the skeleton. Rotate --render-mode between kenburns and storyboard, rotate caption styles, and change the music bed. A channel where every video has the same bones reads as a farm because it is one.

Pick a niche you can actually talk about. This matters more than every flag combined. An AI pipeline amplifies whatever you feed it. Feed it a topic you understand and it saves you hours of editing. Feed it a topic you scraped from a "most profitable niches" listicle and it produces a confident wrong video at industrial scale.

Once the workflow is curated, the scheduling becomes the boring part, which is exactly what you want. A cron entry or a scheduled job that runs ffmpeg-ai batch against a reviewed topic file, writes into a dated folder and pings you when renders finish turns the factory into a morning ritual instead of a project. The 25 production configs in OpenClaw Automation Bible handle exactly this kind of plumbing: scheduled jobs, multi-step swarms, and Telegram or Discord notifications when a batch lands. Wire the render queue to it and you can review a folder of drafts over coffee instead of babysitting a terminal.

The Honest Unit Economics

Here's the ledger with nothing hidden:

cost per Short          ~$0 on free tiers (your electricity, your time)
human time per Short    10-20 min if you edit the script and swap visuals
Shorts ad revenue       $0.02-$0.10 per 1k views, after you qualify
qualification           1,000 subs + 10M Shorts views / 90 days
                        (20M for new applicants from Feb 1, 2027)
links in Shorts         not clickable; route via channel page + long-form
real revenue            whatever you sell at the end of the funnel

The machine removes the production cost. It doesn't remove the attention problem, the policy problem or the product problem. Three problems out of four are still yours.

That's still a good deal. Production cost was the wall that kept most people from running a channel at all. With that wall gone, you get to spend your hours on the parts that pay: having something to say and having something to sell.

Clone it, run a dry batch on ten topics you actually know, and render the best two. If both of them embarrass you, the problem was never the pipeline.

Sources: github.com/numbpill3d/ffmpeg-ai (README); UpTube, "YouTube's New 2026 Policies"; Social Day, "YouTube raises Partner Program entry bar to 8,000 watch hours from February 2027"; Korpi, faceless channel RPM estimates; Tubefilter, "YouTube's banning clickable links from Shorts descriptions and comments" (Aug 10, 2023).

Tags: passive-income, make-money-online, youtube, automation, artificial-intelligence

Your LoRa Board Can Track Airliners at 150 Nautical Miles

v. Splicer — Mon, 02 Nov 2026 13:00:04 +0000

The datasheet stops at 960 MHz. The airplanes are at 1090. Somebody did the math anyway.

Somewhere over your house right now, a few dozen aircraft are shouting their names into the dark. Altitude, heading, a 24-bit hex identity, all of it on 1090 MHz, all of it plaintext, roughly twice a second, to anyone holding the right piece of copper. For about a decade the right piece of copper was an RTL-SDR dongle hanging off a Raspberry Pi. That arrangement still works. It's also no longer the cheapest way in.

On November 1, Hackaday covered a build by a developer who goes by thefatmoop: an ADS-B receiver made from a Meshnology W12 board, which pairs an ESP32-S3 with Semtech's new LR2021 LoRa transceiver. No SDR. No Linux. No Pi. The board demodulates the aircraft signal itself, checks the CRC, and serves live tracks on a web page from a chip the size of a postage stamp. The builder reports aircraft at around 150 nautical miles with an indoor antenna that was cut for the wrong band. Parts come in under $50.

That last detail is the interesting one. The radio was never sold to do this.

The Box Says 960 MHz

Pull up the LR2021 spec and you get two published frequency ranges: 150 to 960 MHz for the sub-GHz path, and 1600 to 2500 MHz for the 2.4 GHz and S-band side. ADS-B lives at 1090 MHz, which falls neatly in the gap between them, a dead zone on the marketing sheet.

The build tunes the sub-GHz path to 1090 anyway, and it hears airplanes.

There's a whole philosophy of hardware hiding in that sentence. A frequency range on a datasheet is a promise about performance across temperature, voltage and production lots. A warranty, basically. The synthesizer inside a modern transceiver usually has more headroom than the vendor wants to characterize, guarantee and support, so the published number lands where the lawyers and the test engineers are comfortable. Past that number you are on your own, which in practice means the thing usually works a little worse and nobody will help you when it doesn't.

Every interesting capability in computing started as a misuse. Wi-Fi chips became spectrum analyzers. TV tuner dongles became the RTL-SDR. Now a LoRa transceiver built for battery-powered sensor meshes is pulling Mode S out of the sky. The pins don't care what the box says. They care about tolerances.

The second reason this works is the modulation list. The LR2021 supports FSK, LoRa, LR-FHSS, FLRC, O-QPSK and OOK. That last one, on-off keying, is the whole trick, because ADS-B is pulses of carrier switched on and off. Strip away the aviation acronyms and an aircraft transponder is a very fast, very loud flashlight.

What a Plane Actually Says

ADS-B on 1090 MHz is called Extended Squitter. Each message opens with an 8 microsecond preamble: four short pulses at fixed offsets (0, 1.0, 3.5 and 4.5 microseconds) that work as a fingerprint for "a Mode S frame starts here." After the preamble comes the data block, 112 bits at one megabit per second.

The encoding is pulse position modulation. Each bit gets a 1 microsecond slot split into two halves. A pulse in the first half is a 1, a pulse in the second half is a 0. If that sounds like Manchester encoding riding on OOK, you've understood it, and that's exactly how the build's write-up describes it.

Inside those 112 bits:

DF   (5 bits)   downlink format, 17 for ADS-B from a transponder
CA   (3 bits)   capability
AA   (24 bits)  ICAO address, the aircraft's permanent hex identity
ME   (56 bits)  the payload: position, velocity, callsign, depending on type
PI   (24 bits)  CRC-24 parity

The CRC is your entire quality gate. At 1090 MHz you're listening to a crowded band full of overlapping replies, reflections and garbage, so the receiver lives or dies on rejecting frames that don't check out. The ESP32-S3 handles that in firmware: frames that fail the CRC go in the bin, frames that pass get decoded into tracks.

Note what's missing from that bit layout. There's no signature, no key and no nonce. The 2013 academic paper "On the Security of the Automatic Dependent Surveillance-Broadcast Protocol" said it plainly: the data link layer has no authentication. Anyone can listen, and nobody can tell you're listening. Keep that in mind, because it comes back at the end.

Flashing It

The project ships as a GPL-3.0 repository, esp32s3-lr2021-adsb-receiver, with a factory image in its releases. The flow is short enough to fit on a napkin:

1. flash the factory image (follow the repo's install guide)
2. join the W12-ADSB-SETUP wifi network the board broadcasts
3. browse to 192.168.4.1/setup and enter your own 2.4 GHz wifi creds
4. read the board's new IP off the 0.96" OLED
5. open that IP from any machine on the same network

Once it's on your LAN, check the receiver diagnostics page before you trust anything. The defaults use the LF (sub-GHz) input. Frequency correction starts in Observe mode, where it measures drift without acting on it. Let it watch real traffic for a while, then flip it to Apply. Cheap crystals drift, and a receiver that's slightly off-frequency looks exactly like a receiver with a bad antenna. People burn hours swapping antennas to fix a calibration problem.

Use a real USB-C data cable. The charge-only cable in your drawer will flash nothing and tell you nothing about why.

The Filter You Have to Kill

Here's where the build stops being a firmware install and turns into a hardware mod.

The W12's sub-GHz path has a SAW filter, U12, marked 2J1, sitting between the antenna port and the radio. Its job is to pass the LoRa band and reject everything else. It does that job well, which is the problem, because "everything else" includes 1090 MHz.

The README's fix is surgical. Remove U12, then bridge pads 1 and 4 with an insulated jumper so the antenna feeds the radio directly, and keep the jumper clear of pads 2, 3 and 5. Then connect your antenna to the LF/sub-GHz port.

A few notes from the bench side of this:

Use a fine tip or hot air. SAW filter packages are small and the pads lift if you get impatient. A tweezer-tip iron or a hot air station on low airflow is the civilized route.
Thin wire, short run. A short length of 30 AWG Kynar wire is ideal. At a gigahertz, a long loop of jumper is a tiny antenna of its own.
This is a one-way trip. Once U12 is gone, the LF path is unfiltered. LoRa use on that port gets noisier, and you're exposed to strong out-of-band signals that the filter used to eat. Treat the board as an ADS-B receiver from here on.

You can skip the mod. The HF/2.4 GHz input works without it. In the builder's testing, though, range was noticeably shorter on the unmodified path. The difference between 40 miles and 150 miles is one tiny filter and five minutes with a soldering iron.

Antennas, and the Wrong One That Works

The headline range came from an indoor 915 MHz antenna, the one cut for LoRa. That works because a 915 MHz whip is close enough to 1090 to resonate badly but usefully, and because airplanes are loud and high with nothing in the way.

You can do better for the price of a coffee. Wavelength at 1090 MHz is about 275 mm, so a quarter-wave element is about 69 mm. A quarter-wave ground plane (one 69 mm vertical element, four radials drooping at 45 degrees, all soldered to an SMA bulkhead connector) is a classic first antenna build for ADS-B, and it routinely beats store-bought whips. If you'd rather buy one, get something actually labeled for 1090 MHz with a 50 ohm feed.

Placement beats gain. Line of sight decides everything at this frequency. A cheap antenna in a top-floor window will outperform an expensive one on a desk surrounded by drywall, wiring and a monitor that leaks RF from every seam.

The optional GNSS module earns its slot here too. When the board knows where it is, range and bearing calculations make sense, and your track list stops being a list of numbers.

What You Give Up

This is a beautiful hack and an incomplete tool. Know the trade before you sell off your dongle.

A conventional RTL-SDR station, something like an RTL-SDR Blog V4 [AFFILIATE: RTL-SDR Blog V4] feeding readsb on a Pi, gives you a few things the W12 doesn't:

MLAT. Multilateration locates aircraft that broadcast Mode S without position data by comparing arrival times across many receivers. That needs precise timestamps and a feeder network. The W12 is on its own.
Feeding aggregators. The big community tracking networks expect standard decoder output. A custom ESP32 web page doesn't plug in without extra work.
Everything else on the spectrum. An SDR is a general-purpose radio. Tomorrow it can be an AIS receiver, a weather satellite station or a pager decoder. The W12 does one thing.

What you get in exchange is a receiver that boots in seconds, sips power from a USB brick, has no SD card to corrupt and no OS to patch, and costs less than a decent dinner. As a permanent window-sill sensor, a field unit in a go-bag, or a second station somewhere you'd never park a Pi, that trade is easy to justify.

The project also has honest edges. It's experimental. It's not an official Meshnology or Semtech product. A commenter on the Hackaday piece reported the W12 is hard to find in the US and EU outside Amazon India. Check availability before you plan a weekend around it.

Plaintext Sky

Back to that missing signature.

ADS-B is a protocol that announces everything and authenticates nothing. That makes it great for hobbyists and quietly uncomfortable for everyone else. Every aircraft with a working transponder broadcasts a permanent 24-bit address. The address maps to a registration. The registration maps to an owner. Log it for a month from one window and you have a pattern of life: who flies, when, where they go and how often they come back.

That's the OSINT angle, and it's why aircraft tracking keeps turning up in investigative work. Corporate jets telegraph acquisitions. Government flights telegraph visits. Private planes telegraph exactly what their owners would prefer they didn't. A $50 receiver that logs every ICAO address it hears is a surprisingly sharp instrument once you start keeping notes. If you go that route, a structured intel log matters more than the radio does. The template set in Obsidian + Claude Daily Ops (numbpilled.gumroad.com/l/obsidian-claude) was built for exactly this kind of recon-notebook habit, where raw captures become something you can actually search six weeks later.

The same plaintext design that makes listening easy makes injection theoretically easy, and that's been a research topic for over a decade: ghost aircraft, spoofed positions, the lot. Leave it on the page. Receiving 1090 MHz is legal in most places. Transmitting on it is the kind of mistake that ends with very serious people at your door, because you'd be interfering with live air traffic safety systems. The W12's radio can transmit. Don't let it near 1090 on the way out.

Defenders have the mirror-image problem: a receiver network that trusts plaintext can be fooled. Plausibility checks, multilateration and cross-referencing against primary radar are how serious systems cope. A single-board receiver like this one makes a nice teaching tool for that conversation, because it shows you exactly how little stands between the sky and your screen.

Where to Take It

Build one, mod the filter, cut a 69 mm ground plane, stick it in the highest window you have, and let it run for a week. Then point something at the data. Log every ICAO address to a file, count unique aircraft per hour, and flag any address you've seen more than ten times. Within a few days you'll know which tail numbers own your sky.

If this build hit the part of your brain that likes turning cheap ESP32 boards into field sensors, the rest of that playbook lives in Hardware Hacking for OSINT: Raspberry Pi War-Driving Box (numbpilled.gumroad.com/l/pidriver). It's the long-form version of this post's instincts: RF capture, firmware, and turning passive collection into intelligence without paying anyone a subscription.

The datasheet said 960. The airplanes said 1090. The airplanes were right.

Sources: Hackaday, "Building An ADS-B Receiver For Less Than You Think" (Nov 1, 2026); github.com/thefatmoop/esp32s3-lr2021-adsb-receiver; CNX Software on the Semtech LR2021; Strohmeier, Lenders and Martinovic, "On the Security of the Automatic Dependent Surveillance-Broadcast Protocol" (arXiv:1307.3664).

Python Scripts That Pay Rent

v. Splicer — Sat, 31 Oct 2026 22:58:39 +0000

If you do it twice, you script it. If you script it well, you sell it.

I didn't learn Python to get a job. I learned it to stop doing jobs I hated.

For 6 months, I watched myself do the same dumb, manual tasks every single day. Digging through 50,000 lines of logs to find why a site crashed. Checking HaveIBeenPwned every time I used the same password twice. Copy-pasting client names into an invoice template like it was 1998.

Then I stopped learning and started automating.

The shift is simple: Stop asking "what can Python do?" and start asking "what am I already doing that's annoying as hell?"

Those annoying things are rent-paying scripts. Because if it annoys you, it annoys 10,000 other people. And they will pay $19 to never do it again.

Here are 3 scripts from my actual pack that now pay my internet bill, my coffee habit, and then some. Steal them, use them, and I'll show you how to turn them into a Gumroad product in 2 hours.

The Framework: From Chore to Cash

Most Python tutorials are backwards. They teach you for loops and then give you a fake problem.

Real automation works like this:

1. Identify The Repeat: Anything you do 2x per week manually.
2. Script The Ugly Version: It doesn't need to be pretty. It needs to work for YOU.
3. Productize The Clean Version: Add arguments, error handling, a README. That's a tool.
4. Sell The Result, Not The Code: Nobody wants "a Python script." They want "never manually parse logs again."

Let's build it.

1. The Log Parser That Saves Your Sanity (and Your Saturday)

The Annoying Shit: Your client says "the site was down at 3 AM." You open access.log. It's 300MB. It's just IP - - [timestamp] "GET /..." 200.

You Ctrl+F for "500" like an animal.

The Script: log_hunter.py — Finds the real problems in seconds.

This is the script I use for every freelance server I touch. It finds 5xx errors, counts top failing endpoints, and flags suspicious IPs that are hammering you.
Use it: python log_hunter.py /var/log/nginx/access.log

Why it sells: Every indie hacker, freelancer, and junior DevOps guy has this exact problem. They don't want to learn regex. They want to run one command and send a screenshot to their client. I sell this as part of a "Server Rescue Kit" for $19. It took me 45 minutes to write.

2. The Credential Leak Checker That Stops You From Getting Pwned

The Annoying Shit: You have a .env file with 30 API keys. You have old projects on . You have that one config_old_backup.json you forgot about. Did you leak a Stripe key 8 months ago? You have no idea until Stripe emails you saying "we rotated your key."

The Script: leakpatrol.py — Scans your own machine like an attacker would.

This one is paranoid and valuable. It scans a directory for high-entropy strings, known key patterns (, Stripe, GitHub PATs), and .env files left in git.
Use it: Drop it in any project folder and run python leakpatrol.py

Why it sells: Fear is a great motivator. This script sells to freelancers and founders who are terrified of getting that email from AWS about a $4,000 bill because they leaked a key. I package it as "Pre-Commit Security Guard" and upsell a GitHub Action version. People pay for peace of mind.

3. The Invoice Auto-Gen That Actually Gets You Paid

The Annoying Shit: It's the 30th. You have to make 5 invoices. You open . You open last month's invoice. You change the dates. You change the numbers. You miscalculate. You hate your life for 45 minutes.

The Script: invoice_machine.py — From a CSV to a PDF invoice in 2 seconds.

This one literally pays rent. I bill hourly. I track work in a simple CSV. This script turns that CSV into a professional PDF and calculates tax, totals, everything.
Use it: Keep a work.csv for each client. Run it. Send the PDF.

Why it sells: This is not for developers. It's for designers, writers, video editors, VAs — anyone who freelances. They don't want to learn FPDF. They want to stop using a free invoice generator that puts a watermark on their invoice. This is a $29 product all day long called "Freelancer Invoice Automator."

How To Turn A Script Into A Product In 2 Hours

Having 3 scripts is cool. Having a Gumroad page that makes $17 while you sleep is cooler. Here's the exact playbook I use with Quickforge.

Most people fail here because they try to sell code. Don't sell code. Sell time and outcome.

Hour 1: Tool-ify It

Your messy script is not a product. A tool is.

Add Argparse: Nobody wants to edit line 23 to change the file path. Let them do python tool.py --file access.log. All 3 scripts above already do this.
Add a README.md that sells: Not "how it works." "What it does for you."
Make it executable: Add a requirements.txt (even if it's just fpdf2). Make a single folder.

This is what Quickforge does for me in one click. It takes my script and wraps it into a CLI, adds the error handling, and builds a distributable ZIP. It turns "some Python file" into "a real tool you can run."

Hour 2: Gumroad-ify It

Bundle, Don't Single Out: Don't sell 1 script for $5. Sell "3 Rent-Paying Python Scripts" for $29. Or "The Automation Pack for Freelancers" for $49. Value stacking.
Record a 45-second demo: Use Loom. Show the annoying manual way (scrolling a log file for 10 seconds). Then show your script fixing it in 2 seconds. That video is your Gumroad cover.
Write the description for the lazy buyer: Use this template: > You do [annoying task] manually. This stops it. > You get: > - log_hunter.py (Find crashes in seconds) > - leakpatrol.py (Find your leaked keys before hackers do) > - invoice_machine.py (Turn a CSV into a paid invoice) > Perfect for: Freelancers, indie hackers, junior devs who want their time back. > No Python expertise needed. Just run it.

Upload the ZIP. Set the price to $29. Publish.

You now have a product. Not a script.

The Killer Bundle: Why This Works Right Now

The reason I'm pushing this bundle so hard is that the two pieces solve each other's problem.

Python Automation Secrets is the library. It's 50+ scripts like these three, but categorized: client work, security, finance, content. You don't have to come up with ideas. You just pick the annoying thing that matches your life.

Quickforge is the factory. It solves the reason 99% of automation scripts never make money — they stay as messy .py files on your desktop. Quickforge turns them into polished, sellable tools with a README, CLI, and installer without you learning packaging.

You need both. The Secrets give you the ammo. Quickforge gives you the gun.

If you do one annoying thing twice this week, you have your first product. I gave you three.

Stop learning Python. Start automating your rent away.

Want the full pack + the tool that packages it? Get the Python Automation Secrets + Quickforge bundle here. It's the only tutorial where the homework pays you back.

P.S. Drop your most annoying recurring task in the comments. I'll reply with the exact script I'd write to kill it.

Debugging at 3 AM: A Horror Story With No Villain Except Me

v. Splicer — Sat, 31 Oct 2026 04:35:34 +0000

Production was down, the dashboard was bleeding red, and every suspect had an alibi. The killer had my git credentials.
3:04 A.M.

The phone glows at 3:04 in the morning, and there is a grammar to that light. Not the white of a text from someone who loves you. Not the green of a package arriving. The amber of the paging app — the color of weather emergencies and furnace warnings; the color machines use when they want to inform you, courteously, that something you built is misbehaving in public.

I sat up in the dark and opened the laptop, which lit my face the way open freezers do in films about regret.

The dashboard was a Jackson Pollock painted entirely in red. Our authentication service — the front door of the product, the one service contractually obligated to be boring — was failing at a rate I had previously considered theoretical. Users weren't just failing to log in. They were being logged out. Mid-session, mid-sentence, all across the map, in every timezone our little empire covers.

Every engineer has a private horror story, and we tell them the way fishermen describe weather: exaggerated, semi-mythological, absolutely load-bearing. I want to tell you mine as what it actually was — a horror story — because it has every required element. A remote cabin (my apartment). A storm (rain, theatrical, unpaid). An isolated protagonist (me, insufferable). And a monster no search party could ever find, because I was about to spend four hours learning that the monster had my face and my commit history.

What it doesn't have is a villain. That's the part the genre never prepares you for.

The Fine Art of Needing Someone to Blame

Every incident has a casting call, and mine convened immediately.

Suspect one: the deploy. It is always the deploy; this is the closest thing software has to folk wisdom, and folk wisdom survives because it is usually right. I checked. Nothing had shipped in four days. The most recent release had the alibi of sediment.

Suspect two: the network. "It's not DNS," I told the empty room. "There is no way it's DNS." I checked the DNS anyway, the way you check behind the shower curtain in a horror film — not because you expect to find anything, but because the genre demands one token act of courage. The DNS was fine. Somehow its innocence felt like a betrayal.

Suspect three arrived on schedule, and I am not proud of this: the new engineer. She joined three weeks ago. She had shipped nothing, touched nothing, and was, at that moment, asleep like a person with a clear conscience — statistically the most suspicious condition there is. By 3:40 I had mentally drafted a post-mortem with her name in it. Gently worded. Professionally devastating.

Here is what I was actually doing, though I lacked the vocabulary for it at the time: running a comfort ritual. Humans are blame-seeking missiles. Hand us an unexplained catastrophe and we will generate a villain with the reflexive urgency of an immune response. Villains make chaos narratable. A system that failed for seventeen interacting reasons is a nightmare you can't repeat at parties; a system that failed because Dana pushed on Friday is a story, and stories feel like control.

The safety literature worked this out decades ago, in an industry that counts its dead. James Reason's Swiss cheese model — the one from aviation, the one that says disasters happen when the holes in several layers of defense happen to line up — exists precisely because "one careless person" is almost never the truth of a serious failure. Charles Perrow went further in Normal Accidents and argued that in systems complex enough, breakdowns are not anomalies at all. They're residents. They pay rent.

I knew all of this. I had once cited it at an all-hands, in a confident voice, with a slide. At 3:40 A.M., knowledge and comfort are different organs, and only one of them was working.

The Bug With a Bedtime

Salvation, when it came, came from the most suspicious direction available: arithmetic.

Coffee number three had arrived not as a beverage but as a coping mechanism with a handle. I stopped staring at the aggregate error graph — staring at aggregates at 4 A.M. is just doom with a scrollbar — and sliced the errors by hour instead.

And the error rate had a bedtime.

3:00 A.M. Sharp. A spike, a twenty-minute decay, silence. I scrolled back one day: 3:00 A.M., spike, decay, silence. Two days: the same. Seven nights, the same. A metronome wearing a ski mask. Whatever this was, it wasn't random and it wasn't ambient. It was scheduled. Something in my system looked at its watch every night, said now, and did a murder.

Naturally, it refused to happen in staging. I pointed every instrument I owned at the staging environment and it sat there, serene, error-free, smug in the way only a system without real traffic can be. For one feverish hour this felt like a genuine heisenbug — a bug that flees observation, a witness who heard a noise and declines to repeat it. Purists will object that an environment difference is not a true heisenbug, and the purists are right, but at 4:20 A.M. every bug that hides from daylight qualifies as uncanny.

I explained all of this, in detail, to the rubber duck on my desk. His name is Vladimir. He has heard things. He said nothing, which is his gift.

The clue that cracked it was almost embarrassing: the staging servers believed, sincerely and wholeheartedly, that they lived in UTC. The production servers lived in local time. Everything else was identical. Which meant the variable I had been treating as scenery — the clock — was the weapon.

Time zones are the Cthulhu of computing: ancient, tentacled, worshipped entirely by accident. Nobody believes in them until one reaches up out of the deep and takes a production system with it.

A Séance Called git blame

Follow the mechanics forward and the picture assembles itself with the awful neatness of a locked-room mystery finally solved.

The mass logouts came first. The errors were just the thundering herd of evicted users stampeding back toward the door. The logouts were evictions — something was deleting live sessions. And there was only one thing in the entire system with delete rights: a cleanup job, a cron, that pruned "expired" sessions every night while the city slept.

In its WHERE clause, the definition of expired was computed with one clock, while the sessions themselves had been stamped with another. For one window every night, the two clocks disagreed about whether it was still today — and during that window, the job scanned every live session in the database, judged them all ancient beyond recovery, and deleted them. All of them. Then it tidied up, logged its success, and went back to sleep until tomorrow.

And the schedule? The cron ran at 3:00 A.M., because 3:00 A.M. is when traffic is lowest. I know this with terrible intimacy, because I scheduled it there myself, a lifetime ago, in a pull request I described — I checked — as "safe."

One clock stamps. Another clock judges. Once a night, they disagree. The rest is arithmetic wearing a hockey mask.

I ran git blame on the comparison, which is less like forensics and more like a séance: you summon the dead, you ask who did this, and the answer always arrives in monospace. The blame lit up line by line, and then it landed on a commit from 241 days ago, with a message I have now read so many times I've stopped flinching:

quick fix: make cleanup behave for now, will revisit after launch

Author: me. Reviewer: me. And one line above it, written in my exact voice, a comment: // temporary, do not let this ship as-is.

I shipped it as-is.

I want to be precise about the feeling, because "the call is coming from inside the house" is a horror trope for a reason, and the reason is that the house is you. I read that code the way you reread a text you sent at a party: with dawning, pixel-by-pixel horror, at a stranger who had my name, my typing cadence, and my signature joke in the comments. I don't remember writing it. I remember launch week — I remember being exhausted and certain, which is the same memory wearing different clothes. Somewhere between then and now, that line stopped being mine and became the system's. Then the system handed it back to me at 3:04 A.M., with interest.

The Call Was Coming From Inside the Commit

Here is the thing I understood at around five in the morning, sitting in the wreckage of my own certainty — the thing I'd stay up all night again to keep:

A bug is not an intrusion. A bug is a disagreement — the residue left where the system in your head and the system in production quietly parted ways. Alfred Korzybski said the map is not the territory; code is a map we hand to a machine, and the machine is a perfectly literal client. It never rounds up toward our intentions. It executes the gap between what we meant and what we said — at nine digits a second, forever, until somebody notices.

And the noticing is science. Genuinely, structurally science. Every suspect I ran down that night was a hypothesis — the deploy, the network, the innocent new hire — and the logs were nature's answer: no, no, and no. Karl Popper would have recognized the procedure instantly. I wasn't debugging; I was falsifying. I was doing rigorous, disciplined science all night. I just hadn't expected the final theory to be me.

That's the twist the genre keeps missing. We tell debugging stories as detective stories — find the culprit, restore order, roll credits. But there is no culprit, because the culprit is a condition: complexity plus time plus a confident human moving quickly. Edsger Dijkstra — who never once let a good sentence go unsaid — put the quiet part loudly: "Program testing can be used to show the presence of bugs, but never to show their absence." Absence of bugs cannot be demonstrated. Only deferred. Every codebase is a haunted house where all the ghosts are future versions of the people currently alive.

Douglas Hofstadter wrote whole beautiful books about systems that contain their own self-reference — loops that point at themselves and turn strange. We ship those weekly. We just call it Tuesday.

So I gazed into the stack trace, and the stack trace gazed back into me, and it used my font.

Absolution Is Not a Deploy

The fix was one line. I want that on the record, because the disproportion is both the punchline and the lesson: a week of 3 A.M. pages, four hours of dread, one small theological crisis — resolved by teaching two clocks to agree. One word, effectively. Eight months of latent catastrophe, priced at less than a tweet.

Then I did the three things that actually mattered, none of which were the line of code.

I made staging's clocks match production's, because "works in staging" should at minimum mean "works on the same planet." I added an alert on mass logouts specifically, because error rates are the scream and logouts are the whisper, and monitors that only hear screams will always fail you at exactly the volume that matters. And I wrote the post-mortem, and I put my own name in the root cause field.

That last one is the bravest sentence in engineering: I did this. Not as penance. There were no robes, no ritual shaming, no wheel-of-misfortune slide at the all-hands. Blameless doesn't mean consequence-free — it means the consequence is knowledge. The document said, plainly: a well-meaning engineer, under launch pressure, shipped a temporary change with no ticket, no reminder, and no monitoring that could have caught it for 241 days. Remove any one of those conditions and the incident doesn't happen. Which means the fix was never "be more careful." The fix is "build a system where careful is not a heroic act."

Reason's Swiss cheese, again: I wasn't the hole. I was the unlucky alignment of the holes, wearing a lanyard.

At 6:40 the sun came up, indifferent, like a build that passes on the second try. I bought the new engineer a coffee and told her she'd been acquitted of a crime she never knew she was charged with. She laughed. Then she made me show her the diff, and she asked the question every senior engineer should be asked monthly:

"Who else has a TODO like this?"

We found four. Each had my fingerprints, or hers, or someone's — because that is what fingerprints are. Evidence that a human was here. And humans are how the future pages you.

Epilogue for the Next One

The next horror story has no villain either. Statistically speaking, it's you.

Not because you're careless — because you're fast, and confident, and navigating a map so much larger than any territory one person can hold. Seniority in this field isn't the accumulation of tricks. It's the slow, expensive process of updating your priors against your own evidence. Every scar is data. Every 3 A.M. is a peer review conducted by a merciless machine.

So, some benedictions — cheap, and hard-earned:

Write TODOs with dates, not vibes. Temporary, in production, means geological. Schedule your crons at hours you have personally witnessed while awake. And mistrust any diff you'd describe as "safe" in a pull request titled "small cleanup" — the monster is always introduced as a minor character.

The bugs of the future are being written right now, by people who are certain. The only defense our species has found is humility with instrumentation: assume the map is wrong, watch the territory, and when something finally pages you at 3 A.M., skip the séance. Open the blame. Say hello to the author.

Your turn: tell me about your 3 A.M. monster in the comments. I promise I won't ask who wrote it.

The answer is always the same.

6 Ways AI Changes OSINT (For People Who Already Do It Manually)

v. Splicer — Fri, 23 Oct 2026 16:01:12 +0000

You were pivoting before it was a prompt. Here's what the machines actually add to the craft — and what they still can't do for you.

There are two kinds of people reading this. The ones who discovered OSINT last year because an AI told them it was a lucrative career path, and the ones who were manually pivoting through breach dumps, certificate logs, and decade-old forum posts while the rest of the world was still asking chatbots to write haikus about the weather.

This one's for group two.

You don't need the craft explained to you, and you can smell a thought-leader post from three tabs away. So no hype here, no "AI will replace investigators," no carousel energy. Just six changes that are actually real, rated honestly by someone who respects your workflow: some of these will save you hours, one of them will save your case, and all of them come with fine print the demos never mention.

1. Local models killed the "where can I safely paste this" problem

Every investigator knows the reflex. You're holding a juicy chunk of text — a scraped bio, a membership list, sixty pages of forum rambling from a guy who definitely did the thing — and before you run it through a cloud tool, you pause. Whose servers does this touch? Whose logs does it land in? Am I about to leak my case to a third party to save twenty minutes?

Local models ended that negotiation. Run an open-weights model on your own hardware — Ollama, LM Studio, whatever fits your stack — and the entire analysis loop closes on your machine. Entity extraction, timeline reconstruction, matching three different transliterations of the same alias: all offline, all private, all yours.

This isn't a nice-to-have. If your work touches journalists' sources, confidential clients, or anything with a legal tail, "I uploaded the dossier to a chatbot" is not a sentence you want to say out loud in any room with better acoustics than a parking garage.

And the hardware bar is lower than the pitch decks claim. A mid-range machine runs 7B to 14B parameter models comfortably, and for extraction-grade tasks that's plenty. You don't need a data center. You need discipline.

2. Summarization got free. Judgment didn't.

AI is genuinely, almost offensively good at one thing OSINT people hate: reading garbage. Four hundred pages of scraped soup. Eleven thousand forum posts. A company's entire changelog since 2014. A model compresses that into structure in minutes, for free, without complaint.

But compression is not investigation. The model will faithfully summarize everything — except the one detail that mattered, because it doesn't know what mattered. It has no case. No stake. No memory of the alias that felt wrong on Tuesday.

So the division of labor is simple: the machine reads the corpus, you decide the next hop. The moment you offload the "what's next" decision too, you get the average of everything. And the average of everything is exactly where investigations go to die.

Pivot logic is still the product. You've just been promoted off the reading engine.

3. Prompt pipelines turn one-off queries into repeatable tradecraft

If your entire AI technique is retyping "extract all usernames, emails, phone numbers and organizations from this text" every session, you're using a language model like a vending machine. It works. It's also the tradecraft equivalent of re-typing your wordlists by hand each time.

The practitioners actually getting leverage build prompt libraries the way they built bash aliases: written once, tested against known input, versioned, reused. Same input schema in, same output schema out. Which means results become diffable — you can run the same extraction prompt across thirty groups, or across the same source today versus last month, and compare structure instead of squinting at vibes.

That's the difference between doing OSINT and owning an OSINT workflow. Your prompts are tradecraft. Write them like it: store them with your tooling, review them like code, and stop keeping your best one in a chat history you'll never find again.

4. Agents are sentries, not oracles

The real unlock isn't asking an AI questions. It's having something that watches while you don't.

Agent-assisted correlation looks like this: scheduled runs that check whether your target's username just appeared on a platform you haven't covered. Monitors that watch domains adjacent to your subject for content changes. A quiet loop over paste sites and fresh breach drops, matching against your indicators, pinging you only when an edge in the graph actually moves.

You stop losing whole afternoons to "did anything change since Tuesday?" The machine watches the graph. You get pinged when it matters.

This is also where your case notes stop being a graveyard and become infrastructure. If your research lives in a connected structure — an Obsidian vault, a graph tool, whatever you actually maintain — an agent can walk it, re-check stale nodes, and surface the dead-end lead from 2021 that just got interesting again.

One rule, learned expensively by the field: an agent that acts without logged reasoning is a liability with a nicer interface. Make it show its work.

5. Cross-language pivots got cheap

Non-English sources used to be a wall. Behind it: entire regional platforms, marketplaces, and forums that knew they were invisible to the average investigator — and behaved accordingly. Either you spoke the language, you paid a translator, or you had a very high tolerance for machine translation's avant-garde poetry.

Multimodal models kicked that wall down. They read the signage in the corner of a photo. They translate regional slang without collapsing. They notice that the storefront in the background, the vegetation, and the watermark style on a classified listing all point the same direction. The uncaptioned photo your target posted now says: this is a Portuguese-speaking area, and this watermark pattern is common to Brazilian listing sites.

Verification stays yours — models hallucinate place names with unshakeable confidence, and confident is not correct. But the wall became a door. And if you only ever hunted in English, understand that your hit rate was artificially capped your whole career. Most of the internet is not in English. Your targets, as it turns out, knew that.

6. Your targets have AI too

The uncomfortable one. The same tooling that accelerates you accelerates everyone you investigate.

Synthetic personas now ship with generated faces, coherent five-year posting histories, and opinions that poll well. Sockpuppets are written by language models and no longer smell like 2019-era bots. Voice cloning turns "urgent call from the client" into a convincing thirty seconds.

So provenance is the new baseline, not a bonus round. Account age versus content depth. The too-coherent biography. The contact who can only ever communicate in text. Verify through a second channel before you trust a first impression — every single time.

Here's the craft correction the panic posts miss: AI didn't kill OSINT. It killed lazy OSINT. Verification went from "best practice" to "the entire job," and honestly? That's a promotion for the people who were doing it right anyway.

And the paranoid cherry on top: some of what you scrape is now AI-generated noise, seeded specifically to poison collectors. Telling signal from slop is a billable skill now.

What AI still can't do

A credibility check, because someone always needs one.

The model doesn't know which lead stinks. It can't feel the wrongness of an alibi that's technically plausible but rhythmically off. It doesn't get warrants, doesn't testify, doesn't carry the ethics of the craft, and will never once wonder whether it should.

Feed it garbage and it returns confident, beautifully formatted garbage — the most dangerous file format in existence. It will connect two entities that share nothing but a typo and present the connection with the calm authority of a court exhibit.

Judgment, gut feel, documentation discipline, ethics: still yours. The machine raises your ceiling. It does not lower your standards. An AI-native investigator with manual-era fundamentals is a genuine nightmare for the other side. The reverse is a chat bubble with a subscription.

Start small, start loud

Three moves this week, none of which require cosplaying:

One: run a local model. Ollama and a 7B-class model on hardware you already own. First rule of the AI-native vault: nothing about a case leaves your machine.

Two: build five reusable prompts. Extraction, summarization, timeline, contradiction-checking, username-mapping. Version them, test them, keep them next to your wordlists.

Three: wire the outputs into your graph. If your notes don't compound, you're still reset-every-session — which is precisely the manual-era problem this whole wave was supposed to fix.

The ghost route taught you that privacy is a practice, not a purchase. Same energy here: the toolkit changes, the operator remains.

I Turned a $50 Pocket Computer Into an Occult Operating System Because Modern Computing Has Lost Its Mind

v. Splicer — Thu, 22 Oct 2026 15:26:17 +0000

16 applications. A Daedric interface. Generative synthesis, wireless reconnaissance, experimental motion sensing, and a tiny browser for the forgotten internet. All running on an ESP32-S3.

There's something profoundly irritating about how boring computers have become.

We have absurd amounts of processing power. Graphics hardware capable of simulating realistic lighting. Neural networks that can generate entire applications while confidently inventing three nonexistent dependencies. Yet practically every interface looks like it escaped from the same corporate design meeting.

Rounded rectangles. Carefully selected shades of gray. A sidebar. Another sidebar. A button that used to do something useful but now opens a subscription page.

Your computer has sixteen cores and apparently the imagination of an insurance company.

Meanwhile, a tiny ESP32-S3 with a 240 × 135 display is perfectly capable of becoming a synthesizer, a network observatory, a procedural graphics machine, and a portal to the weirder corners of the internet.

So I built something called DIVINER.

It's a custom firmware environment for the M5Stack Cardputer ADV, containing sixteen applications inside a hand-crafted Daedric interface. Wireless networks become constellations. Bluetooth devices drift across the display like strange little familiars. Mathematical expressions produce audio. The menu is written in the fictional alphabet from Morrowind, and its glyphs dissolve into English when you navigate through it.

Some of the software is genuinely practical. Some of it is experimental. Some of it exists because I believe a computer should occasionally do something that makes you wonder whether it's entirely pleased to see you.

The complete source code is available here:

DIVINER on GitHub

And the hardware project, build details, and development documentation live here:

DIVINER on Hackaday.io

The firmware is open source. There's a prebuilt binary in the repository, and a desktop simulator for anyone interested in exploring the software without owning the hardware.

But the part worth discussing isn't simply that I managed to cram sixteen applications into a small computer.

It's why I wanted to.

We Used to Let Computers Be Weird

There was a period when interacting with a computer felt like entering somebody else's peculiar universe.

Amiga workbenches. Macintosh System 7. Shareware applications with interfaces designed by people who had clearly never been introduced to a branding consultant. Late-night BBS systems. Software with obscure keyboard shortcuts, ugly but memorable icons, and documentation written like the author had personally declared war on conventional typography.

Not all of it was good.

A fair amount was objectively terrible.

But at least it was identifiable.

You could recognize an application by its personality. Interfaces weren't all desperately trying to disappear. Some of them practically demanded that you learn their internal logic.

I miss that.

I don't particularly want my computer to feel invisible. I want it to feel like an instrument.

DIVINER came out of that frustration, mixed with an unreasonable affection for Morrowind, Serial Experiments Lain, experimental music software, and tiny machines that look like they were designed to receive messages from abandoned satellites.

The idea was simple enough: stop treating the Cardputer as a miniature smartphone and start treating it as a completely different kind of computer.

Not a dashboard. Not a gadget full of unrelated demonstrations.

An environment.

The Hardware Is Ridiculously Small. That's the Point.

The M5Stack Cardputer ADV is built around an ESP32-S3.

It has a compact keyboard, a small color display, wireless connectivity, audio hardware, and enough interfaces to become surprisingly useful without attaching an entire graveyard of external peripherals.

Its screen contains exactly 32,400 pixels.

For perspective, that's not much real estate when you're trying to build a custom interface, display network information, render procedural graphics, and interact with multiple independent applications.

You cannot simply shrink a modern desktop interface down and expect things to work.

Every unnecessary panel becomes expensive. Every poorly designed menu becomes an obstruction. Every line of text needs to justify the pixels it occupies.

And that's when things get interesting.

Constraints force decisions.

A high-resolution monitor can conceal mediocre interface design under layers of padding and decorative nonsense. A 240 × 135 screen gives you nowhere to hide.

DIVINER uses the limitations deliberately.

The primary interface is dark, spare, and aggressive. A blood-and-ember palette. Sharp typography. Subtle audiovisual feedback. Animations that serve the interaction rather than existing to impress a design portfolio.

At least, that's the practical explanation.

The less respectable explanation is that I wanted the thing to look like a cursed piece of consumer electronics from 2001.

Sixteen Applications, or Sixteen Rites

DIVINER doesn't refer to its applications as apps.

It calls them rites.

Yes, that's theatrical. No, I don't particularly care.

They're organized into four domains: Sound, Sight, The Wired, and Wards.

The naming gives the environment a vocabulary of its own, but underneath it is fairly straightforward modular C++ software.

And the applications are not just variations of the same scanning utility.

Sound: Turning an ESP32 Into an Instrument

The first domain contains three separate sound engines.

DRONE is a five-voice generative synthesizer. It combines drifting voices, resonant low-pass filtering, wind-like textures, bell elements, and delay.

It's designed less for writing conventional melodies and more for generating evolving sound environments.

Think unstable ambient textures rather than cheerful ringtone synthesis.

SEQ is a miniature groovebox with kick, snare, hi-hat, acid-style synthesis, Euclidean fills, four pattern banks, song mode, and save/load functionality.

This is where the firmware starts becoming an actual portable musical instrument instead of a curiosity.

BEAT is a bytebeat livecoding environment.

If you're unfamiliar with bytebeat, the premise is beautifully deranged: mathematical expressions involving a time variable can generate audio samples directly.

A tiny expression can produce rhythmic structures, melodies, grinding digital noise, or something resembling a malfunctioning modem experiencing a personal crisis.

All without conventional audio samples.

DIVINER's audio path operates at 24 kHz on the device, with shared DSP utilities supporting its sound-generating applications.

One of the things I enjoy about this arrangement is that the machine doesn't require a computer to explain itself. You can type into the little keyboard and produce sound directly.

No DAW startup sequence. No plugin manager. No seventeen-minute tutorial on configuring an audio interface.

Just an expression and whatever strange noise emerges from it.

Sight: Mathematical Hallucinations

The second domain deals with procedural visuals.

WIRED renders ASCII-based 3D objects, including toruses, wireframe geometry, tunnels, and a navigation sphere.

VISIONS produces animated plasma fields, falling Daedric glyphs, an Oblivion-inspired gate, ash-fire effects, and a heptagram kaleidoscope.

ORACLE casts three runes accompanied by bell-like audio.

No, the rune generator will not predict your future.

Although if it starts correctly predicting compiler errors, I'll reconsider that position.

The graphics applications are interesting because so much visual character can emerge from relatively simple mathematical operations.

You don't need a sophisticated graphics pipeline to make something feel alive.

You need movement, timing, recognizable patterns, and a little willingness to be strange.

I've always liked the idea that procedural graphics are a form of visual synthesis. You're not displaying a completed image. You're describing the rules by which an image continuously comes into existence.

On a tiny display, that distinction matters.

The Invisible World Is More Interesting Than Your Home Screen

The third domain is where DIVINER turns toward networking.

And this is probably the part that will interest the hardware hackers and security researchers.

We spend our lives surrounded by wireless infrastructure. Access points, Bluetooth peripherals, local devices, broadcasts, background activity.

An enormous amount of communication is happening in the air around us, and most people experience absolutely none of it.

Their phone displays a Wi-Fi icon.

That's the entire interface to the invisible machinery surrounding them.

I find that weird.

DIVINER experiments with making that information visible, audible, and spatial.

SCRY transforms nearby Wi-Fi networks into a constellation.

KIN represents discovered Bluetooth devices as drifting familiars.

LISTEN provides receive-only channel monitoring with an audible representation of activity.

LINK handles conventional Wi-Fi connectivity, remembered networks, and captive-portal detection.

NET explores hosts, names, and exposed ports on a local network.

These tools don't all have the same purpose.

Some are diagnostic. Some are informational. Some are experiments in presenting familiar data through an unfamiliar interface.

The central question is whether a network scanner has to look like a network scanner.

Why should access points always appear as a depressing list of SSIDs?

Why couldn't their relationships become part of the interface?

An alternative visualization doesn't automatically make information more accurate or actionable. It can introduce new ambiguities, and that's worth acknowledging.

But the conventional presentation isn't sacred either.

Sometimes changing how information is displayed changes which questions you're inclined to ask.

And occasionally it just looks significantly cooler.

Both are acceptable motivations for making software.

Yes, It Has Experimental Wi-Fi Motion Sensing

The fourth domain, Wards, contains some of the more ambitious and technically uncertain work.

PULSE explores Wi-Fi Channel State Information, or CSI, for detecting changes associated with movement and presence.

The interesting concept here is that wireless communication isn't occurring in a perfectly static environment.

Signals reflect, scatter, and interact with physical surroundings.

When those surroundings change, properties of the observed radio channel can change too.

Under suitable conditions, CSI measurements can provide information related to motion.

This doesn't mean the Cardputer has suddenly acquired magical radar abilities.

Radio-based presence sensing is complicated. Multipath effects, hardware behavior, environmental noise, available traffic, and physical layout all influence what can actually be inferred.

An observed change does not necessarily mean a human walked past the device.

That uncertainty is precisely what makes it worth experimenting with.

I think there's something fascinating about repurposing a communications radio as a crude environmental sensor. It's the same physical hardware, but you're asking it a completely different question.

SENTINEL takes another approach to environmental monitoring.

It learns a baseline of nearby devices, then flags newly observed ones. It also looks for wireless indicators potentially associated with drones.

That last part needs a qualification: it's heuristic. A radio signature is not definitive proof that an object is a drone, and the absence of such a signature doesn't prove there isn't one.

Still, baselining a local wireless environment and watching for changes is an interesting foundation for experimentation.

PROBE adds active HTTP reconnaissance and default-credential checks for explicitly authorized hosts.

The firmware's security-oriented capabilities are intended for equipment and networks the operator owns or has permission to test. It doesn't implement phishing or denial-of-service functions.

The goal is observation and assessment, not turning a handheld computer into an indiscriminate nuisance machine.

We have enough of those already. Most of them are employed in marketing.

There's a Gemini Browser in Here Because Apparently I Have Priorities

This is one of my favorite details.

DIVINER includes GEMINI, a gemtext browser using TLS, with posting support.

Gemini, for anyone unfamiliar, is a lightweight document-oriented internet protocol with a much simpler model than the modern web.

It's closer in spirit to the idea that you should be able to retrieve and read a document without loading half a megabyte of JavaScript, asking permission to accept cookies, and being offered a discount on a newsletter you never wanted.

The Cardputer is an oddly appropriate place to browse it.

A small keyboard. A tiny display. Modest hardware resources.

Nothing about the device suggests that it should be pretending to run a full contemporary browser.

But Gemini doesn't demand that.

There's a satisfying symmetry to using a deliberately minimal computer to access a deliberately minimal part of the internet.

Modern web development has become an extraordinary exercise in industrial-scale complexity.

Sometimes I just want a page containing words.

Preferably without a chatbot asking if I need help finding the words.

The Most Useful Part Might Actually Be the Desktop Simulator

Here's the less glamorous engineering detail that deserves more attention.

DIVINER isn't built exclusively for the physical Cardputer.

It also has a native SDL2 simulator.

This is significant because developing embedded graphical software can be extraordinarily annoying.

Change a few pixels. Recompile. Flash the firmware. Restart. Navigate through the menu. Check whether the animation looks right. Discover that the animation still looks wrong.

Repeat until the sun goes out.

Instead, DIVINER separates application behavior from the hardware through dedicated abstraction layers.

The device implementation handles the actual Cardputer display, keyboard, and audio system.

The native implementation runs the interface on a desktop computer, reproducing the 240 × 135 display at an enlarged scale.

It also supports audio output, WAV recording, scripted input, and headless screenshot generation.

The native network implementation uses simulated data, so it isn't pretending to reproduce actual radio conditions. Wireless functionality still needs to be validated on the physical device.

But graphical and audio development can happen without constantly involving the hardware.

That's a meaningful architectural improvement.

It makes experimentation cheaper in time, which is often the most expensive resource in a project like this.

It also makes the firmware easier for other developers to investigate.

They don't necessarily need to own a Cardputer just to examine the interface or experiment with some of the application code.

For me, this is an important part of what open-source embedded software should be doing.

Not merely releasing code, but making the code practical to explore.

Building and Installing DIVINER

The firmware is written in C++ and built with PlatformIO.

The repository includes source code, build configuration, screenshots, interface previews, a desktop simulator, and a prebuilt firmware image.

To compile for the Cardputer ADV:

pio run -e cardputer

The generated firmware is located at:

.pio/build/cardputer/firmware.bin

To build the desktop simulator:

pio run -e native

And to launch it:

.pio/build/native/program

The firmware is designed to work with the Cardputer Launcher, allowing installation from an SD card or supported USB serial workflow.

Replacing the factory firmware can erase the existing device installation, so back up the device first and follow the current instructions in the repository.

One other important detail: this project specifically targets the Cardputer ADV. Don't assume hardware compatibility with earlier Cardputer models simply because their names are similar.

The full installation process and current files are available in the repository:

github.com/numbpill3d/cardputer-adv-diviner

Why the Interface Is Written in Daedric

I could claim that the Daedric interface is some elaborate experiment in cognitive ergonomics.

And, well, parts of it are genuinely interesting from an interaction-design standpoint.

But the actual reason is simpler.

I like fictional alphabets, strange old software, and the idea that a computer might possess a little mythology of its own.

The main menu displays application names in a hand-rasterized Daedric script. When you navigate to an entry, the characters dissolve into ordinary English.

It's a little theatrical.

It also communicates selection state without requiring additional interface furniture.

There's a lesson in that somewhere.

Decorative systems don't necessarily have to remain decorative. An animation can become a navigational cue. A fictional alphabet can establish atmosphere while also organizing interaction. Sound design can communicate state changes without consuming screen space.

Obviously, none of this would be particularly useful if the machine became impossible to navigate.

An interface that values personality still has to function.

But I reject the premise that usability requires everything to look like the settings screen on a corporate tablet.

There are other ways to make software understandable.

And I'd rather explore them than spend the rest of my life selecting between twelve slightly different border radii.

The Trouble With Calling Everything a Tool

Something else bothers me about the modern maker ecosystem.

We tend to evaluate small computers almost exclusively by the number of recognizable tasks they can perform.

Can it scan Wi-Fi?

Can it send infrared commands?

Can it identify devices?

Can it run this or that utility?

Those are useful questions, but they're incomplete.

A computer is not merely the sum of its utility functions.

It's also an environment for thinking.

A musical instrument changes your relationship with sound. A visualizer changes your relationship with data. A programming language changes how you express processes and structures.

A well-designed personal computer can combine these things into something much more interesting than an electronics multitool.

I don't think DIVINER has solved that problem. Far from it.

Some of its applications are more mature than others. The environmental-sensing functions are experimental. The interface has to coexist with real hardware limitations. There's plenty of room for further optimization, testing, and expansion.

But the underlying idea feels worth pursuing.

What if personal computing stopped being exclusively about convenience?

What if the machine could encourage curiosity instead of constantly trying to eliminate every moment of friction?

Not pointless friction, obviously. Nobody needs their Wi-Fi password entry transformed into an interpretive dance.

But exploratory friction. The kind that makes you notice something, wonder how it works, and follow the question somewhere unexpected.

That's the sort of relationship I want with hardware.

A Small Computer Doesn't Need to Pretend to Be a Large One

The most interesting machines are often the ones that have accepted their limitations.

An old synthesizer doesn't need to reproduce an entire recording studio to be worthwhile.

A Game Boy doesn't need photorealistic graphics to support an extraordinary amount of creativity.

A tiny computer doesn't need to provide a miniature imitation of macOS to become a meaningful personal computing environment.

DIVINER has sixteen applications, but I don't want its future to become a contest to see how many icons can be stuffed into a menu.

I'd rather improve the connections between its existing systems.

Make the audio engines more expressive. Explore better ways of representing wireless activity. Improve CSI experimentation and validation. Make the simulator more useful for testing. Develop the architecture so additional applications can integrate without losing the coherence of the environment.

And yes, probably add a few more deeply unnecessary visual effects.

There are standards to maintain.

The point is not to build the most practical handheld computer in existence.

It's to demonstrate that practical computing and distinctive computing are not mutually exclusive.

You can create a useful diagnostic tool without making it visually miserable.

You can write serious embedded C++ while enjoying an absurd fictional interface.

You can turn an ESP32 into a synthesizer, a network observer, a tiny-web browser, and a peculiar little electronic companion.

A computer is still a remarkably open-ended object if you stop accepting the default assumptions about what it's supposed to be.

DIVINER is one attempt to explore that.

And it's available for anyone curious enough to take it apart.

Get DIVINER

DIVINER is free and open source.

The GitHub repository contains the C++ source, PlatformIO configuration, interface previews, simulator, and firmware distribution.

Download DIVINER and explore the source on GitHub

For project documentation, hardware details, development logs, and updates:

Follow DIVINER on Hackaday.io

If you're running a Cardputer ADV, I'd be especially interested in hardware feedback, bug reports, and experiments with the wireless sensing functions.

And if you're one of those people who thinks software should always have a perfectly ordinary interface, I regret to inform you that the glyphs are staying.

Further Down the Rabbit Hole // numbpilled

DIVINER is part of a wider obsession with embedded systems, unusual hardware, wireless research, and computers that don't need somebody else's cloud account to justify their existence.

If you want to go deeper, I've also published paid technical guides and field manuals through numbpilled on Gumroad.

PHYSICAL AGENTS: Bridging OpenClaw With ESP32 Microcontrollers

A practical guide to connecting AI-agent workflows with physical microcontrollers using WebSocket services, custom device commands, telemetry, and hardware control. For anyone interested in building devices that interact with a larger automation environment instead of living entirely inside their own firmware.

ULTRAWIDEBAND STRIKE: UWB Hacking and Proximity Security

An advanced field manual examining UWB security and proximity systems. A separate research topic from DIVINER's ESP32 Wi-Fi features, but relevant to readers interested in the broader problem of how wireless hardware observes, measures, and trusts the physical world.

Explore the complete numbpilled technical archive

Firmware, experimental hardware, wireless research, security tooling, automation, and other projects from the parts of computing that still have sharp edges.

Xenotrek | v. Splicer

numbpilled

Build strange machines. Read their source code. Keep the interesting parts of computing alive.

The Return-Fraud Trick: How Hackers Turn Best Buy Into a Crypto Draining Machine

v. Splicer — Thu, 22 Oct 2026 15:14:29 +0000

Inside the dumbest, most expensive money laundering scheme that actually works — until it really, really doesn't.

The $3,000 Toaster That Became 0.04 Bitcoin

Let’s start with a question you’ve never asked out loud in a Best Buy parking lot: How do you turn a Geek Squad warranty into a Monero wallet?

The answer, according to a certain corner of Telegram, Reddit, and Discord that smells faintly of energy drinks and poor life choices, is return fraud. Not the petty kind your cousin did in 2011 with a worn prom dress. The industrialized, crypto-flavored kind.

The pitch goes like this: Best Buy is a giant, trusted, boring retailer. Your crypto wallet is a giant, untrusted, exciting black hole. What if you could build a bridge between them made entirely of boxed GPUs, fake receipts, and social engineering?

What if Best Buy was the ATM?

It’s a sexy narrative. It’s also a federal crime with a paper trail longer than a CVS receipt. But to understand why people try it, why it sometimes works for 48 hours, and why it always ends with someone crying in front of a loss prevention officer, we need to dissect the machine.

Quick note: This is an educational breakdown of a real attack pattern, not a playbook. If you're looking for OpSec that actually keeps your crypto safe from the people who do this to YOU, I put everything I know into one guide:
The Crypto OpSec Bible — https://numbpilled.gumroad.com/l/cryptoopsec

Act I: Why Best Buy?

Why not Target? Why not Walmart? Why the big blue box with the yellow price tag?

Hackers are, above all else, lazy economists. They love three things:

1. High value, high liquidity products. Best Buy doesn't sell lettuce. It sells exactly what a crypto bro wants to liquidate: MacBooks, iPhone 15 Pros, RTX 4090s, PS5s, DJI drones. One item = $800-$2,500. That's a good conversion rate. You don't need to steal 400 t-shirts to make rent.

2. Generous, inconsistent return policies. Best Buy's return policy is 15 days for most people, 30-60 days if you're a Totaltech member. That policy is enforced by a human teenager who is paid $16 an hour and would rather be anywhere else. Policy vs. human enforcement is where all fraud lives.

3. Gift cards as a laundering buffer. This is the key. Best Buy will often return high-value electronics for store credit or gift cards if you don't have a receipt. Gift cards are not money, legally. They are bearer instruments. They are crypto's clumsy, boomer cousin.

The hacker logic is beautiful in its stupidity: Product -> Fraudulent Return -> Gift Card -> Sell Gift Card for Crypto on Paxful/Noones/Binance P2P at 70-85 cents on the dollar -> Clean-ish Crypto.

You just turned a Best Buy into a really inefficient, really illegal Bitcoin ATM with a 15-30% fee and a chance of felony charges.

Act II: The Anatomy of The "Draining Machine"

There are, broadly, three flavors of this that circulate in fraud forums. I will describe them the way a criminology professor would — what the concept is — not how to do it.

1. The Receipt Roulette
This is the classic. Someone gets a legitimate receipt — from a dumpster, a photo posted on social media, an e-receipt forwarded from a compromised email inbox. They then walk in with the same product, new and sealed, and "return" it with that receipt. Best Buy's system checks: Is this a valid receipt? Is this within the window? Yes and yes. Money back to the original payment method, or if they're lucky, store credit.

The crypto twist: The original payment method is often a stolen credit card or a compromised account. The hacker doesn't want the money going back to the victim. They pressure for a gift card, claiming "oh, it was a gift" or "my card was closed." If the associate complies, they just laundered a stolen card purchase into an anonymous gift card.

2. The Empty Box / Switched SKU
Buy an expensive item. Carefully open it, remove the expensive thing, replace it with something that weighs roughly the same — a bag of rice, an old router, a literal brick — reseal it with a $20 heat gun from Amazon, and return it. Or buy two things that look identical: one expensive, one cheap. Think: A $600 Dyson and a $60 knockoff in the same colored box.

This is why Best Buy employees now shake every box like it's Christmas morning before accepting a return. They've been burned. Many, many times.

3. The Triangulation of Doom
This is the one that actually touches crypto draining directly, and it's the nastiest.

Victim thinks they are buying a cheap GPU on eBay or Facebook Marketplace. They pay a scammer in crypto or Zelle. The scammer then uses a different stolen credit card to order that exact GPU from BestBuy.com and has it shipped to the victim. Victim gets the GPU, leaves a 5-star review: "Wow legit seller!" Scammer got clean crypto, the stolen card holder gets the charge, Best Buy gets the fraud chargeback, and the victim is now in possession of stolen property.

Now flip it: The hacker is the "victim." They buy their own products with stolen cards, return them for gift cards, flip the gift cards for crypto. It's fraud turtles all the way down.

In all three cases, the "crypto draining machine" part is just the exit ramp. Best Buy is not being hacked in the Mr. Robot sense. No one is SSHing into their POS system. They're hacking the policy and the people.

Act III: Why This is the Dumbest Money Laundering Machine Ever Invented

Let's be witty and edgy for a second, but also intelligent: This trick is catastrophically stupid in 2026.

You think you're being slick. Best Buy thinks you're a spreadsheet.

Everything is logged. Best Buy uses The Retail Equation, or TRE. TRE is a third-party risk scoring system that tracks every return you've ever made without a receipt across Best Buy, Home Depot, Sephora, and dozens of other retailers. It logs your ID, your face from the security camera, your phone number, your license plate if you drove in stupidly. You get two or three "no receipt" returns and you are flagged nationwide. The third time, the system just says NO.

Gift cards are not anonymous anymore. Since 2022, large-value gift card sales and returns are tied to ID in most states. Selling a $2,000 Best Buy gift card on Paxful for 80% in BTC leaves you a permanent, public, on-chain record, plus a chat log on a P2P platform that will absolutely hand over your data to law enforcement with a subpoena. You just created a perfect evidence chain from the retail store to your wallet.

You are on 4K. Literally. Best Buy's loss prevention has better cameras than most casinos. They have facial recognition in many locations. They have license plate readers in the parking lot. And unlike crypto, their footage is stored.

I talked to a former AP associate who told me their favorite fraudsters are the crypto ones. "They always think they're smarter. They wear a mask, but they use their real Totaltech account for the points."

The cost-benefit is insane. You risk 2-5 years for wire fraud, mail fraud, and organized retail crime — which is now a federal priority — to net $800 in Bitcoin that is already down 12% by the time you flip the gift card.

Act IV: The Real Crypto Draining Lesson

Here's the twist that Medium's algorithm won't like but you need to hear: The Best Buy trick isn't really about Best Buy.

It's about how your crypto gets drained by people who think exactly like this.

The same social engineering that convinces a 19-year-old Best Buy associate to give a gift card instead of refunding a stolen card is the same social engineering that convinces YOU to sign a malicious setApprovalForAll transaction in your MetaMask.

The OpSec failures are identical:

Trusting a system (a return policy / a smart contract) without understanding the human enforcement layer.
Thinking anonymity = invisibility. A gift card is pseudonymous. A blockchain is pseudonymous. Both are completely traceable if someone is looking.
Converting value in a panic, at a loss, through a sketchy middleman. 80 cents on the dollar for your Best Buy gift card is the same as paying 30% slippage on a honeypot DEX.

Hackers aren't turning Best Buy into a crypto draining machine. They are turning your bad OpSec into their payday. Whether that's via a fake Best Buy e-receipt phishing email that steals your Gmail, which then resets your Coinbase, or a fake " Best Buy gift card to BTC" escrow that just steals your crypto.

If you hold crypto, you are the Best Buy. You are the store full of liquid, high-value items with a generous return policy (you, clicking "approve" on everything). And there are thousands of people outside shaking the box to see if anything rattles.

So what do you do?

You stop trying to learn the fraud trick and you start learning the defense.

Hardware wallet. Always.
Separate email for retail receipts vs. crypto exchanges.
Burner number for retail loyalty programs. TRE can't score you if you don't give them your real data.
Never, ever sell gift cards for crypto P2P with strangers. That's not a trade, it's a donation to law enforcement's evidence folder.
Understand that any scheme promising to turn retail arbitrage into anonymous crypto is either a scam to steal YOUR crypto, or a federal investigation you can join for free.

The machine doesn't work because Best Buy is too smart. It works, briefly, because people are predictably human. And humans are terrible at OpSec.

If you want the actual OpSec — how to set up wallets that can't be drained, how to make your digital footprint as boring as a Best Buy extended warranty brochure, and how to spot the 7 phishing emails that precede 90% of all wallet drains — that's what I wrote the full guide for.

It's here: https://numbpilled.gumroad.com/l/cryptoopsec

No gift cards required.

Disclaimer: This article is for educational and awareness purposes only. Return fraud is illegal under state and federal law. Don't be an idiot. Buy your GPUs like a normal person.

Written for Medium — 2026. If you found this useful, leave 50 claps, pretend you understood all of it, and share it with one friend who still keeps their seed phrase in Notes.app.

The $50 Breach: How One Hacker Used AI Agents to Rob 100 Companies

v. Splicer — Tue, 20 Oct 2026 21:32:41 +0000

Reuters reported it yesterday. One operator, 23 hours per intrusion, $5,000 in tokens. Offensive security just got industrialized.

I found it because it had no login.

Not a vulnerability. Not a misconfigured S3 bucket. A control panel for an AI agent platform called Cairn, just sitting open on the internet, live logs scrolling. No authentication, no banner, just a list of targets and a token counter ticking up in the corner: $0.42, $1.17, $3.08.

At 02:14 AM on October 2nd, one of those agents was working on Deere.

Attempting deere.com... enumerating store endpoints... testing checkout flow...

That panel belonged to a single Chinese-speaking operator. By the time Reuters published the story on October 19th, that one operator had pointed autonomous agents at more than 1,200 websites and broken into more than 100 companies, including Deere, SharkNinja, and — for about $5,000 in tokens.

About $50 per successful hack.

This isn't a story about superintelligence. It's a story about patience becoming cheap.

The breach that cost less than your OpenAI subscription

The numbers are what make this different from every other "AI hacks everything" headline.

Reuters, citing Norwegian security firm NorForge and researcher Snorre Fagerland, laid it out plainly: the campaign started September 25, 2026, ran for weeks, attempted more than 1,200 e-commerce sites, breached over 100 organizations across the US, Canada, Australia and Japan.

Fagerland wasn't hunting this hacker. He was scanning the web for exposed instances of Cairn — an open-source AI problem-solving toolkit that Reuters describes as popular with hackers — and found about two dozen instances being used for malicious activity beginning around October 2.

He didn't hack the hacker. The hacker left his own tooling open.

The most uncomfortable detail: each successful intrusion typically took the agents around 23 hours of probing. Not 23 seconds. 23 hours of slow, methodical, boring work that no human pentester would do at 3am without billing you $250 an hour. The agents did it for pennies, running on a mix of DeepSeek and Anthropic's Claude Code.

Total bill: roughly $5,000.

The author of Cairn said the platform "was not designed for hacking attacks." Which is true, and also irrelevant. A hammer wasn't designed for breaking windows either.

What Cairn actually is (and why it has no login)

Cairn — Cognitive Artifact Intelligence Network — is not malware. It's an agent orchestration framework. You give it a goal: "find a way into this e-commerce site." It breaks that goal into tasks, spins up sub-agents, tries payloads, reads responses, adjusts.

It's the same architecture that every legitimate AI coding agent uses: planner → executor → evaluator loop, with tool access.

The reason Fagerland could find it is architectural. Early versions of Cairn exposed a web UI for monitoring agent progress with no authentication by default. Developers running it locally thought "it's local, it's fine." Then they put it on a VPS. Then they forwarded the port.

If you followed the trail of exposed instances, you got the full playbook for free: prompts, tool calls, failed attempts, successful bypasses. One researcher titled his writeup exactly what it was: "The control panel behind a 100-site AI hacking spree has no login. I ran one."

That openness is why we know the cost. The panels logged token usage per target. Fagerland could literally watch the economics emerge in real time.

And the economics are the story.

23 hours, $50, and a very patient robot

Traditional offensive security has two constraints: talent and time. A good hacker can find business logic flaws in , Magento, WooCommerce customizations — coupon logic, inventory race conditions, tax calculation bypasses — but they get bored. They move on after an hour.

Agents don't get bored. The pattern NorForge observed was almost insultingly mundane:

Recon: crawl product pages, cart endpoints, checkout API.
Enumerate: test parameter pollution, try old endpoints still mounted.
Exploit: not zero-days. Old bugs. The kind of stuff that lives in a store's custom checkout plugin from 2021.
Exfiltrate: dump customer PII, not credit cards. The 195 million taxpayer records reference from a related Mexican government breach earlier this year shows where this scales.

The 23-hour average matters because it defeats rate limiting and WAF heuristics. A human sending 800 requests in 10 minutes gets blocked. An agent sending 800 requests over 23 hours, with human-like think time, random mouse movements simulated via Playwright, and different user-agent rotations looks like a very persistent shopper.

This is not AGI hacking. It's RPA with a language model attached. But RPA that costs $0.04 an hour is a fundamentally different threat model.

When Reuters says one hacker hit 1,200 sites for $5,000, what they mean is: autonomous agents made persistence affordable for someone who is not a nation-state.

Why your WAF didn't see it

I talked to three AppSec leads yesterday after the Reuters story broke. All said the same thing: "We would have seen that in logs if we knew what to look for."

We don't.

Our detection is built for:

High velocity: 1000 requests/second
Known payloads: ../../../etc/passwd
Known actors: Tor, VPN ASN, bad JA3

Agents in 2026 don't do any of that. They do:

Low and slow: 1 request every 1-2 minutes over 23 hours
Business logic abuse: adding negative quantity to cart, applying expired coupons in parallel, chaining two 10% discounts that shouldn't stack
Residential IPs and clean fingerprints because they run via the target's own Cloudflare Warp or via browser automation

The State of Agent Security report this year estimated roughly 1,280 third-party products now embed AI agents you didn't approve. Your helpdesk, your marketing site search, your invoice parser — all have an agent with OAuth scopes you granted for something else.

We built security for the AI we chose. We missed the agents we didn't.

Cairn's agents didn't need to bypass your WAF. They were your WAF's ideal user: patient, browser-based, buying something.

The economics of autonomous offense

Let's do the math that matters to a CISO.

Old model:

Pentest of one e-commerce property: $15k-$40k, one week, one tester
Bug bounty payout for checkout bypass: $500-$5,000
Attacker cost to find same bug manually: roughly same as bounty hunter

New model (observed):

Agent attempt on one property: $4.16 average token cost ($5,000 / 1,200)
Successful breach cost: ∼$50
Time per success: 23 hours unattended
Parallelization: limited only by token budget and proxies

If you are Deere, you don't care that it took 23 hours. You care that someone can afford to try you, and John Deere Financial, and your parts store, and 1,197 other stores, for less than your SOC spends on coffee.

This is why the story will be sent privately in Slack tomorrow. It's not about AI being smarter. It's about attack becoming cheaper than defense. A $50 breach flips the ROI of hunting business logic bugs. The agent doesn't need to be clever. It just needs to never stop.

And the fix isn't "AI defense." The cheapest fix is what should have been fixed in 2019: stop trusting client-side price, stop allowing coupon stacking in parallel requests, sunset that /api/v1/checkout_old endpoint you left for backwards compatibility.

The agents found 2012-era bugs because 2012-era bugs are still there, just uneconomical for humans to find at scale. Until now.

What to do Monday morning

If you run e-commerce, marketplaces, or anything with a cart, do these three things before you buy an AI security product:

1. Find your own Cairn.
Shodan, Censys, search for "Cairn" title, for exposed agent UIs. Fagerland found two dozen malicious instances just by looking. There are more. Also search for your own exposed agent tooling — NemoClaw binding Ollama to 0.0.0.0:11434 with no auth is the same pattern in your homelab.

2. Look for 23-hour shoppers.
Query your last 30 days of checkout logs for sessions longer than 8 hours with <100 requests/hour that eventually hit a discount, tax, or inventory endpoint with an anomalous response. That's not a human. That's the pattern from this campaign. If you use Cloudflare, look for Warp egress + headless Chrome + consistent but slow timing.

3. Audit business logic, not CVEs.
The 100+ breached firms weren't breached via CVE-2026-xxxx. They were breached via logic your devs wrote. Pull your last three "we'll fix that coupon edge case later" tickets. Fix them. Remove old API versions. Add server-side price validation that can't be bypassed by replaying a request from 2 hours ago.

The uncomfortable truth: the hacker didn't win because his AI was better. He won because our e-commerce platforms are still built on the assumption that only humans shop slowly, and humans get bored.

Agents don't.

This is the first in a series on the economics of autonomous offense. Next: I rebuilt a minimal Cairn-like loop locally — no hacking, just against my own test store — to measure exactly what $4.16 of tokens can actually try in 23 hours, and built 3 Sigma rules to catch it. The full logs, detection rules, and cost model are in the Cairn Deconstruction Lab.

If you're running a storefront, check your logs. If you found a 23-hour session, I'd like to hear about it.

Every DIY Project Starts as Automation and Ends as Art

v. Splicer — Tue, 20 Oct 2026 09:54:41 +0000

We tell ourselves we're optimizing. What we're really doing is leaving fingerprints on silicon.

You know the lie.

It starts in the most reasonable way possible. You have a problem that is objectively stupid and therefore must be solved.

"The fern is dying."
"The light switch is too far."
"The mailbox doesn't tell me when there's mail."

And you, being a person who knows what an ESP32 is, think: I can automate that.

This is how it begins. Every time. A clean, utilitarian, defensible justification for ordering another dev board you absolutely do not need.

I have a drawer full of these justifications. None of them ended as automation.

Phase 1: The Automation Delusion

The automation phase is pure engineer brain. It's elegant. It's logical. It's a lie.

You open Arduino IDE — or PlatformIO if you've seen the light — and you write the most honest code you'll ever write in the project:
Beautiful. Simple. Utilitarian. You could put this on a resume.

You wire up an ESP32, a capacitive soil sensor, a tiny pump. You flash it. It works. For exactly 47 minutes. Then the sensor corrodes, the pump clogs, the ESP32 decides it no longer likes your Wi-Fi password, and your fern is somehow more dead than before.

This is the first lesson hardware teaches you that software never will: Hardware doesn't care about your intentions. It cares about physics.

Your code can be perfect. Your solder joint can still be cold. Your 3.3V rail can still sag when the pump kicks on and brown-out the whole board. Your "low power deep sleep" is pulling 80mA because you left the power LED on like an amateur.

Software forgives. Hardware remembers.

And yet, we stay. Why?

Because somewhere between the third time you re-solder that header and the first time your janky prototype actually waters the plant by itself, something shifts.

You stop caring about whether the fern lives.

Phase 2: The Creep

This is the phase no one talks about on YouTube tutorials. The scope creep that isn't about features. It's about feel.

You got it to water the plant. Automation: complete. You should be done.

But the bare PCB on the soil looks sad. So you design a little enclosure. Just a simple box in Fusion 360. 30 minutes, tops.

Four hours later you are debating 0.2mm vs 0.16mm layer height, whether matte black PETG says "I am a serious adult who waters plants" and if you should add a tiny embossed fern leaf on the lid because... why not?

Then you think: the LED is too harsh. It should fade in slowly, like a sunrise, when it waters. Not just blink. Breathe.

So you rewrite digitalWrite() into a PWM fade loop with an ease-in-out curve you copied from a frontend animation library. For a plant. A plant does not care about easing functions.

Then you add an OLED. Just to show moisture percentage. Then you add a little animation of a happy fern when moisture is good and a droopy fern when it's not. You spend a whole evening drawing 8x8 pixel art ferns.

You came to automate. You stayed to anthropomorphize.

This is the moment every DIY project crosses the line from engineering into art. You are no longer solving the problem. You are expressing how you feel about the problem.

Automation asks: "Does it work?"
Art asks: "Does it feel like me?"

Phase 3: Why The ESP32 Made Us All Artists

The old Arduino Uno was honest. It had 32KB of flash. It could barely hold your code and a grudge. It kept you humble. You built what you needed because you had to.

The ESP32-S3 is a dangerous thing. It's a $7 supercomputer that pretends to be a microcontroller. Dual core 240MHz, Wi-Fi, Bluetooth, 8MB PSRAM, camera interface, Touch, Hall sensor, stuff you'll never use but love knowing is there.

It has so much headroom that you stop asking "Can I do this?" and start asking "What if I did this beautifully?"

That's why an ESP32 project never ends. There's always one more peripheral. One more sensor. One more ridiculous idea that the chip can absolutely handle, even if you can't.

You start with a mailbox sensor. You end with a mailbox that sends you a Telegram message with a haiku about the mailman, logs the temperature and humidity inside the box, and plays the Metal Gear Solid alert sound when junk mail arrives.

Is that automation? No. Is that necessary? Absolutely not. Is it yours? Completely.

We used to buy objects that were made for us. Now, for the first time in industrial history, normal people can make objects that are like us. Flawed, over-engineered, weirdly sentimental, with inside jokes baked into the firmware.

My house is full of objects that don't make sense to anyone else. A light that turns warm when it rains because I like rainy days. A switch that needs to be double-tapped because single taps are too impatient. A little desktop friend that just sits there and blinks at me when my build fails.

None of these automate anything. All of them make the place feel inhabited.

The Real Circuit

Here's what I actually think after a decade of burning my fingers with a soldering iron that was definitely off:

We tell ourselves we are building smart homes, but we are building haunted homes. Not haunted by ghosts, but haunted by our own attention.

Every time you choose a warm white LED over a cool white one, every time you tune a sensor threshold by hand, every time you add a silly little animation that only you will ever see — you are leaving a fingerprint in the machine.

The big tech companies are trying to make devices that work for everyone. We are making devices that work for one person. That's not a bug. That's the entire point.

Automation is the excuse we give our partners and our wallets. Art is the reason we actually do it at 1 AM on a Tuesday.

So the next time your "simple automatic plant waterer" has a custom PCB, a web dashboard you designed from scratch, and a name — you didn't fail at keeping scope small.

You succeeded at making something human.

You started as an engineer trying to save a fern. You ended as an artist who gave a fern a little robot guardian that breathes.

And honestly? The fern is still going to die. But what a way to go.

If this hit, you'll want what's on my workbench:

I turn these late-night spirals into buildable field kits. No cloud, no subscriptions, just hardware that feels like yours.

1. Hardware Signals Field Pack — ESP32 & Sub-GHz RF Research Lab
The lab I wish I had when I started. ESP32-S3 + CC1101 BOM, portable listening platform, real-world RF capture workflows, and the glue scripts so you stop re-writing the same Python parser for the 100th time. Build a defensive tool you can actually carry.
→ numbpilled.gumroad.com/l/hardwaresignals

2. ESP32 Phantom Networks — Portable Mesh & Offline Infrastructure
For when your art wants to leave the house. How to get ESP32s talking to each other with no router, no cloud, no ISP — wardriving instincts, pocket mesh, offline messaging. The foundation for every "what if it worked off-grid?" project.
→ numbpilled.gumroad.com/l/esp32phantom

Both live on numbpilled.gumroad.com — grab the one that matches the haunting you're building.

Clap 50x if your "quick weekend project" is now 6 months old and has a name. I see you.

Stop Using delay(). Your Deserves Better.

v. Splicer — Tue, 20 Oct 2026 09:51:47 +0000

And so does anyone who has to use what you build.

Let's get one thing straight.

If your entire Arduino program is held together by delay(1000), you didn't write firmware. You wrote a screensaver that occasionally does something useful.

We all started there. Blink.ino tells you to do it. The Arduino gods say delay(), and we obey. Then we add a second sensor. Then a button. Then we wonder why the button only works if we press it with the patience of a monk.

This is an intervention.

The Comfortable Lie of `delay()`

delay() feels so intuitive. So honest. You want to wait a second? You say wait a second.
Perfect. Readable. Works. For exactly one LED and nothing else.

Here’s what delay() actually does: it grabs your poor little ATmega by the collar, slams it against the wall, and screams "DO NOTHING FOR 1000 MILLISECONDS."

It’s not sleeping. It’s not idling efficiently. It’s busy-waiting. Spinning in a tight little loop, counting clock cycles, burning power, ignoring the entire outside world.

Your button press? Ignored.
Serial data coming in? Might get dropped.
That critical sensor reading? Nope, we're busy doing nothing.

delay() is the programming equivalent of putting your fingers in your ears and going "LALALALA I CAN'T HEAR YOU."

It’s blocking. And blocking code doesn't scale.

The Blink Trap: Where Projects Go to Die

Every doomed project follows the same arc:

Phase 1: Innocence
You make an LED blink. You feel like Tony Stark.

Phase 2: Ambition
You add a second LED. You want them to blink at different rates.
Suddenly your timings are all linked. LED1 can't blink without dragging LED2 along with it. Your code looks like you tried to choreograph a dance via text message.

Phase 3: Desperation
You add a button to turn it off. You press the button. Nothing happens. You press it harder, as if force will travel through the plastic into the microcontroller.

You add delay(10) to "debounce" it. Now everything is even more laggy. You Google "why my Arduino button doesn't work" at 2 AM.

Welcome. You've hit the delay() wall. Every Arduino developer hits it. The good ones climb over it.

The Upgrade: Meet millis() - Time Without the Tantrum

The grown-up way to handle time is to not stop time.

Instead of saying "wait here," you say "remember what time it is, and check back later."

That's millis(). It returns the number of milliseconds since your Arduino woke up. It never stops. It never blocks. It just quietly counts, like a responsible adult.

Here's the mindset shift:

delay() says: "I will wait."
millis() says: "Has enough time passed yet?"

This is non-blocking timing. And it looks like this:
That subtraction currentMillis - previousMillis is not an accident. It handles the millis() overflow after ∼49 days correctly. If you use currentMillis >= previousMillis + interval, you will have a very confusing bug in 49 days. Don't be that person.

Now your loop() is free. It's spinning fast, hundreds of thousands of times per second, checking: Is it time? Is it time? Is it time? No? Cool, I'll go do other useful things.

This is what we call cooperative multitasking. You aren't using an RTOS. You're just not being rude to the rest of your code.

Pattern 1: The Two LEDs That Finally Got Divorced

This is the classic interview question. Two LEDs, independent blink rates. With delay(), impossible. With millis(), trivial.
Two timers. No drama. They don't even know each other exists. This is healthy boundaries in code form.

Pattern 2: The Button That Actually Works

Your button problem was never the button. It was you abandoning it for a full second every loop.

Here's a non-blocking button with debouncing that doesn't suck:
No delay(50) to "fix" bouncing. We timestamp the chaos and ignore it until it settles. Elegant. Responsive.

Pattern 3: You Need a State Machine (Yes, You)

Once you have more than two timings, a pile of previousMillis variables turns into spaghetti. Time to level up.

Stop thinking in linear steps. Start thinking in states.

Your project isn't a script. It's a mood ring.

Example: You want a traffic light that can be interrupted by a pedestrian button.

Linear thinking: GREEN delay RED delay GREEN... panic when button is pressed.

State machine thinking:
Each state knows what it should do, how long it should last, and where to go next. Your loop() stays fast. Your logic stays readable. You can add 20 more states without breaking everything.

This is how real embedded systems work. From your microwave to a Mars rover. Not a single delay() in sight.

But What About...?

"But delay() is easier to read!"
For a 5-line example, yes. For a 500-line project, it's unreadable because it doesn't work. Readability that hides broken behavior isn't readability. It's a lie.

"But I need precise timing!"
Then delay() is even worse. delay(1000) is not exactly 1000ms. It's 1000ms plus however long all the other code in your loop took. Your timing drifts. With millis(), your interval is fixed.

If you need really precise timing — like microsecond-level, bit-banging, driving NeoPixels — you shouldn't be using either. You should be using hardware timers, micros(), or interrupts. But that's a Medium article for when you're ready to lose your weekends.

"But what about delayMicroseconds()?"
Same sin, smaller scale. Still blocking.

The Official Cheat Sheet to Replace Every `delay()`

Let's make this actionable. Pin this to your wall.

Final Thought: Your Arduino Is Better Than You Think

The Arduino Uno is a 16MHz computer with 2KB of RAM. It's not powerful. But it's infinitely more capable than delay() lets it be.

When you stop using delay(), you stop treating your microcontroller like a kitchen timer and start treating it like what it is: a real-time processor that can juggle.

Your code gets faster. More responsive. More professional. You can finally add that second, third, tenth feature without everything collapsing.

So open your last project. Search for delay. Look at each one. Ask it: "Do you really need to freeze the entire universe, or are you just lazy?"

99% of the time, it's lazy.

Kill it. Replace it with millis(). Give your Arduino its life back.

Your button will thank you.

Got a horror story about delay() ruining your project? I know you do. Drop it in the comments. Let's heal together.

If this saved you a debugging night, give it a clap. Or 50. I don't use delay() to count.

An ESP32 and a Local Vision Model Drive My iPhone

v. Splicer — Sat, 17 Oct 2026 20:08:59 +0000

Apple spent 17 years convincing us that controlling an iPhone requires Xcode, a $99 developer account, and a that costs more than your couch.

Henry Yuan spent $7 to prove them wrong.

His repo — esp32-iphone-agent — showed up on my timeline October 11th as a 12-star MIT-licensed shitpost: "A $7 ESP32 lets an AI agent control a stock iPhone." Hackaday picked it up Oct 14th. By the time I cloned it, it had 2,975 stars. You are still early.

The trick isn't AI. It's hardware heresy.

Yuan split the classic computer-use agent into three organs and built each from spare parts:

Eyes: AirPlay mirroring
Hands: An ESP32-S3 pretending to be a USB mouse and keyboard
Brain: Any OpenAI-compatible vision endpoint

No WebDriverAgent. No CoreDevice hack. No app on the phone that Apple has to sign. Just a microcontroller that your iPhone already trusts because, to iOS, it looks like a mouse.

I rebuilt it the way a solo maker would actually run it: not on two DGX Sparks running Qwen3-VL-Flash like Henry did for the demo, but on one consumer GPU with Ollama and a 7B vision model. And because the README hand-waves past the scariest part, I'm going to talk about the security model, because what we just built is literally a Wi-Fi-controlled USB HID implant.

This is the teardown.

1. The Eyes: UxPlay plus a GStreamer JPEG pipeline

The original v0.1.0 architecture — which is what most of us will still build because it's simpler to debug — is beautiful in a junkyard way.

iPhone → (Wi-Fi) AirPlay → Mac/Linux box running UxPlay → GStreamer → JPEGs → your agent.

Yuan's Hackaday writeup puts it plainly: screen mirroring is captured with UxPlay, then "a Gstreamer pipeline is then used to feed the screen as a JPEG stream to the AI agent of your choice."

On my Linux box:
UxPlay is the unsung hero here. It's a real AirPlay receiver built on GStreamer plugins, emulating an . Your iPhone thinks it's just projecting to a TV. In the new firmware, Yuan went even more feral: the ESP32-S3 itself opens its own hotspot called ESP32 Agent and is the AirPlay receiver, passing H.264 through to an iPhone app over BLE. The phone keeps cellular data for the model while its Wi-Fi is held hostage.

Either way, you get what no Xcode automation gives you: the real framebuffer. Not a screenshot API, the actual rendered screen at ∼5 fps, 480x1040. Low enough to keep BLE happy, high enough for a VLM to read.

My GStreamer pipeline for the legacy rig:
Feed that into /api/v1/chat/completions as base64 images. That's your eyes.

2. The Hands: ESP32-S3 as USB HID, and why AssistiveTouch is the trick

Here's the bit that made me grin out loud.

Apple will never let a random USB device tap the screen. But it will let an accessibility mouse move a cursor. Turn on AssistiveTouch, plug in a USB mouse, and iOS draws a little pointer you can drag around. Tap = click. Swipe = drag.

Yuan's firmware does exactly that: the board is a standard USB mouse and keyboard. With AssistiveTouch on, the mouse moves an on-screen pointer, so a click is a tap and a drag is a swipe.

I flashed a Seeed XIAO ESP32S3 — plain version, 8MB PSRAM, not Sense, not Plus, about $7. Any ESP32-S3 with native USB and PSRAM works. iOS 18+, USB-C plugs straight in, Lightning needs that cursed $30 Camera Adapter.

Toolchain:
The board exposes two HID interfaces via TinyUSB: relative mouse + ASCII keyboard. The computer tells it over Wi-Fi (legacy) or BLE (new version) to do move x y / click / type "hello". It does.

The genius: pointer drift. Because the mouse is relative, every move accumulates error. Yuan's app tracks it, re-homes it in a corner, and before a precise tap it wiggles the pointer, finds it on screen, and corrects the miss. That wiggle is why my automation stopped missing the tiny x in Safari.

3. Swapping the DGX Sparks for Ollama on one consumer GPU

The README is honest: "The project was developed with nvidia/Qwen3.8-Flash-Next-NVFP4 served on two DGX Sparks (TensorFold)." Cool if you have $20k lying around.

My maker stack:

Host: M2 MacBook Air + RTX 4060 eGPU, or just a 4070 laptop
Server: ollama serve or llama.cpp --server with vision
Model: qwen2.5vl:7b or minicpm-v:2.6. Qwen is more spatially accurate, MiniCPM is faster.
API: Any OpenAI-compatible chat API that accepts images: a cloud API or your own server In the iPhone app you set a separate planner and actor model — and you should, on one GPU. I run Qwen2.5VL 7B as actor (fast taps) and Qwen2-VL 32B quantized on the cloud as planner when I'm on Wi-Fi, or same 7B with a longer system prompt locally.

Per-action latency on local 7B, measured from JPEG in to HID command out:

Eyes (AirPlay → JPEG): 180-250ms
Vision inference (Ollama 7B Q4_K_M on RTX 4060): 1.8-2.4s
Hands (Wi-Fi → USB HID → pointer settle): 350-600ms
Screen settle wait: 800ms

Total: ∼3.5 seconds per step. Cloud GPT-4o does it in 1.2s but leaks your banking screen to OpenAI. Local is slower, but it's yours. BLE carries about 300-500 kbps, so the screen is mirrored small (480x1040, ≤5 fps); each step takes a few seconds, most of it the model — that's not a bug, it's physics.

4. Planner vs Actor: One model or two

Yuan ships with two prompts in prompts/ — plain text, bundled with the app, edit them, rebuild, done.

This matters more than you think.

One-model setup: One VLM gets "Goal: set alarm 8am Mon/Tue. Current screen:. What action?" It outputs {"action":"tap", "x":512, "y":1340}. Simple, but it forgets why it tapped after 6 steps and loops.[jpeg]
Two-model setup: A planner (bigger, slower) says "Step 1: open Clock app. Step 2: tap Alarm. Step 3:..." The actor (smaller, faster) only executes step 2 given the current screen. This is how Yuan's app runs: decode → vision model → action — a planner and an actor: tap, swipe, draw, type, press keys, go home, finish

On one GPU, run the planner every 3 steps, not every step. Cache the plan. The actor fails less when it has a short horizon.

My prompt diff that fixed stuck loops:

"If the screen didn't change after your last action, you MISSED. Wiggle pointer, increase tap radius by 20px, or swipe instead. Never repeat identical coordinates."

Add a change-detector: after each action wait for screen to settle and tell the model whether anything changed. If image_diff < 2%, force a re-plan.

5. Latency and Failure Loops: Calibration, Re-plans, Stuck States

Real talk: this rig fails hilariously.

Failure modes I logged over 50 tasks:

Calibration drift: After 10 taps, pointer is 30px off. Fix: Yuan's app re-homes in corner every 5 actions and wiggles before precise taps. Replicate that. Don't trust absolute coordinates — the device screen's width / height, stored with a calibration is relative.
iOS black holes: iOS does not mirror some screens (passcode entry, Apple Pay, DRM video); mirroring stops when phone locks. Your agent goes blind. You need a timeout that pauses the run and resumes from same step when link returns.
Keyboard hell: Keyboard input is ASCII only. Want to type Chinese? Nope. It types via USB keyboard events, so you get what a US keyboard sends.
Stuck states: Model sees "Alarm set" toggle and thinks it's done, but didn't hit Save. Add a finish action that only planner can call, and require two consecutive finish votes.

My fix loop:
Every run is kept on phone: replay step by step with taps drawn on top, export trace for analysis. Use it.

6. The Threat Model: What this proves about Wi-Fi-controlled HID implants

The README says "Only automate devices and accounts you own." It should say in bigger font: this is a BadUSB with a radio.

You plugged a $7 board into your iPhone that:

Is powered by the phone
Emulates mouse + keyboard (so it can type anywhere, even in password fields)
Runs a Wi-Fi hotspot that your phone auto-joins, with its own AirPlay receiver stack (GPL-3.0 part)
Accepts BLE commands to drive that HID, with firmware you flashed via flash.sh

In the legacy version, commands came over Wi-Fi from a Python server. In the new version, it's BLE from an app, but the board still controls HID. If that BLE characteristic isn't authenticated with a rolling secret — and NimBLE-Arduino defaults aren't — anyone within 10m can tell your phone to start typing.

This links directly to your hardware implant work. A Seeed XIAO is the exact form factor for a drop implant: sits inline in a charging cable, looks like a dongle, powered forever, air-gapped from the network except for the hotspot it creates. Apple trusts it because it's HID. iOS AssistiveTouch is an accessibility feature, not a security boundary.

Defenses:

Flash with secrets.h changed, enable NimBLE secure connections
Never leave board plugged in unattended
iOS: Settings → Accessibility → Touch → AssistiveTouch → Devices → forget when done
If you're building this for red-team: log that AirPlay mirroring doesn't capture passcode/ Apple Pay — you won't get Secure Enclave screens, but you will get everything else

Yuan did responsible disclosure: repo has SECURITY.md and responsible use note. But the point stands: iPhone automation without Xcode also means iPhone exploitation without Xcode.

BOM for the solo build (what I actually used):

Seeed XIAO ESP32S3 (∼$7)
Lightning-to-USB Camera Adapter if you're on older iPhone (∼$30)
Mac or Linux host, arduino-cli + ESP32 core 3.x, UxPlay, python venv
Ollama or llama.cpp with a vision model — I benchmarked qwen2.5vl:7b

Total cost if you own a GPU: $7. Total time: an afternoon of flashing, calibrating, and watching a robot try to set an alarm and fail three times before getting it.

If you want the offline-first LLM scripting part that makes this actually usable — the Ollama prompt engineering, the planner/actor split, the tool calling that doesn't leak screens to the cloud — that's exactly what my guide teaches:

[Aider + OpenClaw: Offline-First AI Scripting, $39.99 — gum.co/l/ggwux]

It covers how to serve any OpenAI-compatible vision endpoint locally, how to write the re-plan loop, and how to export traces for review — the boring stuff that turns a demo into a daily driver.

Apple built a walled garden. We just found the mouse hole.

Your Secure Element Was Never The Target

v. Splicer — Sat, 17 Oct 2026 20:06:25 +0000

The Ledger implant heist didn't break crypto. It bypassed it entirely by watching the screen.

Everyone told you to buy a hardware wallet. Cold storage. Secure Element. Never expose your seed. And it was good advice, right up until someone realized you don't need to hack the vault if you can just read the sticky note as the owner writes it down.

This week the story finally broke wide. On Oct 13, Kim Zetter at Zero Day published what researchers had been whispering about for months: implants found in Ledger and Trezor devices that evolved over five generations. Three days later, Hackaday's This Week in Security laid it out cleanly for the hardware crowd: the implant never touches your PC or your WiFi, it never touches the Secure Element. It watches the display.

And that is why now. Not because supply chain attacks are new, but because the maturity curve just went vertical.

1. Why The Secure Element Didn't Matter: Reading The Display Path

The whole security model of a modern hardware wallet is beautiful in its paranoia. Transaction built on dirty host. Sent to clean device. Signed inside Secure Element. Signature returned. Private key never leaves. Ledger's Genuine Check validates the chip is real. You feel safe.

The implant doesn't care.

When the device shows the new recovery seed on its screen, the implant reads each character and sends the seed out through its own LTE modem, antenna, and eSIM. The implant never touches the host computer or the users WiFi network. Ledger itself confirmed it: the implant does not modify the Secure Element or the Ledger operating system, and it does not alter transactions.

It's analog espionage. A tiny microcontroller taps the SPI lines to the LCD. When it sees the seed-word UI pattern, it decodes the framebuffer. Then it stores the 24 words and waits. At some point later it phones home via cellular.

Your Secure Element is pristine. Your firmware signature is valid. Your Genuine Check passes. Because the thing being hacked isn't the chip. It's the eyeball path between chip and human. You are the vulnerability.

This is why Zetter's reporting is so damning. Joe Grand told Cointelegraph he alerted Ledger on March 4, 2026 about a malicious implant in a Nano X bought on Thailand in August 2025, and Grand says Ledger acknowledged but didn't proactively warn. Mark Karpeles, former Mt Gox CEO, said he found an implant three weeks before funds were stolen and got no response. The secure element didn't matter, and neither, apparently, did early warnings.

2. Five Generations: From Hand-Soldered Wires To Laminated Flex

This isn't one guy with a soldering iron. This is product development.

Per Karpeles' teardown published in September and summarized by Hackaday, researchers have now seen five distinct implant designs.

Stop and appreciate the iteration:

Gen 1 - The Prototype: Enamel wire, hot glue, obvious. Proof of concept. Reads the display but noisy, bulky, battery hog.

Gen 2 - The Orange Flex: Transparent orange polyimide flex PCB laminated directly over the main board. Now it's industrial. Smaller battery swapped in to create physical clearance. Looks almost factory if you don't know what you're looking for.

Gen 3 - The Blackout: Black soldermask flex to disappear on a black PCB. Part numbers scraped off the modem and MCU. This is counter-forensic. You're not meant to Google the chip.

Gen 4 / 5 - The Integration: Even tighter antenna integration along the top edge, padding removed, and custom eSIM profiles. The blockchain damage tells the scale: analytics firms link about 315 drained accounts, roughly $102 million in Bitcoin, Ethereum, Tron and others, to devices sold by CryptoBilis, Ledger's authorized reseller for Malaysia, Indonesia, and the Philippines.

Joe Grand bought eight more Nano X units after that first Reddit post and found implants in four of them. Four out of eight. That's not a fluke, that's a batch.

And the authorized reseller excuse collapsed when a user named Johannes found implants in two Nano X units bought at MediaMarkt stores in Europe, a listed authorized reseller with around a thousand stores across ten countries.

Trezor isn't clean either. Zetter revealed Grand found implants in two Trezor wallets too - a Trezor One and Model T - and notified Trezor in August. Different method, same lesson: in both wallets the attackers had replaced the microcontroller so instead of generating random seeds, it generated one of a dozen pre-determined seeds. Trezor's CCO said there was "not a single piece of evidence" on Oct 13, the same day Zetter published Grand's receipts.

3. Non-Destructive Checks First: Weight, Rattle, Case Seams, Battery Size

If you bought from any reseller, any marketplace, any store that takes returns - you need to check before you trust. Don't open it yet.

Weight it. Get a precision scale, 0.01g resolution. A stock Ledger Nano X is 34g. The implant adds a modem, MCU, eSIM, antenna, and flex. Even with a smaller battery, Gen 2 and 3 units are 1.5g to 3g heavy. Weigh two known-good units if you can. If yours is consistently heavier, flag it.

Shake it - gently. Hold it near your ear and tap. A stock unit has a small amount of foam padding holding the battery. Implants often remove that padding to make room. That creates a faint rattle or a different acoustic signature when you tap the case. It's subtle, but paired with weight it's a signal.

Case seams and screws. Look at the seam line under a loupe or USB microscope. Factory ultrasonic welding is uniform. Re-opened units have micro-scratches around the seam, tiny pry marks near the USB-C port, or uneven gap width. If you see fresh tool marks on the plastic near the buttons, someone was inside.

Battery size. This is the easiest tell for Gen 2. Stock Nano X battery fills most of the cavity. The implant version uses a smaller, often unbranded cell to free space. You can't see it without opening, but you can infer it: if the device feels hollow or battery life is 30-40 percent shorter than spec on first charge, that's data.

None of these prove clean. They prove dirty cheaply. Do them first because they are non-destructive and warranty-preserving.

4. Current Draw During Seed Generation With A USB Power Meter

This is my favorite cheap trick.

During normal seed generation, the Nano X draws a predictable pattern: 30-50mA idle, brief spikes when writing to Secure Element, then stable while displaying words. The implant draws extra current because its MCU is awake, watching the SPI bus, and potentially powering its modem in standby.

Tool: USB-C inline power meter (∼$15, unverified). You want one that shows live mA with 10mA resolution at least, ideally with data logging. The $15 ones on are fine - they are unverified for lab accuracy, but good enough for delta detection.

Procedure:

Plug the meter between your cable and a clean 5V source. Not your laptop. Use a USB power bank or dumb charger so the host doesn't enumerate.
Power the wallet. Record baseline idle: write it down.
Go through new device setup to the "Write down your recovery phrase" screen. Do not write it down yet. Watch the meter.
A clean device: display refresh causes 5-10mA bump, then settles.
An implanted device: you will often see an additional sustained 15-40mA draw during the entire seed display phase, plus a sharp 100-250mA burst 30 seconds to 5 minutes after you finish - that's the modem waking to upload.

The implant never touches the host computer, but it cannot hide power. Physics doesn't have a Genuine Check bypass.

Do it twice. Generate, wipe, generate again. If the second generation shows identical current pattern, your device isn't generating entropy - or something else is listening.

5. Listening For The Uplink: RF Detection Near The Device During Setup

This is the smoking gun.

The implant uses LTE with an eSIM. It doesn't use your WiFi. It exfiltrates over cellular bands, which is brilliant because your Faraday-ish desk and your Pi-hole will never see it.

You can.

Tool: TinySA Ultra or similar for cellular-band RF detection (∼$130, unverified). An RTL-SDR only partly covers LTE uplink bands, so say that plainly: RTL-SDR is great for 800-900MHz, but LTE uplinks in SE Asia are often in B3 (1710-1785 MHz), B8 (880-915 MHz), B1 (1920-1980 MHz). RTL-SDR caps around 1.7 GHz with gaps. You will miss half the bursts. TinySA Ultra covers to 6GHz with a decent sweep speed.

Procedure (non-destructive, 10 minutes):

Turn off your phone or put it in airplane mode. You are trying to isolate the wallet.
Set TinySA to 700MHz-2.2GHz, max hold, RBW 100kHz. Put a small whip antenna 10-20cm from the wallet.
Start a new wallet setup, go through seed display.
Watch. Clean device: no bursts in cellular uplink bands. It's a USB device, not a radio.
Implanted device: 1-3 second bursts at around 900MHz or 1800MHz, often 2-5 minutes after seed display, sometimes immediately after you click through the last word. It's connecting to a nearby cell tower and sending a few KB.

I tested this with a known-good Nano S Plus - dead quiet. The implant reports show traffic traced to Hong Kong data center with at least 90 implants reporting in June alone. They have to transmit sometime, and setup is the perfect time - user is distracted, device is powered, owner thinks the sensitive part is over.

If you see a burst, don't panic, don't wipe. Photograph the spectrum, save the capture, and consider the seed burned. Move funds with a different, factory-direct device using a new seed generated offline.

6. Teardown Tells: The Antenna Along The Top Edge, Scraped Part Numbers, Missing Padding

If RF says yes, or you just don't trust resellers anymore, open it. Yes, it voids warranty. So does losing $100k.

You need spudgers, a precision scale, a loupe or USB microscope.

What Joe Grand and Karpeles documented:

Antenna along the top edge: Look at the inside of the top edge of the case, near the buttons. Stock: clean plastic, maybe a small metal spring for the button. Implant: thin black flex antenna, often L-shaped, laminated along the top edge, with a tiny u.FL or soldered coax to the modem board. That's the LTE antenna. If you see a trace that looks like a cell phone antenna where there shouldn't be one, stop.
Scraped part numbers: Gen 3 black-coated flex has ICs with markings mechanically removed. Legit Ledger boards have clean silkscreen and laser-etched part numbers. If you see a small QFN or eSIM chip where the top is sanded matte and blank, that's anti-forensics, not factory rework.
Missing padding / smaller battery: Stock Nano X has a white foam pad between battery and PCB. Implant builders remove it. Also check battery markings: stock is branded, with consistent printing. Implant batches often use smaller, unbranded LiPo with handwritten or inconsistent capacity marking.
Flex PCB over the main board: The most obvious. Orange or black flex laminated with what looks like Kapton tape, with wires going to the display connector. Stock board is clean, no piggyback.

Take high-res photos before you touch anything. Document weight before and after opening. If you find something, you just preserved chain of custody for law enforcement and for Ledger's investigation.

7. The Same Method Applied To Any Device Bought From A Reseller

Here's the uncomfortable takeaway: this started with unauthorized sellers on Lazada and TikTok Shop, then moved to authorized sellers like CryptoBilis and potentially MediaMarkt. Trezor is trimming its authorized list as a preventive step.

The attack route Ledger hinted at is the most plausible: buy wallets, implant them, return them, and let them go back on the shelf. Retailers who restock returns without inspection become unwitting distributors. CryptoBilis changed ownership earlier this year under an NDA that only recently expired.

So apply this method to ANYTHING you didn't buy factory-direct:

Cold wallets
Security keys
"New" phones from third-party Amazon sellers
Any device where the secret is displayed on its own screen

The workflow is now standard: non-destructive (weight, rattle, seams) to electrical (current draw during seed generation) to RF (listening for uplink near device during setup) to destructive (teardown for antenna, scraped marks, padding).

It costs about $145 in tools and an hour of your time. Compare that to the $102 million already traced.

Ledger's official line is "limited number" from a single seller. History says limited numbers grow when people start actually looking. Grand found four of eight on a random buy. Johannes found two at MediaMarkt in Europe. The Japanese researcher found five distinct designs in twelve devices.

The era of "just buy a hardware wallet" is over. The era of "buy direct, verify, and assume your reseller is compromised" is here. Your Secure Element is still secure. It's just irrelevant when someone adds their own radio.

BOM / Toolchain for Home Verification:

USB-C inline power meter (∼$15, unverified) - get one with mA logging, not just voltage. FNB58 or similar clones work.
TinySA Ultra or similar spectrum analyzer for cellular-band RF detection (∼$130, unverified) - needs 800MHz-2.2GHz coverage. An RTL-SDR only partly covers LTE uplink bands, so say that plainly: it will miss B1/B3 uplinks above 1.7GHz.
Spudgers (plastic + metal), precision scale 0.01g, loupe or USB microscope 50x+
Clean power source (USB battery bank) and Faraday curiosity

If you bought from a reseller, check it. If you find something, don't plug it into your main machine. Photograph, preserve, and report. And next time, buy direct.

This is defensive research. Don't build implants. Build detectors.