[HackerNotes Ep. 199] Web Hackers Go Hardware: An IoT LHE Debrief

A little retex about the latest IoT LHE

Author

Aituglo ‎
November 05, 2026

Hacker TL;DR

  • Get a shell first. A root shell is worth much more than the source code. It gives you the bearer tokens and keys that are only kept in memory, so get it early and find bugs from there.

  • Turn the target into something you already know. None of the three are hardware experts. They pulled the firmware, reversed it, and looked at device-to-cloud pivots, which is close to normal web hacking.

  • AI helps, but you still drive. It can reverse binaries, bypass ASLR, and read binary protocols better than you, but it also gives up early and gets stuck on one idea. You have to keep it on track.

Sponsored by ThreatLocker – Privileged Access Management. Fitting, since auth bypass and privilege escalation are the whole theme here: least privilege plus PAM are exactly what keeps a full auth bypass from turning into game over. Worth a look.

eMMC to Cloud Account Takeover

JD's favorite bug this event was not the show-and-tell one. It started with recon on chip types. He knew an eMMC is harder to pull than a chip with side contacts, because the pads are on the bottom, so he picked the device where the chip came off easiest with hot air. The third device worked after two failures, and he had the firmware.

From there it looked a lot like web hacking:

  • The device sent a discovery message on the local network every 8 hours, looking for a second device. The second device answered with a JSON blob that had a location key pointing to a local IP.

  • The device then requested an XML page from that IP and parsed it. There was a check that the IP had to be in the location header, but nothing stopped it from also being in a query parameter. That gave a blind SSRF.

  • The XML parser was the main bug. It read the response byte by byte into a buffer of size n, and only refused to parse when n > 1. So JD sent a chunked response with a chunk size of -1 instead of XML. The size was read as an unsigned integer, the check was fooled, and the buffer went from 1 to 0xFFFF. That is a buffer overflow.

  • There was a stack canary, but it was never randomized. It was hardcoded to 0xdeadbeef. With a known canary he built a ROP chain to get RCE.

RCE did not do much on its own, because there was no shell, just a small device. But the RCE could read memory, and memory held the bearer token for the cloud service the device used. Read that token out and you have access to the account behind the device at the company.

The every 8 hours detail came from AI static analysis, not manual reading. JD did not wait 8 hours to prove it: the same routine also runs on device restart, which made the PoC easy. In a real attack, the attacker puts something on the network and waits.

WAN-Side Router RCE, Brute-Forced Past ASLR

On the WAN port side of a router, with no authentication, a protocol gets negotiated. A few steps into it there was a buffer overflow, only about six bytes, but it landed on a function pointer that gets called right after, and that function is given the raw packet as its first argument. A clean primitive.

Then ASLR got in the way. This was a stack overflow, the primitive was good, but there was no easy way to leak the base. What the AI did here is the interesting part, and Justin is honest that he still does not fully understand the binary exploitation under it:

  • It read everything reachable in the address space it could point the function pointer at, and picked an address most likely to hit a function that does something you can see: writes a couple of bytes back, or crashes, or changes the response timing.

  • From that address it made about 36 different detection paths. Each one, on a hit, tells you something about the base from the response, the crash, or the timing.

  • Then it ran the brute force. End to end it was about a 1 in 40,000 chance to land a path, recover the base, resolve system, and send a second packet.

Two more problems came up. First, a shell-escaping bug in the receiver ate an early hit, and the AI said it had fixed it when it had not, which happened more than once. Second, on the WAN port there is no IP assigned yet, this is before DHCP, so there was nothing to call back to. The fix was to have the payload send a raw ARP for a specific address, which is enough to show the command ran.

The impact: this is WAN-side, so an attacker at the ISP level could take over routers in people's homes. And the fact that this traffic can cross the WAN boundary at all suggests other things that are not meant to leave the LAN might cross it too.

Justin also had a quick second bug: config file injection in hostapd. He could set an ANQP metadata element (a Wi-Fi protocol most people have not touched) tied to an SSID, and one of those elements let him set an arbitrary path that gets included in the response. That is an arbitrary file read. Config file injection still works because IoT vendors build these config files from many binaries and forget the formatting rules that come with them.

One CA Role to Full Cloud Takeover

Brandyn collabed with Matt and went after device-to-cloud pivots. The problem: no shell on the device he wanted. Matt had a lead that let him act as an on-device service and look like a signed, genuine one, which pulled all the session material from the credential store. That gave them credentials but no shell, and the pivots stalled.

The next step was reversing the on-device binaries against those credentials. One service, at first boot, exchanges certificate information: it says which device it is, asks for a cert for some services, and sets how it will sign its session data. Brandyn looked for the host behind it and almost missed it, because the domain did not follow the vendor's naming convention. Someone had just made it up. Lesson: do not assume your list of target hosts is complete, especially for the odd internal ones.

From there it was a token exchange, the kind he covered last episode: hold a token here, hold a token there, and relay one for the other. That gave temporary credentials for the service that issues device certificates. The role name had CA in it, he asked the team if he was on the right track, got a yes, mapped the AWS role, and pulled a set of secrets out of Secrets Manager. What looked like a single certificate-issuing role turned into a full cloud takeover.

We do subs at $25, $10, and $5, premium subscribers get access to:

– Hackalongs: live bug bounty hacking on real programs, VODs available
– Live data streams, exploits, tools, scripts & un-redacted bug reports

Need a Pentest? We just launched CTBB Pentests!

Hack full time? Check out the Full-Time Hunter’s Guild!

The LHE Game: The Dupe Window Matters Most

The scope arrived about a month before the event, with a "look but don't hack" rule (they still wanted accidental criticals), because you are meant to take the devices apart first. But the dupe window was only 3 days. That is a hard mix with AI in play.

The proof: several five-figure dupes across the crew, and a client-side bug at the top of one hacker's skill level, deep and complex, that came back as a dupe from a month before. When a report takes minutes to write and everyone has agents running source review, going deep helps less and hacking early helps more. Hack inside the window.

One methodology note: JD spent a week and a half trying to turn an LFI into RCE on a device he could not get a shell on. That time should have gone to easy bugs, because as soon as he gave up, he found two more bugs quickly, and both were 2.0 dupes anyway. Get the easy bugs in the window first, then dig deeper.

Manual Hardware Hacking: Shell First

The same point comes up in all three:

  • Get firmware, then get a shell. There was no easy UART on these devices this time, so the firmware came off the chip. Once you have firmware, even firmware you cannot decompile cleanly, AI can reverse it.

  • A root shell beats source code. Source is useful, but the key is not in the source, and the bearer token is not in the source. It is in memory, and you need a shell to get it. JD got root on one device through leaked firmware he found using the OSINT section of Matt Brown's course, and that root shell helped him find more bugs. Justin found a clean root shell on another product 12 hours before the end, and it was a dupe, but it would have saved him the whole ASLR brute force.

  • Work in terms you know. Brandyn's plan was to turn the device into device-to-cloud pivots he could reason about. JD rebuilt the cloud API and imitated the device like a JS client. Same approach as web, one layer down.

The Role of AI: Strong and Weak at the Same Time

This event was part AI, part human, depending on the bug. A few things that worked:

  • AI reads binary protocols you have never seen. The main gap between web and IoT is the number of protocols, many of them binary. Give the implementation to AI and ask how it matches the spec, where it differs, and where the holes are. You get up to speed fast, because the model knows the spec better than you.

  • Point the agent at one thing, not "find all bugs." Gr3pme's usual prompt: "map each part of this authentication flow, list every file it touches, flag any validation on user-controlled input, and write it to a file so we can come back to it." Then use it to check your own thinking, "here is how I think this works, confirm or deny," instead of asking for answers. Knowing the architecture is what lets you say "UPnP is broken here, go look" instead of "go find vulns."

  • Don't let the model give up. During two weeks of trying to root a device, Claude told JD it was impossible about once an hour. A human with that good a bug would not quit, so don't let the model quit either. Two tricks that keep working: tell one model that another one already solved it ("Claude found a way, why can't you"), and start a fresh agent to review the first agent's give-up notes ("do you agree with this?" often returns "no, it missed these seven things"). Agents that run a long time get stuck on one idea and need a second look.

The trade-off: AI takes away some of the fun even as it gets better results. The chaining, the bug you work out at the bar, the six hours straight at the DEF CON UART village, that is where the fun is. And AI still can't solder.

Resources

That's it for the week, keep hacking!