It’s a snowy afternoon in the Adirondacks, and while everyone else is playing Scattergories, I’m playing with IDA.
I’m weird, I know.
I started an adventure in disassembling and reverse engineering my Roku 3 some months ago. It began with me taking the thing apart, snapping some photos, taking some pcaps, and poking at it until I shorted something (oops). The semi-destroyed unit provided a great opportunity for further disassembly, including removing the flash part on the reverse side of the board. With some help from my awesome coworkers and some luck, I was able to recover the contents of the flash, which include a couple of firmware images for the Roku.
A photo of my Roku 3. A complete teardown of the Roku 3 4200X can be found here.
Binwalk was able to fairly painlessly extract two elf images from the flash. Loading them up into IDA revealed that they are VideoCore III ELF files. IDA isn’t really sure what to do with these, besides parsing out the segments and finding some strings. So I spent a day googling and learning about the architecture.
It turns out a more modern version of a Broadcom VideoCore is used on the raspberry pi 3 as the GPU. So the community has done some pretty awesome RE work on this architecture already. Sure, it’s VideoCore IV, but it’s pretty extensive and so far has appeared fairly applicable. Of particular note is the idaplugin, which is a disassembler for the architecture. I dropped vciv.py into my ida/proc directory, and from there, I have something that looks like passable disassembly. Woohoo!
Comparing the two ELF images side-by-side, they look awfully similar. The strings window shows a precisely identical strings list. The entry points have the same code. So for sanity sake, I went ahead and compared the two files with a raw hex diff tool. They’re quite different. The first 5% or so of the files are nearly identical, except for a few bits here and there that could be attributed to read errors. But the other 95% is completely different. I scanned through the diff and found something interesting – a string that seems to indicate a firmware version. My current working theory is that the two images are the same firmware, but different versions. Likely the older version is a fallback version in case of corruption of the newer image.
Firmware version numbers of the two ELF files extracted from flash
While the Roku has wifi, ethernet, and USB, the only obvious mentions (via strings) in the ELF files are for video and audio processing. I’m most interested in the networking stuff at the moment, so I wanted to figure out whether that was probably buried in these images somewhere in a non-obvious fashion, or if it was in a library someplace else in the flash. I took another look at the binwalk output and didn’t quite answer my question, but found something else interesting – a mention of ThreadX. Now I know what it’s running.
Binwalk output mentioning ThreadX, the RTOS most likely running on the Roku 3
I didn’t find any immediate answer to my question about the networking comms, but there are some other files I’d like to extract from the blob, including the u-boot image, a MySQL database, and a couple of GIFs. Given what I’ve read, and because the binwalk output calls the u-boot image an Android bootimg, I suspect at least some of the stuff on the roku is related to the graphics drivers released by Broadcom for the BCM 21553.