Three artifact categories worth posting.
The below three artifacts seem rather new based on new capabilities and findings.
iOS Lockdown Mode — Forensic Implications
Apple iOS Lockdown Mode, introduced in iOS 16, is a hardened protection state designed for high-risk individuals. When enabled, it aggressively restricts the device's attack surface. The forensic implications are significant and there seems to be ongoing research on the setting.
| Feature / Artifact | Normal iOS | Lockdown Mode Enabled |
|---|---|---|
| Message link previews | Enabled | Blocked — no preview content generated |
| Wired accessory connections | Full access when unlocked | USB restricted mode always active |
| FaceTime (unknown callers) | Allowed | Blocked |
| Configuration profiles | Installable | Blocked — MDM enrollment prevented |
| JIT JavaScript compilation | Active in browsers | Disabled |
| Shared albums / iCloud Photo links | Available | Disabled |
| Core artifact databases (KnowledgeC, BDC, etc.) | Accessible via full filesystem extraction | Still present — acquisition method is the constraint, not Lockdown Mode |
Lockdown Mode restricts capabilities for forensic extraction tools as well but does not wipe or encrypt artifact databases differently.
If you have the device passcode and a platform capable of a full filesystem extraction
No change to core db files like these below:
/private/var/mobile/Library/CoreDuet/Knowledge/knowledgeC.db/private/var/db/Battery/BDC//private/var/mobile/Library/SMS/sms.db/private/var/mobile/Library/CallHistoryDB/CallHistory.storedata
How to tell if turned on?
Lockdown Mode detection: The device's Lockdown Mode state is stored at:
/private/var/mobile/Library/Preferences/com.apple.springboard.plistLook for the key SBLockdownModeEnabled, a value of 1 confirms the mode was active.
ChatGPT Conversation Artifacts — Browser Storage
ChatGPT stores conversation history in browser-side IndexedDB. These artifacts are not cleared by logging out of the service and they persist until the user explicitly clears site data or uses a private browsing window.
 |
| https_chatgpt.com_0.indexeddb.leveldb |
Artifact locations by browser:
| Browser | Path | Format |
|---|---|---|
| Chrome / Edge | %LOCALAPPDATA%\Google\Chrome\User Data\Default\IndexedDB\https_chatgpt.com_0.indexeddb.leveldb\ |
LevelDB |
| Firefox | %APPDATA%\Mozilla\Firefox\Profiles\<profile>\storage\default\https+++chatgpt.com\idb\ |
SQLite |
| Safari (macOS) | ~/Library/WebKit/WebsiteData/Default/IndexedDB/https_chatgpt.com_0/ |
SQLite |
What is stored:
- Full conversation threads including all user prompts and model responses
- Conversation timestamps (creation and last update)
- Model version used per conversation (e.g.,
gpt-4o,o1) - Conversation titles (auto-generated from the first message)
- Plugin or tool usage metadata where applicable
For Mozilla -->
Firefox / Safari — direct SQLite query:
-- Open the .sqlite file in the idb directory with DB Browser for SQLite
-- Table: object_data
SELECT key, file_ids, data FROM object_data;The data column contains the serialized conversation JSON. Deserializing it recovers full message content and timestamps.
These artifacts reflect locally cached data only not server-side conversation history. Would be interested to see if the difference of the two have been tested.
CarPlay Connection Artifacts — iOS
When an iPhone connects to a CarPlay-enabled head unit, the connection event generates artifacts on the device. These artifacts establish device presence in a vehicle at a specific time and are useful for matching activity and timelines.
Artifacts generated during a CarPlay session:
| Artifact | Path | What It Records |
|---|---|---|
| KnowledgeC — plug-in event | /private/var/mobile/Library/CoreDuet/Knowledge/knowledgeC.db |
USB-C / Lightning connection to the head unit logged as a charge/accessory event with UTC timestamp |
| Wireless CarPlay pairing | /private/var/preferences/com.apple.wifi.known-networks.plist |
Wi-Fi based CarPlay pairings stored with first-seen and last-connected timestamps per SSID/BSSID |
| Bluetooth pairing record | /private/var/mobile/Library/Preferences/com.apple.MobileBluetooth.devices.plist |
Head unit device name, MAC address, first paired timestamp, last connected timestamp |
| App foreground events during session | /private/var/mobile/Library/CoreDuet/Knowledge/knowledgeC.db — /app/inForeground |
Apps active during the CarPlay session (Maps, Phone, Music, third-party navigation) with start/end timestamps |
| Siri interaction logs | /private/var/mobile/Library/Assistant/SiriAnalytics.db |
Voice commands issued through CarPlay with timestamps; each Siri invocation is logged regardless of CarPlay vs. device-direct |
Querying KnowledgeC.db for CarPlay connection events:
SELECT
ZOBJECT.ZSTARTDATE,
ZOBJECT.ZENDDATE,
ZOBJECT.ZVALUESTRING,
ZOBJECT.ZSTREAMNAME
FROM ZOBJECT
WHERE ZOBJECT.ZSTREAMNAME IN ('/charge/isPluggedIn', '/device/isPluggedIn')
ORDER BY ZOBJECT.ZSTARTDATE ASC;Timestamps in knowledgeC.db are stored as CoreData epoch (seconds since January 1, 2001). To convert to Unix epoch, add 978307200.
-- Convert CoreData timestamp to human-readable UTC
SELECT
datetime(ZOBJECT.ZSTARTDATE + 978307200, 'unixepoch') AS start_utc,
datetime(ZOBJECT.ZENDDATE + 978307200, 'unixepoch') AS end_utc,
ZOBJECT.ZSTREAMNAME
FROM ZOBJECT
WHERE ZOBJECT.ZSTREAMNAME IN ('/charge/isPluggedIn', '/device/isPluggedIn')
ORDER BY ZOBJECT.ZSTARTDATE ASC;Investigative value: Pairing a CarPlay plug-in timestamp from knowledgeC.db with the Bluetooth pairing record for a specific head unit (which includes the vehicle's head unit device name and MAC address) can help tie an iPhone to a specific vehicle at a specific time.
Acquisition requirement: All of the above require a full filesystem extraction. These paths are not accessible via logical or advanced logical acquisition.
Check out the latest → Weekly DFIR Watchtower
Tool source and DFIR scripts: github.com/forensicfellowship
