SMobile Global Threat Center

SMobile Global Threat Center
Analysis and Comparison of iPhone 3G, 3GS and

ContactCrypt Encryption Technologies
Troy Vennon, CISSP, CEH, GTC Research Engineer

Mayank Aggarwal, GTC Research Engineer
Chunyu Jiang, PhD., Director of Research and Development
Shinta Salim, Software Engineer
4320 E. 5th Avenue • Columbus, OH 43219

phone: 614-251-2238 • fax:614-251-4083
www.smobilesystems.com
Contents
Overview ..............................................................................................................................................3
Purpose ................................................................................................................................................3
Executive Summary ..............................................................................................................................4
Methodology .........................................................................................................................................4
Test Goals ............................................................................................................................................5
Baseline................................................................................................................................................6
Baseline Configurations ....................................................................................................................7
Test Cases .....................................................................................................................................25
Case 1: .......................................................................................................................................25
Case 2: .......................................................................................................................................29
Case 3: .......................................................................................................................................32
Deleted Contact: .........................................................................................................................35
Case 4: .......................................................................................................................................39
Case 5: .......................................................................................................................................43
Case 6: .......................................................................................................................................48
Synopsis .............................................................................................................................................52
Table of Results..................................................................................................................................52

phone: 614-251-2238 • fax:614-251-4083
Overview
Apple's iPhone 3G and 3G S offer the capability to protect the phone's data from unauthorized users
by setting a four character passcode in order to access the springboard and consequently the phone's
applications. The iPhone 3G does not currently offer any other version of data encryption on the
handset. However, the newly released iPhone 3G S offers an attempt at hardware encryption on the
device to encrypt its data in a couple of different scenarios and this document will outline the specifics
of the 3G S hardware encryption, and its failures. When tethered to and managed by Apple's iTunes
application, the user is also granted the ability to perform certain maintenance tasks, including
performing backups of the device. Beginning with iTunes version 8.1 and with iPhone 3G, the user is
given the ability to encrypt the phone's backup by supplying an additional passcode that can be
applied to iTunes prior to a backup being performed. This function essentially encrypts the files that
are created during the backup process so they can be stored in a secure manner.
Research has shown that there are tools and techniques available to bypass certain aspects of the
security controls applied to both the iPhone and iTunes. Given the proper tools, knowledge and
access to the handset, an attacker can simply bypass the passcode protections that iPhone offers to
gain access to the phone's applications. Additionally, it has been proven that it is possible to
effectively bypass the encryption performed by iTunes when performing a backup. The combination of
bypassing the handset's passcode security, bypassing iTunes' backup encryption capabilities and the
inherent flaws in the implementation of iPhone 3GS encryption allow an attacker to gain access to
sensitive information residing on the handset.
Purpose
SMobile Systems has developed an application called ContactCrypt that was designed to address the
lack of user data encryption available on the iPhone 3G and to supplement the weak encryption made
available on the iPhone 3GS. ContactCrypt is designed to allow the user to encrypt and decrypt the
contents of sensitive information within the Contacts section of the iPhone. While the iPhone was
designed for the easy development of gaming and other entertainment applications, the lack of
meaningful API!s and prohibited access to core components of the operating system make the
development of third-party security applications nearly impossible. Notwithstanding, SMobile
engineers were able to develop ContactCrypt to fully function within the limitations of a non-Jail broken
iPhone device and the application is currently available on Apple!s App Store. Given additional API!s
and operating system access, encrypting other components of the iPhone would take minimal effort by
SMobile development engineers.
With the revelation that it is possible to bypass the security controls native to the iPhone 3G/3G S and
iTunes, the SMobile Global Threat Center (GTC) set out to directly compare the forensic results of
encrypting contact information via the means made available by Apple to the encryption capabilities of
SMobile Contact Crypt.

