Megathread: New, unsupported SC_Info rolling out to iOS 26 devices resulting in decryption failures.

[vnc0]

The README states ipadecrypt decrypts iOS 26 apps. Based on my file-format research on the FairPlay SC_Info key files (https://github.com/vnc0/fairplay-scinfo), there is a class of binaries where this cannot work on a pre-26 device. While the issue is currently only noticeable in a handful of apps, I expect it to affect a wider range of apps in the near future.

Background

iOS 26 introduced new SC_Info key-file variants — .v4.supp (version byte 0x04) and .v5.supf (0x05) — alongside the legacy .supp (0x01) / .supf (0x03). For most apps both generations ship side by side, so a pre-26 kernel can still use the legacy pair.

For binaries that are iOS-26-only, Apple stops shipping the legacy pair: the .supp is absent and the .supf is truncated to 0 bytes, leaving only the new .v4.supp / .v5.supf.

Examples in the wild:

• com.microsoft.rdc.ios 11.3.2 — main binary
• com.gopro.GoPro 13.34.1 — ReelSteady.framework

Impact

The v4/v5 key formats are only understood by the FairPlay subsystem on iOS 26+. On a pre-26 kernel the key material these binaries need is not in a recognized format, and the legacy files such a kernel would understand are gone. Forcing page decryption therefore fails with mremap_encrypted() => -1. The rest of the app may decrypt fine; only the iOS-26-only binaries fail.

Proposed Solutions & Next Steps

Assuming this is a strict kernel-level constraint with no userspace workaround, a true fix will likely have to wait until an iOS 26 jailbreak exists. (That said, if my assumption is incorrect and there is an existing way to parse or feed these new structures to an older kernel, I would be highly interested in a hint!)

In the meantime, it would help to detect this case early rather than failing silently. Before attempting decryption, ipadecrypt could check whether the legacy .supp/.supf are present and non-empty. If not, abort with a clear message:

Error: <Binary> has no legacy SC_Info (iOS-26-only binary). Decryption on a pre-26 device is not possible.

Alternatively, a note in the README under known limitations would at least prevent confusion for users who hit this today.

[londek]

Yep I'm aware of this. I was working on this but hit a dead end while trying to

• emulate key derivation from iOS 26 firmware locally
• inject derived keys into fairplay kext
• translate v5 format to the older one

Could be that newer devices have new hardware to do just this and my iPhone 8 Plus just can't do it.

I was also thinking about adding an error, but at this time I've only spotted it on X app, now it feels more in place.

In any case if anyone wants to pick up (with AI or without) this feel free to do so and share more information here. I will make this into a megathread.

[jared1467321]

Unfortunately I don’t have any answers, but I think this can be helpful regardless. This app is only iOS 17 minimum requirement, and therefore has the regular supf file for the main binary. BUT the extension inside has the 0 byte supf file, with only the v5 supf containing any data, but using this tool, it still decrypts properly. I’m not sure if Im just tired and something isn’t clicking for me right now, but without a supf format the kernel understands, that extension shouldn’t be getting decrypted?? I wish I had answers, but I think there’s hope without waiting for an iOS 26 jailbreak. Here’s the app if anyone is curious. https://apps.apple.com/us/app/yaiiu/id6757139615

[vnc0]

Unfortunately I don’t have any answers, but I think this can be helpful regardless. This app is only iOS 17 minimum requirement, and therefore has the regular supf file for the main binary. BUT the extension inside has the 0 byte supf file, with only the v5 supf containing any data, but using this tool, it still decrypts properly. I’m not sure if Im just tired and something isn’t clicking for me right now, but without a supf format the kernel understands, that extension shouldn’t be getting decrypted?? I wish I had answers, but I think there’s hope without waiting for an iOS 26 jailbreak. Here’s the app if anyone is curious. https://apps.apple.com/us/app/yaiiu/id6757139615

I dug into this specific one (BackgroundUploadExtension in YAIIU), and I'm pretty sure it's a tooling false positive - the extension isn't actually being decrypted. Tested on iOS 18.3.1 (iPad, A10 / fairplayd.A2, frida + IDA + Triton for debugging).

Structure is as you said: the app is iOS 17 min, but the extension is built for iOS 26 (minos 26.2.0) with a 0-byte legacy .supf and the real keys only in .v5.supf.

I traced fairplayd during a decrypt. The extension reads its 0-byte .supf, sees it's empty, and returns -42028 right away. That's an early parse-level bail, not a failed unwrap - a different path than the success route. The main binary reads a valid legacy .supf and goes through the whole verify+unwrap; the extension never gets that far. From what I can tell, fairplayd on iOS 18 and earlier only reads the legacy .supf, so the v5 keys are unreachable. Reconstructing a legacy .supf doesn't seem to help either - I tried, and it just fails the signature check (-42021).

I also tried patching the signature check out of fairplayd directly. Forcing the verdict to pass just moves the failure to the next check (-42018), and forcing a full "success" reply panics the device. Honestly, waiting a few days/weeks (?) for an usbliter8 based iOS 26/27 jailbreak is probably the easier route than any of this.

[londek]

I agree, moreover I've seen exactly the same (or at very least) same response codes from fairplayd binary when emulating it in unicorn.

About the minos dyld cmd, since this is extension, it was probably designed for newer oses on purpose - I've noticed this on other apps when testing with my betatesters. An example could be Dynamic Island handling extension (I'm just yapping there, not sure) where older versions don't have Dynamic Island - just an example.

Fairplayd being heavily obfuscated doesn't make it any easier.