Related
Hi guys,
I have LG Quantum which I converted into C900K (Australia ROM) using instructions from one of the teds here. Now, for various reasons, I want to go back to original C900B (Bell) ROM but I would like to first backup provisioning xml file from current ROM and add it into phone once I convert back to C900B (Bell).
How I can do this?
Thanks
OK, first of all, what do you mean "backup provisioning xml file"? The phone has dozens if not hundreds of provxml files on it, plus whatever ones you've personally added.
If you want to back up the system provxml files, they are generally in the \Windows folder. You can use the Mango Webserver app to download them, though it can't put them back (can't write to \Windows). Note that most of these files are processed invisibly and the user never calls them.
If you mean "create a provxml file that backs up my files" then you're out of luck; the provxml processor available to apps on LG phones doesn't permit operations on files.
If you mean "backup my provxml files from the DiagProvXML app's isolated storage" then you can use a tool like Isolated Storage Explorer or similar to do this.
If you mean something else, you're going to need to be a lot more specific.
As for restore, the only option available on LG is to put it in an app (such as the DiagProvXML app), either in the XAP file directly or into the isolated storage using something like Isolated Storage Explorer (I believe Windows Phone Device Manager can do this too). You can then process the provml using DiagProvXML or a similar app.
Again, if you want to do something else, you're going to need to be way more specific.
GoodDayToDie, thanks for detailed reply.
I'm not expert, but I'll try to explain. I bought my phone from Bell, unlocked it and moved to Speakout (Rogers). Problem was that data and mms never worked over the air, only wireless. My understanding is that provisioning xml file holds necessary settings and unfortunately I haven't had one for Rogers.
My only solution is to follow instruction from one of the treads (specifically written to help with this issue) to convert my phone to Australian version C900K which has necessary software to request and get xml file. I did that and finally I got xml file from Rogers and data working.
Now, I have various problems with C900K. For example I'm unable to install xap files, I have to update my phone manually, etc... All that was working just fine on C900B (Bell) version.
I was hoping I can export Rogers xml file out of phone, revert my phone to C900B, and then import xml file again, enabling data in process. Basically I would like to have C900B version working with data on Rogers using xml file I obtained from C900K version.
Does this make sense? I hope you understand what I'm trying to achieve.
You want to export your network configuration, so you can restore it on the original firmware. Note that while network configurtion can be set using provxml, it is neither stored that way internally once set, nor is that the only way to set it. Provxml is also used for a great many other things, which is why your original request was far too vague.
I assume LG has some kind of "network setup" app, and that you tried it but found it didn't have settings for your carrier? That most likely *does* use provxml, but extracting it will be a neat trick. It's probably stored in a database of some kind under the \Windows folder. Odds are that you can download it using the Webserver app, but I don't even know what files to look for on LG.
Your best bet would simply be to find the APN settings you need (that's basically the "Internet service provider configuration" for a phone) and enter those manually. Typically, your carrier is happy to provide you that info if for some reason your phone doesn't find it automatically, and you can find the option to select your APN, or add a new one, under Settings -> Cellular. That should enable data, hopefully including MMS (which uses data).
If that doesn't work, you could also try running AutoDataConfig; by setting a few registry values (easy on LG) you can force data config to run at the next time the phone boots up, which will try to set up neccessary configuration for your carrier (obviously, you must have the SIM card in at the time).
Hope that helps. It would be good to know what things you tried prior to the (generally quite excessive) step of re-flashing your ROM.
Hi there,
I downloaded SSE and used it.
I want to know is there anything better than this? I want to install the best one.
Thanks
I like EDS a lot. You can open truecrypt containers you make on the PC with it (must use specific encryption etc...). If you have root you can also mount the volume directly on the device.
Most of these types of programs (that don't mount) cache up a part of, or all of the file locally so you can access it meaning there is an unsecured copy on the devices file system while you access it. With mount you open directly from inside the encrypted container bypassing that insecurity.
I think you have to have the pay version to mount, this is the free one:
https://play.google.com/store/search?q=eds
Also it will leave a notification in your notification area saying EDS is loaded but you can hide that by going to the app in settings -> apps and unticking the show notifications checkbox.
Hello everyone,
:crying:
I have a ROOTED Hisence HS-U980 Infinity Pure 1 . Running android 4.2.1
I use TIBU data profiles like crazy. And I use alot of profiles, and once I finish, I delete the unneeded ones.
Anyway,
I was using data profiles today as usual, and I changed the profile to a different one -as always-, but this time I noticed that titanium backup told me "Data profile changed to "...." and applied to 0 apps". ZERO APPS
I was like "Whaaaaaatttttt!!!!". I went after that to the apps I use, to check and see if the multiple profiles for them are somehow disabled. But NO, they are on. So I tried disabling multiple data profiles for them to see what going on with the feature.
And this is what I got: "Sorry, a problem occurred when switching the data profiles for .... app"
And it shows to all the apps I use multiple profiles with. So I think the problem is within TIBU.
What should I do?
I don't want to lose my data on my apps,
Thanks for your help.
EDIT: and BTW, when I activate multiple profiles for a new app, it works fine. But all the previous ones are in error.
SOLUTION
[SOLUTION]
I managed to solve the issue, here are the steps.
- First make a new data profile for this, so that we work away from your old data profiles, and hopefully not lose any former data.
- Go to " /Device/data/data/ " (and there you will find all the apps folders, search for your app folder and enter it)
- (In your app folder) Backup/copy all the data in here -for insurance-, or just copy the needed ones. (you will also see folders named after your data profiles)
- (In your app folder) You will see a folder -mostly hidden- named " .data_profiles ". This is the one causing the error for your app. Delete it, but make sure you don't delete something important inside it, like data profiles or something, unless you made a copy of them.
- Now go back to TIBU , and go to your app, you will see that the multiple profiles feature is now disabled because we deleted ".data_profiles" folder.
- Enable multiple profiles feature for the needed app.( you will see that TIBU will tell you that the current data will be assigned to the current data profile, which is the one we made first.)(CAUTION: THIS STEP WILL DELETE ALL PREVIOUS APP DATA PROFILES FOLDERS FOR THE APP YOU ARE WORKING ON , because now TIBU thinks that this is the first time this app uses data profile, therefore, it will delete all previous data folders to make new ones)
- Now, the multiple profiles feature is re-enabled for your app.
- Go again to your app data folder, and PASTE any needed info from the data you copied previously.(but don't paste the ".data_profiles" folder. You can paste the data that were in it before -if any-, but dont paste the folder itself)
-DONE
"Sorry, problem occured while switching profile data for watsapp 2.12"
Plz help me how to fix it...???
did u fix it? pls help me
sgmarouf said:
[SOLUTION]
I managed to solve the issue, here are the steps.
- First make a new data profile for this, so that we work away from your old data profiles, and hopefully not lose any former data.
- Go to " /Device/data/data/ " (and there you will find all the apps folders, search for your app folder and enter it)
- (In your app folder) Backup/copy all the data in here -for insurance-, or just copy the needed ones. (you will also see folders named after your data profiles)
- (In your app folder) You will see a folder -mostly hidden- named " .data_profiles ". This is the one causing the error for your app. Delete it, but make sure you don't delete something important inside it, like data profiles or something, unless you made a copy of them.
- Now go back to TIBU , and go to your app, you will see that the multiple profiles feature is now disabled because we deleted ".data_profiles" folder.
- Enable multiple profiles feature for the needed app.( you will see that TIBU will tell you that the current data will be assigned to the current data profile, which is the one we made first.)(CAUTION: THIS STEP WILL DELETE ALL PREVIOUS APP DATA PROFILES FOLDERS FOR THE APP YOU ARE WORKING ON , because now TIBU thinks that this is the first time this app uses data profile, therefore, it will delete all previous data folders to make new ones)
- Now, the multiple profiles feature is re-enabled for your app.
- Go again to your app data folder, and PASTE any needed info from the data you copied previously.(but don't paste the ".data_profiles" folder. You can paste the data that were in it before -if any-, but dont paste the folder itself)
-DONE
Click to expand...
Click to collapse
Please explain for those of us who are not experts: What are you talking about here:
- Go to " /Device/data/data/ "
Do you mean on your internal storage on the phone, or what?
Hello. Sorry for being away for so long. Thought the details were enough and never checked back on this thread.
Anyway, "Do you mean on your internal storage on the phone, or what?",
If my memory serves me right, I believe it is only on the internal storage. If you are using data profiles then you are rooted and have access to the internal storage. Go there and check it out and also show any hidden folders if they are not visible.
Good luck.
pnadimm said:
"Sorry, problem occured while switching profile data for watsapp 2.12"
Plz help me how to fix it...???
Click to expand...
Click to collapse
Please follow the steps one by one and your problem will be solved. Backup "copy/paste" your data profile folders first before you do anything.
This problem is caused by TIBU for some reason. Corrupted directory of some sort and this is why you need to do the steps mentioned and make TIBU create a new folder. Then you can paste your old data profile information and regain access.
Again, don't paste the whole folder, just the contents inside.
In my solution, what I am explaining is:
There is a folde directory making a problem for TIBU. This directory needs to be deleted. But NOT the contents and data inside it. Making a new version of the problem directory will fix the issue.
In short, the solution is: (From internal storage), backing up all the data profiles for the application you are using, then deleting the directory that is causing the problem "".data_profiles" folder", then going back to TIBU and REACTIVATING multiple profiles for your application will create a clean copy of " ".data_profiles" folder ". Paste the old contents you copied before from ".data_profiles" folder into the NEW version of ".data_profiles" folder. This will fix the problem.
THIS WAY TO SOLVE AN ERROR DATA PROFILE'S ENABLE BUT SHOW ERROR WHEN USER TRY TO DISABLE THEM.
This caused damage may the user change or other activity to system root like change device id with other app or imei with other app where they not supported by TIBU.
Ok, let go to fix.
(CAUTION!!! THIS IS NOT ONLY ONE THE WAY TO FIX THEM IT'S JUST ABOUT MY EXPERIENCE BUT IT'S WORK FOR MY PROBLEM LIKE THIS)
STEPS:
1. OPEN THE TIBU PRO
2. NEXT -> GOTO BATCH ACTIONS
3. CHOOSE -> MANIPULATED DATA -> RUN WIPE DATA FOR USER & SYSTEM APPS
4. THEN YOU WILL SEE THE WIPE DATA FOR USER & SYSTEM APPS AND AND APPS LIST.
5. TAP INVERT SELECTION
6. THEN CHOOSE YOUR APPS WHERE YOU ENABLE MULTIPLE DATA PROFILES BEFORE.
7. TO EXECUTE AND FIX THEM TAP THE SUBMIT BUTTON IN THE RIGHT TOP CORNER OR TAP THIS BUTTON [√].
8. REBOOT YOUR PHONE (DO NOT USE A SOFT REBOOT) BUT FULL REBOOT.
9. OPEN AGAIN TIBU, AND ENJOY WITH PROFILE AGAIN.
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
I saw this on my device, and only found little info/threads, with almost zero content/analysis. Aparently the kindle app leaves a bunch of random files around. And since the prefix is "RCE" i am a little paranoid, since that usually means "Remote code execution" and is usually associated with exploits
Files:
CS_JIT_Animation.mp4
jit_cs_positive_preview.png
rce_plugin_strings_resource_cs_CZ.json.min
rce_plugin_strings_resource_de_DE.json.min
rce_plugin_strings_resource_en_US.json.min
rce_plugin_strings_resource_es_ES.json.min
rce_plugin_strings_resource_fr_FR.json.min
rce_plugin_strings_resource_it_IT.json.min
rce_plugin_strings_resource_ja_JP.json.min
rce_plugin_strings_resource_nl_NL.json.min
rce_plugin_strings_resource_pt_BR.json.min
rce_plugin_strings_resource_v2_TYPO_TEST.json
rce_plugin_strings_resource_zh_CN.json.min
All Attached in a zip created by the android native file manager.
Current places mentioning this
https://forums.oneplus.com/threads/unkown-files-in-download.948860/
https://talk.sonymobile.com/t5/Xper...erious-Files-in-Downloads-Folder/td-p/1353185
https://forum.xda-developers.com/xperia-xz1/help/phone-mysterious-files-download-folder-t3871763
https://www.youtube.com/watch?v=eMmx5tRm0jM (one of the files is a video, someone uploaded to youtube ...and to https://gfycat.com/generouspinkcolt
How to make those files appear for you:
Install kindle from the google app store
if you already have it installed, or want to see the files again after you deleted, Stop the app and delete all storage. (nothing will be lost, this app syncs everything and some more to the amazon servers)
perform the first Sync on kindle app
Now, insert a pen drive and open the native android File Mananger and look at the local Download folder
Files are somewhat hidden:
If you look into the download folder with any other app (I tried, blackberry file manager, oi file manager, Ghost Commander, and Termux --after enabling the storage setup)
Files probably have a weird attribute or ownership... but the native android file manager does not show anything other than creation date! And every single file operation (copy, move, compress) reset the information to "regular user, creation time set to now". So either I see them on the Native File Manager, without any information available, or I do not see the files until I destroy the information.
Android version is not important (seems to happen on several versions) and has been happening for a while (First mention seems to be Nov2018)
Anyone have any idea what this is? I know I will probably reverse eng the kindle app at some point, wast a bunch of time, and realize it is just some dumb amateur library badly implemented by amazon... or maybe not. I think at this point I am most curious as to how the app "hides" the files from most everything.