HackTricks
HackTricks
TwitterLinkedinSponsorTwitchYoutube
Search
⌃K
Links

iOS Pentesting

Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:

iOS Pentesting

iOS Basics

Testing Environment

In this page you can find information about the iOS simulator, emulators and jailbreaking:

Initial Analysis

Basic iOS Testing Operations

During the testing several operations are going to be suggested (connect to the device, read/write/upload/download files, use some tools...). Therefore, if you don't know how to perform any of these actions please, start reading the page:
For the following steps the app should be installed in the device and should have already obtained the IPA file of the application. Read the Basic iOS Testing Operations page to learn how to do this.

Basic Static Analysis

It's recommended to use the tool MobSF to perform an automatic Static Analysis to the IPA file.
Identification of protections are present in the binary:
  • PIE (Position Independent Executable): When enabled, the application loads into a random memory address every-time it launches, making it harder to predict its initial memory address.
    otool -hv <app-binary> | grep PIE # It should include the PIE flag
  • Stack Canaries: To validate the integrity of the stack, a ‘canary’ value is placed on the stack before calling a function and is validated again once the function ends.
    otool -I -v <app-binary> | grep stack_chk # It should include the symbols: stack_chk_guard and stack_chk_fail
  • ARC (Automatic Reference Counting): To prevent common memory corruption flaws
    otool -I -v <app-binary> | grep objc_release # It should include the _objc_release symbol
  • Encrypted Binary: The binary should be encrypted
    otool -arch all -Vl <app-binary> | grep -A5 LC_ENCRYPT # The cryptid should be 1
Identification of Sensitive/Insecure Funcions
  • Weak Hashing Algorithms
    # On the iOS device
    otool -Iv <app> | grep -w "_CC_MD5"
    otool -Iv <app> | grep -w "_CC_SHA1"
    ​
    # On linux
    grep -iER "_CC_MD5"
    grep -iER "_CC_SHA1"
  • Insecure Random Functions
    # On the iOS device
    otool -Iv <app> | grep -w "_random"
    otool -Iv <app> | grep -w "_srand"
    otool -Iv <app> | grep -w "_rand"
    ​
    # On linux
    grep -iER "_random"
    grep -iER "_srand"
    grep -iER "_rand"
  • Insecure ‘Malloc’ Function
    # On the iOS device
    otool -Iv <app> | grep -w "_malloc"
    ​
    # On linux
    grep -iER "_malloc"
  • Insecure and Vulnerable Functions
    # On the iOS device
    otool -Iv <app> | grep -w "_gets"
    otool -Iv <app> | grep -w "_memcpy"
    otool -Iv <app> | grep -w "_strncpy"
    otool -Iv <app> | grep -w "_strlen"
    otool -Iv <app> | grep -w "_vsnprintf"
    otool -Iv <app> | grep -w "_sscanf"
    otool -Iv <app> | grep -w "_strtok"
    otool -Iv <app> | grep -w "_alloca"
    otool -Iv <app> | grep -w "_sprintf"
    otool -Iv <app> | grep -w "_printf"
    otool -Iv <app> | grep -w "_vsprintf"
    ​
    # On linux
    grep -R "_gets"
    grep -iER "_memcpy"
    grep -iER "_strncpy"
    grep -iER "_strlen"
    grep -iER "_vsnprintf"
    grep -iER "_sscanf"
    grep -iER "_strtok"
    grep -iER "_alloca"
    grep -iER "_sprintf"
    grep -iER "_printf"
    grep -iER "_vsprintf"

Basic Dynamic Analysis

Check out the dynamic analysis that MobSF perform. You will need to navigate through the different views and interact with them but it will be hooking several classes on doing other things and will prepare a report once you are done.

Listing Installed Apps

When targeting apps that are installed on the device, you'll first have to figure out the correct bundle identifier of the application you want to analyze. You can use frida-ps -Uai to get all apps (-a) currently installed (-i) on the connected USB device (-U):
$ frida-ps -Uai
PID Name Identifier
---- ------------------- -----------------------------------------
6847 Calendar com.apple.mobilecal
6815 Mail com.apple.mobilemail
- App Store com.apple.AppStore
- Apple Store com.apple.store.Jolly
- Calculator com.apple.calculator
- Camera com.apple.camera
- iGoat-Swift OWASP.iGoat-Swift

Basic Enumeration & Hooking

Learn how to enumerate the components of the application and how to easily hook methods and classes with objection:

IPA Structure

.ipa files are zipped packages, so you can change the extension to .zip and decompress them. A complete packaged app ready to be installed is commonly referred to as a Bundle. After decompressing them you should see <NAME>.app , a zipped archive that contains the rest of the resources.
  • Info.plist: A file that contains some of the application specific configurations.
  • _CodeSignature/ contains a plist file with a signature over all files in the bundle.
  • Assets.car: Another zipped archive that contains assets (icons).
  • Frameworks/ contains the app native libraries as .dylib or .framework files.
  • PlugIns/ may contain app extensions as .appex files (not present in the example).
  • ​Core Data: It is used to save your application’s permanent data for offline use, to cache temporary data, and to add undo functionality to your app on a single device. To sync data across multiple devices in a single iCloud account, Core Data automatically mirrors your schema to a CloudKit container.
  • ​PkgInfo: The PkgInfo file is an alternate way to specify the type and creator codes of your application or bundle.
  • en.lproj, fr.proj, Base.lproj: Are the language packs that contains resources for those specific languages, and a default resource in case a language isn' t supported.
There are multiple ways to define the UI in an iOS application: storyboard, nib or xib files.
Info.plist
The information property list or Info.plist is the main source of information for an iOS app. It consists of a structured file containing key-value pairs describing essential configuration information about the app. Actually, all bundled executables (app extensions, frameworks and apps) are expected to have an Info.plist file. You can find all possible keys in the Apple Developer Documentation.
The file might be formatted in XML or binary (bplist). You can convert it to XML format with one simple command:
  • On macOS with plutil, which is a tool that comes natively with macOS 10.2 and above versions (no official online documentation is currently available):
    $ plutil -convert xml1 Info.plist
  • On Linux:
    $ apt install libplist-utils
    $ plistutil -i Info.plist -o Info_xml.plist
Here's a non-exhaustive list of some info and the corresponding keywords that you can easily search for in the Info.plist file by just inspecting the file or by using grep -i <keyword> Info.plist:
  • App permissions Purpose Strings: UsageDescription
  • Custom URL schemes: CFBundleURLTypes
  • Exported/imported custom document types: UTExportedTypeDeclarations / UTImportedTypeDeclarations
  • App Transport Security (ATS) configuration: NSAppTransportSecurity
Please refer to the mentioned chapters to learn more about how to test each of these points.
Data Paths
On iOS, system applications can be found in the /Applications directory while user-installed apps are available under /private/var/containers/. However, finding the right folder just by navigating the file system is not a trivial task as every app gets a random 128-bit UUID (Universal Unique Identifier) assigned for its directory names.
In order to easily obtain the installation directory information for user-installed apps you can use objection's command env will also show you all the directory information of the app:
OWASP.iGoat-Swift on (iPhone: 11.1.2) [usb] # env
​
Name Path
----------------- -------------------------------------------------------------------------------------------
BundlePath /var/containers/Bundle/Application/3ADAF47D-A734-49FA-B274-FBCA66589E67/iGoat-Swift.app
CachesDirectory /var/mobile/Containers/Data/Application/8C8E7EB0-BC9B-435B-8EF8-8F5560EB0693/Library/Caches
DocumentDirectory /var/mobile/Containers/Data/Application/8C8E7EB0-BC9B-435B-8EF8-8F5560EB0693/Documents
LibraryDirectory /var/mobile/Containers/Data/Application/8C8E7EB0-BC9B-435B-8EF8-8F5560EB0693/Library
As you can see, apps have two main locations:
  • The Bundle directory (/var/containers/Bundle/Application/3ADAF47D-A734-49FA-B274-FBCA66589E67/).
  • The Data directory (/var/mobile/Containers/Data/Application/8C8E7EB0-BC9B-435B-8EF8-8F5560EB0693/).
These folders contain information that must be examined closely during application security assessments (for example when analyzing the stored data for sensitive data).
Bundle directory:
  • AppName.app
    • This is the Application Bundle as seen before in the IPA, it contains essential application data, static content as well as the application's compiled binary.
    • This directory is visible to users, but users can't write to it.
    • Content in this directory is not backed up.
    • The contents of this folder are used to validate the code signature.
