Goal: pass a whatsapp chat history backup (.crypt12) from one device to another with different telephone (whatsapp account) numbers.
Update: I succeeded with ultimate goal to move the chat history to a different device with a different phone number, but I failed with the re-encryption.
Encryption
First, I believed that the /data/data/com.whatsapp/files/key file might have been a leftover from an old version of Whatsapp on the old device, because I could not find the file. It turned out that it was generated later on the new device, after I finished my experiments. I’m not sure what triggers its creation.
Furthermore I was not able to decipher header and footer of the crypt12 backup file. I believe that a message authentication code (MAC) is part of it and something related to the Whatsapp account number (telephone number), because the app was quick in determining if a backup file is a restore candidate without decrypting, I’ld say.
How I managed to transfer the chat history:
Short version: get root on both devices and move /data/data/com.whatsapp/databases/msgstore.db over to the new device.
Long version: root on the new device will be less problematic, I guess. For the old device I used the fishy Kingroot app. It looks very professional and seems to download exploit code from a huge database for many devices. I got instant root access without flashing anything, but to be honest I don’t trust it regarding what else it might be doing...
Kill both Whatsapp apps before reading the msgstore.db file from the old and writing to the new device. I also removed the msgstore.db-* files on the new device. Sqlite might detect itself that the new database does not fit those helper files, but if they are not even there, they will be recreated correctly without any doubt.
Also set the permissions and ownership of that file to what it would be on the new device (not the old). My biggest oversight were the SELinux security attributes stored in the extended file attributes (XA). It made me believe that Whatsapp is verifying the database content and rejects it, but in reality it eats it just fine, as long as it gets proper access to it.
The XA tools I had available on the phones apparently show all the extended file attributes with “getfattr -d filename”, while e.g. on a standard Linux you need “getfattr -dm- filename” to get them all, not just the user.* domain. „ls -Z” shows the SELinux security context, which is a specific part of the extended file attributes, and in this case the only part I had set.
As with the file ownership, check which context is usually set on the database file on the new device and set it accordingly (“setfattr”). My old device did not even have SELinux and no extended file attributes were set there.
Other findings:
As the restore kicks only in during initial whatsapp setup, I’ve cleared data on whatsapp a lot. Constant reactivating the same phone number will trigger a hold-off on the whatsapp servers, delaying activation-SMS or -call.
But a seemingly corrupt or missing msgstore.db file trigger a restore as well, so it is possible to feed backups to Whatsapp without constant reactivation. Whatsapp failed with the restore if the SELinux context was wrong on the to-be-replaced database file, I believe. During my trials I just deleted the database (if I recall correctly) and the artificially triggered restored worked out.
Below this line is stuff I tried before:
At the moment I try to plant the old backup on whatsapp for decryption. To get to the point of restore, I force close whatsapp, clear app data, open whatsapp, give it no permissions and activate a number. At this point it asks for permissions to find restore files: I deny “contacts”, but allow for “media/files”. Here it consistently finds the most recent _local_ backup from the _same_ whatsapp account. At this point I force close the app and clear the app cache.
Restarting whatsapp brings it to the backup screen where it finds the local backup for the _same_ device.
At the moment I’m investigating which backups it picks up. For this I use backups from the same device/account as well (known to be working).
/data/data/com.whatsapp/files/key
This file is non-existent on the new device. If I drop a key file from a different account, it seems to get ignored. Whatsapp still finds the native backup (not one matching the key), and it successfully restores it.
/data/data/com.whatsapp/shared_prefs/keystore.xml
This file already exists, but only with “client_static_keypair”. If I replace that entry with the one from the old device, whatsapp will still find the native backup, but it will fail to restore it. The restore has to be skipped and whatsapp triggers a reactivation of the phone number, but if you enter the same new number again, whatsapp accepts it without SMS/call.
→this seems to be the encryption key to be used by whatsapp.
I can confirm the following crypt12 decryption code to be working:
https://gist.github.com/nlitsme/b079f351eb1bf9c3d356ce988bb6afdc
https://github.com/EliteAndroidApps/WhatsApp-Crypt12-Decrypter
They both require the backup file and the “key” file. The latter has a check where it compares a component from the key file with the backup 1:1. In the code this is called “t1” and “t2” which should match. So far I have backups with three different t1/t2. The original backup, with a matching key; the backups from the new account on the new devices, without a key; and the backups from the new device/account, where I mixed the string from the keystore.xml file in.
The “key” file is not generated by the latest Whatsapp anymore, as it seems. Maybe the encryption/decryption key is generated on-the-fly from the keystore.xml data. If this is true, then a new activation of my new telephone number would make these backups unreadable.
Created by author: 2018-04-19
Last edit by author: 2018-05-01
siemer said:
Goal: pass a whatsapp chat history backup (.crypt12) from one device to another with different telephone (whatsapp account) numbers.
Update: I succeeded with ultimate goal to move the chat history to a different device with a different phone number, but I failed with the re-encryption.
Encryption
First, I believed that the /data/data/com.whatsapp/files/key file might have been a leftover from an old version of Whatsapp on the old device, because I could not find the file. It turned out that it was generated later on the new device, after I finished my experiments. I’m not sure what triggers its creation.
Furthermore I was not able to decipher header and footer of the crypt12 backup file. I believe that a message authentication code (MAC) is part of it and something related to the Whatsapp account number (telephone number), because the app was quick in determining if a backup file is a restore candidate without decrypting, I’ld say.
How I managed to transfer the chat history:
Short version: get root on both devices and move /data/data/com.whatsapp/databases/msgstore.db over to the new device.
Long version: root on the new device will be less problematic, I guess. For the old device I used the fishy Kingroot app. It looks very professional and seems to download exploit code from a huge database for many devices. I got instant root access without flashing anything, but to be honest I don’t trust it regarding what else it might be doing...
Kill both Whatsapp apps before reading the msgstore.db file from the old and writing to the new device. I also removed the msgstore.db-* files on the new device. Sqlite might detect itself that the new database does not fit those helper files, but if they are not even there, they will be recreated correctly without any doubt.
Also set the permissions and ownership of that file to what it would be on the new device (not the old). My biggest oversight were the SELinux security attributes stored in the extended file attributes (XA). It made me believe that Whatsapp is verifying the database content and rejects it, but in reality it eats it just fine, as long as it gets proper access to it.
The XA tools I had available on the phones apparently show all the extended file attributes with “getfattr -d filename”, while e.g. on a standard Linux you need “getfattr -dm- filename” to get them all, not just the user.* domain. „ls -Z” shows the SELinux security context, which is a specific part of the extended file attributes, and in this case the only part I had set.
As with the file ownership, check which context is usually set on the database file on the new device and set it accordingly (“setfattr”). My old device did not even have SELinux and no extended file attributes were set there.
Other findings:
As the restore kicks only in during initial whatsapp setup, I’ve cleared data on whatsapp a lot. Constant reactivating the same phone number will trigger a hold-off on the whatsapp servers, delaying activation-SMS or -call.
But a seemingly corrupt or missing msgstore.db file trigger a restore as well, so it is possible to feed backups to Whatsapp without constant reactivation. Whatsapp failed with the restore if the SELinux context was wrong on the to-be-replaced database file, I believe. During my trials I just deleted the database (if I recall correctly) and the artificially triggered restored worked out.
Below this line is stuff I tried before:
At the moment I try to plant the old backup on whatsapp for decryption. To get to the point of restore, I force close whatsapp, clear app data, open whatsapp, give it no permissions and activate a number. At this point it asks for permissions to find restore files: I deny “contacts”, but allow for “media/files”. Here it consistently finds the most recent _local_ backup from the _same_ whatsapp account. At this point I force close the app and clear the app cache.
Restarting whatsapp brings it to the backup screen where it finds the local backup for the _same_ device.
At the moment I’m investigating which backups it picks up. For this I use backups from the same device/account as well (known to be working).
/data/data/com.whatsapp/files/key
This file is non-existent on the new device. If I drop a key file from a different account, it seems to get ignored. Whatsapp still finds the native backup (not one matching the key), and it successfully restores it.
/data/data/com.whatsapp/shared_prefs/keystore.xml
This file already exists, but only with “client_static_keypair”. If I replace that entry with the one from the old device, whatsapp will still find the native backup, but it will fail to restore it. The restore has to be skipped and whatsapp triggers a reactivation of the phone number, but if you enter the same new number again, whatsapp accepts it without SMS/call.
→this seems to be the encryption key to be used by whatsapp.
I can confirm the following crypt12 decryption code to be working:
https://gist.github.com/nlitsme/b079f351eb1bf9c3d356ce988bb6afdc
https://github.com/EliteAndroidApps/WhatsApp-Crypt12-Decrypter
They both require the backup file and the “key” file. The latter has a check where it compares a component from the key file with the backup 1:1. In the code this is called “t1” and “t2” which should match. So far I have backups with three different t1/t2. The original backup, with a matching key; the backups from the new account on the new devices, without a key; and the backups from the new device/account, where I mixed the string from the keystore.xml file in.
The “key” file is not generated by the latest Whatsapp anymore, as it seems. Maybe the encryption/decryption key is generated on-the-fly from the keystore.xml data. If this is true, then a new activation of my new telephone number would make these backups unreadable.
Created by author: 2018-04-19
Last edit by author: 2018-05-01
Click to expand...
Click to collapse
I'm trying to do the same thing as you; it is going mostly smooth with permissions and user/group, but I'm having some issues changing the SELinux extended security attributes. I must change mine from
Code:
u:object_r:app_data_file:s0
to
Code:
u:object_r:app_data_file:s0:c512,c768
but I can't really find enough guidance online... If you could help, I'd be really grateful
Hi
My whatsapp backup was corrupted, I extracted it from Google Drive
Then .dump into a sql file, fixed the errors
Recompile into a repair db, which works because it can be viewed on the WhatsappViewer.exe
Since the db is not encrypted, how do I restore it in my own phone?
Can msgstore.db be placed inside /data/data/com.whatsapp/databases/ of my own phone? Will it work without the msgstore.db being crypted with crypt12?
Nite.Achilles said:
Hi
My whatsapp backup was corrupted, I extracted it from Google Drive
Then .dump into a sql file, fixed the errors
Recompile into a repair db, which works because it can be viewed on the WhatsappViewer.exe
Since the db is not encrypted, how do I restore it in my own phone?
Can msgstore.db be placed inside /data/data/com.whatsapp/databases/ of my own phone? Will it work without the msgstore.db being crypted with crypt12?
Click to expand...
Click to collapse
Hi, bro. Would you mind telling me how you fixed errors in the sql file? I have one corrupted database and Im not able to see it in WA Viewer. Thanks in advance.
IvanN8458 said:
Hi, bro. Would you mind telling me how you fixed errors in the sql file? I have one corrupted database and Im not able to see it in WA Viewer. Thanks in advance.
Click to expand...
Click to collapse
Hi I used this
reference from here https://andreas-mausch.de/whatsapp-viewer/
echo .dump | sqlite3 msgstore.db > temp.sql
echo .quit | sqlite3 -init temp.sql repaired.db
Nite.Achilles said:
Hi I used this
reference from here https://andreas-mausch.de/whatsapp-viewer/
echo .dump | sqlite3 msgstore.db > temp.sql
echo .quit | sqlite3 -init temp.sql repaired.db
Click to expand...
Click to collapse
Thank you very much, bro. I'll try that and hope it can fix it. Have a nice one.
Hi,
had any of you success with the restored db, to get it reintegrated into WhatsApp?
siemer said:
Goal: pass a whatsapp chat history backup (.crypt12) from one device to another with different telephone (whatsapp account) numbers.
Update: I succeeded with ultimate goal to move the chat history to a different device with a different phone number, but I failed with the re-encryption.
Encryption
First, I believed that the /data/data/com.whatsapp/files/key file might have been a leftover from an old version of Whatsapp on the old device, because I could not find the file. It turned out that it was generated later on the new device, after I finished my experiments. I’m not sure what triggers its creation.
Furthermore I was not able to decipher header and footer of the crypt12 backup file. I believe that a message authentication code (MAC) is part of it and something related to the Whatsapp account number (telephone number), because the app was quick in determining if a backup file is a restore candidate without decrypting, I’ld say.
How I managed to transfer the chat history:
Short version: get root on both devices and move /data/data/com.whatsapp/databases/msgstore.db over to the new device.
Long version: root on the new device will be less problematic, I guess. For the old device I used the fishy Kingroot app. It looks very professional and seems to download exploit code from a huge database for many devices. I got instant root access without flashing anything, but to be honest I don’t trust it regarding what else it might be doing...
Kill both Whatsapp apps before reading the msgstore.db file from the old and writing to the new device. I also removed the msgstore.db-* files on the new device. Sqlite might detect itself that the new database does not fit those helper files, but if they are not even there, they will be recreated correctly without any doubt.
Also set the permissions and ownership of that file to what it would be on the new device (not the old). My biggest oversight were the SELinux security attributes stored in the extended file attributes (XA). It made me believe that Whatsapp is verifying the database content and rejects it, but in reality it eats it just fine, as long as it gets proper access to it.
The XA tools I had available on the phones apparently show all the extended file attributes with “getfattr -d filename”, while e.g. on a standard Linux you need “getfattr -dm- filename” to get them all, not just the user.* domain. „ls -Z” shows the SELinux security context, which is a specific part of the extended file attributes, and in this case the only part I had set.
As with the file ownership, check which context is usually set on the database file on the new device and set it accordingly (“setfattr”). My old device did not even have SELinux and no extended file attributes were set there.
Other findings:
As the restore kicks only in during initial whatsapp setup, I’ve cleared data on whatsapp a lot. Constant reactivating the same phone number will trigger a hold-off on the whatsapp servers, delaying activation-SMS or -call.
But a seemingly corrupt or missing msgstore.db file trigger a restore as well, so it is possible to feed backups to Whatsapp without constant reactivation. Whatsapp failed with the restore if the SELinux context was wrong on the to-be-replaced database file, I believe. During my trials I just deleted the database (if I recall correctly) and the artificially triggered restored worked out.
Below this line is stuff I tried before:
At the moment I try to plant the old backup on whatsapp for decryption. To get to the point of restore, I force close whatsapp, clear app data, open whatsapp, give it no permissions and activate a number. At this point it asks for permissions to find restore files: I deny “contacts”, but allow for “media/files”. Here it consistently finds the most recent _local_ backup from the _same_ whatsapp account. At this point I force close the app and clear the app cache.
Restarting whatsapp brings it to the backup screen where it finds the local backup for the _same_ device.
At the moment I’m investigating which backups it picks up. For this I use backups from the same device/account as well (known to be working).
/data/data/com.whatsapp/files/key
This file is non-existent on the new device. If I drop a key file from a different account, it seems to get ignored. Whatsapp still finds the native backup (not one matching the key), and it successfully restores it.
/data/data/com.whatsapp/shared_prefs/keystore.xml
This file already exists, but only with “client_static_keypair”. If I replace that entry with the one from the old device, whatsapp will still find the native backup, but it will fail to restore it. The restore has to be skipped and whatsapp triggers a reactivation of the phone number, but if you enter the same new number again, whatsapp accepts it without SMS/call.
→this seems to be the encryption key to be used by whatsapp.
I can confirm the following crypt12 decryption code to be working:
https://gist.github.com/nlitsme/b079f351eb1bf9c3d356ce988bb6afdc
https://github.com/EliteAndroidApps/WhatsApp-Crypt12-Decrypter
They both require the backup file and the “key” file. The latter has a check where it compares a component from the key file with the backup 1:1. In the code this is called “t1” and “t2” which should match. So far I have backups with three different t1/t2. The original backup, with a matching key; the backups from the new account on the new devices, without a key; and the backups from the new device/account, where I mixed the string from the keystore.xml file in.
The “key” file is not generated by the latest Whatsapp anymore, as it seems. Maybe the encryption/decryption key is generated on-the-fly from the keystore.xml data. If this is true, then a new activation of my new telephone number would make these backups unreadable.
Created by author: 2018-04-19
Last edit by author: 2018-05-01
Click to expand...
Click to collapse
Those extended attributes ... I would never have suspected that if it weren't for you, thank you so much !
so, does it work ?
Nite.Achilles said:
Hi
My whatsapp backup was corrupted, I extracted it from Google Drive
Then .dump into a sql file, fixed the errors
Recompile into a repair db, which works because it can be viewed on the WhatsappViewer.exe
Since the db is not encrypted, how do I restore it in my own phone?
Can msgstore.db be placed inside /data/data/com.whatsapp/databases/ of my own phone? Will it work without the msgstore.db being crypted with crypt12?
Click to expand...
Click to collapse
Hi,
So how you fix it ultimately?
Hi, I am having the same problem as with restoring my Whatsapp history and wondered if any kind soul can help me to restore my Whatsapp history?
What I had done :
I had my S8 rooted. The whole phone was wipe when it was rooted. I hope this step is correct.
My encrypted backup (crypt12 and crypt14) was saved already before I rooted and I also need a backup of my phone (just not the application data because the Dr Fone software mentioned that my S8 needed to be rooted before I can backup my application data)
But I couldnt find the folders mentioned here :
/data/data/com.whatsapp/databases/msgstore.db
Can anyone guide me pls?
XMatrix2099 said:
Hi, I am having the same problem as with restoring my Whatsapp history and wondered if any kind soul can help me to restore my Whatsapp history?
What I had done :
I had my S8 rooted. The whole phone was wipe when it was rooted. I hope this step is correct.
My encrypted backup (crypt12 and crypt14) was saved already before I rooted and I also need a backup of my phone (just not the application data because the Dr Fone software mentioned that my S8 needed to be rooted before I can backup my application data)
But I couldnt find the folders mentioned here :
/data/data/com.whatsapp/databases/msgstore.db
Can anyone guide me pls?
Click to expand...
Click to collapse
Hello, since you rooted your phone it wiped out all data.
So you msgstore.db is actually crypt12 and crypt14 data.
Don't root unless you have all your items.
It wipes the key as well.
I do think key don't exist anymore and login happens in keystore.xml with static client
Hey guys, this is my first thread, and I'm a bit confused on the app. Today I'll tell how did I stop the freaking google 'malware' from installing and updating every single day. This would work on any rooted device that has access to the data partition, maybe it could be reproduced via adb without root.
First off, I searched everywhere looking on how to disable, uninstall, break, or do anything to this forced battery hog. The best answers were using 'pm hide' on the package but this caused a very high battery usage, due to the file dependencies. So I searched where it was installed. Luckily enough, it is an user app, so it means I would find it on /data/app and /data/data. I will use solid explorer, but any file manager with root access and chmod to change permissions should do just fine.
Once we locate the folder (/data/app/com.google.android.instantapps.supervisor-1 in my case) we delete it. Utterly. After that, we will create a file, and name it exactly the same as the folder did. This is a dummy file that the system will believe it is a folder, and will try to install the application inside it. We fill that file with enough random characters for making the system think it can't just delete it (sometimes cleaners point empty files as worthless and wipe them out)
Now we need to make the dummy file unremovable for anyone but us, by using chmod. Solid explorer has a nice interface for that. We long press the file, enter to properties and set the permission to 0 0 0 (attributes tab). This makes play store unable to delete the file to recover the old folder, and when it tries to download the package, it will fail because it won't have a respective folder to be sent to.
After this, we reboot the phone and see that google play services for instant apps has lost roughly 90% of it's size, and when we enter settings>google>google play instant it'll ask for installation. I was bold enough to accept, just for getting an error dialogue when it tried to install itself.
Known issue: The app reinstalls once again after reboot. The cause is that, when android can't install the app in the first folder (the one that ends with a -1), it can create a second one (ending with a -2 instead), like an alternative. This is solved by just doing the same procedure above on the second folder, and you will end up having two dummy files instead of one. A third folder cannot show up, or at least it didn't in my phone.
Notes: You can repeat this with the folder in /data/data and any other data partition level instant app folder, but I wouldn't do it because I already broke all functionality since I deleted the base apk, and the app size is less than 300KB now so I don't think the trouble is worth it.
You must whitelist these files from any memory cleaner, i.e SD maid corpse finder will delete it thinking it's a leftover of an old app
WARNING; I'M NOT RESPONSIBLE FOR ANY MISLEADS, WRONGS, OR PLUTONIUM-UNSTABLE ROMS THAT MAY EXPLODE IN ANY WAY. YOU ARE THE RESPONSIBLE FOR YOUR DEVICE'S SAFETY AS THIS ISN'T EVEN FULLY TESTED IN MY PHONE AND I DON'T KNOW THE ULTIMATE CONSEQUENCES OF DOING THIS. YOU ARE WARNED.
PD: Please make some suggestions about how I made the thread, I did what I think it's my best
Hello!
I want to get my whatsapp keyfile, but I'm having a lot of trouble... and I don't want to root due to warranty.
Things I've tried:
Full backup: turns out at some point, google added the option for apps to control which files are backed up, and thus, I can't get a backup that includes the keyfile... This led me to:
installing an older version of whatsapp, from before the version of android which allows control over what is backed up. however, due to a bug, I can't verify my number with the older version, so... no keyfile.
editing the apk to allow a full backup - didn't work. Tried with APK easy, with the option to use the original signature enabled, but the change to the manifest XML is detected and I can't verify my number.
Extracting the key from whatsapp web, and using python scripts that can be found on github to decode my encrypted conversation. However, I couldn't figure out from the scripts what the format of the keyfile is...
I'm out of ideas, so I'm hoping someone could tell me how to translate the data found in whatsapp web (F12 on chrome/firefox, "Application" -> Local Storage -> "https://web.whatsapp.com" -> WASecretBundle on chrome, "Storage" -> Local Storage -> "https://web.whatsapp.com" -> WASecretBundle on firefox) into a keyfile.
Or offer up another way to get that keyfile. I've been foiled at every turn...