In the previous article, we looked at how protections such as secure boot and readout protection behave when someone deliberately attacks them. Each of those tests looked at a single mechanism. An adversary holding a captured drone doesn't work that way.

Security work is usually split by speciality. Hardware, firmware and software teams each test their own layer against their own threat model. The person at the bench with a recovered UAV has no such boundaries. They use whatever gets them further, and the result of one technique is often the starting point for the next.

‍

What one attack path looks like

Take a platform whose firmware sits behind the microcontroller's readout protection. On its own, that protection looks sound: the debug port is locked and the flash can't be read.

Fault injection changes that. On some chips, a well-timed voltage glitch during boot can leave the protection in a weaker state, as the STM32 example earlier in this series showed. The firmware is now on the attacker's laptop, and the problem has moved from hardware to software.

Reverse engineering the image shows where the firmware checks the signature of an update, which routine handles the radio link key, and when during start-up that key is loaded. None of these is a vulnerability by itself. Together, they tell the attacker exactly where to aim the next measurement or glitch: at the cycles where the key is in use, or at the single branch that decides whether an unsigned image runs.

That second round of physical attacks works far better than the first because it is no longer blind. Each layer narrowed the search for the next.

‍

The radio link and the environment belong to the same system

The attack path doesn't stop at the board. Once the radio protocol and its credentials are understood, a captured drone may become a way to talk to the ground station, or to other aircraft in the same fleet. One lost platform becomes a risk for the ones still flying.

The environment is an input too. Navigation, altitude and orientation all come from sensors, and the second article described how spoofed telemetry can convince a platform it is flying normally. How the firmware reacts to those inputs is part of the same analysis.

‍

Where testing in silos falls short

Tested one at a time, every layer in the example above could pass. The readout protection was configured correctly. The update check verified signatures. The cryptographic library used a standard algorithm. The weakness was in how they depended on each other: a protection that held under normal conditions was guarding firmware that pointed straight at the secret.

An assessment that stops where one team's scope ends will miss that. It has to follow the path the attacker would take, from the board to the firmware, to the radio link and back again.

It also changes the fix. With the whole chain in view, the cheapest place to break it is not always the layer where the weakness was found. A glitch that exposes firmware might be countered by redundant checks in software rather than a new chip. A key that leaks through side channels might be better protected by not keeping it on the platform at all.

‍

Coming next: Protecting AI at the Edge

The same applies to the models and decision logic now running on these platforms. In the next article, we look at what happens when AI leaves the data centre, and why the computing hardware becomes part of the AI security perimeter.

‍