Disclosures and Source Code: Appendix - iPhone Forensics

This appendix includes details about the procedures and results described in this book that a court may require from law enforcement witnesses, prosecutors, and defendants.

This excerpt is from iPhone Forensics. iPhone Forensics supplies the knowledge necessary to conduct complete and highly specialized forensic analysis of the iPhone, iPhone 3G, and iPod Touch.

Power-On Device Modifications (Disclosure)

When any computer is turned on, files are read and
written. iPhone examiners need only be concerned with what is written,
as the iPhone’s filesystem is mounted with the noatime option, even if the option is not
specified in /etc/fstab. This option prevents access
times from being updated when a file is read or its metadata (such as
its name) is changed on the device. Therefore, the access time shown on
a file should reflect either its creation or the last time some change
was made to the content, allowing you to concentrate on only the files
that have been actually changed.

In the likely event that you don’t possess special equipment to
physically dump the iPhone’s memory chip, the device must be powered on
and booted into its operating system to recover data. Furthermore, the
forensic tools described in this book require that the device be
rebooted after the toolkit payload is installed.

Just like a desktop operating system, the iPhone’s Leopard operating system performs minor
writes to certain files upon booting. The purpose of most writes is to
replace or reset existing configuration files, and writes generally
don’t add any new data to the filesystem. Some writes, however, append a
very minor amount of data to files. Overall, the writes to the
filesystem are minimal, but are disclosed here in Table A.1, “Bytes added to files during boot” for integrity.

Note

On iPhone firmware versions lower than or equal to 1.1.2, the
mobile directory is replaced with
root.

Installation Record (Disclosure)

The forensic toolkit payload installed by iLiberty+ places
a set of open source tools onto the otherwise read-only portion of the
device, resulting in no destruction to user-level data stored on the
device’s media partition. At the time of payload installation, the
following files are written to the system (root) partition.

Note

File size may vary depending on the application and payload
versions used. Some files are deleted after toolkit
installation.

Technical Procedure

This section explains some low-level technical details of
the operations performed by the iLiberty+ tool. These techniques are
intended for those desiring a technical explanation of the procedure or
who seek to reproduce or reimplement it, and are not necessary for
general forensic examination.

Many different methods have been devised by the iPhone development
community to gain access to an iPhone’s operating system, but very few
of them are able to do so without destroying evidence, or even
destroying the entire filesystem. The technique used in this manual is
considered to be forensically safe in that it is cdisclosures-sourcecodeble of accessing
the device without corrupting user data.

Unsigned RAM Disks

A RAM disk is a filesystem that resides in memory, and
is not physically written on disk. Most Unix kernels are cdisclosures-sourcecodeble of
booting the operating system from memory, and most versions of iPhone
software also support this.

The technique used by iLiberty+ for iPhone software versions
1.0.2–1.1.4 gains access to the operating system by booting an
unsigned RAM disk from the iPhone’s resident memory. This RAM disk is
copied into the iPhone’s memory and booted by setting the appropriate
kernel flags using Apple’s MobileDevice framework. This section is
based specifically on version 7.4.2 of the device framework. Because
the function calls change slightly for newer versions of the
framework, you will have to install this framework with a copy of
iTunes 7.4.2 in order to reproduce the procedure in this
section.

Once the unsigned RAM disk is booted, the iPhone’s disk-based
filesystem is mounted and the selected payload is copied. Depending on
the payload, this could simply enable shell access, or install a
surveillance kit or any other type of software. When the device boots
back into its normal operating mode, the installed payload will be
executed, performing whatever tasks it was designed for.

iLiberty+’s custom RAM disk differs from the RAM disk used by
Apple to install software updates and perform restores. The custom
iLiberty+ RAM disk consists of a disk image containing the necessary
ARM-architecture files to boot and install a custom payload on the
iPhone. The RAM disk itself is padded with 0x800 bytes to contain an
8900 header, and may additionally pad between 0xCC2000 and 0xD1000
zero bytes to assist in aligning the execution space of the
disk.

Once a custom RAM disk has been assembled, it is executed using
private and undocumented function calls within Apple’s MobileDevice
framework. In short, this involves the following procedures.

The device is placed into recovery mode either manually (by
holding the Home and Power buttons until forced into recovery mode),
or by using the MobileDevice function AMDeviceEnterRecovery. The RAM disk image is
sent to the device using the private __sendFileToDevice function after looking up
its symbol address in the framework.

The following commands are sent to the device using the private
__sendCommandToDevice function after
looking up its symbol address in the MobileDevice framework. This sets
the kernel’s boot arguments to boot from a RAM disk, and specifies the
memory address of the approximate location of the custom image copied
to the device.

setenv boot-args rd=md0 -s -x pmd0=0x9340000.0xA00000
saveenv
fsboot

Note

Depending on the cdisclosures-sourcecodecity and firmware version of the device,
different memory addresses may be necessary. The memory address
0x09CC2000.0x0133D000 has also
been reported to succeed.

Once the RAM disk has booted and the payload has been delivered,
the device can be booted back into normal operating mode by sending
the following commands to the device using __sendCommandToDevice:

setenv boot-args [Empty]
setenv auto-boot true
saveenv
fsboot

Note

Depending on the version of iPhone firmware, the fsboot command may be replaced with
bootx.

Source Code Examples

The following source code illustrates the process of
booting an unsigned RAM disk in C. The example waits for the device to
be connected in recovery mode and then issues the commands to send and
boot a RAM disk as described in the previous section. The RAM disk
image and needed framework library are provided by the implementer.
This code was designed to run on the Mac OS X operating system running
iTunes 7.4.2 MobileDevice framework. Comments are provided
inline.

Once the RAM disk has been injected and booted, iLiberty+’s work
is complete and the RAM disk has delivered whatever payload it was
written to deliver. The device can then be returned to normal
operating mode by issuing the following commands in place of those in
the Recovery_Connect
function: