Google patches up Android jailbreak with RC30 update
By Donald Melanson 
posted November 7th 2008 1:31PM
posted November 7th 2008 1:31PM
As you may have noticed, Google doesn't exactly seem to be hesitant about pushing out Android updates, and it looks like it's now at it again, letting the new RC30 update slip out just days after folks finally figured out what the mysterious RC29 update actually did. This particular update is decidedly less mysterious, however, with Google saying up front that it had been notified of the jailbreaking issue with Android and has developed a "fix," adding that it is "currently working with our partners to push the fix out and updating the open source code base to reflect these changes." No word on any other changes included in the update, but it's supposedly on an "accelerated release" and should be in everyone's hands within the next the three or four days.
[Via Talk Android]
[Via Talk Android]
What is the size and process for this update? I hope it will not be like an iPhone or Android would be a bag of hurt.
I see what you did there...
yeah, my phone is still at RC19, but I'm never in 3G coverage. I wonder if that has something to do with it?
Nope, I don't have 3G here in Cincinnati and i got an update last night.
lol,nokia n95 8gb (see picture).
I don't see it.
Look at who is taking the photo (reflex).
Shit, the dry cleaning!
brb
Talk is cute, but I'm thoroughly soured to android with its 'kill switch' and 'fixes', you might as well get a freaking iphone.
YEAH!!! I mean what good software has updates.. and code fixes.. that is just preposterous!!!
Yes, and the iPhone also doesn't totally have a kill switch of its own...no...definitely not...
The kill switch is only for applications downloaded through the google app store, just like Apple. The difference is that you can get applications for the G1 from other places than the application store, unlike apple.
Are they talking about root access or unlocking?
From what I read the unlocking doesn't involve any "hacking" you order an unlock code and then you change your carrier settings in settings. So if by jailbreaking you mean unlocking then there disabling the unlock codes?
If by jailbreaking they mean root access then that just doesn't make any sense. I thought open source meant we could do what we wanted with it.
If this turns into another jeasusphone we "Steve" knows whats best for you thing, then no android for me.
Don't pull a STEVE on us GOOGLE!! Apples are bad for you!!
im guessing they dont want anything similar to jailbreak aka tzones hack i guess something like dat
What they are talking about, is that some people found an exploit where you can gain root access to the device. Programs on Android are supposed to run in a sandboxed environment, and not have root access. This really has nothing at all to do with jailbreaking, or locking down the phone, or anything like that, it is a security measure to keep the OS on the phone from being damaged by applications, and outside of crazy iPhone world, is considered a good thing. Where the problem comes in, is some hackers used to dealing with Windows Mobile wanted to make the phone more like Windows Mobile, and wanted the same sort of root access they have on Windows Mobile, so found an exploit to gain that access on the device, instead of going through the content providers built into the OS.
What articles like this completely miss due to their iPhone perspective, is that the people making these changes, instead of hacking the device through an exploit, could have gone into the source, and rewritten the content provider services to give them the features they desired, while still keeping the apps sandboxed. That way they wouldn't pose a danger to the OS as a whole. That, however would have been more complicated, and required figuring out a way to get the new branch of the OS onto the phone. This isn't about Google locking down functionality of the phone at all, it is about Google patching a security hole that could be maliciously exploited. It is only from the point of view of an iPhone user that closing security holes is the same as locking down the device, because security holes are the only way they can do anything that doesn't have Steve's seal of approval.
I know it is hard, but could Engadget try maybe just once not writing everything through the point of view of an Apple fanboy? Jailbraking? It is funny how different it sounds if you write the story to say "Google is moving quickly to release an update which patches a root level vulnerability that has been exploited" rather than "OMG they are keeping me from jailbreaking my phone."
This phone is not in jail, therefore doesn't need to be broken out of jail. Some hackers found an exploit by which you can gain root access to the device, and Google is releasing a patch that addresses the vulnerability. That is how these sorts of stories are reported outside of iPhone land. Yes, we get it, your iPhone is so crippled out of the box that if it weren't for exploits, it would be completely useless, but that doesn't mean every other phone on the planet has to rely on exploits to function.
This move goes against the very fundamental concepts of Android, closing it up to only applications developed by the SDK, and in my opinion is extremely hypocritical considering what Android represents. The exploit requires the user to use the telnet function of the phone, so there is no danger for hackers to use it to gain root access into an unsuspecting person's phone. It merely allows applications to run natively on the device instead of through a VM.
/me won't update.
I really am getting annoyed at how completely off the mark everyone is getting thrown by the "jailbreak" analogy here. No, this is in no way even remotely "against the principals" of Android. Everything in Android is designed around apps running in the VM, and interacting with the OS through content providers. The OS from the ground up is designed for apps to run sandboxed in the VM, to avoid the stability problems of Windows Mobile. That said, there is nothing stopping you from going in an writing your own branch of the OS that functions differently. For that matter, I am not seeing anything to stop you from just writing your own content provider in C++, and loading that onto the device. Exploiting a root level security hole is just a sloppy way to hack on functionality, without going to the trouble of writing a new content provider.
The worst Google can be accused of here is aggressively enforcing best practices for programming, and closing a security hole. They aren't stopping anyone (at least not yet) from developing programs outside of their SDK, they are just enforcing that programs not gain root access, which they shouldn't be doing anyway, because that is bad programming. There is no reason a program on a handheld device should have to run as root. That isn't some draconian edict from an evil company keeping you from doing what you want, it is just common sense programming. Any program running as root could potentially crash the entire phone. Better to run the application in the VM, and if need be, create a new content provider that gives it the information it needs.
Have you even looked at the SDK and source code, or are you just posting knee jerk responses based on your gut feeling about the inherent rights of device owners? There is a big difference between saying "you can't do this" and "if you are going to do this, we want you to do it the right way."
Are you reading the same information as everyone else, or you don't bother to read the linked articles?
HAHA!
I'm glad I went to a more open platform...
Windows Mobile F T W!
I'm starting to dislike Google
Why, because they patch root level vulnerabilities in their phone OS? Yeah, wouldn't want that, evil bastards!
Because of that disingenuous headline? Inform yourself.
Jeeze has anyone even read up on Android on the G1.
Android is open source, both the kernel and the application framework.
You can compile your own kernel and version of the framework,
you can _not_ currently install that on a G1, partially because we don't know how and secondly because you don't get a console (on the phone) and don't get root.
Because of the "tivo-isation-by-obscurity" you can't _get_ root without modifying the environment and you cant modify the environment without root.
Hence being able to get root on the phone via an exploit is needed right now to even begin to work out how to get a cooked OS on it.
Remember, while Android is open a specific hardware platform implementing Android may not be open.
So this thing has nothing to do with the openness of Android. It just has to do with the fact almost all hardware phone platforms today are not open. Seems the ball is more in the in the court of hardware manufacturers to create an environment where you can install different OSes on the phone (but this of course is unlikely to happen and it seems they try their best to make it next to impossible to install different OSes on a phone).
However, I can say this exploit is quite dangerous because you can issue root commands just by typing a message. For example typing "reboot" will actually reboot the phone after applying this exploit (or something similar to that). That's quite dangerous for most end users, so I see why they needed to patch it.
I wonder if this has more to do with the easy access of root then "jailbreaking" the system. I mean if an app can enable it so easily from Android to allow a remote user to telnet into the system that sure as heck would be a big security hole IMHO. *shrugs* The nice thing is you don't NEED to install this to continue to use the phone, unlike the iPhone where down the road it could impact functionality.
I just got the rc30 update a few minutes ago and I noticed it fixed a very annoying problem. When I used to plugg my G1 to my computer I couldn't play or get to any thing that was saved on my micro SD uuntill I unplugged it but not any more :)
This thread has been an interesting read for me after looking into rooting my own G1.
Lets see if I can sum this up for the other laymen...
I am a tech junkie, and a run of the mill linux user. I am not a programmer sadly, however I also have a lot of info.
I wasn't looking to jailbreak my 2 day old g1. Jailbreaking a phone is unlocking it for service on other networks. att/Tmo do share roaming towers and any att or tmo phone will work on the other carrier's network as mentioned before. Say you wanted to put it on verizon, sprint, or rogers? only then would you need to jailbreak it.
So the term is being misused a lot... kind of like "hacker."
The root access is not about jailbreaking networks, it's about having super user on your machine. I want to use it for simple things, I don't trust all the apps, or the memory management system.(probably because I don't understand how exactly it prioritizes and how optimized it is.) A root shell would do nicely to manage a few things. Better yet, a prompt for a root password similar to ubuntu, even if I didn't call for root. Some people just like to know what is going on, even if they aren't smart enough to wade through the pages of C code.
If you create root on a machine without a root password, and do as some of these root tut's say (yes that is pronounced -root toots-) suggest and change the SU command (calls login for super user) to a "secret" command, all you have done is locked the O.S. out of some essential functions. Ones that provide things like security updates. So you would have to manually handle all of that.
A patch to a easy way to root the android O.S. is in fact a good thing! But I believe we need a application for the G1 that will allow us to have a secure root shell on our phones, we don't need everything to be executed as root, that's just lazy programming and bass ackwards "security."
First off - I agree, root access is dangerous, this patch would be described by M$ as a Ciritical Security Update if it were in Windows.
So, to be clear, I agree that the root access problem needed to be patched - but...
I have a problem with some of the suggestions in the the posts by L.M.Lloyd:
I am a developer, (I haven't writen for android yet, but I am sure I will,) and the idea of adding a new interface sounds reasonable until you look as distributing the app.
From the comertial perspective the main attraction of a widely adopted OS is that your app can be run by any platform running that OS - assuming appropreate HW support.
If a new interface were added to a developement branch of the OS, there is no way we could reasonably expect a customer to update the whole phone for one app. Taken to it's logical conclusion, if the customer had two apps from two companies and needed special branches for both, there would be no way to get both running at the same time.
In short, manufactures should base there updates on releases of the main 'official' Android branch, where the API list is added to (never reduced) with each version. This would mean that apps can be writen to support a particular version and above.
(Although for commertial reasons I could only use APIs that have been arround for a good long while, to ensure the greatest possible number of compatable devices.)
I did think that is the API list changes there should be some obvious way for the customer to know which version they are using so that they don't buy apps that their phones can't support.
(The about box is burried a little deep for my Mum, for example, to find :) )
That said, I have no problem with contributors suggesting (contributing) new interfaces for consideration for new builds, although that wouldn't be of any immediate help to a 'stuck' developer..
BTW
I am a little unclear on who has the responsibility for updates. With WM, the build is specific to the HW - some custom builds exist fro some phones, but only due countless hours of work by enthusiasts.
I suppose if Android is sufficiently modular some level of HW agnostic upgrade may be possible, but it is starting to sound problematic, with unanticipated interactions between existing hardware abstraction layers and new modules from google, and a second source of updates from the manufacturer if the manufacturer has to issue updates to fix bugs in the hardware abstraction layer as well (which is possible).
Does anyone know how this would work if I were to buy a Kogan Agora Pro, for example?
It's actually really easy to roll back the firmware on a G1.
Download this file (RC29 US G1 Version) and put it on the root of your SD card. Restart your G1 and hold the camera button down as it starts up. Flash the image and you are back at RC29 and can jailbreak/root your phone (the correct term for Android is root. Root= gain superuser access Jailbreak= run unapproved code)