by Patrick Siewert, Pro Digital Forensic Consulting
It’s not secret to those involved in the study and practice of mobile forensics that Apple likes to throw us curve balls with almost every new iteration of the iOS operating system. It turns out, iOS 10.2 is no different (released December 12, 2016). A conversation began recently on the IACIS list serve and got me thinking about trying to problem solve and figure out a work-around, so I spent the past day or so trying to do just that. (For those interested, I also wrote an article about the problem-solving aspect of digital forensics and you can read it here.)
The background is as follows: When an i-Device user running iOS 10.2 connects the device to a computer, they are automatically prompted by iTunes for an encryption password:
When the option to encrypt is selected, a prompt is displayed for an encryption password, which may be entirely different from the device passcode or the iTunes account password:
This default encryption prompt becomes an issue for examiners due to the fact that users often don’t remember these passwords because in the age of cloud-driven storage and wireless *everything*, users don’t routinely connect their devices to a computer and therefore, don’t remember the encryption password. This was the issue raised by another examiner on the list serve and it prompted many replies and potential work-arounds because when examiners attempt to analyze the extractions from these devices, they’re encrypted. Pretty much game over.
(For additional background on this issue as was introduced in iOS 10.0.1, please refer to Heather Mahalik’s blog on the topic located here.)
Before iOS 10, I ran across this problem a few times with iOS devices. My work-around then was to simply connect the device to a foreign computer (i.e., one that it had not been connected to previously) and de-select the encryption option and create another unencrypted backup, then pull the new backup into any number of commercial tools for analysis. This doesn’t work any longer because when the device is connected to a foreign computer and encryption is de-selected, iTunes prompts for the encryption password for verification. Darn the luck!
Methodology
For this testing, I used an iPhone 6, which we have on-hand for testing purposes. The phone has a handful of iMessages, pictures, videos, Kik messages and some other data on it. I updated the phone to iOS 10.2 and encrypted the backup on the Mac side of my forensic machine. I then switched to the Windows side and attempted to create another backup by de-selecting the “Encrypt iPhone Backup” option, which is when I quickly learned that in all updated versions of iOS and iTunes, the encryption password is needed to complete this action:
Being that I know the encryption password, I entered it and created a new backup via iTunes on my local machine. To be sure, unless you want to use a tool such as Elcomsoft to brute-force the password or attempt a dictionary attack based upon investigation and/or social engineering, you’ll need the encryption password to make this work. But even having the password doesn’t get us too far with Cellebrite under the current version.
How Does UFED Handle This?
Cellebrite Universal Forensic Extraction Device (UFED) Physical Analyzer (PA) has heretofore been one of the best commercial tools for acquiring and analyzing iOS devices. Indeed, you can use UFED PA to attempt a brute-force dictionary attack on these extractions if you have decent intelligence through additional investigation or social engineering by pointing UFED PA at a text file containing case-specific dictionary words:
In conducting this test and comparison, I used the latest version (as of this publication) of UFED PA, 5.4.7.5, which was released just 24 hours prior. As you can see from the below image, even when the proper password is entered after an advanced logical extraction directly from the device, UFED PA still doesn’t parse the “analyzed data” into chats, web history, etc. like it used to with older versions of iOS:
That’s it. That’s pretty much all we get. When the “Backup” folder is expanded, we are presented with this:
The red arrow is used to illustrate that the listing of files keeps going. Further inspection of these files indicates it would be a very lengthy, tedious process to try and located you sms.db, let alone DBs from many third-party apps which can be crucial in many cases.
My next step was to create an unencrypted backup through iTunes to see if that could be pulled into UFED PA and parsed a bit nicer. It wasn’t. We are presented with a file structure identical to that which is created by iTunes, with one folder with a long alphanumeric name and dozens of sub-folders, each with a shorter alphanumeric designation. The only data that was automatically parsed in the backup was images, videos and device locations. Again, combing through all of this for your crucial evidence and databases can be a time-waster, so what else can we do? Try to use another tool!
How About IEF?
So now we have an advanced logical image in UFED PA (that is all but useless) and a backup through iTunes that is only slightly better when viewed through UFED PA. Now, I profess that push-button tools are the end of true forensics. Anyone who reads this blog knows that I firmly believe that you have to know and articulate where the data is located and how it got there. But sometimes, certain tools can help point us in the right direction. Enter Magnet Forensics’ Internet Evidence Finder (IEF, v. 6.8.4.3639). IEF is widely accepted as one of the best and easiest tools on the market to use. I love it for helping me out, for getting me a leg up on where I need to look, perhaps even with another tool. So I decided to try and pull the iTunes backup into IEF, just to see what would happen.
First, I selected the Mobile and iOS options in IEF:
Then, I selected “File Dump” to point IEF where I wanted it to look.
The next decision is probably the most crucial to the process. I selected the Windows file browser, then navigated to the (now exported) iTunes backup folder – the one with the very long alphanumeric name. But then I drilled down to the sub-folders and files immediately under the parent file and selected all of them, including all of the .plist and .db files:
Next, I had to tell IEF what I wanted it to look for. The data set isn’t large and I’d rather have too much data to sift through than not enough, so I just chose everything and selected “next”:
It’s important to note here that I conducted a subsequent test selecting “iOS Backups” ONLY and did not receive a favorable outcome. Also, if the backup or device is encrypted, IEF will prompt for a password.
The processing took about 15 minutes. Once it was finished, the data was parsed out as you would have expected pre-iOS 10.2:
I have highlighted the file path of the location of the sms.db in the above image because now, IEF has told us where to look in UFED PA or other tools. Consequently, we can now switch back to UFED to examine and export the .DB files as necessary. The below image shows what we find in UFED PA when we follow the file path indicated through IEF in the iTunes backup of the iPhone:
So to wrap it up, get your encryption password, create a backup using iTunes on a foreign machine and bring the backup into IEF to point in you the right direction. From there, you can expand to UFED PA or another tool of your choosing, if necessary.
Take-Aways
There are several important things to take-away from this experiment. First, it has become vital in mobile forensics to have more than one tool at your disposal. Having access to two or more tools can actually save you time and effort. Imagine how tedious it would have been to sift through all of those folders (none of which contained a .db file extension by the way) to find the text messages or other pertinent data.
Second, the problem-solving aspect of “boots on the ground” forensics, especially mobile forensics, cannot be ignored. To make problem-solving a little easier, start to ask about encryption FIRST and save yourself some grief down the road. It’s also becoming apparent that we simply cannot rely on the pretty push-button features of many tools in the coming years, especially with regard to Apple and their iOS… and it’s only going to get more prevalent.
Finally, things are always changing. Never forget that. When I was conducting this testing and writing this article, I did so knowing full well that Cellebrite may push out a solution in the next week or two. But until those updates happen, we all need to collaborate to find solutions to these issues, because just like no one tool can do it all, no single examiner can always do it all.
About The Author
Patrick Siewert is the Principal Consultant of Pro Digital Forensic Consulting, based in Richmond, Virginia. In 15 years of law enforcement, he investigated hundreds of high-tech crimes, incorporating digital forensics into the investigations, and was responsible for investigating some of the highest jury and plea bargain child exploitation investigations in Virginia court history. Patrick is a graduate of SCERS, BCERT, the Reid School of Interview & Interrogation and multiple online investigation schools (among others). He continues to hone his digital forensic expertise in the private sector while growing his consulting & investigation business marketed toward litigators, professional investigators and corporations, while keeping in touch with the public safety community as a Law Enforcement Instructor. Email: ProDigitalConsulting@gmail.com; Web: www.ProDigital4n6.com
Patrick –
This is a very nice piece – extremely well done.
John Crawford <– Met you in Boston … 🙂
Thank you for a nice article, Patrick.
I tried to connect a clean test phone (iPhone 5, running iOS 10.2.1) to iTunes on OSX. I did however not get the automatic prompt for encryption of backup. I had to manually select encryption of backup under the backup section if I wanted to encrypt the backup. So I was not able to reproduce the automatic prompt that you mentioned in the beginning of your article.
Do you have any more research regarding this? I have no reason to doubt your findings, but before I inform my colleagues about this finding (which all LEA’s should keep in mind) I would like to know a bit more.
Best regards,
Odin