-
Notifications
You must be signed in to change notification settings - Fork 56
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
Add support for crypt15 #94
Comments
Can you elaborate this point?
|
Also can you provide the path of these files like this? {
'key': 'apps/com.whatsapp/f/key',
'msgstore.db': 'apps/com.whatsapp/db/msgstore.db',
'wa.db': 'apps/com.whatsapp/db/wa.db',
'axolotl.db': 'apps/com.whatsapp/db/axolotl.db',
'chatsettings.db': 'apps/com.whatsapp/db/chatsettings.db'
} |
If end-to-end encrypted backups are enabled, the "key" file will still continue to exist in the file system and it will not be deleted. However, it will not be used anymore: whatsapp will encrypt the backups using the file "encrypted_backup.key" and will not use "key" anymore.
Hmmm I don't know which format are you talking about, but they should be of the same type of the "key" file so if I were to take a guess: {
'encrypted_backup.key': 'apps/com.whatsapp/f/encrypted_backup.key',
'password_data.key': 'apps/com.whatsapp/f/password_data.key',
} |
Ah okay, I have seen some use of encrypted_backup.key on a repo but couldn't understand (I still have crypt14). Actually the android backup (.ab) file has a particular directory layout, similar to app's private data directory (inside /data/data/ folder) and unless I have the path to these files I can not implement this. Let's see if someone comments the path or I get the crypt15 first. |
to "get the crypt15" you have to manually enable end-to-end encrypted backups in whatsapp settings. |
I managed to find 'encrypted_backup.key' beside 'key' but not 'password_data.key'. For now I'm assuming that is also beside key and updating the code. |
Not fully tested, paths for these new files may not be exact.
Hi, I forgot to tell you, password_data.key will only be there if the user enters a password for encryption, not if you use the 64 character key. So it might or might not be there |
Oh, that makes sense actually. Anyways it looks for both of these and in 404 case it prints to console the link for this issue. I might add a mutual exclusiveness check for these later on.
…-------- Original Message --------
On 21 Apr 2022, 12:48 am, Davide Palma wrote:
Hi, I forgot to tell you, password_data.key will only be there if the user enters a password for encryption, not if you use the 64 character key. So it might or might not be there
—
Reply to this email directly, [view it on GitHub](#94 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AMT67DTMWUYTCBD5VX75H7DVGBJ7LANCNFSM5TTNDI3Q).
You are receiving this because you commented.Message ID: ***@***.***>
|
Imo the program should dump whatever it finds, the user will then have to understand what they need |
It already does that with argument '--tar-only'. It dumps the tar file, but not everyone likes to be overwhelmed so I cherrypicked a few important files.
-------- Original Message --------
…On 21 Apr 2022, 1:24 am, Davide Palma wrote:
> mutual exclusiveness
Imo the program should dump whatever it finds, the user will then have to understand what they need
—
Reply to this email directly, [view it on GitHub](#94 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AMT67DTSMNJ6EJDT4XBRXULVGBOHDANCNFSM5TTNDI3Q).
You are receiving this because you commented.Message ID: ***@***.***>
|
Note that password_data.key is not needed to decrypt the backup. encrypted_backup.key will always be used. However, the user might want to offline bruteforce the password, this is why it should be saved if there, but its absence does not mean anything |
Thanks for the info, I'll make a note of it in further updates. |
Hi,
Should be a pretty easy job
With crypt15 two new files have appeared, they are called encrypted_backup.key and password_data.key
"key" will continue to exist, but only encrypted_backup.key will be used
The text was updated successfully, but these errors were encountered: