Hi,
I am trying to get my phone ready to sell and I would never sell a computer hard drive without writing zeros to the drive so that my data could not be recovered. I can find no way to do this with my phone.
Recovering data off of a factory reset android is extremely easy (this guy does it in like 5 minutes):
(I cant post links so go to gottabemobile dot com and search for the article "Security Guru: Don’t Sell Your Android Phone Until Turning it into Swiss Cheese".)
In this study, the only semi reliable way to securely erase data would be to do a whole disk overwrite or a whole disk encryption (single file deletion or free space overwrite completely fails on SSD drives).
(Search Google for this paper "Reliably Erasing Data From Flash-Based Solid State Drives." This was a study done at UC San Diego.)
I realize that the newer android operating systems have encryption, but I cannot verify if it is whole disk encryption, and if it is not whole disk (encrypting all of the free space on the drive) it would be useless for files that are already deleted (or overwritten considering how wear leveling works, there can be multiple copies of the file spread out over the drive).
Can anyone come up with a way that I could do a whole disk overwrite and then load the operating system back on from download mode?
Thanks
"If you really want to erase data on a rev 0x19 samsung emmc chip, I suggest you just write zeros to the entire partition."
I found this on another post, this is exactly what I am trying to do. Does anyone know how I can do this and then re install the stock rom?
I too would like to know how to ensure data can never be recovered from my Android, should I sell it.
Related
Hi,
I used to know a way to dump a raw range of data (i.e. specifying start/end in hex address) from a block device which I used to do from data recovery days, but I can't remember what it is. I have been googling for about an hour and it's driving me nuts! Can anybody help?
FYI, I am trying to grab data from an unknown range of data on the nand layout for the Xperia Play but this is a general linux/busybox question. For details on what I'm doing check here.
Thanks so much in advance.
EDIT: Nevermind, I've discovered that the range I'm trying to read is a protected area. Mods please close if possible.
cat is more like a parser, dd is capable of dealing with raw data.
http://www.linuxquestions.org/questions/linux-newbie-8/learn-the-dd-command-362506/
http://linux.die.net/man/1/dd
Yeah I figured it would be done with dd, though I can't find any device that represents the "entire" mtd/nand - only mtd# for existing partitions exposed by the kernel. If i could find a "root mtd" device I could use skip and count parameters of dd to read what I want.
Regardless, I don't really need help with this specifically anymore - my problem seems to be specific to the Xperia Play. I am basically trying to resize the partitions (which I did previously on the X10) and I have exposed an unknown ~100MB+ that goes between userdata and cache, but I can't read or write to it at all no matter what I do.
I think what I'm trying to get is a protected area for DRM or something which I want to shift (so I can give space from cache to userdata). I/we need to make kernel or bootloader changes for the device.
Thanks for the help anyway.
I have a Samsung and Samsung is the probably the only one brand that adopt a different partition system for mtd; but remember that dd just copies everything, free space included, if with dd you are copying a filesystem with a total of 100MB and only 40MB are in use, you end up having a 100MB image file with dd.
Yeah I know it's a raw by-sector mirror/dump tool. Well what I did was edit the kernel to only create one entire partition taking the complete nand storage and then tried to dd from that, it works for a long time then once it hits this special "protected" area around ~800MB offset it spams a lot of "I/O Error" messages but doesn't fill these with zero's or anything (using conv=noerror), then once it passes the protected area it successfully dumps the rest (which is where the cache partition for the zeus would go).
OK, I have another question now. I found that this unknown 133MB has about 53MB of data in there, somewhere in the middle, which grabs fine. But the resulting file is not 133MB so I don't know the offset. Can I use dd or another tool to grab this partition while filling I/O errors with zero's? I have googled a lot and couldn't find anything.
Nevermind *facepalm* I use conv=noerror,sync. http://www.mkssoftware.com/docs/man1/dd.1.asp
I'm writing after reading the paper "Security Analysis of Factory Resets" (http://www.cl.cam.ac.uk/~rja14/Papers/fr_most15.pdf), in which Android factory reset through 4.3.x has been revealed to basically be a joke. In light of this fact, I'm looking to come up with the simplest, secure process to follow for resetting a phone before selling it. My current phone is on 4.2.2, but I think the process should ideally be generic and applicable to as many OS's as possible.
ASSUMPTIONS
Based on the researchers' findings, let us assume the following:
1) Let us limit our concern to the data and internal SD card partitions, and we assume the latter is stored as an emulated SD card physically stored on the data partition.
2) We assume the flash memory is overprovisioned and therefore cannot be overwritten on a single pass.
3) Let us only consider 4.0.x and later devices that contain the full disk encryption (FDE) feature.
4) We require a procedure that can be employed on a phone that has not been used "securely" from the moment of purchase (such as employing FDE).
5) Let us assume our potential attackers are equipped/motivated to the point of using widely available software tools to scan for data that is logically deleted but not physically overwritten. At a minimum, we require "logical sanitisation" (storage cannot be recovered via standard hardware interfaces). "Digital sanitisation" (storage cannot be recovered via any digital means, including the bypass or compromise of the device’s controller or firmware, or via undocumented drive commands) would be preferable, if it can be achieved. We do not require "analog sanitisation" (reconstruction is impossible even with the most advanced sensing equipment and expertise).
PROPOSED SOLUTIONS
The researchers' proposed the following:
1) "Overwriting the entire partition bit-by-bit once did provide logical sanitisation for all devices and all partitions we studied; it is therefore a reliable alternative. The drawback of this method is that it requires privileged (i.e. root) access to devices in practice. This method does not provide thorough digital sanitisation, since the flash is overprovisioned – but an attacker cannot recover data using public APIs exposed by the Linux kernel."
First question, can anyone please provide a procedure to perform a bit-by-bit overwrite? I assume this would entail sending data via adb, but I would appreciate links to a specific how-to?
Second, since the flash is overprovisioned, would repeating this procedure 2-3 times ensure a reasonable likelihood that all data had been overwritten at least once and provide us with "likely" digital sanitisation in addition to logical sanitisation?
2) "Enabling Full Disk Encryption (FDE) on first use of the device would be more appropriate for ordinary users if devices support it. Enabling FDE only before performing a Factory Reset (as suggested by Google) may only provide logical sanitisation, not thorough digital sanitisation (plain-text data could still be present on the flash as it is over-provisioned). FDE was introduced in ICS (v4.0.x) so it cannot help the large number of affected GB (v2.3.x) devices. FDE for the internal SD card is not supported on all phones, and not all v4.x devices support FDE on the data partition despite AOSP’s support. As a rule of thumb, only devices with an emulated internal SD card inherit the “encryption support” from the data partition when supported. On supported Android versions, the encryption key is stored encrypted with a key derived from a salt and a user-provided PIN (or password). This encrypted blob is referred to as the “crypto footer” in the AOSP source code. An attacker who gains access to the crypto footer has enough information to brute-force the user’s PIN offline. The footer is stored in a dedicated partition or in the last 16KB of the data partition – the exact location is configured by vendors through the “encryptable=” option of the Android fstab file. In either case, we found that the footer was not erased after a flawed Factory Reset. Consequently, to logically sanitise a device with encryption, it is essential to select a strong password to thwart offline brute-force attacks. As most people just use a 4-6 digit PIN, it would usually be trivial to brute-force."
First thought, since we must assume the crypto footer can be recovered, then perhaps our process should include a step in which FDE is enabled using a long, complex, and random password in order to create a decoy crypto footer.
OPTIMAL SOLUTION???
Combining the above proposals to attempt to obtain a reasonable likelihood of digital sanitisation (but at least surely logical sanitisation), I am thinking of the following process:
1) Enable FDE encryption with a maximum-length, complex, random password (if it is not already enabled).
2) Perform a bit-by-bit overwrite of the data partition with 2-3 passes.
- What tools exist to perform this and ensure that the data and internal SD card partitions are included in the wipe?
- Following this process, what state is the phone in? Can it still be booted to Recovery mode to perform a factory reset?
3) Perform a factory reset from the Settings screens, including the "External Storage" option.
4) Enable FDE encryption with a maximum-length, complex, random password to create a decoy crypto footer.
5) Perform a factory reset from the Settings screens, including the "External Storage" option.
FEEDBACK
While the above process seems thorough, perhaps it is needlessly redundant? At a minimum, I would like to achieve 2-3 passes of bit-by-bit overwrite and the installation of a decoy crypto footer to resist decryption of any encrypted blocks that might be recoverable.
Before I start, I'm aware there are great data recovery guides on this forum and elsewhere. Unfortunately, I was unable to find one pertaining to Nougat and my specific circumstances. Thank you for bearing with me.
How the Data Was Wiped
I ran "fastboot format userdata" to fix a "Decryption Unsuccessful" error message after going from LineageOS 14.1 to 15 on a Xiaomi Mi 5 Pro. Because I was in a hurry to get my phone back online, I foolishly assumed the wipe would leave /data/media intact, just like TWRP, without making sure of it. I know the assumption was wishful thinking at best and I can see the irony in then spending the rest of the day trying to undo the damage.
How the Data Was Dumped
Immediately after finishing the fastboot format, I booted back into TWRP 3.1.1-0 where I discovered the extent of the data loss. Since I hadn't flashed a ROM and didn't want to write anything else to my /data partition, I did a "adb pull /dev/block/sda14 sda14.img" on my computer over USB with my phone still in recovery. With a 128GB phone, the process took a whopping 8102.059s to finish.
How I attempted to Recover Data
I let both R-Studio 8.3 and UFS File Explorer Professional Recovery 5.23.4 scan through my dump to no avail. All they found were meaningless, small files, mostly in a .txt or .so format. I also attempted to mount the image using DiskInternals Linux Reader 2.6, but PhotoRec didn't recognise the volume.
Where do I go From Here?
Christian Weiske wrote about his attempt at recovering photos from a Galaxy S5 mini, running Marshmallow. He noted that data he pulled in Windows was broken using various commands until he tried "adb exec-out". Does the problem lie in my pulled data also being broken/incomplete, or is "fastboot format" actually capable of completely destroying more than 100GB worth of data in mere seconds on TRIM-enabled devices? If I am to do a second /data dump using a different method, I would have to do it directly to my computer as my phone doesn't have a microSD slot. I should add that, to the best of my memory, I never encrypted the storage, as I went directly from CyanogenMod to LineageOS using the experimental migration build.
To anyone who chimes in, if only to tell me that I should suck it up and stick to whatever data I have backed up and move on, I'll be most appreciative! Even more so if anyone can shed some light on modern-day Android data recovery/wiping and limitations.
I'm going thru a recovery process myself. Using a few guides. First I completed a raw dump of the whole phone w/out installing any os over the phone. I'm about to check that and see if testdisk can find something via https://roubert.name/joakim/androidfilerecovery/
In the background, I have another dump going on from https://forum.xda-developers.com/ga...de-internal-memory-data-recovery-yes-t1994705 guide. Hopefully, something comes up.
Is it possible to restore an android phone back to its original factory state if all of its internal EMMC flash memory has become corrupted?
Firstly, I apologise for the verbose way in which I’ve phrased the question. However, there are literally hundreds of guides on the web that misleadingly claim to show how to backup and restore everything on a phone, but which actually do nothing of the sort. So I felt it best to try and be as precise as possible.
When I buy a new PC, the first thing I generally do is to boot into a Linux live USB distribution and save an image of the entire hard disk. This enables me to restore the PC back to its factory state if something goes horribly wrong.
[As an aside, this is a massive pain in the ass to do and shouldn’t really be necessary. But since PC manufacturers stopped providing separate OS install disks with their computers (presumably this is a deliberate Microsoft policy), a disk image has become the only 100% reliable way of restoring a PC back to its factory state when something goes wrong.]
Anyway, I would like to do something similar with my Android phone (which is a Motorola Moto G4). But what is a relatively simple (if time consuming) task in the PC world is proving to be surprisingly difficult in the Android world. What I’ve done to my phone so far is the following:
I unlocked the bootloader, and installed TWRP.
I then booted into TWRP and created a ‘nandroid’ backup.
I assumed this would be enough to enable me to restore it back to a factory state. But I’ve since done some more research, and it turns out that TWRP does not actually allow you to backup all the partitions on the internal flash memory. And at least one of the excluded partitions stores important stuff like the phone’s IMEI number! So whilst a nandroid backup is useful, it is definitely not a backup of the entire phone.
I’ve noticed that there are some guides on how to copy the entire EMMC flash drive (mmcblk0) to an image file. This process seems somewhat similar to how I would take a disk image on a PC. However, no one explains how to flash the image file back to mmcblk0 if the phone gets bricked.
It also throws up some other question that I can’t find definitive answers to. For example, where is the bootloader actually stored? Is it somewhere on mmcblk0, or is it stored on an entirely separate (and hopefully read-only) flash chip in the same way that a PC’s BIOS would be? If it’s the former, then how would you boot the phone if the mmcblk0 chip became entirely corrupted? Also, where is the Android Debug Bridge utility stored? Is that also on the mmcblk0 chip, or somewhere else?
It’s frustrating that, despite hours of googling, I can’t find definitive answers to these fundamental questions. I would be grateful if anyone here could point me in the right direction.
Thnaks in advance.
Hello,
So I need help with completely wiping a linux partition on my android SM-a137f (and computer) that has been there for privacy invasion reason/spying etc by someone at my work.
------------Skip to the bottom part for phone only part, the rest is about the computer issue , both related however as they infect each other and i see the same linux filesystem and patterns on both---------
I never used Linux before and I tried fighting this "trojan" in windows on my computerand fatigued myself after the 50th low level formatting, not understanding how it can just come back, plus self learning, if i use an antivirus that works decent, like install it within 2 minutes after formatting before it activates, it gave me a lifespan of +20 minutes perhaps, next time i did that, it had injected it and just spawned like 10 processors of it to lag me down. Plus installing these fake drivers, meaning it infected my kernel.
So as i dived in to the world of Linux i got my hands on rescuezilla, which is based on ubuntu, things started to clear up, very sophisiticated work, and insane. Looping stuff, a squash filesystems that is impossible to remove, and i mean impossible in my book, thats why i come here, because if you are going to suggest any permission changing command or unmount command, don't - i tried every single one in the book and it won't budge.
It's not even an I (i forgot what I stood for) in the permission, it's only like cr- r ---- r-- or something, two or three 3's
The overlay starts with a /cow and holds everything.
Since this will perhaps be a police matter unless he agrees to replace the devices this has killed (phone, im on my third now, computer and a very secure router) and I have more than enough evidence including a perfect clone of the whole harddrive of my work computer and laptop.
Anyway - i dont care about any data, wipe all, and more if possible. Its my 85th time formatting anyway so, i just can't get rid of it. It's "base" is the X: partition which would be the recovery one I believe, in windows. And it mounts itself as a ddrom and/or ram, virtual, but not virtual. Every program i've said has stated it's a virtual, and when i try anti-virtual removal stuff, it says its not a virtual disk. Read only that nothing can remove in windows at least, forget diskpart etc.
-----------------------------------------------------------Phone---------------------------------
I am willing to pay for proper help on this.
I just rooted it and I want to wipe that whole kernel on this phone. Not a factory reset - a clean wipe. Not a single file left. Is that possible? Or how else do I get rid of all of that stuff, I mean, there is a problem whe 280 system apps has on average 60 permissions each, up to 400.
Thanks a lot for any input in advance. I can't stress how much of a mental toll this has taken on me as i've been on this for 1 month straight not doing anything else. Since it's about my privacy, and It seems I've had one for the past 2 years with my every footstep, thing ive written or said, even a sleepshedule has been monitored.
Just a few screeshot examples
In Odin flash the firmware with a 4-file zip file.
ze7zez said:
In Odin flash the firmware with a 4-file zip file.
Click to expand...
Click to collapse
How do you mean? I done that several times, filled out the AP CP BL CSC etc, doesn't touch that partition
Mikez77 said:
How do you mean? I done that several times, filled out the AP CP BL CSC etc, doesn't touch that partition
Click to expand...
Click to collapse
Show a screenshot of the Odin window after the flashing is complete.
According to the OP, their computer is attacked within seconds of them logging in. Any antivirus only lasts a few minutes. Can't low level format the disk, because the attacker puts BIOS and virtual wifi spots into the UEFI partition, hacked their router and cell phones numerous times as well.
And they claim to know who this is, have a mountain of evidence but somehow won't go to the police with it. Search for the op's name and the keyword linux. They're carpet-bombing forums with paranoia.