Tag Archives: Cellebrite

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

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

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.

SELECT
ZHISTORYITEM.z_pk AS "Item Number",
CASE
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",
ZHISTORYITEM.ZQUERY AS "Location Search",
ZHISTORYITEM.ZLOCATIONDISPLAY AS "Location City",
ZHISTORYITEM.ZLATITUDE AS "Latitude",
ZHISTORYITEM.ZLONGITUDE AS "Longitude",
ZHISTORYITEM.ZROUTEREQUESTSTORAGE AS "Journey BLOB",
ZMIXINMAPITEM.ZMAPITEMSTORAGE as "Map Item Storage BLOB"
from ZHISTORYITEM
left join ZMIXINMAPITEM on ZMIXINMAPITEM.Z_PK=ZHISTORYITEM.ZMAPITEM

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!

SELECT
ZHISTORYITEM.z_pk AS "Item Number",
CASE
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",
ZHISTORYITEM.ZQUERY AS "Location Search",
ZHISTORYITEM.ZLOCATIONDISPLAY AS "Location City",
ZHISTORYITEM.ZLATITUDE AS "Latitude",
ZHISTORYITEM.ZLONGITUDE AS "Longitude",
hex(ZHISTORYITEM.ZROUTEREQUESTSTORAGE) AS "Journey BLOB(hex)",
hex(ZMIXINMAPITEM.ZMAPITEMSTORAGE) as "Map Item Storage BLOB(hex)"
from ZHISTORYITEM
left join ZMIXINMAPITEM on ZMIXINMAPITEM.Z_PK=ZHISTORYITEM.ZMAPITEM
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,
chat_message_join.chat_id,
message.handle_id,
message.text,
message.thread_originator_guid,
message.thread_originator_part,
message.service,
message.account,
chat.account_login,
chat.chat_identifier,
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
datetime(message.date_read+978307200,'unixepoch','localtime')
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
datetime(chat.last_read_message_timestamp/1000000000+978307200,'unixepoch','localtime')
when LENGTH(chat.last_read_message_timestamp)=9 then
datetime(chat.last_read_message_timestamp + 978307200,'unixepoch','localtime')
else 'NA'
END as "Last Read",
attachment.filename,
datetime(attachment.created_date+978307200,'unixepoch','localtime') AS "Attachment Date",
attachment.mime_type,
attachment.total_bytes
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!

iOS 13 – Summary for those of you who enjoy the cliffsnotes

For those of you who don’t have time to read for585.com/ios13, here is a mini summary for you.

First – If the backup is NOT encrypted you will not get:

  • Maps
  • Calls
  • Safari
  • Health
  • Keychain
  • Wallet

Apple has upped their game on protection it seems, so you need to encrypt to extract. I used iTunes in my full blog and just testing PA 7.24 Method 1 with encryption and Method 2 is in progress. Worked like a charm and I got what I expected. You lock it up, or you don’t get much. Bottom line. Jessica Hyde wrote a post on protecting yourself from an accidental sync if using iTunes to create a backup: https://www.magnetforensics.com/blog/three-newer-things-that-may-surprise-you-about-ios-forensics/amp/ If you are using PA, you are protected from this.



While you are going to be forced to read the long blog for the juicy details, here are the file paths you need to be aware of for iOS 13:

  • Contacts /var/mobile/Library/AddressBook/AddressBookImages.sqlitedb
  • Calls /var/mobile/Library/CallHistoryDB/CallHistory.storedata
  • SMS /var/mobile/Library/SMS/sms.db
  • Maps /var/mobile/Applications/com.apple.Maps/Library/Maps/GeoHistory.mapsdata
  • Safari /var/mobile/Library/Safari/History.db
  • Photos Database /var/mobile/Media/PhotoData/Photos.sqlite

The biggest change other than encryption seems to be the use of protobufs, which Sarah Edwards is working on a blog to discuss, settings and how that may determine what is saved to device vs. cloud, Safari artifact storage, and encryption. Please read the full blog for all of the good details and stay tuned for my iOS series, webinars, etc.

Stay tuned for the release of PA 7.24 next week and also for #TipTues on Twitter where I will provide something useful, I hope. 😉

What are your forensic tools really good at?

Happy Saturday everyone! Several of my SANS FOR585 students have asked me to document my opinions on what tools I like and how I find them to be helpful. Again, I am not including every single tool out there or highlighting all of their capabilities, so if one is missing that you find useful, please post in the comments. This is simply a quick blog to highlight what has helped me in the past 6+ months.

I am not going to dive too deep into acquisition. There are so many tools and methods available that most people can figure out a way to get the data. I recommend you always get a physical dump and logical or backup to help you parse the data. Pick your poison on obtaining the data (Cellebrite, MSAB, Lantern, Blacklight, ViaExtract, flasher boxes…. it goes on and on). Each tool has their pros and cons and it’s a bad idea to only have one tool in your toolbox. Smartphones are beasts and security is getting stronger. Make sure you test your tools and test them often. Don’t let one hurdle knock you down. Try to trick your tool into working for you if needed.

I think the easiest way to write this blog is to include highlights and then touch on them. What is your tool really good for based upon my experience:

Commercial Solutions (Not in any particular order):

  • IEF Mobile – Great for Internet evidence and parsing 3rd party application data. One of the best iOS app parsers out there.
  • Physical Analyzer – Probably the best analytical platform out there specific to smartphone tools. It doesn’t parse everything, but it gives us a platform for analysis where we can make it find the evidence with some manual carving and hex searches.  Best physical search feature for locating data in raw hex.
  • MSAB XRY/XACT – One of the only tools that provides access to the raw files during a logical acquisition. Guess what, to recover data that the tools don’t parse you need the raw files. This tool give you access to them!
  • Lantern – Great Facebook app support. Seems to parse more data than the others on specific iOS devices.
  • Blacklight – Great tool that can run on a Mac! Great support for iOS devices. Haven’t you heard that you should examine a Mac with a Mac? A wise examiner once told me that and it still resonates with me.
  • Mobilyze – Best triage tool for iOS and Android.
  • MPE+ – The SQLite builder is a great feature when manually examining databases from 3rd party apps.
  • Oxygen – The best tool for BlackBerry. Acquires the event log and provides a secure way to create a BB backup file. Also counts out all those nasty little databases for you. I also like how Oxygen parses 3rd Party Apps.

Open Source and Other Solutions (Not in any particular order):

  • Andriller – This is one of my new favorites. This tool can crack passcodes and provides parsers for iOS, Android and Windows 3rd Party Application files. Free for LE and well worth it for everyone else. The fee is small the results are huge! https://andriller.com/
  • Now Secure CE (used to be ViaExtract CE) – Andrew Hoog was kind to release this awesome tool. It provides acquisition support for free! Parsers are pretty kick-ass too. Check it out. https://www.nowsecure.com/forensics/community/
  • Sanderson Forensics tools – Great SQLite support! The SQLite Forensic Toolkit is so useful in recovering deleted data and for converting those pesky timestamps. http://www.sandersonforensics.com/forum/content.php
  • Parsers developed by the community. Mari DeGrazia (http://az4n6.blogspot.com/)and Adrian Leong (http://cheeky4n6monkey.blogspot.com/) are rockstars and often give back by developing scripts to help us sift through application and smartphone data. Check out their blogs to see what has been helping us sift through the massive amounts of data.
  • Autopsy – The Android Analyzer module supports parsing commonly missed items from Android devices. It also gives you access to the File System directory tree faster than any commercial tool out there. http://sleuthkit.org/autopsy/

I am sure I have forgotten to give credit to some where it’s due, so I am requesting that you help me out. What tools really help you and how? Is there one that is strong with Base64 decoding? What about the double Base64? Don’t know what that means??? Take FOR585 and Cindy Murphy and I will teach you.  If you need more references on how to use the tools and the open source/free solutions, read the following books:

Practical Mobile Forensics

Learning Android Forensics

Learning iOS Forensics

Good luck and keep digging in that Hex! The data is there and it’s your job to find it.