MIKE BAKER: Greetings, everyone.
Welcome to Google TV or How I Learned to Stop Worrying
and Exploit Secure Boot.
My name is Mike Baker.
I am a firmware developer and I did OpenWrt.
(Applause.) MIKE BAKER: We also have Hans Nielsen who
is a senior securities consultant at Matasano and we have CJ Heres,
IT systems administrator and we have Tom Dwanger
in the audience and stand up, Tom.
(Applause.) MIKE BAKER: And we have Amir Elemadieh who
is a researcher at Accuvant LABS and also the founder
of the GTVHacker group.
GTVHacker is a group of about six hackers that hack
in to the Google TV line of products.
Our primary goal is to bypass the hardware and software restrictions
and open up the device.
The GTVHacker 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 HDI in and HDI out and IR.
Some of them include Blu Ray players and Sony TV has integrated Google TV
and has a custom version of Chrome and
a Flash version that I will talk about later.
So why do we hack the platform?
We hack the platform because unlike the Google Nexus
devices it has a heavy restricted kernel and
the previous generation, generation 1 is the end of life and the Flash player,
I will get to that in the next slides.
So before we start I am going to do a very quick recap
of the stuff we did last year at DEF CON.
I am going to speed through it.
So if you missed something look at last year's slides.
The Logitech review left a root URT and we also have an exploit
by Dan Rossenburg who uses dev man and sort of wrote an impactor plug in.
So the Sony similar situation has a no dev bug and we also wrote
a custom recovery for it and used K exec to load
in a new kernel and now we have unsigned kernels.
The Flash player was blocked by various streaming sites.
So, for example, you can't watch Hula.
You get redirected to a site that says sorry, this
is a Google TV and the fix for that is 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 is a root 13, that says GTVHacker, congratulations,
if you are reading this please post.
Let me know.
And includes all of our nicknames.
(Laughter).
MIKE BAKER: Yes.
Whoever is at Logitech that wrote that you are awesome.
This is why we hack devices.
So the Boxee Box is a similar device and using
the same SoC.
In the process of hacking the Google TV we came
up with an exploit for the Boxee Box that led the way
to the Boxee plus community and it is still vulnerable.
So that's awesome.
So next up is Amir.
(Applause.) AMIR ELEMADIEH: Hi everyone.
I am going to continue the presentation.
My section regards Gen 2 hardware and one of the first ODY that we are
going to release for the platform.
So Gen 2 hardware we have a multitude of devices.
They increase the amount of devices they had by like a factor of 2.
And I guess they were going to increase the market share
but essentially you have the Korean LGU plus the S cube
and the LG 47, G2 and G3 and the Netgear Prime and GS8 and
the Hipulse and the Vizio Costar and they have
a similar hardware design short of the LG 47, G2 and G3.
It is an ARM dual 1.2 gigahertz processor hubbed the Armada 1500.
And it does Secure Boot from RAM via RSA verification
and AS decryption.
On this slide there is not a whole lot to pull from this.
This is direct from their marketing stuff for the chip.
Yes, it is just here to show you kind of how they pride the chip set itself.
Skip the place order apparently.
So platform information, the newest version of GTV
is on Android 3.2.
No public vulnerabilities that worked up until about a week ago.
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 a fat G LPSY setup and does not support native libraries.
Gen 1 was X86 single core atom and Gen 2
is 1500 dual core ARM 1.2 gigahertz.
Adds native libraries and bionic LPSY from what we heard in the rumor miles.
I am going to go through these next devices pretty
quickly because it is all public information and I am sure
you don't really care too much.
Gigabit Flash, site of the Sony it is has the best remote.
So if you are going to buy Google TV we recommend
this one.
Hard to recommend Sony.
Larger form factor than some of the other Google TV devices
and has built in IR blasters which sounds
like something it would be throughout the whole platform.
No voice search, a custom launcher and $99 MSRP
and updates are done through update logic as opposed
to the standard Android check in system.
Common in all Vizio devices.
It was launched with AB running as a root.
When you pick one up because it is actually updated you can AB in,
AB root and AB has root privileges.
So it was patched shortly after and it has a $99 MSRP.
With ADB root there was also a URT root set up I guess
for debugging and whatnot.
And they had debugible set as one.
ADB root was all you needed for a software root, but if you wanted
to have some fun connect your UR to adapters that we give you after this.
You can connect to that pin out that's right up there.
We will have a select number of USB adapters.
$129 MSRP and two exploits for it.
One was real and one was technically oversight, at least in our opinion.
The oversight was that they went ahead and put the console
to start up on UR regardless.
Ro.secure was set.
If they are in a debug environment they will set it to 0 and if not
in a debug environment they will set it to ro.secure to 1.
Then we did the NeoTVPrime root which was
essentially an exploit that leveraged the update system
on the Netgear NeoTVPrime.
The process involves checking of persist radio and if it extracts it
a test mode with a USB drive and then it just straight executes
a shell script from that file.
So you run you get local command execution fairly easily
with a thumb drive and shell script.
It is the same generation to hardware.
Horrible mode.
But we really like this box because of this next part.
Q root.
So we have a lot of fun with this.
We hadn't done an Android APK that actually leveraged
one of our exploits up until this point.
It was neat 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 by patches your cube
because our whole fear was releasing an exploit in to the market,
if someone else takes a look at it they could put it in their own app
and root all your Google TVs.
So we set it up so that it can do patches and it can do rooting,
but essentially how it worked it exploited a helper app.
The helper application passed unsanitized input
to the mount command resulting in command execution,
which triggered the vulnerability from Android PK which showed
network permissions and added it to the Google play store for fun.
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 maliciously and not just help people
unlock their devices.
Then we got to the ODY that I told you guys about.
We have been using this bug for awhile to do our investigations
on like new devices and research on new devices
to see how things are set up.
So this is kind of something that's new and dear
to us because it has worked on the entire platform to date.
What it is is we call the magic USB.
We like saying magic because we are
on the Penn & Teller stage I guess.
If you recall our past exploits it required four USBs.
You could narrow down the number to a lot lower but you have to have
a lot of different images for the USB drive and leveraged
and improperly mounted ext3 drive that was mounted without no dev.
So there is pretty similar to that.
It is NTFS root but it is not and it is not done in recovery but it
is just as powerful.
So all Google TVs and some other Android devices are vulnerable.
What this bug is is actually I will 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 and requires the devices
to be mounted no dev when you plug it in so you can run mount and see if it
is no dev.
And so it affects more than Android.
It affects certain kernel configurations.
So with this particular setup volt mounts partition without no dev
and low num feature it does support blocked devices.
Our magic USB 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 and plug it in to your Google TV
and you DD directly to that newly created device that's
on your USB drive and the kernel does its magic.
Even though the partitions are mounted read only it
overwrites them just beautifully.
We write it back as a user and reboot and we are rooted.
So Sony boxes require an additional step.
Now I am going to go ahead and introduce Hans Nielsen.
Oh, yeah.
(Applause.) HANS NIELSEN: Hello.
I am Hans.
So one thing that we really love to do here at GTVHacker
is we love taking things apart and soldering wires to things.
It tickles something deep in our brain that makes us feel
very good.
There is a few platforms out there.
One of them is this TV that's made by LG.
It is 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.
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 alluded us.
It is in a 47 inch LCD TV and it is very upmarket because it
is a Google TV.
This thing is over a thousand dollars and we didn't
want to spend a thousand dollars on it.
What are we going to do?
Well, we like taking things apart and putting them back together.
One eBay we bought a motherboard and a power supply
and it turns out that you can get that for not so much.
We soldered some wires to it.
So this hardware is based around that LG SoC and
the storage it uses is it is using an eMMC Flash chip.
It is similar to an SD card and has a few extra little bits that allow
for secure storage.
But essentially what it allows us to do is that we can just solder,
you know, a 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.
No issues here.
So like most devices will have a NAND chip.
It is much trickier to write those.
Not as many common available pieces of hardware to read that for you.
Everyone has an SD reader.
So to actually root this thing, we spent awhile digging
through the file system seeing what is here and how can we pull stuff apart.
At 0X 100,000 hex we found the partition information that tells us
where each of the partitions 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 ABKs live and all the LPSY lives.
So likely said all of the file systems stuff was signed
pretty much but it turns out that they did not sign the system image.
Once we figured that out it was just a matter
of unpacking the system image, figuring out what
in that system image gets quickly called with the boot loader
and messing with it.
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 vender bin anit force script.sh.
So we just replace that file to spawn a shell.
Connect it to the UR.
Again we love soldering wires to things and there we go.
Then we have root.
All in a device that we never actually bought the full thing of.
So another device that we did this to was the Sony NSZ GS7 and 8.
They 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 was the usual way to do this
at Android you modify the boot properties ro.secure is 0.
Straight up ADD the device and everything will be great,
easy, simple.
But we did that and it didn't work.
So it turns out that the anit scripts were checking
signatures for some stuff.
And it was also making sure that some of these properties weren't set.
So it is like okay, ro.secure must be why.
So we went around looking at how is this signature stuff working.
And they are just not verifying those signatures.
So it was pretty simple to just replace anit 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 was it had a sata port,
but it did actually have the necessary passer components
on the hardware to support.
So we soldered a sata connector to it.
So far it doesn't appear that the kernel actually supports
these things.
But the hard drive is actually spinning
up and we are pretty sure it is working and we
will talk more about that.
So beyond those two devices is another device that came
up very recently.
Very interesting device.
Very similar.
It is an interesting evolution of the GTV family.
Google Chromecast.
Google announced this device last week.
Last Wednesday even.
35 dollars.
This is an 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.
You plug it in to the TV and power it
from the USB cable and boom, you have something
to share with videos.
It is actually a really awesome device and we think it
is very cool.
In many ways we think it solved some of the issues that GTV had
in the past with kind of expensive niche platform.
It is 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 are 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?
We pulled it apart as soon as we could and it turns
out that it has pretty standard stuff that you kind of see
for an embedded device.
It has RAM.
It has Flash.
It has a WiFi chip and has a CPU.
Now this instantly made us go oh, well, this is cool.
Because the Marvell DE 3800 is what we have been seeing in most
of the Gen 2 TVs.
When we saw that we started getting suspicious.
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 URT in it.
So let's go find that.
So we found the URT and started looking
at the kernel output from this device and turns out that it
is very, very, very similar to a Google TV.
It even says booting GTV kernel when you look at the URT output.
And other things that it has.
It has a USB port on it that you use to power it.
But when you if you plug that in to your computer
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 is not actually a USB device.
It runs in USB host mode.
So you are actually using a USB on the go cable, plug other devices
in to the Chromecast directly.
Another very fun feature was it has the boot loader as the DE 3100.
If you look at the source code drop that Google provided for this device it
is the same boot loader.
In fact, almost no references to the 3005.
Very, very similar to previous Google TV platforms.
So, of course, the first thing we do is say okay,
although 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 is really restricted.
All we have is this URT and we have this host port
and HDMI.
And one button.
The first thing that do with a button you press it while it
is rebooting and turns out holding this button
down causes fun things in the boot loader.
The boot loader has a special recovery mode where
instead of doing a normal, you know, Android style recovery where it boots
a Linux kernel and then you have a whole recovery system there
and does signature verification.
Instead what it does it is a much lower level recovery.
It runs code INF boot loader, 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 is not even like it is a file system in this boot loader.
It reads directly from the from 0X 1000 on that USB key.
And then data.
So now that we discovered okay, well, we can actually try and get it
to load images from here, like how do we figure
out what image format it is loading and it is the it is actually
the same standard Marvell image format that we had seen on a lot
of Google TV devices.
We found an image.
Can we boot stuff?
Do we have signed kernels, other signed images we can try running
on here and see if we can get anything to run.
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.
(Laughter).
HANS NIELSEN: So the original root
for this thing was actually pretty straightforward once you figured
out all of the weird steps to get there, like you had to hold
down the button and had to have USB on the go and
a Flash drive and stuff at the right spot.
You get to the point okay, I can load an image on here.
Why is my image verification not failing?
Well, it is because they don't fail it when you verify the image.
So we manage to actually get root on there.
It is awesome.
Google has already patched this.
They released an update for this yesterday.
So I don't know how readable the source code is.
Essentially that green blob on the right side is the patch
from Google that says if Ret return negative 1.
So they patched that.
A little sad.
But we are looking in to Excuse me.
So a little tradition at DEF CON first time speakers get
to do a shot on stage.
These guys are all first time.
Have to.
Give a big round of applause for the first time.
(Applause.) Are they 21?
Yes.
Just one shot, not 21 shots.
We have to be able to finish.
Just keep going.
Cheers.
HANS NIELSEN: And one for everyone in the audience.
(Applause.) Cheers.
Cheers.
Very good.
All right.
You 21?
All right.
No.
Yes.
HANS NIELSEN: Notice I didn't say the wife.
That is a wife.
Cheers.
First time speakers.
Come on, give a round of applause.
(Applause.) Now we will see if they can keep going
with the presentation and pick up where they left off.
HANS NIELSEN: I am not that much of a lightweight.
Indeed.
Thank you.
That's actually pretty much it for the Chromecast stuff.
Very convenient.
And now I don't have to worry about speaking with a shot in me.
So CJ.
(Applause.) CJ HERES: So now my introduction, lovely picture.
We have root through the NTFS trick.
It works great and we can write whatever we want.
But relating to the sata header we want more.
So Secure Boot exploit and I promise you they checked the code.
Armada 1000 the older version of the Armada 1500.
Now very similar chips.
Just the 3100 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 that model.
Left hand side the Sony NSZ GS7, Vizio Costar, Hisense pulse,
the LG plus IPTV and Google's Berlin's development device which is similar
to the Vizio Costar and also devices we believe it should work
on but haven't tested because we don't have them,
error desktop PC, the Hisense XT 780 TV which might be
out at any moment.
Might patch it.
Lenovo S31 which is available in China.
And others, there may be other venders using this
chip that we aren't aware of.
Detailed security overview, starting from the internal secure crypto
subprocessor, the box will power on and then execute
the RAM code that is built in to it and will load stage 2.
Stage 2 exists either on demand, eMMC, or over SPI but when it loads it in it
will first decrypt it with a key that's stored within the CPU.
So if it decrypts and verifies successfully it
will actually have a return code and it will return a 1 or 0 depending
on how it boots and either fail or continue.
(Off microphone).
CJ HERES: Sorry.
I will slow down.
(Laughter).
CJ HERES: I will take a sip.
Hold on.
Another shot.
(Laughter) (Applause.) CJ HERES: Thanks.
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 0X 680000.
We will admit these addresses are somewhat important.
So that will load in.
And assuming it then decrypts and verifies properly it
will then execute stage 3.
Stage 3 is the boot loader.
It is a highly modified version of U Boot and mostly stripped
out and it is kind of funny but 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 is good.
Upon execution it will load the kernel to 0X 01100800.
Assuming then again it decrypts and verifies and
all good and returns a value that it checks it
will then continue to load the RAM disk to 0X I think it
is about 2 million or so.
It will then execute the kernel and the kernel and
the command lines that are set inside the boot loader
will then set a hash to check the anit script to ensure that
the anit binary has not been tampered with.
Then it will then verify the RSA signatures
on the anit scripts which we know don't work but I am sure
they will probably work within a week.
But back to the URT which keep in mind we are giving away URT
adapters after this.
They are kind of pointy.
We can see they have some dot kernel at 0018000.
So again keep that address in mind.
It is important.
This is a picture of the Android kernel
and model secure image.
Android had the Android magic and then some kernel arguments which
it doesn't use and encrypted gunk below it.
So keep that Android kernel header in mind.
Now if you take a look at Asus boot image dot H you have
an instruct for the kernel itself.
Then you have the kernel size.
Kernel address and RAM disk size and RAM disk address and SHA 1 hash
and some of the stuff is not really relevant now.
I am going to pull up a mocked version
of this and give you a minute to review while I take a sip of this.
Whoo.
So the mocked up version of the Android kernel
and Marvell secure version.
Keep in mind these slides will be (lost audio).
Might wait until Monday when we are back home.
But getting to this, Android magic and then kernel size and then kernel
load address.
After the kernel load address we have the RAM disk size and RAM loader
address and then kernel load arguments which surprisingly are
replaced on root.
When we initially started trying to get in to this box we dumped the image
and noticed the Android kernel header
and we figured we could mess around with the command lines
and it might work.
So we went with the eMMC Flash.
We were able to replace the kernel arguments
but it still wasn't changing.
So figured they were replaced and then SSH 1 hash and still boot.
It does not check that.
The actual Marvell secure image which includes a key index and then RSA 1024
bit signature followed by AES.
So not messing around.
But let's take a second look about header.
RAM disk size and RAM disk load address.
In the red is the RAM disk size and in the black is the RAM disk address.
For some idiotic reason they do especially
if we place it 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 and jam it
in there and 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 and does
an eMMC read and then does a we thought this was load image
and turns out it is a verify image.
Verify image on the kernel image itself and has
an if to check the return code.
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 is set
to something and it will then load an arbitrary amount of data
at whatever address we will give.
For the Sony NSZ7.
Sony went above and beyond with the security
and also signed the RAM disk image.
However what we could do is append a at a small kernel
and append it with our RAM disk which was
a custom kernel and stick that in to the RAM disk location
and offset the RAM disk load address.
Instead of 010008000 we could set it to 010098000 to something
and then still get hacked kernel to load right address and still execute.
Sony has made quite a few blunders 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, or you could modify the source code
to whatever you want.
The cubed 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 FTP.
I will skip this feature and show you guys a quick demo.
I don't use Max.
Where is my mouse?
Thank you.
So we are also going to show a quick come on.
I look totally computer illiterate.
Seriously.
Fix me.
(Laughter).
CJ HERES: Nice.
There you go.
So what we are doing right now Nothing on the screen.
CJ HERES: Really?
Do this.
This is your computer and not mine.
Thanks for that.
CJ HERES: This blame is totally not on me.
I am blaming you, too.
That's awesome.
CJ HERES: There you go.
Move to your right.
Yay.
(Applause.) CJ HERES: Sweet.
So you are probably not going to be able to make this out and going
to be on Youtube when we are off the stage.
What we are doing right now is we are pulling up Asus cubed
and do an NTFS point.
Then we stuck it inside the Asus cube and what we are
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 then write on our modified version.
Keep in mind our custom recovery is rather thin.
It is not like we can just put CWM to it and call it a day
because CWM's buffer uses Android's.
Google TV boxes have a very specific custom version which
is idiotic.
Right now it is showing it being written
and erased and we will give that
a moment and watch blurry text while we listen to a whole model keyboard
to rattle away.
So that was the erase and now we are going
to do the man write and I have a typo.
So it is 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 MTV device and then show my typo.
And honestly I do not know what I mistyped but something happened.
So now we are going to do the actual write
of the custom recovery that we created.
This is the slow of the video watching everything type
and then it picks up.
Write, write, write, write showing that we can write
to anything on the box that we want which should
work on many, many devices and NTFS device can use block
in character devices.
Now we are rebooting in to our custom recovery.
Keep in mind that recovery images, kernel images signed and encrypted
and show you on the left hand side we have put my
handle for the kernel compiler.
We are putting in a USB drive with a copy of U Boot
on it that we are going to then Flash to replace the boot loader.
So there is that custom recovery on the right using unsigned code.
(Applause.) CJ HERES: And now scrolling all the way
to the top we did a busy box I.D.
Also roots over ADB and if you want you can modify
to whatever else you want.
Command line, just proving that it is our own custom compiled kernel
running on the box and pressing 1 and installing the custom U Boot.
As completed we are going to be set.
Reboot the box and you will see on the left hand side we will go
to U Boot prompt letting us boot anything we want.
We can start whatever we need.
So pretty much it for the demo video.
I am going to shoot it back to MBM to close up.
(Applause.) Good luck.
(Applause.) MIKE BAKER: So links to everything that we have covered
in this presentation is at DC21.gtvhacker.com.
We thank you all for attending and we are going to hand
out some URT adapters.
We are looking for questions that people who ask
questions will get priority and URT adapters and after that we
will hand out what's left.
Quick questions.
Anyone?
Right here.
(Off microphone).
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 is not in a good state that I feel
comfortable releasing.
I built a connect APK with just some
like it does very minimal like it uses very minimal native code
but it works.
I tested the native code and it works fine.
If anyone in the community wants to step forward and help
out with that we would appreciate it.
If you want to come and grab your adapter.
Anyone else?
Right here.
It is very pointy.
Can you say that again?
(Off microphone).
He asked if we tried JTAG debugging or
if URT is sufficient.
URT has been sufficient up until this point.
We haven't made a whole lot of progress with them and
the Gen 1 we did.
We haven't needed it at this point.
If we got down to it we would go to that route, but we haven't yet.
You want to give him one.
Anyone?
Next question.
Right here.
(Off microphone).
He asked besides Hula what other content
providers have we had issues with?
CBS, Fox, miscellaneous Flash streaming sites.
It is ridiculous the number of people that choose to block us
or block Google TV in general.
(Off microphone).
He asked how many have we had success bypassing?
All of them.
We mimic the desktop Flash setup.
If you want to give him one.
I think we are I think we are running low on time.
So let me get like one or two more questions.
Yes.
Okay.
Like guy in the red shirt and then we will get the guy
in the black shirt that's behind him.
(Off microphone).
Can you repeat the question?
I am sorry.
(Off microphone).
It hasn't been something he asked if we have tried to get a Python
or pro or any other scripting languages on the box.
We haven't worked on that, but it would absolutely be possible.
Yes.
It is Linux at its core.
So let me get this.
I am sorry.
And oh, wow.
Good throw.
Black shirt polo.
(Off microphone).
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 are here.
If we say anything publicly it could bite us in the butt.
So if you want to someone want to give that gentleman one
or throw one at him.
Sorry.
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 & Teller.
I think the gentleman in the black shirt had
a question unless it was already answered.
(Off microphone).
No, we would actually really love to know.
If anyone is here from Google is here we would love to talk to them.
We had an open conversation with Google and we don't know
if they hate us and we get the feeling that they do
because they tend to shy away from us.
Let's give him a URT and we will continue this in the Q and A room.
Oh.
This is this is getting bad.
So we will follow up in the Q and A room.
We can hand these out directly.
We don't have any more time for questions but we will have time
in the other room.
We will have time in the other room if any of you guys want to follow up.
Thank you.
(Applause) You did great.
Thank you.
We didn't hurt anyone, did we?