iOS10 support about inflatabledonkey

[ajlyakhov]

Good news! I've installed iOS10 (latest beta) and successfully retrieved backup. At least photos, viber and whatsapp data properly downloaded and readable. Cant believe Apple does not break things in iOS 10, may be they would with public release :)

[ajlyakhov]

Seems like it was an issue with non-completed backup as you supposed. Today, I've got a yesterday's snapshot and that is fine. Could you please suggest if you could give me some suggestions regarding porting of your code into python? At least I need to evaluate complexity and time frame needed to complete that.

[horrorho]

Hi and thank you! Contrary to what some believe, I don't know that much about iOS. I still don't own an iPhone. I'm just going to wait until iOS 10 arrives before working with it. That is if I do indeed have the spare time to work with it.

That being said the iOS 8 -> 9 jump was huge due to the migration to CloudKit. Most of our coding here revolves around CloudKit. I'm not expecting such huge changes going in iOS 10. But no doubt Apple will break things for us again.

If you want to port the project to Python that would be brilliant. The reason I've been tidying up code, as opposed to piling on features is to try and make it easier for others to port. The last of the demons is the download engine which I'm re-coding, though it works well it's a horrible convoluted mess.

If you are interested in porting, let me know and I can make suggestions has to how you could approach it.

[ajlyakhov]

I'm agree that clean up code is a good way to help with porting. If you interested, I could upgrade one of our devices to iOS 10 (it is already available for developers), create an iCloud backup and see what happened with retrieval attempt :)

[mca-gif]

I've been testing all of the new updates against my personal device running iOS 10. It shouldn't be considered an extensive test. Everyone should be able to upgrade their devices to iOS 10 as part of the public beta test, if you'd like.

[ajlyakhov]

Thank you Matthew for your note! Did you try to run InflatableDonkey against iOS10 iCloud backup?

[horrorho]

@ajlyakhov thank you for the update! Hopefully we won't see too much in the way of change for a public release.

[ajlyakhov]

@horrorho could you please suggest if there are some method I could check why my latest snapshot does not appear in a list of snapshots? I'm looking at iOS10 updates and if they influence on InflatableDonkey ability to retrieve backups. After latest update, I see backups up to 6th of August when iOS10 latest update been installed.

[horrorho]

I don't have access to iOS 10 backups at present, so it might be difficult to assist if the problem isn't trivial to solve.

As a first step could you try this step from a previous issue. Be careful to filter out the reply as explained.

[horrorho]

Thank you for the feedback, I'm glad you got it figured.

As for the Python porting time frame and complexity, it's a difficult question to answer. I don't work in IT so I don't really have a concept of how quickly projects move along outside of my own personal experience. Excluding the Protobuf auto-generated classes, there are about 25k lines of code. Most of it in fairly small classes of a few hundred lines at most. As you would expect there is a fair amount of crypto and IO code.

The biggest issue is that a lot of the protocols are undocumented, they are my distilled interpretation of what the Apple binaries are doing. However it shouldn't be hard to pick up what's going on by examining the code.

You definitely want to fiddle with the logging configuration to dump out what's going on under the hood. For full trace logging and headers we can substitute in:

    <logger name="com.github.horrorho.inflatabledonkey" level="trace" additivity="false">
        <appender-ref ref="STDOUT" />
    </logger>

    <logger name="org.apache.http.headers" level="debug" additivity="false">
        <appender-ref ref="STDOUT" />
    </logger>

As to where to start? I'd strip out the frills and follow the code/ logging flow. So authentication, escrow keys and so forth. If it doesn't work, you can try again comparing your http client-server responses with what InflatableDonkey is telling you it's doing.

However, you MUST get the escrow SRP exchange working properly before you use it on live servers, otherwise you can potentially lock out the account. Hopefully you can find a nice Python library to get it done which will save you coding it as I have done.

I've had a few individuals express an interest in porting to Python. I have suggested they open a ticket asking if others would also be interested and possibly getting a group effort going. As of yet, nobody has done so.

[ajlyakhov]

Thank you for intro. As I understood from your latest project update, you plan to put this project on hold. Could you please suggest if you'd be able to answer some questions as I still have a serious plans to port your work in some form into python? I'm thinking about some kind of library without any download threading implementation and other complexities but focus on decryption and filtering. That future library should be used to implement end-user tools.

[horrorho]

@ajlyakhov if I were to recode this project I would do things very differently. But as it is we have:

• Core CloudKit layer:

1. Authentication.
2. CloudKitty - Talks to CloudKit servers and returns various records. Based on protobuf.
3. PCS - Handles the decryption of CloudKit records. It starts off with a key bag we unlock with an SRP exchange. This key bag is then used to decrypt records, which may be nested within zones that have additional encrypted keys. I've tried to document the various methods used along with links to RFCs. It's crypto heavy but just be glad you didn't have to sit there and reverse engineer it from binaries like I did.

This core can be used to power various tools. InflatableDonkey uses it to retrieve iCloud backups (PCS_BACKUP). I also have a hacked version of InflatableDonkey that uses this core to retrieve cloud photos (HYPERION).

Other services are:

    PCS_MASTERKEY(1), // MasterKey
    BLADERUNNER(2), // iCloudDrive
    HYPERION(3), // Photos
    LIVERPOOL(4), // CloudKit
    PCS_ESCROW(5), // Escrow
    PCS_FDE(6), // FDE
    PIANOMOVER(7), // Maildrop
    PCS_BACKUP(8), // Backup
    PCS_NOTES(9), // Notes
    PCS_IMESSAGE(10), // iMessage
    FELDSPAR(11), // News

• iCloud backup (PCS_BACKUP) retrieval layer

1. Query for devices, snapshots and assets.
2. Authorize and download assets. Files are created from encrypted chunks which are stored on third party servers. This returns us a list of urls to get these chunks from and how to decrypt/ piece those chunks together. The process is similar to iOS 8 but with improved encryption mechanics.
3. Data Protection. Files may be encrypted. To decrypt them we need retrieve, unlock and then use another key bag. Files are encrypted using AES-CBC or AES-XTS, see Disk_encryption_theory.

• iCloud photos (HYPERION) retrieval layer (unpublished hacked InflatableDonkey).

1. Create a sync and retrieve a list of photos assets.
2. Authorize and download assets. No additional decryption is required.

I was considering pulling out the core layer and forming a separate project. As a side note, I've seen some naughty third party recovery tools VMProtect hacked Apple binaries instead of writing their own core layer. I guess they were thinking no one would notice...

There is a lot going on and I could easily write a little book on this with lots of unpublished/ secret information. Maybe I should do that.

[horrorho]

@ajlyakhov 'I'm thinking about some kind of library without any download threading implementation and other complexities but focus on decryption and filtering. That future library should be used to implement end-user tools.'

To clarify further. I would consider writing a core layer as described above first. Then you can provide additional tool layers on top of that.

The easiest approach would be to drive Windows Apple dlls directly as other third party tools are doing, but this would obviously tie you into the Windows platform. I do have a C++ tool that does this that I created as part of my research process to spy on client server calls, manage debugging with OllyDbg, etc. It can download iOS 9 backups, minus Data Protection which I never implemented. However, I been reluctant to acknowledge its existence or to provide specific details.

[ajlyakhov]

If you write core layer that would be awesome and really speed up dev process. I'd prefer never ever stick to windows OS. All my development run on Linux based systems. But I agree that it is interesting idea to reuse Apple binaries to simplify adoption to Apple updates. We could experiment with vine for that.

[horrorho]

@ajlyakhov To clarify, the core layer code is already present in InflatableDonkey. It doesn't need to be written. I was considering pulling it out as a separate project so it could be reused. However it's a time issue and I'm not actually sure anyone would know what to do with it.

[SmoothAF]

Honorable sir @horrorho, could you please publish the "unpublished hacked InflatableDonkey"?

[horrorho]

@SmoothAF I have a number of private tools that I don't have plans to release. However if you have an open source project that requires assistance then I may be able to help.

[horrorho]

Stale issue. Closing.