Publish Cryptex1 DDI assets, and a script to refresh them

[doronz88]

Why

iOS 17+ can have the DeveloperDiskImage installed as a cryptex through cryptexd, rather than mounted through the image mounter. That path needs four Cryptex1,* payloads which exist only inside Xcode's own bundle — the personalized variant published here ships PersonalizedDMG, which has no cryptex info plist or volume root hash. So today a host without Xcode (notably Windows) cannot install a DDI that way at all.

This publishes those assets as their own variant, and adds a script so refreshing every variant is reproducible instead of a manual copy out of /Library/Developer.

What's here

• update_ddi.py — a PEP 723 script (no third-party deps, uv run --script update_ddi.py). It locates the platform's Restore directory, attaching CoreDevice/CandidateDDIs/<platform>_DDI.dmg when Xcode has not expanded one, verifies every payload against the SHA-384 digests in the build manifest, and removes stale files left by a previous build. Has --dry-run, --platform, --variant.
• PersonalizedImages/Xcode_iOS_DDI_Cryptex/ — the new variant.
• get_cryptex_disk_image() — returns the four payloads plus the build manifest.
• DDIs updated to 27A5228h (personalized was 27A5194q).
• Payloads now come from raw.githubusercontent.com instead of the REST API.

Predictable names

Every payload is published under a fixed name (Image.dmg, Image.dmg.trustcache, Image.dmg.cryptex_info, Image.dmg.root_hash), so download URLs are stable across releases. Apple's own paths embed a build number (022-22107-072.dmg), so the published BuildManifest.plist is rewritten to declare the fixed names. Only Info.Path is adjusted — the digests personalization relies on are untouched — which keeps a downloaded cryptex directory usable as a drop-in Restore directory.

No more rate limiting

Reading blobs through the REST API cost a recursive tree listing of a repository full of disk images on every create(), and burned the anonymous 60-per-hour quota — which is why the tests were xfailed on GithubRateLimitExceededError instead of simply expected to pass. raw.githubusercontent.com is not under that quota, needs no token, and serves any ref. Since every payload now sits at a known fixed path, the tree listing bought nothing.

Consequently create() performs no request at all and takes a ref, so the tests check the revision under test rather than main — previously a PR adding payloads could not see its own files and could only go green after merging. API change: DeveloperDiskImageRepository.__init__ no longer takes a tree.

Verification

The published directory was used to install the DDI on a physical iPhone 11 (iOS 27) end to end, over cryptexd alone, via pymobiledevice3 cryptex auto-install --restore-dir <this directory>. Digest verification passes for every payload; the script is idempotent (a second run reports zero changes) and each commit is flake8/isort clean.

Follow-up

LATEST_DDI_BUILD_ID in pymobiledevice3 needs bumping to 27A5228h, and cryptex auto-install can drop its Xcode requirement once a developer_disk_image release carries get_cryptex_disk_image().