Hi, I accidently master reset my atrix 2 and want to recover SMS from my device memory
I have done the following
- rooted my phone and activated CWM recovery but I am not able to access the internal memory as USB device so I can run any recovery program
- I tried to access the mmssms.db file in /data/data/com.android.providers.telephony/databases/mmssms.db through command prompt but the file is only 42KB, which means a blank file is created.
Is there a way I can access the internal memory as USB device?
or
are there any SU or ADB commands by which I can restore mmssms.db to an older date?
or
Any linux commands i can run to read the data on physical blocks (assuming some blocks of memory will still have some data even if the file is overwritten or the new .db file is not necessarily at the same physical location)
Any Linux developers out there who can help me with any commands to try?
As flash memory is actually erased, not just marked as no longer in use (like magnetic media) there may be no way to get you data back. However this is not ALWAYS the case, but I think it would be pretty difficult.
You may be able to dd the partition where your data was to a file on the sd card and then try to recover data from that once you transfer it to your pc.
Hi guys,
I need some hints on what has changed from Android < 5 to Lollipop when it comes to internal storage.
I have booted my Nexus 4 running Lollipop into ClockworkMod recovery and mounted the internal storage.
Then I did an "adb push" of files that I have backed up before to restore those onto the internal storage.
Once that was done I have opened a shell and changed ownership back to media_rw:media_rw and also
checked POSIX permissions to be correct.
Basically this is what I have done so many different times on different Android devices.
Once I have booted back into the system ... I could not access any of those files and directories.
I assume that there was something added on top of plain POSIX access control. A SELinux thing or something
like ACL or stuff, or maybe a database referring to files stored on /sdcard.
Anyway what can I do in recovery mode to make manually copied files and directories available in the system?
Any help would be appreciated!
Thanks in advance!
/Al
Hello Everyone,
I've been trying for more than a week now to recover data (photos, contacts, messages) from my HTC One M7 after I accidentally hit the factory reset button (was in a hurry to play squash and was fumbling around till the disaster happened!) :crying: Worse of all, I have no backups :crying::crying: My phone has no SD card, only the internal memory. It runs on Android 5.0.2 and has been rooted. I have busybox and TWRP installed on the phone. I have Android SDK and cygwin on my PC.
Initially, I tried to mount the phone's internal memory as a drive on Windows so I can do a scan of it using a data recovery tool. But I wasn't successful as MTP seems like the only option and there's no way to diable it. Even the disable MTP option inside TWRP doesn't make the drive accessible via USB! I have tried various recovery software available online but none of them can see my phone thanks to the stupid MTP!
Finally, I tried the steps on this thread precisely
http://forum.xda-developers.com/gal...de-internal-memory-data-recovery-yes-t1994705
Have managed to copy the whole memory block of the phone using
/system/xbin/busybox nc -l -p 5555 -e /system/xbin/busybox dd if=/dev/block/mmcblk0
and created a mmcblk0.raw file which I can open using Disk Internals (Linux Reader). I found only the data that currently exists on the drive after the factory reset. Tried to access the image with TestDisk (as shown here - http://www.df.lth.se/~jokke/androidfilerecovery/) and I cannot see any of my old files there too! (I'm trying the Deeper Search Option now)
I'm not sure if 'dd' command copies the disk sector-by-sector. I think any data recovery software can scan the disk image and find the old files as long as I can create a sector-by-sector image of the phone's internal drive. If not, any way to mount the internal drive as a USB drive on Windows could work too! Can anyone please help me with this?
Many thanks in advance!!!!
Disclaimer: I know that there are other ways to put apps and data on a sdcard which might circumvent the problems I have. I'm not looking for a practical alternativ, but for insight why things are like they are - understanding. This might or might not lead to a 'howto replace your device and keep your sdcard which is formated as adoptable storage'. I'm aware that understanding things might not lead to any practical help.
Also I searched XDA and the internet for information on this topic various times and didn't find anything helpful. If I oversaw something I'm greatful if I'm pointed to it.
I'm testing on two Sony Xperia Z1. Up till now I did the following:
Test 1:
- made backup of everything to usb otg device in twrp on Device1 (sdcard configured as adoptable storage)
- recovered backup of Device1 on Device2 (excluding trim area)
- put sdcard (adoptable storage) from Device1 into Device2 and started the system
- /dev/block/dm-0 is mounted on /mnt/expand/[uuid], but the sdcardfs-mounts to /mnt/runtime/default/emulated, /storage/emulated, /mnt/runtime/read/emulated and /mnt/runtime/write/emulated are missing.
- relocating the sdcard to Device1 shows that it is still working
Test 2:
- made backup of everything to usb otg device in twrp on Device1 (sdcard configured as adoptable storage)
- recovered backup of Device1 on Device2 (excluding trim area) (so far same as Test1)
- started Device2 inserted blank sdcard2 and generated new adoptable storage.
- shutdown Device2, removed sdcard2 and connected original sdcard1 (removed from Device1) and sdcard2 to a computer
- set up device mapper devices for partition 2 of both devices using the keys copied from the devices.
- mounted both device mapper devices and copied files of sdcard1 encrypted filesystem to sdcard2 encrypted filesystem
- umount of device mapper devices, remove of device mapper devices.
- replaced sdcard1 to Device1 and sdcard2 to Device2. Powered on
- Device1 working with all data found (gallery pictures, maps for osmand)
- Device2 had all the expected mounts, but osmand couldn't read its maps
- logcat showed that selinux stopped osmand from reading the maps directory inside the sdcardfs mount of the adoptable storage
- set selinux to permissive: osmand works as expected
Conclusion: On Device2 and/or sdcard2 selinux policies for osmands data on adoptable storage are missing. Since everything (except trim area) is copied from Device1 to Device2 and from sdcard1 to sdcard2 the policies either have to be in trim area (which as I understood is not available on all types of devices) or they are dependend on some device attribute (uuid of sdcard, s/n of device, etc.).
Ideas?
Chri^2 said:
Disclaimer: I know that there are other ways to put apps and data on a sdcard which might circumvent the problems I have. I'm not looking for a practical alternativ, but for insight why things are like they are - understanding. This might or might not lead to a 'howto replace your device and keep your sdcard which is formated as adoptable storage'. I'm aware that understanding things might not lead to any practical help.
Also I searched XDA and the internet for information on this topic various times and didn't find anything helpful. If I oversaw something I'm greatful if I'm pointed to it.
I'm testing on two Sony Xperia Z1. Up till now I did the following:
Test 1:
- made backup of everything to usb otg device in twrp on Device1 (sdcard configured as adoptable storage)
- recovered backup of Device1 on Device2 (excluding trim area)
- put sdcard (adoptable storage) from Device1 into Device2 and started the system
- /dev/block/dm-0 is mounted on /mnt/expand/[uuid], but the sdcardfs-mounts to /mnt/runtime/default/emulated, /storage/emulated, /mnt/runtime/read/emulated and /mnt/runtime/write/emulated are missing.
- relocating the sdcard to Device1 shows that it is still working
Test 2:
- made backup of everything to usb otg device in twrp on Device1 (sdcard configured as adoptable storage)
- recovered backup of Device1 on Device2 (excluding trim area) (so far same as Test1)
- started Device2 inserted blank sdcard2 and generated new adoptable storage.
- shutdown Device2, removed sdcard2 and connected original sdcard1 (removed from Device1) and sdcard2 to a computer
- set up device mapper devices for partition 2 of both devices using the keys copied from the devices.
- mounted both device mapper devices and copied files of sdcard1 encrypted filesystem to sdcard2 encrypted filesystem
- umount of device mapper devices, remove of device mapper devices.
- replaced sdcard1 to Device1 and sdcard2 to Device2. Powered on
- Device1 working with all data found (gallery pictures, maps for osmand)
- Device2 had all the expected mounts, but osmand couldn't read its maps
- logcat showed that selinux stopped osmand from reading the maps directory inside the sdcardfs mount of the adoptable storage
- set selinux to permissive: osmand works as expected
Conclusion: On Device2 and/or sdcard2 selinux policies for osmands data on adoptable storage are missing. Since everything (except trim area) is copied from Device1 to Device2 and from sdcard1 to sdcard2 the policies either have to be in trim area (which as I understood is not available on all types of devices) or they are dependend on some device attribute (uuid of sdcard, s/n of device, etc.).
Ideas?
Click to expand...
Click to collapse
The only understanding that you need is that you can't do what you're trying to do. You can't "transfer" adoptable storage from one device to another. You have to setup adoptable storage on the new device the same way it was done on the old device, from scratch.
The new device has to make its own "links" to adoptable storage, so to speak, the new device can't use the "links" from the old device, it has to create its own the same way the first device did. When the sdcard is adopted as internal, the device creates an encryption key that is specific to that device, another device can't use the sdcard because it will not recognize the encryption key that was created by the first device. As far as it is concerned, the data on the card may as well not exist because it can't "see" the data.
The encryption key "can" be used to retrieve the data on the adopted sdcard via PC, perhaps, but this encryption key can't be used to help the new device "read" the data.
This is similar to trying to use the hard drive and OS from one PC in another PC, but in android, it is more specific.
Sent from my LGL84VL using Tapatalk
Thanks for your reply, but it didn't help, because you didn't explain why the key should not be usable by another device. I'm looking for technical background: How does android prevent the use of the card even if the target system does know the correct key?
Furthermore I think that you're not right about this point - if you were right the following wouldn't have worked and the decrypted /dev/block/dm-0 wouldn't have existed on the second device:
Test 1:
- made backup of everything to usb otg device in twrp on Device1 (sdcard configured as adoptable storage)
- recovered backup of Device1 on Device2 (excluding trim area)
- put sdcard (adoptable storage) from Device1 into Device2 and started the system
- /dev/block/dm-0 is mounted on /mnt/expand/[uuid]
Click to expand...
Click to collapse
You can try it out if you have two similar devices - maybe I have to move the thread to Sony Z1, because on other devices the test I made doesn't work the same way.
Chri^2 said:
Thanks for your reply, but it didn't help, because you didn't explain why the key should not be usable by another device. I'm looking for technical background: How does android prevent the use of the card even if the target system does know the correct key?
Furthermore I think that you're not right about this point - if you were right the following wouldn't have worked and the decrypted /dev/block/dm-0 wouldn't have existed on the second device:
You can try it out if you have two similar devices - maybe I have to move the thread to Sony Z1, because on other devices the test I made doesn't work the same way.
Click to expand...
Click to collapse
Because each device has it's own "identity" to which each key is associated. The new device has a different "identity" and "key", if the data is not encrypted with the key that the device is looking for, it can't decrypt the key assigned to the data by the previous device.
Effectively, a simplified answer is to say that it is because the two devices speak a different language when it comes to their own encrypted data and there is no way to translate between the two to make encrypted data created on "this" device accessible or readable by "that" device.
It's similar to signatures that are assigned to apps and device firmware from various manufacturers. You can't flash a firmware from a completely different device because the software tools involved will not recognize or pass the signatures of different firmware, it will only approve firmware that has the signature it is looking for.
I could also be wrong, no one knows everything, but I'm certain that it is much deeper than you think.
Maybe you can adapt something from the thread below to work something out.
https://forum.xda-developers.com/general/help/corrupted-sd-card-adoptable-storage-t3801250
Sent from my LGL84VL using Tapatalk
Droidriven said:
Because each device has it's own "identity" to which each key is associated.
Click to expand...
Click to collapse
This is what I thought after my Test1 and has been the reason I did Test2 to check if it's true. But Test2 didn't work neither, because there seems to be some selinux policies missing.
I downloaded the source of vold. I'm no programmer and I'm really bad at reading source code. That said: I searched for 'expand_' to find some hint to the key files. Found function BuildKeyPath, which seems to generate a complete path to a key file. This function is used in 'status_t Disk:artitionMixed(int8_t ratio)'. The interesting part that might be the generation of the key for the encrypted partition is
Code:
// We've had some success above, so generate both the private partition
// GUID and encryption key and persist them.
std::string partGuidRaw;
std::string keyRaw;
if (ReadRandomBytes(16, partGuidRaw) || ReadRandomBytes(16, keyRaw)) {
LOG(ERROR) << "Failed to generate GUID or key";
return -EIO;
}
std::string partGuid;
StrToHex(partGuidRaw, partGuid);
if (!WriteStringToFile(keyRaw, BuildKeyPath(partGuid))) {
LOG(ERROR) << "Failed to persist key";
return -EIO;
} else {
LOG(DEBUG) << "Persisted key for GUID " << partGuid;
}
If this is the point in code where the key is generated I read it the way that the key is purely random and not dependend on any component associated with the devices identity.
Taken together with Test2 there are - in my opinion - strong hints pointing in the direction of selinux. Maybe I should retry Test1, but start the phone without the sdcard which then would be shown as missing, set selinux to permissive and then insert the sdcard. I guess I'll give it a go...
Now I found something interesting: I used twrp 3.2.3-0 on my Sony Xperia Z1 to wipe (advanced) all of the partitions of a phone I used to experiment with adoptable storage. Afterwards I looked at the partitions and found that on data existed the following files
Code:
/data/misc/vold/expand_[uuid1]key
/data/misc/vold/expand_[uuid2].key
/data/misc/vold/expand_[uuid3].key
/data/system/storage.xml
/data/.layout_version
To me it looks like twrp conserved those files and put them back after formating the data partition. However it did it and why it pushed me in the right direction.
Test3 on Xperia Z1 using twrp 3.2.3-0:
made backup of everything excluding trim area to usb otg device in twrp on Device1 (sdcard inserted and configured as adoptable storage)
connected via 'adb shell' to Device1 and made a tar archive containing the above mentioned files in /tmp
downloaded the tar archive from Device1:/tmp using 'adb pull'
recovered backup from usb otg of Device1 on Device2
pushed tar archive with keys, .xml and layout-version to to Device2:/tmp
connected via 'adb shell' to Device2 and unpacked the tar archive from /tmp to /data
started Device2: device complains that my sdcard with adoptable storage is missing
put sdcard (adoptable storage) from Device1 into Device2: sdcard is recognized and integrated as adoptable storage
/dev/block/dm-0 is mounted on /mnt/expand/[uuid] and sdcardfs-mounts to /mnt/runtime/default/emulated, /storage/emulated, /mnt/runtime/read/emulated and /mnt/runtime/write/emulated exist also
osmand works and is able to open the files on the adoptable storage. All other applications I looked at worked also
Can anybody try to confirm that this way works to move a backup from one device to another keeping the adoptable storage?
An interesting conclusion about selinux could be that it reads sometimes storage.xml to generate policies allowing the access to adoptable storage. Might be interesting how this works and whether manipulating storage.xml could be a way to inject selinux policies...
twrp recovery showing 0 files in internal storage and showing some random file names I am unable to do anything please help how to fix it
KARTHIKMC007 said:
twrp recovery showing 0 files in internal storage and showing some random file names I am unable to do anything please help how to fix it
Click to expand...
Click to collapse
If you're using a relatively new phone (shipped with android 9.0 or later versions), you most likely have an encrypted data partition. This kind of encryption is relatively new and is called FBE (File Based Encryption), where every file and folder are encrypted separately. (those random file names!)
To access your data partition through twrp, you need to input your lock screen (or boot-up pin) credentials when prompted at the beginning, if you don't receive such a warning at twrp startup, then your custom recovery image may simply not support decrypting storage. In that case use another one .
Slim K said:
If you're using a relatively new phone (shipped with android 9.0 or later versions), you most likely have an encrypted data partition. This kind of encryption is relatively new and is called FBE (File Based Encryption), where every file and folder are encrypted separately. (those random file names!)
To access your data partition through twrp, you need to input your lock screen (or boot-up pin) credentials when prompted at the beginning, if you don't receive such a warning at twrp startup, then your custom recovery image may simply not support decrypting storage. In that case use another one .
Click to expand...
Click to collapse
thank you
but I have flashed orange fox recovery and twrp latest in both it is showing the same random file names