Add native support for iTunes encrypted backups #1023
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… line switches to either receive the password or prompt for it, changes to the iTunes FileSeeker to handle decrypting the Manifest.db and files as they get copied out. Does NOT yet touch the GUI which still needs a way to prompt for the password.D
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Good evening!
This PR is an initial shot at adding support for encrypted iTunes backups directly in iLEAPP, instead of needing to use an external tool to unpack it first. Python is certainly not my preferred daily driver language, so I'm more than open to hearing improvements you'd like to see before merging. That said, I'm also plenty happy for someone else to run with this, it was just a quick Saturday night feature push to clear my head of another technical hurdle I was stuck on.
This includes new command line line switches to either receive the password (
--itunes_passcode) or prompt for it (--prompt_for_passcode). It changes the iTunes FileSeeker to automatically identify if the file is encrypted by readingManifest.plist, handle decrypting the Manifest.db, building the set of protection classes that will unwrap encryption keys, and decrypting files as they get copied out. These changes try to be as nice as possible to RAM and CPU by only grabbing additional details if the folder is actually encrypted, for example. It also sets a default ofNoneto the function arguments it added, so no current calls should need to be updated.This does NOT yet touch the GUI which still needs a way to prompt for the password. Because FileSeeker detects the encrypted backups automatically, once there is a way to put a passcode into the GUI, it should be minimal changes to make that work, as well.
Having run a comparison between an encrypted and unencrypted backup from the same device (unfortunately, not from the same time, so there are some differences between them) showed largely similar results. The encrypted backup too 5.45 seconds of processing time and the unencrypted took 3.12, so for large devices total time might chew up a bit with all the decryption, but it is hard to say exactly how much since the extra 2 seconds includes a million-round PBKDF2 iteration and it may be once that overhead is done the files are nearly instantaneous.
Appreciate any feedback you have. Would be happy to work on this as I have spare time, or see someone make edits to it directly to get it merged.