The trapped reference register (frame-026) is now matched field for field.
- RegisterServiceCatalog: the reference's four services in wire order
(madrid + multiplex1 + facetime.multi + ess), each row a constant from its
own source, with per-service capabilities/sub-services/client-data and a
per-service ec-version (real 1.0 on madrid, integer 1 on the other three
— the plist types differ).
- IdsHandleFetcher: id-get-handles, the bodiless signed GET the reference
calls per user before building the body; the register echoes the server's
handle list on every service instead of inventing one from the username.
- One prekey mint and one kt-loggable-data blob for the whole body: the
reference mints outside the service loop and clones, and the capture's
blobs are byte-identical across the four services.
- MadridIdentity.clientData now builds the six identity keys only; the
per-service capability keys come from the catalog row. Key order matches
the capture (top-level and per-user).
- RegisterServiceCatalogTest + IdsHandleFetcherTest pin the shape against a
PII-free projection of the capture
(registration/src/test/resources/imessage/register-reference-shape.plist).
Nothing here is verified against Apple yet — the next live register is the
first one whose body matches the oracle's.
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.
NacValidationTest.mintReproducesLiveVendoredStamp reproduces the accepted
genuine prefpane stamp byte-for-byte from recovered live inputs: the rngPad130
is recoverable from the stamp itself (domergestep2 is XOR-invertible —
dm(x, in2) = state(in2) XOR x), session250 is the genuine descrambler's own
inversion, and the scramble pad is thread-RNG filled inside scramble_body
(second code path, disasm 0x179654d) — the session-32 'rng_pad130' verdict is
corrected. Live A/Bs eliminate the TLS transport (ClientHello byte-equivalence),
request shape, and staleness; the prefpane ICLOUD_INVALID_DEVICE_TOKEN blocker
narrows to the machine's IDS registration freshness (the reference runs
wa/register x2 before the delegate sign-in; a pre-prefpane register on our side
answers 6004 transient-retry). Spec rev 47 + NAC-NOTES session-33 addendum.
The A/B ladder 2026-10-15/16: fresh postdata mint was not the prefpane discriminator —
the prefpane now passes with a fresh GENUINE stamp through the whole chain, pinning the
400 on the validation-data mint itself (rng_pad130 of scrambleBody).
The trapped-binary decode (2026-10-15) shows ONE anisette mint serves the whole session — GSA hops, 2FA validate, postdata, both prefpane POSTs — so the PET is paired with the OTP window it was issued under. The rev-25/26 'fresh set at the sign-in POST' reading is corrected (confounded with the replay-guard era). GsaLoginChain mints one cpd per login run and exposes it as lastLoginAnisette (Client-Time frozen at the mint); GsaDelegateLoginClient's prefpane branch reuses a supplied Client-Time instead of re-minting. VEN step-2 wire fact recorded in spec rev 46: zero anisette on initializeValidation, no step-2 binding. Also wire-proven live: the GSA init 'ps' field is REQUIRED (omission answers ec=-80001).
The first-ever capture of the binary's GSA init/complete/postdata/2FA requests
(static OpenSSL via ssl3_write_bytes; rustls only ever saw the prefpane path):
- cpd carries NO X-Apple-I-MD-LU (neither headers nor cpd) — dropped; the
keychainIdentifier constructor param is gone with the derivation.
- cpd 'at' is the plist INTEGER 0 (the boolean-false recording was also
live-accepted; the integer form is what the binary sends).
- GSA login headers: Accept */* added; casing aligned to the binary
(X-Mme-Client-Info, X-Apple-Ak-Context-Type).
- 2FA browser-style set: hardware-identity headers ride it as HTTP headers
(unlike the login POSTs); same casing alignment.
- ptkn rides every login cpd once the app holds a push token (imessage side
wires the persisted courier token).
- cpd gains the hardware-identity headers (SRL-NO/MLB/ROM chained last) — the
vendored get_cpd_data carries them in the login BODY; the gsservice HTTP
header set does NOT (the earlier reading had this inverted).
- GsaHeaderConfig.toHeaders(): drop the hardware headers, add Accept-Language
(get_gsservice_headers carries it).
- ProvisionedAnisette flavor doc corrected (FLAVOR_MAC=1/FLAVOR_IOS=0 — the
inverted doc caused the failed vendored-state swap, GSA ec=-22421).
- 'at' stays the recorded boolean false (vendored source writes Integer(0);
both live-accepted).
- GsaDelegateLogin: the prefpane anisette headers carry the accepted request's
exact wire casing (X-Apple-I-Md / -Md-M / -Md-Rinfo / X-Apple-Adsid /
X-Apple-I-Timezone — real AuthKit forms; the recorded GSA names are all-caps
and setup.icloud.com answers ICLOUD_INVALID_DEVICE_TOKEN with them at full
value parity). GSA keeps its recorded working set.
- GsaHeaderConfig: hardwareHeaders (X-Apple-I-SRL-NO / MLB / ROM) ride every
GSA call — the reference chains the C58 machine's headers into all of them.
- GsaPostdataClient wired: the postdata liveness event fires before the
delegate sign-in (vendored do_login order — the earlier 'sign-in first' note
was wrong), with the APNs push token (the endpoint 401s ec=-800012 without
it); this is what creates the trusted device record on the account.
- NacValidationTest: the live vector — sign() reproduces the vendored client's
real sig16 byte-exactly on gdb-captured inputs (the mint's signature model
exonerated on live data).
- ActivationDryRunTest: postdata ordering corrected to the vendored sequence.
Live GSA A/B + gdb capture of the working client (captures/c58live/):
- gen_otp(gen=unix_seconds/30, one=metadata(400B), two=client_secret(32B))
— the rev-27 '32-byte mid' reading was another mid/secret swap
- Mac machines dispatch gen_otp (OTP flavor byte 1) — FLAVOR_MAC=1
- error ladder: -22421 = structurally invalid OTP; -29004 = wrong sig payload
- genOtp stage B now writes ctx[0x110..0x120] = LE [h3,h2,h1,h0] (the fitted
'never read, [h3,h1,h2,h0]' reading was wrong)
- Kotlin gen_otp still diverges from the binary in the final mixing rounds
(post-table ctx byte-identical; sig differs) — ground truth + ctx
checkpoints captured for the round-state hunt
The ids-bridge (imessage) takes its trust anchors per call from this pool —
the VEN endpoint's TLS fingerprint gate (rev 38) requires a rustls-shaped
handshake, and the JVM stacks cannot provide one. Pure visibility change.
The user's 2FA re-login re-fired the app's own IDS registration; gdb traps
showed the full mint chain ACCEPTED live (key_establishment + sign after a
successful step-2 parse, x3). Fresh-genuine-blob transport matrix: reqwest
0.11 + rustls 0.21 (+ the vendored baked Apple root DER) gets a real
session-info response on the identical XML-plist envelope; curl-OpenSSL over
h2 and h1.1, and curl with UA/Accept stripped, gets 5003/EM on the same
blobs. HTTP version and headers are irrelevant — the VEN endpoint
fingerprints the TLS ClientHello.
Kotlin blob/framing fully vindicated; the tool's :server needs a
rustls-shaped handshake (implementation decision open).
Both found by running ClearAnisetteProvider against Apple's live endpoints
(first live Kotlin provisioning run — succeeds after the fixes):
- lowercase {header, request} on the start/finish POST gets a silent HTTP 200
with an EMPTY body; {Header, Request} gets the real Response.{spim,ptm,tk}
- the GSA lookup GET 404s without X-Mme-Client-Info and only accepts the
angle-bracket form <Model> <macOS;ver;build> <com.apple.AuthKit/1 (…)>
Also records the session-26 step-2 EM A/B: the 5003/EM gate reproduces on a
FRESH genuine blob (ValidationCtx::new under gdb, replay-state eliminated)
and with the full anisette header set — anisette-on-step-2 falsified; the
app's own-flow verdict is blocked on interactive IDS re-registration.
- toBin(): the closed HardwareConfig::to_bin grammar — write_str/write_item prefixes,
model, MAC (raw 6 B), serial, UUIDs, board, build, the 00 03 0b 52 constant, then
the seven binary items in C58 export field order (serialEnc, platformUuidEnc,
rootDiskUuidEnc, ROM, romEnc, MLB ASCII, mlbEnc). Corrects the rev-32/35 label:
the raw second field is the MAC, not the ROM (multicast-bit + stub-type evidence).
- Round-trip verified byte-exact against the live 250-B session250 capture.
- ValidationCertChain: the step-1 cert data's framing (01, count, per cert
u16be type, u16be len, DER; leaf LAST = DRM Technologies A01, the OAEP key cert).
- NacMint/NacValidation: rngPad130 -> rngPad, generalized to 0x17c - session250.size.
- Live smoke result recorded: step 1 OK vs Apple, step 2 returns 5003/EM — blob
construction re-verified against the replay dumps; residue is outside the blob
(spec rev 36, NAC-NOTES session-26). 217 tests green.
Direct in-process replay of ValidationCtx::new (two byte-verified runs, no Apple
network): pearKey16 = the first RNG16 draw (= init_key input = OAEP msg[0:16]);
the post-encrypt 'xor' loops are byte-substitution tables (0x2249f9/0x224af9,
appended to PearTablesData); the pear-AES plaintext = substitute(02 ‖ u32be(1) ‖
innerKey16 ‖ zeros(10)); the encrypt_cbc iv rides an in/out 16-B block.
NacRequestBlob builds the blob with platform OAEP + HmacSHA1; 4 synthetic-vector
tests; :registration:test 213 green. Remaining live-mint gate: C56-c only.
Two session-20-frozen constants falsified on fresh live inputs:
- staging i==10 ecx2 = perm2u[st[0x6fa2]] (was frozen perm2u[0x40])
- the P region (state+0x6898, 7x256): five of seven tables are parameterized
on five body-derived byte-XOR pairs by the SSE builder at 0x17a1381-0x17a20b5
(tables 2/5 constant). The builder's instruction stream is serialized into
generated NacPTable.kt (1833 ints + 46 const vectors) and re-executed
lane-wise, byte-exact vs the emulated builder on fresh + random + s20 states.
NacSign re-ported with every body-derived region computed: u32tab/nacMasksFlags
(12-step barrett chain, full 128-bit product), mapKey cursor0, dynamic N,
base-7 0x6fd8 selectors, region6f98(state) (tsel6f98 span, 4 tables strided
0xf0), masks/flags at 0x6fe8/0x6fec, scatterMutated & ~masks, cipher RC =
state 0x25d8 words. The four former state-embedded constants (region6f98/
sel6fd8/maskC68/pTable) dropped from NacSignTablesData.
Verified: fresh live sig16 307d7151... and the full fresh 517-B stamp
byte-exact vs the live capture; session-20 stamp still byte-exact;
sig_hand.py verify 20/20. 209 registration tests green (vectors regenerated).
Spec -> rev 33. Method + dumps: registration/dev/clearadi/captures/NAC-NOTES.md
(gitignored).
The verified pure-python sign model (sig_hand/sig_init/sig_tail) is now
transcribed to Kotlin: NacSignTablesData.kt carries 102 tables as generated
base64 source (ClearAdiTablesData precedent, provenance header), NacSign.kt
runs the pipeline (u32tab → scatter → perms → keygen → phases B–E → rounds →
genBufs → threshold-cipher tail), and NacValidation.mint computes sig16
internally — the full 517-B stamp from Kotlin inputs. Pinned by 5 synthetic
LCG vectors against the python model (208 tests, 0 failed; table images
re-decoded and compared table-by-table, 32/32). Spec rev 31; README status
updated. NacMint: minimal public facade for consumers (the imessage tool
wires ClearAnisetteProvider + the mint behind its AnisetteSource/
ValidationDataSource seams).
The tail threshold cipher and pre-init region closed via empirical fit
against the 270 checkpointed rounds — pure-Python model (no emulator, no
captures) reproduces sig16 and the full 517-B stamp byte-exact (verify
20/20, independently re-verified). Spec rev 30 residue line corrected;
README: anisette chain now includes the NAC mint (Kotlin signature port
next).
Two further live provisioning runs (gdb_prov8/9) close the last three
TODO(capture) items of the cpim:
- X (the 32-byte tail group) = SHA-256(encout || spim_map_signature(
trailing[0:16]) || fixed 24-byte filler), written to the wire byte-exact;
verified against both runs.
- The signature input is the spim trailing's first 16 bytes (server
material, varies per session) — the earlier 'constant block' reading was
a stale session's value; the signature model matches the live output
exactly.
- The 12-byte plaintext tail is 12 fresh RNG bytes (same thread-RNG pool
construction as the IV).
- trailing[0:16] and the sig/digest 'nowhere on the wire' mystery resolved:
both ride transitively through X.
Kotlin: CpimShaTailSeal (the pinned production seal) wired as the provider
default; doc comments updated; one synthetic-vector test. Spec rev 29.
195 tests green.
One real OpenBubbles provisioning run under gdb (5 attempts, method + dumps in
registration/dev/clearadi/captures/WIRE-NOTES.md) pins what the previous
session left TODO(capture):
- ProvisionedData = {metadata Vec (400 B = decrypt out[4:404], len u32 BE at
out[0]), client_secret = RNG draw 2, mid = RNG draw 3, flavor u8}; the finish
gate is the decrypt output's out[408:440] == draw1 echo (not out[0:32])
- PTM = [u32 BE 4][seed 16][u32 BE payloadLen][payload][tail]; the decrypt
chain seed rides in the PTM itself (finish 17f2557 rcx = ptm[4:20], live)
- cpim = a 276-byte OUTER message [u32be(5)][iv 16][u32be(160)][encout 160]
[X 32][u32be(52)][u32be(4)][Y 52] over the 160-byte plaintext
[len][encsec(rng2)][len][rng1][blob=mid][arg9=-2 BE][unix-seconds BE]
[u32be(1)][12 B]; arg9 = -2 live-confirmed
- the encrypt IV is 16 plain RNG bytes (the 'IV from Spim trailing fields'
reading was the thread-RNG pool, not the Spim)
- the spim carries 99 trailing bytes (the <=23-B cap was a probe artifact) and
trailing[16:76] relays verbatim as the wire tail's Y group
- spim_map_signature args are (rdi=in, rsi=out) and neither its output nor the
SHA-256(encout) digest appears on the wire — the 'two 256-bit tail fields'
reading is falsified
- decryptPTM's math model round-trips the live PTM byte-exact (gate echo found
at out[408])
Remaining TODO(capture): the X 32-byte group's source, the 12-byte plaintext
tail, the spim trailing's first 16 bytes. Kotlin ClearAdiFraming /
ClearAnisetteProvider restructured to the live shapes; README updated.
194 tests green (:registration:test).
fenleon