phone: 614-251-2238 • fax:614-251-4083
About SMobile
SMobile Systems, founded in 2002 and headquartered in Columbus, Ohio, is the world leader in
providing comprehensive software security solutions for all major mobile device platforms, including
BlackBerry, Windows Mobile, Symbian, Palm, iPhone and Android.
In response to the growing demand for mobile device security, SMobile has created a complete mobile
security suite including AntiVirus, Firewall, AntiSpam, Anti-Theft and Identity Protection, Secure Mobile
Banking, and Parental and Enterprise Controls.
SMobile is noted as having the only Antivirus and AntiSpyware solution in the world to support
BlackBerry devices and in November 2008, was the first company to offer an Antivirus solution for
Google Android.
Executive Summary
Through the development of a baseline handset configuration, the GTC was able to perform a series
of tasks that duplicated the process required to bypass the security controls in iPhone and iTunes. A
series of tests were then performed that revealed the encryption status of the handset's data while the
handset was in various states of configuration.
Testing has shown that SMobile's ContactCrypt provides adequate protection to sensitive contact data
when iPhone security and iTunes backup encryption features have failed. Additionally, ContactCrypt
addresses an exposed weakness in the way that the iPhone contacts database handles deleted or
modified contacts that could expose the information to an attacker.
Methodology
Research into iPhone's security features has revealed versions up to and including the iPhone 3G S
running firmware 3.0 offer very little protection of user data and applications from an unauthorized user
who has gained physical access to a device. Several methods for bypassing the security controls of
the passcode and iTunes backup encryption have been identified and are well documented on the
Internet. Of these methods, the forensically sound method of bypassing the device's passcode,
developed by Jonathan Zdziarski, offers a method for bypassing the device's passcode while
preserving the data on the handset.
The GTC thoroughly researched Zdziarski's tools and methodologies and determined that, while his
method is preferable when data must be preserved, the use of the tools and scripts needed wouldn't
provide any better access to the underlying operating system than a device that was jail broken with
the publicly available tools. Therefore, it was determined that performing testing on a jail broken
device that subsequently had contact data inputted and encrypted would be sufficient to determine if
the application was functioning correctly and could be done so without publicly disclosing those
program and methodologies within this document.
For our testing, the GTC performed testing on the 3G and 3G S devices. The testing was performed
side-by-side to ensure the ability to identify any differences in findings based upon different versions of
the device. It is important to note that with the exception of the firmware build specific for the 3G and

phone: 614-251-2238 • fax:614-251-4083
3G S, as well as the tools we chose to jail break the devices, every other step
in the testing was performed in the same manner and there was no difference
in the findings between the two devices.
For the purposes of illustrating the step-by-step processes required to gain access to the device for
our testing, this document will focus its attention on building and jail breaking the 3G device. Where
the process was different for the 3G S device, differences in tool use and the experience will be noted.
Test Goals
The ultimate goal of the testing outlined in this document is to determine whether ContactCrypt was
properly encrypting contact data on the device after iPhone's encryption capabilities had failed.
Primarily, the testing team needed to ensure that the processes to bypass the device's passcode and
to bypass iTunes backup encryption mechanism worked properly and would not adversely affect user
data.
The iPhone passcode is enabled or disabled according to the existence of a particular record in the
keychain database that manages all passwords for every application or function that requires
authentication. Since OpenSSH will be installed and configured to allow the “root” user to
authenticate, this keychain can be accessed on the underlying operating system of the device by
browsing to the “/private/var/Keychain” directory. Inside that directory exists the keychain-2.db
database file that contains records correlating to each application's authentication credentials,
including the record that dictates whether a passcode is set for the handset or not. Removing this
record effectively removes any passcode that was set on the device after a reboot.
Secondly, the testing team needed to be able to illustrate that the iTunes backup encryption
functionality could be bypassed as well. Looking into the keychain database reveals an additional
record that correlates to whether a backup password has been configured through iTunes to force all
backups to be encrypted. Removing this record effectively tricks the device into believing that no
password has been configured through iTunes so the device does not need to process the data to
iTunes is such a way that it will be encrypted. As an interesting aside, removing the backup password
record from the database does not change the fact that the “Encrypt iPhone backup” selection in
iTunes is still checked. If a normal user were unaware that the encryption mechanism in iTunes had
been bypassed at the handset level, they would have no way of knowing that the backup was not
being encrypted by simply observing the settings through iTunes.
It is entirely possible to bypass the above mentioned security controls by simply removing or renaming
the keychain-2.db file and rebooting the device. However, removing the entire database also removes
any authentication settings that may be required for other applications, such as email, IM, WiFi and,
particularly important for this test, ContactCrypt. Through various tests, the GTC determined it best to
just remove the particular records that were needed to bypass the passcode and backup encryption
and leaving the extraneous records intact.

phone: 614-251-2238 • fax:614-251-4083
Baseline
The GTC defined a baseline configuration for the iPhone devices that would allow for the testing of
various levels of security and encryption, bypassed or not. It is important to establish that the process
of jail breaking the device allowed for the installation of Cydia, OpenSSH, SBSettings and
ContactCrypt onto the device, as well as allowed root access to the underlying file system that is
necessary to move the device to different levels of security for testing purposes. For iPhone
consumers, ContactCrypt can be easily installed via the Apple App Store.
The baseline configuration that was chosen is as follows:

• iPhone 3G and iPhone 3G S
• Firmware version 3.0 (7A341). A good repository for iPhone firmware can be found here.
! iPhone 3G Firmware: iPhone1,2_3.0_7A341_Restore.ipsw
! iPhone 3G S Firmware: iPhone2,1_3.0_7A341_Restore.ipsw
• iPhone 3G jail broken with “RedSn0w”
• iPhone 3G S jail broken with “Purplera1n”
• Cydia installed
• OpenSSH installed from Cydia
• No passcode set on device
• Contact exists as following:
! iPhone 3G:
" Name: Jane Doe
" Phone#: (555) 123-0987
" Organization: Testers Unlimited
" Email: jane.doe@aol.com
" Homepage: spoon.com
" Address: 90909 Broad St
Columbus, Oh 43222
! iPhone 3G S:
" Name: John Smith
" Phone#: (808) 444-4444
" Organization: Eight-0-Eight State Inc.
" Email: jsmith@yahoo.com
" Homepage: myspace.com
" Address: 15151 Main St
Reynoldsburg, Oh 43312

