The Lifecycle Before Launch
PHANTOM becomes understandable when package metadata is treated as a lifecycle input rather than a one-time file. This chapter traces what happens after an Android APK or iOS IPA reaches an installation path: which service parses it, what state survives the installation, which later consumers reuse that state, and where boot changes the consequences. The practical judgment is simple but important: a valid delivery channel can be enough to start dangerous parsing, even when application code and ordinary runtime permissions never become involved.
Android: installation turns metadata into shared state
On Android, the installation path begins with a package that has reached the Package Manager Service, or PMS. The package may arrive through Google Play or through sideloading. The study’s point is not that every delivery path is equally easy; it is that once the package is accepted for installation, the operating system performs work before the application is launched.
PMS verifies the package signature and parses AndroidManifest.xml. These steps answer different questions. Signature verification checks the package’s cryptographic relationship to its signer. Manifest parsing turns declarations into information the platform can use: package identity, components, permissions, and other system-facing properties. A successful signature check does not make the parser’s later work cost-free. It only establishes that the bytes being parsed are associated with a valid signer.
After parsing, Android persists extracted metadata in its system package database. This persistence is a state transition: information that began inside one package becomes part of the system’s record of all installed packages. The application has not necessarily executed, but the platform now treats its declarations as an entry in shared operating-system state.
Installation also triggers further activity. When PMS completes the installation flow, it broadcasts a package-added event. The Launcher may query the package manager to update the application grid. SystemUI may refresh its view of recent applications. Account and permission services may update their internal state. These consumers do not need the application to open a screen. They need the platform’s answer to questions such as which applications exist, which activities they declare, or what metadata is associated with a package.
Those answers cross process boundaries. Calls such as application and intent enumeration can cause parsed metadata to be serialized into inter-process communication messages. The same value that was harmless-looking inside the package can therefore be represented again inside a framework object and then again inside a message sent to another process. Every representation is a chance to apply a limit, but it is also a chance for the original assumption—“the developer supplied a reasonable value”—to travel farther into privileged code.
This is why the installation event is not the whole story. The metadata may survive as package state even if the first visible result of installation seems normal. Later queries can activate a different path than the initial parser used. A component list may be requested by a launcher. A package description may be requested by a system interface. A stored value may be written again during a state update. The package’s code remains dormant, but its declarations are now available to services that operate with more authority and broader reach than the application itself.
The fan-out matters because a package manager is not answering only one private question. It maintains a shared view that many system components may consult, often with different requests for package, application, component, or permission information. A value can therefore be harmless along the installation path and problematic along an enumeration path that collects more of the package’s state. The installation boundary and the query boundary are related, but they are not the same boundary and should not inherit assumptions blindly from one another.
This also separates two events that are easy to collapse into one. The package may satisfy the conditions to be installed, and the system may record it as installed. Only later does another service request enough information to expose a resource limit or an unhandled failure. In that case, “installation succeeded” does not mean “every future consumer is safe.” Conversely, a failure during installation can still leave persistent material that changes what happens on the next attempt. The lifecycle must be followed across transitions rather than judged by one user-visible status.
The distinction also matters for failure recovery. If a malformed or oversized value remains in the installed package, rebooting does not remove the input. On a later boot, the system can reconstruct or re-read package state and encounter the same value. The paper reports that Android’s relevant manifest parsing is unconditional for installed packages, so Safe Mode does not automatically make the metadata disappear. Recovery mechanisms can restart a service, but restarting a service that receives the same persistent input can repeat the failure rather than resolve it.
Android’s lifecycle therefore has at least four meaningful states: the package is delivered, its metadata is parsed, the metadata becomes shared package state, and system consumers query or re-read it. The security question changes at each transition. Delivery asks whether the package may enter the installation path. Parsing asks whether the metadata is acceptable. Persistence asks what will be retained. Enumeration asks whether one package can safely be represented to other services. PHANTOM follows the gaps between those questions rather than treating installation as a single yes-or-no event.
The same model makes ownership visible. The delivery channel controls entry, the package manager controls interpretation and stored state, and each downstream consumer controls how it allocates, serializes, or displays the information it receives. A defense at only one point may leave the other transitions exposed. The lifecycle is safe only when the bounds and failure behavior remain valid as metadata moves from one owner to the next. This is also why recovery belongs in the design: a parser that rejects bad input protects installation, while a consumer that isolates one bad package protects the rest of the running system, and a boot path that can quarantine recently installed state protects the user when earlier checks failed.
iOS: a valid install can start pre-launch parsing
The iOS sequence has a different set of services but the same ordering problem. An IPA must reach a valid installation channel. The study discusses enterprise-signed IPAs delivered through mechanisms such as enterprise deployment, mobile-device management, an itms-services:// link, or AirDrop carrying an otherwise installable package. The channel matters because it defines how the package can enter the system. It does not make the metadata safe once installation begins.
During installation, several system daemons can inspect the bundle. installd manages extraction and placement. LaunchServices indexes the application in a system-wide database. SpringBoard uses bundle information while building the user-facing application environment. According to the study, these services parse Info.plist before the application is allowed to execute and, in the reported iOS path, before the user’s developer-certificate trust decision has become the gate that matters.
That ordering defeats a common intuition about malicious applications: the application does not need to be opened for its metadata to have an effect. The system may need to learn the application’s identity, place it in an index, or determine how it relates to an extension before it can present the package as an installed application. The work is automatic and privileged. Runtime permission prompts do not protect a stage that precedes application launch.
Extensions add another lifecycle branch. An iOS application can contain separate bundles for features such as widgets, share sheets, or keyboards. Their metadata is not necessarily read by the same consumer as the parent application’s metadata. A Widget Extension is particularly important in the PHANTOM study because a system daemon named chronod scans installed widget metadata during every system startup to discover and register available widgets. The scan does not depend on whether the user has added a widget or trusted the parent application in the ordinary sense described by the study.
This creates a distinction between presence and use. A widget can be present in the installed package even when the person has never selected it as part of the home screen. Its metadata can still be relevant to the service responsible for discovering available widgets. The package has crossed from “an application the user may choose to open” into “an installed object the operating system inventories.” That inventory action is enough to create a consumer for the metadata.
The parent application and its extensions also make persistence more distributed. Removing an icon from a screen is not the same as removing the bundle and all of the state derived from it. A system index, an extension registry, and an early-boot scan can each represent a different stage of the same installation. PHANTOM’s significance lies in this repeated interpretation: a value that was accepted while placing the package can be encountered again when a daemon rebuilds or refreshes system knowledge.
Boot changes the meaning of persistence. During normal use, a service that encounters an oversized value may crash or be terminated and later restart. During early boot, the operating system is still assembling the environment that will supervise those services. If the restarted service reads the same static metadata and fails again, the system can enter a rapid termination-and-restart cycle. The later chapter on iOS examines the memory threshold and the Widget-specific failure chain; the lifecycle point here is that the boot consumer is an automatic reader of data left behind by installation.
The AirDrop scenario needs the same careful separation. The study does not describe AirDrop as a way to install an arbitrary file. It describes a proximity delivery path for an enterprise-signed IPA that is otherwise installable. The recipient must accept the transfer. After that acceptance, the iOS installation path can parse the IPA’s metadata before the application runs. The security issue is the ordering of that parse, not a claim that every file received over AirDrop becomes an application or that no user action is required.
Across both platforms, the same static value can thus occupy several roles: package content, parsed object, persistent state, inter-process response, and boot input. A signature or installation channel decides whether the package can enter this chain; it does not guarantee that each later role has a safe bound.
That distinction gives the lifecycle a useful success-and-failure model. If a package fails the channel or signature conditions, the metadata parser may never receive it. If parsing rejects an unsafe value, the system can stop at installation and protect later consumers. If parsing accepts the value but persistence or enumeration cannot safely represent it, the visible failure may be delayed until another service asks a broader question. If the value survives in installed state, a later boot consumer can turn a one-time installation decision into a recurring recovery problem. These are different transitions with different owners, so one successful check cannot stand in for all of them.
It also explains why the study treats delivery feasibility and parser behavior as separate parts of the threat model. A delivery path must satisfy whatever conditions the platform imposes, and a user may need to approve installation. Once those conditions are met, however, the trigger is the platform’s own metadata processing. The application does not need to be launched as an additional step. The next question is how PHANTOM turns that general lifecycle exposure into four concrete ways of exceeding a consumer’s assumptions.