Reading dd dump to extract data from internal storage?

Search This thread
hi, i have a xiaomi mi mix 2s that was running los18. one morning i woke up before my alarm, checked my phone and went back to sleep. when i woke up again, i found the phone was on the splash screen and then started bootlooping. going into orangefox recovery, i was greeted with numerous /data mount errors, namely:
Code:
Could not mount /data and unable to find crypto footer.
Failed to mount '/data' (Invalid argument)
Unable to recreate /data/media folder.
Unable to mount storage
from what i can tell, the only way to get the device working again is to format the /data partition, which means losing all my data which im trying to avoid. i did manage to obtain a dd dump of /dev/block/bootdevice/by-name/userdata through usb otg, though ive been unable to read the img file, either through windows or ubuntu. is there any way to mount it and retrieve the data? i did specifically flash dfe from the start, so it should be unencrypted. the file system is ext4.

would also greatly appreciate other suggestions on how to recover the data.
 
Last edited:

xXx yYy

Senior Member
Feb 4, 2017
961
5
162
You restore the data backed up with DD command as following

Code:
dd if=dump.img of=/dev/mmcblk0p29

assuming partition named userdata is block device named mmcblk0p29
 

aIecxs

Senior Member
Feb 17, 2016
1,904
551
gitlab.com
check getprop ro.crypto.type and ro.crypto.state from adb shell. also check dump.img with xxd or hexdump has ext4 / f2fs magic 53.ef / 10.20.f5.f2 starting at 1080 / 1024 byte
 
apologies for the late reply, dont really check xda that often.
You restore the data backed up with DD command as following

Code:
dd if=dump.img of=/dev/mmcblk0p29

assuming partition named userdata is block device named mmcblk0p29
is that after wiping? wouldnt that make the data partition unreadable again?
check getprop ro.crypto.type and ro.crypto.state from adb shell. also check dump.img with xxd or hexdump has ext4 / f2fs magic 53.ef / 10.20.f5.f2 starting at 1080 / 1024 byte
ro.crypto.type=file
ro.crypto.state=encrypted
as for checking the dump, are you referring to the commands:
Code:
xxd -l 1080 dump.img | grep 53ef
xxd -l 1024 dump.img | grep 1020.f5f2
if so, i did not receive any output. if they are wrong commands please let me know what i should enter.
 
Last edited:

aIecxs

Senior Member
Feb 17, 2016
1,904
551
gitlab.com
looks like (FBE) file-based encryption. if dump is really encrypted there is nothing you can do on PC.

you can only restore + decrypt on device (as long as you did not factory reset)
 
looks like (FBE) file-based encryption. if dump is really encrypted there is nothing you can do on PC.

you can only restore + decrypt on device (as long as you did not factory reset)
i havent factory reset as i read some things about tee keys that would be wiped during data format, so i thought it would be handy to keep if i needed them. how would i go about trying to decrypt on device though?

also, what would have been the point of flashing dfe if in the end data is still encrypted?
 

aIecxs

Senior Member
Feb 17, 2016
1,904
551
gitlab.com
right, encryption is bonded to TEE (which is flushed on factory reset). just restore and let orangefox or twrp decrypt (assuming it has well implemented encryption support). otherwise your only chance to decrypt is via regular booting into android (to at least stage with lockscreen or adb).

FBE data is encrypted with screen lock credentials, remember old pin, pattern, password used at time of dump.

"dfe" stands for disable force encryption (encryption will no longer forced after formatting) and there is a good chance this is the reason for failed decrypts. you can undo by restoring vendor partition.
 
Last edited:
  • Like
Reactions: NightRaven49
just restore and let orangefox or twrp decrypt (assuming it has well implemented encryption support).
do you mean restore as in simply
Code:
dd if=/dump.img of=/dev/block/sda21
as @xXx yYy mentioned? would that make a difference? since the block device is fundamentally holding the same bits before and after doing so, at least to my understanding. im also quite apprehensive about making any modifications to the data partition as it is right now.
otherwise your only chance to decrypt is via regular booting into android (to at least stage with lockscreen or adb).
the phone doesnt get to lockscreen... 😢 i did enable usb debugging, but not sure if it is possible to access while bootlooping.
"dfe" stands for disable force encryption (encryption will no longer forced after formatting) and there is a good chance this is the reason for failed decrypts. you can undo by restoring vendor partition.
the thing is, i flash dfe right after flashing the rom with a data format, so i thought i would be safe from this kind of things happening. plus, i had been running this setup since the start of the year, and hadnt so much as changed any system settings recently, so its quite odd that the problem would just randomly manifest. it is not the first time it has happened either, in fact this happening the first time was what prompted me to start using dfe, so it is quite disappointing to see that it did not have its intended effect.

so to clarify, should i dd to the userdata block device and restore vendor (presumably from rom zip) or is dd enough?
 
Last edited:

aIecxs

Senior Member
Feb 17, 2016
1,904
551
gitlab.com
yes, dd is fine (one could also use of=/dev/block/bootdevice/by-name/userdata)
and no, of course it doesn't make sense in that case.

I don't know what is the cause but I am afraid the only way to access that data is fix boot-loop.

It is unclear to me if encryption worked for a year or if you encrypted recently. Open dump with HxD and check first 1088 bytes for ext4 magic, or at least you should see many zeros on plain disk image.

Also check /vendor/etc/fstab* for flags in line /dev/block/bootdevice/by-name/userdata with notepad++ this could help to identify encryption is broken by dfe or healthy.
 

Renate

Recognized Contributor / Inactive Recognized Dev
I checked two devices offhand, one was block encrypted, the other file encrypted.
I looked at the last 1M of the partitition of the file encrypted.
I thought that there was a footer there, there wasn't.

Your original message said that it couldn't find the footer.
I know some things use footers and they are usually a specific number of blocks before the end of the partition.
 

aIecxs

Senior Member
Feb 17, 2016
1,904
551
gitlab.com
@Renate unable to find crypto footer - is misleading message from orangefox twrp recovery - it always check for any type of encryption but FBE encryption requires no crypto footer (only FDE or metadata encryption)
 
  • Like
Reactions: Renate
yes, dd is fine (one could also use of=/dev/block/bootdevice/by-name/userdata)
and no, of course it doesn't make sense in that case.
so should i still do it? 😅
I don't know what is the cause but I am afraid the only way to access that data is fix boot-loop.
but it also seems that the bootloop is caused by the inability to mount data...
also it seems adb is not accessible while it bootloops.
It is unclear to me if encryption worked for a year or if you encrypted recently.
i flashed dfe along with the rom and magisk at the start of the year, havent flashed anything since. i also did not initiate any encryption process the whole time.
Open dump with HxD and check first 1088 bytes for ext4 magic, or at least you should see many zeros on plain disk image.
it is mostly 0000 or ffff, though there is mention of ext4 map blocks a little further down.
xmtUpPk.png
Also check /vendor/etc/fstab* for flags in line /dev/block/bootdevice/by-name/userdata with notepad++ this could help to identify encryption is broken by dfe or healthy.
Code:
<src>   <mnt_point>   <type>   <mnt_flags and options>   <fs_mgr_flags>
/dev/block/bootdevice/by-name/userdata   /data   ext4   noatime,nosuid,nodev,barrier=0,noauto_da_alloc   latemount,wait,check,=ice,quota
 

aIecxs

Senior Member
Feb 17, 2016
1,904
551
gitlab.com
okay the good news it's probably not encrypted (at least no FDE) no need to decrypt disk image on phone.

the bad news it doesn't look like valid ext4 file system, you cannot mount it.

on linux pc, try fsck on dump2.img (make a copy first) then try to loop mount file. you can also try testdisk or photorec

