How, you ask? See below.
How, you ask? See below.
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):
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 email@example.com and ask for a demo. Mention my blog!
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…
For each of these devices, I opened Apple Maps and searched for items I could easily identify:
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.)
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:
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.
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!
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 126.96.36.199 (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.
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 v188.8.131.52 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:
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 184.108.40.206 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:
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.
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!
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…
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?
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.
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
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!
Everyone is asking me to comment on the iPhone 5C. Here is my comment: “Well said, Jon.”
Please read his blog post.
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:
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/
3. Navigate to the libimobiledevice-macosx directory, as follows:
$ cd ~/Desktop/libimobiledevice-
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:
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:
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.
Good luck cracking those devices! And make sure you stay current on what the tools are capable of supporting because it changes quickly!
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!