The IoT Hacker's Handbook: A Practical Guide to Hacking the Internet of Things

Welcome to the deep dive. Today. We're jumping into something that's well, probably all around you right now, the Internet of things IoT. Think about it, you're smart speaker, your fitness tracker, maybe even medical devices. They're super convenient, right, but they also open up a whole new world of well potential problems vulnerabilities. So our mission today is to really get into the weeds of IoT security. It's fascinating stuff,

Term internet of things actually goes back to Kevin Ashty. He was thinking about RFID, you know, tracking physical.

Stuff RFID right, like in inventory tags exactly.

But then fast forward to June two thousand, LG actually launched an Internet connected fridge, the Internet digital dios maybe the first real IoT device.

And internet fridge in two thousand.

Wow. Yeah, bit ahead of its time maybe, But the real sort of tipping point when people really noticed was probably the nests hrmostat ah nest I remember that right when Google bought them at twenty eleven for was a three point two billion dollars That really signaled, wait, this is happening, this is a revolution.

So the money started flowing and everyone wanted.

In pretty much. And the thing is, policymakers, regulators, they just couldn't keep up with how fast it was growing. So you had this massive adoption of devices, but often without any real strict quality controls or safety rules.

Meaning developers could kind of ignore security largely.

Yeah, the pressure was just to get products out the door fast. Security was often.

An afterthought until something big happened to us exactly.

The big wake up call was the Maria botnet twenty sixteen that was genuinely alarming. Maria basically went after internet connected cameras, cheap ones. Mostly. It was brutally simple, really, it just tried common default user names and passwords like admin and pass. They're king defaults on millions of devices. It was like millions of front doors just left unlocked, and once it got in, it took over Liberia's entire internet,

That's staggering. It shows how interconnected everything is and how weak links can cause chaos.

Precisely, it was a systemic failure, not just a few bad devices.

Has security gotten better since.

Then, It's improved definitely slowly, but I wouldn't say devices are extremely safe even now, not by a long shot. We've seen researchers do things like takeover Phillips HU smart lights using drones. Drones how they found encryption keys just hard coded into the firmware, easy to grab, and they use zigbie the wireless protocol to spread the infection.

So one light infects the next, YEP.

And even earlier, back in twenty thirteen, Natistan Johnny showed he could cause permanent blackouts just by replaying old network messages. He just needed the device's m ASSE address, which isn't hard to get and could spoof commands. Basic stuff really but effective, which is.

Worrying because these devices collect so much data about us.

Right, absolutely, really intimate data, sometimes health data, what you do in your home. It's a huge privacy risk if they get hacked. But on the flip side, all these incidents have created a real demand for IoT security experts, people who know how to build this stuff securely, and people who know how to break.

It the ethical hackers right, and.

Companies are finally starting to offer bug bounties more often, paying researchers to find flaws before the criminals do.

Okay, So it sounds like the rapid growth and lack of early overst so I created a bit of a mess. Maybe the best way to understand the risks is to look at some specific example some of those headline grabbing hacks. Let's start with the Nest thermistat. Again, you mentioned it earlier.

Right, the Nest. So researchers found you could crash it, make it reboot just by sending specific Bluetooth signals.

Just crash it. What's the big deal?

Well, it created about a ninety second window where the thermistat was offline. Okay, and if you had a nest security camera link to it. That camera might also be affected or delayed. Ninety seconds could be enough for a burglar to slip past undetected.

Ah. I see, so a security device actually created an insecurity exactly.

Then there were those Phillips Hugh lights. We mentioned the drone attack exploiting the hard coded Zigbie.

Keys right, the self spreading worm.

Yep, and also that replay attack causing permanent blackouts that was also targeting Phillips gear exploiting easily guessable device IDs.

It seems like basic communications security was often missing often.

Yes, look at the lift at smart Bold. Another research Alex Chapman found he could inject malicious packets. He could actually decrypt the owner's Wi Fi password from the.

Bulb get the Wi Fi password from a light bulb.