the flag fileencryption=ice is broken by dfe (which is intended) so encryption/decryption won't work (as desired, not required on plain ext4)
 
  • Like
Reactions: NightRaven49
on linux pc, try fsck on dump2.img (make a copy first) then try to loop mount file. you can also try testdisk or photorec
THANK YOU SO MUCH! my data is now readable on linux, will copy as much over before doing anything else. i was legitimately not expecting it to work.

should i also dd the repaired img to my userdata block device? i know twrp/ofox has e2fsck command, seems like it may be able to repair the partition on device in a similar manner.
 
Last edited:
  • Like
Reactions: aIecxs

aIecxs

Senior Member
Feb 17, 2016
1,904
551
gitlab.com
didn't expect it's so easy lol.. yeah try e2fsck on /dev/block/bootdevice/by-name/userdata directly first.

ro.crypto.type=file
ro.crypto.state=encrypted
as for checking the dump, are you referring to the commands:
Code:
xxd -l 1080 dump.img | grep 53ef
xxd -l 1024 dump.img | grep 1020.f5f2
if so, i did not receive any output.

TWRP/Orangefox properties was bit misleading...

sometimes the solution is simpler than we think
 
Last edited:
didn't expect it's so easy lol..
same, actually the last time it happened (over 1.5 years ago) i also tried something similar, but didnt work because it was f2fs if i remember correctly. so i didnt think of trying e2fsck this time around. i suspect it may be a hardware flaw that caused it, since i am running a different rom now.
yeah try e2fsck on /dev/block/bootdevice/by-name/userdata directly first.
it works now, again thank you so much. funny how i was stuck without a phone for a month, went to so many data recovery specialists that told me that there was no hope and yet the fix was finished in mere seconds.
 
  • Like
Reactions: aIecxs

Top Liked Posts

  • There are no posts matching your filters.
  • 1
    right, encryption is bonded to TEE (which is flushed on factory reset). just restore and let orangefox or twrp decrypt (assuming it has well implemented encryption support). otherwise your only chance to decrypt is via regular booting into android (to at least stage with lockscreen or adb).

    FBE data is encrypted with screen lock credentials, remember old pin, pattern, password used at time of dump.

    "dfe" stands for disable force encryption (encryption will no longer forced after formatting) and there is a good chance this is the reason for failed decrypts. you can undo by restoring vendor partition.
    1
    @Renate unable to find crypto footer - is misleading message from orangefox twrp recovery - it always check for any type of encryption but FBE encryption requires no crypto footer (only FDE or metadata encryption)
    1
    okay the good news it's probably not encrypted (at least no FDE) no need to decrypt disk image on phone.

    the bad news it doesn't look like valid ext4 file system, you cannot mount it.

    on linux pc, try fsck on dump2.img (make a copy first) then try to loop mount file. you can also try testdisk or photorec

    the flag fileencryption=ice is broken by dfe (which is intended) so encryption/decryption won't work (as desired, not required on plain ext4)
    1
    on linux pc, try fsck on dump2.img (make a copy first) then try to loop mount file. you can also try testdisk or photorec
    THANK YOU SO MUCH! my data is now readable on linux, will copy as much over before doing anything else. i was legitimately not expecting it to work.

    should i also dd the repaired img to my userdata block device? i know twrp/ofox has e2fsck command, seems like it may be able to repair the partition on device in a similar manner.
    1
    didn't expect it's so easy lol..
    same, actually the last time it happened (over 1.5 years ago) i also tried something similar, but didnt work because it was f2fs if i remember correctly. so i didnt think of trying e2fsck this time around. i suspect it may be a hardware flaw that caused it, since i am running a different rom now.
    yeah try e2fsck on /dev/block/bootdevice/by-name/userdata directly first.
    it works now, again thank you so much. funny how i was stuck without a phone for a month, went to so many data recovery specialists that told me that there was no hope and yet the fix was finished in mere seconds.