All posts by Heather Mahalik

A breath of fresh air! Conducting application analysis with Oxygen Detective

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.

A breath of fresh air

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!

Image result for Stepping off my soapbox meme

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 and ask for a demo. Mention my blog!

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

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/  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/ 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 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!

Update: Solutions for iOS10 – Encrypted Backup Files, Cracking Passwords and Data Acquisition

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

1. Added an encrypted backup with iTunes (older version) into Physical Analyzer with the Open Advanced option
2. Added an encrypted backup with iTunes (latest version)  into Physical Analyzer with the Open Advanced option
3. I removed the iTunes password from the iPhone and selected to Encrypt Backup during Advanced Logical Extraction
4. I reset the passcode in iTunes and then selected Advanced Logical Extraction. I was prompted for the user’s backup password.
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. 🙂
Not only did it parse the databases, they are decrypted. These databases can be exported and put into other tools for parsing, merging and interpreting the data – something like Paul Sanderson’s SQLite Forensic Browser.  Below is a sample of my call history database.
Now how to handle your analysis of iOS 10… not as easy
When we take the tools out of the equation, which is required to determine how the data got onto the phone, this process gets much harder. Below, you can see what Physical Analyzer is reporting for my location information. If you have heard my and Sarah Edwards endless presentation on location information, you are already aware that these iOS devices track a lot that we do and also track other things people do for us! What does that mean? If a friend tags you in a social media post, this data can show up on your device as a location you have visited – even if you haven’t been there. Why? Because you or something gave that app or browser permission to do this. What does this look like?
In this example, I can tell you what is true and what is not. How – it’s my phone! If it weren’t, I better be prepared to manually look at databases and artifacts to piece this information back together. For example, that Facebook location is the lat/long for one of my friends on chat. I was not at that location. Mail Content, iPhone RecentLog, Map Searches, Map Suggestions and more all need to be verified by an examiner. The tool cannot do this for you. The tool also cannot pull location information from 3rd party applications that they do not parse.
Need to learn proper examination techniques – take FOR585 Advanced Smartphone Forensics. We teach you how to stand behind the evidence you put in your report.
Your tool can only get you so far. My concern in my first blog was that our tool couldn’t even get us beyond the first hurdle. Now that they have, are you prepared to defend your report or what the tool is telling you? Remember, these tools parse everything that is on the phone. It’s your job to determine how the data got there.
See you in class soon!

A glimpse of iOS 10 from a smartphone forensic perspective

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

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!


So you want to break into the field of Digital Forensics…

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


To this?????              PC

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:

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)


Gillware – Murphy’s Laws of Digital Forensics

Gillware Digital Forensics Blog | Cindy Murphy


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.

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!


iPhone Forensics – Separating the Facts from Fiction

For those of you who missed the efforts that Sarah Edwards, Cindy Murphy and I put together, the links are below for you to enjoy.
The webcast provides and overview of our thoughts on what is being requested by the FBI, what Apple may be able to do and how we, examiners, need to be properly trained and ready to handle the hard evidence that comes across our desks.
The blog goes into more detail on technical aspects of this “situation.” Sarah, Cindy and I hope you enjoy it and find it useful.

Can’t Crack into that iOS device?

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

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-


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!

Practical Mobile Forensics eBook 50% Off!

PMF50 smarter forensics

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:

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!