phone: 614-251-2238 • fax:614-251-4083
• ContactCrypt installed, but not enabled
• iTunes version 8.2.1
! Encrypt backup setting not checked
Baseline Configurations
In order to ensure we were working with a device that met the decided upon baseline requirements,
we chose to do a fresh firmware install on both the 3G and 3G S devices. The steps illustrated below
work the same for both devices, with the sole exception that the 3G device and the 3G S device use
different builds of the same firmware version. The steps to restoring a device to factory defaults for
firmware 3.0 is as follows (the images are taken from a 3G device):
1. In order to load a fresh firmware on a running device, the device needs to be put into Device
Firmware Update (DFU) mode:
2. To begin the process, turn the device off by holding down the power button at the top of the
handset until you see the red slide bar, then slide the bar to the right.

phone: 614-251-2238 • fax:614-251-4083
3. Once the device has powered off, it's time to begin the sequence that places the device into
DFU mode. With the device powered off, simply press and hold the power button and the
home button at the same time and count to 10 (100, 200, 300...), then let go of only the power
button, while continuing to hold down the home button for another 20 seconds.

phone: 614-251-2238 • fax:614-251-4083
4. If you're using Windows, somewhere around 10-15 seconds of holding just the home button
you'll hear an audible beep that alerts you to the fact that the system has recognized that a
device is connected to the USB.

phone: 614-251-2238 • fax:614-251-4083
5. After that audible beep, open iTunes. When iTunes is open you'll see
window pop-up saying that iTunes had detected an iPhone in recovery mode, click OK:
6. At this point, you'll be given the opportunity to restore the device. Notice the “Restore” button.
If you simply click this button, iTunes will go out and check with Apple for the most current
firmware version available for your device. At the time of writing this document, the most
current version is 3.0.1. We are specifically interested in restoring the device to version 3.0. In
the “Baseline” section of this document, we have provided a link to a site that maintains all
versions of iPhone firmware versions. Navigate to that site and download the firmware version
of your choice (we chose “3.0.0 (3G): iPhone 3G Firmware:
iPhone1,2_3.0_7A341_Restore.ipsw)

phone: 614-251-2238 • fax:614-251-4083
7. In order to be able to specify the firmware that you downloaded, in
Windows, hold down the “shift” key and click on restore. In Mac, hold down the “option” button
and click restore. You'll be given the option to browse for the firmware bundle:
8. Assuming you have selected a compatible firmware bundle, you'll see the following processes:
Extracting software:

phone: 614-251-2238 • fax:614-251-4083
Preparing Restore:
During the preparation step, you'll notice that the screen on the handset goes from blank to
displaying an apple and a progress bar
Restoring Software:
Restoring Firmware:

phone: 614-251-2238 • fax:614-251-4083
Verify Restore:
After the installation has completed, this is where there was a slight divergence between the
restore of the 3G and the 3G S. The 3G S device continued on to reboot into a fresh install.
However, the 3G device showed an error in iTunes indicating that the restore had failed:
10. Research indicated that the (1015) error did not indicate a failure in the restoration process.
The error indicates that there was a compatibility issue with the baseband that was running on
the previous firmware than the one that was just installed. Research also indicated that the
install completed successful, however the device will likely be placed into a “recovery loop” (not
DFU) as iTunes believes there was a failure. A recovery loop means that when the device
reboots, it will only boot into recovery mode and iTunes will continually believe that the phone
needs to be restored. If you are in recovery mode, you'll notice the device's display looks like
this and all manual attempts to leave recovery mode just bring you back to the same place:

phone: 614-251-2238 • fax:614-251-4083
11. In order to break out of the recovery loop, we need to interface with
iBoot to tell the device what to do. In order to interface with iBoot/iBSS, we chose to use
iRecovery. iRecovery is considered to operate universally in Windows and in Mac. We chose
to use a Mac Mini to run iRecovery
12. To begin, we downloaded iRecovery and unpacked the two relevant files to the desktop.
13. We then copied libusb-0.1.4.dylib file to /usr/local/lib
14. We then opened a terminal and navigated to the Desktop and ran the following command:
iRecovery -s
15. You should see something like this, which indicates that iRecovery has been able to
communicate with iBoot:

phone: 614-251-2238 • fax:614-251-4083
5. If you receive an error that states the following:
“got usb
no iphone/ipod found”
simply unplug the USB cable, force the device to power down by holding down both the
power and home button at the same time for 10 seconds, then reconnect the USB cable.
Once reconnected, run the command again.
6. After you have been able to get iRecovery to recognize the device, run the following command
at the command prompt:
fsboot
**A lot of available information on the Internet says that you need to modify the boot
parameters using iRecovery. We simply ran “fsboot” and it worked.
7. It may be necessary to run this command several times before the device responds, as you
may be able to make out in the terminal screen of the screen capture shown below:

phone: 614-251-2238 • fax:614-251-4083
8. From here, you should see the device's screen display a picture of an
apple with a status bar beneath it. Disconnect the USB cable and the
device will reboot.
9. You'll notice that when the device reboots, it will only allow you to make emergency calls. This
is because the device is not yet activated.
10. Simply connect the USB cable and open iTunes. The device will be activated and you can
access the springboard. You'll also notice that you're required to setup some configuration
settings in iTunes that tells it how to handle syncing tasks. Go ahead and make those changes
if you like, it's not necessary, since we're getting ready to jail break the device and install a
customized firmware that gives us access to the OS.
11. Jail breaking the devices was the second place where there is a slight divergence between the
3G and the 3G S. We chose to use Redsn0w for the 3G device and used Purplera1n to jail
break the 3G S device. We'll address the 3G, since there are screen captures to accompany
the procedures. For the 3G S and Purplera1n, we found that the process was much simpler as
the onscreen instructions for entering DFU mode were easier to understand. However, since
we have screen captures for Redsn0w and it will work for 3G and the 3G S device, that's what
we'll discuss. (Note: these instructions are for Windows users. Mac users should see
something very similar.)
12. Download and unpack Redsn0w from the Dev-Team.
13. Navigate to the folder where Redsn0w was unpacked and run the executable.

phone: 614-251-2238 • fax:614-251-4083
14. When Redsn0w starts, you'll be asked to provide the corresponding
IPSW file for your CURRENT firmware. This should be the same firmware bundle that was
used to restore the device in the previous portions of this document. Click "Browse:
15. Navigate to the correct IPSW file and open it:

phone: 614-251-2238 • fax:614-251-4083
16. Once the IPSW has been successfully identified, click "Next":
17. You'll see a progress bar flash across the screen that says it is patching the firmware. At this
point, you'll be given the opportunity to tell Redsn0w how you want to customize the firmware
to jail break the device. When asked, ensure that "Cydia" is checked and click "Next".

phone: 614-251-2238 • fax:614-251-4083
18. The next step in the process is to put the phone into DFU mode. The
instructions that will be provided can be interpreted to be rather confusing. This step simply
requires that the device is powered off and the USB cable is connected to the device. In our
experience it doesn't matter if iTunes is running in the background or not. Once you have
powered off the device and are ready to proceed click Next.

phone: 614-251-2238 • fax:614-251-4083
19. When you click Next, just remember the process for entering DFU mode. Don't pay as much
attention to what the instructions are saying, just remember to count (100, 200, 300...etc.) If
you have successfully entered DFU mode, Redsn0w will automatically begin updating the
device with your new firmware, if not, you'll get to try again. You should see a series of events
as following:
Begins loading the new ramdisk

phone: 614-251-2238 • fax:614-251-4083
Uploads the new kernel

phone: 614-251-2238 • fax:614-251-4083
Reboot the device
Almost done!

phone: 614-251-2238 • fax:614-251-4083
20. After the pineapple finishes walking across the screen, the device will reboot into a newly jail
broken system. One way to determine if your device is jail broken (and a very important part to
gaining the remote access we need) is the addition of the Cydia application. Because we jail
broke the phone, we were granted the ability to install applications that have not been signed
and approved by the App Store.
21. Cydia is the application that we'll use to gain remote access into the internal operating system
of the device. Because the device has been jail broken, a user now has the ability to traverse
from the user space into the file system. So, from Cydia, we're going to search for and install
OpenSSH. This is simply a port of the open source OpenSSH that is freely available and
widely used by the *Nix community and Windows admins.

phone: 614-251-2238 • fax:614-251-4083
22. Click on the Cydia icon. As it attempts to initialize, you'll likely be
asked to select a WiFi network. Go ahead and configure those
settings.
23. Cydia will then ask “Who Are You?”. Choose “Developer (No Filters)”. If, after choosing
Developer, you are asked to update Cydia, simply choose to ignore.
24. Use the search function and search for “OpenSSH” and follow the onscreen instructions to
install the application, by clicking “install” then “confirm” in the top right corner.
25. Next, as we noticed through dozens of reboots of our devices, sometimes the WiFi adapter
does not activate itself properly. In order to give ourselves better access to toggle a number of
communication interfaces at the swipe of our finger, we chose to install SBSettings from Cydia
as well.
26. Again, using the search function in Cydia, search for “SBSettings”. As the search begins to
find matches, there are quite a few applications that appear that mention SBSettings. Scroll
down to find the application that is labeled, simply, “SBSettings” from BigBoss & Planet-
iPhones (System). For Mac users, you'll notice that there is a blue icon that resembles the
“Finder” application in OS X.
27. Install SBSettings by clicking on the application, click “install” and then “confirm”. Since
SBSettings is updating the iPhone's SpringBoard, it may take a second to reload the
SpringBoard.
28. SBSettings does not include an icon on the SpringBoard to gain access to the features. In
order to access the new toggle features, simply swipe your finger across the notifications bar at
the top of the display, from left to right. SBSettings' new toggles will drop down from the
notifications bar.

phone: 614-251-2238 • fax:614-251-4083
Test Cases
Once the baseline configuration was achieved and the proper process to
bypass security controls was identified, the GTC defined a series of tests that would be run to test
whether ContactCrypt would adequately encrypt contact data regardless of whether the iPhone
security controls were in place or bypassed and whether ContractCrypt was encrypting data or not.
Changes to the system that would normally occur during the process of potentially recovering data that
should be encrypted were broken down into steps and a backup was performed of the system.
Defining the varying degrees of change that could occur from the baseline configuration of the iPhone
resulted in 6 different test cases that would be run. Each backup instance was then analyzed to
determine whether the target contact data could be identified in the backup's raw files.
Due to research that had already been published on the Internet, it is possible to assume the results of
many of the test cases, based upon what is already known about weaknesses in the iPhone's security
controls. However, for the sake of ensuring a systematic test process the GTC performed and
documented each test case as if the outcome was unknown.
For the purposes of our testing, the GTC determined that it would be necessary to perform tests on
both the 3G and the 3G S devices at the same time. This type of testing allowed the GTC to
determine if there were any differences in the way data was handled between the two devices. The
tests that we chose to perform started with both devices configured according to the baseline
configuration that was detailed above. Various changes were made to each device to move the
configurations from the baseline to various levels of security provided by iPhone, iTunes and
ContactCrypt.
Case 1:
In this test case, we are performing a backup of a newly configured 3G and 3G S device with a new
contact added. There are no security controls applied to the data.
Device Configuration: Baseline

• No passcode set on device
! iPhone 3G:
" Name: Jane Doe
" Phone#: (555) 123-0987
Columbus, Oh 43222

phone: 614-251-2238 • fax:614-251-4083
! iPhone 3G S:
" Name: John Smith
" Phone#: (808) 444-4444
• Encrypt backup setting not checked
Strings to Match: 3G: “Jane”, “Doe” 3G S: “John”, “Smith”
Expected Results: Expected to be able to “grep” through directory containing backup files and
receive results confirming existence of clear text strings matching each instance of the test control
data.
Results: As expected, each of the string matching commands returned results indicating that the
strings existed in some form in either the “.mdinfo” or “.mddata” raw file formats that makeup the
iPhone backup. This indicates that we are able to view the contact data in clear text in both the raw
database file and when browsing the contacts database.
3G:
Grep commands matching strings in the backup files:

phone: 614-251-2238 • fax:614-251-4083
phone: 614-251-2238 • fax:614-251-4083
Image of the database being browsed:
3G S:

phone: 614-251-2238 • fax:614-251-4083
Summary: The above mentioned string matches should be expected as there is no encryption set at
either the iTunes backup encryption configuration or by ContactCrypt. What we see here is the
existence of the strings that make up the name of both contacts is visible in the backup files that are
created when a backup is performed. Additionally, because the backup was not encrypted, we can
open the contact database file with SQLite Database Browser and view the contents.
Note: Referring to the above images that illustrate the string matching commands, notice that there is
also a match to the searched strings that applies to the “DynamicDictionary-4” metadata file. This is
the backup of the keyboard cache file that remembers and stores words that are inputted into the
device via the keyboard. This file match will remain a constant through the remainder of the tests that
are performed and does not indicate a match that applies to the specific results that are received.
Case 2:
In this test case we are performing a backup of a 3G and 3G S device that has had the iPhone
passcode and iTunes backup password set.
Device Configuration: Passcode and iTunes backup encryption enabled

• Passcode enabled on handset
! iPhone 3G:
" Name: Jane Doe
" Phone#: (555) 123-0987

phone: 614-251-2238 • fax:614-251-4083
Columbus, Oh 43222
! iPhone 3G S:
" Name: John Smith
" Phone#: (808) 444-4444
• Encrypt backup setting checked, configured to encrypt data
Expected Results: Would expect that the user is now prompted for a passcode to gain access to the
handset, upon reboot. The backup is adequately encrypted from the iTunes backup encryption setting
and any attempt to match the target control data strings would fail.
Results: As expected, the iTunes encryption adequately encrypted the backup of both devices. We
are unable to match the strings that make up the contact data or browse the database file.
3G:

phone: 614-251-2238 • fax:614-251-4083
3G S:
Summary: Since we have enabled the passcode and encryption in iTunes, when a backup is
performed, the handset refers to the keychain-2.db file to determine whether iTunes encryption has
been enabled. When the device notices that a passcode has been set at the iTunes backup, the
device encrypts the backup files when transferring them to iTunes. These backed up files are no
longer able to be searched or viewed in this state. At this point, it appears that encryption is
functioning properly.

