Make fw_prepare pick the right cloudOS IPSW automatically

[felipejfc]

What changed

I updated fw_prepare.sh so it fills in CLOUDOS_SOURCE automatically when I don't pass one.

Instead of falling back to a single hardcoded cloudOS URL, it now:

• derives the build prefix from the selected iPhone IPSW
• looks up the PCC VM cloudOS catalog in AppleDB (ComputeModule14,2)
• picks the newest downloadable cloudOS IPSW with the same build prefix

I kept the manual override path the same, so --cloudos-source / CLOUDOS_SOURCE still win if I want to pin a specific cloudOS IPSW.

Why

I don't want to keep matching the cloudOS IPSW by hand every time I change the iPhone firmware. This makes the default path do the right thing and avoids mismatching the PCC firmware.

Quick check

• bash -n scripts/fw_prepare.sh
• sanity-checked that a 23D* iPhone build resolves to downloadable cloudOS 23D128 on AppleDB

[madelynmp1-lang]

why hasnt this been implemented yet?

[D4rkTT]

There's an issue in line 722 cp "$IPHONE_DIR/BuildManifest.plist" "$IPHONE_DIR/BuildManifest-iPhone.plist"
it should be cp "$IPHONE_DIR/BuildManifest.plist" "$IPHONE_DIR/iPhone-BuildManifest.plist" like original fw-prepare.sh
changing the BuildManifest name produce an error in any call to pymobiledevice3_bridge.py like make restore_get_shsh

[gilboz]

I second this, it is pretty annoying still.

Ideally we would just specify the iOS version and it would pull the relevant CloudOS kernel automatically. There's no real need for this separation for normal users.

Fetching the CloudOS downloads from AppleDB is one option, ipsw dl pcc --info from blacktop's tool also provides this functionality (and it checks

Also the README already contains a mapping to the relevant CloudOS release, so we could just have a mapping that manually translates the iOS version to the CloudOS download URI, these don't get released so often and anyway probably require manual intervention to modify patches, test, before having it supported officially.

[madelynmp1-lang]

@gilboz to be honest someone should have just written a gui manager by now for this to have a clean UI with drop down of ios versions and list of patch types etc

[gilboz]

@madelynmp1-lang Not sure if a GUI is what is missing, but I think having tons of shell scripts launched by a GNU Makefile is just a poor design choice. Many of the shell scripts incorporate inline python code kinda hard to maintain.

I think a much more reasonable approach would've been to write all the shell scripts as python scripts and package them normally with a cli tool including many subcommands, proper argparsing etc.

[madelynmp1-lang]

tons of android virtual machine softwares have GUI managers to manage instances, ram size, disk size etc

whether its bluestacks, mumu player or ldplayer