Handle cases where Manifest.db's reported size doesn't match

[malicious]

I noticed the discrepancies while trying to create a re-encrypted backup, based on files decrypted with MVT. I haven't seen any pattern for when Manifest.db sizes are wrong, or even whether those sizes are reliable; the end-of-file AES padding seems to be the most reliable source of information.

At any rate, these changes at least guarantee consistency with the original encrypted backup. Overall logic:

• in the "normal" case, AES padding is up to 16 bytes, truncate as normal
• if the original file size is more than 16 bytes greater, leave it alone (and remove some extra padding that gets added during encryption)
• if the original file is smaller than the recorded size, avoid truncate, which will extend the size automatically (and turn the AES padding into part of the file)

This was tested by using pip install -e . on a local checkout, with mvt-ios decrypt and then a custom script to re-encrypt backups. Systems used were macOS 10.15-12 Python 3.8-3.10, and backups were for iOS 14.7-15.7.

[malicious]

Anecdotally, this happened for only 30 of 3800 files while reviewing one iOS backup. ~So overall not very noticeable, unless it hits one of the files you're looking for.~ Actually, this happens almost exclusively with SQLite database files. So it will be very noticeable.

[malicious]

https://gist.github.com/malicious/cd2a17f1ace34d27a8c710892721b28d Custom script to reproduce this issue. Run on a decrypted backup directory:

mvt-ios decrypt-backup --destination rgax-decrypted/ rgax/
python re-encrypt.py rgax-decrypted/ rgax-reencrypted/
diff -rq rgax/ rgax-reencrypted/