phone: 614-251-2238 • fax:614-251-4083
Case 3:
In this test case we are effectively bypassing the security applied by the
iPhone passcode and the iTunes backup encryption features.
Device Configuration: Passcode and iTunes backup encryption enabled, but bypassed.
! security bypassed by removing the passcode record from the database located at:
" /private/var/Keychains/keychain-2.db
! iPhone 3G:
" Name: Jane Doe
" Phone#: (555) 123-0987
Columbus, Oh 43222
! iPhone 3G S:
" Name: John Smith
" Phone#: (808) 444-4444
! Enryption bypassed by removing the encryption lock record from the database
located at:
Expected Results: Would expect that upon reboot of the device, the user is no longer prompted for
the passcode to gain access to the handset. The backup encryption should be bypassed, however,
iTunes would still indicate that the backup is being encrypted. Since ContactCrypt is still not enabled,
the contact data should be in clear text again and attempts to match strings will succeed for each

phone: 614-251-2238 • fax:614-251-4083
string.
Results: As expected, each of the string matching commands returned results indicating that the
strings existed in some form in the raw file formats that makeup the iPhone backup. At this point, we
see the exact same data output that we saw in case 1 because we removed the record in the
keychain-2.db database file that tells the device to encrypt the files when performing a backup.
3G:

phone: 614-251-2238 • fax:614-251-4083
3G S:

phone: 614-251-2238 • fax:614-251-4083
Summary: Since we were able to bypass the encryption provided by setting a passcode in iTunes, we
are now able to illustrate that, even though the user still believes their backups are being encrypted,
we are able to view the contents of the backup files in clear text.
At this point in our testing, we would normally begin to illustrate how ContactCrypt can be employed to
encrypt sensitive contact information while it resides on the handset and in backup files. However,
through the many tests that were performed during the process of verifying the weaknesses in
iPhone's passcode security and encryption, the GTC stumbled across another concern in the way that
the iPhone handles deleted data.
Specifically, the GTC identified a process in the contact database that forces modifications or deletions
of contacts in the contact database to be tracked. Our analysis indicates that the process of tracking
changes to the database forces the state of the contact prior to modification to be appended to random
parts of the raw database file that are not viewable as a record in an actual database table. Below is
an example.
Deleted Contact:
In this sample test case, we have deleted the contacts on the 3G and 3G S device to illustrate how the
iPhone handles modified contacts in the contacts database.
Device Configuration: Passcode and iTunes bypassed

! iPhone 3G:
" Contact has been deleted from the handset using the "Contacts" application
! iPhone 3G S:
" Contact has been deleted from the handset using the "Contacts" application
! Enryption bypassed by removing the encryption lock record from the database
located at:
Expected Results: Since we deleted the contact, using the “Contacts” application on the handset, we
would expect that the contact string no longer exists on the device.

phone: 614-251-2238 • fax:614-251-4083
Results: An unexpected result is received at this point. When we grep the
backup files for the strings that match the contact that was just deleted, we notice that the contact data
still exists in the contact database. When we browse the database, we see no record in any of the
viewable tables that indicates that the contact should still exist. However, we do notice that one table
in the database contains additional information and that is the “ABPersonChanges” table. This table is
used to track changes to the database by the “type” of change that has occurred. Type0=Add,
Type1=Modification, Type2=Deletion.
3G:

phone: 614-251-2238 • fax:614-251-4083
phone: 614-251-2238 • fax:614-251-4083
3G S:

phone: 614-251-2238 • fax:614-251-4083
Summary: As illustrated above, we have created a situation in both the 3G and the 3G S device
where a contact was deleted from the handset, but remains intact in the raw database file. At this
point, we believe it is due to the fact that the “ABPersonChanges” table is used to track changes to the
database file. However, even though we know changes are being tracked, there is no viewable table
in the database that allows us to view the specifics of those changes.
At this point, we will revert back to the state that both devices existed at the end of case 3 to ensure
that we are working with consistent data when we begin to implement the encryption provided by
ContactCrypt.
Case 4:
In test case 3 we bypassed the protections provided by iPhone and iTunes. Here we will apply
ContactCrypt encryption.
Device Configuration: Passcode and iTunes bypassed, ContactCrypt enabled and encrypting
contacts
! iPhone 3G:
" Name: Jane Doe
" Phone#: (555) 123-0987

phone: 614-251-2238 • fax:614-251-4083
Columbus, Oh 43222
! iPhone 3G S:
" Name: John Smith
" Phone#: (808) 444-4444
• ContactCrypt installed and configured to encrypt contact data
! Enryption bypassed by removing the encryption lock record from the database located at:
Expected Results: Would expect that ContactCrypt is functioning correctly and the contact data is
encrypted at the handset display, when viewing the records in the database tables, as well as in the
raw database file.
Results: The results of this particular test are slightly different than what we would have expected.
When viewing the contacts via the “Contacts” application on the handset, the user is presented with
information that is encrypted and indiscernible. When browsing the tables of the database that
contains the information specific to the contact, we are given the same indiscernible information that
the user sees at the handset. However, when we match the contact strings in the raw database file,
we see remnants of the phone number and email address of the contact remains. As a result of this
test, SMobile has since modified ContactCrypt and version 1.7 now removes this information from the
raw database file.

