[ERROR] failed to fill whole buffer

[rhk]

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]

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]

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

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

[pascalgn]

Thanks to the pointer from @ribbons I could create a PR: #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) 🤷