 Hello everyone, welcome. I'm Tom Dwenger from the Google TV Hacker. We're going to be talking about hacking the Google TV today. It should be interesting and a lot of fun, so let's get this started. First off, why do we do it? For science as you can see. Moving on, the Google, so basically the Google TV Hacker team is consisted of six hackers. We kind of all met up on RSE and got together and started hacking the Google TV. Our primary goal was to bypass the hardware and the software to allow for unsigned kernels and give us more open to the system. Today we have found multiple methods to accomplish this, so we're pretty happy with that. We're going to be dropping some of those today, so you guys should see some new stuff that you haven't seen yet from us. Our first accomplishment was on the revue, which we got a 500 dollar bounty to gain root on that, and Amir is going to be talking about how we managed to do that. Just kind of basically going over our members today. We've got Agent HH who's out in the audience up here in the front. He's not afraid to wear a pink shirt. We got CJ, the destroyer of the words, Gino Fage, Fonster. He's, I don't know if he's here or not. He's, there we go. Yeah. It's kind of a mystery to us. We got MBM who couldn't be here today. Oh, he's on the cardboard over there. He's known for founding the OpenWRT and tossing 251 children in a well. And then we got T-Dwaying. That's me. I'm a software developer turned superhero. And then we have Amir, which is not very good at creating bios, so we don't know what he really does. And then we also have a special guest, Bliss, also known as Dan Rosenberg. He's a Bond and Reality researcher who takes on sick pleasure and exploiting anything with the CPU and he once punched an android in the face. Moving on. So basically, I'll go over just the basics of what the Google TV is. It's a system platform that bridges between the TV and the Android device. It kind of creates a overlay instead of having to switch your source on your TV. So it's a direct input into your TV that you don't have to switch, which is kind of nice because then you don't have to do that. It comes out of the box with, you know, Chrome, and then it also has an IR transmitter that talks to your TV so you can change channels and other fun stuff that you can do with the remote, but you can do with little keyboards and stuff that they give you. The system re-receives the over-the-air updates from the OEM manufacturer, so they're pretty slow about it as we have found out. They say it's coming soon and soon is six months. The platform contains Chrome, as I stated. It's basically a forked version of what you have on your computer. It works pretty well. It contains Flash, but the plugins and extensions are disabled at the moment. We're currently looking into that, see if we can get it on there, which would be nice. So basically, comparing the Android versus the Google TV, there's many differences. Google TV has a Chrome browser box right out of the box with it, so you can browse the web and it's a nice Chrome browser, as most people probably prefer, like me. The Gen 1 devices all use x86 processors, so that was kind of different. It's the first time I've seen anything with Android that had x86, which causes all sorts of problems with the Android market and games and stuff not being able to run. The initial release didn't have the Android market, which was a big let down, because there was no apps that we could install or do anything when they first came out. Eventually that came out and they're still lagging on apps, but we're hoping more and more come out in the next few months or so. Unlike most devices, the ADB is used over Ethernet instead of a USB, so basically there is only one white listed IP address that you can connect to the box at any given time. So if you have multiple computers like me, you have to use the same one to do any hacking or anything on it, which is kind of a pain, but most people probably only use one PC. Just kind of basically the go over the differences between the x86 and the ARM. Most commonly deployed boxes that we have for the Google TV at the moment are x86. The newest devices are all ARM based and from our understanding everything going forward is going to be ARM based, so we expect to see a lot more apps and stuff that actually functions on these boxes, which would make it more useful. So the devices that we currently have out are the Sony boxes, which is a Blu-ray player and the TVs. We got the LG TVs, the Vizio, which is coming soon, and the Logitech review. But we'll talk more on the ARM devices a little bit later in the talk here. Go over what's out there and let you guys know what's coming up. The big issue with the Google TV that we found is the content providers. So basically what they do is when you log into your open up Chrome and you go out to content provider, they're checking the user agent and the flash version, so they're basically looking in, see what you're on, so they're blocking all that to you, which is kind of the big downside at the moment, but we bypass that on numerous systems and future ones we plan on doing the same. So the content providers basically don't want us to do anything with that. So basically just to briefly go over the Gen 1 boxes, the x86 ones, they have the Intel CE4100 processor in it, which is an atom processor running at 1.2 gigahertz with an SOC on it, so basically they can create a chain of trust of which I'll be talking here shortly about of how they lock down the boxes. The review is running a slightly slower processor, which is the CE4100, and the Sony TV and the Blu-ray player are running the 4150, which is slightly faster. Just kind of to go over the boot loader, we have a signed boot loader, which was created using the Intel CFDK or else known as the Consumer Electronics Firmware Development Kit. The boot loader, as I mentioned before, it's signed with the signature and they use a chain of trust to prevent you from loading anything basically onto the device other than their signed software. Intel supplies a stage one and a stage two for their boot loader and the SDK that they have. Logitech utilizes both of these. The Sony however only uses the stage one and then uses their own prior NBL for stage two. Just to go over the chain of trust here we this kind of breaks it down for you guys on how the train of trust works on the Sony boxes and then Logitech box. So the first step of it is the SOC which decrypts, verifies the signature of stage one of the CFDK, which then once the CFDK boots it moves on to check the signature and decrypts stage two. Once we reach stage two that boots into this kernel and verifies the signature on that as well. So it's not as simple as rewriting that so we can run any new kernels. Once the kernel takes over, at least on the Sony box is what it will do. It checks the SHA1 hash checks and ish files and verifies all of them so we can't just go in and replace them to hack the boot order on that and then it all after it does that it checks the RSA verification on the nish.rc and then the nish.eagle slash shura.rc based on which device you have. Just to briefly go over the kernel security. The kernel requires modules to be properly signed so we can't just create a new module and insert into the kernel so that's something that we've found a way to overcome and we'll be talking about that as well. All partitions except for data and cache are read only so that prevents us from changing anything in the system which would be useful if we could. The ADB shell only allows you to read write to folders with the shell permission which is your basic read write of pretty much nothing on the box. There's also an access dev slash mem which is restricted to the normal shell user so you can't just go into memory and mess with stuff either. And we also tried using all the current known Android phone and realties on the Sony and the Logitech review with no avail. They're pretty good about patching everything and they're pretty quick once we release anything so hopefully we release something here today that people can get on it before it gets patched in the next week or so as we've seen. So basically I'm going to pass this off to Amir who's going to talk about the current devices that we've got. All right. Hi everyone. My name is Amir. So we're going to get started with the Logitech review. It was released in October 2010 and has a full size keyboard with a built in touch pad. It was originally priced at about $249, was later reduced to $199 and was later discontinued and priced at around $99 to, I mean I've seen it around $82. The big thing is that even though it's cheap and it's discontinued it's probably one of our favorite devices. The full size keyboard is really nice and it has all the same functionality as all the rest of the boxes. So if you are looking to get in the Google TV and you're looking for a cheap device to get you started it's really nice. This is the Logitech review motherboard. We did our best to take a multimeter and label the pin outs the best we could. There were still a few that we didn't get like the unused switch and J24 which is an unknown header on the board but it also has a UIRT pin out. It doesn't have pins already soldered into it but it's fairly easy to get to. It's not vias or whatnot. There's also an Intel XDP debug header which requires some proprietary software to interface with and there's a unpopulated SATA header which we haven't had very much luck with. The review recovery is a standard Android 2e recovery. It gives you basically four things you can do. Reboot, apply update from USB, wipe data of factory reset and wipe cache partition. All update files provided are RSA verified before the box even attempts an installation. Our first hack was UIRT on the review. We managed to get this done about two months after the box was released and essentially it was just that you take a, well first of all the box does a mandatory update when you first plug it in. It makes you update to the latest version and it basically kills this hack. The reason we found it was we actually got lucky and plugged the box in before even trying an update and noticed that in recovery you get a console shell. So really easy to mistake, they pushed it out, they didn't think anyone was going to plug it in, plug UIRT, header into it and give it a shot but they didn't know that we were going to buy five boxes at 250 bucks. We're not the brightest. So it required a virgin review. It still works on newly purchased reviews since it was pushed out from the manufacturer with this problem and as mentioned earlier it requires soldering to four pads on the board which are really easy to do other than ground and it allowed us to read write the file system which was great because the kernel has some built in functionality that disables us to be able to write to which we can talk about later. So this is essentially my recursive keyboard setup. As you can see I have way too many keyboards plugged in and that's in my kitchen. My wife is very, very patient. That was up there for like two months and she tolerated it and didn't kick me out. So it's nice. What we did was we created a manual update process that didn't check any of the signatures. Since we had that old UIRT hack or the hack that we found the downside was that it only worked on the unupdated version. So what we had to do is we wanted people to have the most recent version with the same vulnerability. So we created the manual update process but didn't do any checks on signatures or anything along those lines but still mirrored the exact same update process. We continued to release the modified updates until they started encrypting them and then we had to jump through some hurdles plus at one point they jumped to 3.2 and we decided to start looking for other vulnerabilities. This was also our first content provider bypass because that's what people really wanted with this. They were tired of the Hulu and content provider battle with Google and we really wanted a way to stream, you know, TV shows and stuff to get us away from work. So the content provider bypass was extremely simple. What it was was essentially we take the flash version and we manipulated by changing one byte. Literally we could change an aid to an F or whatever and they will just allow it because they strictly have a blacklist type setup. As you can see in the picture we have GTV switch to ATV and just doing that and changing the user agent in Chrome which you can do just by going to settings and typing in anything you want will get you the content provider bypass. So with that we released that and we got a surprise message from Logitech. They essentially removed the recovery menu that I mentioned, the Android 2e recovery menu and they put our names as the menu items and a ROT 13 ciphered message. They removed all the functionality to install manual updates and so they crippled the ability for users to recover their boxes unless they received an OTA update which it was a really bad move because I mean even on the forums, the Logitech forums, which we troll all the time, I assume they troll ours, they were multiple users who probably could have fixed their box if they still had access to this manual USB update mode. Each of the current GTV hackers members' names at the time which it's changed since then but at the time were listed in there which was a little eerie. You know they're watching you but you don't want your name listed in the firmware. So yeah if anyone's here thanks but you know we never got our message back whatever. And this is essentially what it looks like. We had to do some jerry rigging to get this to show up like it did but the message reads A at GTV hackers congratulations if you're reading this please post a note on your forum to let me know. Winky smiley face. So I don't I mean is this a good enough message? We posted it on the forums if anyone here is from Logitech or Google or something please respond back it's been a year and a half. So then we got started and we started working on hardware hacks just different other things that we could do. We got to the flash sabotage. It's just a name we coined. I don't know if there's an actual real name for this but what happened was since they removed the update functionality for manual updates we still wanted a way so that we could update the box if we could get just any update zip file. So we found out that when a an update is done an intent file is placed in slash cache slash recovery slash command when the box is booting it checks this intent file and it will know where the update is and what to do but if only we had a way to write cache that's where the flash sabotage comes in. Essentially cache and chrome are ext partitions stored on NAND flash and it's actually connected the NAND flash is connected to a USB controller which essentially just makes it show up as a flash drive on the device. By simply cutting that line out and adding a USB header to it we could input our own flash drive and take over cache and chrome. So then we had our way to send updates. It allowed us to fix soft bricks and it most of the time if a brick happened it was and we were able to fix it with this it was because they corrupted the boot image. It also allowed us like I said to push OTA updates but it didn't help us fix anything where we really screwed up. So we had to go another route and CJ was brave enough to solder a NAND programmer to his board. As you can see it's a you have to be really brave and have a lot of tape. We have some alternate points if anyone wants to give it a shot that we can pass out but this was an early picture. It allowed us to essentially test all the stuff we wanted to you know to verify the boot loader was actually signed you flash modified one to see if we could get it to boot and just give anything a shot that we really wanted to without a risk of having to go buy another expensive crappy device. But yeah so we had to add that picture. So we wanted a software route on honeycomb builds. No unpatched publicly known vulnerabilities worked as Tom had mentioned and there were no trivial symbolic links oh shit. Okay my bad this goes to bliss sorry. Hey I'm Dan he was trying to steal my thunder. So yeah as he was saying we wanted a way of providing a software route for the honeycomb. These guys reached out to me they had previously done the UART hack and gotten root that way but that got fixed and pretty much users were left without a way of having root access on their own devices. So they reached out to me because I like beating up Android and I took a look you know as we said before they're pretty good about patching. They have this device had no unpatched publicly known vulnerabilities on it when I looked at it. And additionally they didn't have any of the sort of trivial vulnerabilities that tend to plague a lot of the OEMs that have to do with you know simple bugs with world writable directories and playing games with symbolic links to write files you shouldn't. You know none of that was there on inspection. But I looked a little bit deeper and found that there are some very suspicious looking world accessible character devices in slash dev. So just a little background traditionally Linux supports a file called slash dev slash mem that originally allowed users to map physical memory into a processes user address space. Since people realize that this was you know fairly dangerous you know you could make root kits this way things like that. There's a configuration option called config strict dev mem that prevents even route from mapping most of RAM using this mechanism. So it's reserved for some you know I think it's some IO related thing now. It's the X server exactly. So you know this wasn't a viable vector for us but I noticed that on the review there was a similar device that Intel was so kind to include called slash dev slash dev mem and I was like what the hell is this? So this device is world accessible so we can interact with it and on inspection it behaves the same as the original dev mem but it doesn't allow mapping addresses lower than the last page frame of physical RAM. So what does that mean? So we are not allowed to map kernel memory as an unprivileged user using this device file. But on X86 Linux supports memory mapped IO so accessing addresses higher than physical RAM actually results in interacting with hardware registers corresponding to device peripherals. So this means that this device is giving us the ability to poke and prod the hardware of the device directly which is a brilliant idea. So this seems like something that we can use to somehow escalate our privileges. So there were several options available you know we have access to the PCI buses we have access to the interrupt controllers maybe we can reprogram them to do something crazy we had access to the E1000 ethernet controller which you know maybe we could do things with DMA with that but after weighing all these options I ended up choosing the Intel CE NAND flash controller as the device that I would leverage to gain root privileges. The first reason being it supports DMA direct memory access which is a mechanism by which hardware can write directly to physical RAM without intervention from the operating system. And secondly because it had an open source driver which really helps in that I didn't have to do any sort of hardware reverse engineering or any risky guess work where I basically just tried plugging things into random hardware registers and hope I didn't turn the device into a brick. So what can we do with this device now that we can play with it? So by using this dev dev mem file to map and write to flash controller hardware registers we can actually cause this controller to DMA directly on top of kernel memory in a page length increment so 4096 bytes. So fortunately for us the address of kernel memory that we can clobber doesn't have to be aligned to a page boundary which could have been a restraint but this device actually supports non-aligned DMA. Unfortunately the data that we're scribbling over using DMA isn't really controllable by us because it's just sort of raw NAND data that's living below the file system layer you know you don't even really have a hope of getting file fragments or anything like that because of ware leveling and all that. So it's basically just garbage that we can clobber a page of kernel memory with. So the question becomes what do we clobber? Like how do we leverage this capability? So we need a target in kernel memory where it's okay to wipe out an entire full page with random garbage so that you know what I would normally go after would be some sort of function pointer or an entry of the system call table where we can somehow trigger invocation of that and it would point into you know our payload and then we could run things with kernel privileges. But the problem was all the targets that I'm aware of we couldn't do it this way because clobbering an entire page of memory from that point on tended to break the kernel and the device immediately crashed. Then I try to be clever and go after something specific to Android which is the Android properties page. So Android has this shared page of memory that represents sort of global system settings and if you overwrite certain properties the Android debugging daemon will actually run as root and give you a root shell. And I actually got this working and then I found out that on this particular device they modified the ADB daemon to never run as root which really sucked. So I was a bit stuck for a little bit and then I remembered that I actually had already solved this problem in a different context. So the technique that I'm using here I actually talked about with John Oberhide like a year and a half ago and it's a technique that we called like stack jacking which we thought was a really funny name. So in this case a processes kernel stack is a great target on Linux by default these kernel stacks are eight kilobytes big so there's plenty of room and most of it is generally unused. So you can wipe out a full page of memory there and it's not going to break anything. And the next thing is at the base of a processes kernel stack on Linux there's a structure called thread info and this has stuff that's particularly useful for us to overwrite using this DMA. And in particular there's one variable called the adder limit that I chose to go after. So the adder limit is basically it represents the boundary between user and kernel memory. So on Linux by default the first three gigabytes of an address space are user memory and the top one gigabyte is kernel memory. On the review it's actually two gigabytes and two gigabytes and I haven't figured out why they did that. And whenever the kernel is copying data from a supposed user land address to a kernel address it checks is this user land address actually below this limit otherwise you know you could read from a file descriptor right into a kernel buffer. So if we can overwrite this particular variable which is at the base of the kernel stack with a high value then that will allow our process to read and write to arbitrary kernel memory because all of these sort of access checks will pass. The way we actually find out where the processes kernel stack is is a little bit complicated. The gist of it is I leverage another vulnerability to leak some uninitialized bytes from the processes kernel stack and then do some fancy statistical hand waving and you know resolve the address. You can just believe me that it works and the code will be public and this is all implemented in a library that I published like a year ago called with KStack. So here's that thread info structure which lives at the base of the kernel stack that we're going to clobber using DMA. You'll notice that I don't know if you can know there's no mouse. Yeah you can see that at our limit variable and it clobbers we're going to clobber everything from that point on. So we're also going to overwrite the restart block function pointer which is it actually gets invoked when system calls have to be restarted for certain reasons and you can manually invoke it as well and then we're also going to clobber this sysenterreturn function pointer which is a real pain in the ass because this is actually a pointer to a userland address where the kernel will return execution to the process when it is returning from a system call that was invoked using the sysenter mechanism. The other syscall mechanism being interrupt 0x80. So by clobbering this we can no longer use like glibc library functions because they all use sysenter by default and when those functions return it'll go to this random address that we've written there instead of where it's supposed to go. So we had to fix that up too. So here's what the whole exploit looks like just summarizing all that into one page. So we use this dev dev mem file to map the NAND flash controllers hardware registers into our address space. We leverage this kernel info leak and do some magic to resolve the address of the current processes kernel stack and now we know that there's that thread info structure at the base of it. We write to specific hardware registers that we sort of learned about by reading the Intel NAND driver to trigger this DMA on top of that offset corresponding to that adder limit variable from the base of the kernel stack and then we pray that the random garbage that we wrote there happens to make this adder limit variable high enough so that we can read and write to arbitrary kernel memory. And using that new capability we fix up that sysenter return thing. We manually invoke all of our system calls using int 80 from then on. Fix the sysenter return function pointer overwrite the restart block function pointer to point to our payload that will escalate privileges and then trigger it. Our payload gets executed we escalate our privileges and we win. Some caveats about this exploit it really sucks. The gist of it is poking and prodding hardware registers like this is never a good idea and in this particular case it conflicts with what the driver's usage of this hardware. So when you trigger the DMA the hardware sends off an IRQ saying oh I'm done doing DMA and the driver receives it and goes why did you just tell me that I didn't ask you to do that. So and then on Linux the default response to a spurious IRQ is actually to ignore that from then on. So at that point your NAND flash controller can no longer perform DMA and your primary storage goes down and the box is totally useless until you reboot. So you know I have to, that was a weird phone sound, so you have to I toggle an IRQ bit on the actual in the appropriate hardware register to prevent it from firing that off when the DMA is complete but it's essentially a race condition and you know that really lowers the reliability of the exploit. And the other problem is when we're doing our DMA we basically just have to pray that the random data that overwrites this variable is something favorable to us. So this only works like I don't know 20% of the time if that but it's good enough for homebrew and it'll get people's devices rooted. So lastly as these guys mentioned the review, review, review, review, the review has code signing on all of its kernel modules so you can't load arbitrary kernel code into memory. So the way they implement this is they actually add a new elf section to all the kernel modules called dot signature and then when you, when you load a module it validates that signature against public keys that are stored in the kernel. But now that we have root it's actually really easy to shut this off because it turns out that that same dev mem device if you're root allows you to map RAM just like an unrestricted original slash dev slash mem device would. So we just map the RSA verify function which I actually just guessed you know it seemed like it was probably important and and replaced the first bytes of that function with an x or eax eax return which is just a return zero. So now the verification function will always return success and you can load arbitrary kernel modules. So next CJ is going to talk about Sony. So hello everyone I'm, there we go. I'm CJ Hayes going to talk to you about the Sony Google TV devices. My first question anyone from Google or Sony around here? Audience if so I'm sorry about getting busy next week. So the generation one Sony Google TV devices include a Blu-ray player which is the GT1 on the left and the televisions including a 24, 32, 40 and 46 inch GT1 on the right. I'm sorry that should be a GX1. The hardware is identical apart from the obvious differences of the fact that one's a TV, one's a Blu-ray player. You can tell by the GT1's motherboard that it is considerably bulkier than that of the largest check review but it is built like a Sony. I mean it's very heavy and it's populated with debug ports which is very great. At least three Uarts on board and it contains a CE 4150 processor at 1.7 GHz. Now our very first attempt was SATA sabotage. We noticed that the box had an internal SSD. It's connected over an SATA bus. Use the TDK GB driver RS2. However that featured AES encryption on the flash. So we couldn't just pull the flash, dump it, modify it, stick it back. Instead we just tapped into the SATA bus. Our very first attempt was to tap into the bus, hook it into a computer but we got no way since there was an ATA lock on well the SSD. And since the cable and the cable was kind of I guess cheaply soldered in by myself, it wasn't very sturdy. So instead of doing that, soldered a new cable and hooked it up to an external hard drive which allowed us to access the entire file system, read to it, write to it and also downgrade. Since the cash politician stored a flag on the box that kept track of what version the software should be at. So we use that to look for flaws. We initially downgraded to the very first version and started looking there. So the recovery system of the Google TV is far more interesting than that of the Logitech review. But like the review it also has the update from USB features and it also has a few more other interesting features such as service mode that lets you set certain IDs for ACS and what not. However the entire series of the recovery script is done through pretty much a large script. Runs a shell script, probably not the safest thing to do, we'll get to that in a moment. And it outputs logging to the UART which we will use in a moment. And it's worth mentioning that Sony updates RRC4 encrypted well it's an RRC4 and it's all. And they are also RSA signed. Of course. So we saw this in the logs, the first line, can anybody see the obvious problem? If nobody gets it, which I'm sure some people do, but they're being quiet, the very first thing returns a wild card that's directly passed to another shell script. It's a big flaw, it was never validated. So using that we could craft, yes, a package name. If as long as we had, we put some semi-colons in, it matched the wild card, passed it to the SH and we're able to get local command execution. Which is pretty awesome since they never checked it. We initially started with a script called t.sh which would pretty much spawn a shell over UART and also telnet and from there we were able to dump out the entire recovery file system and really examine it for more flaws. However this exploit was patched in the 7 2011 update. We were checking around with it, patched. We still had the hardware exploit talked about but to quote the tech blog and gadget they stated about our review exploit. It's not exactly what we call an easy jailbreak. It's how it requires a soldering iron, an end-fault procedure and a logic check review that's never been powered on. But it looks like it's possible to route a Google TV after wrong. That was four rather large pads. The Sony would have, you'd have to remove four surface mount capacitors and solder them in. I'm sure some of you could do it, most people couldn't. So that was not a viable option to release to the public. Getting back to the UART, there was an active UART line, output only for logging. And after our initial hack with the replacement of the SSD, we were able to achieve a root console in Linux. And using that root console we dumped out the system memory which showed the existence of NBL which was Sony's second stage boot loader that Tom talked about earlier. And looking forward a bit we saw that there was the existence of a shell and after some memory reversing we found out that if we hit the escape key repeatedly when the box boots up, actually MBM did but he's not here, it would bring us to a password prompt. And after more reversing on his part the magic password to bring up a shell was console underscore on. So the console comes on. NBL had options including loading files into memory and executing from internal flash or network via TFTP. That'd be great but we couldn't just stick an unsigned kernel and have it boot. The kernels were of course signed. And the insecure booting features were disabled on production units. And since NBL used signature and hash checks similar to the normal startup mode we couldn't do anything. But do happen to run that recovery version I spoke about that was patched in 7 2011 we could reload it. So this picture shows the initial boot up, shows us entering a password and then we boot over the network to a TFTP server the exploitable recovery version and initial RAM disk. It takes a few minutes but then it will drop us to a root shell which is perfect for what we needed. And it gets even better since the system when you boot via TFTP the system doesn't unlock the ATA the SSD on board. The kernel panics in drops to a shell. We don't even have to do anything past that which is awesome. So the end the exploitable recovery the system boot binaries are stored not on the SSD but on a separate flash located at devglob underscore spectra A2. And since I mentioned the ATA was locked but the flash wasn't we could write to it. So we replaced the new recovery version that was signed with our old exploitable but signed recovery version. Since now we had an exploitable recovery there was no need for you out and thought was we could either wait till the rumored 3.2 release to release the exploit last September 2011. Google and Sony took until December unfortunately. So come to 3.2 release in December we don't really want to give up a boot loader password being found. It was great fixing boxes and it was a pretty cool exploit. So we spent about 2 weeks looking for bugs. We found plenty of bugs including leveraging sim links and zips and unzips and creating files and removing files but we could never get one to execute but we rarely got to know the update process. So the next one shows the update process pretty much recovery mounts USB to temp mount disk B1. It looks for the package list wildcard then it passes it to package update.sh which then copies the file to cache and then the package update unzips the build dot prop and displays it to the user before verification mind you. If the update is accepted it's copied again to cache then it's verified but when they copied it to cache they never checked if there was already an existing file in cache. So this is essentially what we did. Since the Sony recovery mounted EXT2 and EXT3 partitions with no mount parameters we could use a block device on our USB drive to write to a device note as root. So we started with three flash drives USB1, USB2, USB3. USB1 just had a build dot prop it didn't have to be signed it just prompted the user one to switch. USB2 contained the block device that we would write to the box and USB3 contained a full image of the flash stored on the system. So we'd first do we'd insert USB1 it prompted us if we wanted to update this was before the verification but after the initial copy I'm sorry to take that back it was before the verification and before the initial copy. So we'd swap it out with USB2 which held our block device that we labeled package underscore list underscore gtv hackadodzip we'd hit okay it would copy package list gtv hackadodzip as a block device to the cache partition then it would error out since it wasn't validated but that's perfect that's what we wanted it then instead of rebooting or deleting the files it would drop us back to the main menu. From the main menu we repeat the process insert USB1 which would get us past that first prompt and then we'd swap it out with USB3 which contained our image of the flash file system. When we hit okay it copied our new modified image with an exploitable recovery of the flash file system right over to the block device and doing that we were able to rewrite the internal flash only using software which was great. So now assuming all that went correctly which every now and then if somebody copied a file wrong it could go go pull up but then you could use the boot loader to fix it. Assuming that went correctly we used the local yeah the local executable not executable local code execution recovery exploit and our exploit we had a large script that one ran would repartition the internal SSD because we needed a little more room it would copy boot to our new a new partition it edit the initial boot to include kexec files and hijack the initial boot process to call kexec. Now if anybody doesn't know according to Wikipedia kexec is a mechanism of a Linux kernel that allows live booting of a new kernel over the currently running kernel. Now kexec can be built into the kernel but most people don't especially not if you don't want people running unsigned kernels. It wasn't so we built it as a kernel module took a little bit but we got it in there. kexec allowed us to boot the system have it kick over in less than one second and load our new unsigned kernel. But as Tom mentioned the Sony box after checking checking the boot loader checking the signing of the kernel the kernel's the kernel arguments also had a hash an SHA1 hash on the init and the init RSA verified the init scripts. So we've had to find a place to jam something in there the chain of trust needed to be broken. And we could break it a little further on the process but the issue was the platform security firmware would kick in and panic the kernel so we couldn't do that. So we looked for an attack vector and we found e2fsck now if anybody doesn't know it does a file system check it's one of the first things ran before anything is mounted. So we were able to attack that and that was stored in in e2fsck which is mounted from devsdea1 on the SSD that we could now write to in our exploitable recovery. So we replaced e2fsck with a script that mounted system inserted our kexec modules and kexec loaded a new kernel. A new kernel apart from having no hashes, no signatures had a few other tweaks including not signing the init.rc the init.eagle or serr.rc it also modified the init.rc to read write everything set our secure to zero our debugable to one and we had Xenofet sorry, a may have made a script that would mutate the flash plugin totally randomly. So no two boxes would have the same flash plugin and it would also wouldn't randomly mutate it to GTV which would defeat the point made sure to check for that. So you could watch Hulu or whatever else was blocked on the Sony Google TV. So now I'm gonna pass it back off to a man to talk a little off topic about the boxy. All right, so this is a little off topic portion but what happened was that we were looking to port the boxy to the Google TV devices. Now boxy runs a C4100 just like the Google TV so we thought it'd be fairly easy and we actually did get it working Downside was we were lacking certificates and whatnot to get Netflix working to get the box to where everyone would want it. We also discovered that we hate the boxy because it is counterintuitive to everything you'd want it to do. If you have a boxy we have a route for it we're about to drop so enjoy. Yeah, and the boxy hacking community wasn't very friendly to us as it's mentioned at the bottom. So this is about Google TV so we're gonna make this pretty quick. Essentially, there's a software local command execution exploit that's as simple as dropping a semicolon into a certain field in the settings menu and throwing whatever command you want afterwards and owning the box. It's perfect. I don't know how it was missed. I don't know why there's still people looking for this route that we'd been talking with them about for like two or three months but it was incredibly easy to find. I literally just went through and put semicolon reboot in every field. There's also a hardware exploit which is a little more difficult which involves, there's two vias on the board that are kind of hidden and you just scrape away at them a little bit but if you solder a UIRT adapter to it it'll just drop you into a route shell which they also didn't fix. So between those two you can route a boxy very simply in two different methods. Essentially at the bottom we have this example which is semicolon sh mount label custom.sh so you can run so you can run more than one script. Let's get to, okay, do it real quick. We're gonna make this just real quick because we're running low on time. Essentially we go to menu showing that it's up to date. Go to network, SMB client which is our service which is the settings menu. And I, in this example I entered in a semicolon reboot in the share password which is a required field. I just felt like throwing it in there but the actual effective field is share work group which there's a semicolon reboot, semicolon and exit off and reboot. Just that easy. So, so that's that. Now we're gonna let Tom do future devices. So I'm gonna go through the future devices here fairly quickly for you guys if you need more information. There's Google. So basically the last few months Sony has released a new box. Unreleased is their Blu-ray player that's coming out we think in what October or something. We're not quite sure yet. They got the Vizio that's on pre-order. You guys can go get it if you want. It's only 99 bucks. We highly recommend that. It's pretty cheap. There's LG TV that we don't have too expensive for us. This slide just kind of goes over the basically the specs on all the new devices. This just tells you more about the Vizio specs and what's kind of out there. There's supposed to be a Blu-ray player by them coming out in the future. There's just kind of a brief overview of the LG TVs. We don't have, like I said, we don't have these. We don't have $1,200 lying around just to mess with the TV to break it. So, Amir is going to talk about the timeline now. Actually, I'm going to skip the timeline because we're running low on time. So, yeah, look at it. Everyone good? Cool. Good. Next one. So now we're going to talk about the Sony NSZ GS7 which is the newest line of Google TV devices in the first release device. It was released this month. We have the teardown posted at GTV Hacker and there's a CN2000 adapter on it which is the same that's in the NSZ GT1. You can buy it at MicroArch C-Cars websites. We'll have a link posted on our website for where you can get it. It costs about $2 and it can help you have a solder-free solution to root the NSZ GT1, but unfortunately not this device yet. Yeah, timeline, we rooted it the next day. We were pretty proud of that because we got it from a few guys at Google I.O. They went, they got the box. One guy met up with CJ here in Boston and sold it to him for 200 bucks, which was awesome. And another guy from Rootswiki donated a box to myself. Unsigned Colonel's still in work in progress and we're here so we didn't have a whole lot of time to try to finish that. Hopefully soon we'll have it. We're not going to release this one yet until we have it because we want the best for the community. Let's go to the demo. Essentially we've, to not give away exactly what we did, this is just showing the fact that it is rooted and we have ADB set up right there. We dropped a sue binary on the system, gave it the correct permission so that we could just sue up and install SuperUser.APK. And so you can see CJ showing the build number, has his laptop open, he's going, logs in through ADB, types ID so you can just see that we're still shell. Check sue, you can see that SuperUser APK just prompted the device to say that we had root and we're all done. So we need on that one. And yes, we have questions in track two. If anyone wants to drop by, we love questions. We also have our wiki, our forums, our blogs. We're on free note, IRC channel, GTV Hacker. Stop by, we're friendly, we don't bite. And yeah, thank you guys, we love you. Woo!