All posts by Vladimir Katalov

Every other day, Apple makes the work of forensic specialists harder. Speaking of iCloud, we partially covered this topic in Apple vs. Law Enforcement: Cloud Forensics and Apple vs Law Enforcement: Cloudy Times, but there is more to it today. The recent iOS (13.4) and macOS (10.15.4) releases brought some nasty surprises. Let’s talk about them.

iOS 13

It is difficult to say when it actually happened, but iOS stopped syncing call logs, and does not sync them for the time being. We covered call log sync some three years ago:

We even tried to bring the matter to Apple, but the only response was we take privacy very seriously (I am not surprised). Anyway; call logs are no longer synchronized (com’on, Apple, did you forget about Continuity? 😊)

But there is more. Do you use Apple Maps? Its data, surprisingly, has been moved to an encrypted container, similar to other protected data such as the iCloud keychain, iCloud Messages, Health and Screen Time data. It’s a strange move, as Maps data is not all that sensitive compared to other bits stored in secured containers. While we can still obtain that data from the cloud, the procedure now relies on the process for extracting other end-to-end encrypted data, which means you have to use the password/passcode of one of the user’s devices.

Just in case: if you are curious about Screen Time, we are currently able to extract only part of the data from iCloud. This includes the passcode, family information, restrictions etc. The most interesting data such as app usage statistics seems to sync directly across devices, but it is not stored in the way that would allow us to extract it from the cloud. If you have more than one device and use the Share across devices option, just compare the statistics you see on the device it’s been collected from and how it appears on other devices on the account. The results are different. Moreover, some stats are not available at all, while there is some mysterious data from devices that have been disconnected from the account a long time ago. A lot of iPhone users reported similar problems:

This can mean that such ‘direct’ syncing simply does not work correctly. It is difficult to say whether it is an iOS 12/13 or iCloud bug, but we decided not to waste our time trying to obtain this data from iCloud. And btw, in iOS 13 the data related to Screen Time is also protected better than most of other data — it is not enough just to have root privileges to access it.

Oh by the way, iOS 13.4.5 beta (what a strange version number after 13.4) is out yesterday, we are going to have a look at it soon.

macOS

Lockdown (pairing) records had always allowed to access passcode-protected devices. However, with the latest update, lockdown records are no longer accessible.

Starting with maCOS 10.12, you had to to run the following command:

sudo chmod 755 /private/var/db/lockdown

With macOS 10.15.4, it does not work anymore:Is there a workaround? Yes. Just disable SIP (System Integrity Protection) by booting into Recovery mode (+R on system startup), then start Terminal and run the following command:

csrutil disable

Then reboot, and access lockdown folder as you did before, e.g. to perform advanced logical acquisition of a locked iPhone using iOS Forensic Toolkit.

iCloud

iCloud authentication has changed again. Looks like Apple have a dedicated team of software engineers that do nothing but make meaningless changes to authentication protocols just to block our software. This does not really improve the security and privacy but makes Apple’s top management happy.

I am not going to describe all the changes in details, but give you some tips on how this affects the usage of authentication tokens in Elcomsoft Phone Breaker. You can start reading from Accessing iCloud With and Without a Password in 2019; and here is how it works now.

On Windows systems, tokens extracted from iCloud  for Windows version 7.0 and later work only for accounts without two-factor authentication. With these tokens, you won’t be able to access the entire set of iCloud data. The following categories are still accessible: iCloud Photos and certain synced categories (including contacts, calendars, notes, Safari browsing history etc. except end-to-end encrypted data such as the Keychain, iCloud Messages or Health data). As for iCloud backups, you can only retrieve ones created by iOS versions older than iOS 11.2.

On macOS, the situation is slightly better. On macOS from 10.13 to 10.15, we can get the token for non-2FA accounts only; and for ones that have 2FA enabled, the token is, well, ‘tethered’ to the device it is obtained from, so you can authenticate with this token in Elcomsoft Phone Breaker only on the same Mac. The scope of the data that can be downlooaded from the iCloud (regardless the account and token type) is the same as above: limited number of categories of synced data (without end-to-end encryption), and iCloud backups of devices with iOS up to 11.2. Fully ‘untethered’ tokens for 2FA accounts are only available in macOS 10.12 and older. In fact we recently used a kind of vulnerability in iCloud protocol that allowed us to get such tokens even for 2FA accounts, but not anymore, sorry.

Sounds confusing? I know. Here it is once again:

  • We can always get a token for non-2FA accounts
  • For 2FA accounts, tokens from most (modern) Windows systems are completely useless, while tokens from modern macOS versions can be used on the same system only
  • Tokens can be used to access only a limited amount of data from iCloud

One more thing: some changes have been made even for accounts without 2FA. Due to these changes, Apple can now lock accounts after a single incorrect password attempt.

Conclusion

To obtain all the data from the user’s iCloud account, you will need the Apple ID, the password, the second authentication factor, and the device passcode. If you have all of those, you can obtain virtually everything, including some of the data that is not available on the device itself. Do not underestimate this method, and remember that Elcomsoft Phone Breaker is the only product on the market that extracts all the data from iCloud including end-to-end encrypted categories.

We recently introduced a new acquisition method for iPhone and iPad devices. The fast, simple and safe extraction agent requires no jailbreak, and delivers the full file system image and the keychain. The latest release of Elcomsoft iOS Forensic Toolkit expanded this method to iOS 13 and filled the gaps in some versions of iOS 12 that were missing support (such as iOS 12.3 and 12.4.1). Finally, we now officially support the latest generation of iPhone devices including the iPhone 11, iPhone 11 and iPhone 11 Pro. The new compatibility matrix becomes significantly more diverse with this release, so bear with us to learn which iOS devices can be extracted without a jailbreak.

Compatibility

The extraction agent is supported on the following models and iOS versions:

  • iPhone 6s to iPhone X, iPad 5th and 6th gen, iPad Pro 1st and 2nd gen: iOS/iPadOS 11.0 – 13.3
  • iPhone Xr, Xs, Xs Max, iPad Mini 5, iPad Air 3rd gen, iPad Pro 3rd gen, iPod Touch 7th gen: iOS/iPadOS 12.0 – 13.3
  • iPhone 11, 11 Pro, 11 Pro Max: iOS 13.0 – 13.3

For some older models, compatibility remains unchanged. The following models are supported if running iOS 11-12.2 and iOS 12.4:

  • iPhone 5s, 6, 6 Plus
  • iPad Mini 2 and 3
  • iPad Air (1st gen)

There are two ‘iffy’ models: the iPad Mini 4 and iPad Air 2. While the agent-based extraction method will sure work on these models running iOS 11 through 12.2, we have not tested them with iOS 12.3, 12.4.1 or any version of iOS 13.

Requirements

Make sure that your device model and OS version are compatible, and register an Apple Developer account (here is why). Of course, you will need the latest version of iOS Forensic Toolkit, too. The software is really simple to use, but we still recommend to attend our trainings.

General advantages

The main advantage of this method is its wide compatibility with multiple iPhone and iPad models. In the future, we may add support for older iOS versions (to avoid all the troubles with jailbreaking, see below), and of course will do our best to add compatibility with newer versions (iOS 13.3.1 and up).

Next, the extraction agent is safe and reliable. Nothing wrong may happen; the worst is just a reboot of the device, or our method may simply not work on your device. See the Trobleshooting section below for some tips; sometimes it takes several tries (though usually it works from the first try).

Forensically sound? It depends on what you mean by that. Here is a good definition:

Digital evidence is said to be forensically sound if it was collected, analyzed, handled and stored in a manner that is acceptable by the law, and there is reasonable evidence to prove so. Forensic soundness gives reasonable assurance that digital evidence was not corrupted or destroyed during investigative processes whether on purpose or by accident.

(another good source: When is Digital Evidence Forensically Sound?)

For 64-bit iPhones (starting with the iPhone 5s), there is NO method of data acquisition that does not make ANY changes to the system, despite what other vendors say. Some traces are always left, like records in some system logs.

Next, the extraction speed. Instead of re-using ssh, we transfer the data directly over the USB. This method is more reliable and significantly faster; on modern iPhone models, the speed is about 2.5 GB/min.

Finally, the simplicity. No, it is still far from the proverbial “one button” solution, which simply does not exist in the area. Still, we did our best to make acquisition as simple and straightforward as possible, and we are still improving it. Just follow the software manual carefully, and make sure you read the articles published in our blog.

Last but not least. The agent extracts not only the full file system but also the complete keychain. While you can also extract the keychain from iTunes-style-backups, it won’t be complete as a lot of records cannot be decrypted. Use Elcomsoft Phone Breaker to view all the keychain records:

Advantages over jailbreaking

One can also perform full file system acquisition even for latest iPhone models with iOS 13 through jailbreaking. But there are some things you should know.

Jailbreaking is not completely safe. It may brick the device or put it into a boot loop, and it also makes multiple changes to the device file system, even with the rootless jailbreak.

Are there any disadvantages of agent-based extraction? Not a single one, at least for iOS 11.0 to 13.3. Except checkra1n (see below).

One more thing. With iOS 13, some files and folders have improved security attributes and are not accessible by tar over ssh. There is no such problem with agent-based acquisition.

We even made our method compatible with intermediate beta versions of iOS (in the 11-13.3 range) where jailbreaks do not work at all.

Advantages over checkm8 extraction

checkm8-based acquisition is pretty nice, but the devil is in the detail.

First, checkm8 is compatible with a limited number of devices and iOS versions: iPhone 5s to iPhone X, and iOS from 12.3. So forget about the iPhone Xr, Xs, 11 and 11 Pro (as well as many iPads); they are not vulnerable to this exploit. Also, despite the fact that the exploit is hardware-based, the checkra1n jailbreak (and all current checkm8-based acquisition processes) are NOT compatible with iOS 12.2 and below.

Second, the checkra1n jailbreak is not 100% reliable. There are so many compatible devices it does not work on, and the same about direct checkm8 implementation. If there is an error, you’re stuck with it; moreover, you can even ‘brick’ the device with it (it really happened to couple of our test devices). How about the speed? Amazingly low, thanks to ssh and some other things. Some extractions cannot complete in a week, we have no idea why.

The only two real advantages of checkra1n/checkm8 are: they do not require an Apple Developer account, and they allow BFU (Before First Unlock) extractions for devices with an unknown passcode. Also, checkra1n supports iOS 13.3.1 (the latest version at the time of writing this article, though 13.4 is expected very soon). You can use still checkra1n with our iOS Forensic Toolkit to get partial file system and keychain extraction of locked and even desiabled devices.

Usage & troubleshooting

Make sure you have read the iOS Forensic Toolkit manual first, as well as the following two articles:

We described all the steps at iPhone Acquisition Without a Jailbreak (iOS 11 and 12):

  • Put the device into airplane mode (this is mandatory!) and connect it to the computer with EIFT. Make sure that Wi-Fi and Bluetooth are disabled from iOS settings (and not from from the Control Centre)
  • Establish trust relationship (otherwise you will get the “ERROR: Could not connect to lockdownd, error code -2” message in the EIFT)
  • Install the extraction agent though EIFT. You will need to enter Apple ID and app-specific password of the developer’s account, followed by the TeamID; please note that signing the agent requires an internet connection on your computer (but NOT on the iOS device, which should remain offline at all times).
  • Once the agent is installed, it is recommended to disable all Internet connections on the computer you perform the acquisition on.
  • Tun the Agent on the device and leave it running in the foreground.
  • Acquire the keychain and capture the file system; during keychain acquisition, you will have to enter the passcode on the device (sometimes twice), or unlock using Touch ID or Face ID (for devices with Face ID, you will first receive the prompt whether you allow Agent to use it for keychain access)
  • Uninstall the agent.

If something goes wrong when you run the extraction agent on the device (e.g. “Can’t connect to device on specified port” message in EIFT), you may need to reboot the device; make sure to wait for at least one minute after rebooting before starting an agent.


Quick tip: if you do not want to enter Apple ID, password and Team ID when installing the Agent on every new device, you can set them up right in the EIFT script (Windows: Toolkit.cmd, lines 20-22; macOS: macosx/Toolkit.sh, lines 42-44):

AGENT_ID=john.doe@gmail.com
AGENT_PASSWORD=abcd-efgh-ijkl-mnop
AGENT_TEAMID=XXXXXXXXXX

Where AGENT_ID is the Apple ID enrolled into Apple Developer Program; AGENT_PASSWORD is app-specific password you should generate on your account, and AGENT_TEAMID is the Team ID (you can easily find it by logging in to Apple’s Developer Center, under Membership Information in Account | Membership).

The popular unc0ver jailbreak has been updated to v4, and this is quite a big deal. The newest update advertises support for the latest A12 and A13 devices running iOS 13 through 13.3. The current version of iOS is 13.3.1. None of the older versions (including iOS 13.3) are signed, but still there are a lot of A12/A12X/A13 devices floating around. Until now, file system and keychain extraction was a big problem. The newest unc0ver jailbreak makes it possible.

The new build is based on an exploit that is quite reliable by itself. However, jailbreaking is more than just a single exploit; a lot of things (that are outside the scope of this article) have to be done. So the new version of a jailbreak is not a silver bullet, and may still fail on many devices; we have tested a few and received mixed results. Still, if the given device can be jailbroken with unc0ver, it means that we can pull all the data from it, down to the last bit.

ICYMI: iPhones and iPads based on A12/A12X/A13 SoC are not vulnerable to checkm8 exploit, and there is no room for BFU acquisition (if the passcode is not known). That means that jailbreaking them using iOS (not bootrom) exploits is the only way to get all the data, at least for now.

Installing the jailbreak

