Don’t lie – the song is already in your head. And if not, maybe it will be by the end. If you know me, titles/taglines, whatever you want to call them, are not my thing. But since testing iOS 13, I feel like I have backed that thing up a billion times! I dump, I examine and then realize something so I then add/delete that “thing” and repeat. Hence the name of this blog!

First things first, Apple didn’t appear to mess with us too much with this update with a few exceptions. First, encryption is everything! Some artifacts moved, while others are back again (pending settings on the device) , some can be controlled by the user and some just stayed the same. For the artifacts that moved – this is where you need to TEST YOUR TOOLS! Do not trust a blog post from a vendor (even one from me) – TRY IT FOR YOURSELF. Testing and validation is so important. There are so many bugs in tool releases and even false claims of support. Try it and then rely on it.

At the time of writing this, Physical Analyzer Method 1 and Method 2 were not supporting iOS 13. A little birdie tells me it will be released next week and I may have seen the beta. For the tools that did acquire, iTunes was used. When this is the case, I just use iTunes so I can control the environment. I like to encrypt my backups because I want Health, Keychain, Safari, Calls, Maps and Wallet, but I did conduct an unencrypted one for comparison and for parsing in one tool that will be discussed in a bit. Did you notice I said Safari, Maps, and Calls in an encrypted backup – yep – stay tuned.

And then I did it again with 13.1 because I didn’t get my blog out fast enough. 🙁 So this blog really covers both, not that I expected major changes in a tiny update.

The backup content looks similar to iOS 12. The major difference was the name of the backup, which is shown below. The top backup is from iOS 13 and the bottom from iOS 12, but the hardware is different.

Bottom line – until I test the full release of Method 1 and Method 2 in PA and fairly compare it, I recommend doing an encrypted iTunes backup and here is why.

Artifact Locations – The good stuff

For this post, I tested my usual suspects of artifacts. The ones that every device should have. Contacts, Call Logs, SMS, iMessage, Maps, Photos, and Safari. Here is what I found:

Artifacts with no path changes or anything drastic:

• Contacts–/var/mobile/Library/AddressBook/AddressBook.sqlitedb
• SMS/iMessage – /var/mobile/Library/SMS/sms.db

My buddy Jared, who also enjoys 90s hiphop pointed out something cool to me. Look at the message below. For anyone working distracted driving cases, this could be amazing for you. Look how the messages were sent! I’m in a rush to get this out, so I hope something like this will be a quick #TipTuesday on where it exists in the sms.db. Thanks Jared!

