 Greetings, everyone. Welcome to Google TV or how I learned to stop wearing an exploit secure boot. My name is Mike Baker. I'm a firmware developer. I did open WRT. We also have Hans Nielsen, who is a senior security consultant at Modesano. We have CJ Heers, an IT systems administrator, I believe he's 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 IQvent Labs and also the founder of the GTV Hacker Group. So 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 an integrated Google TV. It has a custom version of Chrome and 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 bootloader, 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 UART. We also have an exploit by Dan Rossenberg that uses DevMam, 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. And 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 two. And I guess they were going to increase the market share. But essentially you have the Korean LG U plus the S-Sus cube, the LG 47 G2 and G3, the Netgear Prime, the Sony NS GS7, GS8, the High Sense Pulse and the Vizio 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 chip set. It's an ARM dual 1.2 gigahertz processor dubbed the Armada 1500. It features an on-dicrypto processor with separate memories. And it does secure boot from ROM via RSA verification and AES decryption. This particular slide, there's not a whole lot that you really 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 chip set 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 impactor wrote his amazing tool, or Sark wrote 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 gigahertz. Gen 2 is a Marvel Armada 1500 dual core ARM 1.2 gigahertz. 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 flash 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 Visio costar features a smaller form factor, no voice search, a custom launcher, a $99 MSRP, and updates are actually done through update logic as opposed to the standard Android checking system. It's common in all Visio devices. So the high sense 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, you know, 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 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 . slash temp, 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 tgc file and shell script. So then the ASUS cube, 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 hadn't 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 ASUS cube because our whole fear was that releasing an exploit into the market, you know, if someone else takes a look at it, they could, you know, put it in their own app and, you know, 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 writable UNIX 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 ode 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 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 splits 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 EXT-3 drive that was mounted without no dev. So this is pretty similar to that. It's NTFS but 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 device to be mounted no dev when you plug it in so you can easily just run mount and see if it's no dev. And so it affects more than just Android. It affects certain kernel configurations. So with this particular setup, bold mounts NTFS partitions without no dev. And it's 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 overwrites them just beautifully. So we dump the boot image, we patch in it dot RC or default dot prop to RO dot secure. We write it back as a user, no root needed. We reboot and we're rooted. Sony 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 up market because it's a Google TV, you know, it's cool. So this thing's over $1,000 and you know, 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. It's 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 just 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, you know, 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 libc 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 NSC 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 weren't 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 soldered 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 the 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 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 then 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. You know, that's really slow. That's hard to do. So this device is actually reasonably powerful. So what's in it? Well, we pull 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 88DE 3100 is what we've been seeing in most of the Gen 2 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's 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 a 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. You know, 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 that 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 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 fat file system, not a fat file system, an NBR header and then data. So now that we've discovered, okay, well, we can actually try and get it to load images from here. It's like, how do we figure out what image format it's loading? And it's the, 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 the all of the weird steps to get there, like get the hole down the button and 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. Have to. Let's give them all a big round of applause for their first time. One for everyone in the audience. Now we'll see if they can keep going with the presentation and pick up where they left off. So that's actually pretty much it for the Chromecast stuff. So very, 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 root 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 88DE 3010, the older version of the Amato 1500 or the 88DE 3100. Now very similar chips, just the 88DE 3100 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 it and the floor is in that. So list of devices it should work on. Left hand side, the Sony NSC GS7, the NetGain Neo TV Prime, Visio Costa, Hisense Pulse, Asus Cube, the Sony NSC 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 Xero desktop Mee PC, which is coming out in about two or three weeks though they could patch it by then. The Hisense 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 bots will power on, it will then execute the ROM code that's built into it, and it will load stage two. Stage two exists either on NAND, 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 files private public, everybody knows how 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 one or a zero depending on how it boots, and it will either fail or continue. Sorry, I'll slow down. I'll take a sip, hold on. So next up, stage two will then execute. So assuming it verifies, it starts up. And then stage two 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 three to zero x zero six eight zero zero zero zero. We'll admit these addresses are somewhat important, but we'll just consider it boot loader address, kernel address, RAM disk address. So that will load in, and assuming it then decrypts and verifies properly, it will then execute stage three. Stage three is the boot loader. It's a highly modified version of Uboot. It's mostly stripped out. It's kind of funny, but it's simple. It also has, you know, support to boot 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 zero x zero one zero zero zero eight zero zero. 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 zero x, I think that's about two million or so. It will call the RAM disk address. Once that's done, it will then execute the kernel. The kernel and 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 script, I'm sorry, 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 stock kernel at zero one zero zero eight zero zero zero zero zero. 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 Marvel secure image. Normal Android header, the Android magic, then has some kernel arguments which it doesn't use, then some encrypted gunk below it. So keep that Android kernel header in mind. Now if you take a look at AOSP's 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 while I take a sip of this. So the mocked up version of the Android kernel and Marvel secure image. 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 you 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 so we figured they were replaced somehow. Which they were. 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 marvel secure image which includes a key index, a signature, an encrypted data size, then an RSA 1024 bit signature followed by AES 128 CBC 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 whatever we want. 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 about line four. Some printfs. Then it does a, we thought this was a load image. It turns out it's a verify image. A verify image on the kernel image itself. And it actually has an if to check the return code. It does, you know, if else. And, 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, 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 its security. They also signed the RAM disk image so we couldn't just replace it. However what we, what we could do is append a small, add a small kernel and append it with a 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, zero one, zero zero zero eight thousand. We could set it to say zero one, zero zero zero nine, eight thousand 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 U-boot. We can, for this exploit, which we are releasing these packages for most Google TVs right now. You can also trigger and run U-boot 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 U-boot that we're 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 researches time and show you guys a quick demo. And I pass that up. Thank you. I don't use Macs. This is my mouse. Thank you. So we're also going to show the, a quick, come on. I look totally computer over here. Seriously. Fix me. Nice. We're going to hide this. So we're doing right now. Nothing on the screen. Really? Can't do this. Hey, this is your not mine. Thanks for that. Yeah, I just, I, this blame isn't totally on me. Blaming you too. That's awesome. There you go. Move to your right. Move to your right. Yay. Let's get a round of 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 Cube. We're going to do 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 permissions and then run flash erase and then write on our modified version to then insert a custom recovery that we created. Keep in mind our custom recovery is rather thin. They, it's not like we can just, you know, 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'll listen to an old Model M keyboard rattle away. So that was the erase and now we're going to do the NAND write. 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. Now we're going to do the actual write of the custom 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 block and character devices. So now we're rebooting into our custom 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 custom 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 Uot. There's also root over AGB and if you want, you can modify to whatever else you want. So command line CJ00GTB hacker just proving that it is our own custom compiled kernel running on the box. Now pressing 1, installing the custom U-boot. As then completed, we are 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 shoot it back to MBM to close up. So links to everything that we've covered in this presentation is at DC21.GTVhacker.com. We thank you all for attending and we're going to hand out some UART adapters. We're looking for questions. People who ask questions will get priority on UART adapters and then after that we'll just 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? Anyone else? Right here. Can you say that again? He asked if we've tried JTAG debugging or if UART is sufficient. UART has been sufficient up until this point. I mean we've looked at some of the JTAG pinouts but we haven't made a whole lot of progress with them. In the Gen 1 we did... We haven't needed JTAG. Yeah, we really honestly haven't needed it at this point. If we got down to it we'd go that route but we just haven't yet. If you want to give him one? Anyone? Next question? Right here. He asked besides Hulu what other content providers have we had issues with? CVS, 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 like one or two more questions. Yeah. 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've 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. And 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 you know it could bite us in the butt. So if you want to 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 you know 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 answered. 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. Yeah. Exactly. But we let's give him a UART and we'll continue this in the Q&A room. Oh my God. 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. You did great. Thank you.