Additional functionality/ optimisations.

[horrorho]

Functionality/ optimisations that I would like to implement given time. Possibly of interest to those wanting to port this project.

• DsPrsID token caching. At present users are advised to manually handle dsPrsID tokens for repeated usage of an iCloud account. NB Do we need to obfuscate/ encrypt tokens?
• CloudKit token caching.
• Escrowed key bag caching. A full escrowed key bag SRP exchange is conducted each time the tool is called. This is unnecessary and slow, we can cache the escrowed key bag and verify matches using the supplied digest.
• Manifest cache for snapshots.
• Asset cache for snapshots. NB Tokens do expire after 48 hours.
• Cache purge. Over time our chunk cache may well become bloated and we have no way of removing obsolete chunk data. We would need to authorise all assets over all devices/ snapshots and then disregard the unneeded chunks. Consider a --purge command.
• Improved cached file reconstruction. As it is we reconstruct cached files from cached chunk data even if they already exist. This is potentially slow, particularly with physical storage devices. We can verify a file's presence/ hash and safely skip reconstruction. Also within the confines of a snapshot and assuming that data once written remains intact, we could just verify a file's presence/ length/ time stamp. The latter method although quick is potentially risky and we might want to issue a --force switch to override it.
• Empty files/ directories. At present these are ignored although we should really reconstruct them.
• iTunes style backups.
• Two-step verification.

Functionality I've been reluctant to implement.

• Post retrieval snapshot/ file manipulation. I've had numerous requests to organise files in numerous different ways post recovery. I believe this should remain outside the remit of this project as most modern operating systems already provide the necessary tools to accomplish this. Also in accommodating numerous file reorganisation strategies we risk significantly complicating our command line arguments.

Additionally:

• We aren't really there with separation of concerns, so to cleanly de-construct InflatableDonkey into core libraries: CloudKit, PCS, chunking etc. This would provide a foundation on which we can build other CloudKit based tools.

[ghost]

Would you be able to implement an iCloud Photo Library downloader / engine? It would be huge to be able to implement that into other projects as well as having that power programatically.

[horrorho]

@ManWhoAmI I have a hacked version of InflatableDonkey that does just that, but along with a number of other private tools I don't have plans to release it. I just don't have the time to clean up, debug and maintain additional projects. I'm also acutely aware that a lot of my work is ending up in commercial projects and not in open source projects. This is the reason I haven't released my C++ research tools/ prototypes that work with Apple dlls directly even though they provide a very simple and robust platform specific solution.

If someone starts work in earnest on porting InflatableDonkey to Python or another language, as an open source project mind you, then I'll assist and release the API calls required when the CloudKit/ chunk engine code base becomes functional. However to be honest, someone who pulls that off should have no issue in figuring out what to do themselves.

Sorry for the cynicism.

[horrorho]

@ManWhoAmI However, if by some miracle I do have free time over the new few months then I'll de-construct InflatableDonkey cleanly into it's core libraries: CloudKit, PCS, chunking etc. These can be used to do what you want along with other things like iCloud documents.