Tag: Digital Forensics

Welcome to Part 3 of the Perfect Acquisition series! If you haven’t read Part 1 and Part 2 yet, be sure to check them out before proceeding with this article. In this section, we will introduce our newly developed Perfect HFS Acquisition method, which enables the extraction of data from legacy iOS devices that do not have SEP and utilize the HFS file system.

As a quick recap from the previous section, we consider an acquisition to be a Perfect Acquisition if we can obtain a complete data dump with keys while satisfying the following conditions:

1. We do not rely on any software running on the device that we did not write ourselves (for reliability).
2. We do not alter any single bit on the device (for verifiability).
3. Subsequent acquisitions should produce the same result (for repeatability).

In this section, we will examine how we can perform a (nearly) Perfect HFS Acquisition and explain why any (theoretical) imperfections in this approach can be disregarded.

Loading our code

Normally, iOS has a secure boot process with a chain of trust that reaches down to the immutable BootROM, where the first piece of code is executed. All following code is authorized by Apple and prevents any non-authorized code from being executed.

However, with our method, we use a BootROM exploit to bypass this restriction at the lowest level and gain the highest possible privileges on the SoC, allowing us to load our code at the earliest possible point in time. Our software uses the original iOS firmware downloaded from Apple servers (either automatically or provided by the user) and patches the signature checks to allow our code and modifications of later stages to be executed and boot into a ramdisk. We achieve this by sending the bootloader, kernel, and ramdisk over USB, resulting in a live system similar to booting Linux from USB or CD.

Technically, at this point, we have already violated the first constraint by running several components of the iOS operating system that we can consider as a black box, which to some extent, perform operations we don’t understand. However, the idea is to prevent malicious code from tampering with our acquisition. By downloading the firmware straight from Apple and loading it via USB without relying on any software installed on the device, we can be sure that the loaded code is not malicious. Even if malware is present on the device, it will not be loaded. Therefore, we can reasonably assume that the data hasn’t been tampered with.

From this point on, we are working with a complete operating system running in a ramdisk. We consider it trustworthy based on the following assumptions:

1. We assume that we are working with unmodified, original iOS firmware up until the point where we modify it ourselves to apply necessary patches and remove restrictions.
2. We assume that the original iOS does not interfere with our acquisition process.
3. We assume that the data being acquired does not exploit the operating system and alter it during the process (as is the case with Signal Messenger, but on a lower filesystem level)

We believe these assumptions are reasonable and, under these conditions, we consider the first constraint of reliability to be fulfilled.

We are confident that it is easy to acquire unmodified original iOS firmware, and it is highly unlikely that an attacker could trick users into downloading malicious firmware specifically modified to interfere with this type of acquisition.

We also assume that the original iOS firmware does not intend to and has no mechanism for tampering with raw block device reads, which is what we use for the acquisition process. Such a mechanism would be easy to detect, and we are not aware of any mechanisms that explicitly tamper with data dumps in iOS.

Finally, we are not aware of any vulnerabilities in the block device driver or any software that could compromise it to the point where it would target and alter data acquisition without being detected.

Based on these reasonable assumptions, we believe that we are operating within the listed constraints.

Dumping the data

We acquire the complete data by performing a raw block device dump using the command dd if=/dev/rdisk0s1s2 bs=32K. This process ensures that no bits are modified on the storage device.

To verify the integrity of the data, we can turn off the device and perform the exact same dump again at a later time. It’s important to note that we must not boot iOS in between dumps, as doing so will modify the data and make the two dumps non-identical.

By following this procedure, we can easily fulfill the second condition of verifiability and the third condition of repeatability without any compromises.

Dumping the keys

In addition to the data, we also need to dump the contents of the effaceable storage and derive several keys from the UID key, which we cannot extract directly.

If the passcode is known, we can extract the passcode key directly. Otherwise, we offer an option to crack the passcode on the device first

Final remarks

At the end of the process, we have successfully acquired a complete dump of the HFS filesystem using the Perfect Acquisition method. Finally, we can use the keys to decrypt the dump and gain access to all files, including their metadata, as well as all keys stored in the iOS keychain.

We have demonstrated that any theoretical shortcomings of this approach are not relevant in practice, and can therefore be safely neglected. This is why we refer to this method as the Perfect HFS Acquisition.

In summary, this is the best possible approach for acquiring data using pure software. However, if you have hardware-acquired dumps and the keys needed for decryption, we can also assist you in the decryption process.

Stay tuned for part 4, where we will provide step-by-step instructions on how you can perform Perfect HFS Acquisition using Elcomsoft iOS Forensic Toolkit.

In the previous articles we explained how to connect the first-generation HomePod to a computer, apply the exploit, extract a copy of the file system and decrypt the keychain. Since the HomePod cannot be protected with a passcode and does not allow installing apps, we were wondering what kinds of data the speaker may have and what kinds of passwords its keychain may store.

The keychain

The HomePod contained a copy of the keychain. Once we loaded the file into Elcomsoft Phone Viewer, we were able to see the keychain items available.

What we saw was a long list of Wi-Fi passwords, which contained passwords to pretty much all Wi-Fi access points stored in the iPhone on the same Apple ID. We also found a list of tokens including an Apple account token. We have not looked into this any further.

The file system image

The size of the file system image extracted from the HomePod (user partition only) was some 3.81 GB. Once we loaded the image into Elcomsoft Phone Viewer, we’ve seen some data in the following categories: Calls, Locations, and Media.

Calls

Back in 2016, we discovered that Apple silently synchronizes call logs with iCloud. Back then, we tried to understand how the syncing works and whether one can disable call sync. At a certain point, the syncing seemingly stopped, or was controlled by the “Allow Calls on Other Devices” feature. The HomePod we analyzed contained information about some 253 calls, all dating back to 2020.

Locations

There were some 102 location reports stored in the HomePod. It seems that these locations were determined with a Wi-Fi reverse lookup. Since the HomePod was stationary, all records point to the home location.

Media

We have not found any user-created media files on the HomePod. Some preinstalled sounds (such as white noise) and a number of system images were discovered.

Additional evidence

Mattia Epifani performed a quick analysis of the file system image, and reports the following findings.

• Wi-Fi network:
  /private/var/preferences/com.apple.wifi.known-networks.plist
