pajowu/signal-backup-decode

Bogus "Config file does already exist:" error

tmo1 opened this issue · 7 comments

tmo1 commented

Hi,

I invoked signal-backup-decode in an empty directory as follows:

~/.cargo/bin/signal-backup-decode -p <password> ~/path/to/signal-backup-file/signal-nnnnnnnn.backup

and the program bails with:

nnnn [ERROR] Config file does already exist: signal-nnnnnnnn/preference/SecureSMS-Preferences. Try -f.

Running it with -f does indeed allow it to proceed without error, but I don't understand why the error is occurring in the first place, and whether using `-f' is causing the program to clobber some file.

Thanks again for this great utility!

baltakatei commented

I can confirm that I need to use the --force flag to extract messages. My backup file is "Database Version: 85". Should writes to the preference/SecureSMS-Preferences file need to be appends instead of rewrites?

The command that works for me (for others' reference):

~/.cargo/bin/signal-backup-decode signal-2021-01-01-23-59-59.backup --output-path ./output-force/ --password-file /tmp/key.txt --output-type RAW --force
04:35:40 [INFO] Output path: ./output-force/
04:35:40 [INFO] Input file: signal-2021-01-01-23-59-59.backup
04:35:40 [INFO] Database Version: 85
             Bytes read: [00:00:25] [##################################################] 3.94GB/3.94GB
Read vs. written frames: [00:00:25] [##################################################] 31144/31144
  • Without the --force option, SecureSMSPreferences ends up containing one line: pref_identity_public_v3=stuff. The status message indicates Read vs. written frames count doesn't complete (e.g. 31127/31128). The signal_backup.db file (containing Signal messages) is missing.
  • With the --force option, it also contains a second line: pref_identity_private_v3=stuff2. The Read vs written frames count completes and reaches a higher number (e.g. 31144/31144). signal_backup.db is present.
  • Note: the 30-digit Signal secret is a simple one-line text file with no spaces or line breaks at /tmp/key.txt.

I'm using Debian Testing (bullseye/sid). I compiled signal-backup-decode using:

$ sudo apt install git rustc libsqlite3-dev libssl-dev pkg-config protobuf-compiler
$ git clone https://github.com/pajowu/signal-backup-decode ./localRepo
$ pushd ./localRepo
$ cargo install --features "rebuild-protobuf" --locked --path .

where localRepo was the path of a clone of this git repository's master branch. I followed this post's recommendations for installing dependencies on Debian.

mutlusun commented

Hello,

Actually I added this flag to prevent accidental overwriting one's backups. This may not be intuitive but is safer as the other way round.

pajowu commented

Maybe we should keep a list of files that were created while this tool was running (simple hashmap should do) and not show this error for those files.

tmo1 commented

Hello,

Actually I added this flag to prevent accidental overwriting one's backups. This may not be intuitive but is safer as the other way round.

Thank you, but I don't understand - of course it's a good idea to require confirmation before clobbering an existing backup, but why is it required when doing a fresh extract, when there's no existing backup to be overwritten?

pajowu commented

Hey, if you want to, you could check the code in the feature/override_self_created_files branch. This should fix your issue, but I couldn't test it yet

mutlusun commented

Sorry, I misread your issue report. I thought you are talking about a subsequent run. I didn't notice that the problem occurs on the first run. Thanks, @pajowu !

pajowu commented

This should be fixed with version 0.2.3, which will be in crates.io in a few minutes