Yeah, the key was he dumped the firmware, the bulb software using a hardware technique called JTAG, and right there in the code the AES encryption key, the initialization vector, everything needed to break the security. Wow.

Okay, that's bad, but maybe not as viscerally scary as the GP pack.

Ah. The jeep pack twenty fifteen, That one really got people's attention. Doctor Charlie Miller and Chris Vallisek.

Legends what did they do exactly? I remember the headlines, but the details.

They remotely took control of a Jeep Cherokee while it was driving miles away. They found a vulnerability in the U Connect infotainment system, specifically an open network port Port six six sixty seven running something called DBUS over IP, and through that they found a service that let them run their own code on the car's system, giving them control of the steering, brakes, headlights, transmission, wipers, radio, everything while someone was driving out on the highway.

That is terrifying, actual physical danger from a software flaw.

Absolutely. It led to a recall of one point four million vehicles. It showed that IoT security wasn't just about data theft. It could be about physical safety.

And it's not just cars or light bulbs. You mentioned medical devices, right.

Jay Radcliffe found a major issue with a Johnson and Johnson insulin pump, the Anima's one Touch pain. It communicated wirelessly but in clear text.

No encryption for an insulin pump.

That sounds critically extremely It meant someone nearby could capture the commands, maybe modify them and replay them. They could potentially change the insulin dosage delivered to a patient that could be lethal. Potentially. Yes. Thankfully, the vendor did patch it relatively quickly, within about five months, but it highlighted the risks in critical health devices.

Even things like smart door locks have had problems.

Oh yeah, tons of issues. One researcher, Jay Max, looked at the August smart lock. He found a way for someone with guest access to become an administrator. Oh just by intercepting the network traffic and changing a value from user to super user. Simple as that. Plus the firmware wasn't signed, meaning you could modify it and to bypassed

You can't make this stuff.

Up, you really can't. The pattern is just surprisingly weak security practices in many.

Cases, even smart guns. That sounds like something from a.

Movie, It does, but it's real. Tracking point makes smart rifles, you know, with computer raided targeting. Researchers Runas Sandvik and Michael Auger found they could get admin access through a physical port called art okay.

And what could they do from there?

They could launch network attacks to mess with the rifle's calculations. Change the wind velocity value or the bulletweight parameter.

So the rifle would calculate the wrong shot.

Exactly, making the shoot or miss without them even knowing. Why imagine the implications.

Yeah, and you mentioned another one with magnets.

Ah, right, the Armatix IP one smart gun. It had a safety feature linked to a special watch. Another researcher poor bypassed it using yes, just strong magnets. He could manipulate the firing mechanism directly, proving that sometimes a really low tech attack works just fine against poorly designed high tech security.

So, looking at all these different examples, what's the common thread?

I think what's fascinating and worrying is how it shows every part of an IoT device can be a weak point if it's not secured properly. The hardware itself, the firmware, the mobile app, the cloud service it talks to, the radio signals, any single component can be the point of failure. It's the whole chain.

Okay, so we've seen what goes wrong, But why why are these vulnerabilities so common? What are the root causes?

That's the crucial quest if we actually want to fix things, And there's several big reasons. One huge one is fragmentation. Fragmentation means the sheer number of different ways these devices talk to each other ZIGB Bluetooth, low energy, z wave, Wi Fi, Laura six to low PAN, dozens of protocols and software.

Frameworks like a tower of Babbel for devices.

Kinda yeah, it creates enormous complexity. There's no single standard everyone follows, and this lack of standardization makes it way easier for flaws to creep in. Plus, a lot of developers just grab a popular framework and kind of assume it's secure out of the box, which is often a really dangerous assumption.

So the variety itself is a problem.

What else, A big one is simply a lack of security awareness among developers. You mean they don't care. Not necessarily that they don't care, but they're often under immense pressure to ship products quickly. Deadlines are tight, and they might just not be trained or aware of the specific security pitfalls and IoT how hardware interacts with software, how RADI protocols can be abused. It's a specialized field.

So they need better training and maybe stricter guidelines.

Definitely regular security training, clear coding rules, security checklists baked into the development cycle. That's essential.

Okay, what other factors?

Another issue is what you might call a lack of a macro perspective. A macro perspective, yeah, meaning teams often focus too much on securing just one piece of the puzzle, Like they'll pentis the mobile app, but they won't look closely at how the app, the device, and the cloud all interact.

Ah, so they miss the vulnerabilities that emerge from the connections between components exactly.

They miss the forest for the trees. You need to look at the entire system architecture end to end and do proper threat modeling to see how everything connects and where the real risks lie.

That makes sense. It's the Internet of things, after all, the connections matter.

Right. Then there are supply chain issues.

Supply chain like where the parts come from precisely.

Think about how a complex device gets made. You might have one company making the process or another. The Wi Fi chip another, assembling it, another distributing it. Every step in that chain, every vendor involved, is an opportunity for a vulnerability to be introduced, either accidentally or maybe even deliberately. A backdoor could be slipped in at any point.

Wow, that's complex. How do you even secure that?

It's incredibly difficult. It requires a lot of trust and verification, which is hard to achieve globally.

Okay, any other major causes.

One last big one is the use of insecure frameworks and third party libraries.

So developers using pre written code that's already flawed exactly.

It's very common to grab existing code samples or libraries to speed up development. But if that code you're importing has vulnerabilities, well, now your product has those vulnerabilities too. And again, the business pressure to launch quickly often means proper security vetting of these third party components gets pushed.

To the back burner until there's a breach.

Until there's a breach. Sadly, that's often the trigger for taking it seriously.

So putting it all together, it's a mix of complexities, speed to market pressure, lack of awareness, and issues baked into the whole process of building these things that.

Sums it up pretty well. It's a complex ecosystem with security challenges at almost every level.

Which, as you said, creates a huge demand for people who can find these flaws. The security professionals, the pen testers. How did they actually do it? What's their process?

Right? So, an IoT penetration test or pentest is different from just testing a website or a regular application. It's about assessing everything the physical device, the firmware inside it, the radio communications, the mobile app, the cloud back end. The whole solution.

Sounds comprehensive, it has to.

Be, And interestingly, you often need multiple physical devices for testing because some techniques like physically taking chips off the board are well destructive. You might break a device or two finding vulnerabilities.

Okay, so where do they start?

The absolute foundation is a tax surface mapping. This is the recon phase. You gather as much in from possible before you even touch the device. Read the manuals, check the vendor's website, look for patents, search for previous research on similar devices, anything you can find.

What kind of info are you looking for?

Q details like what processor, cpu architectures it use, what communication protocols, Wi Fi, bl zigbie, Is there a mobile app. How does it get firmware updates? Does it have USB ports, FD card slots, any hardware ports? Visible?

Building a complete picture, yes exactly.

You can generally break down the attack surface into three big areas. First, the embedded device itself the thing. Can you open it? Are the debug ports inside like art or jtag? Can you dump the firmware directly from a chip is authentication week? Second the firmware software and applications.

So you map out all these potential entry points right.

The goal is to create an architectural diagram, show all the components how they talk to each other, and then list every potential way an attacker might try to get in every attack vector.

You mentioned something earlier about sec IDs.

Ah Yes, a really practical tip. Almost every device that transmits radio waves has to have an SECID never printed on it somewhere. If you take that ID and search for it on the FCC website, specifically sites like sccside dot io, it's often a gold mine.

Why what's there?

You can find internal photos of the device before it's even released, sometimes detailed documents test reports. For example, looking up the FCCID for an edmax IP camera revealed internal photos clearly showing four little pads on the circuit board that strongly suggested a u AT interface, a key debug port, public information giving you a clue for hardware hacking.

That's clever, using public data to find hidden doors.

Okay, so once you've mapped the attack surface, what's next? You mentioned getting physical to tear down exactly?

This is often where the real fun begins for hardware hackers, getting physical with the device, trying it open.

Pretty much, the main goals here are things like extracting the firmware directly from memory chips, maybe getting a rootshell or command prompt on the device through a hidden port, connecting debuggers to see what the code is doing live, sometimes even modifying the hardware or writing custom firmware. And yeah, as I said, you need spare devices because you might break things.

So how do you start the physical analysis? First?

Is just external inspection. Look closely at the outside, what buttons are there, any obvious ports, ethernet, USBSD card, what kind of display does it have? Power requirements? And critically look for those certification labels like the STCID. Even note the type of screws holding it together. Sometimes you need special screwdriver just to get inside.

Like on Apple devices.

Exactly ped loavescrews, torques. Knowing that tells you something. For instance, looking at an old Navman GPS, you might note it runs Windows, CE has a Samsung ARM processor and see the USB, port, SD slot, et cetera. All clues.

Then you actually open it up.

Yeah, carefully. This is the internal inspection. You're looking at the printed circuit board PCB, identifying the main chips, the CPU, RAM, flash memory, where the firmware lives. You're also hunting for connectors, antennas, and especially those debug interfaces. We talked about pins or pads for your JTAG SPI. These are often the keys to unlocking the device.

And those fcc ID lookups help here too massively.

Again, that FCC database SCCI dot io is amazing. You might see internal photos there that clearly label the CPU model or show exactly where the ur pads are, saving you a ton of guesswork, like.

Finding the blueprint before you pick the lock.

Precisely that edmax camera example. Again, the SEC filing basically pointed right to the r pads, a huge headstar for anyone wanting to connect to it.

Okay, so you've found these internal ports like u ART, how do you actually use them? How do you talk to the device's insights?

Right? That's where understanding these low level communication protocols is key. Let's start with u ART Universal Asynchronous Receival Transmitter.

Okay, what is it?

Simply, it's a really common, simple way for chips to talk serially one bit after another. It doesn't need a shared clock signal, which makes it easy to implement. Think of it like a basic direct serial chat line between components.

And how do you exploit it?

First, you need to identify the pins on the circuit board ground G and D, transmit TX, receive RX and sometimes power VCC. You can often find these using.

A multimeter testing voltages and continuity exactly.

Yeah, Then you need a tool to connect your computer to these pins, something like an FTDI adapter or a specialized tool like the Adify badge works well. You connect your tools TX to the devices RX, RX to TX and ground to ground. You usually leave the VCC power pin disconnected. Why because the device is usually already powered on. You don't want to feed it extra voltage. Then you need to figure out the speed the bod rate they're

Okay, you've got the pins, the speed, then what Then?

You just use a simple terminal program on your computer like screen or Mini coom, connect to the serial port provided by your tool, and very often, especially on cheaper or older devices, you'll just get dropped straight into a command prompt, often a rootshell.

Meaning full administrative control, no password needed.

Yep, an unauthenticated root shell over art. It's a surprisingly common and critical vulnerability. We found this on that Atmax camera for example, instant root access just by soldering three wires.

Wow, okay, what about other protocols you mentioned I two C right, IT two.

C integrated circuit. There is another common one, but it's a bus protocol, meaning multiple chips can share the same two wires SDA for data and SEL for the clock signal.

So it's like a little internal network kind of.

Yeah. It's used for slower communication between components like e proms small memory chips that store configuration data, real time clocks, sensors, things like that.

And how is that useful for hacking?

Well, if important data like settings or maybe even keys are stored in an e PROM chip that uses IT two C, you can often read or write directly to that chip. You'd find that chip on the board, look up its data sheet to understand how to talk to it. Connect your tool against something like the adify badge using clips or an.

Adapter directly onto the chip yep, clip.

Right onto the legs. If possible, then you use software like scripts often called I two C PROM dot PI or similar to communicate over I two C and dump the contents of the memory or even write new data back to.

It, so you could potentially change device settings stored in that memory exactly.

Maybe disable a security feature, or extract some sensitive configuration data.

Okay, one more SPI.

SPI Serial Peripheral interface another bus protocol generally faster than I two C. It uses separate lines for data going in OSI master out, slave in and data coming out misomaster enslave out, plus a clock SK and a chip select line SS to choose which device you're talking to.

Faster, more wires. What's his main use case in hacking?

The big one for SPI is often dumping the entire firmware directly from the main flash.

Memory chip AH getting the device's brain out precisely.

Many devices store their operating system and all their software on a flash chip that communicates using SPI, so similar process find the chip, identify the SPI pins, mobiles, MISO, skcs, VCCG and D connect your tool, and then use a utility like spyflash dot PI. I often use with tools like the ATIFI badge or flashroom to read the entire contents of.

That chip, and that gives you the firmware file exactly.

You get a binary file containing everything. For example, on a device like the WRT node router, you can use SPI to pull the full OpenWrt firmware off its flash chip. Then you can start analyzing that firmware offline.

So these low level portocols r at I two ce SPI. They're like the secret back doors into the device's hardware, letting you get shells or extract the firmware.

That's a good way to put it. They bypass a lot of the normal software security because you're talking directly to the hardware components.

Which leads perfectly into the next stage. You got the firmware file, Now, what how do you crack that open?

Right? So you've managed to get the firmware, either by downloading it, sniffing it during an update, or dumping it via hardware like SBI. Now the real analysis begins, and having that firmware file is huge for a security researcher. It's arguably the most critical component because it lets you understand the device's logic, find vulnerabilities, look for secrets, all without needing the physical device anymore potentially.

So first step is usually unpacking it. You mentioned it's often compressed exactly.

Firmware files are often archives containing a file system, bootloaders, maybe a kernel. You can try manually analyzing it first, use tools like file to see what type of file it is, strings to look for readable text, hex dump to look at the raw bytes. Sometimes you can spot signatures of and filesystems like squash fs. Just by looking at the hex you might see the magic bytes.

H excludes in the raw data.

Yeah, and if you find something like squash fs, you can use tools like dd to carve out that section of the firmware file and then use unsquash to extract the actual filesystem.

Sounds a bit involved? Is there an easier way?

Oh? Yeah? The go to tool here is binwalk. It's fantastic.

Binwalk. What does it do?

It automatically scans firmware files for known file signatures, compression types, executable code, everything. You just run binwalk on the firmware file, it'll tell you okay, at this offset there's a header. At this offset, there's a squash fs filesystem. At this offset maybe some GFFS two data.

It maps out the structure exactly.

And even better, you can run binwalk de for extract and it will try to automatically carve out and extract everything it finds into a folder. Usually gives you a firmware dot extracted directory containing the filesystem like squashroot. Super convenient.

Okay, so now you have the filesystem laid out, what are you looking for.

Inside one of The first things is hard coded secrets, passwords, API keys, private encryption keys. Developers sometimes mistakenly embed these directly into scripts or configuration files.

You just search for them pretty much.

You'd use rep to search recursively through the entire extract and file system for keywords like password, key, secret, admin token, or maybe specific service names like Telnet FDP, and.

You might find default credentials.

Absolutely, you might find a script like telnetdat dot ashesh that starts the Telnet service with a default login like root and password happens all the time.

Okay, but what if bin walk can't extract anything? What if the firmware just looks like random data.

Ah, that's a strong sign it might be encrypted or maybe heavily obfuscated, So gameover not necessarily. First step is often to look at the entropy. How random the data looks. Tools can measure this. High entropy suggests encryption or compression. Then you might use hext se again to look at the raw bytes. Even with encryption, sometimes you can spot.

Patterns, patterns and encrypted data.

How especially with simpler encryption methods like xor if the same key is used repeatedly, you might see repeating byte patterns in the ciphertext. You might even be able to guess the key length, or if you're lucky and have some known plaintext like a standard file header that should be there, you could potentially deduce the xor key itself.

So you figure out the key.

Then you can write a simple script, maybe in Python, to apply the xor operation with that key to the entire encrypted firmware file and hopefully out pops the decrypted.

Firmware and then binwok can work on it exactly.

Once it's decrypted, you run binwalk again, extract the file system and continue your analysis, maybe dive deeper into specific executable files using reverse engineering tools like guedro or radar two to understand their logic.

Okay, this is getting deep. What about actually running the code you find? Can you do that?

Yes? But it's tricky because IoT devices use different process or architectures. Arm mips are common, not the by eighty six your laptop.

Uses, so the code won't run directly on your computer.

Correct, But we can use emulation. The most common tool for this is keemu U. Yeah, keemu provides userspace emulation. You can take say a memo binary from the firmware and run it on your by eighty six Linux machine using Chemo mipsel static. You copy the right chemostatic binary into the extracted firmware's filesystem, then use a command called troot to make that extracted directory act like the root

The scenes, so you can interact with the device's software environment without the device exactly.

Yeah, but that's just running individual programs. What's even more powerful is full system emulation. There are specialized toolkits, like the Firmware Analysis Toolkit FAT or Fermidine designed to emulate the entire firmware image. What's the advantage of that It tries to boot the whole emulated device, It sets up networking start services. It means you can often access the device's web interface through your browser, interact with its network

That sounds incredibly useful for testing find web vulnerabilities network flaws.

Absolutely, you could test a netgear firmware, for example, emulate it with FAT and then access its weblogin page. Maybe try default credentials like admin passwork.

Okay, one more thing here, backdooring firmware. Can you actually modify the firmware to ad malicious stuff?

Yes, if the device doesn't have proper security checks in place, specifically if it doesn't verify the digital signature of the firmware before installing it.

So if there's no signature check, then.

You can unpack the firmware, modify it, and repack it. There are tools like the Firmware Modkit FMK that help with this. You could, for instance, compile a small program that opens a bindshell basically listens on a network port for incoming connections backdoor exactly. You'd need to cross compile it for the device's architecture, say metpass. Tools like build

And then flash that malicious firmware onto the device yep.

If it accepts it because it's not checking signatures, the device reboots and your back door starts listening. You can then connect to it over the network, maybe using maps netcat and get a remote shell full control.

That's quite powerful both for finding flaws and for creating compromised devices.

Definitely, and there are even automated tools like firm walker that can scan an extracted firmware file system and automatically flagged potential issues hard coded keys, weak permissions, known vulnerable scripts, generates a quick report.

So firmware analysis is really about dissecting the devices brain, finding secrets, understanding its logic, and sometimes even modifying it.

That's the essence of it. It's a critical part of IoT security assessment.

Okay, we've covered the hardware, the firmware. What about the invisible part the radio waves? How do devices talk wirelessly and how is that exploited?

Ah? The radio communications? Yeah, this is often a really fruitful area for finding vulnerabilities, partly because it's less understood by many developers and it's literally invisible.

So how do security researchers see these invisible signals?

The key technology here is software defined radio or SDR.

SDR. What's the basic idea?

Instead of needing dedicated physical hardware for every different type of radio signal like an FM radio, a Wi Fi card, a Bluetooth chip, SDR lets you do most of the processing, receiving, transmitting, demodulating in software used relatively cheap, flexible radio hardware connected to your computer, and then powerful software handles the specifics of the radio protocol you're interested in.

So one piece of hardware can act like many different radios exactly.

It gives you incredible flexibility. For a basic lab, you might use Ubuntu Linux hardware. Why is something like the RTL SDR dongle is super cheap maybe twenty dollars great for receiving signals. For transmitting and receiving over a wider range, the hack RF is popular, though more expensive. Then you use software like GQRX for visualizing signals, GNU Radio for complex processing, and various command line tools specific to your hardware.

Okay, so you have the gear, how do you figure out what frequency a target device is?

Even using good question? Sometimes it's easy. Open up a simple device like a garage door keyfob, and you might literally see the frequency like four hundred and thirty three megahertz, print it on a component called.

An oscillator, look inside the hardware right.

