The Parasite in the Tablet

Notes from bringing up our own OS on a Samsung Galaxy Tab S6 (SM‑T865, Snapdragon 855). Nothing below is a hypothesis — it is what we had to find out for Wi‑Fi to simply work.

0. The hook: why "the same thing" became thirty times harder

We are writing an OS in Rust from scratch — no Linux, no Android. It started on a breadboard: an STM32F407 (the F4VE board), an ILI9341 display and a resistive touch panel over SPI, and next to them an ESP32 module running the stock ESP‑AT firmware, connected to the microcontroller over a single UART. Wi‑Fi looked like this: write AT+CWJAP="ssid","pass" to the port, read WIFI GOT IP; write AT+CIPSTART="SSL","api.cursor.com",443 — and the MCU talks HTTPS to a server without a single byte of cryptography, because the module does TLS. The whole driver was a string parser and a handful of commands: about 950 lines of Rust. Network scan, join, captive portal, over‑the‑air update — all of it worked within days. Later the ESP32 became a standalone board of the same OS — the same 950 lines, only now Espressif's Wi‑Fi stack was linked straight into the image.

Then we wanted a real device: a Samsung Galaxy Tab S6 on a Snapdragon 855 — screen, touch, battery, Wi‑Fi, all already in a case. The plan was literally "do the same thing". The display and touch resisted within reason. Wi‑Fi did not. Instead of one UART — nine stages of initialisation, a dozen silent reboots of the whole chip, each from the secure world, with no panic, no message, no interrupt, so the cause had to be proven by a word written to the PMIC's non‑volatile memory before each step. Instead of an AT‑command parser — a loader of signed images through TrustZone, four IPC servers that we must bring up for the chip, DMA into our memory, a QMI handshake handing over RAM regions through the secure world, seven power rails and two reference clocks, without any of which — another silent reset. About 32,000 lines instead of 950 — thirty‑odd times more.

The first explanation was simple: "well, an SoC is more complex". It is wrong. The complexity came not from the size of the chip but from what the radio is in the system. On the F4VE the radio was a peripheral behind a wire: whatever it thought, it could reach only the UART. On the tablet the radio turned out to be a tenant with the keys to the house — and all nine stages were not "configuring the chip" but serving its demands. What follows is what that tenant is, why it cannot be refused, what it can do, whether this concerns your phone and laptop (yes), and what to do about it.

1. Where it started

When the tablet got to Wi‑Fi, the expectation was simple: as on the ESP32 or a laptop — there is a chip, there is a bus to it, the driver sends commands, the chip answers. A passive peripheral.

Reality was different. On the Snapdragon 855 the "Wi‑Fi chip" WCN3990 is a radio front‑end. All of the 802.11 logic — scanning, association, encryption, queues — runs in firmware on the Hexagon DSP of the cellular modem, in the same subsystem as LTE. That firmware is signed by Qualcomm, loaded and verified by TrustZone, and we can neither read it, nor change it, nor look at its registers (reading QDSP6SS from the normal world is a bus error).

And it has demands on us. Without them Wi‑Fi does not come up — and often it does not fail with an error either, but silently reboots the whole SoC from the secure world, so the only witness is the word we managed to write into the PMIC's non‑volatile memory before the step.

Here is what the firmware demands of the "host" (us) in order to deign to work:

This is not a peripheral. It is a co‑processor with DMA, a file system, IPC and its own radio, whose code we do not control, behaving like a tenant with the landlord's rights. Hence the working name — the parasite.

A caveat up front: we are not claiming Qualcomm's firmware does anything malicious. We are talking about structural privileges — what it could do if compromised (and Wi‑Fi firmware is compromised over the air regularly: Broadpwn, Project Zero's "Over The Air", dozens of Qualcomm WLAN CVEs). A threat model is built on privileges, not intentions.

2. How it works: anatomy

2.1 Where it executes

The stock Android device tree: qcom,icnss@18800000 — and next to it qcom,mss@4080000 with PAS id 4. WLAN is a protection domain inside MPSS (the modem subsystem). One Hexagon, one firmware modem.mbn, inside it WLAN.HL.3.2.0.c3‑00910. There is no separate "chip" on a separate bus (PCIe): it is disabled; the WCN3990 sits on the SNoC — the system NoC, that is, on the same bus as memory.

