I need to erase all data from my phone Sprint PPC 6700 (HTC Apache). How to do it to completly remove all my data from it?
I do not want to hear that there is "Clear Storage" procedure on device because you can retrive that kind of erased data. It brings device to factory state but you can still retrieve data.
Any program which will eg. 10 times write down in free memory space with 0's and then 1's.
I do not want any information to be recovered, info in device is strictly confidential like TaxIDs, SocialSecurityNumbers, passwords and other sensitive data.
It is like with computer format hard drive - normal user will not see data but user with knowledge can access it.
I do not post question in HTC Apache forum because maybe somebody have or may have similar problem with different device.
on wm2005 you format from inside the bootloader
There is no default secure way.
If you're that concerned about the sensitive data now, then really I am surprised it wasn't encrypted anyway.
If it was, simply use the same application to secure wipe those files, and then you have no problem.
If not, use something like http://www.pocketpcfreewares.com/en/index.php?soft=1694 to delete the files you are concerned about, and then simply wipe the storage as normal.
Also, possibly use wm5torage and write/rewrite until you are satisfied with the result.
Rudegar said:
on wm2005 you format from inside the bootloader
Click to expand...
Click to collapse
May you please give me magic commands to do it?
Thank you
Well, format it from the bootloader sounds just like a normal formatting. Anyway, if you do not have ultra secret important information, nobody with that amount of skill will want to hack and recover your data after a hardreset. If you were to ask the gurus here, they may not want to go through the trouble to recover them (if possible at all). If you were to ask me, you are just being paranoid. The chances that your phone will fall into a hand of a [1]hacker capable of recovering data from hardreset phone AND [2]person interested in your data, is very very slim. You will be more likely to have your information stolen surfing the web (wired), getting a trojan in your PC, stolen via wireless, etc.
Anyway, the US military standard of 12 times write on a hardisk ensures that no data can be recovered via physical means. That is to disassemble the hardisk, and using sophisticated electron scanning equipment to get the data. That's because normal reading via the usual way is not possible after just 1 write.
Anyway, having babbled the above, from what I experienced from retrieving data from a hardisk (the normal way), your data is relatively gone if you fill it up with stuff. SO, if you can just hardreset your device, copy some movies, mp3s over (eg via WM5Storage) until it is full, and then hardreset it again, it ought to do the job. If you are still worried, do this 12 times. Those that are good enough to retrieve your data will just get he movies/mp3s you use.
FYI:
On magentic storage, like hard drives, one pass of zeros is sufficient to write over the data such that not even an electron microscope could determine what the bits previously contained. It may have once been possible on 10-20 MB MFM hard drives in the early 80s, but is certainly not possible anymore.
The American military and intelligence agencies use the same clean-room data recovery procedures as do commercial data recovery houses, and in fact often contract out to those houses.
Flash memory I'm not so sure about, especially because a lot of flash memory uses redundant sectors to fill in when a given sector has exceeded the number of read-write cycles it's supposed to be capable of.
I would probably just fill the device up with files, delete and repeat like hanmin is suggesting. If your data is so important that someone would try to steal the device (or buy it from you) and then subject it to a military-grade inspection, you can probably afford to destroy the device physically or at least destroy the memory chips inside it and resell it for parts.
mikesol: Thanks for clarification.
Latelly I read article about guy who recovered average od 20k pages from PocketPC Phones after where were "Clean Storaged" and owners thought that data are safely deleted.
Maybe I am paranoid but if somebody gave me theirs personal/confidential data I try to protect them as much as possible.
Device will stay in one company, but probably next person will not have such vital information as I did. That is why I try to clean it as much as possible.
Now, I am satisfy with what I did.
FYI: I do not work with DoD or cooperating company but level of security is high, ie. old harddrive - 10 times write over + drill over and apply acid inside. Just to be safe
http://www.informit.com/guides/content.asp?g=security&seqNum=234&rl=1
good read
Haahaha, with our old hard drives at my company we just take them apart and then tack up the platters because they look cool.
From what I've been reading, wear-levelling may make it possible to recover "old" bits on a memory card, but there's no context for them - the FAT (or whatever filesystem you're using) won't retain any links to them and it's possible that the microcontroller built into the memory card simply won't allow access to sectors that have exceeded their read/write cycle count.
Regardless, all that would be left in those sectors would be some random bits, context-free and virtually impossible to recover from.
As of now, most of the data recovery techniques for flash rely on the ability to read bits off of the card, and then applying the same utilities to them that you'd use for a disk image of a hard drive. I haven't read about any advanced, dissection-based approaches to determine whether previous states for a given bit can be read even when a bit has been overwritten.
I'd think that there's probably no good way to do that without a massive expenditure in R&D, and you're probably safe filling the memory up once or twice with a format after each. Anyone that gets old data back after that won't be going after you, they'll be working for the NSA or something.
Hmm.. I never thought I will see this, such software do exist!
http://pocketpcapps.net/fileshredppc.aspx
Pawlisko, you may ask your company to get a few copies of this.
hanmin - I used exactly this program. I do not have Apache no more and I feel quite secure about wipe out.
Probably my company will use this software in future, but for now our major concern is case when somebody will lose device. Of course we will remotly wipe it out, but data will not be securly deleted.
Every employee knows that loosing device is not an option
You used this software before or after my post? You ought to let others know your discovery
Anyway, in what form your 'secret' information are in? I mean, text, recordings, pictures? There are some software out there that do encrypt these things. I mean, if they were to be encrypted at stage 1, you won't have to worried about it anymore. If you were to let us know in what form the information is, probably members here can think of a better idea
So, what are you using now?
when it is avaliable, ma i recommend that your company upgrades to wm6, it has built in encryption for everything (optional) it will even encrypt stuff on sd cards.
If by WM6 you mean Crossbow, the encryption option is for the SD card, not the internal memory.
It's so that if you remote wipe a device, the contents of the card can't be read on another device or system, unless you restore that device from ActiveSync.
If the company information is that sensitive, it should be stored encrypted with any one of the hundreds of applications aimed at corporate users.
If they aren't doing this, then their IT department simply is not providing the solution to the business that it should be, and someone should do something about it.
Something like this will encrypt all of the PIM, and for instance your My Documents folder so all files stored will also be encrypted.
http://www.safeboot.com/products/device-encryption/windows/
And this one is quite impressive, I saw a demo at IPSEC in London last time:
http://www.pointsec.com/products/smartphonepda/
hanmin - fileshredppc I used after your tip, thank you very much.
What is sensitive stuff - PIM, text, PDF files and photos. Do you know any good solution to encrypt it in Stage 1?
Midget_1980 - for now on there are no plans to go for WM6. But I am monitoring if WM6 would be worth to invest money in it.
AlanJC - I will investigate your links. Thanks in advance.
Hi, there!
Like many others, I have only recently switched from WM6.5 to Android (with my new HTC Desire).
WM 6 introduced the possibility to encrypt the SD Card, making it only readable in the PPC it was originally encrypted in. I found this a very helpful tool and had bought a respective app from Spritesoft. Unfortunately, their Android software is still in the beginning status, and therefore, I bought yesterday the app from WaveSecure.
I was surprised, however, that they do not offer an encryption for the SD card as I know it from my old TyTN II.
Is anybody here who can advice - tweak, app, or whatever?
I mean, it's nice to secure the phone - but the sensible data are being stored in files on the SD card in the end. And if you lose your device, it may well be broke, but the SD card lives and cannot be wyped in a broken device either.
I couldn't agree more. There are a few applications that either offer individual file passwords, which is not very secure, or just offer encryption of its own text files, like OI Safe. I used to use a commercial application on Windows Mobile, Sentry 2020, which allowed you to create a an encrypted volume within your storage, internal or external. This was ideal, as it allowed you to store any kind of files in this. After a timeout period, the volume was automatically closed and your files were secure. It is a shame that the last activity in Sentry's website is in 2007.
I should be receiving a desire very shortly and am very concerned by the current lack of device level encryption.
Does anyone know if there are any products in development that will soon allow device encryption?
Is the hardware and OS itself capable of supporting full device encryption?
hi, i want to reopen this issue because today i asked myself the same question.
i have tested several apps but most of them are not useable for a large number of files or folders.... what we really need is a secret partition and something like truecrypt.... i didn´t find anything in the net... so if somebody has an idea or solution for that, i would be happy...
thank you!
htclerman said:
hi, i want to reopen this issue because today i asked myself the same question.
i have tested several apps but most of them are not useable for a large number of files or folders.... what we really need is a secret partition and something like truecrypt.... i didn´t find anything in the net... so if somebody has an idea or solution for that, i would be happy...
thank you!
Click to expand...
Click to collapse
did you encounter anything using AES/Rijndael or at least Blowfish or Twofish algorithm? I need something to encrypt single files/folders only. TIA!
wizja said:
did you encounter anything using AES/Rijndael or at least Blowfish or Twofish algorithm? I npartitioneed something to encrypt single files/folders only. TIA!
Click to expand...
Click to collapse
Do you speak about apps?
If yes, there is nothing out there
I know that is working fast with a big number of files. There must be an option to encrypt a whole partition,
That's the only thing that would make sense.
Sent from my HTC Desire using XDA App
http://tasker.dinglisch.net/tour.html
Claims to support encryption, kind of complicated through.
htclerman said:
Do you speak about apps?
If yes, there is nothing out there
I know that is working fast with a big number of files. There must be an option to encrypt a whole partition,
That's the only thing that would make sense.
Sent from my HTC Desire using XDA App
Click to expand...
Click to collapse
With the ability to put apps on the SDCard this is going to be an unlikely feature to work well....
Your best bet is looking for something with a good remote wipe/lock feature.
If you have a partition formatted with ext2/3/4, it's only a matter of copying over static binaries of lvm, device-mapper and cryptsetup, and creating a script called via initrc or controlled via /etc/init.d
I've posted about a similar solution for /data. Search for it.
Push for implementating it in Android:
Using dm-crypt to Encrypt the SD Card...? - xda-developers
Using dm-crypt to Encrypt the SD Card...? - CyanogenMod Forum
Issue 11211 - android - Android too insecure - Encryption of the SDcard is crucial - Project Hosting on Google Code
Issue 3748 - android - Add support for partition/block device encryption - Project Hosting on Google Code
Just bought a new Galaxy Tab S 10.5 Wifi and I have been debating whether to enable full disk encryption. I know that the stock android implementation of encryption is entirely software based, but Samsung mentioned in their documentation that their ODE (On Device Encryption) system supports hardware accelerated encryption. However, information on the topic is scarce, and I cannot confirm which models actually support acceleration.
Does anyone know of a list of android devices that supports hardware accelerated encryption?
snapper.fishes said:
Just bought a new Galaxy Tab S 10.5 Wifi and I have been debating whether to enable full disk encryption. I know that the stock android implementation of encryption is entirely software based, but Samsung mentioned in their documentation that their ODE (On Risk Encryption) system supports hardware accelerated encryption. However, information on the topic is scarce, and I cannot confirm which models actually support acceleration.
Does anyone know of a list of android devices that supports hardware accelerated encryption?
Click to expand...
Click to collapse
Go to Settings/Security and if it says Storage Type-Hadrware Backed, then your device has crypto module. However, big warning here: if your master encryption key sits in hardware (like in Iphones), there is nothing easier for a sophisticated attacker to get the key directly from there. If, like in Lollipop, the master key is salted on hard drive and crypto module holds another key used to sign the master key, that provides an additional layer of protection against brute force attack. In other words, someone can take an image of your entire hard drive and then brute force your password offline or in the case of Iphone, just get the key from hardware. In lollipop, it is impossible. So, sometimes google does good things (by mistake)...
In lollipop, it is impossible.
Click to expand...
Click to collapse
Android disk encryption is based on dm-crypt, which means it's at the block device layer. The encryption algorithm used is AES-128 with cipher-block chaining (CBC) and ESSIV:SHA256. The master key is encrypted with 128-bit AES via calls to the OpenSSL library. New Lollipop devices encrypted at first boot cannot be returned to an unencrypted state.
The unlock PIN/password is used to derive the AES disk encryption key which is stored in the volume header. As from 4.4, scrypt is used to derive the keys in order to make brute force attacks a little harder, but using a strong password instead of a stupid PIN remains highly recommended. On certain Nexus devices, the key is hardware-protected (likely TEE).
Nothing is impossible but's harder:
http://www.bbc.com/news/technology-31765672
http://www.washingtonpost.com/blogs...-apple-and-google-users-researchers-discover/
http://www.bbc.com/news/technology-31729305
CHEF-KOCH said:
Nothing is impossible but's harder:
http://www.bbc.com/news/technology-31765672
http://www.washingtonpost.com/blogs...-apple-and-google-users-researchers-discover/
http://www.bbc.com/news/technology-31729305
Click to expand...
Click to collapse
What have these news to do with Android encryption?
Seriously, there was a clear question by the OP and you didn't even try to answer at all. Instead you copy and paste text fragments from other websites and post irrevelant links...
@bastei
And how your post helps here? I explained very well that FDE is vulnerable with several attacks. It isn't worth to use it, especially on such hardware, because it costs a lot of performance for nothing.
FDE isn't secure to use, especially if you have a mobile device which allows the attacker to get physical access to it + the mentioned attacks.
But to answer the question:
Hardware accelerated encryption is dependent on which hardware (needs to support special flags like AES/AES-NI/AVX) you use and if your os supports it (minimum Android 3.x) or not. And no there is no list, because all new hardware after (and some of them before) Android 3.x comes with support for it, the Tab S uses AES 256-Bit Encryption according to the specs.
ODE (On Risk Encryption)
Click to expand...
Click to collapse
It's Samsung On-Device Encryption (ODE) and not on Risk ...
Yup that's a typo. Going to check the settings when I get home today.
CHEF-KOCH said:
@bastei
I explained very well that FDE is vulnerable with several attacks. It isn't worth to use it, especially on such hardware, because it costs a lot of performance for nothing.
FDE isn't secure to use, especially if you have a mobile device which allows the attacker to get physical access to it + the mentioned attacks. .
Click to expand...
Click to collapse
With all due respect, but your explanation is wrong. If encryption is properly implemented, you reduce vulnerability to virtually none. Users just have to understand how encryption works and what it is designed for. Contrary to popular beliefs, disk encryption is not designed to protect the device that is live/running, it only prevents access to your data, when your phone is off. By the way, the term "full disk encryption" , as it applies to Android, is highly misleading, because unlike in Linux, Android only provides for data encryption.
However, Android allows to implement encryption in a way that it is virtually impossible to break. You can have separate passwords short for screen and long/strong for boot and encryption. In addition, Android Lollipop provides an extra layer of protection by putting a second key, which is used to sign the master key in crypto module (hardware). This is much better than in IOS (iphones) where the master key simply sits in hardware crypto module and therefore could be easily obtained by a sophisticated attacker (think back doors in crypto module and weak hardware assisted random number generation).
Let me give you an example with my Sony Xperia Z1 running custom lollipop. I have enabled 256 bit encryption; I have increased the length of various keys, as well as the number of iterations for random number generation; then I have disabled in kernel hardware based weakened random number generator and enabled all other methods inactive by default (thanks to google and sony for making it easier to break for spooks); I then disabled hardware overlay option, which causes slow down, so, now, there is no visible difference in performance with unencrypted device. And finally, I have encrypted the phone via adb shell by using a long pass phrase, so that screen pin was not used in encryption in any way, including its salted traces on the device. By the way, when you encrypt lollipop via adb shell, you don't input your raw passphrase, but rather its hexed version, and guess what, I hexed it on my computer, as opposed to the phone. So, when I turn my phone off, I know that no sophisticated spook can get access to my data even if they take an image of all my partitions and try to brutforce the password off the phone. They simply can't. No one can break properly implemented 256 bit AES encryption. That is why the spooks need backdoors in hardware and weak random number generation (the latter is disabled in kernel on my Z1).
So, properly implemented encryption (and Android Lollipop provides for that) does not visibly slow down the device and can make it impossible for spooks to break. .
With all due respect, but your explanation is wrong. If encryption is properly implemented, you reduce vulnerability to virtually none. Users just have to understand how encryption works and what it is designed for. Contrary to popular beliefs, disk encryption is not designed to protect the device that is live/running, it only prevents access to your data, when your phone is off. By the way, the term "full disk encryption" , as it applies to Android, is highly misleading, because unlike in Linux, Android only provides for data encryption.
Click to expand...
Click to collapse
But Android is not a Computer which is on the same place all the time which means that it is a lot of easier to get physical access to it. That means an attacker have all the time to crack it, which in fact is only a matter of time. With or without additional protection mechanism - it will be cracked soon or later, and if you asking me it's not worth to use FDE on a mobile device, it coasts performance (as said for nothing).
The focus should be to protect data, correct but these kind of protection not protect against usage data stealing if most aps need internet connection which never use any secure way to send and receive data - So the risk here is much higher that a attacker can collect all necassary data if your phone is unlocked and a app xyz is running in the background which logs all stuff, such as Pin, passwords for website logins or whatever.
However, Android allows to implement encryption in a way that it is virtually impossible to break. You can have separate passwords short for screen and long/strong for boot and encryption. In addition, Android Lollipop provides an extra layer of protection by putting a second key, which is used to sign the master key in crypto module (hardware). This is much better than in IOS (iphones) where the master key simply sits in hardware crypto module and therefore could be easily obtained by a sophisticated attacker (think back doors in crypto module and weak hardware assisted random number generation).
Click to expand...
Click to collapse
It's very easy breakable there a several tools out there, exploits and poc's - and why need to crack something if you better steal data that are necessary over internet? Which tactic is easier - sure the last. Yes, lollipop is the first secure os, but not all people use it right now or the oem rolls out the update for every device. But I generally agree in the aspect that lollipop fix most stuff which are vulnerable compared to Android 4.x.
There are several attacks which affects all Android versions even latest lollipop:
- First, the encryption doesn't help much if you haven't set a passcode!
- Limitations in lollipops encryption explained over here
- Only the /data partition and all stuff in there will be protected (only the sdcard is protected if it's non-removable)
- The attacker boot to recovery and factory reset the device.
- If your phone is rooted and booted up, they'll use adb to copy your unencrypted data (e.g. sdcard). If it's not booted, they're stuck.
- The attack can use a download mode from there they flash a custom recovery or custom kernel (rooted) image. Most custom recovery's allows root adb which is needed to bypass the lockscreen.
- The attacker can simply use some software holes to bypass the pin and of course several known tools to crack the image master password.
- Military-grade encryption just doesn’t matter if an attacker has access to the key already.
- Nobody use a strong password (eg 20 chars) since you can't use a hardware token + the fact it's too long to type on the phone (and this each time).
- Android just required you to use a strong password/passphrase when starting up the device, but for some absurd reason they also require that you use the same password as your screen lock password
So, properly implemented encryption (and Android Lollipop provides for that) does not visibly slow down the device and can make it impossible for spooks to break. .
Click to expand...
Click to collapse
Yes and no, you right if you say the stuff about the implementation but overall encryption always takes performance for e.g. if you use AES 256 encryption anything that needs to decrypt constantly during the read and write process will causes performance impacts examples are give over here and here. But AES is most common used which is already "optimized".
The conclusion is that the performance of your device will take a slight hit if you enable encryption (dependency which hardware you use and which encryption algo was used + possible bugs/implementation problems) but to fight with this only for a technique that will be cracked it the near feature is really not worth to use or recommend if you asking me. It's more like a placebo, nothing is really secure as long the user is to lazy to use a very strong passcode/password
CHEF-KOCH said:
But Android is not a Computer which is on the same place all the time which means that it is a lot of easier to get physical access to it. That means an attacker have all the time to crack it, which in fact is only a matter of time. With or without additional protection mechanism - it will be cracked soon or later, and if you asking me it's not worth to use FDE on a mobile device, it coasts performance (as said for nothing).
The focus should be to protect data, correct but these kind of protection not protect against usage data stealing if most aps need internet connection which never use any secure way to send and receive data - So the risk here is much higher that a attacker can collect all necassary data if your phone is unlocked and a app xyz is running in the background which logs all stuff, such as Pin, passwords for website logins or whatever.
It's very easy breakable there a several tools out there, exploits and poc's - and why need to crack something if you better steal data that are necessary over internet? Which tactic is easier - sure the last. Yes, lollipop is the first secure os, but not all people use it right now or the oem rolls out the update for every device. But I generally agree in the aspect that lollipop fix most stuff which are vulnerable compared to Android 4.x.
There are several attacks which affects all Android versions even latest lollipop:
- First, the encryption doesn't help much if you haven't set a passcode!
- Limitations in lollipops encryption explained over here
- Only the /data partition and all stuff in there will be protected (only the sdcard is protected if it's non-removable)
- The attacker boot to recovery and factory reset the device.
- If your phone is rooted and booted up, they'll use adb to copy your unencrypted data (e.g. sdcard). If it's not booted, they're stuck.
- The attack can use a download mode from there they flash a custom recovery or custom kernel (rooted) image. Most custom recovery's allows root adb which is needed to bypass the lockscreen.
- The attacker can simply use some software holes to bypass the pin and of course several known tools to crack the image master password.
- Military-grade encryption just doesn’t matter if an attacker has access to the key already.
- Nobody use a strong password (eg 20 chars) since you can't use a hardware token + the fact it's too long to type on the phone (and this each time).
- Android just required you to use a strong password/passphrase when starting up the device, but for some absurd reason they also require that you use the same password as your screen lock password
Yes and no, you right if you say the stuff about the implementation but overall encryption always takes performance for e.g. if you use AES 256 encryption anything that needs to decrypt constantly during the read and write process will causes performance impacts examples are give over here and here. But AES is most common used which is already "optimized".
The conclusion is that the performance of your device will take a slight hit if you enable encryption (dependency which hardware you use and which encryption algo was used + possible bugs/implementation problems) but to fight with this only for a technique that will be cracked it the near feature is really not worth to use or recommend if you asking me. It's more like a placebo, nothing is really secure as long the user is to lazy to use a very strong passcode/password
Click to expand...
Click to collapse
I agree with you regarding weaknesses, but they all are rellated to improperly implemented encryption or user's misunderstanding. You have acknowledged that if the phone is off "they are stuck." That's what I call properly implemented encryption, and no tool can help including their super fast computers. By the way, if they do it on the device, in lollipop, data will be erased after 10 attempts, not to mention that there is a slowdown mechanism to prevent brutforce. Stealing online: yes, this is true, but again, it is possible to restrict any app from contacting the internet (afwall that was recently updated for lollipop and Xprivacy). On my phone, only web browser, mail client and sip client (all non google) have access to the internet; and since I have no Gapps, there is no "phoning home" Google's servers. Performance: it is true that encryption degrades performance somewhat, but again, if it is properly implemented, human's eye wouldn't notice. By the way, I think the reason Google is back pedalling on default encryption is that they have realized they really created something that is difficult to crack. Hence, they'll "modify" it soon to help their sponsoring spooks.
"Nobody use a strong password (eg 20 chars) " I use a boot pass phrase that has over 60 characters. This one was used for encryption, as opposed to a screen pin. You can only do it via adb shell.... Again, it is all about implementation. And by the way, most of the time I use soft reboot, which does not require me to use the long phrase at all.
A lot of people over-estimate spook's abilities. Despite the recent revelations: they can't do magic, meaning breaking encryption and they know it. That's why they are colluding with everyting that "moves" to put backdoors, weaken number generation, force weaker ciphers and so on.
May I ask you if using an xposed module is a risk for the whole system itself? It shouldn't be too hard to abuse it and to bypass xprivacy itself and the Android firewall.
Funny stuff, you not use gapps but you trust goggles encryption even if they already worked together in the past with GCHQ/NSA ...
Stealing online: yes, this is true, but again, it is possible to restrict any app from contacting the internet (afwall that was recently updated for lollipop and Xprivacy)
Click to expand...
Click to collapse
Again apps are not the first line of defense, they are the last. Xprivacy can't protect/or fake mac address, ID's or your imei/phone number (please read the whole FAQ) and on Lollipop there are a lot of more restrictions generally and they are not all implemented yet.
Since Xprivacy needs root (or should I say the Xposed framework) this is also a possible security risk, the attacker can use adb (which can be rescricted by an app) to disable/uninstall/freeze XPrivacy or any other app even if you use them as admin (the app will once crash and not restart).
...and no tool can help including their super fast computers
... data will be erased after 10 attempts
Click to expand...
Click to collapse
Erased? Are you sure? I don't think so I guess the os will just shutdown but to erase something would be horrible.
On my phone, only web browser, mail client and sip client (all non google) have access to the internet; and since I have no Gapps, there is no "phoning home" Google's servers.
Click to expand...
Click to collapse
Yes, and this is a mistake here in this thread, people forgett that most users are not experts, they not even know about XPrivacy/AFWall+ or root. The benefit of encryption should that all people even without bigger knowledge can handle it without disadvantages or other hints. So that already failed, google now reverted there own statement which means the encryption will not default enabled for all (see my links for there statement: In short - OEM complaining about performance!).
So security isn't activated from the beginning which is also a possible risk.
Performance: it is true that encryption degrades performance somewhat, but again, if it is properly implemented, human's eye wouldn't notice.
Click to expand...
Click to collapse
No it's not and you not understand it the I/O performance is slower, that can be a little bit different from device to device (due other hardware) but it's definitely noticeable (and not only in benchmarks) - please read the links. Not every use high end devices, never forget it -> again security should be available for all and the fact google reverted it clearly shows that we are not ready yet.
By the way, I think the reason Google is back pedalling on default encryption is that they have realized they really created something that is difficult to crack. Hence, they'll "modify" it soon to help their sponsoring spooks.
Click to expand...
Click to collapse
It's a matter of time anyone found a solution, the only thing we can do is to upgrade the OS to fix the possible holes asap - but that won't protect anyone who not update direct after each new release. And oem's usally needs aslo time to update there stuff, if they not already gave up due the massive fragmentation.
I use a boot pass phrase that has over 60 characters. This one was used for encryption, as opposed to a screen pin. You can only do it via adb shell.... Again, it is all about implementation.
Click to expand...
Click to collapse
Yes and because of implementation there are always security holes, possible risk and negative side-effects and because of this there will always a way to crack thinks as long if you're rooted.
And again because you use that it not means the mass use this - I'm not the only one who complains about that several known security experts and on several sites a lot of people saying that the length of the password is always a problem. Sure there are a lot of tools, but in our case they only works after a login and again ... mostly only experts using them.
A lot of people over-estimate spook's abilities. Despite the recent revelations: they can't do magic, meaning breaking encryption and they know it. That's why they are colluding with everyting that "moves" to put backdoors, weaken number generation, force weaker ciphers and so on.
Click to expand...
Click to collapse
Maybe, maybe not. Maybe NSA already have the ability to crack it with some exploits, maybe not - but we can bet on it they are working on it right know we talking about it. But why holidng on stuff that is placebo? There are already problems which can't be denied.
So we are now a bit off-topic, but if you believe the myth that it can't be bypassed you must be naive it was done in the past and it will be soon or later with lollipop with tools every script kiddy can use (like on 4.x). That's not what I call implementation related, it's also not encryption related it's the fact that as long users can side-load stuff or execute root it's only a matter of time - that was and ever will a possible security risk (not only on Android).
pikatchu said:
May I ask you if using an xposed module is a risk for the whole system itself? It shouldn't be too hard to abuse it and to bypass xprivacy itself and the Android firewall.
Click to expand...
Click to collapse
Don't use any xposed module that is not open source
Use Afwall built in iptables binaries, as opposed to system ones or better move builtin iptables into your system
Prevent any xposed module including xprivacy and xposed framework from internet access
---------- Post added at 04:39 PM ---------- Previous post was at 03:50 PM ----------
CHEF-KOCH said:
Funny stuff, you not use gapps but you trust goggles encryption even if they already worked together in the past with GCHQ/NSA ...
Again apps are not the first line of defense, they are the last. Xprivacy can't protect/or fake mac address, ID's or your imei/phone number (please read the whole FAQ) and on Lollipop there are a lot of more restrictions generally and they are not all implemented yet.
Since Xprivacy needs root (or should I say the Xposed framework) this is also a possible security risk, the attacker can use adb (which can be rescricted by an app) to disable/uninstall/freeze XPrivacy or any other app even if you use them as admin (the app will once crash and not restart).
Erased? Are you sure? I don't think so I guess the os will just shutdown but to erase something would be horrible.
Yes, and this is a mistake here in this thread, people forgett that most users are not experts, they not even know about XPrivacy/AFWall+ or root. The benefit of encryption should that all people even without bigger knowledge can handle it without disadvantages or other hints. So that already failed, google now reverted there own statement which means the encryption will not default enabled for all (see my links for there statement: In short - OEM complaining about performance!).
So security isn't activated from the beginning which is also a possible risk.
No it's not and you not understand it the I/O performance is slower, that can be a little bit different from device to device (due other hardware) but it's definitely noticeable (and not only in benchmarks) - please read the links. Not every use high end devices, never forget it -> again security should be available for all and the fact google reverted it clearly shows that we are not ready yet.
It's a matter of time anyone found a solution, the only thing we can do is to upgrade the OS to fix the possible holes asap - but that won't protect anyone who not update direct after each new release. And oem's usally needs aslo time to update there stuff, if they not already gave up due the massive fragmentation.
Yes and because of implementation there are always security holes, possible risk and negative side-effects and because of this there will always a way to crack thinks as long if you're rooted.
And again because you use that it not means the mass use this - I'm not the only one who complains about that several known security experts and on several sites a lot of people saying that the length of the password is always a problem. Sure there are a lot of tools, but in our case they only works after a login and again ... mostly only experts using them.
Maybe, maybe not. Maybe NSA already have the ability to crack it with some exploits, maybe not - but we can bet on it they are working on it right know we talking about it. But why holidng on stuff that is placebo? There are already problems which can't be denied.
So we are now a bit off-topic, but if you believe the myth that it can't be bypassed you must be naive it was done in the past and it will be soon or later with lollipop with tools every script kiddy can use (like on 4.x). That's not what I call implementation related, it's also not encryption related it's the fact that as long users can side-load stuff or execute root it's only a matter of time - that was and ever will a possible security risk (not only on Android).
Click to expand...
Click to collapse
GAPPS vs. Google encryption: I can't examine or modify GAPPS, but I can Google encryption, which is open source
Xposed modules: Xposed framework needs root once only during installation. After that you can revoke root permission
Attacker use of ADB: no matter what attacker does, he can't mount Data. Even on a live device, if pings are disabled, as well as all incoming connections, there is no way to reach the system over the internet. Now, I am not talking about baseband or simcard exploits, but if you face that kind of an attacker, then you don't use cell phones at all. The point stands: if your phone is off and it is properly encrypted, there is virtually no way to get the data. And I say virtually only because of baseband/simcard exploits.
Erasing data: If you look at lollipop's /system/vold/cryptfs.c and .h, you will see that erasing data is implemented after 10 unsuccessful attempts (the number could be reduced).
Low end devices vs. high end; regular user vs. advanced: you can't have a product that will satisfy all. You can't lower safety standards to satisfy the low end regular user. 2015 Mercedes is safer on the road than 1976 Honda. If you have advanced knowledge, you'll benefit more than a regular user. And if that user refuses to help himself, he will have to face the consequences.. That's the way Linux (and Android is its ugly daughter) is built...
GAPPS vs. Google encryption: I can't examine or modify GAPPS, but I can Google encryption, which is open source
Click to expand...
Click to collapse
Open source isn't a guarantee for security. I'm tired to saying this over and over again here on xda and in other forums. And no, it's not open source since most devices comes with own stock android builds which may use other hardware/drivers and maybe other or touched encryptions. There is also no guarntee that it hold what it promise as long nobody can proof or deny it.
Xposed modules: Xposed framework needs root once only during installation. After that you can revoke root permission
Click to expand...
Click to collapse
Once is more than enough, to get infected by faked Xposed Installers or other possible attacks. You scenarios are very unrealistic, nobody only use root only for one single module - You can't tell me that. Attackers don't need to mount data if you installed apps on external sdcard which isn't encrypted.
as well as all incoming connections, there is no way to reach the system over the internet.
Click to expand...
Click to collapse
Incoming connections are not necessary, outgoing is more important to send data to a eg. C&C.
The point stands: if your phone is off and it is properly encrypted, there is virtually no way to get the data. And I say virtually only because of baseband/simcard exploits.
Click to expand...
Click to collapse
Sure but it's unrealistic too, I will use the phone and not use encryption which can be attacked or bypassed except the phone is offline.
Erasing data: If you look at lollipop's /system/vold/cryptfs.c and .h, you will see that erasing data is implemented after 10 unsuccessful attempts (the number could be reduced).
Click to expand...
Click to collapse
Please give me the source, thanks. According to this normal userdata not getting any wipe on encryption fail and on other systems then EXT4 or F2FS nothing will be done (no access). And as long /data is not mounted there is also no access, that's the reason android temporary mount /data each time to promt for passwords, other processes and such (for more look in the documents)
I didn't know that but nvm it's unimportant since the master key is still on the device itself - which will definitely not erased and as said it not protect against privacy data stealing which is more important, nobody want you android files, only you passwords etc ...
Use Afwall built in iptables binaries
Click to expand...
Click to collapse
Iptables are not installed on every system and not working anymore since Android 5 need some extra flags like -pie and to replace the system own or installing them needs root too - oh, and to fix possible startup data leaks also needs root for init.d.
Low end devices vs. high end; regular user vs. advanced: you can't have a product that will satisfy all.
Click to expand...
Click to collapse
I'm not saying other stuff but you are the one which said that the performance impact is minimal and I'm the one which said encryption should work out of the box for all on any device - sure it's definitly an implementation thing, but as a workaround older devices may just simple lower the encryption e.g. 256 -> 128 Bit.
You can't lower safety standards to satisfy the low end regular user. 2015 Mercedes is safer on the road than 1976 Honda. If you have advanced knowledge, you'll benefit more than a clueless user who refuses to help himself....
Click to expand...
Click to collapse
I'm not comparing cars I only compare the encryption algos which haven't much changed over the years (just some fixes here and there but under the hood the car still needs 4 wheels).
We talked about encryption and possible attacks and you still can't deny them all. You try to find some excuses but under the line it will be cracked - and not in 10 years, this or next year I promise because of this reasons:
- Cracking the pins normally takes only seconds: they are simply to short or follow patterns due to being the same as the lock screen password. Practically speaking, the security of this entire story depends on the passphrase the user sets. If it is very long, it makes brute forcing difficult. But most people would set a 4/6/8 digit PIN, because who would want to enter a 20 digit password with alphabets and special characters every time you want to make a call or send a message?!
- Cracking Encryption in general -> Encrypted Master Key + Salt stored in footer and they are usually stored at the end of the partition or in a footer file on other partitions
- OEM's may use a different key management module
- Some forensic boot images are available which makes it possible to start early in the boot chain before the whole system loads ->
- Keyloggers or memory catcher allowing the attacker to capture unencrypted data -> including encryption keys and passwords for non encrypted content
- If the device is already compromised with malware it will be possible send things into the internet
- Some root kits already breaking most of all hard disk encryption such as the "Stoned" bootkit on TrueCrypt
- A factory reset also resets the master key
optimumpro said:
I have enabled 256 bit encryption; I have increased the length of various keys, as well as the number of iterations for random number generation; then I have disabled in kernel hardware based weakened random number generator and enabled all other methods inactive by default (thanks to google and sony for making it easier to break for spooks); I then disabled hardware overlay option, which causes slow down, so, now, there is no visible difference in performance with unencrypted device.
Click to expand...
Click to collapse
You already mentioned some of these things over at unclefab's "How To Secure Your Phone"-thread. Any chance to get some more detailed steps or even diffs of your changes?
Thanks!
CHEF-KOCH said:
Open source isn't a guarantee for security. I'm tired to saying this over and over again here on xda and in other forums. And no, it's not open source since most devices comes with own stock android builds which may use other hardware/drivers and maybe other or touched encryptions. There is also no guarntee that it hold what it promise as long nobody can proof or deny it.
Once is more than enough, to get infected by faked Xposed Installers or other possible attacks. You scenarios are very unrealistic, nobody only use root only for one single module - You can't tell me that. Attackers don't need to mount data if you installed apps on external sdcard which isn't encrypted.
Incoming connections are not necessary, outgoing is more important to send data to a eg. C&C.
Sure but it's unrealistic too, I will use the phone and not use encryption which can be attacked or bypassed except the phone is offline.
Please give me the source, thanks. According to this normal userdata not getting any wipe on encryption fail and on other systems then EXT4 or F2FS nothing will be done (no access). And as long /data is not mounted there is also no access, that's the reason android temporary mount /data each time to promt for passwords, other processes and such (for more look in the documents)
I didn't know that but nvm it's unimportant since the master key is still on the device itself - which will definitely not erased and as said it not protect against privacy data stealing which is more important, nobody want you android files, only you passwords etc ...
Iptables are not installed on every system and not working anymore since Android 5 need some extra flags like -pie and to replace the system own or installing them needs root too - oh, and to fix possible startup data leaks also needs root for init.d.
I'm not saying other stuff but you are the one which said that the performance impact is minimal and I'm the one which said encryption should work out of the box for all on any device - sure it's definitly an implementation thing, but as a workaround older devices may just simple lower the encryption e.g. 256 -> 128 Bit.
I'm not comparing cars I only compare the encryption algos which haven't much changed over the years (just some fixes here and there but under the hood the car still needs 4 wheels).
We talked about encryption and possible attacks and you still can't deny them all. You try to find some excuses but under the line it will be cracked - and not in 10 years, this or next year I promise because of this reasons:
- Cracking the pins normally takes only seconds: they are simply to short or follow patterns due to being the same as the lock screen password. Practically speaking, the security of this entire story depends on the passphrase the user sets. If it is very long, it makes brute forcing difficult. But most people would set a 4/6/8 digit PIN, because who would want to enter a 20 digit password with alphabets and special characters every time you want to make a call or send a message?!
- Cracking Encryption in general -> Encrypted Master Key + Salt stored in footer and they are usually stored at the end of the partition or in a footer file on other partitions
- OEM's may use a different key management module
- Some forensic boot images are available which makes it possible to start early in the boot chain before the whole system loads ->
- Keyloggers or memory catcher allowing the attacker to capture unencrypted data -> including encryption keys and passwords for non encrypted content
- If the device is already compromised with malware it will be possible send things into the internet
- Some root kits already breaking most of all hard disk encryption such as the "Stoned" bootkit on TrueCrypt
- A factory reset also resets the master key
Click to expand...
Click to collapse
Wipe after 10 attempts, see here https://github.com/CyanogenMod/android_device_qcom_common/blob/cm-12.0/cryptfs_hw/cryptfs_hw.c
A factory reset wipes data, so whatever happens to master key is not significant. But even if the master key is reset, there is no use of it in terms of trying to get previously encrypted data. And by the way, the term reset is not correct: if you do a regular reset, the master key is not touched, as it is not sitting on data partition and if you wipe system and data, your master key is gone and the new one will be generated only when you enable encryption again.
I don't understand your consistent point that users won't bother with long passwords, when Android provides for separate passwords one for boot/encrption and another for screen (which is not used for encryption). As I have already said, I use an over 60 character boot password and a short screen pin. If I need to reboot the device, I use soft reboot, which does not require the password at all. So, having a long password does not create any undue burden.
Again, data/disk encryption is valuable, because it protects your device when it is off, meaning, no one can access your data... I have close to personal experience with "sophisticated attackers": they can do nothing with properly encrypted device that is turned off...
Closed source vs. open source. I am not saying open source is secure. I am saying that open source could be examined unlike proprietary one.
My last words on this:
Well in the source nothing to user data gets wiped, only stuff that protects android system related files which proofs that the user data aren't safe if someone use forensic image and cloned everything.
Short screen pins can be cracked in minutes so as long we can sideloading anything before or after a boot especially if not all stuff is mounted it is still a risk.
Fastboot/softboot or whatever you want to call it isn't available on every device so you whole argumentation about complex passwords are useless (for example a friend of mine recently got the LG G3 which had fastboot deactivated). And of course if you got an error like kernel panic or other crash you can't fast reboot which also required that complicated and complex password - especially on mobile devices this is pretty annoying.
Again FDE on Android is placebo that's all, as long the user can dump the whole system and crack it on a PC which is powerful enouth it will be always useless. Apple use a unique key (if we can believe it) which can't be extracted with any tool or read out during the boot (maybe some day but I don't know any tool yet) so everything like brute force must be directly on the device which takes a lot of more time compared to a computer with an external powerful nvidia card and tools like hashkill/hashcat.
About explaining closed source, if you are good enouth you can reverse engineering most of the code - you don't even need to deobfuscate all stuff but in most time if you know the basics you know which weakness e.g. the encryption may have.
As long you not understand that sideloading is the biggest problem in android you not understand that all can be cracked soon or later and because you use xyz do not means that millions of stock users doing such complicated steps too to "secure" the phone which do not protect all stuff except the os itself. Android has defenses yes, but it is more to protect itself and not the private data that's the conclusion. It's a good step what was made with lollipop but there are still attacks which can't be that easily blocked, especially if the user doesn't know how or most if the mechanism are deactivated or simply to complex.
CHEF-KOCH said:
My last words on this:
Well in the source nothing to user data gets wiped, only stuff that protects android system related files which proofs that the user data aren't safe if someone use forensic image and cloned everything.
Short screen pins can be cracked in minutes so as long we can sideloading anything before or after a boot especially if not all stuff is mounted it is still a risk.
Fastboot/softboot or whatever you want to call it isn't available on every device so you whole argumentation about complex passwords are useless (for example a friend of mine recently got the LG G3 which had fastboot deactivated). And of course if you got an error like kernel panic or other crash you can't fast reboot which also required that complicated and complex password - especially on mobile devices this is pretty annoying.
Again FDE on Android is placebo that's all, as long the user can dump the whole system and crack it on a PC which is powerful enouth it will be always useless. Apple use a unique key (if we can believe it) which can't be extracted with any tool or read out during the boot (maybe some day but I don't know any tool yet) so everything like brute force must be directly on the device which takes a lot of more time compared to a computer with an external powerful nvidia card and tools like hashkill/hashcat.
About explaining closed source, if you are good enouth you can reverse engineering most of the code - you don't even need to deobfuscate all stuff but in most time if you know the basics you know which weakness e.g. the encryption may have.
As long you not understand that sideloading is the biggest problem in android you not understand that all can be cracked soon or later and because you use xyz do not means that millions of stock users doing such complicated steps too to "secure" the phone which do not protect all stuff except the os itself. Android has defenses yes, but it is more to protect itself and not the private data that's the conclusion. It's a good step what was made with lollipop but there are still attacks which can't be that easily blocked, especially if the user doesn't know how or most if the mechanism are deactivated or simply to complex.
Click to expand...
Click to collapse
And here are my last words. Click the link in the previous post and you will see code to wipe user data. There is annotation that says we will wipe everything related to encryption followed by the code itself that contains the words "wipe user data":
} else {
if(ERR_MAX_PASSWORD_ATTEMPTS == err)
wipe_userdata();
With regard to cracking everything soon, this is just your opinion that is not based on known facts. And one of the facts is that if spooks could break the encryption, they wouldn't need back doors and weakening.
Again, I fail to understand your point about users not using long screen passwords. You don't need long ones for your screen. But let's leave it there and agree to disagree.
bastei said:
You already mentioned some of these things over at unclefab's "How To Secure Your Phone"-thread. Any chance to get some more detailed steps or even diffs of your changes?
Thanks!
Click to expand...
Click to collapse
Look here for kernel changes:
https://github.com/AOSP-Argon/android_kernel_sony_msm8974/commit/29d918c1f11247602c58096a62084811bccc328f
// When device comes up or when user tries to change the password, user can
// try wrong password upto a certain number of times. If user enters wrong
// password further, HW would wipe all disk encryption related crypto data
// and would return an error ERR_MAX_PASSWORD_ATTEMPTS to VOLD. VOLD would
// wipe userdata partition once this error is received.
#define ERR_MAX_PASSWORD_ATTEMPTS -10
#define QSEECOM_DISK_ENCRYPTION 1
#define MAX_PASSWORD_LEN 32
Click to expand...
Click to collapse
It won't touch userdata at all, it wipes only (as written) disk encryption related data stuff but I'm talking about sideloading user data and this will never be wiped since this will destroy other stuff too - so this prevents only some attacks if you just start you're phone. - Or if you dump the data without - in a locked state - the master key.
The stuff you linked is also different from my link from AOSP project since it's CM, also a mistake, because CM isn't stock or based on OEM's firmware. So all you're stuff may applies only to custom firmwares - I'm talking again about stuff which use the mass and not only certain "expert" people.
Look here for kernel changes:
Click to expand...
Click to collapse
This is also from CyanogenMod which also only affects /cache/recovery which doesn't matter if the system was already booted success and (as shown) some stuff was already compromised or running in the background.
With regard to cracking everything soon, this is just your opinion that is not based on known facts. And one of the facts is that if spooks could break the encryption, they wouldn't need back doors and weakening.
Click to expand...
Click to collapse
Yes and your wrong opinion is that it isn't crackable, same was said years ago about TrueCrypt which now is labeled as unsafe and I already mentioned tools which break it.
Seems you're to ignorant to understand which possible negative effects may comes with side-loading. As long you not understand this we can stop the entire discussion here (I already gave up because you don't know s much as I do which tools can break stuff) - it will be cracked and the the dm-crypt stuff was already cracked in Android 4. because of some fixes that doesn't mean anything. Again, because you use xyz that doesn't mean all use the same stuff you already ignored this several times now and I already said that - but okay.
CHEF-KOCH said:
It won't touch userdata at all, it wipes only (as written) disk encryption related data stuff but I'm talking about sideloading user data and this will never be wiped since this will destroy other stuff too - so this prevents only some attacks if you just start you're phone. - Or if you dump the data without - in a locked state - the master key.
The stuff you linked is also different from my link from AOSP project since it's CM, also a mistake, because CM isn't stock or based on OEM's firmware. So all you're stuff may applies only to custom firmwares - I'm talking again about stuff which use the mass and not only certain "expert" people.
This is also from CyanogenMod which also only affects /cache/recovery which doesn't matter if the system was already booted success and (as shown) some stuff was already compromised or running in the background.
Yes and your wrong opinion is that it isn't crackable, same was said years ago about TrueCrypt which now is labeled as unsafe and I already mentioned tools which break it.
Seems you're to ignorant to understand which possible negative effects may comes with side-loading. As long you not understand this we can stop the entire discussion here (I already gave up because you don't know s much as I do which tools can break stuff) - it will be cracked and the the dm-crypt stuff was already cracked in Android 4. because of some fixes that doesn't mean anything. Again, because you use xyz that doesn't mean all use the same stuff you already ignored this several times now and I already said that - but okay.
Click to expand...
Click to collapse
I guess we speak different languages. My point is (and it stands) that if encryption is properly implemented, there is no way to get data from unmounted encrypted partition. Let's forget about wiping, any sophisticated attacker will take an image of the device and then try to break a copy. However, to mount data, he will have to bruteforce my 60 character password that will unlock master key or break 256 bit AES. Good luck on either front. And I am not talking about stock, aosp or Cm roms. It makes no difference, the bottom line is he won't be able to do either of the above. I also don't care about careless users. They have a right to be ignorant and most enjoy it very much. Linux (on which Android is based) was not created for ignorant users...
So I'm selling my old Meizu M2 Note which is running Flyme OS that doesn't allow me to encrypt the whole phone. How can I ensure the data is actually gone before selling? Normal wiping doesn't erase everything.
That's a good but hard to answer question.
A good old fashioned hard drive can be single pass overwritten (debate about overwrite passes is still an open discussion) making it unrecoverable for anything but an MFT, Mobile devices use flash memory just like a USB drive or an SSD.
What is the difference? Wear leveling (https://en.wikipedia.org/wiki/Wear_leveling).
Because of that people came up with crypto-shredding or crypto erase which only truly works with Hardware Encryption because Software encryption can never, with 100% certainty, know how the wear leveling reacts on every device.
You already said this isn't an option so what can you do to be sure nothing can be recovered? The answer is unfortunately short, nothing.
However recent research showed that multi pass overwriting caught a lot of data but even the Gutmann method (35 passes) did not get rid of everything (I forgot the link to the Whitepapers).
That said, you aren't selling it to a forensic specialist.
My best suggestion is to use one of the higher rated wiping apps (Shreddit for example) to first destroy your files, then factory reset and download a few good recovery apps and again a wiping app. Make sure you can't recover your own files anymore (if you have very sensitive data you can connect it to a PC and use even better recovery or, if you are paranoid, forensic tools) then overwrite it with as many passes, rounds and algorithms you feel comfortable with. Check recovery tools again and call it a day when you feel satisfied.
This WILL eat at the wear level so keep that in mind when you want to start overdoing it.
Not everything will be gone but it's as good as it's going to get and I highly doubt the person you sell it to will be able to recover anything.
Good luck!
GU42 said:
So I'm selling my old Meizu M2 Note which is running Flyme OS that doesn't allow me to encrypt the whole phone. How can I ensure the data is actually gone before selling? Normal wiping doesn't erase everything.
Click to expand...
Click to collapse
#noob guide incoming
(potentially useless and harmful)
i just thought of it
shred memory
download custom rom and flash
fill memory with stuff
shred again
xD
TheMarchHare said:
That's a good but hard to answer question.
A good old fashioned hard drive can be single pass overwritten (debate about overwrite passes is still an open discussion) making it unrecoverable for anything but an MFT, Mobile devices use flash memory just like a USB drive or an SSD.
What is the difference? Wear leveling.
Because of that people came up with crypto-shredding or crypto erase which only truly works with Hardware Encryption because Software encryption can never, with 100% certainty, know how the wear leveling reacts on every device.
You already said this isn't an option so what can you do to be sure nothing can be recovered? The answer is unfortunately short, nothing.
However recent research showed that multi pass overwriting caught a lot of data but even the Gutmann method (35 passes) did not get rid of everything (I forgot the link to the Whitepapers).
That said, you aren't selling it to a forensic specialist.
My best suggestion is to use one of the higher rated wiping apps (Shreddit for example) to first destroy your files, then factory reset and download a few good recovery apps and again a wiping app. Make sure you can't recover your own files anymore (if you have very sensitive data you can connect it to a PC and use even better recovery or, if you are paranoid, forensic tools) then overwrite it with as many passes, rounds and algorithms you feel comfortable with. Check recovery tools again and call it a day when you feel satisfied.
This WILL eat at the wear level so keep that in mind when you want to start overdoing it.
Not everything will be gone but it's as good as it's going to get and I highly doubt the person you sell it to will be able to recover anything.
Good luck!
Click to expand...
Click to collapse
Thanks for your amazing reply!
I finally found the solution I was looking for: as Avast! support told me, you can still use Avast! Mobile Security to securely erase your phone (by overwriting data), it's just a hidden feature. You just have to deactivate the Device Administrators permission for the app.
Then you just use the "erase device."
Was that research about multi pass overwriting done on SSD, or HDD? I always thought that one pass is enough on a standart HDD.
Can you recommend me any good forensic tools to use to check if the data is truly erased, please? And does the phone need to be rooted in order to restore deleted data?
Thanks for all your insight and advice !
GU42 said:
Thanks for your amazing reply!
I finally found the solution I was looking for: as Avast! support told me, you can still use Avast! Mobile Security to securely erase your phone (by overwriting data), it's just a hidden feature. You just have to deactivate the Device Administrators permission for the app.
Then you just use the "erase device."
Was that research about multi pass overwriting done on SSD, or HDD? I always thought that one pass is enough on a standart HDD.
Can you recommend me any good forensic tools to use to check if the data is truly erased, please? And does the phone need to be rooted in order to restore deleted data?
Thanks for all your insight and advice !
Click to expand...
Click to collapse
Avasts shredder works but it's a single pass on flash memory so it doesn't clear everything with 100% certainty because of the wear leveling but no algorithm does. I'm pretty sure that's a feature they added after purchasing CCleaner.
They also added it as a module in their windows platform.
The multi pass research was done on Solid State Drives and I still can't find the link. Just from a research paper in 2011.
SSD's are still closest in comparison to the kind of memory used in Mobile devices.
As for HDD's it's an open debate. Forensics have claimed to be sble to read past 200 writes in the past but there is no research to support this. I believe that they showed that 1 pass PRNG is enough in 2005, however the DoD was still developing machines to perform 7 pass DoD standard wipes so, I have to say that I have no idea.
If you want serious forensic tools you're looking at these kind of distributions (infosec just made me laugh, SSL_ERR_CERT_COMMON_NAME_INVALID, it's infosec! ??).
http://resources.infosecinstitute.com/computer-forensics-tools/
But if anyone you sell it to would try something it would be more along the lines of Recuva and similar software.
On phones you can just download a bunch of high rated recovery tools and see if anything pops up.
You do not need root for most of them.
You could run fstrim which I'm pretty sure has no root requirements either. This would mark all blocks as invalid so Garbage Collection can pick it up as well. Even though GC has been show not to clean everything it doesn't hurt.