There is a moment in the life of anyone who enjoys taking things apart when "how does this work" stops being enough and gives way to "what happens if I use it differently from how it was intended".
For me the first part, plain curiosity about electronics, came long before any thought about security. I simply wanted to know what was inside things.
Before the word "pentest" showed up
Electronics interested me long before I worked in security professionally. Not in any systematic way, more the way it usually starts: open it up, look inside, try to work out what that particular chip is for and why it is where it is.
In parallel I was learning to program, including on CS50x, where a good deal of the work is in C. That turned out not to be a coincidence but one of the best things that could have happened to me before moving into embedded work.
C teaches three things that are invaluable in the world of devices. First, that memory is just a region of bytes, not a magical abstraction. Second, that a pointer can point anywhere, including where it should not. Third, that the programmer owns the boundaries, because nobody else will handle them. When you later look at the firmware of a device that costs fifty euros and has two hundred kilobytes of memory, that is exactly the right frame of mind.
RFID, the first time I saw what "secure" means in practice
After joining Bosch I ran into subjects I previously knew about at roughly the level of a technology news reader. One of them was contactless card security testing. Colleagues with more experience showed me things that impress mostly by how simple they are.
The best illustration of this topic is a story from my own city: the Warsaw City Card.
The card ran on MIFARE Classic, built around the proprietary Crypto1 cipher, designed as a secret algorithm. That is the classic mistake cryptography has warned about since Kerckhoffs: security cannot rest on nobody knowing the algorithm. In 2008 researchers broke Crypto1, recovering the 48-bit key. A year later another team demonstrated attacks requiring only the ability to communicate with the card, partly because the random number generator turned out to depend on how much time had passed since the chip powered up.
The practical consequences in Warsaw dragged on for years. Illegal top-ups became widespread from around mid-2011, and the transport authority at one point invalidated tickets belonging to roughly ten thousand people, which became a prosecution matter. Writing a fake contract required only an NFC-capable phone and the right app, and such tickets were indistinguishable during a routine inspection.
For the record and without dressing it up: that was a crime and people were held responsible for it. Glorification is not the point here.
The point is the lesson that landed with me then and kept being confirmed on every subsequent project. The flaw was publicly known for several years before anyone exploited it at scale. The knowledge existed, the papers existed, and the system kept running on a broken cipher, because replacing infrastructure costs money and, as long as nobody is stealing, the problem is theoretical.
In IoT security that is the rule, not the exception. We rarely lose because the adversary is brilliant. Far more often we lose because the cost of fixing lands today and the cost of not fixing lands in three years.
One technical note worth adding: newer card families such as MIFARE DESFire use open, standard algorithms. That is not fashion, it is precisely this lesson applied at the design level.
Bosch, or pentesting on commission
At Bosch I worked in a department carrying out security testing commissioned by external clients. That is a convenient situation, because the existence of such a service is public information, so I can write about it while observing the obvious rule: I do not name clients and I do not describe specific findings in specific products.
What I can describe are the categories of hardware that passed through our hands, because that alone is interesting. Robot vacuums. Kitchen extractor hoods with wireless connectivity. Microwaves. An oven. Broadly: things that a decade ago had no business having an IP address and today ship with a mobile app, a Wi-Fi module and BLE.
And that is exactly the point where the subject turns serious. Not because someone will take over your microwave. Because that microwave sits on the same home network as your laptop, holds a permanent connection to the manufacturer's cloud, and was designed by a team whose main engineering problem was heating food evenly.
What testing an IoT device actually looks like
Leaving project specifics aside, the shape of the work is worth describing, because people arriving from web pentesting often find it surprising. The attack surface spreads across several layers, and each is practically a separate specialisation.
Physical and hardware layer. Opening the enclosure, identifying chips, finding service interfaces, reaching memory. This is where a soldering iron and patience earn their keep.
Firmware. Obtaining an image, unpacking it, analysing the filesystem, hunting for embedded credentials, keys, forgotten diagnostic tooling and binaries nobody stripped from the production build.
Wireless communication. Wi-Fi, BLE, sometimes proprietary protocols. The interesting questions are: is the traffic encrypted, does the device verify who it is talking to, and can pairing be performed by someone who should have no such option.
Mobile app and cloud. This is where the IoT world circles back to classic application and API security. And often this is where the most serious problems live, because a flaw in a cloud API affects every unit of the device in the world at once, not just the one on your desk.
Updates. Do they exist, are they signed, is the signature actually verified, and can an older build be installed in which a fixed flaw was still present.
Each of those layers is separate effort, which is why testing a device costs more than testing an application. How much a penetration test costs breaks that down, and how to prepare for a penetration test covers what is worth having ready before handing a unit over.
The findings that came up most often
Here I will describe classes of problems rather than specific cases, because the classes are far more interesting. A specific finding belongs to the client and expires with the patch, whereas the pattern persists.
Open UART. The serial interface, used during development to read logs and reach a console, can survive into production entirely unprotected. You attach to the pads on the board and get what the developer saw while debugging, sometimes including a shell. This is one of the most common and most mundane problems across all of IoT.
Key material where it has no business being. Keys and other sensitive values are sometimes held in ways that allow them to be read, for instance because the data preparation sequence leaves them in memory in plaintext, or because they are written straight into the firmware image. The same key across every unit of a product is a classic of its own: breaking one device then grants access to the entire production run.
No verification of the other party. The device trusts whoever connects to it, because the manufacturer's threat model assumed only the legitimate user app ever would.
Forgotten developer functionality. Service modes, hidden commands, diagnostic tools. Nobody removed them, because nobody was keeping a list of what was supposed to disappear before release.
The common denominator is always the threat model. These devices are designed assuming the user is benign, the home network is safe, and nobody will unscrew the enclosure. Every one of those assumptions is false, and the last one especially so.
The soldering iron, or why hardware matters
I spent a substantial share of that period with a soldering iron in hand, and I consider it one of the best investments of my time.
The reason is simple. A great many IoT protections assume the attacker stays on the software side. The moment you step outside that assumption and reach the board directly, the memory, the service interfaces, a large part of that protection stops mattering. And home devices have the property that an attacker has physical access by definition. They buy a unit in a shop.
Hardware skills also unlock everything else. You will not obtain firmware if you cannot extract it from a chip. And without firmware you are left with black box testing, which is dramatically less effective.
The kit, or how you assemble a workshop without noticing
Nobody plans this. It starts with a single USB-to-UART adapter bought for one specific task, and it ends with a cable organiser where every elastic loop holds something different and you remember what each piece is for.
Mine holds roughly this:
- A flash memory programmer with a SOIC clip. The basic tool for dumping firmware straight off the chip without desoldering it from the board. Very often this is the exact moment a test stops being a black box exercise.
- Two USB-to-UART adapters. Two, because the first one is always mislaid somewhere, and because different chips prefer different voltage levels and it helps to have a choice.
- An eight-channel logic analyser, 24 MHz. It costs about as much as lunch and solves a problem you cannot otherwise solve: what is actually travelling on those traces, and which protocol is it.
- A multimeter with a full set of probes. Before connecting anything, it pays to know where ground is and what voltage sits on the line you are about to touch. Skipping that step can get expensive.
- A third party Wi-Fi adapter. For everything happening over the air.
- Jumper wires, tweezers, small radio modules, flash drives, a USB power meter. The things you always turn out to be missing at the worst possible moment.
What is striking is how inexpensive the whole set actually is. Practically everything visible in the photos fits within a budget comparable to one decent monitor. That is important information for anyone who assumes hardware hacking requires a laboratory. It does not. It requires patience and a willingness to read a chip datasheet.
There is also a contrast here with the corporate world I wrote about earlier. Automotive test equipment is so expensive that in practice it is only reachable through an employer. Here the barrier is low enough that anyone can start over a weekend.
And one lighter observation. Every time I pack for an airport, I look at this organiser and think it is not an object I would enjoy explaining in a security queue. An assortment of cables, boards, clips and something labelled "logic analyser", packed into a cube the size of a wallet.
A practical note, entirely seriously: carry-on rather than checked baggage, and a calm explanation that it is work equipment. These are diagnostic tools, completely legal, bought from ordinary electronics shops. But if you are flying to a conference with a hardware workshop, it is worth assuming somebody may want to look inside, and simply being ready for that.
So far it has never come to a conversation. Only a matter of time.
Whose shoulders this stands on
It is only fair to say that a huge share of the knowledge in this field comes from the public research of individual people.
In the robot vacuum space the essential figure is Dennis Giese, who runs dontvacuum.me. He works on the security and privacy of embedded devices, has presented at Chaos Communication Congress, DEF CON, HITCON and other conferences, and his robot collection spans dozens of models across manufacturers. His work covers flash memory analysis, obtaining root without disassembling the device, and liberating hardware from the manufacturer's cloud.
His material was genuinely useful to us as a working reference. When you know which classes of problem someone has already documented in a product category, instead of starting from zero you start by asking whether this particular unit has them too.
His argument is also worth attention, because it goes beyond pure technique. A robot vacuum is a device with a camera, a microphone and a complete map of your home, sending data to a cloud. The question of who controls that is every bit as important as whether it can be rooted.
Material: dontvacuum.me, along with his publicly available DEF CON and CCC talks.
Today: television security
I currently work at Xperi on smart TV security, where my job is making sure the end user stays safe.
It is an interesting continuation of the same path, because a television is essentially a complete computing device pretending to be furniture. Permanent network access, an app store, user accounts, data about what you watch and when, a microphone in many models, increasingly a camera, and on top of that a product lifecycle measured in years, far longer than a phone's.
That last point is the hardest one from a security perspective. A phone gets replaced every few years. A television sits in a living room for a decade, and throughout that time someone has to keep shipping fixes for components whose vendors stopped supporting them long ago.
The nature of the work also differs from commissioned pentesting. There you join a project, find things, report and move on. Here you sit with the product across its whole lifecycle, so what counts is not only finding a problem but ensuring the entire class of it does not return in the next release.
The smart home, or all of it at once in one flat
A television is one device. It gets more interesting where there are twenty of them from fifteen different vendors: a lock, a camera, a vacuum robot, a thermostat, contact sensors, sockets, a voice assistant. Each one on its own is often protected reasonably well. The trouble starts because they share one network, sign in to several clouds at once, and are tied together by an app that has to speak to all of them.
That is why the most interesting findings in a home ecosystem rarely sit in the device itself. They sit in between: in the pairing procedure, in what a guest on the same network can see, in the copy of your data held on the vendor's side, and in what stays inside the hardware after it is sold on second hand.
This is the subject of my talks titled "Spies in your home", and a subject for its own article, because it no longer fits in this one.
The smart home: what your house actually sees. A separate article on what testing a home ecosystem looks like and which of those devices deserve a network of their own. Coming soon.
Why IoT is in the state it is
A few observations collected along the way.
Security loses to deadlines and margins. For a device meant to retail at fifty euros and reach shelves before the season, every additional engineering hour and every additional chip is a real cost visible in a spreadsheet.
Expertise is fragmented. A team that can design excellent motor control does not necessarily have cryptography experience, and a company sourcing a product from an external supplier often has no way to verify what it received.
The supply chain is long and opaque. A Wi-Fi module from one vendor, an operating system from another, an app from an outside agency, a cloud from someone else again. A vulnerability in such a module then affects dozens of brands that do not even know they share a problem.
Updates are sometimes fictional. A device may ship with an update mechanism nobody will ever use, because the manufacturer discontinued the product line in the meantime.
The good news is that this is changing, largely under regulatory pressure. The EU Cyber Resilience Act imposes security and vulnerability handling requirements on manufacturers of products with digital elements across the whole lifecycle. In the UK the PSTI Act bans, among other things, default universal passwords. There is also ETSI EN 303 645, setting baseline requirements for consumer IoT.
In other words, "it's only a kettle" is slowly ceasing to be an accepted answer.
Whether a given product falls under the CRA is settled by the five question test, and the manufacturer's duties are covered in what the CRA requires from manufacturers.
Closing thought
Looking back, the whole path is surprisingly coherent. It started with taking things apart out of curiosity. Then came C and the understanding that memory is bytes somebody has to manage. Then contactless cards and the lesson that a broken algorithm can live in production for years after publication. Then home appliances, a soldering iron, and the discovery of how much protection falls apart the moment an enclosure is opened. Today televisions, and the question of how to hold all of it together for ten years.
The same question throughout, just on progressively larger devices: what happens if I use this differently from how it was intended?
I still have not found a better one.
Testing of IoT and embedded devices, from hardware through to the update process, is described under services. If you have a product that needs to go through it, get in touch.
Resources
- dontvacuum.me, Dennis Giese's research on robots and IoT devices
- OWASP IoT Top 10, a solid starting point for classifying problems
- ETSI EN 303 645, baseline requirements for consumer IoT
- The Cyber Resilience Act and the UK PSTI Act
- Publications on MIFARE Classic vulnerabilities and the Crypto1 cipher