2.2 How it reaches our memory

Between DMA masters and RAM on ARM stands the SMMU (an IOMMU). It can translate a master's addresses (IOVA) into physical ones using tables the OS fills in — and then the master physically cannot touch anything not mapped for it.

The WLAN stream in apps_smmu is 0x640. In the stock Android tree it is marked qcom,smmu-s1-bypass: stage‑1 translation is off. The address the firmware writes into a DMA descriptor is a physical RAM address. The only fences are the hypervisor's stage‑2 (Samsung) and the XPU (Qualcomm TrustZone). Both are foreign; for our OS this means: on our part of the system the parasite is limited by nothing. It can read the kernel, the heap, network passwords, account tokens — and rewrite kernel code.

Why is it done this way? Simplicity and compatibility. The downstream icnss driver has worked like this for years, and our first bring‑up went the same way: the goal was "Wi‑Fi works", and enabling translation along the way broke initialisation with a silent reset.

2.3 How it reaches our disk and files

Through IPC the firmware finds the rmtfs (id 14) and tqftp (4096) services on the QRTR "router" and starts using them as a client: OPEN /boot/modem_fs1, RW_IOVEC (move such‑and‑such sectors there), RRQ /readonly/firmware/image/…, WRQ /readwrite/server_check.txt.

In Linux and Android these servers are rmtfs and tqftpserv from the qrtr utilities (or their proprietary equivalents). They do exactly what they are asked: read and write the real modemst1/2 partitions, write into a real directory of the host file system (in Android — under /data/vendor). The modem gets persistent storage on the host's disk. This is by design — EFS must survive a reboot.

2.4 How it reaches everything else

• SMEM — 2 MiB of shared memory where both sides allocate structures; a chain of items with canaries that the host walks along pointers written by the modem.
• GLINK/QRTR/QMI — FIFO queues in SMEM; item offsets and lengths are words written by the modem.
• memshare — the modem asks over QMI for ownership of RAM regions; the host goes to the secure world (SCM assign_mem) and transfers ownership. The modem writes the granted region its own way — Q6 → XPU — bypassing apps_smmu entirely.
• Traffic encryption — in the firmware (hwcrypto). The host installs session keys (PTK/GTK) into it with a VDEV_INSTALL_KEY command. Even if the WPA handshake is computed on the host, the traffic key leaves for the modem.
• The radio — its own. What it transmits on its own, we do not see. And the same Hexagon has a cellular uplink.

2.5 The map

Everything from §2.1–2.4 in one picture: where the firmware lives (the modem, red), the paths by which it reaches our memory, disk and files, and where the fences stand — and do not. Blue is the memory under dispute; green is our code; dashed lines are "can, if it wants" (DMA anywhere today, exfiltration over cellular, coordinates from GNSS). Outlined in bold is the path that makes the radio a tenant rather than a peripheral: copy engines → SMMU → RAM. This is the Wi‑Fi slice of the device's overall map; the full map of all tenants (TrustZone, hypervisor, AOP, display, PMIC) is in the opening article.

3. Threat model: what the parasite can do

Let us lay it out along three axes — surveillance, code execution, data. For each: what the structure gives, and how it is limited on Linux/Android and on our OS.

The answer to "is it the same on Linux?" is yes, the parasite is the same, and Linux serves it more generously: a real disk, real files. On one point mainline Linux is better than stock Android and than us today: WLAN DMA goes through SMMU translation. That is also proof that translation for stream 0x640 works on this SoC with this firmware.

4. This is not about one tablet: Android, Windows, Apple

Everything above was established on one device. But not a single detail is a peculiarity of the tablet. It is a protocol Qualcomm presents to any host: without serving the firmware's demands the radio does not initialise. The host cannot refuse — it can only choose how to serve.

4.1 Android on Snapdragon — the whole fleet

• The cellular modem (MPSS) exists in every Snapdragon with an X modem — practically every Android phone on Qualcomm. And every one needs rmtfs (EFS on the host disk), tqftp/pd‑mapper, memshare through TrustZone, GLINK/QMI. In Android this is done by Qualcomm's proprietary daemons (rmt_storage, tftp_server, pd‑mapper), which write to a real disk.
• Wi‑Fi on the modem's Hexagon — the 2018–2020 generation: Snapdragon 845, 855, most of the 6xx/7xx with an integrated WCN3980/3988/3990. The downstream icnss driver with qcom,smmu-s1-bypass — DMA by physical addresses.
• Wi‑Fi on a separate core — since 2020 (FastConnect: QCA6390, WCN6750, WCN6855, WCN7850; Snapdragon 865 and newer). The firmware runs not on the modem but on the WLAN chip's own processor, yet the protocol is the same: QMI WLFW, the firmware demands memory from the host (REQUEST_MEM_IND — tens of megabytes the host must allocate and hand over for DMA), firmware and calibration files, traffic keys — in it. The only thing that changes is whether it shares a processor with the cellular modem.
• Not Qualcomm — the same class. Samsung Exynos (Shannon), MediaTek, Broadcom Wi‑Fi — everywhere a separate processor with vendor firmware, DMA and demands on the host. Qualcomm differs only in that there is more of it than anyone and that its WLAN lived inside the modem for years.

4.2 Windows — Snapdragon and not only

• Laptops on Snapdragon (8cx, X Elite, X Plus): Wi‑Fi is Qualcomm FastConnect 6900/7800 over PCIe, cellular is SDX over PCIe/MBIM, drivers from Qualcomm. The same protocol.
• x86 laptops with a Qualcomm Wi‑Fi card (QCA61x4A, QCNFA765/WCN6855 — Lenovo, HP, Dell, Acer fit them en masse instead of Intel). Here a Windows detail matters: DMA remapping for internal PCIe devices is opt‑in by the driver. Kernel DMA Protection protects external ports (Thunderbolt) by default; for an internal card the IOMMU is enabled only if the driver declared DmaRemappingCompatible / RemappingSupported. Without that, per Microsoft's documentation, "DMA remapping is not enforced for this device" — the card writes by physical addresses. You can check in Device Manager, property "DMA Remapping Policy": 2 — translated, 0/1 or absent — not.

4.3 Apple — the modem, not Wi‑Fi

Apple's Wi‑Fi is Broadcom, and since 2025 its own N1 chip; Qualcomm was never there. But the cellular modem in the iPhone has been Qualcomm since 2011: the whole iPhone 17 line (2025) — Snapdragon X80, the US iPhone 18 Pro Max (2026) — still X80, and only the models with Apple's own C1/C1X/C2 leave that behind. The modem is discrete, over PCIe, and iOS puts an IOMMU (DART) in front of it — DMA is translated. This is the strongest of the three configurations. But everything "uncloseable" remains: its own radio, its own uplink, memory the host must hand over to it, and code Apple does not read.

4.4 The common denominator

The same table as five DMA paths from radio to RAM. Vendor firmware (red) is on every platform; the difference is one node in the middle: whether its IOMMU translates or not. Stock Android and Windows without opt‑in have none — the firmware writes by physical addresses; Apple (DART), mainline Linux (dma‑iommu) and we (stage‑1, planned) have one, and ours narrows the window to a single region.

And one more Qualcomm detail that is easy to miss: Qualcomm's GNSS is in the modem (gpsOne/IZat, a separate protection domain on the same Hexagon). The parasite knows the device's coordinates natively, without asking the OS. In 2023 Nitrokey recorded that Qualcomm phones without Google services send traffic to izatcloud.net; Qualcomm replied that this is the XTRA service (assisted GPS), described in its privacy policy. Not a compromise — but an illustration that the subsystem has its own relationship with the outside world that the OS is not asked about.

5. Is there none of this on the ESP32 and at other vendors?

The natural question after §0: since everything was simple on the breadboard, there is no parasite there? The answer: there is no this parasite there. Closed code exists there too, and the question "is there a backdoor" is the wrong one. The right one: who holds the keys, where the foreign code executes, what the boundary between you is, and what channels of its own it has to the outside.

5.1 The ESP32 as a standalone board

Wi‑Fi and Bluetooth on the ESP32 are closed code too: Espressif's libraries (libnet80211, libpp, libphy, libbt, libcoexist) ship as binaries and are linked into your image. Nobody but Espressif has the sources of the 802.11 stack and the PHY. But three things are arranged differently:

• It executes on your processor, in your address space, with your privileges. There is no separate core, no TrustZone, no hypervisor. That means if the blob is malicious, it needs no DMA tricks: it is already inside. But it also means it has nowhere to hide: every memory access, every flash write, every frame on the air passes where you can set a breakpoint, a trace, or a wrapper around the radio interrupt handler.
• The keys are yours. Secure boot and flash encryption on the ESP32 use keys you generate yourself and burn into eFuse. The firmware does not arrive vendor‑signed via someone else's OTA; you build it.
• It has no channels of its own. Only the same Wi‑Fi/BT radio that you control and listen to from the same core. No cellular uplink, no GNSS, no file server, no EFS on your disk. It has nothing to demand from the host — it is the host.

Over‑the‑air vulnerabilities exist all the same — the same class of "a blob parses frames": CVE‑2019‑12586/12587 (a crash and PMK zeroing via EAP), BrakTooth (2021, Bluetooth). Only the consequence is RCE in your process, where all your code already is, not in a hidden subsystem with its own exit to the world.

Separately — the story of March 2025: Tarlogic announced a "hidden backdoor in the ESP32" — 29 undocumented vendor HCI commands (CVE‑2025‑27840) giving RAM and flash read/write and MAC spoofing. On analysis it turned out that all of them require code already executing on the ESP32 itself (it is a local interface between the host and the BT controller inside one chip) and are not reachable remotely; Espressif called them debug commands and promised to remove them. Not a backdoor in the sense of "an entrance from outside" — but a good illustration: any closed blob has an undocumented surface, and vendors differ not in whether it exists but in which side of the boundary it sticks out on.

5.2 The ESP32 as a modem behind a UART (the F4VE breadboard)

This, strangely enough, is the cleanest configuration we have seen. A module with stock ESP‑AT is a separate processor with closed code, like Qualcomm's. But the boundary between it and the MCU is a wire and a text protocol. DMA into the host's memory is impossible by construction: the module has no bus to it. It asks for no files, no disk, no memory. All it can do to the host is send a string the host will parse (and that parser — yes, that is your attack surface).

What it sees, meanwhile, is everything you send through it, in the clear, because TLS is computed inside the module (and in ESP‑AT by default without certificate verification — CIPSSLCCONF=0, "trust the wire"). So confidentiality of content is limited just as on the tablet: the boundary must be drawn above the radio. But such a modem has no control over the host. This is exactly the model Apple arrived at with a discrete modem behind an IOMMU — only at 115200 baud.

5.3 The others: Intel, Broadcom, MediaTek, Samsung

Nobody makes Wi‑Fi without firmware on a separate processor — that is the physics of 802.11: microsecond timings do not live on a general‑purpose processor under an OS. The difference between vendors is along the same four axes:

Summing up the columns: on the ESP32 there is foreign code, but the perimeter is yours — keys, flash, address space, the single channel out. With Qualcomm the perimeter is drawn by the vendor together with the OEM, and inside that perimeter sits a processor with DMA, storage on your disk and its own exit to the cellular network. The word "backdoor" does not help here; the right words are a trusted base you did not choose and cannot verify. On the breadboard it is small and in your power; on the phone it is large and in someone else's.

6. What this gives intelligence agencies

Let us lay it out by what the attacker needs to have. Three grades: what is documented, what researchers have demonstrated, what is structurally possible.

6.1 Nothing but the network (carrier, state)

This is not about the parasite as such, but it is the endpoint of that network: cell‑based location, lawful intercept (CALEA/SORM), SS7/Diameter, IMSI catchers, silent SMS. All documented for decades. The modem does exactly what it was made for: it answers the network. Wi‑Fi gives less here: probe requests with a MAC (MAC randomisation in the OS gets in the way — but the firmware knows the real MAC).

6.2 A vulnerability in the firmware, over the air

Range — hundreds of metres for Wi‑Fi; a rogue base station or simply the network for the cellular modem. Precedents:

• Project Zero, 2023 — 18 zero‑days in the Samsung Exynos baseband, four of them RCE "from the internet into the modem" knowing only the phone number (Pixel 6/7, Galaxy S22). Not Qualcomm, but the same class and the same position in the system.
• Broadpwn and "Over The Air", 2017 — RCE in Broadcom Wi‑Fi firmware with a single frame, then into the host via DMA on devices without an IOMMU (Nexus 6P, Galaxy S7). Exactly the diagram from §2.2.
• Check Point, 2021 (CVE‑2020‑11292) — a vulnerability in the Qualcomm modem's QMI: from Android into the modem, reading SMS and calls, unlocking the SIM. The direction is reversed (host → modem), but it shows the modem's QMI parsers are no fortress.
• Qualcomm, October 2023 (CVE‑2023‑33063/33106/33107) and CVE‑2024‑43047 — vulnerabilities in the Hexagon DSP that Qualcomm reported as "under limited, targeted exploitation"; the second, per Amnesty International's report (December 2024), was used by Serbian police through Cellebrite. That is not the modem but a neighbouring DSP, and with physical access — but it is a Hexagon exploited by a state, in the field.

What someone sitting in the Wi‑Fi or modem firmware gets:

6.3 Cooperation or coercion of the vendor / OEM

The firmware is signed with Qualcomm's key, verified by TrustZone and arrives with the device maker's OTA. Whoever can sign an image and deliver it via OTA — Qualcomm plus the OEM, or whoever commands them — gets an implant that is legitimate for every check the device makes, invisible to the OS, survives any reinstall and has everything in the table above at once, without a single vulnerability. Technically there are no obstacles; whether there are legal and institutional ones is a question of jurisdiction and trust, not engineering. The NSA's ANT catalogue of 2008 (leaked in 2013) contained baseband implants for the phones of that time — so the direction is not hypothetical.

The same goes for the EL2 hypervisor and the XPU: on stock Android they are the only fence before the parasite's DMA, and both are Samsung's and Qualcomm's code.

6.4 Physical access

Qualcomm's EDL (Emergency Download) mode with an OEM‑signed Firehose programmer gives read and write of all flash memory, EFS included — the standard forensics path (Cellebrite, GrayKey and the like). That is a separate topic; one thing matters here: the modem's partitions are the most durable place for an implant, because no OS reinstall touches them.

6.5 What this does not give

In fairness:

• TLS content — if the certificate is verified, the parasite sees only metadata. Which is why TLS without verification is not a detail.
• The content of e2e messages — as long as the host is not compromised via DMA. An IOMMU in front of the parasite turns "full control" into "sees traffic".
• Microphone and camera directly — WLAN/modem have none; the only path is through the host.

Hence the priorities: an IOMMU (closes the pivot into the host), TLS with verification (closes content), a shadow instead of a disk (closes persistence). The air, the keys and the uplink remain, and that must be known, not hoped away.

7. The principle of neutralisation: transparent isolation

The channels cannot be switched off: without any one of them the firmware does not start or brings down the SoC. So the strategy is to answer everything the modem asks, but give away nothing extra. A syntactically correct answer, semantically empty. At every step the parasite must see SUCCESS — and get a shadow.

7.1 Disk — a shadow instead of a disk

On OPEN, rmtfs reads the partition into RAM once. All RW_IOVECs go to the copy. The disk never changes; a reboot forgets. The modem sees that its writes "landed"; in fact nothing landed. Every transfer is checked twice — against the shadow's sector and against the offset in the shared region.

A detail we had to learn live: the fsg partition (the golden copy of EFS) is absent on this tablet. Answering "no such file" brought the modem down in 23 ms. Answering "here it is, empty" (zeros = an erased copy) — the modem is satisfied.

7.2 Files — a limited scratch

/readonly/... → only the firmware search path, .. traversal is cut. /readwrite/... → RAM, 64 KiB, 16 files, the oldest evicted. Writing anywhere else — access violation. server_check.txt is written and read from scratch: the modem "checked the server" and loaded WLAN.

7.3 Memory — named regions only

memshare transfers ownership only for regions the platform has explicitly declared, with specific owners and permissions. The modem cannot assign itself an arbitrary address.

7.4 Input — validation of everything untrusted

Everything that came from the modem — the FIFO base, an item offset, a length, an address in QMI — is checked against the window before dereferencing. The SMEM chain is walked with a step limit. Foreign SMEM partitions (TZ–modem) are not read at all: a read behind the MPU hangs the core until the watchdog.

