Why we test it this way

Signed firmware and encrypted traffic stop the attacks people think of first. The ones we find are elsewhere: an update mechanism that can be pointed somewhere else, a debug interface left enabled on production hardware, a key shared across every unit shipped, or a device that trusts anything on the local network because the designers assumed the local network was safe. We take the device apart and test the whole chain, including the part that runs in your cloud.

A device is a stack, and an assessment stops somewhere in it. Where it stops decides which defects are findable at all.

How far down we get, and what came out of each depth

Application and OS What most assessments cover, and where a defect is still a patch. Android patch gap: vendors shipped the patch level without all of the patches
Where a typical device assessment stops
Update chain The mechanism that decides whether anything below can ever be fixed.
Application firmware Pulled off the device and read, not inferred from behaviour.
Radio and baseband Runs on cores most analysis tooling cannot reach. hexagon_fuzz: full-system emulated fuzzing of Qualcomm basebands, released 2025
Peripheral controllers The chips inside the parts nobody counts as a computer. BadUSB: USB controller firmware reprogrammed to impersonate another device
Silicon and boot Where a defect is a recall. We work here with chip manufacturers.

Above the update chain a defect is a patch. Below it, a recall.

Where a device carries regulatory weight we produce the evidence for it, including Cyber Resilience Act obligations for products with digital elements. The hardware runs from IoT and consumer devices, routers and gateways, phones and tablets, wearables and health devices, through to automotive and mobility systems and industrial and medical equipment. What changes between them is the constraint: power budget, safety interlocks, regulatory approval, how often you can ship an update. That changes which findings are worth reporting. The method holds throughout: pull the firmware, map what is reachable, then prove the parts that matter.

The work goes back a long way. BadUSB, in 2014, showed that the controller chips inside ordinary USB peripherals could be reprogrammed to impersonate another device entirely, and that reinstalling the operating system removed nothing. LEGIC Prime, used for access control in military installations, government departments and power plants, turned out to defend itself with fifteen bits of secret state and no key at all.

What we found

Some vendors shipped the Android patch *level* without shipping all of the patches behind it. We found that by testing the installed binaries on real devices instead of trusting what the phone reported. Eight weeks later we corrected our own method and numbers in public: community firmware builds had been mixed in with vendor ones, and we had reported a larger gap than there really was. Re-measured in 2019, official firmwares missed about half as many patches as in 2018.

How

Binary-level patch-presence detection on real devices via SnoopSnitch, compared against the vendor’s claimed patch level.

What it does not support

Crowd-sourced, so the population is self-selecting: it reflects the devices people ran SnoopSnitch on, not the device population as a whole.

Since

Improving. Missed-patch rate fell below 0.3 per firmware build in 2019, from 0.7 in 2018.

Android patch gap

Qualcomm basebands run on Hexagon cores that almost no analysis tooling could reach, which is why that attack surface stayed unexamined for years. We built the first open-source toolchain for full-system emulated fuzzing of Hexagon firmware and released it at TROOPERS in 2025. It is the level we work at when the firmware was never meant to be analysable.

hexagon_fuzz: full-system emulated fuzzing of Qualcomm basebands

Where engagements usually start

Device assessment

We take one device apart and test everything reachable on it, including its cloud side.

Firmware extracted and analysed, statically and while running
Radios and local services, including what the device trusts on the network
The update chain end to end, including whether it can be redirected
Key material and secrets: what is on the device, and whether it is shared across units

Update chain review

We test whether you can ship a fix, and whether someone else can ship one for you.

Signing, verification and rollback protection
What happens on a failed or interrupted update
Whether the device can be pointed at a different update source
Whether what you shipped is what ended up installed

Fix verification

We re-run the proofs of concept against your fixes and confirm the class of bug is closed.

Original proofs of concept re-run against the fixed build
Variants tried, so a narrow patch does not pass as a fix
Harnesses handed over so you can re-run them yourself
A short written result per finding, closed or not

How we work

We start by taking the device stack apart on paper: what runs where, what talks to what, and what an attacker would want out of it. Then we get the firmware off the hardware and read it, statically and under emulation where that helps. The Hexagon toolchain we released in 2025 exists for the hard end of that: Qualcomm baseband code no tooling could execute before it. When we think something is exploitable we build a working proof of concept, because an untested theory is not a finding. The report is written for engineers with a sprint to plan.

Related research

Send us the problem

Tell us what you are building and what you need looked at. You will get an answer from the people who would run the engagement, and if another firm is the better fit for what you are asking, we will name one.

Get in touch