To make a long story short I needed to root my phone and didn't notice the warning that unlocking the bootloader erased all contents of the memory.

I contacted a data recovery company and told them that the memory was encrypted and the phone used Android 6. In response I was told that there was a chance, albeit small, that they could recover some data. However, they were unsuccessful and in their report they blamed the encryption.

This made me pretty upset since the encryption was the first thing I mentioned in my contact with them. When I called and complained about this I got the very "interesting" answer: sometimes there is a glitch when enabling encryption leaving some of the storage unencrypted and we might be able to recover that.

Is this really true??? It sounds completely absurd that something like that could happen frequent enough so they could base their business model on it. In my ears it sounds like a bad excuse for charging me money for something that could "never" work.

  • 1
    An Android 6 the encryption was AFAIR not enabled by default. Considering a large storage and an encryption algorithm that only encrypts the data but leaves the rest untouched there is a chance of being able to recover something, if the encrypted time is not too long. Also how you use the phone can change the recovery rate. Also on some older devices factory reset and re-encryption had flaws not erasing everything. Anyway they told you that the chance was low - and their business model is not "recovering data" but "searching for recoverable data".
    – Robert
    Commented Aug 19, 2019 at 18:50
  • 1
    i don't believe that data is recoverable from encrypted partition when keys are wiped, and android 6 uses FDE full disk encryption, so a partially unencrypted partition won't be mountable. maybe he was talking about the (unencrypted) encryption footer at end of partition, with this it would be possible to decrypt. Besides this, they spend time in trying to recover, you must pay for the try
    – alecxs
    Commented Aug 19, 2019 at 22:30

1 Answer 1


I'm not an expert in the filed, it's just an analyses of the case according to my limited knowledge.


Android supports two modes of encryption; FDE and FBE. FDE encrypts whole block device i.e. userdata partition using Linux kernel's dm-crypt framework, while FBE is based on fscrypt available since Android 7. From data recovery's aspect, approach is similar for both. Both offer strong encryption and what's been attacked by hackers is not the encryption itself, but Android's mechanism to create and store keys required for decryption.

sometimes there is a glitch when enabling encryption leaving some of the storage unencrypted

You are right, it's interesting. FDE, AFAIK, encrypts the whole block device, just excluding the crypto footer at the end of partition which includes keys for decryption. Initially all sectors might not be encrypted as is the case with inplace encryption:

vold checks to see if a sector is in use before reading and writing it, which makes encryption much faster on a new device that has little to no data.

But the skipped sectors are the ones which contain no data in filesystem. However as data is written to the sectors (or if the encryption was initialized with random data which doesn't seem to be the case with Android), they get encrypted and very soon whole block device becomes one giant high entropy block of data with no visible structure. It's impossible to distinguish encrypted data from random noise. TRIM, however, if supported by hardware, kernel, filesystem and the OS, may reveal the empty space in filesystem. But reading from that space only returns zeros.


Data recovery works in two ways generally:

  • Read just the file contents by carving method / signature search
  • Or read the complete files along with metadata (file names, timestamps, permissions) from filesystem

Possible methods are:

  • Reading flash memory through firmware controller (Flash Translation Layer) of eMMC using commonly available APIs e.g. of Liux kernel. It's the FTL which stores LBAs to PBAs mapping, and information related to partitions, bad sectors, deleted data etc. This can be done by exposing partitions to a PC in some bootloader mode if available, or by using some lower level communication protocol e.g. JTAG or by chip-off method.
  • Or accessing silicon cells directly which is possible only with sophisticated equipment found in forensic labs, and not without manufacturer’s data sheet. In this case only carving method is possible. Data read from cells is random bytes from un-partitioned space and all 50+ partitions, including the ones which don't have filesystems at all. So the probability of recovering useful data is almost negligible, particularly of reasonably larger files. If the data saved is encrypted (using FDE, FBE or any other method), chances with this method are nil for sure.

The choice of method depends on multiple factors like if the purpose is:

  • To recover deleted data
  • To recover data off a dead phone
  • To break the encryption mechanism, e.g. in case of forensics, phone theft etc.

Data recovery can be done either:

  • On the device e.g. in recovery mode if the device is unlocked and some custom recovery environment is available.
  • Or off the device. It's the only option in most cases as the devices have bootloaders locked. But if your device was shipped with Android 5+, the chances are it must have hardware-backed encryption enabled which makes it almost impossible to recover - even undeleted - data off-the-device, except trying some hacks, because you can't brute force RSA keys.


Keeping all above facts and you situation in view, only an on-the-device or semi-offline approach can be tried to recover data. But then comes the bootloader unlocking part.

Google demands from SoC/OEM vendors to completely erase data on bootloader unlocking:

As a best practice, unlockable Android devices must securely erase all user data prior to being unlocked.
Failure to implement these protections is considered a moderate level security vulnerability.

Quoted from here:

When the fastboot flashing unlock command is sent...
a factory data reset should be done to prevent unauthorized data access

Depending on the device a BLKSECDISCARD, BLKDISCARD or a complete overwrite with zeros is recommended. It's then followed by filesystem creation which may again issue TRIM. Same happens during a factory reset i.e. userdata and cache partitions are completely erased (though conformance in past has been bad). See this answer for more details.

BLKDISCARD and FITRIM are Linux kernel's IOCTLs which issue special commands to underlying eMMC devices depending on their capabilities. TRIM is issued by the filesystem to the FTL, requesting the actual physical erasure of data blocks (LBAs) which have been deleted from the filesystem. DISCARD is kind of TRIM for whole block device. TRIM obviously doesn't touch undeleted files, filesystem structure and drive's partition table. BLKDISCARD saves nothing at all on block device, including the crypto footer. Both of these commands belong to Logical Sanitization level of secure data deletion. So is ERASE command issued by BLKSECDISCARD IOCTL, while others issued by the same - including SECURE TRIM, SECURE ERASE and SANITIZE - are considered of Digital Sanitization level i.e. they cause even more secure deletion. Even a complete overwrite with zeros will render data irrecoverable - at least without melting eMMC - because of Overprovisioning and Garbage Collection.


So in short these commands (if supported by underlying hardware and if required drivers provided by vendors) don't leave much space for deleted data recovery. Encryption adds to the trouble. As explained above, encryption type with FDE is, a kind of, all or nothing. If even a small part of crypto footer is erased during bootloader unlocking, forget about decryption. Quoted from a lead engineer for Android security (ref):

If you plan to resell or discard your device and you haven’t already, encrypt it and then perform a factory reset

And so does the removal of LUKS header on Linux. Quoted from warnings section on official page:

By far the most questions on the cryptsetup mailing list are from people that managed to damage the start of their LUKS partitions, i.e. the LUKS header. In most cases, there is nothing that can be done to help these poor souls recover their data.

So without the crypto footer which contains encrypted master key, RSA key (hardware-bound) and other information related to encryption, everything is random data. But even if we assume that crypto footer wasn't erased in your case and hardware-backed encryption wasn't a hurdle either, the problems aren't over. With dm-crypt FDE a master key is used to encrypt / decrypt sectors (512B each) individually when they are written / read respectively (every sector has it's own IV). After decrypting userdata partiton a new virtual block device is created at /dev/block/dm-0 which contains a filesystem, mostly ext4.

In order to mount the filesystem, the sectors containing basic structure of filesystem must be intact e.g. superblock(s), directory entries, inode tables, inode/block bitmaps, journal etc. It's next to impossible that all of this wasn't overwritten when unlocking bootloader and creating new filesystem. So the old filesystem is gone and what you would be left with is carving method which has a very small success rate particularly because of file fragmentation of large files. Mostly what you get is small nameless thumbnails or text files, that too after so many assumptions.


Bootloader unlocked on an encrypted device, the probability of data recovery seems very near to zero.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .