The Phone That Forgot Itself:
Reconstructing a Wiped iPhone

The following is a lightly anonymised account of a real forensic engagement conducted by Mjolnir Security. Organisational identifiers, personal names, and timestamps have been altered or generalised. All technical details — the artifacts examined, the commands used, and the conclusions drawn — are presented exactly as they occurred in the investigation. We are publishing this case because it illustrates something poorly understood even among experienced forensic practitioners: an iPhone that has been factory reset does not erase the forensic record of its existence if it was ever paired with a Mac.

The Engagement

How We Were Called In

A mid-sized financial services firm had terminated an employee following an internal HR investigation. The circumstances were serious enough that legal counsel recommended a forensic review of the employee's company-issued devices to determine whether any client data or intellectual property had been removed before or during the termination.

Two devices were handed to us: a MacBook Pro running macOS Ventura, and an iPhone 14 Pro. Both were company-issued, enrolled in MDM, and had been in the employee's sole possession for approximately 22 months.

The problem, which legal counsel disclosed at the outset, was that the iPhone had been factory reset. The employee had initiated a full erase through Settings before surrendering the device. By the time it was handed over, it was sitting on the iOS setup screen — a blank slate.

The Mac, however, had not been touched.

Initial Assessment

Our first hour was spent taking forensic images of both devices: a full sector-level image of the MacBook's SSD, and a logical extraction of the iPhone (which yielded almost nothing — just default iOS artefacts from the brief MDM re-enrolment). The iPhone acquisition confirmed what we already knew: the factory reset had been effective at the filesystem level. No user data, no call logs, no app data, no photos. iOS factory resets are thorough — they re-encrypt the NAND using a new key, rendering all prior data cryptographically inaccessible.

We turned our full attention to the Mac.

Finding 1: The Pairing Record

What the Mac Knew Before We Did Anything

The lockdown directory on macOS stores cryptographic pairing records for every iOS device that has ever been paired with the machine via USB. These records are created the moment a user taps "Trust" on their iPhone when connecting it to a new Mac.

In the lockdown directory, we found a single pairing record. Its UUID matched the MDM-reported device UUID of the employee's iPhone 14 Pro. The plist contained a RootPrivateKey and a HostCertificate created on the date the device was originally issued — 22 months prior. Most importantly, the EscrowBag field confirmed this specific Mac and this specific iPhone had been in a trusted pairing relationship.

Finding 2: The Backup the Employee Forgot

MobileSync — What Stays on the Mac

When a user connects an iPhone to a Mac and opens Finder, a backup can be created. Many users are unaware of this — iCloud Backup is the prominent option, and local Mac backups feel like a legacy workflow. But local backups happen, especially when a device is first set up, when iCloud storage is full, or simply because the user clicked "Back Up Now" without thinking about the forensic implications.

In the MobileSync directory, we found a backup dated eight days before the termination date. The device UUID matched the pairing record exactly. The backup had not been encrypted with a custom password, which meant we could extract it fully.

What the Manifest.plist Told Us Immediately

$ plutil -convert xml1 Manifest.plist -o - | grep -E 'Serial|IMEI|Phone|Product|LastBackup'

  <key>Build Version</key>    <string>21A342</string>
  <key>Device Name</key>       <string>████ iPhone</string>
  <key>IMEI</key>              <string>35████████████5</string>
  <key>Last Backup Date</key>  <date>2024-██-██T14:23:07Z</date>
  <key>Phone Number</key>      <string>+1 (███) ███-████</string>
  <key>Product Type</key>      <string>iPhone14,3</string>
  <key>Serial Number</key>     <string>████████████</string>

The IMEI, serial number, and phone number were now part of the forensic record — data that the factory reset had obliterated from the device itself but that lived unchanged on the Mac's hard drive.

Finding 3: The App Inventory

Info.plist — A Snapshot of Installed Applications

The Info.plist file within the backup contains an Applications key enumerating every third-party app installed at backup time.

$ python3 - << 'EOF'
import plistlib
with open('Info.plist','rb') as f:
    info = plistlib.load(f)
apps = info.get('Installed Applications', [])
for app in sorted(apps): print(app)
EOF

The installed applications list contained the expected productivity apps — Mail, Slack, the company's MDM agent — but it also contained several entries directly relevant to the investigation:

• com.getdropbox.Dropbox — A personal Dropbox client. The company did not use Dropbox; all approved file storage was via SharePoint.
• com.google.Drive — Personal Google Drive. Same observation as Dropbox.
• com.telegram.Telegram — End-to-end encrypted messaging with "secret chats" that prevent backup.

The backup's Info.plist also contained a LastSyncedComputerName field matching the MacBook's hostname — creating an explicit documented link between the two devices.

Finding 4: The KnowledgeC.db Cross-Device Timeline

Why the Mac's KnowledgeC Contains iPhone Data

This is one of the most powerful and least understood aspects of macOS forensics. When an iPhone is paired with a Mac and iCloud is enabled, Apple's Continuity framework syncs activity data between devices. The Mac's KnowledgeC.db accumulates records from every paired Apple device associated with the same Apple ID.

Extracting iPhone-Sourced Activity

-- Step 1: Identify device IDs
SELECT ZDEVICEID, ZOWNER, ZPLATFORMROOTID
FROM   ZSOURCE
GROUP BY ZDEVICEID;

-- Step 2: Pull all iPhone activity for a date range
SELECT datetime(Z.ZSTARTDATE + 978307200,'unixepoch','localtime') AS start,
       datetime(Z.ZENDDATE   + 978307200,'unixepoch','localtime') AS end,
       Z.ZSTREAMNAME, Z.ZVALUESTRING
FROM   ZOBJECT Z
JOIN   ZSOURCE S ON S.Z_PK = Z.ZSOURCE
WHERE  S.ZDEVICEID = 'A3F2████-████-████-████-████████████'
  AND  Z.ZSTARTDATE > strftime('%s','2024-██-01') - 978307200
ORDER BY Z.ZSTARTDATE ASC;

What the Timeline Revealed

Dropbox was used three times across three days, for a combined foreground duration of over 53 minutes. This is not background sync — a background sync daemon does not register foreground focus in KnowledgeC. The user had the app open and was actively interacting with it.

Finding 5: PowerLog — Battery Data as a Behavioural Record

What PowerLog Is and Why It Ends Up on the Mac

PowerLog is Apple's internal battery and performance telemetry system. It runs continuously on every iPhone, recording per-process CPU usage, network activity, and battery state. When a Mac backup is performed, PowerLog databases are included as part of the com.apple.BatteryLife domain — stored as hash-named blobs in the MobileSync directory.

Extracting PowerLog from the Backup

import sqlite3, shutil, os

conn = sqlite3.connect('Manifest.db')
rows = conn.execute(
    "SELECT fileID, relativePath FROM Files"
    " WHERE relativePath LIKE '%BatteryLife%'").fetchall()

for file_id, rel_path in rows:
    src = os.path.join(backup_dir, file_id[:2], file_id)
    dst = os.path.join('powerlog_extracted', rel_path.replace('/','_'))
    shutil.copy2(src, dst)

What PLNetworkUsageMonitor Revealed

SELECT datetime(timestamp,'unixepoch') AS sample_time,
       bundleIdentifier,
       wifiOut, wifiIn, wiredOut, wiredIn
FROM   PLNetworkUsageMonitor
WHERE  bundleIdentifier IN ('com.getdropbox.Dropbox','com.google.Drive')
ORDER BY timestamp ASC;

The PowerLog data showed cumulative WiFi outbound bytes for Dropbox increasing by approximately 340 MB across the period of interest. Google Drive showed approximately 95 MB of outbound WiFi transfer. Combined: ~435 MB transferred to personal cloud storage in three days.

Finding 6: Browser Activity That Safari History Didn't Contain

The Gap in Standard Browser Forensics

The employee had cleared Safari history on the Mac — the History.db file contained no entries older than the morning of termination. On a Windows machine, cleared browser history is often a dead end. On a Mac, it is not.

SELECT datetime(ZSTARTDATE + 978307200,'unixepoch','localtime') AS visit_time,
       ZVALUESTRING AS domain,
       CAST((ZENDDATE - ZSTARTDATE) AS INT) AS duration_sec
FROM   ZOBJECT
WHERE  ZSTREAMNAME = '/safari/history'
ORDER BY ZSTARTDATE DESC
LIMIT  100;

The /safari/history stream for the two weeks prior to termination showed browsing to the company's internal SharePoint, a legal information site about employee rights during termination, and — on three separate days — the web interface for a competing financial services firm.

Reconstructed Timeline

By the end of the analysis, we had constructed a comprehensive picture of an iPhone that had been factory reset and was forensically blank — not from the device itself, but entirely from its forensic shadow on the Mac.

What This Engagement Teaches Us

For Investigators

When a mobile device has been wiped, do not treat it as the end of the forensic road. Begin treating every Mac, iPad, or Apple TV that the device was ever paired with as a potential evidence source. The specific artifacts to prioritise, in collection order:

1. Lockdown pairing records — establish device identity and pairing date even with a blank device.
2. MobileSync Manifest.plist and Info.plist — recover IMEI, serial, phone number, and installed app inventory from backups that predate the wipe.
3. KnowledgeC.db ZSOURCE filtering — extract iPhone activity timeline from the Mac database, separate from Mac activity. Covers ~30-day retention regardless of device wipe.
4. PowerLog databases (via Manifest.db) — recover per-application network transfer volumes, quantifying data exfiltration candidates.
5. KnowledgeC /safari/history — recover browsing domains independent of Safari history, which can be manually cleared.

For Security Engineers

If you are building MDM policies or endpoint security controls for an Apple fleet, several practical implications follow:

• MDM should enforce encrypted local backups — an unencrypted backup can be extracted without any password. An encrypted backup with a strong, MDM-managed password significantly raises the bar.
• KnowledgeC.db is a DLP telemetry source — the /app/inFocus and network.request streams provide app-level activity data without requiring an endpoint agent on the device.
• Pairing restrictions via MDM — a supervised iOS device can be configured to disallow pairing with unmanaged computers, limiting forensic surface on unapproved Macs.
• The backup window matters — the 8-day gap in this case meant we missed the final 8 days of PowerLog. MDM policies that enforce nightly backups minimise this evidence gap.

Conclusion

A factory reset iPhone handed over at termination is not a blank slate — it is an iPhone whose forensic record has been moved. From device, to Mac. From volatile storage, to a hard drive that nobody wiped.

The artifacts documented here are not obscure research findings. They are features Apple built into the operating system for legitimate purposes. KnowledgeC.db powers Screen Time. MobileSync powers local backups. Lockdown pairing records power trusted device connections. PowerLog powers battery diagnostics. None were designed as forensic tools — but all function as forensic tools.

The investigation was successful because the Mac remembered everything the iPhone tried to forget.