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