• Photos – /var/mobile/Media/PhotoData/Photos.sqlite (nothing major about the graphics jumped out upon initial review.

I have been asked so many questions about photos.sqlite lately that it will also be a blog of its own. There is so much goodness contained there! I plan to do another blog on deleted artifacts and how to recover, if possible, so watch out for that. For fun – this is a screenshot I took today to share with Paul all for the fun of testing. You never know what I may share, right Sarah? 😉 Honestly, if you cannot make fun of yourself – you need to relax.

Artifacts with minor changes:

• Calls–/var/mobile/Library/CallHistoryDB/CallHistory.storedata

 For Calls, the data remains the same, but you need an encrypted backup to get the data. Additionally, one file was added –CallHistoryTemp.Storedata. Mine had nothing of interest, but keep an eye on this bugger. It was put there for a reason, I just don’t know the exact one yet. I initially thought that AXIOM missed the calls, but realized I gave AXIOM and unencrypted backup so it could handle the file system view.

 It is worth noting that I deleted a call and could not find it in the free pages of CallHistory.storedata. I tried Physical Analyzer, Oxygen (the trash can feature), BlackLight, AXIOM, Forensic Browser for SQLite (Paul Sanderson) and Mari’ Degrazia’s awesome script https://github.com/mdegrazia/SQLite-Deleted-Records-Parser And guess what – I didn’t find the call. So more on that in another blog. I bet it’s in the cloud… 

• Health – (yes, I snuck this one in here because it is so valuable) /private/var/mobile/Health – examine the healthdb.sqlite and healthdb_secure.sqlite databases and take note of the new ones. I will write a complete Health blog soon. The tools may not be parsing everything, so refer to the presentation Sarah Edwards and I gave a few years ago: https://github.com/mac4n6/Presentations/blob/master/%23DFIRFIT%20or%20BUST/DFIRFIT.pdf

I do have to call out Oxygen Jet Engine here, who did a nice job on Health. Well done on connecting the device, OS version and locations. See a snippet below. More on this in my Health blog, where I plan to include Android health as well.

Apple switched the path up again – READ this part:

• Safari –/var/mobile/Library/Safari/History.db

IMPORTANT – the history.db is NO LONGER in com.apple.mobilesafari! See below. Here we have a visual of what is included in mobilesafari for an encrypted backup. The history.db. is no longer here. (NOTE: I would  examine all of these databases for relevant info. Mine didn’t have much, but I prefer Chrome.)

Take note here – at the time of testing, not all tools parsed Safari history! I assume they thought the database would remain in mobilesafari and guess what – that no longer exists. We are back to good ‘ole history.db in it’s first home in the Safari directory. Physical Analyzer, BlackLight and AXIOM parsed all of the searches I conducted in iOS 12 and 13 if an encrypted backup was obtained. NOTE – you will not get safari history in unencrypted backups anymore. You will simply get bookmarks and the dummy login for Safari, as shown below.

Additionally, it appears that Safari has moved all of the history data, which is uncommon. This history included much more data than that of iOS 13 and what is show below is history from May 2019 to present. 🙂 Makes it easier on us. Thank you Paul for sharing yours – again, I use Chrome. 

For the tools that didn’t parse Safari history, the database was there and the searches were as well. So they just need to catch up. I will explain which tools missed the artifacts at the end of this blog.

Something else worth noting is that it seems like Safari wants you to go into Private Browsing when you launch it. If this happens, you won’t find anything in history.db. Verify the setting on the iPhone. The user may not even realize it’s happening, which is what occurred while Paul and I were conducting our testing over the past few days. Screenshot of what this looks like for the user is below. Note, once Private is exited, all history is capture in an encrypted backup or Method 1 in PA.

In summary – for Safari, you MUST have an encrypted backup or an encrypted Method 1 from Physical Analyzer. I know this because we tested the beta of PA 7.24 and it works like a charm.  If it’s not encrypted by iTunes or the tool – you will not gain access to  Safari/history.db.  If the user last used Private browsing and did not close Safari, chances are good you will also get nothing. If you want to find Private Browsing traces – sign up for FOR585 Advanced Smartphone Forensic Analysis In-Depth and we will teach you. for585.com/course.  

It’s back – well, depending on your settings!

• Maps – /var/mobile/Applications/com.apple.Maps/Library/Maps/History.mapsdata  – older searches – pre iOS 11 and /var/mobile/Applications/com.apple.Maps/Library/Maps/GeoHistory.mapsdata – iOS 11 and newer searches

I have spent years on Apple Maps. Literally years… While it’s back, only some tools only parsed history.mapsdata! Again, make sure you use a tool that will parse both history.mapsdata and Geohistory.mapsdata. Verify the source of the data for everything parsed as your first clue. This is super important to ensure you aren’t missing information. Vendors – again, make sure you are doing this correctly. I found major gaps. This is what it looks like when the tool does it’s job.

You should also be able to manually examine the Geohistory.mapsdata file for confirmation.

If you see nothing at all for Maps, the user probably enabled the cloud setting for Maps, which seems to skip saving anything to the phone other than the group.com.apple.Maps.plist which stores the last search in Apple Maps and can be found here: /var/mobile/Applications/group.com.apple.Maps/Library/Preferences/. If that isn’t the case, you need to choose a tool you know properly parses Apple Maps.

Here is what the setting looks like that may keep Maps from being saved to the device. I have Maps turned off for iCloud, so the data was saved to Geohistory.mapsdata on my iPhone. On Paul’s device, his was turned on and he didn’t have a Geohistory.mapsdata. The settings seem to control what we can extract. You need to pull iCloud information to extract this and Elcomsoft does a fantastic job.

 

Tool Support