Is this compatible with iOS 9?

[ciucaandrei]

I updated to iOS 9 and I can not download the new backup. I can connect to the account but I only see the backup from iOS 8. It is almost like the backup from iOS 9 is on a different server.

[luc-lynx]

I see the same:

python iloot.py -o ./backup/ "...@icloud.com" '...' Working with ...@icloud.com : ... Output directory : ./backup/ Available Devices: 0 There are no backups to download!

[cheyenne]

I get only the iOS 8 backups as well. To be sure it wasn't a different issue (e.g. slow propagation of backups into iCloud), I restored my iOS 9 device from an iOS 9 backup, and that worked and contained the newer backup data missing from the iOS 8 content I see in iloot.

[mca-gif]

So it appears that in iOS 9 they re-built backups to be based on CloudKit. This means that the process of accessing backups is totally different. I had started reversing CloudKit but hadn't gotten very far. I'll continue to work on it. And if anyone has done some work in this area, feel free to jump in.

[shuaibimran]

Is there any sign of success?

[FiZiX]

A jailbreak is out for iOS 9 now. Hopefully that'll help the reverse engineering efforts.

[vipinbeni]

same issue here it cant work for ios 9 ..... any progress..

[DanClarke-io]

As a side point for any developers that may be able to work with this, there is now a third party app that (apparently) works with iOS 9 backups, which is found detailed here: http://www.iphonebackupextractor.com/blog/2015/sep/25/download-ios-9-icloud-backup-data/

However, this app costs, and is not open source; but this may help people in the short term, and possibly help developers bring iloot along to support iOS 9.

[horrorho]

I had a look at iPhone Backup Extractor web logs a while back and it performs a round about operation connecting to it's own servers, which in turn connect to iCloud. We don't see any of the iCloud API mechanics first hand. Boo.

Unfortunately I don't have unfettered access to an iOS 9 device so I've been unable to acquire logging sessions of backup retrievals. This is what we really need. Failing that if someone can confirm the name of the iOS 9 iCloud backup CloudKit container, it would save me guessing.

I also had a quick nose at the Windows iCloud app logs and it's interaction with CloudKit and I might be able to outline a minimal retrieval process including skeletal protobufs for existing containers such as com.apple.clouddocs. There a few quirky data structures I know of already. I'll try and spare time for it this weekend, but no promises. This may assist in the development of an iCloud backup retrieval tool, but then again it may not. Until we get logs, it's hard to say.

[FiZiX]

@horrorho I have some logs I've collected with Fiddler. What's the best way to contact you directly?

[horrorho]

@FiZiX fantastic!

horrorhorrorho@gmail.com

[fongph]

@FiZiX Can you please send me the fiddler logs also? Thanks

fongph@gmail.com

[dixon528]

@FiZiX its cool, please send me logs also! Thanks

[FiZiX]

@fongph @dixon528 I'm sorry but I can only share the logs with persons who have public Github projects related to restoring iCloud backups.

[dixon528]

@FiZiX can you parse only requests, responses from logs and send me.

[horrorho]

Hi all. I've had a few offers of assistance for creating logs of iCloud restorations to iOS9 devices. However the process is not trivial and appears further complicated in iOS9 with the introduction of additional security layers.

If anyone has detailed information on achieving this, it would be greatly appreciated!

[horrorho]

Ok. I've written a proof of concept tool that demonstrates what we have discovered so far regarding iCloud and iOS9. There are maybe only a couple of client-server calls left remaining to figure out.

https://github.com/horrorho/InflatableDonkey

[markxmith]

Hi , I want to help you guys by taking logs from my iphone running iOS 9..0.2 but I've never done it. So you can either send me detailed instructions to take the logs Or we can communicate on a messenger and do a live session to take logs from phone. I follow Australian eastern time zone and I'm available on weekend as well

[horrorho]

@markxmith help is always appreciated, however the real issue is that it's unclear exactly how we create backups. Hopefully some bright spark will figure it out soon!

Additional note. I've figured out another step and pushed the new code. I'll hit the grindstone again this evening. You now all owe me chocolate! Thank you.

[markxmith]

@horrorho , i do have an Apple account which contains iCloud backup from 9.0.2 device. Will it be helpful If i give you credentials of that account ? It is just a test account

[horrorho]

@markxmith thank you for the offer! But I already have an iOS 9 iCloud account I can access and test retrieval with. However, and understandably, the owner is reluctant to let me jailbreak their iPhone.

That being said, the client-server calls are almost complete. My concern is the presence of encrypted fields. I have a very limited grasp of cryptography, so that will prove challenging.

[horrorho]

Ok, some good news and some bad news.

Good, steps 9 and 10 are functional so we should be able to download files.

Bad, step 9 returns encryptedAttributes for files. Without this we do not know what the files represent, nor can we decrypt them if needed. Unless this is solved, it's potentially a deal breaker. It's possible we may be missing additional client-server responses. Shout if anyone has any ideas.

[FiZiX]

I was able to get Fiddler to capture the iCloud restore process on iOS 9. Here's what I did:

1. Backup the iOS 9 device to iCloud
2. Reset the device to defaults: Settings – General – Reset – Erase All Content and Settings
3. Go through the setup assistant without connecting to WiFi, then tell it to skip the rest of the setup
4. Jailbreak the device
5. Connect to WiFi
6. Install iFile from Cydia
7. Use iFile to turn off the following switches in /var/mobile/Library/Preferences/com.apple.purplebuddy.plist
   • AppleIDPB9Presented
   • AssistantPHSOffered
   • AssistantPresented
   • Passcode4Presented
   • PBDiagnostics2Presented
   • PBTCPresented
   • RestoreChoice
   • SetupDone
   • SetupFinishedAllSteps
   • WiFiPresented
8. Configure Fiddler as your WiFi proxy
9. Install Fiddler SSL cert on device
10. Turn off HTTPS decryption in Fiddler
11. Reboot the device
12. Tell setup assistant you want to restore from iCloud
13. Log in with your Apple ID when Setup assistant asks
14. Turn Fiddler HTTPS decryption back on before accepting the EULA
15. Choose your iCloud restore file
16. Watch Fiddler capture and decrypt

[devzero0]

Here's a way to capture it without Jailbreaking:

1. Backup the iOS 9 device to iCloud
2. Reset the device to defaults: Settings – General – Reset – Erase All Content and Settings
3. Go through the setup and configure WiFi
4. Turn off HTTPS decryption in Fiddler
5. Press the home button to go back to the WiFi configuration, tap the 'i' and configure proxy settings to point to Fiddler
6. Use Apple Configurator 2 to install the Fiddler cert (create a new profile that contains the Fiddler cert, create a new blueprint that contains that profile, apply the blueprint to the phone)
7. Proceed with setup
8. Tell setup assistant you want to restore from iCloud
9. Log in with your Apple ID when Setup assistant asks
10. Turn Fiddler HTTPS decryption back on before accepting the EULA
11. Proceed with the restore

The key to figuring this out was FiZiX determination that you can't turn on HTTPS decryption until after you've signed in.

[FiZiX]

@devzero0 Thanks! I had looked at Apple Configurator but the documentation made it look like it could only be used after the Setup Assistant was finished. Great discovery!

[vipinbeni]

any update for ios 9

[horrorho]

@vipinbeni From the InflatableDonkey side, it's been a tough week. Apple have tightened up the security model and it's proving difficult. If anyone has any information, it would be much appreciated.

I've made brief write-up of some low-level CloudKit mechanics that may interest some.

[fongph]

Hi horrorho

Did you find a way to get the UDID besides the serial number of a device when calling "/api/client/record/retrieve" to retrieve the snapshots list for the device? I have gone through a complete iCloud restore log but didn't seem to be able to find the UDID of devices in plain text within the Protobuf response messages. Please advise.

Thanks

On Mon, Nov 2, 2015 at 10:39 PM, horrorho notifications@github.com wrote:

@vipinbeni https://github.com/vipinbeni From the InflatableDonkey https://github.com/horrorho/InflatableDonkey side, it's been a tough week. Apple have tightened up the security model and it's proving difficult. If anyone has any information, it would be much appreciated.

I've made brief write-up https://github.com/horrorho/InflatableDonkey/blob/master/CloudKit.md of some low-level CloudKit mechanics that may interest some.

— Reply to this email directly or view it on GitHub https://github.com/hackappcom/iloot/issues/62#issuecomment-153258896.

[horrorho]

@fongph Hi. Ok, that corresponds to step 5 InflatableDonkey. This returns us a device UDID list.

As far as I'm aware, the deviceIdentifier/ deviceHardwareID can be randomly generated. The returned UDID list is based on account details, not the phone details we supply. The protobuf reply has a devices key (if devices are present) and the backup UDID will look something like "D:772201d07ecbe303361e1d0f4a19a33e9cc2b376".

Are you able to run InflatableDonkey? As it will dump out all the client-server responses including headers/ protobufs. You can examine step 5 output to see exactly what it does. It might assist you in looking for a similar call in your own logs.

Also, I presume you're able to decode the delimited protobuf replies when looking at raw logs.

[devzero0]

Not sure if this will be of any value, but here is a reimplementation of InflatableDonkey in Python. I did this because I'm a "Python guy" so hacking on this in Python is easier for me than in Java. Thinking that others might be in the same boat and that it might increase the audience of folks that can participate in working on this I decided to make the code public.

To be clear, there is no additional functionality or insight here that isn't already in InflatableDonkey. In fact I didn't test the snapshots or manifest options too heavily so there might be a mistake in there.

[horrorho]

@devzero0 Excellent!! Thank you for this. It's always been my intention that we somehow restore iLoot's functionality or at least create a functional fork/ clone. Unfortunately my Python skills are limited to basic interpretation, otherwise it would have been my first choice for coding.

[fongph]

@horrorho Thanks for your quick reply. I made a CKDFetchRecordsOperation request and got a reply that contains a list of devices and in this case only 1 device "Paulino's iPhone" with device ID : "D:342dd360112661a1387aed03b7e408adeda782b3".

I then made another CKDFetchRecordsOperation request by specifiying the above device ID in message 211 and got a reply of snapshots for that device along with some basic properties including the serial number for the device.

I think from the reply I can get the serial number for the device as seen in iTune through the protobuf response but the device ID from the protobuf response is definitely not the same as the UDID of the device that we can use to get in iOS8 and prior MobileMe system.

I have tried running InflatableDonkey and it is doing the same thing as the iCloud backup restore process log up to that point so I don't think it is missing any call. Could the UDID I am looking for get buried within the below unknown objects?

Thanks

[horrorho]

@fongph Ok. Are we confusing phone UDID with backup UDID? The first iCloud response returns a 'devices'/ backup UDID, which is not related to the phone UDID. The backup UDID is created randomly when a phone is first backed up to iCloud. At least that's my understanding of the process.

In short, backups are referenced by their own UUIDs, not by the phone UUID.

It is possible that the phone UDID is present in some of the encrypted fields that are eluding us. But unless it's required for decryption (unlikely) or a yet undefined operation, I wouldn't worry too much about it.

[nsglcck]

Are you guys aware that the people from Elcomsoft somehow managed to download ios9 backups when iCloud panel is installed?

[horrorho]

@Enes81 a few of us were discussing this the other week about Elcomsoft potentially hooking into iCloud dlls. If someone has the new Elcomsoft Phone Breaker, the necessary skills (which rules me out) and tools they could potentially spy on the process. If we can isolate the calls being made and their context/ purpose, it could guide us to own our solution.

The http/ protobuf aspect is trivial so it's likely that it's the crypto calls being utilized. Then again, why reinvent the wheel, they could be using http/ protobuf calls too.

The other concern is to why they have gone down this route. Is the new security model that difficult to crack? Or is this an interim measure to produce a marketable product whilst a more independent solution is developed? Or possibly it's just the weakest link in the chain and the most efficient attack point, why waste resources?

Again mere speculation and musings, I'm no expert.

[t3zuka]

Having taken a quick look at the elcomsoft solution. The atex binary may be of interest, it generates a text file named icloudtoken{date/time}, containing the email address and of course a token. I'll investigate a little more and see how this applies to what is already known.

[dfirfpi]

you could check if the DPAPI decryption of Windows iCloud token still works (see here http://blog.digital-forensics.it/2015/01/happy-dpapi.html). Actually I can't, but I could to it in the next days if useful. As far as I remember, I was able to access the backups with the pair [dsPrsID, mmeToken]... but it was not the actual version. If I can help with this, let me know.

[vladmazur]

Guys, any progress? How can I help?

[mca-gif]

If there is anyone with mod access, @hackappcom or perhaps @dlo, can delete the preceding comments containing the Elcomsoft licenses, that would be great. The Elcomsoft team has historically been quite open in their sharing of information. They have given talks and published their slides containing a wealth of information. If we have any hope of them continuing to do so, or possibly collaborating with them in the future, openly pirating their software in this forum should not be condoned. If @TSWorks wishes to purchase a license of EPPB for an individual developer so be it. Not to mention the fact that those serials could constitute a violation of GitHub's terms of service, and be grounds for removal of this project.

TL;DR: Seriously @TSWorks? Don't be a jerk.

[dlo]

I would delete, but don't have mod access. :(

[mjainv5]

Any update guys? I can pay to that guy which will do backup(iOS 9)stuff Thanks

[dixon528]

Hello guys,

Our team of 3 people has been working hard on getting data from Cloudkit backups during the last month. We've been researching all possible ways, but there is no luck with getting the data from there so far. I'm pretty sure each of you has done a lot in this research direction. Everyone has done his unique research.

If we share information about what we've been able to learn, we can make one more step closer to our common goal. Together we are much stronger than working apart. How about uniting our efforts to get answers to all of our questions. I want to make a discussion where everyone will be able to post what he’s got and look at what others’ got.

So everyone who's interested, please send emails to me chinedisi@gmail.com. I'll make discussion through "Reply All". And we will start from our investigations first.

Let's make a present to ourselves for Christmas!

Thanks in advance,
dixon528

[shawl852]

Hey Everyone,

Has anyone got a solution for iOS9+ already? I'm willing to pay generously for it. My email is shawl852@gmail.com.

[sammarcus]

@shawl852 I've personally used Reincubate's product and can confirm it's able to extract an iOS 9 CloudKit backup and decrypt it. I was also tweeting at the CEO and he's a cool guy — they have solid support.

[ItsASmallWorld]

Anyone know if Elcomsoft Phone Breaker can be run from command prompt on WIn?

[MkDevelop]

Guys I don't know if it's of any use but have you looked at https://github.com/reincubate/ricloud

[Jstev3]

to use ricloud you need pay for get an userid and password and put in the script, but maybe someone with knowledge can inspect that script and make this fully functional

[t3zuka]

The problem with reincubate is that they do all the interesting iCloud stuff server side, so their API isn't much use.

[MkDevelop]

Hmm that sucks... Any update guys?

[nickgoodman]

If I'm reading the above discussion and the code correctly, what needs to be done is:

• Track down the API needed to find the encryption keys
• Get ahold of the keys
• Use the keys to decrypt the info that will lead to implementing step 11 in the code

From various comments here and other locations, it looks like the best approaches to solving the above are:

• somebody with knowledge of the backup process coming forward
• low-level traffic analysis to identify the API calls being made and the data structures returned during the restoration of a backup

Does anybody (particularly @horrorho or @mattandersen ) have any suggestions on how one might approach this problem (I believe I've got the necessary tools and skills to dig into this a bit)?

[horrorho]

@nickgoodman Thank you for the offer! I'll take some time this weekend to summarize what we have and what we need. It will take more than a few minutes and more than a few sentences to describe the issue in any sort of detail. In short: we can recover files but we can't decrypt them, so either we figure the decryption scheme or we hook into iCloud dll decrypt calls.

I've reported @TSWorks for abuse for the above comments. If we were looking for Elcomsoft to assist the wider community, as they have done in the past, then that sort of behaviour will surely not help.

I'm rather snowed under at the moment, so apologies for my lack of participation of late.