1

I have a device running Android 9.0 Pie with a locked bootloader running unmodified stock firmware. The userdata partition on the device is currently encrypted using Full Disk Encryption (FDE) with the default password (I have not used the option to encrypt the device with a lock screen password.)

There exists a loophole in this firmware which allows me to create images of entire partitions of the device (by copying a block device from /dev/block/bootdevice/by-name/) and save them on a PC. I have tested this on the cache partition and I was able to successfully mount and browse the copied image as an ext4 partition under Linux.
Note: I don't have root access on the running system, so I cannot directly access decrypted files under /data, so this method is out of question.

Now, I wish to unlock the bootloader which will wipe the userdata partition and reset the device.

Which all partitions should be backed-up before unlocking the bootloader and restored after the unlock, so that the device will be able to successfully decrypt the userdata partition and boot normally (or at least a custom recovery like TWRP will be able to decrypt the partition) ?

The Android Source documentation for FDE states that the key is stored in the Crypto metadata, which is located either inside the userdata partition itself or in a separate metadata partition.
Here is a list of partitions present on the device :-

ImageFv -> /dev/block/sdf4
abl_a -> /dev/block/sde32
abl_b -> /dev/block/sde33
aop_a -> /dev/block/sde14
aop_b -> /dev/block/sde15
apdp -> /dev/block/sde6
bk01 -> /dev/block/sda3
bk02 -> /dev/block/sda4
bk03 -> /dev/block/sda5
bk04 -> /dev/block/sda8
bk05 -> /dev/block/sda13
bk31 -> /dev/block/sdd1
bk32 -> /dev/block/sdd3
bk33 -> /dev/block/sdd5
bk41 -> /dev/block/sde3
bk42 -> /dev/block/sde9
bk43 -> /dev/block/sde16
bk44 -> /dev/block/sde17
bk45 -> /dev/block/sde25
bk46 -> /dev/block/sde29
bk47 -> /dev/block/sde38
bk48 -> /dev/block/sde40
bk49 -> /dev/block/sde41
bk51 -> /dev/block/sdf2
bk52 -> /dev/block/sdf3
bk53 -> /dev/block/sdf5
bluetooth -> /dev/block/sde24
boot -> /dev/block/sde45
cache -> /dev/block/sda20
cdt -> /dev/block/sdd2
cmnlib64_a -> /dev/block/sde20
cmnlib64_b -> /dev/block/sde21
cmnlib_a -> /dev/block/sde18
cmnlib_b -> /dev/block/sde19
cust -> /dev/block/sda18
ddr -> /dev/block/sdd4
devcfg_a -> /dev/block/sde12
devcfg_b -> /dev/block/sde13
devinfo -> /dev/block/sda12
dip -> /dev/block/sde28
dsp -> /dev/block/sde44
dtbo -> /dev/block/sde37
frp -> /dev/block/sda7
fsc -> /dev/block/sdf1
fsg -> /dev/block/sde36
hyp_a -> /dev/block/sde26
hyp_b -> /dev/block/sde27
keymaster_a -> /dev/block/sde22
keymaster_b -> /dev/block/sde23
keystore -> /dev/block/sda6
limits -> /dev/block/sde2
logdump -> /dev/block/sda16
logfs -> /dev/block/sda10
logo -> /dev/block/sde43
minidump -> /dev/block/sda17
misc -> /dev/block/sda9
modem -> /dev/block/sde46
modemst1 -> /dev/block/sdf6
modemst2 -> /dev/block/sdf7
msadp -> /dev/block/sde7
oops -> /dev/block/sda11
persist -> /dev/block/sda14
persistbak -> /dev/block/sda15
qupfw_a -> /dev/block/sde4
qupfw_b -> /dev/block/sde5
recovery -> /dev/block/sda19
sec -> /dev/block/sde1
splash -> /dev/block/sde42
spunvm -> /dev/block/sde39
ssd -> /dev/block/sda2
sti -> /dev/block/sde30
storsec_a -> /dev/block/sde10
storsec_b -> /dev/block/sde11
switch -> /dev/block/sda1
system -> /dev/block/sde48
toolsfv -> /dev/block/sde31
tz_a -> /dev/block/sde34
tz_b -> /dev/block/sde35
userdata -> /dev/block/sda21
vbmeta -> /dev/block/sde8
vendor -> /dev/block/sde47
xbl_a -> /dev/block/sdb2
xbl_b -> /dev/block/sdc2
xbl_config_a -> /dev/block/sdb1
xbl_config_b -> /dev/block/sdc1

Note that the metadata partition is not present.

------------------------- UPDATE -------------------------

(based on the comments by @alecxs)

FSTAB entry

I extracted the fstab.qcom file from the device firmware image (/vendor/etc/fstab.qcom) and here is the relevant line (the full fstab is here) -

/dev/block/bootdevice/by-name/userdata /data ext4 noatime,nosuid,nodev,barrier=1,noauto_da_alloc wait,check,reservedsize=128M,forceencrypt=footer,quota

android_bruteforce_stdcrypto

I ran the python script from Santoku's repository on the header (first 512 bytes) and footer (last 16KB) extracted from the userdata image, and got this output (private data is concealed) -

Android FDE crypto footer
-------------------------
Magic          : 0xXXXXXXXX
Major Version  : 1
Minor Version  : 3
Footer Size    : 2352 bytes
Flags          : 0x00001000
Key Size       : 128 bits
Failed Decrypts: 0
Crypto Type    : aes-xts
Encrypted Key  : 0xXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Salt           : 0xXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
KDF            : scrypt
N_factor       : 15     (N=32768)
r_factor       : 3      (r=8)
p_factor       : 1      (p=2)
-------------------------

So, now that I have enough evidence about all the encryption data being present in the userdata partition itself, I am going to proceed by backing up and restoring only the userdata partition after the bootloader unlock.

I will update this with an answer containing my results after unlocking.

ManSamVampire
  • 417
  • 3
  • 9
  • 1
    if flag in fstab is forceencrypt=footer then it is last -16384 bytes of userdata, otherwise there is path to file or partition. to double check you can run bruteforce_stdcrypto.py, it is impossible to decrypt but it will reveal Android FDE crypto footer is valid – alecxs Apr 07 '20 at 21:28
  • Hello @alecxs and thank you for responding. Please have a look at the updated question. Unfortunately, I won't be able to try the patched-image injection that you suggested. I have read online that the EDL mode on my device model is protected by some proprietary manufacturer authorisation. Moreover, to start EDL mode, I will have to dismantle the device (which I am not willing to do at least currently). – ManSamVampire Apr 08 '20 at 13:02

0 Answers0