pajowu / signal-backup-decode

Decode Signal Backups
GNU General Public License v3.0
216 stars 18 forks source link

[ERROR] failed to fill whole buffer #58

Open rhk opened 1 year ago

rhk commented 1 year ago

Thanks for the awesome tool! However I run into an issue when running:

rhk@haapa:~/Datat/backup/signal/signal-backup-decode$ signal-backup-decode --no-verify-mac -v WARN -f --password-file ../salasana.txt signal-2023-04-13-03-59-11.backup Bytes read: [00:02:32] [#################################################>] 6.33GB/6.33GB Read vs. written frames: [00:02:32] [##################################################] 129207/129207 07:14:34 [ERROR] failed to fill whole buffer.

rhk@haapa:~/Datat/backup/signal/signal-backup-decode$ signal-backup-decode --version signal-backup-decode 0.2.3

rhk@haapa:~/Datat/backup/signal/signal-backup-decode$ lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 12 (bookworm) Release: 12 Codename: bookworm

Any ideas what's wrong or what to try?

multimob commented 1 year ago

We found out signal-backup-decode 0.2.3 can still handle backup files created up to around mid-July 2023. It fails when opening any backup file created with recent versions of Signal (current version is 6.27.10) and produces the same error message.

Running with -v DEBUG produces a string like this. Hex values edited for privacy. It ends after reading the first frame. Observe the length (812 Mb despite the backup file itself is only 2 Mb). Same error message whether the password is correct or not.

00:22:49 [DEBUG] (1) signal_backup_decode::input: Frame type: Header Frame (salt: [01, AA, 2F, 1A, E8, 33, 1E, 8F, 44, 19, EE, 15, 33, 5A, 92, A4, 7A, AA, AB, 4E, 12, 01, 2E, 5F, 11, 26, C7, 9B, 4A, 50, D1, 80] (length: 32), iv: [1A, BB, CD, E9, 15, 12, 22, 19, AB, 01, 91, A2, 31, AA, A1, F0] (length: 16)) 00:22:49 [DEBUG] (2) signal_backup_decode::input: Read frame number 1 with length of 812962618 bytes 00:22:49 [ERROR] failed to fill whole buffer.

ribbons commented 1 year ago

Not an expert but this rather opaquely documented commit seems like it could well be the culprit: signalapp/Signal-Android@c6473ca9e63236af3eae9959a50cfa643d53272e

The new function called isFrameLengthEncrypted seems like it's particularly relevant to the error we're seeing.

pascalgn commented 1 year ago

Thanks to the pointer from @ribbons I could create a PR: https://github.com/pajowu/signal-backup-decode/pull/60

I'm quite sure it's working correctly, but I only checked the attachments, I didn't look at the SQL file.

The code isn't great and it's missing the version check (for older backup file versions, it should use the old logic) 🤷