iPhone Forensics – Zdziarski Technique

Jonathan Zdziarski is a Research Scientist for McAfee, Inc., and well known outside of work in the iPhone community as “NerveGas”, who has contributed significantly to research into the iPhone and iPod touch.

He has authored many utilities, and devised many of the methods used to open the iPhone’s platform to the open source community. Zdziarski has written three books pertaining to the iPhone platform: iPhone Open Application Development, iPhone SDK Applications, and iPhone Forensics: Recovering Evidence, Personal Data, and Corporate Assets.

Prior to publishing iPhone Forensics, Zdziarski maintained an unofficial forensics guide for the iPhone distributed exclusively to law enforcement.

The “holy grail” of any forensic acquisition is performing a bit-by-bit copy of the original media and retaining proof that the two are identical by comparing the unique cryptographic signatures of the original and the copy to ensure they match. While the processes and procedures for this are well established in traditional hard drive based computer forensics, the process for mobile forensic devices proves quite challenging. Unlike hard drives which can be removed or computers that can start in special read-only forensic environments, cell phones comparatively have a very limited operating system, cannot boot into a forensic environment and the memory is typically non-removable. Logical copies have been the only method of performing mobile forensics outside of imaging removed memory cards or reading SIM card data.

The uniqueness of Zdziarski’s method is that it is the only approach that allows the examiner to perform a bit-by-bit copy of the iPhone’s user partition and can provide an MD5 sum to prove the copy was authentic. However, this ability does not exist in the standard iPhone operating system and requires modifying a read-only system partition to allow for this technique. Fortunately, this partition remains completely isolated from the partition containing user data and is intended to remain in a factory state throughout the life of the iPhone. This makes it an ideal and forensically sound location to perform the necessary payload installation, without violating user data.

Zdziarski recognized the technique has obstacles to overcome to be fully understood and accepted and addressed various concerns beginning on the second page of his book. Zdziarski explains that since his technique modifies the system partition only and preserves the user partition, the process is not only valid but more reliable and complete than other “triage” approaches, because it provides access to the raw disk images and allows the examiner to bypass any security added onto the iPhone, such as a user pass code.

It is important to point out that during the normal operation of the iPhone, the system partition remains in a factory state and is only modified during a firmware upgrade. As such, the likelihood of any user data or evidence existing in this system partition in highly unlikely, so modifying this system partition is not much different than modifying a desktop’s boot sequence to boot a USB keychain or CD-ROM.

Another important point to note is the difference between Zdziarski’s methods and popular jailbreaking methods, and the forensic superiority of the former over the latter. The term jailbreaking refers to a hacking process by which the iPhone firmware is overwritten in order to install third party application bundles or perform baseband unlocking. The jailbreaking process makes many modifications to the user data partition (as well as the baseband radio) to accomplish this, making it forensically unsound. Zdziarski’s procedures, on the other hand, are more custom-tailored to forensic recovery and only operate on the read-only system partition. Unlike jailbreaking, they do not install any additional software or modify the user data partition in any way.

Zdziarski’s procedure involves creating a custom forensic recovery RAM disk that is booted as if it were a firmware restore. Rather than actually restoring the iPhone, this bundle installs a recovery payload onto the iPhone’s read-only system partition granting the examiner SSH access to the device, and bypassing any pass code security that might exist. The payload can also be optionally modified to disconnect the iPhone’s user data from the system keychain, preventing the iPhone from logging into a suspect’s email accounts after it has been seized.

In speaking with the author, he stated that the concerns attorneys, law enforcement officers, judges or juries might have are quickly alleviated when a simple explanation and overview of his technique is presented. He stressed the importance of explaining the difference between the jailbreaking hacking techniques and his own recovery techniques, and explained that some misconceptions about his procedures may have led some agencies to quickly discount his procedures based on incorrect assumptions.

Since Zdziarski’s technique is not an application but rather the procedures to follow to install a forensic toolkit and acquire a bit-by-bit copy (dd image), there is no single application to install. Rather, you must possess the tools and technical knowledge to follow his procedures.

I consider myself very technical. I’ve taught assembly language as an Adjunct Professor, programmed numerous system and in many languages, lead large teams of developers on enterprise implementations, performed complicated Cisco networking and phone installs, function as the CIO of a large, multi-national corporation and I am an experience computer/mobile forensic analyst. I have been an avid user of Linux since 1993 (pre-1.x kernel) and am comfortable navigating in many operating systems including version of VMS, Unix, Linux, Mac and Windows.

I mention the above to provide some background as to my technical knowledge. I was confident at the outset that I could follow Zdziarski’s technique and easily acquire an iPhone. However, my experience was quite different. I feel certain that without 15+ years of highly technical experience, I would have likely failed or would have certainly taken much longer to succeed (and perhaps sacrifice the iPhone data a few times along the way). In the end, I succeeded in performing Zdziarski’s technique and acquired a physical image of the iPhone user data partition. For completeness, I performed the technique a second time on a different phone. The method certainly works and while very technical, the benefits are, are you will see, quite significant.

Briefly, the following four steps provide an overview of the procedures you must follow to prepare an iPhone for a physical dd acquisition (if you want the full details I suggest purchasing a copy of his book):

I will preface these steps by stating that I used a combination of Mac OS X 10.4, 10.5, Debian Linux (2.6.18) and Windows XP Professional to perform various tasks. In his book, Zdziarski points out both the Mac and Windows XP versions of the packages needed however to perform his technique however he executes all steps using Mac OS X 10.5.

Installing Pwnage Tool and creating your base custom firmware package is quite simple. I chose to run Pwnage Tool 2.2.1 for the Mac. Basically, you follow the prompts. First, select your phone type (important to not get this part wrong).

Figure 1.1. Pwnage Tool

And then select the firmware (which you can download from several archive sites if needed) that the phone is running.

Figure 1.2. Pwnage Tool Selection

You then answer a series of question which I will not step you through in detail at this time.

Figure 1.3. Pwnage Tool General

But, basically you are using Pwnage Tool to build a custom firmware bundle (IPSW) which you will then modify to suit your needs.

After the questions are answered, Pwnage Tool will prompt you to name the custom firmware bundle.

Figure 1.4. Pwnage Tool Save

And will then build it for you.

Figure 1.5. Pwnage Tool Building

At this point, Pwnage Tool asks if your phone has ever been Pwned before. If not, if steps you through setting the iPhone into DFU mode.

Figure 1.6. Setting to DFU Mode

This prepares the iPhone to accept the custom firmware update into the boot ROM.

Figure 1.7. DFU Mode Successful

Things get a bit more interesting when you have to create the stage1.ipsw and stage2.ipsw firmware bundles. If you are following the book step by step, make sure you check the book’s Errata (http://oreilly.com/catalog/9780596153588/) and the sample code section (http://www.zdziarski.com/iphone-forensics/) as there have been some corrections and updates since it was published.

When I first installed Xpwn on OS X, I noticed the firmware bundles needed to grab the key and initialization vector needed to unpack and decrypt the Apple firmware were not included. I did not want to switch to Windows XP so I decided to use Linux for these steps. The binaries I found for Xpwn on Linux did not work on my workstation as they required GLIBC 2.4. So, I downloaded and compiled the Xpwn on Linux and used Linux for steps 2 and 3 (full directions at http://chicago-ediscovery.com/iphone-forensic-howtos/howto-compile-xpwn-debian-etch.html).

While these steps were more technical, it is the final step that can be the most difficult and frustrating. Putting the iPhone in DFU mode is quite easy and you get better over time. But what is very frustrating are the series of errors you may experience from iTunes. You will eventually dread the various errors you may receive such an error 6, 1600, 1601, 1602 or 1604.

Figure 1.8. iTunes Errors

Here are a few things I did to (eventually) get around these errors.

While creating the stage1.ipsw and stage2.ipsw can be a bit tedious, iTunes errors are the most frustrating because you really don’t know what is going on and there are way too many posts on the web from people you should probably not take advice from. If you are determined to get around these problems, follow Zdziarski’s steps closely, make sure your equipment and software are up to date and be tenacious.

After you successfully apply the Stage 1 and Stage 2 custom firmware bundles, things get a bit easier. Zdziarski details several ways to acquire the dd image from the iPhone but I chose to create an Ad-Hoc network with my Mac and configure the iPhone with a static IP. If you choose to use a WAP, then you may consider more secure options such as using encryption or tunneling over SSH.

My 16GB iPhone took about 5hrs and 15mins to upload the resulting dd image. The MD5 hash of the drive also took several hours however everything matched in the end. Below is output from the second session on the iPhone during the acquisition:

andrew-hoogs-mac:~ ahoog$ ssh -l root 192.168.0.2

The authenticity of host ‘192.168.0.2 (192.168.0.2)’ can’t be established.

RSA key fingerprint is ba:d0:4f:d9:5c:2f:a1:5d:7c:16:79:44:9e:5b:6e:53.

Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added ‘192.168.0.2′ (RSA) to the list of known hosts.

root@192.168.0.2’s password:

-sh-3.2# cd / -sh-3.2# umount -f /private/var

-sh-3.2# mount -o ro /private/var

-sh-3.2# /bin/dd if=/dev/rdisk0s2 bs=4096 | nc 192.168.0.1 7000

3836826+0 records in

3836826+0 records out

15715639296 bytes (16 GB) copied, 19224.3 s, 817 kB/s

And the corresponding session on the Mac:

andrew-hoogs-mac:Desktop ahoog$ nc -l 7000 | dd of=./rdisk0s2 bs=4096

23349+22444701 records in

23349+22444701 records out

15715639296 bytes transferred in 19484.749921 secs (806561 bytes/sec)

Both the iPhone and the Mac reported the same MD5 has for /dev/rdisk0s2 and the dd image: 543f2ce0f118d5e1f3a6bd29c575b75f.

Unlike other tools which then guide the examiner through analysis of the acquired data, Zdziarski’s method produces a raw dd image and can thus be imported into many forensic tools or analyzed command line.

However, the iPhone uses the HFS/X file system (fifth generation HFS) and as such many forensic tools do not yet recognize the file system. A work around is to modify the dd image a 0×0400 and change the HX to H+. This will allow any forensic tool that understands HSF+ to process the image.

ahoog@wintermute:~/iphone-img$ file rdisk0s2.img

rdisk0s2.img: Macintosh HFS Extended version 5 data last mounted by: ‘10.0′, created: Sat Jan 3 04:43:38 2009, last modified: Sat Jan 3 19:49:38 2009, last checked: Fri Jan 2 22:43:38 2009, block size: 4096, number of blocks: 3836826, free blocks: 3829592

This is another key area where you must be able to explain what you changed, why you changed it and how it did not impact the authenticity of the image.

I chose not to import the image into any commercial forensic tools, instead opting for command line analysis on my Linux forensic workstation. I did have a problem where Linux could not fully traverse the HFS file system mounted natively and so I preformed part of the analysis in Linux but mounted the disk image file system on a Mac.

Like any standard dd image analysis, you likely want to carve files from allocated and unallocated space as well as extract all strings. Zdziarski provides a scalpel configuration file in the sample code section of his website that is tailored to recovering important iPhone files such as images, XML files, SQLite database, Plist files and more. When I ran scalpel on my Linux workstation, it processed the image in just over 8 minutes and carved 30,213 files. Below is the output from the command.

ahoog@wintermute:~/iPhone-results$ time /home/ahoog/src/scalpel-1.60/scalpel -c /home/ahoog/scalpel.conf rdisk0s2.dd Scalpel version 1.60 Written by Golden G. Richard III, based on Foremost 0.69.

Opening target “/home/ahoog/iPhone-results/rdisk0s2.dd”

Image file pass 1/2.

rdisk0s2.dd: 100.0% |***********************************| 14.6 GB 00:00 ETA

Allocating work queues…

Work queues allocation complete. Building carve lists…

Carve lists built. Workload:

gif with header “\x47\x49\x46\x38\x37\x61″ and footer “\x00\x3b” –> 1 files

gif with header “\x47\x49\x46\x38\x39\x61″ and footer “\x00\x3b” –> 78 files

jpg with header “\xff\xd8\xff\xe0\x00\x10″ and footer “\xff\xd9″ –> 1022 files

jpg with header “\xff\xd8\xff\xe1″ and footer “\x7f\xff\xd9″ –> 53 files

png with header “\x50\x4e\x47\x3f” and footer “\xff\xfc\xfd\xfe” –> 17 files

png with header “\x89\x50\x4e\x47″ and footer “” –> 983 files

dat with header “\x44\x79\x6e\x61\x6d\x69\x63\x44\x69\x63\x74\x69\x6f\x6e\x61\x72\x79\x2d” and footer “” –> 2 files

plist with header “\x3c\x70\x6c\x69\x73\x74″ and footer “\x3c\x2f\x70\x6c\x69\x73\x74″ –> 9240 files

plist with header “\x62\x70\x6c\x69\x73\x74\x30\x30″ and footer “” –> 11873 files

sqlitedb with header “\x53\x51\x4c\x69\x74\x65\x20\x66\x6f\x72\x6d\x61\x74″ and footer “” –> 915 files

email with header “\x46\x72\x6f\x6d\x3a” and footer “” –> 5469 files

doc with header “\xd0\xcf\x11\xe0\xa1\xb1″ and footer “” –> 4 files

htm with header “\x3c\x68\x74\x6d\x6c” and footer “\x3c\x2f\x68\x74\x6d\x6c\x3e” –> 545 files

pdf with header “\x25\x50\x44\x46″ and footer “\x25\x45\x4f\x46\x0d” –> 0 files

pdf with header “\x25\x50\x44\x46″ and footer “\x25\x45\x4f\x46\x0a” –> 1 files

amr with header “\x23\x21\x41\x4d\x52″ and footer “” –> 10 files

Carving files from image.

Image file pass 2/2.

rdisk0s2.dd: 100.0% |***********************************| 14.6 GB 00:00 ETAProcessing of image file complete. Cleaning up… Done.

Scalpel is done, files carved = 30213, elapsed = 509 seconds.

real 8m28.869s

user 5m37.189s

sys 0m20.561s

As you can see, this process was fast and produced many carved files but the drawback is the potential for many false positives. However, using standard techniques such as the file command, scripts, image viewers and more, you can whittle away at the extraneous files quickly. The results were quite effective and provided insight into iPhone usage that no other tool could provide

Of the 2,000+ images exported, many gave detailed information about the phone and the owner. One feature of the iPhone is that screens zoom in and out as you switch between applications. To achieve this, the iPhone takes a screenshot of the iPhone just prior to changing screen and then applies the transition. Because of this, the iPhone is full of images that show what the user was viewing when they switched screens. Below are examples of some images recovered from the iPhone.

Table 1.1. Screen Images Extracted

Multiple images of Contacts were recovered allowing the examiner to possibly piece together contacts that may have been deleted and were unrecoverable.
Screen displayed a note that was later deleted. While the note was discovered by analyzing deleted records in the SQLite database, sometimes that approach fails. This screenshot could provide a key piece of evidence in a case.
Map image that was displayed on the iPhone
Voicemail page displaying undeleted message(s)
Dial pad displaying phone numbers dialed
Image likely downloaded from email (Internet Explorer)
Email message with To/From/CC and full message

Another useful technique is to run strings on the dd image. Below is the output from that command:

wintermute:/home/ahoog/iPhone-results# time strings -t d rdisk0s2.dd > rdisk0s2.dd.str

real 4m29.952s

user 3m54.267s

sys 0m18.137s

The resulting file had 14,400 lines and could be easily searched to located important information.

As with other tools, analysis of the SQLite databases directly (using a hex editor, strings and other techniques) revealed some deleted rows that were not yet purged from the file. Quite notably, Zdziarski’s technique was the only approach that found the 1,000+ email messages on the system. This highlights the drawback to techniques that do not perform a bit-by-bit copy. In scenarios where a logical copy is made, the technique can only produce information that is presented by the operating system, transfer protocols or known by the forensic vendors. I suspect every other product missed the emails because they were either stored in non-standards areas since they were downloaded via Microsoft’s Active Sync or because the iPhone transfer protocol does not expose these files. If you assume some criminals are technically savvy and have some financial support, it would be quite simple to develop an application for the iPhone that stores information they want in non-standard ways, thus thwarting any logical data extractions.

Zdziarski’s technique was also the only approach to recover deleted and undeleted voicemails (11 in total). This can be a key aspect of any investigation. Similarly, his technique also recovered various office documents including an Excel expense report, 1 PowerPoint presentation, 546 HTML documents and two court documents that were stored as a Word document and PDF. Given the iPhone’s agility in handling these types of documents and their proliferation in email messages, the inability to recover them is a real deficit for any forensic tool. Finally, Zdziarski’s technique also recovered over 21,000 XML and Plist files. Undoubtedly there are some repeats and false-positives however I believe a more thorough investigation of these files will results in even more detailed information being discovered.

The following are the results from the Zdziarski tests.

The forensic technique outlined by Jonathan Zdziarski provides the most sought after asset in any computer forensic investigation, a bit-by-bit copy of the original media. While there are questions that might arise about how the technique is performed, what it might change and the degree of difficultness, it is unarguably the most accurate of any tool tested. By analyzing the resulting image, an examiner can discover a wealth of information other tools simply cannot provide and they can use the forensic analysis tools and approaches they utilize in standard hard drive based forensic investigations.

The following ranking establishes Zdziarski’s technique’s overall rating of 3.3 on the four criteria established at the beginning of this white paper.

Andrew Hoog, Chief Investigative Officer of viaForensics, is a recognized computer scientist and forensic analyst and former chief information officer of a $750 million multinational corporation. He has led investigations, contributed to policy development and lectured at corporations, attorneys’ associations and law enforcement agencies about the computer forensic discipline. He maintains a computer forensics and E-discovery glossary, authors computer/mobile forensic how-to guides and is now writing a book about Android forensics. He is the original author of this ground breaking white paper on iPhone Forensics that has gained recognition throughout the industry.

Kyle Gaffaney is a third year law student at Loyola University of Chicago School of Law. Kyle also has degrees in Accounting and Management Information Systems from the University of Minnesota Carlson School of Management. Prior to law school Kyle served as a staff accountant at a financial management firm.

viaForensics is an innovative computer/mobile forensic and e-discovery company providing expert consulting services to corporations, law firms, law enforcement and government agencies.

Beyond servicing our clients immediate needs, the company focuses on groundbreaking research in areas such as mobile forensics, SQLite forensics, data visualization and general education on forensics by regularly posting HOWTOs, glossary terms and the results of our research, accessible at viaforensics.com.

One key strategy to minimizing this risk is to implement computer forensic techniques. But the question is, why outsource? Often the initial response is that internal IT resources can perform these services in addition to their normal day to day tasks. But the reality is that there are significant burdens including: