Constructing decrypted iOS backup

[malicious]

Hello, has anyone looked into creating a usable, decrypted iOS backup? (As in, you can restore the decrypted backup with macOS Finder.)
I'm mostly trying to do this for education purposes, so I've been trying with an iOS 15.7.1 backup (for a newly wiped phone, the directory is approximately 22 MB). Steps I've taken so far:

• decrypt the actual files with mvt-ios (filesystem files + Manifest.db)
• change the encryption/protection class for each file in Manifest.db (5 => 3 and 6 => 4), removing the EncryptionKey and recomputing the SHA1 hash
• removing encryption-related keys from Manifest.plist's BackupKeyBag (DPIC, DPSL, DPWT, and setting IsEncrypted to false)

This works for a few minutes, but then Finder reports that "the backup is corrupt". I'd guess that most of my top-level checks are fine (remove passcode key stuff, change file protection classes), but something is off about how I'm doing the per-file bplist in Manifest.db. Does anyone know if this has been implemented somewhere? Or debugging steps that can help me figure out what Finder is doing when it reports corruption?

[malicious]

Ah, I think I have a lead on this: the file size recorded in Manifest.db is sometimes substantially smaller than the actual size of the file, though the recorded SHA1 hash will match. I think this outFile.truncate() line in the iOSbackup library needs to be a little smarter in case of substantial mismatches, to make up for what may be a race condition on the Apple side.

• For example, my gyroCal.db file is around 32 KB, but the Manifest.db size is reported as 4096. The data's all there if you comment out the truncate line.
• The iOS backup encryption also adds padding to align the input to a 16-byte boundary, which I'm trying to account for, but I haven't been able to figure out the exact rules.

Having incorrect data on the encryption and decryption side is more than a little annoying. I hope I can brute force one or both sides of the process, rather than having to manually inspect the "corrupt" files each time.

[malicious]

Okay, I have found that SQLite databases in a backup directory will be decrypted incorrectly because of this Manifest.db size-mismatch issue. This is extremely troubling (important databases like SMS.db can get truncated), but since it's in an upstream project, there's nothing to do here.

• PR: Handle cases where Manifest.db's reported size doesn't match avibrazil/iOSbackup#26
• re-encryption test script: https://gist.github.com/malicious/cd2a17f1ace34d27a8c710892721b28d