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 OpenWRT. We also
have Hans Nielsen who is a senior security consultant at Modisano. We have CJ Hughes
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 AccuVent 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 will talk to you about the software. The Google
TV is a little bit different. But it's a little bit different. So I'm going to talk about
that 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 little bit of a
quick recap of the stuff we did last year at DEF CON. I'm going to speed through it. So if you
missed 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 dev mem. And SORC wrote an impact
or 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. Sorry, this is a Google TV. Sorry, this is a Google TV. Sorry, this is a Google TV. 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 it includes
all of our names and passwords. And it includes all of our names and passwords. And it 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 we're going to talk a little bit more about
it. 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 increased 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 Asus cube, the LG 47, G2 and G3, the Netgear Prime, the Sony NS GS7, GS8, the Hisense Pulse
and the Vizio CoStar. They have a similar hardware design throughout most of the generation, short
of the LG 47, G2 and G3. So we're going to talk a little bit more about Gen 2 hardware. So Gen 2
features a Marvel 88 DE 3100 based chipset. It's an ARM dual 1.2 gigahertz processor dubbed the
Armada 1500. It features an on die crypto 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 chipset itself. Skip the place holder
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, you know, the key signing bugs were big news. And impact wrote his
amazing tool. Or Sarek wrote his amazing tool. So that's kind of where we're going with this. So
let's talk about the
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 next devices pretty quickly because, you know, it's all public
information. I'm sure you guys don't really care too much. 8 gigabyte EMMC flash inside of the
Sony NSC GS7. It has the best remote. So if you're going to buy a 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. So it's a little bit different. It's a little bit different than the
Vizio. 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 Hisense 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 is ‑‑ has root privileges. So it was patched up. It's a little bit different than the
Vizio. It's 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 fun, you know,
connect your UART adapters that we give you after this, you could technically connect to that pin
out 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. And if they're not in a
debug environment, they'll set RO.secure to zero. So we have a lot of
different options. Then we did the Neo TV Prime root which was essentially an exploit that
leveraged the update system on the Neo, the Netgear Neo TV Prime. Essentially the process
involves checking if Persist dot radio dot test mode is enabled and if it is, it extracts a test
mode dot TGZ from a USB drive and then it just straight executes a shell script from that file.
So to get the control of the compute, I was very surprised to see that in the first place.
So you get local command execution fairly easily with just a thumb drive with a special
TGVC file and shell script.
So then the Asus cube, it's the same generation 2 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
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 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 pwn.
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 Oplay.
We've been using this bug for a while to do our investigations on 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 Penn 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 an improperly mounted EXT3 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 devices 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 or certain Linux configurations.
So with this particular set up, Volt mounts NTFS.
It's a little known feature.
It does support block devices.
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 init.rc or default.prop to ro.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.
HANS NIELSEN.
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 full 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, 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 is it.
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 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.
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 bootloader 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 init force strip.sh.
So that's on system.
So we just replaced that file to spawn a shell, connected a UART, you know, again,
we love soldering wires to things.
And there we go.
Then we have root.
All on a device that we never actually used.
We 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 this 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 IP address.
I'm sorry.
I'm sorry.
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.
You know, 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 then you plug it in.
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.
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 88DE3100 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?
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.
It turns out that it is very, very, very similar to a Google TV.
It even says booting GTV kernel.
It's the URL.
It's actually a USB-based 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 if you plug that into your computer, for 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.
devices into the Chromecast directly. Another very fun feature was that it has the
same bootloader as the DE3100. If you look at the source code drop that Google provided
for this device, it's the same bootloader. 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, you know, we've got a lot of
buttons. 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 bootloader. The bootloader 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's a much lower
level recovery. It runs some code in the bootloader that reads directly from a USB stick. So
that host mode USB port turns out to be useful for this recovery mode. So the bootloader 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 bootloader. 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
MBR header, and then data. So now that we've 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 the ‑‑
it's actually the same standard Marvell image format that we've seen on a lot of other Google TV
devices. So we're going to go ahead and do a little bit more of this. We're going to go ahead and
do that. Okay. 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 to 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. emails name message address knows jebese.date, the name believes in gmail.id, e-mail, e-mail, e-mail, Sc uncertain codes, that sounds 2016. E-mail, the powerful demand.ल
So the original route for this thing was actually pretty straight forward. Once you figured
out all of the weird steps to get there, like you had to hold 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 where 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. 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 shot, not 21 shots. They have to be able to finish.
And one for everyone in the audience.
Cheers. There we go. All right.
.
No, but you know what?
.
That's a wife right there.
.
.
Notice I didn't say the wife. That is a wife.
.
Very important.
.
Cheers.
.
Cheers. First time speakers. Come on.
.
.
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 lightweight.
.
.
.
.
.
.
.
.
.
.
.
And now I don't have to worry about speaking with a shot in me. So C.J.
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 secure boot exploit. Let's actually make it work. And this time they did, I promise you,
they checked the return code. So it's a bit more real of an exploit. So to start off, there was
the Armada 1000, which was the 88DE3010, the older version of the Armada 1500 or the 88DE3100.
Now, very similar chips, just the 88DE3100 was a bit faster. So we believe that this exploit
should also work on pretty much every Android based Armada 1000 because the boot loader was
provided by the NTFS.
So a list of devices it should work on. Left-hand side, the Sony NSC-GS7, the NETGAIN
Neo TV Prime, Vizio CoStar, Hisense Pulse, Asus Cube, the Sony NSC-GS8, the LG U Plus IPTV,
Google's Berlin development device, which is very similar to the Vizio CoStar. Also devices we
believe it should work on but haven't tested because we don't have them. The Xero desktop,
Mi PC, which is coming out in about a month. We believe it should work on, but haven't
tested yet. So we believe it should be 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, which 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,
processor, the box will power on, it will then execute the ROM code that's built into
it and it will load stage 2. Stage 2 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 area is 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 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.
So, next up, stage 2 will then execute. So, assuming it verifies, it starts up. 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 0x06800000. And then stage 3 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 boot secure images. It will send the image directly to the secure boot processor, send it to
the boot loader, and then it will send it back to make sure it's good. So upon execution, it will
then load the kernel to 0x0100800. 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
send 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 if you're
looking for a UART, and we can see they have the start kernel at 01008000. 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 kernel header in mind. Now, if you take a look at the UART, you'll see that the
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's 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 header is going to give you a
look at the kernel and model 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.GTBhacker.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 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 the command lines. It might work. Tried that, but we
wanted to fail safe, so we went with the EMMC flash backup. 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 didn't have. 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 AES128 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. 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 doesn't even have a boot loader code. It's just a
EMMC read about line four. Some printf's. 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. 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 ‑‑
That's horrible.
So for the RAM disk image, it was not a secure one. It was horribly insecure because of that,
we were able to own the box. Now, for the Sony NSC 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 ‑‑ add 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, 0, 1, 0, 0, 0, 8,000, we could set
it to, say, 0, 1, 0, 0, 0, 8,000, which means that we could simply do the same thing.
one, zero, zero, zero, nine, 8,000 or something. And then we could still get a hacked kernel
to load in at just the right address and still execute. Sony has 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. Through 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 directly from USB, TFTP or you could modify the source code wherever you want. The
ASUS cubes GPL release had a version of U-boot 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 this time and show you guys a quick
demo. And I pass that up. Thank you. I don't use Macs. So I'm going to show you guys a quick
demo. This is my mouse. Thank you. So we're also going to show the quick ‑‑ come on. I look
totally computer. Seriously? Fix me. Nice. So what we're doing right now ‑‑
there's nothing on the screen. I'm going to hide this. So what we're doing right now is
I'm going to do this. Hey, this is your computer, not mine. Thanks for that. Yeah, I just ‑‑
this blame isn't totally on me. Blame on you, too. That's awesome. There you go. Move it to
your right. Move it to your right. Yay! Let's get a round of sound for everyone in the audience. Sweet. So you're probably not going to be able to
make this out. It's going to be on YouTube probably when we're off the stage. Just check out our GTV Hacker
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 an 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 root permissions. And then run flash erase
and Nanwrite on our modified version to then insert a custom recovery that we created. Keep in mind our custom recovery is rather thin.
It's not like we can just, you know, put 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 while we listen to an old Model M keyboard rattle away.
So that was the erase, and now we're going to do the Nanwrite. And I have a typo, so it's going to error it 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 block and character devices.
So now we're rebooting into our custom recovery that you'll see popup 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 in.
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 so we have root over U-out.
There's also root over ADB, and if you want, you can modify it to whatever else you want.
So command line CJ000, a GTP hacker, just proving that it is our own custom compiled kernel running
on the box. Now pressing 1, installing the custom U-boot. And it's 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's left. So
if we can get a few more questions, we'll be happy to answer them.
Let's see if we can get some quick questions. Anyone? Right here.
What experience do you have getting apps that are not designed for the Google TV
to run on the regular Android apps?
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'd feel comfortable
releasing. I built a connect block 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 ‑‑ huh?
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 ‑‑ 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.
How many of them do you have success by now?
He asked how many of we had success bypassing their
mitigations. All of them. Essentially we just mimic the
desktop flash set up. 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. Okay. Like guy in the red shirt and then we'll get the
guy in the black shirt that's 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
then I'm going to go to the black shirt polo. 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 someone to give that
gentleman one or throw one at him. Sorry. Yeah, please. Oh,
my God. Oh, my God. Oh, my God. Oh, my God. Oh, my God. 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. But I think
they do because they tend to shy away from ever speaking to us.
So, huh? Publicly, yeah, exactly. But let's give him a UART. 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. So if
you guys want to follow up. 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.