How to make a complete factory reset, without anyone being able to retrieve my data?

Question

I will have a few Android phones that I will have to let go.

I would like to make a proper clean wipe of the data, without no one being able to retrieve them, and do a factory reset.

I have read about the Schneier Method, encrypting the device before doing a factory reset, doing both, etc.

Since I am not an Android/adb guru, I would like to know if some of you would have some idea on how to achieve this with certainty.

I know "certainty" is a big word when it comes to proper data erasure on flash memory but still.

I have found some answers here and somewhere else, saying that encrypting and doing a factory reset on your Android device is enough, but I could not find a reliable source.

Just a few information that could be useful:

• I'm running Linux as my OS and, therefore, I'm not looking for a Windows-based solution
• My devices are non-rooted and (almost) identical (Samsung A510F + 1 A510FD)

Answer 1

HOW DELETED DATA IS RECOVERED?

Data (un)deletion strongly depends on how a storage media (HDD, SSD, eMMC etc.), filesystem (NTFS, FAT32, ext4 etc.) and OS save and delete files.

• File carving / signature search / content-aware recovery identifies standard signatures values in the headers of deleted files (as file command and antivirus programs do to identify known viruses hiding in files) e.g. JPEG files start with 0xffd8 and end with 0xffd9. The data in between blocks is assumed to be the file (considering the file is contiguous; no fragmentation). Other checks may also be performed on header like a checksum, the file’s length, or date/time etc. But not all file types have a standard header/footer signature, so determining where the file starts/ends is difficult. Metadata (including filenames) isn't recovered with this method.

  This approach works for deleted files, filesystems or partitions. Photorec, scalpel, foremost and popular Android app DiskDigger (in dig deeper mode) work on this approach.

• Recovering as much as possible information about deleted data blocks from within filesystem e.g. from directory entries, journal, inodes etc. Filesystem is basically the catalog which holds file name vs. file location information and journal is a kind of backup information. So recovery of filenames (and other metadata) is more probable with journaling filesystems.

  This approach works only if filesystem and partition are intact, or are recoverable using first method. DiskDigger (in dig deep mode) and extundelete work on this approach.

---

WHAT MAKES RECOVERY OF DELETED DATA DIFFICULT / IMPOSSIBLE?

• A file/directory is simply deleted e.g. from some File Explorer app or with rm from commadline.
• A file is renamed to some random string, then deleted.
• Filesystem on the device is not journaling, so no information can be collected from journal. Ext4, the commonly used filesystem on Android, is journaling.

• Filesystem on the device is a Flash Filesystem e.g. F2FS.

  In this case you are left with minimum tools (e.g. no debugfs to list deleted inodes and to lookup corresponding data blocks from journal) and also data is always written to new blocks as a wear-leveling strategy. Garbage Collection makes recovery less probable from filesystem because Logical Block Addresses (LBAs) of data blocks get changed. So only carving method is applicable, and it works.

• Filesystem or partition is deleted, making it harder to search directory structures and journal from within filesystem. Android's stock recovery deletes filesystem during a Factory Reset. See this answer.
• Whole disk is erased including Partition Table, boundaries of partitions and filesystems are vanished. This isn't possible on Android devices because there are partitions required to boot the device.

• File was fragmented (not saved contiguously as a single piece), particularly if no information can be recovered from filesystem.

  Fragmentation is higher on Windows as compared to Linux/Android; Ext4 is self de-fragmenting because of Delayed Allocation and reserved-blocks-percentage etc. But usually large files on an older filesystem are always fragmented.

• You overwrite file/filesystem/partition with other file/filesystem/partition, or zeros, or random data (shredding).

  If you have root access, throw a stream of /dev/urandom on block device to overwrite all data including filesystem. Now forget about its recovery, though it doesn't nullify the possibility of data recovery directly from flash storage (raw NAND), by chipping it off the board (who will do this except in forensic lab!). Official tool from SD organization: SD Memory Card Formatter also overwrites with zeros in full format mode. Please note that repeated overwriting wastes precious E/P cycles of flash memory.

• Filesystem is TRIMmed or SECURE TRIMmed, or ERASEd or SECURE ERASEd.

  These are special commands for different types of flash storage devices. TRIM is issued by the filesystem to the firmware of flash device, requesting the actual physical erasure of data blocks (LBAs) which have been deleted from the filesystem. Filesystems mounted with discard option always send FITRIM ioctl whenever a file is deleted. Android does a scheduled TRIM, or you can do manually with fstrim command. See this answer.

• Partition is BLKDISCARDed or BLKSECDISCARDed.

  blkdiscard issues TRIM command for whole block device i.e. partition or disk (roughly equivalent to issuing TRIM on a newly created filesystem).
  TRIM saves filesystem's superblocks/inode table and drive's partition table, BLKDISCARD saves nothing on block device.

  Android's stock recovery tries to do at least one of the both during a Factory Reset. See this answer.
  Something similar happens with bootloader unlock and fastboot erase, though it depends on implementation inside bootloader but that's what Google expects from OEM/SoC vendors.

• Deleted file is encrypted or file doesn't have an identifiable unique signature (at start or end), so no carving is possible.

  Like an encrypted archive or file that mostly file explorers can create. Or a file with some uncommon format, not known to recovery programs.

• Filesystem or block device is encrypted so the data becomes unrecognizable (like FBE/FDE on Android). Mostly new devices come with forceencrypt or fileencryption flags set in fstab, so vold encrypts them on first usage. If not decryptable (e.g. formatted), data is impossible to be recovered on such devices.
• Flash storage device is self-encrypting, common for SSDs but not for eMMCs.
• Flash storage device is erased with SECURITY_ERASE or ENHANCED_SECURITY_ERASE ATA commands, common for SSDs but not for eMMCs.

• Storage device isn't accessible e.g. on embedded system if bootloader is erased, device is bricked and no more bootable. There is no protocol to communicate with eMMC, even if the data is there, except through something very lower level like JTAG or a chip-off.

  Also see: Bootloader/BIOS, flashing ROM and correlated risks. Why Android devices are more brickable than PCs?

• Storage media is physically damaged; mechanically or electrically.

Large size storage solutions like NAS or the more complicated SAN that makes use of LUNs with advanced protocols likes iSCSI, and data integrity solutions like RAID also complicate the data recovery process. However single disks like on home PCs or the flash memory like on Android phones are rather simple cases.

---

So while a Factory Reset with stock recovery suffices in most cases, you can combine any of the above described steps, whichever applicable to your device, to make sure your data is not retrievable.

RELATED:

• Can user data be recovered after formatting and flashing stock ROM?
• How to recover a deleted file from /data partition?
• How to get data off a completely dead Android phone?