iOS Activation Accepts Custom XML Provisioning – Configs Persist Across DFU, Plist Shows Bird Auth Mod

While inspecting iOS activation behavior, I submitted a raw XML plist payload to Apple's https://humb.apple.com/humbug/baa endpoint during provisioning.

What I observed:

• The endpoint responds with 200 OK and issues a valid Apple-signed certificate
• The payload was accepted without MDM, jailbreak, or malware
• Device was new, DFU-restored, and unsigned
• Provisioned settings (CloudKit, modem policy, coordination keys) persisted even after full erase + restore

What caught my eye later was a key entry in defaults-com.apple.bird:

<key>CKPerBootTasks</key> <array> <string>CKAccountInfoCacheReset</string> </array> ... <key>CloudKitAccountInfoCache</key> <dict> <key>[redacted_hash]</key> <data>[base64 cloud credential block]</data> </dict> 

This plist had modified CloudKit values and referenced authorization flow bypass, possibly tied to pre-seeded trust anchors or provisioning profiles injected during setup.

Why Post Here?

I’m not claiming RCE. But I suspect a nonstandard activation pathway or misconfigured Apple provisioning logic.

I’ve submitted the issue to Apple and US-CERT — no acknowledgment. Another technical subreddit removed the post after it gained traction (70+ shares).

Open Questions:

• Could this reflect an edge-case provisioning bypass Apple forgot to deprecate?
• Does the plist confirm persistent identity caching across trust resets?
• Anyone seen this behavior or touched provisioning servers internally?

Not baiting drama — I’m trying to triangulate a quiet corner of iOS setup flow that’s potentially abused or misconfigured.