Panel - Google TV or: How I Learned to Stop Worrying and Exploit Secure Boot
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Etemadieh, Amir
Heres, C.J.
Baker, Mike
Nielsen, Hans
Google TV is intended to bring the Android operating system out of the mobile environment and into consumers' living rooms. Unfortunately, content providers began to block streaming access to popular content from the Google TV platform which hindered its reach. Furthermore, the first generation of Google TV hardware used an Intel powered x86 chipset that fractured Google TV from that of the traditional ARM based Android ecosystem, preventing most Android applications with native code from functioning properly. In our previous presentation at DEFCON 20, we discussed exploits found in the first generation of Google TV hardware and software. This presentation will be geared towards the newly released second generation of devices which includes models from a wider variety of OEM's such as Asus, Sony, LG, Vizio, Hisense, and Netgear. Our demonstration will include newly discovered and undisclosed hardware exploits, software exploits, and manufacturer mistakes as well as discuss in detail how to exploit the new Secure Boot environment on the Marvell chipset. In order to bypass Secure Boot on the Google TV we will release two separate exploits which will allow users to run an unsigned bootloader on Google TV devices. One of which affects specific configurations of the Linux kernel that can also be used for priviledge escalation against a multitude of other embedded devices. Finally, after our talk make sure to stop by the Q&A room and ask us a question. We have a limited number of USB TTL adapters to give away for free to aid the community in bootloader and kernel development. Amir Etemadieh founded the GTVHacker group and has been working on the GTVHacker project from its initial start in November 2010. Amir is on the research and development team at Accuvant LABS and prior to his employment conducted independent research in consumer devices including the Logitech Revue, Ooma Telo, Samsung Galaxy S2, Boxee Box as well as services such as the 4G Clear Network. CJ Heres (@cj_000) is an IT consultant by day who enjoys breaking devices ranging from washing machines to Blu-Ray players. His philosophy is to use a simple approach for complex problems. CJ's recent work includes independent research on Hospira and Alaris IV infusion pumps, as well as consumer electronics such as the Roku, Google TV, Boxee Box, and Vizio Smart TV's. Mike Baker (aka [mbm]) is a firmware developer, better known as the Co-Founder behind OpenWrt. He hacks stuff. Hans Nielsen is a security wizard at Matasano Security. When he isn't busy protecting your in-house and external applications from evil, he enjoys hacking apart consumer electronics and designing prototype boards. Hans is a tinkerer at heart with an ability to quickly reverse hardware and software through whatever means necessary.
 Greetings everyone. Welcome to Google TV or how I learned to stop worrying in exploit secure boot. My name is Mike Baker. I'm a firmware developer. I did open WRT. We also have we also have Hans Nielsen who is a senior security consultant at MataSana. We have CJ Hirz, an IT systems administrator. I believe he's out running CTF right now. And we have Tom Dwanger in the audience. And stand up, Tom. And we have Amir Edmada who is a researcher at occupant labs and also the founder of the GTV hacker group. GTV hacker is a group of about six hackers that hack into the Google TV line of products. Our primary goal is to bypass the hardware and software restrictions and open up the device. The GTV hacker team was the first to exploit the Google TV and won a $500 bounty. So what is the Google TV platform? The Google TV platform is an Android device that connects to your TV. So your TV essentially becomes the same Android device as your mobile phone. It has HDMI in, HDMI out, and IR. Some of them include Blu-ray players. The Sony TV has integrated Google TV. It has a custom version of Chrome and a flash version that I'll talk about later. So we have a GTV hacker team that is a developer. We have a GTV hacker team that is a developer. We have a flash version that I'll talk about later. So why do we hack the platform? We hack the platform because unlike the Google Nexus devices, it has a locked boot loader. It has a heavily restricted kernel. And the previous generation, the generation one is now end of life. And the flash player, I'll get to that in the next slides. So before we start, I'm going to do a very quick recap of the stuff we did last year at DEF CON. I'm going to speed through it so if you miss something, go look at last year's slides. So the generation one hardware consists of the Logitech review, the Sony Blu-ray player, and the Sony TV. The Logitech review, they left a root U art. We also have an exploit by Dan Rossenberg that uses DevMem. And SORC wrote an impactor plug-in. Awesome. So the Sony, similar situation. It has a no-dev bug. We also wrote a custom recovery for it and used Kexec to load in a new kernel. So now we have unsigned kernels. So let's talk about the flash player. The flash player was blocked by various streaming sites. So for example, you can't watch Hulu. You get redirected to a site that says, sorry, this is a Google TV. And the fix for that is literally just changing the version string. So what happened after we hacked these Google TV devices? We found this. This is a nice message from Logitech that they hid in the Android recovery. It's a ROT 13 cipher that says, GTV hacker, congratulations if you're reading this, please post a note on the form and let us know. Let me know. And includes all of our nicknames. Yes, whoever is at Logitech that wrote that, you are awesome. This is why we hack devices. So the boxy box is a very similar device. It uses the same SOC. In the process of hacking the Google TV, we also came up with an exploit for the boxy. That led the way to the boxy plus community. And it's still vulnerable. So that's awesome. So next up is Amir. Hi, everyone. I'm going to continue the presentation. My section regards Gen 2 hardware. One of the first O-days we're going to release for the platform. Gen 2 at least. So Gen 2 hardware, we have a multitude of devices. They increase the amount of devices they had by like a factor of 2. And I guess they were going to increase the market share. But essentially you have the Korean LG U plus the S-Suscube, the LG 47 G2 and G3, the Netgear Prime, the Sony NS GS7, GS8, the High Sense Pulse and the Visio CoStar. They have a similar hardware design throughout most of the generation, short of the LG 47 G2 and G3. Generation 2 features a Marvell 88DE3100 base chipset. It's an ARM dual 1.2 GHz processor dubbed the Armada 1500. It features an on-die crypto processor with separate memory and it does secure boot from ROM via RSA verification and AES decryption. This particular slide, there's not a whole lot you need to pull from this. It was just directly from their marketing stuff for the chip. Yeah, it's just here to show you kind of how they pride the chipset itself. Skip the placeholder apparently. So platform information. The newest version of GTV is currently on Android 3.2. There was no public vulnerabilities that worked up until a week ago, maybe a week plus when the master key vulnerability and the key signing bugs were big news and impact wrote his amazing tool ‑‑ sorry, his amazing tool, impactor. It is not a Bionic Lib C setup. It's a fat G Lib C setup and it doesn't support Android native libraries currently. So Gen 1 was an Intel CE 4150 which is an X86 single core atom 1.2 GHz. Gen 2 is a Marvel armata 1500 dual core arm 1.2 GHz. So they switched from X86 to ARM. Android 4.2 incoming for Gen 2 adds native libraries and Bionic Lib C from what we've heard in the rumor mills. So I'm going to go through these devices pretty quickly because it's all public information. I'm sure you guys don't really care too much. 8 gigabyte EMMC flashed inside of the Sony NSCGS7. It has the best remote. So if you're going to buy Google TV, we probably recommend this one. Hard to recommend Sony. Larger form factor than some of the other Google TV devices and it has built‑in IR blasters which sounds like something that would be throughout the entire platform but it's sadly not. The Vizio costar features a smaller form factor, no voice search, a custom launcher, $99 MSRP and updates are actually done through update logic as opposed to the standard Android checking system. It's common in all Vizio devices. So the Heisen's pulse has the second best remote in our opinion. It was launched with ADB running as root when it first was released. So if you pick one up before it's actually updated, you could just ADB in ADB root and ADB has root privileges. So it was patched shortly after and it has a $99 MSRP. With ADB root, there was also a UART root set up I guess for debugging and whatnot. And they had RO debugable set as one. So ADB root was all you really needed if you wanted a software root but if you wanted to have some funds, you know, connect your UART adapters that we give you after this, you could technically connect to that pinout that's right up there. Again, we'll have a select number of USB TTL adapters. So the Netgear Neo TV Prime has a horrible remote. It's $129 MSRP. We had two exploits for it. One was real. One was technically an oversight, at least in our opinion. The oversight was that they went ahead and put the console to start up on UART regardless of what RO.secure was set as. RO.secure is set for like if they're in a debug environment, they'll set RO.secure to zero. And if they're not in a debug environment, they'll set it RO.secure to one for just setting up special block downs. Then we did the Neo TV Prime root which was essentially a exploit that leveraged the update system on the Netgear Neo TV Prime. Essentially the process involves checking if persist.radio.testmode is enabled and if it is, it extracts a testmode.tgz from a USB drive to.tmode and then it just straight executes a shell script from that file. So you get local command execution fairly easily with just a thumb drive with a special TGFC file and shell script. So then the S-Suscube, it's the same generation to hardware, horrible remote again, $139 MSRP. But we really liked this box because of this next part, cube root. So we had a lot of fun with this. We had actually done an Android APK that actually leveraged one of our exploits up until this point. So it was really neat to be able to put this together and certain members were a big portion of this. So this was great because we created an app that not only exploits but it patches your S-Suscube because our whole fear was that releasing an exploit into the market, you know, if someone else takes a look at it, they could put it in their own app and root all your Google TVs. So we set it up so that it can do patching and it can do rooting. But essentially how it worked is it exploited a helper app called OPLAY Helper via a world-rideable domain socket. The helper application passed unsanitized input to the mount command resulting in local command execution. We triggered the vulnerability from Android APK that just literally showed network permissions and it was point click PON. We added it to the Google Play Store just for fun. So with that being said, it was pulled by Google after six days. We rooted around 256 boxes including one engineer build which was pretty cool. And it took two months for them to actually patch it. So, you know, with six days in the market, can you imagine the type of damage someone could have actually done if they were trying to be malicious and not just help people unlock their devices? So then we got to the O-Day that I told you guys about. We haven't ‑‑ we've been using this bug for a while to do our investigations on like new devices and research on new devices to kind of just see how things are set up. So this is kind of something that's near and dear to us because it's worked on the entire platform to date. So what it is, we call it the magic USB. We just like saying magic because we're on the pen and teller stage, I guess. So if you recall our plastic exploits with the Sony Gen 1 GTV, it required four USBs. You could narrow down the number to a lot lower but you had to have a bunch of different images for the USB drive. And it leveraged and properly mounted EXT3 drive that was mounted without Nodev. So this is pretty similar to that. It's NTFS but it's not ‑‑ and it's not done in recovery but it's just as powerful. So all Google TVs and some other Android devices are vulnerable. What this bug is is ‑‑ actually I'll get to that in the next slide. The way that this is set up, it requires a user to have an NTFS removable storage device. It requires the devices to be mounted Nodev when you plug it in so you can easily just run mount and see if it's Nodev. And so it affects more than just Android. It affects certain kernel configurations or certainly its configurations. So with this particular setup, VODE mounts NTFS partitions without Nodev and a little known feature, it does support block devices. So our magic USB essentially the process is that you go, you get the major and minor hashes, you set up a device on a separate computer on an NTFS formatted drive, you plug it into your Google TV and you DD directly to that newly created device that's on your USB drive. The kernel does its magic even though the partitions are mounted read only, it over writes them just beautifully. So we dump the boot image, patch in it.rc or default.prop to RO.secure, we write it back as a user, no root needed. We reboot and we're rooted. So many boxes require an additional step. So now I'm going to go ahead and introduce Hans Nielsen. Oh, yeah. Hello. I'm Hans. So one thing that we really love doing here at GTV Hacker is we like taking things apart and then we like soldering little wires to things. It tickles something deep in our brain that makes us feel very, very good. So there's a few platforms out there, you know, some interesting Google TV platforms. One of them is this TV that's made by LG. It's an interesting implementation of the platform. They use a different chip than the rest of the Gen 2 Google TVs. It has a custom chip called the ARM L9. It's a custom LG SOC that they use in it. LG also signed pretty much everything in terms of images on the flash file system including the boot splash images. So this platform has always kind of eluded us. You know, it's in a 47 inch LCD TV and it's very upmarket because it's a Google TV. It's cool. So this thing is over $1,000 and we really didn't want to spend $1,000 on it. So what are we going to do? Well, I mean, we like taking things apart. We like putting things back together. So we did the next best thing which was on eBay we just bought a power supply and a motherboard from the TV. We didn't actually buy the rest of the TV. And it turns out you can get that for not that much. So as soon as we had this, we did that thing that we love so much. We soldered some wires to it. So this hardware is based around that LG SOC and the storage it uses on this is it uses an EMMC flash chip. So it's very similar to an SD card. It just has a few extra little bits that allow for secure boot storage and other stuff like that. But essentially what it allows us to do is that we can just solder, you know, very few number of wires to this thing and hook it up directly to an SD card reader. And with that SD card reader, we can read and write from the flash on the device at will. You know, no issues here. So like most devices will have a NAND chip. It's much trickier to write those. They have a lot more pins. The interface is, you know, there aren't as many common available pieces of hardware to read that for you. But SD, everyone has an SD reader. So to actually root this thing, we spent a while digging through the file system, seeing what is here, how can we pull stuff apart. At OX 100,000 hex, we found the partition information that tells us where each of the different partitions that are used in this device are. So what we did now was we just went through each of the partitions looking for, okay, is this one signed? Can we do anything with it? Is there fun stuff here? So one of the more interesting partitions as usual is system because that contains the majority of the files used to actually run Google TV. That's where all the APKs live. That's where all the Lib C lives. So like we said, all of the file system stuff was signed pretty much. But it turns out that they did not sign the system image. So once we figured that out, it was just a manner of unpacking the system image, figuring out what in that system image gets quickly called by the boot loader and then messing with it. So it turns out that the boot partition, you can see on the right side here, there is part of the boot scripts, at the bottom it calls this vendor bin initforcedstrip.sh. So that's on system. So we just replaced that file to spawn a shell, connected to UART. Again, we love soldering wires to things. And there we go. Then we have root. All on a device that we never actually bought the full thing of. So another device that we did this to was the Sony NSZ GS7 and GS8. They also went with this EMMC flash interface. So on this platform, neither boot nor system were signed. So just a matter of rewriting those partitions. So the first thing that we did is the usual way to do this in Android is you modify the boot properties to say, okay, RO.secure is zero. So that you can just straight up ADB to the device and everything will just be great, easy, simple. But we did that and it didn't work. So it turns out that the init scripts were actually checking signatures for some stuff and it was also making sure that some of these properties were in set. So it's like, okay, RO.secure must be one. Well, so we went around looking at how is the signature stuff working and it turns out that they're just not verifying those signatures. So it was pretty simple to just replace init and then we were able to do whatever we wanted and, yeah. This is why you don't allow hardware access to systems because you get to do things like this and then we win. Another fun feature that this device had is it had a SATA port, unpopulated SATA header inside the device. But it did actually have the necessary passive components on the hardware to support this. So we saw it at a SATA connector to it and plugged in a hard drive. So far it doesn't appear that the kernel actually supports these things but the hard drive is actually spinning up and we're pretty sure it is working and we'll talk more about that. So beyond those two devices, there's another device that came out very recently, very interesting device, very similar. It's an interesting evolution of the GTV family. Google Chromecast. Google announced this device last week, last Wednesday even. It's $35. This is order of magnitude cheaper than pretty much any current GTV device. It doesn't have the same in and out for HDMI that all the other GTV devices do. It just straight up, you plug it into the TV and then you power it from a USB cable and boom, you have something that you can use to share videos. It's actually a really awesome device and we think it's very cool. In many ways we think it solves some of the issues that GTV has had in the past with, you know, kind of expensive niche platform. It's a really interesting device. Instead of having two thick clients to deal with content, you now have one thinner device that goes with your thick device, say your phone or your computer and you can share content directly to it. So one of the interesting things about that is, so this is a thin device. How are you pushing content to this device? Well, you're not just streaming video from your phone. That's really slow. That's hard to do. So this device is actually reasonably powerful. So what's in it? Well, we pulled it apart as soon as we could. And it turns out that it has pretty standard stuff that you kind of see for an embedded device. It has RAM, it has flash, it has a Wi-Fi chip and it has a CPU. The CPU is a Marvell 88DE3005. Now, this instantly made us go, oh, well, this is cool. Because the Marvell 88DE300 is what we've been seeing in most of the Gen2 Google TVs. So it's very interesting to see this Marvell device in here. And when we saw that, you know, we start getting suspicious. You know, why is this device in here? Maybe this shares similarities to the Google TV platform. So the first thing that we did is say, okay, well, this thing is going to have a UART in it. So let's go find that. So we found the UART and started looking at the kernel output from this device. Turns out that it is very, very, very similar to a Google TV. It even says booting GTV kernel when you look at the UART output. And other things that it has, it has a USB port on it that you use to power it. But when you plug that into your computer example with a standard USB data cable, you don't actually get anything there. The device doesn't show up or anything. That's because it's not actually a USB device. It runs in USB host mode. So you can actually, using a USB on the go cable, plug other devices into the Chromecast directly. Another very, very fun feature was that it has the same boot loader as the DE3100. It shares the, if you look at the source code drop that Google provided for this device, it's the same boot loader. In fact, there's almost no references to the 3005 in there. The references are pretty much all for the 3100. So it's very, very similar to previous Google TV platforms. So of course, the first thing we do is say, okay, well now we have this thing. How can we get root on it? Well, part of that involved, how do we actually get to a point where we can, you know, run a recovery on this device? It's really restricted. All we have is this UART. We've got this host mode USB port and we've got HDMI. And we also have one button. I like buttons. So with this button, because the first thing you do with the button is you press it while it's rebooting, see what happens. And it turns out that holding this button down causes fun things in the boot loader. The boot loader actually has a very special recovery mode where instead of doing a normal, you know, Android style recovery where it boots a Linux kernel and then, you know, you have a whole recovery system there and it does signature verification and all that fun stuff, instead what it does is it's a much lower level recovery. It runs some code in the boot loader that reads directly from a USB stick. So that host mode USB port turns out to be useful for this recovery mode. So the boot loader is really simple. They tried to put not too much stuff in there. So it's not even like it's a file system available for this boot loader. Instead, it just reads directly from the, from OX1000 on that USB key. It leaves just enough space to put a file system, not a file system, an NBR header and then data. So now that we discovered, okay, well, we can actually try and get it to load images from here. How do we figure out what image format it's loading? It's actually the same standard Marvell image format that we've seen on a lot of other Google TV devices. So we found an image. Okay. Well, can we boot stuff? Do we have, you know, signed kernels, other signed images we can try running on here, see if we can get anything to run? Well, we spent some time looking at the code. And what we found was a very significant oversight. It turns out that if you don't verify the result of your signature check, your secure boot doesn't work very well. So the original route for this thing was actually pretty straightforward. Once you figured out all of the weird steps to get there, like you had to hold down the button, you had to have USB on the go, and you had to have a flash drive with stuff at the right spot. And eventually you get to the point you say, oh, okay, I can load an image on here now. Wait, why is my image verification not failing? Well, it's because they don't fail it when you verify the image. So we managed to actually get root on there. It's awesome. Google has already patched this. They released an update for this yesterday. So I don't know how readable the source code is, but essentially that green blob on the right side is the patch from Google that says if ret return one or negative one. So they patched that. We're a little sad, but we are looking into, excuse me. So we have a little tradition at DEF CON. First time speakers get to do a shot on stage. These guys are all first time. Half do. Let's give them all a big round of applause for their first time. Thank you. Just one shot, not 21 shots. They have to be able to finish. And one for everyone in the audience. Cheers. There we go. All right. Notice I didn't say the wife. That is a wife. Cheers. First time speakers. Now we'll see if they can keep going with the presentation and pick up where they left off. I'm not that much of a light weight. Thank you. So that's actually pretty much it for the Chromecast stuff. Very convenient. And now I don't have to worry about speaking with a shot in me. So CJ. So now my introduction, lovely picture. We have through the NTFS trick. It works great. We can write whatever we want. But relating back to the SATA header, we want more. We want to run our own kernels. We don't like locked boot loaders. So secure boot exploit. What's actually make it work. And this time they did, I promise you they checked the return code. So it's a bit more relevant exploit. So to start off, there was the Amato 1000, which was the 8080E3010, the older version of the Amato 1500 or the 8080E3100. Now very similar chips. Just the 8080E3100 was a bit faster. So we believe that this exploit should also work on pretty much every Android based Amato 1000 because the boot loader was provided by Marvel to whoever wanted and the floor is in that. So list of devices it should work on. Left hand side, the Sony NSZ GS7, the NetGanio TV Prime, Visio Costa, Highsense Pulse, Asus Cube, the Sony NSZ GS8, the LG U Plus IPTV, Google's Berlin development device, which is very similar to the Visio Costa. Also devices we believe it should work on but haven't tested because we don't have them. The ZERO desktop Mee PC, which is coming out in about two or three weeks so they could patch it by the highsense XT780 TV, which should be out any moment, might also patch it but sometimes they don't because it's already being produced. The Lenovo S31 slash S61 TV, which is available in China, the TCL Movo that should be out soon and others, there may be other vendors using this chip that we're unaware of. So for a detailed security overview of how the entire system boots. Starting from the internal secure crypto sub-processor, the XT780 TV will then execute the ROM code that's built into it and it will load stage 2. Stage 2 exists either on land, EMMC, or over SPI. But when it loads it in, it will first AES decrypt it with a key that's stored inside the CPU and then it will RSA verify it with its own public-private key pair, you know, RSA file, private, everything else, all that works. So if it decrypts and verifies successfully, it will then return, it will actually have a return code and it will return a 1 or a 0 depending on how it boots and it will either fail or continue. Sorry, I'll slow down. I'll take a sip. Hold on. Another shot. Oh. So next up, stage 2 will then execute. So assuming it verifies, it starts off. And then stage 2 will finish the initialization on EMMC that we could remind you modify to pretty much do whatever we want. And it will then load stage 3 to 0x068000. So that will load in and assuming it then decrypts and verifies properly, it will then execute stage 3. Stage 3 is the boot loader. It's a highly modified version of U-boot. It's mostly stripped out. It's kind of funny but it's simple. It also has, you know, support to secure images. It will send the image directly to the secure boot processor, send it back to make sure it's good. So upon execution, it will then load the kernel to 0x01000800. Assuming then again it decrypts, it verifies and it's all good and it returns a value that it checks. It will then continue to load the RAM disk to 0x, I think that's about 2 million or so. It will call the RAM disk address. Once that's done, it will then execute the kernel. The kernel in the command lines that are set inside the boot loader will then set a hash to check the init script to ensure that the init binary hasn't been tampered with due to the RSA sig checking that was somehow broken. Then it will then verify the RSA signatures on the init scripts which we know don't work but I'm sure they probably will work within about a week. But back to the UART which keep in mind we are giving away UART adapters right after this. They're kind of pointy but they're free. So pulling it up, all the boxes have a UART and we can see they have the start kernel at 0100800000. So again keep that address in mind. It is important. A lot of data to throw at you but it will work. So this is a picture of the Android kernel and model secure image. Normal Android header with the Android magic then has some kernel arguments which it doesn't use. Then some encrypted gunk below it. So keep that Android header kernel header in mind. Now if you take a look at AOSPs boot image dot H, you have a struct for the kernel header itself. Character magic, Android with the exclamation point. Then you have the kernel size, kernel address, RAM disk size, RAM disk address, second size, second address, SHA1 hash, some of the stuff that not really relevant right now. I'm going to pull up a mocked version of this image and give you a minute to review. So the mocked up version of the Android kernel and model secure image. On the top left you have your Android magic. Keep in mind these slides will be posted up maybe in about an hour on DC21.GTVhacker.com with all of the files. We'll get the stuff up on the wiki rather shortly thereafter. Can't really trust the network here so we might wait until Monday when we're back home. But getting back to this, Android magic, then kernel size, then we have the kernel load address. After the kernel load address we have the RAM disk size, the RAM disk load address. Then we have the kernel load arguments which surprisingly are replaced on boot. When we initially started trying to get into this box we attempted, we dumped the image, noticed the Android kernel header, we figured we could mess around with command lines. It might work. Tried that but we wanted to fail safe so we went with the EMMC flashbacker. That wasn't, we were able to replace the kernel arguments but it still wasn't changing to figure they were replaced somehow. Then there's an SHA1 hash which surprisingly we can alter and it will still boot. It does not check that. Followed by that is the actual model secure image which includes a key index, a signature, an encrypted data size, then an RSA 1024 bit signature followed by AES128CBC encrypted data. So they're not messing around. But let's take a second look at that header. The RAM disk size and the RAM disk load address. In the red is the RAM disk size, the black is the RAM disk load address. What we can do for some idiotic reason they do not verify the RAM disk load address. So we can change it to whatever we want and it will execute our code especially if we place it right where the kernel should be loading. This loads in right after the kernel and since we changed the RAM disk load address we can then replace the RAM disk with our own unsigned kernel with SATA support or something. Jam it in there. When we boot the box it will automatically boot up to that. So some pseudo code of what the boot loader code looks like. We have a fixed kernel load address. It does an EMMC read of line four. Some printfs. We thought this was load image. Turns out it's verify image. A verify image on the kernel image itself. And it actually has an if to check the return code. It does an if else. But if you notice after the return it will then load the RAM disk. It will check the RAM disk header size to see what it is and if it's actually set to something. It will then load in an arbitrary amount of data at whatever address we give it. Which horribly insecure because of that we're able to own the box. Now for the Sony NSD GS7 it was a bit different. Sony went above and beyond with the security. They also signed the RAM disk image so we couldn't just replace it. However what we could do is append a small at a small kernel and append it with our RAM disk which was a custom kernel and stick that into the RAM disk location and then just offset the RAM disk load address. So instead of you know 0100008000 we could set it to say 010000980000 is something. And then we could still get a hacked kernel to load in just the right address and still execute. Sony's made quite a few lenders like this trying to improve security. I don't know what's up. So placeholder image and now Uboot. We can for this exploit which we are releasing these packages for most Google TV's right now. You can also trigger and run Uboot which will let you load an unsigned kernel which directly from USB, TFTP or you could modify the source code to wherever you want. The ASUS Cubes GPL release had a version of Uboot that we were able to modify and then get it to execute with no issues and we could load a kernel via TFTP as I said flash or USB for development. So I'm going to skip this future research time and show you guys a quick demo and I'll pass that up. Thank you. I don't use Macs. This is my mouse. Thank you. So we're also going to show the quick, come on. I look totally computer-like. Seriously? Fix me. Nice. We're going to hide this. So what we're doing right now, nothing on the screen. Really? Hey, this is not your not mine. Thanks for that. Yeah, I just, I, this blame isn't totally on me. Blame YouTube. That's awesome. There you go. Move to your right. Yay. Let's get around the sound for everyone in the audience. Sweet. So you're probably not going to make this out. It's going to be on YouTube probably when we're off the stage. Just check out our GTV Hackers channel. What we're doing right now, we're pulling up ASUS Cubes. We're doing the NTFS exploit. We wrote two block devices, I'm sorry, character devices, block of character onto NTFS flash drive. Then we stuck it inside the ASUS cube and what we're going to do right now is run flash erase on the normal one that doesn't work since we don't have group permissions and then run flash erase and Nanrite on our modified version to then insert a customer recovery that we created. Keep in mind our customer recovery is rather thin. It's not like we can just port CWM to it and call it a day. Because CWM's frame buffer uses Android's frame buffer which the Google TV boxes do not have. The Google TV boxes have a very specific custom version which is idiotic. So right now it's showing it being written and erased and we'll give that a moment and watch blurry text but we listen to an old Model People that would rattle away. So that was the erase and now we're going to do the Nanrite and I have a typo so it's going to error at first. Yeah, this took many, many takes because I do not know how to use a camera. So it shows the permission denied trying to write the actual MTD device and then we're going to show my typo. And honestly I do not know what I mistyped but something happened. So there's the error and now we're going to do the actual write of the customer recovery we created. This is the slow file of the video watching everything type and then it picks up. Copy paste, enter, write, write, write, write, write showing that we can write to anything on the box we want using that NTFS trick which should work on many, many devices because most people don't know an NTFS device can use NTFS devices. So now we're rebooting into our customer recovery that you'll see pop up on the right hand side of the screen. Keep in mind that recovery images, kernel images are signed and encrypted. I'm going to show you on the left hand side that we have put my handle for the kernel compiler just showing we're putting in a USB drive with a copy of U-boot on it that we're going to then flash to replace the boot loader. So there's our customer recovery on the right using unsigned code. And now scrolling all the way to the top we did a busy box ID just show we have root over U-o-t. It's also root over ADB and if you want you can modify it to whatever else you want. So command line CJ00GTBHacker just proving that it is our own custom compiled kernel running on the right hand side of the screen. So we're going to reboot the box now pressing one installing the custom U-boot. And it's then completed we're then going to reset, reboot the box and you'll see on the left hand side we'll get a U-boot prompt letting us boot anything we want. Stopping auto boot and we can start whatever we need. So that's pretty much it for the demo video. I'm going to boot it back to NBM to close up. So links to everything that we've covered in this presentation is that dc21.gtvhacker.com. We thank you all for attending and we're going to hand out some UR adapters. We're looking for questions that people who ask questions will get priority on UR adapters and after that we'll hand out whatever is left. So if we can get some quick questions, anyone? Right here? He said what experience do we have getting Android applications that are not built for the Google TV with native code to run on the Google TV. I actually did put together a native development kit for Google TV but it's not in a good state that I feel comfortable releasing. I built a connect box APK with just some like it does very minimal, like it uses very minimal native code but it works, I tested the native code, it works fine. If anyone in the community wants to step forward and you know, help out with that we'd appreciate it. Anyone else? Right here? He asked if we've tried JTAG debugging or if UR is sufficient. UR has been sufficient up until this point. We've looked at some of the JTAG pinouts but we haven't made a whole lot of progress with them. In the gen one we did ‑‑ we really honestly haven't needed it at this point. If we got down to it we'd go that route but we just ‑‑ we haven't yet. Do you want to give him one? Anyone? Next question? Right here? He asked besides Hulu what other content providers have we had issues with? CBS, Fox, just miscellaneous flash streaming sites. It's actually kind of ridiculous the number of people who actually choose to block us or block Google TV in general. He asked how many of we had success bypassing their mitigations, all of them. Essentially we just mimic the desktop flash setup. So if you want to give him one. I think we're running low on time so let me get one or two more questions. Okay. Like a guy in the red shirt and then we'll get the guy in the black shirt behind him. Can you repeat the question? I'm sorry. It hasn't been something ‑‑ he asked if we tried to get Python or Perl or any other coding scripting languages on the box. We haven't actually worked on that but it would absolutely be possible. Yeah. So it's Linux at its core. So ‑‑ let me get this ‑‑ I'm sorry. Oh, wow. Good throw. Black shirt puller? He asked what's next for the Chromecast. We are looking at other avenues of exploitation but we are afraid to mention exactly what they are based on how quickly it was patched and also that we're here so if we say anything publicly, it could bite us in the butt. So if you want to ‑‑ someone give that gentleman one or throw one at him, sorry. Yeah, please ‑‑ oh, my God. Okay. You know, let's use the honor system and pass that to him if that's cool or just leave it for Penn and Teller. I think the gentleman in the black shirt next to him had a question unless it was already there. No, we'd actually really love to know. So if they're here or anyone from Google is here and they'd like to talk to us, we'd really appreciate it. We haven't really had an open communication with Google about much of anything. I don't know if they hate us or not. And we kind of get the opinion they do because they tend to shy away from ever speaking to us. So, huh? Publicly, exactly. But let's give him a UR and we'll continue this in the Q&A room. Oh, my God, dude! Holy ‑‑ okay, this is getting bad. So we'll follow up in the Q&A room where we can hand these things out directly instead of hurting anyone. So, yes, I'm sorry, we don't have time for any more questions but we will have time in the other room if ‑‑ we will have time in the other room if any of you guys want to follow up. Thank you. Thank you. You did great. Thank you. I hope we didn't hurt you.
 Greetings everyone. Welcome to Google TV or how I learned to stop worrying in exploit secure boot.  My name is Mike Baker. I'm a firmware developer. I did open WRT. We also have  we also have Hans Nielsen who is a senior security consultant at  MataSana. We have CJ Hirz, an IT systems administrator. I believe he's out running  CTF right now. And we have Tom Dwanger in the audience. And stand up, Tom. And we have  Amir Edmada who is a researcher at occupant labs and also the founder of the GTV hacker group.  GTV hacker is a group of about six hackers that hack into the Google TV line of products. Our  primary goal is to bypass the hardware and software restrictions and open up the device. The  GTV hacker team was the first to exploit the Google TV and won a $500 bounty. So what is the  Google TV platform? The Google TV platform is an Android device that connects to your TV. So  your TV essentially becomes the same Android device as your mobile phone. It has HDMI in, HDMI  out, and IR. Some of them include Blu-ray players. The Sony TV has integrated Google TV. It  has a custom version of Chrome and a flash version that I'll talk about later. So we have  a GTV hacker team that is a developer. We have a GTV hacker team that is a developer. We have  a flash version that I'll talk about later. So why do we hack the platform? We hack the  platform because unlike the Google Nexus devices, it has a locked boot loader. It has a heavily  restricted kernel. And the previous generation, the generation one is now end of life. And the  flash player, I'll get to that in the next slides. So before we start, I'm going to do a very  quick recap of the stuff we did last year at DEF CON. I'm going to speed through it so if you  miss something, go look at last year's slides. So the generation one hardware consists of the  Logitech review, the Sony Blu-ray player, and the Sony TV. The Logitech review, they left a root U  art. We also have an exploit by Dan Rossenberg that uses DevMem. And SORC wrote an impactor plug-in.  Awesome. So the Sony, similar situation. It has a no-dev bug. We also wrote a custom recovery for  it and used Kexec to load in a new kernel. So now we have unsigned kernels. So let's talk  about the flash player. The flash player was blocked by various streaming sites. So for  example, you can't watch Hulu. You get redirected to a site that says, sorry, this is a Google TV.  And the fix for that is literally just changing the version string. So what happened after we  hacked these Google TV devices? We found this. This is a nice message from Logitech that they  hid in the Android recovery. It's a ROT 13 cipher that says, GTV hacker, congratulations if  you're reading this, please post a note on the form and let us know. Let me know. And includes  all of our nicknames. Yes, whoever is at Logitech that wrote that, you are awesome. This is why we  hack devices. So the boxy box is a very similar device. It uses the same SOC. In the process of  hacking the Google TV, we also came up with an exploit for the boxy. That led the way to the  boxy plus community. And it's still vulnerable. So that's awesome. So next up is Amir.  Hi, everyone. I'm going to continue the presentation. My section regards Gen 2 hardware. One of  the first O-days we're going to release for the platform. Gen 2 at least. So Gen 2 hardware, we  have a multitude of devices. They increase the amount of devices they had by like a factor of 2. And  I guess they were going to increase the market share. But essentially you have the Korean LG U  plus the S-Suscube, the LG 47 G2 and G3, the Netgear Prime, the Sony NS GS7, GS8, the High Sense  Pulse and the Visio CoStar. They have a similar hardware design throughout most of the generation,  short of the LG 47 G2 and G3. Generation 2 features a Marvell 88DE3100 base chipset. It's an  ARM dual 1.2 GHz processor dubbed the Armada 1500. It features an on-die crypto processor with  separate memory and it does secure boot from ROM via RSA verification and AES decryption. This  particular slide, there's not a whole lot you need to pull from this. It was just directly from  their marketing stuff for the chip. Yeah, it's just here to show you kind of how they pride the  chipset itself. Skip the placeholder apparently. So platform information. The newest version of GTV is  currently on Android 3.2. There was no public vulnerabilities that worked up until a week ago,  maybe a week plus when the master key vulnerability and the key signing bugs were big news and  impact wrote his amazing tool ‑‑ sorry, his amazing tool, impactor. It is not a Bionic  Lib C setup. It's a fat G Lib C setup and it doesn't support Android native libraries currently.  So Gen 1 was an Intel CE 4150 which is an X86 single core atom 1.2 GHz. Gen 2 is a Marvel  armata 1500 dual core arm 1.2 GHz. So they switched from X86 to ARM. Android 4.2 incoming for Gen 2  adds native libraries and Bionic Lib C from what we've heard in the rumor mills. So I'm going to go  through these devices pretty quickly because it's all public information. I'm sure you guys don't  really care too much. 8 gigabyte EMMC flashed inside of the Sony NSCGS7. It has the best remote.  So if you're going to buy Google TV, we probably recommend this one. Hard to recommend Sony. Larger  form factor than some of the other Google TV devices and it has built‑in IR blasters which  sounds like something that would be throughout the entire platform but it's sadly not. The Vizio  costar features a smaller form factor, no voice search, a custom launcher, $99 MSRP and updates  are actually done through update logic as opposed to the standard Android checking system. It's  common in all Vizio devices. So the Heisen's pulse has the second best remote in our opinion. It  was launched with ADB running as root when it first was released. So if you pick one up before  it's actually updated, you could just ADB in ADB root and ADB has root privileges. So it was  patched shortly after and it has a $99 MSRP. With ADB root, there was also a UART root set up I  guess for debugging and whatnot. And they had RO debugable set as one. So ADB root was all you  really needed if you wanted a software root but if you wanted to have some funds, you know,  connect your UART adapters that we give you after this, you could technically connect to that  pinout that's right up there. Again, we'll have a select number of USB TTL adapters. So the  Netgear Neo TV Prime has a horrible remote. It's $129 MSRP. We had two exploits for it. One was  real. One was technically an oversight, at least in our opinion. The oversight was that they went  ahead and put the console to start up on UART regardless of what RO.secure was set as. RO.secure  is set for like if they're in a debug environment, they'll set RO.secure to zero. And if they're  not in a debug environment, they'll set it RO.secure to one for just setting up special  block downs. Then we did the Neo TV Prime root which was essentially a exploit that leveraged  the update system on the Netgear Neo TV Prime. Essentially the process involves checking if  persist.radio.testmode is enabled and if it is, it extracts a testmode.tgz from a USB drive to .tmode and then it just straight executes a shell script from that file. So you get local  command execution fairly easily with just a thumb drive with a special TGFC file and shell  script. So then the S-Suscube, it's the same generation to hardware, horrible remote again,  $139 MSRP. But we really liked this box because of this next part, cube root. So we had a lot of  fun with this. We had actually done an Android APK that actually leveraged one of our exploits up  until this point. So it was really neat to be able to put this together and certain members were  a big portion of this. So this was great because we created an app that not only exploits but it  patches your S-Suscube because our whole fear was that releasing an exploit into the market, you  know, if someone else takes a look at it, they could put it in their own app and root all your  Google TVs. So we set it up so that it can do patching and it can do rooting. But essentially how  it worked is it exploited a helper app called OPLAY Helper via a world-rideable domain socket.  The helper application passed unsanitized input to the mount command resulting in local command  execution. We triggered the vulnerability from Android APK that just literally showed network  permissions and it was point click PON. We added it to the Google Play Store just for fun. So  with that being said, it was pulled by Google after six days. We rooted around 256 boxes including  one engineer build which was pretty cool. And it took two months for them to actually patch it.  So, you know, with six days in the market, can you imagine the type of damage someone could have  actually done if they were trying to be malicious and not just help people unlock their devices? So  then we got to the O-Day that I told you guys about. We haven't ‑‑ we've been using this bug  for a while to do our investigations on like new devices and research on new devices to kind of  just see how things are set up. So this is kind of something that's near and dear to us because  it's worked on the entire platform to date. So what it is, we call it the magic USB. We just  like saying magic because we're on the pen and teller stage, I guess. So if you recall our  plastic exploits with the Sony Gen 1 GTV, it required four USBs. You could narrow down the  number to a lot lower but you had to have a bunch of different images for the USB drive. And it  leveraged and properly mounted EXT3 drive that was mounted without Nodev. So this is pretty  similar to that. It's NTFS but it's not ‑‑ and it's not done in recovery but it's just as  powerful. So all Google TVs and some other Android devices are vulnerable. What this bug is is  ‑‑ actually I'll get to that in the next slide. The way that this is set up, it requires a  user to have an NTFS removable storage device. It requires the devices to be mounted Nodev when  you plug it in so you can easily just run mount and see if it's Nodev. And so it affects more than  just Android. It affects certain kernel configurations or certainly its configurations. So  with this particular setup, VODE mounts NTFS partitions without Nodev and a little known  feature, it does support block devices. So our magic USB essentially the process is that you  go, you get the major and minor hashes, you set up a device on a separate computer on an NTFS  formatted drive, you plug it into your Google TV and you DD directly to that newly created  device that's on your USB drive. The kernel does its magic even though the partitions are  mounted read only, it over writes them just beautifully. So we dump the boot image, patch  in it.rc or default.prop to RO.secure, we write it back as a user, no root needed. We reboot  and we're rooted. So many boxes require an additional step. So now I'm going to go ahead and  introduce Hans Nielsen. Oh, yeah. Hello. I'm Hans. So one thing that we really love doing here at  GTV Hacker is we like taking things apart and then we like soldering little wires to things.  It tickles something deep in our brain that makes us feel very, very good. So there's a few  platforms out there, you know, some interesting Google TV platforms. One of them is this TV  that's made by LG. It's an interesting implementation of the platform. They use a different  chip than the rest of the Gen 2 Google TVs. It has a custom chip called the ARM L9. It's a  custom LG SOC that they use in it. LG also signed pretty much everything in terms of images on  the flash file system including the boot splash images. So this platform has always kind of  eluded us. You know, it's in a 47 inch LCD TV and it's very upmarket because it's a Google TV.  It's cool. So this thing is over $1,000 and we really didn't want to spend $1,000 on it. So  what are we going to do? Well, I mean, we like taking things apart. We like putting things back  together. So we did the next best thing which was on eBay we just bought a power supply and a  motherboard from the TV. We didn't actually buy the rest of the TV. And it turns out you can get  that for not that much. So as soon as we had this, we did that thing that we love so much. We  soldered some wires to it. So this hardware is based around that LG SOC and the storage it  uses on this is it uses an EMMC flash chip. So it's very similar to an SD card. It just has a  few extra little bits that allow for secure boot storage and other stuff like that. But  essentially what it allows us to do is that we can just solder, you know, very few number of  wires to this thing and hook it up directly to an SD card reader. And with that SD card reader, we  can read and write from the flash on the device at will. You know, no issues here. So like most  devices will have a NAND chip. It's much trickier to write those. They have a lot more pins. The  interface is, you know, there aren't as many common available pieces of hardware to read that for  you. But SD, everyone has an SD reader. So to actually root this thing, we spent a while digging  through the file system, seeing what is here, how can we pull stuff apart. At OX 100,000 hex, we  found the partition information that tells us where each of the different partitions that are  used in this device are. So what we did now was we just went through each of the partitions  looking for, okay, is this one signed? Can we do anything with it? Is there fun stuff here? So one  of the more interesting partitions as usual is system because that contains the majority of the  files used to actually run Google TV. That's where all the APKs live. That's where all the  Lib C lives. So like we said, all of the file system stuff was signed pretty much. But it turns  out that they did not sign the system image. So once we figured that out, it was just a  manner of unpacking the system image, figuring out what in that system image gets quickly  called by the boot loader and then messing with it. So it turns out that the boot partition,  you can see on the right side here, there is part of the boot scripts, at the bottom it  calls this vendor bin initforcedstrip.sh. So that's on system. So we just replaced that file to  spawn a shell, connected to UART. Again, we love soldering wires to things. And there we go.  Then we have root. All on a device that we never actually bought the full thing of. So another  device that we did this to was the Sony NSZ GS7 and GS8. They also went with this  EMMC flash interface. So on this platform, neither boot nor system were signed. So just a  matter of rewriting those partitions. So the first thing that we did is the usual way to do  this in Android is you modify the boot properties to say, okay, RO.secure is zero. So that you  can just straight up ADB to the device and everything will just be great, easy, simple. But  we did that and it didn't work. So it turns out that the init scripts were actually checking  signatures for some stuff and it was also making sure that some of these properties were  in set. So it's like, okay, RO.secure must be one. Well, so we went around looking at how is  the signature stuff working and it turns out that they're just not verifying those signatures. So  it was pretty simple to just replace init and then we were able to do whatever we wanted and, yeah.  This is why you don't allow hardware access to systems because you get to do things like this and  then we win. Another fun feature that this device had is it had a SATA port, unpopulated SATA  header inside the device. But it did actually have the necessary passive components on the  hardware to support this. So we saw it at a SATA connector to it and plugged in a hard drive. So  far it doesn't appear that the kernel actually supports these things but the hard drive is  actually spinning up and we're pretty sure it is working and we'll talk more about that. So  beyond those two devices, there's another device that came out very recently, very interesting  device, very similar. It's an interesting evolution of the GTV family. Google Chromecast. Google  announced this device last week, last Wednesday even. It's $35. This is order of magnitude cheaper  than pretty much any current GTV device. It doesn't have the same in and out for HDMI that all the  other GTV devices do. It just straight up, you plug it into the TV and then you power it from a  USB cable and boom, you have something that you can use to share videos. It's actually a really  awesome device and we think it's very cool. In many ways we think it solves some of the issues  that GTV has had in the past with, you know, kind of expensive niche platform. It's a really  interesting device. Instead of having two thick clients to deal with content, you now have one  thinner device that goes with your thick device, say your phone or your computer and you can share  content directly to it. So one of the interesting things about that is, so this is a thin device.  How are you pushing content to this device? Well, you're not just streaming video from your  phone. That's really slow. That's hard to do. So this device is actually reasonably powerful.  So what's in it? Well, we pulled it apart as soon as we could. And it turns out that it has pretty  standard stuff that you kind of see for an embedded device. It has RAM, it has flash, it has a  Wi-Fi chip and it has a CPU. The CPU is a Marvell 88DE3005. Now, this instantly made us go, oh,  well, this is cool. Because the Marvell 88DE300 is what we've been seeing in most of the Gen2  Google TVs. So it's very interesting to see this Marvell device in here. And when we saw that,  you know, we start getting suspicious. You know, why is this device in here? Maybe this  shares similarities to the Google TV platform. So the first thing that we did is say, okay,  well, this thing is going to have a UART in it. So let's go find that. So we found the UART and  started looking at the kernel output from this device. Turns out that it is very, very, very  similar to a Google TV. It even says booting GTV kernel when you look at the UART output. And  other things that it has, it has a USB port on it that you use to power it. But when you  plug that into your computer example with a standard USB data cable, you don't actually get  anything there. The device doesn't show up or anything. That's because it's not actually a USB  device. It runs in USB host mode. So you can actually, using a USB on the go cable, plug other  devices into the Chromecast directly. Another very, very fun feature was that it has the same  boot loader as the DE3100. It shares the, if you look at the source code drop that Google  provided for this device, it's the same boot loader. In fact, there's almost no references to  the 3005 in there. The references are pretty much all for the 3100. So it's very, very similar to  previous Google TV platforms. So of course, the first thing we do is say, okay, well now we  have this thing. How can we get root on it? Well, part of that involved, how do we actually get  to a point where we can, you know, run a recovery on this device? It's really restricted. All we  have is this UART. We've got this host mode USB port and we've got HDMI. And we also have one  button. I like buttons. So with this button, because the first thing you do with the button is  you press it while it's rebooting, see what happens. And it turns out that holding this button  down causes fun things in the boot loader. The boot loader actually has a very special  recovery mode where instead of doing a normal, you know, Android style recovery where it boots a  Linux kernel and then, you know, you have a whole recovery system there and it does signature  verification and all that fun stuff, instead what it does is it's a much lower level recovery.  It runs some code in the boot loader that reads directly from a USB stick. So that host mode  USB port turns out to be useful for this recovery mode. So the boot loader is really simple.  They tried to put not too much stuff in there. So it's not even like it's a file system  available for this boot loader. Instead, it just reads directly from the, from OX1000 on that  USB key. It leaves just enough space to put a file system, not a file system, an NBR header  and then data. So now that we discovered, okay, well, we can actually try and get it to load  images from here. How do we figure out what image format it's loading? It's actually the same  standard Marvell image format that we've seen on a lot of other Google TV devices. So we found an  image. Okay. Well, can we boot stuff? Do we have, you know, signed kernels, other signed  images we can try running on here, see if we can get anything to run? Well, we spent some time  looking at the code. And what we found was a very significant oversight. It turns out that if you  don't verify the result of your signature check, your secure boot doesn't work very well. So the  original route for this thing was actually pretty straightforward. Once you figured out all of  the weird steps to get there, like you had to hold down the button, you had to have USB on the  go, and you had to have a flash drive with stuff at the right spot. And eventually you get to the  point you say, oh, okay, I can load an image on here now. Wait, why is my image verification not  failing? Well, it's because they don't fail it when you verify the image. So we managed to  actually get root on there. It's awesome. Google has already patched this. They released an update  for this yesterday. So I don't know how readable the source code is, but essentially that green  blob on the right side is the patch from Google that says if ret return one or negative one. So  they patched that. We're a little sad, but we are looking into, excuse me. So we have a little  tradition at DEF CON. First time speakers get to do a shot on stage. These guys are all first  time. Half do. Let's give them all a big round of applause for their first time.  Thank you.  Just one shot, not 21 shots. They have to be able to finish. And one for everyone in the  audience. Cheers. There we go.  All right.  Notice I didn't say the wife. That is a wife.  Cheers. First time speakers.  Now we'll see if they can keep going with the presentation and pick up where they left off.  I'm not that much of a light weight. Thank you.  So that's actually pretty much it for the Chromecast stuff. Very convenient. And now I don't  have to worry about speaking with a shot in me. So CJ.  So now my introduction, lovely picture. We have through the NTFS trick. It works great. We can  write whatever we want. But relating back to the SATA header, we want more. We want to run  our own kernels. We don't like locked boot loaders. So secure boot exploit. What's actually  make it work. And this time they did, I promise you they checked the return code. So it's a bit  more relevant exploit. So to start off, there was the Amato 1000, which was the 8080E3010, the  older version of the Amato 1500 or the 8080E3100. Now very similar chips. Just the 8080E3100 was  a bit faster. So we believe that this exploit should also work on pretty much every Android  based Amato 1000 because the boot loader was provided by Marvel to whoever wanted and the  floor is in that. So list of devices it should work on. Left hand side, the Sony NSZ GS7, the  NetGanio TV Prime, Visio Costa, Highsense Pulse, Asus Cube, the Sony NSZ GS8, the LG U Plus IPTV,  Google's Berlin development device, which is very similar to the Visio Costa. Also devices we  believe it should work on but haven't tested because we don't have them. The ZERO desktop  Mee PC, which is coming out in about two or three weeks so they could patch it by the  highsense XT780 TV, which should be out any moment, might also patch it but sometimes they  don't because it's already being produced. The Lenovo S31 slash S61 TV, which is available  in China, the TCL Movo that should be out soon and others, there may be other vendors using  this chip that we're unaware of. So for a detailed security overview of how the entire  system boots. Starting from the internal secure crypto sub-processor, the XT780 TV  will then execute the ROM code that's built into it and it will load stage 2. Stage 2  exists either on land, EMMC, or over SPI. But when it loads it in, it will first AES  decrypt it with a key that's stored inside the CPU and then it will RSA verify it with its own  public-private key pair, you know, RSA file, private, everything else, all that works. So if  it decrypts and verifies successfully, it will then return, it will actually have a return  code and it will return a 1 or a 0 depending on how it boots and it will either fail or continue.  Sorry, I'll slow down. I'll take a sip. Hold on. Another shot. Oh.  So next up, stage 2 will then execute. So assuming it verifies, it starts off. And  then stage 2 will finish the initialization on EMMC that we could remind you  modify to pretty much do whatever we want. And it will then load stage 3 to 0x068000. So  that will load in and assuming it then decrypts and verifies properly, it will then  execute stage 3. Stage 3 is the boot loader. It's a highly modified version of U-boot. It's  mostly stripped out. It's kind of funny but it's simple. It also has, you know, support to  secure images. It will send the image directly to the secure boot processor, send it back to  make sure it's good. So upon execution, it will then load the kernel to 0x01000800.  Assuming then again it decrypts, it verifies and it's all good and it returns a value that it  checks. It will then continue to load the RAM disk to 0x, I think that's about 2 million or so.  It will call the RAM disk address. Once that's done, it will then execute the kernel. The kernel  in the command lines that are set inside the boot loader will then set a hash to check the  init script to ensure that the init binary hasn't been tampered with due to the RSA sig  checking that was somehow broken. Then it will then verify the RSA signatures on the init  scripts which we know don't work but I'm sure they probably will work within about a week. But  back to the UART which keep in mind we are giving away UART adapters right after this. They're  kind of pointy but they're free. So pulling it up, all the boxes have a UART and we can see  they have the start kernel at 0100800000. So again keep that address in mind. It is  important. A lot of data to throw at you but it will work. So this is a picture of the Android  kernel and model secure image. Normal Android header with the Android magic then has some  kernel arguments which it doesn't use. Then some encrypted gunk below it. So keep that  Android header kernel header in mind. Now if you take a look at AOSPs boot image dot H, you  have a struct for the kernel header itself. Character magic, Android with the exclamation  point. Then you have the kernel size, kernel address, RAM disk size, RAM disk address,  second size, second address, SHA1 hash, some of the stuff that not really relevant right  now. I'm going to pull up a mocked version of this image and give you a minute to review.  So the mocked up version of the Android kernel and model secure image. On the top left you have  your Android magic. Keep in mind these slides will be posted up maybe in about an hour on  DC21.GTVhacker.com with all of the files. We'll get the stuff up on the wiki rather  shortly thereafter. Can't really trust the network here so we might wait until Monday when  we're back home. But getting back to this, Android magic, then kernel size, then we have the  kernel load address. After the kernel load address we have the RAM disk size, the RAM disk  load address. Then we have the kernel load arguments which surprisingly are replaced on  boot. When we initially started trying to get into this box we attempted, we dumped the  image, noticed the Android kernel header, we figured we could mess around with command lines.  It might work. Tried that but we wanted to fail safe so we went with the EMMC flashbacker.  That wasn't, we were able to replace the kernel arguments but it still wasn't changing to  figure they were replaced somehow. Then there's an SHA1 hash which surprisingly we can  alter and it will still boot. It does not check that. Followed by that is the actual  model secure image which includes a key index, a signature, an encrypted data size, then an  RSA 1024 bit signature followed by AES128CBC encrypted data. So they're not messing around.  But let's take a second look at that header. The RAM disk size and the RAM disk load address.  In the red is the RAM disk size, the black is the RAM disk load address. What we can do  for some idiotic reason they do not verify the RAM disk load address. So we can change it to  whatever we want and it will execute our code especially if we place it right where the kernel  should be loading. This loads in right after the kernel and since we changed the RAM disk load  address we can then replace the RAM disk with our own unsigned kernel with SATA support or  something. Jam it in there. When we boot the box it will automatically boot up to that. So  some pseudo code of what the boot loader code looks like. We have a fixed kernel load address.  It does an EMMC read of line four. Some printfs. We thought this was load image. Turns out  it's verify image. A verify image on the kernel image itself. And it actually has an if to  check the return code. It does an if else. But if you notice after the return it will then  load the RAM disk. It will check the RAM disk header size to see what it is and if it's actually  set to something. It will then load in an arbitrary amount of data at whatever address we give it.  Which horribly insecure because of that we're able to own the box. Now for the Sony NSD GS7 it  was a bit different. Sony went above and beyond with the security. They also signed the RAM disk  image so we couldn't just replace it. However what we could do is append a small at a small  kernel and append it with our RAM disk which was a custom kernel and stick that into the RAM disk  location and then just offset the RAM disk load address. So instead of you know 0100008000 we  could set it to say 010000980000 is something. And then we could still get a hacked kernel to load  in just the right address and still execute. Sony's made quite a few lenders like this trying  to improve security. I don't know what's up. So placeholder image and now Uboot. We can  for this exploit which we are releasing these packages for most Google TV's right now. You  can also trigger and run Uboot which will let you load an unsigned kernel which directly from  USB, TFTP or you could modify the source code to wherever you want. The ASUS Cubes GPL release  had a version of Uboot that we were able to modify and then get it to execute with no issues  and we could load a kernel via TFTP as I said flash or USB for development. So I'm going to  skip this future research time and show you guys a quick demo and I'll pass that up. Thank you. I  don't use Macs. This is my mouse. Thank you. So we're also going to show the quick, come on. I  look totally computer-like. Seriously? Fix me. Nice. We're going to hide this. So what we're  doing right now, nothing on the screen. Really? Hey, this is not your not mine. Thanks for that. Yeah, I just, I, this blame isn't totally on me. Blame  YouTube. That's awesome. There you go. Move to your right. Yay. Let's get around the sound for everyone in the  audience. Sweet. So you're probably not going to make this out. It's going to be on YouTube probably when we're off the  stage. Just check out our GTV Hackers channel. What we're doing right now, we're pulling up ASUS Cubes. We're  doing the NTFS exploit. We wrote two block devices, I'm sorry, character devices, block of character onto  NTFS flash drive. Then we stuck it inside the ASUS cube and what we're going to do right now is run flash  erase on the normal one that doesn't work since we don't have group permissions and then run flash  erase and Nanrite on our modified version to then insert a customer recovery that we created. Keep  in mind our customer recovery is rather thin. It's not like we can just port CWM to it and call it a day. Because  CWM's frame buffer uses Android's frame buffer which the Google TV boxes do not have. The Google TV  boxes have a very specific custom version which is idiotic. So right now it's showing it being  written and erased and we'll give that a moment and watch blurry text but we listen to an old Model  People that would rattle away. So that was the erase and now we're going to do the Nanrite and I have  a typo so it's going to error at first. Yeah, this took many, many takes because I do not know how to  use a camera. So it shows the permission denied trying to write the actual MTD device and then we're  going to show my typo. And honestly I do not know what I mistyped but something happened. So there's  the error and now we're going to do the actual write of the customer recovery we created. This is the  slow file of the video watching everything type and then it picks up. Copy paste, enter, write, write,  write, write, write showing that we can write to anything on the box we want using that NTFS trick  which should work on many, many devices because most people don't know an NTFS device can use  NTFS devices. So now we're rebooting into our customer recovery that you'll see pop up on the  right hand side of the screen. Keep in mind that recovery images, kernel images are signed and  encrypted. I'm going to show you on the left hand side that we have put my handle for the kernel  compiler just showing we're putting in a USB drive with a copy of U-boot on it that we're going to  then flash to replace the boot loader. So there's our customer recovery on the right using unsigned  code. And now scrolling all the way to the top we did a busy box ID just show we have root  over U-o-t. It's also root over ADB and if you want you can modify it to whatever else you want.  So command line CJ00GTBHacker just proving that it is our own custom compiled kernel running on  the right hand side of the screen. So we're going to reboot the box now pressing one installing  the custom U-boot. And it's then completed we're then going to reset, reboot the box and you'll see  on the left hand side we'll get a U-boot prompt letting us boot anything we want. Stopping auto  boot and we can start whatever we need. So that's pretty much it for the demo video. I'm going to  boot it back to NBM to close up. So links to everything that we've covered in this presentation is  that dc21.gtvhacker.com. We thank you all for attending and we're going to hand out some UR  adapters. We're looking for questions that people who ask questions will get priority on UR  adapters and after that we'll hand out whatever is left. So if we can get some quick questions,  anyone? Right here? He said what experience do we have getting Android applications that are  not built for the Google TV with native code to run on the Google TV. I actually did put  together a native development kit for Google TV but it's not in a good state that I feel  comfortable releasing. I built a connect box APK with just some like it does very minimal,  like it uses very minimal native code but it works, I tested the native code, it works fine.  If anyone in the community wants to step forward and you know, help out with that we'd  appreciate it. Anyone else? Right here? He asked if we've tried JTAG debugging or if UR  is sufficient. UR has been sufficient up until this point. We've looked at some of the JTAG  pinouts but we haven't made a whole lot of progress with them. In the gen one we did ‑‑  we really honestly haven't needed it at this point. If we got down to it we'd go that route  but we just ‑‑ we haven't yet. Do you want to give him one? Anyone? Next question? Right  here? He asked besides Hulu what other content providers have we had issues with? CBS, Fox,  just miscellaneous flash streaming sites. It's actually kind of ridiculous the number of  people who actually choose to block us or block Google TV in general. He asked how many of  we had success bypassing their mitigations, all of them. Essentially we just mimic the  desktop flash setup. So if you want to give him one. I think we're running low on time so  let me get one or two more questions. Okay. Like a guy in the red shirt and then we'll get  the guy in the black shirt behind him. Can you repeat the question? I'm sorry. It hasn't  been something ‑‑ he asked if we tried to get Python or Perl or any other coding scripting  languages on the box. We haven't actually worked on that but it would absolutely be  possible. Yeah. So it's Linux at its core. So ‑‑ let me get this ‑‑ I'm sorry.  Oh, wow. Good throw. Black shirt puller? He asked what's next for the Chromecast. We are  looking at other avenues of exploitation but we are afraid to mention exactly what they are  based on how quickly it was patched and also that we're here so if we say anything publicly,  it could bite us in the butt. So if you want to ‑‑ someone give that gentleman one or  throw one at him, sorry. Yeah, please ‑‑ oh, my God. Okay. You know, let's use the  honor system and pass that to him if that's cool or just leave it for Penn and Teller. I  think the gentleman in the black shirt next to him had a question unless it was already  there. No, we'd actually really love to know. So if they're here or anyone from Google is  here and they'd like to talk to us, we'd really appreciate it. We haven't really had an open  communication with Google about much of anything. I don't know if they hate us or not. And we  kind of get the opinion they do because they tend to shy away from ever speaking to us. So,  huh? Publicly, exactly. But let's give him a UR and we'll continue this in the Q&A room. Oh,  my God, dude! Holy ‑‑ okay, this is getting bad. So we'll follow up in the Q&A room where we  can hand these things out directly instead of hurting anyone. So, yes, I'm sorry, we don't  have time for any more questions but we will have time in the other room if ‑‑ we will have  time in the other room if any of you guys want to follow up. Thank you.  Thank you.  You did great.  Thank you. I hope we didn't hurt you.
DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_0_167.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_168_1439.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_1440_2075.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_2076_2987.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_2988_3563.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_3564_3911.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_3912_4139.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_4140_4895.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_4896_5507.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_5508_6191.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_6192_6719.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_6720_7307.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_7308_8087.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_8088_8603.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_8604_8999.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_9000_10355.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_10356_11099.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_11100_11459.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_11460_11903.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_11904_12551.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_12552_12815.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_12816_13331.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_13332_14291.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_14292_14339.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_14340_14507.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_14508_15515.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_15516_15863.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_15864_16187.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_16188_16979.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_16980_17363.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_17364_18287.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_18288_19343.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_19344_20519.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_20520_20795.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_20796_21155.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_21156_22751.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_22752_23591.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_23592_24251.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_24252_25295.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_25296_26687.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_26688_28511.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_28512_31487.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_31488_32819.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_32820_42611.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_42612_42983.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_42984_45035.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_45036_49259.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_49260_49751.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_49752_50183.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_50184_50819.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_50820_52979.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_52980_53435.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_53436_53843.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_53844_54875.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_54876_55931.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_55932_56651.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_56652_56723.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_56724_56843.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_56844_56999.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_57000_57899.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_57900_57971.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_57972_58163.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_58164_58259.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_58260_58331.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_58332_62075.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_62076_62171.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_62172_62279.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_62280_62963.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_62964_63155.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_63156_63203.png DEF_CON_21_-_Panel_-_Google_TV_9gEooKg77Yw_63204_71287.png