1. Introduction

The proliferation of sophisticated Android-based surveillance architectures has introduced a class of threats that operate not through conventional malware installation, but through the exploitation of legitimate, manufacturer-supplied system infrastructure. This paper documents one such case: the discovery of active, configured Dynamic System Update (DSU) infrastructure on a personal Android device, pre-loaded with Generic System Image (GSI) builds representing Android versions two generations beyond the device's officially supported maximum.

The subject of this investigation — a Xiaomi 11T Pro running HyperOS on Android 14 — had been in continuous personal use for five years. The device's owner, conducting a broader investigation into unauthorised device cloning and suspicious access patterns across multiple Google accounts, discovered through a third-party diagnostic application that a hidden DSU Loader existed on the device. Tapping the loader's configured options triggered a live connection to Google's servers and presented a Terms of Service agreement for Android 16 Early Access GSI — a build released in 2025 and representing functionality entirely beyond what Xiaomi officially supports on this hardware.

This discovery, taken in isolation, might be dismissed as an artefact of Android's underlying architecture. Taken in the context of persistent security application alerts — dangerous system property flags, Package Manager anomalies, test build signatures, and emulator environment detection — it forms a coherent and technically consistent picture of infrastructure configured for purposes beyond legitimate developer testing.

This paper presents the full technical architecture of DSU-based remote operation, maps each observed anomaly to a specific component of that architecture, and proposes a unified model — the Remote Emulator Architecture — that accounts for every observed irregularity as a single coherent system. It further examines the forensic implications for investigators operating in court-adjacent contexts and identifies the ways in which standard mobile forensic practice will fail to surface evidence of this activity.

2. Technical Background

2.1 Dynamic System Update (DSU)

Dynamic System Update is a native Android feature introduced in Android 10 (API level 29) by Google. Its stated purpose is to allow developers to temporarily boot a Generic System Image alongside their device's primary operating system without permanently modifying the device's existing partition structure. DSU achieves this by creating a separate dynamic logical partition at runtime, into which the GSI is installed. The primary operating system remains untouched; on the next ordinary reboot, the device returns to its original state.

A critical design characteristic of DSU is that it does not require an unlocked bootloader. This distinguishes it from conventional device modification approaches (such as flashing custom ROMs) and means that DSU activation leaves none of the standard indicators — unlocked bootloader warnings, recovery mode changes, or factory reset — that digital forensics practitioners typically look for when assessing device modification.

2.2 Generic System Images (GSI)

A Generic System Image is a build of Android that adheres to Google's Treble-compliant partition structure, enabling it to boot on any compatible device regardless of manufacturer. GSI builds are produced by Google and carry the core Android Open Source Project (AOSP) codebase, with optional inclusion of Google Mobile Services (GMS). They are explicitly described in Google's developer documentation as experimental tools for developer use, noting that their use may void device warranties, erase data, and render portions of a device non-functional. GSI releases are not Compatibility Test Suite (CTS)-certified — a detail of forensic significance, as this means the standard Android security certification chain does not apply to them.

2.3 Project Treble

Project Treble, introduced with Android 8.0 Oreo in 2017, restructured the Android codebase to separate the Android OS framework from device-specific vendor implementations. This architectural separation enables GSI compatibility across device families and is signalled by the system property ro.treble.enabled=true. The Xiaomi 11T Pro is fully Treble-compliant. Security analysis tools detecting Project Treble on this device were detecting a legitimate architectural feature — however, when combined with the additional anomalies documented here, its detection takes on additional investigative significance.

2.4 Android Virtualization Framework (AVF)

The Android Virtualization Framework, introduced in Android 13, extends the DSU concept by enabling protected Virtual Machines to run concurrently with the primary Android operating system using hardware-level ARM virtualisation extensions. The Snapdragon 888 System-on-Chip present in the Xiaomi 11T Pro includes these ARM virtualisation extensions, meaning the hardware is technically capable of running a concurrent VM environment. Where standard DSU requires a reboot to switch between environments, AVF-based virtualisation enables simultaneous operation — the primary OS continues to run while a secondary environment operates in an isolated but hardware-sharing VM.

3. Case Profile

3.1 Subject Device

Table 1. Subject Device Profile

Parameter	Detail
Device	Xiaomi 11T Pro
Processor	Qualcomm Snapdragon 888 (ARM64, virtualisation-capable)
Operating System	Xiaomi HyperOS (Android 14)
Maximum Supported Android	Android 14 — no further official updates
Years in Use	5 years (continuous personal use by owner)
Bootloader Status	Standard consumer (not required to be unlocked for DSU)
Project Treble Compliant	Yes — ro.treble.enabled=true
DSU in Developer Options	Not present — hidden by Xiaomi in HyperOS
DSU Framework Status	Active and fully functional via hidden Android Activity

3.2 Context of Discovery

The device's owner was conducting a formal investigation into unauthorised device cloning and suspicious access patterns across multiple personal Google accounts, evidenced in part by identical IMEI and serial numbers registered across different accounts and access events routed through commercial VPN infrastructure including Hern Labs AB (Sweden), Mullvad VPN, NordVPN, and Cloudflare WARP. In the course of this investigation, the owner installed a third-party diagnostic application — Hidden Settings — which surfaces normally inaccessible Android system components by directly launching system Activities through the Android Package Manager, bypassing the standard Settings UI entirely.

Through Hidden Settings, the owner navigated to a Testing and Diagnostics section containing a DSU Loader option. Upon tapping the loader, two options were presented: GSI ARM64 and GSI+GMS ARM64. Selecting either option produced an active connection to Google's servers and presented a Terms of Service agreement for the Early Access Google Mobile Services and Android 16 GSI licence — a build from 2025 representing a version of Android two generations beyond the device's officially supported maximum.

4. Observed Security Anomalies

Prior to the DSU Loader discovery, multiple third-party security applications had independently flagged a set of anomalies on the subject device. These flags, taken individually, might be attributed to various causes. Taken together and mapped against the DSU/GSI infrastructure subsequently discovered, they form a consistent and technically coherent pattern.

Table 2. Security Flag Taxonomy and Technical Attribution

Observed Flag	Technical Attribution
Dangerous properties installed	GSI and DSU frameworks set system build properties including ro.debuggable=1, ro.secure=0, and ro.build.type=userdebug. These are standard in GSI/test builds and are flagged by security tools as indicators of a non-certified, potentially compromised environment.
Package Manager anomalies (red/blue)	The Package Manager in an environment influenced by DSU configuration or a concurrently running secondary Android environment presents state inconsistencies relative to a clean certified build. Colour-coded alert states indicate the PM's runtime environment does not match expected certified signatures.
Running test builds	GSI images carry BUILD_TYPE=userdebug or BUILD_TYPE=eng by definition. The presence of these signatures detectable on the device indicates that GSI-origin system properties are influencing the runtime environment observed by security scanning tools.
Device identified as emulator	GSI builds are architecturally identical to Android emulator images used in developer environments. They share the same build fingerprint structure, property configurations, and system signatures. Security tools use these exact signatures for emulator detection; a device with active GSI properties will test positive for emulator environment.
Project Treble GSI detection	System analysis tools detected the device in a state consistent with GSI deployment readiness — active Treble separation combined with configured DSU infrastructure — rather than the passive Treble compatibility present in a standard consumer device.

5. Three Operational Models

The DSU/GSI infrastructure found on the subject device is consistent with three technically distinct operational models, each representing a different method by which the GSI environment could be exploited. These models are not mutually exclusive and may operate in combination.

5.1 Model I — Sequential Dual-Boot

In the standard DSU operational model, the GSI is installed into the dynamic partition and the device is rebooted into the GSI environment. The primary operating system (HyperOS) remains installed and unmodified; the device runs one environment or the other, not both simultaneously. Upon a subsequent normal reboot, the device returns to HyperOS. The GSI partition can then be deleted, leaving no OS-level trace of the secondary environment's activities.

This model is fully operational on the subject device. Its primary forensic characteristic is its near-zero trace profile within the primary OS: actions taken during a GSI session do not appear in HyperOS logs, and the deletion of the GSI partition removes the primary evidence of the session's existence.

5.2 Model II — Concurrent Virtualisation (AVF)

Utilising the Android Virtualization Framework available on Android 13+ devices with ARM virtualisation-capable hardware, a GSI-derived environment can operate as a protected Virtual Machine concurrently with the primary OS. The Snapdragon 888 in the subject device supports this. Under this model, HyperOS remains active and visible to the device owner while the VM operates in parallel, sharing the device's hardware via the Hardware Abstraction Layer.

This model would explain security tool detections occurring while the user is actively using HyperOS normally — the emulator-like signatures and test build properties originate from the concurrently running VM environment rather than from HyperOS itself.

5.3 Model III — Remote Emulator Architecture

The third model — and the one most consistent with the full body of evidence — does not require the GSI to run on the subject device at all. In this architecture, a complete Android environment (in this case, Android 16) runs on a remote server or cloud emulator infrastructure. The subject device functions as a client relay and identity source: it provides hardware identifiers, network connectivity, account credentials, and session tokens to the remote environment, which in turn operates using the device's identity to authenticate, access accounts, and conduct activity.

This model explains emulator detection in a manner the other two models do not fully account for: the device's own system properties may be partially configured to interact with a remote Android environment, causing the device to exhibit behaviours consistent with an emulator client — because, in functional terms, it is operating as one.

