Database Info

Remote Wipe with CyanogenMod??

Hi all,
I've just found out that the exchange server I connect to at work will soon enable remote wipe capabilities for security purposes.
I'm running cyanogenmod 5.0.7 on my HTC Dream. Not knowing a lot about remote wipe, will they still be able to do it even though I have this custom Rom?
I'm assuming that if they do a remote wipe, I can just boot into the recovery and restore a nandroid backup?
I don't expect them to do it but I just want to understand the repercutions if I enable email on my phone.
Geoff

IIRC, that feature was included in Android 2.2.

I'm currently using 5.0.7 of cyanogen though so it's only 2.1. I'm assuming then a remote wipe can still be done on a custom rom?
Is it as easy as going into the recovery and restoring a backup in the event a remote wipe is done?

If the exchange client and server both support it then yeah, you'll be able to remote wipe. This will only wipe your emails though.. not your whole phone..

You cannot enable remote wipe as a feature in the stock email client in android 2.1 regardless of which rom you are using
You have 2 options, either install Touchdown from the market (which costs money) or run Android 2.2, currently the only rom that I know of built on 2.2 is here http://forum.xda-developers.com/showthread.php?t=686105

I'm already using touchdown. I was told at work though that a remote wipe will wipe the phone, not just email.

sounds like a need for a new app
Seems like what is needed is an app that tells the server that it supports remote wipe, complex passwords, etc, and then doesn't do anything unless the end user allows it.
When somebody pays for my phone they can put whatever back door on it they want. Until then, I'll put in my own back doors...

rich0 said:
Seems like what is needed is an app that tells the server that it supports remote wipe, complex passwords, etc, and then doesn't do anything unless the end user allows it.
When somebody pays for my phone they can put whatever back door on it they want. Until then, I'll put in my own back doors...
Click to expand...
Click to collapse
And then have that app fake it's device string so it would appear as Touchdown or some other well-behaved app. I like it.

gleff1 said:
I'm already using touchdown. I was told at work though that a remote wipe will wipe the phone, not just email.
Click to expand...
Click to collapse
Heh. That would be contrary to android security implementation. Letting windoze to remotely interfere with an android phone would be REALLY BONEHEADED.
Simply put, the application would have to have SYSTEM permissions, which it simply isn't going to / can't have unless it was installed as part of the system image. ANY kind of add-on application WILL NOT have the permission required to interfere with your phone unless you do something REALLY dumb, like authorizing root access (assuming that the application even knows to ask for it, which is unlikely).
There *IS* a possibility that froyo "enterprise" features would implement this capability, but if you have control over the device, it would simply be a matter of disabling that application.
IN GENERAL, such security features would only be possible on devices that are (1) owned by somebody besides you, (2) configured by those who own it to do so. Simply connecting to some MS server MUST not be sufficient for them to interfere with your phone.
And to be honest with you, I would NEVER allow anything I use to connect to an MS server. I absolutely do NOT trust them. MS probably steals all your information without telling you. They're evil like that.

The person in your IT dept that told it wiped the entire device is not telling you the entire truth. This is taken directly from Microsoft Technet:
Perform a Remote Wipe on a Mobile Phone
[This topic's current status is: Content Complete.]
Applies to: Exchange Server 2010 Topic Last Modified: 2009-10-13
Microsoft Exchange Server 2010 enables you to send a command to a mobile phone that will perform a wipe of that phone. This process, known as a remote device wipe, clears all Exchange information that's stored on the mobile phone. You can use the EMC or the Shell to perform a remote wipe on a mobile phone.
You can use this procedure to clear data from a stolen phone or to clear a phone before assigning it to another user.
Now, there are MANY administrative options for the Remote Wipe tool. Most organizations only worry about the Exchange side. The other options are dependent on a device having a true 1to1 ActiveSync Partnership. Android devices do not have this, Only WinMo devices do. So, no, your phone will not be wiped clean if they initiate a remote wipe, only your corporate email.

W.O.P.R said:
The person in your IT dept that told it wiped the entire device is not telling you the entire truth.
Click to expand...
Click to collapse
Actually, I.T. staff member *is* correct: "In addition to resetting the mobile phone to factory default condition, a remote device wipe also deletes any data on any storage card that's inserted in the mobile phone"
http://technet.microsoft.com/en-us/library/bb124591.aspx

Good For Enterprise

Has anyone been able to get this working with Root? I install fine, enter my pin and it goes through but since I have root it doesnt sync. Im running liberty, any suggestions

matt1313 said:
Has anyone been able to get this working with Root? I install fine, enter my pin and it goes through but since I have root it doesnt sync. Im running liberty, any suggestions
Click to expand...
Click to collapse
Checking for root is configurable by your IT area. My account is not setup to check for root but I have had other problems. Can you easily unroot and reroot your device so Good would work except for the rare times that you actually need root? One problem I have had is the initial setup would never complete (stops at retrieving policies) unless I go back to stock eclair, get it working and back it up via Titanium backup, then upgrade to Froyo or GB, and then restore it. Mine continues to work via root though. The other problem I have had is if I ever restore to an earlier state (using the same PIN), it will stop syncing. I need a new PIN issued to get it working again.

I'm reading that IT admins can lock your phone camera, wipe SD card, etc.
What other kinds of things can they do once "Good for Enterprise" is installed on your personal phone?

Nate2 said:
I'm reading that IT admins can lock your phone camera, wipe SD card, etc.
What other kinds of things can they do once "Good for Enterprise" is installed on your personal phone?
Click to expand...
Click to collapse
I was involved in piloting "Good for Enterprise" for my company. I do know that the possible "controls" vary depending on the platform. Good for Enterprise on the IPhone will have much more control because the devices (hardware) and OS are very limited compared to Android. Keep that in mind as you read some of these items if they don't mention which platform. Also, the Good application would have to be granted root access to your phone "I believe" in order to do any of the items you mentioned. If you are running a custom ROM and have the "SuperUser" app, you would see if it had that access. I "think" it will be very hard for Good to implement some of those controls unless the Android OS provides an API for it because the underlying hardware can vary so much. I'm not a developer but I think that is correct.
Also, if you work for any decent sized company, they will be very concerned about the legal aspects of company provided software deleting (or even reading) personal information outside the "Good container". I mention the word container because Good provides encryption of everything within the app so it can not be read by anything outside the app (such as root explorer). I have successfully backed up and restored the encrypted data to another ROM but it is just bits to Titanium Backup or anything else. Feel free to PM me if you have any other questions on it that I might be able to answer. I know the admin for Good for our company that I could ask other questions.

I'm reading that the installation can detect jailbroken iPhones and rooted Android devices, and if the IT admins decide, they can configure it to refuse installation on such devices to prevent compromising Good's security/integrity of its resources.
(I'm not rooted, and don't plan to root my DroidX, so it is a moot point for me)
I heard from Verizon that IT admins can remotely control hardware components, including cameras, Bluetooth and IR ports, SD Cards, and more.
Things I'd like to know... can IT admins:
Track/monitor internet usage on the device?
Track/monitor GPS usage?
Copy non-Good related resources (e.g. files) from the device or SD card?
Lock the device?
Locate the device?
Wipe non-Good related resources?
Does the Good app send device System Logs to the IT folks?
Phone call logs?
App Permissions:
YOUR ACCOUNTS
ACT AS AN ACCOUNT AUTHENTICATOR Allows an application to use the account authenticator capabilities of the AccountManager, including creating accounts and getting and setting their passwords.
MANAGE THE ACCOUNTS LIST Allows an application to perform operations like adding, and removing accounts and deleting their password.
SERVICES THAT COST YOU MONEY
DIRECTLY CALL PHONE NUMBERS Allows the application to call phone numbers without your intervention. Malicious applications may cause unexpected calls on your phone bill. Note that this does not allow the application to call emergency numbers.
NETWORK COMMUNICATION
FULL INTERNET ACCESS Allows an application to create network sockets.
YOUR PERSONAL INFORMATION
READ CONTACT DATA Allows an application to read all of the contact (address) data stored on your device. Malicious applications can use this to send your data to other people.
READ SENSITIVE LOG DATA Allows an application to read from the system's various log files. This allows it to discover general information about what you are doing with the device, potentially including personal or private information.
WRITE CONTACT DATA Allows an application to modify the contact (address) data stored on your device. Malicious applications can use this to erase or modify your contact data.
PHONE CALLS
READ PHONE STATE AND IDENTITY Allows the application to access the phone features of the device. An application with this permission can determine the phone number and serial number of this phone, whether a call is active, the number that call is connected to and the like.
STORAGE
MODIFY/DELETE USB STORAGE CONTENTS
MODIFY/DELETE SD CARD CONTENTS Allows an application to write to the USB storage. Allows an application to write to the SD card.
SYSTEM TOOLS
RETRIEVE RUNNING APPLICATIONS Allows application to retrieve information about currently and recently running tasks. May allow malicious applications to discover private information about other applications.
PREVENT DEVICE FROM SLEEPING Allows an application to prevent the device from going to sleep.
YOUR ACCOUNTS
DISCOVER KNOWN ACCOUNTS Allows an application to get the list of accounts known by the device.
HARDWARE CONTROLS
CONTROL VIBRATOR Allows the application to control the vibrator.
NETWORK COMMUNICATION
VIEW NETWORK STATE Allows an application to view the state of all networks.
VIEW WI-FI STATE Allows an application to view the information about the state of Wi-Fi.
SYSTEM TOOLS
READ SYNC STATISTICS Allows an application to read the sync stats; e.g., the history of syncs that have occurred.
AUTOMATICALLY START AT BOOT Allows an application to have itself started as soon as the system has finished booting. This can make it take longer to start the device and allow the application to slow down the overall device by always running.
KILL BACKGROUND PROCESSES Allows an application to kill background processes of other applications, even if memory isn't low.
Sent from my unrooted DroidX using XDA App

I've been using EVO CM7 nightlies for quite a while now and never had issues with Good for Enterprise. With last 3 versions of nightlies, Good hasn't worked. When trying to reinstall Good, it says there is no phone network when trying to register. When looking at Device Info in Good setup screen, it doesn't have a phone number. Tried clearing, data, all cache, etc.
Is anyone else having this issue? It's like CM7 is not sending the phone string to Good when calling it.
A coworker also uses CM7 (not nightlies) and has no issues with Good on EVO. The phone number shows up in Good device info on his EVO.

I had the same problem, but I'm luckily an admin at our company on the good software. After messing around with it... this is what I had to do.
1. Uninstall Good from your phone on CM7 (Must be uninstalled at first for this to work....)
2. Reboot into Recovery and make a Nandroid Backup
3. Wipe the both Caches and Data, Install a Sense Rom
4. Install Good Mobile and have you admin resend you the email to enroll your phone
5. After entering the code and entering a password.. the Good will try to pull emails... kill the good app before this.
6. With Titinium Backup, backup Good and its Data.
7. Reboot into recovery.
8. Wipe the both Caches and the Data... Recover your previous CM7 Nandroid backup.
9. In CM7 launch Titanium backup and restore Good Mobile and its Data.
Worked after that... this way Good would communicate with the phone during the enrollment... which for some reason with CM7 it doesn't work... and just complains about not being connected to your mobile network.

Coincidentally I've just put up another post relating to IMSI numbers which was prompted by Good refusing to activate as some devices are reporting the same 1st 6 digits of their IMSI rather than the full 15 that Good uses to authenticate the license relative to the specific SIM card the license is for. Has anyone else come across this issue with Good?

matt1313 said:
Has anyone been able to get this working with Root? I install fine, enter my pin and it goes through but since I have root it doesnt sync. Im running liberty, any suggestions
Click to expand...
Click to collapse
Mine quit syncing after the first day. I had to upgrade my personal unlimited data plan to a corporate/enterprise data plan for an additional $15/month with Verizon, and reinstall Good.
Sent from my unrooted DroidX using XDA App

Sievers said:
I had the same problem, but I'm luckily an admin at our company on the good software. After messing around with it... this is what I had to do.
1. Uninstall Good from your phone on CM7 (Must be uninstalled at first for this to work....)
2. Reboot into Recovery and make a Nandroid Backup
3. Wipe the both Caches and Data, Install a Sense Rom
4. Install Good Mobile and have you admin resend you the email to enroll your phone
5. After entering the code and entering a password.. the Good will try to pull emails... kill the good app before this.
6. With Titinium Backup, backup Good and its Data.
7. Reboot into recovery.
8. Wipe the both Caches and the Data... Recover your previous CM7 Nandroid backup.
9. In CM7 launch Titanium backup and restore Good Mobile and its Data.
Worked after that... this way Good would communicate with the phone during the enrollment... which for some reason with CM7 it doesn't work... and just complains about not being connected to your mobile network.
Click to expand...
Click to collapse
I previously had a similar problem that I mentioned above - on custom FROYO ROMs it would stop at retrieving policies but flashing to stock eclair, I could finish the setup (and let all current emails come in) and then backup via TB, flash to custom FROYO, then restore and it would be all set. However, when I recently reinstalled Good on Continuum 5.5, I decided to try to let it complete the setup and it did with no problem. I only tried that since my IT admin setup "self-service" for me. I can access a link where I can send a new PIN for my account since it can easily stop syncing. The PIN goes to your corporate email so it is safe to allow.
@Nate2 - sorry I didn't see your post previously. Yes, there are Good policies that can be setup to detect "jailbroken" IPhones, etc. At my company, Good on Android is still not a standard offering because corporate policies are limited to what they can do on Android due to the numerous OS and hardware combinations. However, I have been pushing simply putting trust in the Good encryption (AES 256 if I remember right). Looking at the permissions of the app makes it look at first glance like it can do anything. However, I don't think it is as extensive as it seems. The only "data" outside the Good container that can be read by the app "to my knowledge" is the contact info. This is because your IT administrator can allow Good to sync corporate contact info (in Good) to your phone's contact info. This allows you to easily see who is calling (rather than a phone #) if it is one of your corporate contacts. Although it can access (modify/delete) SD contents, it doesn't say "Read". I don't think I am "reading" too much into that... For internet access, I know Good is working on adding in internet access (from inside the Good container) so browser access is allowed. I am "guessing" this is mostly for IPhones, etc. where the IT admin could stop internet access outside the Good container. That way they could control internet access on a "corporate" device. This is speculation on my part, though. I do think it can send device logs which is required "I think" to detect root access. Look over all the permissions listed keeping in mind READ access to system logs and contact info only and it seems to fit. Therefore, I think they probably can detect that you enabled/disabled GPS but I "doubt" they can detect where you went since I don't "think" that goes in system logs that they pull. If you still have any question, send me a PM since I don't frequently check this thread.

Thanks RichMD.
I once worked in a large company where a sysadmin was fired for accessing the corporate e-mail of an employee (his ex-girlfriend). She reported the incident to HR. Possible access to additional sensitive resources on the phone makes these kinds of incidents worse, and that's why we should be cautious.
Sent from my unrooted DroidX using XDA App

An Introduction to Android Rooting for the Complete Beginner

There are a few of these guides around, but I thought to write my own. Hope it will be helpful! I'll keep the most up-to-date version on my site.
Rooting Android: What Is it?
If you've heard about "rooting" your Android phone, and are confused by what exactly it does, or don't understand the instructions you found on an obscure forum or blog post somewhere, this guide might help you make sense of things.
What Is "Root"?
"Root" is the name of the default administrative user in Unix. The user named "root" can do absolutely anything: edit or delete any file, start or stop any system service, and also add, remove or change the privileges of other users, so that they, too, could perform the same operation.
So, user "root" can actually bestow administrative privileges on any Android user, including the default one you use normally on the phone.
When you buy an Android phone, it normally does not let you login as user "root".
What Can User "Root" Do?
Your phone is really a general-purpose hand-held computer. People have written apps for it that can do the things like this:
Turn it into a wireless internet router, connecting to your 3G/4G network on one end, and broadcasting a wifi hotspot on another. You can thus connect your laptop to the internet from anywhere. "Tethering," but without cables!
Lets you overwrite any of the Android system files, customizing it to your heart's content. This lets you customize the built-in fonts, colors, keyboards, etc.
Lets you install newer versions of Android, beyond what your phone's vendor has provided.
Why stop at standard Android? Because Android is an open source operating system, people have been able to modify it to add features far and beyond what Google has put in it, as well as offering better performance in some situations. With administrative privileges, you can just flash an entire new Android ROM to your phone. A very popular one is CynaogenMod, which is based on Android 2.3.
Install various networking servers and clients, such as QuickSSHd to allow logging in to your phone over the internet, or CifsManager, which lets you access Windows shared drives from your phone.
Who knows? People might think of new users for these hand-held computers, uses that would require full access to all features of the phone.
Why Won't My Phone Normally Let Me Login As "Root"?
First, for reliability -- as far as you're concerned.
Imagine if your phone automatically gave you administrative access. This means that any app you install can do anything it wants to it. Obviously, unacceptable.
An alternate solution is available in newer versions of Windows and other desktop operating systems, which require you to enter a special administrative password whenever a program is trying to access secure parts of your computer. This is annoying enough on a desktop computer: on a phone, it would again be unacceptable.
So, it makes sense -- for your sake -- to disallow any administrative privileges.
Second, for reliability -- as far the phone vendor is concerned.
A smartphone, unlike a PC, is an expensive consumer device with an explicit support contract. People normally and frequently return phones to the shop if they stop working properly, or call customer support to get assistance. There's a huge cost for the vendor to maintain this support network.
Think for a minute what would happen if any phone user could login as "root" and delete any system file: you would have broken phones everywhere, frustrated consumers, and clogged support networks. Indeed, "rooting" a phone pretty much voids your warranty as far the vendor is concerned.
I Understand the Risks and Am Willing to Void the Warranty, So Why Can't I Login As "Root"? It's My Phone!
Even if logging in as "root" were an advanced feature, hidden away somewhere in the menus with thousands of warnings about possible dangers, you can bet that many non-advanced users would find it. When their phone breaks, you bet they will be angry, and will not care that the warnings were there. As far as they would be concerned, this "root" thing is a feature of their phone, and if it can break the phone then it shouldn't even be there.
And there's a third party who has a business interest in denying you "root": the telecommunication carriers. Their business model is designed around typical consumer uses of the phone, and they do not want it to be too powerful. For example, a "rooted" phone can let you tether it to a laptop, so that your laptop gets its internet access. But, carriers typically sell special "laptop sticks" for that purpose specifically, and these usually are more expensive than phone plans, because they take into account the much heavier bandwidth that laptop users tend to use. If everybody could "root" their phone and tether it, this product -- and source of revenue -- would be irrelevant.
So, Phones Don't Come with a "Root" User?
Android is based on the Linux operating system, which requires the "root" user to function. It's there. However, the vendor has tried to hide all the normal ways to access it. The "root" user is there, it's just "locked."
What Is "Rooting"?
In the context of Android phone, rooting means more than just letting you log in as the "root" user: it means installing a set of tools so that any of your programs can access "root" when then need to and you allow them.
The result is that "rooted" phone works just like Windows, in that it will ask you for permission (but not a password) whenever an app is trying to get administrative privileges.
Fortunately, once you gain access to the "root" user, it's very easily to install a set of standard apps that let you implement this feature, specifically the Superuser app.
How Do I Root My Phone?
Nothing in software can be truly locked down, and hackers have found ways to get "root" access on any Android phone on the market. There are quite a few holes.
But, these methods vary a lot and are different per phone. It's easier on some phones than others. It's often risky, too, because a misstep could potentially "brick" your phone -- making it so that you cannot boot into Android. "Unbricking" is possible in some cases, but not in others. Take care!
Search the internet, and you will likely find various blog and forums posts with instructions for rooting your particular phone model.
This is not a guide for rooting your particular phone model. Instead, it is a general description of what rooting is and how it works. It can help you understand the rooting instructions you find.
Any Downsides?
Well, first of all, there is the risk of bricking your phone. You might want to make sure that someone you know with the same model phone as you have has used the method before. Or, read about it in the internet forums, and make sure that lots of other people have used this method successfully.
Also, you may void your warranty: of course, this would only happen if customer support looks closely at your phone and notices that it has been rooted. It's a good idea to look at these rooting guides to see if there is an easy way to un-root the phone, or at least return it to factory settings.
Finally, there's the issue of "firmware updates" coming from your carrier. Sometimes they will work fine with rooted phones (as long as custom Android ROM has not been installed on them), but depending on the rooting method it may mean that won't work fine anymore. "Not working fine" can mean that the upgrades simply won't run, but it can also mean that the upgrades would fail terribly and brick your phone. Generally, if you have rooted your phone and are getting an "Update Available, Do you want to download?" message from your carrier, don't just say "yes," instead check the forums to see the experience of other people with rooted phones with this update. Generally this problem seems rare, a result of a very poor upgrade package from the vendor -- the usual case is that the upgrade simply won't work.
Don't worry too much: with a rooted phone (and a good Recovery program, see below) you will likely be able to install the upgrade yourself, and possibly better upgrades to more advanced versions of Android than your vendor provides.
How Rooting Works
First, let's understand how the locking down happens.
Your phone actually has more than just Android installed on it. There are, at minimum, three and usually four "partitions" in which entirely different programs are installed. Android is just one of them.
The Boot Loader
The first partition has the boot loader, the very first program see when you turn on the phone normally. The boot loader's main job is simply to boot other partitions, and by default it just boots the Android partition, commonly called the ROM (described below). So, you don't really see the boot loader for very long.
However, all phones allow for a special way of turning them on -- for example, holding the volume up button while pressing the power on button -- that shows the boot loader menu.
When you're there, you can actually choose if you want to boot into the Android partition, or you can boot into the Recovery partition (described in detail below).
The interesting thing about the boot loader is that it is very, very simple. It has no mechanism for users and privileges. One way to look at it is that it always is "root," and in fact can't be anything else.
Sounds like a good place from which to unlock your phone! Unfortunately, most boot loaders are too simple.
One exception is the boot loader found in Google's Nexus phones, and in a few other developer-friendly phones. These boot loaders can actually communicate with a PC over USB, and support writing data to partitions ("flashing" them), as well as booting from them. With this feature, you can flash an unlocked Android ROM to the Android partition, and you're done! Well, the challenge is just to find such a ROM that works well with your phone...
Most phones don't have such a flexible boot loader. However, getting into the boot loader menu is important, because it lets you boot into the Recovery partition, detailed next.
The Recovery Partition
As its name can tell you, this partition is mostly for customer support: the Recovery program can be used to return the Android partition to its factory settings, which can solve a lot of problems with faulty phones, or phones that were infected by bad apps. It can also format the SD card partition.
Some Recovery programs can also install special phone upgrades from the SD card, that write directly to ("flash") the Android ROM partition. Obviously, free access for anyone would allow rooting, so vendors make sure that Recovery would only accept official upgrades. But, one way to root a phone would be for hackers to find a way to create such an "upgrade" that the Recovery program would accept.
There's quite a lot of variation in Recovery programs out there: every vendor has their own idea of which recovery features would be useful for their customer support team. Boot into yours and take a look! It's harmless, unless you actually choose one of the recovery options...
Like the boot loader, the Recovery program is always in "root". A hacked Recovery program could let you flash an unlocked Android ROM, or run any "upgrade" you like. So, in addition to just "recovering" an unusable phone, it can help you "recover" the "root" user that has been locked from you!
A good Recovery program is very useful for customizing your phone, beyond just rooting it. By far the most popular Recovery program is Clockwork Recovery, also called ClockworkMod.
Some rooting methods begin by finding a way to flash ClockworkMod to your Recovery partition, from which you can then run an "upgrade" that roots your phone. Other rooting method find another way in, but still recommend you flash ClockwordMod as soon as possible, because it's just so useful for customizers.
You will not find a homepage or an "official" way to download ClockwordMod: carriers obviously do not want you get have easy access to it. But, search around, and you will find one appropriate for your phone. The ROM Manager app can also flash it for you, assuming you are already rooted.
The SD Card
This is another partition, entirely for you. It is not protected in any way, and you have full access to reading and writing files on it.
For many phones, this partition does not exist unless you physically install an SD card. Some phones have a built-in SD card.
The Android ROM
Finally, the most important partition on your phone! When the boot loader starts the Linux operating system (the "kernel") that sits underneath Android, one of the first subsystems to come up is the security system. From then on, the "root" user will be used to start various user-level subsystems required for the phone to function.
Eventually, the default user will be started, and that will be used to run your apps: the status and notification bar that appears on the top of the screen, the settings manager, the virtual keyboards, etc. Finally you get the home launcher, from which you can launch all the other apps on your phone. None of these programs run as "root", so you are effectively locked from administrative privileges.
The Linux operating system can set security permissions per file. So, indeed large parts of this partition are restricted to be read-only by any user except "root". So, if you boot into Android, none of the apps you run will be able to change these system files. The rest of the partition is readable-and-writeable, and generally functions just like the SD card partition, though it's usually much smaller.
Of course, if you boot into Recovery instead, you will be able to write to these files, because you are "root" there. That's why ClockworkMod is so useful for rooting your phone!
Most Android apps run on yet another layer, a virtual machine called Dalvik, which is a heavily modified version of the Java virtual machine found on previous generations of cell phones, as well as on desktop computers, servers, and many other devices. Definitely, everything you install from an app store will run on Dalvik. Dalvik is a tightly controlled environment in which privileges are carefully controlled per program, beyond what the Linux operating system provides. Not only do apps not have administrative access to the phone, but they can be limited in access to wifi, cellular access, and your data.
Except... that Android does provide a way for apps to request administrative privileges. In locked phones, this is automatically and silently denied. However, the Superuser app can hook into these requests and let any app switch to the "root" user, from which they have full administrative access. A friendly dialog box will pop up, asking you if you want to give the app full permissions. Say yes, and there you go!
A phone in which the Superuser app is running properly is rooted.
Summary: Rooting Methods
The rooting instructions you find will likely be one of these, or a combination of these steps:
Phones with boot loaders that can be unlocked (such as Google's Nexus) will let you flash other partitions. You can flash a whole Android ROM that is already rooted, such as CynaogenMod, and you're done! Or, if you don't want to replace your entire Android ROM, you can flash ClockworkMod into the Recovery partition, and move from there to the next method.
Some rooting methods start with a hacked way to flash ClockworkMod into the Recovery partition. With ClockworkMod, you can run your own special "upgrade" from the SD card. This "upgrade" will vary a lot per phone model, but at the minimum it will involve installing the Superuser app. For some phones, it will modify a few Linux configuration settings to make sure that Superuser app can login as "root." Other, more heavily locked-down phone models might require replacing certain locked parts of Linux and the Android system, sometimes much of the Linux "kernel" itself.
Other rooting methods use the phone's existing Recovery program, but the hackers found a way to create an "upgrade" that can fool the Recovery program into believing it's official. From there on, it's identical to the previous step.
Some rooting methods start straight from Android. Hackers found a way to login as root while Android is running. Of course, logging in as root is not the same rooting, but once you are logged in as root you can run a similar "upgrade" as is used in the previous steps.
Need More Help?
Don't ask me, please! Seriously, I spent a lot of time writing this long article specifically so I would not have to keep answering questions about the process. There are many internet forums and bloggers that welcome questions from noobs. I've generally found the Android hacker community to be extremely generous and welcoming.
Happy rooting!

Nice - but clarification requested
I like the article as it answers some questions.
One thing I'm curious about - you seem to use the terms Recovery Partition and Recovery Program interchangeably. Is that your intent? I'm not trying to split hairs - I just want to understand. I would have expected booting into the recovery partition loads the recovery program.
Also, you talk about how vendors choose features of their recovery program. CWM is then a replacement for the vendor supplied recovery program, correct? If you root then install CWM, are you in effect replacing the recovery program after rooting (as opposed to forcing CWM to overwrite the existing recovery program via flash)?
Thx

Thanks!
A very useful guide for android beginners like me!
Sorry for the bump . This post deserves a thanks and a bump

Thanks! A very useful guide for beginner. I've forwarded this to my colleague who just switched from Windows to Android phone.

Much appreciation!
Thank you so much. I have just purchased a rooted phone & have a ton of questions. Have spent hours here tonight searching for basic info. Finally found this & it really helped this total "noob".
Thank you again.

thanks (very2 usefull) from iphone4 user

Good work..
Sent from my Galaxy Mini using xda-premium

Thanks. It helped very much

how to root sony xperia u
How to root sony xperia U..?
please give me detailed and simple procedure to follow...
i would also happy to know should i have pc drivers to run this rooting process..?

thanks

Thx for taking the time to write the article helped me understand a lot of things

Is there any Android device that supports hardware accelerated encryption?

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...

How to securely erase Android phone that I can't encrypt?

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.