The jailbreak (curren version: 4.0.2) is available as an IPA file (iOS/iPadOS package). There are several methods of installing it, but they usually require signing the IPA using a third-party certificate, which is not very safe and requires approving the certificate on the device, which in turn means that you have allow the device make an Internet connection. This in turn means that the device can be remotely locked or wiped (and even if Find My is disabled, it may sync and modify the data. The only workaround is to set up the network so that that it can only access the Apple’s servers that take care of certificate approval, but this is not not as easy as it sounds.

The better and safer way is to sign the jailbreak IPA with a developer’s certificate using Cydia Impactor. You will need a developer’s account to do that. If you have one, create an Application-specific password first as Cydia Impactor does not natively support 2FA.

Once the IPA is installed, just run it and press [Jailbreak]. That simple.

Well, not quite. First, you have to press [Settings] in the top-right corner and enable the following options:

  • Re(Install) OpenSSH
  • SSH Only
  • Read-Only RootFS

What is it all about? Install OpenSSH (which is not installed by default); do not install Cydia (not only you won’t need it for the purpose of file system extraction, but removing Cydia after you’re done is a separate headache); do not remount the system partition, making the jailbreak rootless, safer, and with a minimum impact. I would not say “forensically sound”. But very close to that.

Note that the new build of unc0ver is not very reliable yet. If it fails, here is what the jailbreak developers recommend:

To everyone having reliability issues. You must follow those conditions carefully to have the best success:
– reboot
– airplane mode
– lock device
– wait 30 seconds (don’t do anything)
– jailbreak

A better exploitation method is required to avoid this. We’ll try our best.

Data acquisition

iOS Forensic Toolkit is all you need. First, do not miss some basic usage tips:

Ready to go? Extract the keychain and the file system first. Just note that with the keychain extraction, you may get error/warning messages like the following:

[+] memory_size: 3962028032
[-] no offsets for iPad8,1 17C54
[e] error reading kernel @0x0
[-] no kernel_call addresses for iPad8,1 17C54 [e] error reading kernel @0x0 Injecting to trust cache...
Actually injecting 1 keys
1 new hashes to inject
Successfully injected [1/1] to trust cache.
[e] error writing kernel @0x0

Just ignore them for now, we will take care on them later; they don’t seem to affect the keychain acquisition.

As for the file system, please note that if you forget to set the appropriate unc0ver options and install OpenSSH later from Cydia, acquisition will probably fail. The OpenSSH client installed alongside with the jailbreak works fine.

Anything else? Almost everything matters. Including whether you connect the iPhone directly or through a USB hub; the type of the cable (USB-A or USB-C to Lightning); and even the brand of the cable (original or not). Do not ask us why, ask Apple. To our experience, you get the best results when using an original Apple USB-A to Lightning cable connected directly (with no hubs); also, it works better on Macs. Yes, even that matters.

Data analysis

For “quick and dirty” analysis, use Elcomsoft Phone Viewer to browse the data acquired by iOS Forensic Toolkit. Do not underestimate this little tool; it does not parse all the data categories, but you will be surprised by the amount of data it can extract from media files (including deleted ones), locations, Apple Pay, Wallet etc. All the most-critical evidence is there.

Need more, including system databases, building the complete Timeline, defining social links between device contacts and extractions in Social Graph, getting comprehensive data analysis with facial recognition and image categorization, advanced data search and detailed reports? Get Oxygen Forensic Detective.

Did you extract the keychain? That’s a gold mine. Not just all the passwords and tokens (for dozens web sites, social networks, mail accounts and more), but also the encryption keys that will allow you to decrypt WhatsApp and Signal conversations. Use Elcomsoft Phone Breaker to browse it in a very convenient way (well, three ways); there you will be also able to export passwords to a wordlist, allowing you to break other files, documents and systems almost instantly.

Just days ago, we have reviewed the data stored in iCloud, and studied its encryption mechanisms. We also discussed the discrepancies between the data that is stored in the cloud and the data that’s provided to the law enforcement. In case you missed it, make sure to check out Apple vs. Law Enforcement: Cloud Forensics. Today, the differences are great; Apple is using point-to-point encryption to protect certain types of data. However, it has not always been that way. Apple security model changed year after year. This article reviews the timeline of Apple security changes over time.

We’ll list the security measures and discuss whether the real purpose of these changes were the customers’ security and privacy, or throwing a monkey wrench into the work of the law enforcement. We will also try to understand where iCloud security stands today, and how safe your data is against hackers and the law enforcement. Are you a forensic professional? I think you’ll find this article handy.

Apple iCloud: the beginning

Apple has introduced iCloud in October 2011, replacing the aging MobileMe service. At that time, Apple iCloud services were based solely on Amazon and Microsoft Azure servers (new platforms have been added a few years later). Using iCloud on the iPhone required installing iOS 5.

Apple iCloud today provides a range of services including synchronization of data across devices connected to the account, iCloud backups for iOS and iPadOS devices, iCloud Drive (just the storage), as well as the Find My service.

iCloud security

While you can always refer to the source in iCloud security overview, I can give you a shorter and simpler description.

First, all iCloud data (including backups) is stored on third-party servers. These servers are owned by Amazon, Google, Microsoft, or the Chinese government in the case of Chinese users. We also witnessed some mysterious AT&T data centers in the past.

Second, all that data is always encrypted.

Third, the encryption keys for most of that data are also retained by Apple. However, the keys are not stored on the same physical servers; instead, Apple keeps them in Apple-owned data centers under the company’s full control. Interestingly, this seems to be the case even for data stored in China (where iCloud data itself is located on Chinese servers only).

Careful readers noticed the “most” part. The “most” part does not mean that the data is not encrypted; it’s rather the opposite. More on that in “end to end encryption” below.

Do the same rules apply to iCloud backups? Yes, they do. A couple years ago, Apple war rumored to have plans to encrypt iCloud backups in a more secure way (potentially with end-to-end encryption). Those plans have been but finally rejected it, probably under FBI pressure, but only Apple knows the actual reasons.

Two-factor authentication: 2SV, 2FA and iCloud backups

Today, it is hard to believe that an online account that holds your personal data may not support two-factor authentication. Online threats and phishing are the main risks, and if you re-use your passwords, the situation is even worse.

In the first two years, iCloud did not have any kind of two-factor authentication. One was only added in 2013, but the half-baked solution only protected access to the account itself, and not to iCloud backups. We wrote about that in Apple Two-Factor Authentication and iCloud.

You probably remember what happened next. Celebgate. Only after that, Apple applied second-factor protection to backups.

It is important to note that Apple’s initial implementation (called Two-Step Verification, 2SV) was not perfect. It was a rushed afterthought. The current implementation of two-factor authentication (2FA) was introduced with iOS 9 in 2015, and it offers good protection.

We covered this subject many times:

It’s all about the tokens

In 2014 (the year when Apple added 2SV to iCloud backups), we got a bright idea. If you set up your computer to access iCloud account*, you won’t be prompted for your password or prompted for a one-time code every time you access the cloud. This means that the authentication token could be saved somewhere. Could we use that token to bypass password-based authentication?

* iCloud access is a built-in feature on a Mac, while “iCloud Control Panel” is required on Windows; its current name is iCloud for WIndows.

It worked; see Breaking Into iCloud: No Password Required. Having the token obtained, we were able to download iCloud backups (and later implemented the same technique to download other/synced data from iCloud).

Did our work introduce a new security risk for iCloud account owners? Probably not (or just a little), as extraction and decryption of the tokens requires physical access to the computer, as well as administrative privileges (and if you have both, there are much more serious risks involved).

However, Apple took it seriously, and since then, implemented additional security measures related to tokens, in particular:

  • Limited lifetime. The token worked perfectly for synced data. When accessing iCloud backups, its lifetime was limited first to 24 hours, and then to just one hour.
  • Limited use. Currently, the token stored on the device is only good for a limited number of categories including iCloud Photo Library and most synced data and excluding end-to-end encrypted data. Tokens cannot be used for accessing iCloud backups.
  • Pin to device. That was the biggest surprise. After some changes Apple did last year, the token could be used (even for accessing a limited set of data) on the same computer only. On macOS, we have recently found a way to obtain an “unpinned” token that can be used on other computers, but there is no way to do that for Windows.

Still, it is theoretically possible to obtain full-featured “unpinned” tokens that allow obtaining almost everything from iCloud from a trusted macOS computer. We are working hard in this direction; watch our blog for updates. Still no access to backups though. Apple did everything to get iCloud backups extremely hard, even if you know the password and have the second authentication factor.

End-to-end encryption (they call it so)

C’mon, Apple, please do not call it “end-to-end”, that term is reserved for the case when some data can be only decrypted at the end point, because it is the only place that holds the decryption key. Yes, trusted iPhones do have the key, but we can get one even from the outside and without access to the device. This isn’t exactly end-to-end, is it?

What does Apple protect with this “end-to-end” encryption? This encryption covers data that belongs to the following categories: iCloud keychain, Health data, messages in iCloud, Home data, and (surprisingly!) some Apple Maps data, even though Apple does not mention that.

All that data is stored in iCloud and synchronized across “trusted devices”. In case if you did not know, the key to decrypt that data is also stored in iCloud (even if Apple wants you – and the law enforcement – to believe otherwise). That key, however, has stronger protection than the general iCloud encryption keys (that could be probably called “snake oil”) and can only be accessed by devices that are part of the “trusted circle”.

Can someone enter into the trusted circle? Of course, but not easily so.

Notifications, account locks, GSA and other changes

There are a couple extra security measures related to iCloud backups we have not mentioned.

First, you probably noticed that once the backup restoration process is completed, the notification is being sent to the account owner (by email).

Second, Apple does its best to detect whether download process is initiated by the actual device or by third-part software like ours.

We did our best to ‘mimic’ the device, but suppress the ‘restore’ notification. Currently, it works, but it looks like Apple has a dedicated team of security specialists working against our software.

On a regular basis, Apple changes everything they can: protocols, encryption, and data storage formats. Some of these changes are reasonable, while the other (solid!) part of these changes is intended only as a countermeasure against forensic tools, while adding little to no extra security to iCloud.

Have I mentioned GSA (Grand Slam Authentication) and “anisette data”? I was not going to dive deep into technical details, but you can search for my presentations on this subject; they are publically available.

The dark side of the cloud

Are you sure that you know all of the following?

  • What information is synced between your device and iCloud (or just uploaded to iCloud)
  • If Apple really deletes your data from iCloud when you delete it from the device
  • What information Apple provides to the law enforcement once they are served with a legal request

Nobody knows, and I have some surprises for you.

First, Apple syncs more data with iCloud than it publically admits. A good example is the call log (the list of incoming and outgoing calls); there is no option on the iPhone that disables syncing.

Second, there is some extra data in iCloud such as iCloud access logs, stored for 28 days. It includes your IP address (it can be used to get physical location) and the time stamp.

Next, it is not clear what really happens when you delete the data. In the past, we found some of the data to remain on Apple’s server past the advertised retention time, including media files (photos and videos), Web history and notes. Moreover, we have found a way to extract it. At this time, our method does not work anymore, but we never know whether it is still saved somewhere, and if it is, whether it is provided to law enforcement agencies (maybe just the select few).

Bonus track: Google and Microsoft

This is definitely outside the scope of this article, but you might be curious how Apple iCloud security compares to Google and Microsoft, the other two major cloud vendors.

Neither of these companies offer detailed descriptions on how they store and encrypt the user’s data. Still, it is not too hard to guess, based on what we know.

Google saves enormous amounts of data. It sources the data from all the devices running their software or using their services, and not just from Android. As opposed to Apple, even though Google provides granular control to what data is stored or synced, it is not easy to disable or enable data syncing from the device(s). The data stored by Google usually includes detailed location history, a comprehensive history of the user’s search queries, all of the user’s purchases (not just with Google), and a lot more.

Microsoft syncs or may sync less data than Apple and Google, but the company still has some. This includes Web history and Bing searches, contacts, Cortana commands, Skype conversations and more, including BitLocker recovery keys. Microsoft does not make it very clear what data is saved in the account.

Cloud acquisition

If you want to get the maximum amount of data from Apple iCloud, you have no choice but use Elcomsoft Phone Breaker. iCloud backups, files from iCloud Drive, iCloud Photos, FileVailt2 recovery token, iCloud keychain and all end-to-end encrypted data such as messages, Health, Screen Time and more, you can obtain all of that. This product can also extract the data from Microsoft accounts, from contacts to Skype conversations.

For Google accounts, use Elcomsoft Cloud eXplorer. The only thing we cannot get is Android device backups as they are securely encrypted (we continue our research).

When it comes to other cloud data, Oxygen Forensic Suite leaves no place for competitors. The number of cloud sources it supports is impressive (close to one hundred), including Telegram, Samsung cloud, Xiaomi Mi Cloud, Huawei Cloud and dozens others, including third-party apps that sync enormous amount of data (and so the evidence). All that stuff is continuously improved and perfectly supported according to the vendors’ changes, contrary to similar products from other vendors, even those that are more expensive and pretend to be “number one”. Seriously, do not waste your time trying the others: you will get a result that is not even close. Do not trust vendors’ claims, but verify yourself.

Protecting your data

Do you want to make your iCloud account secure? Don’t use it this way! Just kidding; the iPhone without iCloud is quite a Samsung.

The very first thing I would recommend is requesting a copy of your data from Apple’s Data & Pricacy Portal and analyzing it carefully. About the same amount of data (plus backups) will be provided to the law enforcement if requested.

A more effective way is using Elcomsoft Phone Breaker to get everything including “end-to-end encrypted data”.

If you decide to keep using iCloud, here is what we can recommend (simple and probably well-known, but still often overlooked):

  • Use a secure iCloud password, long and complex enough.
  • Make sure that password does not look similar to any other passwords you use. Of course, it must not be identical to any other password you have.
  • Don’t cache that password in your Web browser, ever.
  • Don’t ever store that password in your Google Account.
  • Don’t store that password in the keychain (iOS, iPadOS or macOS).
  • Use two-factor authentication (I know some people who don’t).
  • Use strong passcode/password on your iOS device(s) and desktop(s).
  • Physically secure all your devices and never leave them unattended (even locked).
  • Did I mention you should never re-use your passwords and passcodes?
  • Keep all your devices updated to the latest system (iOS/iPadOS/Windows/macOS), and do not forget about your Apple TV and Apple Watch.
  • If you are using an old Android (more than one year old), don’t count on updates to arrive. Just buy the current flagship.
  • For Windows, follow our recommendations listed here; the macOS guide will follow.
  • Be aware of checkm8 exploit if you are using an old device. Make sure you know that some data can be extracted even from locked and disabled devices.
  • Remember how to enable the SOS mode.
  • Know how to use Find My

If you work for law enforcement

Speaking of iCloud, you have several options. First, read our recent Apple vs. Law Enforcement: Cloud Forensics for better understanding what is stored in iCloud, how it is encrypted and protected, and what your options are. In general, you need to analyze all devices the suspect regularly used, and probably even those that’ve been used at least once. You might be able to get lockdown records, leading you to locked device access; or extract passwords saved in the browser. Better yet, attend one of the ElcomSoft trainings to understand how to obtain as much data as possible from every available source. We don’t just tell you how to use our software. Instead, we’re offering the complete workflow, talk about the typical mistakes and share our knowledge and expertise.

Conclusion

So what about iCloud security today? I would say, it is generally OK. More information here:

Still, we have two conflicting thoughts. First, Apple saves a lot of data in iCloud, and we don’t know all the details. The fact that others are (much) worse in this respect doesn’t change much. Second, Apple makes the work of forensic experts unnecessarily more complicated without making any real security improvements, all the time. Apple, it’s hard to wear two hats.

What can possibly go wrong with that iPhone? I’ll have a look (oh, it’s locked!), then switch it off, eject the SIM card and pass it on to the expert. Well, you’ve just made three of the five most common mistakes making subsequent unlock and extraction attempts significantly more difficult. Learn about the most common mistakes and their consequences.

Power off

The first and probably the most important step (or at least one of) is data preservation, to make sure that the device content does not change, device will not discharge, will not be remotely locked or wiped etc. We made some introduction to the process in our The Art of iPhone Acquisition article, but you know what many forensic “experts” (sorry for the quotes) do first, instead of turning the airplane mode on or placing the device into Faraday bag?

They turn it off.

Granted, a powered-off device won’t make an accidental connection or self-discharge rapidly. However, if the device is powered off, you’re making the device switch from the forensic-friendly AFU* mode into the locked-down BFU* mode. As a result, several things happen.

  • The encryption keys are wiped from the device RAM (no instant AFU extraction possible)
  • Passcode recovery attack falls to BFU speeds (much slower than AFU attacks)
  • Biometric authentication becomes impossible
  • Lockdown records become useless; logical acquisition impossible
  • Extremely limited BFU extraction

AFU: After First Unlock; the condition in which the device has been unlocked with a passcode at least once after being powered on or rebooted.

BFU: Before First Unlock; the condition in which the device rebooted or powered on and has never been unlocked.

Ejecting SIM card

What’s the next most common mistake in mobile forensics? It’s removing the SIM card, usually just to make sure that device does not make an accidental connection to a mobile network. I would not say it is fatal, but here is what happens, at least when the device is running iOS 11, 12 or 13:

  • The phone locks immediately
  • Biometric unlock disabled (until unlocked with the passcode)
  • USB restricted mode activated

More on biometric authentication: Passcode vs. Biometrics: Forensic Implications of Touch ID and Face ID in iOS 12; on USB restricted mode: USB Restricted Mode Inside Out (updates: iOS 12 Enhances USB Restricted Mode and USB Restricted Mode in iOS 13: Apple vs. GrayKey, Round Two).

I believe no further explanation is needed. In short, you may completely lose an opportunity to unlock or further analyze the device.

“Don’t hold it that way”

Steve Jobs was never wrong. If you hold a modern iPhone equipped with Face ID, you’re likely to waste one or more attempts to unlock the device by pointing it towards the suspect. Why? This YouTube clip shows what happened during the iPhone X announcement.

As to the iPhones with Touch ID, make sure to never touch the fingerprint sensor. Otherwise you’ll just lose one of the five biometric unlock attempts.

Resetting backup password

In most cases (unless the device can be jailbroken or vulnerable to the checkm8 exploit), an iTunes backup is the main source of data. iPhone backups, however, are really special (see

The Most Unusual Things about iPhone Backups for details).

If the backup is password-protected, it could be a problem. Starting with iOS 10.1, brute-force password recovery is virtually impossible (though we can try, and have the software for that). However, as you know, iOS 11 Makes Logical Acquisition Trivial, Allows Resetting iTunes Backup Password.

The problem is that all passwords in Apple ecosystem are connected to each other (Four and a Half Apple Passwords). And if you reset the backup password (as it was done recently by FTI Consulting when investigating the hack of Jeff Bezos’ Phone, see the report), then the iPhone passcode is also reset. And that has bad, really bad consequences. First, you are going to lose the saved Wi-Fi passwords, Apple Pay transaction history, downloaded Exchange mail and some other data. Second (and this is critical), you lose all the things you could do with the passcode. Like what things? See iOS 11 Horror Story: the Rise and Fall of iOS Security and Protecting Your Data and Apple Account If They Know Your iPhone Passcode. This includes (but not limited to) access to end-to-end encrypted data in iCloud including the iCloud keychain, synced messages, Health data etc.

iOS logical acquisition

In fact, logical acquisition is not as simple as it sounds. Just create iTunes-styles backup and that’s it, right? Not quite. Several things can go wrong.

Creating a backup with iTunes. This is acceptable in general; all forensic packages create exactly the same backups as iTunes. In fact, backups are made by the service running on the iPhone itself, and not by desktop software. However, if you forget to disable iTunes sync in advance (before connecting the iPhone to the computer), the content on the device may change.

Making a passwordless backup. A backup without a password is easier to analyze, right? Yes, it is, but the devil is in the details. Backups without a password contain less data than password-protected backups. You will not get the keychain, Health data, Safari browsing history and call logs (at least).

Miss something. Well, actually a lot. Proper logical acquisition is not limited to backups. In fact, backups are just the beginning. You can also obtain media files (and not just files but also a metadata, sometimes even on deleted files), app shared data (including but not limited to media players, office packages and even some password managers), crash and diagnostic logs (the ultimate source of data that could really help building the timeline). All of that regardless of whether or not the user has a backup password. This, by the way, can be done for Apple Watch and Apple TV devices, thanks to Elcomsoft iOS Forensic Toolkit.

Conclusion

I just listed the most common mistakes made by the law enforcement and forensic experts. We’ve seen many more of those, albeit less frequently. Strictly following the correct workflow, documenting your every step, ensuring that your steps are repeatable and results verifiable, cross-matching the results and proper reporting are essential. Just using a “tool” is not nearly enough, even if it’s the best tool on the market. The environment is always changing, and you either keep up, or fall behind. Taking a training course is one of the better ways to keep up with the ever changing mobile forensic and computer forensic environment.

We have recently updated Elcomsoft iOS Forensic Toolkit, adding the ability to acquire the file system from a wide range of iOS devices. The supported devices include models ranging from the iPhone 5s through the iPhone X regardless of the iOS version; more on that in iOS Device Acquisition with checkra1n Jailbreak. In today’s update (for both Windows and macOS platforms as usual), we’ve added the ability to extract select keychain records in the BFU (Before First Unlock) mode. We have a few other changes and some tips on extracting locked and disabled devices.

BFU Forensics

The BFU stands for “Before First Unlock”. BFU devices are those that have been powered off or rebooted and have never been subsequently unlocked, not even once, by entering the correct screen lock passcode.

In Apple’s world, the content of the iPhone remains securely encrypted until the moment the user taps in their screen lock passcode. The screen lock passcode is absolutely required to generate the encryption key, which in turn is absolutely required to decrypt the iPhone’s file system. In other words, almost everything inside the iPhone remains encrypted until the user unlocks it with their passcode after the phone starts up.

It is the “almost” part of the “everything” that we target in this update. We’ve discovered that certain bits and pieces are available in iOS devices even before the first unlock. In particular, some keychain items containing authentication credentials for email accounts and a number of authentication tokens are available before first unlock. This is by design; these bits and pieces are needed to allow the iPhone to start up correctly before the user punches in the passcode. (more…)

We’ve just announced a major update to iOS Forensic Toolkit, now supporting the full range of devices that can be exploited with the unpatchable checkra1n jailbreak.  Why is the checkra1n jailbreak so important for the forensic community, and what new opportunities in acquiring Apple devices does it present to forensic experts? We’ll find out what types of data are available on both AFU (after first unlock) and BFU (before first unlock) devices, discuss the possibilities of acquiring locked iPhones, and provide instructions on installing the checkra1n jailbreak. (more…)

Are you excited about the new checkm8 exploit? If you haven’t heard of this major development in the world of iOS jailbreaks, I would recommend to read the Technical analysis of the checkm8 exploit aricle, as well as Developer of Checkm8 explains why iDevice jailbreak exploit is a game changer. The good news is that a jailbreak based on this exploit is already available, look at the checkra1n web site.

The jailbreak based on checkm8 supports iPhone devices based on Apple’s 64-bit platform ranging from the iPhone 5s all the way up to the iPhone 8 and iPhone X. Unlike previous jailbreaks, this one supports most iOS versions, up to and including iOS 13.2.2 at the time of  this writing. Support for future versions of iOS is also possible due to the nature of this exploit. Most iPads are also supported. Currently, there is no support for the Apple Watch, though theoretically it is possible for Series 1, 2 and 3. The Apple TV series 4 and 4K are supported by the exploit, and a jailbreak for series 4 is already available.

What does that mean for the forensic crowd? Most importantly, the jailbreak can be installed even on locked devices, as it works through DFU mode. That does not mean that you will be able to break the passcode. While you can extract some data from a locked device / unknown passcode, it won’t be much. From the other side, the jailbreak allows to dump the complete image of the file system if the passcode is known. This works for all devices from the iPhone 5s to X, many iPads, and Apple TV 4.

In this article, we will briefly describe how to install the jailbreak on Apple TV and what you can expect out of it.

(more…)

Passwords are probably the oldest authentication method. Despite their age, passwords remain the most popular authentication method in today’s digital age. Compared to other authentication mechanisms, they have many tangible benefits. They can be as complex or as easy to remember as needed; they can be easy to use and secure at the same time (if used properly).

The number of passwords an average person has to remember is growing exponentially. Back in 2017, an average home user had to cope with nearly 20 passwords (presumably they would be unique passwords). An average business employee had to cope with 191 passwords. Passwords are everywhere. Even your phone has more than one password. Speaking of Apple iPhone, the thing may require as many as four (and a half) passwords to get you going. To make things even more complicated, the four and a half passwords are seriously related to each other. Let’s list them:

  • Screen lock password (this is your iPhone passcode)
  • iCloud password (this is your Apple Account password)
  • iTunes backup password (protects backups made on your computer)
  • Screen Time password (secures your device and account, can protect changes to above passwords)
  • One-time codes (the “half-password” if your account uses Two-Factor Authentication)

In this article, we will provide an overview on how these passwords are used and how they are related to each other; what are the default settings and how they affect your privacy and security. We’ll tell you how to use one password to reset another. We will also cover the password policies and describe what happens if you attempt to brute force the forgotten password.

(more…)

While the dust surrounding the controversy of rushed iOS 13 release settles, we are continuing our research on what has changed in iOS forensics. In this article we’ll review the new policy on USB restrictions and lockdown record expiration in the latest iOS release. We’ll also analyze how these changes affect experts investigating iPhone devices updated to the latest OS release.

The real purpose of the USB restricted mode may not be immediately obvious, and the new enhancements may cause even more confusion. In our view, using USB accessories while the device is locked creates no additional risk to the user’s security and privacy. However, if we assume that this mode is aimed straight at certain forensic extraction and passcode-cracking solutions (such as GrayKey), the target of the USB restriction would be law enforcement agencies.

USB restricted mode made its appearance in iOS 11.4.1 and further enhanced in iOS 12. We posted five articles on the matter; do check them out if you don’t know what this feature is for. We also recommend the original Apple KB article “Using USB accessories with iOS 11.4.1 and later”.

Apple is still to update its iOS Security Guide. The May 2019 version (iOS 12.3) of the Guide defines USB restricted mode as follows.

(more…)