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.
Hello, all.
I have a Moto E with a 32GB External Memory card.
I've formatted the card to have a 12G FAT32 partition for the phone to use as intended, and the other 20GB I've formatted into a EXT4 filesystem that I plan to use for various stuff.
I can mount and write to the partition without any problem:
Code:
mount -t ext4 -o rw /dev/block/mmcblk1p2 /sdcard/sdext4/
The issue lies in that I have no idea where I should place this so that it automatically does it on boot (I cannot find any init.d directory, for example).
Could someone let me know what scripts are read at boot and where the best location for putting said command would be?
----
EDIT: Come to think of it, I'll need it for the following command so I can rsync as well without a hassle:
Code:
ln -s /data/data/eu.kowalczuk.rsync4android/files/rsync rsync
Hi, I'd like to ask a general question about device boot. I'd like to mount /system, /data, and /cache partitions in selected locations based on detection of sdcard in the device.
How could I add an if ... then ... else statement to init.rc before that /system, /data, and /cache partitions are mounted? Any ideas?
Solved
I've found a way to perform this task. It's possible to place if ... then ... else statement into a shell script and put the shell script into ramdisk root directory of boot.img. Then, just run the script by busybox ash command from init.rc (with busybox located into ramdisk root directory).
cristian_c said:
I've found a way to perform this task. It's possible to place if ... then ... else statement into a shell script and put the shell script into ramdisk root directory of boot.img. Then, just run the script by busybox ash command from init.rc (with busybox located into ramdisk root directory).
Click to expand...
Click to collapse
Hey... I managed to mount /dev/block/mmcblk1p2 as my /data partition by editing my boot.img ramdisk(the 3. fstab files and the .rc files... i replaced [email protected] with dev/block/mmcblk1p2 wherever i saw them)
So i was trying to use an if statement in some of the .rc files to check if /dev/block/mmcblk1p2 was mounted on /data and if not then mount /dev/block/mmcblk0p9 (my usrdata partition) on /data... Soon i realised that this isn't exactly bash...
Please explain how you managed to get a .sh to run from your .rc files( or do you only need it in the init.rc, and remove all the /data mounting lines from them and do it all from the script???)
I don't always have access to a pc so if my sdcard somehow dies i want my phone to boot using the internal /data partition otherwise i will bootloop until i flash the original boot.img
nullbyte001 said:
Hey... I managed to mount /dev/block/mmcblk1p2 as my /data partition by editing my boot.img ramdisk(the 3. fstab files and the .rc files... i replaced [email protected] with dev/block/mmcblk1p2 wherever i saw them)
So i was trying to use an if statement in some of the .rc files to check if /dev/block/mmcblk1p2 was mounted on /data and if not then mount /dev/block/mmcblk0p9 (my usrdata partition) on /data... Soon i realised that this isn't exactly bash...
Please explain how you managed to get a .sh to run from your .rc files( or do you only need it in the init.rc, and remove all the /data mounting lines from them and do it all from the script???)
I don't always have access to a pc so if my sdcard somehow dies i want my phone to boot using the internal /data partition otherwise i will bootloop until i flash the original boot.img
Click to expand...
Click to collapse
I've found on fs_property:ro.mount.fs=EXT4 in init.rc. In that section, I've added the following iine:
Code:
exec /busybox ash /mount_partitions.sh
[of course, I've placed busybox arm compiled binary (the version provided by busybox android app should work) and a mount_partitions.sh script (created by myself) into boot image ramdisk (I mean / main directory, the same where init.rc is located) ]
You could also need to give permissions to busybox and to .sh script. You could also need to remount / in read-write mode, in case of issues with the above command.
Hello
I am working with a Nanopi Fire3 board. I need to change the boot logo and boot animation.
With this Android Lollipop :
112.124.9.243/dvdfiles/S5P6818/images-for-eflasher/android-lollipop-images.tgz
Click to expand...
Click to collapse
If I unpack with the following method, the new image has a completely different size and does not boot.
Code:
apt install android-tools-fsutils
simg2img rootfs.img r.img
mount -t ext4 -o loop r.img /mnt
… To Change Something …
umount /mnt
img2simg r.img rootfs.img
I have tried to root the device, no tool found online works.
I have tried to unpack/repack, no tool found online works.
Tools like mkbootimg just copies the img file (it doesn't extract anything)
I am also trying to compile android completely, and it fails in the middle of the build process.
Would you have any advice please? I have run out of options
Thank you :good:
Hey everyone,
I have pulled a block of encrypted userdata partition ".img" and trying to mount it on unecnrypted device (same device with encryption set to off). My device is rooted
I have tried these steps
1. Pulled the block on local system using adb pull - userdata_block.img
2. mounted the block on an unencrypted device over CIFS using busybox mount command - userdata_block is virtually present on /sdcard/temp/userdata_block.img
3. Want to mount this img file on device to check the directory status on Android 11 if all the directories are encrypted or not.
/system/bin/losetup /dev/block/loop2 /sdcard/temp/userdata_block.img
/system/bin/mount -o ro /dev/block/loop2 /sdcard/dummy
Getting below error on Android 11, same command works fine on Android 10.
mount: /dev/block/loop2: need -t
Does anyone has any idea how to fix this?