mirror of
https://github.com/fenleon/open-madrid.git
synced 2026-10-22 16:12:35 +00:00
registration: the register body reaches capture parity (rev 48) — NGM identity client-data + gzip; machine register added
The trapped wa/register frames (ob-trap-20261014-201103 frame-025/026/051/052) decode to two registers: the full user register (x-auth families) and a machine-only register (services: [], push-only signature, fresh stamp). Our body was a stub: client-data carried only client-data-version. MadridIdentity ports the NGM identity (EC signing + RSA-1280 enc + EC device key + EC prekey — the genuine enc key IS RSA-1280), the identity-key DER (249 B at 1280), the prekey-data protobuf (109 B), kt-loggable-data (40 B), and the ~47 captured capability booleans. The request body is gzipped (C3 resolved by capture). Live: both registers answer 6004 ActionRetryWithNewAbsintheContext (SED server-session record in the message); the stored delegate credentials now answer 6008 at §1.2 authenticate.
This commit is contained in:
1 parent
2b96445cb4
commit
03f0ce12df
6 files changed
+409
-9
No files matched your search
@@ -111,7 +111,7 @@ A binary blob proving the client is a genuine Apple device; every registration s
|
||||
- `cpim`: an OUTER 276-B message `[u32be(5)][iv 16][u32be(160)][encout 160][X 32][u32be(52)][u32be(4)][Y 52]`; the 160-B plaintext = `u32be(32) ‖ encsec(rng2) ‖ u32be(32) ‖ rng1 ‖ 60 B blob (caller-extra ‖ rng3 pad) ‖ u64be(−2) ‖ u32be(unix-seconds) ‖ u32be(1) ‖ 12 fresh RNG bytes`. The IV is 16 plain RNG bytes; X = `SHA-256(encout ‖ spim_map_signature(trailing[0:16]) ‖ fixed 24-byte .rodata filler)` — written to the wire byte-exact (rev 29 closes the X32/12-B-tail/trailing-head TODOs; the earlier "constant sig block" and "sig16 not on the wire" readings are corrected).
|
||||
- `ptm`: `[u32be(4)][seed 16][u32be(payloadLen)][payload][tail]`; key16 = `encrypt(session, NULL iv, tk)`; block count = payloadLen/16; the finish gate is the decrypt output's `out[408:440] == rng1` echo. ProvisionedData = `{metadata: Vec (400 B live = decrypt out[4:404], length u32be at out[0]), client_secret = rng2 (32 B), mid = rng3 (60 B), flavor u8}`.
|
||||
|
||||
**Live-mint status (as of rev 47):** the full chain runs live on-device — export-code parse, hardware serialization byte-identical to capture, Apple-ID login with 2FA, fresh-blob mint accepted at step 2 through the rustls transport, courier connected, Albert activation accepted. Current blocker: the delegate sign-in's `400 ICLOUD_INVALID_DEVICE_TOKEN` (rev 45). **Rev 47 EXONERATES the §1.1 mint itself:** the Kotlin mint reproduces an accepted genuine stamp byte-for-byte from recovered live inputs (`NacValidationTest.mintReproducesLiveVendoredStamp` — body576 from the trapped sign-entry ctx, session250 == the genuine descrambler's own inversion, rngPad130 recovered by XOR-inverting the scramble chain via the genuine .so's `domergestep2`, whose `dm(x, in2) = state(in2) ⊕ x` makes every group invertible). The session-32 "rng_pad130 of scrambleBody" verdict is corrected: the pad is genuine thread-RNG filled INSIDE `scramble_body` (two code paths — a `len == 0x17c` fast path and an RNG-fill loop for shorter data; disasm 0x179654d), the scramble input buffer's caller-side tail is not the pad, and the descrambler inverts our stamps cleanly. Also eliminated live: the TLS transport (our rustls 0.20.9/0.21 ClientHellos are byte-equivalent to the reference's — captured via a write/writev interceptor — and stamps minted through either from a genuine blob still 400), the request shape (pass/fail prefpane requests are structurally identical), and stamp staleness. **The remaining discriminator is the machine's IDS registration freshness:** the reference's launch flow runs §1.4 `TDIdentityService/wa/register` TWICE *before* the delegate sign-in (trapped wire), its completed re-registrations (`id_cache.plist` write) are followed by our only two passes, and a pre-prefpane §1.2+§1.4 re-registration attempt on our side reaches the register endpoint but answers **6004 transient-retry** (§1.2 authenticate passes with the stored delegate credentials). Next: chase 6004 (retry/backoff, register-body diff vs the trapped `wa/register` frames) and consider registering before the prefpane as the standing flow.
|
||||
**Live-mint status (as of rev 48):** the full chain runs live on-device — export-code parse, hardware serialization byte-identical to capture, Apple-ID login with 2FA, fresh-blob mint accepted at step 2 through the rustls transport, courier connected, Albert activation accepted. Current blockers (rev 48): the §1.4 register answers **6004 = `ActionRetryWithNewAbsintheContext`** (both the machine-only register, `services: []` + push-only signature per the trapped wire's register #2, and the full user register; the response's SED message is a server-side VEN session record, not a stamp echo), and the §1.2 authenticate with the stored delegate credentials answers **6008** (stale delegate token — the delegate token dies within hours). The §1.4 register body is now capture parity (rev 48): full NGM identity `client-data` + gzip request body; the register body was a stub before.
|
||||
|
||||
### 1.2 Activation endpoints and certificates
|
||||
|
||||
@@ -562,6 +562,8 @@ Each item names its arbitration path. Closed residue is noted inline.
|
||||
|
||||
## Revision history
|
||||
|
||||
- **Rev 48 (2026-10-16 evening):** the §1.4 register body was a STUB — now capture parity. The trapped `wa/register` frames decoded (frame-025/026 = the full user register, frame-051/052 = a second MACHINE register): the genuine body carries the full madrid NGM identity in `client-data` (identity-key = DER SEQ{[1] u16be‖uncompressed P-256 signing point, [2] u16be‖RSA-1280 PKCS#1 DER} = 249 B; prekey-data = protobuf `PreKeyData{x32, ECDSA-SHA256 raw sig over "NGMPrekeySignature"‖x‖f64-le ts, ts}` = 109 B; `kt-loggable-data` = protobuf `{deviceIdentity{x32}, ngmVersion 13, ktVersion 5}` = 40 B) plus the ~47 captured capability booleans. Ported as `MadridIdentity` (four persisted keys: EC signing, RSA-1280 enc, EC device key, EC prekey — the genuine's enc key IS RSA-1280, `Rsa::generate(1280)` in rustpush). The register request body is GZIPPED (`content-encoding: gzip` — C3 resolved by capture; the "un-gzipped lower-assumption" choice was wrong). The genuine wire's register #2 = machine-only register: `services: []`, NO `x-auth-*` headers (push-only signature), fresh stamp — implemented as the first `idsRegister` step. **Live: both our machine register AND the full register answer `6004`** — decoded via [IG:idserrors]: **6004 = `ActionRetryWithNewAbsintheContext`**, with `message` = an SED server-session token `SED:3:VEN-PROD:<uuid>:<uuid>:<mint-epoch>:<uuid>:<hash>:EM` (all fields server-side: the hash ≠ sha256(stamp), UUIDs rotate per attempt). Separately: the §1.2 authenticate with the stored delegate credentials now answers **6008 (no cert)** — the delegate token went stale hours after session 33's pass. Open questions: whether the reference's register #1 also 6004s (responses not captured — the trap hooks writes only), and what "new absinthe context" concretely means when the register carries no anisette (the stamp's VEN session is the only context it rides).
|
||||
|
||||
- **Rev 47 (2026-10-16):** §1.1 mint EXONERATED on live data — the Kotlin mint reproduces an accepted genuine stamp byte-for-byte from recovered inputs (pad recovered by inverting the scramble chain; `domergestep2` is XOR-invertible). The session-32 "rng_pad130" verdict is corrected: the scramble pad is thread-RNG filled inside `scramble_body` (second code path, disasm 0x179654d). Transport (rustls ClientHello byte-equivalence), request shape, and staleness eliminated live. The prefpane `ICLOUD_INVALID_DEVICE_TOKEN` blocker narrows to the machine's IDS registration freshness: the reference runs §1.4 register ×2 before the delegate sign-in, and a pre-prefpane register on our side answers 6004 transient-retry.
|
||||
|
||||
One line per revision, newest first. Details live in the sections above and in `registration/dev/clearadi/captures/`.
|
||||
|
||||
Reference in new issue
Block a user