Data directory:
  • Documents/
    • Contains all the user-generated data. The application end user initiates the creation of this data.
    • Visible to users and users can write to it.
    • Content in this directory is backed up.
    • The app can disable paths by setting NSURLIsExcludedFromBackupKey.
  • Library/
    • Contains all files that aren't user-specific, such as caches, preferences, cookies, and property list (plist) configuration files.
    • iOS apps usually use the Application Support and Caches subdirectories, but the app can create custom subdirectories.
  • Library/Caches/
    • Contains semi-persistent cached files.
    • Invisible to users and users can't write to it.
    • Content in this directory is not backed up.
    • The OS may delete this directory's files automatically when the app is not running and storage space is running low.
  • Library/Application Support/
    • Contains persistent files necessary for running the app.
    • Invisible to users and users can't write to it.
    • Content in this directory is backed up.
    • The app can disable paths by setting NSURLIsExcludedFromBackupKey.
  • Library/Preferences/
    • Used for storing properties that can persist even after an application is restarted.
    • Information is saved, unencrypted, inside the application sandbox in a plist file called [BUNDLE_ID].plist.
    • All the key/value pairs stored using NSUserDefaults can be found in this file.
  • tmp/
    • Use this directory to write temporary files that do not need to persist between app launches.
    • Contains non-persistent cached files.
    • Invisible to users.
    • Content in this directory is not backed up.
    • The OS may delete this directory's files automatically when the app is not running and storage space is running low.
Let's take a closer look at iGoat-Swift's Application Bundle (.app) directory inside the Bundle directory (/var/containers/Bundle/Application/3ADAF47D-A734-49FA-B274-FBCA66589E67/iGoat-Swift.app):
OWASP.iGoat-Swift on (iPhone: 11.1.2) [usb] # ls
NSFileType Perms NSFileProtection ... Name
------------ ------- ------------------ ... --------------------------------------
Regular 420 None ... rutger.html
Regular 420 None ... mansi.html
Regular 420 None ... splash.html
Regular 420 None ... about.html
​
Regular 420 None ... LICENSE.txt
Regular 420 None ... Sentinel.txt
Regular 420 None ... README.txt

Binary Reversing

Inside the <application-name>.app folder you will find a binary file called <application-name>. This is the file that will be executed. You can perform a basic inspection of the binary with the tool otool:
otool -Vh DVIA-v2 #Check some compilation attributes
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
MH_MAGIC_64 ARM64 ALL 0x00 EXECUTE 65 7112 NOUNDEFS DYLDLINK TWOLEVEL WEAK_DEFINES BINDS_TO_WEAK PIE
​
otool -L DVIA-v2 #Get third party libraries
DVIA-v2:
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.1)
/usr/lib/libsqlite3.dylib (compatibility version 9.0.0, current version 274.6.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
@rpath/Bolts.framework/Bolts (compatibility version 1.0.0, current version 1.0.0)
[...]
Check if the app is encrypted
See if there is any output for:
otool -l <app-binary> | grep -A 4 LC_ENCRYPTION_INFO
Disassembling the binary
Disassemble the text section:
otool -tV DVIA-v2
DVIA-v2:
(__TEXT,__text) section
+[DDLog initialize]:
0000000100004ab8 sub sp, sp, #0x60
0000000100004abc stp x29, x30, [sp, #0x50] ; Latency: 6
0000000100004ac0 add x29, sp, #0x50
0000000100004ac4 sub x8, x29, #0x10
0000000100004ac8 mov x9, #0x0
0000000100004acc adrp x10, 1098 ; 0x10044e000
0000000100004ad0 add x10, x10, #0x268
To print the Objective-C segment of the sample application one can use:
otool -oV DVIA-v2
DVIA-v2:
Contents of (__DATA,__objc_classlist) section
00000001003dd5b8 0x1004423d0 _OBJC_CLASS_$_DDLog
isa 0x1004423a8 _OBJC_METACLASS_$_DDLog
superclass 0x0 _OBJC_CLASS_$_NSObject
cache 0x0 __objc_empty_cache
vtable 0x0
data 0x1003de748
flags 0x80
instanceStart 8
In order to obtain a more compact Objective-C code you can use class-dump:
class-dump some-app
//
// Generated by class-dump 3.5 (64 bit).
//
// class-dump is Copyright (C) 1997-1998, 2000-2001, 2004-2013 by Steve Nygard.
//
​
#pragma mark Named Structures
​
struct CGPoint {
double _field1;
double _field2;
};
​
struct CGRect {
struct CGPoint _field1;
struct CGSize _field2;
};
​
struct CGSize {
double _field1;
double _field2;
};
However, the best options to disassemble the binary are: Hopper and IDA.
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:

Data Storage

To learn about how iOS stores data in the device read this page:
The following places to store information should be checked right after installing the application, after checking all the functionalities of the application and even after login out from one user and login into a different one. The goal is to find unprotected sensitive information of the application (passwords, tokens), of the current user and of previously logged users.

Plist

plist files are structured XML files that contains key-value pairs. It's a way to store persistent data, so sometimes you may find sensitive information in these files. It's recommended to check these files after installing the app and after using intensively it to see if new data is written.
The most common way to persist data in plist files is through the usage of NSUserDefaults. This plist file is saved inside the app sandbox in Library/Preferences/<appBundleID>.plist
The NSUserDefaults class provides a programmatic interface for interacting with the default system. The default system allows an application to customize its behaviour according to user preferences. Data saved by NSUserDefaults can be viewed in the application bundle. This class stores data in a plist file, but it's meant to be used with small amounts of data.
This data cannot be longer accessed directly via a trusted computer, but can be accessed performing a backup.
You can dump the information saved using NSUserDefaults using objection's ios nsuserdefaults get
To find all the plist of used by the application you can access to /private/var/mobile/Containers/Data/Application/{APPID} and run:
find ./ -name "*.plist"
The file might be formatted in XML or binary (bplist). You can convert it to XML format with one simple command:
  • On macOS with plutil, which is a tool that comes natively with macOS 10.2 and above versions (no official online documentation is currently available):
    $ plutil -convert xml1 Info.plist
  • On Linux:
    $ apt install libplist-utils
    $ plistutil -i Info.plist -o Info_xml.plist
  • On an objection's session:
    ios plist cat /private/var/mobile/Containers/Data/Application/AF1F534B-1B8F-0825-ACB21-C0301AB7E56D/Library/Preferences/com.some.package.app.plist

Core Data

​Core Data is a framework for managing the model layer of objects in your application. Core Data can use SQLite as its persistent store, but the framework itself is not a database. CoreData does not encrypt it's data by default. However, an additional encryption layer can be added to CoreData. See the GitHub Repo for more details.
You can find the SQLite Core Data information of an application in the path /private/var/mobile/Containers/Data/Application/{APPID}/Library/Application Support
If you can open the SQLite and access sensitive information, then you found a miss-configuration.
Code from iGoat
-(void)storeDetails {
AppDelegate * appDelegate = (AppDelegate *)(UIApplication.sharedApplication.delegate);
​
NSManagedObjectContext *context =[appDelegate managedObjectContext];
​
User *user = [self fetchUser];
if (user) {
return;
}
user = [NSEntityDescription insertNewObjectForEntityForName:@"User"
inManagedObjectContext:context];
user.email = CoreDataEmail;
user.password = CoreDataPassword;
NSError *error;
if (![context save:&error]) {
NSLog(@"Error in saving data: %@", [error localizedDescription]);
​
}else{
NSLog(@"data stored in core data");
}
}

YapDatabase

​YapDatabase is a key/value store built on top of SQLite. As the Yap databases are sqlite databases you can find them using the purposed commend in the previous section.

Other SQLite Databases

It's common for applications to create their own sqlite database. They may be storing sensitive data on them and leaving it unencrypted. Therefore, it's always interesting to check every database inside the applications directory. Therefore go to the application directory where the data is saved (/private/var/mobile/Containers/Data/Application/{APPID})
find ./ -name "*.sqlite" -or -name "*.db"

Firebase Real-Time Databases

It can be leveraged by application developers to store and sync data with a NoSQL cloud-hosted database. The data is stored as JSON and is synchronized in real-time to every connected client and also remains available even when the application goes offline.
You can find how to check for misconfigured Firebase databases here:

Realm databases

​Realm Objective-C and Realm Swift aren't supplied by Apple, but they are still worth noting. They store everything unencrypted, unless the configuration has encryption enabled.
You can find this databases in /private/var/mobile/Containers/Data/Application/{APPID}
iPhone:/private/var/mobile/Containers/Data/Application/A079DF84-726C-4AEA-A194-805B97B3684A/Documents root# ls
default.realm default.realm.lock default.realm.management/ default.realm.note|
​
$ find ./ -name "*.realm*"
You can use the tool Realm Studio to open this database files.
The following example demonstrates how to use encryption with a Realm database:
// Open the encrypted Realm file where getKey() is a method to obtain a key from the Keychain or a server
let config = Realm.Configuration(encryptionKey: getKey())
do {
let realm = try Realm(configuration: config)
// Use the Realm as normal
} catch let error as NSError {
// If the encryption key is wrong, `error` will say that it's an invalid database
fatalError("Error opening realm: \(error)")
}

Couchbase Lite Databases

​Couchbase Lite is a lightweight, embedded, document-oriented (NoSQL) database engine that can be synced. It compiles natively for iOS and macOS.
Check for possible couchbase databases in /private/var/mobile/Containers/Data/Application/{APPID}/Library/Application Support/

Cookies

iOS store the cookies of the apps in the Library/Cookies/cookies.binarycookies inside each apps folder. However, developers sometimes decide to save them in the keychain as the mentioned cookie file can be accessed in backups.
To inspect the cookies file you can use this python script or use** objection's ios cookies get. You can also use objection to convert these files to a JSON** format and inspect the data.
...itudehacks.DVIAswiftv2.develop on (iPhone: 13.2.3) [usb] # ios cookies get --json
[
{
"domain": "highaltitudehacks.com",
"expiresDate": "2051-09-15 07:46:43 +0000",
"isHTTPOnly": "false",
"isSecure": "false",
"name": "username",
"path": "/",
"value": "admin123",
"version": "0"
}
]

Cache

By default NSURLSession stores data, such as HTTP requests and responses in the Cache.db database. This database can contain sensitive data, if tokens, usernames or any other sensitive information has been cached. To find the cached information open the data directory of the app (/var/mobile/Containers/Data/Application/<UUID>) and go to /Library/Caches/<Bundle Identifier>. The WebKit cache is also being stored in the Cache.db file. Objection can open and interact with the database with the command sqlite connect Cache.db, as it is a normal SQLite database.
It is recommended to disable Caching this data, as it may contain sensitive information in the request or response. The following list below shows different ways of achieving this:
  1. 1.
    It is recommended to remove Cached responses after logout. This can be done with the provided method by Apple called removeAllCachedResponses You can call this method as follows:
    URLCache.shared.removeAllCachedResponses()
    This method will remove all cached requests and responses from Cache.db file.
  2. 2.
    If you don't need to use the advantage of cookies it would be recommended to just use the .ephemeral configuration property of URLSession, which will disable saving cookies and Caches.
    ​Apple documentation:
    An ephemeral session configuration object is similar to a default session configuration (see default), except that the corresponding session object doesn’t store caches, credential stores, or any session-related data to disk. Instead, session-related data is stored in RAM. The only time an ephemeral session writes data to disk is when you tell it to write the contents of a URL to a file.
  3. 3.
    Cache can be also disabled by setting the Cache Policy to .notAllowed. It will disable storing Cache in any fashion, either in memory or on disk.

Snapshots

Whenever you press the home button, iOS takes a snapshot of the current screen to be able to do the transition to the application on a much smoother way. However, if sensitive data is present in the current screen, it will be saved in the image (which persists across reboots). These are the snapshots that you can also access double tapping the home screen to switch between apps.
Unless the iPhone is jailbroken, the attacker needs to have access to the device unblocked to see these screenshots. By default the last snapshot is stored in the application's sandbox in Library/Caches/Snapshots/ or Library/SplashBoard/Snapshots folder (the trusted computers can' t access the filesystem from iOX 7.0).
Once way to prevent this bad behaviour is to put a blank screen or remove the sensitive data before taking the snapshot using the ApplicationDidEnterBackground() function.
The following is a sample remediation method that will set a default screenshot.
Swift:
private var backgroundImage: UIImageView?
​
func applicationDidEnterBackground(_ application: UIApplication) {
let myBanner = UIImageView(image: #imageLiteral(resourceName: "overlayImage"))
myBanner.frame = UIScreen.main.bounds
backgroundImage = myBanner
window?.addSubview(myBanner)
}
​
func applicationWillEnterForeground(_ application: UIApplication) {
backgroundImage?.removeFromSuperview()
}
Objective-C:
@property (UIImageView *)backgroundImage;
​
- (void)applicationDidEnterBackground:(UIApplication *)application {
UIImageView *myBanner = [[UIImageView alloc] initWithImage:@"overlayImage.png"];
self.backgroundImage = myBanner;
self.backgroundImage.bounds = UIScreen.mainScreen.bounds;
[self.window addSubview:myBanner];
}
​
- (void)applicationWillEnterForeground:(UIApplication *)application {
[self.backgroundImage removeFromSuperview];
}
This sets the background image to overlayImage.png whenever the application is backgrounded. It prevents sensitive data leaks because overlayImage.png will always override the current view.

Keychain

Tools like Keychain-Dumper can be used to dump the keychain (the dive must be jailbroken). You can also use ios keychain dump from Objection.
NSURLCredential
NSURLCredential is the perfect class to store username and password in the keychain. No need to bother with NSUserDefaults nor any keychain wrapper. Once the user is logged in, you can** store** his username and password to the keychain:
NSURLCredential *credential;
​
credential = [NSURLCredential credentialWithUser:username password:password persistence:NSURLCredentialPersistencePermanent];
[[NSURLCredentialStorage sharedCredentialStorage] setCredential:credential forProtectionSpace:self.loginProtectionSpace];
You can use Objection's ios nsurlcredentialstorage dump to dump these secrets.

Custom Keyboards/Keyboard Cache

From iOS 8.0 Apple allows to install custom extensions for iOS like custom keyboards. The installed keyboards can be managed via Settings > General > Keyboard > Keyboards Custom keyboards can be used to sniff the keystrokes and send them to the attacker server. However, note that custom keyboards requiring networking connectivity will be notified to the user. Also, the user can switch to a different (more trusted) keyboard for introducing the credentials.
Moreover, applications can prevent its users from using custom keyboards within the app (or at least for sensitive parts of the app).
It's recommended to not allow third party keyboards if you consider the users won't need them
Note that because of auto-correct and auto-suggestions, the default iOS keyboard will capture and store each non-standard word word in a cache file if the attribute securetTextEntry is not set to true or if autoCorrectionType is not set to UITextAutoCorrectionTypeNo.
By default the keyboards store this cache inside the applications sandbox in Library/Keyboard/{locale}-dynamic-text.dat file or in /private/var/mobile/Library/Keyboard/dynamic-text.dat. However, it might be saving the dateaelsewhere. It's possible to reset the cache in Settings > General > Reset > Reset Keyboard Dictionary
Therefore, check always these files and search for possible sensitive information. Intercepting the network traffic is another way to check if the custom keyboard is sending keystroked to a remote server.
The UITextInputTraits protocol is used for keyboard caching. The UITextField, UITextView, and UISearchBar classes automatically support this protocol and it offers the following properties:
  • var autocorrectionType: UITextAutocorrectionType determines whether autocorrection is enabled during typing. When autocorrection is enabled, the text object tracks unknown words and suggests suitable replacements, replacing the typed text automatically unless the user overrides the replacement. The default value of this property is UITextAutocorrectionTypeDefault, which for most input methods enables autocorrection.
  • var secureTextEntry: BOOL determines whether text copying and text caching are disabled and hides the text being entered for UITextField. The default value of this property is NO.
To identify this behaviour in the code:
  • Search through the source code for similar implementations, such as
textObject.autocorrectionType = UITextAutocorrectionTypeNo;
textObject.secureTextEntry = YES;
  • Open xib and storyboard files in the Interface Builder of Xcode and verify the states of Secure Text Entry and Correction in the Attributes Inspector for the appropriate object.
The application must prevent the caching of sensitive information entered into text fields. You can prevent caching by disabling it programmatically, using the textObject.autocorrectionType = UITextAutocorrectionTypeNo directive in the desired UITextFields, UITextViews, and UISearchBars. For data that should be masked, such as PINs and passwords, set textObject.secureTextEntry to YES.
UITextField *textField = [ [ UITextField alloc ] initWithFrame: frame ];
textField.autocorrectionType = UITextAutocorrectionTypeNo;

Logs

The most common ways to debug code is using logging, and the application may print sensitive information inside the logs. In iOS version 6 and below, logs were world readable (a malicious app could read logs from other apps and extract sensitive information from there). Nowadays, apps can only access their own logs.
However, an attacker with physical access to an unlocked device can connect it to a computer and read the logs (note that the logs written to disk by an app aren't removed if the app ins uninstalled).
It's recommended to navigate through all the screens of the app and interact with every UI element and functionality of and provide input text in all text fields and review the logs looking for sensitive information exposed.
Use the following keywords to check the app's source code for predefined and custom logging statements:
  • For predefined and built-in functions:
    • NSLog
    • NSAssert
    • NSCAssert
    • fprintf
  • For custom functions:
    • Logging
    • Logfile
Monitoring System Logs
Many apps log informative (and potentially sensitive) messages to the console log. The log also contains crash reports and other useful information.
You can use these tools:
idevice_id --list # To find the device ID
idevicesyslog -u <id> (| grep <app>) # To get the device logs
You can collect console logs through the Xcode Devices window as follows:
  1. 1.
    Launch Xcode.
  2. 2.
    Connect your device to your host computer.
  3. 3.
    Choose Window -> Devices and Simulators.
  4. 4.
    Click on your connected iOS device in the left section of the Devices window.
  5. 5.
    Reproduce the problem.
  6. 6.
    Click on the Open Console button located in the upper right-hand area of the Devices window to view the console logs on a separate window.
You can also connect to the device shell as explained in Accessing the Device Shell, install socat via apt-get and run the following command:
iPhone:~ root# socat - UNIX-CONNECT:/var/run/lockdown/syslog.sock
​
========================
ASL is here to serve you
> watch
OK
​
Jun 7 13:42:14 iPhone chmod[9705] <Notice>: MS:Notice: Injecting: (null) [chmod] (1556.00)
Jun 7 13:42:14 iPhone readlink[9706] <Notice>: MS:Notice: Injecting: (null) [readlink] (1556.00)
Jun 7 13:42:14 iPhone rm[9707] <Notice>: MS:Notice: Injecting: (null) [rm] (1556.00)
Jun 7 13:42:14 iPhone touch[9708] <Notice>: MS:Notice: Injecting: (null) [touch] (1556.00)
...
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:

Backups

iOS includes auto-backup features that create copies of the data stored on the device. You can make iOS backups from your host computer by using iTunes (till macOS Catalina) or Finder (from macOS Catalina onwards), or via the iCloud backup feature. In both cases, the backup includes nearly all data stored on the iOS device except highly sensitive data such as Apple Pay information and Touch ID settings.
Since iOS backs up installed apps and their data, an obvious concern is whether sensitive user data stored by the app might unintentionally leak through the backup. Another concern, though less obvious, is whether sensitive configuration settings used to protect data or restrict app functionality could be tampered to change app behaviour after restoring a modified backup. Both concerns are valid and these vulnerabilities have proven to exist in a vast number of apps today.
A backup of a device on which a mobile application has been installed will include all subdirectories (except for Library/Caches/) and files in the app's private directory. Therefore, avoid storing sensitive data in plaintext within any of the files or folders that are in the app's private directory or subdirectories.
Although all the files in Documents/ and Library/Application Support/ are always backed up by default, you can exclude files from the backup by calling NSURL setResourceValue:forKey:error: with the NSURLIsExcludedFromBackupKey key. You can use the NSURLIsExcludedFromBackupKey and CFURLIsExcludedFromBackupKey file system properties to exclude files and directories from backups.
Therefore when checking the backup of an application you should check if any sensitive information is accessible and if you can modify any sensitive behaviour of the application by modifying some setting of the backup and restoring the backup
How to test
Start by creating a backup of the device (you can do it using Finder) and finding where is the backup stored. The official Apple documentation will help you to locate backups of your iPhone, iPad, and iPod touch.
Once you have found the backup of the device (/Users/carlos.martin/Library/Application Support/MobileSync/Backup/{deviceID}) you can start looking for sensitive information using grep for example, or using tools like iMazing).
To identify if a backup is encrypted, you can check the key named "IsEncrypted" from the file "Manifest.plist", located at the root of the backup directory. The following example shows a configuration indicating that the backup is encrypted: