Tag Archives: Apple Maps

Rotten to the Core? Nah, iOS14 is Mostly Sweet

By Heather Mahalik

This blog is a cursory glance of iOS14, which was officially released this week. To keep with my previous trends, I focus on basic artifacts that impact almost every investigation and then dive in and take a bite from the apple. Think of this blog as the bobbing part. 😊 For this blog, I tested the tools that I have available to me personally. If you think something is missing – share it. If you are a vendor and think something is missing – share it with me and I will try it for myself. At this point in time, an encrypted iTunes backup seemed to be the most stable option. I know that vendors are releasing updates to support iOS14 shortly, so be patient. If you DO NOT encrypt the backup, you will NOT extract Calls, Apple Maps (some databases extracted but are empty), Safari, Health and probably a lot more!

Apple didn’t go of the beaten path to much for the primary artifacts. There are some strange things I noted and those will be shared. Since iOS13, best practices are to encrypt your backups! If you do not, you will not get all the databases needed for basic examinations.

For this blog, I acquired many ways to compare the differences. The ones in bold were the best acquisition.

Mac Acquisition Tests:

  • Backup on a Mac using Finder – Encrypted
  • Backup on a Mac using Finder – No encryption set
  • Backup on a Mac using Finder – Encryption set but DID NOT save the password to the keychain

The issue I found when backing up to a Mac and saving the encryption passcode to the keychain is that the Manifest.plist does not show the encryption flag and the tools do not request the passcode for parsing.

Manifest.plist comparison

Thus, you don’t get much of anything! I loaded all of these extractions into Cellebrite Physical Analyzer and Magnet AXIOM to verify and the keychain taking the passcode really limits us examiners so pay attention when using a Mac to create a backup and DO NOT let that box stay checked or your examination opportunities will be limited.

Backing up using a Mac

Windows Acquisition Tests:

I first attempted to use a previous version of iTunes and it didn’t even see my device running iOS14. I updated and all was good from that point forward.

  • Backup with iTunes – Encrypted
  • Backup with iTunes – No encryption set

There weren’t any oddities here other than the fact that as soon as I moved my backup from the MobileSync directory, iTunes claimed it was never backed up to this PC.

iTunes backup

And a backup a few mins later.

iTunes view after backup was moved from the MobileSync directory

Keep in mind, I did about 10 backups of this device because I kept adding data and then pulling it. It makes sense if you think about it, but I know that the device stores this information, so I was surprised to see iTunes simply relying on the backup directory for this information. Bottom line do not trust what iTunes states regarding backups on the summary screen because the truth lies within the iOS device.

