See what I did there? I am getting craftier with these blog titles. First things first – this is NOT a sponsored blog. I am just really impressed with the bounds Oxygen is making in the mobile world.
I have been using Oxygen for years and this last update has really impressed me. I test tools thoroughly and include the best ones in the SANS FOR585 Advanced Smartphone Forensic course that I co-author. I also use these tools for my regular job, where I aim to find gaps and then fill them with my own methods and tools. So, it’s safe to say that I spend a lot of time becoming familiar with the tools, learning what I am able to trust and where they ultimately fail me.
Normally, I have a hard time seeing the good side of tool output because the artifacts are often so convoluted and misleading to examiners who don’t know any better. Is it the vendor’s fault – No! The phones are hard to keep up with and the version updates on each OS make it even harder, but examiners like to press the “Find Evidence” button and that makes me shiver. So… that is why I am normally opposed to those who use tools and live by what the tools report without digging in to verify. Don’t get me wrong, there is never enough time, but some things are worth digging for and verifying!
What changed my mind about Oxygen? Well, it’s not that I was ever against the tool, I just didn’t see how it added value to my everyday work or smartphone course until this latest release. I have always loved the PList Editor and SQLite Viewer, but that is really where my love existed – until recently, that is. This tool has made my life so much easier! I am going to highlight some of my favorite new features. Why should you care? Because you are going to see smartphones with third-party applications on them. This tool is fantastic at supporting the parsing of third-party apps and when it can’t – guess what? It will give you a cheat sheet for the files you must MANUALLY examine. Now that, is the key to success right there. Don’t believe me, keep reading.
Oxygen has taken the parsing of social networking apps to a new level. This includes popular apps like Facebook, Facebook Messenger, WhatsApp and those less popular ones that will shock you when you load your image file and see the glorious application data parsed for you. Now will this tool get it right every time? No, but it gets you a little bit closer. Tools should be used to triage what you need to focus your efforts on. Oxygen has been helping me see what I need to hone in on and then allows me to keep my deep dive all within the tool.
My normal application analysis process involves (Note: since this blog is about my Oxygen experience, I am highlighting how to do as much of the examination as possible in that tool):
Scanning the Applications that are parsed by the tool (I commonly use Physical Analyzer, Oxygen, IEF/AXIOM, BlackLight, etc.)
Examining the data for application installation traces
Identifying apps of interest and going directly to the application directory for manual examination and verification (via File Browser in Oxygen Detective)
Combing through each relevant database and examining for both active and deleted artifacts of interest (via SQLite Database Viewer in Oxygen Detective)
Leveraging the SQL Editor to draft my own queries to parse and join tables of interest (No experience here? Try the query builder that is built in to learn)
Examining each .PList of interest (using the Apple PList Viewer in Oxygen Detective)
Examining any other files of interest pertaining to the applications (xml, dat, multimedia, etc)
Examining browser and webkit artifacts
Exporting what isn’t support and dive into it using another tool
I am a firm believer that one tool cannot solve all of your investigative needs, which is why I use all of the tools available to me to my advantage and branch out from there. For example, I was working an app last week that allowed the user to share their location for a set period of time. The first tools I tried did not parse this data. Even Google maps could not render the broadcasted location from this obscure app. But guess what – Oxygen decoded it and correctly displayed the location I was sharing from that app. How do I know? Because I created test data to mimic what I found in that file on that Android device and it parsed my location information correctly. Add another thing to the list on what is impressing me about Oxygen.
I aim learn the strengths (and weaknesses) of each tool and tool feature and impart that wisdom on my students. A tool that was great two years ago could be useless today, so you need to keep up and always test and validate with datasets you trust. Not everyone has time to thoroughly test all tools, so we, as a community need to test and share our results (hence most of my blog posts).
Let’s take a look at some examples. For this scenario, I used Oxygen to highlight application analysis on WhatsApp and webkit artifacts. As previously mentioned, I start by looking at the apps that are parsed vs which are installed. From there, I select the ones of interest and start looking at the actual files. Below, I scanned the files associated to WhatsApp. Some of these were parsed and a lot them were not. This tool gives me a quick reference to the files associated to the application and leaves the rest to me, which I prefer and appreciate. Few tools will provide you the location for all of the files associated with the app. Often, you will find yourself needing to hop around to see the paths for all application data.
During this examination, I opened databases of interest and examined them. Some required queries and the recovery of items marked for deletion, all of which is possible within the tool. If you have other tools you prefer, simply export the file and go on your merry way. What I really like is the ability to get a glance of what is stored within each file without opening each one. Below I was examining a log file associated to WhatsApp without navigating from my list of app files. This is helpful to those of us who are lazy and do not enjoy opening every file and examining the data in separate windows.
After exhasting my examination of the apps themselves, I went to the webkit and browser for more hunting. Below, I am using Oxygen to get an idea of the webkit files available from my data dump. I normally conduct a simple keyword search in my tool of choice for “localstorage”, but this way was much easier and eliminated the need for that step. As a side note, Oxygen did a great job parsing these files. I am simply showing the raw files associated with webkit activity.
Below I am showing an example of a localstorage file that I wanted to customize to fit my examination needs. I drafted a SQL query and joined two tables to show the results I needed for my forensic examination. This can be exported and included in my report template. The SQL Editor was used in this example.
The mapping was great in this tool, but I have decided to omit those screenshots, since it highlights my home location. I found it interesting at how well the pesky locations (those located in log, xml and dat files) were parsed by Oxygen. If you have heard me present on location artifacts in tools, it is commonly a WARNING to tread carefully. The tools have a hard time interpreting how the location got onto the phone. A simple example: I receive an iMessage with an attached photo. I save the photo to my device. I dump my phone and look at the locations. The location from the shared photo shows up in my report as if my device was there. This is how someone without a lot of experience may interpret that evidence. Hence, be careful! The reality is that the the cool artifacts used and created by third-party apps use are often overlooked. I was thrilled that Oxygen parsed that location information, especially because Google Maps was throwing fits when I was attempting to manually render the lat/longs. Go Oxygen!
In summary, this was just a short blog post highlighting the successes I have been having with Oxygen. Additionally, customer support has been great. Is the tool perfect? No? Is it something you need in your forensic toolbox – Absolutely. If you end up taking FOR585, you will learn more about this tool. For those who aren’t looking for training and just want to test it on their own, see the details below and ask for a demo.
I hope these tools keep growing in capabilities and keep one another competitive to be the best. It helps us as examiners! Even though I use the tools to only get so far and rely on manual investigation techniques, getting over the first few hurdles is the hardest and then you set your pace. (Yes, I ran track… :)) I believe this tool will get you over those hurdles for application analysis.
To try Oxygen Detective and see the benefits for yourself, reach out to sales@oxygen-forensic.com and ask for a demo. Mention my blog!
If you apply the Local LEdiscount (50%) to the Advanced Smartphone Forensics (FOR585) the cost is ~$2550 but we only have a limited amount of seats at this rate per class so act soon.
Only those at the State and Local level who carry a badge can access the program. For everyone else we recommend looking at the “Work Study” program. Only 1-2 seats per course are generally allowed, but it is a great program that we fought very hard at establishing.
This is going to be a series of blog posts due to the limited amount of free time I have to allocate to the proper research and writing of an all-inclusive blog post on iOS 11. More work is needed to make sure nothing drastic is missing or different and to dive deeper into the artifacts that others have reported to me as currently being unsupported by tools.
From what I have seen thus far, I am relieved that iOS 11 artifacts look very similar to iOS 10. This is good news for forensicators who see iOS devices and have adapted to the challenges that iOS 10 brought. Prior to writing this, I was referred to a blog post on iOS 11, that was an interesting read (thanks Mike). I suggest you also check it out as it pinpoints what is new in iOS 11 in regards to features: https://arstechnica.com/gadgets/2017/09/ios-11-thoroughly-reviewed/5/
Understanding what the OS is capable of doing helps us determine what we need to look for from a forensic standpoint. From what I have seen so far, the major artifact paths have not changed for iOS 11. Key artifacts for normal phone usage appear to be in the same locations:
Maps – /private/var/mobile/Applications/com.apple.Maps/Library/Maps/History.mapsdata – Still missing? Refer to my blog post from Dec.
When I test an update to a smarphone OS, I normally start with basic user activity (create a new contact, place some calls, send messages, ask for directions, etc.) and then I dump my phone and see what the tools can do. For this test, I created both encrypted and unencrypted iTunes backups, used PA Methods 1 and 2 and did a logical extraction with Oxygen Detective. What I found is that not all tools parsed the data in the same manner, which is to be expected. (I also plan to test more methods and tools as time allows and for my FOR585 course updates.)
To get this post done in a timely manner, I found one item that has always been parsed and jumped out as “missing” or not completely supported.
iMessages and SMS in iOS 11 were the first items that jumped out as “something is off…” and I was right. I sent test messages and could not locate them in the tools as easily as I have done in the past. I normally sort by date, because I know when I send something. Up until this release of iOS, we could rely on our tools to parse the sms.db and parse it well. The tools consistently parsed the message, to/from, timestamps, attachments and even deleted messages from this database. Things have changed with iOS11 and it doesn’t seem that our tools have caught up yet, at least not to the same level they were parsing older iOS versions.
One of the most frustrating things I find is that the tools need access to different dumps in order to parse the data (as correctly as it could for this version). For example, Oxygen didn’t provide access to the sms.db for manual parsing, nor did it parse it for examination when the tools was provided and iTunes backup. This had nothing to do with encryption, because the passcode was known and was provided. UFED isn’t the same as PA Method 1 and 2 (you have heard this from me before), but it’s confusing because most don’t know the difference. This is what it looked like when I imported the iOS 11 backup into Oxygen. Believe me, there are more than 3 SMS/iMessages on my iPhone.
However, I when I dumped my iPhone logically using Oxygen Detective, it parsed the SMS and provided access to the sms.db. When I say “parsed” the sms.db, I am not referring to timestamp issues at all, those will be addressed in a bit. Here is what my device looked like when I dumped it and parsed it in Oxygen.
Spot the differences in the messages? Yep, you now see 48,853 more! Crazy… all because the data was extracted a different way. I also tested adding in the PA, Method 1 image and those message numbers were different, but the sms.db was available and parsed. You really have to dump these devices in different ways to get the data!
Bottom line – add the sms.db to something you need to manually examine for iOS 11 to ensure your tool is grabbing everything and parsing it. The rest of this blog is going to focus on just that – parsing the sms.db in regards to changes found in iOS 11.
Let’s take a look at what is the same (comparing iOS 11 to iOS 10):
SMS and iMessages are still stored in the sms.db
Multiple tables in this database are required for parsing/joining the messages correctly
What is different (comparing iOS 11 to iOS 10):
Additional tables appear to be used?
The timestamp is different for iOS 11 – SOMETIMES!
Here is what I found (so far). The tools are hit or miss. Some tools are parsing the data, but storing the messages in a different location, others are parsing the message content, but not the timestamp… you catch my drift… What I recommend? Go straight to the database and take a look to make sure the tool(s) you rely on are not missing or misinterpreting the messages (wait… didn’t I just say that – YES, I did.)
Thetimestamp fields for the sms.db are all over the place now. What I am seeing is that the length of the Mac Absolute value varies between two formats and both of these formats can be stored in the same column. This is why the tools are struggling to parse these dates. Additionally, the tables in the sms.db differ in how they are storing the timestamp. So, if your tool is parsing it correctly, excellent – but still take a look at the tables.
Here are some examples of what this mess looks like. The column below is from the chat table in the sms.db. Notice how it has the traditional Mac Absolute value ( number of seconds since 01/01/2001), while others are a 18 digit Mac Absolute values and some are 0 (sent messages).
Additionally, I was seeing some that were 18 digits that were not appended with 00s at the end. The “conv start date” on the left column is from the messages table in sms.db and this timestamp has not changed. As expected, your tools handle this one nicely. The table on the right column is from the chat_message_join table, and this caused a little havoc as well due to the variety of timestamps in the column. Converting this wasn’t fun! Thanks Lee for your help here. You, my friend, ROCK!
When I first ran my SQL query, I noticed this one pesky date that wasn’t converting. This is because it was the timestamp highlighted above and I needed to beef up my query to handle this. If you see a date that looks like the one below, something is up and you aren’t asking for the data to be rendered correctly. The query below will handle this for you.
Don’t believe me that this causes issues yet, take a look at how it looked in one tool.
The dates and times are not parsed correctly. I found that the dates and times appear to be consistent when the tools are parsing the 9 digit Mac Absolute timestamps from specific tables. Otherwise, expect to have to do this yourself. Here is where it was correct, but this wasn’t the case for all of my messages sent using iOS 11.
If you need a sanity check, I always like to use the Epoch Converter that I got for free from BlackBag to make sure I am not losing my mind when dealing with these timestamps. Below, you can see it was parsing it correctly (Cocoa/Webkit Date). Also, I love that it gives you both localtime and UTC.
This leads me to the good news -below is the query that will handle this for you. This query is a beast and “should” parse all sms and iMessages from the sms.db REGARDLESS of the iOS version, but only columns that I deemed interesting. (Note that I state should, because this has only been run across a few databases and you should report any issues back to me so they can be fixed.) Take this query and copy and paste it into your tool of choice. Here, I used the DB Browser for SQLite because it’s free. I limited some columns to the ones I care about the most, so you should make sure this query isn’t missing any columns that may be relevant to your investigation.
SELECT message.rowid, chat_message_join.chat_id, message.handle_id, message.text, message.service, message.account, chat.account_login, chat.chat_identifier AS “Other Party”, datetime(message.date/1000000000 + 978307200,’unixepoch’,’localtime’) AS “conv start date”, 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 ‘N/A’ END AS “conversation start date”, datetime(message.date_read + 978307200,’unixepoch’,’localtime’) AS “date read”, message.is_read AS “1=Incoming, 0=Outgoing”, 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 ‘N/A’ END AS “last date read”, attachment.filename, attachment.created_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
Here is a snippet of what this beauty looks like. (Note: this screenshot was taken prior to me joining attachments – aka MMS).
I always stress that you cannot rely on the tools to be perfect. They are great and they get us to a certain point, but then you have to be ready to roll up your sleeves and dive in.
What’s next – applications, the image/video files that apparently aren’t parsing correctly, interesting databases and plists new to iOS 11 and the pesky maps. That one is still driving me crazy! Stay tuned for more iOS 11 blogs and an upcoming one on Android 7 and 8.
Thanks to Lee, Tony, Mike and Sarah for keeping me sane, sending reference material, testing stuff and helping me sort these timestamps out. Like parenting, sometimes forensicating “takes a village” too.
I realize it’s been awhile and these tools have really changed since my last post in 2015. Have they changed for the better? Not necessarily. Some tools update so quickly that they lose the basics. For that reason, please test and validate your tools and never trust what is advertised. Your goal should be to determine how the artifacts were placed on the device, not that the artifact exists on the phone. By this I mean – how did it get there? Did the phone suggest it, the user searched for it or was it synced to the device? This level of analysis is something your tool cannot do for you, which is why you probably read blogs like this and learn what you can trust and where you must apply your smartphone skills.
One of the most common questions I am asked is “which tool is the best?” Guess what? There isn’t just one! And I strongly recommend you use more than one, especially for analysis and sometimes even for acquisition (read my blog on iOS 11 from Oct. 2017). These tools are picky and seem to like one device better than another and parsing is not the same across the board. You must know the tool strengths and be able to defeat the weaknesses. To help you out, I am listing the tools that I prefer and my reasons why. These tools are not perfect and they DO NOT have a “Find Evidence” button. Is your tool missing from this list? Offer me a demo and I will try to find time to test it and give feedback.
As I stated in the last blog I wrote on this topic, I am not going to delve too much into acquisition tools and methods. There are so many out there. Some of the ones I rely on to get my data are Cellebrite UFED (not for iOS devices), Cellebrite Physical Analyzer (for iOS devices), Oxygen, iTunes and my good ‘ole Mac. I always tell my students to try everything when you have a smartphone on your desk. You don’t know how that device was used and what settings are already enabled behind that locked device. You may surprise yourself when you are able to grab everything with the click of the “acquire evidence” button on your tool of choice. However, it’s not always that easy so verify that you have unencrypted data even if you get a dump. Additionally, I recommend you always get a physical dump and logical or backup to help you parse the data. Make sure you test your tools and test them often. Don’t let one hurdle knock you down.
The list below doesn’t include all smartphone tools, but simply the ones I rely upon. If you have others you like, please comment and share. I love hearing what others are using because I don’t have time to test every tool and keep up with the quickly released updates. So, help me out here.
The Heavy Hitting Commercial Solutions (Not in any particular order):
*NOTE: DO NOT RELY ON YOUR TOOL TO TELL YOU HOW DATA WAS PLACED ON THE DEVICE—THAT REQUIRES YOUR KNOWLEDGE! VERIFY ALL LOCATION ARTIFACTS!!!
Magnet – IEF Mobile – Great for Internet evidence and parsing 3rd party application data. One of the best iOS app parsers out there. AXIOM is now the up and coming tool, but does have some growing pains, so test it for yourself. In both of these tools, the Custom/Dynamic App finder is so useful as location additional databases of interest that you should examine for relevance. This tool easily ingests image files from other tools.
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 leverage it find the evidence with some manual carving and hex searches. PA doesn’t seem to omit files it doesn’t understand, which seems to be happening in other tools. Best physical search feature for locating data in raw hex, other than in file system dumps of iOS devices. The new fuzzy models plug-ins are fantastic as they identify databases commonly associated to 3rd party applications that aren’t parsed by the tool. This tool easily ingests image files from other tools.
MSAB XRY/XACT – One of the only tools that consistently provides access to the raw files (databases, xml, dat, plists, BLOBs, etc.) 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! XRY is strong at parsing strange backup files from smartphones, such as those created with Samsung Kies.
BlackLight – Great tool that can run on a Mac or PC! Primarily supports iOS devices, but I have seen students force load Windows Phones and Android devices into the tool to use it as a file system examination platform. However, it was designed to support 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. This tool uniquely pulls out Google Maps and Apple Maps searches that the other tools commonly misinterpret. If you hear me talk about BlackLight, you know that I rave about the Windows hard drive support. Strange that the Mac guys are doing so well on Windows.
Oxygen – This is one of my new favorites because I am constantly examining 3rd party applications. This tool highlights files the applications use and where they are stored. Guess what? That list is now your cheat sheet. Pretty sweet! I also love the built in PLIST Editor (hex and xml views) and the SQLite editor. This is the best tool for BlackBerry and BlackBerry 10 devices. It 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 wrote a recent blog on Oxygen, so read it if you want more details on this tool. Just like most of the others, there are growing pains, so test it and validate that it’s showing you all of the data.
Elcomsoft – I use the Phone Password breaker to crack locked BlackBerry device, BlackBerry and iOS Backup files. I also use this tool to pull cloud data. It’s awesome! Runs on both a Mac and PC.
The Other Guys (Not free, but not as expensive as the heavy hitters):
Not in any particular order…
Andriller – This tool can crack passcodes for locked Android devices and provides logical 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/
Sanderson Forensics tools – Great SQLite support! The SQLite Forensic Toolkit is so useful in recovering deleted data and for converting those pesky timestamps. I love how this tool shows you how the queries are run and what’s happening when you press a button. New to SQLite forensics – start here! Stay tuned for Pauls’ new SQLite Forensics book (it’s fantastic and is not a sales pitch for his tool!) Paul will provide a free demo upon request. http://www.sandersonforensics.com/forum/content.php
Open Source and Other Solutions:
Parsers developed by the community. These people are rock stars and often give back by developing scripts to help us sift through application and smartphone data. Check out their blogs and githubs to get the latest scripts that I rely on to parse the massive amounts of data the commercial tools just don’t support.
Mari DeGrazia (http://az4n6.blogspot.com/)
SQLite-Deleted-Records_Parser – A must have for unveiling deleted data in SQLite databases.
Adrian Leong (http://cheeky4n6monkey.blogspot.com/)
His blog rocks! Adrian hits on hard topics. Read it! (HEIC/HEIF on iOS 11 is one of his latest). Also, all of his scripts have been tested to work in the SANS SIFT.
Honestly, he has so many scripts out there – go check them out! (Facebook Messenger, SQLite parsers, coordinate converters and more!)
Jon Baumann was a student of mine recently who decided to build scripts to fix the things that were broken in the tools. LOVE THAT! https://github.com/threeplanetssoftware/
His new sqlite-miner script parses databases containing BLOBs that contain human-readable data. Not only does it identify the contents, it parses them and exports them!
Autopsy – The Android Analyzer module hasn’t been updated in a while, but it still supports parsing some items from Android devices. It also gives you access to the File System directory tree faster than any commercial tool out there. Most tools make you wait to see the file system during parsing – not Autopsy. Also, the keyword searching and carvers are top notch. http://sleuthkit.org/autopsy/
iBackupBot – Great for parsing iOS backup files. Works on both Macs and PCs. Make sure you have the latest version that supports iOS 10 and 11.
As I always say, 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 script that you found and cannot live without? Do you use something more robust than a Java decompiler for mobile malware? Is there something parsing double Base64? Don’t know what that means??? Take FOR585 and Cindy Murphy, Lee Crognale and I will teach you. Our course is offered almost every month and all over the world. Check it out for585.com/course.
Keep digging in that Hex! The data is there and it’s your job to find it.
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
SELECT datetime(timestamp,’UNIXEPOCH’,’localtime’) AS “Timestamp”, name, start_point_name, start_point_latitude, start_point_longitude, end_point_latitude, end_point_latitude, telephone, url, 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.
I have been recently asked by students for a summary on how to handle smartphone acquisition of iOS and Android devices. I have avoided writing it down, like I would avoid the Plague, because mobile changes so quickly and I don’t want people to read something and live by it. I wrote this on my plane ride to Vancouver, so forgive any typos or briefness in this blog.
With that said, these methods are what work for me today. Others may prefer different methods, and that is great. If we were all the same, this would be a boring community, right?
This blog contains what I do on a normal basis when it’s possible. Anyone who conducts mobile device forensics knows that everything changes so quickly and what is possible today may require modification to work tomorrow. We adapt, adjust and are smarter because of it.
What I decided to do was to focus on Android and iPhone for this blog. Most of you have your favorite vendor tools and that is great. I recommend you use more than one because not one of them is perfect. Don’t become so reliant on one method that you avoid opportunities to test other tools and that you rely so much on a single tool that cannot extract data properly. I am avoiding listing tools specifically that I prefer because I have blogged on that in the past . I am simply defining steps I take that work and you can use the tool of choice to accomplish the following. Remember, it doesn’t have to cost the most to work the best! Sometimes the free methods give you the most data.
Android Acquisition Recommendations
Android devices are becoming increasingly difficult to acquire. We have seen many devices now where basic information (photos, contacts and some calls) are retrieved. Sometimes only data that exists on the SIM is extracted. I am sure many of you have gotten the screen below and it’s disheartening! But we cannot stop trying.
This is not good enough for us to conduct our investigations. We need to get crafty! The first Android running OS 7 that I acquired shocked me. I was getting nothing from the tools! Below is an example of what I pulled – just a bunch of empty directories! Not good…
It was a scary moment for me until I realized that good old ADB was my key to the most data. I will cut to the chase momentarily, but if you want more information on Android acquisition, I recommend you take vendor training if you rely on a tool and/or take FOR585 Advanced Smartphone Forensics, where we focus on analysis but recently updated the course to include the other options that may work when simple tool acquisition fails.
ADB Backup (capture both the device (all) and SD (shared))
adb backup –all
adb backup – shared
Logical Acquisition using a forensic tool – especially if ADB isn’t going well for you
File System Acquisition if more than a backup is offered
Physical Dump if you are aware and don’t care about the traces left behind (i.e. you don’t give the device back and you are not conducting covert operations)
Make sure you acquire the SD card and SIM card if one is present (I like to remove these and acquire separately to ensure nothing is overlooked)
Obtain Google credentials if possible
Extract cloud data – IF YOU HAVE AUTHORITY!
I like to run some ADB commands to the device to ensure I extracted all information and that I am aware of what exists on the Android. Some examples are:
adb shell service list
adb shell pm list packages (shows apps that are installed)
ALWAYS open the extraction to ensure you got what you hoped. If you have a physical dump, Autopsy is the fastest you will gain access to your data! And it’s free. (https://www.sleuthkit.org/autopsy/)
Android acquisition leaves traces behind on the device. If you conduct covert operations – tread carefully here. I put these steps in order with you in mind. Don’t go too far without knowing the footprint your tools and methods are leaving behind. These topics are covered more in the FOR585 class. (http://for585.com/course)
iOS Acquisition Recommendations
For iOS acquisition, it’s the same as it has been for years. Yes, there are rumors of the data port lockout. Yes, there are tools that crack into the device anyway. This blog is not focusing on that. It’s focusing on what you should try when you have an iOS device to investigate. You can choose to work on a Windows or Mac. I do both. Honestly, most of my acquisition takes place on my Windows forensic workstation, but I do have a Mac that I use to examine native files to Apple and for jailbreaking because Windows is sometimes flaky when it comes to that.
Things you will need:
Install iTunes if you plan to create a backup
Install iBackupBot (I prefer this tool over the other free ones because of the option to dump the crash logs) (http://www.icopybot.com/download.htm)
Your forensic tools of choice
Recommended iOS Steps:
Determine the iOS device type (chances are you will not obtain a physical dump because the device is most likely 64 bit and not jailbroken).
Conduct a File System/Advanced Logical Extraction
If using Cellebrite products, make sure you use Physical Analyzer and conduct both Method 1 and Method 2. I do not use UFED to dump iOS devices. Physical Analyzer is better.
If you use Physical Analyzer and see Method 3 – congrats! You have come across a jailbroken device.
If using another tool, use more than one to ensure you obtain all potential data from the device.
If you want to be thorough, obtain a logical and/or backup file of the device. I typically stop at the file system dump since it contains the backup if I trust my tool (refer to my old blog or take FOR585 for more info on this topic)
Connect the device to iBackup bot and dump the crash logs
Ensure the tools you used did not enable iTunes encryption by connecting the device to iTunes and making sure “Encrypt Backup” is not selected.
6. Obtain iCloud and Google credentials if possible and extract cloud data – IF YOU HAVE AUTHORITY!
Also – do not guess passwords on the device and risk wiping it. Use a method that you have tested or a service that supports that device. If you are desperate and you are locked out, try the following:
For iOS:
Attempt to communicate with (aka run command to) or pair to the device via libimobile
2. Attempt an iTunes backup
3. If you believe you can obtain iCloud credentials, pull the data from there – many tools support this
4. Try multiple cables
5. Only brute force on your own using a “hacker” box if you are willing to wipe the device.
For Android:
Attempt to run ADB commands to the device. Try to collect as much information as possible.
Remove and acquire the SD card in a write-protected manner, if one exists
If not, attempt to acquire the emulated SD via FTK Imager or a similar tool as a USB Mass Storage Device
Remove and acquire the SIM card
Crack the lock if you can access the require files (*.key, etc.)
Pull Google cloud artifacts, if possible – many tools support this
Try multiple cables and modes (Recovery, Safe, Download, etc.) to see if your extraction is failing due to the device not being in the proper state
If the device is unlocked – make sure you properly enabled all required developer mode settings
Again, we cover other methods and direct ways to interact with the device in FOR585 and I don’t want to, nor can I, give all of those juicy details away. This is simply a guide for things you should consider when faced with these devices. Obviously, we don’t all have time to run through all of these steps, but it’s nice to lay out what may work the best for you. If you want to learn more about smartphone forensics, sign up for FOR585 in DC next month. WARNING: The class is sold out so you can log in LIVE via Simulcast! This means you get to take the live course from anywhere and you get 6 days of action from 9-5 with me. You can ask questions via an online moderator and I will answer them LIVE! It’s not pre-recorded it is not OnDemand. It’s a pretty cool setup and I think you will like it. Check it out for585.com/online.
Looking to blog and don’t know where to post it? I am happy to host your thoughts for you. Below is the first guest blog post by a past FOR585 student. If you have something to write about, please let me know.
by Terrence D. Williams
I have revisited this same post in my mind nearly fifteen times a day. It finally hit me. It hit me a little harder than I expected but the topic was pretty apparent to me. Until I was driving down the road to work, I didn’t understand the purpose of many of the tasks I completed in my early years in the Marine Corps. When I first entered the Corps, I had a lot of functions that seemed purposeless. All these actions are something that I call “grunt work.” Grunt work can be categorized as all the long, tedious days of doing tasks that seem meaningless, but in the future, they become muscle memory.
Forensic grunt work hurt me because I did not understand why I needed to stare at a computer screen day in and day out, learning about various computer technologies. It dawned on me when I was driving down the street how I should have put in the work in the early days of my forensic career. I wanted to build a Python XML parser that could convert the output from one of the live forensic tools utilized by my team. My problem was that I did not know a lick about XML. I mean, I did not know about the root, the children, nor the elements. These are basic terms that are present in the popular XML language. I couldn’t fathom how my biggest problem in the situation is that I didn’t know the basics of XML.
Forensic grunt work helped me because the Marine Corps inadvertently taught me how to develop skills that become muscle memory. Over the course of two weeks, I read possibly twenty different articles about the structure of XML. Once I knew the basics, I began to combine my Python knowledge with my new XML knowledge. I was spending about 4 hours a day playing in Python’s interactive mode trying to see the many ways that I could build the original program that I set out to create back in July. With the help of Stack Overflow and the SEC573 SANS course, I was able to build the program that allowed me to parse the XML output from the tool to make my team more efficient.
How does Forensic Grunt Work work? It is a somewhat simple process. If we only limit the forensics world to Windows Operations Systems, Smartphones, and Network Security Monitoring you are still looking at more than a year’s worth of reading material. If you are a Mike Ross (a USA Suits reference), then this will be an easy task for you. You will be able to read each book and article one time and remember every single detail that you previously read. Unfortunately, you are most likely like me. You will read it once or twice, then use it as a reference book for the future because everything didn’t stick. This is where forensic grunt work comes into play.
2018 is the probably one of the greatest times to learn forensic skills. After reading “The Importance of Deep Work & The 30-Hour Method for Leaning A New Skill” by Azeria, I have developed my process of using Grunt Work to my advantage:
The Prep Work
Pick a skill that I need currently or will need in the future
Open the calendar app in my iPhone, to make me a study schedule of 30 hours. Monday – Friday: 4 hours, Saturday – Sunday: 5 hours
I am a tech junkie, so the best way to establish my schedule is to use technology. When a calendar alert is scheduled, my phone tells me, my watch tells me, my home system tells me, it pops up in my car, and it lets the people I share with that I have something scheduled
I break my daily sessions into 2-hour sessions. One session in the morning and one session at night
I know myself, so 4 hours is not the starting point for me.
During my sessions, I turn off the TV and place my phone on Do Not Disturb
The Grunt Work
Gather the books and articles related to the subject
First 10 hours of the work will be reading and note taking
Build a lab environment
The lab environment is a simple setup that typically involves one or two virtual machines
I tend to use open source tools that are easy to obtainable to not detract from my work
iii. Lab build is 2 hours
Goal setting
I write down the goal from the prep work stage in multiple locations.
The goal is to be able to see it to allow me to stay on task
The Grunt Work
The last 18 hours of my process is dedicated to the skill development
I begin in the lab environment by exploring the environment in relation to the goal
1) If the goal is to understand XML, I open the document in a text editor to see the format. I open the same document with the various tools to see how the tool will present it. Then compare the tools to the text editor.
iii. I begin to replicate the examples I found in the books and articles.
1) If the goal is to build the XML parser, I copy the examples in the books and articles. I slowly transform the examples to fit the current XML file I want to analyze
I now assign some challenges for myself that I think will help me get to the end goal
1) What if I don’t want all the XML file, how do I alter it?
2) What if I want to have pieces of the file that I will want consistently, how can I loop through it?
Finally, I apply the goal to challenges that others have had with similar goals
1) Go through stack overflow to see the questions that are similar to my goal
2) Can I answer their questions in my lab?
a) If not, revisit the examples and challenge steps above.
Post Work
Save the books, articles, and notes for later reference
Clean the material into an easily searchable format for me
For me, the above process is excellent. For someone else, the process will not be what he or she needs. The goal is not to repeat my process verbatim, but to make you’re 30-hour process in the same way. The process is a condensed Grunt Work model that will be an introduction to a new skill. The overall grunt work process will transform you into a master of the skill the more and more you apply the skill over your career. Challenge yourself to push past your comfort point in learning. To push myself, I will eventually work up to the point where my 30 hours are broken up into 4-hour sessions. Make it work for you. Good luck in beginning the skill learning process of grunt work.
One point of contention in the FOR585 Advanced Smartphone Forensic class is – which files store the correct datetime for when a user created an iOS backup? I’ve engaged in a few friendly arguments over this topic and it recently popped up again when Lee was teaching in NYC in August. Every time this question comes up, I test it again. I have probably tested this more times than I should have, which is why I am finally putting it in writing.
So, when you are asked – “When did a user last create an iTunes or iCloud backup?” – You can answer with confidence next time.
The first thing to consider is what you are examining. Are you looking at a backup file extracted from a PC or Mac? Are you looking at an iCloud backup? Are you looking at a file system dump created by a commercial or free tool? If you are looking at a backup (iTunes or iCloud) this process is a lot easier. If you are looking at a file system dump created by a tool, this is where the confusion may set in. I hope this blog makes your examination easier by breaking down what is happening for each file. For this test, I used my own iPhone that I use every day. Why? Because I know when I backup and I can then verify dates.
The files we are going to examine for backup datetime activity include:
info.plist
status.plist
manifest.plist
device_values.plist
All of these files are important, but the dates inside of each may vary and a smartphone tool may update the date inside of the file. If you are looking at a backup that was extracted from a PC or a Mac, the status.plist will contain the start date and time for an iTunes backup. The info.plist also stores a datetime and whether the backup was successful (snapshot state), but it is not the start date. It is often the completion datetime and doesn’t state if the backup was successful, which is why I rely on the status.plist, when the file is available. The manifest.plist is more helpful when it comes to dealing with locked backup files that need to be cracked. The date in the manifest.plist is often the same as the date in the info.plist and again this file does not track if the backup was successful or not.
Now here is the tricky part. If you completed a file system dump of an iOS device, the following files will most likely show a date that is NOT when the user created a backup. This date will be when you created the forensic image. This makes people uncomfortable, but it makes sense if you think about it. iTunes (or a process like iTunes) is most likely being used in the background to create the forensic image. It makes sense that these datetimes would be trampled. In this case, I rely on device_values.plist which remains untouched by any tool or method you use to create a forensic image of an iOS device.
At this point I have either confused you or validated what you already know. Either way, let’s take a look at my test.
I dumped my iPhone using Cellebrite Physical Analyzer Method 1. I only did Method 1 because I wanted to make sure that it pulled the device_values.plist and I was doing this test during a lab and didn’t have much time. NOTE: I have noticed in the past that this file may only be pulled using Method 2, so use both just in case. If you are wondering why I recommend both of these extraction methods refer to my previous blog posts. I completed this extraction on August 18, 2018 around 14:20 (I had a few connection issues and had to troubleshoot which is why I state “around”). I did not backup my device at this time other than using my tool to create a file system dump (aka – I did not launch iTunes and create a backup).
The info.plist is shown below. Notice the timestamp matches the extraction completion time and NOT the time the device was backed up by the user? If you used a commercial tool to acquire the device, simply look at the Extraction details to compare extraction time.
Next, I looked at status.plist. Again the date is NOT when the user backed up the device. This is when the extraction completed in Physical Analyzer.
Finally, we look at the manifest.plist. And we see the same date, but a time that occurs before the times in info.plist and status.plist.
I believe this is when Cellebrite scans the phone to determine if the tool should present you with the check box to encrypt the backup, or not, if the device is already encrypted. This is also around the time I started the extraction. So, this is really just showing you how long the Method 1 extraction took and has absolutely nothing to do with when the user last created a backup. Now we look at the device_values.plist and we get the correct answers.
Not only do we get to see datetimes for iTunes backups, but also iCloud, if the user has ever backed up to cloud under com.apple.mobile.backup. We simply have to decode our datetime stamp for the LastiTunesBackupDate and we get June 4, 2018 at 21:32:42 Eastern Time. (Note: I normally keep it at UTC, but I know when I created my last backup in local time and wanted to compare).
So, in short the forensic extraction methods will update the datetime in status.plist, info.plist and manifest.plist during the acquisition process. If you are conducting analysis of an iOS device image (not a backup) you should rely on the datetime recovered from device_values.plist. If you are dealing with a traditional backup file, use the status.plist for the datetime on when the last successful backup was created.
I’ve realized just how important it is to blog vs just do a webcast when I was completing my course updates. I would stumble upon a webcast, but didn’t have time to watch it, so I looked in another direction. This made me realize that I should write down everything I put into a webcast. Will a webcast hold up in course? Do you have time to watch all of them? Seriously, I am curious about the impact so please let me know.
In 2019 – I am going to write down what I talk about in webcasts. If I have the time, I may try to blog about my speaking events as well (think Keynotes and SANS @Nights). Some blogs may be short and sweet, but this way when someone says, “how can I do X” I will point them to my blog.
To kick this one off, I am going to simply discuss a file that stores information on how an iOS device was setup. This is a file that I am asked about a few times a week. In many cases, it matters if the user synced from iCloud, started from scratch or restored from iTunes. So here goes!
First, you should be obtaining an encrypted backup at a minimum. If you have the ability to get a full file system dump, even better. Without encryption, I cannot guarantee that all of the files I plan to discuss in upcoming blogs will exist. Make sure your analytical tool of choice will decrypt the data. If you are trying to do this for free follow the steps below.
Creating and parsing an encrypted iOS backup for FREE:
Launch iTunes on your forensic workstation. Update if necessary.
Make sure you Trust the computer on the iPhone.
Create an encrypted backup with a password you will remember (yep, people forget all of the time!)
If you aren’t using a commercial tool or one that supports decrypting the backup, you may have to get crafty. I stumbled upon AnyTrans during my updates and it’s pretty sweet. To use this, you must know the password or crack it (refer to other blog posts in my archives.)
Launch AnyTrans and it will show you if you have locked backups.
6. Select the locked backup (you know it’s locked because the option is to “unlock” it.
7. Enter the password and the backup will be unlocked! The top portion shown below is how the backup directory will look. The original backup remains and the unlocked version is called BackupUnlock. If you peek inside that directory, you will find the backup with the date it was unlocked.
8. From here, you can load the unlocked backup into iBackupBot or your tool(s) of choice (iExplorer, etc.). Note: Some commercial tools HATE this format and will not support it. The free ones seem happy enough!
Now let’s get to that file you care about. Once your backup or image is loaded into your tool, you need to locate the following file: /Library/Preferences/com.apple.purplebuddy.plist. I normally just search for purplebuddy.
This plist stores the SetupState of the device which will tell you how the device was setup by the user.
If the user selected to restore a backup from iCloud, the com.apple.purplebuddy.plist will show:
If the user setup the iPhone using iTunes, the com.apple.purplebuddy.plist will show:
It is worth noting that I am testing on an iOS 12.1.x device and I restored from iTunes in 2 ways to obtain these results. First, I wiped and set up via iTunes and then I also forced a restore of a backup via iTunes. I wanted to be sure the SetupState didn’t change. If you find that the user restored from iCloud, consider pulling cloud data if you are legally capable of extracting that form of evidence. Should you find the user restored from iTunes, you now have to find that host computer to do analysis on other potential backups. This is where the fun begins!
Bottom line, Apple has a ton of plists that are relevant. You need to hunt for them. Do a keyword search, dump your device (yep, use the free way I described above) and VALIDATE!!!
If you want to watch the webcast, check it out here: https://www.youtube.com/watch?v=AC2TpWsLPLQ
CAUTION: iBACKUPBOT and iOS10+ potential issues.
Below I am attempted to do the same thing with iBackupBot, but I ran into iOS version issues.
Launch iBackupBot
Make sure you Trust the computer on the iPhone.
Create an encrypted backup. Notice that the tool is telling you that Backup encryption is turned on? This is good.
4. Select where to save the backup image. I recommend into your case directory for the investigation.
5. The backup will be created and then you can open it in iBackupBot for analysis. Once the backup is complete, it will prompt you to open it. If you have issues, this is an iOS10 error from what I have seen. :/ At this point, revert to iTunes.
If you are wondering where I have been, the answer is easy – busy! But I haven’t been ignoring you. Since joining Cellebrite, I have been working on sharing my research through their channels. To be honest, between that and SANS, I haven’t had time to blog on my own. So, here is just my promise to you – I will have another blog on here soon. Most likely on mobile acquisition techniques and iOS 13. I need to update some of the older posts anyway.
If you have missed my work, check out the following new stuff:
CellebriteWebinar – http://bit.ly/2kx61bR – Mastering the Mobile Device Challenges in eDiscovery – Do not let the term eDiscovery sway you from listenting to this. Here, I provided a preview of Physical Analyzer 7.23 as well as hints on what is coming in new releases. Learn about redaction, advanced searches and Legalview.
CellebriteWebinar – http://bit.ly/2kF09NJ – Fantastic Android Encryptions and How to Defeat Them – ‘nuf said
OSDFCON – iOS Sysdiagnose Bugs – Speaking with Mattia Epifani
ICAC NW – Speaking on Smartphones: How to Reach the Summit When You Have a Mountain of Data
DFIRCON 2019 –https://www.sans.org/event/dfircon-miami-2019/courses/Teaching FOR585, Running DFIR Netwars with Eric Zimmerman and doing an @Night on A Wild Goose Chase: Hunting For Hard to Find Smartphone Apps and Malware
Published articles – I will tweet about them
A new podcast… just wait for it! I am better at talking when I think of something vs taking the time to write it all down. This is going to be fun!
As always, I will be teaching FOR585 around the world so look out for me. for585.com/course to see where not only me, but the team of instructors who support this are also teaching. We hope to see you there.
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 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 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.
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:
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.
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.
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:
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.
I have been meaning to get this out for a bit, so here it is. Something has been keeping me busy – you know kids, work, SANS and being all in the same place together 24 hours a day. 🙂
The forensic 4Cast awards by Lee Whitfield have really become quite a “thing” for many. It’s such a great idea and Lee, well done. You , my friend, give people and companies some to strive toward and I love it.
Let’s get right to it. Opinions are my own and for that if you do not like them, no need to worry. Everyone has their own opinions and some simply want recommendations. Do I work for a vendor – yes. Do I sell training via SANS – yes. Do I have my own brain – YES!
I give a brief snippet for some, but not all. If you want to know who I really nominated, ask me. 🙂
DFIR Commercial Tool of the Year
UFED Ultimate
Elcomsoft Cloud Tools
Oxygen Forensic Detective
Magnet AXIOM
DFIR Non-commercial Tool of the Year
iLEAPP
KAPE
Sysdiagnose scripts – Mattia
Epifani, Adrian Leong, Heather Mahalik
Sysdiagnose research – Mattia Epifani, Adrian Leong, Heather Mahalik
Axi0mX – checkm8 – need I say more?
DFIR Newcomer of the Year
Geraldine
Blay – She lives for DFIR, tests for everyone and is starting to blog
Josh
Hickman – Blogging, providing public images and staying on top of forensics
DFIR Mentor of the Year
Alexis Brignoni – community contributions and work
Scott Lorenz – EDL support and guidance
DFIR Resource of the Year
Cellebrite Ask The Expert (Tip Tues, ATE series) – Provides snippets of information to make you smarter each week.
Heather Mahalik – Cellebrite – Yes I am laughing, but again with the busting my butt thing to spread knowledge
Digital Forensics Discord- A. Rathbun created this and it rocks
DFIR Team of the Year
Cellebrite – I love my teammates. My SANS teammates wonder who I love more.
SANS – See item 1
Magnet – I have tons of friends at Magnet and they have good morale
Digital Forensic Investigator of the Year
Mattia Epifani – He researches, blogs, teaches and PRODUCES! This man never sleeps.
Shafik Punja – Continuous support to detecting and reporting bugs to vendors to make DF better for everyone.
Ian Wiffin – Thinking outside of the box and developing tools to fill the gaps that commercial tools have yet to address.
So, some shameless plugs in there, but why not – my opinions right? Some categories were harder than others to pick just one, but you have to go with your guy. You will notice that I didn’t nominate Eric Zimmerman (my good friend) for Investigator of the Year. He is the Meryl Streep of the 4Cast! Time for the Hall of Fame Eric. 😉
Working from home, social-distancing, travel restrictions, and homeschooling all related to COVID-19 have changed our lives. The new normal is not always fun, to be honest. This is why “Life Has No Ctrl+Alt+Del” was created. I wanted a forum where we could casually get together, but also include a way for us to stay engaged.
This is an online meetup/show that happens several days a week to enable you to listen, see and share with others in this community. It is not a formal presentation, sales pitch or place to bore you. It’s an open forum where anyone is welcome to speak! This meetup is supported by Cellebrite, but it’s not a Cellebrite centric event – it’s a DFIR event. Curious, join for at least one!
When: March 30th week – every weekday; after that M, W, F weekly
Host: Heather Mahalik (may have subs, if needed)
Guest Stars: Announced Weekly – Each star will decide if they want it to be recorded – all recordings will be shared!
Hashtag: #DFIRatHome
When you think of this show, I want you to imagine having lunch with friends when a cool conversation spikes. It’s literally that relaxed! I hope to see you on the show soon.
First, thank you to everyone for humoring me and submitting jokes. If we cannot laugh at ourselves, we are way too serious. Here are some of my favorites from the DFIR Summit. On a positive note – always try to find the humor in the situation. Especially with all that 2020 has thrown our way. Laugh and smile.
*Due to covid-19 all TCP applications are being converted to UDP to avoid Handshakes..!!
*Bill Gates walked into an APPLE store and farted but it was APPLE’S fault that they had no WINDOWS
*Do you know why I like UDP jokes?” “I don’t care if you get it or not.
*Why doesn’t Tigger have any friends? Because he plays with Pooh!
*What concert costs just 45 cents? 50 Cent featuring Nickelback!
*This graveyard looks overcrowded. People must be dying to get in.
*On a Friday, its a five minute walk from my house to the bar. It’s a 35 minute walk from the bar to my house. The difference is staggering.
*How can you find a blind man on a nude beach” … come on… it’s not that hard.
*What do dentists call their x-rays? Tooth pics
*Why did the first restaurant on the moon go out of business? It had no atmosphere
*Why do ducks have feathers? To cover their butt quacks!
*My friend said he didn’t understand what cloning was. I said that makes two of us.
*A guy walks into a psychiatrist office fully naked and wrapped in saran wrap from head to toe. The Psychiatrist says I can clearly see you’re nuts.
*Where did the software developer go?! I don’t know, he ransomware!
*I once started a band. We were called 999MB. Unfortunately, we broke up because we couldn’t get a gig.
*When does a joke become a ‘dad’ joke? When it becomes apparent.
*Which computer has the best voice? A Dell.
*How do astronomers organize a party? They planet
*I always knock on the fridge door before opening it. I do it just in case a salad is dressing!
*At a job interview I continued filling my glass of water until it overflowed. “Nervous?” asked the interviewer. “No, I always give 110%”
*Why do milking stools have 3 legs? Because the cow has the udder
*Want to hear a construction joke? I am still working on it!
*Did you hear about the guy who invented the knock-knock joke? He won the ‘no-bell’ prize.
*what made the tomato red/blush? it saw the salad dressing
*a pirate walks into a bar. the bartender notices a GIANT ship steering wheel coming out of his pants. the bar tender asks “hey man, whats with the giant wheel?” the pirate answers (in pirate voice): “Yarrr, its driving me nuts”
*I pulled a muscle digging for gold… Just a miner injury
*I would not buy anything that’s Velcro, it’s a total rip off
*Why did Adele cross the road? To say hello from the other side
*What happens when you go to the bathroom in France? European
*One snowman turns to another snowman and says… “Is it just me, or do you smell carrots too?”
*Where did the military hide their armies? In their sleevies
*What do computers and air conditioners have in common? They both become useless when you open windows.
*There was a gorilla in my garden this morning. He stole my gnomes, my gate, my lawnmower. I didn’t want to say anything in case he took offense.
*Does anyone have any good elevator jokes? They’re just good on so many levels!
*I applied to be a doorman but didn’t get the job due to lack of experience. That surprised me, I thought it was an entry level position.
*I tell dad jokes, but I don’t have kids. Does this make me a faux pa?
*How many developers does it take to change a light bulb? None it’s a hardware problem.
*What are you called if you see a crime at an Apple Store? – An iWitness
*Why should you never trust stairs? They’re always up to something.
*What kind of shorts do clouds wear? Thunderpants
*Why did the duck get arrested? For selling quack
*How much do pirate earrings cost? A buck an ear.
*Have you heard the steak pun? It’s a rare medium well done.
*what did the fish say when he hit the wall…dam
*Why don’t ants get sick? Because they have little antibodies
*What do you call an elephant that doesn’t matter? An irrelephant.
*A chicken coup only has two doors. If it had four, it would be a chicken sedan
*I hate when my wife gets mad at me for being lazy. It’s not like I did anything
*What type of shoes do frogs wear? Open toad
*Why didn’t the invisible man take the job? He couldn’t see himself doing it!
*I take an extra pair of pants when I golf, just in case I get a HOLE IN ONE!
*I got fired from my job at an orange juice factory, I couldn’t concentrate properly
*My wife just completed a 40 week body building program this morning It’s a girl and weighs 7lbs 12 oz
*Researchers have discovered a pod of whales playing instruments. It’s an orca-stra
*bought a cute dog a few days ago. Every time when the doorbell rings he goes to the corner….. it’s a boxer
*Don’t worry if you miss a gym session. Everything will work out.
*What do you call it when Batman skips church? Christian Bale
vWhat do you call a cow that just gave birth? Decaffeinated
*What didn’t the toilet paper cross the road? It was stuck in a crack
*What do sprinters eat before a race? Nothing. They fast
*Why are spiders so smart? They can find everything on the web.
*Why did the cryptographer send back his breakfast? Because the hash wasn’t salted.
*How do you make a tissue dance? You put a lil boogie in it
*Why do cows wear bells? Because their horns don’t work.
*How does a computer get drunk? A. It takes screenshots.
*What do you call it when you have your mom’s mom on speed dial? A. Instagram.
*A man was talking with a psychiatrist saying, “I’m a teepee. I’m a wigwam. I’m a teepee. I’m a wigwam.” The psychiatrist said, “Relax man, you’re two tents.
*why can’t you run while camping? You can only ran because it’s past tents
*Why do cows have hooves and not feet? They lactose
*I went camping, it was intents
*Why can’t a nose by 12 inches long? Because then it would be a foot
*I changed all my passwords to Kenny. Now I have all Kenny Loggins
*How do you make holy water? You boil the hell out of it
*It’s hard to explain puns to kleptomaniacs because they always take things literally
*What is the only car that can safely drive over a speedbump at 70mph?A rental car
*How do you get a squirrel to like you? Act like a nut
*Knock, knock Who’s there? Little ol’ lady. Little ol’ lady who? I didn’t know you knew how to yodel.
First, I would like to thank Heather Mahalik for her help with this process and for allowing me to post something on her blog. It’s an honor! Additionally, thanks to Jared Barnhart for his assistance with research and with testing.
During my last examination and analysis, I learned some interesting things and would like to share them with you. After the examination of an Apple iPhone 7, I discovered some photos were captured using the camera application (com.apple.camera.CameraMessagesApp) from within the native iPhone messaging application (com.apple.MobileSMS). As a result of photos being captured, several files were created that I haven’t observed during my past examinations and I had a few questions.
Was this because I was examining a full file system extraction?
or
Was it because I haven’t been paying close enough attention during my exams?
Either way, I set out to test and validate what I discovered.
Suspect’s Device: Test Device:
Apple iPhone 7 (A1778) Apple iPhone XS (A1920)
iOS 13.4.1 (17E262) 13.5.1 (17F80)
During testing, I did not find any significant changes between 13.4.1 and 13.5.1 that would make the testing invalid. I did notice when looking an iOS 12.*.* FFS extraction there were some differences.
Acquisitions:
After Fist Unlock (AFU) Full File System (FFS) (Suspect’s device and test device).
While examining the suspect’s device and analyzing the data, I had a few questions about the data being displayed and how it was created. I formulated a few scenarios that might help demonstrate and explain what happened:
Scenario #2 – What happens when a photo is captured from within native iOS messenger, sent as an attachment message and the message that contained the attachment is later deleted from the conversation thread (/private/var/mobile/Library/SMS/Attachments/)?
Scenario #3 – What happens when a photo is captured within native iOS messenger, sent as an attachment message and the photo sent as an attachment is later deleted from the Photos Application (/private/var/mobile/Media/DCIM/)?
Scenario #1 – What happens when a photo / live photo is captured using the camera application within native iOS messenger and sent as an attachment:
During the testing I followed the steps below to capture both photos and live photos:
Launched the native iOS messenger application (Figure 1.1) and entered a conversation thread (Figure 1.2).
Figure 1.1
Figure 1.2
From the conversation thread clicked the camera icon (Figure 1.3), a photo was captured (Figure 1.4) and clicked done (Figure 1.5). Note: Figure 1.5 this is a preview of the photo that can be sent. But wasn’t this a photo that was captured?? Thanks to Jared Barnhart’s help, I learned this photo is in fact saved to the device even if the user chooses to “Retake” the photo. This photo will be stored in the /private/var/mobile/Containers/Data/PluginKitPlugin/<UUID>/tmp/ folder.
Figure 1.3
Figure 1.4
Figure 1.5
A preview then appeared (Figure 1.6) and clicked the up arrow to send the photo to its recipient without any text (Figure 1.7).
Figure 1.6
Figure 1.7
Now let’s take a look at what happens within the device when these actions occurred.
The application usage and applications in focus was recorded within the KnowledgeC database. There are several resources and published research about the KnowledgeC database and what can be found within it. I would encourage you to take the time to review the list of references and other sources at the end of this blog.
8:21:22 PM – 8:22:54 PM the application (com.apple.MobileSMS) was launched and in use.
During that time:
8:22:01 PM – the back camera was turned on
8:22:03 PM – the application (com.apple.camera.CameraMessagesApp) was launched and several cached locations were created and stored in Cache.sqlite – ZRTCLLOCLATIONMO table. These locations were accurate for where the device was located during testing. If you have additional questions about location data please see Ian Whiffin’s presentation in the list of resources.
8:22:03 PM – Miscellaneous file path locations were opened, modified and created related to \private\var\db\uuidtext\. I haven’t researched or decoded any of these but wanted to mention it.
Figure 1, Figure 2, Figure 2.1 Figure 3 and Figure 4 are examples of how different tools represented the launched applications and what was decoded.
In Figure 4 we can see this plist can be viewed within AXIOM and could also be viewed within PA. I saved, exported and opened the plist using Ian Whiffin’s Mushy plist viewer. See Figure 4.1. The plist contained the phone number and the associated UUID’s for the device the attachment message was sent to.
Figure 4 – AXIOMFigure 4.1 – Mushy Plist Viewer
This plist was also in the suspects device and contained a list of phone numbers and their associated UUID’s. There appears to be different property lists for different types of messages sent:
At 8:22:20 PM a live photo of my friend Dexter was captured, which resulted in several files being created on the device to include the following:
Each tool used to examine the test data, put these files in a different order in the timeline, but they all had the same capture and created time of 8:22:20 PM. See Figure 5.
Figure 5 – PAFigure 5.1 – AXIOM
Figure 5.1 within AXIOM – Timeline, there is an event for an entry being made into the Photos.sqlite database. See Figure 5.2 and Figure 5.3 for more details.
Figure 5.2 – AXIOM
Photos.sqlite information
Figure 5.3 – Photos.sqlite – PA
In Figure 5.3 we are looking within PA SQLite Viewer and looking at the Photos.sqlite database ZGENERICASSET table. Notice that all of the PK values are in sequential order and there are no missing values, indicating that the list is complete. I just stated when I took a photo of Dexter there were multiple files created to include IMG_0012.MOV. Where is the information about the additional files? More on this is to come in this blog.
Notice in Figure 5.3 there’s indication that an entry was also made in Photos.sqlite ZADDITIONALASSETATTRIBUTES table. Notice AXIOM is indicating that both the Z_PK value and the ZADDITIONALASSETATTRIBUTES value are the same. More about this later in the blog. Got to give a big shout out to Ian Whiffin here. I first noticed these values when viewing the full file system dump from within his tool Artifact Examiner (ArtEx). I reached out to him with a few questions, which he answered right away. It helped so much while examining the suspect’s device…Thanks Ian!! See Figure 6.
I wanted to take a minute and discuss some of the items I discovered while examining at the ZADDITIONALASSETATTRIBUTES table. First notice, that Z_PK entries 1-6 do not have a date in the ZEXIFTIMESTAMPSTRING column. These images were not captured with the test device. They were sent to the test device as MMS from an android device. These photos were then saved to the photos application via the native iOS messenger application. Notice the ZCREATORBUNDLEID indicates com.apple.MobileSMS. See Figure 7.1.
Figure 7.1 ZADDITIONALASSETATTRIBUTES table
Z_PK entries 7-11 and 17-22 were captured with the test device native camera application, launched from the springboard. Notice there isn’t an entry for ZCREATORBUNDLEID, but there is a value for ZIMPORTEDBY. Using the suspect data and the test data, I believe I’ve decoded some of the values. These are preliminary and require additional testing:
0 = Is related to .MOV files.
1 = Captured via native Back facing camera
2 = Captured via native Front facing camera
3 = Third Party Application – Snapchat
6 = Third Party Application – Facebook
8 = Captured via native Back facing Camera
9 = Saved from outside source (SMS, Safari)
Notice there is a binary property list located in the ZREVERSELOCATIONDATA column for each one of these entries. Location services was active for the camera application when the photos were captured. Notice that entries 21 and 22 do not have binary property lists. These photos were captured minutes before the device data was extracted. I believe data did not have time to populate this field prior to the device being acquired. I will discuss the contents of this bplist later in this blog. See Figure 7.2 and Figure 7.3.
Figure 7.2, Figure 7.2.1 and Figure 7.2.2 Screenshots of test device location services settings
Figure 7.2
Figure 7.2.1
Figure 7.2.2
Figure 7.3 ZADDITIONALASSETATTRIBUTES table – PA
Z_PK entries 12-16 were captured via the Camera Application from within iOS Messenger. See Figure 7.4.
Something to notice here…ZORIGINALFILENAME column. All of the photos captured using the CameraMessagesApp have an UUID as the original file name. If you remember when I was discussing the Photos.sqlite – ZGENERICASSET table, these files are not listed in the ZFILENAME column. Another note, only the JPG files that were created are listed. Remember there were several files created as the result of me capturing a live photo of Dexter using the CameraMessagesApp:
Date, Times and Time Zone:
Notice in the ZADDITIONALASSETATTRIBUTES table ZEXIFTIMESTAMPSSTRING column and the ZGENERICASSET table ZDATECREATED column the dates and time values are being stored in different formats. The values in the ZDATECREATED are natively stored as unix epoch and require conversion, but the values in ZEXIFTIMESTAMPSSTRING column are being stored according to the device time settings when the files were captured. In the test device, the date and time settings were set to auto and the time zone was set to Cupertino also known as Pacific Time (UTC -8 or -7…damn DST). There are other columns within the database that record the time zone setting at the time the files are created ZADDITIONALASSETATTRIBUTES table ZTIMEZONEOFFSET, ZINFERREDTIMEZONEOFFSET and ZTIMESONENAME columns.
Orientation:
In ZGENERICASSET table there is a column ZORIENTATION. Using the test device data, I determined 1 = Horizontal and 6 = Vertical. The photos I sent from an android to the test device had both horizontal and vertical original orientations. When they were saved to the test device, all of the photos were saved with a horizontal orientation.
Locations:
In Figure 5 from Physical Analyzer, there is no location data being parsed for the photos that were captured using the CameraMessagesApp. After closer analysis, I could not locate any location data that was recorded within the EXIF data or database metadata for any of the items that were created with com.apple.camera.CameraMessagesApp application. During testing, location services was tuned on and the location was recorded for the files captured with the native camera (com.apple.camera), just not the files captured with com.apple.camera.CameraMessagesApp. Not sure if this is a security feature to conceal the location because the files are being sent via messenger. Note: I did a brief overview of the file at the hexadecimal level and did not find any location data. Additional analysis and research might be required to for a definitive conclusion.
In Figure 8 I have highlighted the columns related to the ZREVERSELOCATIONDATA column. Notice the ZREVERSELOCATIONDATAISVALID column and the values are 1 and 0. I believe based on the test data the values indicate 1 = If available has been populated and 0 = If available has not populated. This also appears to be related to ZGENERICASSET – ZANALYSISSTATEMODIFICATIONDATE. The items with a value of 0 in the ZREVERSELOCATIONDATAISVALID were also missing an Analysis State Modification Date. Additional testing and acquisitions are required for further analysis.
Let’s take a look at ZREVERSELOCATIONDATA bplist. This plist can be viewed from both Cellebrite PA SQLite Viewer and Magnet AXIOM SQLite Viewer, but like I stated earlier I used Ian Whiffins tool Mushy Plist Viewer. The locations discovered within this bplist were accurate as to where the device was located at the time the photos were captured. See Figure 8.1 and Figure 8.2.
Figure 8 we can see the ZADDITIONALASSETATTRIBUTES table – PAFigure 8.1 ZADDITIONALASSETATTRIBUTES table ZREVERSELOCATIONDATA column – PAFigure 8.2 ZREVERSELOCATIONDATA Plist in Mushy Plist Viewer
There is a significant amount of data being stored within the Photos.sqlite database and there has been recent research and publications about this database by researchers far more advanced than I. I would strongly encourage you to review the reference material list at the end of this blog for additional details and links to the other research.
As a result of my research, I created a SQLite query that can be used to parse out some of the data from the Photos.sqlite. Please test and validate prior to using within your cases. Some of the column headers have long names that should allow you to decipher where the data is coming from. This should also allow others to improve upon it so it can be used within open source tools. Here is a link to a google drive for the script:
Original file name & /private/var/mobile/Containers/Data/PluginKitPlugin/<UUID>/tmp/:
After running the SQLite script in Navicat (paid) and DB Browser (free), I exported the output into a CSV. For this portion, I will again focus on the live photo that was created at the start of this presentation (IMG_0012.JPG). Figure 9 is a portion of the output to show how the files are related:
Figure 9 SQLite script output
Notice the original file name for IMG_0012.JPG is 61777214080__90B95980-BB3C-4A7A-B74E-82C62C923CC2.JPG.
During the examination of the suspect device, some of the files created during this testing process were located, but the more obvious files that should have been present appeared to be deleted. What does that mean??
In the suspect’s device, I located files being stored in the /private/var/mobile/Containers/Data/PluginKitPlugin/<UUID>/tmp/ file location. Notice that I removed the UUID and replaced it with <UUID>. In the suspect’s device the UUID for this temporary file location was different than the one listed in my test device. Here are the two file paths:
When this was discovered in the test device, I believed there had to be documentation which indicated a relationship between the temporary file location and an associated application. Figure 10 is a screenshot from Physical Analyzer that shows the temporary file and a view of the file system. Notice in the file system there is a plist in the root of the “45AAD7D6-8C36-411A-B311-04EAE0B5C470 folder.
Figure 10 – PA
In Figure 11 I exported the plist (.com.apple.mobile_container_manager.metadata.plist) and when viewed with Mushy Plist Viewer, I discovered a “MCMMetadataIdentifier: AsciiString = com.apple.CameraMessagesApp.” This appears to be the application associated with the folder path UUID.
Figure 11 Mushy Plist Viewer
Based on the testing and what was observed in the suspect’s device, I came to the conclusion that if a file was stored in this file path, it was captured/created via the CameraMessagesApp.
Note: This was not the only application that was storing data at /private/var/mobile/Containers/Data/PluginKitPlugin. There are several other applications storing data at this location, to include SnapChat. I haven’t gone into detail about the other data contained here, but it would be very beneficial to analyze this file location to see if any evidence you are looking for could be found here.
Scenario #2 What happens when a photo is captured from within native iOS messenger, sent as an attachment message and the message that contained the attachment is later deleted from the conversation thread:
In Figure 12 we can see within PA a file, IMG_0014.JPG, that was captured using Camera Messenger Application. When this photo was captured Live Photos was turned OFF. The photo was captured, attached to a message and then sent to another device. At a later time, the sent message with the attachment was deleted from messenger. In this instance the files that remained on the test device were stored at:
Note: In this example there wasn’t any text in the message only the attachment.
Figure 12 – PA
I thought this might be a great time to change my PA Duplicates settings. I entered the setting and changed “Multiple Extraction” settings from not merging similar items to merge similar items. I then closed the case and reprocessed the extraction.
After reprocessing the data, I noticed all of the similar files were merged based on their hash. I then filtered the merged photos based on the temporary file location /private/var/mobile/Containers/Data/PluginKitPlugin/45AAD7D6-8C36-411A-B311-04EAE0B5C470. See Figure 13.
Figure 13 – PA
In Figure 13, all of the duplicates and similar items are merged with each other, hence the layered squares icon on the bottom left of each photo. When examining the icon notifications within Physical Analyzer, I noticed two icons were missing from the highlighted photo. One was the outgoing message icon that indicates a message was sent and the other was the paperclip icon used to indicate attachment. These icons are missing because the message and the attachment were deleted from the message thread. When the message and the attachment were deleted, the associated file being stored at /private/var/mobile/Library/SMS/Attachments/ was deleted. I could not locate the file and it appeared to be removed from the device as soon as the message was deleted.
In Figure 12 the other files being displayed were created via the same method as the one highlighted.
NOTE: It was not this easy when I was examining the suspects device!! There were thousands of photos and I had no idea what I was looking for or what I was looking at once these were found.
Scenario #3 What happens when a photo is captured within native iOS messenger, sent as an attachment message and the photo sent as an attachment is later deleted from the Photos Application:
In Figure 14 we can see within PA a file, IMG_0013.JPG, that was captured using Camera Messenger Application. When this photo was captured Live Photos was turned OFF. The photo was captured, attached to a message and then sent to another device. At a later time, the photo being stored at /private/var/mobile/Media/DCIM/100APPLE was deleted. Luckily, I was able to extract the device data before it the photo was removed from “Recently Deleted.” In this instance the files that remained on the test device were stored at:
Notice in Figure 14 there is an indication that IMG_0013.JPG was deleted or is in the trash/recently deleted. Unfortunately, at the time this blog was published, the amount of time necessary for the recently deleted photo to permanently delete hasn’t passed. I will complete a follow up blog posting to let everyone knows which files remain after the photos application (/private/var/mobile/Media/DCIM/100APPLE/IMG_0013.JPG) photo gets permanently deleted. Additional testing and device acquisitions to be completed in the near future.
Figure 14 – PA
Let’s take a look at what this looks like in via the SQLite query that was written for the Photos.sqlite database. See Figure 15. Notice that there is a status column for File Trash State and another column File Trash Date.
Figure 15
Magnet AXIOM File Relationship using Connections:
After my research and testing it’s been determined the files created with com.apple.camera.CameraMessagesApp are related and wanted to see if AXIOM connections feature would relate these files. The only connection that was displayed was through the matching file hashes. See Figure 16.
Figure 16 – AXIOM
Summary:
During this blog we discussed some additional file locations that should be analyzed if you have a iOS Full File System extraction.
You should check the Photos.sqlite database and review the original file names. This could indicate the existence of additional files to analyze and if a full file system extraction would be beneficial to your investigation.
The /private/var/mobile/Containers/Data/PluginKitPlugin/<UUID>/tmp file location can hold vital data that might not be present in other extractions. It can also contain files that were deleted by the user and may not exist elsewhere.
You should also check Photos.sqlite creator bundle ID which could indicate which application was being used to capture the photo. Using this information, you can locate the appropriate /private/var/mobile/Containers/Data/PluginKitPlugin/<UUID>/tmp file location that can be examined for additional files.
I couldn’t have completed this research without help from the other outstanding and knowledgeable professionals who have been doing this type of work long before I even acquired my first cell phone. I would like to take this time to say thanks to everyone who shares their experiences with the community and list some resources that I have used during my forensic examinations and hope it can help you as much as it helped me.
Thanks, for going on this journey with me and please feel free to contact me if you have any questions about this research blog. As always, please test and validate your findings and take time to share!
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.
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
PA Photos
Notes: var/mobile/Containers/Shared/AppGroup/group.com.apple.notes/NoteStore.sqlite – parsed by commercial tools
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
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.
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!
It’s that time of year again – the Forensic 4:Cast awards season and nominations are open. Last year I won 4 awards and my team won an additional 2! It was mind blowing and humbling. Thank you again if you voted for me.
I have taken the time to think over the last two weeks on who I want to nominate and why. Last year I played it safe and made suggestions. This blog is going to be honest about who I personally nominated and why. Take it as suggestions if you are still unsure about who to nominate and why. Note: these are my personal opinions, not those of my company or SANS! https://forms.gle/r7XwVwdoUFR4We4X9
DFIR Commercial Tool of the Year – Cellebrite Physical Analyzer
PA (Physical Analyzer) has made a difference in every smartphone case I have worked. I have used this tool since it’s been logical analyzer and I have witnessed the progress and the growth over the years. Now that I work at Cellebrite, I am able to see what is coming, changes made and sprint plans. I love that I am able to push feature requests and see them integrated. While mobile may be a small facet of DFIR, Physical Analyzer adds major impact and deserves this award.
DFIR Non – commercial Tool of the Year –ArtEx
Ian Whiffin, the mastermind behind ArtEx is also a friend and co-worker of mine. ArtEx is brilliant to say the least and is a tool I rely upon to conduct iOS testing and validation. It is the fastest way to get answers without extracting and parsing data! Not only is ArtEx my new tool of choice for iOS testing, but Ian’s blogs are helpful and detailed! If you find ArtEx is missing something you need – ask Ian! Check it out: https://www.doubleblak.com/blogs.php
DFIR Show of the Year – Life Has No Ctrl+Alt+Del
This show, created by (me) Heather Mahalik and sponsored by Cellebrite has been running for exactly a year at this point. When COVID happened, I wanted a way to cheer up the DFIR community and I created a show that ran at lunch 5 days a week. That lasted 2 weeks and then I cut it back to 3 days a week. That lasted 2 months. After trying to book fresh speakers for each episode, I cut it back to Mondays and it’s still going strong! This show is about us – the DFIR community and what we know, want to know and is a forum to relax, make friends and collaborate. Check it out and start joining on Monday! https://www.cellebrite.com/en/series/ctrl-alt-del/
DFIR Blog of the Year – CellebriteAsk the Expert
My brilliant co-workers and I have been working on a series called Ask the Expert where you, the community, select topics and we record videos and write blogs on that topic. It’s current, relevant and is ongoing. Check it out here: https://www.cellebrite.com/en/ask-the-expert/
DFIR Book of the Year – iOS Research & Exploration Volume I
James Duffy wrote this book and it’s helpful in understanding key terminology and concepts for iOS devices.
DFIR Article of the Year –How to use iOS Bluetooth Connections to Solve Crimes Faster
This blog https://www.cellebrite.com/en/how-to-use-ios-bluetooth-connections-to-solve-crimes-faster/ was written by Matt Goeckel and myself and literally includes 3 years of research. It has been accepted by the DFIR Review and is hosted on that site as well. Matt and I were both researching this topic for the same Detective before ever meeting. Ironic that our worlds collided and we finished the research and closed the loop. Sharing is caring and Matt and I really do care.
DFIR Social Media Contributor of the Year – Me :)
I bust my butt on social to keep everyone informed and entertained. So nominate me. @heathermahalik on Twitter if you don’t follow me.
DFIR Training Program of the Year –SANS Cyber Camp
Lee Whitfield created the SANS Cyber Camp that ran 2 times in 2020. He recruited experts from the field to create fresh content and labs for teens around the world. Best part – it was FREE! Let’s face it, we aren’t getting any younger so the next generation of DFIR professionals need to be trained correctly and by the right people.
Most Valuable Threat Intel Contribution – STAR Webcast
DFIR Groundbreaking Research of the Year – Cellebrite Qualcomm Live in UFED
In my job, I need full file system extractions, especially with Android. UFED supports a ton of devices for full file system extractions under the Generic Qualcomm Live option. This hidden gem has helped me so many times I can’t even count!
DFIR Newcomer of the Year –Jason Wilkins or Sahil Dudani
I recommend both! Jason and I met on Life Has No Ctrl+Alt+Del (show of the year nomination) and we have been friends since. He is a loyal follower of the show and loves to learn! Show your love to Jason.
Or Sahil Dudani who I met during my FOR585 course a few years ago. Sahil is now an intern at Cellebrite as he works on his PhD at Virginia Tech. He is a go getter and will make big waves in DFIR!
DFIR Resource of the Year –Cellebrite Capture the Flag
The Cellebrite CTF was a labor of love and was a huge team effort between the Dream Team, Cellebrite Training, IT, Marketing and Product. If you haven’t created a CTF, you won’t understand the amount of work it takes to create solid datasets, create questions and run the CTF. Every second was worth it to see the participation and the outcome. And now 4 public images have bene provided for testing and training! Please nominate us. https://www.cellebrite.com/en/cellebrite-capture-the-flag-follow-up-our-experts-review-the-questions-and-answers/
DFIR Team of the Year –Cellebrite
I have been with Cellebrite for almost 2 years and I can say I work with the best people on the planet. They are my nearest and dearest of friends and I trust them. I haven’t even been a part of a team where everyone cares as much as I do and at Cellebrite we all care. If you haven’t heard of the Dream Team, it’s because you haven’t attended Life Has No Ctrl+Alt+Del or I Beg to DFIR. The Dream Team is one tiny part of the entire time. We work hard and we play hard. (Note: Matt Goeckel and Ian Whiffin are missing from this pic)
Digital Forensic Investigator of the Year –Paul Lorentz
See the guy on the right in the picture above? That is Paul. If you don’t know him you should try your best to meet him. I have learned so much from Paul since being at Cellebrite. He is the master of knowing every single make, model, version, lock, encryption type and more for Android. It’s creepy scary with how much he knows off the top of his head. Not only is Paul and Android master, he loves helping customers and is always researching and sharing his findings. When you ask me questions, I guarantee Paul is on the response and helping research the solution. Paul has contributed to so many in 2020 and he deserves this aware. If you want to see some of his work, check out the webinars, join I Beg to DFIR, watch Life Has No Ctrl+Alt+Del (he is running a game show the first Mon in April) and follow him on Twitter @PaulScurvy.
I have been meaning to update this blog for years, so here goes. This blog is going to cover what I recommend to get the most data from iOS and Android devices. Many tools exist to successfully extract data from mobile devices and I am sharing some of my favorite methods that have proven to be successful for me over the years.
ANDROID Acquistion
Since most devices are using File Based Encryption (FBE), physical acquisition may not be possible. For devices that can be physically acquired, that should render the most data. The next best option to collect the most data from the phone is Full File System access. HOT devices should be acquired quickly. To explain HOT – If the device is in an AFU (after first unlock) state, make sure you acquire it and ensure the device doesn’t reboot, if possible. A reboot will put the device into a BFU (before first unlock) state and may be difficult or impossible to acquire without the passcode.
Obtain a Physical or Full File System extraction with Cellebrite UFED, Premium or Premium ES. These are my preferred tools, others can be used as well.
If a Full File System is not possible for a specific model, verify the chipset and try Android Qualcomm/Qualcomm Live under Generic profiles.
Make sure you open the extraction prior to returning the device to ensure the data is not encrypted!
UFED Generic Profiles
Qualcomm Live Android Option
File System Acquisition
This may simply be a backup and backups don’t get a lot with newer Android devices.
Try Generic Android on Cellebrite UFED if you are not finding the specific model to be working.
Logical Acquisition using a forensic tool – especially if ADB isn’t going well for you. I recommend using more than one tool or a single tool and also capturing an ADB backup for validation purposes.
Note that most tools will install a software agent in order to extract data from the device. This is normal and accepted. If you are ever questioned on what the software agent is doing, simply extract the APK and examine it manually to review the permissions.
FREE WAY – ADB Backup (capture both the device (all) and SD/media (shared))
adb backup –all
adb backup – shared
Make sure you acquire the SD card and SIM card if one is present.
I like to remove these and acquire separately to ensure nothing is overlooked.
Make sure you write-protect the SD card.
Use Cellebrite UFED to conduct a Chat Capture. I love the generic option as any screen can be captured and parsed for analysis.
I like to use chat capture to grab the settings screen of the device and to access application data that may not be extracted with the methods above. This method is great for apps that are not parsed or extracted.
Extract cloud data – IF YOU HAVE AUTHORITY! My tools of choice for this are Physical Analyzer and Elcomsoft. Magnet and Oxygen work well too.
I like to run some ADB commands to the device to ensure I extracted all information and that I am aware of what exists on the Android. The script from Mattia that is mentioned above can capture all of these commands for you with a nice GUI.
ALWAYS open the extraction to ensure you got what you hoped. If you have a physical dump, Autopsy is the fastest you will gain access to your data! And it’s free. (https://www.sleuthkit.org/autopsy/). You can also use FTK Imager or a similar tool that is free for quick access.
Android acquisition leaves traces behind on the device. If you conduct covert operations – tread carefully here. Don’t go too far without knowing the footprint your tools and methods are leaving behind. These topics are covered more in the FOR585 class http://for585.com/course, in blogs and webinars found at https://www.cellebrite.com/en/resources/. Also note that multiple extractions may be necessary to capture the most information from these devices.
iOS Acquisition Recommendations
For iOS acquisition my methods have remained steady and I am not as paranoid as I am with Android. You can choose to work on a Windows or Mac. I do both. Honestly, most of my acquisitions take place on my Windows forensic workstation, but I do have a Mac that I use for jailbreaking.
Things you will need:
Install iTunes if you plan to create a backup on Windows. Finder will work on the Mac.
Install iBackupBot (I prefer this tool over the other free ones because of the option to dump the crash logs http://www.icopybot.com/download.htm
Your forensic tools of choice.
ArtEx – if you are examining a jailbroken device. Read Ian Whiffin’s blogs! http://www.doubleblak.com
Recommended iOS Steps:
Determine the iOS device type and type of iOS device.
Obtain a Full File System Extraction.
I prefer using Cellebrite UFED checkm8.
If the device is already jailbroken, I will use Cellebrite UFED Full File System. Other tools will work as well.
If I get a Full File System extraction I stop at this point other than obtaining log files, which is mentioned in steps 6 and 7.
Conduct a File System/Advanced Logical Extraction – YOU MUST ENCRYPT the extraction!
This can be done in most tools. I use Cellebrite UFED and make sure to encrypt the backup. Cellebrite will use 1234 to do this.
If using another tool make sure the option to encrypt the extraction is there or you will MISS a lot of data starting with iOS 13. Refer to my other blogs for more information on this.
If you want to be thorough, obtain a logical and/or backup file of the device. I typically stop at the Full File System or file system dump since it contains the backup if I trust my tool (refer to my old blog for more info on this topic).
Connect the device to iBackup bot and export the crash logs.
Collect sysdiagnose logs and extract them. This can be done nicely with Elcomsoft. More information is at www.for585.com/sysdiagnose
Ensure the tools you used did not enable iTunes encryption by connecting the device to iTunes and making sure “Encrypt Backup” is not selected. This should be performed prior to giving the device back to the suspect/custodian/witness.
Extract cloud data – IF YOU HAVE AUTHORITY! I prefer the same tools mentioned above in the Android part of this blog.
Everyone has their preferences on tools and acquisition methods. A Full File System is the best bang for your buck on most devices. Make sure you validate your extracted data and reach out to the vendors you leverage if issues arise.
When I teach SANS FOR585 Smartphone Forensic Analysis In-Depth, we really dive into iOS artifacts to validate the truth of what happened, what tools are reporting, and what they are missing. Message retention is often needed to help examiners understand why data no longer exists on the iOS device if the user didn’t delete it. When hunting for deleted messages, I suggest students validate the current message retention settings in com.apple.MobileSMS.plist, then examine the messages that are parsed in the tools and compare that to the message table of sms.db. If message retention is set to 30 days and you are looking for older messages, chances are good they no longer exist on the device. If this isn’t the case and message retention is set to forever, get ready to dig and hope for the best because your job just got harder. Bottom line, understanding the values in com.apple.MobileSMS.plist when it comes to message retention can be a time saver.
Apple always likes to change things up and it’s impossible to see everything that has changed right away, even with all the amazing DFIR researchers out there. Sometimes it takes a customer to email with a question on how the tool is behaving. This is why I decided to write this blog. I want to thank that customer and anyone reading this for validating! This is key to our craft in DFIR. I also want to thank Ian Whiffin for hearing me out and sharing screenshots from test devices.
It’s a known fact that I work at Cellebrite with a group of brilliant examiners. Part of our job is helping customers make sense of data. A question came in about message retention and why PA 10 was reporting one thing and the phone showed another. Same day, different question, new bug? Or new method of tracking settings on the device? For this matter, it was a bit of everything. Apple changed the way message retention is tracked in com.apple.MobileSMS.plist. This plist can be located here: /private/var/mobile/Library/Preferences/com.apple.MobileSMS.plist.
The good news is that this file is accessible with an encrypted iTunes backup, advanced logical, and full file system extractions. I didn’t bother testing unencrypted backups because so much data is missed. ALWAYS encrypt the backup.
For as long as I can remember, we have been reading the values from the com.apple.MobileSMS.plist under KeepMessageForDays. The values may be:
KeepMessageForDays = 0 = Forever
KeepMessageForDays = 365 = 1 Year
KeepMessageForDays = 30 = 30 Days
**Note – for iOS 13 and earlier if KeepMessageForDays is missing from the plist, the message retention was set to Forever on that device. According to Ian Whiffin, if the default message retention of Forever is neverchanged (regardless of iOS version), the KeepMessageForDays may also be missing from the plist. We plan to validate this further as we will soon have access to devices where that setting has never been modified and will also look for the new values.
So just when we are comfy with the values in this plist, iOS 17 came along and changed how the values are stored. While the KeepMessageForDays may exist in the com.apple.MobileSMS.plist, it is no longer in use by Apple for tracking message retention in devices that are running iOS 17. The values here seem to reflect old settings of message retention, and not what the device settings currently reflect. Don’t you love when old remnants are left behind that cause confusion?
For iOS 17, we need to rely upon the value stored under SSKeepMessages. The values will be the same as before.
SSKeepMessages = 0 = Forever
SSKeepMessages = 365 = 1 Year
SSKeepMessages = 30 = 30 Days
Testing and Validation:
Ian provided me with 4 examples from test devices and I used 3 of my own test devices and my personal phone. Here are some examples you may come across that I think makes the point of the blog.
iPhone 15 Pro running 17.4.1 – Message Retention is set to Forever and was previously set to Forever in iOS 16.
iPhone 10 running iOS 16.* – was set to forever on iOS 16.1.2. Changed it to 1 year and updated to 16.7.10. Here is what the settings looked like.
The device was acquired using iTunes and the encrypted backup was parsed in ArtEx. Note that only the current setting is shown. The modified date of com.apple.MobileSMS.plist reflects when I made the changes, but other factors could impact the timestamp.
Note that SSKeepMessages does not exist. It’s because this is iOS 16 and this key was added in iOS 17.
iPhone 11 running iOS 17.0 – message retention was set to forever and not changed when updated from iOS 16 to iOS 17. This extraction was parsed in Cellebrite Physical Analyzer 10.3.
The following examples are from iOS 17 devices. Note the lack of KeepMessageForDays. I am providing several screenshots to show the different settings as captured by Ian Whiffin.
iOS 17+ – The default setting is Forever. I am examining the com.apple.MobileSMS.plist in Mushy, a free tool developed by Ian Whiffin.
iOS 17+ – Message retention was changed from the default of forever to 1 year. Again, I reviewed this in Mushy.
iOS 17+ -Message retention was changed from the default of forever to 30 days. I reviewed this in Mushy.
iOS 17+ – Message retention was changed from the default of forever to 365 or 30 and then changed back to Forever.
As I have found in many aspects in life – it takes a village. This is also true in DFIR research. It’s better when we work together and ask questions, which can really make a difference. Imagine how many examiners out there can be helped by one person asking a question! Keep asking and stay tuned for more on this topic in the Notebook on the Cellebrite 101. This is the new community we created to host all tech questions, just like this! As always, trust but validate!
So this blog really covers both, not that I expected major changes in a tiny update.
Makes it easier on us. Thank you Paul for sharing yours – again, I use Chrome. 
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.
