2

I have nothing against root except eFUSE. Whose ever idea eFUSE was . . .

As far as I understand:
Because of amateur users and clueless minimalists who don't know how to utilise tools that are intended for power users, the development team of TWRP has controversially decided that their NANDROID backup does not include /data/media.

More information and sources in these comments:
1. Best practice for backing up /data/media?
2. Best practice for backing up /data/media?

What I want is a block-level image backup of the entire phone, so that I can return to the exact spot later on.

I want that block-level backup to include the /data/media partition.

Now, I have found out it is possible via ADB, but that requires root. If there is really no other way, I would consider taking the risk of rooting the phone after doing any other possible backup method (adb app backup, file backup, etc.)

But my question is:

Is it technically possible to do a block-level (dd) backup of the /data/media partition without root?

Had the developement team of TWRP decided to include /data/media, pleasing power users and maximalists instead of minimalists and amateur users, would it actually have been possible without root?

neverMind9
  • 778
  • 1
  • 11
  • 27
  • 1
    First of all /data/media is not /dev/media. Former is a directory of userdata partition which is mounted at /data. So in a sense you want to backup the whole block device of userdata partition. That's possible without rooting your actual OS. But you need an unlocked bootloader to boot in TWRP. From there you can dd out any block device, even the whole flash memory chip. But why do you want a block level access? A simple tar of /sdcard is sufficient in most cases. – Irfan Latif Apr 14 '19 at 08:42
  • @IrfanLatif Thank you for solving my confusion. The best thing is a block-level backup of /dev/block/mmcblk0. – neverMind9 Apr 14 '19 at 20:04
  • 1
    @IrfanLatif Block-level access means that it can be flashed back bit by bit to it's original state and the confidence that absolutely nothing is missing from the backup. – neverMind9 Apr 14 '19 at 20:05
  • 1
    The first thing to do when buying an Android device is making sure the bootloader is unlocked. I'm looking at you, Google Nexus. (their locked bootloader has been troublesome to me at some point). Samsung fortunately usually ships without crippled bootloader. – neverMind9 Apr 14 '19 at 20:25
  • 2
    Block level access is usually required when you have to deal with inodes or filesystem journal, such as to recover some deleted data or do some forensics. /sdcard (which exposes /data/media to us) is an emulated filesystem with a subset of filesystem features. E.g. you can't change permissions and SELinux context of files, those are fixed. So they even don't need to be backed up and restored. Filesystem attributes (such as immutable flag) are supported on /sdcard but can't be backed up with tar. – Irfan Latif Apr 14 '19 at 21:51
  • 2
    Extended attributes (and hence ACL's) are not supported (except security.selinux), but they don't matter a lot on Android. However if you are backing up and restoring /data/media directly (with root access), you should take care of file permissions and SELinux contexts. Tar supports backing up a lot of metadata; permissions (including owner and group), timestamps (including mtime, atime, ctime) and extended attributes (including ACLs, SELinux contexts and file capabilities). Interestingly, TWRP also creates tar backups of filesystems like /data, /system, /vendor etc. – Irfan Latif Apr 14 '19 at 21:57
  • in Open GApps a full featured gnu tar binary is included, it support --acls --xattrs --selinux flags – alecxs Apr 17 '19 at 13:35
  • Why even bother with partitions? Why not just dd the entire disk? Don't even worry about partitions, just a full backup of the underlying media and that will copy every last bit or everything. Unless there are more than one disk (chips) in the phone, that should be it. How does one do it? – Gunther Schadow Feb 24 '24 at 13:54

1 Answers1

2

Is it technically possible to do a block-level (dd) backup of a file? - Yes
Is it technically possible to do a block-level (dd) backup of a folder? - No

alecxs
  • 4,034
  • 3
  • 16
  • 34
  • /data/media is just a folder as @death-mask-salesman already stated in your linked duplicate – alecxs Apr 14 '19 at 12:05
  • 1
    Also from /dev/block/mmcblk0? – neverMind9 Apr 14 '19 at 21:24
  • 3
    @neverMind9 mmcblk0 is a block device file, which can be backed up by dding out (provided that you arrange to provide enough space for saving file). But that's unnecessary. If your device is no more bootable, you won't be able to restore that backup. So overwriting partitions related to bootloaders (like sbl, aboot etc.) and telephony (like modem) is never recommended. Normally you should backup (and restore) only filesystems (data, cache, system, vendor) and kernel (boot). But do keep backup of other partitions as well just to be on safe side. – Irfan Latif Apr 14 '19 at 23:13
  • 2
    But it is useless if device is encrypted. GNU tar is strongly recommended. at least we need a custom recovery, or rooted device for this. some stock recovery do full dd backup of whole data partition (chinese brands). some stock flash tools can make a full dump. adb backup has a -shared flag. but easiest "stock" way is just copy /storage/emulated/0 via MTP, the file permissions are not a big mystery for /data/media and can be ignored – alecxs Apr 15 '19 at 08:15
  • @alecxs MTP has been horribly unreliable and unstable in my experience, with every phone I have ever owned. – neverMind9 Apr 15 '19 at 21:09
  • @alecxs If the device is encrypted, no problem because I know my lockscreen credentials. I guess if I mount the image in Linux, the OS will ask me for it. – neverMind9 Apr 15 '19 at 21:12
  • 2
    Android encryption is hardware-bound (Arm TrustZone). userdata can only decrypted on the source phone itself. EFS (or METADATA) partition is wiped on each userdata format (thats where encrypted key is stored) - encrypted backup becomes useless – alecxs Apr 15 '19 at 23:44
  • 1
    @alecxs What a headache. – neverMind9 Apr 16 '19 at 20:37
  • @alecxs Oh wait, Apparently, Samsung's bootloaders are locked by default too and the FramaRoot/ActiveRoot/PassiveRoots thing was just an exploit. Oh well… – neverMind9 Apr 16 '19 at 21:11
  • 1
    you should read careful the whole artice http://bits-please.blogspot.com/2016/06/extracting-qualcomms-keymaster-keys.html – alecxs Apr 17 '19 at 08:45