<summary><strong>Support HackTricks and get benefits!</strong></summary>
Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
**Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/carlospolopm)**.**
**Share your hacking tricks submitting PRs to the** [**hacktricks github repo**](https://github.com/carlospolop/hacktricks)**.**
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**:
It's recommended to use the tool [**MobSF**](https://github.com/MobSF/Mobile-Security-Framework-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
Check out the dynamic analysis that [**MobSF**](https://github.com/MobSF/Mobile-Security-Framework-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.
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`):
`.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**.\
* [`Core Data`](https://developer.apple.com/documentation/coredata): 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`](https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/ConfigApplications.html): 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.
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**](https://developer.apple.com/documentation/bundleresources/information\_property\_list?language=objc).
* 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):
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`:
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:
These folders contain information that must be examined closely during application security assessments (for example when analyzing the stored data for sensitive data).
* 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`.
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`):
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`**:
```bash
otool -Vh DVIA-v2 #Check some compilation attributes
However, the best options to disassemble the binary are: [**Hopper**](https://www.hopperapp.com/download.html?) and [**IDA**](https://www.hex-rays.com/products/ida/support/download\_freeware/).
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** 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`](https://developer.apple.com/documentation/foundation/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.
* 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):
[`Core Data`](https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/CoreData/nsfetchedresultscontroller.html#//apple\_ref/doc/uid/TP40001075-CH8-SW1) is a framework for managing the model layer of objects in your application. [Core Data can use SQLite as its persistent store](https://cocoacasts.com/what-is-the-difference-between-core-data-and-sqlite/), 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](https://github.com/project-imas/encrypted-core-data) 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`
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}`)
It can be leveraged by application developers to s**tore 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 Objective-C](https://realm.io/docs/objc/latest/) and [Realm Swift](https://realm.io/docs/swift/latest/) 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}`
```bash
iPhone:/private/var/mobile/Containers/Data/Application/A079DF84-726C-4AEA-A194-805B97B3684A/Documents root# ls
[Couchbase Lite](https://github.com/couchbase/couchbase-lite-ios) is a lightweight, embedded, document-oriented (NoSQL) database engine that can be synced. It compiles natively for iOS and macOS.
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**](https://github.com/mdegrazia/Safari-Binary-Cookie-Parser) or use\*\* objection's **`ios cookies get`.**\
**You can also use objection to** convert these files to a JSON\*\* format and inspect the data.
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 n**ormal 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. It is recommended to remove Cached responses after logout. This can be done with the provided method by Apple called [`removeAllCachedResponses`](https://developer.apple.com/documentation/foundation/urlcache/1417802-removeallcachedresponses) You can call this method as follows:
This method will remove all cached requests and responses from Cache.db file.
2. If you don't need to use the advantage of cookies it would be recommended to just use the [.ephemeral](https://developer.apple.com/documentation/foundation/urlsessionconfiguration/1410529-ephemeral) configuration property of URLSession, which will disable saving cookies and Caches.
`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. Cache can be also disabled by setting the Cache Policy to [.notAllowed](https://developer.apple.com/documentation/foundation/urlcache/storagepolicy/notallowed). It will disable storing Cache in any fashion, either in memory or on disk.
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.
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.
**NSURLCredential** is the perfect class to **store username and password in the keychain**. No need to bother with NSUserDefaults nor any keychain wrapper.\
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.
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**_
**Intercepting the network traffic** is another way to check if the custom keyboard is sending keystroked to a remote server.
{% endhint %}
The [UITextInputTraits protocol](https://developer.apple.com/reference/uikit/uitextinputtraits) 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
* 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`.
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.
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](https://developer.apple.com/library/content/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html#//apple\_ref/doc/uid/TP40010672-CH2-SW12).\
Although all the files in `Documents/` and `Library/Application Support/` are always backed up by default, you can [exclude files from the backup](https://developer.apple.com/library/content/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html#//apple\_ref/doc/uid/TP40010672-CH2-SW28) by calling `NSURL setResourceValue:forKey:error:` with the `NSURLIsExcludedFromBackupKey` key.\
You can use the [NSURLIsExcludedFromBackupKey](https://developer.apple.com/reference/foundation/nsurl#//apple\_ref/c/data/NSURLIsExcludedFromBackupKey) and [CFURLIsExcludedFromBackupKey](https://developer.apple.com/reference/corefoundation/cfurl-rd7#//apple\_ref/c/data/kCFURLIsExcludedFromBackupKey) 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
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](https://support.apple.com/en-us/HT204215).
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](https://imazing.com)).
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:
```markup
<?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">
In case you need to work with an encrypted backup, there are some Python scripts in [DinoSec's GitHub repo](https://github.com/dinosec/iphone-dataprotection/tree/master/python\_scripts), such as **backup\_tool.py** and **backup\_passwd.py**, that will serve as a good starting point. However, note that they might not work with the latest iTunes/Finder versions and might need to be tweaked.
In the open source bitcoin wallet app, [Bither](https://github.com/bither/bither-ios), you'll see that it's possible to configure a PIN to lock the UI.\
To investigate an application's memory, first create a **memory dump**. Alternatively, you can **analyze the memory in real time** with, for example, a debugger. Regardless of the method you use, this is a very error-prone process because dumps provide the data left by executed functions and you might miss executing critical steps. In addition, overlooking data during analysis is quite easy to do unless you know the footprint of the data you're looking for (either its exact value or its format). For example, if the app encrypts according to a randomly generated symmetric key, you're very unlikely to spot the key in memory unless you find its value by other means.
Wether you are using a jailbroken or a non-jailbroken device, you can dump the app's process memory with [objection](https://github.com/sensepost/objection) and [Fridump](https://github.com/Nightbringer21/fridump).
After the memory has been dumped (e.g. to a file called "memory"), depending on the nature of the data you're looking for, you'll need a set of different tools to process and analyze that memory dump. For instance, if you're focusing on strings, it might be sufficient for you to execute the command `strings` or `rabin2 -zz` to extract those strings.
However if you'd like to inspect other kind of data, you'd rather want to use radare2 and its search capabilities. See radare2's help on the search command (`/?`) for more information and a list of options. The following shows only a subset of them:
By using [**r2frida**](https://github.com/nowsecure/r2frida) you can analyze and inspect the app's memory while running and without needing to dump it. For example, you may run the previous search commands from r2frida and search the memory for a string, hexadecimal values, etc. When doing so, remember to prepend the search command (and any other r2frida specific commands) with a backslash `\` after starting the session with `r2 frida://usb//<name_of_your_app>`.
Some developers save sensitive data in the local storage and encrypt it with a key hardcoded/predictable in the code. This shouldn't be done as some reversing could allow attackers to extract the confidential information.
Developers shouldn't use **deprecated algorithms** to perform authorisation **checks**, **store** or **send** data. Some of these algorithms are: RC4, MD4, MD5, SHA1... If **hashes** are used to store passwords for example, hashes brute-force **resistant** should be used with salt.
The main checks to perform if to find if you can find **hardcoded** passwords/secrets in the code, or if those are **predictable**, and if the code is using some king of **weak****cryptography** algorithms.
It's interesting to know that you can **monitor** some **crypto****libraries** automatically using **objection** with:
```swift
ios monitor crypt
```
For **more information** about iOS cryptographic APIs and libraries access [https://mobile-security.gitbook.io/mobile-security-testing-guide/ios-testing-guide/0x06e-testing-cryptography](https://mobile-security.gitbook.io/mobile-security-testing-guide/ios-testing-guide/0x06e-testing-cryptography)
The tester should be aware that **local authentication should always be enforced at a remote endpoint** or based on a cryptographic primitive. Attackers can easily bypass local authentication if no data returns from the authentication process.
The [**Local Authentication framework**](https://developer.apple.com/documentation/localauthentication) \_\*\*\_provides a set of APIs for developers to extend an authentication dialog to a user. In the context of connecting to a remote service, it is possible (and recommended) to leverage the [keychain](https://developer.apple.com/library/content/documentation/Security/Conceptual/keychainServConcepts/01introduction/introduction.html) for implementing local authentication.
The **fingerprint ID** sensor is operated by the [SecureEnclave security coprocessor](https://www.blackhat.com/docs/us-16/materials/us-16-Mandt-Demystifying-The-Secure-Enclave-Processor.pdf) and does not expose fingerprint data to any other parts of the system. Next to Touch ID, Apple introduced _Face ID_: which allows authentication based on facial recognition.
Developers have two options for incorporating Touch ID/Face ID authentication:
*`LocalAuthentication.framework` is a high-level API that can be used to **authenticate the user via Touch ID**. The app can't access any data associated with the enrolled fingerprint and is notified only whether authentication was successful.
*`Security.framework` is a lower level API to access [keychain services](https://developer.apple.com/documentation/security/keychain\_services). This is a secure option if your app needs to **protect some secret data with biometric authentication**, since the access control is managed on a system-level and can not easily be bypassed. `Security.framework` has a C API, but there are several [open source wrappers available](https://www.raywenderlich.com/147308/secure-ios-user-data-keychain-touch-id), making access to the keychain as simple as to NSUserDefaults.
Please be aware that using either the `LocalAuthentication.framework` or the `Security.framework`, will be a control that can be bypassed by an attacker as it does only return a boolean and no data to proceed with. See [Don't touch me that way, by David Lindner et al](https://www.youtube.com/watch?v=XhXIHVGCFFM) for more details.
Developers can display an **authentication prompt** by utilizing the function `evaluatePolicy` of the `LAContext` class. Two available policies define acceptable forms of authentication:
*`deviceOwnerAuthentication`(Swift) or `LAPolicyDeviceOwnerAuthentication`(Objective-C): When available, the user is prompted to perform Touch ID authentication. If Touch ID is not activated, the device passcode is requested instead. If the device passcode is not enabled, policy evaluation fails.
*`deviceOwnerAuthenticationWithBiometrics` (Swift) or `LAPolicyDeviceOwnerAuthenticationWithBiometrics`(Objective-C): Authentication is restricted to biometrics where the user is prompted for Touch ID.
The **`evaluatePolicy` function returns a boolean** value indicating whether the user has authenticated successfully. Which means that it can be easily bypassed (see below)
The **iOS keychain APIs can (and should) be used to implement local authentication**. During this process, the app stores either a secret authentication token or another piece of secret data identifying the user in the keychain. In order to authenticate to a remote service, the user must unlock the keychain using their passphrase or fingerprint to obtain the secret data.
The keychain allows saving items with the special `SecAccessControl` attribute, which will allow access to the item from the keychain only after the user has passed Touch ID authentication (or passcode, if such a fallback is allowed by attribute parameters).
In the following example we will save the string "test\_strong\_password" to the keychain. The string can be accessed only on the current device while the passcode is set (`kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly` parameter) and after Touch ID authentication for the currently enrolled fingers only (`SecAccessControlCreateFlags.biometryCurrentSet` parameter):
OSStatus status = SecItemAdd((__bridge CFDictionaryRef)query, nil);
if (status == noErr) {
// successfully saved
} else {
// error while saving
}
```
{% endtab %}
{% endtabs %}
Now we can request the saved item from the keychain. Keychain services will present the authentication dialog to the user and return data or nil depending on whether a suitable fingerprint was provided or not.
{% tabs %}
{% tab title="Swift" %}
```swift
// 1. define query
var query = [String: Any]()
query[kSecClass as String] = kSecClassGenericPassword
query[kSecReturnData as String] = kCFBooleanTrue
query[kSecAttrAccount as String] = "My Name" as CFString
query[kSecAttrLabel as String] = "com.me.myapp.password" as CFString
query[kSecUseOperationPrompt as String] = "Please, pass authorisation to enter this area" as CFString
// 2. get item
var queryResult: AnyObject?
let status = withUnsafeMutablePointer(to: &queryResult) {
SecItemCopyMatching(query as CFDictionary, UnsafeMutablePointer($0))
}
if status == noErr {
let password = String(data: queryResult as! Data, encoding: .utf8)!
If `LocalAuthentication.framework` is used in an app, the output will contain both of the following lines (remember that `LocalAuthentication.framework` uses `Security.framework` under the hood):
[Objection Biometrics Bypass](https://github.com/sensepost/objection/wiki/Understanding-the-iOS-Biometrics-Bypass) can be used to bypass LocalAuthentication. Objection **uses Frida to instrument the `evaluatePolicy` function so that it returns `True`** even if authentication was not successfully performed. Use the `ios ui biometrics_bypass` command to bypass the insecure biometric authentication. Objection will register a job, which will replace the `evaluatePolicy` result. It will work in both, Swift and Objective-C implementations.
```bash
...itudehacks.DVIAswiftv2.develop on (iPhone: 13.2.3) [usb] # ios ui biometrics_bypass
It's important to check that no communication is occurring **without encryption** and also that the application is correctly **validating the TLS certificate** of the server.\
One common issue validating the TLS certificate is to check that the certificate was signed by a **trusted****CA**, but **not check** if **the hostname** of the certificate is the hostname being accessed.\
In order to check this issue using Burp, after trusting Burp CA in the iPhone, you can **create a new certificate with Burp for a different hostname** and use it. If the application still works, then, something it's vulnerable.
If an application is correctly using SSL Pinning, then the application will only works if the certificate is the once expected to be. When testing an application **this might be a problem as Burp will serve it's own certificate.**\
In order to bypass this protection inside a jailbroken device, you can install the application [**SSL Kill Switch**](https://github.com/nabla-c0d3/ssl-kill-switch2) or install \[**Burp Mobile Assistant\_\*]\(\_**[**https://portswigger.net/burp/documentation/desktop/tools/mobile-assistant/installing)\\**](https://portswigger.net/burp/documentation/desktop/tools/mobile-assistant/installing\)/)\*
* **`iTunesMetadata.plist`**: Info of the app used in the App Store
* **`/Library/*`**: Contains the preferences and cache. In **`/Library/Cache/Snapshots/*`** you can find the snapshot performed to the application before sending it to the background.
The developers can remotely **patch all installations of their app instantly** without having to resubmit the application to the App store and wait until it's approved.\
For this purpose it's usually use [**JSPatch**](https://github.com/bang590/JSPatch)**.** But there are other options also such as [Siren](https://github.com/ArtSabintsev/Siren) and [react-native-appstore-version-checker](https://www.npmjs.com/package/react-native-appstore-version-checker).\
**This is a dangerous mechanism that could be abused by malicious third party SDKs therefore it's recommended to check which method is used to automatic updating (if any) and test it.** You could try to download a previous version of the app for this purpose.
One problem of 3rd party SDKs is that there is **no granular control over the features offered by the SDK**. You could sue the SDK and have all features (including diagnostic leaks and insecure HTTP connections), or not use it. Also, usually it's no possible for the applications developers to **patch a vulnerability** on the SDK.\
Moreover some SDKs start **containing malware once they are very trusted** by the community.
Besides, the features these services provide can involve t**racking services to monitor the user's behaviour** while using the app, selling banner advertisements, or improving the user experience. The downside to third-party services is that developers don't know the details of the code executed via third-party libraries. Consequently, no more information than is necessary should be sent to a service, and no sensitive information should be disclosed.
The downside is that a **developer doesn’t know in detail what code is executed via 3rd party libraries** and therefore giving up visibility. Consequently it should be ensured that not more than the information needed is sent to the service and that no sensitive information is disclosed.
Most third-party services are implemented in two ways:
All data that's sent to third-party services should be anonymized to prevent exposure of PII (Personal Identifiable Information) that would allow the third party to identify the user account.
You can find the **libraries used by an application** by running **`otool`** against the app (and **running** it **against****each** shared **library** to find more shared libraries used).
<summary><strong>Support HackTricks and get benefits!</strong></summary>
Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
**Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/carlospolopm)**.**
**Share your hacking tricks submitting PRs to the** [**hacktricks github repo**](https://github.com/carlospolop/hacktricks)**.**