• Wi-Fi network geolocation:
  /private/var/root/Library/Caches/locationd/cache_encryptedB.db
• Paired and Seen Bluetooth devices (huge list):
  /private/var/containers/Shared/SystemGroup//Library/Database/com.apple.MobileBluetooth.ledevices.other.db
  /private/var/containers/Shared/SystemGroup//Library/Database/com.apple.MobileBluetooth.ledevices.paired.db
• KnowledgeC, containing info about Display On/Off and NowPlaying (with timestamp and media/song name)
• MediaLibrary (usual file and info)
• Account (usual file and info about iCloud account)
• Synced Preferences
  /private/var/mobile/Library/SyncedPreferences/com.apple.kvs/com.apple.KeyValueService-Production.sqlite
  this seems really interesting as it contains metadata of some of your messages/email with addresses.
• Apple Podcast data
  privatevarmobileContainersSharedAppGroupDocumentsMTLibrary.sqlite
• Biome data (Backlight and NowPlaying, similar to knowledgeC)
• Call History from 2020
• Alarms set on the device
• Mobile Activation Logs
• Mobile Installation Log
• OS Software Update History
• PowerLogs with recent activities (Data Usage, Applcation Usage)

By loading the image into iLEAPP, one can access a bit more information.

Podcasts:

Biome Now Playing:

Paired Bluetooth devices:

And finally, the iOS update history log:

Conclusion

Our analysis of the first-generation HomePod has revealed that it contains a limited amount of potentially sensitive information. The keychain stored on the device contained a list of Wi-Fi passwords and tokens, while the file system image contained call logs (the last of which originated back in 2020), limited location data, the list of paired and seen Bluetooth devices, and information about media files. Although we did not find any user-created media files on the HomePod, we did discover some metadata and playback history records. Our analysis highlights the importance of analyzing all kinds of electronic devices when collecting digital evidence.

Obtaining information from a locked iPhone can be challenging, particularly when the device is passcode-protected. However, four critical pieces of information that can aid forensic analysis are the device’s International Mobile Equipment Identity (IMEI), Mobile Equipment IDentifier (MEID), MAC address of the device’s Wi-Fi adapter, and its serial number. These unique identifiers can provide valuable insights into a device’s history, including its manufacture date, hardware specifications, and carrier information.

In forensic investigations, accessing this information can be crucial for tracing a device’s ownership, determining if it has been stolen or involved in criminal activity, and retrieving important data for legal or investigative purposes. This article will explore the various methods available to forensic investigators for obtaining the device’s MAC address, MEID, IMEI, and serial number information from a locked iPhone.

Method 1: iPhone Diagnostic Mode

The iPhone diagnostic mode reveals essential information about the device such as its serial number, IMEI, and MEID numbers. Additional information such as the exact model identification, iOS version and MAC address of the device’s Wi-Fi adapter is accessible with third-party software such as iOS Forensic Toolkit. Importantly, the diagnostic mode can be invoked even if the iPhone is passcode-protected or locked.

To enter iPhone Diagnostic Mode follow these steps.

1. Press and hold both the volume up and volume down buttons.
2. While holding the two buttons, plug the Lightning cable into the iPhone‌ and connect it to a computer or power adapter.
3. Wait for the Apple logo to appear, then release the buttons.

The following screen will display the device’s serial number, MEID, and IMEI numbers.

If you use iOS Forensic Toolkit while the iPhone is in Diagnostic Mode, you will be able to access additional information that does not appear on the device’s display, such as:

• Exact model number and color of the iPhone
• Wi-Fi MAC address
• iOS version number and built number
• IDs of certain hardware
• Some additional information, which will be exported as an XML

Method 2: Recovery Mode

In iOS, Recovery is a failsafe method for recovering devices if they become unresponsive. The Recovery mode, also known as “second-stage loader”, boots the device in iBoot (bootloader) mode. iBoot can be used to flash the device with a new OS. iBoot responds to a limited number of commands, and can return some limited information about the device. As iBoot does not load iOS, it also does not carry many iOS restrictions. In particular, iBoot/Recovery mode allows connecting the device to the computer even if USB data transfers are disabled, the device is locked, or the screen lock passcode is unknown.

Compared to Diagnostic Mode, Recovery provides even less information about the device. In particular, the following data is available:

• Device model: two representations of the device model, e.g. iPhone7,2 (n61ap), iPhone10,6 (d221ap) etc.
• ECID (UCID). The ECID (Exclusive Chip Identification) or Unique Chip ID is an identifier unique to every unit, or more accurately, to every SoC.
• Serial number

Read more about the Recovery mode:

The True Meaning of iOS Recovery, DFU and SOS Modes for Mobile Forensics

Method 3: DFU mode

Unlike Recovery, DFU mode was never intended for general use. This mode lacks proper documentation, and requires precise timing for every step (otherwise the device will simply reboot). As a result, entering DFU mode can be difficult even for experts, especially if the device has one or more buttons broken.

The DFU mode returns even less information compared to the Recovery mode, and significantly less information than Diagnostic mode.

• Device model: two representations of the device model, e.g. iPhone7,2 (n61ap), iPhone10,6 (d221ap) etc.
• ECID/Unique Chip ID: XXXXXXXXXXXXXXXX

Serial number and IMEI number are never available in DFU. DFU does not return iOS version number; however, iBoot version number is available through DFU, which allows guesstimating iOS version number.

Read more about information available in DFU mode and steps to enter DFU on various Apple devices:

The True Meaning of iOS Recovery, DFU and SOS Modes for Mobile Forensics

Conclusion

The IMEI, MEID, MAC address, and serial number of the device are crucial pieces of information that can aid forensic investigations in understanding an iPhone’s history, ownership, and involvement in criminal activities. While obtaining this information from a locked iPhone can be challenging, various methods are available to forensic investigators, including iPhone Diagnostic Mode, Recovery Mode, and DFU Mode. Each method provides different levels of information, with iPhone Diagnostic Mode providing the most comprehensive details.

Elcomsoft iOS Forensic Toolkit 8.20 for Mac and 7.80 for Windows now includes a new mechanism for low-level access, which enables the extraction of certain parts of the file system from the latest Apple devices. This partial extraction raises questions regarding what data can and cannot be extracted and how missing information can be accessed. Learn about the partial file system extraction, its benefits and limitations.

Introduction

With the increasing usage of mobile devices in daily lives, the need for digital forensics on these devices has also grown. One of the most commonly used mobile operating systems is Apple’s iOS. For forensic investigators, gaining access to the file system of an iOS device is crucial in order to extract relevant data for analysis. However, due to the security measures implemented by Apple, this can be a challenging task. In this article, we will explore the concept of “partial” file system extraction on iOS devices built on Apple’s latest chips. We will discuss what data can be accessed through this method, as well as what limitations exist when utilizing known vulnerabilities to gain elevated privileges and extract data from the device’s file system. Through understanding partial file system extraction, investigators can gain a better understanding of what data can and cannot be obtained from an iOS device, and how to best approach digital forensics on these devices.

Some vendors implemented support for the new exploit without fully understanding its implications, making incorrect claims about the availability of a larger data set than actually accessible. In this article, we will try to clearly demonstrate what is and what is not accessible with the new exploit.

Compatibility

The new extraction process is supported for all current Apple devices with iOS 15.6-16.1.2 (iOS 15.4-16.1.2 on some devices). Full file system extraction with keychain is supported on older versions of iOS, while many older devices are supported via the forensically sound checkm8 extraction process. Please refer to the following image for detailed support matrix.

What is “partial” file system extraction?

What data is available?

What is unavailable?

Data from system and built-in apps, as well as many system databases, including the keychain, remains inaccessible. We recommend using advanced logical acquisition to access this information. Password-protected backups include both user passwords (keychain) and data from many system apps, such as Safari browsing history. Particularly missing are biome data, knowledgeC, ScreenTime data and many system databases. Location data in /private/var/mobile/Library/Caches/com.apple.routined/ and /private/var/root/Library/Caches/locationd/ is not accessible.

Compared to the full exploit, the partial extraction has some omissions:

Getting the missing data

We recommend this newly added partial file system extraction method as complimentary to advanced logical acquisition. In addition to information extracted through the advanced logical process, the new low-level extraction method pulls sandboxed data and working sets of third-party apps that do not allow their data in local backups. This includes many instant messaging apps, some third-party Web browsers and email clients, and multiple other apps. The local backup, on the other hand, will deliver information that cannot be obtained with partial file system extraction, which includes calendars, Safari browsing history, and, for password-protected backups, passwords and authentication data stored in the keychain.

The following are examples of data available with each extraction method.

Extended logical

• Calendars, notes, contacts, call history
• SMS and iMessage
• Safari history, bookmarks, tabs
• Photos and videos
• Passwords from the keychain (source: password-protected backup)

Partial file system

• Chats in third-party instant messengers (except iMessage), e.g. Telegram
• Databases of social networking apps
• Downloaded mail and other data from third-party mail clients
• Data from some third-party Web browsers
• Data from user-installed apps, which is mostly unavailable in backups
• Some system databases that are not included in backups

Extraction steps

The extraction steps for partial file system extraction differ very little compared to other agent-based extractions; the differences are around iOS 16, which requires an extra step. Please refer to the following article for details:

iOS Forensic Toolkit installation notes

• macOS: do not forget to remove the quarantine flag for v8.
• Windows: temporarily disable Windows Defender or another antivirus before installing and using the tool. Antivirus software may fire a false malware detection warning caused by the exploits implemented in the software.

Important: When extracting iOS 16.x devices, you will need to enable Developer Mode on the device to sideload the extraction agent. The Developer Mode is available in Settings > Privacy & Security. You will need to enter the screen lock passcode to enable Developer Mode.

The agent prompts for additional permissions; tap OK to grant:

Note that agent-based extraction is available in both iOS Forensic Toolkit 8.20 (Mac only, command-line interface) and 7.80 (Mac and Windows, menu-driven interface).

Conclusion

The latest builds of iOS Forensic Toolkit introduced a new partial low-level extraction support for Apple devices using A11 through A16 Bionic chips, as well as iPad models based on Apple M1 and M2 chips. While this method can extract parts of the file system, including the sandboxes and working data set of third-party apps, many built-in and system apps and databases are excluded due to limitations caused by the exploit used. This newly added method is recommended as complementary to advanced logical acquisition, as it can extract information that cannot be obtained with a local backup, such as data from certain instant messengers and third-party apps. However, local backups are still necessary to obtain information like calendars, Safari browsing history, and passwords stored in the keychain. We will continue to research the vulnerability used in this release to expand the amount of extractable information.

Welcome to part 2 of the Perfect Acquisition series! In case you missed part 1, make sure to check it out before continuing with this article. In this section, we will dive deeper into iOS data protection and understand the obstacles we need to overcome in order to access the data, which in turn will help us accomplish a Perfect Acquisition when certain conditions are met.

Let’s start by taking a look at how iOS data protection works. More specifically, we will limit ourselves to iOS devices that do not have a security co-processor, i.e., only devices without SEP. Therefore, for now, we will consider the following devices:

• iPhone 2G – iPhone 5c
• iPod Touch 1 – iPod Touch 5
• iPad 1 – iPad 4, iPad Mini 1
• Apple TV 2 – Apple TV 3

By doing so, we are working with the following properties:

• iPhone OS 1 – iOS 10
• HFS+ file system
• 32-bit ARM CPU
• BootROM exploit available
• No SEP

Hardware

All of these devices have a hardware crypto co-processor with fused encryption keys. The key that we’re interested in is called UID key. The important thing to know is that the key cannot be read from software, but it is possible to ask the crypto engine to encrypt or decrypt something with those keys.

iOS data protection

The data protection mechanisms used in various Apple devices evolved a lot over time.

iPhone OS 1 and iPhone OS 2

There is no disk encryption. If you remove the flash, you should be able to read it directly.

iPhone OS 3

Disk encryption of the data partition was introduced. Note: other partitions are not encrypted, but also don’t contain user data.

The UID key is used to derive the so called 0x89B key, which is used to protect the EMF key. The EMF key is used to encrypt the whole data partition. It is generated freshly each time you erase-restore your device and it is stored in a special area in the flash, called the effaceable storage, which is designed for fast and secure wipe. If you wipe the effaceable storage and delete the EMF key, data can no longer be decrypted.

This provides two security mechanisms:

• First, you can no longer simply remove the flash to read the data, as you still need to access keys on device due to the entanglement with the UID key.
• Second, it is possible to quickly and securely erase all user data on the device as only the EMF key needs to be securely erased to make all data inaccessible.

This means that you now need to execute code on the device to get the data, because you also need to access the 0x89B key (or access the EMF key directly).

iOS 4

iOS 4 came with a major security upgrade incorporating the user passcode tightly in the security model (previously it was not used for encryption). The so called System Keybag was introduced which stores 11 different class keys. Each file on the data partition is encrypted with its own key, which in turn is encrypted with one of the class keys. The class determines when the file can be accessed. For example class A (key 1) is only accessible when the device is unlocked (with the passcode), while class C (key 3) is always available after the user unlocked the device at least once after boot (we call this AFU After First Unlock).

The difference between the classes isn’t too relevant for us here, the important part is that when the keys are not accessible they are locked. To unlock the class keys you need the passcode key, which is derived from the user passcode (entered at the lock screen), as well a the UID key.

This means in order to access the user data you first need to know the user passcode and then with the help of the UID key derive the passcode key, which you can use to unlock the class keys stored in the System Keybag, which you can then use to unlock individual file keys which finally let you access individual files.

In addition, the System Keybag itself is also encrypted with a file key, which in turn is protected by the class D (key 4) key. The class D key is special, as it is not stored in the System Keybag, but is first encrypted with the so called 0x835 key and then stored in the effaceable storage next to the EMF key. The EMF key is still used, but now only protects the filesystems metadata and not file contents anymore.

There are a few more keys and steps involved, but the gist is that you now need the passcode key to access user data, which you have to generate on device due to the requirement of the UID key.

The main new security mechanism is that you need to know the user passcode in order to access the data. While it is possible to crack the passcode, this needs to be done on device and thus the speed it limited. It is not easily possible to do offline cracking on a GPU cluster.

iOS 5 – iOS 10

The following iOS versions shipped small improvements to the model and spread the use of stronger protection classes to more files, but without the introduction of the SEP co-processor and the APFS filesystem (which are both out of scope here), no major changes occurred to the scheme.

Perfect Acquisition

The scheme above might sound confusing and complicated, but essentially it boils down to needing three things.

• Dump of the data
• Access to encryption keys
• Knowledge of the passcode -> Access to the passcode key

We will consider the acquisition to be a Perfect Acquisition if we manage to acquire all of those three things while meeting the following conditions:

• Do not trust any software running on the device that we did not write ourselves (to avoid malware tampering with us)
• Do not change any single bit on the device (so we can have verifiable extractions)
  • Ideally do not even power on the device for extracting the data
• Subsequent acquisitions should yield the same result (for repeatability)

Admittedly, this already looks like a fairytale, since clearly nobody is doing that in practise. But let’s take a look at what would be needed for a truly perfect acquisition.

Acquire the dump

Let’s tackle the first and most important point: Can we get a dump of the data without violating any of the constraints above? Yes, and surprisingly, the solution is much simpler than you might think. We can desolder the flash and read its contents. This will give us two things: first, the actual storage dump, and second (if done correctly), the effaceable storage containing the (encrypted) keys we need. At this point, we don’t care about what happens to the device anymore because we can be sure that nothing tampered with the data, and we can easily perform repeatable reads of the flash. Technically, we don’t even need to put the flash back. Thus, if we never actively modify the flash ourselves, we can be sure that nothing else ever modifies it.

Acquire the keys

At the root of the security of an iOS device is the UID key, which is the only thing left in the device if we desolder the flash. Accessing the UID key allows us to perform all other operations offline. While it has been shown that retrieving the UID key is possible in some cases using techniques such as side-channel attacks or decapping the SoC and reading the bits with a microscope, such approaches are too expensive and outside the scope of most use cases.

Instead, a simpler approach is to execute code on the SoC and ask the crypto processor to use the UID key and derive all necessary keys. In this blog post, we have covered deriving the 0x835, 0x89b, and EMF keys, all of which depend on the UID key as the only unknown variable. It is technically possible to do this without putting back the flash, and since the flash is the only place the device can store relevant data persistently, there is no need to worry about accidentally modifying the data even if unknown software is run. Furthermore, there is no risk of software providing false keys, as they either work or do not work. In the case of AES, which is what we are dealing with here, there is no such thing as a “man in the middle” possibly giving out a malicious key providing incorrect data.

Acquire the passcode (key)

The strategy here is the same as with the other keys described previously. If we have the UID key, we can derive the passcode key offline. If we don’t have the UID key, we can ask the device to derive it for us. If we already know the passcode, we can derive the key directly. If we don’t know the passcode, we can brute-force it by repeatedly generating passcode keys and trying to decrypt the System Keybag with them. Only the correct passcode key will successfully decrypt the keybag, wrong keys are recognised easily.

Final remarks

Finally, having acquired the dump and all needed keys without modifying the data during the process or having to trust unknown variables, we can truly call this a Perfect Acquisition. While it is not very likely anyone would go through these lengthy efforts just to fulfill all points on the list above (given that it’s not even needed in most cases), our software can support decryption of dumps acquired through reading the flash externally, provided you also manage to extract the effaceable storage and provide all needed keys.

To state the obvious, we do not offer data extraction exactly like this (but our software can help you if you do it yourself!). Instead, we have a simple and convenient to use software-only approach, which comes extremely close to the truly Perfect Acquisition described here. Stay tuned for part 3 to find out how it works and why we can still reasonably and confidently call it Perfect Acquisition.

Forensic acquisition in the past

In the early days, forensic acquisition was easy. Storage media was easily separable, and disk encryption wasn’t common. You simply took out the hard drive from the computer, made a bitwise copy of it, and you were done with the acquisition step. The data could then go to the analysis phase.

Nowadays, things are very different. Looking at mobile forensics like phones and tablets, flash storage media is soldered directly onto the device mainboard and is not easily separable. Furthermore, widespread disk encryption prevents access to data, even if one were to go through lengthy efforts to desolder the flash.

With traditional desktop disk encryption, you could decrypt the data on any machine assuming you know the key or even crack the key on a high-performance GPU cluster if you don’t know it. However, on mobile devices, hardware encryption engines with fused unique device keys and security co-processors make it very difficult to access those keys.

Accessing those keys suddenly becomes extremely difficult, and brute-forcing unknown passcodes becomes time-consuming or sometimes even impossible. Either way, in most cases, code execution on those extremely well-protected devices is required to be able to access the data.

Modern mobile forensics

As classical forensic disk dumps became infeasible and running some kind of software on the target device became a must, the forensic industry shifted to other, less ideal means of accessing the data. The easiest solution to the problem is to create a backup where the device cooperates and sends out the data already decrypted. However, this approach usually requires being already fully authenticated and even then doesn’t send all of the device data.

Another approach is to exploit the device through software vulnerabilities and access the data from a running system with higher privileges. In fact, this approach became the industry standard, as it’s most of the time the only viable way to access the data.

Many solutions on the market exist that share the general idea but differ in how the method is applied in practice. For example, one can remotely install a trojan and access the data when the legitimate user unlocks the device. While this is the shadiest, it’s unfortunately one of the most common ways to access data nowadays. Another very similar method is to install an application to a seized device in physical possession, which uses software vulnerabilities to exploit the operating system, elevate privileges, and retrieve the data. The downside of this is that it often requires already knowing the passcode to install the application in the first place.

Sometimes very powerful exploits exist for a particular device, which compromise the security of the device at a very early stage, allowing for the execution of fully custom code, which in theory, removes the need to rely on any unknown code at all.

Current limitation of mobile acquisition

Many of the methods (sometimes unavoidably) alter some of the data on the device during operation, such as causing log entries. Most of the time, it is not possible to create two complete dumps of the device that are identical, thus breaking the core principle of forensic sound acquisition (repeatability).

However, there is an even greater issue. Except for the case where one executes fully custom code on the device, all current methods have one fundamental underlying problem: they require, to some extent, collaboration with the device, and thus, to some extent, we need to trust the device to give us the correct data. But this isn’t necessarily always true! What if the device is malfunctioning and can no longer cooperate with us? What if the software running on the device hides some data from us? What if a device infected with malware deliberately lies to us about data on the device during the acquisition? How can we be sure that the data returned is actually truly valid, correct, and untampered? While in many cases, we can assume that the acquired data is good and with certain methods the likelihood of something fishy going on is extremely low, the truth is that we can never be 100% sure!

Another, more likely, problem is hardware defects in devices that prevent acquisition software from running. For example, if the device has been dropped in water and is no longer booting, it may still have a functioning flash chip. Of course, you could try to fix the mainboard, but without knowing which component broke, that could turn out to be a difficult task.

Obviously, there is no magic solution to all possible problems, but once in a while we can solve some of them.

Conclusion

Mobile forensics has evolved significantly in recent years due to the increasing complexity of mobile devices and their security features. As a result, the traditional approach of forensic disk dumps has become infeasible, and the industry has shifted towards exploiting software vulnerabilities on the device to access data. However, these methods have their limitations, such as the potential for data alteration during acquisition and the need to trust the device to provide correct data. Despite these limitations, the forensic industry continues to work towards finding solutions to these problems to ensure the integrity of the acquired data. Overall, while there is no magic solution to all possible problems, ongoing research and development in the field of mobile forensics will undoubtedly yield more effective and reliable acquisition methods in the future. Stay tuned for part 2!

The first-generation HomePod is a smart speaker developed by Apple that offers high-quality audio and a range of features, including Siri integration and smart home controls. However, as with any electronic device, it can store valuable information that may be of interest in forensic investigations. In this article, we will explore how to use the forensically sound checkm8 extraction to access data stored in the HomePod, including the keychain and file system image. We will also outline the specific tools and steps required to extract this information and provide a cheat sheet for those looking to extract data from a HomePod. By the end of this article, you’ll have have a better understanding of how to extract data from the first-generation HomePod and the potential limitations of this extraction method.

HomePod extraction: cheat sheet

To extract data from a first-generation HomePod, follow these steps:

1. Launch iOS Forensic Toolkit 8.0 (Mac)
2. Connect the device to the computer with a USB adapter (you will need a custom adapter for connecting the HomePod)
3. Place the HomePod into DFU (see below)
4. [optional] Run ./EIFT_cmd info to ensure that the HomePod entered DFU
5. Run ./EIFT_cmd boot
6. Run ./EIFT_cmd unlockdata
7. Run ./EIFT_cmd ramdisk keychain -o {filename} to extract the keychain
8. Run ./EIFT_cmd ramdisk tar -o {filename} to pull the file system image
9. [optional] Run ./EIFT_cmd ssh halt to power off the device. Alternatively, simply pull the plug.

Note: as long as you keep it connected to USB and upside down, it will never boot into the normal OS.

Placing HomePod devices to DFU

Placing the HomePod into DFU is surprisingly simple.

1. Power the speaker off by pulling the power cord.
2. Turn it upside down (the diagnostic port facing up).
3. Connect it to the computer with an adapter.
4. Plug it in.

The HomePod boots into DFU.

HomePod extraction steps explained

Once you connect the HomePod to the computer, place the device into DFU as explained in the previous chapter. You can verify the device is in DFU mode by running the following optional command:

./EIFT_cmd info

Once “Mode:” says [DFU], apply the exploit with iOS Forensic Toolkit by running the following command:

./EIFT_cmd boot

iOS Forensic Toolkit will detect the HomePod in DFU mode and automatically apply the exploit. The toolkit detects the OS version installed on the device, and provides a download link to an Apple firmware image.

If there are multiple potential matches, several download links will be displayed. We recommend starting from the last link from the list. Please note that if a link to a wrong OS version is provided the HomePod will panic and will not boot. If this happens, try a different OS version.

Download the file from the link, and drop it onto the console window, then press ENTER. Alternatively, you can simply paste the firmware download link instead. If you do that, the tool will only download parts of the firmware image that are required to boot the HomePod.

Notably, Apple does not publish full IPSW images for HomePod devices. Our tool can use OTA update images for the purpose of applying the exploit.

In many cases, the OS version will be detected automatically by EIFT during the first stage of the exploit. The detection is based on the detected iBoot version and device hardware. However, in some cases the iBoot version may correspond to several OS builds. If the wrong build is used, you will have an option to either repeat the process with a different version of firmware, or continue with the current firmware image (which works in many cases).

./EIFT_cmd ramdisk unlockdata

This command unlocks the data partition and mounts it read-only. Since the HomePod does not have a passcode, you will not need to provide one.

./EIFT_cmd ramdisk keychain -o {filename}

This command extracts and decrypts the keychain. If no path is specified, it will be saved into the current folder. Note that the number of keychain records extracted can be limited compared to the content of an iPhone or iPad device. Since the HomePod cannot have a passcode, the HomePod devices cannot access any end-to-end encrypted data in iCloud, which includes the iCloud keychain.

./EIFT_cmd ramdisk tar -o {filename}

This command images file system. The checksum (hash value) is calculated on the fly and displayed once the extraction is finished.

On the test device, the command dumped some 3.84 GB of data; your mileage may vary. In the next article we’ll analyze that data to see what is and what is not available.

You can power off the HomePod by either pulling the plug or running ./EIFT_cmd ssh halt first.

Conclusion

Accessing information stored in the first-generation HomePod requires a specific set of tools and steps, including the use of forensically sound checkm8 extraction and a custom USB adapter. By following the outlined steps and using iOS Forensic Toolkit 8.0, it is possible to extract the keychain and file system image from the HomePod. However, it is important to note that the amount of data that can be accessed from the HomePod may be limited compared to other Apple devices, and the HomePod cannot access any end-to-end encrypted data in iCloud. Nonetheless, this extraction method can be useful in forensic investigations and shed light on the potential data that can be obtained from HomePod devices. We strongly believe that analyzing IoT devices such as the HomePod, Apple TV, and Apple Watch is essential for investigations.

In this article, we will discuss how to access the hidden port of the first-generation HomePod and extract its file system image. Note that this process requires disassembly, voids the HomePod warranty, and requires specific tools, including a custom 3D-printable USB adapter, a set of screws, and a breakout cable. Therefore, this method is not recommended for casual users and should only be used by professionals who have a thorough understanding of the process.

Background

Introduced in early 2018, the HomePod is Apple’s smart speaker that has been designed to offer a superior audio experience while featuring a smart assistant, Siri, that helps users manage their daily tasks, listen to music, and control their smart home devices. While the HomePod is known for its sound quality, smart assistant, and tight integration into the user’s Apple ecosystem, it also contains valuable information that experts may want to access.

The first-generation HomePod is based on the Apple A8 chip, which is the same chip found in the iPhone 6. This chip is vulnerable to the checkm8 exploit, which makes the first-generation HomePod a potential source of digital evidence during forensic investigations. Just like the Apple TV, the HomePod cannot be protected with a passcode, which makes it a relatively easy target. Interestingly, the iPhone 6 was never updated beyond iOS 12.x, while the HomePod runs the latest OS version (currently 16.3.1). The OS is very similar to tvOS; we’ll discuss it in the next article.

Prerequisites

To access the information in the HomePod, you will need all of the following.

1. The original first-generation HomePod that was set up and used for some time (iOS version does not matter).
2. A custom 3D-printable USB adapter to connect the HomePod to a computer. If you build this adapter yourself, you’ll need access to a 3D printer and some soldering skills.
3. Speaking of the computer, you’ll need a Mac. Currently we only support checkm8 on macOS.
4. Elcomsoft iOS Forensic Toolkit 8 to apply the checkm8 exploit, pull and decrypt the keychain and extract the file system image. Did I mention you’ll need a Mac to run it?

Accessing the hidden port

The first-generation HomePod has a communication port hidden under the bottom lid. To access this port, you will need to remove the bottom lid first. The lid is glued in; you will need to heat it with a fan, then use a flat screwdriver. We had to repeat the heating process several times as to not damage the lid.

Before you begin, make sure the HomePod is powered off. Turn the speaker upside down and place it on a piece of soft cloth.

Once the HomePod is upside down, the bottom lid is exposed. The diagnostic port hides under the lid, so we need to remove it to access the port. The lid is held by some glue; you’ll need to heat and peel to take it off. Heat it with an ordinary fan; apply the heat in short sessions to avoid melting. 10 to 15 seconds is enough to start the process.

Then use a flat screwdriver:

Heat again and repeat as many times as needed. Do not rush or you may damage the lid.

Once the lid is gone, you will see the diagnostic port.

This is a combination USB/UART port. Since we don’t need UART for our purpose, we’ll just use a simple 3D-printable adapter to connect to the pins.

We’ve used the simplest 3D printable adapter, which exposes the connections and can be used for USB (only). The complete instructions are available in GitHub – Elcomsoft/homepwn. UART connections are also exposed, but aren’t needed for our purpose. Additionally you will need M2x6 screws and Pogo pins. The ones we used have the following properties:

• 1.02 mm outer diameter
• 15.8 mm total length
• 1.4 mm pin length (such as these)

Print with the side going into the HomePod facing upwards and print with support. First solder wires to the pins, only then insert them into the adapter (otherwise the 3D printed plastic will melt). Make sure they have a good solder connection, otherwise the USB connection will be very unstable or will not work at all.

Note: if you need UART access, you’ll need to insert two more pogo pins, then connect the two wires to a 1.8v UART to USB adapter. This is not needed for our purposes.

Attach the adapter with four screws:

The seated adapter looks like this:

Connect the wires to the USB breakout cable:

Finally, connect the USB cable to the computer. If your computer only has Type-C ports, you’ll need yet another USB-A to USB-C adapter:

Conclusion

We explained how to access the hidden communication port in the first-generation HomePod. The port is located under the bottom lid, which is glued in place, and requires heating and peeling to remove it. Once the lid is removed, the diagnostic port is visible, which is a combination USB/UART port. We’ve provided instructions for creating a simple 3D-printable adapter to connect to the pins and access the USB port. At this point, you’ve successfully pwned the HomePod and connected it to the computer. We’ll talk about the data in the next article.

