The IoT Attack Surface
A smart plug is not one target. It is five stacked on top of each other, and the good bugs hide in the seams.
What you will learn
- -Map an IoT product into its device, firmware, app, cloud, and radio surfaces
- -Pick the right recon tool for each surface
- -Explain why the interesting bugs live where two surfaces meet
Pull apart a $20 IP camera and you are not looking at one target. You are looking at five, and they trust each other in ways nobody audited. The chip on the board. The firmware running on that chip. The phone app that drives it. The cloud service it dials home to. And the radio link tying the pieces together. Test one, skip the , and you walk right past the bug that owns the whole product line.
The reason a camera falls when a laptop would not is that trust. The app assumes the cloud validated the request. The cloud assumes the device only sends what the app allowed. The device assumes nobody is soldering wires to its board. Every one of those assumptions is a place to push.
The five surfaces
Draw this map before you touch a single tool. It keeps you honest about what you have and have not looked at.
The device is the physical board. UART and JTAG , an exposed serial console, a SPI flash chip you can clip onto and read, test pads the factory used and never removed. Physical access here often skips every other at once.
The firmware is the code sitting on that flash: the kernel, the filesystem, the , the startup scripts, and whatever got baked in at build time. Getting a copy of it is the next lesson.
The app is the mobile or web . An APK or IPA decompiles cleanly and routinely leaks hardcoded keys, backend URLs, and weak or absent pinning. The app tells you where the cloud lives and how it authenticates.
The cloud is the backend the fleet talks to: a REST API, an MQTT broker, the account and device-pairing model. This is where one on a device ID turns into every camera on the platform, because the whole fleet answers to the same service.
The radio is the wireless link: Wi-Fi, BLE, Zigbee, Z-Wave, or sub-GHz at 433 and 915 MHz. Sniff it with a cheap BLE dongle or an SDR and you read pairing traffic and commands that the vendor assumed nobody could see.
Where to start looking
the device on your bench and fingerprint it like any other . Open on an embedded target tell you a lot fast: 23 is telnet, 554 is RTSP video, 1883 is MQTT, 80 and 8080 are the config web UI.
$nmap -sV -p- --min-rate 1000 192.168.1.50The seams matter more than any single surface. A hardcoded key you pull from the app opens the cloud API. A cloud API with no per-device lets you replay a command the radio taught you. Chain two surfaces and you get that neither one has alone.
Everything in this module assumes the hardware is yours or you hold signed authorization to test it. Reading a flash chip, sniffing a radio link, or hammering a cloud API tied to someone else's device crosses into unauthorized access and interception law fast. Buy the unit, test your own, or work inside a scoped engagement. There is no casual version of this.
You find one API endpoint that returns any camera's stream if you change the device ID in the request. Which surface is broken, and why is the impact large?