12 min read

Taking The First Step - iOS Security & Forensics

Taking The First Step - iOS Security & Forensics

Today i’m going to share some of my processes, and the background terminology, techniques and background information you’ll be able to use during your exploration, giving you a kick-start to begin your own research effectively.

Part 1 focuses on covering the iPhone Encryption States, iOS/Mobile System Data Management, Extracting The Entire Filesystem Contents Of Your Device & Configuring & Troubleshooting SSH Appropriately, how these processes work, and the influence various protection mechanisms and public projects could have on your research.

Why Might You Be Interested In iOS Forensics, anyway?

iOS Forensics (and Mobile Forensics as a wider subject), is an incredibly interesting area. As more and more personal data is held on mobile devices, from banking data, sensitive conversations and health data - gaining access to the data held on a mobile device could possibly be considered more valuable than gaining access to a laptop or desktop computer.

Mobile Devices naturally develop a large repository of personal/sensitive information due to the vast amount of sensors present on device.

A prime example of this could be location data - though a desktop or laptop may be moved from location to location, mobile devices maintain a constant connection to cell towers, WiFi networks and more. All of this information is logged and stored in various locations on your device - some user facing locations, some not. Today, we’ll learn how to begin deciphering this information.

Let’s discuss the filesystem and the relevant ‘Encryption States’, as it’s a very key part of the process!

iDevice Encryption States

When we think about the iPhone, it’s quite common to be under the generally-accepted consumer idea that “all of my data is encrypted” - because it’s what Apple pushes to their consumer-base. For the purposes of our exploration, we should change up this idea a little bit to better reflect the technicalities.

“Select files on the iDevice filesystem will be encrypted and protected by the SEP, under conditions”

What this essentially means is that each file on the device’s filesystem is assigned a ‘marker’ of sorts. This marker defines the ‘encryption state’ of said file, and it’s availability to the system.

The filesystem on an iPhone resembles a standard ‘*nix filesystem’ structure very closely! Later in the guide, we’ll compare the filesystem of our macOS and iOS Device, discussing both the similarities and differences.

Quoting the Apple Developer Documentation defining which ‘markers’ can be applied to individual files - “Protection level values … can be associated with a file attribute key”.

There are actually 4 different protection levels - although we can look at this from another abstraction which will be a little more relevant to our research. ‘AFU-accesible’ and ‘BFU-accesible’.

BFU/AFU?

After First Unlock (AFU) represents the state that the device will be in where the device has been unlocked since boot time. For example, the user boots the iPhone, unlocks it. It then becomes AFU - even if the phone screen becomes locked. It’s still AFU as it had been unlocked at least  once since boot.

Before First Unlock (BFU) represents a state where the iPhone has been booted, and the passcode is not known.

I’ve created a little table, which i’ve actually posted in a couple of my other articles previously - I feel it’s relevant here too!

From this point onwards, the terms ‘encrypted’ and ‘AFU-accessible’; ‘decrypted’ and ‘BFU-accessible’ have the same meaning.

Is your Photo Gallery encrypted? yes. Is your address book encrypted? yes again! - These are often the first couple of questions i’m asked by users interested in getting started in iOS Security Research, and so it’s important to clear that up. The majority of content is encrypted and only available with a user passcode.

This bring us very nicely to…

Databases, Logs & Caches!

Your iPhone will maintain various system databases, logs and caches which are naturally not user-facing - the large majority of consumers are probably not aware of the existence of these databases.

Are these databases and logs malicious? absolutely not! although, these files do have the possibility of containing personal/sensitive information, which could in turn be used for malicious purposes.

To bring a little more clarity to this subject, let’s think about an application you likely use often. Apple Photos. Lot’s of features, right? face detection, in-built album sharing facilities, comments, likes, you name it. How are these features fulfilled? and how does iOS remember who sent what comment at what time? Well... databases!

In fact, it’s probably arguable that if you combined all of data from all of the databases that iOS maintains, your device may well possibly know more about you and your habits than you!

The problem begins to present itself where iOS requires access to said databases and caches during boot. For example, iOS populates a database of each application you have installed on your iPhone, and various statistics pertaining to your usage of each application.

If the iPhone requires this during boot, it becomes apparent very quickly that some of these databases are not encrypted at all - or in other words, ‘BFU-accessible’. This could be for speed-reasons (saving decryption time), or because the data is actually required in BFU.

Technical note - BFU-accessible files are still technically encrypted, but sep will process the decryption of BFU-accessible files without a user passcode.

Does iOS need access to some of the data available in BFU, in BFU? I’d argue not…

So, now we know a little about how the iOS Platform ‘enhances’ the user experience via the use of databases - let’s learn about some of the file formats you’re likely to encounter during your research!

SQL - Structured Query Language

Structured Query Language (SQL) is a database file format designed to allow for, as you may have guessed, custom queries to be executed against the data held in a database (and general interfacing, too - adding, removing records etc!). We could think of a database as a more complex, programmed excel workbook.

Here’s an example query...

‘SELECT Password FROM Users WHERE UserActive=1’

SQL Queries very often follow the ‘SELECT, FROM, WHERE’ style. Quite simple!

We choose which column(s) of data to select, the table containing the column, and define ‘conditions’ which each ‘row’ of data will have to meet to be included in the output.

If we take this example (this is actually just a spreadsheet in numbers, for visual purposes) - we can construct a couple of ‘queries’ to pull the data we’re looking for…

The ‘Table’ is iOSResearch, and the columns are ‘PageNumber’, ‘Complete?’, and ‘Notes’.

I’ll present a few queries here in the table below, alongside the records which would be returned!

There are more complex abilities such as parsing cell’s as different datatypes, such as hex. We use these features in my PhotoSH script, actually! Here’s the blog post -> https://www.duffy.app/blog/photosh

PLIST - Property List

Property List (PLIST) - PLISTS are often used for storing a small amount of data such as configuration data or a small list of ‘VIP’ contacts. PLISTS will often use a ‘key’ to represent a specific datapoint. We can parse PLISTs using the ‘plistbuddy’ on the Mac, which is kindly built-in!

Here’s an extract of a PLIST…

We can observe the usage of the ‘plistbuddy’ utility to parse the PLIST file. Each datapoint has a ‘Key’ and a value. For example, we can observe the CFBundleDisplayName key in the output above, and the value is ‘Stocks’.

We can use plistbuddy to process the key of our choosing, using the following syntax…

/usr/libexec/plistbuddy -c 'print KEY' Info.plist

If we know what we’re looking for, we can start to filter our results! This will help us a lot when automating our data gathering process - and save a lot of time when working with many devices, and documenting our research!

BPLIST - Binary Property List

BPLISTs are a ‘binary representation’ of a standard, human-readable plist. BPLISTs are often chosen over PLISTs due to their naturally faster processing speed. We can still parse BPLISTs in exactly the same way as a standard PLIST, using plistbuddy on the Mac.

There’s a few other file formats too, namely JavaScript Object Notation (JSON) - often used where data is pulled from an ‘API’, and parsed as the Application see’s fit. Another file format you might come across is quite simply, standard text (TXT) files! (for logs, mostly)

Extension-less Files

It’s also worth noting that it’s not uncommon to see files without any file extension, making it difficult to identify the correct file format at first glance. I’ll discuss file headers a little as it’s relevant to our work!

Here’s the file name… Can you guess what file format this file could be? no, neither can I!
I’ve now opened the file in a HEX editor. Here’s the file’s header. How about now? Have a guess at the file-type? Nope, me neither!
Here’s the ASCII representation of the HEX.

File headers are the first ‘section’ of information in a file. The header defines both the ‘type’ of file, and associated information.

For example, a JPEG will have the text ‘JFIF’ in the header - but will also contain the image resolution, colour depth and more. An audio file, however, will contain first it’s filetype, and additional information specific to that type, such as the audio bitrate.

Luckily for us, the ‘file’ *NIX utility can read the ‘headers’ of a file and often decipher the filetype from this information. You could actually try this on your Mac now! Head to Finder, remove the file extension from an image, launch terminal, and type “file image” where image is the name of the extension-less file.

Above, you’ll see the output of ‘file’ on our extension-less image. File identified! <3

Just a note - 4A464946 is the hex representation of JFIF, and can also be called the file’s ‘magic number’ or file signature. These are widely used in the forensic community to identify files without an extension.

If you’re interested in learning more about this, here’s a website containing a table of file signatures! https://www.garykessler.net/library/file_sigs.html

I’ve also found during my research, that iOS likes to use extension less files in a variety of areas across the system, including stock iOS Applications and also user-installed applications.

I personally like to identify extension less images in bulk, which I generally do using find. Find is a *nix utility used for identifying/‘finding’ files in a directory structure, and allow us to use a variety of criteria to identify the file’s we’re looking for.

Find in itself will not allow you to identify extension-less files, but will allow us to execute a command based on files matching certain criteria.

find . -type f -size +10k -size -800k -not -name "*.jpg" -exec file '{}' \; 2>/dev/null | grep -H JFIF

Above you’ll see an example command I’ve constructed and forms part of MapperSH (available for free on my GitHub as part of my SPIDER repository). I’ll explain each part of the find command in a table so that we can fully understand what’s going on…

Let’s Initialise An SSH Connection To The iPhone!

So, iPhone at hand, let’s obtain SSH access to the device - there’s a few ways we can do this…

To connect to a device via SSH, there must be an SSH Server/Daemon (the target device), and an SSH Client (our Mac).

On a checkra1n compatible device, all we have to do is simply boot the device using checkra1n - This allows for the ‘SSH Server/Daemon’ to start and accept incoming connections. This allows us to interface with the device, even if it’s passcode locked and in the BFU State we discussed earlier.

We could also use a public jailbreak, which may or may not have an SSH Server implemented by default. If it doesn’t, you could install OpenSSH from Cydia, the package manager for jailbroken iDevices. If you go that route, keep in mind where I mention port 44, you’ll have to use 22 instead!

Daemon / service are terms that can be used interchangeably.

The SSH Daemon is not present in iOS by default as it opens up the device to ‘uncontrolled’ and potentially unauthorised code execution on the device.

I’ll presume we’re using checkra1n to boot the device. Use checkra1n, and following the reboot - do not unlock your device.

Let’s connect the iPhone to the Mac, and continue to the next step!

We’re going to have to enable a ‘tunnel’ for SSH traffic to pass between our Mac and the iPhone. We can do this using a variety of applications, but my favourite is iProxy.

To use iProxy, you should have libimobiledevice installed on your machine.

You can use Brew to install libimobiledevice using the command “brew install libimobildedevice” in your Mac’s Terminal. If you receive a command not found error, head to https://brew.sh for installation instructions and give it another go!

Once everything is installed and ready to go, we can proceed. When using checkra1n, the device exposes the SSH service on Port 44 of the iPhone. We need to redirect this port to our Mac and allow us to initialise a connection, and we use the iProxy utility to do so.

“iproxy 44 7788”

Keep in mind you may have to use sudo for the command to execute properly, depending on your system configuration.

The iProxy command listed above will redirect the ‘device port’ 44 to the local port on our Mac 7788. Any specific reason for choosing 7788? none at all! We can use almost any available port on our Mac, it’s just best to choose a semi-random number so we don’t run into conflicts with other system services.

We’re now ready to initialise our SSH connection to the iPhone! Head to your Terminal in macOS, and type the following:

“ssh [email protected] -p7788”

This command initialises a connection to our ‘local machine’ on port 7788, which is really the iPhone (remember the device port was directed to a local port) - the username we’re connecting with is ‘root’ and the -p flag is used to define a custom port.

Upon executing this command, we should be presented with a password prompt. ‘alpine’ without the quotes, is the default password for an iOS Device. It’s recommended that you change this password upon connection by typing ‘passwd’ once connected.

Congratulations, we’re connected!

Quick Troubleshooting

It’s possible you’ll receive an error like this while connecting. This is simply due to a mismatch in the cryptographic keys provided during the connection. macOS records these keys and checks them against it’s internal records upon each connection as it expects each host to be using the same keys upon each connection.

In our case, each new iPhone will appear to be on the same host and will cause an error like the one above! Type: “rm .ssh/known_hosts” and try the connection again <3

Browsing The iOS Filesystem

With our SSH connection initialised, we’re now able to pivot through the devices filesystem structure! We can use the cd command to change our ‘working directory’ to one of our choosing. Let’s change our working directory to the ‘root’ or ‘top’ of the filesystem.

cd /

We can then use ls to list the contents of the directory. I personally suggest using…

ls -l

…as it’ll present everything in a pretty list!

We can then begin to browse the filesystem. Try to ‘cd’ to one of the listed directories and ls inside it!

If you spot a file, we can use ‘cat’ to print the contents of the file to our Terminal window.

This is going to be extremely tedious (and very limiting, as we don’t have access to all of the tools on our Mac like plistbuddy), and so what we should really do is acquire the filesystem!

Acquiring The Filesystem…

So, iPhone ready to go, let’s manually obtain a copy of our device’s filesystem, outputting the contents to a tar.

Once our SSH connection has been initialised, as counter-intuitive as this may seem, we must actually exit from the SSH prompt so that we can execute a ‘single line command’ without establishing a full terminal session with the device…

ssh [email protected] -p7788 'tar zcf - /’ > rootfs.tar

Above, you’ll see the command I use to compress a directory to a tar, which in this case is ‘/‘, meaning the entire root filesystem.

You’ll see an ssh connection to the device is opened, immediately executing the command in the quote marks.

Everything within the quote marks is executed on the iPhone.

What we’ll also notice is that there’s a ‘>’ symbol. This allows for a *nix system to redirect the stdout of a command, or the ‘output’, somewhere else. Because we’re not initialising a full session and the redirection occurs outside of the quote marks, the stdout is being redirected to rootfs.tar on our Mac.

In the case of this command, the output will be the ‘tar’ data!

If you wanted too, you could actually remove the ‘> rootfs.tar’ section of the command, and you’d see the compressed data in the terminal window as it’s generated. Something like this… not so useful!

Conclusion - Part 1

So, that was part 1! a lot longer than my normal articles, but I really wanted to focus on the basic terminology and techniques <3