The Ghost Data Problem

Recent reporting by 404 Media revealed that the FBI had recovered Signal message content from a suspect’s iPhone — not by breaking Signal’s encryption, but by reading cached push notification data that Apple’s Push Notification Service (APNs) had stored on the device independently of the Signal app. The story made headlines. What it should have done was trigger a profession-wide reassessment. That push notification cache is one of probably two dozen mobile artifact categories that routinely survive app deletion, factory resets, and even deliberate wiping.

The Notification Cache Was Just the Beginning

The FBI’s Signal recovery worked because of a fundamental architectural reality: on both iOS and Android, push notifications are handled by the operating system, not by the app. When a Signal message arrives, Apple’s APNs framework receives it first, caches it in a system-level database, and then delivers it to the Signal app. Signal can delete the message from its own sandbox. It cannot reach into the OS-level notification cache and delete what APNs stored there. The notification daemon does not take instructions from third-party applications.

This is not a bug. It is the intended design of a write-optimised, reliability-first notification delivery system. Apple and Google both cache notifications to handle edge cases: the app is not running, the device is in low-power mode, the app crashes before acknowledging delivery. The cache exists to guarantee delivery. The side effect is that it also guarantees forensic persistence.

But push notification caches are just one category. Mobile operating systems maintain dozens of system-level databases that independently track app behaviour, network usage, battery consumption, location history, device state, and user interaction patterns. These databases are maintained by OS daemons that do not coordinate with individual applications. They do not honour app deletion. Many survive factory resets because they are stored in partitions that the reset process does not touch.

Why Data Survives When It Shouldn’t

The persistence of ghost data is not a single vulnerability. It is a feature collision — the unintended forensic consequence of multiple well-designed systems operating independently.

Consider what happens when a user installs a messaging app on iOS. The app gets a sandbox. It stores its messages in its own SQLite database within that sandbox. But the moment the app runs, at least six other system components start independently recording data about it:

• CoreDuet (knowledgeC.db) records that the app was opened, when, for how long, and what state transitions occurred.
• Battery daemon (PowerLog.PLSQL) records the app’s CPU usage, network radio usage, and energy impact per hour.
• Wireless data daemon (DataUsage.sqlite) records per-app cellular and Wi-Fi bytes transferred.
• Push notification service (APNs) caches incoming notifications in a system database outside the app’s sandbox.
• Location daemon (routined/locationd) records location context associated with app usage.
• Spotlight indexer indexes any searchable content the app exposes via the iOS search API.

When the user deletes the app, the sandbox is removed. The app’s own database is gone. But the six system databases listed above? They have no mechanism to detect that the app was deleted. They have no cleanup hook. They are maintained by system daemons that run at a privilege level above individual applications. They continue to hold their historical records indefinitely, subject only to their own internal retention policies — which can be weeks, months, or in some cases years.

The same pattern applies on Android, with different databases but the same architectural reality. UsageStats, notification_history.db, FCM delivery logs, recent task thumbnails — all maintained by system services that operate independently of individual applications. The user controls the app. The user does not control the OS.

iOS Artifact Catalog

knowledgeC.db — The Everything Database

knowledgeC.db is, in our assessment, the single most valuable forensic artifact on iOS for establishing a behavioural timeline. It is a SQLite database maintained by Apple’s CoreDuet framework, which exists to power Siri Suggestions, Screen Time, and adaptive battery management. To do its job, CoreDuet records an extraordinarily detailed log of how the user interacts with their device — which apps they open, when, for how long, in what context, and what device state changes occur alongside those interactions.

-- Query knowledgeC.db for app usage events (foreground/background transitions)
-- Timestamps are CoreData/Cocoa epoch (2001-01-01 00:00:00 UTC)
-- Add 978307200 to convert to Unix epoch

SELECT
    datetime(ZOBJECT.ZSTARTDATE + 978307200, 'unixepoch') AS 'start_time',
    datetime(ZOBJECT.ZENDDATE + 978307200, 'unixepoch') AS 'end_time',
    ZOBJECT.ZVALUESTRING AS 'bundle_id',
    (ZOBJECT.ZENDDATE - ZOBJECT.ZSTARTDATE) AS 'duration_seconds',
    ZSOURCE.ZBUNDLEID AS 'source',
    CASE ZOBJECT.ZSTREAMNAME
        WHEN '/app/usage' THEN 'App Usage'
        WHEN '/app/inFocus' THEN 'App In Focus'
        WHEN '/safari/history' THEN 'Safari Visit'
        WHEN '/app/activity' THEN 'App Activity'
        ELSE ZOBJECT.ZSTREAMNAME
    END AS 'event_type'
