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
Related
Playing around with the ls -R command, I found where the SMS database is kept, and it's somewhat readable in a text editor...
UPDATE (thanks staulkor): This database is viewable, and searchable using an SQLite database viewer.
Code:
/data/data/com.android.providers/telephony/databases/mmssms.db
Just run the following command to back it up to the SD Card:
Code:
busybox cp /data/data/com.android.providers.telephony/databases/mmssms.db /sdcard
Happy hacking
You can use an SQLite viewer to read the database correctly
Would seem simple enough to write a script to run on a PC/Mac to back up the database and load it into some sort of viewer... searchable perhaps?
I'm not too familar with databases, but would seem simple enough to make a lightweight app to keep the SMS archive...
Cool, maybe we'll soon see a port of PIM Backup. Would be nice...
Hmm...
/data/data/com.android.providers/telephony/databases/mmssms.db
Click to expand...
Click to collapse
and
busybox cp /data/data/com.android.providers.telephony/databases/mmssms.db /sdcard
Click to expand...
Click to collapse
are two different paths - I think both are supposed to be
Code:
/data/data/com.android.providers.telephony/databases/
(since I can't cd to the other one).
At any rate - thanks for the tip, but can anyone else confirm this works for them? On my android (R30) I get "opendir failed, Permission denied" if I try to read the contents of that directory.
Seeing as it's fully possible to write an application to back up the database to the sdcard (or even to a website), wouldn't that make more sense?
Afterall, there's no need to have the actual database -- and the method is highly restrictive to both people with root on their phones and those with a USB cable and computer handy.
Also, backing up this database will not backup any MMS attachments, which are stored here:
/data/data/com.android.providers.telephony/app_parts/
Refer to the "part" table for an index matching the files there to messages/filenames. (For each MMS, there should be an XML file that helps identify the type of message, and then the file itself, such as a jpeg).
is this the best and safest way to back up sms database as of yet? I have about 1000 sms and it slows down my messaging so I've been try to find a way to free that up. Backing them up would be great so i can clear them.
If anyone has tried this, please share with the rest of us on its effect on the phone.
Thank you,
Hbguy
P.S: This site is truely GREAT because pros are patient with noobs
i don't understand this...i downloaded the file managers on marketplace, and cannot when i click on data file, there is nothing in there..so i dowonloaded a terminal program and still don't understand how to use the commands to move sms from memory to sim...can u do a quick step-by-step? do i have to use any specific programs to do this? sorry, so used to the simplicity of WM6 on my old phone, having trouble adapting to this platform..thanks for any help.
jazzmanmonty said:
i don't understand this...i downloaded the file managers on marketplace, and cannot when i click on data file, there is nothing in there..so i dowonloaded a terminal program and still don't understand how to use the commands to move sms from memory to sim...can u do a quick step-by-step? do i have to use any specific programs to do this? sorry, so used to the simplicity of WM6 on my old phone, having trouble adapting to this platform..thanks for any help.
Click to expand...
Click to collapse
You need to have root on your phone to follow the instructions given above (if you don't know what that means, you don't have it). For non-root users, most of the Android system on the G1 is locked down -- including /data and all its subfolders.
If you do have root on the phone, you can follow the instructions at the top from a terminal while logged in as root. You can verify you are root by running the program "id":
# id
uid=0(root) gid=0(root)
From there, to copy the SMS/MMS database to your sdcard, you can follow the above instructions. If you don't have busybox (ie, "busybox: not found"), you can use the "cat" command as so:
cat /data/data/com.android.providers.telephony/databases/mmssms.db > /sdcard/mmssms.db
You may also want any files stored here:
/data/data/com.android.providers.telephony/app_parts/
Which are from MMSs (if you've no MMSs saved, then you've no need to bother).
Also, not sure if there is a clarification needed for you. The instructions provided offer no way to access SMSs stored on the SIM, as Android uses a PDU interface that doesn't use the SIM's SMS storage space. It is possible to read SMSs off the SIM, however, and into the internal memory storage. See the settings window in the messaging application.
If someone does take the time to create an application to do this, then it would not require root access. Applications are allowed to access the SMS/MMS database, provided the user grants them permission, and could then be used to read the data from the database and into a new database or other file (eg, csv).
do ya think it would be posible to move these permanently to the memory card? ummmm.... ill try if i get a chance ..... ya can connect to phone via adb in recovery mode right ? an undo whatwver i break?
how would you view your backed up sms messages using staulkors sql database?
step by step would be great
hbguy
Just to be clear - for most people on RC30, this probably will not work.
Per http://forum.xda-developers.com/showthread.php?t=442480 the hacks to gain root access have been blocked since RC30 was deployed in early November. Someone should write an application to support this, but instead everybody is busy creating new useless calculators and niche geolocation applications.
If I'm wrong about the above, it would be terrific for anyone to chime in and clarify that.
goodwinm said:
Cool, maybe we'll soon see a port of PIM Backup. Would be nice...
Click to expand...
Click to collapse
https://github.com/jberkel/sms-backup-plus
So a while ago I grabbed a Motorola G2, made a complete physical memory dump to file “Full_Phone_Backup.image” I also have a .vhd which will not mount, but I remember very clearly extracting the contacts list from it.
I didn’t keep records of how I went about doing it, but I’m sure it was some busybox or cygwin and I’m very sure the file contains all the partitions. Don’t know what happened to .vhd, but I also can’t make a new one either, so bad luck I guess. Anyway, now I need to extract SMS messages from it, and so I turned to Foremost. With the following in a foremost-db.conf:
Code:
db n 4000000 \x53\x51\x4c\x69\x74\x65\x20\x66\x6f\x72\x6d\x61\x74\x20\x33\x00
I hoped to get a good rundown of the databases and extract from there. Now, I don’t need deleted messages or anything, I need to find the SMS messages that would be there as if the phone was on right now. Well, that and search them.
So, Foremost carved a whooping 36 GiB of .db files, which I think suggests that the file header is actually not for SQLite 3 file as much as for a part of SQLite3 file, and one file may contain many. Secondary evidence of that is that massive number of files contain the same data shifted a more or less uniform number of lines (like an entire block shifted 1k lines down across 10 files before it completely disappears).
Anyway, from the carved DB files I got meaningful e-mail messages, from the carved photos and videos, I got meaningful pictures (ones which would be on this phone), so I am sure data is there. Problem is, I could not find the messages I’m looking for. I was unable to find a single SMS message, I was unable to browse any of the recovered databases with sqlite database browsers, and the most useful thing I was able to do was to use Ransack in windows to search for relevant text in those recovered files.
What am I doing wrong that I’m not finding SMS messages or any relevant text in this mess?
KYKYLLIKA said:
So a while ago I grabbed a Motorola G2, made a complete physical memory dump to file “Full_Phone_Backup.image” I also have a .vhd which will not mount, but I remember very clearly extracting the contacts list from it.
I didn’t keep records of how I went about doing it, but I’m sure it was some busybox or cygwin and I’m very sure the file contains all the partitions. Don’t know what happened to .vhd, but I also can’t make a new one either, so bad luck I guess. Anyway, now I need to extract SMS messages from it, and so I turned to Foremost. With the following in a foremost-db.conf:
Code:
dbn 4000000\x53\x51\x4c\x69\x74\x65\x20\x66\x6f\x72\x6d\x61\x74\x20\x33\x00
I hoped to get a good rundown of the databases and extract from there. Now, I don’t need deleted messages or anything, I need to find the SMS messages that would be there as if the phone was on right now. Well, that and search them.
So, Foremost carved a whooping 36 GiB of .db files, which I think suggests that the file header is actually not for SQLite 3 file as much as for a part of SQLite3 file, and one file may contain many. Secondary evidence of that is that massive number of files contain the same data shifted a more or less uniform number of lines (like an entire block shifted 1k lines down across 10 files before it completely disappears).
Anyway, from the carved DB files I got meaningful e-mail messages, from the carved photos and videos, I got meaningful pictures (ones which would be on this phone), so I am sure data is there. Problem is, I could not find the messages I’m looking for. I was unable to find a single SMS message, I was unable to browse any of the recovered databases with sqlite database browsers, and the most useful thing I was able to do was to use Ransack in windows to search for relevant text in those recovered files.
What am I doing wrong that I’m not finding SMS messages or any relevant text in this mess?
Click to expand...
Click to collapse
You can't get into the phone and use SMS backup app or PC to backup your SMS? Can you back them up to your Google account and then recover them from there?
There are several ways to recover SMS from a device, is this method the only one you've tried?
Are you recovering your SMS or someone else's?
Sent from my SM-S903VL using Tapatalk
KYKYLLIKA said:
So a while ago I grabbed a Motorola G2, made a complete physical memory dump to file “Full_Phone_Backup.image”
.
.
and I’m very sure the file contains all the partitions.
Click to expand...
Click to collapse
How did you make this Backup.image? In my question over here I dreamt of something like 'dd if=/dev/sda of=/image.bak' for a really complete backup. Did you make your complete memory dump in such a way and would i be possible to write it back to the phone?
Thanks!
Droidriven said:
You can't get into the phone and use SMS backup app or PC to backup your SMS? Can you back them up to your Google account and then recover them from there?
There are several ways to recover SMS from a device, is this method the only one you've tried?
Are you recovering your SMS or someone else's?
Sent from my SM-S903VL using Tapatalk
Click to expand...
Click to collapse
This is my sister’s phone. The backup is from 16 months back or so. I can’t go search the SMS it has now, because updates been around since then, including a new version of android, and all that. It does not have the old messages.
What I tried is a sqlite forensics utility called “sqlite forensics reporter”, but no luck with that either. Piriform recuva did not work, and I was unable to mount it as a virtual hard drive or find a part of it that I could mount as a virtual hard drive.
andy_ross said:
How did you make this Backup.image? In my question over here I dreamt of something like 'dd if=/dev/sda of=/image.bak' for a really complete backup. Did you make your complete memory dump in such a way and would i be possible to write it back to the phone?
Thanks!
Click to expand...
Click to collapse
This is entirely possible. However, I cannot find the boot record in there or a partition table, which is very strange. I do remember dumping all the partitions in that file, though. It’s been over a year now, so details kind of gone fuzzy. I am sure I could write it back to a phone and use like that, but I don’t have a suitable surrogate phone or a virtual machine to try that on. I will not do it on the device itself, seeing as how it’s in use and all that. I just want to find the text of some messages.
I had my 2nd Galaxy Note 4 show the eMMC fault and go into endless bootlooping. I thought that I had been backing up whatsapp to google, but I found out otherwise. Here is the situation:
*Note 4 (unrooted) would start up for about 20 seconds before restarting. Not enough time to backup whatsapp to google drive. I was backing up whatsapp locally though. Marshmallow 6.0.1
*I was able to install TWRP. The phone has no problem starting and staying in TWRP recovery mode. Endless bootlooping only occurs when I try to start Android
*I could see all non-root-access folders in TWRP as well as in file explorer in Windows 10 when the phone was in recovery mode and connected to PC
*I copied all whatsapp folders from the phone to PC with Windows 10 file explorer (again, only when the phone is in TWRP recovery mode)
* I realized that these files may not be enough to open the whatsapp db in a new phone due to encryption
*I then used TWRP to install Magisk
*Then I was able to use ADB to pull the whatsapp key file and wa.db file from the phone to PC
*I am able to unencrypt the database and view in WhatsApp viewer
*After 6+ years of the Note 4 (2 separate devices), I purchased the Note20 Ultra yesterday (what an upgrade!!)
Question is, what do I need to do to get the chats from my PC onto my Note 20? Phone-to-phone transfer won't work because the Note 4 won't stay on long enough. BTW, I'm almost a complete noob--I just figured these things out yesterday with the help of some amazing resources from folks like you. So a big thanks to you. I did some whatsapp db merging a few years ago when my first Note 4 died, but I don't think any of that knowledge is still relevant.
...surely it can't be as easy as transferring my media files then dropping only the msgstore.db file into the Note 20, can it?
Ok, it really was that easy.
*I copied all my non-root-access Whatsapp folders over to my unrooted Note 20. These folders included all media and the msgstore.db.crypt12 files but, of course, did not include the key nor the wa.db files as these latter files are only found in the root-access folders.
*I then signed in to a google account so that I could download Whatsapp from the Play Store
*After initial installation and before a full whatsapp setup, I signed out of all google accounts on the Note 20 in order to force a restore from the local backup that I had copied to the phone (actually, I messed up twice and Whatsapp found an old google drive backup; I had to uninstall and reinstall whatsapp twice; finally worked on the 3rd try)
*Most of my chat contents, media, and correct contact names are now on my new phone
I must not have understood the high-level details of the encryption. I thought that the key was device-specific and that moving an encrypted msgstore.db file to a new device meant that I must also move the original key with the db file so that the new device could decrypt the first time. This doesn't seem to be the case. It must be that the key is associated with the whatsapp-registered phone number because I did use the same sim card/phone number in the old and new phones. Does anybody know if that is correct?
Two slight issues that I will try to fix today include 1) some missing contact details and 2) a few missing recent whatsapp chats.
1) Most of my contacts were synced with google, so I pulled most of them to my Note 20 quite easily. I must have also had some local contacts on my old phone that I never synced with google. Can anybody post a link to a good tutorial on how to convert a contacts2.db to vCard or a similar format? It's tantalizing that my old Note 4 will start for about 20 seconds and I have tried to get into my contacts on the phone and export them to the removable SD card. It's so close. The export starts but doesn't quite finish. The result is an unfinished (408kb) vcf file on my sd card that won't open on my new phone.
2) I think that the old phone started up just long enough to download the latest whatsapp chats from the server, but not long enough for me to view them. I'm missing chats from the 3-4 days between when the old phone was wonky and I installed whatsapp on the new phone. I think that they are not downloading from the whatsapp server onto my new phone because they already downloaded to my old phone
Any thoughts on any of this?
If you can't decrypt, key file has changed.
Decrypting is not a problem. I can do it on my pc as long as I have the key file (which I do). The new phone is also able to decrypt--without the key. That is what surprised me
If you make a full backup and then make a full restore, your whatsapp will work perfectly.
You mixed things up a lot.
Msgstore.db and wa.db are never in same folder of msgstore.db.crypt12.
Msgstore.db and all other databases (*.db files) are not encrypted.
You don't need key file to read them.
Only *.crypt12 files are encrypted.
For them, you will never can decrypt them without key file.
About google backups, they are NOT encrypted.
All files backuped to google, are unencrypted.
Taken care.
Your worries are unnecessary.
Keep your backups safe and secure and you will have no one problem.
Ok.
So I did make a complete backup of the rooted Note 4 to my external SD card using twrp. I now have 2 phones: the old Note 4 which won't start and the new Note 20 which I don't want to root at the moment.
How could I make a full restore, so that my whatsapp will work perfectly?
Ok, I think I got this now. I've read up on the various threads related to this and I think I know what to do now
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...
I do copy msgstore.db(even from fresh whatsapp install) and when use new file (premissions and owner are correct) whatsapp is starting crash.
Any idea why so?
(when starting to use original file whatsapp is starting fine)
WhatsApp is trashware, ditch before it gives you a good dose of malware.
I won't allow it on any of my devices, it is trouble. Keep all social media apps off the device, they are a multiple vector security risk.
If the social media site isn't fully usable through the browser don't use it. Even then... watch your six.
not sure why u liked to answer so to tech question....
The copied db is corrupted. So easy.
xXx yYy said:
The copied db is corrupted. So easy.
Click to expand...
Click to collapse
Files are exactly same after copy, i even used diff command to be sure... i have several working renamed msgstore.db files(if i rename them to msgstore.db then ok). But when i do copy them to msgstore.db then crash is happening.
Then do a LOGCAT to get the very reason why WA crashes when loading db in question.