Related
So after a failed attempt to upgrade from CyanogenMod 10.1.3 to 10.2, I was unable to access /data or /sdcard because both systems were encrypted. I ended up having to factory reset my phone because it refused to co-operate or let me access my files. However, before I did that, I was able to run
Code:
adb shell "dd if=/dev/block/mmcblk0p2" > data.img
and
Code:
adb shell "dd if=/dev/block/mmcblk0p3" > sdcard.img
, which appears to have copied the raw partition images from the phone (at least, they're the right sizes).
According to my reading, Android (and, I'm inferring, CyanogenMod) encrypts filesystems using dm-crypt, with a AES-CBC ESSIV:SHA256 cipher, with the key being derived from the password using PBKDF2. Knowing the precious little I do about encrypted file systems, my guess is that if I configure the image in cryptsetup to create a drive mapping, I can mount the mapped drive and recover the data from the images.
According to /fstab.herring on my ahem, fresh, install of Android, the /data partition is in ext4 format whereas the /sdcard partition is vFAT. So, once I've gotten through the encryption on the partition images, they should mount normally, right?
I know that dm-crypt accepts plain, LUKS, LoopAES and TrueCrypt device formats. I'm inferring from the PBKDF2 extension that Android goes the LUKS route for encrypting. Is this conclusion correct?
Could someone explain whether it's possible to decrypt a dumped android image? I'm really hoping that the cypher information is stored on the file system and not on some key file that I nuked in the factory reset. If it can, in theory, be decrypted, am I using the right tools to approach the matter? If so, I'll continue fiddling with cryptsetup and mount, but no sense in wasting time if it's an impossible task.
Never did get a response to this question, so I'll try it again, but start with a simpler question:
If someone dds an Android (specifically Cyanogenmod 10.x) partition to an img file, is there any way to read that image from, say a Linux laptop? I dumped the contents of the /system partition using
Code:
adb shell "dd if=/dev/block/mmcblk0p1" > system.img
I expected system.img to be a normal ext4 partition. However, attempting to loopback mount it with
Code:
sudo mount -t ext4 -o loop,ro system.img ~/android/system
Gave me errors about corrupt group descriptors, bad magic numbers and other maladies indicative of a thoroughly corrupted file system. I'm assuming that:
/data has the same ext4 partition structure as /system; and
The process to mount /storage would be no different to mounting /system with the exception that the former uses vFAT as its file system
However, as my Android is currently working normally (well, as well as one can hope for Android to work), I know I don't have a corrupted file system.
So what's going on? Does Android use a special version of ext4 that other Linuxes don't recognise? Am I not dd-ing correctly? Is there a block-size issue I ignored to my peril?
Borden Rhodes said:
So after a failed attempt to upgrade from CyanogenMod 10.1.3 to 10.2, I was unable to access /data or /sdcard because both systems were encrypted. I ended up having to factory reset my phone because it refused to co-operate or let me access my files. However, before I did that, I was able to run
Code:
adb shell "dd if=/dev/block/mmcblk0p2" > data.img
and
Code:
adb shell "dd if=/dev/block/mmcblk0p3" > sdcard.img
, which appears to have copied the raw partition images from the phone (at least, they're the right sizes).
According to my reading, Android (and, I'm inferring, CyanogenMod) encrypts filesystems using dm-crypt, with a AES-CBC ESSIV:SHA256 cipher, with the key being derived from the password using PBKDF2. Knowing the precious little I do about encrypted file systems, my guess is that if I configure the image in cryptsetup to create a drive mapping, I can mount the mapped drive and recover the data from the images.
According to /fstab.herring on my ahem, fresh, install of Android, the /data partition is in ext4 format whereas the /sdcard partition is vFAT. So, once I've gotten through the encryption on the partition images, they should mount normally, right?
I know that dm-crypt accepts plain, LUKS, LoopAES and TrueCrypt device formats. I'm inferring from the PBKDF2 extension that Android goes the LUKS route for encrypting. Is this conclusion correct?
Could someone explain whether it's possible to decrypt a dumped android image? I'm really hoping that the cypher information is stored on the file system and not on some key file that I nuked in the factory reset. If it can, in theory, be decrypted, am I using the right tools to approach the matter? If so, I'll continue fiddling with cryptsetup and mount, but no sense in wasting time if it's an impossible task.
Click to expand...
Click to collapse
Can you give the result of the "file sdcard.img" and "file data.img" commands?
You are quite right. With regular LUKS container/partition, you would do (being root) the following. With the following commands, you can create a container named "safe", setup it, then format its content in ext3 and mount the partition:
Code:
dd if=/dev/zero bs=1M count=50 of=safe
losetup /dev/loop0 safe
cryptsetup luksFormat -c aes -h sha256 /dev/loop0
cryptsetup luksOpen /dev/loop0 safe
mkfs.ext3 /dev/mapper/safe
(losetup /dev/loop0 safe)
(cryptsetup luksOpen /dev/loop0 safe)
mkdir mnt
mount -t ext3 /dev/mapper/safe mnt
//HERE: do whatever you want in your mounted encrypted filesystem
umount mnt
cryptsetup luksClose safe
losetup -d /dev/loop0
For details, you can go there: http://blog.theglu.org/index.php/20...-couteau-suisse-du-chiffrement-de-partitions/
Sorry, the article is in French but you can translate it if you need to.
Here, using "hexdump", you can see the "safe" file has a LUKS magic at the beginning. And doing a "file safe" command, you can check it detects it as a "LUKS encrypted file".
If doing "file" on your .img files does not give you the same result, you may not be able to directly use the "cryptsetup" command and need to adapt it.
Finally: usually in Android the header containing the key is stored on another partition so you may have lost it when wiping your phone, sorry.
---------- Post added at 02:44 PM ---------- Previous post was at 02:41 PM ----------
Borden Rhodes said:
Never did get a response to this question, so I'll try it again, but start with a simpler question:
If someone dds an Android (specifically Cyanogenmod 10.x) partition to an img file, is there any way to read that image from, say a Linux laptop? I dumped the contents of the /system partition using
Code:
adb shell "dd if=/dev/block/mmcblk0p1" > system.img
I expected system.img to be a normal ext4 partition. However, attempting to loopback mount it with
Code:
sudo mount -t ext4 -o loop,ro system.img ~/android/system
Gave me errors about corrupt group descriptors, bad magic numbers and other maladies indicative of a thoroughly corrupted file system. I'm assuming that:
/data has the same ext4 partition structure as /system; and
The process to mount /storage would be no different to mounting /system with the exception that the former uses vFAT as its file system
However, as my Android is currently working normally (well, as well as one can hope for Android to work), I know I don't have a corrupted file system.
So what's going on? Does Android use a special version of ext4 that other Linuxes don't recognise? Am I not dd-ing correctly? Is there a block-size issue I ignored to my peril?
Click to expand...
Click to collapse
Can you give the result of the "file system.img" command?
Thanks, saidlike, for your reply:
saidelike said:
Can you give the result of the "file sdcard.img"...
Click to expand...
Click to collapse
sdcardPartitionDump.img: data
saidelike said:
... and "file data.img" commands?
Click to expand...
Click to collapse
data.img: data
saidelike said:
Can you give the result of the "file system.img" command?
Click to expand...
Click to collapse
system.img: Linux rev 1.0 ext4 filesystem data, UUID=57f8f4bc-abf4-655f-bf67-946fc0f9f25b (needs journal recovery) (extents) (large files)
Again, attempting to run
Code:
mount -t ext4 -o loop systemimg mountpoint/
yields
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
Click to expand...
Click to collapse
Ignoring the results of data.img and sdcard.img for the time being, the fresh dump of the system partition shows that it's an EXT4 filesystem, but that it's heavily corrupted. fsck.ext4 on that partition basically asks me to fix every single inode, so it's not a simple unclean journal issue. Therefore, is it fair to conclude that CyanogenMod (and maybe AOSP too) have modified the ext4 partiiton type?
@Borden Rhodes
Maybe, my reply is too late, but you could try to make the same experiment with backup of your current data.
If you get the same results as with the old pre-wipe backup, then you still have a hope.
I'm trying to build aosp for my galaxy tab 10.1 wifi (p4wifi). I've included the relevant device and vendor projects, as well as an updated bionic with tegra2 support for libc. It successfully builds, but flashing the resulting otapackage (using twrp) or the img files (using heimdall) results in empty boot and system directories on the device.
The system directory within the otapackage isn't empty, and the img files aren't as well. The updater-script extracts the system directory as normal.
Edit (Solved):
The partitions weren't being mounted in recovery, but I believe they are mounted normally. "mount /system" mounted the partition and it contains the expected files. Still not booting properly, but at least I know this isn't my issue.
Hello ..
Someone help me.
i Took Backup from Official TWRP but when i am trying to restore it giving me error=255 . How i fix this.
it happens when i am trying to restore FIRMWARE partition.
any solution . anyone facing this issue.. ?
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
FurqanHanif said:
Hello ..
Someone help me.
i Took Backup from Official TWRP but when i am trying to restore it giving me error=255 . How i fix this.
it happens when i am trying to restore FIRMWARE partition.
any solution . anyone facing this issue.. ?
Click to expand...
Click to collapse
Answered you in the TWRP thread. Check again.
FurqanHanif said:
Hello ..
Someone help me.
i Took Backup from Official TWRP but when i am trying to restore it giving me error=255 . How i fix this.
it happens when i am trying to restore FIRMWARE partition.
any solution . anyone facing this issue.. ?
Click to expand...
Click to collapse
Just restore system, data,and boot , don't forget flash frimware..Done , solved.
sachin n said:
Answered you in the TWRP thread. Check again.
Click to expand...
Click to collapse
I am stuck with the same problem. Can you link me to your answer to him or just again tell me what's the solution?
Firmware was 90MB before, after trying to restore it, TWRP wiped it and now it's 23MB.
nilanko said:
I am stuck with the same problem. Can you link me to your answer to him or just again tell me what's the solution?
Firmware was 90MB before, after trying to restore it, TWRP wiped it and now it's 23MB.
Click to expand...
Click to collapse
The answer is to just restore system, data and boot. That's the way to go.
Sent from my mido using XDA Labs
I just restore system and data, but problem was occur like that. Any solution?
From my experience, i think it is because of miui rom??
After trying many time, I used this method .....
1. first wipe everything
2. flash original zip rom
3.then flash your backup
4. Flash lazyflasher
It will show error though but you will get radio working
Firmware Problem "extractTarFork process ended with ERROR 255"
In My case Firmware is not restoring
shoiwing error "extractTarFork process ended with ERROR 255"
so to solve it
1.Wipe data dalvik cache and system
2.Just flash the new rom which u had earlier.
for exp. i had lineage 14.1
3.After installing it ask for wipe dalvik and cache do it then dont wipe it from the main menu.
4.just restore the backuped file without ticking the firmware
Note-Firmware must be untick while restoring
5.done Problem of fingerprint scanner and network problem also solved by this
Note-Dont restart in between
if it helps you
Subscribe to My Youtube Channel youtube.com/AnonymAb
AmanBhagat said:
In My case Firmware is not restoring
shoiwing error "extractTarFork process ended with ERROR 255"
so to solve it
1.Wipe data dalvik cache and system
2.Just flash the new rom which u had earlier.
for exp. i had lineage 14.1
3.After installing it ask for wipe dalvik and cache do it then dont wipe it from the main menu.
4.just restore the backuped file without ticking the firmware
Note-Firmware must be untick while restoring
5.done Problem of fingerprint scanner and network problem also solved by this
Note-Dont restart in between
if it helps you
Subscribe to My Youtube Channel youtube.com/AnonymAb
Click to expand...
Click to collapse
does not work for me. do you have any other method?
FurqanHanif said:
Hello ..
Someone help me.
i Took Backup from Official TWRP but when i am trying to restore it giving me error=255 . How i fix this.
it happens when i am trying to restore FIRMWARE partition.
any solution . anyone facing this issue.. ?
Click to expand...
Click to collapse
sohanaw said:
does not work for me. do you have any other method?
Click to expand...
Click to collapse
That happened to me twice, loosing the imei.
To fix it, just restore or flash any rom you want, and follow this steps:
Extract NON-HLOS.bin file from official ROM.
Copy extracted NON-HLOS.bin to the adb/fastboot folder.
Boot your device into fastboot mode.
Connect your device to PC
In the folder with adb/fastboot tools press “Shift” key + right mouse button and select “Open command window here”.
Enter these commands in order:
Code:
Fastboot devices
Fastboot.exe erase modem
Fastboot.exe flash modem NON-HLOS.bin
Fastboot.exe reboot
Check your IMEI. It should be restored now.
ramping said:
That happened to me twice, loosing the imei.
To fix it, just restore or flash any rom you want, and follow this steps:
Extract NON-HLOS.bin file from official ROM.
Copy extracted NON-HLOS.bin to the adb/fastboot folder.
Boot your device into fastboot mode.
Connect your device to PC
In the folder with adb/fastboot tools press “Shift” key + right mouse button and select “Open command window here”.
Enter these commands in order:
Code:
Fastboot devices
Fastboot.exe erase modem
Fastboot.exe flash modem NON-HLOS.bin
Fastboot.exe reboot
Check your IMEI. It should be restored now.
Click to expand...
Click to collapse
modem is okay i am able to flash that.
but for me persist is showing 0mb in twrp and i am unable to flash persist i have tried fastboot miflash none worked for me .
please if you have any other method then share.
Go back to StockROM with the help of Xiaomi's tools
Had the same problem. The methods above didn't work for me, either.
I went back to StockROM with the tools provided on the Xiaomi website, the process will re-flash the firmware, too and all described problems will be solved. Make sure you'll untick "firmware" on the next time when trying a restore
ramping said:
That happened to me twice, loosing the imei.
To fix it, just restore or flash any rom you want, and follow this steps:
Extract NON-HLOS.bin file from official ROM.
Copy extracted NON-HLOS.bin to the adb/fastboot folder.
Boot your device into fastboot mode.
Connect your device to PC
In the folder with adb/fastboot tools press “Shift” key + right mouse button and select “Open command window here”.
Enter these commands in order:
Check your IMEI. It should be restored now.
Click to expand...
Click to collapse
Well what can i said??u really save my poor soul last night!!been 2 days searching for solution after error 255 on my redmi 5 plus,ur solution work perfectly n thank you brooooo!!!???
Sent from my Redmi 5 Plus using XDA Labs
well this is weird.
I'm having error 255 on firmware partition restore, no matter what I do (redmi note4x snapdragon global, nandroid backups from stock miui8.5-9.2 and LAOS15.1)
However using (at least some of) my backups with firmware unticked and then installing firmware from TWRP package does the trick, like this one below:
https://forum.xda-developers.com/re...irmware-firmware-miui-9-china-stable-t3697976
I had this problem on a Redmi Note 3 Pro/Qualcomm recently. It seems to me to be loosely correlated to the /data backup size, and seems to manifest just below 4GB, looks suspiciously like some 32bit counter/offset ... but .... in my case this seems to happen only in the first tar/win file which much < 2GB uncompressed anyway.
Interestingly, not all tar binaries are equal. The binary from LineageOS 14.1 crashes reading win000 files often if I try to test this from a terminal session when the phone is booted normally, however tar from TWRP does work and doesn't crash. Using tar from ubuntu 18.04 I can see all the files, however there are numerous reports of
Code:
tar: Malformed extended header: missing equal sign
Maybe this tar crash is also what is happening for the TWRP GUI using it's internal tar? Although this seems to be crashing when the recovery is nearing 4GB, however my tar crash seems to happen on the first segmented win000 file? Maybe it is related in some way to pigz which seems to be used by the TWRP GUI to compress/uncompress and it does multi-threading. I haven't looked at TWRP code.
I tried TWRP 3.1.1-0, and downloaded the latest 3.2.3-0 from twrp.me. Both failed in the same way.
I inspected some of the backups I had, finding decrypted /data space usage less /data/media:
Code:
$ ls -1
2018-09-06--12-41-18_lineage_kenzo-userdebug_7.1.2_NJH47F_02865f
2018-11-10--11-08-53_lineage_kenzo-userdebug_7.1.2_NJH47F_02865f
2019-01-10--10-01-22_lineage_kenzo-userdebug_7.1.2_NJH47F_02865f
2019-01-26--16-04-54_lineage_kenzo-userdebug_7.1.2_NJH47F_02865f
$ grep Data.backup.size */recovery.log|uniq|sed 's/\// /;s/--[^ ]* / /;s/:/ /'
2018-09-06 recovery.log I:Data backup size is 3464MB, free: 14062MB.
2018-09-06 recovery.log I:Data backup size is 3464MB, free: 11552MB.
2018-11-10 recovery.log I:Data backup size is 4622MB, free: 11065MB.
2018-11-10 recovery.log I:Data backup size is 4622MB, free: 7576MB.
2019-01-10 recovery.log I:Data backup size is 4041MB, free: 11284MB.
2019-01-10 recovery.log I:Data backup size is 4041MB, free: 8192MB.
2019-01-26 recovery.log I:Data backup size is 652MB, free: 24414MB.
$
I could restore 2018-09-06 and 2019-01-26 using TWRP GUI while the other 2 failed with error=255. Of the backups I could restore with the TWRP GUI, both backups are easily < 4GB. 2019-01-10 is just below, still no idea if it is related to 4GB. In each case I formatted /data before hand, so /data/media was empty, so there was 24GB of free space, so there was always at least 2 times, sometimes 5 times, the actual space required for the recovery available.
Irrespective of the actual failure mode, I was able to restore the other backups manually.
Interestingly when I examine the .win and .win000 files with
Code:
tar tvf file | sed 5q
I find that the single .win file backups need to be restored while current directory is /data whereas the multipart backups need to be restored while current directory is /.
Manual restore process from TWRP recovery shell :
Backup everything to storage external the phone, and then backup the backup.
Wipe /data. I prefer to format /data while also wipes /data/media = /sdcard as this guarantees /data is clean, however if your backups are stored in /sdcard/TWRP then you are going to need to either not format /data or restore them from your PC, or not store them in /sdcard/TWRP and store them on an external sdcard or external USB OTG drive. Actual location may vary depending on TWRP build. Determine the b= lines below appropriately.
Connect using adb shell. You could type this in using the TWRP Advanced Terminal, but error prone.
Make sure you have enough free space on /data to do the restore. You should have, but this is the manual process so cross check.
Restore the .win0?? files with tar.
Code:
... # PS1="# " # optional
# cd /location/TWRP/BACKUPS/serialnumber/2019-01-10* # location: sdcard sdcard1 usb-otg
# pwd # verify backup directory
/location/TWRP/BACKUPS/.../2019-01-10--10-01-22_...
# b=$(pwd) # remeber backup folder location
# ls -l data.*.win000 # verify backup file exists
-rw-rw---- 1 root sdcard_rw 1109681843 2019-01-26 11:02 data.ext4.win000
# for m in data*md5; do md5sum -c $m; done # verify md5 checksums of each tar/win file.
data.ext4.win000: OK
data.ext4.win001: OK
data.ext4.win002: OK
# cd /
# for w in $b/data*win0??; do echo recover $w; tar xpvf $w > $w.rec; echo; done
recover /.../data...win000
tar: removing leading '/' from member names
recover /.../data...win001
tar: removing leading '/' from member names
recover /.../data...win002
tar: removing leading '/' from member names
# cd $b
# wc -l data*rec # verify recovery of reasonable number of files
29346 data.ext4.win000.rec
343 data.ext4.win001.rec
1831 data.ext4.win002.rec
31520 total
# df /data
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/block/dm-0 25667344 15051056 10599904 59% /data
#
Reboot
Download latest mido firmware and flash through twrp.
If you are on mido here is the solution i used
I flashed the last rom i had ( for my case :miui.eu 10.3 oreo port )
Then wipe data
The flashed the miui 10.1.1.0 for mido
And wait for it to boot up and you will be fine
You can update after to 10.2.3.0
The good fix!!!
TWRP always skip data/media in backup or restore. This is a problem!
Restoring procedure "automatic format" skipped data/media folder, only delete other folders. "Wiping data without wiping data/media ..."
To delete data partition completly:
1. Go to Wipe menu
2. Wipe Data
3. Yes (all data, audio, video, etc deleted)
4. Go to Restore menu
5. Restore Data partition
Restore completed without error!
samarium said:
I had this problem on a Redmi Note 3 Pro/Qualcomm recently. It seems to me to be loosely correlated to the /data backup size, and seems to manifest just below 4GB, looks suspiciously like some 32bit counter/offset ... but .... in my case this seems to happen only in the first tar/win file which much < 2GB uncompressed anyway.
Interestingly, not all tar binaries are equal. The binary from LineageOS 14.1 crashes reading win000 files often if I try to test this from a terminal session when the phone is booted normally, however tar from TWRP does work and doesn't crash. Using tar from ubuntu 18.04 I can see all the files, however there are numerous reports of
Code:
tar: Malformed extended header: missing equal sign
Maybe this tar crash is also what is happening for the TWRP GUI using it's internal tar? Although this seems to be crashing when the recovery is nearing 4GB, however my tar crash seems to happen on the first segmented win000 file? Maybe it is related in some way to pigz which seems to be used by the TWRP GUI to compress/uncompress and it does multi-threading. I haven't looked at TWRP code.
I tried TWRP 3.1.1-0, and downloaded the latest 3.2.3-0 from twrp.me. Both failed in the same way.
I inspected some of the backups I had, finding decrypted /data space usage less /data/media:
Code:
$ ls -1
2018-09-06--12-41-18_lineage_kenzo-userdebug_7.1.2_NJH47F_02865f
2018-11-10--11-08-53_lineage_kenzo-userdebug_7.1.2_NJH47F_02865f
2019-01-10--10-01-22_lineage_kenzo-userdebug_7.1.2_NJH47F_02865f
2019-01-26--16-04-54_lineage_kenzo-userdebug_7.1.2_NJH47F_02865f
$ grep Data.backup.size */recovery.log|uniq|sed 's/\// /;s/--[^ ]* / /;s/:/ /'
2018-09-06 recovery.log I:Data backup size is 3464MB, free: 14062MB.
2018-09-06 recovery.log I:Data backup size is 3464MB, free: 11552MB.
2018-11-10 recovery.log I:Data backup size is 4622MB, free: 11065MB.
2018-11-10 recovery.log I:Data backup size is 4622MB, free: 7576MB.
2019-01-10 recovery.log I:Data backup size is 4041MB, free: 11284MB.
2019-01-10 recovery.log I:Data backup size is 4041MB, free: 8192MB.
2019-01-26 recovery.log I:Data backup size is 652MB, free: 24414MB.
$
I could restore 2018-09-06 and 2019-01-26 using TWRP GUI while the other 2 failed with error=255. Of the backups I could restore with the TWRP GUI, both backups are easily < 4GB. 2019-01-10 is just below, still no idea if it is related to 4GB. In each case I formatted /data before hand, so /data/media was empty, so there was 24GB of free space, so there was always at least 2 times, sometimes 5 times, the actual space required for the recovery available.
Irrespective of the actual failure mode, I was able to restore the other backups manually.
Interestingly when I examine the .win and .win000 files with
Code:
tar tvf file | sed 5q
I find that the single .win file backups need to be restored while current directory is /data whereas the multipart backups need to be restored while current directory is /.
Manual restore process from TWRP recovery shell :
Backup everything to storage external the phone, and then backup the backup.
Wipe /data. I prefer to format /data while also wipes /data/media = /sdcard as this guarantees /data is clean, however if your backups are stored in /sdcard/TWRP then you are going to need to either not format /data or restore them from your PC, or not store them in /sdcard/TWRP and store them on an external sdcard or external USB OTG drive. Actual location may vary depending on TWRP build. Determine the b= lines below appropriately.
Connect using adb shell. You could type this in using the TWRP Advanced Terminal, but error prone.
Make sure you have enough free space on /data to do the restore. You should have, but this is the manual process so cross check.
Restore the .win0?? files with tar.
Code:
... # PS1="# " # optional
# cd /location/TWRP/BACKUPS/serialnumber/2019-01-10* # location: sdcard sdcard1 usb-otg
# pwd # verify backup directory
/location/TWRP/BACKUPS/.../2019-01-10--10-01-22_...
# b=$(pwd) # remeber backup folder location
# ls -l data.*.win000 # verify backup file exists
-rw-rw---- 1 root sdcard_rw 1109681843 2019-01-26 11:02 data.ext4.win000
# for m in data*md5; do md5sum -c $m; done # verify md5 checksums of each tar/win file.
data.ext4.win000: OK
data.ext4.win001: OK
data.ext4.win002: OK
# cd /
# for w in $b/data*win0??; do echo recover $w; tar xpvf $w > $w.rec; echo; done
recover /.../data...win000
tar: removing leading '/' from member names
recover /.../data...win001
tar: removing leading '/' from member names
recover /.../data...win002
tar: removing leading '/' from member names
# cd $b
# wc -l data*rec # verify recovery of reasonable number of files
29346 data.ext4.win000.rec
343 data.ext4.win001.rec
1831 data.ext4.win002.rec
31520 total
# df /data
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/block/dm-0 25667344 15051056 10599904 59% /data
#
Reboot
Click to expand...
Click to collapse
Did your instructions. When running the recover command, I have some errors: Cannot remove file: Is a directory / Or "File exists"
When I am finished, I run "df" and 30% of disk is used which seems ok. But when I check /sdcard folder, nothing appears there... It is like it was recovered but somewhere else.
Do you have any clue?
Sorry,
today for the first time i must restore a nandroid backup (recovery 3.2.1.2) in my xiaomi mi a1: i meet the exact error of this thread, "extractTarFork process ended with ERROR 255".
How can i restore all my backup without problem?
tnx
Hello,
I am trying to investigate the contents of the stock rom. I have downloaded the zip and extracted it, and also converted the sparse image files to nonsparse ones with simg2img. Unfortunately, I am still unable to mount the images. No matter whether I try to mount the converted image as ext2, ext4 or f2fs, I am getting the error:
mount: /mnt/temp: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error.
Click to expand...
Click to collapse
Does anybody know if/how can the oreo stock images for griffin be mounted? The issue seems to be specific to motorola or oreo as I was able to mount files from nexus 5x oreo stock images without issues. Thank you for the advice.
It turns out motorola images have 128kb header which needs to be removed before they can be mounted. Assuming dd's default block size of 512 bytes this gives the following:
Code:
$ dd if=system.raw.img of=system.raw.img.fixed skip=256
After that the images can be mounted.
? How to recover deleted files on rooted Android without USB Debug & PC connection?
Hello.
I have removed some important files in my DCIM folder on internal memory of my Android device. The USB socket of the phone is broken so I couldn't use any recovery software that using USB debug mode but I have Team Win I want to use the terminal of Team Win to make an image and copy it to SD Card of my Android device. I know that there is a command dd but how to use it in a proper way to make a full image of the partition including also free space.
Thank you very much in advance!
Yes, dd command could be used simmilar to this:
open terminal, cd to external SD folder
dd if=/dev/block/block/bootdevice/by-name/userdata of=data.img
or if you know number of partition
dd if=/dev/block/mmcblk0p18 of=data.img (p18 is on Huawei LDN, image size is that same as partition size 16GB/32GB/64GB..etc, so for bigger then 32GB need to use NTFS sdcard or exFAT sdcard and TWRP also has to support NTFS or exFAT).
Or edit etc/*.fstab and repack twrp. You can back up files from /data for now (as ext4 or f2fs). Just add line to back up full image of /data (as emmc).
If /data has ext4 filesystem it can easilly mount/unpack/scan/rip image. But if /data has f2fs ... got not cure.
Example:
/data f2fs /dev/block/bootdevice/by-name/userdata flags=length=-16384;backup=1;settingsstorage;encryptable=footer;
/data_image emmc /dev/block/mmcblk0p55 flags=display="Data Image";backup=1;flashimg;
adeii said:
Yes, dd command could be used simmilar to this:
open terminal, cd to external SD folder
dd if=/dev/block/block/bootdevice/by-name/userdata of=data.img
or if you know number of partition
dd if=/dev/block/mmcblk0p18 of=data.img (p18 is on Huawei LDN, image size is that same as partition size 16GB/32GB/64GB..etc, so for bigger then 32GB need to use NTFS sdcard or exFAT sdcard and TWRP also has to support NTFS or exFAT).
Or edit etc/*.fstab and repack twrp. You can back up files from /data for now (as ext4 or f2fs). Just add line to back up full image of /data (as emmc).
If /data has ext4 filesystem it can easilly mount/unpack/scan/rip image. But if /data has f2fs ... got not cure.
Example:
/data f2fs /dev/block/bootdevice/by-name/userdata flags=length=-16384;backup=1;settingsstorage;encryptable=footer;
/data_image emmc /dev/block/mmcblk0p55 flags=display="Data Image";backup=1;flashimg;
Click to expand...
Click to collapse
Thank you very much for you point to point reply!
Finally, I choose to use that option with some modifications because vfat doesn't support files larger than 4GB.
Code:
dd if=/dev/block/bootdevice/by-name/userdata conv=noerror,sync bs=100M | gzip -c | split -b1000000000 - mybackup.img.gz
I have mounted this *.img partition using OSFMount for Windows. But after the scanning process (I was using R-Studio that supports ext4 file system I found my deleted files in the tree structure /media/0/DCIM/Camera but all of the deleted files has 0 bytes size and have 2 flags: deleted, wiped.
I couldn't understand how that happened. I mean I didn't use my phone after deleting files at all. I also mounted this *.img as raw disk in Active Undelete but the result is actually the same all of the deleted files have 0 bytes file size.
Is that a bug of the program? Or I have made an image using wrong command? Or Android 9 actually wiping files after deletion?
The files have been accidentally deleted by AirDroid-web app but I don't think so that this app is wiping deleted files it doesn't make sense...
RaTr said:
Thank you very much for you point to point reply!
Click to expand...
Click to collapse
You are welcome. Thank you are for note about 4GB file size limit on vfat/fat32, will save us from a lot of headache.
---------- Post added at 10:03 AM ---------- Previous post was at 09:49 AM ----------
RaTr said:
actually the same all of the deleted files have 0 bytes file size.
Click to expand...
Click to collapse
Maybe to try DiskDigger on phone if it is rooted to scan internal sd?
PhotoRec for Windows/Linux: https://www.cgsecurity.org/wiki/PhotoRec_Step_By_Step
There are few programs to try on your image on GNU/Linux like extundelete, ext4magic, AnalyzeEXT, ext3grep ...
Source: https://askubuntu.com/questions/217606/undelete-files-on-ext4
I am trying to use ext4magic to recover deleted files. But I need a copy of the journal when I am trying to use command
Code:
debugfs -R "dump <8> /var/tmp/home.journal" /dev/mapper/home
I see that Team win terminal do not have this command how to add it or how to make a copy of the journal of my ext4 partition where I am trying to recover my files.
adeii said:
Maybe to try DiskDigger on phone if it is rooted to scan internal sd?
Click to expand...
Click to collapse
I have tried to use DiskDigger. When I am putting a filter to show only deleted files it doesn't show anything. Which is pretty strange.
adeii said:
There are few programs to try on your image on GNU/Linux like extundelete, ext4magic, AnalyzeEXT, ext3grep ...
Source: https://askubuntu.com/questions/217606/undelete-files-on-ext4
Click to expand...
Click to collapse
Next program that I have tried was TestDisk but looks like it doesn´t support ext4 file system.
Thank you for the advice about PhotoRec. It has support of ext4 system. But it won't help. So, there are still some options. I will try to use extundelete as the next one.
If you have an image of EXT4, then you can use 7-Zip Archiver to read all the files inside it.
jwoegerbauer said:
If you have an image of EXT4, then you can use 7-Zip Archiver to read all the files inside it.
Click to expand...
Click to collapse
7-Zip will show deleted files also?..
I have tried 2 more utilities:
1. ext4magic without external journal file. It has done the job but I couldn't find any files that I need.
2. extundelete that program restored less files and also no files that I want to recover.
One more strange thing:
I have installed R-Studio and opened my image there. I fount full list of my deleted files, but all of the records of my deleted files have 2 flags: deleted, wiped and it shows me that the size of that specific files is 0 bytes.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
I have checked other files from different dates, they can be recovered, there is no flag wiped and also I can see the size, in some of them there is a flag cross-link, but I think it is normal, that means part of that file is already overwritten by another one.
RaTr said:
I have tried 2 more utilities:
1. ext4magic without external journal file. It has done the job but I couldn't find any files that I need.
2. extundelete that program restored less files and also no files that I want to recover.
One more strange thing:
I have installed R-Studio and opened my image there. I fount full list of my deleted files, but all of the records of my deleted files have 2 flags: deleted, wiped and it shows me that the size of that specific files is 0 bytes.
I have checked other files from different dates, they can be recovered, there is no flag wiped and also I can see the size, in some of them there is a flag cross-link, but I think it is normal, that means part of that file is already overwritten by another one.
Click to expand...
Click to collapse
I am stuck in the same situation bro
See it here I described the issue very similar to yours. Any luck in trying to recover that `ext4` data
RaTr said:
I found my deleted files in the tree structure /media/0/DCIM/Camera but all of the deleted files has 0 bytes size and have 2 flags: deleted, wiped.
Click to expand...
Click to collapse
expected.
emmc/ufs flash storage is handled different from hard disk drive. there is FTL controller with own firmware that is wear-leveling whole storage all the time. not to mention files are fragmented.
file system sends TRIM on each deletion of file. note the discard mount flag for userdata partition.
Android 4.3 Update Brings TRIM to All Nexus Devices
www.anandtech.com
Hi, I tried dd command, and it returned
Code:
dd: data.img: Read-only file system
But ./adb pull /dev/block/mmcblk0p57 57.img worked, and created a NDIF image.
Why dd did not work?
And which format of image would dd create?
Thanks.
you're trying to write into phones / rootdir. you cannot dump partition into phone itself. external MicroSD card or OTG pendrive is required. but you could redirect to stdout into remote file (note the quotes make the difference where > redirection is executed)
Code:
adb root
adb shell 'dd if=/dev/block/mmcblk0p57 bs=1m status=none' > data.img
open data.img file with HxD editor and have a look into first bytes. search for magic 53 ef at offset 0x438 to confirm it's ext4 image.
dd is useful in case no usb connection available (topic of thread). the result is same as adb pull. you can increase speed with block size (bs= default 512 bytes) up to 1 MB.
Note: on FDE encrypted phone one can't pull userdata directly. instead pull whatever is mounted /data (like /dev/block/dm-0)
aIecxs said:
you're trying to write into phones / rootdir. you cannot dump partition into phone itself. external MicroSD card or OTG pendrive is required. but you could redirect to stdout into remote file (note the quotes make the difference where > redirection is executed)
Code:
adb root
adb shell 'dd if=/dev/block/mmcblk0p57 bs=1m status=none' > data.img
open data.img file with HxD editor and have a look into first bytes. search for magic 53 ef at offset 0x438 to confirm it's ext4 image.
dd is useful in case no usb connection available (topic of thread). the result is same as adb pull. you can increase speed with block size (bs= default 512 bytes) up to 1 MB.
Note: on FDE encrypted phone one can't pull userdata directly. instead pull whatever is mounted /data (like /dev/block/dm-0)
Click to expand...
Click to collapse
Thanks for your reply.
What would be the differences between
adb shell 'dd if=/dev/block/mmcblk0p57 bs=1m status=none' > data.img
and
the method described in this message: https://stackoverflow.com/a/41214172 ?
Thanks.
streaming over netcat avoids unwanted characters using stty raw. on macOS probably result is no difference (after unpacking gzip).
you don't need this as you wrote adb pull worked (which is the easiest method)
aIecxs said:
streaming over netcat avoids unwanted characters using stty raw. on macOS probably result is no difference (after unpacking gzip).
you don't need this as you wrote adb pull worked (which is the easiest method)
Click to expand...
Click to collapse
Thanks.
I searched Hex in 57dd.img created by adb shell 'dd if=/dev/block/mmcblk0p57 bs=1m status=none' > 57dd.img.
It showed
Is the 53EF on line 1080 in the image above is the one you mentioned "at offset 0x438"?
right, that is ext4 magic at offset/byte hex (0x438)16 = (1080)10 dec
I have a slightly different but related question /problem. My apologies if this is not the right place to post.
On my Samsung A10e, TWRP (and other recoveries) gives me a tarfork 255 error when trying to backup userdata. Normally this should be 32GB in size from Samsung specs.
I have used two alternatives :
* adb pull /dev/block/by-name/userdata data.img which creates a 26G file on my linux PC, that I can mount and inspect. When I run filesystem check it throws out errors, probably due to some of the data being encrypted - I am running AOSP Android 11 gsi. Perhaps the same errors that prevents TWRP from working ?
* alternatively I have put in a clean 32GB SD card, then via adb shell run dd if=/dev/block/by-name/userdata of=/dev/block/mmcblk1p1 to copy the full userdata partition over to the SD card. Once removed from the phone and put in a card reader, again this can be inspected on my linux PC, and gives the same filesystem check errors. I also ran dd if=/dev/external_sd of=data2.img on my linux PC to create a similar image file as adb pull but it is now the full 32GB that I would have intially expected.
So why the size difference between adb pull and dd ?? Does adb pull actually get everything - in other words if I try and restore with adb push will the phone recover to previous state and boot ?
I was hoping to then reduce the size of my data copy to 16GB since on my phone I am only using 12GB of the 32GB, but file errors are preventing me at the moment.
I was thinking about wiping data and then with arm32 parted and adb shell creating a 16GB userdata partition and an additional 16GB user shadow partition - the latter only to be used locally via dd to do backup and restore and avoid TWRP errors.
that is very lightly due to encryption issues....esp Magisk is known to break encryption.
if you can decrypt at TWRP level and then proceed to backup user data via ADB shell to memory card that is your best bed and then wipe the partition and then restore your app data individually for apps that you need e.g. contacts db for contact an SMS. I strongly doubt if you will be able to restore that entire partition and boot to that original partition successfully.... it may have become what what we can call "encryption tainted"
excuse my typos