#ifihadglass I would jailbreak it and modify the software
twitter.com
twitter.com
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.
Also, I would install vim on it.
https://plus.google.com/118343182830485155505/posts/ERUJ8e1y...
Computers got to where they are because they were hackable, not because they were locked up.
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.
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...
Tim Bray says, "Yes, Glass is hackable. Duh."
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.)
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.)
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.
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).
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...
"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."
No need to try and find a back door. As Tim Bray put it, "Yes, Glass is hackable. Duh."
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.
I'm sure they wouldn't pursue it... but it's shitty enough that they could.
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?
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."
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.
[1]: http://en.wikipedia.org/wiki/Lexmark_Int%27l_v._Static_Contr...
That said, in order to get the true efficiency of computer controlled vehicles, it really helps to have them all computer controlled.
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.
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.
[0] https://maps.google.com/maps?q=flagstaff+to+sedona&saddr...
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.
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.
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.
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.
Apparently similar laws exist in Canada, Australia, and the EU. I guess you learn something new every day.
[1] http://www.nhtsa.gov/Laws+&+Regulations/Electronic+Stabi...
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.
> 9.3 Traction control
> 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.
[1] http://www.formula1.com/inside_f1/rules_and_regulations/tech...
Not for government bulletins, though--for instant-vote referrendums :)
Just this time...try not to capitalize too much on the whole thing ;)
> reboot-bootloader
> fastbook oem unlock
(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.)
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).
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.
On an unrelated note — have you tried physically disassembling Glass to see the hardware? Just curious.
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?
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.)
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.
Here's the kernel: https://code.google.com/p/google-glass-kernel-source/
Ramdisk can be constructed/retrieved from any Android recovery build. Here's one: http://download.clockworkmod.com/test/ramdisk-recovery.img
mkbootimg to construct a flashable boot image.
fastboot oem unlock fastboot flash recovery /path/to/recovery.img
It's rooted.
The exploit was unnecessary I think.