FROM ZOBJECT
LEFT JOIN ZSOURCE ON ZOBJECT.ZSOURCE = ZSOURCE.Z_PK
WHERE ZOBJECT.ZSTREAMNAME IN (
    '/app/usage', '/app/inFocus',
    '/safari/history', '/app/activity'
)
ORDER BY ZOBJECT.ZSTARTDATE DESC;

PowerLog.PLSQL — Battery Daemon Attribution

-- Query PowerLog.PLSQL for per-app CPU and network radio usage
-- Useful for corroborating knowledgeC.db timelines with independent energy data

SELECT
    datetime(timestamp, 'unixepoch') AS 'time',
    BundleID AS 'app',
    ScreenOnTime AS 'screen_on_sec',
    BackgroundTime AS 'bg_sec',
    CellRxBytes + CellTxBytes AS 'cell_bytes',
    WiFiRxBytes + WiFiTxBytes AS 'wifi_bytes'
FROM PLAppTimeService_Aggregate_AppRunTime
WHERE BundleID NOT LIKE 'com.apple.%'
ORDER BY timestamp DESC;

PowerLog.PLSQL’s primary forensic value is timeline corroboration. When knowledgeC.db says an app was in the foreground for 12 minutes, PowerLog.PLSQL independently records the CPU time and network bytes consumed during that period. Two independent system databases, maintained by two independent daemons, both recording the same app activity. This is the kind of dual-source corroboration that survives cross-examination.

DataUsage.sqlite — Per-App Network Accounting

DataUsage.sqlite is the iOS equivalent of Windows SRUM.db for network attribution. It records how many bytes each app has transferred, and critically, it retains entries for apps that have been deleted. The cumulative counters persist until the user manually taps “Reset Statistics” in Settings > Cellular — an action that fewer than 5% of users ever perform, according to our sample of over 200 forensic extractions.

routined + locationd — Behavioural Location History

The routined database is Apple’s behavioural location model — it learns where the user lives, works, and frequently visits. Unlike GPS track logs, Significant Locations are inferred from a combination of GPS, Wi-Fi, cellular tower data, and time-of-day patterns. The result is a remarkably accurate location timeline that most users do not know exists and that survives standard device wipes in certain iOS versions because the data is stored in a protected data partition that the user-facing “Erase All Content and Settings” operation does not always fully clear.

SQLite WAL Files — The Hidden Recovery Layer

SQLite’s Write-Ahead Logging is a journaling mechanism designed for performance and crash recovery. When an application writes to a SQLite database in WAL mode, the write goes to a separate -wal file first. The main database is only updated when a checkpoint occurs — typically when the WAL reaches a size threshold, the database is closed cleanly, or an explicit checkpoint is requested. Until that checkpoint happens, the -wal file contains data that the main .sqlite file does not.

The forensic implication is significant. If a user deletes messages from a chat app, and the app deletes those rows from its SQLite database, but no checkpoint has occurred since, the deleted rows may still exist in the WAL file. This is not theoretical — it is one of the most reliable recovery techniques in mobile forensics, and it applies to every SQLite database on both iOS and Android.

Android Artifact Catalog

UsageStats — App Usage History

Android UsageStats is the closest equivalent to iOS knowledgeC.db, with one significant advantage: its retention window can extend to a full year. The /data/system/usagestats/ directory contains XML files organised by time bucket (daily, weekly, monthly, yearly). Each file records every app that was used during that period, when it was last in the foreground, how many times it was launched, and the total foreground duration. This data survives app uninstallation and persists until the time bucket rolls off the retention window.

Android Notification History — Message Preview Cache

This is the artifact that makes end-to-end encryption forensically complicated. When Signal delivers a message, the notification includes a preview of the decrypted message content — that preview is what appears in the notification shade. Android’s notification history service caches that preview in a system database outside Signal’s control. Signal cannot delete it. Signal does not even know it exists. The decrypted message content sits in a system database, indexed by timestamp and package name, waiting to be read.

-- Query Android notification_history.db for encrypted messenger notifications
-- This recovers message previews from Signal, Telegram, WhatsApp
-- that the OS cached independently of the app's own database

SELECT
    datetime(posted_time / 1000, 'unixepoch', 'localtime') AS 'notification_time',
    pkg AS 'app_package',
    title AS 'sender',
    text AS 'message_preview',
    sub_text AS 'group_name'
FROM notification_log
WHERE pkg IN (
    'org.thoughtcrime.securesms',     -- Signal
    'org.telegram.messenger',          -- Telegram
    'com.whatsapp',                    -- WhatsApp
    'com.whatsapp.w4b'                 -- WhatsApp Business
)
ORDER BY posted_time DESC;

Recent Tasks Thumbnails — OS-Generated Screenshots

Recent Tasks thumbnails are perhaps the most visually striking ghost data artifact. Every time a user switches away from an app — presses home, opens another app, or locks the device — Android takes a screenshot of the current screen and stores it as the thumbnail for the task switcher. These screenshots are stored in the system partition, not the app’s sandbox. They can capture anything that was on screen: message content, file listings, login screens, financial data, map locations.

Tombstone Crash Logs — Memory Fragments from Crashes

Tombstone files are Android’s crash dump mechanism for native code. When a process crashes due to a segmentation fault, abort signal, or similar native error, the system writes a tombstone file containing the register state, stack trace, memory maps, and portions of the process’s memory at the time of the crash. This memory dump can contain fragments of whatever data the process was handling when it crashed.

FCM Delivery Logs — Push Message Receipts

FCM delivery logs serve a similar forensic function to iOS APNs caches. They prove that a message was received by the device via push notification. Even if the app has been uninstalled and its own message database is gone, the GMS-level FCM delivery log retains a record that a push message was delivered to that app’s package name at a specific time. This is particularly valuable for establishing communication timelines when the messaging app itself is no longer present on the device.

MITRE ATT&CK Mapping

The following table maps mobile MITRE ATT&CK techniques to the ghost data artifacts that survive each technique’s execution. These artifacts provide forensic evidence even when the adversary believes they have successfully covered their tracks.

Practitioner Notes

Acquisition Method Matters — Full Filesystem or Nothing

The single most important takeaway for practitioners is this: logical extraction is not sufficient for ghost data recovery. An iTunes backup (iOS) or ADB backup (Android) will not contain knowledgeC.db, PowerLog.PLSQL, DataUsage.sqlite, UsageStats, notification_history.db, or any of the system-level databases described in this article. These files live outside the backup scope. You need a full filesystem extraction — GrayKey, Cellebrite UFED Premium with applicable exploits, checkm8-based extraction for older iOS devices, or root-level access on Android.

If your engagement scope or tooling limits you to logical extraction, you must document that limitation in your report. The absence of ghost data artifacts in a logical extraction is not evidence of absence — it is evidence that your extraction method did not reach the relevant partitions.

Parse WAL Files First

Before examining any SQLite database from a mobile extraction, check for the presence of -wal and -shm sidecar files. If they exist, the WAL contains uncheckpointed writes that may include data no longer present in the main database. Always work on a forensic copy. If you need to checkpoint the WAL to make the data visible in a standard SQLite browser, perform the checkpoint on the copy, never the original. Document the WAL file size and modification timestamp before any manipulation.

Android Root Is Not Optional

For Android devices, the gap between what you can see with ADB-level access and what you can see with root or physical access is enormous. ADB gives you the app sandboxes (and only for debuggable apps or apps that have opted into backup). Root gives you /data/system/, /data/system_de/, /data/system_ce/, /data/data/com.google.android.gms/, and /data/tombstones/. Without root, you are examining a mobile device through a keyhole. With root, you have the full floor plan.

Document Artifact Metadata for Court

Ghost data artifacts are powerful precisely because they are maintained by the operating system independently of the user. This independence is their forensic strength — but it also means you need to explain their provenance clearly in reports and testimony. For each artifact, document: (1) the exact file path and extraction method, (2) the system service that maintains the database, (3) why the data persists after app deletion (because the system service has no app lifecycle hook), (4) the retention policy (how far back the data extends), and (5) any corroborating artifacts from independent system databases. Courts respond well to multiple independent system databases telling the same story.

The Signal Story Isn’t About Signal

The FBI’s Signal recovery was newsworthy because of Signal’s reputation for privacy. But the forensic principle it demonstrated has nothing to do with Signal specifically. End-to-end encryption secures the transport layer — the path between sender and recipient. It does not and cannot secure the OS-level caching, indexing, and accounting that happens on the recipient’s device after the message arrives and is decrypted for display.

Every app on a mobile device leaves OS-level traces it cannot control. The app developer can encrypt their database, implement disappearing messages, and delete data on command. They cannot reach into knowledgeC.db and delete the usage entry. They cannot reach into DataUsage.sqlite and zero the byte counters. They cannot reach into the notification history and purge the cached preview. They cannot delete the Recent Tasks thumbnail that the OS captured when the user switched away. They cannot suppress the tombstone file if their app crashes.

The implication for forensic practitioners is clear: if your mobile examination stops at logical extraction and app-level databases, you are seeing maybe 40% of what is there. The remaining 60% lives in system databases that most commercial tools can extract but that many examiners never think to query. It lives in WAL files that standard SQLite browsers silently ignore. It lives in crash dumps, task thumbnails, and notification caches that exist because the operating system was designed for reliability, not for privacy.