For this test, I created new Contacts, placed Calls (both FaceTime and regular), texted (used the new “reply to a message” feature, took photos, searched for directions (and even had to do extra drives to get really test Maps), created a note, and browsed using Safari. These are the key items that everyone should examine for most cases, so I tend to start there. My colleagues and I are going to dive into the harder artifacts (KnowledgeC, locations, Health, etc.) and will do a separate blog on that.

The common artifacts:

Contacts: var/mobile/Library/AddressBook/AddressBook.sqlitedb – parsed by commercial tools

Calls: var/mobile/Library/CallHistoryDB/CallHistory.storedata – – parsed by commercial tools

PA Parsed Call Logs
PA Call logs with Source File

SMS: var/mobile/Library/SMS/sms.db – mostly parsed by commercial tools. See below for more details.

Safari: var/mobile/Library/Safari/History.db – mostly parsed by commercial tools. Note: Make sure your tool parses history, Google searches and Tab history.

AXIOM Tabbed Sessions
PA Safari History
PA Safari History – Source

Photos: var/mobile/Media/DCIM/100APPLE/ – parsed by commercial tools – However, there is a new table. Take a look below.

PA Photos

The table ZGENERICASSET that we have relied upon for so long is now ZASSET. Thanks to Jared Barnhart for finding this first. 🙂 And thanks to Scott Koenig for this query to parse it all. https://drive.google.com/drive/folders/1v6T6OqD8eyL1xwHXDMePaXxEZ3IZssp2

Notes: var/mobile/Containers/Shared/AppGroup/group.com.apple.notes/NoteStore.sqlite – parsed by commercial tools

**NEW File and Path***

Maps: var/mobile/Containers/Shared/AppGroup/group.com.apple.Maps/Maps/MapsSync_0.0.1


Apple Maps is the biggest change and to be honest, I thought I lost them again. If you aren’t sure what I am referring to, please read my previous blogs on Apple Maps. I have spent countless hours trying to find locations and you know what’s sad – I don’t even like Apple Maps. I prefer Waze. However, as a researcher, I must test all things. Let’s take a historical look at Apple Maps.

History. mapsdata – was the primary storage file for Maps until iOS 8

GeoHistory.mapsdata – the primary storage file for Maps from iOS 8 – iOS 11(ish). Went to cloud storage for iOS12 and then came back and stored here again for iOS13 – again refer to my previous blogs –How the Grinch stole Apple Maps artifacts… or did he just hide them? and First the Grinch and now the Easter Bunny! Where is Apple Maps hiding?

MapsSync_0.0.1 – the new file on the block – this is the primary file storing iOS 14 Maps data.

MapsSync_0.0.1 seems to only keep the last 15 history items. This is about 3-5 directions/lookups/searches based upon my testing. I dumped my device several times to confirm this. Let’s look.

Here is how it looked when I first extracted the data.

Apple Maps Data – DB Browser for SQLite

And just two Apple Maps searches later, it looked like this.

Apple Maps Data – DB Browser for SQLite

The bad news is that none of the tools I tested parse this file. The good news? Here is a query for you. Use your tool of choice to parse it. Keep in mind the “Time Created” below will reflect the time The device was updated to iOS14. Thus, this is NOT when that search occurred. To get that information, you need to examine GeoHistory.Mapsdata – the protobuf that stores this historical information.

ZHISTORYITEM.z_pk AS "Item Number",
when ZHISTORYITEM.z_ent = 14 then "coordinates of search"
when ZHISTORYITEM.z_ent = 16 then "location search"
when ZHISTORYITEM.z_ent = 12 then "navigation journey"
end AS "Type",
datetime(ZHISTORYITEM.ZCREATETIME+978307200,'UNIXEPOCH','localtime') AS "Time Created",
datetime(ZHISTORYITEM.ZMODIFICATIONTIME+978307200,'UNIXEPOCH','localtime') AS "Time Modified",

When examining the output, I was perplexed by the lack of results, which is when I realized that number of 15 stayed constant no matter what I searched for. It appears to be transactional in nature. Also, I went through all the coordinates and realized that the Type “coordinates of search” will not show as “navigation journey” unless selected.  For example, I searched for UMMC (no longer part of this database in my final dump, but the “coordinates of search” persist. The one set of coordinates is for the University Medical Center in Maryland (the one I navigated to) and the other a University Medical Center in Mississippi, which I never selected.

The good news – GeoHistory.mapsdata has the historical searches made in iOS13! If you do not see these in the MapsSync_0.0.1 database, go back and examine the protobuf for locations of interest. Below we can see the searches for UMMC, which are no longer in MapsSync_0.0.1 exist here.

Protobuf View in PA

What about those BLOBS stored in “zrouterequeststorage” you ask? Well, they store your starting location and your final destination. Pretty important, right? This is the literal journey.

BLOBS embedded in Apple Maps
BLOBS embedded in Apple Maps

These BLOBs are protobufs and a special shout out to Jon Baumann who stayed up late to fix his script for me. You can find his script here to parse these nasty buggers. https://github.com/threeplanetssoftware/sqlite_miner/tree/protobuf

Here is some sample output of my file. Note that it isn’t perfect (he worked on this in minutes) and may have false positives.

SQlLte-Miner-.pl output

Protoc can be used to look at the protobufs. And there are many scripts to help. One recommended by the Cheeky4n6Monkey is https://github.com/mildsunrise/protobuf-inspector.

Another consideration is going back into your tool and searching around. Cellebrite Physical Analyzer has a built in button to search in binary blobs. I did two searches here. One for my home street (not sharing that here) and one for a location I navigated to/searched for (chantilly).

Searching Binary BLOBS in PA

Another option is to convert the BLOBS from the query provided above to Hex so you see the output and are alerted. Again, this is a preference thing. Thanks Jared Barnhardt for the suggestion here!

ZHISTORYITEM.z_pk AS "Item Number",
when ZHISTORYITEM.z_ent = 14 then "coordinates of search"
when ZHISTORYITEM.z_ent = 16 then "location search"
when ZHISTORYITEM.z_ent = 12 then "navigation journey"
end AS "Type",
datetime(ZHISTORYITEM.ZCREATETIME+978307200,'UNIXEPOCH','localtime') AS "Time Created",
datetime(ZHISTORYITEM.ZMODIFICATIONTIME+978307200,'UNIXEPOCH','localtime') AS "Time Modified",
BLOB output as HEX – DB Browser for SQLite

I plan to keep digging into Apple Maps and will blog more as I find more information. For now, use this query if you dump a device running iOS14. Don’t be afraid to make it your own too! You will see many columns that I could not get to populate with valuable information.

For iMessage, you can now reply to a single portion of the conversation. The below screenshot shows you how this appears on the device.

Reply To Message

The database has two new columns called “thread_originator_guid” and “thread_originator_part” which appear to be what the tools are not yet parsing and is what alerts you to the message the reply was to. I have yet to determine what the “thread_originator_part” means.

SMS Reply To – DB Browser for SQLite
SMS Reply To – DB Browser for SQLite

Refer to the screenshot from the phone to put this all together. Until the tools catch up, here is a query that will get you part of the way. It’s not perfect, and I plan to try to merge them. Maybe one of my friends will help write a script for it (Calling Brigs, Ian and Cheeky4n6Monkey!). The query below has been updated for iOS14.

SELECT message.rowid,
case when LENGTH(chat_message_join.message_date)=18 then
datetime(chat_message_join.message_date/1000000000 + 978307200,'unixepoch','localtime')
when LENGTH(chat_message_join.message_date)=9 then
datetime(chat_message_join.message_date + 978307200,'unixepoch','localtime')
else 'NA'
END as "Message Date",
case when LENGTH(message.date_read)=18 then
datetime(message.date_read/1000000000 + 978307200,'unixepoch','localtime')
when LENGTH(message.date_read)=9 then
else 'NA'
END as "Date Read",
case when message.is_read=1
then 'Incoming'
when message.is_read=0
then 'Outgoing'
end as "Message Direction",
case when LENGTH(chat.last_read_message_timestamp)=18 then
when LENGTH(chat.last_read_message_timestamp)=9 then
datetime(chat.last_read_message_timestamp + 978307200,'unixepoch','localtime')
else 'NA'
END as "Last Read",
datetime(attachment.created_date+978307200,'unixepoch','localtime') AS "Attachment Date",
FROM message
left join chat_message_join on chat_message_join.message_id=message.ROWID
left join chat on chat.ROWID=chat_message_join.chat_id
left join attachment on attachment.ROWID=chat_message_join.chat_id
order by message.date_read desc;

Bottom line – Apple isn’t rotten. The days I spend researching and blogging are for my family until I press submit! 😊 Please research and share! Validation is key. We all need to do it! Create test data and try it for yourself. If you find bugs, report them to vendors. If you find gaps, report them, and find someone who can build a tool to parse it. It’s our job in DFIR to educate and share. Happy hunting on iOS 14! And you may see this image coming to you publicly soon!

First the Grinch and now the Easter Bunny! Where is Apple Maps hiding?


Why is it that I stumble upon a smartphone artifact that drives me bonkers around holidays??? I am in the midst of the FOR585 course updates and I go through everything in great detail during this time. I expect to see major changes in a full version update (aka iOS 10 to iOS 11 or Android 7 to Android 8) but seeing artifacts hop around (bunny reference there just in case you missed it) in the minor steps of updates (iOS 11.2.5 to iOS 11.2.6) is not something I like. I don’t like it because it makes even more work for me and for you!

As I am writing this, I am updating to iOS 11.3. I hope to have that added into this blog by the end. For now, my research is based on what I noticed when examining 11.2.5 and 11.2.6 in great detail. The Apple Maps is different, inconsistent and just doesn’t make sense. All of the Apple Maps uncertainty started in the minor updates of iOS 10.  I wrote a blog about it titled “How the Grinch Stole Apple Maps.” Read it for all of the details. I am going to summarize what the “Grinch” did.

To do my Grinch blog, I tested the following devices. (Again, a special thanks to my trusting friends and family for granting me access to their devices.)

  • iPhone 6s with a fresh install of 10.0.2
  • iPhone 7 updated from previous iOS versions running 10.0.2
  • iPhone 6s updated from previous iOS versions running 10.0.2
  • iPhone 7 updated from previous iOS versions running 10.2
  • iPhone 6s with a fresh install of 9.3 – jailbroken
  • iPhone 6s+ with a fresh install of 10.1.1
  • iPhone 6 updated from previous iOS versions running 10.1.1
  • iPhone 6s+ updated from previous iOS versions running 10.2
  • iPhone 7 updated from previous iOS versions running 10.1.1

I was attempting to find where Apple Maps was storing my search requests and directions since I couldn’t find them in GeoHistory.mapsdata or the older history.mapsdata.

For each of these devices, I opened Apple Maps and searched for items I could easily identify:

  • Radio City Music Hall, NYC
  • Malvern Buttery

So, when I was just updating my slides, I decided to take a look at my iPhone again (running 11.2.6) and verify the file paths.  I was SHOCKED to see that the GeoHistory.mapsdata was gone.  Literally, not even there. Did the Easter Bunny hide it or did the Grinch steal it completely?

Before, he appeared to be snatching the new data and being evil and allowing you to see the old stuff.  But where the heck are my searches and where did my file go? I honestly even considered that Apple reverted back the history.mapsdata because that file is still present, but that isn’t the case.

What’s a girl to do next? PANIC and then I phoned a few friends and asked them to try to find GeoHistory.mapsdata on their devices (thank you Lee and Mattia for testing with me)  and ultimately went back to my first blog post on it and read it again. Sometimes revisiting your old work can spark something in your mind. One major thing that I took away from reading that blog post again is this:

“*Note: Some of the devices below are syncing with iCloud and some are not. I wanted to be thorough and make sure that the Grinch didn’t take the file to the cloud…”

Could it be that the Easter Bunny did what the Grinch had envisioned and hid the GeoHistory.mapsdata in iCloud? We know the bunny is tricky and this year Easter falls on April fools, so we should expect anything. Here is what I tested and found (so far) during my hunt for this file.

The following test devices were used:

  • iPhone 6s with a fresh install of 11.2.5
  • iPhone 7 updated from previous iOS versions and currently running iOS 11.2.6
  • iPhone X updated from previous iOS versions and currently running 11.2.6 (being updated to 11.3 as I type)
  • iPhone 7 with a fresh install of 11.2.5
  • Many backups from all of my test devices

My iPhone is the iPhone X (listed above and I know I searched for locations in Dallas, Panama and in Paris  on recent trips. I rarely use Apple Maps (probably because the Grinch killed it for me) so I rely on it only when Google Maps and Waze let me down.  The iPhone 6s is a test device that I have searched for directions many times in Apple Maps. It makes testing so much easier when you know what data you expect to find. Here is what Apple Maps looks like on my iPhone X.

Once all data was populated, I conducted both iTunes/iCloud backups and Cellebrite Physical Analyzer File System dumps (Methods 1 and 2) to quickly acquire the data. I even tried looking at my attached device live in BlackLight and iBackupBot. I tried parsing the data dumps in BlackLight, Oxygen Detective, Magnet AXIOM, Cellebrite Physical Analyzer and manual examination to ensure I wasn’t overlooking something. I pulled my own iCloud data with Elcomsoft and searched for the file in those backups and still didn’t find exactly what I was looking for – wait for it…

When I manually examined the file system of the backups and data dumps, I started to see major inconsistencies just like I did in iOS 10. The GeoHistory.mapsdata file was sometimes present and sometimes not. The history.mapsdata file was there no matter what. History.mapsdata, contains legacy searches in Apple Maps, it does not contain any data since iOS 8. If you don’t see this file, chances are the user didn’t have a device running iOS 7 that they updated from (aka, they either started fresh with iOS 8 or a newer iOS version).

Based upon my experience with iOS device forensics, it seems that when Apple no longer uses a file, the file persists and is no longer updated. When Apple wants to protect a file, they encrypt it and/or make it inaccessible without a full physical image, which is currently not possible on new devices without a jailbreak.

What I found is that some of the devices running versions ranging from iOS 10.0.2 – 11.2.5 had GeoHistory.mapsdata with older Apple Maps content. None of the devices running iOS 11.2.6 have GeoHistory.mapsdata. This is insanity. Again, I believe if Apple doesn’t want you to see something they encrypt, restrict or hide it.

I promised to keep hunting for you and what better time to hunt than Easter. So, where the heck is this darn file hidden? Well, the Easter Bunny got crafty and hid it in the cloud. Before doing what is listed below, you need to make sure you have legal authority or written consent from the user to access their cloud data. You also need their credentials.

I used Elcomsoft Phone Breaker to first pull iCloud, which I previously mentioned, and didn’t find anything further than what iTunes had presented. Then I pulled the “Synced data” from iCloud. (Thanks Mattia for providing me your results as well!)

I then entered my iCloud credentials and my PIN for 2FA (yes, this is required the first time you use the tool and will alert the user – user caution here).

From here, I was presented with a list of options to pull from synced iCloud data. Since this is all about Apple Maps, that is all I selected. If you want to learn about the others, I suggest you sign up for FOR585 Advanced Smartphone Forensics (shameless plug- for585.com/course).

What I found when I opened this file blew my mind. I expected this of Apple, so I shouldn’t be shocked, but I couldn’t believe that the crazy Easter Bunny decided to hide my Apple Maps in iCloud. I am just thrilled that I can access some, if not all of the history. Side note: the user must sync to iCloud or you will not find it here. 🙁

To examine the results, Elcomsoft creates an AppleMaps.db file that I examined manually and a file that can be opened in Elcomsoft Phone Viewer. Let’s start with Phone Viewer, because let’s be honest, most people like for a tool to show them the results. (Click on the image to see the graphic in a zoomed in format.)

In Elcomsoft Phone Viewer, I started examining searches and saw everything from Paris and Panama that I searched for in addition to other historical searches. This is great news, but let’s keep going because these could just be generic searches where the user didn’t request directions.

Next I looked at explored places and found other searches that I performed on my iOS device, but not necessarily in Apple Maps. However, when you search for something on an iOS device, the device assumes you may ask for directions and caches that info.

Finally, we find the directions the user searched for. Best part, we get to see how the requested the directions (walk, drive, transit, fly, etc.) Pretty cool stuff.

Thanks to Mattia, I can even show just how far back some of these artifacts span… Again, I am not a huge fan of Apple Maps, so seeing dates from 2015 in Mattia’s data is pretty sweet. Below we can see searches from 2015.

Mattia also had directions from 2015.

The databases can be used as well. This is really helpful if you like to write SQL queries to parse these artifacts. This database is created by Elcomsoft and isn’t something you are going to find on the device. It’s strictly iCloud based. The table provided is called AppleMaps.db. There are several tables provided. You need to determine what is relevant to your investigation, but I recommend during a cursory glance of all of them.

I wrote a simple query to parse the DirectionsSearch table. Please do not copy and paste from this blog. WordPress does some funky formatting the SQLite doesn’t like. Grab it here: AppleMapsQuery.txt

datetime(timestamp,’UNIXEPOCH’,’localtime’) AS “Timestamp”,
transport_type AS “0-Drive, 1=transit, 2=walk”,
start_point_is_current_location AS “Start Point:1=Current Location”
from DirectionsSearches
order by timestamp desc

This query found all of the directions I searched for including the pesky Malvern Buttery and Radio City Music Hall, which I was searching for in my Grinch post.

Now I am wondering if the Grinch is in cahoots with the Easter Bunny and it was hidden here all along. :/ This is why we keep testing and digging. This is why we need more than one tool. This is why we have to get out of our own way and start trying to new methods and tools. I also plan to keep testing the cloud capabilities of the other tools to include in my FOR585 update.

Just as I was done writing, my update to iOS 11.3 completed. I did a simple Apple Maps search for directions to Jim’s in Philadelphia. (Another thanks to Lee for introducing me to Jim’s in 2003! Here, you will get the world’s best cheesesteak.)

I forced my device to backup to iCloud and repeated all of the steps above. Everything appears to be the same and Elcomsoft was able to parse my search from the Synced data. And unfortunately, the GeoHistory.mapsdata is still missing from the file system image.

All of this was done with the demo version of Elcomsoft Phone Viewer. If you want to try a tool, ask the vendor. Most will give you at least a free demo. Not one tool can do it all, so get out there and help me hunt! Oh, and Happy Easter.

Other things you may want:

Files of interest on the device (if the plist appears to be Base64 encoded use Oxygen Detective’s Apple plist Viewer):

Note: For graphics on what these files look like and the paths for each data dump, refer to the Grinch blog.