Is this compatible with iOS 9?
ciucaandrei opened this issue · comments
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.
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!
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.
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.
Is there any sign of success?
A jailbreak is out for iOS 9 now. Hopefully that'll help the reverse engineering efforts.
same issue here it cant work for ios 9 ..... any progress..
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.
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.
@horrorho I have some logs I've collected with Fiddler. What's the best way to contact you directly?
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!
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.
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
@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.
@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
@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.
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.
I was able to get Fiddler to capture the iCloud restore process on iOS 9. Here's what I did:
- Backup the iOS 9 device to iCloud
- Reset the device to defaults: Settings – General – Reset – Erase All Content and Settings
- Go through the setup assistant without connecting to WiFi, then tell it to skip the rest of the setup
- Jailbreak the device
- Connect to WiFi
- Install iFile from Cydia
- 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
- Configure Fiddler as your WiFi proxy
- Install Fiddler SSL cert on device
- Turn off HTTPS decryption in Fiddler
- Reboot the device
- Tell setup assistant you want to restore from iCloud
- Log in with your Apple ID when Setup assistant asks
- Turn Fiddler HTTPS decryption back on before accepting the EULA
- Choose your iCloud restore file
- Watch Fiddler capture and decrypt
Here's a way to capture it without Jailbreaking:
- Backup the iOS 9 device to iCloud
- Reset the device to defaults: Settings – General – Reset – Erase All Content and Settings
- Go through the setup and configure WiFi
- Turn off HTTPS decryption in Fiddler
- Press the home button to go back to the WiFi configuration, tap the 'i' and configure proxy settings to point to Fiddler
- 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)
- Proceed with setup
- Tell setup assistant you want to restore from iCloud
- Log in with your Apple ID when Setup assistant asks
- Turn Fiddler HTTPS decryption back on before accepting the EULA
- 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.
@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!
any update for ios 9
@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.
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
#62 (comment).
@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.
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.
@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.
@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
@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.
Are you guys aware that the people from Elcomsoft somehow managed to download ios9 backups when iCloud panel is installed?
@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.
Having taken a quick look at the elcomsoft solution. The atex binary may be of interest, it generates a text file named icloud_token_{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.
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.
Guys, any progress? How can I help?
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.
I would delete, but don't have mod access. :(
Any update guys?
I can pay to that guy which will do backup(iOS 9)stuff
Thanks
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
Hey Everyone,
Has anyone got a solution for iOS9+ already? I'm willing to pay generously for it.
My email is shawl852@gmail.com.
@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.
Anyone know if Elcomsoft Phone Breaker can be run from command prompt on WIn?
Guys I don't know if it's of any use but have you looked at https://github.com/reincubate/ricloud
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
The problem with reincubate is that they do all the interesting iCloud stuff server side, so their API isn't much use.
Hmm that sucks...
Any update guys?
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)?
@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.
Thanks @horrorho -- I'm working on capturing my own restore logs at the moment.
I reported @TSWorks as well. Interestingly, the serial he provided has a prefix of "EPV" which is for another Elcomsoft product and not Elcomsoft Phone Breaker.
@nickgoodman see page 11 of the iOS 9 security guide for the encryption architecture overview https://www.apple.com/business/docs/iOS_Security_Guide.pdf
In case it's helpful for others working on this problem, I was able to capture my restore traffic using Charles Proxy following @devzero0's procedure with a few modifications:
- I shared my laptop's wifi network with my phone so that the laptop would be the phone's internet gateway -- this simplified a few things (this requires a wired connection for the laptop but I found it much simpler than other approaches I tried).
- I used the default Charles certificate by downloading and trusting them on my laptop.
- I installed the Charles certificate onto the phone using Apple Configurator (I highly recommend testing this procedure when the phone is not in the middle of a restore if you've not done it before, because it only works if the certificate is trusted properly). I did this after entering my iCloud credentials and before accepting the EULA (I also connected to the proxy at this point).
Also, thanks @ItsASmallWorld for the pointer to the security documents, the codebase makes a lot more sense now that I've read that.
Looking at my traffic capture, I see two things that may be related to the keys we're looking for:
- There's a Hashed MAC key (and I believe it's a shared secret key, not a signature of a message) returned from ckdatabase.icloud.com in one response (it's part of the 211 protobuf).
- The device makes several calls to escrowproxy very early in the restore. This service may be providing access to the keychain in its responses. I don't see anything in the codebase leveraging this today, so perhaps it's an area to dig into further.
any progress?
I've looked through both the backup and restore logs and see a few things that may be related to the keys, but I'm not sure what format or encryption is being used. Any thoughts?
I bought both Elcomsoft Explorer for WhatsApp and Elcomsoft Phone Breaker Forensic version, and
I tried them both on iOS 9.0.2 devices
EXWA worked almost perfectly on 2 Iphone 6, I was able to retrieve all messages, pictures and audio from the icloud backup with a single click saying "save all". except for videos, whatsapp said it's not available anymore on their servers.
EPPB was able to do the same for whatsapp backup but was only able to get sms messages from the other icloud backups and not pictures videos or other, in the same directory structures as iloot did, so HomeDomain, RootDomain etc. etc.
If I can be of any help somehow I'll be happy to help tracking what those programs do by sniffing with Fiddler or something else, just tell me what to do.
@mn3monic , perhaps we'd learn something by comparing the sequence of calls that the native restore process makes to what the EPPB does. In my logs of a restore, I see:
- general calls to apple (i'm guessing relating to the phone telling apple what's going on)
- escrowproxy.icloud.com calls that look like they may be getting encryption info and/or keychain info
- a bunch cloudkit calls
- downloads of data from google and at&t cloud storage
Do you see a similar pattern?
I didn't even know AT&T cloud storage was a thing until I looked at reincubate's calls. Is it possible EPPB is leveraging Reincubate's iCloud API?
@t3zuka I only have one url that I have logged from their app and it was in an alert. They are using SSL pinning so I haven't been able to log any of their other requests.
http://att-us-sfo-dfw-00002.nawest4.synaptic.att.com/rest/namespace/****?x-client-request-id=****&byte-range=****&bin=****
I know it's lame but seems I'm not able to point Fiddler4 at EXWA or EPPB, only web browsers work with it, I tried to change some connection and HTTPS options but still nothing.
Anybody have a clue how to make it work?
I would really like an update for this application so that it could also work with iOS 9. Now iloot can not be used because about 75% of iOS devices are with iOS 9. I am sure that there are more people that need this update and if it takes more time, soon iOS 10 will be released and that could mean that the update for iOS 9 could be useless.
I am thinking that we could raise some money(from the people that need this update) and award the money to the person that makes the update. Maybe this will make more people interested. I am sure that this update is possible because there are many companies that offer this for iOS9 - but you need somebody with some expertise in this field.
Maybe this will make more people interested. If you are interested, please contact me at ciucaandrei84@hotmail.com . Maybe this will speed up the process.
Thank you
@teambobbenbobnewshoes they are using vmprotect (in the latest version at least), so reverse engineering the actual application could be incredibly difficult.
I'm fairly sure the icloud library they are using is AOSKit.dll, I've briefly looked through the assembly, but I've not had time to get any further. I'll try hooking into the functions soon and find out what is actually being called.
Additionally, EPPB creates an SQLite db called EscrowCache1.0 containing two binary blobs (escrow and escrowMetadata), relating back to the comments made by @nickgoodman. So there are a few avenues we can go down from the reverse engineering side.
FYI: Tenorshare iPhone Data Recovery (latest version) will download iOS9 backups without problems. It will also decrypt them, even in the trial version, but not offer you the ability to "recover" (aka. rename files and recreate folder structures) without a license. Not packed, can be debugged, MITMed and sniffed easily with proxifier and e.g. Fiddler. Just force it to not run as admin. It interfaces with iCloud for Windows somehow though.
Downloaded files are put in C:\ts_tmp and then in %TEMP%\ts_download after decryption.
Try to download notes only for a single authorizeGet and chunk to understand and decrypt.
I see calls to /setup/authenticate/APPLE_ID, followed by /setup/get_account_settings, /mbs/SOMENUMBER, /setup/ck/v1/ckAppInit?container=com.apple.backup.ios then a few record retrievals, an authorizeGet, download of the chunk - and then a final record retrieval.
@teambobbenbobevennewershoes
Fiddler lets you forge your own SSL certificates. This is needed to see the traffic flow to Apple's servers. EPPB does verify the certificates though, but Tenorshare doesn't care at all.
@DustyZ I don't see any evidence that Tenorshare supports iOS 9 iCloud backups. Like several of the other recovery tools, it does support iOS 9 recovery from device, local backups, and iOS 8 iCloud backups.
@ifnull I've just tested Tenorshare and can confirm it does work with iOS 9 backups (including whatsapp). However you need to have iCloud control pannel installed like with Elcomsoft.
Unable to download now, Tenorshare download is breaking after 7 MB of download. Hope it will be fixed soon and then I can track it back.
On the other hand Dr. Fone isn't compatible with iOS 9 backup extraction and giving me the same screen as uploaded by @teambobbenbobevennewershoes
Tenorshare for Mac is version 6.6.0.6 which cannot retrieve iOS 9 backups. Tenorshare for PC is version 6.7.1.0 which can indeed retrieve iOS 9 backups.
@DustyZ Thank you! I can confirm that on a virtual Windows 7, Tenorshare 6.7.1.0 does retrieve iOS9 backups and that the process can be redirected through Fiddler using a proxifier.
Examining the logs I've noted a SRP exchange which occurs early on. However the protocol is not trivial, and yes I suck at crypto so don't expect much progress on that front from me.
Previously PKCS 12/ X.690 like structures had been noted in the logs. Some of these appear to be wrapped in NSData blobs, although I'm not certain of this.
So as a rough guess we have a SRP exchange which fronts a cascading set of security layers, each one requiring the outer key to proceed.
Also of note, my attempts to hook dll calls have been limited by Tenorshare's use of VMProtect. I'll see if I can work around this. Again my knowledge of Window's internals sucks, so don't expect much progress there either. I had rather been hoping to follow in the footsteps of Elcomsoft/ Tenorshare and use Apple dlls directly to avoid as much hoo-ha as possible.
Can someone please leave a small tutorial on how to retrieve files from Tenorshare with out a license? Before you say no, just remember you may be in the shoes of someone who doesn't know how to do something. Good karma pays off. Thank you in advance.
-Kevin
Has anybody analyzed this software yet?
https://www.wondershare.com/iphone/ios-9-data-recovery.html#part2
btw, Elcom updated their software a couple of days ago. No longer requires iCloud control panel installed on Windows.
https://www.elcomsoft.com/news/624.html
http://blog.elcomsoft.com/2016/02/elcomsoft-phone-breaker-5-20-direct-icloud-access-and-ios-9-3-support/
Just another user interested in LiquidDonkey Java access to iCloud access here --
The work already/being done is way beyond me, but I know there must be many of us hoping it all ends successfully! My wife got an iPhone, and I'm desperate to access her phone contacts for inclusion into our home-grown personal-info files.
Good luck.
Paul
My account keeps getting marked as a bot. Stop it please GitHub!
Recently, I attached Olly to Tenorshare and viewed it's loaded modules. I cross-referenced the DLLs that Apple supply with iCloud Control Panel with those loaded by Tenorshare and used API Monitor to hook function calls from those DLLs during a "Notes" backup download. (iOS 8.4 unfortunately: Tenorshare crashes when I try to log into my own iCloud account to retrieve my iOS 9 backups). Interestingly enough, the only exported functions that Tenorshare used were from objc.dll and it seemed to be a repeated sequence of:
- object_getClass()
- object_getClass()
- objc_destructInstance()
Note that no calls from AOSKit.dll were detected by API Monitor. As I say, I watched all the Apple-supplied DLLs for export activity, with the exception of icudt55.dll, which API Monitor could not bind to. DLL Export Viewer (Nirsoft), however, was able to read icudt55.dll and listed only one function within the DLL. The function's name was listed as: "icudt55_dat". Do we think it's perhaps possible that this function is used to export a crypto key of some sort?
Following that, I decided to take a look at the DLLs that ship with Tenorshare. Again, I used Olly to identify loaded modules and API Monitor to watch exports. Most of the functions called were to do with data parsing, as opposed to authentication and backup retrieval. API Mon detected:
- CreateFilterObj (LibSearchFileName.dll) (Multiple calls)
- searchDeleteData (lib_iphone_recovery.dll)
- RecoveryPhoto (RecoveryPhoto.dll)
--- Which in turn made a load of calls to sqlite3.dll functions. - More calls from the main thread to sqlite3.dll functions
(sqlite3.dll exports include basic database functionality: _get_table, _free_table, _open, _close, _column_int, _step)
So it looks like all the DLLs monitored are pretty much irrelevant in the context of authenticating and downloading backup files. The good news though, is that I wasn't actually able to monitor ALL of the DLLs shipped with Tenorshare (API Monitor was unable to bind to bind to 5 of the programs native DLLs). This means that the un-monitored DLLs must be responsible the backup retrieval. The un-monitored DLLs were as follows:
- iCloudLib.dll
- managercdb.dll
- mobilelink.dll
- tango_decode.dll
- updataError.dll
I know which of these I find most interesting! Exploiting the information provided by Nirsoft's DLL Export Viewer about each of the DLLs above, the following was deduced (perhaps incorrectly, so feel free to double check my work):
- managercdb.dll deals with iTunes playlists and photo albums
- mobilelink.dll deals with all things crypto related (of secondary interest)
- tango_decode.dll obviously decodes data retrieved from the Tango messenger app
- updataError.dll contains only one function which, judging by it's name, logs data UPLOADED to iCloud.
Which of course leaves the very alluring "iCloudLib.dll". This looks of huge interest because it contains a whole host of functions dedicated to the download of iCloud content. Many of the functions have secondary functions of the same name, with "OS9" tacked on the end, which are presumably the functions which provide iOS 9 support :)
For example, we have both "DownBackupData" and "DownloadBackupDataOS9" functions exported from iCloudLib.dll. Following this post, I shall provide a comprehensive list of functions contained within iCloudLib.dll, as detected by Nirsoft's DLL Exporter Viewer. A 'next step' to consider would be to disassemble this DLL and take a look at the functions within (perhaps with IDA Pro, which is what I'd use) or debug the software, tracing calls to this library to try to determine exactly what is going on where. I hope this is somewhat helpful!
@teamboldshoes as this is from an iOS8 backup, are you sure this is applicable?
@t3zuka Well I'm pretty sure the exports DownBackupInfoOS9(), DownloadBackupDataOS9(), ParseBackupDataOS9() and ReleaseBackupInfoOS9() are the functions that provide iOS 9 functionality, so analysis of those would be relevant. Unfortunately, I'm having difficulty with my own account (a buffer overflow seems to occur whenever I try to login), so I can't take a look at the iOS 9 backup download procedure. If anyone wants to perform similar analysis on an iOS 9 backup download, I'm sure it would be appreciated hugely by fellow GitHubbers; I know I would certainly appreciate it!
My initial approach aimed to narrow down the amount of relevant code that could be analysed by any interested reverse-engineers. I thought that the lack of AOSKit.dll activity was worth mentioning. However, a post by an iLoot contributor (apologies, I forget... was it perhaps @horrorho?) suggested, probably correctly, that AOSKit.dll may have been statically linked during the compilation of Tenorshare's iCloudLib.dll. As such, we would not see any activity from this DLL using API Monitor as all of the functions would have been internalised within iCloudLib.dll. Thus no narrowing-down of code was actually achieved, unfortunately. (The post by a contributor mentioned previously has since been removed.)
Still, we know that iCloudLib.dll and mobilelink.dll are fundamental interfaces to iCloud functionality for Tenorshare's software. We know that the code for authentication, snapshot enumeration and operating system determination almost definitely lie within one of these two DLLs. Maybe everyone already knew that, but I thought I'd point it out for anyone who may be as unskilled as myself!
Just putting this out there, not sure if its helpful or not, but I have a license of the most recent version of Elcomsoft Phone Breaker Pro edition, and although it isnt perfect, it can indeed download iOS 9 backups. If theres anything I can do to help just let me know.
Sure would have been nice if it was more obvious that this doesn't work for iOS 9. I just wasted about 2 hours before finding this thread.
Hi! I'm still working on it as much as I can in my spare time. I'm slowly making progress although I hate cryptography with a passion and I enjoy working with raw assembly language even less. I've spent the last day or two writing cryptography code which I'll push at some point.
Rather like wandering into a giant rabbit hole, I'm not sure sure how deep it goes. So as to how much more code I need to derive, I couldn't say. I was rather hoping some random genius would have it all done and dusted by now.
Wonder share is now support ios9
@Aliasr Hi there. I've been pressed for time again. I haven't forgotten, I promise! As for expertise, it's the twin black arts of cryptography and reverse engineering binaries.
Ok! I've pushed a load of changes to InflatableDonkey.
I've figured out the escrow process and we now have access to decryption keys. Protection zone decryption is 90% figured but mostly uncoded. The old keybag/ protection classes mechanic looks unchanged. I'll code these in over the next few weeks as free time allows.
Chunk decryption is the big sticking point, although I do have an idea of how it may work.
Update! Protection info code is largely in place. Keybag unlocking seems to be functioning ok. Chunk decryption is figured, I just need to formally code then push it. This leaves us with protection class handling which should be it. If the mechanics haven't changed from iOS 8 then it will be a trivial port of LiquidDonkey code, otherwise it will be more reversing and crypto work.
I was only ever intending InflatableDonkey to be a research tool that I would expire once it had reached 100% inflation. But I now have so much of the code in place that would turn it into a fully functional download tool, I'll probably go ahead and do that. But let's not get ahead of ourselves, I sill need to solve the final stages. Wish me luck!
@horrorho 👊💪
@horrorho I finally stopped just being a lurker here and signed up on GitHub just to commend you for your amazing work. Been a long time user of your projects and just wanted to say thanks. We all look forward to your release!
Update! As some of you are already aware, I've already figured out the last few steps. I can provisionally download and decrypt files. I've yet to perform exhaustive tests, so it's not a guarantee.
So InflatableDonkey has largely achieved its goal. It now floats amongst the clouds in a suitably inflated state.
The caveat being I've not pushed the latest updates... Why? Because it won't meet the demands that will be placed upon it. It's barely functional experimental/ concept code that downloads a single file. Whilst this may interest some, it will surely disappoint the majority. I'm going to take the liberty of spending another week or two to code a more functional solution.
I'll keep everyone updated.
👌🚀
Sent from my iPhone
On Apr 14, 2016, at 11:03 PM, horrorho notifications@github.com wrote:
Update! As some of you are already aware, I've already figured out the last few steps. I can provisionally download and decrypt files. I've yet to perform exhaustive tests, so it's not a guarantee.
So InflatableDonkey has largely achieved its goal. It now floats amongst the clouds in a suitably inflated state.
The caveat being I've not pushed the latest updates... Why? Because it won't meet the demands that will be placed upon it. It's barely functional experimental/ concept code that downloads a single file. Whilst this may interest some, it will surely disappoint the majority. I'm going to take the liberty of spending another week or two to code a more functional solution.
I'll keep everyone updated.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
@horrorho Thank you again for all of your hard work! Is there a way to contribute to you, financially or otherwise?
Update update! I've had requests to push code for the complete backup process. I have done so. InflatableDonkey is now downloading complete backups, but it's still an experimental build so please don't expect too much.
It's primarily out there for the developers and security experts who've been keen to inspect it, bugs and all.
I'll continue to work on it.
@FiZiX my reward has been that I've become curiously initiated in the dark arts of reverse engineering and cryptography, by no means an expert in any sense of the word but certainly more knowledgeable. Then again, a little knowledge can be a bad thing... especially where cryptography is concerned. On the other hand if someone with little prior knowledge can pull apart the iOS9 iCloud backup retrieval process, it makes you wonder what feats the experts are capable of.
@horrorho Thank you for your incredible efforts!!
Ok, bad news all. InflatableDonkey in it's current (un-pushed) build works pretty well with iOS9.2 backups.
However Apple have altered some of the core encryption mechanics for 9.3 which break things for us, namely a new protectionInfo format. Previously it was a DER encoded entity, now it appears to be an encrypted byte format with a 0xFF prefix.
The other issue is that I have work pressures again and I'm building up a progressive sleep deficit. I'll try and spare time to figure out the new mechanics, but as it stands I can't promise anything. Sorry.
I'll push my current InflatableDonkey build when it's stable. You're all welcome to play with it and see if you can figure out the missing 9.3 steps.