Who tests the chip in your phone?
Hidden components inside smartphones can silently track activity beyond your control. Research at Birmingham is exposing the risks before they are exploited.
Hidden components inside smartphones can silently track activity beyond your control. Research at Birmingham is exposing the risks before they are exploited.
Inside every phone are components most users never think about, capable of silently sharing your location, sending messages, or opening a browser without you ever knowing. At the University of Birmingham, Marius Muench has spent years cracking this black box open before the wrong people do.
A digital device can sit idle on a desk, screen locked and untouched, yet still be active in ways its owner cannot see and would not expect. Beneath the screen lies a set of separate processors, each running its own code and carrying its own vulnerabilities.
"I consider myself a researcher in low-level cybersecurity”, says Marius Muench, as he introduces his work as Assistant Professor of Cyber Security focused on “everything which is typically not directly visible to the user, but affects them tremendously because it's deployed in all the devices out there."
His work is built on a simple idea: systems need to be tested under adversarial conditions, a principle he has spent years applying to parts of modern devices that the industry has largely left untested.

Image: Unsplash
Most people interact with their phone through its operating system—the main software, such as Android or iOS, that runs apps and controls what appears on screen. What sits beneath it is considerably less familiar.
Every phone also contains a second, entirely separate processor with a single dedicated job: managing communication for the phone. "A lot of people are not aware that the software implementing communication with a cell tower—2G, 3G, 4G, 5G—runs on a completely separate chip," says Muench. "It's a dedicated processor, highly proprietary, produced by only five or six vendors in the world…and they keep the source code of their implementation secret."
This system, known as the baseband, operates largely outside the reach of the main operating system. Its code is not publicly available, cannot be independently audited, and offers little opportunity for inspection—whether by external researchers or by the users who rely on it.
The scale of the software involved is significant: Muench estimates it at four times the size of the Windows operating system kernel, and ten times the complexity of the code that flew the Apollo moon missions. Built up over decades, each cellular standard has added features while older ones remain, creating layers of accumulated complexity. “There’s a large amount of software, not a lot of introspectability—and as a result, a high-profile impact,” Muench concludes.
Because this layer communicates directly with the network, it can be reached over the air. An attacker within wireless range can simulate a cell tower and send crafted signals to test how the system responds. "If you can attack a cellular baseband processor, you get access to a victim's communications," warns Muench, with documented attack chains reaching into the Android runtime, demonstrating how this layer can serve as a foothold into the device.
Yet cellular vulnerabilities remain among the least reported in wireless security tracking, reflecting how difficult these systems are to access and study in practice.
Dr Muench and his team member Lisowski will discuss their journey into SIMs as attack vector at the TROOPERS26 conference.
By default, testing for the baseband follows a narrow pattern: systems are evaluated against expected behaviour. Does the device respond correctly to valid inputs? Does it comply with the standards that define how cellular networks should operate?
This process uses well-formed, legitimate inputs—signals a real cell tower would actually send. While necessary, it only confirms one side of security: that the device complies with its specification. "If you have an aeroplane, you use wind tunnels and stress testing rigs to put it under adverse conditions before it flies," says Muench. "For baseband processors, that kind of adversarial testing doesn't exist in the design process, which is why we built it."
His approach recreates the baseband environment outside the device. Working without access to source code or internal specifications, Muench extracts the compiled code (“binary firmware”) directly from the device and replicates it inside a virtual software environment, where it can be subjected to large volumes of adversarial inputs while its responses are observed. The result was FirmWire, published at the Network and Distributed System Security Symposium (NDSS) 2022: the first platform to bring systematic adversarial testing to baseband firmware, now widely used across the field.
Moving the firmware into a controlled environment changes what can be tested. “We find attack scenarios and types of bugs which people simply didn’t think about, and had no way of testing for,” explains Muench, describing a shift that has helped surface more than 20 vulnerabilities across 2G and 4G baseband software stacks, with patches from Google, Samsung, and MediaTek.
The FirmWire approach has since expanded to testing with network-connected phones through BaseBridge and to SIM security with SIMurai. For Muench, these are not separate projects but variations on the same goal: "In my research, what I'm doing is finding new testing methods to make sure a third party can assess the security of these devices, and building tools to make that testing more accessible."
If you have an aeroplane, you use wind tunnels and stress testing rigs to put it under adverse conditions before it flies. For baseband processors, that kind of adversarial testing doesn't exist in the design process, which is why we built it.
That a component as familiar as the SIM card can act in ways its owner never intended, and never sees, is what makes it worth understanding. This danger begins with a misconception: "What people don't realise is that SIM cards are tiny computers," explains Muench. "They don't just store secrets to access the network; they can directly interact with the phone. And there is a full specification defining what a SIM is allowed to request from the phone."
A SIM can instruct the phone to reveal its location, send an SMS, or open the browser at a specified address; combine the first two, and a hostile SIM becomes a passive tracking device. Muench’s work shows that this is not a single vulnerability, but a class of risks that can be understood across three attack surfaces:

Tools of the trade: Muench's team uses custom software, off-the-shelf hardware, and commercially available interposer devices to probe what a SIM card can be made to do.
"It's not enough to mitigate vulnerabilities one by one, we need robust systems in the first place."
Attacks that require access to the device or SIM. In practice, this can be as simple as placing a thin hardware interposer between the SIM and the phone: a commercially available layer, often sold for carrier unlocking, that can be planted in seconds to manipulate the commands exchanged by the two.
Where the SIM is reached through the same infrastructure that allows it to be managed by the operator.
Attacks that exploit flaws in the SIM software itself. Like any software, SIM applications can mishandle unexpected inputs from the phone, turning trusted functionality into behaviour the designers never intended.
Fixing one vulnerability is not the same as fixing the underlying problem. In 2024, when Marius Muench’s team identified a faulty boundary check in the code handling a routine cellular function on Pixel devices, Google patched it and paid a bug bounty; months later, a different flaw appeared in the same function, also later patched: same class of error, different line. For Muench, this makes the case for more comprehensive and systemic security measures. "It's not enough to mitigate vulnerabilities one by one," he says. "We need robust systems in the first place."
There are signs that this is beginning to change, with Muench highlighting Google Pixel 10’s memory-safe firmware components and Raspberry Pi's RP2350 Hacking Challenge, which he believes was the first launch-time challenge of its kind from a chipmaker, as examples of the industry beginning to treat security more and more seriously. "Vendors used to say: 'Oh, this is an arcane attack that only works if it's full moon on the first of the month,' he notes, “but there's been quite a shift in recent years: vendors are trying to get their systems secure, looking into proactive security measures, helping academics to do their research and, most importantly, listening to us."
Tomasz Lisowski will also present the team's latest research on hostile SIMs at the 2026 USENIX WOOT Conference on Offensive Technologies.

Sign up to hear about our Computer Science research, insight and innovation