Baseband-Level Surveillance in Smartphones: A Technical Feasibility Analysis of a Call-Activated Backdoor

Type: Speculative security analysis
Date: 7 December 2025

Abstract

This article presents a detailed technical analysis of a baseband processor-level backdoor in smartphones, with particular focus on Apple iPhone devices. The analysis is speculative and based on publicly available technical information about baseband architecture, telecommunications protocols, and historical security incidents. Information not publicly available has also been provided for the analysis, but to protect the source, the article does not separately identify the information or its origin. The article does not claim that such a backdoor definitively exists, but rather examines its technical feasibility and potential detection methods as part of defensive security research, while noting that the material we have received corroborates this possibility to the extent that it can no longer be unequivocally ruled out at the time of writing. Based on the material we have received, special attention is directed at a call-activated mechanism that enables remote activation without the user's knowledge.

Keywords: baseband processor, security threats, smartphone surveillance, firmware analysis, telecommunications security

1. Introduction and Responsibility Disclaimer

1.1 Nature and Purpose of This Article

This document is a technical analysis of a baseband processor-level security threat that has not been publicly proven but whose existence is supported by significant observational evidence. The purpose of this article is not to spread misinformation or cause unfounded concern, but to document technical feasibility and serve as part of responsible security research.

Although this analysis relies heavily on publicly available technical information, its writing was motivated by concrete observational evidence pointing to the existence of such a system. To protect our sources and evidence, we cannot present all the material at our disposal directly, but we include sufficient references in the analysis to make the threat concrete rather than mere speculation.

Among the foundational principles of security research is the "defence in depth" approach, where theoretical attack vectors are analysed regardless of whether they have been observed in use. The most famous example of this in the history of cryptography is Bruce Schneier's dictum that "anyone can invent a security system that they themselves cannot break" — the real test is whether the system can withstand expert analysis actively seeking weaknesses.

Baseband processors represent a particularly interesting research subject because they are an essential component of every smartphone yet simultaneously the least understood component, owing to their technical complexity and closed source code. Considering that there are over five billion smartphones in use worldwide, the impact of a potential baseband-level vulnerability would be unprecedented in scope.

1.2 Why This Analysis Matters — and Why Now

Historical evidence demonstrates that hardware-level backdoors are not mere theory. The Crypto AG scandal made public in 2020 revealed that intelligence services had controlled a Swiss encryption equipment manufacturer for over 48 years and sold intentionally weakened encryption machines to more than a hundred countries. The operation codenamed "Thesaurus" and "Rubicon" represents the longest-running intelligence operation in history based on a hardware-level compromise.

Another significant case is the Dual EC DRBG random number generator, which was standardised by NIST in 2006. In 2013, Edward Snowden's revelations confirmed that the algorithm contained a mathematical backdoor enabling prediction. This demonstrates that even standardisation processes can be manipulated and that the embedding of backdoors into widely used technologies is a documented fact, not mere theory.

But now the situation has become more concrete. Recently, observations have emerged suggesting that a baseband-level backdoor is not merely a theoretical threat but a potentially active system in use. We have access to material documenting cases in which users' iPhones appeared to behave in ways consistent with the threat model described in this article.

Particularly concerning is the fact that the observations involve the latest iPhone 16e model, which uses Apple's first entirely self-designed C1 modem. This means that if a backdoor exists, it is not limited to products from external modem manufacturers (Qualcomm, Intel) but extends to Apple's own design as well.

These historical cases teach a critical insight: well-designed backdoors can remain hidden for decades when they are integrated into complex technical systems whose complete auditing is practically impossible. Baseband processors meet all these criteria: they are technically complex, closed-source, and a critically important piece of infrastructure whose operation is trusted but rarely truly verified.

1.3 Academic and Ethical Context

This analysis adheres to the ethical principles of security research as reflected in the IEEE Code of Ethics and the ACM Computing Code of Ethics. The purpose of the research is not to enable harmful activity but to improve defensive capability by identifying potential vulnerabilities. The security community has long followed the principle of "responsible disclosure," where vulnerabilities are reported first to the parties responsible for fixing them before public disclosure.

In this case, the hypothetical vulnerability is systemic in nature, concerning the entire baseband architecture rather than a single implementation error, so the traditional disclosure model does not directly apply. Instead, the purpose of this article is to stimulate broader discussion about how the security of critical infrastructure components could be improved through transparency and independent auditing.

It is important to emphasise that reading or distributing this analysis is not illegal in any jurisdiction we are aware of, as it is purely a theoretical security analysis based on public information. The article does not disclose actual vulnerabilities nor provide tools for exploiting them, but describes a theoretical scenario for pedagogical purposes.

2. Baseband Processor Architecture — The Technical Foundation

To understand how a hypothetical baseband backdoor would work, we must first build a thorough understanding of what a baseband processor is and how it integrates into a modern smartphone's architecture. This section proceeds pedagogically from basic concepts toward more complex technical details.

2.1 The Dual-Processor System — The Hidden Reality of Smartphones

When a user thinks of a smartphone, they generally conceive of it as a single computer running an operating system like iOS or Android. In reality, every modern smartphone is at least two entirely separate computers in the same housing, communicating with each other but operating independently.

The first of these computers is the Application Processor, or AP. This is the processor discussed in specifications: for example, Apple's A18 Bionic or Qualcomm's Snapdragon. The Application Processor runs the operating system, applications, and everything the user sees on screen. It is responsible for graphics rendering, application execution, and processing user interactions.

The second computer is the Cellular Processor, more commonly known as the baseband processor or simply the "baseband." This processor is responsible for all radio communication: mobile networks, often Wi-Fi and Bluetooth as well, GPS, and other wireless technologies. The baseband runs its own operating system, which is typically some form of real-time operating system, or RTOS (Real-Time Operating System), such as FreeRTOS or a manufacturer's proprietary implementation.

The separation between these two processors is not arbitrary but rooted in fundamental technical reasons. Radio signal processing requires deterministic, real-time processing that cannot wait for an operating system's task scheduler. When a mobile network sends a signal requiring a response within five milliseconds, the baseband processor must respond on time regardless of what applications the user happens to be running or whether the main processor is overloaded.

Moreover, telecommunications standards such as 3GPP (3rd Generation Partnership Project) define precise protocols and time constraints that modems must observe. These standards cover everything from how a call is initiated, how data is packaged for transmission over the air, and how handovers between base stations occur as the user moves. Implementing these complex protocols in a general-purpose operating system would be extremely difficult and reliability would suffer.

2.2 Baseband Firmware and Its Distinctive Nature

The baseband processor runs firmware — software stored in flash memory or, in some cases, partly in ROM (Read-Only Memory). This firmware contains all the logic needed to communicate with the mobile network.

The firmware architecture is typically layered as follows. At the lowest level is the Physical Layer (L1), which handles the actual radio signals: modulation, demodulation, error correction, and everything that happens "on the airwaves." Above this is the Data Link Layer (L2), which handles packet formation and resource allocation. At the top is the Network Layer (L3), which manages connections, authentication, and mobility.

All of this code is digitally signed by the modem manufacturer using RSA or ECDSA signatures. When the baseband processor boots, it first verifies that the firmware is signed with the correct key and only then executes it. This is a security mechanism that prevents malware from being loaded onto the baseband processor and ensures that only manufacturer-approved code is executed.

In practice, this means that an ordinary user — or even an experienced programmer — cannot modify the baseband firmware. If you attempted to write your own firmware version and load it onto the device, signature validation would fail and the device would not boot. This is technically necessary, because otherwise malware could take control of the baseband and, for example, call premium-rate numbers without the user's knowledge or intercept communications.

This security mechanism simultaneously creates a trust problem: since the firmware is closed-source and digitally signed so that it cannot be modified, the user must place complete trust in the manufacturer not having included malicious functionality. There is no practical way for an ordinary user — or even an experienced researcher — to verify what the firmware actually does without an extremely lengthy and costly reverse engineering process.

2.3 Memory Architecture and Inter-Processor Communication

The baseband processor has its own physical memory, which may be integrated into the same System-on-Chip (SoC) as the main processor or be an entirely separate component. The iPhone's architecture has evolved over the years, but the fundamental arrangement has remained the same.

In early iPhone models, the baseband was a completely separate chip on its own PCB. For example, the iPhone 4 used an Infineon XMM6180 modem that was physically separate from Apple's A4 processor. They communicated via a USB bus: the baseband appeared to the main processor essentially as a USB device that received AT commands (the classic modem protocol) and sent responses.

In more modern implementations, the baseband may be integrated into the same SoC as the main processor, even though they remain logically separate. For example, Apple's new C1 modem is integrated as part of the A18-series chips. Communication then occurs via the PCIe bus (Peripheral Component Interconnect Express), which offers considerably faster data transfer than USB.

A critical technical detail is that the baseband processor may have DMA access (Direct Memory Access) to the main processor's memory. DMA means the baseband can read from or write directly to the main processor's RAM without this occurring through the main processor. This is necessary for performance: when the baseband receives, for example, a large data file from the mobile network, it can write it directly to the application's memory area rather than having the data pass slowly through the main processor.

DMA also creates a potential security risk: if the baseband is compromised, it can theoretically read anything in the main processor's memory, including passwords, encryption keys, or other sensitive information. To defend against this threat, modern systems use an IOMMU (Input-Output Memory Management Unit), which restricts which memory areas the baseband can access.

Apple's architecture is relatively secure in this regard. In the iPhone, the baseband is not directly integrated into the same memory space as the main processor; instead, communication occurs through restricted channels. Additionally, the Secure Enclave — a separate security processor that handles cryptographic keys and biometric data — is isolated from both the main processor and the baseband. This means that even if the baseband were compromised, it would not directly gain access to, for example, Touch ID or Face ID keys.

Yet the baseband occupies a critical position. It is the only component that handles all radio communication, and it does so before data reaches the operating system's awareness. This makes it an ideal location for a backdoor that wants to remain hidden.

2.4 Why the Baseband Is "Trusted but Not Verifiable"

The baseband processor's position in the system architecture creates a paradox. On one hand, it must be fully trusted because it handles all communication and has access to critical system resources. On the other hand, its operation is practically impossible to verify without specialised tools and deep expertise.

From the operating system's perspective, the baseband is a "black box" that receives commands and returns results but whose internal operation is abstracted away. iOS does not "see" what the baseband firmware does internally: it simply sends requests like "call this number" or "send this data packet" and trusts that the baseband handles it.

This level of abstraction is technically sound because it separates concerns — the operating system does not need to understand the complexity of 3GPP protocols and can focus on higher-level functionality — but from a security perspective, it means there is an entire layer of functionality operating without the operating system's oversight or even awareness.

Furthermore, baseband firmware is typically updated as part of iOS updates, but the update process is opaque. The user is told that "iOS 18.2 includes a modem update," but no details about what changes were made are provided. There is no public changelog documentation for baseband firmware, unlike iOS itself, where Apple lists at least the major changes.

This opacity makes it an ideal place to hide functionality not intended to be found. If a hypothetical backdoor were integrated into the baseband firmware, detecting it would require either insider knowledge of the firmware's structure or a massive reverse engineering project.

3. Historical Context — Proven Hardware Backdoors

Before we delve into a hypothetical baseband backdoor, it is important to understand that hardware-level backdoors are not mere speculation but a documented part of intelligence history. This section examines three significant cases that provide context for why a baseband-level threat must be taken seriously.

3.1 Crypto AG — History's Longest Intelligence Operation

Crypto AG was a Swiss company that manufactured encryption machines and devices from 1952 onward. The company built a reputation as a trusted enterprise from neutral Switzerland and sold its devices to over 120 countries, including governments, militaries, and diplomatic services around the world. Clients included Iran, India, Pakistan, Latin American states, and numerous others.

In 2020, the Washington Post, ZDF, and SRF published a collaborative investigative journalism project that revealed a startling truth. Western intelligence services had secretly purchased Crypto AG in 1970 and controlled the company in operations codenamed "Thesaurus" and "Rubicon." The operation lasted until 2018 — a total of 48 years.

Throughout this entire period, Crypto AG sold intentionally weakened encryption machines. The encryption algorithms contained built-in weaknesses that made it possible to read communications. Technically, this was accomplished through multiple methods. In early mechanical machines, rotor configurations were manipulated so that the "randomness" they generated was not truly random but followed a pattern known to the intelligence services.

In later electronic devices, the weakness was in the encryption key generation. The devices used a random number generator that appeared entirely random to an outsider but in reality contained a cryptographic backdoor. The generated keys were long enough that a brute force attack would have been impossible, but they followed a hidden mathematical pattern that made key derivation possible if one knew the secret parameter.

The scale of the operation was immense. An estimated over 40 per cent of diplomatic communications during the Cold War passed through Crypto AG devices. The operation provided a significant intelligence advantage, particularly during the Iran hostage crisis of 1979, the Falklands War of 1982, and countless other geopolitical crises.

This case teaches several critical lessons. First, a well-designed backdoor can remain hidden for decades, even when the devices are used by countries with significant intelligence services of their own. Second, embedding backdoors in standardised devices that appear legitimate is demonstrably practical. Third, the duration of the operation shows that institutional support for such activity exists, transcending individual administrations or political changes.

3.2 Dual EC DRBG — Manipulation of the Standardisation Process

The Dual Elliptic Curve Deterministic Random Bit Generator, or Dual EC DRBG, was a cryptographic random number generator standardised by NIST (National Institute of Standards and Technology) in 2006 as part of the SP 800-90A standard.

Early on, cryptography experts raised concerns about the algorithm. Microsoft researchers Dan Shumow and Niels Ferguson presented at the Crypto 2007 conference that the algorithm contained a potential backdoor. Their analysis demonstrated that if any party knew a certain secret parameter (called "e") related to the elliptic curves used in the algorithm, it could predict the generator's future "random" numbers after observing a sufficient quantity of previous outputs.

A critical detail is that the elliptic curve parameters used in the algorithm were chosen without public explanation. In cryptography, there is a general principle that constants and parameters should be selected using a "nothing up my sleeve" method — for example, using the decimals of pi or the natural logarithm — so that no one can claim they were chosen for a special purpose. The Dual EC DRBG parameters did not follow this principle.

In 2013, among the documents leaked by Edward Snowden was material confirming that Dual EC DRBG did indeed contain a deliberate backdoor. The documents revealed that an intelligence organisation had paid RSA Security 10 million dollars to use Dual EC DRBG as the default algorithm in their widely used BSAFE library, even though the algorithm was known to be slow and had suspicious properties.

The technical implementation is mathematically elegant. Dual EC DRBG uses two points on an elliptic curve called P and Q. If someone knows the secret value d such that Q = d × P, they can derive the generator's internal state after seeing just 30 bytes of the generator's output. This enables prediction of all future output.

Because a random number generator is used to create cryptographic keys, this backdoor is devastating. If you generate random parameters for a TLS connection using Dual EC DRBG and an attacker intercepts your connection initiation data, they can derive your private key and decrypt all your encrypted traffic.

This case demonstrates that even public standardisation processes can be targets of manipulation. NIST is a respected institution whose standards are trusted globally, yet in this case the process failed to detect (or deliberately failed to detect) a systematic backdoor. It also shows that mathematical elegance can conceal malicious functionality: the algorithm appears entirely legitimate from the outside, and only deep cryptographic analysis reveals the problem.

3.3 Lessons from These Cases

The common themes of these historical cases are clear. First, backdoors can remain hidden for extremely long periods: 48 years in the Crypto AG case and seven years from Dual EC DRBG's publication to its actual exposure. Second, they require long-term institutional support and coordination among multiple actors. Third, technical complexity and closed implementations make auditing extremely difficult.

Baseband firmware combines all of these characteristics. It is technically extremely complex closed-source software whose complete auditing would require massive resources. It is a critically important component present in every mobile phone, so the impact of its compromise would be enormous. And it is part of an infrastructure that has traditionally been of interest to intelligence services, as Snowden's revelations documenting cooperation with telecommunications operators demonstrate.

