MapsSync_0.0.1: Testing the Device Location Inside Apple Maps Route Requests

Research and testing by Michael Edwards, Digital Forensics Examiner, Richland County Sheriff's Department
Test device: iPhone 16 Pro, iOS 18.3

MapsSync_0.0.1 stores Apple Maps search and route history on iOS. Most of it tells you what a user looked up, not where the phone was. One field is different. When a user requests a route, MapsSync_0.0.1 can record the device's own position, a timestamp and an accuracy value inside a protobuf BLOB.

We tested that BLOB against a known timeline and against Cache.sqlite. The device location matched to the last decimal place.

What was already known

This test builds on published work. Cellebrite's 2025 location booklet lists three points about the ZHISTORYITEM table:

• ZROUTEREQUESTSTORAGE is a protobuf BLOB with the start and end of a requested route.
• The start is the device's real location when node 1/0/3/100 holds a value of 1.
• If ZROUTEREQUESTSTORAGE is empty, treat the row as a search and not a visit.

What was missing was a node-by-node map of the protobuf and a check of its values against a second source. That's what this test adds.

One scope note: MapsSync_0.0.1 belongs to the native Apple Maps app. It holds nothing from Google Maps, Waze or other third-party apps.

Test setup

Actions on the device

Times are local (UTC-4) and read off a clock by hand, so allow 1 to 2 seconds of error.

What MapsSync_0.0.1 recorded

Seventeen actions produced four rows in ZHISTORYITEM.

Timestamps

ZCREATETIME, ZMODIFICATIONTIME and ZMAPITEMLASTREFRESHED are Mac Absolute timestamps stored in UTC. Each one landed within a few seconds of the logged action.

Row 2 is the useful one. ZCREATETIME lines up with selecting the destination. ZMODIFICATIONTIME lines up with starting navigation, one second off the logged time. In row 4 the two values are identical, and that route was requested but never started. Two records is a thin basis for a rule, so treat "modification time equals navigation start" as a lead to test, not a finding.

This query gives you the same view with UTC output:

SELECT
          Z_PK,
          datetime(ZCREATETIME + 978307200, 'unixepoch') AS create_utc,
          datetime(ZMODIFICATIONTIME + 978307200, 'unixepoch') AS modified_utc,
          datetime(ZMAPITEMLASTREFRESHED + 978307200, 'unixepoch') AS mapitem_refreshed_utc,
          ZLATITUDE1,
          ZLONGITUDE1,
          ZLOCATIONDISPLAY,
          ZQUERY,
          ZROUTEREQUESTSTORAGE
      FROM ZHISTORYITEM
      ORDER BY ZCREATETIME;

Inside the ZROUTEREQUESTSTORAGE protobuf

The BLOB from row 2 was copied out and opened in Mushy. The top level has four nodes. Everything of interest sits under node 1, which splits into two branches:

• 1, 0 is the route start, which here was the device location.
• 1, 1 is the destination.

Device location nodes

Some of these values repeat elsewhere in the protobuf. The paths above are the ones we tested.

Destination nodes

The destination branch carries coordinates only. No timestamp, no accuracy. In both BLOBs the coordinates matched the destination selected during the test.

Validating against Cache.sqlite

Cache.sqlite, and its ZRTCLLOCATIONMO table in particular, is a well-tested source of iOS device location. We looked for a record with the same timestamp as the protobuf and found one.

Every digit matches. We repeated the check with row 4, the only other row with a BLOB. It matched its Cache.sqlite record exactly too.

A match to 13 decimal places isn't two sensors agreeing. It points to Maps writing the same location fix that routined cached. That matters for two reasons. The MapsSync value is as good as the Cache.sqlite value. And Cache.sqlite ages out quickly, so a MapsSync_0.0.1 record may still give you a validated device position after the Cache.sqlite record is gone. How long MapsSync rows persist was not part of this test.

The timestamp gap you need to know about

The protobuf timestamp did not match either row timestamp:

The fix is 8 seconds older than the route request. Maps appears to use the most recent fix it already has and does not take a new one at the moment of the request. In this test the phone was stationary, so the gap changed nothing. On a moving device, or with a longer gap, the difference could matter.

Report the protobuf timestamp as the time of the location. Report ZCREATETIME as the time of the user action. Don't merge them.

What MapsSync_0.0.1 did not record

• Typing without selecting. The 1701 Main St entry was typed but never selected or submitted. It left no row. More testing is needed before you call that a rule.
• Travel. Navigation ran for 15 seconds and was ended. No record shows the device moved along the route or arrived. A route request is intent, not presence at the destination.
• A BLOB for every selected address. Rows 3 and 4 came from the same kind of action: search an address, select it, clear it. Row 4 got a BLOB. Row 3 did not. We don't know why. Row 3 stored only the searched place's coordinates in ZLATITUDE1 and ZLONGITUDE1.
• Search text for address searches. ZQUERY held "Chick-fil-A" for the business search. It was NULL for the address searches. It may hold business or place names only. That needs more testing.

How to use this in casework

1. Query ZHISTORYITEM and separate rows with a ZROUTEREQUESTSTORAGE BLOB from rows without one.
2. Treat rows without a BLOB as searches. ZLATITUDE1 and ZLONGITUDE1 are the searched place, not the phone.
3. For rows with a BLOB, decode the protobuf. Pull the device location from 1, 0, 9 and the destination from 1, 1, 9.
4. Check node 1/0/3/100 for a value of 1 before you call the start point a device location. A user can set a route start that isn't their current position.
5. If Cache.sqlite still covers the time frame, find the matching ZRTCLLOCATIONMO record and document the match.
6. Report the location with its own timestamp and horizontal accuracy. Report the row timestamps as user activity.

Bottom line

When ZROUTEREQUESTSTORAGE is populated, MapsSync_0.0.1 gives you a device position, a time and an accuracy value that matched Cache.sqlite exactly in this test, plus destination coordinates that matched the route the user requested. It tells you where the phone was when the user asked for directions. It does not tell you the user went there.

Testing and original report by Michael Edwards, Digital Forensics Examiner, Richland County Sheriff's Department. Prior reference: Cellebrite, Location Booklet (2025).