Speaker 1: Welcome to the deep dive. Today. We're jumping into something
Speaker 1: that's well, probably all around you right now, the Internet
Speaker 1: of things IoT. Think about it, you're smart speaker, your
Speaker 1: fitness tracker, maybe even medical devices. They're super convenient, right,
Speaker 1: but they also open up a whole new world of
Speaker 1: well potential problems vulnerabilities. So our mission today is to
Speaker 1: really get into the weeds of IoT security. It's fascinating stuff,
Speaker 1: sometimes a bit unsettling. We're using the IoT Hackers Handbook
Speaker 1: as our guide here, kind of a shortcut to understanding
Speaker 1: why these things are often insecure and how security pros
Speaker 1: and yeah, the bad guys too figure out how to
Speaker 1: break into them. By the end of this you'll have
Speaker 1: a much better handle on the tech behind your smart world,
Speaker 1: way more than just a news headline. Ready to dive in.
Speaker 1: All right, So where did this all kick off, this
Speaker 1: idea of connecting everything, Well, the.
Speaker 2: Term internet of things actually goes back to Kevin Ashty.
Speaker 2: He was thinking about RFID, you know, tracking physical.
Speaker 1: Stuff RFID right, like in inventory tags exactly.
Speaker 2: But then fast forward to June two thousand, LG actually
Speaker 2: launched an Internet connected fridge, the Internet digital dios maybe
Speaker 2: the first real IoT device.
Speaker 1: And internet fridge in two thousand.
Speaker 2: Wow. Yeah, bit ahead of its time maybe, But the
Speaker 2: real sort of tipping point when people really noticed was
Speaker 2: probably the nests hrmostat ah nest I remember that right
Speaker 2: when Google bought them at twenty eleven for was a
Speaker 2: three point two billion dollars That really signaled, wait, this
Speaker 2: is happening, this is a revolution.
Speaker 1: So the money started flowing and everyone wanted.
Speaker 2: In pretty much. And the thing is, policymakers, regulators, they
Speaker 2: just couldn't keep up with how fast it was growing.
Speaker 2: So you had this massive adoption of devices, but often
Speaker 2: without any real strict quality controls or safety rules.
Speaker 1: Meaning developers could kind of ignore security largely.
Speaker 2: Yeah, the pressure was just to get products out the
Speaker 2: door fast. Security was often.
Speaker 1: An afterthought until something big happened to us exactly.
Speaker 2: The big wake up call was the Maria botnet twenty
Speaker 2: sixteen that was genuinely alarming. Maria basically went after internet
Speaker 2: connected cameras, cheap ones. Mostly. It was brutally simple, really,
Speaker 2: it just tried common default user names and passwords like
Speaker 2: admin and pass. They're king defaults on millions of devices.
Speaker 2: It was like millions of front doors just left unlocked,
Speaker 2: and once it got in, it took over Liberia's entire internet,
Speaker 2: the whole country, whole country. Yeah, and then launched this
Speaker 2: massive DDoS attack distributed denial of service against DIN, a
Speaker 2: big internet infrastructure company that took down huge sites GitHub, Twitter, Reddit, Netflix,
Speaker 2: you name it all because of default passwords on cheap cameras.
Speaker 1: That's staggering. It shows how interconnected everything is and how
Speaker 1: weak links can cause chaos.
Speaker 2: Precisely, it was a systemic failure, not just a few
Speaker 2: bad devices.
Speaker 1: Has security gotten better since.
Speaker 2: Then, It's improved definitely slowly, but I wouldn't say devices
Speaker 2: are extremely safe even now, not by a long shot.
Speaker 2: We've seen researchers do things like takeover Phillips HU smart
Speaker 2: lights using drones. Drones how they found encryption keys just
Speaker 2: hard coded into the firmware, easy to grab, and they
Speaker 2: use zigbie the wireless protocol to spread the infection.
Speaker 1: So one light infects the next, YEP.
Speaker 2: And even earlier, back in twenty thirteen, Natistan Johnny showed
Speaker 2: he could cause permanent blackouts just by replaying old network messages.
Speaker 2: He just needed the device's m ASSE address, which isn't
Speaker 2: hard to get and could spoof commands. Basic stuff really
Speaker 2: but effective, which is.
Speaker 1: Worrying because these devices collect so much data about us.
Speaker 2: Right, absolutely, really intimate data, sometimes health data, what you
Speaker 2: do in your home. It's a huge privacy risk if
Speaker 2: they get hacked. But on the flip side, all these
Speaker 2: incidents have created a real demand for IoT security experts,
Speaker 2: people who know how to build this stuff securely, and
Speaker 2: people who know how to break.
Speaker 1: It the ethical hackers right, and.
Speaker 2: Companies are finally starting to offer bug bounties more often,
Speaker 2: paying researchers to find flaws before the criminals do.
Speaker 1: Okay, So it sounds like the rapid growth and lack
Speaker 1: of early overst so I created a bit of a mess.
Speaker 1: Maybe the best way to understand the risks is to
Speaker 1: look at some specific example some of those headline grabbing hacks.
Speaker 1: Let's start with the Nest thermistat. Again, you mentioned it earlier.
Speaker 2: Right, the Nest. So researchers found you could crash it,
Speaker 2: make it reboot just by sending specific Bluetooth signals.
Speaker 1: Just crash it. What's the big deal?
Speaker 2: Well, it created about a ninety second window where the thermistat
Speaker 2: was offline. Okay, and if you had a nest security
Speaker 2: camera link to it. That camera might also be affected
Speaker 2: or delayed. Ninety seconds could be enough for a burglar
Speaker 2: to slip past undetected.
Speaker 1: Ah. I see, so a security device actually created an
Speaker 1: insecurity exactly.
Speaker 2: Then there were those Phillips Hugh lights. We mentioned the
Speaker 2: drone attack exploiting the hard coded Zigbie.
Speaker 1: Keys right, the self spreading worm.
Speaker 2: Yep, and also that replay attack causing permanent blackouts that
Speaker 2: was also targeting Phillips gear exploiting easily guessable device IDs.
Speaker 1: It seems like basic communications security was often missing often.
Speaker 2: Yes, look at the lift at smart Bold. Another research
Speaker 2: Alex Chapman found he could inject malicious packets. He could
Speaker 2: actually decrypt the owner's Wi Fi password from the.
Speaker 1: Bulb get the Wi Fi password from a light bulb.
Speaker 2: Yeah, the key was he dumped the firmware, the bulb
Speaker 2: software using a hardware technique called JTAG, and right there
Speaker 2: in the code the AES encryption key, the initialization vector,
Speaker 2: everything needed to break the security. Wow.
Speaker 1: Okay, that's bad, but maybe not as viscerally scary as
Speaker 1: the GP pack.
Speaker 2: Ah. The jeep pack twenty fifteen, That one really got
Speaker 2: people's attention. Doctor Charlie Miller and Chris Vallisek.
Speaker 1: Legends what did they do exactly? I remember the headlines,
Speaker 1: but the details.
Speaker 2: They remotely took control of a Jeep Cherokee while it
Speaker 2: was driving miles away. They found a vulnerability in the
Speaker 2: U Connect infotainment system, specifically an open network port Port
Speaker 2: six six sixty seven running something called DBUS over IP,
Speaker 2: and through that they found a service that let them
Speaker 2: run their own code on the car's system, giving them
Speaker 2: control of the steering, brakes, headlights, transmission, wipers, radio, everything
Speaker 2: while someone was driving out on the highway.
Speaker 1: That is terrifying, actual physical danger from a software flaw.
Speaker 2: Absolutely. It led to a recall of one point four
Speaker 2: million vehicles. It showed that IoT security wasn't just about
Speaker 2: data theft. It could be about physical safety.
Speaker 1: And it's not just cars or light bulbs. You mentioned
Speaker 1: medical devices, right.
Speaker 2: Jay Radcliffe found a major issue with a Johnson and
Speaker 2: Johnson insulin pump, the Anima's one Touch pain. It communicated
Speaker 2: wirelessly but in clear text.
Speaker 1: No encryption for an insulin pump.
Speaker 2: That sounds critically extremely It meant someone nearby could capture
Speaker 2: the commands, maybe modify them and replay them. They could
Speaker 2: potentially change the insulin dosage delivered to a patient that
Speaker 2: could be lethal. Potentially. Yes. Thankfully, the vendor did patch
Speaker 2: it relatively quickly, within about five months, but it highlighted
Speaker 2: the risks in critical health devices.
Speaker 1: Even things like smart door locks have had problems.
Speaker 2: Oh yeah, tons of issues. One researcher, Jay Max, looked
Speaker 2: at the August smart lock. He found a way for
Speaker 2: someone with guest access to become an administrator. Oh just
Speaker 2: by intercepting the network traffic and changing a value from
Speaker 2: user to super user. Simple as that. Plus the firmware
Speaker 2: wasn't signed, meaning you could modify it and to bypassed
Speaker 2: some standard security check to other locks. Other researchers found
Speaker 2: locks sending passwords and plaintext over the network yep, or
Speaker 2: vulnerable to replay attacks, or using ridiculously weak hard coded
Speaker 2: encryption keys. One Dana loock model literally used the key
Speaker 2: this this secret, this the secret.
Speaker 1: You can't make this stuff.
Speaker 2: Up, you really can't. The pattern is just surprisingly weak
Speaker 2: security practices in many.
Speaker 1: Cases, even smart guns. That sounds like something from a.
Speaker 2: Movie, It does, but it's real. Tracking point makes smart rifles,
Speaker 2: you know, with computer raided targeting. Researchers Runas Sandvik and
Speaker 2: Michael Auger found they could get admin access through a
Speaker 2: physical port called art okay.
Speaker 1: And what could they do from there?
Speaker 2: They could launch network attacks to mess with the rifle's calculations.
Speaker 2: Change the wind velocity value or the bulletweight parameter.
Speaker 1: So the rifle would calculate the wrong shot.
Speaker 2: Exactly, making the shoot or miss without them even knowing.
Speaker 2: Why imagine the implications.
Speaker 1: Yeah, and you mentioned another one with magnets.
Speaker 2: Ah, right, the Armatix IP one smart gun. It had
Speaker 2: a safety feature linked to a special watch. Another researcher
Speaker 2: poor bypassed it using yes, just strong magnets. He could
Speaker 2: manipulate the firing mechanism directly, proving that sometimes a really
Speaker 2: low tech attack works just fine against poorly designed high
Speaker 2: tech security.
Speaker 1: So, looking at all these different examples, what's the common thread?
Speaker 2: I think what's fascinating and worrying is how it shows
Speaker 2: every part of an IoT device can be a weak
Speaker 2: point if it's not secured properly. The hardware itself, the firmware,
Speaker 2: the mobile app, the cloud service it talks to, the
Speaker 2: radio signals, any single component can be the point of failure.
Speaker 2: It's the whole chain.
Speaker 1: Okay, so we've seen what goes wrong, But why why
Speaker 1: are these vulnerabilities so common? What are the root causes?
Speaker 2: That's the crucial quest if we actually want to fix things,
Speaker 2: And there's several big reasons. One huge one is fragmentation.
Speaker 2: Fragmentation means the sheer number of different ways these devices
Speaker 2: talk to each other ZIGB Bluetooth, low energy, z wave,
Speaker 2: Wi Fi, Laura six to low PAN, dozens of protocols
Speaker 2: and software.
Speaker 1: Frameworks like a tower of Babbel for devices.
Speaker 2: Kinda yeah, it creates enormous complexity. There's no single standard
Speaker 2: everyone follows, and this lack of standardization makes it way
Speaker 2: easier for flaws to creep in. Plus, a lot of
Speaker 2: developers just grab a popular framework and kind of assume
Speaker 2: it's secure out of the box, which is often a
Speaker 2: really dangerous assumption.
Speaker 1: So the variety itself is a problem.
Speaker 2: What else, A big one is simply a lack of
Speaker 2: security awareness among developers. You mean they don't care. Not
Speaker 2: necessarily that they don't care, but they're often under immense
Speaker 2: pressure to ship products quickly. Deadlines are tight, and they
Speaker 2: might just not be trained or aware of the specific
Speaker 2: security pitfalls and IoT how hardware interacts with software, how
Speaker 2: RADI protocols can be abused. It's a specialized field.
Speaker 1: So they need better training and maybe stricter guidelines.
Speaker 2: Definitely regular security training, clear coding rules, security checklists baked
Speaker 2: into the development cycle. That's essential.
Speaker 1: Okay, what other factors?
Speaker 2: Another issue is what you might call a lack of
Speaker 2: a macro perspective. A macro perspective, yeah, meaning teams often
Speaker 2: focus too much on securing just one piece of the puzzle,
Speaker 2: Like they'll pentis the mobile app, but they won't look
Speaker 2: closely at how the app, the device, and the cloud
Speaker 2: all interact.
Speaker 1: Ah, so they miss the vulnerabilities that emerge from the
Speaker 1: connections between components exactly.
Speaker 2: They miss the forest for the trees. You need to
Speaker 2: look at the entire system architecture end to end and
Speaker 2: do proper threat modeling to see how everything connects and
Speaker 2: where the real risks lie.
Speaker 1: That makes sense. It's the Internet of things, after all,
Speaker 1: the connections matter.
Speaker 2: Right. Then there are supply chain issues.
Speaker 1: Supply chain like where the parts come from precisely.
Speaker 2: Think about how a complex device gets made. You might
Speaker 2: have one company making the process or another. The Wi
Speaker 2: Fi chip another, assembling it, another distributing it. Every step
Speaker 2: in that chain, every vendor involved, is an opportunity for
Speaker 2: a vulnerability to be introduced, either accidentally or maybe even deliberately.
Speaker 2: A backdoor could be slipped in at any point.
Speaker 1: Wow, that's complex. How do you even secure that?
Speaker 2: It's incredibly difficult. It requires a lot of trust and verification,
Speaker 2: which is hard to achieve globally.
Speaker 1: Okay, any other major causes.
Speaker 2: One last big one is the use of insecure frameworks
Speaker 2: and third party libraries.
Speaker 1: So developers using pre written code that's already flawed exactly.
Speaker 2: It's very common to grab existing code samples or libraries
Speaker 2: to speed up development. But if that code you're importing
Speaker 2: has vulnerabilities, well, now your product has those vulnerabilities too.
Speaker 2: And again, the business pressure to launch quickly often means
Speaker 2: proper security vetting of these third party components gets pushed.
Speaker 1: To the back burner until there's a breach.
Speaker 2: Until there's a breach. Sadly, that's often the trigger for
Speaker 2: taking it seriously.
Speaker 1: So putting it all together, it's a mix of complexities,
Speaker 1: speed to market pressure, lack of awareness, and issues baked
Speaker 1: into the whole process of building these things that.
Speaker 2: Sums it up pretty well. It's a complex ecosystem with
Speaker 2: security challenges at almost every level.
Speaker 1: Which, as you said, creates a huge demand for people
Speaker 1: who can find these flaws. The security professionals, the pen testers.
Speaker 1: How did they actually do it? What's their process?
Speaker 2: Right? So, an IoT penetration test or pentest is different
Speaker 2: from just testing a website or a regular application. It's
Speaker 2: about assessing everything the physical device, the firmware inside it,
Speaker 2: the radio communications, the mobile app, the cloud back end.
Speaker 2: The whole solution.
Speaker 1: Sounds comprehensive, it has to.
Speaker 2: Be, And interestingly, you often need multiple physical devices for
Speaker 2: testing because some techniques like physically taking chips off the
Speaker 2: board are well destructive. You might break a device or
Speaker 2: two finding vulnerabilities.
Speaker 1: Okay, so where do they start?
Speaker 2: The absolute foundation is a tax surface mapping. This is
Speaker 2: the recon phase. You gather as much in from possible
Speaker 2: before you even touch the device. Read the manuals, check
Speaker 2: the vendor's website, look for patents, search for previous research
Speaker 2: on similar devices, anything you can find.
Speaker 1: What kind of info are you looking for?
Speaker 2: Q details like what processor, cpu architectures it use, what
Speaker 2: communication protocols, Wi Fi, bl zigbie, Is there a mobile app.
Speaker 2: How does it get firmware updates? Does it have USB ports,
Speaker 2: FD card slots, any hardware ports? Visible?
Speaker 1: Building a complete picture, yes exactly.
Speaker 2: You can generally break down the attack surface into three
Speaker 2: big areas. First, the embedded device itself the thing. Can
Speaker 2: you open it? Are the debug ports inside like art
Speaker 2: or jtag? Can you dump the firmware directly from a
Speaker 2: chip is authentication week? Second the firmware software and applications.
Speaker 2: This is where traditional pen testing skills come in more
Speaker 2: analyzing the mobile app, the web dashboard if there is one,
Speaker 2: checking network services like SSH or FDP that might be
Speaker 2: running on the device, looking for hard coded passwords, weak authentication,
Speaker 2: logic flaws. And Third the radio communications. This is often
Speaker 2: overlooked by developers. Wi Fi security yes, but also ble
Speaker 2: zigb Z wave Laura. Can you sniff the traffic as
Speaker 2: it encrypted? Can you jam the signal? Can you perform
Speaker 2: replay attacks?
Speaker 1: So you map out all these potential entry points right.
Speaker 2: The goal is to create an architectural diagram, show all
Speaker 2: the components how they talk to each other, and then
Speaker 2: list every potential way an attacker might try to get
Speaker 2: in every attack vector.
Speaker 1: You mentioned something earlier about sec IDs.
Speaker 2: Ah Yes, a really practical tip. Almost every device that
Speaker 2: transmits radio waves has to have an SECID never printed
Speaker 2: on it somewhere. If you take that ID and search
Speaker 2: for it on the FCC website, specifically sites like sccside
Speaker 2: dot io, it's often a gold mine.
Speaker 1: Why what's there?
Speaker 2: You can find internal photos of the device before it's
Speaker 2: even released, sometimes detailed documents test reports. For example, looking
Speaker 2: up the FCCID for an edmax IP camera revealed internal
Speaker 2: photos clearly showing four little pads on the circuit board
Speaker 2: that strongly suggested a u AT interface, a key debug port,
Speaker 2: public information giving you a clue for hardware hacking.
Speaker 1: That's clever, using public data to find hidden doors.
Speaker 2: Okay, so once you've mapped the attack surface, what's next?
Speaker 2: You mentioned getting physical to tear down exactly?
Speaker 1: This is often where the real fun begins for hardware hackers,
Speaker 1: getting physical with the device, trying it open.
Speaker 2: Pretty much, the main goals here are things like extracting
Speaker 2: the firmware directly from memory chips, maybe getting a rootshell
Speaker 2: or command prompt on the device through a hidden port,
Speaker 2: connecting debuggers to see what the code is doing live,
Speaker 2: sometimes even modifying the hardware or writing custom firmware. And yeah,
Speaker 2: as I said, you need spare devices because you might
Speaker 2: break things.
Speaker 1: So how do you start the physical analysis? First?
Speaker 2: Is just external inspection. Look closely at the outside, what
Speaker 2: buttons are there, any obvious ports, ethernet, USBSD card, what
Speaker 2: kind of display does it have? Power requirements? And critically
Speaker 2: look for those certification labels like the STCID. Even note
Speaker 2: the type of screws holding it together. Sometimes you need
Speaker 2: special screwdriver just to get inside.
Speaker 1: Like on Apple devices.
Speaker 2: Exactly ped loavescrews, torques. Knowing that tells you something. For instance,
Speaker 2: looking at an old Navman GPS, you might note it
Speaker 2: runs Windows, CE has a Samsung ARM processor and see
Speaker 2: the USB, port, SD slot, et cetera. All clues.
Speaker 1: Then you actually open it up.
Speaker 2: Yeah, carefully. This is the internal inspection. You're looking at
Speaker 2: the printed circuit board PCB, identifying the main chips, the CPU, RAM,
Speaker 2: flash memory, where the firmware lives. You're also hunting for connectors, antennas,
Speaker 2: and especially those debug interfaces. We talked about pins or
Speaker 2: pads for your JTAG SPI. These are often the keys
Speaker 2: to unlocking the device.
Speaker 1: And those fcc ID lookups help here too massively.
Speaker 2: Again, that FCC database SCCI dot io is amazing. You
Speaker 2: might see internal photos there that clearly label the CPU
Speaker 2: model or show exactly where the ur pads are, saving
Speaker 2: you a ton of guesswork, like.
Speaker 1: Finding the blueprint before you pick the lock.
Speaker 2: Precisely that edmax camera example. Again, the SEC filing basically
Speaker 2: pointed right to the r pads, a huge headstar for
Speaker 2: anyone wanting to connect to it.
Speaker 1: Okay, so you've found these internal ports like u ART,
Speaker 1: how do you actually use them? How do you talk
Speaker 1: to the device's insights?
Speaker 2: Right? That's where understanding these low level communication protocols is key.
Speaker 2: Let's start with u ART Universal Asynchronous Receival Transmitter.
Speaker 1: Okay, what is it?
Speaker 2: Simply, it's a really common, simple way for chips to
Speaker 2: talk serially one bit after another. It doesn't need a
Speaker 2: shared clock signal, which makes it easy to implement. Think
Speaker 2: of it like a basic direct serial chat line between components.
Speaker 1: And how do you exploit it?
Speaker 2: First, you need to identify the pins on the circuit
Speaker 2: board ground G and D, transmit TX, receive RX and
Speaker 2: sometimes power VCC. You can often find these using.
Speaker 1: A multimeter testing voltages and continuity exactly.
Speaker 2: Yeah, Then you need a tool to connect your computer
Speaker 2: to these pins, something like an FTDI adapter or a
Speaker 2: specialized tool like the Adify badge works well. You connect
Speaker 2: your tools TX to the devices RX, RX to TX
Speaker 2: and ground to ground. You usually leave the VCC power
Speaker 2: pin disconnected. Why because the device is usually already powered on.
Speaker 2: You don't want to feed it extra voltage. Then you
Speaker 2: need to figure out the speed the bod rate they're
Speaker 2: talking at. There are tools like bodrate dot PI that
Speaker 2: can automatically detect this.
Speaker 1: Okay, you've got the pins, the speed, then what Then?
Speaker 2: You just use a simple terminal program on your computer
Speaker 2: like screen or Mini coom, connect to the serial port
Speaker 2: provided by your tool, and very often, especially on cheaper
Speaker 2: or older devices, you'll just get dropped straight into a
Speaker 2: command prompt, often a rootshell.
Speaker 1: Meaning full administrative control, no password needed.
Speaker 2: Yep, an unauthenticated root shell over art. It's a surprisingly
Speaker 2: common and critical vulnerability. We found this on that Atmax
Speaker 2: camera for example, instant root access just by soldering three wires.
Speaker 1: Wow, okay, what about other protocols you mentioned I two
Speaker 1: C right, IT two.
Speaker 2: C integrated circuit. There is another common one, but it's
Speaker 2: a bus protocol, meaning multiple chips can share the same
Speaker 2: two wires SDA for data and SEL for the clock signal.
Speaker 1: So it's like a little internal network kind of.
Speaker 2: Yeah. It's used for slower communication between components like e
Speaker 2: proms small memory chips that store configuration data, real time clocks, sensors,
Speaker 2: things like that.
Speaker 1: And how is that useful for hacking?
Speaker 2: Well, if important data like settings or maybe even keys
Speaker 2: are stored in an e PROM chip that uses IT
Speaker 2: two C, you can often read or write directly to
Speaker 2: that chip. You'd find that chip on the board, look
Speaker 2: up its data sheet to understand how to talk to it.
Speaker 2: Connect your tool against something like the adify badge using
Speaker 2: clips or an.
Speaker 1: Adapter directly onto the chip yep, clip.
Speaker 2: Right onto the legs. If possible, then you use software
Speaker 2: like scripts often called I two C PROM dot PI
Speaker 2: or similar to communicate over I two C and dump
Speaker 2: the contents of the memory or even write new data
Speaker 2: back to.
Speaker 1: It, so you could potentially change device settings stored in
Speaker 1: that memory exactly.
Speaker 2: Maybe disable a security feature, or extract some sensitive configuration data.
Speaker 1: Okay, one more SPI.
Speaker 2: SPI Serial Peripheral interface another bus protocol generally faster than
Speaker 2: I two C. It uses separate lines for data going
Speaker 2: in OSI master out, slave in and data coming out
Speaker 2: misomaster enslave out, plus a clock SK and a chip
Speaker 2: select line SS to choose which device you're talking to.
Speaker 1: Faster, more wires. What's his main use case in hacking?
Speaker 2: The big one for SPI is often dumping the entire
Speaker 2: firmware directly from the main flash.
Speaker 1: Memory chip AH getting the device's brain out precisely.
Speaker 2: Many devices store their operating system and all their software
Speaker 2: on a flash chip that communicates using SPI, so similar
Speaker 2: process find the chip, identify the SPI pins, mobiles, MISO, skcs,
Speaker 2: VCCG and D connect your tool, and then use a
Speaker 2: utility like spyflash dot PI. I often use with tools
Speaker 2: like the ATIFI badge or flashroom to read the entire
Speaker 2: contents of.
Speaker 1: That chip, and that gives you the firmware file exactly.
Speaker 2: You get a binary file containing everything. For example, on
Speaker 2: a device like the WRT node router, you can use
Speaker 2: SPI to pull the full OpenWrt firmware off its flash chip.
Speaker 2: Then you can start analyzing that firmware offline.
Speaker 1: So these low level portocols r at I two ce SPI.
Speaker 1: They're like the secret back doors into the device's hardware,
Speaker 1: letting you get shells or extract the firmware.
Speaker 2: That's a good way to put it. They bypass a
Speaker 2: lot of the normal software security because you're talking directly
Speaker 2: to the hardware components.
Speaker 1: Which leads perfectly into the next stage. You got the
Speaker 1: firmware file, Now, what how do you crack that open?
Speaker 2: Right? So you've managed to get the firmware, either by
Speaker 2: downloading it, sniffing it during an update, or dumping it
Speaker 2: via hardware like SBI. Now the real analysis begins, and
Speaker 2: having that firmware file is huge for a security researcher.
Speaker 2: It's arguably the most critical component because it lets you
Speaker 2: understand the device's logic, find vulnerabilities, look for secrets, all
Speaker 2: without needing the physical device anymore potentially.
Speaker 1: So first step is usually unpacking it. You mentioned it's
Speaker 1: often compressed exactly.
Speaker 2: Firmware files are often archives containing a file system, bootloaders,
Speaker 2: maybe a kernel. You can try manually analyzing it first,
Speaker 2: use tools like file to see what type of file
Speaker 2: it is, strings to look for readable text, hex dump
Speaker 2: to look at the raw bytes. Sometimes you can spot
Speaker 2: signatures of and filesystems like squash fs. Just by looking
Speaker 2: at the hex you might see the magic bytes.
Speaker 1: H excludes in the raw data.
Speaker 2: Yeah, and if you find something like squash fs, you
Speaker 2: can use tools like dd to carve out that section
Speaker 2: of the firmware file and then use unsquash to extract
Speaker 2: the actual filesystem.
Speaker 1: Sounds a bit involved? Is there an easier way?
Speaker 2: Oh? Yeah? The go to tool here is binwalk. It's fantastic.
Speaker 1: Binwalk. What does it do?
Speaker 2: It automatically scans firmware files for known file signatures, compression types,
Speaker 2: executable code, everything. You just run binwalk on the firmware file,
Speaker 2: it'll tell you okay, at this offset there's a header.
Speaker 2: At this offset, there's a squash fs filesystem. At this
Speaker 2: offset maybe some GFFS two data.
Speaker 1: It maps out the structure exactly.
Speaker 2: And even better, you can run binwalk de for extract
Speaker 2: and it will try to automatically carve out and extract
Speaker 2: everything it finds into a folder. Usually gives you a
Speaker 2: firmware dot extracted directory containing the filesystem like squashroot. Super convenient.
Speaker 1: Okay, so now you have the filesystem laid out, what
Speaker 1: are you looking for.
Speaker 2: Inside one of The first things is hard coded secrets, passwords,
Speaker 2: API keys, private encryption keys. Developers sometimes mistakenly embed these
Speaker 2: directly into scripts or configuration files.
Speaker 1: You just search for them pretty much.
Speaker 2: You'd use rep to search recursively through the entire extract
Speaker 2: and file system for keywords like password, key, secret, admin token,
Speaker 2: or maybe specific service names like Telnet FDP, and.
Speaker 1: You might find default credentials.
Speaker 2: Absolutely, you might find a script like telnetdat dot ashesh
Speaker 2: that starts the Telnet service with a default login like
Speaker 2: root and password happens all the time.
Speaker 1: Okay, but what if bin walk can't extract anything? What
Speaker 1: if the firmware just looks like random data.
Speaker 2: Ah, that's a strong sign it might be encrypted or
Speaker 2: maybe heavily obfuscated, So gameover not necessarily. First step is
Speaker 2: often to look at the entropy. How random the data looks.
Speaker 2: Tools can measure this. High entropy suggests encryption or compression.
Speaker 2: Then you might use hext se again to look at
Speaker 2: the raw bytes. Even with encryption, sometimes you can spot.
Speaker 1: Patterns, patterns and encrypted data.
Speaker 2: How especially with simpler encryption methods like xor if the
Speaker 2: same key is used repeatedly, you might see repeating byte
Speaker 2: patterns in the ciphertext. You might even be able to
Speaker 2: guess the key length, or if you're lucky and have
Speaker 2: some known plaintext like a standard file header that should
Speaker 2: be there, you could potentially deduce the xor key itself.
Speaker 1: So you figure out the key.
Speaker 2: Then you can write a simple script, maybe in Python,
Speaker 2: to apply the xor operation with that key to the
Speaker 2: entire encrypted firmware file and hopefully out pops the decrypted.
Speaker 1: Firmware and then binwok can work on it exactly.
Speaker 2: Once it's decrypted, you run binwalk again, extract the file
Speaker 2: system and continue your analysis, maybe dive deeper into specific
Speaker 2: executable files using reverse engineering tools like guedro or radar
Speaker 2: two to understand their logic.
Speaker 1: Okay, this is getting deep. What about actually running the
Speaker 1: code you find? Can you do that?
Speaker 2: Yes? But it's tricky because IoT devices use different process
Speaker 2: or architectures. Arm mips are common, not the by eighty
Speaker 2: six your laptop.
Speaker 1: Uses, so the code won't run directly on your computer.
Speaker 2: Correct, But we can use emulation. The most common tool
Speaker 2: for this is keemu U. Yeah, keemu provides userspace emulation.
Speaker 2: You can take say a memo binary from the firmware
Speaker 2: and run it on your by eighty six Linux machine
Speaker 2: using Chemo mipsel static. You copy the right chemostatic binary
Speaker 2: into the extracted firmware's filesystem, then use a command called
Speaker 2: troot to make that extracted directory act like the root
Speaker 2: file system. Now, inside that trute environment, you can run
Speaker 2: the firmware's own programs like it's BusyBox shell or other
Speaker 2: utilities using chemu behind.
Speaker 1: The scenes, so you can interact with the device's software
Speaker 1: environment without the device exactly.
Speaker 2: Yeah, but that's just running individual programs. What's even more
Speaker 2: powerful is full system emulation. There are specialized toolkits, like
Speaker 2: the Firmware Analysis Toolkit FAT or Fermidine designed to emulate
Speaker 2: the entire firmware image. What's the advantage of that It
Speaker 2: tries to boot the whole emulated device, It sets up
Speaker 2: networking start services. It means you can often access the
Speaker 2: device's web interface through your browser, interact with its network
Speaker 2: services attached debuggers. It's like having a virtual version of
Speaker 2: the physical device running.
Speaker 1: That sounds incredibly useful for testing find web vulnerabilities network flaws.
Speaker 2: Absolutely, you could test a netgear firmware, for example, emulate
Speaker 2: it with FAT and then access its weblogin page. Maybe
Speaker 2: try default credentials like admin passwork.
Speaker 1: Okay, one more thing here, backdooring firmware. Can you actually
Speaker 1: modify the firmware to ad malicious stuff?
Speaker 2: Yes, if the device doesn't have proper security checks in place,
Speaker 2: specifically if it doesn't verify the digital signature of the
Speaker 2: firmware before installing it.
Speaker 1: So if there's no signature check, then.
Speaker 2: You can unpack the firmware, modify it, and repack it.
Speaker 2: There are tools like the Firmware Modkit FMK that help
Speaker 2: with this. You could, for instance, compile a small program
Speaker 2: that opens a bindshell basically listens on a network port
Speaker 2: for incoming connections backdoor exactly. You'd need to cross compile
Speaker 2: it for the device's architecture, say metpass. Tools like build
Speaker 2: root can help with that. Then you inject your compiled
Speaker 2: backdoor program into the firmware's file system, maybe modify a
Speaker 2: startup script system dot SHA or some so your backdoor
Speaker 2: runs automatically when the device boots. Then you use fnk's
Speaker 2: build firmware dosh script to repack it all into a
Speaker 2: new firmware file.
Speaker 1: And then flash that malicious firmware onto the device yep.
Speaker 2: If it accepts it because it's not checking signatures, the
Speaker 2: device reboots and your back door starts listening. You can
Speaker 2: then connect to it over the network, maybe using maps
Speaker 2: netcat and get a remote shell full control.
Speaker 1: That's quite powerful both for finding flaws and for creating
Speaker 1: compromised devices.
Speaker 2: Definitely, and there are even automated tools like firm walker
Speaker 2: that can scan an extracted firmware file system and automatically
Speaker 2: flagged potential issues hard coded keys, weak permissions, known vulnerable scripts,
Speaker 2: generates a quick report.
Speaker 1: So firmware analysis is really about dissecting the devices brain,
Speaker 1: finding secrets, understanding its logic, and sometimes even modifying it.
Speaker 2: That's the essence of it. It's a critical part of
Speaker 2: IoT security assessment.
Speaker 1: Okay, we've covered the hardware, the firmware. What about the
Speaker 1: invisible part the radio waves? How do devices talk wirelessly
Speaker 1: and how is that exploited?
Speaker 2: Ah? The radio communications? Yeah, this is often a really
Speaker 2: fruitful area for finding vulnerabilities, partly because it's less understood
Speaker 2: by many developers and it's literally invisible.
Speaker 1: So how do security researchers see these invisible signals?
Speaker 2: The key technology here is software defined radio or SDR.
Speaker 1: SDR. What's the basic idea?
Speaker 2: Instead of needing dedicated physical hardware for every different type
Speaker 2: of radio signal like an FM radio, a Wi Fi card,
Speaker 2: a Bluetooth chip, SDR lets you do most of the processing, receiving, transmitting,
Speaker 2: demodulating in software used relatively cheap, flexible radio hardware connected
Speaker 2: to your computer, and then powerful software handles the specifics
Speaker 2: of the radio protocol you're interested in.
Speaker 1: So one piece of hardware can act like many different
Speaker 1: radios exactly.
Speaker 2: It gives you incredible flexibility. For a basic lab, you
Speaker 2: might use Ubuntu Linux hardware. Why is something like the
Speaker 2: RTL SDR dongle is super cheap maybe twenty dollars great
Speaker 2: for receiving signals. For transmitting and receiving over a wider range,
Speaker 2: the hack RF is popular, though more expensive. Then you
Speaker 2: use software like GQRX for visualizing signals, GNU Radio for
Speaker 2: complex processing, and various command line tools specific to your hardware.
Speaker 1: Okay, so you have the gear, how do you figure
Speaker 1: out what frequency a target device is?
Speaker 2: Even using good question? Sometimes it's easy. Open up a
Speaker 2: simple device like a garage door keyfob, and you might
Speaker 2: literally see the frequency like four hundred and thirty three megahertz,
Speaker 2: print it on a component called.
Speaker 1: An oscillator, look inside the hardware right.
Speaker 2: Or as we discussed, use the SCCID. Look up a
Speaker 2: device like a wireless weather station on SECSID dot io
Speaker 2: using its ID, and the public filings will often tell
Speaker 2: you the exact operating frequency, say four hundred and thirty
Speaker 2: three point nine two mable hertz using public infogas YEP,
Speaker 2: and then you use your SDR software like GQRX to
Speaker 2: confirm it. You tune near that frequency and look for
Speaker 2: spikes in the spectrum display or signals in the waterfall
Speaker 2: view that appear when the device transmits. That lets you
Speaker 2: pinpoint the exact frequency like maybe four hundred and thirty
Speaker 2: three point eighty nine seven mitlhertz for that keyfob.
Speaker 1: So you've found the frequency, you can see the signal.
Speaker 1: How do you understand what it's saying? How do you
Speaker 1: decode the data?
Speaker 2: It depends on the complexity For many simple devices keyfobs,
Speaker 2: weather sensors, high pressure monitors. There's an amazing tool called
Speaker 2: ARDL four three three. It has built in decoders for
Speaker 2: hundreds of common devices. You just run it and when
Speaker 2: your keyfob transmits eard L four three three. You might
Speaker 2: recognize the signal and just print out the decoded data
Speaker 2: like the button code being sent. That sounds easy for
Speaker 2: simple things it often is, but for more complex or
Speaker 2: unknown signals you need to do more work, often using G.
Speaker 1: In your radio, the complex processing software.
Speaker 2: Right, you build a flow graph in G in your radio.
Speaker 2: You start with an SDR source block to capture the signal.
Speaker 2: Then you might add blocks to filter it, convert it,
Speaker 2: amplify it. You save into a file. You can then
Speaker 2: open that save signal file, maybe a dot wave file
Speaker 2: in an audio editor like Audacity.
Speaker 1: Audacity for radio signals.
Speaker 2: Yes, If you record the signal's amplitude, you can often
Speaker 2: visually analyze the waveform Inaudacity. You look for patterns is
Speaker 2: it on off keying okay, where pulses represent data or
Speaker 2: frequency shift king FSK for simple okay, like from that
Speaker 2: weather station. You might see short pulses for digital zeros
Speaker 2: and longer pulses for ones. You can literally just measure
Speaker 2: the pulse widths and manually decode the binary data packet.
Speaker 1: Wow. Manual decoding that reveals the actual data.
Speaker 2: Yep. You might decode a packet containing the station's ID
Speaker 2: the temperature, humidity, maybe a checksum.
Speaker 1: Okay, decoding is one thing. What about replaying those signals
Speaker 1: you mentioned that earlier.
Speaker 2: Replay attacks are very powerful, especially if the target device
Speaker 2: doesn't have good protection against them, like sequence numbers or
Speaker 2: proper checks them CRCs.
Speaker 1: Meaning it just accepts any valid looking command A hears.
Speaker 2: Pretty much. So you use SDR hardware capable of transmitting
Speaker 2: like the hacker F. You first use it to capture
Speaker 2: a legitimate radio packet, say the signal scent when you
Speaker 2: press the unlocked button on a car FIP, save that
Speaker 2: captured signal to a file. Then you just use the
Speaker 2: hack RF again to transmit the contents of that file.
Speaker 2: If the car doesn't have replay protection, and many older
Speaker 2: ones didn't, it will hear that replayed unlocked signal.
Speaker 1: And unlocked simple but effective.
Speaker 2: Very You can even use simpler hardware like an Arduino
Speaker 2: micro controller connected to a cheap four hundred thirty three
Speaker 2: milihertz transmitter module for basic replay attacks on some systems.
Speaker 1: Okay, let's talk about specific protocols. ZIGB common in smart homes.
Speaker 2: Right, very common. It's based on the IEEO two point
Speaker 2: one five point four standard operates usually around two point
Speaker 2: four gigger heerts globally and forms mesh networks where devices
Speaker 2: can relay messages for each other mesh network.
Speaker 1: Okay, and how do you attack sigby?
Speaker 2: First? You need hardware that can sniff zigby traffic, things
Speaker 2: like specially flashed at mil ars, raven USB sticks, or
Speaker 2: dedicated devices like the API mode often used with the
Speaker 2: killer B frame. Killer be cool name, Yeah, it's a
Speaker 2: popular Python framework. You start by using a tool like
Speaker 2: zib stumbler from killerb to scan the sixteen possible Zigbee
Speaker 2: channels and find which channel your target network is using.
Speaker 1: Find the right frequency right.
Speaker 2: Once you know the channel, say channel twenty, you use
Speaker 2: an tool like zibi dump or zib wire shark which
Speaker 2: integrates with wire shark, to just capture all the packets
Speaker 2: flying around on that.
Speaker 1: Channel and what might you see?
Speaker 2: If the communication isn't properly encrypted, which sometimes happens during
Speaker 2: initial device pairing or with poorly implemented systems, you might
Speaker 2: see sensitive data in clear text. We've seen examples where
Speaker 2: sniffing the pairing process of a vulnerable zigbi lock revealed the.
Speaker 1: Network key, the master key for that whole network.
Speaker 2: Yep, just by passively listening.
Speaker 1: And replay attacks. Do they work? On Zigbe?
Speaker 2: They can take the Phillips Hughes smart hub example. Again,
Speaker 2: using specialized Zigbie tools, researchers were able to capture the
Speaker 2: commands sent from the mobile app to change a light
Speaker 2: bulb's color. Because the system it didn't properly check if
Speaker 2: the command was fresh or unique. They could simply replay
Speaker 2: that captured packet later and the bulb would change color
Speaker 2: again without any reauthentication needed from the app.
Speaker 1: Control without credentials, just by replaying old messages exactly. Okay,
Speaker 1: last Radio one Bluetooth Low Energy or BLE that's everywhere now,
Speaker 1: fitness trackers, headphones, everywhere.
Speaker 2: Its big advantages are low power use and simplicity, making
Speaker 2: it ideal for battery powered gadgets. It's used in healthcare,
Speaker 2: smart homes, wearables, tons of applications.
Speaker 1: How does it work? Briefly?
Speaker 2: BLE devices advertise their presence when you connect. They expose
Speaker 2: things called services and characteristics. Think of services as categories
Speaker 2: of function like heart rate or battery level, and characteristics
Speaker 2: as the actual data points or controls within those services,
Speaker 2: like the heart rate value or a command to turn
Speaker 2: something on off. These are identified by unis numbers called UUIDs.
Speaker 1: So interacting with the BLE device means reading or writing
Speaker 1: these characteristics pretty much.
Speaker 2: First, you need a BLE dongle on your computer. Then
Speaker 2: you use tools like h tool s scan on Linux
Speaker 2: to scan for nearby BLE devices. You'll see their names
Speaker 2: and MTh addresses BDA d DR find your target right.
Speaker 2: Then you use a tool like gad tool to connect
Speaker 2: to the device using its address. Once connected, you can
Speaker 2: use commands like primary to list its services and char
Speaker 2: desk to list the characteristics within those services along with
Speaker 2: their unique handles short addresses.
Speaker 1: And then you manipulate them.
Speaker 2: Yep, you can read the current value of a characteristic
Speaker 2: using shar red and and its handle number, or more interestingly,
Speaker 2: you can write a new value using char rate rec
Speaker 2: the handle number and the new value in hexdesimal.
Speaker 1: Give me an example.
Speaker 2: Okay, say you have a simple BLEI tag tracker that
Speaker 2: beeps if you get too far from your phone. Maybe
Speaker 2: it disconnects too easily. You might find a characteristic related
Speaker 2: to connection parameters. You read its current value, then write
Speaker 2: a new value to try and keep it connected longer.
Speaker 2: Or on a proximity beacon might be an alert level
Speaker 2: characteristic standard ui D zero by two AO six six.
Speaker 2: You could write the value ero one to its handle
Speaker 2: to make the beacon start buzzing, or two to make
Speaker 2: it buzz louder. You're directly controlling the device by writing
Speaker 2: to these characteristics.
Speaker 1: That seems quite powerful. What about sniffing and replaying.
Speaker 2: BLE also possible? You need specialized hardware for reliable sniffing,
Speaker 2: like the ubertooth.
Speaker 1: One ubertooth another cool name.
Speaker 2: Yeah, you run uberto buttlef to follow connections from a
Speaker 2: specific device address and dump the captured packets to a PCC.
Speaker 1: File and analyze that file exactly.
Speaker 2: Open it. In wire shark, you can filter for BLE
Speaker 2: attribute protocol att packets which contain the read write requests
Speaker 2: for characteristics. You can see the handles being accessed and
Speaker 2: the data values being exchanged.
Speaker 1: So you could see the exact hex value sent to
Speaker 1: turn a smart light red precisely.
Speaker 2: Wider shark would show you the right request packet, the
Speaker 2: handle for the color characteristic, and the RGB values being
Speaker 2: sent oug fs zero zero zero for.
Speaker 1: Red, and then you could just replay that value yourself.
Speaker 2: Yep, go back to gat tool, connect to the light
Speaker 2: and use charwright rec with the correct handle and that
Speaker 2: ff zero zero zero value and the light should turn red.
Speaker 2: You've replicated the command without needing the original app. There
Speaker 2: are even guy tools like BTL Juice that try to
Speaker 2: automate this sniffing and replaying in real time.
Speaker 1: So across all these radio protocols, the themes seem to
Speaker 1: be sniffing unencrypted data, finding wheak keys, and exploiting replay vulnerabilities.
Speaker 2: Those are definitely some of the most common attack vectors
Speaker 2: in the radio space.
Speaker 1: For IoT Wow, we've covered a lot of ground from
Speaker 1: the very beginnings of IoT and why it grew so insecurely.
Speaker 2: Right the wild West phase and the lack of initial oversight.
Speaker 1: To looking at specific sometimes scary hacks like the jeep
Speaker 1: or the insulin pump.
Speaker 2: Learning from those past mistakes is crucial.
Speaker 1: Then digging into the root causes fragmentation, developer awareness, supply.
Speaker 2: Chains, understanding the why behind the vulnerabilities, and.
Speaker 1: Then we got into the actual techniques, the pentester's process,
Speaker 1: mapping the attack surface.
Speaker 2: The importance of that in reconnaissance.
Speaker 1: The hardware tear downs, finding those secret ports like yort.
Speaker 2: Getting physical with the device often the first step to deep.
Speaker 1: Access, exploiting it two C and SPI to grab data
Speaker 1: or even the entire firmware.
Speaker 2: Speaking of those low level hardware languages.
Speaker 1: Then diving deep into that firmware, extracting it, finding secrets,
Speaker 1: emulating it, even backdooring.
Speaker 2: It, analyzing the device's brain.
Speaker 1: And finally exploring the invisible world of radio waves with
Speaker 1: SDR decoding signals, replaying commands over zigbie and ble.
Speaker 2: Listening to the airwaves often a treasure trove of flaws.
Speaker 2: It's been quite a journey through the layers of IoT security,
Speaker 2: and hopefully this deep dive gives you a much more
Speaker 2: solid grasp of why these devices can be risky and
Speaker 2: the clever, sometimes complex ways these risks are uncovered and exploited.
Speaker 2: We wanted to make this complex field feel a bit
Speaker 2: more accessible.
Speaker 1: Absolutely, you now have a much clearer picture of what's
Speaker 1: going on under the hood of all those smart devices
Speaker 1: you interact with every single day. And this knowledge isn't
Speaker 1: just for the tech experts, right, It's really about being
Speaker 1: a smarter, more critical consumer in this super connected world we.
Speaker 2: Live in now, exactly, and maybe it leads you with
Speaker 2: the final thought to consider what other devices in your life.
Speaker 2: Things that seem totally ordinary or harmless might have surprising
Speaker 2: hidden layers or vulnerabilities, just waiting for someone to take
Speaker 2: a deep dive, or for a flaw to be found.