Merge pull request #2032 from HackTricks-wiki/research_update_src_mobile-pentesting_ios-pentesting_ios-testing-environment_20260319_202436

Research Update Enhanced src/mobile-pentesting/ios-pentestin...

Author: carlospolop

src/mobile-pentesting/ios-pentesting/ios-testing-environment.md

@@ -9,10 +9,42 @@ A **provisioning identity** is a collection of public and private keys that are
 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**".
 
+On **iOS 16+**, **Developer Mode** must also be enabled on the device before locally installed development-signed applications (or apps re-signed with `get-task-allow`) will run. This option only appears **after pairing the device with Xcode** or after installing a development-signed app once. The flow is: **pair the device**, trigger an install from Xcode, then enable **Settings** --> **Privacy & Security** --> **Developer Mode**, reboot, and confirm the prompt after unlock.
+
 Note that **applications signed by the same signing certificate can share resources on a secure manner, like keychain items**.
 
 The provisioning profiles are stored inside the phone in **`/Library/MobileDevice/ProvisioningProfiles`**
 
+### Modern host-side device tooling
+
+For current iOS testing, the host tooling is increasingly split between:
+
+- **`xcrun simctl`** for simulator management
+- **`xcrun xctrace list devices`** to enumerate simulators and physical devices
+- **`xcrun devicectl`** (Xcode 15+) to interact with paired physical devices from the command line
+
+Useful examples:
+
+```bash
+# List booted simulators
+xcrun simctl list | grep Booted
+
+# List all visible devices/simulators
+xcrun xctrace list devices
+
+# List paired physical devices (Xcode 15+)
+xcrun devicectl list devices
+```
+
+`devicectl` is especially useful in automation pipelines where you need to install or launch a test build without opening Xcode:
+
+```bash
+xcrun devicectl device install app --device <udid> <path_to_app_or_ipa>
+xcrun devicectl device launch app --terminate-existing --device <udid> <bundle_id>
+```
+
+Keep Xcode updated when testing **iOS 17+** devices. Apple moved developer services to the **CoreDevice** stack and also changed how **Developer Disk Images** are handled, so outdated host tooling frequently fails with pairing, image-mounting, or app-launch errors.
+
 ## **Simulator**
 
 > [!TIP]
@@ -28,6 +60,8 @@ It's highly recommended to **download** Xcode from the **official app store**. O
 
 The simulator files can be found in `/Users/<username>/Library/Developer/CoreSimulator/Devices`
 
+The simulator is still very useful for quickly testing **filesystem artifacts**, **NSUserDefaults**, **plist parsing**, **custom URL schemes**, and **basic runtime instrumentation**. However, keep in mind that it doesn't emulate several physical-device security properties that are often relevant during a pentest, such as the **Secure Enclave**, **baseband**, certain **keychain access-control behaviours**, realistic **biometric flows**, and jailbreak-specific execution conditions.
+
 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:
 
@@ -93,12 +127,27 @@ iOS updates are controlled by a **challenge-response mechanism** (SHSH blobs), a
 
 Jailbreaking tools vary by iOS version and device. Resources such as [Can I Jailbreak?](https://canijailbreak.com), [The iPhone Wiki](https://www.theiphonewiki.com), and [Reddit Jailbreak](https://www.reddit.com/r/jailbreak/) provide up-to-date information. Examples include:
 
-- [Checkra1n](https://checkra.in/) for A7-A11 chip devices.
-- [Palera1n](https://palera.in/) for Checkm8 devices (A8-A11) on iOS 15.0-16.5.
-- [Unc0ver](https://unc0ver.dev/) for iOS versions up to 14.8.
+- [Checkra1n](https://checkra.in/) for older A7-A11/iOS 12-14 era research devices.
+- [Palera1n](https://palera.in/) for checkm8-compatible devices (A8-A11) on iOS/iPadOS 15+.
+- [Dopamine](https://github.com/opa334/Dopamine) for many arm64/arm64e devices on iOS 15/16 using a modern rootless jailbreak.
+- [Unc0ver](https://unc0ver.dev/) remains relevant mainly for older iOS versions up to 14.8.
 
 Modifying your device carries risks, and jailbreaking should be approached with caution.
 
+### Rootless jailbreaks
+
+Modern iOS 15+ jailbreaks are commonly **rootless** instead of **rootful**. From a tester perspective, this matters because a lot of older guides still assume that jailbreak files live directly under `/` or `/Library/...`, which is no longer true on many current setups.
+
+- Rootless jailbreaks avoid modifying the sealed system volume directly.
+- On palera1n, jailbreak files are typically stored under a randomized path in `/private/preboot/...` and exposed through the stable symlink **`/var/jb`**.
+- Tweaks, launch daemons, and helper binaries might therefore exist under **`/var/jb`** instead of the legacy rootful locations.
+
+This has a direct impact on **environment validation**, **Frida setup**, and **jailbreak detection bypass**:
+
+- When checking whether your tooling installed correctly, inspect both legacy paths and **`/var/jb`**.
+- When reviewing jailbreak detection logic in an app, remember that modern checks often look for **rootless** artifacts and symlinks in addition to classic indicators like `Cydia.app`.
+- If a third-party script or tweak assumes a rootful filesystem layout, it may fail silently on a rootless device.
+
 ### Jailbreaking Benefits and Risks
 
 Jailbreaking **removes OS-imposed sandboxing**, allowing apps to access the entire filesystem. This freedom enables the installation of unapproved apps and access to more APIs. However, for regular users, jailbreaking is **not recommended** due to potential security risks and device instability.
@@ -115,6 +164,7 @@ basic-ios-testing-operations.md
 **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 modern **rootless** jailbreaks, those files may appear under **`/var/jb`** or resolve through symlinks into `/private/preboot/...` instead of only in classic rootful locations.
 - 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
@@ -132,7 +182,8 @@ You can try to avoid this detections using **objection's** `ios jailbreak disabl
 ## References
 
 - [https://mas.owasp.org/MASTG/iOS/0x06b-iOS-Security-Testing/](https://mas.owasp.org/MASTG/iOS/0x06b-iOS-Security-Testing/)
+- [https://developer.apple.com/documentation/xcode/enabling-developer-mode-on-a-device](https://developer.apple.com/documentation/xcode/enabling-developer-mode-on-a-device)
+- [https://docs.palera.in/docs/reference/environment-types/](https://docs.palera.in/docs/reference/environment-types/)
 
 {{#include ../../banners/hacktricks-training.md}}
 
-