Applications the user can access run as the **mobile** user while critical system processes run as **root**.
However, the sandbox allows better control over actions that processes and applications can perform.
For example, even if two processes run as the same user \(mobile\), they are **not allowed to access or modify each other's data**.
Each application is installed under **`private/var/mobile/Applications/{random ID}`**
Once installed, applications have limited read access to some system areas and functions \(SMS, phone call...\). If an application wants to access a **protected area,** a **pop-up requesting permission** appears.
## Jailbreaking
Apple strictly requires that the code running on the iPhone must be **signed by a certificate issued by Apple**. **Jailbreaking** is the process of actively **circumventing such restrictions** and other security controls put in places by the OS. Therefore, once the device is jailbroken, the **integrity check** which is responsible for checking apps being installed is patched so it is **bypassed**.
{% hint style="info" %}
Unlike Android, **you cannot switch to "Developer Mode"** in iOS to run unsigned/untrusted code on the device.
{% endhint %}
The most important side effect of Jailbreaking is that it **removes any sandboxing put in place by the OS**. Therefore, any **app on the device can read any file** on the filesystem, including other apps files, cookies and keychain.
A jailbroken device allows users to **install unapproved apps** and leverage **more APIs**, which otherwise aren't accessible.
There are 2 types of jailbreaks:
* **Tethered**: Temporary jailbreak that requires the device to be connected to a computer every-time the device needs a restart. The jailbreak is reversed otherwise.
* **Untethered**: Rebooting the device does not reset the jailbreak.
**For regular users it's not recommended to jailbreak the mobile.
Note also that updating the OS removes the effect of jailbreaking.**
## **Simulator**
All the tools required to build and support an iOS app are **only officially supported on Mac OS**.
Apple's de facto tool for creating/debugging/instrumenting iOS applications is **Xcode**. It can be used to download other components such as **simulators** and different **SDK****versions** required to build and **test** your app.
It's highly recommended to **download** Xcode from the **official app store**. Other versions may be carrying malware.
The simulator files can be found in `/Users/<username>/Library/Developer/CoreSimulator/Devices`
To open the simulator, run Xcode, then press in the _Xcode tab_ -->_Open Developer tools_ -->_Simulator_
In the following image clicking in "iPod touch \[...\]" you can select other device to test in:
A **provisioning identity** is a collection of public and private keys that are associated an Apple developer account. In order to **sign apps** you need to pay **99$/year** to register in the **Apple Developer Program** to get your provisioning identity. Without this you won't be able to run applications from the source code in a physical device. Another option to do this is to use a **jailbroken device**.
Starting in Xcode 7.2 Apple has provided an option to create a **free iOS development provisioning profile** that allows to write and test your application on a real iPhone. Go to _Xcode_ -->_Preferences_ -->_Accounts_ -->_+_ \(Add new Appli ID you your credentials\) -->_Click on the Apple ID created_ -->_Manage Certificates_ -->_+_ \(Apple Development\) -->_Done_
Then, in order to run your application in your iPhone you need first to **indicate the iPhone to trust the computer.** Then, you can try to **run the application in the mobile from Xcode,** but and error will appear. So go to _Settings_ -->_General_ -->_Profiles and Device Management_ --> Select the untrusted profile and click "**Trust**".
Note that **applications signed by the same signing certificate can share resources on a secure manner, like keychain items**.
## Obfuscation
Unlike an Android Application, the binary of an iOS app **can only be disassembled** and not decompiled.
When an application is submitted to the app store, Apple first verifies the app conduct and before releasing it to the app-store, **Apple encrypts the binary using** [**FairPlay**](https://developer.apple.com/streaming/fps/). So the binary download from the app store is encrypted complicating ting the reverse-engineering tasks.
MH_MAGIC_64 X86_64 ALL 0x00 EXECUTE 47 6080 NOUNDEFS DYLDLINK TWOLEVEL PIE
```
If it's set you can use the script [`change_macho_flags.py`](https://chromium.googlesource.com/chromium/src/+/49.0.2623.110/build/mac/change_mach_o_flags.py) to remove it with python2:
Now that the PIE flag isn't set, the OS will load the program at a **fixed starting location** every-time. In order to find this **location** you can use:
```bash
otool -l Original_App | grep -A 3 LC_SEGMENT | grep -A 1 __TEXT
segname __TEXT
vmaddr 0x00001000
```
Then, it's necessary to extract the the memory range that needs to be dumped:
```bash
otool -l Original_App | grep -A 4 LC_ENCRYPTION_INFO
cmd LC_ENCRYPTION_INFO
cmdsize 20
cryptoff 4096
cryptsize 4096
cryptid 0
```
The value of **`cryptoff`** indicated the starting address of the encrypted content and the **`cryptsize`** indicates the size of the encrypted content.
So, the `start address` to dump will be `vmaddr + cryptoff` and the `end address` will be the `start address + cryptsize`
In this case: `start_address = 0x1000 + 0x1000 = 0x2000` __and `end_address = 0x2000 + 0x1000 = 0x3000`
With this information it's just necessary to run the application in the jailbroken device, attach to the process with gdb \(`gdb -p <pid>`\) and dump the memory:
```bash
dump memory dump.bin 0x2000 0x3000
```
Congrats! You have decrypted the encrypted section in dump.bin. Now **transfer this dump to your computer and overwrite the encrypted section with the decrypted** one:
There is one more step to complete. The application is still **indicating** in its metadata that it's **encrypted**, but it **isn't**. Then, when executed, the device will try to decrypt the already decrypted section and it's going to fail.
However, you can use tools like [**MachOView**](https://sourceforge.net/projects/machoview/) to change this info. Just open the binary and set the **cryptid** to 0:
### Removing App Store Encryption Automatically
You can use tools like [**Clutch**](https://github.com/KJCracks/Clutch) to automatically remove the encryption and an app.
`.ipa` files are zipped packages, so change the extension to `.zip` and decompress them. After decompressing them you should see an `.app` folder. This **folder contains the files of the application**.
Inside the application you can find different interesting files.
### 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.
### Binary
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/).
Starting in iOS version 8.4, Apple has **restricted the third-party managers to access to the application sandbox**, so tools like iFunbox and iExplorer no longer display/retrieve files from apps installed on the device if the device isn't jailbroken.