phone: 614-251-2238 • fax:614-251-4083
3G:

phone: 614-251-2238 • fax:614-251-4083
3G S:

phone: 614-251-2238 • fax:614-251-4083
Summary: When ContactCrypt is employed, we are able to illustrate that the application adequately
encrypts the data as it is displayed to the user and as it rests in the contact database. However, we
still see remnants of the email address and phone number in the raw database file. This is due to the
same process that was mentioned in the previous example that forces modifications to the database to
be tracked and appended to the raw file.
Case 5:
This test case uses ContactCrypt to decrypt the contacts, similar to how the application would normally
be used.
Device Configuration: Passcode and iTunes bypassed, ContactCrypt decrypted

! iPhone 3G:
" Name: Jane Doe
" Phone#: (555) 123-0987

phone: 614-251-2238 • fax:614-251-4083
Columbus, Oh 43222
! iPhone 3G S:
" Name: John Smith
" Phone#: (808) 444-4444
Expected Results: For this test, we chose to decrypt the contact data from ContactCrypt. As such,
we would expect that the contact data is now unencrypted in the database tables as well as in the raw
database file.
Results: In one sense, the results that are received are expected in that the data that was encrypted
now resides in clear text. The unexpected result is that we continue to see the encrypted data,
alongside the unencrypted data.

phone: 614-251-2238 • fax:614-251-4083
3G:

phone: 614-251-2238 • fax:614-251-4083

phone: 614-251-2238 • fax:614-251-4083
3G S:

phone: 614-251-2238 • fax:614-251-4083
Summary: In this test case we are able to highlight the fact that the process the iPhone employs to
track changes to the contact database forces data to remain in the raw database file when it should
have been deleted. In this particular case we are seeing that the encrypted data that resembles
“Smobileencrypted......” remains in the raw database file while it is no longer visible in the database
tables.
Case 6:
In this test case we are going to re-encrypt the data with ContactCrypt to see how the database reacts
to additional changes occurring and whether they will continue to be tracked and appended.
Device Configuration: Passcode and iTunes bypassed, original contact encrypted, new contact
unencrypted.
! iPhone 3G:
" Name: Jane Doe
" Phone#: (555) 123-0987

phone: 614-251-2238 • fax:614-251-4083
Columbus, Oh 43222
! iPhone 3G S:
" Name: John Smith
" Phone#: (808) 444-4444
• ContactCrypt installed and configured to encrypt the contact data.
! Enryption bypassed by removing the encryption lock record from the database located at:
Expected Results: At this point, we are uncertain what results we will receive at this point. Logically,
we would expect that the contact data is encrypted and is unable to be searched or viewed in the
database tables. However, since we began noticing that iPhone forces the database to track changes
to the database and appends the clear text data to the raw file, we are unsure how it will react in this
test case.
Results:

phone: 614-251-2238 • fax:614-251-4083
3G:

phone: 614-251-2238 • fax:614-251-4083
3G S:
Summary: In this test case, we re-encrypted the contact data using ContactCrypt in an effort to see
how the database would react when it attempted to track the changes that occurred. With this
additional step of re-encrypting the contact data, we're able to show how ContactCrypt addresses the
weakness in the way that iPhone has implemented tracking change to the contacts database.
ContactCrypt was specifically designed to address the process that the database uses to track
changes and appending the state of the contact prior to the change to the raw database file.
Specifically, Contact Crypt calls the encrypt function multiple times in order to overwrite the tracking
data that is appended to the database file.

phone: 614-251-2238 • fax:614-251-4083
Synopsis
The GTC originally set out to determine whether or not SMobile's ContactCrypt would provide
adequate encryption for contacts that reside on an iPhone device, even after the iPhone and iTunes
encryption capabilities had been bypassed. The GTC reproduced the process of jail breaking a device
in order to install unsigned applications and gain access to the underlying operating system of the
device. By gaining this type of access, the GTC verified that it is a very simple process to bypass the
security of the iPhone and encryption of a backup performed from iTunes. The GTC was able to show
that by simply removing 2 entries in the keychain-2.db database file, it is possible to trick the device
into thinking that no security has been enabled. Even if a user has configured iTunes to encrypt the
system backup, the device believes it does not have to encrypt the data as it performs the task.
During testing, the GTC was able to show that ContactCrypt succeeds in encrypting sensitive contact
data, even after iPhone's passcode and backup encryption features have been easily bypassed.
During the tests, the GTC identified an additional weakness in the way that the iPhone contact
database handles modifications to the database. Specifically, the iPhone contact database is
configured to track changes to the database. This process of tracking changes forces the database to
append the state of the contact prior to the modification to the raw database file, in what appears to be
a random manner, even though the data is not viewable in the database tables. This means that it
could be possible to retrieve deleted or modified contact data directly from the raw database file when
the user believes the data has been purged. ContactCrypt 1.7 is equipped with a mechanism to purge
this data from the rawe database file
Table of Results
Test Case Configuration Expected Result Result
Case 1 Device Configured Data in clear text in database Contact data was in clear text in raw
according to baseline table and raw file database file
Case 2 iPhone and iTunes No data readable in backup Files were adequately encrypted
protections applied files
Case 3 iPhone and iTunes Data in clear text in database Contact data was in clear text in raw
protections bypassed tables and raw file database file
Case 4 -iPhone and iTunes Data should be encrypted in -Database tables contained only
protections bypassed tables and raw file encrypted data
-ContactCrypt 1.6 -Remnants of clear text data existed in
enabled and encrypting raw file due to iPhone database
data tracking
Case 5 -iPhone and iTunes Data in clear text in database -Contact data was in clear text in raw
protections bypassed table and raw file database file
-ContactCrypt not -Remnants of encrypted data existed in
encrypting data raw file
Case 6 -iPhone and iTunes Data should be encrypted in -Data was encrypted in tables and raw
protections bypassed tables and raw file database file
-ContactCrypt 1.7 -Remnants of clear text data no longer
enabled and encrypting existed
data

