intimate partner violence — tech trail — methodology
intimate partner violence tech abuse is not always a hidden spy app. it is shared Google accounts showing real-time location (ios location history), AirTag-class bluetooth pairings the survivor did not know were tracking them, home Wi-Fi passwords stored under coercion, and iOS significant locations that contradict what someone told a judge. audience: DV advocates, shelter staff, trusted friends helping a survivor document tech-facilitated abuse for protective orders — not corporate IR. your job is to preserve location and connectivity artifacts locally, build a timeline that holds up for advocate review, and never tip the abuser that evidence is being collected. victim safety comes before documentation.
safety and advocate referral — before any of the path
if someone is in immediate danger, start with crisis support — not forensic exports. this guide documents evidence preservation for advocates and survivors; it is not counseling, advocacy, or legal advice. do not interpret tool output as proof admissible in court without qualified review. US crisis lines: 988 (suicide & crisis lifeline) · 1-800-799-7233 (national DV hotline). connect survivors to a local DV advocate before pulling backups — they help decide whether preservation, account reset, or safety relocation comes first. this case type focuses on location and connectivity trails; covert phone monitoring is covered separately under stalkerware sweep.
- is the survivor physically safe right now? location artifacts can prove the abuser knew where they were — treat that as safety planning input, not a puzzle to solve first.
- will requesting a Google Takeout, iCloud backup, or Wi-Fi export notify the abuser? shared Apple/Google accounts, family sharing, and "new login" emails can alert a controlling partner.
- does the survivor want a forensic record for a protective order, police report, divorce discovery, or simply to understand what was tracked? each path has different risk — an advocate should set the order, not a well-meaning friend with a browser tool.
- preserve without confronting. do not tell the abuser you found their SmartTag pairing, do not change passwords from a device they monitor, do not threaten legal action until safety planning says it is safe.
- document consent if you are not the survivor — verbal permission is not enough for advocates and counsel. note who pulled what export, when, from which account, and on whose device.
- work on a workstation and accounts the abuser does not control. if the survivor must keep using a shared iCloud or Google login, assume timeline views and Find My alerts are visible to the partner.
- if the survivor needs to disappear: new number, new accounts, and leaving the phone behind may be correct even when it destroys evidence. respect that call over completing the path.
what evidence exists and how fast it dies
| artifact | volatility | time to loss |
|---|---|---|
| iOS consolidated.db (learned locations + visits) | persistent in backup | factory reset · location services off · rolling retention |
| iOS Cache.sqlite (Significant / Frequent Locations) | persistent in backup | up to ~1 year rolling · gone on reset |
| android location_history table | persistent on device | cleared by account removal or factory reset |
| Google Takeout Records.json / timeline exports | persistent if exported | abuser with shared account can delete visits anytime |
| bluetooth pairing plists / BluetoothConfig.xml | persistent until unpaired | survives reboot · unpair + forget removes history |
| saved Wi-Fi networks (PSK, hotspot joins) | persistent | "forget network" or reset wipes entries |
| live Google / Apple location sharing UI | volatile | disabled in seconds — screenshot only if safe |
| shelter address exposure via saved Wi-Fi | persistent risk | reconnecting to shelter guest SSID after leaving may re-leak location to abuser-controlled accounts |
| advocate intake notes + consent forms | persistent on paper/system | not in phone exports — capture separately |
the first 10 minutes
- confirm the survivor is safe and wants evidence preserved — if not, stop here and connect them to an advocate (988 · 1-800-799-7233).
- record UTC timestamps for shelter intake, alleged separation date, and any court dates tied to location claims.
- list accounts the abuser may share: Google, Apple ID, carrier family plan, Find My, Life360, tile apps.
- if safe: export iOS backup or pull consolidated.db + Cache.sqlite from an encrypted backup on a machine the abuser does not access.
- request Google Takeout (Location History / Records.json) from an account the abuser does not monitor — or save an existing export before disabling sharing.
- pull android location_history.db if the survivor uses android — many cases span both platforms over time.
- export bluetooth pairing files and Wi-Fi network lists from both phones if dual-device — hash every file sha-256 before editing.
- do not remove AirTags, change passwords, or disable location sharing until the advocate says it is safe — sudden changes can escalate abuse.
- do not confront the abuser with coordinates, tracker names, or "we found your SmartTag."
- begin the path below on copies — not on live shared accounts while the partner still has access.
the path
IPV tech-trail evidence arrives as iOS/Android location databases, Google Takeout fragments, and connectivity configs — not a single disk image. run steps 1–2 on iOS consolidated data; steps 3–4 when android or shared Google timeline is in scope; steps 5–6 for tracker and Wi-Fi coercion; steps 7–8 to summarize Routined clusters for advocate and counsel review.
1. ios location history
consolidated.db from iOS backup (Routined / learned locations). surfaces labeled places — Safe Harbor DV Shelter, K. Walsh residence, Brooks workplace — plus visit entry/exit timestamps in Apple epoch.why first: location abuse in IPV often starts with what the phone already learned, not a stalkerware APK. consolidated.db is the baseline timeline before you drill into Routined clusters or shared Google accounts.
2. ios location history deep reconstructor
same consolidated.db plus visit tables. rebuilds multi-day movement chains, dwell time at partner residence vs shelter, and gaps where the survivor said they were somewhere else — Brooks fixture includes a shelter visit followed by a return to Walsh residence.why second: flat coordinate rows hide the story. reconstruction shows whether movement contradicts an alibi or a protective-order narrative the abuser later challenged.
3. android gps location history forensic extractor
android fused/GPS location_history table export. gps vs fused vs network providers, accuracy rings, and timestamps at shelter, partner residence, and workplace — many survivors carry both platforms or switch mid-case.why third: android location history lives in a different schema than iOS consolidated.db. if the abuser had account access to both, you need both surfaces before correlating.
4. android google timeline artifact forensic extractor
Google Takeout Records.json fragment (latitudeE7, timestampMs, source). the Brooks pack includes shelter GPS points, Walsh-residence WIFI/CELL hits, and a post-shelter return the partner could see via shared Google location.why fourth: shared Google timeline is one of the most common IPV tracking vectors — no install required. Takeout preserves what the map UI showed the abuser even after the survivor turns location off.
5. bluetooth pairing history forensic extractor
iOS bluetooth.plist and android BluetoothConfig.xml. paired AirTag-class devices — Partner TrackTag, Walsh SmartTag — with link keys present, alongside benign car-audio pairings to separate tracker from everyday bluetooth.why fifth: physical trackers pair quietly. bluetooth history proves a tag was bonded to the survivor's phone, which supports "he knew where I was" even when GPS exports look incomplete.
6. wifi connection history forensic extractor
iOS com.apple.wifi.plist NetworkList and android WifiConfigStore. coercive home-network credentials (BrooksHome-5G with stored WPA key), shelter guest SSID joins, and Walsh-iPhone personal hotspot with last-joined timestamps.why sixth: abusers force Wi-Fi password sharing for network-level monitoring. saved PSKs and partner-hotspot joins are persistent even when location services are disabled — and they can re-expose shelter networks if the survivor reuses the phone.
7. ios significant locations forensic extractor
Cache.sqlite (Significant Locations / Routined shape). home, partner residence, shelter, and low-confidence one-off stops with visit counts and confidence scores — Brooks fixture labels Safe Harbor DV Shelter and K. Walsh residence explicitly.why seventh: significant locations summarize months of routine in clusters the survivor may not know exist. advocates use them to show the phone "learned" shelter and partner addresses before testimony about where the survivor actually was.
8. ios frequent locations artifact analyzer
Routined visit rows with arrival/departure, visit count, and distance-from-home. correlates repeat returns to partner residence after shelter intake — the Brooks scenario includes a post-shelter Walsh visit that contradicts a "I never went back" statement.why last: frequent-location analytics turn clusters into repeat-behavior evidence. run after significant locations so you compare visit cadence, not just labeled pins.
common false leads
- no stalkerware APK means no tracking — shared Google location, Find My, and bluetooth tags require no install. absence of malware is not absence of surveillance.
- survivor visited partner address once so they wanted to go back — IPV patterns include coerced returns, property retrieval, and child exchange. frequency and timing matter, not single pins.
- shelter Wi-Fi join proves nothing — it proves the phone was at the shelter network, which supports protective-order timelines when the abuser claims the survivor never left the shared home.
- bluetooth car audio pairing equals a tracker — filter ClassOfDevice and names like TrackTag / SmartTag before treating every pairing as abuse.
- google timeline deletion was the survivor cleaning up — if the abuser had account access, they may have deleted visits to hide their own monitoring. compare Takeout timestamps to advocate intake dates.
- run stalkerware sweep first — stalkerware-sweep covers covert apps and MDM profiles; ipv-tech covers location history, shared accounts, trackers, and coercive Wi-Fi. run both only if both threat models apply.
- tool output is courtroom-ready — browser tools produce advocate-grade timelines, not legal conclusions. qualified counsel and forensic examiners validate before filing.
what we can tell you, what we can't
we can tell you:
- iOS learned locations and visit entry/exit from consolidated.db
- reconstructed movement chains and dwell time across labeled places
- android GPS/fused/network location rows with accuracy metadata
- Google Takeout Records.json points with source (GPS, WIFI, CELL)
- bluetooth pairings including AirTag-class devices with link keys present
- saved Wi-Fi SSIDs, stored credentials, and partner personal-hotspot joins
- iOS Significant Locations clusters with visit counts and confidence
- frequent-location visit cadence and distance-from-home patterns
we can't tell you:
- whether a protective order will be granted — that is court and advocate territory, not tooling
- prove intent — coordinates show where the phone was, not why someone traveled
- recover visits deleted before export if no backup exists — export first, analyze second
- access the abuser's accounts or devices — these tools analyze exports the survivor or LE legally holds
- decide whether the survivor should report to police — advocate safety planning comes first
- provide legal advice on admissibility, chain of custody, or expert testimony requirements
- monitor live location in real time — preserve artifacts, analyze offline in the browser
handing it off
- DV advocate (often first): safety plan, whether to preserve or reset accounts, whether evidence sharing is safe now, shelter confidentiality implications of location exports.
- survivor's counsel: sha-256 hashes of each export, timeline PDFs, bluetooth/Wi-Fi artifacts, limitations memo — for protective-order or divorce discovery packages.
- law enforcement (with advocate guidance): only when the survivor chooses to report — preserved Takeout, backup extracts, tracker pairing names/MACs, UTC timeline. local PD for immediate threats; IC3 for interstate cyber-enabled stalking when appropriate.
- qualified mobile examiner: if the case pivots to full-device compromise, MDM profiles, or stalkerware overlap — backup acquisition beyond location tables alone.
- shelter tech safety: review saved Wi-Fi lists for shelter SSIDs before the survivor reconnects phones to guest networks that could re-expose location to abuser-controlled accounts.
further reading
reference investigation
synthetic fixture brooks-ipv-tech: S. Brooks scenario (case BRV-IPV-2026-0612) — partner K. Walsh tracking via shared Google timeline, AirTag-class bluetooth pairings (Partner TrackTag, Walsh SmartTag), coercive Wi-Fi credential storage, and iOS significant locations contradicting shelter alibi. seed brooks-ipv-tech:v1. compare output via npm run check:flagship.
fixture download: evidence zip · proof page: /forensics/proof/brooks-ipv-tech · case playbook: case type tools