Update README.md Add Simplified Chinese README and link Add README_zh-Hans.md containing a full Simplified Chinese translation of the project README and update README.md to include a link/badge to the new Chinese README. This makes the documentation accessible to zh-Hans readers.
7.7 KiB
BuildManifest.plist Research
1. Multi-Source Comparison
Identity Count Overview
| Source | Identities | DeviceClasses |
|---|---|---|
| iPhone 26.1 | 5 | All d47ap |
| iPhone 26.3 | 5 | All d47ap |
| CloudOS 26.1 | 6 | j236cap, j475dap, vphone600ap (x2), vresearch101ap (x2) |
| KnownWork 26.1 | 5 | All vresearch101ap |
CloudOS 26.1 Identity Structure (6 identities)
| Index | DeviceClass | Variant | BuildStyle | Manifest Keys |
|---|---|---|---|---|
| [0] | j236cap | Darwin Cloud Customer Erase Install (IPSW) | RELEASE build | 37 keys (server hardware) |
| [1] | j475dap | Darwin Cloud Customer Erase Install (IPSW) | unknown (no path) | 0 keys (empty placeholder) |
| [2] | vphone600ap | Darwin Cloud Customer Erase Install (IPSW) | RELEASE build | 29 keys (includes UI assets) |
| [3] | vresearch101ap | Darwin Cloud Customer Erase Install (IPSW) | RELEASE build | 20 keys (no UI assets) |
| [4] | vphone600ap | Research Darwin Cloud Customer Erase Install (IPSW) | RESEARCH_RELEASE build | 29 keys (research kernel) |
| [5] | vresearch101ap | Research Darwin Cloud Customer Erase Install (IPSW) | RESEARCH_RELEASE build | 20 keys (research kernel) |
Key distinctions:
- CloudOS[2] vs [4] (vphone600ap): [2] uses RELEASE boot chain + release kernelcache; [4] uses RESEARCH_RELEASE + research kernelcache + txm.iphoneos.research.im4p
- CloudOS[3] vs [5] (vresearch101ap): Same pattern — [3] is RELEASE, [5] is RESEARCH_RELEASE
- vphone600ap has components vresearch101ap lacks: RecoveryMode, AppleLogo, Battery*, RestoreLogo, SEP (vphone600 variant)
- vresearch101ap has only 20 manifest keys (no UI assets, no RecoveryMode)
vphone600ap vs vresearch101ap Key Differences
| Property | vphone600ap | vresearch101ap |
|---|---|---|
| Ap,ProductType | iPhone99,11 | ComputeModule14,2 |
| Ap,Target | VPHONE600AP | VRESEARCH101AP |
| ApBoardID | 0x91 | 0x90 |
| DeviceTree | DeviceTree.vphone600ap.im4p | DeviceTree.vresearch101ap.im4p |
| SEP | sep-firmware.vphone600.RELEASE.im4p | sep-firmware.vresearch101.RELEASE.im4p |
| RecoveryMode | recoverymode@2556~iphone-USBc.im4p | NOT PRESENT |
| MKB dt flag | dt=1 (keybag-less boot OK) | dt=0 (fatal keybag error) |
2. Component Source Tracing (Corrected)
Hybrid Identity: vresearch101 boot chain + vphone600 runtime
The working configuration mixes components from both board configs:
| Component | Source Identity | File | Why This Source |
|---|---|---|---|
| LLB | PROD (vresearch101 release) | LLB.vresearch101.RELEASE.im4p |
Matches DFU hardware (BDID 0x90) |
| iBSS | PROD | iBSS.vresearch101.RELEASE.im4p |
Matches DFU hardware |
| iBEC | PROD | iBEC.vresearch101.RELEASE.im4p |
Matches DFU hardware |
| iBoot | RES (vresearch101 research) | iBoot.vresearch101.RESEARCH_RELEASE.im4p |
Only research identity has iBoot |
| SPTM (all) | PROD | sptm.vresearch1.release.im4p |
Shared across board configs |
| TXM restore | PROD | txm.iphoneos.release.im4p |
RELEASE for restore |
| TXM installed | RES | txm.iphoneos.research.im4p |
Research variant, patched |
| DeviceTree | VP (vphone600 release) | DeviceTree.vphone600ap.im4p |
Sets MKB dt=1 |
| SEP/RestoreSEP | VP | sep-firmware.vphone600.RELEASE.im4p |
Must match device tree |
| KernelCache | VPR (vphone600 research) | kernelcache.research.vphone600 |
Patched by fw_patch.py |
| RestoreKernelCache | VP (vphone600 release) | kernelcache.release.vphone600 |
Unpatched, restore-time only |
| RecoveryMode | VP | recoverymode@2556~iphone-USBc.im4p |
Only vphone600ap has it |
| RestoreRamDisk | PROD | cloudOS erase ramdisk | PCC restore ramdisk |
| OS / SVC / etc. | I_ERASE (iPhone) | iPhone OS image | iPhone system |
Why Not All-vresearch101 or All-vphone600?
Problem with all-vresearch101: The vresearch101ap device tree sets MKB dt=0,
causing MKB_INIT: FATAL KEYBAG ERROR on first boot (no system keybag exists yet).
Also missing RecoveryMode entry.
Problem with all-vphone600: The DFU hardware identifies as BDID 0x90
(vresearch101ap). Using vphone600ap identity (BDID 0x91) fails TSS/SHSH signing
and idevicerestore identity matching (Unable to find a matching build identity).
Solution: vresearch101ap identity fields for DFU/TSS + vphone600 runtime components for a working boot environment.
3. idevicerestore Identity Selection Logic
Source: idevicerestore/src/idevicerestore.c lines 2195-2242
Matching Algorithm
idevicerestore selects a Build Identity by iterating through all BuildIdentities and returning the first match based on two fields:
Info.DeviceClass— case-insensitive match against devicehardware_modelInfo.Variant— substring match against the requested variant string
For DFU erase restore, the search variant is "Erase Install (IPSW)" (defined in idevicerestore.h).
Matching Modes
// Exact match
if (strcmp(str, variant) == 0) return ident;
// Partial match (when exact=0)
if (strstr(str, variant) && !strstr(str, "Research")) return ident;
Critical: Partial matching excludes variants containing "Research". This means:
"Darwin Cloud Customer Erase Install (IPSW)"— matches (contains "Erase Install (IPSW)", no "Research")"Research Darwin Cloud Customer Erase Install (IPSW)"— skipped (contains "Research")
What idevicerestore Does NOT Check
- ApBoardID / ApChipID (used after selection, not for matching)
- Identity index or count (no hardcoded indices)
Conclusion for Single Identity
A BuildManifest with one identity works fine. The loop iterates once, and if DeviceClass and Variant match, it's returned. No minimum identity count required.
4. TSS/SHSH Signing
The TSS request sent to gs.apple.com includes:
ApBoardID = 144(0x90) — must match vresearch101apApChipID = 65025(0xFE01)Ap,ProductType = ComputeModule14,2Ap,Target = VRESEARCH101AP- Digests for all 21 manifest components
Apple's TSS server signs based on these identity fields + component digests. Using vphone600ap identity (BDID 0x91) would fail because the DFU device reports BDID 0x90.
5. Final Design: Single DFU Erase Identity
Identity Metadata (fw_manifest.py)
DeviceClass = vresearch101ap (from C[PROD] deep copy)
Variant = Darwin Cloud Customer Erase Install (IPSW)
Ap,ProductType = ComputeModule14,2
Ap,Target = VRESEARCH101AP
Ap,TargetType = vresearch101
ApBoardID = 0x90
ApChipID = 0xFE01
FDRSupport = False
Source Variable Map
PROD = C[vresearch101ap release] — boot chain, SPTM, ramdisk
RES = C[vresearch101ap research] — iBoot, TXM research
VP = C[vphone600ap release] — DeviceTree, SEP, RestoreKernelCache, RecoveryMode
VPR = C[vphone600ap research] — KernelCache (patched by fw_patch.py)
I_ERASE = I[iPhone erase] — OS, trust caches, system volume
All 21 Manifest Entries
Boot chain (PROD): LLB, iBSS, iBEC
Research iBoot (RES): iBoot
Security monitors (PROD): Ap,RestoreSPTM, Ap,RestoreTXM, Ap,SPTM
Research TXM (RES): Ap,TXM
Device tree (VP): DeviceTree, RestoreDeviceTree
SEP (VP): SEP, RestoreSEP
Kernel (VPR/VP): KernelCache (research), RestoreKernelCache (release)
Recovery (VP): RecoveryMode
Ramdisk (PROD): RestoreRamDisk, RestoreTrustCache
iPhone OS (I_ERASE): OS, StaticTrustCache, SystemVolume, Ap,SVC Metadata
Restore.plist
DeviceMap: [d47ap (iPhone), vphone600ap, vresearch101ap]
ProductTypes: [iPhone17,3, ComputeModule14,1, ComputeModule14,2, Mac14,14, iPhone99,11]