All,

I know that training is expensive. Here is a way to attend FOR585 for half the price! Next up:

Tysons Corner, VA

Prague (Cindy Murphy)

Ft. Lauderdale

Back by request, here is another coupon code offering 50% off the eBook of Practical Mobile Forensics. This code is only valid until October 2nd and is for the eBook directly from our publisher’s site.

To order, click the link below and enter the Discount code prior to checkout.

Unique link: http://bit.ly/1Qvf018

Discount code: PMF50

We hope this book helps you get the most bang for your buck in mobile forensics. We aimed to include as many open source solutions as possible to conduct mobile device forensics.

Happy Reading!

This offer is only good through the New Year! Enjoy Practical Mobile Forensics for $5. A great guide to get your mobile forensic practices in place. Stay tuned for the second edition this summer!

http://bit.ly/1YlSBfa

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

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!

Everyone is asking me to comment on the iPhone 5C. Here is my comment: “Well said, Jon.”

Please read his blog post.

tl;dr Apple’s technical capabilities under FBI AWA order

It seems like I am asked this question at least twice a month via email. This week, I was asked 4 times. Instead of telling people the same thing over and over, I figured I would write a blog and refer the next person to it. Having said that, if you have positive experiences to add, please do so in the comments. Remember, we all needed to get our start somewhere. The biggest mistake we can make is not helping those who want to do what we do every single day!

I am often asked, “how did you get into this field and how did you get where you are today?” My response, “I was in the right place at the right time.” I graduated with a BS in Forensic and Investigative Science from WVU and could not get a job in Bloodstain Pattern Analysis, as I had planned. Remember, this was 2002, before CSI! Yes, I am older than 24… hard to believe. I applied and interviewed with several Government agencies and Police Departments. Nobody would hire a grad with no experience and the Forensic degree was a new thing. I was one of the first 4 with this degree in the United States. This makes me feel old…

So how did I get from here (I actually did this in college):   

To this?????              

This is where the Air Force helped me. I joined the Air National Guard to pay my tuition so I could get my degree. On my way to a drill weekend, flying in the back of a C-130, I met an IT guy from ManTech. He told me he could put me in touch with someone hiring an evidence technician. And the rest was history. Well, not really – they didn’t want to hire me because I didn’t understand digital evidence as my experience was in physical evidence. However, I made them see that it is really the same. How we handle it is the same. They took a chance and my career in Digital Forensics began. I was lucky to have a great boss who was willing to teach me how the tools worked and no just press buttons. Without him (nickname: Lancer), I have no idea where I would be today. I showed the interest and he took the time to teach me.

So, how can you meet your Lancer, you ask? You need to meet people to introduce you to opportunities. You need to network! Emailing someone on LinkedIn is not fully networking.  You need to get out there and go to conferences where these people thrive. Don’t be afraid to introduce yourself and ask for help. There is always someone who will help you. If you get turned away, you haven’t found your Lancer. Keep looking and don’t give up.

When I am approached for help, I ask a few things?

1. What is your background?
2. What do you want to do? Most people don’t know, so I point them to webcasts and blogs to see what sparks their interest (see below).
3. Can you get a clearance?
4. Are you willing to move?

You need to take the initiative to show your interest. By this, I mean take any training you can. Not all training is cheap and the courses I teach are expensive, but are worth the money. If you cannot pay for training, take free training, watch free webcasts, read forensic blogs and books and practice on your own. This will give show you are trying, show you are passionate about the field and give you some cool stories to share at your interviews.

Your best bet is to pay and attend a forensic conference to meet people who are in the field. My favorite is the SANS DFIR Summit, for the sole reason that examiners present – not vendors. So you are getting a glimpse of different careers, the tools and methods they use and how they fill the gaps that the tools cannot meet. It’s amazing and it’s the best networking experience of the year. But, it’s not free! Can’t afford it, ask a speaker to sponsor you as their guest! Again – back to that networking thing. You have to jump out of your shell and ask! Other conferences that may be helpful (and there are so many) EnFuse, HTCIA, BlackHat, DEFCON, Mobile Forensics World, Paraben and others. Before attending one, I recommend you look at the agenda, the speakers and determine if this is what you want to spend your time and money attending. Each offers something different and all have a target audience.

Take forensic training. It’s that simple. Learn the trade. Some courses are free and some cost a good chunk of change! Again, take what you can and remember it’s better to start somewhere vs. never getting started. Here is a list you can refer to: http://www.forensicswiki.org/wiki/Training_Courses_and_Providers

Shameless plug: I author and teach for the SANS Institute. I recommend FOR585 Advanced Smartphone Forensics. Why? Because it’s fun, cutting edge, vendor neutral and it’s my baby. Plus, who doesn’t have a phone? May as well learn how to forensicate it.

Books to read (just Google them – you can buy them in several placed):

These are the books that helped me get into this field and still help me during my investigations:

File System Forensic Analysis – Brian Carrier

Handbook of Digital Forensics and Investigations – Eoghan Casey

Harlan Carvey’s books on Windows and Registry Forensics

Practical Mobile Forensics 2nd Edition – Mahalik and Tamma (again shameless plug…)

These books are necessarily something you would read cover to cover, but they are great reference material. Will show you how to examine your own computer and phones and will get you some hands on experience! Most suggest free and commercial tools, so you can access what we use on a daily basis. There are several others out there, but these are general enough and have helped me.

Blogs:

This is a great place to start because it’s free and you can hop around as you wish. Clearly you are here on my blog, but others I recommend are:

Cheeky4n6monkey –Learning about digital forensics

Az4n6blog – Another Forensics Blog

Mac4n6blog – Mac Forensics (iOS too)

SANS – DFIR Blog

Gillware – Murphy’s Laws of Digital Forensics

Gillware Digital Forensics Blog | Cindy Murphy

Webcasts:

The SANS institute sponsors and hosts webcasts, where professionals give you a glimpse of topics they care about, courses they teach and developments in forensics. Check it out! It’s free and you can refer back to archives and get tons of free training. https://www.sans.org/webcasts/

If you have done all of these things and you are ready to break into forensics, let’s talk. I hope to meet you at a SANS event or conference soon. Good luck and never let anyone tell you it’s to hard to get into. It’s not always what you know, but who you know and how hard you are willing to work!

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.

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.

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.)

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.

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

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.

The encryption was removed.

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.

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!

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

Happy Friday everyone. After my post last week, I was in touch with several vendors about what was occurring, my thoughts and how they intended to fix the problem when it comes to accessing the backup file data. Since then, two vendors (Cellebrite and Elcomsoft) reached out with an updated solution. I tested these tools over the last two days and want to share my results. I used Cellebrite Physical Analyzer v 5.3.5.10 (soon to be released), Elcomsoft v6.10 and iTunes 12.5.1 as well as the previous iTunes version to be thorough.

What changed since the last blog?

First, if an iOS10 backup file was encrypted with iTunes, you do not need to assume you cannot get into that data. (This was the case in my previous blog. Even if the password was known, the tools were choking on the data).  If you can crack the password, Cellebrite’s UFED Physical Analyzer will properly decrypt this data. I bet you are now wondering how I cracked the encrypted iOS 10 backup files? I used  Elcomsoft Phone Breaker v 6.10.

Cracking an encrypted iOS10 backup file

I set three different passwords to test. The first was 0000 and Elcomsoft laughed at this and provided the password before I could even sit back in my chair to watch. I then updated iTunes and changed my password to “hank” – this password didn’t even take a full second to crack.

Maybe their claims are true that they will crack a passcode the fastest due to a vulnerability they found in the hashing of the passcode.

Researchers say iOS 10 backups can be cracked 2,500 times faster

I then set a more difficult password “Heather1” and backed up my data using iTunes. Elcomsoft is saying that there is 87 years remaining for a brute force attack, so I am not going to wait. What should you do here? Try a dictionary attack! It’s much more effective with passwords such as “Heather1” when compared to Brute Force. When I changed to dictionary attack, this password was crack in less than 1 second! As a side note, I relied on the English dictionary and did not create anything custom for this test.

So, we have the password, what about the encrypted databases?

I was able to successfully parse all of the iOS10 backup files that I created over the last two days, containing various backup passwords, as well as the ones that were created for my previous blog post. As long as Physical Analyzer had the password, the data was decrypted and parsed. Make sure you are using Physical Analyzer v5.3.5.10 or later (assuming you have tested and validated the latest versions).

When attempting an Advanced Logical in Physical Analyzer, the option to encrypt the backup is provided if the backup has not been encrypted via iTunes by the user. You should select this option. If not, you will not get the data protected by the keychain. I selected to Encrypt my backup as shown below.

As stated in my last post, this was not an option with iOS10. Cellebrite has fixed this issue and all of the data will be parsed and decrypted. Additionally, if you are prompted for the users iTunes backup file password (the one you cracked with Elcomsoft), Physical Analyzer will parse the data when the password is correctly entered whether you selected an Advanced Logical Extraction or to add an iTunes backup file into the tool for analysis.

To be thorough, I tested the following in physical analyzer:

The results – Physical Analyzer parsed the databases that I stated were encrypted in my previous test.! This is great news for those of us who use this tool to conduct smartphone forensics. And yes, I realize that I am out of space on my iPhone… I am waiting on my 128GB iPhone 7 to arrive.

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!

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):

1. Scanning the Applications that are parsed by the tool (I commonly use Physical Analyzer, Oxygen, IEF/AXIOM, BlackLight, etc.)
2. Examining the data for application installation traces
3. Identifying apps of interest and going directly to the application directory for manual examination and verification (via File Browser in Oxygen Detective)
4. Combing through each relevant database and examining for both active and deleted artifacts of interest (via SQLite Database Viewer in Oxygen Detective)
5. 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)
6. Examining each .PList of interest (using the Apple PList Viewer in Oxygen Detective)
7. Examining any other files of interest pertaining to the applications (xml, dat, multimedia, etc)
8. Examining  browser and webkit artifacts
9. 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!

How, you ask? See below.

for585.com/course

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 19 digit Mac Absolute values and some are 0 (sent messages).

Additionally, I was seeing some that were 19 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 datbases andplists 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.

Everyone is asking me to comment on the iPhone 5C. Here is my comment: “Well said, Jon.”

Please read his blog post.

tl;dr Apple’s technical capabilities under FBI AWA order

It seems like I am asked this question at least twice a month via email. This week, I was asked 4 times. Instead of telling people the same thing over and over, I figured I would write a blog and refer the next person to it. Having said that, if you have positive experiences to add, please do so in the comments. Remember, we all needed to get our start somewhere. The biggest mistake we can make is not helping those who want to do what we do every single day!

I am often asked, “how did you get into this field and how did you get where you are today?” My response, “I was in the right place at the right time.” I graduated with a BS in Forensic and Investigative Science from WVU and could not get a job in Bloodstain Pattern Analysis, as I had planned. Remember, this was 2002, before CSI! Yes, I am older than 24… hard to believe. I applied and interviewed with several Government agencies and Police Departments. Nobody would hire a grad with no experience and the Forensic degree was a new thing. I was one of the first 4 with this degree in the United States. This makes me feel old…

So how did I get from here (I actually did this in college):   

To this?????              

This is where the Air Force helped me. I joined the Air National Guard to pay my tuition so I could get my degree. On my way to a drill weekend, flying in the back of a C-130, I met an IT guy from ManTech. He told me he could put me in touch with someone hiring an evidence technician. And the rest was history. Well, not really – they didn’t want to hire me because I didn’t understand digital evidence as my experience was in physical evidence. However, I made them see that it is really the same. How we handle it is the same. They took a chance and my career in Digital Forensics began. I was lucky to have a great boss who was willing to teach me how the tools worked and no just press buttons. Without him (nickname: Lancer), I have no idea where I would be today. I showed the interest and he took the time to teach me.

So, how can you meet your Lancer, you ask? You need to meet people to introduce you to opportunities. You need to network! Emailing someone on LinkedIn is not fully networking.  You need to get out there and go to conferences where these people thrive. Don’t be afraid to introduce yourself and ask for help. There is always someone who will help you. If you get turned away, you haven’t found your Lancer. Keep looking and don’t give up.

When I am approached for help, I ask a few things?

1. What is your background?
2. What do you want to do? Most people don’t know, so I point them to webcasts and blogs to see what sparks their interest (see below).
3. Can you get a clearance?
4. Are you willing to move?

You need to take the initiative to show your interest. By this, I mean take any training you can. Not all training is cheap and the courses I teach are expensive, but are worth the money. If you cannot pay for training, take free training, watch free webcasts, read forensic blogs and books and practice on your own. This will give show you are trying, show you are passionate about the field and give you some cool stories to share at your interviews.

Your best bet is to pay and attend a forensic conference to meet people who are in the field. My favorite is the SANS DFIR Summit, for the sole reason that examiners present – not vendors. So you are getting a glimpse of different careers, the tools and methods they use and how they fill the gaps that the tools cannot meet. It’s amazing and it’s the best networking experience of the year. But, it’s not free! Can’t afford it, ask a speaker to sponsor you as their guest! Again – back to that networking thing. You have to jump out of your shell and ask! Other conferences that may be helpful (and there are so many) EnFuse, HTCIA, BlackHat, DEFCON, Mobile Forensics World, Paraben and others. Before attending one, I recommend you look at the agenda, the speakers and determine if this is what you want to spend your time and money attending. Each offers something different and all have a target audience.

Take forensic training. It’s that simple. Learn the trade. Some courses are free and some cost a good chunk of change! Again, take what you can and remember it’s better to start somewhere vs. never getting started. Here is a list you can refer to: http://www.forensicswiki.org/wiki/Training_Courses_and_Providers

Shameless plug: I author and teach for the SANS Institute. I recommend FOR585 Advanced Smartphone Forensics. Why? Because it’s fun, cutting edge, vendor neutral and it’s my baby. Plus, who doesn’t have a phone? May as well learn how to forensicate it.

Books to read (just Google them – you can buy them in several placed):

These are the books that helped me get into this field and still help me during my investigations:

File System Forensic Analysis – Brian Carrier

Handbook of Digital Forensics and Investigations – Eoghan Casey

Harlan Carvey’s books on Windows and Registry Forensics

Practical Mobile Forensics 2nd Edition – Mahalik and Tamma (again shameless plug…)

These books are necessarily something you would read cover to cover, but they are great reference material. Will show you how to examine your own computer and phones and will get you some hands on experience! Most suggest free and commercial tools, so you can access what we use on a daily basis. There are several others out there, but these are general enough and have helped me.

Blogs:

This is a great place to start because it’s free and you can hop around as you wish. Clearly you are here on my blog, but others I recommend are:

Cheeky4n6monkey –Learning about digital forensics

Az4n6blog – Another Forensics Blog

Mac4n6blog – Mac Forensics (iOS too)

SANS – DFIR Blog

Gillware – Murphy’s Laws of Digital Forensics

Gillware Digital Forensics Blog | Cindy Murphy

Webcasts:

The SANS institute sponsors and hosts webcasts, where professionals give you a glimpse of topics they care about, courses they teach and developments in forensics. Check it out! It’s free and you can refer back to archives and get tons of free training. https://www.sans.org/webcasts/

If you have done all of these things and you are ready to break into forensics, let’s talk. I hope to meet you at a SANS event or conference soon. Good luck and never let anyone tell you it’s to hard to get into. It’s not always what you know, but who you know and how hard you are willing to work!

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.

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.

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.)

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.

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

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.

The encryption was removed.

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.

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!

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

Happy Friday everyone. After my post last week, I was in touch with several vendors about what was occurring, my thoughts and how they intended to fix the problem when it comes to accessing the backup file data. Since then, two vendors (Cellebrite and Elcomsoft) reached out with an updated solution. I tested these tools over the last two days and want to share my results. I used Cellebrite Physical Analyzer v 5.3.5.10 (soon to be released), Elcomsoft v6.10 and iTunes 12.5.1 as well as the previous iTunes version to be thorough.

What changed since the last blog?

First, if an iOS10 backup file was encrypted with iTunes, you do not need to assume you cannot get into that data. (This was the case in my previous blog. Even if the password was known, the tools were choking on the data).  If you can crack the password, Cellebrite’s UFED Physical Analyzer will properly decrypt this data. I bet you are now wondering how I cracked the encrypted iOS 10 backup files? I used  Elcomsoft Phone Breaker v 6.10.

Cracking an encrypted iOS10 backup file

I set three different passwords to test. The first was 0000 and Elcomsoft laughed at this and provided the password before I could even sit back in my chair to watch. I then updated iTunes and changed my password to “hank” – this password didn’t even take a full second to crack.

Maybe their claims are true that they will crack a passcode the fastest due to a vulnerability they found in the hashing of the passcode.

Researchers say iOS 10 backups can be cracked 2,500 times faster

I then set a more difficult password “Heather1” and backed up my data using iTunes. Elcomsoft is saying that there is 87 years remaining for a brute force attack, so I am not going to wait. What should you do here? Try a dictionary attack! It’s much more effective with passwords such as “Heather1” when compared to Brute Force. When I changed to dictionary attack, this password was crack in less than 1 second! As a side note, I relied on the English dictionary and did not create anything custom for this test.

So, we have the password, what about the encrypted databases?

I was able to successfully parse all of the iOS10 backup files that I created over the last two days, containing various backup passwords, as well as the ones that were created for my previous blog post. As long as Physical Analyzer had the password, the data was decrypted and parsed. Make sure you are using Physical Analyzer v5.3.5.10 or later (assuming you have tested and validated the latest versions).

When attempting an Advanced Logical in Physical Analyzer, the option to encrypt the backup is provided if the backup has not been encrypted via iTunes by the user. You should select this option. If not, you will not get the data protected by the keychain. I selected to Encrypt my backup as shown below.

As stated in my last post, this was not an option with iOS10. Cellebrite has fixed this issue and all of the data will be parsed and decrypted. Additionally, if you are prompted for the users iTunes backup file password (the one you cracked with Elcomsoft), Physical Analyzer will parse the data when the password is correctly entered whether you selected an Advanced Logical Extraction or to add an iTunes backup file into the tool for analysis.

To be thorough, I tested the following in physical analyzer:

The results – Physical Analyzer parsed the databases that I stated were encrypted in my previous test.! This is great news for those of us who use this tool to conduct smartphone forensics. And yes, I realize that I am out of space on my iPhone… I am waiting on my 128GB iPhone 7 to arrive.

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!