4 min read

ZPET - The iOS Deep Digger Project -Development Part 1

ZPET - The iOS Deep Digger Project -Development Part 1

After experimenting with Cellebrite’s BFU Extraction Functionality myself, I become very interested in how much data was really encrypted on the average stock iPhone, and the possibilities this could bring to law enforcement agencies when inspecting a device.

My aim with ZPET Toolkit is to bring this functionality to everybody, so end users can see the data their device is holding in an unencrypted form - that in turn any malicious actor with physical access to the device could gain access to, too.

What’s BFU?

As of now, we can pull a limited amount of data from the device in BFU mode (Before First Unlock). BFU essentially means the device was rebooted, and has not had the passcode entered for the first time, so the Data partition, in theory, should be encrypted at this point and inaccessible to malicious users. Even more so if the macOS host is not trusted to communicate with the iPhone being inspected.

Of course, Cellebrite’s BFU functionality was fulfilled utilising the checkm8 bootrom exploit, and the same applies to ZPET Toolkit.

A General Overview - What ZPET Really Does

ZPET Toolkit requires you to first boot the device using checkra1n, regardless of whether the device is already jailbroken or not. The purpose of this is for us to be able to initialise an SSH connection with the iDevice in order to pull the interesting/useful data.

The first challenge finding data which is first unencrypted, and secondly information we can actually classify as interesting. Interesting data is, of course, different in every situation/scenario. For consumers this could be photographs and videos stored on the device. In contrast, for law enforcement agencies, useful information could be file metadata, or the last phone number used on the device - in particular cases where the sim card is missing or was destroyed.

Beginning Our Research

After digging through a rootFS that I acquired manually from the locked device, I managed to identify some areas and files of interest.

In this particular case where the device is BFU, a minimal amount of data is designed to be available or decrypted without user authentication, for obvious reasons.

However, personal details, session tokens, images/videos, and Apple Wallet pass details are unencrypted on the device, being stored in a wide variety of locations such as caches(temporary storage for applications to store data - can contain recent images), plists (used for storing preferences and values), and other temporary storage on-device.

Is This Time Effective? Pros & Cons?

Now, for the issues that are presented to us. Some data we can sift through is right there, unencrypted on the device in these various formats. We need a way of effectively parsing and visualising this data in a clean and concise format for the viewer so we can keep our eye focused on what really matters for our investigation. The plist and cache files often arrive individually with many useless values, alongside a little useful information in each file.

To extract useful information from the plist files, we have to make a decision to use on-device processing, or returning the file to the mac and parsing/processing the resources locally.

For speed, it’ll be faster in most cases (if we know what we’re looking for), to process the data on the device itself, and return the results to the desktop application, then to be converted to a report.

This is extremely applicable where large files are involved, considering the amount of time it’ll take to compress the folders/files and return them to the Mac over USB if we wanted to process the files locally on the Mac.

However, that would be very 'un-' forensically sound...

An entire rootFS dump of my day-to-day device has taken well over a few hours to compress, and that’s not too efficient in a forensic environment as we are trying to reduce the amount of contact-time we have with the device itself.

With that being said, I had to make that few hour sacrifice in order to get a good idea of what I could find in this iPhone rootFS and take note of the interesting files/directories for us to repeat on other devices. So I did, and I found a ton of really scary things (considering the iPhone is BFU I didn’t expect to find so much personal data.) My expectations were very, very wrong.

Back To Parsing & Extracting!

I considered the many methods of extracting and parsing the data, and eventually come to the conclusion it would be better to process all data on the Mac. You might be thinking, wait, but didn’t he just literally say on-device was faster?

I did. But processing on the Mac will produce much more steady and reproducible results, as we can utilise a wide variety of available parsing tools to help us with the file-types we will encounter rather than using a mix of the built in Unix tools available to us on the iOS device itself. Not to mention, processing on device could cause caches to be purged, etc, potentially compromising the integrity of the on-device data.