How the Glass hack works

Recently a vulnerability was discovered in Google Glass. I thought I'd write up a description of how it works.

Glass has no normal input. Thus, there's no way to type in a password for WiFi. The way Google solved this is with QRCodes. This starts on your account page:

You then click on the "My Wifi networks" tile. (By the way, it has this tile interface so that you can easily use a touchscreen instead; during my indoctrination, they had a Google Pixel laptop which has a touchscreen.) Once you select this option, you get the following popup screen:

At this stage, you can use the laptop to type in the WiFi name and password, then touch "Generate Code", which then displays the following qrcode:

At this stage, you point your Glass at this qrcode and take a picture. It'll see the code, recognize it, and change the WiFi settings accordingly.

What Lookout found is that Glass searches any picture taken for any reason for qrcode, and that if it finds one with WiFi information, it'll switch the WiFi settings.

The problem isn't limited to WiFi settings. Glass uses qrcodes for a lot of reasons, not just WiFi settings. There are likely other problems lurking here.

What information does this qrcode contain? That's an easy question to answer, just point your phone at the above picture and run your qrcode-reader app. What you'll find is that this code contains:

WIFI:T:WPA;S:linksys;P:Password1234;;

Notice that there is nothing special about this information. You can print it out and past it on your wall, allowing visitors to your home to easily use your WiFi.

As a hacker, several things jump out at me.

The first is the possibility of buffer-overflows. According the WiFi spec, the name like "linksys" is supposed to be only 32 letters. I wonder what would happen if I put 33 letters into this field of the qrcode, or 100 letters, or 1000 letters? The same goes with the password. Also, not only can I play with the length, I can play with weird characters, like Unicode.

The second thing that jumps out is that there's an obvious format of "name:value;", where the name is separated by a colon, and the value terminated by a semicolon. Moreover, a fields can be nested inside other fields, which is why there are two semicolons at the end, one terminating the child-field, the other terminating the parent-field. This means I can probably insert "XYZ:pdq;" in arbitrary locations and not affect the overall effectiveness of the code -- but cause bad side-effects to happen.

The third things that jumps out is that there are possibly other things controlled by the qrcode other than "WIFI". I need to reverse engineer the binary to go find what other fields it knows about.