mobile device triage (consent-based) — methodology

safety and consent — before any of the path

this case type is built for advocate-led intakes — someone who believes they need help, not a covert employer sweep. if you are supporting a survivor, start with safety planning, not backup extraction. US crisis lines: 988 (suicide & crisis lifeline) · 1-800-799-7233 (national DV hotline).

1. does the device owner explicitly consent to this scan? verbal consent is not enough — document it.
2. is the phone shared, monitored, or financially controlled by someone else? scanning may tip them off.
3. does the owner want a forensic record, or do they want the abuse to stop? both are valid — the path differs.
4. will creating a backup notify the abuser? (iCloud sync echoes, shared Apple ID, MDM alerts)
5. if safety requires a factory reset: that destroys evidence. an advocate may still recommend it — respect that call.
6. preserve before you analyze. airplane mode before backup where safe. work on a workstation the abuser does not control.

what evidence exists and how fast it dies

the first 10 minutes

1. confirm written or documented consent from the device owner — note who, when, and scope.
2. assess safety: is scanning now safe, or should you defer until a shelter plan is in place?
3. enable airplane mode if safe — stops live sync without obvious "offline" banners on every app.
4. iOS: create an encrypted local backup via Finder/iTunes to a trusted workstation — not iCloud if the abuser shares the account.
5. android: export .ab backup via adb or OEM backup tool; pull a logcat threadtime dump in the same session.
6. export google location timeline json if the owner controls that account and consents.
7. hash every export (sha-256) and note local save path — chain of custody starts here.
8. do not install forensic tools on the live phone unless the owner agrees — backup-first is the default.
9. do not confront anyone named in the artifacts until an advocate says it is safe.
10. begin the path below on the exports — not on the live device.

the path

iOS and android artifacts share one case type but not one export. run steps 1–2 and 4–6 on the iOS backup; steps 3 and 7 on the android export; step 8 on whichever location sources the owner provided.

1. 1. ios backup browser

   drop Manifest.db from an iTunes/Finder backup folder. lists backed-up app domains, relative paths, and file inventory — first map of what exists before deep extraction.why first: consent-based triage starts with inventory. you need to know which messaging apps, databases, and spotlight caches are in scope before pulling anything heavy.

2. 2. ios backup analyzer

   same backup manifest — browse file structure, extract app data and sqlite databases (SMS, Safari, messaging app containers).why second: the browser tells you what is there; the analyzer lets you pull the artifacts the path needs (interactionC, ApplicationState, Screen Time).

3. 3. android backup analyzer

   drop the .ab backup export. browse app data, shared preferences, and databases — surfaces stealth tracker prefs and sideload residue on shared devices.why third: many intakes involve both iOS and a shared android phone. the ab file is the android equivalent of the iOS manifest pass.

4. 4. ios spotlight search artifact extractor

   drop interactionC.db or spotlight sqlite from backup. reconstructs on-device search queries — shelter lookups, advocate contacts, restraining-order searches.why fourth: spotlight survives app uninstalls longer than chat history. in DV-adjacent intakes, search queries often tell the story before messages do.

5. 5. ios screen time forensic analyzer

   drop RMAdminStore-Local.sqlite from backup. app usage minutes, website visits, pickup frequency — digital activity timeline.why fifth: screen time corroborates messaging-app spikes and late-night pickup patterns without needing intact chat databases.

6. 6. ios app install and uninstall timeline reconstructor

   drop ApplicationState.db, MobileInstallation.log, or manifest db. install/uninstall/upgrade timeline with mass-uninstall burst detection.why sixth: mass uninstall of Signal/WhatsApp/Telegram in one hour is a strong coercion or cover-up signal — this tool surfaces the window.

7. 7. android logcat analyzer

   drop logcat threadtime export. package install/uninstall traces, security exceptions, ANR/crash lines — android-side install timeline.why seventh: when the android backup is sparse, logcat often preserves package manager events the ab file no longer holds.

8. 8. mobile location history extractor

   drop Consolidated.db (iOS significant locations), google location history json, or csv gps export. haversine stops and movement timeline.why last: location corroborates shelter visits and residence clusters — run after you understand app/search context so clusters are interpretable.

common false leads

• the messaging apps are still installed, so nothing was deleted — mass uninstalls leave ApplicationState and MobileInstallation.log traces even when icons return later.
• iCloud backup equals a forensic copy — iCloud is not chain-of-custody friendly and may be visible to a shared account holder.
• no chat.db means no evidence — spotlight search queries and screen time often survive longer than message content.
• location history proves guilt — clusters show movement patterns; intent and consent require human context from the advocate interview.
• android .ab contains everything — modern android backups are sparse; logcat install lines may be the only android-side proof.
• screen time spike equals addiction — elevated Messages usage can also indicate coercion, monitoring, or crisis communication.

what we can tell you, what we can't

we can tell you:

• which apps were installed, uninstalled, and when — including mass-uninstall bursts
• spotlight search queries and on-device search history from exported sqlite
• screen time usage patterns, pickup frequency, and app-level minutes
• location stop clusters from Consolidated.db or google timeline exports
• android package install/uninstall events from logcat and backup residue
• stealth tracker or suspicious shared-pref keys in android backup exports

we can't tell you:

• recover deleted chat content that is not in the backup — if chat.db is empty, it is empty
• prove who installed an app or searched a term — device access and consent context are human evidence
• covertly image a phone without owner consent — that is outside this case type and may be unlawful
• whether the owner should confront a partner — advocate and safety-planning territory
• legal admissibility in your jurisdiction — counsel and qualified examiners decide that
• live acquisition from a locked device — these tools analyze exports you already have

handing it off

• DV advocate (often first): safety plan, consent documentation, whether evidence sharing is safe now or should wait.
• qualified mobile examiner: if the case escalates to litigation or criminal complaint — full logical/physical acquisition, hash-validated images, expert report.
• law enforcement (with advocate guidance): backup exports, timeline UTC, uninstall windows, location clusters — only when the survivor chooses to report.
• outside counsel: preservation log (sha-256 of each export, who pulled what, when), consent record, tool output pdfs/json.
• small-org IT: if the intake is employment-adjacent (BYOD policy, harassment complaint) — separate consent from employer policy review; do not conflate with survivor intakes.

further reading

• NIST CFTT — mobile forensics tool testing
• CISA — device security hygiene (baseline hardening)
• EFF surveillance self-defense
• Coalition Against Stalkerware
• MITRE ATT&CK · application layer protocol (mobile exfil patterns)

reference investigation