The Black Boxes in Your Devices

Proprietary firmware runs with full access to your system. You can't see what it does.

State of Surveillance Editorial Team

Researchers reverse-engineering a MediaTek phone modem found something disturbing: custom AT commands that could capture keyboard events, take screenshots, access the camera, and emulate key presses - all executable remotely from the carrier's network. This wasn't a bug. It was a feature, buried in proprietary firmware that no one outside the company was supposed to see. Your phone runs dozens of these black boxes. So does your computer.

Every modern device contains proprietary firmware - closed-source code running on dedicated processors that you can't inspect, audit, or control. These aren't peripheral components. They have direct memory access, network connectivity, and often run before your operating system even loads. They're the foundation your security is built on - and you have no way to verify what they're doing.

This isn't theoretical risk. It's documented reality. Here's what's actually running inside your devices.

The Baseband Processor: A Phone Within Your Phone

Every smartphone contains two computers. The application processor runs Android or iOS - the part you interact with. The baseband processor handles all cellular communication: calls, texts, data. It's a complete system with its own CPU, operating system, and direct access to your device's memory. [1]

The baseband firmware is completely proprietary. Qualcomm, MediaTek, Samsung - none publish source code. Independent security researchers can only examine it through reverse engineering, which is difficult, time-consuming, and legally fraught.

What researchers have found is alarming:

  • Remote code execution vulnerabilities: Multiple baseband exploits allow attackers to run arbitrary code on your phone through malicious cellular signals - no user interaction required [2]
  • Memory access: The baseband can read and write to the application processor's memory, bypassing any OS-level security
  • Persistence: Malware can be embedded in baseband firmware, surviving factory resets and OS reinstalls [3]
  • Hidden capabilities: Researchers found telemetry routines capturing keystrokes, screenshots, and camera output - triggered remotely by carriers [1]

Security researcher findings: "There are so many vulnerabilities in the baseband that it's not even funny. If a government agency wanted to drop a persistent baseband rootkit on your device with full access to userspace, they could." [1]

The lack of basic security measures is striking. Researchers auditing 5G modems "quickly noticed the absence of stack cookies mitigation" - a fundamental protection against buffer overflow attacks that's been standard in application software for decades. [2]

Why This Matters

Your phone's baseband:

  • Has network access independent of your OS
  • Can be remotely updated by carriers without your knowledge
  • Runs constantly while the phone has power
  • Has DMA (direct memory access) to your main system
  • Cannot be disabled or replaced with open-source alternatives

There is no feasible open-source baseband. OsmocomBB is the closest attempt, but it's incomplete and only works on badly outdated hardware. For any modern phone, you're running mystery code with root-level access to your device.

Intel Management Engine: The Computer Inside Your Computer

Since 2008, virtually every Intel processor has contained the Intel Management Engine (ME) - a separate computer running inside your CPU. The ME has its own processor, memory, and operating system (based on MINIX). It runs even when your computer is "off" - as long as the motherboard has power. [4]

What the ME can do:

  • Full memory access: The ME can read and write any address in RAM, completely invisible to your operating system
  • Network access: Through Intel's Active Management Technology (AMT), the ME can send and receive network traffic even when the computer is powered off
  • Bypass security: The ME operates below the OS level, making it invisible to antivirus, firewalls, and any software-based security

The Electronic Frontier Foundation and security researchers have called the ME a potential backdoor. Security researcher Damien Zammit noted the ME "has full access to memory without the owner-controlled CPU cores having any knowledge, and has full access to the TCP/IP stack and can send and receive network packets independently of the operating system, thus bypassing its firewall." [4]

Documented Vulnerabilities

In 2017, CVE-2017-5689 revealed a critical vulnerability allowing unauthorized network attackers to execute arbitrary code with administrative privileges on the ME. This affected virtually every Intel system shipped in nearly a decade. [5]

Intel's response has been to deny the ME is a backdoor: "Intel does not put backdoors in its products, nor do our products give Intel control or access to computing systems without the explicit permission of the end user." [4]

But here's the problem: we can't verify this. The ME firmware is proprietary and encrypted. We really don't know what it's doing - we only have Intel's word.

Can You Disable It?

Before 2008, ME firmware could be removed. Now, if you remove or corrupt the ME firmware, the computer shuts off after 30 minutes. You can partially disable ME after boot using projects like me_cleaner, but the ME still runs during startup and can't be fully eliminated. [5]

AMD Platform Security Processor: AMD's Version

AMD processors have an equivalent called the Platform Security Processor (PSP) - an ARM processor embedded in the CPU that runs its own firmware with full system access. [6]

The PSP:

  • Boots before the main CPU and controls whether the system can start
  • Has unrestricted access to system memory
  • Runs a complete micro-operating system
  • Cannot be disabled - the system won't boot without it

In 2017, Google security researcher Cfir Cohen discovered PSP vulnerabilities that could allow attackers to access passwords, certificates, and other sensitive information. In 2018, researchers reported additional serious flaws. [6]

One key difference from Intel ME: AMD's PSP lacks direct network access, reducing remote attack potential. But it still has full system access and runs code you can't audit.

WiFi and Bluetooth: More Black Boxes

Your WiFi and Bluetooth chips also run proprietary firmware - binary blobs provided by manufacturers without source code. [7]

Purism, a privacy-focused hardware manufacturer, explains: "A blob is a file of proprietary binary code provided from a corporation, without source code, that is needed to power certain chips. It is the place where spyware and malware can - and will - run, without your knowledge." [7]

Bluetooth vulnerabilities are particularly concerning:

  • BleedingTooth (2020): Zero-click remote code execution on Linux devices via Bluetooth - no user interaction required [8]
  • KNOB attack (2019): Allows attackers to weaken Bluetooth encryption
  • BIAS attack (2020): Enables impersonation of previously paired devices

Many devices in 2025 still run Bluetooth 4.x or earlier, lacking modern security mitigations. And because the firmware is proprietary, patching depends entirely on manufacturers who may have no incentive to update older devices.

Some privacy-focused projects (like Purism's Librem phones) don't include Bluetooth at all because there's no way to run it without proprietary firmware.

GPU Firmware: Another Attack Surface

Graphics processors have their own proprietary firmware with direct memory access capabilities. Security researchers have identified multiple attack vectors: [9]

  • Memory leaks: Improperly deallocated GPU memory can retain sensitive data from previous workloads - deep learning model weights, images, cryptographic data
  • GPU escape attacks: In virtualized environments, vulnerabilities in NVIDIA vGPU and AMD MxGPU have allowed guest VMs to access other tenants' data or escalate to host system access
  • DMA attacks: PCIe connections between CPU and GPU are generally untrusted and vulnerable to snooping

NVIDIA and AMD regularly patch GPU driver vulnerabilities. In late 2024, NVIDIA addressed eight high-severity CVEs in a single update. [10] But as with other components, the proprietary nature of GPU firmware means independent security audits are nearly impossible.

SSD Firmware: Encryption You Can't Trust

Self-encrypting SSDs promise hardware-level encryption without performance overhead. In 2018, researchers at Radboud University discovered the encryption was often worthless. [11]

By reverse-engineering firmware from Samsung and Crucial drives (which together represent about half the SSD market), they found:

  • Master passwords were empty strings: Hitting Enter would unlock the "encrypted" drive
  • Keys weren't cryptographically bound to passwords: The encryption key and user password were completely separate - knowing one didn't require knowing the other
  • Keys were recoverable from flash: Due to wear-leveling, unencrypted copies of encryption keys remained accessible on the storage chips

The researchers' conclusion: "Hardware encryption currently comes with the drawback of having to rely on proprietary, non-public, hard-to-audit crypto schemes designed by their manufacturers. Correctly implementing disk encryption is hard and the consequences of making mistakes are often catastrophic." [11]

Worse, Windows BitLocker defaulted to trusting SSD hardware encryption when available - meaning BitLocker-protected drives on these SSDs were completely compromised. [12]

Sensor Hubs: Always Listening

Modern smartphones contain dedicated sensor hub processors that continuously monitor accelerometers, gyroscopes, and other sensors while the main processor sleeps. This enables features like step counting and "Hey Siri" without draining battery. [13]

The problem: these run entirely on proprietary firmware with no source code or documentation. Qualcomm's Snapdragon Sensor Core, Intel's Integrated Sensor Hub, and similar components process sensor data in black boxes you can't inspect.

Nitrokey, a security-focused hardware company, claimed Qualcomm's firmware was uploading device identifiers, country codes, operator information, and installed software to Qualcomm servers. Qualcomm disputed the specific claims but acknowledged their Location Service downloads and processes location-related data. [13]

The Trust Problem

Every security model ultimately rests on trust. You trust your operating system because you can (in theory) inspect the source code. You trust open-source encryption because cryptographers worldwide have audited it.

Proprietary firmware breaks this model. You're trusting:

  • The manufacturer's competence: That they implemented security correctly
  • The manufacturer's honesty: That there are no intentional backdoors
  • The manufacturer's priorities: That security matters more than carrier demands or government pressure
  • The manufacturer's maintenance: That they'll patch vulnerabilities in components they've already sold

History shows these assumptions are often wrong. The SSD encryption failures weren't malice - they were incompetence. The baseband telemetry features weren't bugs - they were deliberate. The difference doesn't matter when your data is compromised.

What Can You Do?

Complete elimination of proprietary firmware isn't realistic for most users. But you can reduce exposure:

For Phones

  • GrapheneOS or CalyxOS: Can't eliminate baseband risks but reduce attack surface elsewhere
  • Airplane mode: Disables cellular radio (but baseband processor still runs)
  • Librem 5 or PinePhone: Hardware kill switches physically disconnect cellular, WiFi, Bluetooth, cameras, and microphones - though they still have firmware blobs
  • Faraday bags: Physically block all radio signals when not in use

For Computers

  • Libreboot/Coreboot systems: Some older ThinkPads and other systems can run with ME partially disabled
  • System76, Purism: Manufacturers that disable ME where possible and prioritize open firmware
  • AMD systems: PSP can't be disabled but lacks network access - lower risk than Intel ME
  • Software disk encryption: Use VeraCrypt or LUKS instead of trusting SSD hardware encryption
  • Disable AMT: If you don't need Intel's remote management, disable it in BIOS

General Principles

  • Assume compromise: Design your security model assuming any individual component could be compromised
  • Defense in depth: Multiple layers of protection so one breach doesn't expose everything
  • Compartmentalization: Sensitive activities on dedicated devices with minimal attack surface
  • Update firmware: When patches are available, apply them - known vulnerabilities are worse than theoretical ones

The Bigger Picture

The modern computing ecosystem is built on trust in entities you can't verify. Your phone contains code from Qualcomm, Samsung, Google, your carrier, and dozens of component manufacturers - all running at the deepest levels of your device, all invisible to you.

This isn't inherently malicious. Much of it exists for legitimate reasons: performance optimization, power management, regulatory compliance. But legitimate purposes don't prevent abuse. The same firmware that enables carrier features can enable carrier surveillance. The same processor that manages power can read your memory.

The solution isn't paranoia - it's honesty about the security model you're actually operating under. Your device isn't secure because you installed a security app. It's as secure as the least trustworthy proprietary component with system access. Right now, you don't even know what all those components are.

Related Articles

References

  1. Comsecuris. "Path of Least Resistance: Cellular Baseband to Application Processor Escalation on Mediatek Devices." comsecuris.com
  2. Black Hat USA 2021. "Over The Air Baseband Exploit: Gaining Remote Code Execution on 5G Smartphones." blackhat.com
  3. USENIX Security. "Baseband Attacks: Remote Exploitation of Memory Corruptions in Cellular Protocol Stacks." usenix.org
  4. Wikipedia. "Intel Management Engine." wikipedia.org
  5. Undercode Testing. "Intel ME & AMD PSP: The Hidden Backdoors In Your Hardware." undercodetesting.com
  6. Wikipedia. "AMD Platform Security Processor." wikipedia.org
  7. Purism. "Binary Blobs and You." puri.sm
  8. Google Security Research. "BleedingTooth: Linux Bluetooth Zero-Click Remote Code Execution." google.github.io
  9. Liquid Web. "GPU Vulnerability: 8 Security Risks and How to Address Them." liquidweb.com
  10. Tom's Hardware. "NVIDIA GPU driver addresses eight major high-severity vulnerabilities." tomshardware.com
  11. IEEE S&P 2019. "Self-encrypting deception: weaknesses in the encryption of solid state drives." ieee-security.org
  12. Bleeping Computer. "Flaws in Popular SSD Drives Bypass Hardware Disk Encryption." bleepingcomputer.com
  13. The Register. "Are Qualcomm chips snooping on you? No, not quite." theregister.com