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.

[nickgoodman]

Thanks @horrorho -- I'm working on capturing my own restore logs at the moment.

[ifnull]

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.

[ItsASmallWorld]

@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

[nickgoodman]

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.

[nickgoodman]

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.

[ShooTeX]

any progress?

[nickgoodman]

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?

[mn3monic]

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.

[nickgoodman]

@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?

[ifnull]

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?

https://github.com/reincubate/ricloud

[t3zuka]

@ifnull Could you point to the reincubate calls you mentioned?

[ifnull]

@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=****

[mn3monic]

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?

[ciucaandrei]

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

[t3zuka]

@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.

[DustyZ]

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.

[ifnull]

@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.

[nsglcck]

@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.

[vinchigreg]

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

[Aliasr]

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.

[horrorho]

@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.

[Itskev95]

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

[FiZiX]

Has anybody analyzed this software yet?

https://www.wondershare.com/iphone/ios-9-data-recovery.html#part2

[Pink280z]

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/

[pauljayd]

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

[teamboldshoes]

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]

[t3zuka]

@teamboldshoes as this is from an iOS8 backup, are you sure this is applicable?

[teamboldshoes]

@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!

[andrewbluepiano]

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.

[SeAlgoAsoma]

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.

[horrorho]

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.

[vipinbeni]

Wonder share is now support ios9

http://www.digitaljournal.com/pr/2869706

[horrorho]

@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.

[horrorho]

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.

[horrorho]

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!

[gastonmorixe]

@horrorho 👊💪

[elaygueta]

@horrorho you are amazing! great job!!!! please continue updating.. ;)

[ill0gix]

@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!

[ghost]

@horrorho amazing work ,We have great implement from @horrorho , all hope on you

[vipinbeni]

@horrorho great we are looking soon implementation from you sir

[horrorho]

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.

[gastonmorixe]

👌🚀

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

[FiZiX]

@horrorho Thank you again for all of your hard work! Is there a way to contribute to you, financially or otherwise?

[vipinbeni]

Good and Great Work @horrorho

[iwzoo]

@horrorho Great job!!! Thanks

[horrorho]

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.

[sammarcus]

@horrorho Thank you for your incredible efforts!!

[horrorho]

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.

[vipinbeni]

@horrorho Dear Sir Is there is python implementation of InflatableDonkey is available devzero0/iOS9_iCloud_POC is only showing the backups of ios 9 but iwill not able to find how to download the same Kindly Help me .

thanks