Category Archives: iOS

iOS, Uncategorized

iOS 17- The “Forever” Setting That Isn’t… Or Is It?

1 Comment

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 never changed (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!

iOS

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

4 Comments

 

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.

/var/mobile/Applications/group.com.apple.Maps/Library/Preferences/group.com.apple.Maps.plist

/var/mobile/Applications/com.apple.Maps/Library/Preferences/com.apple.Maps.plist

/var/mobile/Applications/com.apple.Maps/Library/Maps/history.mapsdata

/var/mobile/Applications/com.apple.Maps/Library/Maps/GeoHistory.mapsdad

Android, forensic tool, iOS, Open Source, Uncategorized

My Handy Smartphone Toolbox

2 Comments

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.

forensic tool, iOS, Uncategorized

Time is NOT on our side when it comes to messages in iOS 11

5 Comments

Image result for apple iPhone X meme

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:

  • Contacts- /private/var/mobile/Library/AddressBook/AddressBook.sqlitedb
  • Calls-/private/var/mobile/Library/CallHistoryDB/CallHistory.storedata
  • SMS – /private/var/mobile/Library/sms.db
  • 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.

Image result for keep charging forward meme

iOS, Uncategorized

How the Grinch stole Apple Maps artifacts… or did he just hide them?

6 Comments

Happy Holidays everyone! Tis the time to be relaxing with family or just sitting in your office writing a blog. 🙂 This post is brought to you thanks to a FOR585 Advanced Smartphone Forensic alumni who could not locate an artifact he learned about in class. This artifact is tied to Apple Maps on iOS devices. The file of interest is the GeoHistory.mapsdata, which was introduced with iOS 8 and has been tracking the Apple Maps data since.  This file replaced the legacy history.mapsdata file. This file was required for examination in his case. When he couldn’t find it, he reached out and sent me on a frenzy of testing. Since his question arrived in my inbox, I have been obsessed with figuring out what the “Grinch” did with it.

What I tested (thank you to my brave family and friends for letting me dump your phones for this research):

*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…

  • 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

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

  • Radio City Music Hall, NYC
  • Malvern Buttery

Additionally, I sent my mother in law to the grocery store and had her literally use Apple Maps on her iPhone 6 running 10.1.1 to ensure the data would “stick.”

Once all data was populated, I conducted both iTunes backups, Cellebrite Physical Analyzer File System dumps (Methods 1 and 2 for non-jailbroken devices, Method 3 for jailbroken devices, and Method 1 for devices running 10.2) and BlackLight for acquisition of the data. I tried parsing the data dumps in BlackLight, Oxygen Detective, Magnet IEF, Cellebrite Physical Analyzer and manual examination to ensure I wasn’t overlooking something. I pulled my own cloud data with Elcomsoft and searched for the file in those backups with some luck – wait for that at the end.

When I manually examined the file system of the backups, I started to see major inconsistencies. The GeoHistory.mapsdata file was sometimes present and sometimes not. The history.mapsdata file was there no matter what.  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.

Below is a list of the phones from above showing which devices presented access to the GeoHistory.mapsdata file. (Note: Additional testing was done by Sarah Edwards and Lee Crognale on their devices to confirm my findings – thanks a ton ladies.)

  • iPhone 6s with a fresh install of 10.0.2 – GeoHistory.mapsdata was present and contained Apple Maps data
  • iPhone 7 updated from previous iOS versions running 10.0.2 – NO GeoHistory.mapsdata
  • iPhone 6s updated from previous iOS versions running 10.0.2 – GeoHistory.mapsdata was present and contained Apple Maps data
  • iPhone 7 updated from previous iOS versions running 10.2 – NO GeoHistory.mapsdata 
  • iPhone 6s with a fresh install of 9.3 – jailbroken – GeoHistory.mapsdata was present and contained Apple Maps data
  • iPhone 6s+ with a fresh install of 10.1.1 – NO GeoHistory.mapsdata
  • iPhone 6 updated from previous iOS versions running 10.1.1 – NO GeoHistory.mapsdata
  • iPhone 6s+ updated from previous iOS versions running 10.2 – NO GeoHistory.mapsdata
  • iPhone 7 updated from previous iOS versions running 10.1.1 – NO GeoHistory.mapsdata

Here are some examples of what I was expecting to see:

Example 1: An iPhone that has been updated to iOS 10+.  We know it has been updated because we see the historical History.mapsdata file as well as the GeoHistory.mapsdata.

Example 2: Examining the Hex of the GeoHistory.mapsdata. Below we can see my search for Malvern Buttery.

Example 3: What the data may look like – NOT GOOD! While the file, History.mapsdata, contains legacy searches in Apple Maps, it does not contain any data since iOS 8.

Continuous searching for locations that I populated in Apple Maps lead to two files that seemed to store the most recent search conducted and manual location entry in Apple Maps, but lacked additional artifacts.  The first is /mobile/Applications/group.com.apple.Maps/Library/Preferences/group.com.apple.Maps.plist.  In the example below, I used Apple Maps to search for a location in Sedona, AZ. Keep in mind that this was the most recent Apple Maps search on the device at that point in time ( I was running iOS 10.1.1). Nothing I searched for after that was found in this file.

The second location was mobile/Applications/com.apple.Maps/Library/Preferences/com.apple.Maps.plist. This was the only location where I could find my search for Radio City Music Hall. There was nothing of interest other than the fact that the location was listed with a bunch of yelp reviews.

My current location was not captured, which normally occurs in the .mapsdata files. I think this plist is tracking the last search within Apple Maps where the goup.com.apple.Maps.plist seemed to save the last manual entry in Apple Maps. Again, this is an assumption which requires further testing and research.

From the device side, it seems that the Grinch has stolen the GeoHistory.mapsdata from the following devices/versions:

  • The iPhone 7 running any version starting with 10.0.2 – EVEN devices that have been updated from previous iOS versions.
  • Any iPhone running iOS 10.1.1
  • WARNING: iOS 10.2 presents us with major hurdles and potentially missing artifacts that span beyond the GeoHistory.mapsdata.  Get ready to learn ways around this… check out how it looks in Physical Analyzer below.

From the iCloud perspective. I used Elcomsoft Phone Breaker to extract my iCloud data. I had three snapshots in the cloud from two different iOS versions. (Keep in mind you need legal authority, consent or some form of permission to access cloud data.) What I found is even more confusing.

  • iPhone 7 backup from iOS 10.2 – GeoHistory.mapsdata was present but not updated with current Apple Maps data
  • iPhone 7 backup from iOS 10.1.1 – No GeoHistory.mapsdata

Not sure why the file is not present with 10.1.1 or where the Grinch put it, but I promise to keep searching.  I plan to focus research on iOS 10.2, cloud data and additional location artifacts for the FOR585 course update and will blog on findings. I may even do a SANS webcast after the baby and I get settled in (yes, I am due to have a baby in 24 days.)

In the meantime, please test on your own devices and let me know if you find where the Grinch placed this file, if that is even possible. Also, make sure you always validate your findings and your tools. I know I taught my student the right way because he was manually digging to find the truth. That’s what mobile forensics is all about even when the results are not what we expect and the artifacts we need are stolen by the mean Grinch!

I’m really hoping that 2017 brings us a new artifact that is storing this data or we find a way to access this missing file. Happy Holidays!

iOS, Open Source

A glimpse of iOS 10 from a smartphone forensic perspective

Image 4 Comments

I immediately installed and started using iOS 10.0.1 when the full release was available. For this testing, I used my non-jailbroken iPhone 6S and iTunes 12.4.2.4 with the addition of free and commerical tools. My intention is to share my initial thoughts on what is different in iOS 10 and what to expect when you see a device running this version. For more in depth details, analysis tips and tricks on iOS, refer to for585.com/course.

I expected major artifact location changes in iOS 10.  I based this assumption on the fact that iOS 7 to iOS 8 was drastic in artifact changes. Nothing really changed when we upgraded to iOS 9, so I assumed… I’m happy to report that upon my initial research, I haven’t found drastic changes for most files of interest. I plan to keep digging here, just to be sure. As capabilities increase, we know that log files and usage artifacts are left on the device. These need to be researched further.

One major change I have noticed is with the structure of the iOS device backup. Below is an example of the new file structure.

backup_structure

A few things of interest:

  1. The Manifest.mbdb is now a SQLite database file – Manifest.db
  2. Instead of seeing all of files or “strings of letters” representing backup file contents, you now have folders containing these files, as shown above in the boxed area.

Once I had my backup, I starting digging through the files and panicked!  Everything of interest appeared to be encrypted. This includes simple things like contacts, call logs, SMS and locations pulled from Apple maps.  I frantically sent a Tweet seeing if this is what others were seeing and heard nothing. My tools all flopped. After the panic subsided, I decided to launch iTunes and take a look at my settings. Here is what I saw… The pesky box to Encrypt iPhone backup was checked even though I have been backing up to iCloud for as long as I can remember. Good think I remembered the password.

itunes_issue

I was confused by this for several reasons. One, most of the commercial tools prompt you to enter a backup password and decode the data when this setting is enabled. Also, encrypting a backup and knowing the password provides us additional access to data – not blocks us from it!  What could be going wrong? Could it be examiner error? Next, I did what most examiners would do and attempted to force my tools to parse this image. I launched UFED Physical Analyzer, IEF and BlackLight and entered the password (don’t worry, my passwords are much stronger than this, but I used a “dummy” one for this example.)

ufed-pw_prompt

To my surprise, all of the databases of interest were still encrypted even after I asked the tool to decrypt my data with the correct passcode. To my dismay, nothing of interest was parsed, other than the Info.plist and Manifest.plist files. Even the Manifest.db was encrypted. Below you can see that the file system was parsed and accessible, but the databases and files of interest were encrypted, so this isn’t very helpful.

encrypted_backup

(Once opened, the History.db looked like this)

encrypted_safari

So now what? If you know the user’s backup password or can crack it, the password can be removed in iTunes. I tried this and then backed my phone up again.

First, I launched iTunes and unchecked the box for Encrypt iPhone Backup. I correctly entered my password.

itunes1

The encryption was removed.

itunes2

When I loaded this unencrypted version of my iOS backup file into forensic tools, some crashed, but I did have success in others.  The first think I noticed was that the Manifest.db was no longer encrypted.

manifest

This gave me hope. I started examining the files that were previously encrypted within the iOS backup and found that they too, were accessible. Below, the CallHistory.storedata shows my call logs. When I initially created my backup, this file, like the Safari History.db, was encrypted!

callhistory

I have reported these issues and concerns to the vendors and they are working on the issue. Here are some things they provided me in the meantime.

  1. Do not update to the latest version of iTunes if you are creating backups as forensic images. It causes issues.
  2. Do not select to “Encrypt” the backup in Physical Analyzer when obtaining an Advanced Logical Extraction. That too will render your data encrypted.
  3. Hope that the user never used iTunes encryption!

If you come across an encrypted iOS backup file, try to crack it. Personally, I rely on Elcomsoft tools to handle this.  If you crack the password, you will manually have to remove the iTunes restriction and back the data up again until the tools adapt to handle iOS 10 backup file encryption.

In the meantime, practice on your own device and sign up for FOR585 Advanced Smartphone Forensics, where we cover topics like bypassing encryption and cover the cool artifacts of iOS. Happy iOS hunting!

for585.com/course

GASF

iOS

Can’t Crack into that iOS device?

2 Comments

Good afternoon everyone! One of the most common questions I get is in regards to accessing locked iOS devices. My first response is always, “it depends.” Anyone who conducts smartphone forensics on a regular basis knows that nothing is consistent and that there always seems to be a way around a hurdle, but that is not always true when dealing with iOS.

For newer 64-bit iOS devices, if they are locked and you don’t have access to the passcode, the pairing/lockdown file and the device is not jailbroken, you are going to have a hard time successfully getting into the device.  I recommend trying all tools available to you, just to make sure you have tried everything! Elcomsoft provides physical support for jailbroken 64-bit devices, and it may work for you, so try it if you have access to the tool. Or ask for a demo! You never know when it may be your lucky day.

Before researching your options, you have to know the version on the device, if you don’t know the version, you can obtain in on a Mac by using libimobiledevice from http://www.libimobiledevice.org/ and running ideviceinfo.  This method will work on locked iOS devices, enabling the examiner to identify the iOS version they are facing on the device.  Simply follow these steps:

  1. Launch Terminal

2.  Type the  command below to create the libimobiledevice-macosx directory on the user’s desktop and place the libimobiledevice command-line tools into it.

$ git clone https://github.com/benvium/libimobiledevice-macosx.git~/Desktop/libimobiledevice-macosx/

3.  Navigate to the libimobiledevice-macosx directory, as follows:

$ cd ~/Desktop/libimobiledevice-macosx/

4.  Create and edit the .bash_profile file using the nano command, as follows:

$ nano ~/.bash_profile

5.  Add the following two lines to the .bash_profile file, as follows:

export DYLD_LIBRARY_PATH=~/Desktop/libimobiledevice-
macosx/:$DYLD_LIBRARY_PATH

PATH=${PATH}:~/Desktop/libimobiledevice-macosx/

6.  Press Ctrl + X, y and hit Enter

7.  Return to the terminal and run the following command:

$ source ~/.bash_profile

Your device information will be displayed. 🙂

On a Windows platform (version 7 or later), simply plug the iOS device into a PC that does not have iTunes installed and follow these steps:

  1. Plug the iOS device into the PC

2.  Go to My Computer

3.  Right click on the iOS device

4.  Select Properties

apple

 

 

 

 

 

 

 

 

 

Today, Dylan Dorow, kindly shared some useful cheat-sheets on what’s currently possible for locked iOS devices.  They are attached below and are available for download in my Reading Room. These are extremely useful when trying to decide what is possible for accessing a locked iOS device.

iDevice_Make_Model_and_iOS_version iOS_Device_Bypass_WorkFlow

Good luck cracking those devices! And make sure you stay current on what the tools are capable of supporting because it changes quickly!

Android, iOS, Open Source

What are your forensic tools really good at?

5 Comments

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

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

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

Commercial Solutions (Not in any particular order):

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

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

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

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

Practical Mobile Forensics

Learning Android Forensics

Learning iOS Forensics

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

Android, iOS, Windows Phone

Has the smartphone finally outsmarted us?

Leave a comment

I originally posted this on the SANS blog, but figured I would share below as well. Special thanks to Cindy Murphy, Adrian Leong, Maggie Gaffney, Shafik Punja, JoAnne Gibb, Brian McGarry and the Cellebrite developers who worked tirelessly on the WP8 device discussed in this blog!

Has the smartphone finally outsmarted us?

I can honestly say that the most common question I am asked by examiners, investigators, students and even my neighbors is, “which phone is the most secure?” Obviously, the concern behind the question varies. Some want to secure their own device, and others, like myself, want to prove everyone in DFIR wrong by cracking into the toughest and most secure devices.

Smartphone security has gotten drastically stronger in 2014. This year, we are expecting even more challenges when examining smartphones. When thinking about the forensic aspects of smartphone security and encryption, we have to consider two things:

  1. How are we going to get access to the data?
  2. Even if we get a dump of the device, can we decrypt and examine the data?
  3. What happens if I can access the data, but the application data is encrypted?

Let’s look at a few devices to consider our options. First, Windows Phone 8 (WP8) brought us new issues that commercial forensic kits could not fully support. The good news is that these devices only comprise approximately 2.5% of the smartphone market. The bad news – criminals still use them! My co-author for FOR585, Cindy Murphy, worked with others in DFIR to get over this hurdle when it really mattered. A criminal investigation forced Cindy into action when she realized the critical part of the crime was a Nokia 520 running WP8. Cindy essentially formed a “team” to divide and conquer on this WP8 device. They successfully obtained a JTAG image of the device and manually parsed the data. FYI, if you haven’t looked at a smartphone dump in awhile, it’s no longer just a few files you need to sift through like legacy mobile device images. You are now looking at a small hard drive of evidence needing to be manually parsed. This task alone could take a lot of patience and a really long time.

What makes WP8 devices so secure compared to the others? WP8 devices brought change that we, smartphone examiners, haven’t faced in the past. This is the first OS introduced into the smartphone community that utilized BitLocker technology to support data encryption on the device with AES 128, which utilizes a Trust Platform Module (TPM) to protect the encryption key once the data is secure. These two factors have caused heartache for us smartphone examiners who have one of these devices appear in our evidence lineup. Fortunately, Cindy and her “team” were able to obtain a physical image, bypass the encryption and parse the relevant evidence to support her criminal investigation. Their work can be found here: http://dfir.to/Win8Phone-Forensics If you haven’t read this paper, you should!

Cindy and her “team” worked directly with Cellebrite developers to provide a recent release supporting the Nokia 520 and similar WP8 devices, thus making your life easier.   In FOR585 we stress the importance on understanding how the data is stored and parsed by your tool. One tool cannot uncover and decode all data on a smartphone. It’s your job to learn the file system structures, data formats, encoding schemas and all of the other fun bit of smartphone forensics. Additionally, in Cindy’s case, one single tool did not parse or interpret all of the data from this device. The smartphone forensic tools could not handle the data dump. You will find this is true for some smartphones, so you need to understand all concepts of smartphone data. Your toolbox must contain both smartphone forensic tools as well as standard DFIR tools (yes, the same ones your learned about in FOR408 and FOR572).

Here are some cheat sheet locations where evidence on the WP8 resides (for more details on how to manually parse the data, please refer to the referenced paper, above):

SMS and Contacts:

Users\WPCOMMSERVICES\APPDATA\Local\Unistore\store.vol

MMS:

SharedData\Comms\Unistore\Data

Call Logs:

Users\WPCOMMSERVICES\APPDATA\Local\UserData\phone

Internet History and Cookies:

Users\DefApps\APPDATA\INTERNETEXPLORER\INetCahe\.

Multimedia Files:

Users\Public\Pictures\CamerRoll\.

Application data and other traces of user activity were located on this device and required manual examination, custom Python scripts and intensive reconfiguration of raw data. Keep in mind that all 3rd party applications are different, store data with different obfuscation levels and require manual parsing (aka, don’t trust your tool – be smarter than it and validate your findings).

Now let’s consider the other devices that are trying to outsmart us. BlackBerry has always been secure. Pre-paid phones have locked data ports and knock-off devices are counterfeit, so support is inconsistent. iOS devices containing the A5-A8 chips are difficult if they are locked. There are methods for bypassing the lock, such as using the host computer Lockdown files as well as attempting to crack the PIN with the IP-BOX. If the user doesn’t back up their iOS device with a computer and uses a complex passcode… let’s just say you may not be getting access to that device, unless of course it’s jailbroken and not 64-bit. So may considerations, right?

Then there is Android Lollipop, which introduced the first default full disk encryption for this OS. How this will change our methods is TBD. I suggest you sign up for a FOR585 class to see how these devices can be accessed when you seem to have been outsmarted.

When considering which SANS course to take next, consider this – smartphone operating systems contain file systems similar to those discussed in FOR408 and FOR518, but need to be handled in a unique way. What about network traffic on smartphones? Here’s something to consider that you may have learned in FOR572 that should lead you to take FOR585 next.

“This class is critical for any forensicator in 2015,” said Phil Hagen, SANS Certified Instructor and course lead for FOR572, Advanced Network Forensics and Analysis.  “One thing we focus on from the network side is to hunt for adversaries in an environment and identify which endpoints require detailed examination.  When those are workstations or servers, the analysis path is very well-established.  However, if that endpoint is a modern mobile device, a forensicator must have the skills necessary to perform a comprehensive examination.  With ’smart’ mobile devices, the techniques are often vastly different than those required for traditional computing devices.”

References:

[1] http://dfir.to/Win8Phone-Forensics

[2] Practical Mobile Forensics

Heather Mahalik serves as a PM and leads the forensic effort for Oceans Edge, Inc. She has spent over twelve years conducing computer crime investigations ranging counter-intelligence to high profile criminal investigations. She is a Certified Instructor, course lead and co-author of FOR585 Advanced Smartphone Forensics and co-author of FOR518 Mac Forensic Analysis at the SANS Institute. Heather is co-author of Practical Mobile Forensics, by Packt Publishing. Find her on Twitter @HeatherMahalik and on her personal website/blog smarterforensics.com.