file_blob not a plist for iOS 10 backup

[zerolagtime]

I've got a backup

Product Type : iPhone7,2
Product Version : 10.0.2
iTunes Version : 12.5.2.36

password-protected backup. I'm trying to recover my keys for Google Authenticator. I have the password, but it's my first go around at trying this. Yes, I know I have the password - I used it to restore the backup to another phone when my first one went for a spin in the washing machine.

I'm getting an Expat error in backups/backup10.py:81. When I step through to see the string it is trying to parse, it's obviously "encoded" and not XML for a plist file. So obviously, it fails to parse and crashes.

By "encoded", I mean that I don't recognize it and have been unable to translate it to XML. I tried using base64's base64.b64decode() on the string, and got binary data, but it did parse. Base32 decode did not parse. Is this string AES encoded? What would be a quick test I could run on the base64 decoded (and thus binary) data? The string is

N6WN84yeiT8Lgb8GpeijYV/ReSICttKt19M32XDvRgzIaC1mo5THYwK8BMafdSpy474jClleTZC7WRRlzfHcxd07vkN+yipgzM3i9wjXJFdPFQg06LTOQk9LzOTIGiF3452S6Hk4W+9LrxMUBpTCNNDQWt6Monflnn50VDMJRH97BWsrsavKlTPbr4vPL23bmpPaoBiHpt0MNntX1R1N3/kud2QpybQsydwa8Njl1hhAeqG+t484dJSIwaXIb4Kvptrx16kpBOROL/cGdmOu/2MYspOIKIk7qaRF/DDCfWAWDUJwwAycB4VlmlzeTNVkEiO33KMiLN4eYa90GjtCCzMuhjM/emAzJgx9frq9Hf6hlicasfEUZDmQ69Fv0r8/KZMpnNY8eufCBRsGO9Ppd32j1HD68SJfeV5Ns4Uglw/0eMGlXVFQrTLlAvclz8A5EQAfaCiN0xl/8jlgVXerf1wche9mtZIhPH+2QM0YNBC4KE4b+M7SL8vmN0SlSdCOobWo0cQdhcMq2BDiEgLEjR4a0Em3aEI2gju1ZtkyLNk=

The good news is that backup10.py successfully opened the sqlite3 database. Any pointers?

[lcfr123]

There already is s a pull request that fixes this, and I've got some small additions to that locally. So we just need to be patient with the maintainer. After he accepts the pull request, things should work.

[zerolagtime]

I've been checking out the pull request and it doesn't address the blobs in the Files.file column in Manifest.db. The text above isn't a plist and it isn't a bplist (it would start with the magic bplist text if it were), so I'm not sure. I've tried to treat the binary blob as an AES encoded string, in any bit strength or block mode, but openssl claims that it doesn't have the magic number for an AES-encoded block.
Maybe the encrypted backup you are using to validate the patch was with a slightly newer backup version. Not sure.

[JoshuaErnewein]

It appears to me that iOS 10.1 and above has the Files.file column in the Manifest.db as a standard bplist file, but iOS10.0.x has it encoded somehow. Sorry I'm not much more help than this, I'm also curious on a solution to iOS10.0.x files.

[bacoboy]

Looks like I got stopped by this too. :( Hopefully somebody has some nog-enspired ideas on this...

[lcfr123]

There has been a pull request waiting for merge for a couple of weeks that fixes this, together with my local patch. So nothing else to do but wait for the maintainer, or someone with write access.

[bacoboy]

Can you reference the patches on this issue so I can pull them and give it a try? Thanks!

[lcfr123]

Pull request #12. See the comments in that request for what I patched.

[dinosec]

Thanks for the contribution and sorry about the delay merging this pull request.

[bacoboy]

Didn't seem to help me so since this issue doesn't match exactly my issue, opening a new issue to track. Thanks for the help!

[bkerler]

Yes, the issue is that the base64 data are neither bplist nor plist. It's encoded/compressed somehow. Having the same issue on a iOS 10.0.2 device. Happens on both encrypted and unencrypted backup. Thus, issue needs to be addressed.

[chiefbrain]

I created a fork at https://github.com/chiefbrain/iphone-dataprotection where I try to solve it. This behaviour only occurs on 10.0 <= iOS < 10.1.
The base64-data is encrypted with AES128CBC. I achieved to successfully decrypting it but the parsing of the resulting plist fails. Any help is appreciated.

[dinosec]

Reopen under request, as this issue is not solved for iOS < 10.1.

[zaphodatreides]

I had the same issue. Just decrypted a password protected iOS 10.0.2 backup.
In case anyone is still interested:
Changed chiefbrain's code:
in backup10.py put
aes = AES.new(key, AES.MODE_CBC, iv)
just after
if cryptedFileInfo:
because if left where it was, only the first file blob was correctly deciphered.
The problem is that deciphered file_blob is padded, we have to determine the original (correct) size for file_blob I did it by deleting all bytes that have the same values and leave two bytes after a zero... Very ugly hack... But it deciphered my backup except one file.

[ameyaonline]

iOS 10.0.2 specific backup extraction quirks, might apply to other versions, here is a PR. Sadly I was stuck with a backup for that version and needed to extract items out of it.
#30