6. The Version Disparity and Its Operational Significance

The GSI builds configured on the subject device are Android 16 — released by Google in 2025. The device officially supports a maximum of Android 14. This two-version disparity is not merely a technical curiosity; it carries direct operational implications.

Android 15 and 16 introduced permission framework changes, expanded hardware API access, and new system-level capabilities that Android 14's security model was designed without reference to. An environment operating under Android 16 on hardware running Android 14 can invoke API calls and permission requests that the device's primary OS was never designed to anticipate, block, or log. The security controls Xiaomi built into HyperOS for Android 14 do not extend to Android 16 system call patterns.

Furthermore, the GSI+GMS variant carries Google Play Services build 25.08.34 — significantly newer than the Play Services version available to HyperOS on this device. Newer GMS versions carry expanded system access privileges, and Play Services operates with elevated permissions that no user-installed application can replicate.

7. Correlation with Known Attack Infrastructure

The Remote Emulator Architecture model requires a communication channel between the subject device and the remote server. This channel must fulfil two functions: it must deliver commands from the remote environment to the device, and it must exfiltrate data, credentials, and session tokens from the device to the remote environment. The channel must also conceal the remote server's true location and identity.

The VPN infrastructure documented across the broader investigation associated with this device — Hern Labs AB (Sweden), Mullvad VPN, NordVPN, and Cloudflare WARP — is entirely consistent with the requirements of such a command-and-control layer. Each of these services provides encrypted tunnelling and anonymised exit node routing capable of concealing both the origin of account access events and the identity of the remote server from standard IP-based forensic analysis.

Table 3. Command and Control Channel Analysis

Channel Type	Method	Detectability
GMS / Firebase Cloud Messaging	Google's push notification infrastructure carries arbitrary data payloads silently over standard HTTPS. Traffic is indistinguishable from legitimate Google service communication.	Very low
ADB over Network	Android Debug Bridge wireless mode (Android 11+) permits full remote command execution without USB connection. If active, provides complete shell-level device access from any network-accessible endpoint.	Low — requires traffic analysis
VPN Tunnel	An always-on VPN routes all device traffic through a controlled remote server. The server receives all device traffic, can inject commands, and operates as a man-in-the-middle for all unencrypted application communications.	Low — traffic appears as VPN
Privileged System Application	An application installed in /system/priv-app operates with elevated permissions, survives factory resets, and can silently receive and execute commands. Invisible in standard app listings.	Very low
DSU Configuration Update	The DSU Loader configuration can be updated to point to an attacker-controlled server rather than Google's official GSI servers. The device then downloads and potentially boots a custom-built GSI containing additional components. The user interface remains identical to legitimate DSU operation.	Very low without source verification

8. Forensic Implications

The operational models described in this paper present a set of specific challenges for digital forensics practitioners approaching cases of this type. Standard mobile forensic practice — whether logical extraction, file system acquisition, or even physical imaging of the primary partition — will not surface evidence of GSI environment activity, Remote Emulator Architecture operations, or the system property modifications introduced by DSU infrastructure.

Specifically, a forensic examination of the HyperOS partition will not contain: activity logs from GSI sessions, commands received from remote servers, data exfiltrated during secondary environment operations, network transactions conducted by a concurrent VM, or modifications made to system properties by DSU framework activation.

9. Discussion

The case documented in this paper illustrates a class of Android-based surveillance architecture that is distinguished by several characteristics that set it apart from conventional mobile threat models. It operates through legitimate, manufacturer-supplied infrastructure. It requires no malware installation in the traditional sense. It leaves no trace in the primary operating system. It does not require bootloader modification. And it exploits the gap between a device's official support lifetime and the continued activity of the Android framework components that persist beneath the manufacturer's OS layer.

The question this raises for the broader security community is not whether DSU can be misused — it evidently can — but whether the architecture of consent and visibility around DSU is adequate for consumer devices that will inevitably reach end-of-support status while continuing to carry active DSU infrastructure. A device that officially receives no further security updates, but continues to maintain functional connectivity to remote Android build servers, represents a persistent attack surface that outlives its manufacturer's support commitment.

The version disparity identified in this case — Android 16 GSI on an Android 14 device — is not a consequence of deliberate targeting of a specific device model. It is a structural consequence of how DSU configuration updates propagate. The DSU Loader on any compatible device is updated by the Android framework to point to current GSI builds, regardless of whether the device's manufacturer continues to support it. As Google advances through Android versions, the gap between the device's supported OS and the GSI builds available to it grows without bound — and with it, the gap between the device's security controls and the capabilities available to an environment operating through DSU.

10. Conclusions

---