All of this is written in safe Rust. A bug in a parser of modem data is a panic and a reboot, not a write past a buffer.

7.5 Cache — nothing shared

All memory written by the modem or the secure world is mapped non‑cacheable, in 2 MiB windows on a block boundary. A lesson that cost one reset: a lent RAM region that began off a block boundary got its first MiB cacheable — the modem read empty EFS headers from a buffer we had written through the cache, restored the golden copy over the top and crashed on restart.

8. The main thing: lock down DMA

Everything above is defusing the command surface. But while stream 0x640 goes untranslated, the parasite can physically write anywhere, and everything else is decoration.

The cure is to enable stage‑1 for 0x640: an SMMU context bank with translation, page tables mapping only the 4‑megabyte window where the rings and buffers live (identity inside the window: IOVA = PA, nothing outside). Then any firmware DMA outside the window is a context‑bank fault, not a write to memory. The rings are programmed with the same addresses; for honest firmware nothing changes.

An SoC nuance: Samsung's hypervisor vetoes an S2CR of type bypass (the write comes back as fault) — which is why our current bypass is implemented as a translate‑type bank with translation switched off. Enabling translation in that same bank is a step that has to be taken live, because any deviation here is a silent reset. Mainline Linux on the HDK SM8150 with the same firmware does it, so the answer is known: it works.

9. What remains even after that

Honestly — because a threat model in which "everything is closed" lies.

Not closeable from our side, because it is a function of the parasite, not a side channel:

• All Wi‑Fi traffic in the clear. It encrypts. The keys are its. The confidentiality boundary is TLS and end‑to‑end, not WPA. (Which is why TLS without certificate verification — a temptation on small boards — is not "good enough for now" here but a door: the parasite becomes a MITM for tokens, APIs and, if updates ever travel over the network, for code.)
• The air. The list of networks, neighbours' RSSI (= geolocation), the ability to steer into a rogue AP — all its.
• The cellular uplink of the same Hexagon. An exfiltration channel that passes through none of our layers. This, not DMA, is the main leak channel for a compromised modem.

Partially closeable:

• memshare regions (MSA, the rmtfs buffer) — the modem writes there its own way, past apps_smmu; stage‑1 does not lock them. The cure is minimal grants and sizes; the fence is the XPU from TZ.
• Parser bugs — safe Rust turns them into DoS; fuzzing on deterministic fakes (each of our servers has a fake modem for host‑side tests) finishes off the rest.

Already closed:

• Persistence through the host. Firmware compromised over the air has nowhere to write itself through us: the EFS shadow and the scratch are in RAM, the disk is untouched. Every reboot is a clean slate. On Linux/Android this is not so: rmtfs writes to disk.

10. What we cannot do and do not pretend to

• The EL2 hypervisor and TrustZone's XPU — Samsung and Qualcomm. Until stage‑1 is enabled they are the only DMA fence, and they cannot be relied on as our boundary. After — a second echelon.
• The firmware itself is signed by Qualcomm. We do not read or change it. Our boundary is around it, not inside.
• The TrustZone log is encrypted and cleared on reset. We have no witness of compromise on the secure‑world side.

11. How to look at your own device

Almost everything in this article can be checked without disassembly.

Linux (a laptop or a phone with mainline). Whether the Wi‑Fi card's DMA is translated — the type of its IOMMU group:

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 or DMA-FQ — translated; identity — physical addresses; no file — there is no IOMMU in front of the device. Who serves the modem — pgrep -a 'rmtfs|tqftpserv|pd-mapper'; what it writes to — rmtfs shows the device or partitions in its arguments.

Android (root, or at least adb shell, needed). The modem partitions on disk: ls -l /dev/block/by-name/ | grep -E 'modemst|fsg|fsc' — there is the EFS a factory reset does not touch. The SMMU mode for Wi‑Fi — in the live device tree: find /proc/device-tree -name 'qcom,smmu-s1-bypass' | grep -i -E 'icnss|wifi|wlan' — found means bypass. Where Wi‑Fi executes — is there a qcom,icnss node (integrated, on the modem) or qcom,cnss/PCIe (a separate chip).

Windows. Device Manager → Wi‑Fi adapter → Details → property "DMA Remapping Policy": 2 — DMA is translated, 0/1 or no such property — physical addresses. msinfo32 → "Kernel DMA Protection" — whether protection is on at all (it is about external ports; it does not save an internal card without the 2 above).

iPhone. Nothing to check — DART is always in front of the modem. Which modem — most reliably by model number and published teardowns (iFixit, TechInsights): the whole 17 line — Qualcomm X80; Air, 16e and 18 Pro outside the US — Apple C1X/C1/C2. The "Modem Firmware" line in "About" shows the version, not the vendor.

Any phone. "Airplane mode" is a request from the OS to the modem, not a power cut. The only check that the radio is not transmitting is a measurement from outside.

12. Conclusions

1. On a modern SoC the "Wi‑Fi chip" is half a modem with DMA, IPC, a file server and its own radio. A Wi‑Fi driver is not "controlling a peripheral" but serving a privileged tenant.
2. This is not a peculiarity of one tablet but Qualcomm's protocol: every Android on Snapdragon serves it, every laptop with a Qualcomm Wi‑Fi card or modem under Windows, every iPhone with a Qualcomm modem — and it cannot be refused, or the radio does not start. The difference between platforms is only whether DMA is translated (Apple, mainline Linux — yes; stock Android with WCN39xx and Windows without driver opt‑in — no) and whether the modem gets a real disk (everywhere except us).
3. Linux and Android serve this tenant fully and honestly: a real disk, real files, and in stock Android also DMA by physical addresses. Mainline Linux at least translates DMA.
4. On the ESP32 and at other vendors closed code exists too — but the question is not "is there a backdoor" but whose perimeter it is. On the breadboard the foreign blob lives in your address space, under your keys, with a single channel out that you yourself listen to; behind a UART — it is behind a wire altogether. With Qualcomm the perimeter is drawn by the vendor and the OEM, and inside sits a processor with DMA, your disk and a cellular uplink. The thirty‑fold difference in driver size from §0 is the price not of chip complexity but of serving a tenant.
5. For someone with a firmware vulnerability, a signing key or power over the vendor, this gives: all traffic at the link layer, coordinates (GNSS lives in the modem), an uplink past VPN and "airplane mode", persistence in modem partitions that survive a factory reset — and, where DMA is not translated, full control of the host. Precedents for every point except the last on Qualcomm are published.
6. The right strategy is not to switch off (impossible) but to isolate transparently: an answer correct in form, empty in substance. A shadow instead of a disk, scratch instead of files, named regions instead of arbitrary ones, validation of everything it wrote — and an IOMMU locking DMA into a window.
7. And after all of that, what remains is what cannot be closed: traffic, keys, the air, the cellular network. Which means confidentiality has to be built higher up — TLS with verification, e2e — rather than hoped for at the radio layer.
8. A threat model in which everything is closed is not a threat model. An honest list of "we cannot" is part of the result.

This is the central article of the series; the map of all the device's tenants and the reading order are in the opening article. The individual stories: a reset without witnesses, the megabyte that killed the modem, 23 milliseconds to lie, the hypervisor that said no, the WPA boundary, trust the wire?.

Technical details — the memory map, every SoC reset with its cause, SMMU registers, message formats — are in docs/wifi-sm8150.md and docs/wifi-threat-model.md in the repository. Code: crates/qcom (SMMU, SMEM, GLINK), crates/tools (rmtfs, tqftp, memshare, wifi), crates/ath10k (copy engines, HTT, WMI), crates/wpa.

Recommended

VPN Chrome extension: what it protects and what it doesn't

A Chrome VPN extension is a proxy for browser traffic only. What it really protects, where it leaks, and when you need a full VPN app instead.

Turnkey smart homes on our own OS: 0xd-os and 0xd-ui

We build turnkey smart homes on components we designed ourselves. At the core is 0xd-os — one operating system that runs identically on a flagship tablet and on a device with 512 KB of memory.

Why security agents need a sandbox

An agent that can 'just run tools' on a security review is a second attacker — unless every call has a grant. AGI Core isolates tool execution; Forge keeps the skill list in UIDE.