Droidcedas : Decrypting Android 1000 Adopted Storage

Oleh Didiet86

Thursday, July 26, 2018

Bagikan :

Tweet

One of the novel features Android thou introduces is AppsOnSD. There are, of course, a few differences, the major i beingness that piece AppsOnSD (just similar app Android 4.1 app encryption) creates per-app encrypted containers, adoptable storage encrypts the whole device. This brusque post service volition await at how adoptable storage encryption is implemented, in addition to demonstrate how to decrypt in addition to utilisation adopted drives on whatever Linux machine.

Adopting an USB drive

In gild to enable adoptable storage for devices connected via USB you lot ask to execute the next ascendancy inwards the Android crunch (presumably, this is non needed if your device has an internal SD card slot; all the same at that topographic point are no such devices that run Android thou at present):

$ adb crunch sm set-force-adoptable truthful 

Now, if you lot connect a USB campaign to the device's micro USB slot (you tin also utilisation an USB OTG cable), Android volition compass you lot an selection to laid it upwardly every bit 'internal' storage, which requires reformatting in addition to encryption. 'Portable' storage is formatted using VFAT, every bit before.

After the campaign is formatted, it shows upwardly nether Device storage inwards the Storage shroud of organisation Settings. You tin right away migrate media in addition to application information to the newly added drive, but it appears that at that topographic point is no selection inwards the organisation UI that allows you lot to movement applications (APKs).

Adopted devices are mounted via Linux's device-mapper nether /mnt/expand/ every bit tin hold upwardly seen below, in addition to tin hold upwardly conduct accessed solely yesteryear organisation apps.

$ mountain rootfs / rootfs ro,seclabel,relatime 0 0 ... /dev/block/dm-1 /mnt/expand/a16653c3-... ext4 rw,dirsync,seclabel,nosuid,nodev,noatime 0 0 /dev/block/dm-2 /mnt/expand/0fd7f1a0-... ext4 rw,dirsync,seclabel,nosuid,nodev,noatime 0 0 

You tin safely eject an adopted campaign yesteryear tapping on it inwards the Storage screen, in addition to the choosing Eject from the overflow menu. Android volition demonstrate a persistent notification that prompts you lot to reinsert the device i time it's removed. Alternatively, you lot also tin 'forget' the drive, which removes it from the system, in addition to should presumably delete the associated encryption telephone commutation (which doesn't seem to hold upwardly the illustration inwards the electrical flow preview build).

Inspecting the drive

Once you've ejected the drive, you lot tin connect it to whatever Linux box inwards gild to inspect it. Somewhat surprisingly, the campaign volition hold upwardly automatically mounted on virtually modern Linux distributions, which suggests that at that topographic point is at to the lowest degree i readable partition. If you lot await at the division tabular array amongst fdisk or a similar tool, you lot may run into something similar this:

# fdisk /dev/sdb Disk /dev/sdb: 7811 MB, 7811891200 bytes, 15257600 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk label type: gpt    #        Start          End    Size  Type            Name  1         2048        34815     16M  unknown         android_meta  ii        34816     15257566    7.3G  unknown         android_expand 

As you lot tin see, at that topographic point is a tiny android_meta partition, but the mass of the device has been assigned to the android_expand partition. Unfortunately, the total source code of Android thou is non available, in addition to then nosotros cannot hold upwardly certain how precisely this division tabular array is created, or what the contents of each division is. However, nosotros know that virtually of Android's storage administration functionality is implemented inwards the vold organisation daemon, in addition to then nosotros banking corporation check if at that topographic point is whatever cite of android_expand within vold amongst the next command:

$ strings vold|grep -i expand --change-name=0:android_expand %s/expand_%s.key /mnt/expand/%s 

Here expand_%s.key suspiciously looks similar a telephone commutation filename template, in addition to nosotros already know that adopted drives are encrypted, in addition to then our adjacent pace is to await for whatever similar files inwards the device's /data division (you'll ask a custom recovery or rootage access for this). Unsurprisingly, at that topographic point is a matching file inwards /data/misc/vold which looks similar this:

# ls /data/misc/vold bench expand_8838e738a18746b6e435bb0d04c15ccd.key  # ls -l expand_8838e738a18746b6e435bb0d04c15ccd.key  -rw-------  1 rootage root xvi  expand_8838e738a18746b6e435bb0d04c15ccd.key   # od -t x1 expand_8838e738a18746b6e435bb0d04c15ccd.key 0000000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 0000020 

Decrypting the drive

That's precisely xvi bytes, plenty for a 128-bit key. As nosotros know, Android's FDE implementation uses an AES 128-bit key, in addition to then it's a practiced bet that adoptable storage uses a similar (or identical) implementation. Looking at the start in addition to halt of our android_expand division doesn't disclose whatever readable info, nor is it similar to Android's crypto footer, or LUKS's header. Therefore, nosotros ask to approximate the encryption trend and/or whatever related parameters. Looking i time once again at Android's FDE implementation (which is based on the dm-crypt target of Linux's device-mapper), nosotros run into that the encryption trend used is aes-cbc-essiv:sha256. After consulting dm-crypt's mapping table reference, nosotros run into that the remaining parameters nosotros ask are the IV offset in addition to the starting offset of encrypted data. Since the IV offset is ordinarily zero, in addition to virtually in all probability the entire android_expand division (offset 0) is encrypted, the ascendancy nosotros ask to map the encrypted division becomes the following:

# dmsetup do crypt1 --table "0 `blockdev --getsize /dev/sdb2` crypt \ aes-cbc-essiv:sha256 00010203040506070809010a0b0c0d0e0f 0 /dev/sdb2 0" 

It completes amongst error, in addition to then nosotros tin right away endeavour to mountain the mapped device, i time again guessing that the file organisation is virtually in all probability ext4 (or you lot tin inspect the mapped device in addition to discovery the superblock first, if you lot desire to hold upwardly extra diligent).

# mountain -t ext4 /dev/mapper/crypt1 /mnt/1/ # cd /mnt/1 # discovery ./ -type d ./ ./lost+found ./app ./user ./media ./local ./local/tmp ./misc ./misc/vold ./misc/vold/bench 

This reveals a real familiar Android /data layout, in addition to you lot should run into whatever media in addition to app information you've moved to the adopted device. If you lot re-create whatever files to the mounted device, they should hold upwardly visible when you lot mountain the campaign i time again inwards Android.

Storage managing director commands

Back inwards Android, you lot tin utilisation the sm ascendancy (probably brusque for 'storage manager') nosotros showed inwards the outset department to listing disks in addition to volumes every bit shown below:

$ sm list-disks disk:8,16 disk:8,0  $ sm list-volumes emulated:8,2 unmounted naught mortal mounted naught private:8,18 mounted 0fd7f1a0-2d27-48f9-8702-a484cb894a92 emulated:8,18 mounted naught emulated unmounted naught private:8,2 mounted a16653c3-6f5e-455c-bb03-70c8a74b109e 

If you lot accept rootage access, you lot tin also partition, format, mount, unmount in addition to forget disks/volumes. The total listing of supported commands is shown inwards the next listing.

$ sm usage: sm list-disks        sm list-volumes [public|private|emulated|all]        sm has-adoptable        sm get-primary-storage-uuid        sm set-force-adoptable [true|false]         sm division DISK [public|private|mixed] [ratio]        sm mountain VOLUME        sm unmount VOLUME        sm format VOLUME         sm forget [UUID|all] 

Most features are also available from the organisation UI, but sm allows you lot to customize the ratio of the android_meta in addition to android_expand partitions, every bit good every bit to do 'mixed' volumes.

Summary

Android thou allows for adoptable storage, which is implemented similarly to internal storage FDE -- using dm-crypt amongst a per-volume, static 128-bit AES key, stored inwards /data/misc/vold/. Once the telephone commutation is extracted from the device, adopted storage tin hold upwardly mounted in addition to read/written on whatever Linux machine. Adoptable storage encryption is done purely inwards software (at to the lowest degree inwards the electrical flow preview build), in addition to then its functioning is probable comparable to encrypted internal storage on devices that don't back upwardly hardware-accelerated FDE.

Tag : android security