4. Technical Architecture of a Hypothetical Baseband Backdoor

Now that we have built an understanding of baseband architecture and the historical context, we can analyse how a hypothetical baseband backdoor could technically function. This analysis is purely theoretical but is based on real technical knowledge of baseband architectures and telecommunications protocols.

4.1 Backdoor Location in the Firmware Architecture

The most effective location for a backdoor would be at the ROM level or in eFUSE memory that is "burned in" during the manufacturing process. ROM, or Read-Only Memory, is a type of memory written during the manufacturing process using lithography, whose contents cannot be changed afterward. eFUSE technology works on a slightly different principle: it contains tiny electrical fuses that can be "burned" individually, programming permanent values into memory. Once a fuse is burned, it can no longer be changed.

Baseband firmware normally consists of multiple layers. At the lowest level is the bootloader, which executes first when the device boots. The bootloader's task is to initialise the hardware, load the actual firmware from flash memory, and verify its digital signature before execution. If the signature does not match, the bootloader halts the boot process.

Above the bootloader is the actual baseband firmware, which contains all the logic for implementing 3GPP protocols. This firmware is generally modular, containing separate components for different radio technologies (2G, 3G, 4G, 5G), network layer management, AT command processing, and other functions. The firmware is updated regularly as the manufacturer releases updates.

A hypothetical backdoor would ideally be at the bootloader level or separately in ROM that the bootloader references. This would make it persistent: it would exist regardless of firmware updates. When a user updates iOS (and thus the baseband firmware), the actual firmware partition may change, but ROM-level code remains the same.

Technically, this could be implemented such that the ROM-resident bootloader contains an additional code segment executed alongside the bootloader's normal operation. This code would be deliberately hidden and integrated among legitimate code so that static analysis would not easily reveal it.

Another approach would be a "reserved" memory area. The baseband firmware's layout documentation may reference memory areas marked "reserved for future use" or similar terms. To an outsider, these appear to be empty memory areas set aside for possible future features. In reality, these areas could contain functional code that activates under certain conditions.

In a hypothetical example, we might assume that at address 0x87FF8000 there begins a 32-kilobyte memory area that the documentation labels "RESERVED_REGION_1." Under normal operating conditions, this memory area is never used and appears empty if someone examines a firmware dump, but the firmware contains code that, when certain conditions are met, jumps to this memory area and begins executing the code residing there.

4.2 Activation Mechanism — The Call-Activated Backdoor

The hypothetical backdoor's most critical innovation would be an activation mechanism enabling remote activation without the user noticing anything. This requires two-way communication, and therefore activation would occur during a phone call.

The process would begin with a normal-looking call. The attacker (assumed in this scenario to be a state actor or a well-resourced intelligence organisation) calls the target's number. The phone number can be anything — even the target's friend's or colleague's number, if the attacker can manipulate Caller ID information (which is possible on many mobile networks). The target's phone rings normally.

The critical step is that the target must answer the call. This is a technical necessity because, before the call is answered, the two-way RTP audio stream (Real-time Transport Protocol) has not yet been established. In the signalling phase alone, the network only announces "incoming call," but there is no audio connection. Only when the target presses the green answer button does the mobile network establish a full-duplex audio link in both directions.

4.2.1 Era 1: Legacy Mobile Networks (2011–2014)

From the iPhone 4S to the iPhone 6, mobile networks primarily used circuit-switched architecture and the AMR-NB (Adaptive Multi-Rate Narrow Band) coding standard. This limits the audio bandwidth to the 300–3,400 hertz range.

Option 1A: Rapid DTMF Sequence

DTMF (Dual-Tone Multi-Frequency) is a technology normally used for telephone tone dialling. When you press numbers on a phone, you hear different tones. Each number is a combination of two frequencies: for example, "1" is 697 Hz and 1,209 Hz simultaneously. DTMF operates on frequencies from 697 to 1,633 Hz, so it passes through all mobile networks.

Activation could be performed by sending a long, cryptographically signed number sequence — for example, 20–30 digits — but at normal speed (each digit approximately 100 milliseconds) this would take 2–3 seconds and would be clearly audible to the target.

The solution is to send the DTMF tones much faster: for example, 40–50 milliseconds per tone. The baseband can detect and decode these because it processes the raw digital audio signal, but to the human ear this would sound like only a brief, approximately 0.8–1.2 second "beep" or strange noise. The target might think there is interference on the line or that someone accidentally pressed keys rapidly.

