Hacker News new | comments | show | ask | jobs | submit login
Exploiting a Bug in Google's Glass (saurik.com)
170 points by dpearson 1515 days ago | hide | past | web | 31 comments | favorite

"At this point, I could have simply complained to Google in order to obtain the source code for the kernel. However, I expected that would take days (Google actually ended up posting the code within hours on Saturday, but that was under rather large public pressure), "


1. It wouldn't have taken days, it would have taken roughly the same time no matter when it happened, or whether it was requested privately or publicly.

In most cases, faster. Part of the time delay was that I needed to give the code.google.com oncall folks a heads up in case it caused them a massive amount of traffic (it's generally bad form to cause a DDOS to someone else's service without giving them a heads up), since that was not the original planned release mechanism, and historically, these releases generate a bunch of traffic.

2. The very small number of times (in the 7 years i've been there) these things have been screwed up, even privately, we have almost always given people source within hours, so i'm going to say it was more that I try to correct mistakes as quickly as possible.

The only case it didn't happen that quickly that i'm aware of was when someone in a beta program requested pre-release GPL source, which we, of course, gave them, but it took a day or two to actually pull it together.

When it comes to stuff like open source compliance, what you do when things go wrong matters as much as what you do when things go right.

You should always feel free to ask folks for source, and beat them over the head if they don't reply quickly.

Besides that, the general rule of thumb for the GPL is that if you give binaries outside the company, that's what matters, not whether it was only sold to a few people, labeled a beta, or whatever.

There were a few companies (this is about 13 years ago now) using GCC that tried to use NDA's to separately restrict GPL release of new architecture patches until some "public release date" for that architecture, and the FSF threatened suit. It got worked out, and eventually led to this seemingly random message to the GCC mailing list: http://gcc.gnu.org/ml/gcc/2001-07/msg01342.html

(This is also when the GPL FAQ was updated with the same answer)

Hey, so speaking as someone who has tried and failed to get support from Google in the past, can you tell me the right way to complain to Google about such things?

(Who to email, which webpage I submit the request at, or whatever the official process is)

I'm asking here because what you said sounds great, but unfortunately Googling for "google gpl request" and the like didn't turn up anything.

Support or GPL source? For GPL or open source complaints, we actually watch a pretty large number of sources for this (gpl violations mailing lists, various open source mailing lists, G+ posts, twitter, etc). If you email legal@google, it will get to me, but they may take a little time. In fact, most normal support channels will get there, they just may take a few forwards to end up in my inbox.

I haven't heard that people have had difficulty getting source (because we try to be proactive about it), so I haven't set up an alternate method of contact specifically for it (and in most cases, i'd rather just fix whatever process is broken).

In the short term, the easiest way is to just email me at dannyb@

Longer term, maybe i'll create opensource-requests@ or something.

The only caveat i'll mention is that Motorola is run as a completely separate subsidiary, so I can't guarantee quick answers/solutions if you are having issues with Moto. Not that I can't help, but in practice, because the companies are run separately, it involves beating up people that don't work for me

Very pleased to see such a detailed post. I'm also perturbed by how quickly I went from "Sweet, I can't wait to get glass and compile my own stuff," to "Wait, right, security holes in a 24/7 camera. Umm..." I mean, there have been studies that show you can identify passwords from audio recordings of known keyboard keys clicking. Then again, we did already have such as cellphones. (For quite some time I preferred iOS /because/ it was so hard to jailbreak...)

> from audio recordings of known keyboard keys clicking



"We present a novel attack taking as input a 10-minute sound recording of a user typing English text using a keyboard, and then recovering up to 96% of typed characters. There is no need for a labeled training recording. Moreover the recognizer bootstrapped this way can even recognize random text such as passwords."

I think this also works on dvorak, but it might be stumped by plover + custom dictionaries. Especially for short typing sessions. Although short sessions might be mitigated by recording from multiple locations... hm.

Thanks for sourcing my statement. I was worried for a minute that I'd misremembered it. (I'm also glad that's a word!)

Also, this is worth mentioning as a related attack:


"In particular, we show a practical Keyboard JitterBug that solves the data exfiltration problem for keystroke loggers by leaking captured passwords through small variations in the precise times at which keyboard events are delivered to the host. Whenever an interactive communication application (such as SSH, Telnet, instant messaging, etc) is running, a receiver monitoring the host's network traffic can recover the leaked data, even when the session or link is encrypted."

Not sure if you meant 'was' so hard to jailbreak there. I'm pretty sure jailbreaking the iPhone is the hardest it's ever been.

I meant 'was' because I'm currently testing a Nokia 920 and a Nexus 4. And yes, I'm planning on switching back to iOS as soon as it gets NFC or curved front-glass for easier swiping, as both phones have those two features and feel quite modern as a result. A new dashboard for icons wouldn't go amiss either. But I do miss my always-on encryption in sleep and lack of jailbreak, indeed...

While the first part of this article couldn't decide whether it was directed toward technical or non-technical audience, second part about security implications of such an easy way to get root was definitely thought-provoking.

While I was super-eager to get Glass before, it really got me wondering if having camera and microphone in your glasses is such an great idea after all.

Yes it's a great idea. Microphones are already a standard part of widely accepted headphones/headsets. Cameras aren't as accepted yet but they will be, whether that's in 2015 or 2025 is the 64 billion dollar question.

Well, I'm glad you have the answer :P

I agree with your statement that cameras will be accepted in the future, but I'm not sure it follows that it's a great idea.

On the other hand, I'm not even convinced cellphones and facebook are great ideas, so my life is probably not representative. (Now get off my lawn.)

It would be interesting if there was some way to pop the camera/microphone off so that Glass could still give you notifications, just not collect input. Would solve a few problems.

paper and sticky tape should sort the camera out nicely.

And look mighty attractive on your face.

your phone has both, specially the microphone is always with you in possible working condition, if not the camera that could be blinded in your pocket.

Relevant - 4 days ago there was a twitter pic posted and much discussion on HN [1].

[1] https://news.ycombinator.com/item?id=5614920

As someone who wasn't familiar with saurik or his work before this original picture posting (sorry!), I'd just like to say that it's really refreshing to see such a level-headed member of the community at work. Some of the responses (on HN and other places) to his original post seemed very dismissive (along the lines of the now-famous "Yes, Glass is hackable. Duh."), which could easily lead to some defensive bickering. But from what I saw, saurik responded calmly and thoroughly to many comments, in situations where I've seen less experienced/matured members of the community (no, I'm not going to name names) take a... different approach. I'm looking forward to reading his write-up more thoroughly when I get the chance.

Summary: He did you not use oem unlock (but he could have if he wanted to), but rather exploited a race condition bug that let him gain root.

I think the entire ensuing discussion and a small part of this followup article point to the fact that at the time at which he exploited the device, the kernel source was unavailable, as well as that flashing a new boot image is only useful if you can actually build a kernel to flash.

Given that the kernel source was not made available until the next day, he could not have used oem unlock - even "if he wanted to."

To be fair, I'd say the goal of my article is to just make certain that everyone else can replicate what I did and learn from it; normally I'd co-release a post with the announcement, but I wanted to do the announcement sooner and wasn't expecting it to burn quite so much of my time.

Additionally, my article documents the threat of this kind of security exploit on Glass, along with some issues with this specific device that make exploits of any kind more dangerous (the lack of a PIN being key), as well as looking at some scary examples of Glass-specific malware opportunities.

Thank you for performing a valuable public service because we need to have the facts first before having a discussion about the implications. I read an article around the same time about the claim by Julian Assange that the internet is a threat to civilization, and thought your work tied in nicely as a cautionary warning about the path we are currently on. http://www.salon.com/2013/04/30/tk_5_partner_15/singleton/

Why would you need the kernel source to fastboot unlock?

I encourage you to read the article, as this is one of the things that I cover (including a quote from the developer of ClockwordMod regarding the practicality of using fastboot oem unlock for purposes of getting root on a device without anything to start with, such as kernel source in specific).

So, it is possible, it just isn't practical, especially when an exploit happened to be so easy to come by. Once you then have a security exploit, you can then start to ask "what does this let me do that an unlocked bootloader does not", and the ramifications on Glass are, at least to me, interesting.

Unlocking the bootloader just allows you to have access to boot an unsigned system image. He points out in the article that you'd still need an image to boot.

With an unlocked bootloader, you could boot something that then messed with the filesystem to drop "su" out in the bin (and this is what happens when you boot a recovery image to root an Android phone).

But in order to do that, you'd need kernel sources, so that you could have something that would properly boot on the device and mount the filesystem.

Looks like there's going to be an IO talk about rooting Glass: https://developers.google.com/events/io/sessions/332704837

I'm not at all surprised that Glass can be rooted and such, but I wonder about the social implications. A while ago I (incorrectly, sort of) made a post saying that you wouldn't be able to tell when Glass is recording. Somebody replied and mentioned that it would have a red light visible when it is. I didn't bother replying because, despite precedent, I had no proof that Glass would be able to be rooted etc. My point is, with Glass already rooted, is anything stopping somebody from having Glass without a red light while recording?

It could be similar to how apple laptop camera lights work. Those light come on when the camera is recording and as far as I know it is impossible to stop them within the software. Hopefully glass does the same thing.

Glass does not have a light of any kind that comes on while it is recording. The closest you have is that the screen itself is visible from the front (due to how light refracts through a prism). I have heard that the older Glass units that were being demoed by Google employees did have such a light, but if that was true it was removed for the Explorer Edition units.

Oh. Wow, I'm quite surprised they'd remove that, seems like it would make them a bit easier for people to accept if there's a clear sign of whether they're recording. I expect not doing so is going to mean they're treated like holding your phone up, and there's quite a few places that's really not going to fly.

The thing we seem to be missing is what was Dan Morrel getting at when he thought they didn't get root? Di he think they just ran adb against the glass and figured out how to talk to it directly via the same calls the mirror api uses? Is there some easier way to "hack" Glass into doing interesting stuff?

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact