Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE] Validate the provided decryption key against an encrypted backup and exit #130

Open
ritiek opened this issue Feb 20, 2025 · 6 comments
Assignees
Labels
android Android exclusive issue enhancement New feature or request pending for release Feature or bug fix to be released

Comments

@ritiek
Copy link

ritiek commented Feb 20, 2025

Hi, thanks for creating this tool!

I do automated periodic snapshots of my WhatsApp backup. I'm also interested in automating whether the decryption key I currently posses is valid for the latest snapshot. Currently it seems tricky to perform such a check without having the exporter write the decrypted db file to disk.

Does it seem interesting to have a param such as --dry-run, which'll only check whether the provided decryption key is valid for a given backup file and then exit with an appropriate return code? It'll help me keep in check whether my snapshots are dependable or not in the time of need.

@KnugiHK KnugiHK self-assigned this Feb 21, 2025
@KnugiHK KnugiHK added enhancement New feature or request ios iOS exclusive issue android Android exclusive issue and removed ios iOS exclusive issue labels Feb 21, 2025
@KnugiHK
Copy link
Owner

KnugiHK commented Feb 21, 2025

I added a dry-run logic to the decrypt_backup function. I hope that will be useful for you!

@KnugiHK
Copy link
Owner

KnugiHK commented Feb 21, 2025

Moreover, rather than adding the --dry-run option to the exporter (which doesn't seem right to me), I think it would be better to load the decrypted database into memory and work with the in-memory version. In this way, no decrypted database will be written into disk.

I am not sure if the sqlite3.Connection.deserialize method introduced in Python 3.11 will help.

@ritiek
Copy link
Author

ritiek commented Feb 22, 2025

I added a dry-run logic to the decrypt_backup function. I hope that will be useful for you!

Much thanks!

Moreover, rather than adding the --dry-run option to the exporter (which doesn't seem right to me), I think it would be better to load the decrypted database into memory and work with the in-memory version. In this way, no decrypted database will be written into disk.

I am not sure if the sqlite3.Connection.deserialize method introduced in Python 3.11 will help.

Yep, I guess this area could be improved a lil. Currently it's not very clear that the tool writes the decrypted msgstore.db in current working directory. On my first try, it seemed like it was normal to take a while to decrypt the messages (when in fact the tool was almost immediately done with decrypting the db and was on the next stage taking its time to write the html files).

Although I think some people may also play around with decrypted db itself (in addition to post processed html/txt), so we might want to keep some way to write the decrypted db to disk.

KnugiHK added a commit that referenced this issue Feb 26, 2025
This commit also made `dry_run` and `keyfile_stream` keyword arguments

Affects #130
@KnugiHK
Copy link
Owner

KnugiHK commented Feb 26, 2025

I have moved the decrypt_backup function to a separate module called android_crypt in commit b2bcf36. You should now import it using from Whatsapp_Chat_Exporter.android_crypt import decrypt_backup. Additionally, please note that the dry_run parameter is now a keyword argument. See the function signiture below:

def decrypt_backup(
    database: bytes,
    key: Union[str, io.IOBase],
    output: str = None,
    crypt: Crypt = Crypt.CRYPT14,
    show_crypt15: bool = False,
    db_type: DbType = DbType.MESSAGE,
    *,
    dry_run: bool = False,
    keyfile_stream: bool = False
)

ritiek added a commit to ritiek/dotfiles that referenced this issue Mar 1, 2025
ritiek added a commit to ritiek/dotfiles that referenced this issue Mar 1, 2025
@ritiek
Copy link
Author

ritiek commented Mar 1, 2025

That does it for me. Thanks again.

@ritiek ritiek closed this as completed Mar 1, 2025
@KnugiHK
Copy link
Owner

KnugiHK commented Mar 1, 2025

Good to hear that! I will leave this open until release.

@KnugiHK KnugiHK reopened this Mar 1, 2025
@KnugiHK KnugiHK added the pending for release Feature or bug fix to be released label Mar 1, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
android Android exclusive issue enhancement New feature or request pending for release Feature or bug fix to be released
Projects
None yet
Development

No branches or pull requests

2 participants