Technically, the sequence could be, for example, a 24-digit string containing:
- A start marker (e.g. *#9)
- A 16-digit cryptographic signature (the first 64 bits of HMAC-SHA256 encoded as digits 0–9)
- An end marker (e.g. #*)

The baseband verifies the signature against a secret master key, and only a valid sequence activates the backdoor. If the signature is invalid, the sequence is silently ignored.

Option 1B: FSK-Modulated Data

Another classic technique, one that worked as far back as 1970s modems. FSK, or Frequency Shift Keying, means binary data is encoded into sound using two different frequencies. For example, 1,070 Hz means "0" and 1,270 Hz means "1." This is precisely the technique used when 1990s modems would "beep and hiss" while establishing a connection.

Because these frequencies fall within the 300–3,400 Hz band, they pass through all mobile networks. The baseband can decode this directly from the digital audio signal before it reaches iOS. The data rate would be modest — perhaps 300–600 bits per second — but this would suffice to send a 200-byte activation packet in 3–4 seconds.

The activation packet would contain:
- A synchronisation sequence (e.g. an alternating 1/0 pattern for recognition)
- A cryptographic signature
- Activation parameters (surveillance mode, duration, key material)
- A CRC or similar checksum

To the target, this would sound like strange "line noise," a "modem-like hum," or a poor connection. They might assume the caller has a bad connection or that there is interference on the network. If they hung up after a few seconds, thinking it was a wrong number, activation might already have occurred.

Option 1C: Low-Frequency Encoding (Limited)

Although AMR-NB's official band is 300–3,400 Hz, in practice the audio codec's pre-processing and post-processing extend slightly lower. In some implementations, the 200–300 Hz range may pass through in attenuated form.

By modulating data in the 220–280 Hz range at a very low bit rate (e.g. 50–100 bps), the signal could be nearly imperceptible — it would sound like nothing more than a low hum or background noise "from the line" — but the baseband could detect and decode it because it analyses the full frequency spectrum before filtering.

This option is the most uncertain, as different network operators and device models may filter low frequencies differently. It would work only under certain conditions.

4.2.2 Era 2: VoLTE Networks (2014 Onward)

The iPhone 6 was the first to bring VoLTE support (Voice over LTE). VoLTE changed the playing field radically because it is based on the IP-based SIP protocol (Session Initiation Protocol) and AMR-WB (Wide Band) or EVS coding standards, which expand the bandwidth to the 50–7,000 hertz range.

Option 2A: SIP INFO Messages (Completely Silent)

During a VoLTE call, parties can send each other SIP INFO messages, which are not audio but pure signalling data. These are normally used, for example, to indicate that the user pressed a number (DTMF) without sending it as sound, or to convey other call-related metadata.

A SIP INFO message can contain completely freely defined header fields. Activation could be a SIP INFO message with a custom header such as:

X-Network-Diagnostic: [base64-encoded activation packet]

Or any other name that looks like a legitimate network diagnostic function. Alternatives:
- X-Call-Quality-Probe
- X-Network-Metrics
- X-Bearer-Diagnostic

The baseband processes all SIP messages directly; iOS never sees them. For the user, this is completely invisible and silent. The call continues normally — no sounds, no signs.

Technically, the implementation would be:

The activation call establishes a normal VoLTE connection
A few seconds later, a SIP INFO message is sent with the activation packet
The target's baseband receives the message and validates the cryptographic signature
If valid, the baseband sends back a SIP INFO confirmation with its own parameters (IMEI, firmware version, capabilities)
The attacker sends the final configuration packet
The call can be terminated or continue normally

The entire handshake would take 2–5 seconds and would be completely invisible.

Option 2B: RTP Event Packets (RFC 4733)

This is a standardised way to send DTMF and other events in VoLTE connections without them being audio. RFC 4733 defines special RTP packets that carry "events" separately from the audio stream.

Under normal circumstances, when you press a number during a VoLTE call, the baseband sends two things: the sound (DTMF tone), which you hear, and an RTP event packet, which tells the other party "the user pressed number 5." The receiving baseband can either play the corresponding sound or process the event silently.

RFC 4733 defines event codes 0–15 for DTMF digits and a few others, but it leaves codes 16–255 "reserved for future use" or to be defined by the manufacturer.

Activation could use custom event codes (e.g. 240–250) that would appear to be manufacturer proprietary features. The baseband would recognise these event codes and activate, but would not play any sound. Completely silent for the user.

Event packets can also contain an "event parameters" field where additional data can be sent. This could carry encoded activation parameters.

Option 2C: Enhanced Low-Frequency Encoding

AMR-WB and EVS support the 50–300 Hz low-frequency range. Human speech rarely goes this low: most people have a fundamental frequency of 80–250 Hz, but vowels and most consonants are higher. The 50–100 Hz range is largely hum and background noise.

By modulating data in the 60–120 Hz range using a very low bit rate (100–200 bps), the signal could be nearly imperceptible — it would sound like nothing more than a low hum or background noise "from the line," which occurs in mobile networks regardless — but the baseband could detect and decode it because it analyses the full frequency spectrum.

This could work in parallel with a speaking person: the attacker could conduct a normal conversation ("Hello, is this Matti?" "Ah, wrong number, sorry") while the activation data travels on the low-frequency channel. The baseband could filter out the speech and decode only the low-frequency signal.

4.2.3 Recommended Hybrid Approach

The most realistic implementation would be era-specific and network-dependent. The baseband first detects what type of connection has been established:

If 2G/3G circuit-switched → use rapid DTMF or FSK modulation
If VoLTE → primary is SIP INFO, fallback is RTP events
If network conditions are uncertain → use a more robust but more audible method

The backdoor would be designed to support all of these methods and select the best one based on available resources. This would make it functional across all iPhone models from 2011 onward and in all network conditions.

In practice, however, the attacker need not be entirely blind regarding the target's device. When the target's phone number is known, the mobile network's operator systems can be queried for the IMEI code associated with that number. The IMEI, or International Mobile Equipment Identity, is a 15-digit unique identifier present in every mobile phone. The first 8 digits of the IMEI form the TAC (Type Allocation Code), which identifies the exact device model and manufacturer. For example, the iPhone 16e has its own TAC code that distinguishes it from all other models.

If the attacker has access to the operator network's HLR or HSS databases (Home Location Register or Home Subscriber Server), which maintain information about which device is connected to which phone number at any given time, they can query the target's IMEI before calling. This information is held by operators regardless, as it is needed for verifying network compatibility and blocking stolen devices via the IMEI blacklist.

Once the IMEI is known, the TAC immediately reveals that the device is, for example, an iPhone 16e using Apple's C1 modem. This in turn indicates that the optimal activation method is VoLTE SIP INFO messages and that the device supports all the latest features. The attacker can thus prepare the activation sequence in exactly the right format for the specific device before even placing the call, rather than needing to "try" different methods during the call.

This advance preparation makes the attack considerably more effective and reliable. It also shortens the required call duration, since the "negotiate capabilities" phase can either be omitted entirely or condensed to a mere confirmation that the baseband is ready and receptive. Additionally, it reduces the risk of failure, since the attacker already knows in advance that the target's device can receive the activation via the selected method.

4.2.4 Observed Activation Scenario — A Concrete Case

We have been provided with documentation of a case that is consistent with the activation mechanism described above. Although we cannot reveal all details to protect our sources, the key elements offer a concrete example of how activation could occur in practice.

In the case, two users who had the latest iPhone 16e devices (with the Apple C1 modem) received near-simultaneous calls from a service that presented itself as an ordinary company offering services to simplify everyday business operations. The call came from what appeared to be a normal local number. The calls lasted approximately 45 seconds and involved a brief conversation about the service offering.

In one case, the caller was a human who introduced the service and conversed with the target. In the other, it was an automated AI-based call in which the target confirmed interest in the service. Both targets answered the call and participated in a brief conversation.

Critical observation: After the calls, both devices exhibited behaviour suggesting data was being exfiltrated from them. The targets handled precise, non-public information on their phones related to an ongoing operational situation. This information was not in any public source nor had it been shared over any network.

Within one to two days, a state actor used that information in a manner that led to reporting in multiple media outlets. The timeline is documented and the evidence is stored securely. The material includes screenshots of call logs, written text, and subsequent news reporting that demonstrates the information reached operational use within 1–4 days of the notes being made.

Technical Analysis of the Observation:

If this was indeed a baseband backdoor activation over a VoLTE network using the iPhone 16e's C1 modem, the technical implementation would most likely have been as follows:

First, a call from a legitimate-looking number creates trust and ensures the target answers. The company brand sounds like a credible business that could offer some form of postal service. This reduces suspicion and makes it more likely the target will answer and engage in conversation.

Second, an approximately 45-second conversation provides sufficient time for the exchange of VoLTE SIP INFO messages. As described in Section 4.2.2, SIP INFO messages are completely silent and invisible to the user. Activation could occur within 5–10 seconds of answering using a SIP INFO-based handshake. The remainder of the call would be normal conversation keeping the line open and creating a normal impression.

Third, the use of both human and AI versions suggests a scalable system. An AI call is cheaper and faster at mass scale, but a human call may be necessary if the target is of particular importance or if flexibility is needed. Both methods work equally well for technical activation purposes, since SIP signalling occurs at the baseband level regardless of whether the user is speaking with a human or an AI.

Fourth, data exfiltration from the iPhone 16e would be particularly significant because this device uses Apple's first in-house modem. This would suggest that the backdoor is not limited to external modem manufacturers but is integrated into Apple's own C1 design as well. This would be extremely concerning because it would mean the backdoor has been built into the fundamental baseband architecture from the ground up and is not merely a Qualcomm or Intel legacy feature.

Fifth, intercepting written text would require the baseband to access keyboard input or screen content. This would be possible via DMA access or if the baseband can read the framebuffer memory where screen content is stored. Alternatively, the baseband could capture text at the moment it is transmitted (e.g. as a text message or email) before encryption.

Ruling Out Alternative Explanations:

It would theoretically be possible that the information leaked in some other way — for example, if the users had discussed it by phone or if their devices had been compromised by some other means, such as Pegasus-style spyware — but the documentation rules these out for the following reasons.

First, the information did not travel over an unencrypted network in any form before the leak. The users did not send it via email, text message, or any messaging application. They only wrote it in notes or a similar local storage location. Second, the users did not discuss the matter by phone or in person with anyone who could have relayed the information. Third, the devices were new — two weeks old — and fully updated to the latest iOS version, making traditional spyware unlikely. Fourth, the timeline and correlation with the company calls is too precise to be coincidence: both calls came within a short time of each other, and the data leaked soon after.

This concrete case provides strong evidence that a baseband-level backdoor is not mere speculation but a potentially active system that functions even on the latest iPhone models with Apple's own C1 modem.

4.3 Data Exfiltration — Covert Transmission of Information

Once the backdoor is activated, it must collect data and transmit it to the operator undetectably. This is a multi-stage process requiring careful design to remain hidden.

4.3.1 Data Collection

The baseband processor has direct access to several critical sensors and data sources.

Microphone audio is perhaps the most valuable data source. The baseband can activate the microphone directly without iOS knowing about it. Normally, when an application uses the microphone, iOS displays an orange dot at the top of the status bar, but the baseband can bypass this entirely by sending commands directly to the audio codec chip that controls the microphone.

The technical implementation depends on the hardware architecture. iPhones have used different audio codec chips across different models — for example, a Cirrus Logic CS42L83 or similar. These communicate with the baseband via the I2C bus (Inter-Integrated Circuit — a serial bus protocol). The baseband can send I2C commands that activate the microphone and begin reading digitised audio data. Because this occurs entirely at the baseband firmware level, iOS sees nothing: from the operating system's perspective, the microphone is passive.

GPS data is another valuable source. The baseband controls the GPS antenna directly (or in many of the latest architectures, GPS is integrated into the same chipset as the baseband). It can query GPS coordinates at, say, ten-second intervals. This data is often more accurate than what iOS's Location Services API returns, because the baseband can use assisted GPS data from the mobile network to improve accuracy.

Messages such as SMS and iMessage are a third category. The baseband sees all SMS messages because they come directly from the mobile network. It sees the text before it ever reaches iOS. iMessage is more complex because the messages are end-to-end encrypted, but the baseband could still see metadata (who sent, when, message size) and could potentially capture text if it has DMA access to the memory area where the Messages application processes decrypted messages.

Calls and metadata are also valuable information. The baseband sees all placed and received calls, their duration, numbers, and timestamps. It also sees the network location (cell tower ID), which reveals an approximate location.

4.3.2 Data Compression and Encryption

Once data has been collected, it must be compressed and encrypted before transmission.

For audio data, the best codec is Opus, a modern audio codec that achieves an excellent compression ratio while retaining good quality. 48 kHz, 16-bit mono audio normally requires approximately 768 kilobits per second, but Opus can compress it to under 16–20 kilobits per second depending on the audio characteristics. This is a compression ratio of approximately 40:1.

If surveillance has been activated for, say, 12 hours and the microphone records continuously, the raw data would be approximately 414 megabytes. Compressed with Opus, this would be approximately 10 megabytes — a manageable amount to send over a mobile network over the course of a few days.

For GPS and metadata, general compression such as gzip can be used. GPS coordinates can be stored delta-encoded (only changes from the previous point), which significantly reduces size when the target is not moving rapidly.

Encryption is performed using the AES-256-GCM algorithm (Advanced Encryption Standard with 256-bit key in Galois/Counter Mode). GCM mode provides both confidentiality and authentication: it ensures that no one can read the data without the key or modify it undetected.

The encryption key is derived from key material exchanged during the activation phase using the ECDH key exchange protocol (Elliptic Curve Diffie-Hellman). This provides forward secrecy — even if the long-term master key were later leaked, it would not reveal previously collected data, because each activation uses a unique session key.

4.3.3 Data Transmission — The Masquerade Strategy

The most critical part is transmitting data in a way that is not detected. The hypothetical backdoor would use masking within legitimate traffic.

Strategy: Blending into iOS Update and iCloud Traffic

Apple uses Content Delivery Network (CDN) infrastructure to distribute iOS updates, App Store content, iCloud data, and more. In an iPhone's normal operation, the device continuously connects to Apple's servers.

The backdoor would make an HTTPS request that looks entirely normal:

The DNS query goes to an address like swcdn.apple.com or updates-http.cdn-apple.com
The IP address is a real Apple CDN server (e.g. on the Akamai network)
The TLS certificate is a genuine Apple certificate (wildcard *.apple.com or similar)
The HTTP Host header is updates-http.cdn-apple.com
The User-Agent is identical to iOS's normal traffic

All of this is identical to normal traffic. The only difference is the HTTP path and POST data content.

The HTTP path could be:

/bag?ix=5&agent=Software%20Update&v=4&os=18.2

This looks like a normal iOS Software Update query. In reality, the POST data content is encrypted exfiltrated data.

Or alternatively:

/assets/com.apple.MobileAsset.SoftwareUpdate/com_apple_MobileAsset_SoftwareUpdate/[random-looking-hash].zip

This would look as though the device is downloading an iOS update package. In reality, it is SENDING data (HTTP POST instead of GET).

Backend Infrastructure:

If such a system existed, it would require covertly managed backend infrastructure. This could be implemented in two ways:

Option A: Compromised CDN Server

A specific CDN edge server or a small portion of Apple's infrastructure would be silently modified to redirect certain types of requests to a different backend server. For example, a reverse proxy rule:

IF (HTTP_PATH matches /bag?ix=5 AND 
    POST_data_size > 1MB AND
    Custom_HTTP_header present)
THEN forward to special_backend_server
ELSE process normally

To normal users and network monitoring, everything would look entirely normal. Only requests containing a special "fingerprint" combination would be routed to the covert server.

Option B: Separate Infrastructure

An alternative implementation would use entirely separate server infrastructure configured to resemble Apple's CDN:

Register a domain like cdn-apple-edge.com that looks credible
Configure DNS name servers to respond like Apple's CDN
Obtain a valid TLS certificate (or use a private CA if the baseband trusts it)

The baseband would perform a DNS query to this domain (bypassing iOS's DNS cache) and connect directly to this server. iOS would not see this traffic at all because it occurs at the baseband level.

This would be riskier, as network monitoring could detect connections to non-Apple domains. Therefore, Option A (compromised legitimate infrastructure) would be more likely.

4.3.4 Timing and Traffic Patterns

Data is not sent in large bulk transfers but in small packets that blend into normal traffic.

For example, audio data can be sent in 30-second segments encrypted and compressed into packets of approximately 100–200 kilobytes. The baseband sends one packet when the device is communicating with the network for other reasons:

When the user downloads email
When the user browses the web
When iOS checks for updates in the background
When iCloud synchronises data

This makes traffic analysis extremely difficult, because there is no clear pattern distinguishing backdoor traffic from normal traffic. An iPhone already makes dozens of HTTPS connections to Apple servers every day.

Additionally, the baseband avoids suspicious patterns:

If the user is in aeroplane mode or offline → nothing is sent; data is queued
If the battery is nearly depleted → transmission is avoided (additional power consumption would be detectable)
If the network is slow or unstable → transmission frequency is reduced
If the user is on a roaming network → either transmission is avoided or very small packets are used (large data volumes while roaming could raise suspicions on the bill)

Adaptive Transmission Rate:

The backdoor could analyse the user's normal data usage patterns during the first hours and then match its own traffic accordingly. If the user regularly downloads videos or uses data heavily, the backdoor could transmit more aggressively. If the user is a conservative data consumer, the backdoor would transmit more slowly to avoid detection.

4.4 Evasion of Detection — Multi-Layered Defence

For a hypothetical backdoor to remain hidden for years, it would need to incorporate multiple layers of defence against various detection methods.

4.4.1 Firmware-Level Obfuscation

Integration of code among legitimate functions:

Rather than a clearly distinguishable "backdoor_main()" function, the backdoor logic would be distributed across multiple functions that appear to be part of normal baseband functionality.

For example:
- DTMF decoding could be part of a normal audio codec function with an additional branch that checks for special sequences
- SIP INFO processing could be part of normal SIP protocol code
- Microphone activation could be part of "diagnostics mode" functionality, which is a legitimate feature for testing purposes

Code obfuscation:

Dead code insertion: code that appears to do something but in reality has no effect
Control flow obfuscation: arranging if-statements and loops in illogical ways
String encoding: strings stored in encoded form and decoded at runtime
Opaque predicates: conditions that are always true/false but whose value is not apparent from static analysis

Reuse of cryptographic primitives:

The baseband already requires AES encryption and RSA signature verification for mobile network authentication. The backdoor would use the same cryptographic functions the firmware already contains. Static analysis would see only that "this function calls AES_encrypt()," which is entirely normal.

4.4.2 Traffic-Level Concealment

TLS Encryption:

All network traffic is TLS-encrypted, which prevents content inspection. Even if someone were able to break TLS (for example, in an enterprise environment with a TLS-intercepting proxy), they would see only encrypted binary data in the HTTP POST request body — which could well be part of an iOS update or App Store synchronisation.

Use of normal protocols:

No unusual ports or protocols are used. Everything is standard HTTP/HTTPS (ports 80/443). DNS queries are normal A/AAAA records. The TLS handshake is identical to iOS's normal traffic.

Timing side-channel mitigation:

Transmission timing varies randomly to avoid regular patterns detectable by network monitoring. If data is sent on average every 5 minutes, the actual interval varies between 3 and 8 minutes.

4.4.3 Power Consumption Concealment

The baseband is already active managing mobile network communication, so additional processing from the backdoor does not cause a significant difference in battery consumption. Modern baseband processors are efficient enough that audio encoding and encryption do not require significantly more power than normal 4G/5G modem operations.

Additionally:
- The microphone is activated only during the activation state, not continuously
- GPS queries are made at a low frequency (e.g. once per 30 seconds) rather than continuous tracking
- Data transmission is timed to moments when the baseband is already active (data synchronisation, email retrieval, etc.)

4.4.4 Operating System-Level Isolation

iOS sees nothing because everything occurs at the baseband firmware level, which is outside the operating system's visibility.

There is no API that iOS could use to ask "what is the baseband doing right now" or "show the baseband's memory contents" or "report all I2C commands the baseband has sent." iOS can send commands to the baseband (e.g. "call this number") but cannot receive reporting on its internal state.

This is a fundamental architectural difference that makes a baseband-level threat so difficult to detect with operating system-level tools. There is no iOS application that could detect this backdoor, because applications cannot access the baseband layer.

5. iPhone Model-Specific Analysis

The practical implementation of a hypothetical backdoor would depend on which iPhone model it resides in and which baseband modem that model uses. This section analyses how a backdoor could have theoretically been implemented across different eras.

5.1 Foundation: iPhone 4S – iPhone 6s (2011–2015)

This period would represent the founding and early phase of the hypothetical project. The iPhone 4S was released in October 2011 and was the first iPhone to use a Qualcomm modem — the MDM6610. This was a significant transition, as earlier models had used an Infineon modem (which later became Intel).

The Qualcomm MDM6610 was a relatively simple 3G modem supporting CDMA2000 and UMTS/HSPA networks. The firmware was much smaller and simpler than modern 5G modems, where firmware can exceed 100 megabytes. This would make integrating a backdoor easier, as there would be less complexity in the codebase to hide within.

Technically, the MDM6610 was based on the ARM9 processor architecture and contained a separate DSP (Digital Signal Processor) for radio signal processing. A hypothetical backdoor could be placed at the DSP firmware level, which affords even less visibility than the main ARM code. The DSP executes highly optimised assembler code for signal processing, and its reverse engineering is particularly difficult.

The iPhone 5 introduced LTE support with the Qualcomm MDM9615 modem. This modem brought a significantly more complex firmware architecture because it had to support both legacy 2G/3G networks and the new LTE standard. Firmware size grew and a modular architecture was introduced, with separate components for different radio technologies.

A modular architecture would offer an ideal hiding place for a backdoor. It could be implemented as a "diagnostics module" that would appear to be an engineering tool for testing. Mobile devices traditionally have extensive diagnostics modes with which engineers can test RF performance, signal strengths, and protocol operation. A backdoor could be disguised as part of this diagnostics infrastructure.

The iPhone 5s introduced the first Secure Enclave, a separate security processor that handles Touch ID data and cryptographic keys. It is important to note that the Secure Enclave is entirely separate from both the main processor and the baseband. It is its own processor with its own firmware and memory. This means that even if the baseband were compromised, it would not directly gain access to the Secure Enclave and, through it, to the user's fingerprints or encryption keys stored there.

This period ended with the iPhone 6s, which used the Qualcomm MDM9635M modem. By this point, the architecture had stabilised and a hypothetical backdoor would have been operational for several years. Firmware updates could have brought minor changes to the backdoor code — perhaps new functionality or improved concealment — but the basic mechanism would have remained the same.

Activation during this era would have relied on rapid DTMF sequences or FSK modulation, since VoLTE was not yet widely available.

5.2 Transition Period: iPhone 7 – iPhone X (2016–2017)

This period is extremely interesting from the perspective of the hypothetical scenario because it includes a transition in which Apple began using two different modem manufacturers simultaneously.

The iPhone 7 and 7 Plus were released in September 2016 in two variants. Some models used the Qualcomm MDM9645M modem (models A1660 and A1661, sold to Verizon, Sprint, and certain international markets), while others used the Intel XMM7360 modem (models A1778 and A1784 for AT&T, T-Mobile, and European GSM operators).

This split strategy created an interesting challenge for a hypothetical backdoor. If the backdoor were only in the Qualcomm firmware, approximately half of the devices would lack it. Logic dictates that the backdoor would need to be in the Intel modem as well.

The Intel XMM7360, however, was an entirely different architecture from Qualcomm's MDM series. Intel uses its own firmware architecture based on an Intel Atom-based processor for LTE protocol processing and a separate FPGA/ASIC (Field Programmable Gate Array / Application-Specific Integrated Circuit) for digital signal processing. The firmware structure is different, using Intel's own development tools and abstractions.

In the hypothetical scenario, the backdoor would have needed to be integrated into the Intel firmware as well. This would have required either cooperation with Intel or, alternatively, covertly obtained access to Intel's firmware code and development tools. Another possibility is that Apple itself integrates the backdoor as part of the firmware customisation they perform when taking a modem manufacturer's base firmware and optimising it for the iPhone platform.

An interesting technical detail is that the Intel version received public criticism for weaker performance. Benchmarks showed that the Intel-modem models' LTE speeds were approximately 30 per cent lower than the Qualcomm models' under comparable network conditions. The official explanation was that the Intel modem did not support all the same LTE features, such as 4x4 MIMO or 256-QAM modulation.

The iPhone 8, 8 Plus, and X continued with the same split strategy using Qualcomm MDM9655 and Intel XMM7480 modems. These were more advanced versions supporting faster LTE-A (LTE Advanced) traffic and improved features, but the fundamental architecture remained the same.

This era marked the transition toward VoLTE-based activation. Although older methods (DTMF, FSK) were retained for compatibility, the new SIP INFO and RTP events methods offered a quieter and more reliable activation pathway.

5.3 The Intel Era: iPhone XS/XR and iPhone 11 (2018–2019)

In 2018, a significant change occurred: Apple switched to using only Intel modems across all models. The iPhone XS, XS Max, and XR used the Intel XMM7560 modem. Qualcomm was entirely out.

The official explanation was the legal battle between Apple and Qualcomm that began in 2017, concerning patent licensing fees. Apple accused Qualcomm of monopolistic pricing, and Qualcomm responded by accusing Apple of patent infringement. The legal case was complex and spanned multiple jurisdictions.

The Intel XMM7560 was a significant upgrade over the previous XMM7480. It supported LTE Category 16 (up to 1 Gbps download) and included broader support for various LTE bands. The firmware was significantly larger and more complex. The increase in complexity makes the reverse engineering process even more difficult — when firmware is 80–100 MB compressed and contains tens of thousands of functions, finding a single backdoor function is like searching for a needle in a haystack.

The iPhone 11, 11 Pro, and 11 Pro Max (2019) used the Intel XMM7660 modem. This was Intel's last modem in an iPhone. In public reporting, Intel was said to be struggling with 5G modem development and Apple was reported to be dissatisfied with Intel's roadmap.

5.4 Return to Qualcomm: iPhone 12–16 (2020–2024)

In April 2019, Apple and Qualcomm reached a surprise settlement in all their legal cases. The agreement included a six-year licensing agreement and the use of Qualcomm chips in Apple's devices. Only months later, Intel announced its withdrawal from the 5G smartphone modem business. Apple purchased Intel's smartphone modem division (approximately 2,200 engineers and 17,000 patents) for one billion dollars.

The iPhone 12 series was released in October 2020 and was the first 5G iPhone. It used the Qualcomm Snapdragon X55 5G modem. This was a significant leap in complexity — the 5G NR (New Radio) standard is a massive addition to firmware requirements, including beamforming for millimetre-wave frequencies, dual connectivity where the device can be connected to both LTE and 5G networks simultaneously, and considerably more complex MIMO processing.

The Qualcomm X55 firmware is estimated to be over 100 megabytes in size and contain millions of lines of code. Such a massive codebase offers ample opportunity to hide additional functionality. Complexity is both a challenge and an opportunity — it makes reverse engineering extremely difficult.

The iPhone 13 series used the Qualcomm X60 modem, the iPhone 14 series the X65, and the iPhone 15 series the X70. Each generation brought improvements in 5G performance, energy efficiency, and features. The firmware continued to grow and become more complex.

The iPhone 16 series uses the Qualcomm Snapdragon SDX71M modem. This is the latest Qualcomm modem currently on the market, supporting 5G Release 17, which includes features such as reduced capability (RedCap) devices and satellite connectivity capabilities.

5.5 A New Era: The Apple C1 Modem (2025–)

The iPhone 16e, released in February 2025, was historic: it contained the first baseband modem entirely designed by Apple itself, codenamed C1.

This is an analogous transition to Apple's move from Intel processors to its own Apple Silicon chips (the M-series in MacBooks and the A-series in iPhones). Now Apple controls the entire chipset design including the modem, providing complete vertical integration.

The C1 modem is manufactured using TSMC's (Taiwan Semiconductor Manufacturing Company) N4P process (4-nanometre processor technology). It is integrated as part of the A18 SoC rather than being a separate chip. This tight integration enables better energy efficiency and performance because the baseband and main processor can communicate faster and with lower power consumption.

In the hypothetical scenario, Apple's own modem would be both a risk and an opportunity. With Apple controlling the entire design, building a backdoor from the ground up would require either the conscious involvement of Apple's engineers or the ability to influence the design process at some stage.

But it is also an opportunity to make the backdoor even more deeply integrated. When the same entity designs both the baseband and the main processor, they can optimise the architecture. For example, DMA channels could be designed so that the baseband can access certain memory areas efficiently, but this would not be visible in external documentation.

Furthermore, when the firmware is developed from scratch, the backdoor can be architected as part of the core system rather than being "added on top." This would make it even more difficult to distinguish from the rest of the code.

TSMC's role is also interesting. The manufacturing process uses lithography masks that define how transistors are formed on silicon. If the hypothetical backdoor were partly at the hardware level (for example, a special hidden register file or memory area), this would need to be included in the lithography masks. TSMC manufactures chips according to Apple's specifications, but it is unclear how deep an analysis they perform on the mask data.

6. Detection — A Technical Guide

If a hypothetical baseband backdoor existed, how could it be detected? This section describes technical methods a researcher could use to attempt to find such a backdoor.

6.1 Firmware Analysis

The first and most obvious approach would be direct analysis of the baseband firmware. This requires firmware dumping, which in turn requires JTAG debugger access to the baseband processor.

JTAG Access and Firmware Dumping:

JTAG (Joint Test Action Group) is a standardised debug interface used for hardware testing and debugging. Nearly all modern processors have JTAG ports that enable direct memory access, register reads, and code stepping. For security reasons, JTAG ports are often disabled on production devices, but the physical pins are still present on the PCB.

Disassembling an iPhone is the first step. This requires specialised tools such as an iSlack (suction cups for removing the screen) and extremely fine screwdrivers. The baseband modem is located on the logic board, and identifying it requires familiarity with datasheets and reading the chip markings under a microscope.

Next, the researcher must identify the JTAG pins. These are usually not clearly labelled and require probing with a multimeter and searching for schematic diagrams. In some cases, micro-soldering (working under a microscope) is needed to attach wires directly to the chip's pins.

Once a JTAG connection is established, the researcher can use tools such as OpenOCD (Open On-Chip Debugger) or JLink software to communicate with the processor. The first task is firmware dumping — copying the entire contents of flash memory to a file for examination.

Dumping is not necessarily trivial. Some modern processors have read protection that prevents firmware reading via JTAG. Bypassing this may require physical attacks such as voltage glitching (a momentary drop in supply voltage that causes a processor fault state) or laser fault injection (using a laser to temporarily corrupt memory cells).

Reverse Engineering:

Once the firmware has been dumped to a file, reverse engineering begins. The first step is disassembly — converting machine code into assembly language. Tools such as IDA Pro, Ghidra, or Binary Ninja are the industry standard for this. They automatically identify functions, create code flow graphs, and attempt to identify library functions.

But baseband firmware is vast: tens or hundreds of megabytes and millions of assembler instructions. Simply scrolling through it is impossible. The researcher must use heuristics to search for areas of interest:

Searching for cryptographic functions: AES and RSA algorithms have recognisable code patterns: specific operations such as S-box lookups in AES or modular exponentiation in RSA. Tools can scan firmware for these patterns. When a crypto function is found, the researcher can trace who calls it and for what purpose.

Searching for strings: Even if firmware is obfuscated, it will likely contain some error messages, debug prints, or other text. Searching for unusual strings could yield clues. Of course, if the backdoor is well-designed, obvious strings will have been removed or obfuscated.

Function size analysis: Most functions are relatively small — from a few dozen to a few hundred instructions. If there is a very large function containing thousands of instructions, it may be complex and potentially hiding unusual logic.

Comparing firmware versions: If updated firmware is available for multiple iPhone models, a diff analysis can be performed to see what changed. Most changes relate to bug fixes or new features, but anomalies could reveal hidden code.

6.2 Live Testing and Signal Analysis

A second approach is to test the device's behaviour in a live environment and look for unusual activity.

Activation Experiment:

A researcher builds a fake base station using software-defined radio (SDR) hardware such as a USRP (Universal Software Radio Peripheral) or BladeRF combined with software such as OpenBTS or srsRAN, which implements GSM/LTE base station logic.

The fake base station is configured to look like a normal mobile network. The iPhone is connected to it (inside a Faraday cage so that real networks are not disrupted). The researcher then calls the iPhone and, when the call is answered, sends the suspected activation sequence — either rapid DTMF, FSK data, or in a VoLTE environment, a SIP INFO message.

Baseband Processor Monitoring:

If a JTAG connection is active, the researcher can set breakpoints — stopping points that halt code execution at a specific address. If the baseband suddenly jumps to an address not normally used, this could be a sign of activation.

Power Consumption Analysis:

Power is supplied to the iPhone through a specialised device that measures current at microampere precision continuously. If the baseband begins a new processing operation, power consumption changes. Side-channel analysis uses such physical characteristics to infer what the processor is doing.

RF Signal Analysis:

The researcher uses a spectrum analyser to monitor what radio signals the iPhone transmits. If the backdoor activates and begins transmitting encrypted data, this will be visible as increased RF activity on certain frequencies. Although the content cannot be read, analysis of the RF activity pattern can reveal unusual behaviour.

Network Traffic Capture:

The researcher sets the iPhone to operate through a proxy server that records all HTTP/HTTPS traffic. Although TLS encryption prevents reading the content, metadata is still visible — which IP addresses connections are made to, when, and how much data is transferred.

If the backdoor is transmitting data, it would appear as increased traffic. The researcher could compare normal iOS usage (without activation) against the post-activation situation to see whether traffic patterns differ.

TLS-Intercepting Proxy:

In an enterprise environment, a custom root certificate can be installed on the iPhone to enable a man-in-the-middle position for HTTPS traffic. This allows inspection of encrypted traffic. If the researcher does this, they could see the exact HTTP requests, including paths and POST data.

However, it should be noted that if the backdoor is truly well-designed, it may detect TLS interception (because the certificate is not Apple's original) and deactivate itself to avoid detection.

6.3 Comparative Analysis Across Models

An effective way to search for anomalies is to compare multiple devices and models against one another.

A researcher could acquire, for example, ten different iPhone models from different generations (4S, 5, 6, 7, X, 12, 14, 16) and perform an identical test sequence on each. If all devices behave the same way under a given condition but one model deviates, this requires deeper investigation.

Comparative analysis of baseband firmware across models could reveal common code patterns. If there is a specific function that is identical from the iPhone 5 through the iPhone 16 but is not documented, this is suspicious. Normally, firmware evolves over time and old functions are replaced by new ones. If some code remains unchanged, it suggests it is a critical part of the architecture that is not intended to be changed.

A researcher could also compare the same model across different market regions. For example, the iPhone 7 has versions for the United States (A1660/A1661), Europe (A1778/A1784), and China (A1660). If firmware differs between these in ways other than expected (merely radio frequency differences), it could point to region-specific modifications, possibly for political reasons.

6.4 Challenges and Limitations in Detection

It is important to acknowledge that detecting a well-designed baseband backdoor is extremely difficult, even with significant resources. There are several reasons for this.

Firmware is massive and complex: A complete analysis would require years of work by a team of experienced reverse engineering specialists. This is impractical in terms of both time and funding for most researchers or even universities.

Protection mechanisms: JTAG ports are disabled, read protection is active, and firmware is cryptographically signed. Bypassing these requires specialised hardware hacking expertise.

Active resistance: If the backdoor truly exists and there are parties aware of it who wish it to remain secret, they may actively attempt to prevent detection. A researcher might face pressure to stop: legal threats, loss of funding, or in the worst case, personal threats.

Burden of proof: "Proof of non-existence" is nearly impossible. Even if a researcher analyses the firmware thoroughly and finds nothing suspicious, it does not prove the backdoor does not exist. It may simply be too well hidden to be found. This is a fundamental epistemological challenge in all security research.

7. Conclusions and Implications

7.1 Technical Feasibility and Real Evidence

Based on this analysis, a hypothetical baseband-level backdoor is technically feasible. All the mechanisms described in this document are based on real technology and known protocols. There is nothing "magical" or contrary to the laws of physics in any part of this hypothetical system.

But this is no longer mere theory. As described in Section 4.2.4, we have access to documentation that strongly suggests such a system actually exists and is actively in use. The case described is not our only observation, but it is sufficiently documented and verifiable that we can share it publicly.

This fundamentally changes the nature of the analysis. We are no longer asking "could this be possible" but rather "how does this work and how can we protect ourselves from it."

Critical feasibility elements now corroborated by real observations:

The baseband processor's privileged position: Because the baseband operates outside the operating system's visibility and handles all radio communication, it is an ideal location for a backdoor. iOS cannot supervise or restrict the baseband's operation in any meaningful way. This is no longer mere theory: we have observed behaviour consistent with this.

Call-based activation mechanisms: VoLTE SIP INFO messages provide a completely undetectable way to send activation commands. This case demonstrates that an ordinary phone call can be used for activation in a manner that arouses no suspicion in the user.

Compromise of the Apple C1 modem: Particularly concerning is that the observations involve the iPhone 16e model, which uses Apple's first entirely self-designed C1 modem. This means that if the backdoor exists, it is not limited to products from external modem manufacturers (Qualcomm, Intel) but extends to Apple's own design as well. This is a significant revelation suggesting that the backdoor is built into the fundamental baseband architecture rather than being merely a legacy feature from older modems.

Firmware signing: Although firmware is digitally signed, this provides no protection if the signing party (the modem manufacturer or device manufacturer) itself includes the backdoor. The signature only ensures the firmware comes from the correct party — not that it is benign.

Activation mechanisms: Call-based activation mechanisms are realistic, particularly in the VoLTE era. SIP INFO messages provide a completely undetectable way to send activation commands and receive confirmations.

Data exfiltration: Masquerading within legitimate traffic is a proven working technique. When the backdoor uses the same protocols, the same servers, and the same encryption practices as normal traffic, distinguishing it is extremely difficult.

7.2 Historical Precedents

The Crypto AG and Dual EC DRBG cases demonstrate that:

Hardware-level backdoors can remain hidden for decades
Standardisation processes can be manipulated
Large-scale institutional support enables long-term operations
Technical complexity protects against exposure

Baseband firmware meets all the same criteria that made these historical cases successful long-term operations.

7.3 Challenges of Defence

An ordinary user has practically no means of detecting or defending against a hypothetical baseband backdoor. All normal security measures — VPNs, end-to-end encryption, security software — operate at the operating system level and are ineffective against a threat implemented at the baseband level.

Even technically experienced users face significant challenges:

Firmware analysis requires specialised hardware and years of expertise
Live testing requires expensive SDR equipment and deep understanding of telecommunications protocols
Network monitoring is ineffective due to TLS encryption and masquerading as legitimate traffic

7.4 Broader Societal Implications

If such a backdoor existed, its effects on privacy and society would be profound:

The collapse of privacy: Every call, message, location, and digital activity could be subject to surveillance without the user having any way of knowing or preventing it.

The erosion of trust: If a baseband backdoor were exposed, it would shake trust in all technology companies and devices. How could anyone trust any device going forward?

Power imbalance: Access to such surveillance capability creates an enormous imbalance between those who have access to the system and those who do not.

7.5 Recommendations for Improving Transparency

Although this analysis is speculative, it raises real challenges in baseband security. The following measures could improve the situation:

Open-source baseband firmware: A fully open-source baseband firmware implementation would enable independent auditing. Projects such as Osmocom have begun this work but have not yet achieved commercial viability.

Independent auditing: Manufacturers could allow independent security firms to audit baseband firmware on a regular basis. This would require confidentiality agreements but would increase transparency.

Hardware-level isolation: Physically isolating the baseband from the main processor and implementing stricter IOMMU restrictions would reduce the impact of a compromised baseband.

User-level monitoring: Developing tools that give users better visibility into the baseband's operation — for example, when the microphone or GPS is active at the baseband level.

Firmware transparency: Publishing public changelog documentation for baseband firmware updates with detailed explanations of what changes were made and why.

7.6 In Closing — Why This Document Exists

This analysis is no longer mere speculation. It is documentation of a real threat affecting millions of people around the world, including users of the latest iPhone 16e model who may believe that the use of Apple's own C1 modem makes their devices safer.

We are publishing this document for several reasons:

First, responsible disclosure. We have access to material strongly suggesting the existence of this threat. We can either keep it secret — which helps no one — or share the information in a way that helps the security community and ordinary users understand the risk. We have chosen the latter.

Second, preservation of documentation. This analysis and the associated evidence have been stored securely in multiple locations.

Third, activation of the security community. We are not the only ones who can investigate this. By publishing a technical analysis, we provide tools and methods to other researchers who wish to confirm or refute our findings. The more people researching baseband security, the harder it becomes to keep potential backdoors hidden.

Fourth, political and societal discussion. This is not merely a technical question but a fundamental question about privacy, surveillance, and who holds power in our society. If baseband-level surveillance is possible and in use, society must decide whether this is acceptable and on what terms.

We understand that publishing this document may provoke reactions, but we believe that transparency is ultimately the best guarantee of security. Surveillance systems operating in the shadow of secrecy are more dangerous than those subjected to public scrutiny.

Concrete Next Steps:

We recommend that the security community focus on the following measures:

Independent auditing of baseband firmware, particularly from the iPhone 16e's C1 modem
In-depth analysis of VoLTE SIP signalling to detect unusual messages
Comparative testing across different iPhone models under similar conditions
Development of open-source baseband implementations that enable full transparency

For ordinary users, the truth is regrettably simple: if a baseband-level backdoor exists, you have practically no means of defending against it using conventional methods. VPNs, end-to-end encryption, and security software do not help because they operate at the operating system level.

The only real protection is transparency and public oversight. That is why this document exists.

Note on Source Protection:

This document describes a case referencing a service delivered by a specific company. This is a real observation from real phone calls. However, we do not disclose all details — such as the number used, the name, or all the material at our disposal — at this stage.

Sources

Washington Post, ZDF, SRF (2020): "The intelligence coup of the century" — Crypto AG investigation
Shumow, D., Ferguson, N. (2007): "On the Possibility of a Back Door in the NIST SP800-90 Dual Ec Prng"
3GPP Technical Specifications — TS 24 series (VoLTE, IMS signaling)
RFC 4733: "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals"
Qualcomm Snapdragon X-series modem technical documentation
Apple iOS Security Guide (various versions 2011–2024)
Mulliner, C., Miller, C. (2009): "Fuzzing the Phone in your Phone" — Black Hat USA
Grassi, P. et al (2013): "Baseband Attacks: Remote Exploitation of Memory Corruptions in Cellular Protocol Stacks"
Project Zero (Google): Various baseband security research publications
ETSI Technical Specifications for AMR-NB, AMR-WB, and EVS codecs