Learn & practice AWS Hacking:<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Learn & practice GCP Hacking: <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
In iOS, a distinction in privilege exists between the user-accessible applications and the system's core processes. Applications run under the **`mobile`** user identity, while the crucial system processes operate as **`root`**. This separation is enhanced by a sandbox mechanism, which imposes strict limitations on what actions applications can undertake. For instance, even if applications share the same user identity, they are prohibited from accessing or modifying each other's data.
Applications are installed in a specific directory (`private/var/mobile/Applications/{random ID}`) and have restricted read access to certain system areas and functionalities, such as SMS and phone calls. Access to protected areas triggers a pop-up request for user permission.
iOS offers developers the **Data Protection APIs**, built atop the Secure Enclave Processor (SEP) — a dedicated coprocessor for cryptographic operations and key management. The SEP ensures data protection integrity via a unique device-specific key, the device UID, embedded within it.
Upon file creation, a unique 256-bit AES encryption key is generated, encrypting the file's content. This encryption key, alongside a class ID, is then encrypted using a class key and stored within the file's metadata. Decrypting a file involves using the system's key to access the metadata, retrieving the class key with the class ID, and then decrypting the file's unique encryption key.
- **Complete Protection (NSFileProtectionComplete)**: Data is inaccessible until the device is unlocked using the user's passcode.
- **Protected Unless Open (NSFileProtectionCompleteUnlessOpen)**: Allows file access even after the device is locked, provided the file was opened when the device was unlocked.
- **Protected Until First User Authentication (NSFileProtectionCompleteUntilFirstUserAuthentication)**: Data is accessible after the first user unlock post-boot, remaining accessible even if the device is locked again.
- **No Protection (NSFileProtectionNone)**: Data is only protected by the device UID, facilitating quick remote data wiping.
The encryption of all classes, except for `NSFileProtectionNone`, involves a key derived from both the device UID and the user's passcode, ensuring decryption is only possible on the device with the correct passcode. From iOS 7 onwards, the default protection class is "Protected Until First User Authentication".
In iOS, a **Keychain** serves as a secure **encrypted container** for storing **sensitive information**, accessible only by the application that stored it or those explicitly authorized. This encryption is fortified by a unique **password generated by iOS**, which itself is encrypted with **AES**. This encryption process leverages a **PBKDF2 function**, combining the user's passcode with a salt derived from the device's **UID**, a component only the **secure enclave chipset** can access. Consequently, even if the user's passcode is known, the Keychain contents remain inaccessible on any device other than the one where they were originally encrypted.
**Management and access** to the Keychain data are handled by the **`securityd` daemon**, based on specific app entitlements like `Keychain-access-groups` and `application-identifier`.
Brute-forcing the Keychain password involves either attacking the encrypted key directly or attempting to guess the passcode on the device itself, hindered significantly by secure enclave's enforcement of a delay between failed attempts.
Data protection levels for Keychain items are set using the `kSecAttrAccessible` attribute during item creation or update. These levels, [as specified by Apple](https://developer.apple.com/documentation/security/keychain_services/keychain_items/item_attribute_keys_and_values#1679100), determine when and how Keychain items are accessible:
Unlike app-specific data deleted upon app uninstallation, **Keychain data persists** on the device. This characteristic could enable new owners of a second-hand device to access the previous owner's application data simply by reinstalling apps. Developers are advised to proactively clear Keychain data upon app installation or during logout to mitigate this risk. Here's a Swift code example demonstrating how to clear Keychain data upon the first app launch:
In the realm of app development, **sandboxing** plays a crucial role in enhancing security. This process ensures that each app operates within its own unique home directory, thus preventing it from accessing system files or data belonging to other apps. The enforcement of these restrictions is carried out through sandbox policies, which are a part of the **Trusted BSD (MAC) Mandatory Access Control Framework**.
Developers have the ability to configure certain **capabilities or permissions** for their apps, such as **Data Protection** or **Keychain Sharing**. These permissions are applied immediately after the app is installed. Nonetheless, for accessing certain protected resources, the app must obtain explicit consent from the user at the time of the first attempt. This is achieved through the use of _purpose strings_ or _usage description strings_, which are presented to users in a permission request alert.
The `Info.plist` file of an app specifies **device capabilities** that help the App Store filter apps for device compatibility. These are defined under the **`UIRequiredDeviceCapabilities`** key. For instance:
This example indicates that the app is compatible with the armv7 instruction set. Developers may also specify capabilities like nfc to ensure their app is only available to devices supporting NFC.
**Entitlements** are another critical aspect of iOS app development, serving as key-value pairs that grant apps permission to perform certain operations beyond runtime checks. For example, enabling **Data Protection** in an app involves adding a specific entitlement in the Xcode project, which is then reflected in the app's entitlements file or the embedded mobile provision file for IPAs.
Learn & practice AWS Hacking:<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Learn & practice GCP Hacking: <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.