phone: 614-251-2238 • fax:614-251-4083

SMobile Global Threat Center - Analysis and Comparison of Iphone 3G, 3GS and - Contact Crypt Encryption Technologies

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SMobile Global Threat Center - Analysis and Comparison of Iphone 3G, 3GS and - Contact Crypt Encryption Technologies

Uploaded by

Copyright:

Available Formats

Analysis and Comparison of iPhone 3G, 3GS and

Troy Vennon, CISSP, CEH, GTC Research Engineer

4320 E. 5th Avenue • Columbus, OH 43219

Executive Summary ..............................................................................................................................4

Test Goals ............................................................................................................................................5

4320 E. 5th Avenue • Columbus, OH 43219

4320 E. 5th Avenue • Columbus, OH 43219

4320 E. 5th Avenue • Columbus, OH 43219

4320 E. 5th Avenue • Columbus, OH 43219

The baseline configuration that was chosen is as follows:

4320 E. 5th Avenue • Columbus, OH 43219

4320 E. 5th Avenue • Columbus, OH 43219

4320 E. 5th Avenue • Columbus, OH 43219

4320 E. 5th Avenue • Columbus, OH 43219

4320 E. 5th Avenue • Columbus, OH 43219

4320 E. 5th Avenue • Columbus, OH 43219

4320 E. 5th Avenue • Columbus, OH 43219

4320 E. 5th Avenue • Columbus, OH 43219

13. We then copied libusb-0.1.4.dylib file to /usr/local/lib

4320 E. 5th Avenue • Columbus, OH 43219

4320 E. 5th Avenue • Columbus, OH 43219

12. Download and unpack Redsn0w from the Dev-Team.

4320 E. 5th Avenue • Columbus, OH 43219

15. Navigate to the correct IPSW file and open it:

4320 E. 5th Avenue • Columbus, OH 43219

4320 E. 5th Avenue • Columbus, OH 43219

4320 E. 5th Avenue • Columbus, OH 43219

Begins loading the new ramdisk

4320 E. 5th Avenue • Columbus, OH 43219

4320 E. 5th Avenue • Columbus, OH 43219

4320 E. 5th Avenue • Columbus, OH 43219

4320 E. 5th Avenue • Columbus, OH 43219

4320 E. 5th Avenue • Columbus, OH 43219

Device Configuration: Baseline

4320 E. 5th Avenue • Columbus, OH 43219

Strings to Match: 3G: “Jane”, “Doe” 3G S: “John”, “Smith”

4320 E. 5th Avenue • Columbus, OH 43219

4320 E. 5th Avenue • Columbus, OH 43219

Device Configuration: Passcode and iTunes backup encryption enabled

4320 E. 5th Avenue • Columbus, OH 43219

4320 E. 5th Avenue • Columbus, OH 43219

Image of the database being browsed:

4320 E. 5th Avenue • Columbus, OH 43219

4320 E. 5th Avenue • Columbus, OH 43219

Image of the database being browsed:

4320 E. 5th Avenue • Columbus, OH 43219

Image of the database being browsed:

4320 E. 5th Avenue • Columbus, OH 43219

Device Configuration: Passcode and iTunes bypassed

4320 E. 5th Avenue • Columbus, OH 43219

Image of the database being browsed:

4320 E. 5th Avenue • Columbus, OH 43219

Image of the database being browsed:

4320 E. 5th Avenue • Columbus, OH 43219

4320 E. 5th Avenue • Columbus, OH 43219

4320 E. 5th Avenue • Columbus, OH 43219

4320 E. 5th Avenue • Columbus, OH 43219

4320 E. 5th Avenue • Columbus, OH 43219

Device Configuration: Passcode and iTunes bypassed, ContactCrypt decrypted

4320 E. 5th Avenue • Columbus, OH 43219

4320 E. 5th Avenue • Columbus, OH 43219

4320 E. 5th Avenue • Columbus, OH 43219