Hello Universe, welcome back. It’s been a while since our last post due to a lack of new Google TV hardware and developments. When we have free time we tend to look at other interesting opportunities that come our way and recently we came into just such a situation when we found ourselves auditing multiple Roku devices.

You may not know it by looking at the device, but the Roku is considerably more secure than most entertainment devices in its genre (even our namesake). The engineers at Roku not only implemented a decently hardened grsec kernel, they did it where we hadn’t seen before, on ARM. The layers above that contain a miscellaneous assortment of secure boot and encryption methods with configurations varying between the different chipsets throughout the platform. Our package leverages one such configuration, the bcm2835 chipset, in which user accessible per box keys are used to sign the initial “stage 1” portion of the bootloader. This allows us, from the initial root bug, to modify a portion of the system boot and remove signature verification checks. Effectively breaking the “chain of trust” established and allowing us to load any compatible image desired.

Now for the details. The initial root exploit utilizes a local command execution vulnerability within the developer settings menu of the device. Specifically, the bug is within the development password field, and due to poor sanitation of input, the bug lets us run commands as root. This affects the majority of updated Roku devices and was ironically introduced as a security improvement.  The downside to this bug is that it does not provide a persistent root method (or, in short, a method that continues beyond system restarts). This left us looking for a method to persist root on the device, which is when we noticed the configuration of the bcm2835 Roku devices. In this chipset, the bootloader is signed by a per box key which, in all tested bcm2835 devices, is included on the box.  By having the per box key we are able to break the chain of trust and load a modified “stage 2” bootloader image. In our case we modify the stock U-Boot to include the “dev=1” kernel cmdline argument that identifies a developer device. We then take advantage of a init.d script which allows us to place files in a non-signature validated portion of the file system that is executed when the “dev=1” kernel cmdline argument is set. We use this file to place commands to mount a replacement version of “/bin/Application”, Roku’s main content shell binary, to allow us to disable automatic updates on each boot.

We’ve packaged up all of the above into a nicely commented script which can be downloaded from our download servers at:

The file above contains a script with a cpio archive that includes the following 5 files:

•     bpatch – compiled for the device and used to apply binary patches to files
•     mtd1-uboot.patch – a patch file for bpatch used to patch the U-Boot portion of mtd1
•     nandboot.patch – a patch file for bpatch used to patch nandboot.bin (stage1 bootloader)
•     roku2-nandwrite.ko – a custom kernel module used to modify kernel cmdline in memory and trick the NAND driver into allowing bootloader writes.
•     Application.patch – a patch file for bpatch used to patch /bin/Application to disable updates.

The entire GTVHacker team has put a lot of work into this release and we hope the Roku community enjoys it. We invite others to continue our work and are happy to share progress made while we work to further leverage the current exploits before a patch is released. In the mean time, if you have a second generation Roku, root it. And if you don’t, buy one quick!

This bug will probably get patched soon. So in other words, exploit now or forever hold your peace.