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

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

Code of Conduct

• [x] 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