ADP on the table: when commercial tools were not enough
In late March 2026 we had a concrete operational need: download an iCloud device backup protected by Advanced Data Protection (ADP). The commercial forensic products we relied on simply were not working for that case at the time. That gap pushed me and a colleague to start asking a more fundamental question—how do you even begin to understand the Apple APIs that the iCloud section of iOS Settings talks to?
The first phase was deliberately practical. We needed a way to observe real traffic and real device behaviour. Two paths were available: obtain (and instrument) a jailbroken iPhone, and/or study what Elcomsoft Phone Breaker was already doing on the wire. Holding both a valid EPB license and a jailbroken device, I chose to use both.
The early blockers clustered around GrandSlam / GsService2. EPB itself was broken in that window for the flows we needed; Elcomsoft shipped a fix in a later release the following month. Until then I did not wait: I proceeded through iCloud.com on one side and the jailbroken iPhone on the other.
The iCloud.com route produces idmsa-style web tokens—useful for the browser surface, not for native mobile clients. Even so, those reverse-engineering sessions paid off. I mapped authentication endpoints, including paths around trusted devices and SMS second-factor flows, and built a clearer picture of metadata that survives around deleted media in iCloud Photos.
From iCloud.com I moved onto the jailbroken iPhone. There the GrandSlam surface oriented
at mobile clients became visible, along with the first
CloudKit endpoints relevant to device backup—especially the
mbksync zone inside the
com.apple.backup.ios container (the Mobile Backup / backupd
stack), not a generic “MobileSync” label.
That was the real beginning: not a finished extractor, but a forced path from an ADP recovery we could not buy off the shelf, into the private Apple surfaces that eventually became iCloudKit Extractor.
← All notes