Or as we discussed, use the SCCID. Look up a device like a wireless weather station on SECSID dot io using its ID, and the public filings will often tell you the exact operating frequency, say four hundred and thirty three point nine two mable hertz using public infogas YEP, and then you use your SDR software like GQRX to confirm it. You tune near that frequency and look for spikes in the spectrum display or signals in the waterfall

So you've found the frequency, you can see the signal. How do you understand what it's saying? How do you decode the data?

It depends on the complexity For many simple devices keyfobs, weather sensors, high pressure monitors. There's an amazing tool called ARDL four three three. It has built in decoders for hundreds of common devices. You just run it and when your keyfob transmits eard L four three three. You might recognize the signal and just print out the decoded data

In your radio, the complex processing software.

Right, you build a flow graph in G in your radio. You start with an SDR source block to capture the signal. Then you might add blocks to filter it, convert it, amplify it. You save into a file. You can then open that save signal file, maybe a dot wave file in an audio editor like Audacity.

Audacity for radio signals.

Yes, If you record the signal's amplitude, you can often visually analyze the waveform Inaudacity. You look for patterns is it on off keying okay, where pulses represent data or frequency shift king FSK for simple okay, like from that weather station. You might see short pulses for digital zeros and longer pulses for ones. You can literally just measure the pulse widths and manually decode the binary data packet.

Wow. Manual decoding that reveals the actual data.

Yep. You might decode a packet containing the station's ID the temperature, humidity, maybe a checksum.

Okay, decoding is one thing. What about replaying those signals you mentioned that earlier.

Replay attacks are very powerful, especially if the target device doesn't have good protection against them, like sequence numbers or proper checks them CRCs.

Meaning it just accepts any valid looking command A hears.

Pretty much. So you use SDR hardware capable of transmitting like the hacker F. You first use it to capture a legitimate radio packet, say the signal scent when you press the unlocked button on a car FIP, save that captured signal to a file. Then you just use the hack RF again to transmit the contents of that file. If the car doesn't have replay protection, and many older ones didn't, it will hear that replayed unlocked signal.

And unlocked simple but effective.

Very You can even use simpler hardware like an Arduino micro controller connected to a cheap four hundred thirty three milihertz transmitter module for basic replay attacks on some systems.

Okay, let's talk about specific protocols. ZIGB common in smart homes.

Right, very common. It's based on the IEEO two point one five point four standard operates usually around two point four gigger heerts globally and forms mesh networks where devices can relay messages for each other mesh network.

Okay, and how do you attack sigby?

First? You need hardware that can sniff zigby traffic, things like specially flashed at mil ars, raven USB sticks, or dedicated devices like the API mode often used with the killer B frame. Killer be cool name, Yeah, it's a popular Python framework. You start by using a tool like zib stumbler from killerb to scan the sixteen possible Zigbee channels and find which channel your target network is using.

Find the right frequency right.

Once you know the channel, say channel twenty, you use an tool like zibi dump or zib wire shark which integrates with wire shark, to just capture all the packets flying around on that.

Channel and what might you see?

If the communication isn't properly encrypted, which sometimes happens during initial device pairing or with poorly implemented systems, you might see sensitive data in clear text. We've seen examples where sniffing the pairing process of a vulnerable zigbi lock revealed the.

Network key, the master key for that whole network.

Yep, just by passively listening.

And replay attacks. Do they work? On Zigbe?

They can take the Phillips Hughes smart hub example. Again, using specialized Zigbie tools, researchers were able to capture the commands sent from the mobile app to change a light bulb's color. Because the system it didn't properly check if the command was fresh or unique. They could simply replay that captured packet later and the bulb would change color again without any reauthentication needed from the app.

Control without credentials, just by replaying old messages exactly. Okay, last Radio one Bluetooth Low Energy or BLE that's everywhere now, fitness trackers, headphones, everywhere.

Its big advantages are low power use and simplicity, making it ideal for battery powered gadgets. It's used in healthcare, smart homes, wearables, tons of applications.

How does it work? Briefly?

BLE devices advertise their presence when you connect. They expose things called services and characteristics. Think of services as categories of function like heart rate or battery level, and characteristics as the actual data points or controls within those services, like the heart rate value or a command to turn something on off. These are identified by unis numbers called UUIDs.

So interacting with the BLE device means reading or writing these characteristics pretty much.

First, you need a BLE dongle on your computer. Then you use tools like h tool s scan on Linux to scan for nearby BLE devices. You'll see their names and MTh addresses BDA d DR find your target right. Then you use a tool like gad tool to connect to the device using its address. Once connected, you can use commands like primary to list its services and char desk to list the characteristics within those services along with their unique handles short addresses.

And then you manipulate them.

Yep, you can read the current value of a characteristic using shar red and and its handle number, or more interestingly, you can write a new value using char rate rec the handle number and the new value in hexdesimal.

Give me an example.

Okay, say you have a simple BLEI tag tracker that beeps if you get too far from your phone. Maybe it disconnects too easily. You might find a characteristic related to connection parameters. You read its current value, then write a new value to try and keep it connected longer. Or on a proximity beacon might be an alert level characteristic standard ui D zero by two AO six six. You could write the value ero one to its handle to make the beacon start buzzing, or two to make

That seems quite powerful. What about sniffing and replaying.

BLE also possible? You need specialized hardware for reliable sniffing, like the ubertooth.

One ubertooth another cool name.

Yeah, you run uberto buttlef to follow connections from a specific device address and dump the captured packets to a PCC.

File and analyze that file exactly.

Open it. In wire shark, you can filter for BLE attribute protocol att packets which contain the read write requests for characteristics. You can see the handles being accessed and the data values being exchanged.

So you could see the exact hex value sent to turn a smart light red precisely.

Wider shark would show you the right request packet, the handle for the color characteristic, and the RGB values being sent oug fs zero zero zero for.

Red, and then you could just replay that value yourself.

Yep, go back to gat tool, connect to the light and use charwright rec with the correct handle and that ff zero zero zero value and the light should turn red. You've replicated the command without needing the original app. There are even guy tools like BTL Juice that try to automate this sniffing and replaying in real time.

So across all these radio protocols, the themes seem to be sniffing unencrypted data, finding wheak keys, and exploiting replay vulnerabilities.

Those are definitely some of the most common attack vectors in the radio space.

For IoT Wow, we've covered a lot of ground from the very beginnings of IoT and why it grew so insecurely.

Right the wild West phase and the lack of initial oversight.

To looking at specific sometimes scary hacks like the jeep or the insulin pump.

Learning from those past mistakes is crucial.

Then digging into the root causes fragmentation, developer awareness, supply.

Chains, understanding the why behind the vulnerabilities, and.

Then we got into the actual techniques, the pentester's process, mapping the attack surface.

The importance of that in reconnaissance.

The hardware tear downs, finding those secret ports like yort.

Getting physical with the device often the first step to deep.

Access, exploiting it two C and SPI to grab data or even the entire firmware.

Speaking of those low level hardware languages.

Then diving deep into that firmware, extracting it, finding secrets, emulating it, even backdooring.

It, analyzing the device's brain.

And finally exploring the invisible world of radio waves with SDR decoding signals, replaying commands over zigbie and ble.

Listening to the airwaves often a treasure trove of flaws. It's been quite a journey through the layers of IoT security, and hopefully this deep dive gives you a much more solid grasp of why these devices can be risky and the clever, sometimes complex ways these risks are uncovered and exploited. We wanted to make this complex field feel a bit more accessible.

Absolutely, you now have a much clearer picture of what's going on under the hood of all those smart devices you interact with every single day. And this knowledge isn't just for the tech experts, right, It's really about being a smarter, more critical consumer in this super connected world we.

Live in now, exactly, and maybe it leads you with the final thought to consider what other devices in your life. Things that seem totally ordinary or harmless might have surprising hidden layers or vulnerabilities, just waiting for someone to take a deep dive, or for a flaw to be found.