Building on my previous blog about discovering new forensic evidence with file structure analysis, I decided to search a GreyKey acquisition for files with the “latitude” key in their structure.

Unlike an iOS backup directory, a GreyKey contains a full file system acquisition and optionally memory dump. I was curious to see how many hits I would get for “latitude” is a file structure search. For the iPhone in my previous blog (a different iPhone!), my search returned 296 hits (2 bplist, 6 SQLite databases and 288 JPEG images). Scanning the list of files, one stood out.

NavdDoomConductor.storage

So I’ll be honest…I noticed the “NavdDoomConductor.storage” file located in the directory “./private/var/mobile/Library/Caches/com.apple.navd/” because of the name. Doom Conductor? This has to be interesting!

First off, I noticed that while the file extension was .storage it was in fact an Apple binary property list (bplist). I converted the ftree extracted “macb” times of out curiosity (to Central Time):

mtimeMs = 1533670725000.0. - Tuesday, August 7, 2018 2:38:45 PM GMT-05:00 DST
atimeMs = 1576609581010.87 - Tuesday, December 17, 2019 1:06:21 PM GMT-06:00
ctimeMs = 1571449632038.38 - Friday, October 18, 2019 8:47:12 PM GMT-05:00 DST
birthtimeMs = 1571444012981.75 - Friday, October 18, 2019 7:13:32 PM GMT-05:00 DST

Interestingly, the last modified time was related to the original modification on the iPhone while the other times were all related to the acquisition or access of the file post acquisition.

Google to the rescue?

Like any good forensic analyst, the first thing I did was Google the file name. :-) Annoyingly, IANA actually decided the world needed a .storage domain so both Chrome and Sarafi thought I was trying to access a website and just told me:

This site can’t be reached
navddoomconductor.storage’s server IP address could not be found.

I might just have to buy that domain. But I digress. I am a forensic analyst and will not be easily deterred! Unfortunately, no combo of Apple or iOS with navddoomconductor (with or without the .storage) panned out. I was able to read a little about Apple / iOS and navd but nothing close to a direct hit.

View plist with fplist

Whelp, time to cross our fingers and look at the file. I wrote a free forensic tool called fplist to display xml, plist and bplist files in json, csv or dot notation. Since this bplist list has 103 key value pairs, I’ve truncated the output:

$ fplist -f dot ./private/var/mobile/Library/Caches/com.apple.navd/NavdDoomConductor.storage
0.$objects.3 = NavdDoomStorageKeyNextWakeup
0.$objects.4 = NavdDoomStorageKeyMostRecentDoomWindow
0.$objects.5 = NavdDoomStorageKeyMostRecentDestinations
0.$objects.6 = NavdDoomStorageKeyMostRecentStart
0.$objects.7 = NavdDoomStorageKeyMostRecentLocation
0.$objects.8 = NavdDoomStorageKeyMostRecentTripWindow
0.$objects.9 = NavdDoomStorageKeyNumberOfUpdatesToDestinations
0.$objects.10 = NavdDoomStorageKeyNumberOfUpdatesToExitTime
0.$objects.11 = NavdDoomStorageKeyMostRecentModification
0.$objects.12 = NavdDoomStorageKeyCachedIncidents
0.$objects.13.NS.time = 555364125.83071
0.$objects.15.NS.duration = 14400
0.$objects.16.NS.time = 555350526.6666666
0.$objects.17.NS.time = 555364926.6666666
0.$objects.21.NS.time = 555363504.683838
0.$objects.22.kCLLocationCodingKeyHorizontalAccuracy = 65
0.$objects.22.kCLLocationCodingKeyType = 4
0.$objects.22.kCLLocationCodingKeyCoordinateLongitude = -77.07109066011417
0.$objects.22.kCLLocationCodingKeyFloor = 2147483647
0.$objects.22.kCLLocationCodingKeyCourse = -1
0.$objects.22.kCLLocationCodingKeyIntegrity = 50
0.$objects.22.kCLLocationCodingKeyMatchInfo.UID = 0
0.$objects.22.kCLLocationCodingKeySpeedAccuracy = -1
0.$objects.22.kCLLocationCodingKeyLifespan = 0
0.$objects.22.kCLLocationCodingKeyCoordinateLatitude = 38.894930170954964
0.$objects.22.kCLLocationCodingKeyVerticalAccuracy = 10
0.$objects.22.reserved = 1
0.$objects.22.kCLLocationCodingKeyAltitude = 42.16602325439453
0.$objects.22.kCLLocationCodingKeyTimestamp = 555363472.6609
0.$objects.24.NS.duration = 14400
0.$objects.25.NS.time = 555350526.6666666
0.$objects.26.NS.time = 555364926.6666666
0.$objects.29.NS.time = 555363525.863849

NavdDoomConductor.storage data analysis

Of course, the incredibly precise geolocation data stood out as well as the timestamps which appeared to be in [CFAbsoluteTime)[https://developer.apple.com/documentation/corefoundation/cfabsolutetime] which is commonly used on macOS an iOS apps.

Some of the other values stood out when taking into account this Reddit thread about navd. Basically, the theory is that navd and related processes are tracking travel time to your next appointment.

Since the GreyKey acquisition was on my phone, I was able to easily check my calendar and corroborate the geolocation data (changed) and timing.

HOWTO find latitude file structures in GreyKey acquisitions

An ftree scan of the GreyKey acquisition analyzed 348,861 files in just under 5 minutes, resulting in a 925M SQLite file.

I ran a few quick queries to search for file structure containing “latitude”:

$ sqlite3 iphone6-greykey.sqlite 'SELECT key, magic_base FROM ftree WHERE structure_data like "%latitude%"'
./System/Library/Frameworks/CoreLocation.framework/factory_minimum.db|SQLite 3.x database
./System/Library/Frameworks/CoreSpotlight.framework/schema.plist|Apple binary property list
./System/Library/PrivateFrameworks/AppSupport.framework/CityInfo.db|SQLite 3.x database
./System/Library/PrivateFrameworks/GeoServices.framework/altitude-541.xml|XML 1.0 document
./System/Library/PrivateFrameworks/WeatherUI.framework/00_day@2x-568m.caml|XML 1.0 document text
<Showing 5/505 results>

While it may be interesting to look at files on the iOS System partition with “latitude” references, I was only interested in user generated data so I limited the results to files under the root private directory:

⇒  sqlite3 iphone6-greykey.sqlite 'SELECT key, magic_base FROM ftree WHERE structure_data like "%latitude%" AND key LIKE "./private/%"'
./private/var/mobile/Library/Assistant/knowledgeC.db|SQLite 3.x database
./private/var/mobile/Library/Calendar/Notifications.db|SQLite 3.x database
./private/var/mobile/Library/Calendar/Calendar.sqlitedb|SQLite 3.x database
./private/var/mobile/Library/Passes/UserNotifications.archive|Apple binary property list
./private/var/mobile/Library/Passes/passes23.sqlite|SQLite 3.x database
<Showing 5/246 results>

OK, so these were more interesting but I wanted to get past a slew of JPEG files so I added one more filter:

sqlite3 iphone6-greykey.sqlite 'SELECT key, magic_base FROM ftree WHERE structure_data like "%latitude%" AND key LIKE "./private/%" AND magic_base <> "JPEG image data"'

which returned a manageable 73 files:

• 2 - XML 1.0 document
• 25 - SQLite 3.x database
• 46 - Apple binary property list

Free your data

I’ve never come across NavdDoomConductor.storage before and if you have, I’d love to hear from you. My suspicion is that commercial forensic tools do not surface this data. Perhaps it’s only on a few devices? Or maybe it’s quite common?

But bear in mind that’s 1 of 246…so there are 245 more files to take a look at. And that’s just randomly choosing “latitude” as a search terms for file structure analysis.

There’s lots of unsurfaced evidence out there folks…we just have to look a little smarter and harder.