I Can Root Almost Any IoT Device With a Kit That Fits in a Pencil Case — And That’s the Easy Part

The hardware gets you in. The firmware — and the cloud, app, and network wrapped around it — is where the real bugs hide. Here's how to do it in the right order.

Read this first. Everything below is for authorized testing on gear you own or are paid to assess. Hardware attacks leave fingerprints, brick devices, and run into computer-misuse, wiretap, and radio law that changes from country to country. Get your scope in writing. Then open the case.

TL;DR

Here's the mistake I see in every "hardware hacking kit" post, and one I made myself in an earlier draft of this article:

Treating the hardware as the exploit.

Cloning an RFID badge, dropping a BadUSB, popping a UART shell — those feel like the finale. They're not. On a real IoT engagement, the hardware kit is how you get in. What you do after — reversing the firmware you extracted, then turning those findings loose on the device's network services, cloud API, and mobile app — is where the actual vulnerabilities live.

This framing follows the way IoT specialists like Matt Brown (Brown Fine Security) structure an assessment: an IoT product isn't one target, it's five surfaces — hardware, firmware, network, mobile/web app, and cloud — and hardware access is mostly a lever to reach the other four.

So this guide is split honestly:

• The access kit (most of the pencil case) → gets you a shell and the firmware image.
• The firmware → the pivot. Hardcoded creds, keys, decryption routines.
• The ecosystem → where you actually exploit: missing auth, cleartext cloud traffic, broken TLS, mobile auth downgrades.

The whole engagement on one page

Keep this map in mind as you read. Amber = hardware access (how you get in). Red = where the real bugs live. Everything below walks these seven stages in order.

The corrected pipeline

Old mental model (wrong): recon → interface → extract → analyze → exploit the hardware.

Real model: hardware access is stages 2–4, and it feeds a firmware pivot that unlocks exploitation of the whole product.

See the color-coded diagram above for the full seven-stage breakdown.

Stage by stage — what I'm answering → the tools:

• 1 · Scope — Which of the 5 surfaces are in play? → threat model, rules of engagement.
• 2 · HW recon — What's the board, where are the debug pads? → multimeter, logic analyzer, soldering iron.
• 3 · Interface — Which protocol reaches the chips? → Bus Pirate, USB-TTL serial, jumper wires.
• 4 · Foothold + extract — Root shell? Firmware image? → UART console, CH341A, SOIC clip.
• 5 · Firmware analysis — What secrets and logic are inside? → Ghidra/IDA, binwalk, host tooling.
• 6 · Exploit the ecosystem — Can I abuse the live surfaces? → proxy, network + cloud + app testing.
• 7 · Report + retest — What's the impact, and is it fixed? → severity ranking, PoC, retest.

Stages 2–4 are the hardware kit. Stage 5 is the pivot. Stage 6 is the exploit — and it usually isn't hardware at all.

The access kit, piece by piece

Everything here exists to do one job: get me a shell and get me the firmware. That's it. Read the tool list through that lens.

Multimeter — my first move, always

Voltage, current, resistance, continuity. Boring, non-negotiable. Before any data tool touches the board: is this rail 1.8, 3.3, or 5 V? (Guess wrong, cook the target.) Which pin is ground? Continuity mode traces a mystery header back to a chip pin so I know what I'm about to talk to.

Getting me:

• logic voltage for level-matching
• ground/power pins
• a header that pings to the SoC — the fingerprint of a UART or JTAG/SWD debug port

Soldering iron — physical access enablement

Vendors leave debug interfaces as bare, unpopulated pads. The iron turns "test point I can't reach" into "header I can clip onto." Tack a lead onto a flash pin, add pins to a UART pad, or lift a chip to read off-board.

Getting me:

• live debug pads
• a removable flash chip
• a solid joint (a cold one gives garbage data and wrong conclusions)

Logic analyzer (8-ch, 24 MHz) — the protocol microscope

Captures up to 8 lines and decodes SPI/I²C/UART/USB/1-Wire. Clip on while the device runs; host software (PulseView/Sigrok) rebuilds the bytes. Passive — I'm eavesdropping on the board's internal gossip.

