I'm not an expert in the filed, it's just an analyses of the case according to my limited knowledge.
ANDROID'S ENCRYPTION
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.
POSSIBLE METHODS OF DATA RECOVERY
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.
BOOTLOADER UNLOCKING
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.
POSSIBILITY OF DATA RECOVERY
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.
CONCLUSION
Bootloader unlocked on an encrypted device, the probability of data recovery seems very near to zero.
RELATED
