iOS forensics is always a lot of fun. Say, you’ve got an iPhone of a recent generation. It’s locked, you are blank about the passcode, and the worst part is it’s more than just the four proverbial digits (the last iOS defaults to six). And you don’t have their computer, and there is not an iCloud account either. A horror story where no one, even us, can do anything about it.

However, the reality has far more than 50 shades of (insert you favorite color). Almost every case is unique. Over 1.2 billion iPhones are sold to date, and they tend to show up in every other investigation. The iPhone is the ultimate source of evidence, no doubt.

The Marketing

If you are familiar with mobile forensics, you may skip that part; there will be nothing new for you here. But if you are new in the area, work for LE or looking for a forensic tool and just stumbled upon that shiny all-in-one silver-bullet toolkit, keep reading.

First, the numbers. Every mobile forensic vendor does its best to present its software as the most compatible, advertising support for “over XX devices, YYY cloud services and ZZZZ applications”. The reality is usually a bit dull. The number of supported devices usually counts all possible combinations of hardware, firmware and software revisions of every model. Every operator-specific version of each model is usually counted as a separate device. The numbers include the countless legions of Chinese phones, while many of which are the same white-label boxes with a name slapped on top. The number of applications supported usually counts individual versions of each app, even if there is no difference from the “forensic” point of view. (Counting iOS, Android and Windows apps as separate applications is OK with us). But yeah, you can divide these numbers by ten at least.

Second, the features. Do not blindly trust the statement like “we can unlock [vendor name] device and decrypt the data”. Do the fact check. In most cases, the vendor supports a limited number of model/firmware/software combinations, and there would be numerous limitations on top.

Analytics? Take that HTML report with the number of data records in every category. Application support? Built-in SQLite browser. Social graph? <Censored>.

Some companies will say in their press releases that they are “the first” or “the only” “leading solution providers” to do this or that. We laugh when we read that because in most cases it’s simply not true. And how many “leading solution providers” can you have, after all?

All that does not necessarily translate into a bad product. The actual product delivered may be awfully powerful, immensely useful, and have the broadest compatibility. I’d even go as far as saying you probably cannot live without it if you are doing the forensic job. But, do your due diligence. And keep in mind that you may have to take the costly software trainings to understand how to get the most out of that product – or simply use a certain feature. While this is rarely mandated, you will like need that anyway after spending a day or two struggling through the UI. Sometimes I am tempted to believe that the extra complexity is there on purpose.

You may ask: “Hey, ElcomSoft, aren’t you the same?”. The easy answer: don’t ask, just click that “Download” button and get the trial version. It’s free, and we won’t even ask for your name or email to spam you later. Nobody’s perfect, and we are far from believing our software sets the industry standard. What we do, however, is spending a good half of our time thinking how to improve our tools to make them easier to use; how to cut the learning curve, and how to develop a convenient UI so that you don’t have to hunt for that button. Sometimes we dare removing the user’s manual from the distribution package because it is not really needed. If we are saying that a certain feature is unique to our software and you cannot find it elsewhere – it simply means we looked hard, and that feature does not exist anywhere else. We dare you to prove us wrong.

Rambling complete; let’s go back to iOS.

The Kill Chain and the Weakest Link

The golden rule of cyber security: first, always get the full picture and review all possibilities; and second, always attack the weakest link. When cracking a password, you may spend centuries attacking BitLocker passwords, but instantly obtain the encryption keys from the volatile memory; or break a password on another file with weaker security, and the same password may work for BitLocker too.

In other words, always reach for the low-hanging fruit.

In that iPhone case, what do we really have? That could be:

• The device itself, locked or not, with or without the original SIM card.
• The computer (PC or Mac) the device has been connected to at least once.
• iCloud credentials.
• Some other credentials, e.g. to Google mail account.
• The suspect’s (well, the device owner) profile: personal data, habits, contacts, or whatever else.

How do we proceed from there? There are countless options. There is no (and could not be, even theoretically) a single “one-button” tool that would do your job and hand you the paperwork you could bring to the judge. Sorry, not going to happen. You’ll have to be the real expert to get the job done.

The Reality

Again, we cannot, even theoretically, think of all possible cases even for a single iPhone, and provide you with a straightforward workflow. We can only give you an idea, guide to the right direction, and give you a hint on what you can do. Sometimes. And you’ll need a lot of luck.

So, there was that one case we were helping a LE company in Eastern Europe with. The guys were working on a serious crime (sorry, no details), and this is what we’ve done.

In the beginning, we had the following data:

• Suspect uses iPhone 7 (no further info)
• Device itself is not available
• iCloud is probably used
• Computer (running macOS) of the suspect is available
• Current location of the suspect is not known

We (us and the LE guys) started with a Mac investigation. The first challenge: FileVault2 encryption. No access to the data without logon password. We imaged the disk in recovery mode and launched Distributed Password Recovery. The dictionary attack failed. We used a larger dictionary with millions of words; just wasted another two weeks. Back to the smaller dictionary, now with “mutations” (like adding digits at the end of every word, but more extensive); no success.

We gained access to the suspect’s Gmail account (don’t ask us how). To our luck, there was no 2FA there. Elcomsoft Cloud Explorer worked like a charm, and among other things (that really helped), it extracted passwords saved in Chrome. We saved them as a wordlist. Then we tried each password with the disk image – and voila, one of them just fits! Thanks God for password reuse!

Well, we now have access to the Mac disk. The next step? The suspect rarely used that Mac, so we found nothing interesting. Except one old iPhone backup created with iTunes.

That iTunes backup was really, really old, made some two years ago. It didn’t even belong to the suspect’s current iPhone, but an older iPhone 5S the suspect used before.

Next challenge: the iTunes backup is encrypted. We used Phone Breaker trying to break it (iOS version was 9.x, so the recovery speed was good enough), but we failed. Whatever we tried was failing: brute-force, dictionary (with both built-in dictionaries and custom ones created using all data from suspect’s profile), different mutation etc.

Did we forget something? The backup was created on a Mac, so its password might be saved in the Mac keychain! But… in that particular case, it wasn’t.

Someone else may give up there. But we did not. We exported all passwords from the Mac keychain (yes, we have a tool for that, Password Digger) and used it with Phone Breaker again. No luck. Mutations? Well, let’s try to use as many as we can, trying all possible combinations of existing passwords we have. Since we needed a lot more computational power than Phone Breaker could utilize, we loaded that task into Distributed Password Recovery, and added a bunch of Amazon EC2 instances.

Long story short, we did it. The backup password has been found. But… This was an old iPhone 5S, not the suspect’s current device! What’s next?

Again, that was a matter of luck.

When we work with encrypted iTunes backups (and the backup password is known or recovered), we actually get more than we get from a plain unencrypted backup – in particular, Health data, third-party app data and (probably the most important) the keychain.

So let’s have a look at the keychain using Phone Breaker. Web site passwords (nothing there); Wi-Fi passwords (nothing interesting); passwords to Web sites (same as we got from the Mac keychain), but no Apple iCloud password. It could be there, just not this time.

Dead end? Not yet. The iOS keychain has more than just passwords. It also stores authentication tokens, including the one for iCloud, and that token is always there if the device ever uses iCloud (does not matter whether the device has iCloud backups enabled or not).

That was it. We’ve got the iCloud token, and used it in Password Breaker to download synced data – contacts, notes, call log and web browsing history (but no iCloud keychain because it was not set up). Everything synced in real time (fortunately, the iCloud password did not change – if it would, the current device would still be synced, but we would not be able to get that data with that token). What we’ve got from iCloud was well enough to get the evidence. The (happy) end.

One More Thing

We have many more stories like this and would be happy to share them through “case studies”. One other story is about unlocking FileVault2 using data from the cloud; in that case, we had the locked iPhone and a pairing record from the PC. We used the pairing record to create a backup of the device using iOS Forensic Toolkit), then again accessed the iCloud, and extracted the disk recovery key from the account.

Again, each and every case is unique. That’s why we love our work.

If you are working on a similar case and want to know more about what we did, feel free to send us an email. We have numerous articles in our blog on some of those topics such as password cracking, extracting the keychain, using tokens and downloading iCloud synchronized data. But we’ll be happy to provide more information on request.