We climb into the internal storage of Android M

Android 6.0 introduced a feature that allows you to format the memory card so that it is not a separate storage, but an appendage to the internal memory. This avoids confusion with the two data storages, especially when manually installing some not always honestly purchased large applications delivered in parts. However, there is one caveat: while all of us tightly block access to the card directly. If you want to transfer something to the device, use MTP with all the consequences, such as a file transfer speed comparable to the walking step of a contused turtle. Now the card can not be directly connected to a PC via a cable: you cannot just mount it from a switched off phone through a card reader, because it is formatted into something unknown neither to science nor to our computers.

But the rules are created to break them? Let's try to get around this shameless limitation.

Method one, simple: adb push / pull

Recommended for daily use. Apparently, does not even require a root. All you need is ADB. Those who are aware, can scroll through to the second method.

With the transfer, everything is simple: the first argument is from where, the second argument is where. / sdcard is the place where the user-accessible storage is mounted on Android, i.e. The root directory of the staff file manager of almost any device on Android.

$ adb push chunk.bin /sdcard chunk.bin: 1 file pushed. 4.8 MB/s (44040192 bytes in 8.667s) 

Receiving is similar:

 $ adb pull /sdcard/chunk.bin chunk2.bin /sdcard/chunk.bin: 1 file pulled. 16.0 MB/s (44040192 bytes in 2.627s) $ cmp chunk.bin chunk2.bin 

The main advantage is the two-way data exchange at a quite satisfactory speed (when compared with MTP). Also, a nice progress percentage is attached to all this beauty, which, unfortunately, is not visible from here. I suppose that you can somehow attach something similar to the graphical file manager, but in practice you have never had to deal with such plugins. Perhaps, Android is still not in vain to let the map to us, but oh well, who asks him?

Method two, interesting: manual mounting of encrypted partitions

This time we need root access to a smartphone and a PC with a Linux-based system.

To begin, pull the card out of the device, connect it to the PC and immediately look at its contents.

 $ parted /dev/mmcblk0 print Model: SD SD32G (sd/mmc) Disk /dev/mmcblk0: 31.2GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 1049kB 17.8MB 16.8MB fat32 android_meta 2 17.8MB 31.2GB 31.2GB android_expand 

Well, at least there is a partition table.

With the naked eye it is clear that the filet portion is the second partition with the unidentified file system. The first section is perfectly mounted in fat32 and is equally beautifully empty, so you can forget about it, because I do not know what is stored on it in healthy people.

The second part of the sinister plan is the key. Yes, yes, the data is encrypted: well, not just so parted could not be detected on the target file system partition. The key is almost as simple: it is stored on our Android device in a binary file at /data/misc/vold/expand_PARTUUID.key, where PARTUUID is the UUID of the encrypted partition in lower case without separators. We will need Ruth just to get to this file through unreadable for everyone except the root, the / data / misc / vold directory.

 $ partuuid=$(lsblk /dev/mmcblk0p2 -o PARTUUID | tail -1 | tr -d '-') $ adb root $ adb pull /data/misc/vold/expand_$partuuid.key magic.key /data/misc/vold/expand_9d292da2b76a9179118aaa217f23e4a7.key: 1 file pulled. 0.0 MB/s (16 bytes in 0.110s) 

Is done. 128 bits of treasured information.

The final part of the Merleson Ballet is the connection of the section. Let's make it the standard Linux dm-crypt, which, in fact, is used by Android itself.

Unfortunately, I don’t know what kind of encryption method Android is using, so I’ll hope for the holy default, leaving --cipher unspecified.

 $ cryptsetup open --type plain --key-file=magic.key --key-size=128 /dev/mmcblk0p2 dm-magic 

I do not swear, it's good. Mounted.

 $ mount /dev/mapper/dm-magic /mnt $ ls -l /mnt total 21 drwxrwx--x 33 alpha alpha 3488 Mar 16 08:51 app drwxr-x--x 3 root root 3488 Nov 29 00:34 local drwxrwx--- 4 1023 1023 3488 Nov 29 08:01 media drwxrwx--t 3 alpha 9998 3488 Nov 30 03:02 misc drwx--x--x 3 alpha alpha 3488 Nov 29 00:34 user drwx--x--x 3 alpha alpha 3488 Nov 29 00:34 user_de 

It seems to work out. Unidentified UIDs remind us that the card is not from our PC and it would be better for us not to stir up anything special here.

If you dig through the directories, you can see the data of applications stored on the memory card, as well as directly the contents of the SD card, which we slipped in the first method to the / sdcard address. We can find it in the / mnt / media / 0 directory.

That's all, pleasant picking.