Chromecast: Exploiting the Newest Device By Google | Hacker News Reader

Chromecast: Exploiting the Newest Device By Google

blog.gtvhacker.com

127 pointsbackrage31 comments

It's a pity that GoogleTV (which the Chromecast OS appears to be derived from) is such a messed up platform. They really wanted to be able to run Chrome, before Chrome had been ported to bionic/Android...

So, they ported Android to glibc instead! If you poke around on a Google TV device, you'll notice that the Chrome build they include links to GTK+ 2, which renders the scrollbars (that you can't use with a remote on a TV...).

I have no idea why if porting Chrome to bionic was so hard, they didn't use a regular Android build but run Chrome using ld-linux and glibc (and the rest of the system with bionic). You'd have to write something to bridge Chrome's content to the outer system via shared memory and IPC but (having done so once myself) this is much less work than hacking up a whole operating system!

Porting code to it which already ran on Android and Linux was a pain because it was somewhere in between (lots of Android library stuff, no bionic hackery). If it had looked like regular Linux, or looked like regular Android I would have had an easier time.

Anyway, I hope that Chromecast stays unlocked and that a bunch of OSes get ported to it. It's like a super souped up Raspberry Pi that even comes with a case...

Cool, has anyone put up those glib/chrome bindings anywhere? I would really like to use those. Are they gobject bindings? Does this mean that the glib event loop was combined with the v8 event loop? I see some search results indicate that Chrome OS uses this too? Way schway.

No, no, they ported Android to glibc the GNU libc implementation (from bionic, the APSLv2 licensed Android libc implementation) in order to run Chrome, which at the time depended on some glibc/posix things that weren't in bionic (Chrome on GTV also links against glib and gtk2, but that's because it does on regular linux too -- Chrome uses the glib runloop already fwiw and v8 has no runloop).

I think GNOME3 has spidermonkey with GObject bindings, and I'm sure I've seen JavaScriptCore GObject bindings too...

"I have no idea why if porting Chrome to bionic was so hard, they didn't use a regular Android build but run Chrome using ld-linux and glibc (and the rest of the system with bionic). You'd have to write something to bridge Chrome's content to the outer system via shared memory and IPC but (having done so once myself) this is much less work than hacking up a whole operating system!"

Just so i'm clear, your suggestion would be to use a completely hacked up libc, running on a platform not made for it, using shared memory and IPC hacks as well, for an app made to run as part of a TV 24/7?

I'm not sure i'd agree with your engineering choices. :)

"They really wanted to be able to run Chrome, before Chrome had been ported to bionic/Android..."

It's weird that you assume this is the issue, and then explain why it probably wasn't.

I can assure the the platform was not built on glibc solely because of the need to run chrome :)

The reasons GTV was such a "messed up platform" are entirely mundane (IMHO).

> your suggestion would be to use a completely hacked up libc, running on a platform not made for it, using shared memory and IPC hacks as well, for an app...

When last I did this I was able to build Chrome for Ubuntu ARM and copy over Ubuntu's libc and the runtime linker. I didn't have to even rebuild them, so I wouldn't say it was a "completely hacked up libc". It obviously wasn't ideal either, but it's similar to using chroot (only without calling chroot).

GTV forked Android in a binary incompatible way ensuring that no NDK apps can run on it. An entire forked platform!

I'd rather everything ran natively with no trickery, but if I couldn't have that then I'd definitely prefer to have one hacked up app than to ship an entire incompatible platform!

> It's weird that you assume this is the issue, and then explain why it probably wasn't.

Oh, whoops. I don't know why GTV is the way it is, but I assumed it was to support Chrome. Sorry if I'm mistaken; I have no inside knowledge on it. I'm assuming that Chromecast is also a Chimera OS and I'm curious if Google plan to ship it long-term since I don't see Android and Chrome converging technically. I do feel like Android is a better "fit" for something like the Chromecast, though.

The reasons GTV was such a "messed up platform" are entirely mundane (IMHO).

What were those reasons?

Sadly, HN is too public for this kind of conversation.

Slightly OT, but I always recognized you on HN as a lawyer - now I see it appears you have an engineering background as well? Why the switch?

So, without trying to to go into too much detail, I am both. I have a degree in CS, and i actually worked my way up the eng side at google (and other companies) before being a lawyer. Mainly on compilers and version control systems (GCC, LLVM, Subversion). Being both was always my plan, and I actually still do both lawyering and engineering on a daily basis, though i'm an eng manager now rather than an engineer.

