This article nails it. Myself and the other folks who make up the Unrevoked team are basically searching for security exploits on the devices we support. We can't reveal these to the carriers, the phone manufacturers or the Android team because they'll be fixed in the next release and we'll invest the time to find another one.* Each additional exploit is marginally more difficult than the last to find.
We'd much prefer to abandon our rooting efforts entirely and have the market flooded with phones that have the equivalent of "fastboot oem unlock", or have easy ways to flash custom ROMs like the Dell Streak (no signature required), the original Droid and some of Samsung's devices. The energy we spend working on root could be better applied in finding and fixing the security holes that exist on the Android platform.
Until then we'll keep poking holes in the security of HTC devices (our focus) and make them work as hard as possible to figure out which holes we've exploited to keep the rooting window open as long as possible. We'll also keep recommending that people put their money on open devices like the Nexus One and the Nexus S.
* The exception to this was the skyagent hole, where HTC and Sprint shipped a suid-root program that would give any program you installed full control of your device. We notified them of the problem, then shipped a root based on it shortly after:
In a more perfect world, the general public would understand the important distinction between malicious "hackers" and you guys. Keep up the good work.
What do you tell your laymen friends and family that you do? Do you call it hacking? Security analysis? Something else?
This is the best kind of security research. Sometimes people think security research is unethical, but there is no ethical question here: should a user sitting in front of his own device be able to use it for anything he wants? The answer is "of course".
As a user of an unlocked Evo, I want to thank you for doing this work. It makes my life more enjoyable!
There's absolutely nothing illegal about downloading the SSH source code, finding a buffer overflow, and releasing code that demonstrates that that buffer overflow gets you root. The downside is that a lot of kiddies will use this information to cause mayhem.
When you do the same to the phone, there is much less mayhem. But there's absolutely nothing illegal about the first scenario.
Thank you so much for your work guys.
you facilitated turning my "nice" htc incredible device, to a rooted awesome custom rom souped up droid phone that is truly incredible.
This is the same thing that the iPhone jailbreakers do: look for security holes to open up the window to "root" (or install another OS: http://www.idroidproject.org/) on the iPhone.
The sad part is that Android is supposed to solve this problem, but (for many of the devices) it doesn't seem to change it at all.
I'm not as familiar with jailbreaking the iPhone as I am with rooting Android phones, so feel free to correct me.
Android is much more difficult to exploit for us because most processes don't run with the equivalent of root. Even through we're able to exploit the browser occasionally, we can't normally use that to escalate to root (there are some exceptions to this that I won't go into :)). There are system processes, but generally these important processes run as "system" rather than root. Generally, only the processes that need to setuid() to another user run as root.
I believe (but I'm not sure) that the iPhone has two users: one at a root level for system processes/applications and another for installed applications. This allows the iPhone dev team to attack the browser and use that to quickly gain control of the entire device.
The nice part on Android for us is having access to the adb shell, which occasionally lets us poke into things we shouldn't normally be able to poke at. Most Android root attempts happen through this shell user which is generally inaccessible to installed applications. You can see the additional groups granted to the shell user here:
That was true for iPhone OS 1.x, but since 2.0 they moved everything to 'mobile' except a few (very heavily sandboxed) daemons. For example, the 'JailbreakMe' jailbreak exploited FreeType running in the browser (Safari), but it still was sandboxed and running as 'mobile', so it had to the exploit the kernel itself -- from userland -- to get full access to the system. (It also installed itself to run at startup, using yet another exploit to evade the code signing requirements.)
However, if, on an iOS device, you do find an exploit in a root process, you still don't have a way to do much. Because of the code signing requirements and the W^X protection, you can't run your own binary or even execute shellcode: ROP is the only method possible to run code. So you still have to exploit the kernel to disable those, making root code execution is only slightly more useful than 'mobile' code execution for that purpose.
But that's not even really relevant, since only a few (JailbreakMe, Spirit, the on-bootup component of limera1n and greenpois0n) of the "jailbreaks" (a really misleading term, since they are more of "injected kernel patches to remove code signing requirements") are even done from a booted device at all! Most of the exploitation happens in the lower-level bootloaders, over USB (using the protocols intended for restoring the device if the higher-level components fail). Once you get access there, you can pretty much do anything you want (run a different OS, remove restrictions from the kernel), but only for this one boot cycle. After a reboot, you need to apply these patches again, leading to what's known as a "tethered jailbreak": you have to exploit the bootloaders each reboot to start up the device. This can be avoided with yet another exploit, which breaks the chain of trust at boot time to apply the patches without user intervention.
Edit: some clarification.
Edit 2: I should turn this into a blog post ;P.
Thanks for the clarification! My iPhone knowledge is horribly dated. It sounds like the iPhone security model has advanced beyond Android: there is still no sandboxing outside of uid/gid perms on Android.
Much of the work we do on Android involves some of the lower-level bootloaders well. Because each of the different Android manufacturers has implemented their own bootloaders, we tend to find lots of potential exploits at that level.
The work you guys do on the iPhone side is impressive.
iOS actually has a full implementation of Scheme (TinyScheme) running inside the kernel, that manages the (often very complex) permission schemes -- one for each type of pre-installed app or daemon, and then one for the third-party apps as well.
Edit: Unrelated: I just realized you made the Treo 650 Linux version -- that was awesome!
Aren't most unbranded HTC Android phones already sold unlocked? E.g., on my HTC Wildfire there was an engineering bootloader preinstalled, so shouldn't this bootloader provide me with the same features as an "oem unlock'ed" Nexus?
We'd much prefer to abandon our rooting efforts entirely and have the market flooded with phones that have the equivalent of "fastboot oem unlock", or have easy ways to flash custom ROMs like the Dell Streak (no signature required), the original Droid and some of Samsung's devices. The energy we spend working on root could be better applied in finding and fixing the security holes that exist on the Android platform.
Until then we'll keep poking holes in the security of HTC devices (our focus) and make them work as hard as possible to figure out which holes we've exploited to keep the rooting window open as long as possible. We'll also keep recommending that people put their money on open devices like the Nexus One and the Nexus S.
* The exception to this was the skyagent hole, where HTC and Sprint shipped a suid-root program that would give any program you installed full control of your device. We notified them of the problem, then shipped a root based on it shortly after:
http://www.scribd.com/doc/34024714/Skyagent-Protocol-Descrip...
http://unrevoked.com/rootwiki/doku.php/public/unrevoked1_dis...