The state of iOS jailbreaking in 2025

A deep dive into TrollStore and Dopamine

@al ecg_dev & @opa334dev 0x41con 2025

fi
Jailbreaking today
What does the public scene have?

• No public kernel exploits for iOS 17+

• No public jailbreak for arm64e devices on iOS 16.6+
• iOS 15.5+ only jailbroken thanks to Operation Triangulation
• The only public exploits for iOS 17 and above:
• CoreTrust bypass (17.0 only)
• Some backup bugs
TrollStore
TrollStore
Overview

• Allows installing applications with arbitrary entitlements

• Applications are permanently signed and do not revoke
• Uses a CoreTrust codesigning bypass to sign applications
• Also used to sign TrollStore itself (and its helper binaries)
• Supports iOS 14.0 - 16.6.1, 17.0
Codesigning
Overview

• Every executable le in iOS requires a valid code signature to run

• Multiple di erent types of code signatures can be found:
• Ad-hoc
• App Store and TestFlight
• Developer and enterprise
• Checked by the kernel before execution
• posix_spawn and execve syscalls
• Loading a library through dyld (which calls fcntl(F_ADDFILESIGS) on the library)
ff
fi
Code signature
Structure

Header

LC_SEGMENT_64
LC_SEGMENT_64 Code signature
LC_SEGMENT_64
LC_SEGMENT_64 CSSLOT_CODEDIRECTORY
(…) CSSLOT_ALTERNATE_CODEDIRECTORIES
CSSLOT_ENTITLEMENTS
LC_CODE_SIGNATURE CSSLOT_DER_ENTITLEMENTS
CSSLOT_REQUIREMENTS
CSSLOT_SIGNATURESLOT
Code directories
CSSLOT_CODEDIRECTORY & CSSLOT_ALTERNATE_CODEDIRECTORIES

• Contains hashes of each page of the MachO up to the code signature

• Contains hashes of other code signature blobs
• XML and DER entitlements
• Requirements
• Contains hashes of other relevant data
• Info.plist
• CodeResources le
• Launch constraints
• Code directory hash (CD hash) is representative of the entire binary
• Important: MachOs can have multiple code directories as long as they are di erent hash types
fi
ff
 Entitlements
CSSLOT_ENTITLEMENTS & CSSLOT_DER_ENTITLEMENTS

• De nes permissions possessed by the process once spawned

• Readable and writable le paths
• Accessible kernel drivers and userclients
• Sandboxing restrictions
• DER entitlements are a requirement as of iOS 15
• Helps mitigate XML entitlement parsing bugs (e.g. Psychicpaper)
fi
fi
 Requirements
CSSLOT_REQUIREMENTS

• De nes requirements for the code signature to meet

• Certi cate anchor
• Certi cate common name
• Application identi er
• Only respected for non-Apple certi cates (developer and enterprise apps)
fi
fi
fi
fi
fi
Signature
CSSLOT_SIGNATURESLOT

• ASN.1-encoded CMS signature blob

• Contains a signature for the signed attributes
• Content type
• CD hashes in various forms (plaintext, Base64)
• Contains certi cates and signer information
• Not present in ad-hoc code signatures
• Important: can contain multiple signers in one CMS blob
fi
 Code signature validation
As of iOS 15

• AppleMobileFileIntegrity (AMFI) and CoreTrust kernel extensions

• They work together, AMFI calls into CoreTrust to validate all CMS blobs
• am d daemon
• Userspace counterpart to AMFI
• Used to verify developer, enterprise and TestFlight apps
• Validation goes through several varying stages, depending on the binary
fi
Code signature validation
Trustcache

• No need to send all binaries on the root lesystem through CoreTrust

• SSV prevents them from ever being modi ed
• All binaries should, in theory, be original Apple binaries
• AMFI uses trust caches to allow for quicker validation of these binaries
• Lists of CD hashes that are pre-approved and trusted
• Static trustcache for pre-installed binaries, dynamic trustcaches for DDIs
• If the binary is not in the trustcache, it is passed on to CoreTrust
fi
fi
Code signature validation
CoreTrust

• Kernel extension introduced in iOS 12

• Prevents attackers from intercepting am d in userspace to defeat
codesigning entirely

• Assumed to be immutable under KTRR/CTRR

• All binaries not in trustcache are validated by CoreTrust
• If it has no CMS blob, CoreTrust will reject it and it will never reach am d
• Returns CD hashes and policy ags to AMFI
fl
fi
fi
 Code signature validation
CoreTrust

https://github.com/apple-oss-distributions/xnu/blob/main/EXTERNAL_HEADERS/CoreTrust/CTEvaluate.h
Code signature validation
CoreTrust

• Policy ags are set based on the certi cate’s common name and public key
• Chains without an Apple root will have policy ags set to zero
• AMFI will subsequently reject the binary
• CoreTrust does not verify that both CD hashes are correct
• Purely used to validate the CMS signature itself
fl
fi
fl
 Code signature validation
am d

• Userspace daemon that checks developer and enterprise certi cates for AMFI
• Also performs checks on TestFlight apps
• Has been intercepted by attackers in the past to allow any code signature
• Attaching an expired certi cate to every binary causes am d to validate all of them
• Can hook MISValidateSignature(AndCopyInfo) to force validation to succeed for every binary
• Hardly used in a regular iOS user scenario
• Average user is unlikely to install developer/enterprise/TestFlight applications
• Why do App Store apps never reach am d?
fi
fi
fi
fi
fi
App Store Fast Path
Overview

• iOS 14 added the “App Store Fast Path” to AMFI

• In iOS 12 and 13, CoreTrust only ensured that the certi cates had an Apple root
• Was used to short-circuit failure, rather than success
• App Store Fast Path ensures automatic validation for App Store apps
• “App Store apps” assumed to be those that have the App Store policy ag set
• As you will soon see, this is an important distinction :-)
• Any and all entitlements* are allowed
• Apart from three that were restricted to trustcached processes only
fi
fl
App Store Fast Path
Exploitation

• The App Store Fast Path makes CoreTrust an attractive target for an attacker
• Trick CoreTrust into setting the App Store policy ag, bypass codesigning
• Logic bugs are always 100% reliable in exploitation
• Multiple interesting uses
• Permanently signed applications
• Arbitrary entitlements
• Spawning binaries as root (or any UID, for that matter)
• Persistence on iOS 14, by replacing a system binary (e.g. launchd)
fl
CoreTrust bypasses

• Since iOS 14, there have been two public CoreTrust bypasses
• Both used in TrollStore and di erent points
• No incentive for such logic bugs in iOS 12 and 13
• One found in-the-wild as part of an €8m spyware chain
• Largely unmitigated between the rst and second bypasses releasing
• Have been mitigated since (more details on this later on)
ff
fi
CVE-2022-26766
The rst bypass

• Discovered by Linus Henze and patched in iOS 15.5

• Regressed in iOS 15.6 betas, xed again in the RC
• Used in Fugu15 to obtain DriverKit entitlements for the kernel exploit
• Used in TrollStore 1.x to support iOS 14.0 - 15.5b4, 15.6 betas
• Bug is simple: CoreTrust did not verify the root certi cate was an Apple certi cate!
• By creating a custom root certi cate with the App Store extension, you could sign
any app with the certi cate and trigger the App Store Fast Path
fi
fi
fi
fi
fi
fi
CVE-2023-41991
The second bypass

• Discovered in-the-wild by Google TAG and Citizen Lab in September 2023

• Found being used by the Intellexa Predator spyware chain
• Alongside a WebKit RCE exploit and a kernel LPE used to spawn the binary
• Allowed the spyware’s implant binary to be executed
• Patched in iOS 16.7 and 17.0.1 (never patched in iOS 15)
• I patchdi ed and wrote an exploit for the bug
• Used in TrollStore 2.x to support iOS 14.0 - 16.7RC and 17.0
ff
CVE-2023-41991
The second bypass

• Contrastingly to the rst bypass, one of the most complex bugs we have seen
• Made use of multiple ‘quirks’ in CoreTrust to bypass validation
• As mentioned earlier, a CMS signature can have multiple signers
• Question: did CoreTrust handle this case correctly?
• Same error variable used for each signer (if the last one was valid, they all were)
• The CD hashes returned to AMFI were collected from the rst signer (us)
• The policy ags were always set based on the second signer (App Store)
• By creating a crafted code signature with a fake App Store signer, you could bypass CoreTrust
fl
fi
fi
CVE-2023-41991
Entitlements

• Access to almost any entitlement

• Three entitlements are restricted to trustcache binaries only on arm64e
• com.apple.private.cs.debugger (act as a debugger)
• dynamic-codesigning (ability to create proper JIT mappings)
• com.apple.private.skip-library-validation (load any library into your process)
• Arbitrary entitlements open up many more attack surfaces
• Removing sandbox
• Access to restricted kernel drivers and userclients
• Spawning other binaries (with arbitrary UIDs and GIDs)
CVE-2023-41991
Main code directory

• SHA-1 code directory taken from a validly-signed App Store binary

• None of the hashes match our binary
• The kernel will only validate the hashes of the highest ranked code directory
• Matches the rst CD hash in the App Store signer’s signature blob
• Matches the rst CD hash in our custom signer’s signature blob
• Both signers need a common CD hash, so this is the one we use for that
fi
fi
CVE-2023-41991
Alternate code directory

• SHA-256 code directory containing the correct hashes for our binary
• All hashes are correct and will be validated by the kernel
• Does not match the second CD hash in the App Store signer’s signature blob
• Matches the second CD hash in our custom signer’s signature blob
• Meaning our custom signer contains two ‘correct’ CD hashes
CVE-2023-41991
Signature blob

• Contains two SignerInfo components

• Valid custom SignerInfo, matches our binary and custom certi cate chain
• Valid App Store SignerInfo, taken, intact, from an original App Store binary
• CoreTrust takes the CD hashes from the rst signer, the custom one
• CoreTrust uses the second signer, the App Store one, to set policy ags
• Finally, you just have to assemble the new code signature…
fi
fi
fl
TrollStore
Introduction

• We can permanently install applications with arbitrary entitlements

• The next step: develop a front-end installer for this exploit
• TrollStore is an on-device application installer
• It itself is signed with the CoreTrust bypass
• As are its helper binaries
• Uses arbitrary entitlements to install new applications like installd
TrollStore
App installations

• Uses a 'root helper’ to install applications

• The persona-mgmt, introduced in iOS 14, allows spawning binaries with an arbitrary UID and GID
• Spawning binaries as root is no longer allowed for non-root processes as of iOS 17.6, 18.0
• Accepts unsigned IPA les to be installed
• Signs all MachO les with the CoreTrust bypass
• Copies the bundle to the lesystem
• Creates any necessary containers
• Adds the application to the icon cache
• App appears on the Home Screen and is installed and usable like any other
fi
fi
fi
Problem #1
FrontBoard

• FrontBoard will perform a separate set of code signature checks on apps

• The checks are part of Security.framework, the same as am d
• Not vulnerable to the CoreTrust bypass
• FrontBoard does not perform these checks on system apps
• When adding apps to the icon cache, register them as system instead of user
• Has some minor side e ects
• App preference panes unavailable in Settings
• System icon cache refreshes will revert TrollStore and its apps to user registrations
ff
fi
Problem #1
FrontBoard

• Fugu15 got around this issue entirely by also

exploiting a vulnerability in Security.framework,
but more on that later

• Systemicon cache refreshes will reset all

TrollStore apps to user, rendering them unusable

• Solution: replace a legitimate system app’s main

binary with a ‘persistence helper’

• Survives icon cache refreshes

• Allows the user to refresh TrollStore app
registrations to system
Problem #2
installd

• installd performs the Security.framework checks on an app during installation

• This means we cannot simply sideload TrollStore like a regular app
• Instead, we have to install the application through other means
• Various methods of doing so have been used throughout:
• Bypassing installd’s code signature checks during installation
• Using a kernel exploit and/or privilege escalation to install TrollStore
• Using backups to restore les to arbitrary le paths
fi
fi
 TrollHelper OTA
iOS 14.0 - 15.6.1

• Two bugs found by Linus Henze

• CVE-2021-30773, patched incompletely in iOS 14.7
• CVE-2022-42792, patched in iOS 15.7
• Both vulnerabilities abused the fact that installd and the kernel could pick two
di erent slices of a fat MachO as the slice to validate or execute

• By making installd’s preferred slice a normal App Store binary, and the kernel’s
preferred slice TrollStore Helper, you could sideload or install the app via Safari

• Also allows an application to persist through icon cache reloads, because

FrontBoard’s checks would also be bypassed
ff
TrollInstallerX
iOS 14.0 - 16.6.1

• Developed by myself to install TrollStore from a sideloadable application

• Uses a kernel exploit and a PPL bypass (on arm64e) to escalate to root,
unsandbox and spawn the TrollStore helper binary that will perform a regular
installation of TrollStore

• On versions without a public PPLRW chain (iOS 16.6.x), it uses kernel exploit
primitives to install a persistence helper into a system app by abusing vnodes

• User can then open said app and install TrollStore via that
 TrollRestore
iOS 15.2 - 17.0

• Uses CVE-2024-44252, a vulnerability in the backup system that allows restoring les to arbitrary
le paths

• Uses some extra tricks to keep the executable bit on the le

• Restores a TrollStore Helper binary into a removable system app
• Avoids a proper restore by moving the binary to /var/backup/…
• FinishRestoreFromBackup is executed by launchd during boot, moving les into their nal paths
• For example, a le at /var/backup/var/test will be moved to /var/test
• Crashes the backup system early to prevent it from initiating a restore
• Reboots the device, user opens the system app and installs TrollStore
fi
fi
fi
fi
fi
fi
 Final result: permanent IPA
installations on iOS 14.0 - 17.0
Future of TrollStore
TrollStore 3?

• Root helpers are pretty much dead in this scenario of no LPEs

• Running the helper binary as other UIDs yields disappointing results
• CoreTrust is pretty strong now
• Essentially ignores any other signers completely
• Attack surface is pretty small for a CMS parser
• However, it’s been seen in-the-wild before, so maybe it could happen again
Dopamine
Dopamine
Overview

• Jailbreak for
• iOS 15.0 - 16.5 arm64e
• iOS 15.0 - 16.6.1 arm64
• Uses kernel exploit + PPL bypass to gain PPL R/W primitives

• Bypasses code signing system wide

• Enables tweak injection
Code Signature Validation
For Executables

• libsystem_kernel: posix_spawn(„/some/executable“, …), execve(„/some/

executable“, …)

• Kernel parses executable and nds code signature

• Kernel attaches code signature attached to executable vnode
• Kernel veri es code signature, if valid, allows execution
fi
fi
Code Signature Validation
For Libraries

• dlopen(„/some/library.dylib“)
• Dyld parses library and nds code signature
• Attaches signature to the le descriptor
• fcntl(fd, F_ADDFILESIGS, <code signature o set/size>)
• Then maps the executable segment via mmap()
• Kernel veri es that attached code signature is valid
fi
fi
fi
ff
Code Signature Validation
Valid under what conditions?

• Page hashes in code directory match page hashes of le?

• Hash of code directory is considered trustworthy by Kernel?
• Code directory is signed by Apple? (CoreTrust)
• Code directory is signed by a valid developer account? (am d)

fi
fi
Code Signature Validation
TrustCache Linked List

pmap_image4_trust_caches

CDHash(„/System/Library/
Caches/com.apple.dyld/
CDHash(„/usr/lib/dyld“) dyld_shared_cache“)

CDHash(„/sbin/launchd“) CDHash(„/System/Library/
Caches/com.apple.dyld/
<…> dyld_shared_cache.1“)

<…>
Code Signature Validation Bypass
TrustCache Injection using PPL R/W

pmap_image4_trust_caches

CDHash(„/System/Library/
Caches/com.apple.dyld/ CDHash(„/var/jb/basebin/
CDHash(„/usr/lib/dyld“) dyld_shared_cache“) launchdhook.dylib“)

CDHash(„/sbin/launchd“) CDHash(„/System/Library/ CDHash(„/var/jb/basebin/

Caches/com.apple.dyld/ jbctl“)
<…> dyld_shared_cache.1“)
<…>
<…>
Code Signature Validation Bypass
Requirements

• Hook fcntl in dyld to automatically add any library that’s about to me mapped
to TrustCache

• Requires static dyld patch

• Hook posix_spawn and execve in libsystem_kernel.dylib to add any
executable that’s about to be executed to TrustCache

• Requires dylib injected into every process

Code Signature Validation Bypass
Additional Challenges

• Static dyld patch

• Requires „replacing“ /usr/lib/dyld on the lesystem, which is read-only
• Requires infrastructure to merge executable code into dyld
• System wide posix_spawn and execve hook
• Overwriting executable pages is locked behind CS_DEBUGGED (arm64) and pmap-
>wx_allowed (arm64e)

• „DYLD_INSERT_LIBRARIES“ environment variable is only allowed in processes with the

„get-task-allow“ entitlement

• Adding CDHashes to TrustCache requires PPL R/W, so we need to outsource this to a

daemon and have the system wide hook talk to it
fi
Jailbreak Server
Hosting a mach server in launchd

• Idea: Server with PPL R/W that the entire system can talk to via IPC
• Victim: launchd, accessible system wide
• Server can then
• Add CDHashes to TrustCache
• Provide any additional functionality utilizing the primitives that we need for
the jailbreak
Jailbreaking: Step by Step

• Going through the entire jailbreak process step by step

• Relevant changes for the current step are colored in yellow
Jailbreaking: Step by Step

• Use Kernel Exploit to

Kernel Exploit get Kernel R/W
primitives

Dopamine.app Kernel R/W

Page Table

Userspace
Pages
 Jailbreaking: Step by Step

• Use Kernel R/W to chain

PPL Bypass PPL bypass

• Use PPL bypass to add

kernelspace pages
Dopamine.app Kernel R/W (gPhysBase ->
gPhysBase + gPhysSize)
to our own process
Page Table
• E ectively escalates from
Userspace Kernelspace Kernel R/W to PPL R/W
Pages Pages
ff
Jailbreaking: Step by Step

• Use PPL R/W to escalate

ucred->uid = 0
ucred->label = NULL
Dopamine process to unsandbox
the process and get root

Dopamine.app PPL R/W

Page Table

Userspace Kernelspace
Pages Pages
Jailbreaking: Step by Step

• Extract BaseBin tar to

BaseBin.tar
Extract
Filesystem Filesystem

• Contains les for post

jailbreak environment
Dopamine.app PPL R/W
• Contains prebuilt
TrustCache containing all
CDHashes for executables
Page Table and libraries in it
Userspace Kernelspace
Pages Pages
fi
Jailbreaking: Step by Step

pmap_image4_trust_caches
BaseBin • Use PPL R/W to upload
Stock basebin.tc into Kernel
TrustCache memory
basebin.tc

Jailbreak
• Add to linked list of
BaseBin TrustCaches
TrustCache
Dopamine.app PPL R/W • Allows BaseBin binaries
to execute

• Allows BaseBin libraries

Page Table to be mapped into all
Userspace Kernelspace processes
Pages Pages
Jailbreaking: Step by Step

initports[2] launchd
• Host mach server inside
Dopamine

jbctl BaseBin • Spawn jbctl from basebin

and pass mach port to it via
posix_spawn attribute
Mach
Server
Dopamine.app PPL R/W • jbctl gets task port to
launchd and stores mach
server port into it’s initports
Page Table via mach_ports_register
Userspace Kernelspace
Pages Pages
Jailbreaking: Step by Step

initports[2] launchd launchdhook.dylib

• opainject: Tool to inject dylib
into running process

opainject BaseBin • Uses task port to create a

thread that will run dlopen

Mach
• Use opainject to inject
Server
Dopamine.app PPL R/W launchdhook.dylib into
launchd

Page Table

Userspace Kernelspace
Pages Pages
Jailbreaking: Step by Step

initports[2] launchd launchdhook.dylib • We now have code execution

inside launchd using
launchdhook.dylib
Page Table PPL R/W

Userspace Kernelspace • launchdhook.dylib can use

Pages Pages
port stashed into initports[2]
Mach
to talk back to Dopamine app
Dopamine.app PPL R/W
Server
• Tell Dopamine mach server to
transfer PPL R/W to launchd
Page Table by adding the kernelspace
mapping to the page table of
Userspace
Pages
Kernelspace
Pages
launchd
Jailbreaking: Step by Step

• launchdhook can now

Hook intercept messages being
sent to launchd’s already
existing mach server
Server launchd launchdhook.dylib

• Check for speci c magic to

Page Table PPL R/W
distinguish between stock
and jailbreak messages
Userspace Kernelspace

Process
Pages Pages
• Add logic to process jailbreak
related messages, utilizing it’s
PPL R/W capabilities
fi
Jailbreaking: Step by Step

Filesystem BaseBin • Copy /usr/lib to /var/jb/

basebin/.fakelib
Copy
/usr/lib/ .fakelib

Mach
Dopamine.app PPL R/W
Server

Page Table

Userspace Kernelspace
Pages Pages
 Jailbreaking: Step by Step

BaseBin .fakelib dyld

• Merge hook library into dyld

dyldhook.merge.dylib MachOMerger

Mach
Dopamine.app PPL R/W
Server

Page Table

Userspace Kernelspace
Pages Pages
Patching the Dynamic Linker (dyld)

• We can reuse Fugu15_Rootful’s MachOMerger

• Allows us to statically merge the stock dyld together with a library compiled
by us

• Can only use library functions already in dyld, need to reimplement a lot
• We can hijack dyld_start to get code execution right when the process starts
• We can hook any function we want by replacing it with a trampoline to our
code

• Additionally, we can apply manual shellcode patches to dyld as well

dyld Patch #1
Unrestricting Environment Variables

• Normally, DYLD_* environment variables are restricted in most processes

• dyld uses a syscall to get „AMFI ags“ for current process
• We can patch dyld to prevent this syscall and to always make it use „0x “ as
the AMFI ags, which removes all restrictions on environment variables

• Then we can use DYLD_INSERT_LIBRARIES to insert additional libraries into

processes (LD_PRELOAD equivalent)
fl
fl
ff
dyld Patch #2
Bypassing Library Validation

• All executable segments have to have a valid code signature attached to

them to be mapped executable

• When mapping a library, dyld will call the fcntl syscall with F_ADDFILESIGS
and pass the code signature o set and size to that

• This makes the Kernel attach a code signature, which allows a later mmap()
call to succeed

• To fully bypass library validation, we can hook fcntl to automatically add the
code signature to TrustCache by sending it to the jailbreak server
ff
dyld Patch #3
Entry Point

launchd
• Redirect the entry point of dyld to our own code
launchdhook.dylib • Send „check-in“ message to jailbreak server in
launchd

• Allows jailbreak server to apply patches to a

Response Check-In
processes kernel structure on startup and return
data to the calling process

dyld

Process
Process Patch #1
Bypassing Page Validation

• Normally, writing unsigned executable code is strictly prohibited

• Only allowed for processes speci cally signed to allow debuggers
• We need to bypass this to hook functions outside of dyld
• (In dyld we can hook functions since we are statically patching and resigning it
and our patches will therefore have a valid code signature)

• Set CS_DEBUGGED (arm64) / pmap->wx_allowed (arm64e) on process structure in

kernel memory in check-in handler

• This makes the system think the process is debugged, which makes it allow
writing unsigned executable code
fi
Process Patch #2
Bypassing Sandbox Restrictions

• We want to weaken the sandbox so that any process will be able to access
the jailbreak les at „/var/jb“

• Generate „sandbox extension“ tokens in launchd and include them in the

check-in response message

• Read-access to „/var/jb“
• Read-write-access to „/var/jb/var/mobile“
• Reimplement various syscalls in dyldhook to consume sandbox extension in
the local process, granting the permissions we want
fi
Jailbreaking: Step by Step

mount
BaseBin .fakelib /usr/lib/ Filesystem • Mount /var/jb/basebin/.fakelib
on top of /usr/lib

jbctl
• Using bindfs mount
• Requires
„com.apple.private.bindfs-
Mach
Server
Dopamine.app PPL R/W allow“ entitlement

• Normally prohibited by
sandbox, need to steal kernel
Page Table
credentials in jbctl (omitted
Userspace Kernelspace for simplicity)
Pages Pages
Systemwide Hook
Code Signature Validation Bypass

• Hooks posix_spawn and execve to automatically add executables to

TrustCache

• Reinjects „DYLD_INSERT_LIBRARIES=systemhook.dylib“ into all child

processes

• Kickstarted inside launchdhook

• launchdhook injects systemhook into all processes spawned by launchd
• systemhook reinjects itself into all processes spawned by something else
Jailbreaking: Step by Step
Summary

• Code signing is now fully bypassed for any new processes that spawn
• What about the old processes?
• We need to reboot the userspace!
• During a userspace reboot, launchd will call execve on itself
• We need to nd a way to preserve the jailbreak through that
• Then all we need to do is reboot the userspace and the device will be fully
jailbroken
fi
Userspace Reboot: Step by Step

• Some process requests a userspace

Re-exec reboot

Hook • Launchd runs kill(-1) to kill all processes

running on the system
launchd launchdhook.dylib
• Then re-exec’s itself using posix_spawn
reboot3(RB2_USERREBOOT)
with POSIX_SPAWN_SETEXEC

Process
• Intercept posix_spawn call right before
re-exec by hooking it
Userspace Reboot: Step by Step

initports[2] boomerang BaseBin • Start temporary server inside

launchd for communication
spawn • Spawn boomerang, pass mach
port to it via it’s initports
Hook
• Boomerang can now talk to
temporary server for further
actions

Server launchd launchdhook.dylib

 Userspace Reboot: Step by Step
Userspace Kernelspace
Pages Pages

Page Table
• Boomerang tells temporary
initports[2] boomerang PPL R/W
server to transfer the PPL R/W
primitive and other important
stu to it’s process
Hook
• Server uses PPL R/W to add
kernelspace pages to page
Server launchd launchdhook.dylib table of boomerang

PPL R/W
• Boomerang now stores
Page Table primitives to persist them
across userspace reboot
Userspace Kernelspace
Pages Pages
ff
Userspace Reboot: Step by Step
Userspace Kernelspace
Pages Pages

Page Table
• Boomerang creates temporary
Server boomerang PPL R/W
server

• Stashes port in launchd’s

Hook initports
re-exec
• Boomerang tells launchd it’s
initports[2] launchd launchdhook.dylib done, which makes launchd tear
down it’s temporary server

Page Table
PPL R/W
• launchd triggers re-exec
Userspace Kernelspace
Pages Pages
Userspace Reboot: Step by Step
Userspace Kernelspace
Pages Pages

Page Table
• launchd is reexecuted with
Server boomerang PPL R/W
launchdhook.dylib reinjected

• New launchd no longer has

PPL R/W

• Connection to boomerang in
initports[2] launchd launchdhook.dylib initports is retained

• Boomerang retains PPL R/W

Page Table primitives

Userspace
Pages
Userspace Reboot: Step by Step
Userspace Kernelspace
Pages Pages

Page Table
• launchdhook.dylib tells
Server boomerang PPL R/W
boomerang server to transfer
PPL R/W and other related
primitives / o sets back to it

• Boomerang uses it’s PPL R/W

primitives to add the
initports[2] launchd launchdhook.dylib kernelspace pages to the page
table of the new launchd

Page Table • New launchd now has PPL R/W

and tells boomerang to exit
Userspace Kernelspace
Pages Pages
ff
Userspace Reboot: Step by Step

• New launchd now has PPL R/W and tells

boomerang to exit

launchd launchdhook.dylib • Other hooks are reapplied in launchd

• Launchd now continues the userspace
reboot as it normally would
Page Table PPL R/W

Userspace Kernelspace
• The entire userspace is restarted with the
Pages Pages jailbreak patches in place
 Summary

• Code signing is now bypassed for the entire system

• Procursus bootstrap and package manager installed on rst jailbreak
• Tweak injection is enabled by an additional dlopen call on the tweak loader
library from within systemhook.dylib

• Jailbreak apps are added to icon cache by additional launch daemon added
by the jailbreak

• Pro t???
fi
fi
Final result: semi untethered
jailbreak for iOS 15 and 16
 The End
Questions?
(We probably don’t have time for those)