Someone else's computer: why your phone isn't yours — and what to do about it

You are holding a device in which code by at least eight different authors is executing right now. Yours is one of them: the operating system and the apps. It is also the least privileged. We learned this not from slides but in practice: we wrote our own OS in Rust, booted it on an ordinary Samsung Galaxy Tab S6 and spent half a year finding out who else lives inside the chip and whose rules apply there. This article is about how a modern device is really put together, why “my phone” is an imprecise phrase, and what can be done about it — and what honestly cannot.

The textbook model — “the processor runs the operating system, the OS controls the hardware” — went stale about fifteen years ago. A modern system-on-chip is an apartment building, and the operating system in it is not the owner but one of the tenants. Not on the top floor, either. Here is who lives in a typical flagship Android on Qualcomm (other vendors use other names; the roles are the same).

Note the direction of the arrows. Everything that comes from you is a request, a vote, a reply. Everything that comes in is power: the right to reboot, the right to read memory, the right not to boot you at all. That is normal for a modern SoC. What is abnormal is not knowing it.

And one observation everyone should remember: “airplane mode” is a request from the operating system to the modem, not a switch. The only way to be sure the radio is silent is to measure from outside. The modem has its own uplink to the carrier network, and it structurally goes past your VPN, your firewall and any setting of yours.

The temptation is to say “this is about Android on Snapdragon”. No. The protocol we served is Qualcomm's for any host: the same on Windows laptops with Snapdragon X Elite, the same on x86 with QCA cards (where DMA translation is an opt‑in driver property), the same in iPhones with a Qualcomm modem (there a DART always stands in front of the modem — Apple does not trust the tenant). Broadcom, MediaTek, Exynos have their own names and the same architecture: signed firmware, DMA, an uplink of its own.

Go lower: the ESP32 in a “smart” bulb is a Wi‑Fi stack blob in your address space, with your keys, and three loud vulnerabilities in five years. Go higher — and you find the same thing in software:

• A browser extension with the right to “read and change all your data on all websites” is a tenant with keys to every page of yours. That is how most “free VPNs for Chrome” are built, and that is why stores keep removing them.
• An app with access to contacts, the microphone and background networking is a process whose code you never read, on a device whose OS cannot check what it does with the data after sending.
• Clouds and third‑party APIs. Every request to someone else's AI model is your document on someone else's server. “We don't train on your data” is a policy, not an architecture. Policies change with one line in a contract.
• A brand-name smart home — a hub that stops working without someone else's server, and a panel whose firmware is updated by someone other than the homeowner.

The general formula: a trusted base you did not choose and cannot inspect. Devices differ only in how generously the host serves the tenant: whether it hands over a real disk, translates DMA, verifies the certificate of the server it talks to.

Let's lay it out honestly by what the attacker needs. Nothing but the network: cell-tower location, lawful intercept, SS7, IMSI catchers — documented for decades; the modem does what it was made for. A firmware vulnerability over the air: Project Zero found 18 zero‑days in the Exynos baseband in 2023, four of them RCE knowing only the phone number; Broadpwn in 2017 was RCE in Broadcom Wi‑Fi firmware with one frame, then into the host via DMA where there is no IOMMU. Hexagon DSP vulnerabilities (CVE‑2023‑33063, CVE‑2024‑43047) Qualcomm described as “limited, targeted exploitation”; per Amnesty International the latter was used by Serbian police via Cellebrite.

The conclusion is not that you personally will be hacked through the modem — most likely not. The conclusion is that control, updates and persistence in your device do not belong to you, and any security model that pretends otherwise is not a security model. This matters most to those responsible for other people's data: doctors, lawyers, journalists, developers with production keys — and any business that stores client documents.

We answer this problem on three levels — and that is exactly how everything we do is organised. The levels don't exclude each other: the first is for everyone, the second for most, the third for those who can afford to choose their hardware.

Floor 1 — understand. Almost everything in this article can be checked on your own device without taking it apart. Who serves the modem, whether Wi‑Fi DMA is translated, which partitions survive a reset:

for d in /sys/class/net/*/device; do
  echo "$(basename $(dirname $d)): $(cat $d/iommu_group/type 2>/dev/null || echo 'no IOMMU')"
done
# DMA / DMA-FQ — translated; identity — physical addresses; no file — no IOMMU

On Android (needs adb shell or root):

# modem partitions that survive a factory reset
ls -l /dev/block/by-name/ | grep -E 'modemst|fsg|fsc'
# found — the Wi‑Fi firmware writes to RAM by physical address
find /proc/device-tree -name 'qcom,smmu-s1-bypass' | grep -iE 'icnss|wifi|wlan'

On Windows — Device Manager → Wi‑Fi adapter → Details → “DMA Remapping Policy”: 2 — DMA is translated, 0/1 or no property — physical addresses. On an iPhone there is nothing to check: a DART always sits in front of the modem, and which modem is inside you learn from the model number and iFixit teardowns. For a business, “understand” means an audit: a map of who reaches what in your devices, agents and services, with honest residual risk. That is work we do on request — with the same tools we use for ourselves.

Floor 2 — protect yourself where the platform is foreign. If the tenant cannot be evicted, confidentiality is built above it. Three rules we derived by breaking our own code:

1. Encrypt above the channel. The key to your Wi‑Fi traffic lives in the modem — for everyone: Linux, Android, us. So content is protected only by TLS with certificate verification and end‑to‑end encryption. We found HTTPS without certificate verification on all three of our boards — “why break the fence if the door isn't locked”. Check your IoT devices: there it is the norm.
2. A VPN is a lock on the channel, not an invisibility cloak. It closes traffic from the ISP and a stranger's Wi‑Fi and promises nothing else: browser fingerprint, timezone, accounts and the modem's own uplink remain. A good VPN asks for no personal data (only what is collected can leak), runs on the WireGuard family and states honestly what it does not do.
3. Consistency of signals. If the address says “Amsterdam” and the browser clock says “Moscow”, it wasn't the tunnel that gave you away but Intl.DateTimeFormat. Privacy is not one tool but a non-contradictory story told by every signal of the device. We built a free extension that moves the timezone along with the IP for exactly this.

Floor 3 — replace the platform. Where you choose the hardware, you can also choose how many tenants live in it. We went this way twice:

This is an expensive floor, and we won't pretend it is for everyone. But it is the only one on which the “cannot” list gets shorter rather than longer.

• Read the code of TrustZone, the hypervisor, the modem — it is signed and closed. We serve it, validate everything it sends, and lock what we can reach.
• Forbid the modem to transmit. “Airplane mode” is a request. It can only be measured from outside.
• Fully close the Wi‑Fi firmware's DMA on the tablet: stage‑1 translation is possible (mainline Linux does it on the same chip); it is in our plan and honestly marked “not done”.
• Make a foreign platform ours. On an iPhone, in stock Android, on Windows, floor 2 remains — protection above the channel. We don't sell the illusion that a VPN or an extension solves the problem described above.

If you have read this far, you are already on the first floor: you know there are tenants in the device and which of them is in charge. What comes next depends on your situation. Engineering detail — the eight articles of the series “Whose computer is this?” with addresses, registers and source code. How we build our own AI stack — a separate article. Homes on our own OS — here. And if you have a device, an agent or an infrastructure you want to know the owner of — write to [email protected].

Next

Whose Computer Is This? Yours, or…

We wrote an OS from scratch in Rust and booted it on a Samsung Galaxy Tab S6. Inside the device live at least eight executing entities — seven of them not ours, and almost every one can kill us. The opening map of a series on who really owns a modern SoC.

The Parasite in the Tablet

On the F4VE breadboard Wi‑Fi was 950 lines behind a UART. On a Snapdragon 855 tablet it became 32,000: nine stages, a dozen silent SoC resets, four servers we run for the chip. The 'Wi‑Fi chip' is half a modem with DMA, a file system and its own radio — a tenant with the landlord's keys. What it can do, whom it concerns (every Snapdragon Android, Windows laptops, iPhones with a Qualcomm modem), and how to isolate it transparently.

Our own AI, all the way down: engine, memory, agent — and the night it learns

In five and a half months we built a complete AI stack of our own in Rust: an inference engine faster than llama.cpp, an agent runtime with memory and task preemption, a benchmark harness and a nightly training loop with proof. Numbers from our benchmarks — and what of it your business needs.