Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Encryption! #5

Open
vgmoose opened this issue Feb 12, 2019 · 3 comments
Open

Support Encryption! #5

vgmoose opened this issue Feb 12, 2019 · 3 comments
Labels
good first issue Good for newcomers help wanted Extra attention is needed

Comments

@vgmoose
Copy link
Owner

vgmoose commented Feb 12, 2019

I don't know the first thing about doing this, but it would be awesome.

I guess step one would be to make an iPhone backup with encryption on for a known password and to inspect the files it creates and try to see how they get from plaintext A version of a file to encrypted B version of the same file.

@armaanhammer
Copy link

armaanhammer commented Feb 12, 2019

Is there a whitepaper out there about how the unencrypted files are stored? I've just started looking through your codebase, but can't seem to tell where the file parsing / conversions are happening, or what exactly is being done.

I'm not a Swift developer yet, but beginning to cut my teeth on it.

@vgmoose
Copy link
Owner Author

vgmoose commented Feb 18, 2019

Unfortunately, I don't know much about the unencrypted format or if there are any documents on it. I made this program with the observation that if you go through an encrypted backup directory file by file and ignore the directory/naming structure that you can still determine the file type (using magic numbers in the file) and then rename/copy out the file based on the extension.

The main loop that runs on each subfolder of the (unencrypted) backup is here: https://github.com/vgmoose/OpenBackupExtractor/blob/master/Open%20Backup%20Extractor/ViewController.swift#L267-L290

Which calls a parse method in this file that contains the actual mapping of file magic responses to file extensions (and also is hooked up to the checkboxes in the UI, so the user can choose what to export): https://github.com/vgmoose/OpenBackupExtractor/blob/master/Open%20Backup%20Extractor/SelectableTypesView.swift

The file magic checking is done by using calling out to libmagic, which is what the unix file command uses.

That being said, it looks like someone has managed to decrypt an itunes backup and document the process: https://stackoverflow.com/a/13793043 – so a quick way to do this would be to just "decrypt" the file after getting the decryption information, and then use libmagic to identify it.

From step 4 of that stack overflow:

For each file of interest, get the class-encrypted per-file encryption key and protection class code by looking in the Files.file database column for a binary plist containing EncryptionKey and ProtectionClass entries. Strip the initial four-byte length tag from EncryptionKey before using.

It looks like the filename can also be extracted though, so libmagic wouldn't be needed if one just wanted to browse a filesystem-organized backup.

Although... at the bottom of the same stack post:

That code no longer works on backups from phones using the latest iOS, but not all that much has changed

So it looks like there would still be more work beyond just translating the python code

@TomasHubelbauer
Copy link
Contributor

Hey, I just tried extracting a backup that I know is encrypted to see what would happen and I got a bunch of TXT files with binary contents. I wonder if in the meantime it would be possible to detect encrypted backups and show an error instead of extracting them? I am not sure if that's technically feasible though.

@vgmoose vgmoose added help wanted Extra attention is needed good first issue Good for newcomers labels Sep 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants