Note that a **simulator isn't the same as en emulator**. The simulator just simulates the behaviour of the device and functions but don't actually use them.
{% endhint %}
**T**he iOS SDK simulator offers a higher-level _simulation_ of an iOS device. Most importantly, emulator binaries are compiled to x86 code instead of ARM code. Apps compiled for a real device don't run, making the simulator useless for black box analysis and reverse engineering.
### **Simulator**
The first thing you need to know is that **performing a pentest inside a simulator will much more limited than doing it in a jailbroken device**.
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:
### Applications in the Simulator
Inside `/Users/<username>/Library/Developer/CoreSimulator/Devices` you may find all the **installed simulators**. If you want to access the files of an application created inside one of the emulators it might be difficult to know **in which one the app is installed**. A quick way to **find the correct UID** is to execute the app in the simulator and execute:
Once you know the UID the apps installed within it can be found in `/Users/<username>/Library/Developer/CoreSimulator/Devices/{UID}/data/Containers/Data/Application`
However, surprisingly you won't find the application here. You need to access `/Users/<username>/Library/Developer/Xcode/DerivedData/{Application}/Build/Products/Debug-iphonesimulator/`
And in this folder you can **find the package of the application.**
## Emulator
Corellium is the only publicly available iOS emulator. It is an enterprise SaaS solution with a per user license model and does not offer any trial license.
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.
iOS jailbreaking is often **compared to Android rooting**, but the process is actually quite **different**. To explain the difference, we'll first review the concepts of "rooting" and "flashing" on Android.
* **Rooting**: This typically involves installing the `su` binary on the system or replacing the whole system with a rooted custom ROM. Exploits aren't required to obtain root access as long as the bootloader is accessible.
* **Flashing custom ROMs**: This allows you to replace the OS that's running on the device after you unlock the bootloader. The bootloader may require an exploit to unlock it.
**On iOS devices, flashing a custom ROM is impossible** because the iOS bootloader **only allows Apple-signed images** to be booted and flashed. This is why even **official iOS images can't be installed if they aren't signed by Apple, and it makes iOS downgrades only possible for as long as the previous iOS version is still signed.**
The purpose of jailbreaking is to **disable iOS protections** \(Apple's code signing mechanisms in particular\) so that **arbitrary unsigned code can run on the device** \(e.g. custom code or downloaded from alternative app stores such as Cydia or Sileo\). The word "jailbreak" is a colloquial reference to all-in-one tools that automate the disabling process.
Jailbreaking an iOS device is becoming more and more **complicated** because Apple keeps hardening the system and patching the exploited vulnerabilities. Jailbreaking has become a very time-sensitive procedure because **Apple stops signing these vulnerable versions relatively soon after releasing a fix** \(unless the jailbreak benefits from hardware-based vulnerabilities, such as the [limera1n exploit](https://www.theiphonewiki.com/wiki/Limera1n) affecting the BootROM of the iPhone 4 and iPad 1\). This means that **you can't downgrade to a specific iOS version once Apple stops signing the firmware**.
If you have a jailbroken device that you use for security testing, **keep it** as is unless you're 100% sure that you can re-jailbreak it after upgrading to the latest iOS version.
iOS upgrades are based on a challenge-response process \(generating the so-called SHSH blobs as a result\). The device will allow the OS installation only if the response to the challenge is signed by Apple. This is what researchers call a "signing window", and it is the reason **you can't simply store the OTA firmware package you downloaded and load it onto the device whenever you want to**. During minor iOS upgrades, two versions may both be signed by Apple \(the latest one, and the previous iOS version\). This is the only situation in which you can downgrade the iOS device. You can c**heck the current signing window and download OTA firmware from the** [**IPSW Downloads website**](https://ipsw.me).
{% hint style="danger" %}
**Updating the OS removes the effect of jailbreaking.**
* **Tethered** **jailbreaks** don't persist through reboots, so re-applying jailbreaks requires the device to be connected \(tethered\) to a computer during every reboot. The device may not reboot at all if the computer is not connected.
* **Semi-tethered jailbreaks** can't be re-applied unless the device is connected to a computer during reboot. The device can also boot into non-jailbroken mode on its own.
* **Semi-untethered jailbreaks** allow the device to boot on its own, but the kernel patches \(or user-land modifications\) for disabling code signing aren't applied automatically. The user must re-jailbreak the device by starting an app or visiting a website \(not requiring a connection to a computer, hence the term untethered\).
* **Untethered jailbreaks** are the most popular choice for end users because they need to be applied only once, after which the device will be permanently jailbroken.
Different iOS versions require **different jailbreaking techniques**. [Determine whether a public jailbreak is available for your version of iOS](https://canijailbreak.com/). Beware of fake tools and spyware, which are often hiding behind domain names that are similar to the name of the jailbreaking group/author.
The iOS jailbreak scene evolves so rapidly that providing up-to-date instructions is difficult. However, we can point you to some sources that are currently reliable.
* \*\*\*\*[**Can I Jailbreak?**](https://canijailbreak.com/)\*\*\*\*
> Note that any modification you make to your device is at your own risk. While jailbreaking is typically safe, things can go wrong and you may end up bricking your device. No other party except yourself can be held accountable for any damage.
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.
{% hint style="warning" %}
**It's not recommended to jailbreak the mobile for regular users**
**Several applications will try to detect if the mobile is jailbroken and in that case the application won't run**
* After jailbreaking an iOS **files and folders are usually installed**, these can be searched to determine if the device is jailbroken.
* In a jailbroken device applications get **read/write access to new files** outside the sandbox
* Some **API****calls** will **behave differently**
* The presence of the **OpenSSH** service
* Calling `/bin/sh` will **return 1** instead of 0
**More information about how to detect jailbreaking** [**here**](https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/jailbreak-detection-methods/)**.**