Dictionary attacks are among the most effective ones because they rely on the human nature. It is human nature to select passwords that are easily memoizable, like their pet names, dates of birth, football teams or whatever. BBC counted 171,146 words in the English dictionary, while a typical native speaker (of any language) knows 15,000 to 20,000 word families (lemmas, or root words and inflections). Whatever the attack speed is, it will not take too much time to check all the English words.

There is a difference between a ‘dictionary’ and a ‘wordlist’. Even simple passwords are not always “words” from the dictionary but may be also common combinations (like “qwerty”) and abbreviations (like “ROFL&SMC”). Several wordlists are included with Elcomsoft Distributed Password Recovery, and of course you can use your own; you can find many collections in the public domain or order specific dictionaries from the manufacturer.

Is there a difference between a common wordlist and an optimized dictionary?

Dictionary optimizations

A dictionary can be optimized to increase the probability of finding a password at the beginning of the attack. One way to optimize a dictionary is using a specific order of word entries. For example, one may place the most commonly used words at the top of the list (e.g. English Word Frequency | Kaggle), while less frequently used words could be placed lower down the list.

Our tools use a different sorting scheme. Dictionaries provided with Elcomsoft Distributed Password Recovery are optimized for our software to deliver the fastest attacks. The dictionaries of natural languages and many specialized dictionaries we provide are sorted by the length of the entries; the shortest words are placed at the top of the list, while the longest entries are at the bottom of the dictionary. We chose this sorting because of the particular implementation of mutations in Elcomsoft Distributed Password Recovery; this may not be optimal for password recovery tools made by other vendors. Dictionaries of leaked passwords, on the other hand, are always sorted by popularity.

If you are composing your own dictionary, you may want to optimize it for your password recovery tasks. We recommend using frequency sorting for dictionaries composed of leaked passwords (e.g. “Top-100”, “Top-10000” and so on). If using dictionaries of natural languages, we only recommend frequency sorting if you are not using mutations. If using mutations, ordering entries by their length is more efficient.

Dictionary types

The dictionaries can be grouped as follows.

Common passwords. These dictionaries contain passwords that are common in certain communities or language groups. The “Top-100”, “Top-10000”, various lists of leaked passwords and similar dictionaries belong to this group. We recommend using these dictionaries for all attacks.

Specific dictionaries. Various argot and slang dictionaries (e.g. the “hacker’s slang”), dictionaries of common names and landmarks belong to this group. We only recommend using these dictionaries if you know that the user could be setting a password belonging to that specific group (e.g. after analyzing their existing passwords).

Dictionaries of natural language. These can be common English words or words that belong to the user’s native language. Various transliteration dictionaries for non-Latin alphabets also belong to this group. These dictionaries can be used for all types of attacks.

The use of mutations

You may or may not want to enable mutations depending on the dictionary used. For example, when using a dictionary that belongs to the “specific” or “natural language” group, mutations do come handy as they account for the common password variations (e.g. appending one or more digits to the end of the password or varying the letter case). On the other hand, dictionaries of common passwords do not benefit from enabling mutations because they already contain the final modifications of dictionary words (of course if the password is based on a certain dictionary).

There are two major types of mutations: generic and specific.

We recommend using generic mutations for all types of attacks as these are commonly used when composing passwords. For example, the most common mutation turns a dictionary word “password” into something like “Password1”, capitalizing the first letter and adding a digit to the end. Generic mutations are especially handy for cold attacks.

Specialized mutations, on the other hand, are in general rarely used. A good example of such mutations is a “l00p” mutation that transforms ordinary dictionary words into “hacker’s slang”. We only recommend using these specific mutation algorithms when you have reasons to believe that the user might have composed their passwords in that specific manner.

Using free dictionaries

If you were wondering if you can use a text dictionary or wordlist obtained from the Internet to set up a password recovery attack, you most certainly can. However, you have to make sure that the dictionary is converted to a supported format (see below). If you are going to use mutations, we recommend making all entries lower-case; this does not apply to dictionaries of common passwords. You may further improve performance by optimizing the dictionary for the particular password recovery tool. The following settings are applicable to Elcomsoft Distributed Password Recovery.

For common and specialized dictionaries:

• Save the dictionary as a “.udic” text file. The file must be using the Unicode LE (little-endian) encoding.
• Deduplicate.
• Make all entries lower-case.
• Sort entries by their length. The shortest words should be placed on the top of the list, while longer words should be at the bottom.

If you are using a password comprised of existing passwords, use a different workflow.

• Save the dictionary as a “.udic” text file. The file must be using the Unicode LE (little-endian) encoding.
• Do not change the case of the entries.
• Sort entries by popularity. Entries that show up more frequently should be placed on the top of the list, with less popular entries at the bottom.
• At this point, deduplicate.

Making a custom dictionary

You can create custom dictionaries for your circumstances. For example, a custom dictionary may contain a list of phone numbers, dates, document numbers, names of family members or pets of a given user, and any other personal information that might have been used as part of a password.

We recommend treating such passwords depending on whether or not you are planning to use mutations. With no mutations, the order of entries does not affect the recovery speed; you may want to place the more common passwords closer to the top of the list.

If, however, you are making a password based on natural words, you may need to use mutations to produce realistic passwords. In this case, we recommend lower-case conversion and sorting (see previous chapter).

If possible, try keeping the size of the dictionary within limits. About 10,000 entries make a good dictionary that can be realistically used on most data formats together with the most common mutations. A significantly larger dictionary will likely choke the attack if you use any but the most basic mutations.

Finally, Elcomsoft Distributed Password Recovery supports attacks that combine entries from two dictionaries. The two dictionaries can be different, or they could be the same dictionary; in the latter case the passwords will be produced as two-word combinations from that dictionary. Please note that if you use two dictionaries the number of passwords to try will be the multiple of the two.

Specifications

Elcomsoft Distributed Password Recovery supports dictionaries that conform to the following specifications.

• Format: text file, with one entry per line.
• Encoding: Unicode LE (little-endian). Do not use ANSI or UTF-8 dictionaries as they are not supported.
• Case: lower-case entries if you plan to use mutations; original case if you don’t.

Conclusion

Dictionary attacks are among the most effective ways to crack passwords due to human nature. Most users tend to use easily memorable passwords that are based on words that can be found in  a dictionary, making these attacks faster and more likely to succeed. There are different types of dictionaries, and choosing the right one and optimizing it correctly can cut the time of an attack severely while improving the success rate. Mutations can also be used to further increase the chances of finding a password while increasing the time required to run the attack. While free dictionaries from the internet can be used, they must be converted to a supported format and optimized for the specific password recovery tool being used. By understanding the various types of dictionaries and mutations, one can better plan and execute successful password recovery attacks.

In the previous article we discussed the different methods available for gaining access to encrypted information, placing password recovery attacks at the bottom of the list. Password recovery attacks are one of the methods used to gain access to encrypted information. In this article we’ll discuss the process of building a password recovery queue. Learn how to choose the appropriate workflow for the attack, the first prioritizing files with weaker protection, the second prioritizing faster and shorter attacks, and the third being a combination of the two. For your reference, we built a table to compare the relative strength of different file formats and encryption methods, helping users prioritize their attack queues.

Building the password recovery queue

The password recovery workflow consists of an ordered queue of individual jobs. Each job specifies a single attack on a single file. You may set up a queue consisting of multiple attacks on a single file, or attack multiple files. For example, your queue may look like this:

Workflow 1:

File #1
------ Attack #1
------ Attack #2
------ Attack #3
File #2
------ Attack #1
------ Attack #2
------ Attack #3
File #3
------ Attack #1
------ Attack #2
------ Attack #3

When you opt for the first workflow, files with the weakest protection should be on the top of the queue, while formats with the slowest attacks should be placed at the bottom. This workflow prioritizes files with weaker protection over faster and shorter attacks. However, you can also set up the queue like this:

Workflow 2:

File #1
------ Attack #1
File #2
------ Attack #1
File #3
------ Attack #1
File #1
------ Attack #2
File #2
------ Attack #2
File #3
------ Attack #2
File #1
------ Attack #3
File #2
------ Attack #3
File #3
------ Attack #3

If you opt for the second workflow, the queue will be ordered with the shortest attacks first, while longer and time-consuming attacks take the bottom of the list. This workflow prioritizes faster and shorter attacks over weaker protection.

Of course, nothing should stop you from combining the two approaches. For example, a classic example of Workflow 1 may look like this:

Newdocument.docx
------ Dictionary attack top-10000
------ Digit only passwords (1-6 digits)
------ Dictionary attack with mutations English.dic
------ Dictionary attack with mutations Spanish.dic
------ Brute force attack (1-8 characters)
Expenses.xlsx
------ Dictionary attack top-10000
------ Digit only passwords (1-6 digits)
------ Dictionary attack with mutations English.dic
------ Dictionary attack with mutations Spanish.dic
------ Brute force attack (1-8 characters)

However, the brute force attack on the first file may take forever, while a dictionary attack may end in reasonable time. You may want to modify your attack with an element of the second workflow, in which case your password recovery queue may look like this:

Newdocument.docx
------ Dictionary attack top-10000
------ Digit only passwords (1-6 digits)
------ Dictionary attack with mutations English.dic
------ Dictionary attack with mutations Spanish.dic
Expenses.xlsx
------ Dictionary attack top-10000
------ Digit only passwords (1-6 digits)
------ Dictionary attack with mutations English.dic
------ Dictionary attack with mutations Spanish.dic
Newdocument.docx
------ Brute force attack (1-8 characters)
Expenses.xlsx
------ Brute force attack (1-8 characters)

Notice that in the second example we moved the most time-consuming attack (the brute-force) to the bottom of the queue for both files. This makes sense if the files in the queue have similar encryption strength. However, if there is a big difference in attack speeds between the files, you may have a better chance of success with the first type of workflow, placing the weakest protected files on top of the queue.

Choosing the right workflow

Which of the two workflows should you choose when attacking a password? We have already discussed the “low hanging fruit” strategy (e.g. May the [Brute] Force Be with You!) where you would generally target data formats protected with weakest encryption. There is another side to “low hanging fruit”: attempting short, limited-time attacks on other formats before launching a longer attack on the weaker formats. Generally, you would place the fastest and shortest attacks on the top of the queue, with longer, time-consuming attacks taking the bottom of the list. The “Top-10000 passwords” attack will be fast on nearly every format. A dictionary attack with mild mutations may be already too slow on some formats but still meaningful on the others. To help you prioritize your password recovery queue we built a table comparing the relative strength of the different formats. WinZIP AES-256 will be the point of reference with the value of “1”. Attacks on NTLM passwords are nearly 45,000 times faster on the same hardware, while attacks on RAR5 archives are almost 10 times slower.

This table demonstrates that if you have a mix of files and hashes to break, it might be beneficial to attack NTLM passwords and individual hashes first if they are parts of the queue, making it a Workflow 1. If, however, you have a bunch of ZIP and RAR archives as well as a number of Microsoft Office documents, their relative protection strength is so close that you may ignore this factor and set up the attack as demonstrated in the Workflow 2.

The practical steps

Considering the above, we recommend setting up the following attack pipeline in Elcomsoft Distributed Password Recovery.

1. Use Top 10,000 password list and set up a straight dictionary attack as shown here:
2. Add a digit-only attack. Limit the length of the passwords to 8 digits (for formats with stronger protection limit to 6 digits).
3. Make use of the dictionary of English language followed with an attack based on the dictionary of your local language. Configure the attack using medium mutations as shown below:
4. If none of that worked, estimate your chances with a brute-force attack. You may still use masks and rules to throw out some very random passwords.

Conclusion

The password recovery process involves a queue of sequential jobs, each job representing a single attack on a single file. The queue can be set up in many different ways. We recommend one of the two setups: you can place the multiple attacks on a single file first, or attack multiple files with multiple attacks, placing the fastest and shortest attacks at the front of the queue.

The choice of workflow depends on the relative protection strength of files and hashes to be broken. A table comparing the relative strength of different formats will help prioritize the password recovery queue. In the first workflow, files with the weakest protection are placed on the top of the queue. Then, for each file, the fastest and shortest attacks are placed at the top, while longer and time-consuming attacks take the bottom of the list. In the second workflow, the most time-consuming attacks are moved to the bottom of the queue for all files. Ultimately, the choice of workflow will depend on the specific mix of files and hashes to be broken and their relative protection strength.