IOS Ing I OS Hacking Guide
iOS%20Hacking%20Guide
iOS%20Hacking%20Guide
iOS%20Hacking%20Guide
iOS%20Hacking%20Guide
iOS%20Hacking%20Guide
User Manual: Pdf
Open the PDF directly: View PDF 
.
Page Count: 139 [warning: Documents this large are best viewed by clicking the View PDF Link!]
- 1. Setting Up iOS Pentest Lab
- 2. Acquiring iOS Binaries
- 3. Generating iOS Binary (.IPA file) from Xcode Source Code:
- 4. Installing iOS Binaries on Physical Devices
- 5. iOS Binary Package Primer
- 5.1 Understanding the iOS Binary Package Structure
- 5.2 Understanding the Supported Architectures for the Provided Application
- 5.3 Understanding the Architecture Available on the Test Devices
- 5.4 Converting Application Binaries from FAT Binary to Specific Architecture Binary
- 5.5 Converting Pre-iOS 9 Executables to an iOS 9 Executable
- 5.6 Converting 32 Bit Applications into 64 Bit Applications in Xcode
- 6. Compiling Customer-Provided Source Code for Pentesting on Latest iOS Using Xcode
- 7. iOS Security Model Primer
- 8. Exploring iOS File System
- 9. Application Data Encryption
- 10. Binary Analysis
- 10.1 Binary Analysis – Check for Exploit Mitigations – Position Independent Executable (PIE & ASLR)
- 10.2 Binary Analysis – Check for Exploit Mitigations – Automatic Reference Counting (ARC)
- 10.3 Binary Analysis – Check for Exploit Mitigations – Stack Protectors
- 10.4 Binary Analysis – List All Libraries Used in the iOS Binary
- 10.5 Simple Reverse Engineering iOS Binaries Using class-dump-z
- 11. Decrypting iOS Applications (AppStore Binaries)
- 12. iOS Application Debugging - Runtime Manipulation
- 13. Reverse Engineering Using Hopper
- 14. Reverse Engineering Using IDA PRO
- 15. MITM on iOS
- 16. Side Channel Leakage
Hacking iOS
Applications
a detailed testing guide
2
www.securityinnovation.com | @SecInnovation | 978.694.1008
Table of Contents
1. Setting Up iOS Pentest Lab ................................................................................................. 5
1.1 Get an iOS Device ................................................................................................................................ 5
1.2 Jailbreaking an iOS Device................................................................................................................... 7
1.3 Installing Required Software and Utilities ........................................................................................ 10
2. Acquiring iOS Binaries ...................................................................................................... 13
3. Generating iOS Binary (.IPA file) from Xcode Source Code: ............................................... 15
3.1 Method I – With A Valid Paid Developer Account. ........................................................................... 15
3.2 Method II - Without a Valid Paid Developer Account ....................................................................... 18
4. Installing iOS Binaries on Physical Devices ........................................................................ 23
4.1 Method I - Using iTunes .................................................................................................................... 23
4.2 Method II - Using Cydia Impactor ..................................................................................................... 27
4.3 Method III - Using iOS App Signer ..................................................................................................... 27
4.4 Method IV - Installing .app file .......................................................................................................... 27
4.5 Method V - Installing Modified Binary .............................................................................................. 28
4.6 Method VI - Using Installipa Utility ................................................................................................... 29
4.7 Method VII - Using iPhone Configuration Utility .............................................................................. 29
4.8 Method VIII - Using iFunBox ............................................................................................................. 29
5. iOS Binary Package Primer ............................................................................................... 30
5.1 Understanding the iOS Binary Package Structure ............................................................................. 30
5.2 Understanding the Supported Architectures for the Provided Application ..................................... 31
5.3 Understanding the Architecture Available on the Test Devices ....................................................... 32
5.4 Converting Application Binaries from FAT Binary to Specific Architecture Binary ........................... 34
5.5 Converting Pre-iOS 9 Executables to an iOS 9 Executable ................................................................ 34
5.6 Converting 32 Bit Applications into 64 Bit Applications in Xcode ..................................................... 35
6. Compiling Customer-Provided Source Code for Pentesting on Latest iOS Using Xcode ...... 36
6.1 Download the Source Code .............................................................................................................. 36
6.2 Launch the Workspace ...................................................................................................................... 36
6.3 Application Configuration ................................................................................................................. 37
7. iOS Security Model Primer ............................................................................................... 41
7.1 Security Features .............................................................................................................................. 41
3
www.securityinnovation.com | @SecInnovation | 978.694.1008
8. Exploring iOS File System ................................................................................................. 42
8.1 Reading Data Using iExplorer ............................................................................................................ 42
8.2 Reading Data Using iFunBox ............................................................................................................. 42
8.3 Reading iOS > 8.3 Application SandBox Data Using Backup Method ............................................... 44
8.3.1 Backing Up the iDevice ............................................................................................................... 44
8.3.2 Using iBackupBot ....................................................................................................................... 45
8.3.3 Using iExplorer ........................................................................................................................... 45
8.4 Reading Application Data Using OpenSSH ........................................................................................ 47
8.5 Reading Application Data Using SSH Over USB ................................................................................. 48
8.6 Reading Application Data on the iOS Device .................................................................................... 49
8.6.1 FileExplorer/iFile ......................................................................................................................... 49
8.6.2 Using Mobile Terminals ............................................................................................................. 50
9. Application Data Encryption ............................................................................................ 50
9.1 Understanding Apple Data Protection API........................................................................................ 50
9.2 Validate the Data Protection Classes Being Used ............................................................................. 51
9.3 Insecure Local Data Storage .............................................................................................................. 52
9.3.1 PropertyList files ......................................................................................................................... 52
9.3.2 NSUserDefaults Class ................................................................................................................. 53
9.3.3 Keychain ..................................................................................................................................... 54
9.3.4 CoreData and SQLite Databases ................................................................................................ 57
9.4 Broken Cryptography ........................................................................................................................ 58
10. Binary Analysis .............................................................................................................. 61
10.1 Binary Analysis – Check for Exploit Mitigations – Position Independent Executable (PIE & ASLR) 61
10.2 Binary Analysis – Check for Exploit Mitigations – Automatic Reference Counting (ARC) .............. 62
10.3 Binary Analysis – Check for Exploit Mitigations – Stack Protectors ................................................ 64
10.4 Binary Analysis – List All Libraries Used in the iOS Binary .............................................................. 65
10.5 Simple Reverse Engineering iOS Binaries Using class-dump-z ........................................................ 68
11. Decrypting iOS Applications (AppStore Binaries) ............................................................ 72
11.1 Manual Method .............................................................................................................................. 72
11.1.1 Using GDB ................................................................................................................................ 72
11.1.2 Using LLDB ............................................................................................................................... 75
11.2 Automated Method ........................................................................................................................ 79
11.2.1 Using dump decrypted ............................................................................................................. 79
11.2.2 Using Clutch ............................................................................................................................. 81
12. iOS Application Debugging - Runtime Manipulation ....................................................... 85
12.1 Cycript on Jailbroken Device ........................................................................................................... 85
12.1.1 Using Cycript to Invoke Internal Methods ................................................................................ 85
12.1.2 Using Cycript to Override Internal Methods ............................................................................ 90
4
www.securityinnovation.com | @SecInnovation | 978.694.1008
12.2 Debugging iOS Applications Using LLDB ......................................................................................... 94
13. Reverse Engineering Using Hopper ............................................................................... 100
14. Reverse Engineering Using IDA PRO ............................................................................. 112
15. MITM on iOS ................................................................................................................ 113
15.1 MITM HTTP Traffic ........................................................................................................................ 114
15.2 MITM SSL/TLS Traffic .................................................................................................................... 116
15.3 MITM non HTTP/SSL/TLS Traffic ................................................................................................... 118
15.4 MITM using VPN ........................................................................................................................... 118
15.5 MITM When iOS Application Accessible Only Via VPN ................................................................. 119
15.6 MITM Bypassing Certificate Pinning ............................................................................................. 120
15.7 MITM by DNS Hijacking ................................................................................................................. 123
15.8 MITM Using Network Gateway ..................................................................................................... 123
15.9 Monitoring iOS FileSystem Activities ............................................................................................ 124
16. Side Channel Leakage................................................................................................... 127
16.1 iOS Default Screen Shot Caching Mechanism ............................................................................... 127
16.2 iOS UIPasteboard Caching ............................................................................................................. 130
16.3 iOS Cookie Storage ........................................................................................................................ 132
16.4 iOS Keyboard Cache Storage ......................................................................................................... 134
16.5 iOS Device Logging ........................................................................................................................ 137
5
www.securityinnovation.com | @SecInnovation | 978.694.1008
1. Setting Up iOS Pentest Lab
Setting up a device is one of the first priorities before starting a scheduled project. If setting up an iOS
device for the first time, it’s likely that something may break (even if the device is one that has been
used previously), so it’s best to test the device a couple of days before the pentest begins to ensure that
the tools in it still work.
1.1 Get an iOS Device
A reliable source for iOS devices is eBay (https://www.ebay.com/). iOS updates and hardware
compatibility can be an issue with Apple products, so always try to buy one of the newer devices. As of
the publication of this guide, the latest iPhone in the market is Apple iPhone 7/7+ and the oldest phone
recommended is the Apple iPhone 5s. An iPad Mini is also a good option. If using a new iOS device is
preferable, but test cases related to network carrier usage aren’t a concern, consider an iPod Touch 6th
generation. They are relatively inexpensive compared other new devices that run the latest iOS releases.
For best results, choose an iOS version greater than 9.0+.
NOTE: When trying to buy a device on eBay use the "Auction" functionality in conjunction with the
"Time: ending soonest" filter.
6
www.securityinnovation.com | @SecInnovation | 978.694.1008
Unlocked devices with at least 32GB memory are preferable as they provide enough space to update the
device and install all tools. Keep in mind that not all iOS versions can be jailbroken so choose a device
that has a public Jailbreak available (refer to the Jailbreak section in this guide for determining if the iOS
version of a device can be jailbroken). If the product description does indicate the iOS version running
7
www.securityinnovation.com | @SecInnovation | 978.694.1008
on the device you are considering, message the seller to confirm the iOS version. To message the seller,
open the product page, go to the end of the description, and click on the link as shown below.
1.2 Jailbreaking an iOS Device
Jailbreaking is the process of gaining root access to the entire device. The best approach for security
testing an application is to examine it on a jailbroken device. Jailbreaking an iOS device allows for:
● Removing the security (and other) limitations on the OS imposed by Apple
● Providing root access to the operating system
● Allowing important testing software tools to be installed
● Providing access to the Objective-C Runtime
iOS applications store data in the application sandbox which is not accessible to the public (but is
available to root and the application itself). Without root access, it is not possible to access the
application sandbox, see what data is being stored, and how is it stored. Also, most the system level files
are owned by root.
The process for jailbreaking various iOS versions can be quite different. Instructions for jailbreaking iOS
devices are found via a simple Google search. Be aware, however, that the Google links may not be
legitimate even if they include names that are the same as genuine jailbreak tools.
Example:
9
www.securityinnovation.com | @SecInnovation | 978.694.1008
• https://www.theiphonewiki.com/wiki/Jailbreak A reliable website to check if Jailbreak for an
iOS device is available and what software to use
• https://www.redmondpie.com/ Includes walkthrough guides with links to the real software
• https://www.reddit.com/r/jailbreak/ Good resource to keep track of updated jailbreak events
around the world (note: use with caution and double check information found on this site)
Use the guide below to jailbreak an iOS 10.2.1 device:
http://www.redmondpie.com/jailbreak-ios-10-for-iphone-ipad-ipod-touch-latest-status-update/
Since this is a legitimate site, these links may be used to download the proper IPA or source code for the
jailbreak application. This site also includes helpful walkthrough guides.
A quick Redmond Pie search will confirm whether there are jailbreak steps for various IOS versions, what
they are, and how to implement them.
NOTE: Never use the "reset all content and settings” option on a jailbroken iOS device as it will ALWAYS
get stuck in a reboot loop. When this happens, the device will need to be restored (to latest version
most likely). If a reboot loop occurs, try the steps mentioned in the links below to fix:
● https://www.qdtricks.net/how-to-fix-iphone-stuck-on-apple-logo/
10
www.securityinnovation.com | @SecInnovation | 978.694.1008
● https://support.apple.com/en-in/HT201263
● http://www.ikream.com/2016/02/how-to-fix-apple-iphone-6-boot-loop-blod-and-other-power-
related-issues-troubleshooting-guide-23912 http://www.iphonehacks.com/2016/08/fix-boot-
loop-jailbreak-ios-9-3-3-iphone-ipad-ipod-touch.html
1.3 Installing Required Software and Utilities
After jailbreaking an iOS device, the following utilities will need to be installed. The majority of the tools,
if not all, can be installed from Cydia. Cydia is a GUI wrapper for apt and, once apt is installed, the rest
can be installed via command line. Cydia is preferred due to the ease of use.
Installation steps for many of these tools are covered elsewhere in this guide.
● OpenSSH
○ A utility to provide users the ability to connect remotely to the iOS FileSystem. OpenSSH
utility is broken in the iOS 10.2 jailbreak released by Luca, however there is a default
DropBear SSH service running on the device to make sure that SSH access isn’t missed.
■ Connect to DropBear using the same steps as mentioned in Method 8 (Reading
Application Data using SSH over USB)
■ IMPORTANT: change the OpenSSH password as soon as OpenSSH is installed.
● BigBoss Recommended Tools
○ A collection of all the recommended hacker CLI tools like wget, tar, vim etc., that do not
come pre-installed with the Cydia repo.
● Cydia substrate
○ An important requirement for many of the tweaks and tools included in this guide.
Required for modifying the software during the runtime on the device without access to
the source code. Tools like Cycript need Cydia Substrate installed.
○ Be wary of installing third-party patches on latest iOS. Patches by Ijapija00 for iOS 10
and 10.1.1 were found to cause devices to break.
● APT 0.6 transitional (apt-get command)
○ Packaging tools for iOS
● Class-dump-z, class-dump, classdump-dyld
○ A reverse engineering tool for iOS that helps dump declarations for the classes,
categories and protocols.
● Cycript
○ A utility that provides a mechanism to modify applications during runtime using a
combination of Objective-C++ and JavaScript syntax.
● IPA installer console
11
www.securityinnovation.com | @SecInnovation | 978.694.1008
○ A command-line utility to install third party applications on a jailbroken iOS device.
● AppSync
○ An iOS tweak that allows for the installation of a modified and fake signed IPA package
on the iOS device.
○ Make sure whether Jailbreak supports this tool or the device might end up in reboot
loop.
■ AppSync is temporarily broken in iOS 10.2 jailbreak so installation is not
recommended.
● Clutch from the iphonecake repo (com.iphonecake.clutch2)
○ A utility that allows users to dump decrypted iOS binaries from a jailbroken device.
● GDB from the repo cydia.radare.org
○ The GNU Debugger for jailbroken IOS on arm64.
● MTerminal
○ An on-device terminal for running commands on the iOS device without the need for a
separate laptop.
● Filemon
○ A real-time iOS Filesystem Monitoring software.
○ Can be downloaded from www.newosxbook.com
● Introspy-iOS
○ A tool to help security researchers profile the iOS applications using a blackbox
approach
○ Can be downloaded from https://github.com/iSECPartners/Introspy-iOS
● SSL Kill Switch 2
○ A tool to help bypass SSL validation and SSL pinning in iOS applications
○ Can be downloaded from https://github.com/nabla-c0d3/ssl-kill-switch2
On a laptop, the software below will need to be installed:
● Hopper
○ An inexpensive, but useful, reverse engineering tool to help disassemble, decompile and
debug iOS applications.
● IDA Pro
○ An expensive, but advanced, tool to aid iOS reverse engineering.
● Burp Suite
○ An interception proxy to perform MITM on iOS applications.
● idb
○ A tool to aid many of the commonly seen iOS application test cases.
● FileDP
○ A tool to help extraction of data protection class from files on iOS device.
○ Can be downloaded from http://www.securitylearn.net/wp-
content/uploads/tools/iOS/FileDP.zip
13
www.securityinnovation.com | @SecInnovation | 978.694.1008
2. Acquiring iOS Binaries
Customers will not always provide an .IPA file for a pentest. Below are some alternative ways to acquire
iOS Binaries for analyzing.
1. Open iTunes App Store on Mac. Download the application from the App Store using Mac Native
application. Select “Apps” and select Application name in the “Library.” Right click and select
“Show in Finder” to get the iPA path. Normally it is /Users/<username>/Music/iTunes/iTunes
Media/Mobile Applications/
2. When the device is synced with iTunes, the .IPA file is sent to the iTunes folder. Pull the .IPA file
from the iTunes folder. (Works on non-jailbroken devices)
3. Use a tool like iMazing. Launch iMazing and connect the iOS device to the laptop. Click on Apps.
Select the application binary to be extracted. Click on Manage Apps at the bottom of the view.
Click on Extract App - then choose a location for the app to be stored on the computer. (Works
well on apps before 9.0. Versions after 9.0 do not work well)
4. Use a tool like iFunBox. Launch iFunBox and connect the iOS device. Click on iFunBox Class tab
and then in the “Connected Devices” section, select the iOS device. Click on User Applications.
Select the application to be extracted. Right click and select “Backup to .ipa Package.” Save the
application to any location. (Works only up to iOS 8.3 or on a jailbroken device)
5. Use iTools. Connect device. Click on Apps. Select application. Right click and select archive to get
the application binary. (Works only up to iOS 8.3 or on a jailbroken device)
6. With access to the source code, it is possible to compile the application binarydirectly. This is
helpful when working with older jailbroken devices as it allows for compile the application to
run on the older device and perform the testing.
7. Download the application from the App Store. The problem with using these binaries for testing
are that they are encrypted for your protection and for digital rights management (DRM).
Techniques on breaking the FairPlayDRM and perform analysis of the encrypted App Store
binaries are discussed later in this guide.
8. Use "transfer purchases from device” option in iTunes.
14
www.securityinnovation.com | @SecInnovation | 978.694.1008
9. Sometimes, the customer will provide you access to the application via TestFlight
(https://developer.apple.com/testflight/) where you can directly log in to the account and
download the IPA file.
If all of the above methods fail, which is unlikely, ask the customer for the .IPA file. Always make sure to
get the mobile provision certificate along with the application binary.
15
www.securityinnovation.com | @SecInnovation | 978.694.1008
3. Generating iOS Binary (.IPA file) from Xcode Source
Code:
Testing an iOS application requires access to the IPA file. Below are two ways of generating IPA files:
3.1 Method I – With A Valid Paid Developer Account.
Make sure iOS device is registered to the Developer account using the steps mentioned
here:https://developer.apple.com/library/content/documentation/IDEs/Conceptual/AppDistributionGui
de/MaintainingProfiles/MaintainingProfiles.html#//apple_ref/doc/uid/TP40012582-CH30-SW10
1. In Xcode log in to the correct developer account. Set the target device to “Generic iOS Device”.
2. Connect the iOS device to a laptop.
3. Go to the Product menu at the top and select Archive. This will archive the current build and
provide a list of Archives in the Organizer.
19
www.securityinnovation.com | @SecInnovation | 978.694.1008
The steps below can be followed to generate an .IPA file when there is not a valid developer account
and a personal team certificate is being used.
Make sure the iOS device is registered to the Developer account using the steps mentioned here:
https://developer.apple.com/library/content/documentation/IDEs/Conceptual/AppDistributionGuide/
MaintainingProfiles/MaintainingProfiles.html#//apple_ref/doc/uid/TP40012582-CH30-SW10
1. In Xcode log in to the correct account. Set the target device to “Generic iOS Device”.
2. Connect the iOS device to a laptop.
3. Go to the Product menu at the top and select Archive. This will archive the current build and
provide a list of Archives in the Organizer.
4. Go to Window -> Organizer. Note that Export will not work since there is no developer account.
5. Right click the archive name and select “Show in Finder.”
21
www.securityinnovation.com | @SecInnovation | 978.694.1008
This generated ipa file can be used for binary analysis but, to install it on a real device, the application
will need to be re-signed.
This can be done using the steps below or by using tools like Cydia Impactor as explained in “section 4”:
1. Check the current signature used to sign the application using the below command:
● codesign -v -d HelloWorldDns.app
2. Create a self-signed signature using the Certificate Assistant in Keychain Access.
○ Choose Keychain Access > Certificate Assistant > Create a Certificate.
○ Enter a name for the certificate.
○ Set Identity Type as “Self Signing Root” and the Certificate Type as “Code Sign”.
22
www.securityinnovation.com | @SecInnovation | 978.694.1008
○ Click on Create.
○ In Keychain Access, search for the created certificate and copy it to a known location on
the laptop.
3. Modify the application signature using codesign.
● codesign -v -fs “<abovecreatedcertificatename>” HelloWorldDns.app/
23
www.securityinnovation.com | @SecInnovation | 978.694.1008
4. Resign the application using ldid on the binary inside the .app folder
○ ldid -s <appname>
5. Choose one of the following steps:
○ Create a new folder named Payload. Move .app folder inside it and compress the
Payload folder as Payload.zip. Rename Payload.zip to <applicationname>.ipa. The
application can then be installed using the steps mentioned in “Module 4” (Using
installipa utility)”.
OR
○ Copy the .app file to the /Applications directory on the device. The application can then
be installed using the steps mentioned in “Module 4” (Using .app).
4. Installing iOS Binaries on Physical Devices
If the client provides iOS binary, below are some of the methods to install them on a physical device.
4.1 Method I - Using iTunes
The steps below can be used to install the application on a device once access is granted to the .IPA or
.app file. Depending upon the circumstances, there be a need for a separate mobile provision file which
is the provisional certificate for ad hoc distribution of the binary file.
1. Launch iTunes
2. Drag drop the .app/.ipa file and the provisional certificate into the iTunes “Apps” tab in Library
(Not in device Apps). If the “Apps” tab is missing, follow the steps below.
a. On Mac: iTunes -> Music Dropdown -> Click Edit Menu -> check if Apps is selected or
not. If not, click on Music Dropdown -> Click Edit Menu -> Enable Apps.
b. On Windows: iTunes -> Edit -> check if Apps is selected or not.
27
www.securityinnovation.com | @SecInnovation | 978.694.1008
4.2 Method II - Using Cydia Impactor
On a non-jailbroken device, Cydia Impactor can be used to install self-signed iOS binaries and install
them to the device.
1. Download the tool from cydiaimpactor.com
2. Download the .deb or .IPA file
3. Install the latest version of iTunes
4. Connect the iOS device to the laptop
5. Launch Impactor and drag drop the iOS binary to the dropdown menu with the device name
6. Log in using an Apple developer account. Select the Agent/iOS Distribution certificate from the
list.
○ A free account can also be used, but the certificate will expire after 7 days. Also, note
that an existing iOS developer certificate will be revoked to make way for this new
device certificate
7. Click OK on the Apple Developer Warning
8. In Settings > General > Profile & Device Management find the profile used to sign the application
and Trust it
4.3 Method III - Using iOS App Signer
On a non-jailbroken device, iOS App Signer can be used to install self-signed iOS binaries and install
them to the device. The binary can be a .IPA file or a .deb file.
This is a relatively straight forward application. The steps can be found here:
● http://dantheman827.github.io/ios-app-signer/
4.4 Method IV - Installing .app file
On a jailbroken device:
1. scp -r HelloWorldApp.app/ root@10.0.1.24:/Applications/
28
www.securityinnovation.com | @SecInnovation | 978.694.1008
2. cd /Applications/HelloWorldApp.app/
3. chmod +x HelloWorldApp
4. uicache
4.5 Method V - Installing Modified Binary
There are a variety of ways to modify/patch a binary (find more information later in this guide). Due to
code signing, these applications won’t work as-is on the iOS device. Follow the steps below to make sure
that the modified binary works.
1. Download the .app file from the device (Use ipa -> decrypted ipa -> app file if using encrypted
binary).
2. Extract the contents of the .app file and look for the application binary in it.
3. Patch the binary file using any technique.
4. Create a self-signed signature using the Certificate Assistant in Keychain Access.
○ Choose Keychain Access > Certificate Assistant > Create a Certificate.
○ Enter a name for the certificate.
○ Set Identity Type as “Self Signing Root” and the Certificate Type as “Code Sign.”
○ Click on Create.
○ In Keychain Access, search for the created certificate and copy it to a known location on
the laptop.
5. Modify the application signature using codesign.
● codesign -v -fs “<abovecreatedcertificatename>” HelloWorldDns.app/
6. Resign the application using ldid on the binary inside the .app folder
○ ldid -s <appname>
7. Copy the modified .app file not yet converted into a valid one to the device using the below
command:
○ scp -r HelloWorldApp.app/ root@10.0.1.24:/Applications/
8. Navigate to the directory and run the below commands to clear the iOS device cache.
○ cd /Applications/HelloWorldApp.app/
○ chmod +x HelloWorldApp
○ uicache
9. The application now appears on the iOS device and can be used without any issues.
29
www.securityinnovation.com | @SecInnovation | 978.694.1008
4.6 Method VI - Using Installipa Utility
On a jailbroken device, Installipa Utility can be used to install self-signed iOS binaries as user “mobile” or
“root.” Installipa can be downloaded from Cydia.
Copy the .IPA file on the device using ssh. With AppSync installed on the device using Cydia, ssh into the
device as user “mobile” and use the below command to install application as user “mobile”:
● installipa HelloWorldApp.ipa
4.7 Method VII - Using iPhone Configuration Utility
To install the binary .IPA file, use the iPhone configuration utility (now renamed as Apple Configurator
and downloadable from Mac AppStore) from here:
● https://www.theiphonewiki.com/wiki/IPhone_Configuration_Utility
AppSync must be installed on an iPhone via Cydia for majority of the .IPA files to be installed on the
device. Appsync Unified is software that allows the installation of fake signed IPA files on the device.
If have AppSync is not installed, add http://cydia.angelxwind.net as a repo & look for AppSync Unified.
Once the tool is installed on a MAC and iPhone, launch the tool on the MAC and add the IPA file to
install to Apple Configurator.
4.8 Method VIII - Using iFunBox
iFunBox can also be used to install an .IPA file. This requires a jailbroken device. Follow the steps
mentioned here:
● http://iosgeeksblog.blogspot.in/2013/01/how-to-install-ipa-files-directly-on-iphone-with-
ifunbox.html
30
www.securityinnovation.com | @SecInnovation | 978.694.1008
5. iOS Binary Package Primer
iOS applications have a binary file format known as IPA which are basically ZIP archives. The .IPA files
include a binary for the ARM architecture and can only be installed on an iOS device. There are no
known ways to install the .IPA file on an iOS simulator.
The .IPA files can be uncompressed using an unzip utility.
5.1 Understanding the iOS Binary Package Structure
iTunesArtwork: A 512 x 512 pixel PNG image. It contains the applications icon that shows up on iTunes
and the App Store app on the iOS device.
iTunesMetadata.plist: A property list xml file that contains developer information like developer name,
ID, copyright information, application name, release information, etc.
31
www.securityinnovation.com | @SecInnovation | 978.694.1008
Payload: The folder that contains the application data.
Application Binary: The executable file containing the application’s code. The name of this file is always
the same as the actual application name without the .app extension. During the pentest, the complete
binary analysis is performed on this application binary.
Mobile Provision File: By default, applications on iOS can only be installed via the AppStore. In special
cases, when the application is to be beta tested, mobile provision certificates are generated and used.
This is the file which is included in the binary when ad hoc distribution of the file is to be done. A
provision profile is a document that lists the digital certificates, the devices, and the IDs of the
applications allowed to operate on a device. This is specifically used for beta stages (usually named
Ad_Hoc_Distribution_Profile.mobileprovision).
For more information, see: http://www.wikihow.com/Install-Ad-hoc-iPhone-OS-Apps
Code Signature: The purpose of the code signature is to make sure that the integrity of the .app file is
maintained from when the application was released. Any kind of editing or deletion (even images having
the same name) will invalidate the signature. Any changes that are made to the .app file require that the
whole package be re-signed.
Bundled Resource Files: Images, Videos, Sounds, HTML, Property list files, etc. which are required by
the application to be installed on the mobile device.
For further information on iOS application package structure, go here
● https://developer.apple.com/library/content/documentation/CoreFoundation/Conceptual/CFB
undles/BundleTypes/BundleTypes.html#//apple_ref/doc/uid/10000123i-CH101-SW1.
5.2 Understanding the Supported Architectures for the Provided
Application
Lipo is a Mac utility that can be used to view all the architectures on which the provided application can
be installed. Lipo might need to be installed on aMAC when running it for the first time. The syntax for
using lipo is shown below:
lipo -info <applicationbinary>
Remember to run lipo on the binary inside the .app folder, not on the IPA file.
33
www.securityinnovation.com | @SecInnovation | 978.694.1008
Source image: http://dorianroy.com/blog/wp-content/uploads/2016/09/iOS_Support_Matrix_v4.2.pdf
A text only version of this support matrix can be found here:
https://www.innerfence.com/howto/apple-ios-devices-dates-versions-instruction-sets
iOS device identifiers can be found here: https://www.theiphonewiki.com/wiki/Models
Maximum iOS version for every iOS device can be found here: http://www.everyi.com/by-
capability/maximum-supported-ios-version-for-ipod-iphone-ipad.html
34
www.securityinnovation.com | @SecInnovation | 978.694.1008
Users with jailbroken access can run uname -a on the device local SSH terminal to check the architecture
that the device supports.
5.4 Converting Application Binaries from FAT Binary to Specific
Architecture Binary
Many of the available tools do not support AArch64 binaries. To analyze these 64bit binaries, strip out a
particular architecture from the fat binary.
Lipo can be used to strip out a particular architecture (64 bit - arm64) from the provided binary. Use the
below command:
lipo -thin armv7 -output <newarmv7binaryname> <binaryname>
The application can then be repackaged into an .IPA file and installed on the device using steps
mentioned in “Module 4 - Method VI” (Using installipa utility).
5.5 Converting Pre-iOS 9 Executables to an iOS 9 Executable
Use this tool to convert pre-iOS 9 executables to an iOS 9 executable:
35
www.securityinnovation.com | @SecInnovation | 978.694.1008
● https://github.com/Starwarsfan2099/iOS-9-Executsable-Converter
5.6 Converting 32 Bit Applications into 64 Bit Applications in Xcode
This method can be used to run 32bit applications on a 64-bit device even with just a 32-bit binary.
With access to the source code, use the steps below:
1. Open the application source code in Xcode
2. Update the project settings to support the latest version of iOS available
3. In Build Settings go to the Architectures section and set Architectures to “Standard architectures
(arm64)”
4. Fix all the compiler warnings that have countered using steps mentioned
here:http://www.chupamobile.com/blog/2015/01/19/convert-app-64-bit-requirement/ and
https://developer.apple.com/library/content/documentation/General/Conceptual/CocoaTouch
64BitGuide/ConvertingYourAppto64-Bit/ConvertingYourAppto64-Bit.html
5. Run the updated project code in a 64-bit iOS simulator to ensure that the application works.
36
www.securityinnovation.com | @SecInnovation | 978.694.1008
6. Compiling Customer-Provided Source Code for
Pentesting on Latest iOS Using Xcode
For code assisted penetration tests, the best approach is to get the source code from the customer and
set it up to run locally. This gives additional debugging capabilities which could prove to be very helpful
in the long run. During the kick-off call with a customer request “build-ready code package along with all
the dependencies.” This will avoid missing library and other dependency issues that may arise if the
development team just copies a folder.
Even with a build-ready source code, there could be issues getting the application up and running.
Assume that a customer has provided the source code for DVIA (Damn Vulnerable iOS application) for a
code assisted penetration test.
The below steps assume Xcode 8.x is being used (the latest Xcode available as of the publication of this
guide). The target device for testing can be iOS 9.x or higher.
6.1 Download the Source Code
Download the source for DVIA from https://github.com/prateek147/DVIA using this command:
git clone https://github.com/prateek147/DVIA.git
6.2 Launch the Workspace
From the downloaded source code open the. xcworkspace file using Xcode. Allow the “Indexing” process
to complete.
37
www.securityinnovation.com | @SecInnovation | 978.694.1008
6.3 Application Configuration
1. Change the deployment target from iOS 8.2 to the device iOS version and click on the yellow
warning sign as shown here:
2. Make sure that the Projects menu has “DamnVulnerableIOSApp” selected and the Target is set
to the physical device that is connected to the laptop.
38
www.securityinnovation.com | @SecInnovation | 978.694.1008
3. Click on General and set the Bundle Identifier to a unique value that is not already registered to
any of the other developer accounts.
4. In the Signing section, enable “Automatically manage signing.”
Enabling the “Automatically manage signing” option resets the signing build settings.
5. Change the Team Name to the Developer account.
6. Repeat the steps 4 and 5 for all the other Targets like WatchKit Extensions, etc.
39
www.securityinnovation.com | @SecInnovation | 978.694.1008
7. If the Apple watch app will not be tested, disable the AppleWatch app group. Navigate to the
Capabilities menu and under the App Groups uncheck “group.dvia.applewatch.” Add a new
group “group.dns.dvia.”
8. Repeat step 7 for all the other Targets like DamnVulnerableiOSApp, etc.
9. In the WatchKit App target, remove WatchKit binaries from General -> Embedded Binaries.
10. In the Watchkit extensions rename com.highaltitudehacks.dvia to com.dns.dvia on the basis of
the group name
11. In the source code look for references of the original bundle identifier
“com.highaltitudehacks.dvia” using the below command
ack -i com.highaltitudehacks.dvia
Make sure that all the references to original “com.highaltitudehacks.dvia” are replaced by the
updated reference with “com.highaltitudehacks.dvia-dns”
In our case use open "DVIA/DVIA/DamnVulnerableIOSApp/DamnVulnerableIOSApp WatchKit
App/Info.plist" and replace “com.highaltitudehacks.dvia” with “com.highaltitudehacks.dvia-
dns”
Open "DVIA/DVIA/DamnVulnerableIOSApp/DamnVulnerableIOSApp WatchKit
Extension/Info.plist" and replace content with group name - com.dns.dvia.watchkitapp
12. In the Build Settings for all targets set enable bitcode = no
13. If there exists hard links in the framework search path, remove them.
14. (If using POD) Do a “pod init”
15. (If using POD) Add all required pods in the Podfile and do a “pod install”
40
www.securityinnovation.com | @SecInnovation | 978.694.1008
16. (If using POD) Remove all the items that were added in Podfile from the general -> linked
frameworks
17. Remove -ObjC from “Other Linker Flags” and add $(inherited)
18. Keep only $(inherited) in all the “search path”
19. Relaunch the workspace in Xcode and not the project file
20. A network connection issue means the application does not have ATS disabled. To disable it set
the code below in DamnVulnerableIOSApp-Info.plist before the last dict.
<key>NSAppTransportSecurity</key>
<dict>
<key>NSAllowsArbitraryLoads</key> <true/>
</dict>
21. Make sure the iOS device is registered to a Developer account using the steps mentioned here:
https://developer.apple.com/library/content/documentation/IDEs/Conceptual/AppDistribution
Guide/MaintainingProfiles/MaintainingProfiles.html#//apple_ref/doc/uid/TP40012582-CH30-
SW10
41
www.securityinnovation.com | @SecInnovation | 978.694.1008
7. iOS Security Model Primer
Below are some important features about the iOS security model.
7.1 Security Features
1. The applications need to be signed with a paid Apple developer certificate.
2. The application binaries are encrypted using FairPlayDRM, similar to what is used in iTunes
Music.
3. The applications are protected by code signing.
4. Patched applications cannot be installed on non-jailbroken devices.
5. Every iOS application runs in its own sandbox. After iOS 8.3+, this sandboxed data cannot be
accessed without jailbreaking the iOS device.
6. No application can access data belonging to another application. Protocol handlers like URL
schemes are the only way for inter-application communication to be used for message passing
between applications. The data can also be stored in keychains.
7. Whenever new files are created on the iOS device, they are assigned data protection classes as
specified by the developers. This helps put access restriction on these files.
8. Applications need to specifically request for permission from the user to access resources like
Camera, Maps, Contacts, etc.
9. iOS devices 5s+ have a secure hardware component called Secure Enclave. It is a highly-
optimized version of ARM’s TrustZone and prevents the main processor from directly accessing
sensitive data. More details about the Secure Enclave can be found here:
○ https://www.blackhat.com/docs/us-16/materials/us-16-Mandt-Demystifying-The-
Secure-Enclave-Processor.pdf
A detailed account of the available iOS security features can be found here:
● https://www.apple.com/business/docs/iOS_Security_Guide.pdf
● https://support.apple.com/en-us/HT207143
● https://www.apple.com/support/security/
42
www.securityinnovation.com | @SecInnovation | 978.694.1008
8. Exploring iOS File System
The iOS File System can be accessed on both jailbroken and non-jailbroken phones. The amount of
access varies. From iOS 8.3+ on the application sandbox can be accessed only on a jailbroken phone. Risk
rating for this vulnerability should explained to customers so they can make an informed decision.
If there is a difficulty reading the file directories (except the Media and app directories on the iOS
device) even after a jailbreak, make sure AFC2 (Apple File Conduit2) is installed from Cydia
(https://cydia.saurik.com/package/com.saurik.afc2d/).
8.1 Reading Data Using iExplorer
iExplorer is one of the simplest tools to view the iOS file structure use even without a jailbroken device.
Before iOS 8.3, the application sandbox and its content were directly visible using iExplorer. As of iOS
8.3+ the application sandbox and root device directories are accessible only after jailbreak.
The iExplorer utility installed can be downloaded here: https://macroplant.com/downloads
Connecting the device to a laptop and launching iExplorer should enable the device file system to be
read.
8.2 Reading Data Using iFunBox
iFunBox is another application that can be used to access the iOS File System. Before iOS 8.3, the
application sandbox and its content was directly visible using iFunBox.
The following directories are accessible via iFunBox.
43
www.securityinnovation.com | @SecInnovation | 978.694.1008
As of iOS 8.3+ the application sandbox and root device directories are accessible only after jailbreak.
iFunBox can also be used to install iOS applications on the device using the “Install App” feature.
Cracked applications or applications without a provision certificate require a jailbroken device.
44
www.securityinnovation.com | @SecInnovation | 978.694.1008
Legitimate applications can be directly installed using the iTunes method mentioned in “4.1 Method 1 -
Using iTunes.”
8.3 Reading iOS > 8.3 Application SandBox Data Using Backup Method
Application sandbox data for iOS > 8.3 is not allowed by Apple, but there is a workaround that can be
used to access this data. Before proceeding, take a backup of the device and the application data.
8.3.1 Backing Up the iDevice
Method 1: iTunes
Backing up the device can be performed using iTunes as shown below. Be sure to rename the device
with a unique name so that it can be identified.
Method 2: LibImobiledevice
Alternatively, the backup can be performed using the idevicebackup2 utility that can be installed from
the libimobiledevice library. Install is as follows - brew install libimobiledevice.
The udid for the utility can be found using “idevice_id -l”
45
www.securityinnovation.com | @SecInnovation | 978.694.1008
It may be necessary to run sudo chmod -R 777 /var/db/lockdown before backing up data.
Use the command below to back up the content:
idevicebackup2 backup --full --source <deviceudid> --udid <deviceudid> ~/Documents
Method 3: 3rd party tools
The backup of the device can also be done using iCloud content. Tools like iLoot
(https://github.com/hackappcom/iloot) can be used. Legitimate login credentials linked with the target
device are needed for the backup to work.
Use the command below to perform an iCloud backup of the content:
python iloot.py iCloudemailaddress iCloudpassword
Once the backup is complete, tools like iExplorer or iBackupBot can be used to view the application
sandbox data.
8.3.2 Using iBackupBot
8.3.3 Using iExplorer
Launch iExplorer and locate the backed-up device names and click on Backup Explorer to view content
as shown below:
48
www.securityinnovation.com | @SecInnovation | 978.694.1008
OpenSSH is one of the first applications to be installed on a jailbroken device for accessing the iOS file
system contents. OpenSSH can be installed from Cydia.
To install OpenSSH, navigate to Cydia, search for OpenSSH, and click on Install.
The default credentials for the SSH server hosted by OpenSSH locally on the device is “alpine” (alpine
was actually the codename for iOS 1.0).
After installing OpenSSH, choose a utility to access the iOS file system. For a GUI of the filesystem, use
FileZilla on Mac or Linux. On windows, use WinSCP to connect to the iOS device.
Make sure to change the OpenSSH password after first login (ssh root@IPAD_IP_ADDRESS) to the SSH
using simple “passwd” via a CLI.
For more information, go to: http://lifehacker.com/5760626/how-to-install-and-set-up-ssh-on-your-
jailbroken-ios-device
Root access allows access to the complete iOS file system. Look over the file system to understand the
various important directories and locations where the application can store data. This location can be
the application sandbox or the iOS OS cache.
NOTE: OpenSSH does not need to be installed on the latest iOS 10.2 jailbreak because the jailbreak
comes with a Dropbear instance out of the box.
8.5 Reading Application Data Using SSH Over USB
Sometimes, especially during conferences- accessing multiple devices directly on a network is not
possible. In these cases, the only way to access a jailbroken device is with USB instead of WiFi.
A tool that works well (even on iOS viz 10.2.1) is:
http://www.hackthatphone.com/5x/open_ssh_usb.shtml.
Install OpenSSH on the device. With the jailbroken iOS device connected to a laptop run the command
below to create an SSH tunnel to access the iOS file system:
python tcprelay.py -t 22:3333 &
49
www.securityinnovation.com | @SecInnovation | 978.694.1008
Install SSH onto the device over USB, port 3333 (ssh root@localhost -p 3333) with credentials as
root/alpine.
8.6 Reading Application Data on the iOS Device
On the first day of testing, it’s typical to go through the application to become familiar with it. It may not
be necessary to connect the iOS device to a laptop. Instead, it may be helpful to have simple tools to
access the files in the application sandbox directly on the jailbroken device.
This section shows some of the tools that can be used.
8.6.1 FileExplorer/iFile
iFile can be installed on a jailbroken or a non-jailbroken device to access local data directly on a device.
Application sandbox cannot be accessed without on a non-jailbroken device.
iFile is normally installed via Cydia, however it can be installed on a non-jailbroken device using Steps
mentioned in “4.2 Method II - Using Cydia Impactor” and the IPA file here:
https://drive.google.com/open?id=0B0b4lUTjHfRKX3VrdW9GV2NUb2c
50
www.securityinnovation.com | @SecInnovation | 978.694.1008
BillyE has a FileExplorer here: https://github.com/Billy-Ellis/iOS-File-Explorer This is a good alternative
for non-jailbroken phones, but note that the accessible directories include only files that are publicly
accessible.
8.6.2 Using Mobile Terminals
Use terminal programs on iOS devices to read data or access the iOS shell. The two terminals that work
best are NewTerm and MobileTerminal.
9. Application Data Encryption
Developers can store sensitive data on an iOS device in a variety of ways. Data can be stored in the
application sandbox or in the iOS Keychain. This section will cover the Apple Data Protection API and the
ways in which data can be stored on an Apple device.
9.1 Understanding Apple Data Protection API
If sensitive data is stored in the application sandbox, data can be secured using Apple’s Data Protection
API. Apple’s Data Protection API (DPAPI) specifies when the decryption key should be available. The
DPAPI uses a combination of the user’s device passcode and the hardware UID for encrypting each file.
Data protection is managed on a file-by-file basis. Every time a file is created on an iOS device, Apple
uses a 256-bit unique file specific key and gives it to the built-in Apple AES hardware engine. The
hardware engine encrypts that file using AES-CBC mode by default. On the A8 devices, the encryption is
performed using AES-XTS.
This file specific key is encrypted with the “class key” depending upon how and when the file should be
accessible and stored in the file’s metadata which, in turn, is encrypted with the file system key. The
class key is a simply random key, and is applied to the files based on the DPAPI level. Refer to page 15 of
http://esec-lab.sogeti.com/static/publications/11-hitbamsterdam-iphonedataprotection.pdf for a
detailed understanding of class key ID.
51
www.securityinnovation.com | @SecInnovation | 978.694.1008
The data protection classes determine when the class is accessible. Below are currently available data
protection classes:
a) Complete Protection (NSFileProtectionComplete):
This is the safest protection level that can be used unless a continuous read/write access to the
file in the background is needed or if the device is locked. The class key is protected with a key
derived from the user passcode and the device UID. If the device is locked, depending upon the
""require password"" setting on the device, the decrypted class key is soon discarded. The data
secured by this attribute is not accessible until the user enters the passcode again or unlocks the
device using Touch ID.
b) Protected Unless Open (NSFileProtectionCompleteUnlessOpen)
This protection level ensures that files that are open can still be accessed, even if the user locks
the device. Other files with the same protection level cannot be accessed unless they were
already opened when the device locked. Files can be created while the device is locked, but
once closed, cannot be opened again until the device is unlocked.
c) Protected Until First User Authentication
(NSFileProtectionCompleteUntilFirstUserAuthentication):
The default protection level for third party applications. This setting is automatically applied if
another protection attribute is not specified. This protection class is similar to Complete
Protection, but the file is available to the users after they first unlock the device. The file is
stored in an encrypted format on a disk and cannot be accessed until after the device has
booted and until the first device unlocks (similar to full-volume encryption on laptops).
d) No Protection (NSFileProtectionNone):
Only the class key with the UID is protected. The file can be read and written to at any time.
For a detailed source code, along with an explanation of these Data Protection classes refer to
“Protection Levels” and “Checking for Protected Data Availability” sections in “iOS Application Security”
by David Thiel (https://www.nostarch.com/iossecurity).
9.2 Validate the Data Protection Classes Being Used
FileDp is used to find the Data protection class of the file (http://www.securitylearn.net/wp-
content/uploads/tools/iOS/FileDP.zip).
Below are the steps to use of FileDp:
52
www.securityinnovation.com | @SecInnovation | 978.694.1008
1. Push FileDp to the iOS device using SSH
2. Make FileDp executable using chmod +x
3. Use the below command to view the Data protection accessibility constant for the file or
directory in the application sandbox:
./FileDP -<f/d> <filepath/directorypath>
9.3 Insecure Local Data Storage
Below are some of the ways data can be stored on a device:
● PropertyList files
● NSUserDefaults class
● Keychain
● CoreData and SQLite databases
9.3.1 PropertyList files
Plist files are one of the more standard ways of storing data on an iOS device in the form of key-value
pair. Plist files are basically just XML files that can be read by Xcode. It is very common during
penetration tests to notice that developers store sensitive data in plist files. Often, the sensitive data
includes credentials, credit card information, API keys, financial information, PII etc. Plist files are not
encrypted by default and should not be used to store sensitive information in clear text.
Application used for Example: Damn Vulnerable IOS Application
Black Box Testing Approach:
1. Launch the application and navigate to the Insecure Data Storage section.
2. Click on Plist.
3. Enter Username and Password.
4. Click on Save in Plist file.
5. Connect the device to the laptop.
6. It is possible to read the content of the iOS sandbox using any of the tools and methods
mentioned in “8 Exploring iOS File System.” This example uses iExplorer.
53
www.securityinnovation.com | @SecInnovation | 978.694.1008
7. Navigate to DVIA in iExplorer. In the Documents folder, right click on the userInfo.plist file and
select “Quick Look.”
Note that credentials are stored in plaintext on the device. During a pentest, make sure that no
sensitive information in stored in plist files without proper encryption.
9.3.2 NSUserDefaults Class
NSUserDefaults class is one more way data on the iOS device persists even after restart. The information
stored NSUserDefaults class is stored in plaintext plist file at: <Application
Directory>/Library/Preferences/<Bundle Identifier>.plist. During pentests, developers may assume that
data will be encrypted and choose to store sensitive data here.
Application used for Example: Damn Vulnerable IOS Application
Black Box Testing Approach:
1. Launch the application and navigate to the Insecure Data Storage section.
2. Click on NSUserDefaults.
54
www.securityinnovation.com | @SecInnovation | 978.694.1008
3. Enter text to be stored in the text field.
4. Click on Save in NSUserDefaults.
5. Connect the device to a laptop.
6. It is possible to read the content of the iOS sandbox using any of the tools and methods
mentioned in “8 exploring iOS File System.” This example uses iExplorer.
7. Navigate to DVIA in iExplorer. In the Library > Preferences folder, right click on the plist file and
select “Quick Look”.
Note that the sensitive data entered is stored in plaintext on the device. During a pentest, make sure
that no sensitive information is stored in plist files without proper encryption
9.3.3 Keychain
iOS Keychain is one of the best locations to store sensitive data like keys and login tokens. Keychain
items can be shared only between applications from the same developer. The keychain items are
encrypted using device hardware identifiers using AES-GCM. Keychain data is protected using a class
structure similar to the one used in the Data Protection API. The classes also have similar behavior to
that of the Data Protection API but use distinct keys and different names. See screenshot below from
the Apple Security Guide: (https://www.apple.com/business/docs/iOS_Security_Guide.pdf)
55
www.securityinnovation.com | @SecInnovation | 978.694.1008
Keychain protection classes determine when the class is accessible. Below are current data protection
classes:
a. Complete Protection (kSecAttrAccessibleWhenUnlocked): The default value for keychain items
added without explicitly setting an accessibility constant. Developers use this protection level
when the application needs access to the keychain data only when the application is in the
foreground. When used, the keychain item data can be accessible only when the device is
unlocked. Keychain data items with this attribute migrate to a new device when using encrypted
backup.
b. Protected Until First User Authentication (kSecAttrAccessibleAfterFirstUnlock): Similar to
Complete Protection but keychain items are available to the users after they first unlock the
device. The keychain items are stored in an encrypted format on a disk and cannot be accessed
until after the device has booted and until the first device unlocks.
c. Protected when passcode enabled (kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly):
Developers use this protection level when the application needs access to the keychain data
only when the application is in the foreground and needs additional security. When used, the
keychain item data can be accessible only when the device is unlocked and a passcode is
enabled on the device. Data cannot be stored on the device keychain when the pin code is not
56
www.securityinnovation.com | @SecInnovation | 978.694.1008
set on the device. The keychain data items with this attribute never migrate to a new device. If
the pin code is disabled, the keychain item data gets deleted.
d. No Protection (kSecAttrAccessibleAlways): When this protection level is used, the data in the
keychain item is always accessible even when the device is locked.
Even though keychain is a secure way of storing data, on a jailbroken device, an attacker can still gain
access to this information. During a pentest, look for sensitive information like passwords stored in the
keychain. Plaintext passwords should never be stored in keychains. As mitigation, set up a session
handling mechanism by means of cookies to avoid the need to store credentials in iOS keychains.
Application used for Example: Damn Vulnerable IOS Application
Black Box Testing Approach:
1. Launch the application and navigate to the Insecure Data Storage section.
2. Click on Keychains.
3. Enter text to be stored in the text field.
4. Click on Save in Keychain.
5. SSH into the iOS device with the credentials root/alpine.
6. Download keychain dumper tool using the command below:
○ wget http://github.com/ptoomey3/Keychain-Dumper/archive/master.zip --no-check-
certificate
7. Unzip the zip folder and navigate to the Keychain-dumper-master folder.
8. Make the keychain_dumper file executable using the below command:
○ chmod +x keychain_dumper
9. Run the command below and note that the information that was supposed to be critical and
sensitive was found stored in plaintext.
○ ./keychain_dumper
If not secured, the keychain data can also be found in the iOS device backup.
For detailed source code along with an explanation on the usage of these Keychain protection schemes,
refer to Chapter 13 : “Using the Keychain” section in “iOS Application Security” by David Thiel
(https://www.nostarch.com/iossecurity).
57
www.securityinnovation.com | @SecInnovation | 978.694.1008
9.3.4 CoreData and SQLite Databases
CoreData is the framework that manages the layer between user interface and the data stored in a
database. The main advantage of CoreData over SQLite databases is the speed and ease of use. Using
CoreData creates sqlite files on the iOS device.
The main difference between using SQLite and CoreData is that the tables are prefixed with Z in
CoreData. The SQLite files are stored in the Documents folder in the application sandbox.
Application used for Example: Damn Vulnerable IOS Application
Black Box Testing Approach:
1. Launch the application and navigate to the Insecure Data Storage section.
2. Click on Core Data.
3. Enter the data in all fields.
4. Click on Save in Core Data.
5. Connect the device to a laptop.
6. It is possible to read the content of the iOS sandbox using any of the tools and methods
mentioned in “8 Exploring iOS File System.” This example uses iExplorer.
7. Navigate to DVIA in iExplorer. In the Documents folder, right click on the CoreData.sqlite file and
export it to laptop.
8. The sqlite file can be read using SQLite Browser (http://sqlitebrowser.org/) or SQLite Manager
(https://addons.mozilla.org/en-US/firefox/addon/sqlite-manager/), or sqlite3 CLI. When using
the sqlite3 on the iOS device use the below commands to view the contents of the sqlite3
database:
○ sqlite3 CoreData.sqlite
○ .tables
○ select * from ZUSER
Note the credentials are being stored in plaintext on the iOS device.
Similar steps are to be used for testing SQLite storage vulnerabilities except the tables won’t have ‘Z’
prefixed.
58
www.securityinnovation.com | @SecInnovation | 978.694.1008
9.4 Broken Cryptography
CommonCrypto is the framework that iOS uses for Cryptographic operations. CCCrypt is the main
encryption and decryption function of the framework for symmetric cryptography.
The method signature for CCCrypt:
CCCrypt(CCOperation op, CCAlgorithm alg, CCOptions options, const void *key, size_t keyLength, const
void *iv, const void *dataIn, size_t dataInLength, void *dataOut, size_t dataOutAvailable, size_t
*dataOutMoved);
The types of arguments passed:
CCCryptorStatus CCCrypt(
CCOperation op, // operation: kCCEncrypt or kCCDecrypt
CCAlgorithm alg, // algorithm: kCCAlgorithmAES128...
CCOptions options, // operation: kCCOptionPKCS7Padding...
const void *key, // key
size_t keyLength, // key length
const void *iv, // initialization vector (optional)
const void *dataIn, // input data
size_t dataInLength, // input data length
void *dataOut, // output data buffer
size_t dataOutAvailable, // output data length available
size_t *dataOutMoved) // real output data length generated
Some of the common test cases to test for when looking at the cryptographic security used in the
application are outlined in the table below.
Test ID
Test Title
Test Description
1
Secure Random Number
Generation
Confirm that secure random generation is performed
by reading the bytes from /dev/random device file. This
can be done by using the SecRandomCopyBytes
59
www.securityinnovation.com | @SecInnovation | 978.694.1008
function. Refer to
https://developer.apple.com/reference/security/16585
65-randomization_services for the randomization
service details on iOS.
2 Random Initialization Vector
Confirm that the IV used in the encryption and hashing
process is generated using a secure pseudorandom
generator (using /dev/random as mentioned in 1) and
is sufficiently random and unique every time.
3
Hardcoded Initialization
Vector
Confirm that the IV in the encryption and hashing
process is not hardcoded in the application source.
4 Key Size
Confirm that the Key size used in the encryption and
hashing process for the cryptosystem is sufficiently
large.
5 Random Salt
Confirm that the salt in the encryption and hashing
process is generated using a secure pseudorandom
(using /dev/random as mentioned in 1) generator and
is sufficiently random and unique every time.
6 Hardcoded Salt
Confirm that the salt in the encryption and hashing
process is not hardcoded in the application source.
7
Strong Cryptographic Seed
for Random Number
Generator
Ensure that the seed value has sufficient entropy and
does not rely on weak sources of entropy. Also, ensure
periodic reseed of the seed value.
9 Cryptographic Strength
Confirm that a cryptographically strong algorithm is
used to encrypt sensitive data.
10 Integrity Checks - Encryption
Confirm that the integrity and authenticity of the
encryption function is maintained by means of
ENCRYPT-then-MAC or authenticated encryption mode.
11 Password Hashing
Confirm that the passwords are stored using a secure
password hashing function.
12 Number of Iterations
Confirm that the number of iterations for the
hashing/encryption function in use is sufficiently large.
13 Integrity Checks - Hashing
Confirm that the integrity/authenticity of hashing
function is maintained by means of ENCRYPT-then-
60
www.securityinnovation.com | @SecInnovation | 978.694.1008
MAC.
14
Weak Cipher Mode
Confirm that the weak ECB cipher mode is not in use.
15 Error Messages
Confirm that error messages do not reveal sensitive
information regarding the encryption system or the
machine that hosts the application.
16 Password-Based Encryption
Confirm that weak and old password based encryptions
algorithms are not currently in use.
17 Custom Cryptography
Confirm that the application does not use a custom
crypto algorithm.
Ensure that the key used in CCCrypt or any of the related functions is never hardcoded. It has to be
generated dynamically on the device and can then be stored in the keychain.
If adding encryption functionality is suggested, RNCryptor (https://github.com/rnapier/RNCryptor) is
your best bet. Essentially, it serves as a wrapper over CommonCrypto and allows encryption using AES
and a user supplied key. In most cases, the key is the one that is generated dynamically on the device
and can then be stored in the keychain.
Use the latest version of RNCryptor as the older versions have known vulnerabilities:
(http://robnapier.net/rncryptor-hmac-vulnerability).
61
www.securityinnovation.com | @SecInnovation | 978.694.1008
10. Binary Analysis
Binary Analysis – Check for Exploit Mitigations – Making Buffer Overflows Difficult to Exploit
Buffer overflows occur when the attacker’s cleverly constructed input overwrites memory resulting in
the execution of the attacker’s code.
There are 3 technologies that are used to prevent buffer overflows
● Address Space Layout Randomization (ASLR)
● Automatic Reference Counting (ARC)
● Stack Protectors
If one or more of these options are not used or if there are improperly handled strings or dangerous
string functions, the application may be vulnerable to a buffer overflow exploit.
Although these don’t directly affect security testing, it is much harder to write buffer overflows for code
compiled with these options.
Test engineers need to know if these technologies are implemented in apps that are being tested. This
section covers the required details to better understand these technologies.
10.1 Binary Analysis – Check for Exploit Mitigations – Position
Independent Executable (PIE & ASLR)
● Memory corruption vulnerabilities typically rely on knowing where in the process address space
to overwrite code or data
○ Code does not care where it is located in memory, so it is moved to a random spot. This
makes Return Oriented Programming (ROP) attacks much more difficult to execute
reliably. (https://access.redhat.com/blogs/766093/posts/1975793)
○ Address Space Layout Randomization (ASLR) randomizes where code and data are
mapped to in the processes address space
● Executable binaries are made entirely from position-independent code
○ ASLR allows for the creation of Position Independent Executables
○ All built-in applications are compiled with PIE by default after iOS 5.0.
62
www.securityinnovation.com | @SecInnovation | 978.694.1008
Application used for Example: LinkedIn from AppStore
White Box Testing Approach:
1. Check if “Generate Position-Dependent Code” is set to “YES” within the XCode project Build
Setting
2. You can also look for -fPIC and -pie flags set for the compiler
Black Box Testing Approach:
1. Use otool to check whether PIE is enabled on the application binary. Run the command below
and look for the PIE flag in the mach header
● otool -hv <appname>
10.2 Binary Analysis – Check for Exploit Mitigations – Automatic
Reference Counting (ARC)
● Automatic Reference Counting (ARC) removes the responsibility of memory management
○ The compiler manages memory, reducing the likelihood of introducing memory
corruption vulnerabilities into the application
● ARC evaluates the lifetime requirements of objects and automatically inserts the appropriate
memory management calls during pre-compilation
○ Developers no longer have to remember when to use retain, release, and auto-release
memory objects
63
www.securityinnovation.com | @SecInnovation | 978.694.1008
○ The compiler determines when an object’s lifetime has expired and will automatically
dealloc objects for the developer
● Safeguards against many memory corruption vulnerabilities and specially object use-after-free
and double-free flaws
Application used for Example: LinkedIn from AppStore
White Box Testing Approach:
1. Check if “Objective-C Automatic Reference Counting” is set to “YES” within the XCode project
Build Setting
2. You can also look for -fobjc-arc or -fno-objc-arc compiler flags being used
Black Box Testing Approach:
1. Use otool to check whether ARC is enabled on the application binary. Run the command below
to look at ARC references:
● otool -Iv <appbinary>| grep objc_
Otool won’t indicate if ARC is in use, but the following symbols will indicate ARC usage:
64
www.securityinnovation.com | @SecInnovation | 978.694.1008
_objc_retain
_objc_release
_objc_storeStrong
_objc_releaseReturnValue
_objc_autoreleaseReturnValue
_objc_retainAutoreleasedReturnValue
10.3 Binary Analysis – Check for Exploit Mitigations – Stack Protectors
● Protection against memory corruption vulnerabilities that attempt to overwrite the stack such
as stack-based buffer overflows
● Achieved by placing a known value or “stack canary” before local variables on the stack to
protect the saved base point, instruction pointer, and saved function arguments
● When the function returns, the canary value is checked to verify that the stack hasn’t been
overwritten
● Stack protection is enabled by default in the latest iOS
Application used for Example: LinkedIn from AppStore
White Box Testing Approach:
● Look for –fstack-protector-all compiler flags being used
Black Box Testing Approach:
● Use otool to check whether stack protectors are enabled on the application binary. Run the
command below and to look at stack references:
○ otool -Iv <appbinary> | grep “stack”
65
www.securityinnovation.com | @SecInnovation | 978.694.1008
The presence of these symbols indicates stack protection
● ___stack_ chk_fail
● ___stack_ chk_guard
10.4 Binary Analysis – List All Libraries Used in the iOS Binary
When performing a penetration test on an iOS application, check the security posture of the application
as well as the libraries used in the application using otool or a more advanced tool named Jtool.
Vulnerabilities libraries in the application could allow for leaks of application information that should not
be available to attackers.
66
www.securityinnovation.com | @SecInnovation | 978.694.1008
Download the latest version of Jtool from http://newosxbook.com/tools/jtool.html.
Application used for Example: Damn Vulnerable iOS Application
White Box Testing Approach:
1. Open the Xcode project and View the “General” project properties.
2. Scroll down to view the “Linked Framework and Libraries” section. This lists the frameworks
used in the application.
Make sure that all the libraries are up to the date with the latest versions. Any publicly known
open vulnerabilities in these libraries leave the application vulnerable.
Application used for Example: LinkedIn Application
Black Box Testing Approach:
Extract the .app file or the .IPA file using the steps mentioned in “2. Acquiring iOS Binaries.” Un-
compress the file and run the command below on the binary file:
68
www.securityinnovation.com | @SecInnovation | 978.694.1008
10.5 Simple Reverse Engineering iOS Binaries Using class-dump-z
When performing a penetration test on an iOS application, it is important to read the code of the
provided application and understand the backend classes and hidden information. This allows for
exploitation of the application to gain access to sensitive information or to redirect the flow of the
application in a malicious manner. Reverse Engineering an iOS application is completely different
compared to an Android apk.
The complete original source code cannot be revived from an existing iOS application. Only declarations
for the classes, categories, and protocols can be decompiled from any given iOS binary. Advance tools
like IDA Pro or Hopper can be used to look at the pseudo code.
Using class-dump-z from cydia.radare.org repository on Cydia as an example, note that the default class
dump utility that is bundled with Cydia does not support 64-bit Mach-O files. The Mac OSX version of
class dump for reverse engineering the application may be used as well.
Application used for Example: Default Stocks application
Below are the steps to perform the de-compilation of the iOS applications using class-dump-z:
1. SSH into iOS device using credentials as root:alpine.
2. Launch the Stocks application on the device and note the application location using the ps -ax |
grep "App" command.
69
www.securityinnovation.com | @SecInnovation | 978.694.1008
As shown in the above diagram, the application is running from location “
/Applications/Stocks.app/Stocks”.
3. Navigate to “/Applications/Stocks.app/” via the shell. Use class-dump-z to reverse engineer this
application. It is a command-line utility for examining the Objective-C runtime information
stored in Mach-O files. It generates declarations for the classes, categories and protocols. Do
this using the command below:
● class-dump-z Stocks > /tmp/Stockreversed.txt.
The class-dump-z -H /var/mobile/<app-binary-to-be-reversed> -o
/var/mobile/<outputdirectory>/ may also be used to get the headers in separate files.
On arm64 devices the following error may occur:
If so, install “pcre” via Cydia to fix.
Note: Even after running the class-dump-z properly, a “null” error as shown in the following
screenshot may occur.
70
www.securityinnovation.com | @SecInnovation | 978.694.1008
If so, install “classdump-dyld” instead of the default class-dump-z (classdump-dyld Stocks >
/tmp/Stockreversed.txt). Another option is to try classdump-dyld -o /tmp/dump Stocks.
4. The screenshot below shows the contents of the file “Stockreversed.txt.” It is readable and
contains valuable information.
71
www.securityinnovation.com | @SecInnovation | 978.694.1008
The declarations of the classes and the protocols allow for debugging the application using GDB.
Alternatively, it is possible to hook on to the functions present in the application via Cycript and
try to change its behavior. This topic will be explained in greater detail later in the guide.
Note: The Mac OSX version of class dump for reverse engineering the application can also be used.
72
www.securityinnovation.com | @SecInnovation | 978.694.1008
11. Decrypting iOS Applications (AppStore Binaries)
Sometimes it is necessary to test the applications that are live in the App Stores. If extracting the .IPA file
from the App Store (using the methods mentioned in section 2, Acquiring iOS Binaries), and trying to
decompile the application by means of tools like class-dump-z fails it’s likely due to Apple’s FairPlay DRM
scheme to protect against piracy.
Apps that are normally not encrypted include:
● Apps installed by default on the iOS device (located in /Applications/)
● Self-distributed apps
● Side-loaded apps
For these apps, there is no need to do anything to decrypt them. Binary analysis can be conducted on
them “as-is.”
11.1 Manual Method
This is the most complicated and the most time-consuming decryption method.
11.1.1 Using GDB
The easiest option is to use a jailbroken device that runs GDB properly without errors. If this is not an
option, consider the suggestions in the next section and view LLDB usage. Use the GDB from
cydia.radare.org repo. If there are issues using GDB, try using lipo.
73
www.securityinnovation.com | @SecInnovation | 978.694.1008
Application used for Example: Facebook application from AppStore
Below are the steps to perform the decryption of the iOS binaries manually:
1. Launch the iOS application on a device and locate the encrypted segment by means of otool
using the following syntax:
○ otool -l LinkedIn | grep LC_ENCRYPTION_INFO -A 4
The cryptid=1 indicates that the application is encrypted.
2. Locate the encrypted segment using the below command:
○ otool -l <app_name> | grep LC_ENCRYPTION_INFO -A 4
The cryptoff field gives the start of the encrypted data (16384 bytes [0x4000] into the file)
The cryptsize field is the size of the encrypted segment (37208064, [0x237C000])
3. The command below gives the vmsize (the complete size of the segment)
○ otool –arch all -Vl <app_name>
74
www.securityinnovation.com | @SecInnovation | 978.694.1008
Calculate the start and end addresses:
Start address = hex(cryptoff) + base address = 0x4000 + 0x4000 = 0x8000
End address = Start address + cryptsize = 0x8000 + 0x237C000 = 0x2384000 (37240832)
Note: Base address is the same as vmsize or it can be found using “info sharedlibrary.”
4. Set a breakpoint using GDB
○ gdb attach <app_name>
5. Dump decrypted segment from memory and save to a file which will be used to patch the
encrypted binary
○ dump binary memory memorydump.bin <start_addr> <end_addr>
Note: START = hex(base)+hex(cryptoff)
END = DEC(START+hex(crypt size))
6. Replace the encrypted data with decrypted data from memory. Copy the decrypted data into
the binary using the below command:
○ dd bs=1 seek=16384 conv=notrunc if=memdump.bin of=Facebook_patched
16384 is the cryptoff value found from the otool query.
The binary will no longer be encrypted on the device.
75
www.securityinnovation.com | @SecInnovation | 978.694.1008
7. To convert the binary into a decrypted binary is to patch cryptid to disable the encryption load
command. Find the cryptid offset using MachOView. Use a hex editor to set cryptid field to 0x0.
8. Check Cryptid to show that encryption load is disabled (=0)
NOTE: The base address can also be found using “info shared library” in GDB (Details mentioned in
Mobile Application Hacker’s Handbook).
11.1.2 Using LLDB
Since Xcode 5, LLDB has been the standard for iOS debugging. It was created in close coordination with
the LLVM compilers to replace GDB.
Application used for Example: LinkedIn application from AppStore
Below are the steps to perform the decryption of the iOS binaries manually:
76
www.securityinnovation.com | @SecInnovation | 978.694.1008
1. Launch the iOS application on the device and locate the encrypted segment by means of otool
using the following syntax:
○ otool -l LinkedIn | grep LC_ENCRYPTION_INFO -A 4
The cryptid=1 indicates that the application is encrypted. The cryptoff field gives the start of the
encrypted data and the cryptsize field is the size of the encrypted segment.
2. In the previous step, note that there are 2 different entries for LC_ENCRYPTION_INFO. This
indicates that the application is a multi-architecture application. Choose and decrypt one
application at a time. Use the command below to view the architecture details:
○ otool -fh LinkedIn
78
www.securityinnovation.com | @SecInnovation | 978.694.1008
3. The specific architecture can be chosen by using the -arch attribute.
○ otool -arch armv7 -l LinkedIn | grep crypt
The cryptid=1 indicates that the application is encrypted. The cryptoff field gives the start of the
encrypted data (16384) and the cryptsize field is the size of the encrypted segment (311296).
4. On an iOS device, start a debug server and hook the LinkedIn application following the steps
mentioned in the section titled “Debugging iOS application using LLDB.”
5. In the lldb interpreter enter the command “image list LinkedIn” to find the offset of the
executable image in the memory.
Note - If the application is compiled with ASLR(PIE) enabled, this image offset will be different
each time the application is launched.
6. Dump decrypted segment from memory and save to a file which will be used to patch the
encrypted binary using the below command:
○ (lldb) memory read --force --outfile LinkedIn_memdump.bin --binary --count <cryptsize>
<image offset>+<cryptoff>
7. Replace the encrypted data with decrypted data from memory. Copy the decrypted data into
the binary using the command below:
○ dd bs=1 seek=<cryptoff> conv=notrunc if=LinkedIn_memdump.bin of=LinkedIn_patched
Where seekvalue= <offset from “otool -fh” + cryptoff from “otool -arch armv7 -l”>
This output binary is no longer encrypted on the device.
79
www.securityinnovation.com | @SecInnovation | 978.694.1008
8. Patch the cryptid to disable the encryption load command. This can be easily modified by means
of MachOView. Download from: https://sourceforge.net/projects/machoview/. Open the
LinkedIn patched binary in MachOView. Find “cryptid”. In the UI, double click on “Data” in the
“Crypt ID” for cryptid=1 and set it to zero. Save the binary.
9. To verify, if the cryptid change is reflected, view the value using the below command:
○ otool -l LinkedIn | grep LC_ENCRYPTION_INFO -A 4
10. Using the decrypted binary, it is possible reverse it via tools like class-dump-z
NOTE: Recommended guides on manually decrypting apps from the AppStore can be found here:
● http://codedigging.com/blog/2016-03-01-decrypting-apps-from-appstore/
● http://codedigging.com/blog/2016-04-27-debugging-ios-binaries-with-lldb/
Or refer to Chapter 6 of “iOS Application Security” book by David Thiel
(https://www.nostarch.com/iossecurity)
11.2 Automated Method
Because the manual method is time consuming, consider one of the following automated tools to help
decrypt iOS binaries for binary analysis.
11.2.1 Using dump decrypted
Dump decrypted works by injecting a constructor via a dynamic linker into the application. This
constructor extracts the decrypted segment in very much the same manner as the manual method.
The link to the tool is here: https://github.com/stefanesser/dumpdecrypted. Use “make” to build the
required .dylib.
Application used for Example: LinkedIn application from AppStore
To use the tool, upload dumpdecrypted.dylib to the iOS Documents folder on
/var/mobile/Containers/Data/Application/<Linkedin-GUID>/Documents device. The Linkedin-GUID can
be found by running ‘ps aux|grep -i <appname>’ and looking at the path in the last column of the
display.
Change working folder to that directory and run the following command in the application sandbox:
80
www.securityinnovation.com | @SecInnovation | 978.694.1008
DYLD_INSERT_LIBRARIES=dumpdecrypted.dylib
/var/mobile/Containers/Bundle/Application/LinkedIn.app/LinkedIn
This generates a decrypted copy of the binary “LinkedIn.decrypted” in the current working directory.
Now, run the command below to make sure that the binary is decrypted by looking at the value of
cryptid.
● otool -l LinkedIn.decrypted | grep LC_ENCRYPTION_INFO -A 4
81
www.securityinnovation.com | @SecInnovation | 978.694.1008
Cryptid of 0 indicates that the application has been decrypted.
11.2.2 Using Clutch
This is the easiest way to decrypt encrypted iOS binaries. Either download the latest version of Clutch
from https://github.com/KJCracks/Clutch/releases and move it the /bin/ folder on the iOS device, or
install Clutch from the cydia repo http://cydia.iphonecake.com.
Application used for Example: LinkedIn application from AppStore
1. Download the LinkedIn application using AppStore on the MacBook. Install and Sync the
LinkedIn application to the iOS device.
82
www.securityinnovation.com | @SecInnovation | 978.694.1008
2. SSH into the iOS device.
3. Use the command below to list all the installed applications on the iOS device
○ Clutch -i
4. Use the command below to decrypt the application.
○ Clutch -d <app-id from previous command>
To decrypt LinkedIn type
● Clutch -d 3
83
www.securityinnovation.com | @SecInnovation | 978.694.1008
The decrypted application can be found in the form of an IPA file on the same device at
/private/var/mobile/Documents/Dumped/
5. Unzip the decrypted application and run the command below to make sure that the binary is
decrypted by looking at the value of cryptid.
○ otool -l LinkedIn | grep LC_ENCRYPTION_INFO -A 4
6. It is now possible to run class-dump-z on the binary.
Note:
● The message, “Segmentation fault: 11” issues with Clutch make use of “ulimit -n 2048”,
indicates that the number of allowed open file handles per process is increased to solve the
issue.
84
www.securityinnovation.com | @SecInnovation | 978.694.1008
● Use “Clutch -f” to clear Clutch cache.
● Sometimes, the class-dump-z gives nil output on the device. If this happens, run Clutch, pull the
ipa file off the device, and run Mac version of class-dump on it.
● The error message, “Killed: 9”, means there is a signing error. ldid -S <binary> should fix it.
85
www.securityinnovation.com | @SecInnovation | 978.694.1008
12. iOS Application Debugging - Runtime Manipulation
Runtime (Dynamic) Analysis is the ability to manipulate apps while they are running. This is done by
enabling debugging and runtime tracing functionality. With the debugging and tracing functionality
enabled, an attacker can manipulate how the application behaves during runtime.
Runtime Manipulation allows the attacker to:
● Execute hidden functionality which should not be accessible
● Discover weak/missing encryption
● Bypass client-side restrictions
● Unlock additional features and premium content
● Dump copyright-protected content
12.1 Cycript on Jailbroken Device
Cycript is the most commonly used tool for performing debugging or runtime manipulation on iOS
applications. A detailed guide on how to use Cycript can be found here:
http://iphonedevwiki.net/index.php/Cycript_Tricks.
12.1.1 Using Cycript to Invoke Internal Methods
Application used for Example: Photo Vault application version 2.5/3.1 from:
● https://drive.google.com/open?id=0B0b4lUTjHfRKWTRlMW1WUy14bkE
● https://drive.google.com/open?id=0B0b4lUTjHfRKN1l3Mk1hSDNBU0k
The steps below are for version 2.5.
1. Launch the Photo Vault application on the device. When prompted for the PIN, set it as “9876.”
SSH into the iOS device, and get the process id of the application using the command “ps aux”.
86
www.securityinnovation.com | @SecInnovation | 978.694.1008
2. When prompted with the Cycript interpreter, use “cycript -p <process-id>” to hook on to the
application.
3. On the lock screen where the application requests the passcode, get the instance of the
application using the command below:
○ [UIApplication sharedApplication]
87
www.securityinnovation.com | @SecInnovation | 978.694.1008
4. Get the delegate class for the application using the command below:
○ [UIApplication sharedApplication].delegate
5. Use the function below to get the methods of the delegate class found in the previous step.
function printMethods(className, isa) {
var count = new new Type("I");
var classObj = (isa != undefined) ? objc_getClass(className).constructor :
objc_getClass(className);
var methods = class_copyMethodList(classObj, count);
88
www.securityinnovation.com | @SecInnovation | 978.694.1008
var methodsArray = [];
for(var i = 0; i < *count; i++) {
var method = methods[i];
methodsArray.push({selector:method_getName(method),
implementation:method_getImplementation(method)});
}
free(methods);
return methodsArray;
}
Then, enter printMethods("AppDelegate") to print the complete list of possible methods for
that screen.
NOTE: This function list can also be found using class-dump-z. Search the class-dump output for
AppDelegate and look for methods below the AppDelegate @interface in the output.
6. From the output of the previous step, note a method called
“pinLockControllerDidFinishUnlocking.” Class-dump-z output will reveal that this function does
not take any arguments and can be called directly.
Use the command below to call the function directly:
● [UIApp.delegate pinLockControllerDidFinishUnlocking]
Note that that the lock screen is bypassed.
A similar approach can be used for bypassing Jailbreak Detection in iOS applications.
It may be difficult to find the details of the current ViewController (current screen) that the user is on.
Use the instructions below to locate the name of the current ViewController on the iOS device.
89
www.securityinnovation.com | @SecInnovation | 978.694.1008
Application used for Example: CycriptDemoDNS application from the below mentioned link:
● https://drive.google.com/open?id=0B0b4lUTjHfRKXy1pU29oZmdSUjg
a. Launch the application and navigate to the appropriate ViewController.
b. Enter the command below for keyWindow (the current window accepting user touch events)
details:
○ [[UIApp keyWindow] recursiveDescription]
c. Search for the value of “UIView” in the output. In this case, it is 0x151099630. Get the value of
the nextResponder using the command below:
○ [#0x151099630 nextResponder]
The name of the current ViewController is indicated.
d. To use this detail to bypass the screen, get the function names using printMethod (detailed in
the previous module) and run the command below to call the login function directly bypassing
any available checks.
90
www.securityinnovation.com | @SecInnovation | 978.694.1008
○ [#0x14fee28e0 doSuccess]
■ Where 0x14fee28e0 is the ViewController address and doSuccess is the function
to be called.
Note that the post login screen is called on the iOS device.
12.1.2 Using Cycript to Override Internal Methods
Application used for Example: CycriptDemoDNS application from the below mentioned link:
● https://drive.google.com/open?id=0B0b4lUTjHfRKXy1pU29oZmdSUjg
1. Launch the CycriptDemoDNS application on the device. SSH into the iOS device, and get the
process id of the application using the command “ps aux”.
2. When prompted with the Cycript interpreter, use “cycript -p <process-id>” to hook on to the
application.
91
www.securityinnovation.com | @SecInnovation | 978.694.1008
3. Find the keyWindow (the current window accepting user touch events) using the command
below:
○ UIApp.keyWindow
4. The below command provides the rootViewController for the keyWindow.
5. Use the function below toobtain the methods of the delegate class found in the previous step.
function printMethods(className, isa) {
var count = new new Type("I");
var classObj = (isa != undefined) ? objc_getClass(className).constructor :
objc_getClass(className);
var methods = class_copyMethodList(classObj, count);
var methodsArray = [];
for(var i = 0; i < *count; i++) {
var method = methods[i];
methodsArray.push({selector:method_getName(method),
implementation:method_getImplementation(method)});
}
92
www.securityinnovation.com | @SecInnovation | 978.694.1008
free(methods);
return methodsArray;
}
Enter printMethods("ViewController") to print the complete list of possible methods for that
screen.
NOTE: This function list can also be found using class-dump-z. Search the class-dump output for
AppDelegate and look for the @interface in it.
NOTE: “UIApp.keyWindow.rootViewController.visibleViewController” can often be used to view
the current view controller.
6. Class-dump reveals that the isLoginSuccessful returns a BOOL value determining whether the
login is supposed to be successful or not.
7. Look at the current value of the isLoginSuccessful function using the following command:
○ UIApp.keyWindow.rootViewController.isLoginSuccessful()
OR
93
www.securityinnovation.com | @SecInnovation | 978.694.1008
○ [UIApp.keyWindow.rootViewController isLoginSuccessful]
Note that the current value is a boolean false.
8. Use the command below to modify the function to always return TRUE irrespective of the values
or the operation performed.
○ ViewController.prototype.isLoginSuccessful = function() { return true;}
9. Click on the “Check Password” button on the device screen and note that the login is successful
even though no password was provided.
A similar approach can be used for bypassing Jailbreak Detection in iOS applications.
94
www.securityinnovation.com | @SecInnovation | 978.694.1008
12.2 Debugging iOS Applications Using LLDB
Since the introduction of iOS 8, GDB may not be a viable solution for debugging as GDB support is only
available to arm7. In these cases, consider Apple’s GDB replacement - LLDB (learn more about LLDB
from Apple WWDC videos). For more information refer to the links below:
● http://asciiwwdc.com/2016/sessions/417
● https://developer.apple.com/videos/play/wwdc2015/402/
● https://developer.apple.com/videos/play/wwdc2013/413/
A similar command set to GDB makes LLDB user friendly for those familiar with GDB. Additionally, LLDB
is reputed to be faster than GDB.
To debug an iOS application, start the debug server utility running on the iOS device. Debug server is the
utility that Xcode uses to debug applications on the iOS device.
By default, debug server can be found on the Mac in the Xcode’s developer disk image. Navigate to the
following
location:/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport/ to
view all the versions of iOS available to you.
Choose the version that is running on the iOS device and mount the related Xcode’s developer disk
image on your Mac to extract the debug server. In this case, the iOS version running is iOS 9.0.*.
Use the command below to mount the developer disk image:
● hdiutil attach
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport/9.0/
DeveloperDiskImage.dmg
95
www.securityinnovation.com | @SecInnovation | 978.694.1008
Copy the debugserver binary to your device at a known location using the command below:
● cp /Volumes/DeveloperDiskImage/usr/bin/debugserver /Users/dns/Desktop/mobile/lldb_guide
By default, this debug server binary can only debug applications that are signed by a specific
provisioning profile. This is due to the lack of entitlement to allow task_for_pid(). To counter this, create
an entitlement file with the task_for_pid flag set to true and use it to sign the debug server binary.
See the content of the entitlement file entitlements.plist below:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/ PropertyList-
1.0.dtd">
<plist version="1.0">
<dict>
<key>com.apple.springboard.debugapplications</key> <true/>
<key>run-unsigned-code</key> <true/>
<key>get-task-allow</key> <true/>
<key>task_for_pid-allow</key> <true/>
96
www.securityinnovation.com | @SecInnovation | 978.694.1008
</dict>
</plist>
Resign the debug server binary using the command below:
● codesign -s - --entitlements entitlements.plist -f debugserver
Copy the signed debug server to the iOS device.
To start debugging, SSH into the iOS device and attach the debug server to the running iOS application
to be debugged.
● debugserver *:6666 -a LinkedIn
97
www.securityinnovation.com | @SecInnovation | 978.694.1008
NOTE: If the tool does not work, strip the fat binary to anything other than arm64 since many of the
tools do not work on arm64.
On the Mac, while connected to the same network as your iOS device, enter the command below to
connect to the debug server instance:
lldb
(lldb) platform select remote-ios
(lldb) process connect connect://<iphone-ip>:6666
The connection may take some time. When connected, the output will look like the screenshot below:
98
www.securityinnovation.com | @SecInnovation | 978.694.1008
You can now debug the application.
Following are some of the basic LLDB commands.
“po” can be used to print the object instances and the delegates via the commands below:
● po [UIApplication sharedApplication]
● po [[UIApplication sharedApplication] delegate]
To dump all symbols from the main executable and any shared libraries use the command “image dump
symtab.”
To dump all sections from the main executable and any shared libraries use the command “image dump
sections.”
To list the main executable and all dependent shared libraries along with their location in memory use
“image list.”.
To dump the information stored for a raw address in the executable or any shared libraries use “image
lookup --address 0x00011e4.”
To look up functions matching a regular expression in a binary use the commands below:
99
www.securityinnovation.com | @SecInnovation | 978.694.1008
image lookup -r -n <FUNC_REGEX> → finds debug symbols
image lookup -r -s <FUNC_REGEX> → finds non-debug symbols
NOTE: Provide a list of binaries as arguments to limit the search.
It is possible to set breakpoints on any of the methods in the iOS application. To do this, locate the
method names. This can be gathered via a class-dump-z of Hopper.
Decompile the binary using Clutch, pull it from the iOS device, and run it on Hopper to view some of the
method names. To pull the binary from the device use:
●scp -P 5555 root@192.168.0.125:"/tmp/LinkedIn_Patches" ./
The breakpoint can be set using a syntax of the form shown below:
breakpoint set --name "-[NSString stringWithFormat:]"
b -[NSString stringWithFormat:]
b -[AppDelegate pinLockControllerDidFinishUnlocking:]
Use “target stop-hook add” to add any command or script to be executed every time a breakpoint is
reached.
Use “process continue” to continue once breakpoint is set.
Refer to http://lldb.llvm.org/lldb-gdb.html for a GDB to LLDB Command Map along with a detailed
command set for LLDB.
NOTE: To use LLDB for a local iOS binary from a Mac, most of the steps remain the same. The only
changes will be in the lldb initialization:
(lldb) platform select remote-ios
(lldb) target create --arch arm64 /Users/dns/Desktop/mobile/lldb_guide/newiOSBinaryWithoutPIE
100
www.securityinnovation.com | @SecInnovation | 978.694.1008
13. Reverse Engineering Using Hopper
Hopper is the best (and often the cheapest) disassembler for reverse engineering iOS applications. The
demo version does allow reverse engineering, but it is time limited and does not allow dumping the
newly modified executables. Hopper can be used for reversing 32bit and 64bit iOS applications.
Application used for Example: JailbreakDetectionDemoDNS application from the below mentioned link:
●https://drive.google.com/open?id=0B0b4lUTjHfRKNTdCVzlvN2ZReVk
Install the JailbreakDetectionDemoDNS application using Xcode on to the iOS device. (Steps will be
different if the .IPA file is used instead of installation via Xcode).
1. Extract the JailbreakDetectionDemoDNS ipa file and open the JailbreakDetectionDemoDNS
binary in Hopper.
When prompted for the loader, select AArch64.
2. Once the automatic analysis is complete, look at the Labels present in the binary. To bypass
Jailbreak detection, search for the keyword “jailbreak.”
101
www.securityinnovation.com | @SecInnovation | 978.694.1008
Lookat “checkJailbreakStatusButton.” See the disassembled code on the right.
3. An interesting feature of Hopper is the option to look at the pseudocode of a function. To look
at the Pseudocode for the application click the button shown in the following screenshot.
104
www.securityinnovation.com | @SecInnovation | 978.694.1008
4. The screenshot below shows how the application looks for the presence of the binaries like
Cydia, bash and sshd on the file system.
If those binaries are present, the application infers that the device is jailbroken and sets the
required flags.
5. In conjunction with Pseudo code, it is always important to look at the Control Flow Graph (CFG)
that Hopper provides, to understand the code and branching. To get the CFG, click on the
button shown in the following screenshot.
107
www.securityinnovation.com | @SecInnovation | 978.694.1008
Note the CFG and the 3 nodes that could affect the branching conditions. To bypass the jailbreak
detection, use any of the methods below:
a) Convert the “tbz” in the CFG to “tbnz”
b) Convert “tbz” to “jmp address”
c) Convert “tbz” to “mov w10, 0x0”
d) NOP out all the operations that set the jailbreak status boolean to true.
7. NOP out all the operations that set the jailbreak status boolean to true. Do this by selecting the
instruction and choosing NOP from Modify -> NOP region.
111
www.securityinnovation.com | @SecInnovation | 978.694.1008
10. After the application is installed launch the application and click the button to check the
jailbreak status. Note that the application now states that the device is not jailbroken -
indicating that the patching was successful.
Note: If you notice that the application crashes when opened, instead of using the .app approach of installing the
application - use the .IPA method and install the IPA on the device using Cydia Impactor
113
www.securityinnovation.com | @SecInnovation | 978.694.1008
15. MITM on iOS
The basic intention of an interception proxy is to determine whether or not a transmission channel is
secure. Unlike traditional web applications, the protocol used by a mobile application can vary.
Additionally, there are additional channels to consider like 4g, GPRS, SMS, USSD, Bluetooth, NFC etc.
during testing.
The simplest setup for intercepting iOS traffic is shown below:
The aim is to make sure that any data that leaves the iOS device should go through the laptop. This
laptop can be used for sniffing the traffic or for data manipulation.
114
www.securityinnovation.com | @SecInnovation | 978.694.1008
15.1 MITM HTTP Traffic
1. Launch Burp Suite and configure it to listen for traffic on all interfaces. Set the port number to a
random number.
2. On the iOS device, go to Settings -> WiFi and connect to the same WiFi network as the laptop.
3. Click on the exclamation mark beside the network connection.
4. Select “Manual” in the HTTP PROXY section.
5. Set the Server to use the laptop as the proxy and the port on which Burp Suite is running.
6. Note that the traffic is intercepted in Burp Suite without any issues.
116
www.securityinnovation.com | @SecInnovation | 978.694.1008
15.2 MITM SSL/TLS Traffic
1. Launch Burp Suite and configure it to listen for traffic on all interfaces. Set the port number to a
random number.
2. On the iOS device, go to Settings -> WiFi and connect to the same WiFi network as the laptop.
3. Click on the exclamation mark beside the network connection.
4. Select “Manual” in the HTTP PROXY section.
5. Set the Server to use your laptop as the proxy and the port on which Burp Suite is running.
6. In the mobile browser navigate to http://burp
7. Click on CA Certificate
8. When prompted, install the PortSwigger CA certificate.
9. Launch the LinkedIn application and note that TLS traffic is intercepted in Burp Suite without any
issues
118
www.securityinnovation.com | @SecInnovation | 978.694.1008
15.3 MITM non HTTP/SSL/TLS Traffic
For non HTTP/(s) traffic use Mallory. You can refer to the guide below on installing and using Mallory:
https://www.pentestpartners.com/blog/advanced-traffic-interception-for-mobile-apps-using-mallory-
and-burp/
15.4 MITM using VPN
in a Mobile Device Management (MDM) environment there is often the challenge of showing a
customer how to intercept traffic without connecting to the WiFi on the iOS device. This can be done by
means of iOS VPN.
1. On the linux laptop that will act as the VPN server, install the pptpd package using the command
below:
○sudo apt-get install pptpd
2. Edit the /etc/pptfpd.conf file to limit the ip range of addresses allocated to VPN clients (here, lan
range is 10.10.1.0/24). Set the VPN client to use 10.10.10.1 as gateway
○localip 10.10.10.1
○remoteip 10.10.10.100-254
3. Edit the /etc/ppp/pptpd-options and configure the DNS server
○ms-dns 8.8.8.8
○ms-dns 8.8.4.4
4. Edit the /etc/ppp/chap-secrets configuration file and set up the credentials
○#client server secret IP addresses
○dinesh pptpd admin *
■ Here admin/admin is the credential and pptpd is the type of service
5. Set up IP forwarding using the command below
○sysctl -w net.ipv4.ip_forward=1
6. Set up IP masquerading using the command below
○iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
7. Restart the VPN service using the command below:
○/etc/init.d/pptpd restart or service pptpd restart
8. On iOS device locate the VPN settings option. Edit the PPTP settings to reflect the information
below:
119
www.securityinnovation.com | @SecInnovation | 978.694.1008
○Description - SomeVPNName
○Server - 10.10.1.106 (VPN server IP)(Remote IP)
○Account - dinesh
○Password - admin
○Encryption Level - Auto
○Send all Traffic - ON
9. Set PROXY to Manual and enter the proxy settings to the machine and port for Burp. Note that
the traffic is now captured in Burp Suite.
15.5 MITM When iOS Application Accessible Only Via VPN
Andreas Kurtz wrote an excellent article nice write-up explaining how to pentest iOS applications when
the application is accessible only via a VPN connection. This can happen when the backend is only
accessible from an internal corporate environment and local LAN access is restricted when a VPN
connection is established. Below are the steps as suggested by Kurtz.
1. Launch Burp Suite on the laptop
2. In Burp Suite, Options -> Connections -> Upstream Proxy Servers, set up Server as 127.0.0.1 and
Port as 7777
3. On the iOS device, install “3proxy” from Cydia
4. SSH into the iOS device and set up the 3proxy config file at /var/root/3proxy.cfg with the below
configuration:
○log /var/root/3proxy.log D
○Logformat “%d-%m-%Y %H:%M:%S %U %C:%c %R:%r %0 %I %T”
○proxy -p7777 -n
5. Launch 3proxy on the iOS device using the below command:
○3proxy /var/root/3proxy.cfg &
6. On the iOS device in the VPN settings set up Proxy settings to Manual and set the configuration
as shown below:
○Server: 127.0.0.1
○Port: 8080 (Burp port number)
NOTE: If due to MDM solution, it is not possible to enter the IP as 127.0.0.1 then edit /etc/hosts on the
iOS device and set an alias for localhost.
7. On the laptop, since connecting to local addresses is blocked when VPN is launched, SSH into
the device using SSH over USB as explained in Module 8 (reading application data using SSH over
USB).
8. On the device, run the command below:
○ssh -p 2222 -L 7777:127.0.0.1:7777 -R 8080:127.0.0.1:8080 root@127.0.0.1
120
www.securityinnovation.com | @SecInnovation | 978.694.1008
Note: Refer to either of the links below for further details:
●https://andreas-kurtz.de/2013/07/ios-proxy-fight/
●http://techie-anand.blogspot.com/2015/02/how-to-intercept-traffic-from-devices.html
15.6 MITM Bypassing Certificate Pinning
Certificate pinning is the way to limit a Mobile application by allowing only the server’s certificate to be
trusted rather than relying on the Mobile's own Trusted Certificate Store.
Rather than relying on the device trusted store, some developers set the application to trust only the
server’s SSL certificate. This way, when connecting to a specific SSL/TLS server, there’s no need for a
third party to share the server’s identity. Additionally, compromises to any of the CA in the device
trusted store is not an issue as the connection no longer relies on it. However, certificate pinning can still
be bypassed by means of tools like SSL Kill Switch or iOS TrustMe.
The latest version of SSL Kill Switch is v2 and can be found here: https://github.com/nabla-c0d3/ssl-kill-
switch2.
Before using SSL Kill Switch 2, install the following dependencies using Cydia:
●Debian Packager
●Cydia Substrate
●PreferenceLoader
Pull the latest installation binary from https://github.com/nabla-c0d3/ssl-kill-switch2/releases into the
device using the command below:
●wget https://github.com/nabla-c0d3/ssl-kill-
switch2/releases/download/0.10/com.nablac0d3.SSLKillSwitch2_0.10.deb --no-check-certificate
Respring the device using the below command:
121
www.securityinnovation.com | @SecInnovation | 978.694.1008
●killall -HUP SpringBoard
In the Settings menu see an additional “SSL Kill Switch 2” option that allows disabling Certificate
Validation and bypassing certificate pinning.
Application used for Example: Twitter application from AppStore
1. Set up the iOS device to proxy the traffic via Burp Suite using the steps mentioned in Module 15
(MITM SSL/TLS Traffic)
2. Launch the Twitter application on the iOS device and try to log in to the application. Note that
you are restricted from logging in to the application and are prompted with a “TLS trust
verification failed” error. This indicates that certificate pinning is enabled in the Twitter
application.
Also note that the requests do not reach Burp Suite.
3. Enable “Disable Certificate Validation” using SSL Kill Switch 2 from the Settings menu.
4. Relaunch the Twitter application and now try to log in to the application. Note that the
certificate pinning was bypassed and the traffic now reaches Burp Suite.
123
www.securityinnovation.com | @SecInnovation | 978.694.1008
It is possible to log in to the application even with Burp Suite intercepting your requests.
A detailed guide for SSL Pinning can be found here:
●http://media.blackhat.com/bh-us-
12/Turbo/Diquet/BH_US_12_Diqut_Osborne_Mobile_Certificate_Pinning_Slides.pdf
Another tool to use for bypassing certificate pinning on iOS is TrustMe, and it can be downloaded here:
●https://github.com/intrepidusgroup/trustme
Instructions for TrustMe are the same as for SSL Kill Switch 2.
Follow the guide below to learn to bypass open ssl pinning on iOS applications:
●https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2015/january/bypassing-
openssl-certificate-pinning-in-ios-apps/
15.7 MITM by DNS Hijacking
Use DNSChef to try to MITM the iOS traffic using DNS Hijacking. Details can be found here:
●http://thesprawl.org/research/ios-data-interception/#dns-hijacking
15.7 MITM Using Network Gateway
The majority of MITM techniques have been covered in this guide. If you still find that the traffic
interception fails, however, follow the guide at the link below to understand how to MITM using
additional IP Table rules:
●http://thesprawl.org/research/ios-data-interception/#capturing-on-the-network-gateway
124
www.securityinnovation.com | @SecInnovation | 978.694.1008
15.8 Monitoring iOS FileSystem Activities
There may be times when an application is writing to files on the file system without your knowledge. In
this situation, a tool like Filemon can be helpful.
Filemon is a utility that tracks the file system activities in IOS. It shows changes made along with the
operations performed in the application’s file system during runtime.
Application used for Example: DemoLogin application from
https://drive.google.com/open?id=0B0b4lUTjHfRKRW9uQ0hKVzM2dEU
For Installing Filemon on a jailbroken device
●SSH to iOS device from a PC
●Download file mon from http://newosxbook.com/tools/filemon.tgz
○wget http://newosxbook.com/tools/filemon.tgz
●Unzip the file filemon.tgz
1. Run Filemon by using option –f [string] which will filter paths containing given string. In this
case, the application GUID is E3A9DACE-C895-4B28-9A38-0312A90EA06F. Run the below
command:
a. ./filemon –c –f E3A9DACE-C895-4B28-9A38-0312A90EA06F”
2. Launch the “DemoLogin” application on the iOS device
3. Navigate to the “Register” screen and fill out the registration form. Then click on “Sign Up”.
127
www.securityinnovation.com | @SecInnovation | 978.694.1008
16. Side Channel Leakage
Side Channel Leakage happens when data is being cached on the device either by the application or by
iOS itself.
16.1 iOS Default Screen Shot Caching Mechanism
The iOS device takes a screenshot of the application's current page when the HOME key is pressed. This
is used to generate an animation when the application shrinks into the background and expands back to
the screen when the user opens the application again. The image is cached in local storage and can be
easily accessed by an attacker who has physical access to the device. If sensitive information such as
payment details, SSN or other PII are being displayed on the page during backgrounding, these can be
stolen by an attacker by retrieving the screenshot file from the device.
Application used for Example: DemoLogin application from
https://drive.google.com/open?id=0B0b4lUTjHfRKRW9uQ0hKVzM2dEU
Black Box Testing Approach:
1. Launch the “DemoLogin” application, register a new user, and log in to the application.
2. Enter the payment information and press the HOME button on the device.
128
www.securityinnovation.com | @SecInnovation | 978.694.1008
3. FTP to the iOS device using a client such as FileZilla to grab the screenshot from the Snapshots
folder. This can be found here:
●/private/var/mobile/Containers/Data/Application/<DemoLogin-
GUID>/Library/Caches/Snapshots/
Since the GUID in the folder name changes with each installation and/or during runtime, it is necessary
to manually look into each folder to find the “DemoLogin” application folder. Some other techniques
that can be employed are:
4. In FileZilla, navigate to “/private/var/mobile/Containers/Data/Application/” and sort by Last
modified. Since DemoLogin was the last used application, the recently modified folder is where
to find the application data such as the Screenshot file.
129
www.securityinnovation.com | @SecInnovation | 978.694.1008
5. Alternatively, SSH into the iOS device, navigate to
“/private/var/mobile/Containers/Data/Application/” and run the command below to list all the
plist files. If plist files were created, we can use the plist filename to identify the application
folder.
○find -type f -name '*plist'| grep 'Preferences' 2>/dev/null
6. Navigate to the location below and download the screenshots.
●/private/var/mobile/Containers/Data/Application/06EBB07F-13E4-41F9-AA51-
E6942EDC8CC2/Library/Caches/Snapshots/shrth.DemoLogin
7. The screenshot contains the payment details that were cached on the device.
130
www.securityinnovation.com | @SecInnovation | 978.694.1008
16.2 iOS UIPasteboard Caching
When text is copied in an iOS device the data goes into the buffer and this data can be used in different
areas of the application as well as by other applications on the device. If any sensitive data is being
copied, this data in pasteboard could be leaked to other third-party applications. A third-party
application running on the device could log the contents of the pasteboard. An example code is shown
below:
●NSLog("@Print the contents of pasteboard: %@", [UIPasteboard generalPasteboard] string);
During a black box pentest look for sensitive fields in the application that allow the copy-paste feature
and see if they are being cached by the iOS.
Application used for Example: DemoLogin application from
https://drive.google.com/open?id=0B0b4lUTjHfRKRW9uQ0hKVzM2dEU
Black Box Testing Approach:
131
www.securityinnovation.com | @SecInnovation | 978.694.1008
1. Open the “DemoLogin” application, register a new user and log in to the application.
2. Enter any data in the text field and copy the content to clipboard.
3. SSH into the iOS device, and get the process id of the application using the command “ps aux”.
4. Use “cycript -p <process-id>” to hook on to the application. You will be prompted with the
Cycript interpreter.
5. Enter the command below to list the contents of the device clipboard. The screenshot below
highlights the copied item.
○[UIPasteboard generalPasteboard]. items
132
www.securityinnovation.com | @SecInnovation | 978.694.1008
16.3 iOS Cookie Storage
The iOS device allows application to store cookies which could be created by the URL loading system or
HTTP request by web view. The cookies are stored in the device storage and an attacker with physical
access to the device can steal the cookies. The cookies are stored in binary format and can be parsed
using the BinaryCookieReader.py script from http://securitylearn.net/wp-
content/uploads/tools/iOS/BinaryCookieReader.py
Application used for Example: DemoLogin application from
https://drive.google.com/open?id=0B0b4lUTjHfRKRW9uQ0hKVzM2dEU
Black Box Testing Approach:
133
www.securityinnovation.com | @SecInnovation | 978.694.1008
1. Launch the “DemoLogin” application and login with valid credentials. Fill in the payment
information and tap the submit button.
2. FTP to the iOS device using a client such as FileZilla to grab the cookie file. This can be found at:
/private/var/mobile/Containers/Data/Application/<DemoLogin-GUID>/Library/Cookies Since
the GUID in the folder name changes with each installation and/or during runtime, we would
have to manually look into each folder to find the “DemoLogin” application folder. Some other
techniques that can be employed are shown below.
3. In Filezilla, navigate to “/private/var/mobile/Containers/Data/Application/” and sort by Last
modified.
4. Navigate to the Cookies folder: /private/var/mobile/Containers/Data/Application/311C2C31-
6E53-47AD-96C2-8231DF83CD96/Library/Cookies
134
www.securityinnovation.com | @SecInnovation | 978.694.1008
5. The Binary cookies can be parsed using the BinaryCookieReader.py script. Run the command as
shown in the screenshot.
Download BinaryCookieReader.py from the below mentioned link:
https://gist.github.com/sh1n0b1/4bb8b737370bfe5f5ab8
The cookies stored by the application contain sensitive information such as the username and password.
16.4 iOS Keyboard Cache Storage
135
www.securityinnovation.com | @SecInnovation | 978.694.1008
The iOS caches data being typed which is utilized by the auto correction feature. The data is cached in
clear text in the order it is typed by the iOS and can be found in the file
“/var/mobile/Library/Keyboard/dynamic-text.dat”.
Application used for Example: DemoLogin application from
https://drive.google.com/open?id=0B0b4lUTjHfRKRW9uQ0hKVzM2dEU
Black Box Testing Approach:
1. Launch the “DemoLogin” application and enter any value in the Username field.
2. SSH in to the iOS device and navigate to the below folder:
○/var/mobile/Library/Keyboard
3. Run strings command on the file “dynamic-text.dat” and note that the typed text is being
cached by the device.
137
www.securityinnovation.com | @SecInnovation | 978.694.1008
16.5 iOS Device Logging
Developers commonly use NSLog for debugging and diagnostic purposes. Sometimes sensitive data is
logged and this data is captured in the device logs. Since error logs are not bound by the application
sandbox they can be read by another application in the device. This could allow a malicious application
running on the device to steal sensitive data logged by the application. It’s possible to read the error logs
created by the application using the Console app or Xcode. During pentest, it is important to navigate
through all areas of the application to see if any sensitive data is being logged.
Application used for Example: DemoLogin application from
https://drive.google.com/open?id=0B0b4lUTjHfRKRW9uQ0hKVzM2dEU
BlackBox Testing approach:
1. Launch the “DemoLogin” application, register a new user and log in to the application.
2. Enter Payment details and tap the Submit button.
