My Broca's and Wernicke's areas often go on and on about how good a job they would do with sudo privileges. And they say their arguments are well formed.
An unlocked bootloader can sometimes be converted to root, but it is not itself root. Once you unlock it, now you need something to ask it to boot: you need a working kernel for that device. I, for the record, cannot find the GPL2 source code for the kernel that is on this device, nor is that even guaranteed to allow me to boot it (due to Linux allowing binary blobs in modules, etc.). Therefore, I feel somewhat forced to use exploits to actually get root on the device so I can modify the software, or even dump the kernel from it and potentially take advantage of the unlockable bootloader.
Given the way that babies flail around uselessly and can't produce meaningful output for years, I was under the impression that vim was the default editor ;)
There is no need to 'jailbreak' it. It's built with the same idea as the Nexus phones. It isn't 'fastboot unlock' but Glass has a specific command in adb to unlock, so you can root it. Takes less than a minute, no need for exploits.
Apparently the previous person to provide your overall commentary got downvoted enough that you likely don't see my response anymore, so I will respond more directly here (making this reply sadly somewhat repetitive: I'm sorry).
First, it actually does have fastboot oem unlock, and no: there is no "specific command in adb" to unlock it; the command you are seeing people post reboots the device unto the bootloader, which can then be used with fastboot oem unlock.
However, that isn't helpful; in fact, I had to use an exploit (not one I came up with: a known one that affects all Android 4.0/4.1 devices) to accomplish this. (So, my device actually still has a locked bootloader ;P.)
In order to go from "unlocked bootloader" to "root" you need a new image to flash. The most common way to get this is to dump the kernel from the device (as you know that that works), but guess what: you can't, as that requires root.
The alternatives are either to have a stock image from the manufacturer that you can extract a working kernel from (something Google did not provide for the Glass, at least yet) or to build your own from the Linux source code.
Building your own kernel is, of course, possible, however it is quite irritating, and there is no guarantee the result will work as there might be binary blobs in loadable modules that you need, or other irritating hardware checks.
You also need a good feel for what hardware the device has for this to be an option, and Google disabled access to /proc/config, which makes the process of building a vaguely compatible kernel all the more like guess-and-check.
So no, it isn't at all clear to me that it is so obvious that you can go from nothing to "modified software" on the Google Glass. I'd like to see Tim Bray explain how he'd easily go about hacking on the thing ;P.
This is especially the case as the Glass Guide (the fancy term for the Google Glass sales person) who gave me the glass (I chose the option to go to Google HQ to pick it up in person) seriously told me that the debug mode feature (which gives you adb shell) is something that he thought they removed from the units they were distributing. (I guess I was the first person to find it during the at-Google demo and then ask what it would let me do ;P.)
Google disabled access to /proc/config, which makes the process of building a vaguely compatible kernel all the more like guess-and-check.
Is there really no .config in their GPL release? AFAIK compile-time config is a GPLv2 requirement as part of the "scripts used to control compilation" (Gpl-Violations FAQ specifically mentions Linux .config files.) I'd hope there's either a .config or a defconfig that applies to Glass as-shipped.
(NB: I don't mean to dispute your overall point by this, just wondering.)
I cannot find one for the "glass-1" (or, to be clear, for any glass). I've also tried searching around the device hierarchy of git repositories they have, and cannot find anything for glass{,-1} under various vendor names (including "google"). I really just don't think they posted anything.
Could you expand on why you need a image with a kernel? I rooted my nexus 4 by unlocking the boot loader, installing cm recovery, and flashing a zip that just contains superuser and busybox binaries. Is there a key difference with Google glass?
The critical step is "installing cm recovery": ClockwordMod is an image that you can boot, and which you chose to flash to your recovery partition (which is how most guides recommend you proceed, so you can easily access it while on the go; you don't actually need to do this: you can just boot it from RAM using "fastboot boot"). To make a working copy of ClockwordMod (or any similarly custom recovery), you will need to be able to build or dump a kernel for that device.
There are some pretty serious potential health consequences for the improper use of such a device.
In this case, I actually don't blame Google for keeping things locked down a bit until those are better understood.
The best I would hope for is for them to provide some amount of support for custom OEMs... but allowing people to do whatever they want on the device without some real barriers / safeguards would expose them to enormous liability.
There are some pretty serious potential health risks for the improper use of your laptop and mobile phone too. Each can easily start a fire. Your laptop's keyboard is likely damaging your wrists. Small text, dimly lit screens, and hours upon hours of constant use are hurting your eyes.
Maybe we should take away root access to your computer while installing software that forces you to take a break every few hours? Maybe require some APIs that lock you out of your Google account during that time period so you don't cheat with another device (like your cell phone).
"I worry that Google and certain other companies are neglecting some important lessons. Their design decisions could make it hard for many folks to use these systems. Worse, poorly configured products might even damage some people’s eyesight and set the movement back years.
My concern comes from direct experience. The very first wearable computer system I put together showed me real-time video on a helmet-mounted display. The camera was situated close to one eye, but it didn’t have quite the same viewpoint. The slight misalignment seemed unimportant at the time, but it produced some ___strange and unpleasant results. And those troubling effects persisted long after I took the gear off.___" http://spectrum.ieee.org/geek-life/profiles/steve-mann-my-au...
(FWIW, that specific set of issues was not related to having a monitor in his peripheral vision, but replacing his eye with the output of a camera that had a slightly different perspective, something that Glass does not attempt.)
That specific issue, but this one is relevant to how Glass is designed:
"Using lenses in this way forces one eye to remain focused at some set distance [the screen] while the focus of the other eye shifts according to whatever the wearer is looking at, near or far. Doing this leads to severe eyestrain, which again can be harmful, especially to children."
His solution is to not use a lens, but a pinhole:
"My pinhole aremac is the reverse of a pinhole camera: It ensures that you see a sharp image through the display, no matter how you focus your eyes. This aremac is more complicated than a barrier with a pinhole, though. It requires a laser light source and a spatial light modulator, similar to what’s found inside many digital projectors. With it, you can focus both eyes normally while using one eye to look through the mediated-vision system, thus avoiding eyestrain."
But that is the entire thing that makes Google's phones fundamentally better than most other phones[1]! They are, by design, entirely hackable. If you wish, you can get root on your phone; they explicitly make them this way. You're "allowed" to. No security exploits needed.
And, if they are true to their word--and there's no reason to think they won't be--the same will go for their computer-glasses.
[1]: EDIT: I mean that they are objectively, indisputably better in this fundamental way (of being expressly hackable by design). I am not saying Google's phones are better in all ways.
Well, when they come out in the end and are easily hackable (they provide stock images, they provide the source code for everything in a way that we can compile, etc.) then that will be great, but as long as I'm having to use exploits to easily get root on the device (which I did) I'm going to say "jailbreak" ;P.
I was mainly replying to the notion that hackable devices are a "dying category". Clearly that is something we are gradually losing, in this age of the DMCA and locked-down app stores. But Google is one of the few major smartphone/table companies bucking that trend.
Hopefully, this will continue to be the case, although they have been slow sometimes in getting it all sorted out when new hardware comes out...
Or you can just use adb to unlock it. It's built right in. It's not 'fastboot unlock' but it's an actual adb command on Glass, specifically to unlock it so you can root it.
No need to try and find a back door. As Tim Bray put it, "Yes, Glass is hackable. Duh."
I believe that demand will exist for software that requires jail breaking, and hardware that interfaces with Glass's standard inputs.
Think of high-income professionals who can make $xx,xxx more per year by face-identifying people in the street and knowing their job and income. I don't believe Google's API supports this, and there are bounds of examples I'm sure.
Google has put a lot of effort into calling android an open platform. The amount of bad press and angry developers they'd get for suing _saurik_ for jealbreaking a device that already doesn't have too hot of PR would be incredible.
I'm not sure about how the decision making process went when deciding who to give an early preview of glass, but I'd imagine the people responsible knew who Saurik was and what his intentions were.
I was loopholed because I "pre-ordered" it at Google I/O. I did not get the impression that I was very carefully chosen. (That said, I doubt they mind that I did this, I'm just saying that I do not find it to be likely that they thought "oh, yeah, saurik, we know him".)
Don't be so sure of that, I went to pick up a glass in NYC yesterday and the staff had the exact conversation of when you were going to have this jailbroken. It is just funny that it was literally done within 24 hours.
Interesting; to be clear: the people in Mountain View didn't seem to have any clue of the kinds of things I worked on, even after I attempted to carefully explain it to them (doing demos on my iPhone, etc.).
It isn't immediately obvious to me that DMCA applies to jailbreaking a device; has it been confirmed to apply? I understand it applies to breaking access control measures on copyrighted materials but it seems to be a stretch to apply it to jailbreaking in general.
Some of the code on the device is no doubt a copyrighted work, eg the main Glass APK and such. You can't dump some parts of Android without being root, and getting root would count as circumvention.
I'm sure they wouldn't pursue it... but it's shitty enough that they could.
But the measures that jailbreaking circumvents aren't intended to function as copy protection - they're doing something else entirely.
And even if those measures are protecting copyright in addition to locking down the device, has any court ever ruled on whether circumventing those measures without intending to breach copyright is a violation?
If a car manufacturer decided to lock the hoods of the cars they sell so that only authorized mechanics could access the engine, could they use the DMCA to outlaw users from circumventing the hood-locks on their own cars merely by printing some copyrighted text on the inside of the hood, and call it a copy-protection measure?
There was the DeCSS case, other than Sony's autorun CDs I think that would be the most trivial "DRM" but was still ruled a violation to circumvent.
Auto manufacturers, along with printer manufacturers, are already using IP in the on board diagnostics and printer cartridges to claim copyright violations when people adjust or replace parts "without authorisation."
Because the CSS code was there for the purpose of preventing unauthorized duplication of content, not to restrict people's ability to control the functioning of their DVD players.
Regarding printer cartridges, there have already been court rulings [1] that have determined that "jailbreaking" them isn't a violation of the DMCA, making the distinction specifically on the basis of whether the the element of the product being protected is "creative" or "functional". So we already know from case law that the DMCA doesn't actually prohibit people from circumventing functional lock-outs.
Last night me and my buddy were talking about the future of personal transportation and how when cars (or helicopters) start flying themselves people will resort to jailbreaking them to take back control.
Cars have had antilock brakes for a long time now. Sometimes those are sensitive enough to harm braking performance when the car is driven by an expert under race conditions. It is not uncommon for people building race cars from street cars or racing cars they also drive on the street to disable ABS.
Now, traction/stability control is mandated by law. Worse yet, if there's a switch to disable it or set it to a "sport mode" that intervenes less aggressively, it must reset to full-on every time the engine is started. It's that last bit I really dislike; I generally appreciate help from computers in various aspects of my life, but once I make my intent clear, I want the machine to respect my decisions.
I had no idea that ESC was required by law. Sure enough, you're right; U.S. National Highway Traffic Safety Administration Federal Motor Vehicle Safety Standard Rule 126 [1]: "require electronic stability control (ESC) systems on passenger cars, multipurpose passenger vehicles, trucks, and buses with a gross vehicle weight rating of 4,536 Kg (10,000 pounds) or less"
Apparently similar laws exist in Canada, Australia, and the EU. I guess you learn something new every day.
Expert drivers under race conditions? I pull my ABS plugs every winter because it's terrible in snow. Pump the brakes manually and you're much better off than the standard ABS chatter.
I was trying to make my claim as non-controversial as possible. I agree that it fails under a lot of conditions and many above-average drivers are better off without it.
You must have a car with terrible ABS. Bad weather such as snow is the only time I prefer ABS. It makes controlled stops in bad conditions much easier and more controlled.
Contrary to this, ABS in Formula 1 is banned. It was so successful in reducing braking distances that it was seen to remove much of the skill of the driver, to the detriment of the sporting aspects of the races. Similarly, traction control and stability controls are banned.
Traction control has been permitted in F1 for about ten years now. ABS is still banned.
ABS for road cars is usually tuned to prevent wheel lockup and loss of steering control no matter how unreasonable the driver's inputs. I have the feeling that any ABS designed for racing will behave quite differently. Thing is, there aren't any knobs to turn on a road car, so people often just disable it. It would be more fun to have knobs.
> No car may be equipped with a system or device which is capable of preventing the driven wheels from spinning under power or of compensating for excessive torque demand by the driver.
> Any device or system which notifies the driver of the onset of wheel spin is not permitted.
Traction control was allowed between 2002-2008. 2008 saw the introduction of standardised, 3rd party ECUs (Engine Control Units). This made the policing of the ban much easier than it had been in the past because teams couldn't reimplement traction control in their own engine firmware.
...why? Having control of the car requires paying attention to the car and surroundings. I'd rather be able to ignore all that and have more time for reading (whether educational or entertainment) and such.
I don't believe that anyone truly enjoys driving. If that were the case I could say "I need a ride to North Dakota" and someone would totally be like "yeah I love driving, hop in!"
That never happens. People that love surfing will surf at every opportunity you give them, people that love eating will eat nearly anything you put in front of them. People that love driving.....well I need a ride to North Dakota.
Some people enjoy driving in certain situations. Few people get much enjoyment out of guiding a car down the interstate; it's boring, but breaking concentration can be rapidly fatal. No, I won't drive you to North Dakota.
Many people enjoy driving a sports car down a mountain road with light/no traffic though. If you wanted me to drive you from Flagstaff to Sedona[0] in a Mazda Miata, I'd do it happily, over and over. I would rather do that myself than let a computer do it, even if the computer can do it safer and faster.
That is a silly conclusion to make. For a more HN relevant analogy try replacing driving in your post with coding and a ride to North Dakota with building an MVP. Would you suggest that no one really likes to code or that people should volunteer to work for you with no future expectations just because they enjoy their job?
I love driving. I'd drive you to ND assuming you'd compensate me for the time it'd take from my work. That cost would make it extremely impractical for you to choose that option though. Just because someone loves driving doesn't mean they can't be practical about it.
I enjoy flying, though not driving, and I wouldn't fly you to North Dakota just because you asked me. It's too expensive when you're not doing it for fun. (Also, North Dakota is cold and far away.)
Agree, in fact driving a car on the road is a very questionable freedom. But some would like to exercise it in spite of restrictions, for a variety of reasons. I had hoped that self-driving cars prevented also others from driving their cars. But the grandparent comment just spoiled my hopes.
Given the toll of road traffic in terms of human lives, removing the freedom to choose the precise driving speed and the distance from the preceding vehicles and adjacent lanes, is a no brainer.
Because no software ever has bugs under unknown conditions. I think removing (human) brains from the equation will still result in there still being casualties - even if there are much less.
Making a change that lowers the number of failures is the definition of improvement.
Devil's advocate: For humans who insist on trying to drive anyway, we can give them race tracks or have designated "Human Driving" areas. It won't ever go away completely.
Roads like the california 1 coastal highway, and the 89A from flagstaff to Sedona, sure people are going to want to drive those and while it may make it marginally more dangerous, it would be hard to make a case for mandatory computer control under good road conditions.
In areas with significant congestion however, such as the entire city of Seattle, requiring computers to do the driving and navigation could significantly improve commute times (by, like, an order of 10 during peak hours), but only if everyone is on board.
Exactly. This is no different from smoking in designated smoking areas. I'm not going to stop you from smoking entirely, but I'm not going to put up with your sidestream smoke polluting my lungs or your awful manual driving slowing my commute and making it more dangerous.
Because I enjoy driving, and I'm sure I would enjoy flying as well. Obviously we weren't talking about manually overriding the system for every commute to the grocery store or even over urban populated areas.
'Control' doesn't necessarily mean 'personally pay attention to all the details'.
Even if you let the car/plane/misc operate itself, the legal ramifications of rooting are interesting (presuming you've already reached the point of having cars without manual overrides, that is).
Imagine the impact of rooting your car on your insurance, for example.
Except that flying a jailbroken plane with custom software in public airspace really should be illegal. It'll lead to interesting times, if not more open ones...
I wonder if one day it will be mandatory to wear some descendant of this device in order to receive government bulletins, and if the jailbreakers become some underground citizens rebellion against the corporate borg in Google, which ironically still goes by the now-sinister mantra "don't be evil".
I'd be okay with this being mandatory in some sense to our future descendants, after it becomes uniquitous enough that it's only the lone straggler who doesn't have one.
Not for government bulletins, though--for instant-vote referrendums :)
You have to wonder if face recognition will become regulated in some way. For example, if it becomes OK for police to ID you by face, but not OK for you to know that the policeman talking to you has lots of complaints filed against him.
That lets you flash the device, it doesn't give you root. To get root from that you need to make a bootable image, which requires a compatible kernel, which you normally pull off the device as root. Thankfully, there is a race condition in the backup/restore mechanism that lets you do a symlink traversal to unlock root adb (by modifying /data/local.prop).
(To be clear, though, this was a known exploit: it is normally done to the Android Settings application, which isn't present on the Glass, but it turns out that the Glass Logging service also has the right prerequisites to pull off the attack, so I adapted the restore payload. The tweet I posted right after this one made it clear what exploit I was using against what installed package.)
Thanks for the explanation. Your next tweet was too cryptic for me to understand so I didn't realize you were explaining your jailbreak method.
If I'm understanding you right though, this technique sounds fairly universal. Does it affect any android device with an unlockable bootloader? Just devices running a newer version of the adb daemon?
This exploit seems to affect almost every device running Android 4+ (I am not certain about lower ones: all of the comments I've seen about the exploit talk about 4.0/4.1, but it might be because 2.3 already had a pretty universal root: GingerBreak). The person who wrote the most common implementation is B1nary (but I don't think he came up with the exploit either; it wasn't clear if the people he credited as having helped him did either... so I just cited the exploit itself as that seemed sufficient), which may help you find the XDA developers thread (which, as is usual, doesn't explain the exploit, it just provides a wad of shell scripts you can download from a few random filelockers ;P).
The exploit requires not just something in adb: it requires the device have the package for the backup service (I guess some don't, so B1nary's implementation tries to work around this as the most common alternative actually had a similar bug) and that there be a system package installed that 1) is not marked allowBackup="false" and 2) is marked with sharedUserId="android.uid.system". The normal Android Settings app has these properties, as does the Glass Logging service. It is thereby a trivial thing to mitigate, even without any extensive code changes: these packages don't need to be backed up anyway (backing up Settings, for example, results in an empty file... it has no data of its own, so it has no reason to avoid allowBackup"false").
The way it then works is that the backup service, in order to extract files with the right permissions, does a setuid to the owner of the package being restored (in this case that is root, so it continues to be root). It then extracts the restore image (which is a compressed tar file with a special header) to the package's data directory, and as it does so it honors the access flags of the files and directories. You then make a world-writable directory with numerous very large files, which slows down the process. As it extracts the files, you use adb shell access to add a symlink from a file in that folder to /data/local.prop. You have that file in the backup contain a /data/local.prop that forces adb to give you root access.
(Note: with those modifications, which typically includes telling the system you are running in the qemu debugger, Glass actually doesn't work correctly due to an assumption it makes that Bluetooth will work, which the qemu debugger I guess doesn't normally support. However, it is then easy to drop a copy of su, mark it setuid, delete the local.prop, and reboot to a system that is now pristine except for the one modification of setuid su.)
I don't know anything about Glass, but I believe, usually, if one can reflash the device, one should generally be able to dump any MTD partition contents, too. If that is the case, rooting is as simple as getting to the bootloader, asking it to dump the root partition, unpacking (in case of cramfs, SquashFS or alikes), modifying, repacking (if necessary) and flashing back.
At least, this was the possible with D-Link and TP-Link routers (using pre-flashed u-boot) and Tegra-based Android tablet (using nvflash).
> ...usually, if one can reflash the device, one should generally be able to dump any MTD partition contents, too...
The Google fastboot protocol allows you to flash, but not to dump. The reason nvflash on your Tegra tablet is different is because those devices are capable of booting into an NVIDIA-specific bootloader that offers the extended functionality to dump the flash contents. On most Android devices, you need to boot the device first and use root access to dump the flash partitions (and in fact on some Android devices even root doesn't have access to dump the flash partitions, so you also need a kernel exploit to modify the driver).
The realistic alternative, and which is totally possible, is to just build your own semi-compatible kernel. With normal adb access you can easily see what kind of hardware it is running, and you can try to guess and check (and pray you don't fry) your way to a compatible set of kernel drivers to access the flash partition; you really need just enough to get flash working with a custom initrd that does nothing but mounts the /system partition and makes the modifications you need; but honestly: "ain't nobody got time for that" ;P.
No. It requires a kind of screwdriver that I don't have with me (and which wasn't in the set that I bought in my initial attempts to cut apart a pair of prescription glasses to work with it), and for all I know it will strip the threads on the way out ;P. If nothing else (Further, I would pretty much just be able to say "uhh... it looks like some kind of digital computer... possibly one involving silicon?" ;P.)
You are also correct in that all you need is a bootable image, which consists of a ramdisk and a kernel. Your statement that it requires root to pull it off the device is not true however.
Come on.
UPD: I already have my mind where I don't have "root" on. It's kind of a black box. And it is counterproductive.