CyberPhone — Persistence & Detection Resistance in Hardware-Modified Devices

Any surveillance capability faces the same question: how does it survive a device reset? For software running on the application processor, the answer is constrained by the operating system's own reset semantics. A factory reset reformats the data partition and reinstalls the OS from a recovery image, removing user-installed software and most persistence hooks. OTA updates replace system partitions wholesale, overwriting boot-time modifications. A determined adversary — or a security-conscious user — can flash a factory image via fastboot, returning the device to a known-clean state.

Software spyware copes with this by exploiting persistence locations that survive partial resets (kernel-level rootkits, bootloader modifications) or by re-exploiting the device after a reset. Both strategies are fragile: the first is removed by a full image flash, and the second requires a live exploit against the post-reset OS version.

Hardware-backed surveillance sidesteps the entire problem by storing its firmware in a domain the operating system cannot address or reset.

The surveillance coprocessor in a hardware-modified device boots from and stores its firmware in dedicated non-volatile flash that is physically separate from the eMMC/UFS storage the Android OS uses. This flash is not mapped into the application processor's address space; the Android storage stack has no partition entry for it, and the bootloader's partition table does not reference it.

Consequently, a factory reset — which operates on the Android data partition — has no effect on the coprocessor's firmware. An OTA update, which rewrites Android system partitions, does not touch the coprocessor's flash. A full fastboot flash of every Android partition still leaves the surveillance domain untouched, because the flash operation is scoped to partitions the bootloader knows about, and the coprocessor's flash is not among them.

The only operation that would clear the coprocessor is a JTAG or board-level reflash of its dedicated flash, performed by disassembling the device — a procedure no end user and virtually no forensic lab undertakes.

The surveillance coprocessor has its own boot ROM and power-on sequence that is independent of the Android bootloader. When the device powers on, the coprocessor initializes from its own ROM, loads its firmware from its dedicated flash, and begins operating before — and regardless of — the state of the Android boot chain.

This means that even if the Android side of the device is booted into recovery mode, safe mode, or fails to boot entirely, the surveillance domain is active. A target who suspects compromise and boots into recovery to wipe the device removes only the Android software state; the coprocessor continues to run from its independent power domain.

The boot independence also means the capability is present from the first power-on of a factory-fresh device. There is no installation window during which the surveillance is not yet active — a property no software implant can claim.

Every consumer-facing detection tool — anti-virus apps, mobile threat defense suites, privacy scanners, and researcher toolkits like MVT — operates by inspecting the Android file system, process list, network connections, and system logs. These tools can only see what the operating system can see. Because the surveillance coprocessor is not a device the operating system enumerates, it produces no file system entries, no processes, no network sockets, and no log lines on the Android side.

The data the coprocessor captures is read from the peripheral bus and stored in the coprocessor's private flash before any Android component is aware of it. Exfiltration occurs over a transport the Android networking stack does not manage, so it does not appear in connection tables, data-usage meters, or VPN logs.

The result is a detection asymmetry: the surveillance domain can observe everything the application processor does, while the application processor — and every tool running on it — can observe nothing about the surveillance domain. Standard forensic acquisition of an Android device will return a completely clean image with zero indicators of compromise.

Routine mobile forensic acquisition, as performed by Cellebrite UFED, Magnet AXIOM, or GrayKey, images the Android file system and extracts logical and physical data from the partitions the OS presents. None of these tools image the coprocessor's dedicated flash, because it is not a partition they are instructed or able to acquire.

Detecting a hardware modification therefore requires physical teardown: removing the mainboard shield, identifying the coprocessor die under microscope, and performing a JTAG or chip-off read of its flash. This is a destructive, time-intensive process available to a small number of specialized hardware-analysis laboratories. It is not part of any standard device inspection workflow, and in practice it is never performed unless hardware tampering is already strongly suspected.

For the operational lifetime of a typical deployment, this means the device will pass every software and standard forensic inspection it is subjected to, retaining full surveillance capability throughout.

A hardware-modified device resists: factory resets (coprocessor flash not in data partition), OTA OS updates (coprocessor flash not in system partitions), full fastboot image flash (coprocessor flash not in bootloader partition table), recovery-mode wipes (independent boot domain), anti-virus scans (no OS-level artifacts), network monitoring (covert exfiltration transport), and standard forensic acquisition (coprocessor flash not imaged).

The only effective countermeasure is board-level hardware analysis, which is outside the capability set of any target, any consumer security tool, and the overwhelming majority of forensic laboratories. This is the technical foundation of the detection-resistance claims that distinguish hardware-backed surveillance from software-only alternatives.