Overview

PHANTOM’s Android cases split into two processing paths. Package and signing metadata can overflow an approximately 1 MB Binder reply and crash a receiving service such as SystemUI or telephony; a string can also exceed FastDataOutput.writeUTF’s 65,535-byte Modified UTF-8 limit during persistence, causing package-state loss or, through an unchecked AssertionError in system_server, reboot behavior. The same static package can retrigger failures after restart. Severity depends on the queried object, receiving process, exception path, and recovery behavior; reported outcomes range from L2 disruption to tested L5 escalation.

Learning outcomes

Binder overflow can crash a receiving Android service when package metadata makes a serialized reply too large.
FastDataOutput.writeUTF’s 65,535-byte encoded-length limit can turn persistence failure into package-state loss or system_server failure, depending on error handling.
Android severity follows the processing chain—query, representation, receiving process, supervision, and recovery—not field size alone.

Keywords

PHANTOMAndroidBinderpersistenceSystemUIRescueParty

Android: When a Package Query Takes Down the UI

PHANTOM’s Android findings are easiest to understand as a diagnosis with two different paths. One path fails when package metadata is serialized into a Binder reply; another fails when a string is persisted through Android’s Modified UTF-8 encoder. This chapter follows each path from the same lifecycle input to its distinct service, recovery, and data-loss consequences, so the reader can see why “the Android crash” is not one mechanism and why a static package can keep causing trouble after a reboot.

The Binder path: a package description becomes a process-wide reply

Android uses Binder as a core inter-process communication mechanism. In plain terms, Binder lets one process ask another process for information and receive a structured response. Package metadata crosses this boundary when a system component queries the package manager for application, component, or signing information.

The first step is not a crash. A package has already been installed, its manifest has been parsed, and its metadata has become part of persistent package state. Later, a caller requests information about installed software. The package manager constructs an object such as package or application information and prepares it for transmission. Values that began as fields in one package are now part of a reply intended for another process.

Binder imposes an approximately 1 MB transaction-buffer limit, shared across concurrent transactions in a process. The limit is an operating-system protection: a single message should not consume unbounded space in the receiving or sending path. PHANTOM shows how that protection becomes an attack trigger when the package parser has allowed one application’s metadata to grow beyond what a later reply can carry.

When the serialized response exceeds the buffer, the kernel driver rejects the transaction. The Java-side result can appear as a TransactionTooLargeException, but the more important system consequence is what happens to the receiving process. A component such as SystemUI may be in the middle of asking for installed applications or launcher information. If the reply cannot be reconstructed safely, the receiving side can throw while handling the response. The failure is not contained inside the package manager or the originating application; it reaches a system process that supplies visible device functions.

The study’s representative chain begins with SystemUI initializing its launcher and asking for application information. The response containing the malicious package is too large. The transaction fails, the receiving process crashes, and Android automatically restarts the persistent SystemUI process. The restart does not change the package metadata. When SystemUI makes the same query again, the same package produces the same oversized response.

This is a feedback loop, not a one-time exception. A persistent service is designed to restart when it fails, but restart is useful only if the input or state that caused the failure has changed or can be isolated. Here the static package remains installed. The system repeatedly attempts to reconstruct a normal view of its applications and repeatedly encounters the same bad entry.

Android’s PackageWatchdog and RescueParty mechanisms are intended to respond to repeated failures.

Published by DeepMox

FAQ

What happens when Android package metadata exceeds Binder’s limit?

The Binder transaction is rejected when the serialized reply exceeds its approximately 1 MB buffer, and the receiving system process can crash while handling the response. A persistent SystemUI restart can repeat the same query.

Why can Android package-state persistence cause data loss?

An oversized string can exceed FastDataOutput.writeUTF’s 65,535-byte Modified UTF-8 limit, causing the atomic package-state write to fail and a later read to fall back to an older backup. The study reports that a recently installed app and its data may then be silently removed.

Why do Android metadata fields have different severity levels?

Severity depends on the query, serialized object, receiving process, exception handling, and recovery mechanism, not on field size alone. Reported Android paths span partial disruption, data loss, and tested recovery escalation.

Previous9 minPHANTOM: Four Metadata Growth Paths

Next9 minPHANTOM: iOS Widget Boot Failures

PHANTOM: Android Binder and Persistence

Android: When a Package Query Takes Down the UI

The Binder path: a package description becomes a process-wide reply

FAQ