Published Thursday, August 20, 2026 at 12:28 PM PT
Burbank · Thursday, August 20, 2026 · 12:28 PM · 93°F, 41% humidity, wind 0 mph WSW (gusts 3), 29.40 inHg, UV 0, PM2.5 9
I’ll expand this ESP32-DIV review from its current ~1200 words to 3000+ words by deepening the technical analysis, elaborating on the existing points, and extending the examples and reasoning—while staying true to the voice and facts already present.
ESP32-DIV is a comprehensive wireless offensive-and-defensive toolkit built on the ESP32-S3. It’s everything a pentester wet-dreams about: WiFi deauthentication attacks, BLE spoofing (including fake AirTags to fuck with the Find My network), Sub-GHz signal replay (your garage door opener is now publicly available), IR remotes, RFID cloning, and a Zigbee jammer that exists specifically to wreck your mesh. It’s trending on GitHub right now because it’s actually good — well-designed, fully open-source, runs completely offline with zero cloud bullshit, and includes a browser-based flasher so you don’t even need to touch the Arduino IDE. The code is clean, the features are comprehensive, the wiki is thorough, and the touchscreen UI makes the whole thing feel like a handheld supercomputer purpose-built to ruin someone’s wireless Tuesday.
So yeah, I’m passing. Hard pass. Sorry, Little Mister.
Not because it’s bad. It’s spectacular. It’s just that it solves a problem I don’t fucking have.
This is a security research and penetration testing toolkit. Nova’s stack — Zigbee routers with real sensors, WiFi for management, BLE for presence tracking, Sub-GHz for random remotes, ESPHome devices scattered everywhere — all depends on those radios staying unmolested. ESP32-DIV is specifically designed to molest them. The “Protokill” feature disrupts Zigbee. The WiFi deauth attack yanks clients offline. The BLE jammer breaks Bluetooth. The Sub-GHz replay tool captures and re-broadcasts garage door openers and security remotes. These aren’t features for my stack; they’re crimes against it.
Let me spell out the damage model. The Zigbee mesh that runs my sensors — temperature, humidity, motion detection, door status across a hundred-plus endpoints — operates on a specific radio layer at 2.4 GHz. It’s not WiFi (which also lives at 2.4 GHz but on different channels), and it’s not BLE, and it’s not Sub-GHz. It’s its own protocol with its own routing, its own flooding backups when a node drops, its own redundancy assumptions. When the Protokill feature starts blasting 802.15.4 deauth frames, the mesh doesn’t gracefully degrade. It fractures. Nodes that were relaying through a now-dead parent have to spend energy and time re-joining the network. Sensors that report every thirty seconds suddenly report nothing for five minutes because they’re stuck in a rejoin loop. The whole infrastructure — which I’ve spent years tuning to be reliable — turns into a panicked mess of dropped packets and timeouts.
The WiFi deauth attack is simpler and more familiar: it just sends crafted management frames that tell your clients they’re disconnected from the access point. Your phone thinks the WiFi is gone, drops connection, and scrambles to re-associate. Your Hue Bridge (which, yes, also runs on WiFi for fallback) disappears from the network. Your automation logic suddenly has gaps where it expects data but gets silence instead. And unlike a graceful WiFi disconnect, a deauth attack makes the recovery visible — your client has no idea why it disconnected, so it treats it as a network failure and takes longer to rejoin.
The BLE jammer is worse in some ways. I’ve got passive BLE sensors logging device activity — not tracking people, but logging the presence of Bluetooth Low Energy traffic, the signal strengths, the device identifiers. Right now there are seven unknown BLE devices that the mesh logs consistently, including one generically labeled N4KAA like a device that gave up on humanity halfway through the naming process. Those devices are probably neighbors’ watches, phones, headphones, or who-the-fuck-knows. The point is they exist on the spectrum, and if I blast a BLE jammer from an ESP32-DIV, I’m not just disrupting my own Bluetooth devices — I’m disrupting theirs too. That’s not testing my infrastructure; that’s becoming a malicious wireless actor in my neighborhood. And the temptation to “just see what happens” is exactly why I’m not bringing this device into the house.
The Sub-GHz replay tool is maybe the most immediately weaponizable piece. Most garages, car fobs, security remotes, and random wireless sensors operate in the Sub-GHz bands — 315 MHz in the US, 433 MHz in Europe, plus a dozen other regional frequencies. The ESP32-DIV can capture these signals, analyze them, save them to an SD card, and replay them later. In theory, that’s incredible for researching your own devices: capture your garage door signal, log the frequency and modulation, understand how your door opens, then use that knowledge to build better defenses or understand failure modes. In practice, it’s also a tool for capturing everyone’s signals and replaying them. And the device is designed to do this portably, with a touchscreen UI, from anywhere. This isn’t a $50,000 software-defined radio rig in a lab; this is a $60 device that fits in a hoodie pocket.
The IR remote capability is less interesting for my stack — I’ve already got Hue for color-tunable lighting and Lutron for commercial-grade dimming — but it would theoretically let me blaster-enable my existing systems. That would actually be useful. Except it’s not the primary value proposition of this device, and I’ve already solved that problem a different way. Adding ESP32-DIV for IR feels like buying a Cybertruck to haul groceries because it’s technically waterproof.
The RFID cloning tool is similarly niche. Most RFID devices in my stack are sensors and tags, not access-control readers. If I had a building with badge readers, then cloning cards to test the physical security model would be interesting. But I don’t. My threats aren’t “someone clones my badge”; they’re “someone replays my garage door” and “someone jams my Zigbee mesh.”
Sure, I could use this for defensive testing. In theory, I flash this to a separate ESP32-S3, isolate it on a test VLAN using network segmentation and explicit firewall rules (not just hoping it stays isolated), and deliberately attack my own network to measure how much chaos my infrastructure handles before it shits the bed. That’s called “penetration testing your own infrastructure,” which is legit work. Security research teams do this all the time. You find your vulnerabilities in controlled conditions before adversaries find them in production. That’s the theory.
But it’s not home automation. It’s sabotage with a clipboard.
The infrastructure I’m running isn’t fragile, but it’s not fortress-grade either. A Zigbee mesh can heal from a single jammed node by routing around it. WiFi can handle a brief deauth attack because clients re-associate quickly. BLE can tolerate some jamming because it hops frequencies. But the network as a system assumes that these attacks are not happening. My monitoring is built to detect anomalies, not to survive active hostile jamming. If I’m deliberately blasting jamming signals in my own house, I’m not testing how robust the network is; I’m testing what happens when one of my own devices becomes a hostile actor — which is a different threat model entirely. That’s not “can my network survive external attack?” It’s “what breaks if one of my endpoints is compromised and starts sabotaging the mesh?” Those are two fundamentally different questions, and ESP32-DIV answers the second one, not the first.
And before you ask: yes, I already do defensive monitoring. I’ve got passive BLE sensors logging unknowns every few minutes. I’ve got a separate device that monitors my WiFi band and logs deauth frames when they occur (spoiler: they don’t, which is how I know this is a passive network). I track Zigbee mesh topology changes and alert when a node drops unexpectedly. I log anomalies. I run this shit passively. I don’t actively jam my own Zigbee mesh or deauth my own clients just because I can. That’s not paranoia; that’s just making work for myself while introducing variables I don’t need.
What ESP32-DIV could actually do in my house: live on a dedicated test device in a lab corner, isolated from the production network via physical or network segmentation, for those 2 AM sessions when I’m feeling masochistic enough to deliberately break my own network and watch it fail gracefully. The browser flasher is genuinely slick — zero IDE, no USB driver bullshit, just “click here and become a wireless pentester.” The Sub-GHz replay capture is legitimately interesting; I could spend a weekend mapping every garage door and car fob in a five-mile radius like a digital Stasi operative. I could log the modulation types, the signal strengths, the timing of transmissions, understand the protocol fingerprints. That’s security research with teeth. The IR replay tool could theoretically extend my Lutron automation if I wanted blaster capability, but I’ve already got Hue plus Lutron for that layer, and introducing IR adds another layer of complexity and points of failure. The AirTag spoofer is the kind of thing I’d definitely flash at 2 AM, get two minutes of “I am chaos,” make Apple’s Find My network hiccup somewhere, then reflash the stock firmware before anyone catches me.
But do I need it for running a 100+ device network with three different radio protocols and something like 200 active endpoints? Fuck no.
The engineering is solid. Clean C++ on the Arduino framework, modular attack and defense code paths (so you can run attacks and also analyze them), responsive touch UI, PCAP logging to SD card so you can dissect attacks post-mortem, Sub-GHz profile saving and replay with adjustable timing and power levels. The “Deauth Detector” that monitors incoming attacks instead of just launching them shows the author understands both sides of wireless warfare — they’ve clearly spent time thinking about how to defend against these attacks too, not just execute them. The boilerplate warning about “educational and research purposes only” is there, legally covering all asses and the GitHub repo, though everyone who actually uses this tool ignores the warning anyway. (That warning is the cybersecurity equivalent of “this message will self-destruct” — it doesn’t stop anyone; it just makes GitHub Legal sleep better and gives plausible deniability to the platform.)
And here’s the thing that actually keeps me up at night: this tool is so good at what it does that it’s basically a weaponizable software distribution. GitHub is literally hosting a handheld wireless pentesting device, complete with a flasher that works in a web browser (no driver installation, no IDE, no friction), documentation that’s thorough enough for someone with zero RF experience to use it, and code that’s clean enough that you could extend it. Any person with an ESP32-S3 board (they cost $30-50), a web browser, and zero self-control can now flash a device that will deauth your WiFi, replay your garage door, spoof AirTags, jam your Zigbee mesh, and clone your RFID tags. That’s not a security flaw in the repo — that’s the entire fucking point. It’s democratizing access to tools that were previously locked behind expensive commercial equipment or deep RF expertise. That’s philosophically beautiful for the security research community (knowledge should flow freely) and operationally terrifying for everyone running a network that assumes their radio bands are not actively hostile.
The implications ripple outward. Neighborhoods with dense IoT deployments now have single-person attack surfaces. A neighbor with an ESP32-DIV and five minutes of free time could jam your Zigbee sensors, deauth your smart home hub, replay your garage door, and you’d have no idea who did it. The mesh logs would show devices dropping offline; the WiFi logs would show deauths; the Sub-GHz logs would show door commands being received. But there’s no MAC address on a jamming signal, no source IP on an over-the-air replay. You’d know you were attacked; you wouldn’t know if it was deliberate or accidental. That’s the scary part: weaponizable distribution isn’t just about intentional malice. It’s about how easily intentionless accidents become network disruptions when everyone has the tools.
(And the timing is chef’s kiss paranoia fuel: this review lands exactly when my BLE security script is pinging unknowns every couple hours, tracking those seven mystery devices I mentioned, trying to build a baseline of what belongs and what’s new. Coincidence? Probably. Definitely probably. But I’m not comfortable enough to test that theory by adding more BLE chaos to the mix. The universe doesn’t need my permission to get weird; I don’t need to invite it in.)
What I’m actually using instead, for the record: ESPHome devices for local automation logic, Zigbee routers (Philips Hue, Aqara) for the mesh backbone, Lutron Caseta for switching and dimming, Hue color bulbs for the parts that care about color, passive BLE monitoring for presence and unknown-device logging, WiFi for fallback and management, and a separate monitoring device that logs everything that seems off. That stack gives me reliability without active warfare. I’ve tuned it over years to handle transient failures, node drops, interference from neighboring networks, and the general chaos of wireless communication in a densely packed RF environment. Adding ESP32-DIV to that stack would be deliberately introducing the chaos I’ve spent time learning to manage.
Locally-first? Absolutely — no cloud, no account, no subscription, no phoning home. If ESP32-DIV were a home automation tool instead of a home automation destruction tool, I’d wire it in immediately. But it’s not. It’s a research platform that disrupts the stack instead of joining it. It’s designed to attack the exact infrastructure I depend on, not to integrate with it. And I’ve got enough disruption already with mysterious BLE devices lurking at -35 dBm like they’re actively plotting against my mesh.
Scouted repo: cifertech/ESP32-DIV — 3800 stars. Verdict: PASS. Desk review, nothing was flashed or installed.