> It's a pity that GoogleTV (which the Chromecast OS appears to be derived from) is such a messed up platform.

At least Google TV seems to be heading in the right direction now (Google Cast support coming [1], coming back to mainline 4.2.2 with NDK support [2]). It might be too little, too late, but, as someone who's happy with his Google TVs, I'm hoping there will be room for a Chromecast+ (where the + can be more apps, an ethernet jack and/or better WiFi for streaming and so on).

[1] http://www.theverge.com/2013/7/25/4556420/google-tv-update-t...

[2] http://gigaom.com/2013/05/15/google-tv-android-jelly-bean-up...

"By holding down the single button, while powering the device, the Chromecast boots into USB boot mode. USB boot mode looks for a signed image at 0×1000 on the USB drive. When found, the image is passed to the internal crypto hardware to be verified, but after this process the return code is never checked! Therefore, we can execute any code at will."

I thought the device received power over USB. Do you need a hub to both power the Chromecast and connect the USB flash drive?

Read the article, it uses a powered USB OTG connector.

tl;dr

That's a pretty big screw-up on someone's part - it seems strange that no one tested "does this unsigned image boot".

I'll avoid judgement for a big "screw-up" that lets someone who run what they want on a device they purchased.

Right, "holding down the single button" certainly means the user has physical access, so this sounds like it is by design. There is context to security.

It's amusing, and perhaps a bit distressing, that all the work put into using hardware crypto was defeated by such a simple failure like that.

One will never know if it might've been done on purpose.

Hard to call seemingly advertent actions a failure...

Probably the Marvell first-stage bootloader always verifies what it loads and the decision of whether to enforce or not comes after verification. Google chose not to enforce, good for us :).

Similar in this respect to several Chumby devices (esp. the Chumby 8) which used SoCs with hardware signing, but chose to either disable it or use it in as minimal a fashion as possible.

Or perhaps it was done exactly for that reason : it made testing easier, and they just forgot to turn the check back on before shipping ?

Screw up, or perhaps the engineers understood how many of the people like themselves would want to use it.

Perhaps not just the engineers either.

I'm working with these people: http://dev.moorescloud.com/

Check out the text on the pcb mask just between the bottom row of pads and the microSD card here:

http://dev.moorescloud.com/wp-content/uploads/2013/07/Holida...

We're going to a lot of effort to ensure these are "secure" for regular users – but it's an iMX233 ARM Linux device with a ATmega328 "Arduino" hanging off it – it's eminently hackable, and at least at the current introductory price it's very cost effective compared to, say, a RaspberryPi with a power-supply/case/wifi-adapter/Arduino (which is almost exactly what the prototype was).

While we're working hard to ensure your Christmas tree lights aren't remotely exploitable – if you've got it in your hands and have a screwdriver handy – it's yours to do what you want with. You can pop that SD card out and load your own OS to play with the software, and you've got a bunch of GPIO pins from both the iMX233 and the ATmega328 if you want to play with the hardware. I'll be a little disappointed if no-one's got one controlling a quadcopter or a laser cutter or a 3d printer within a few weeks of them shipping…

Google has a strong history of not locking up devices in beta (and often, not even locking up released products either).

I very much doubt it's a screw up.

Sounds quite likely that even if the return code checking does get patched in, that this will still be vulnerable to Travis Goodspeed's techniques here: https://www.youtube.com/watch?v=ijyAwxH_iok

(So you don't ned to watch right through – though I highly recommend you do – there's a trick he describes where you use a specially crafted "USB Drive" which can return one version of a file the first time it's read, and a different file the second time – if you know you've got a device that reads in a file to check it's signature first, then reads it again assuming it's getting the same content – that assumption isn't necessarily correct… A "smart" USB Drive can return whatever you choose, including a properly signed Google sourced image the first time 0x1000 is read, and whatever else you want the second time when the device is mounting it rather than verifying it.)

The original PS3 jailbreak used a similar trick where the first USB descriptor returned had size A and the second time the descriptor was read it was size B > A. Buffer overrun! =) It required a special device that can act as a USB gadget like a Nokia N900 or AVR-USB micro.

Yeah, Travis credits that with the inspiration for some of his work in the presentation.

That took about as long as I figured it would.

Site is really slow, failed to load a few times for me.

Mirror: http://blog.gtvhacker.com.nyud.net/2013/chromecast-exploitin...

GTVhacker - you are a badass mofo

Reply on news.ycombinator.com