Getting me:

• the protocol + parameters (SPI mode 0 @ 8 MHz? UART 115200 8N1?)
• which line is clock/data/CS
• sometimes cleartext secrets between MCU and peripheral

Bus Pirate (v3/v4) — the universal talker

Where the analyzer listens, the Bus Pirate talks: SPI, I²C, UART, 1-Wire, GPIO. Read/write registers, dump an EEPROM, poke an embedded device and watch it fall over.

Getting me:

• readable/writable config memory
• undocumented register behavior
• a quick serial dump from smaller parts

USB-to-TTL serial (CH340 / CH341A) — the console line

The one that wins engagements. Tons of devices expose a serial console on a 3–4 pin header. Wire GND/RX/TX, open a terminal, and you routinely get boot logs, a bootloader, or a login shell — sometimes an unauthenticated root shell. Highest value, lowest effort. Even when the shell is restricted, an unlocked bootloader is often enough to walk it up to full root.

Getting me:

• an interactive console (jackpot if it's root)
• bootloader access to change boot args or halt boot
• verbose logs leaking partition layout, kernel version, hardcoded paths

CH341A programmer — the extraction workhorse

Reads/writes EEPROM and SPI flash directly; dumps and reflashes BIOS/firmware. This turns a soldered-down chip into a file on my laptop. Attach (via the clip below), run flashrom, and the whole chip reads out as an image.

Getting me:

• the complete firmware image — raw material for stage 5
• write capability, if I later need to prove a modified-boot at
• SOIC test clip (IC clip) — read the chip without desoldering

Clamps onto a surface-mount SOIC chip and contacts every pin. Paired with the CH341A, I read (and often write) the flash in-circuit — clip on, dump, clip off, no visible tampering. If the board pollutes the read, I lift the chip and read it socketed.

Getting me:

• non-destructive, covert firmware extraction
• a repeatable read-modify-reflash loop.

Breadboard, jumpers, components — the bench

Solderless space for the little bridge circuit that makes a flaky connection reliable, plus a rig to wire up targets repeatably. Jumper wires are the glue for every connection above — and the dirty secret is that most "the tool's broken" moments are a swapped RX/TX, not a broken tool.

The three tools that touch other surfaces (don't confuse them with the hardware chain)

These three are in the kit but they are not part of the hardware-access chain. They each hit a different surface, and lumping them in with "hardware exploitation" is exactly the mistake this article is correcting.

• Wi-Fi adapter (ALFA / RTL) → the network surface. Monitor mode + injection: sniff traffic, capture WPA handshakes, run deauth, stand up an evil twin / rogue AP. This is a network-layer test, not a hardware one.
• RFID-RC522 → the physical-access surface. Read/clone/emulate 13.56 MHz badges. It's a physical-security finding, independent of whatever the device's firmware is doing.
• BadUSB / ATtiny85 → a host / peripheral-trust attack. A fake HID keyboard that types a payload on insert. Great for demonstrating that a workstation trusts any keyboard — but that's usually a different target than the embedded device under test.

Keep them in your kit. Just don't file them under "how I exploited the hardware."

The pivot: firmware analysis is where it gets real

Once the firmware image is on my laptop, the hardware phase is basically done. Now the actual hunting starts. Unpack the root filesystem, identify the boot chain, and reverse the interesting binaries in Ghidra or IDA.

What I'm digging for:

• Hardcoded credentials — a root password baked into the firmware unlocks every unit of that model, not just the one on my bench.
• Keys and decryption routines — including the routine the vendor uses to decrypt their own firmware updates. Recover that and you unlock every future image too.
• Restricted-shell bypasses — the path from a locked-down or bootloader-limited shell to full root.
• The device's real logic — how it authenticates, what it talks to, and where it trusts input it shouldn't.

This is the hinge of the whole engagement. The hardware got me the bytes; the firmware tells me how to break the product.

Exploitation: what firmware findings actually unlock

This is the phase I got wrong before. Real IoT exploitation mostly happens on the live surfaces, using what the firmware taught me. The strongest findings look like these (all real categories from Brown Fine Security's published IoT work):

• Missing authentication on device services — e.g., an unauthenticated ONVIF interface that lets an attacker pull the video stream and move the camera remotely. No hardware needed to trigger it — but firmware analysis is how you find it.
• Cleartext cloud communications — device shipping data to backend servers unencrypted, straight across the public internet.
• Broken TLS validation in the companion app — a mobile app that fails to validate server certificates, so a MITM reads everything. (In one case, a police bodycam app quietly sending data to servers in China.)
• Authentication downgrade in enterprise mobile apps — forcing the client onto a weaker auth path.
• Weak or proprietary encryption — home-rolled crypto in a P2P protocol that falls apart under analysis.

Notice what's common: the hardware kit never appears in the finding. It appears in the methodology — it's how you got the firmware that revealed the flaw. That's the whole point.

What I'm actually hunting (reframed, correctly)

1. A foothold — root shell via UART, or firmware off the flash. The entry, not the win.
2. The firmware image — everything downstream depends on it.
3. Secrets in firmware — hardcoded creds, keys, and the vendor's own update-decryption routine.
4. Auth gaps on live services — missing/broken authentication on device network services.
5. Insecure comms — cleartext cloud traffic, broken TLS in the app.
6. App/cloud logic flaws — auth downgrades, injection, misconfigured APIs.
7. Physical/network side-doors — cloneable badges (RC522) and weak Wi-Fi, tracked as their own surfaces.

Prizes 1–3 are what the pencil case gets you. Prizes 4–6 are the report's headline findings.

A real run, start to finish

1. Scope. Agree which surfaces are in play and whether physical access is allowed.
2. HW recon. Multimeter confirms 3.3 V logic, finds ground, traces a 4-pin header to the SoC — probable UART.
3. Interface. Logic analyzer confirms UART @ 115200, identifies RX/TX.
4. Foothold + extract. USB-TTL gives a console; if it's a restricted shell, walk the unlocked bootloader up to root. SOIC clip + CH341A + flashrom pulls the full firmware image.
5. Firmware analysis. Unpack rootfs, reverse binaries, recover a hardcoded root password and the firmware-decryption key.
6. Exploit the ecosystem. Use that knowledge to find the real bugs — an unauthenticated device service, cleartext cloud traffic, a companion app that skips cert validation.
7. Report + retest. Severity-ranked findings, working PoCs, remediation, retest after the vendor patches. Put the device back exactly how I found it.

The loop-back arrow in the diagram is stage 6 → stage 5: every ecosystem finding sends me back into the firmware for the next one.

Where the kit stops working (and why that's the finding)

Hardware attacks need physical possession, can brick the target, and run into secure boot, encrypted flash, fused-off debug ports, and anti-tamper packaging. A mature product shrugs off half this kit — and that's the result you report. If a cheap pouch of red boards gets root off a UART and dumps unencrypted firmware, the vendor didn't get unlucky. They skipped the basics.

The part I don't skip: authorization

Physical and wireless attacks touch far more law than software testing — computer misuse, wiretap/interception, RF regulation, telecom rules, all varying by country. Deauth and evil-twin can hit bystanders. Cloning a real badge without permission is a crime. Use only where you're authorized, know the local law, stay in scope. The line between a pentest and a felony is authorization, drawn in writing before the first wire goes on.

Credit & further reading

The surface-based methodology here — hardware, firmware, network, app, cloud, with hardware as the entry technique rather than the payoff — follows the approach Matt Brown documents at Brown Fine Security. His IoT Pentesting Roadmap and his device write-ups (UART root shells, restricted-shell bypasses, firmware secret extraction, cleartext cloud comms, broken app TLS) are the clearest public examples of this pipeline in action.

Wrap-up

The pencil case is real, and it's powerful — but it's a door key, not a crown. It gets you a shell and a firmware image. The exploitation that fills a report happens afterward, on the firmware and the ecosystem around it. Learn that sequence, not just the gadgets, and you stop mistaking "I got in" for "I found the bug."

Assume the enclosure will be opened — and design like the attacker already has your firmware.

Educational write-up for authorized security research. Test only what you own or are contracted to assess.