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

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:




Topics


2D Engines   3D Engines   9-Patch   Action Bars   Activities   ADB   Advertisements   Analytics   Animations   ANR   AOP   API   APK   APT   Architecture   Audio   Autocomplete   Background Processing   Backward Compatibility   Badges   Bar Codes   Benchmarking   Bitmaps   Bluetooth   Blur Effects   Bread Crumbs   BRMS   Browser Extensions   Build Systems   Bundles   Buttons   Caching   Camera   Canvas   Cards   Carousels   Changelog   Checkboxes   Cloud Storages   Color Analysis   Color Pickers   Colors   Comet/Push   Compass Sensors   Conferences   Content Providers   Continuous Integration   Crash Reports   Credit Cards   Credits   CSV   Curl/Flip   Data Binding   Data Generators   Data Structures   Database   Database Browsers   Date &   Debugging   Decompilers   Deep Links   Dependency Injections   Design   Design Patterns   Dex   Dialogs   Distributed Computing   Distribution Platforms   Download Managers   Drawables   Emoji   Emulators   EPUB   Equalizers &   Event Buses   Exception Handling   Face Recognition   Feedback &   File System   File/Directory   Fingerprint   Floating Action   Fonts   Forms   Fragments   FRP   FSM   Functional Programming   Gamepads   Games   Geocaching   Gestures   GIF   Glow Pad   Gradle Plugins   Graphics   Grid Views   Highlighting   HTML   HTTP Mocking   Icons   IDE   IDE Plugins   Image Croppers   Image Loaders   Image Pickers   Image Processing   Image Views   Instrumentation   Intents   Job Schedulers   JSON   Keyboard   Kotlin   Layouts   Library Demos   List View   List Views   Localization   Location   Lock Patterns   Logcat   Logging   Mails   Maps   Markdown   Mathematics   Maven Plugins   MBaaS   Media   Menus   Messaging   MIME   Mobile Web   Native Image   Navigation   NDK   Networking   NFC   NoSQL   Number Pickers   OAuth   Object Mocking   OCR Engines   OpenGL   ORM   Other Pickers   Parallax List   Parcelables   Particle Systems   Password Inputs   PDF   Permissions   Physics Engines   Platforms   Plugin Frameworks   Preferences   Progress Indicators   ProGuard   Properties   Protocol Buffer   Pull To   Purchases   Push/Pull   QR Codes   Quick Return   Radio Buttons   Range Bars   Ratings   Recycler Views   Resources   REST   Ripple Effects   RSS   Screenshots   Scripting   Scroll Views   SDK   Search Inputs   Security   Sensors   Services   Showcase Views   Signatures   Sliding Panels   Snackbars   SOAP   Social Networks   Spannable   Spinners   Splash Screens   SSH   Static Analysis   Status Bars   Styling   SVG   System   Tags   Task Managers   TDD &   Template Engines   Testing   Testing Tools   Text Formatting   Text Views   Text Watchers   Text-to   Toasts   Toolkits For   Tools   Tooltips   Trainings   TV   Twitter   Updaters   USB   User Stories   Utils   Validation   Video   View Adapters   View Pagers   Views   Watch Face   Wearable Data   Wearables   Weather   Web Tools   Web Views   WebRTC   WebSockets   Wheel Widgets   Wi-Fi   Widgets   Windows   Wizards   XML   XMPP   YAML   ZIP Codes