App Store Decryption

[marioparaschiv]

Is your feature request related to a problem? Please describe.

On ARM Macs, it seems to be possible (correct me if I’m wrong) to decrypt iOS App Store apps.

This would be useful for decrypting apps to analyze them further and potentially tweak them.

Describe the solution you'd like

ipsw app-decrypt —-region us

Describe alternatives you've considered

https://github.com/meme/apple-tools/tree/master/foulplay
https://github.com/paradiseduo/appdecrypt?tab=readme-ov-file

Search

• I did search for other open and closed issues before opening this

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

No response

[blacktop]

it was my understanding that you needed to be running on an old version of macOS for it to work?

[blacktop]

https://github.com/blacktop/ipsw/blob/master/pkg/fairplay/fairplay.go I wrote this 7 months ago; didn't have an OLD mac to try it on.

[blacktop]

if you have a machine it'll work on; I can spin up a cmd; but you can also write a simple Go CLI and import that pkg I linked:

import "github.com/blacktop/ipsw/pkg/fairplay"

[marioparaschiv]

My apologies, that's a crucial detail I missed!

Unfortunately, I don't have access to a MacOS version that supports this exploit :(

Thank you for your quick response time.

If anyone else reading this has a compatible MacOS version, give the above a try and it could potentially make it into ipsw as ipsw fairplay or something of the sort if @blacktop wishes to add this.

[ink-splatters]

Hi everyone, I recall decrypting some app on macOS Big Sur 11.2.3 with something using

extern int mremap_encrypted(void*, size_t, uint32_t, uint32_t, uint32_t);

under the hood (likely: UnFairPlay)

I've Apple M1 and I could test the fix if you implement it.

For the purpose above but actually more - for the sake of being able to run any iOS app compatible with Big Sur iOS ABI, I keep Big Sur 11.2.3, installable as a side system in just a few mins.

Since my installer is not releasable (yet), click here for details if interested

macOS versions before introducing Cryptex1 can be installed as main system or as additional system (to existing container) from any running Recovery, including after Erase this Mac and follow-up activation; from the following preserved artifacts:

• System VG or just System Volume (with sealed snapshot; you add Data role volume with diskutil to create a VG and then populate it with System template);
• Preboot vol (boot, restore and usr, personalized earlier for the same machine);
• Recovery Vol

NOTES

• 1TR is non-functional in Big Sur installed using this method, hence no security downgrades, but not an issue for decryption purpose, to my best knowledge;

• I personally store the above artifacts as DMG with System VG, pre-populated with template, and Preboot and Recovery assets on role-less volume in the same DMG container. This is because I don't think it's trivial to clone a volume with boot or recovery roles, so you create those if needed, upon install.

• beware: modern ditto has lost its ability to correctly preserve com.apple.rootless xattr (--preserveRootless)

So roughly it can be described as:

hdiutil attach -nomount -noverify -owners on -shadow $(mktemp) <dmg with artifacts>
diskutil mount <system vol device from dmg>
diskutil mount <artifacts vol device from dmg>

snap=<system vol sealed snapshot> # get with diskutil apfs listSnapshots

diskutil apfs addVolume <target container> APFS Preboot -role B # if doesn't exist
diskutil apfs addVolume <target container> APFS Recovery -role R # if doesn't exist
diskutil apfs addVolume <source container> APFS Data -role D -groupWith <system vol device> # if VG is not there already

asr restore -s <system vol device> -t <target system vol device> --erase --toSnapshot $snap --noverify -noprompt

diskutil mount <restored data volume aka Data>
diskutil enableOwnership <Data>

mkdir /tmp/s
mount_apfs -s $snap <device> /tmp/s
pushd /tmp/s/System/Library/Templates/Data
cp -a . <Data> # preserves rootless, doesn't preserve xattrs
ditto --rsrc --extattr --preserveHFSCompression . <Data> # vice-versa
popd || true

vg=<UUID> # get target VG uuid using `diskutil apfs listVolumeGroups`

cd /
diskutil mount <preboot device> # if not already
diskutil mount <recovery device> # if not already
mkdir <Preboot>/$vg
ditto --rsrc --extattr --preserveHFSCompression <preboot artifacts> <Preboot>/$vg

mkdir <Recovery>/$vg
ditto --rsrc --extattr --preserveHFSCompression <recovery artifacts> <Recovery>/$vg

diskutil mount <target system vol device>
diskutil apfs updatePreboot <target system vol>

bless --setBoot --device <target system vol device>

<enter> #empty usr name
<enter> #empty password

It may ask you owners approval, if it's not main system.

Reboot

PS: there is a likehood that Cryptex1-based system can be enabled with the same method, after Big Sur is set up as main system first, via Owner approval from booted Big Sur

[blacktop]

you have a system ready to test @ink-splatters ? I could make a initially hidden command that you could try out?

[ink-splatters]

you have a system ready to test @ink-splatters ? I could make a initially hidden command that you could try out?

Yes! I can make it ready ASAP. SIP will be on (shouldn't be an issue, but just sayin'). For SIP control I would need to DFU restore to Big Sur (you can't load Big Sur 1TR if it's side- installed). That's also possible but will need a bit more time as there is some data on this machine.

[blacktop]

@ink-splatters a prerelease should be auto-generated (or you can build from source) to try out the NEW 'hidden' meaning it doesn't show up in --help ipsw macho decrypt command; please let me know how it goes

[ink-splatters]

@ink-splatters a prerelease should be auto-generated (or you can build from source) to try out the NEW 'hidden' meaning it doesn't show up in --help ipsw macho decrypt command; please let me know how it goes

TL;DR: negative, unfortunately

Details: not much for now but I observed two ways of it not working:

• mmap_recrypt returned error (the only result from ipsw I obtained)
• the same plus sometimes mmap failing with "invalid argument" (result from unfairplay

The exact error (mmap_recrypt) I lost unfortunately as it's gone with Big Sur which I already ditched, but it was fairplay error.

I tried:

• IPAs downloaded with (ipatool)[https://github.com/majd/ipatool] (with App Store logged in with the same acc; as I don't know much about decryption stack, it might or might not have sense, the later - if SINF metadata needs to be processed in order to derive decryption key, which IDK)
• IPA I installed from AppStore (iOS apps allowed to run on Apple Silicon)

Not tried yet: random decrypted app form the internets, installable with Sideloadly

TODO

this was result from testing in side-installed Big Sur. AFAIK some/most of Big Sur firmware doesn't get used (and for sure Big Sur recovery can't be loaded) due to obvious security concerns.

just in case it might've affected the results via blocking decryption at firmware / SEP level (which I don't know but can anticipate), I want to DFU restore from Big Sur 11.2.3 image and try again.

Compatibility issue

The builds produced by go1.25 are not runnable on Big Sur. I created a compat shim to mitigate this and filed you a PR which adds a goreleaser config to build with this shim on, just in case you are interested.

FYI it can be used not only from go, but as dylib. This way I also was able to run toolchain itself:

❯ DYLD_INSERT_LIBRARIES="<shim dylib>" DYLD_FORCE_FLAT_NAMESPACE=1 go version
go version go1.25.4 darwin/arm64