Panel - Google TV or: How I Learned to Stop Worrying and Exploit Secure Boot
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 112 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/38963 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
DEF CON 2141 / 112
3
6
8
9
13
14
15
16
17
22
23
24
25
29
32
33
36
37
39
42
45
47
49
53
60
61
64
65
66
71
76
79
80
82
89
103
106
108
00:00
BootingGoogolHacker (term)Software developerSystem programmingJava appletBootingSoftware developerHacker (term)Group actionRadon transformSystem administratorInformation securityInformation technology consultingPhysical systemComputer animation
00:57
Computer hardwareElectric currentHacker (term)Local GroupSet (mathematics)GoogolProxy serverSoftwareRootComputing platformOverlay-NetzStreaming mediaPhysical systemPlug-in (computing)Revision controlGraphical user interfaceAndroid (robot)Content providerBlock (periodic table)Computer hardwareLine (geometry)Product (business)Hacker (term)Group actionSoftwareBlu-ray DiscGraphical user interfaceRevision controlComputing platformFlash memoryINTEGRALComputer animation
01:59
Kernel (computing)GoogolFlash memoryHacker (term)Computing platformCNNGoogolBootingFlash memoryComputing platformElectric generatorVideo gameSlide ruleKernel (computing)Computer animation
02:36
Computer hardwareRootData recoveryElectric generatorBlu-ray DiscComputer hardwareRootPlug-in (computing)Software bugKernel (computing)Data recoverySimilarity (geometry)Flash memoryComputer animation
03:16
Content (media)Block (periodic table)Proxy serverGraphical user interfaceFlash memoryWeb browserRevision controlString (computer science)Internet forumMessage passingFlash memoryWebsiteString (computer science)Revision controlMessage passingEncryptionReading (process)Hacker (term)Data recoveryAndroid (robot)Computer animation
04:07
SoftwareLjapunov-ExponentComputer hardwareRootFunction (mathematics)Hacker (term)ArmProcess (computing)System on a chipCuboidSheaf (mathematics)Computer hardwareComputing platformPresentation of a groupComputer animationLecture/Conference
04:52
CubeComputer hardwarePrime idealPulse (signal processing)Similarity (geometry)Hacker (term)ArmDuality (mathematics)Advanced Encryption StandardCryptographyCoprocessorRead-only memoryBootingRSA (algorithm)Electric generatorPrime idealDivisorSimilarity (geometry)SpeichermodellCubePulse (signal processing)Shared memorySet (mathematics)Duality (mathematics)CoprocessorFlow separationSemiconductor memoryFormal verificationArmEncryptionCryptographyInformation securityBootingPoint (geometry)Computer animationLecture/Conference
05:44
Invertible matrixComputing platformInformationAndroid (robot)IntelCore dumpSingle-precision floating-point formatDuality (mathematics)ArmSlide ruleMulti-core processorLibrary (computing)InformationAutomatic differentiationAndroid (robot)Computing platformFree variables and bound variablesVulnerability (computing)Revision controlArmKey (cryptography)Sign (mathematics)Software bugSingle-precision floating-point formatCore dumpComputer animation
06:54
Flash memoryDivisorLogicComputing platformForm factor (electronics)NP-hardEntire functionFlash memoryInformationAndroid (robot)Standard deviationLogicPhysical systemForm (programming)Pulse (signal processing)Lecture/ConferenceComputer animation
07:38
Pulse (signal processing)RootHacker (term)Gastropod shellGraphical user interfaceFlash memoryPulse (signal processing)RoutingRootAdaptive behaviorPersonal identification numberNumberSoftwareDebuggerSet (mathematics)Prime idealSelectivity (electronic)Lecture/ConferenceComputer animation
08:22
Prime idealHacker (term)RootMachine codeFactory (trading post)Backdoor (computing)Service (economics)Information securityVideo game consoleReal numberIntegrated development environmentVideo game consoleProcess (computing)RoutingPhysical systemAsynchronous Transfer ModeScripting languageSoftware testingPrime idealGastropod shellComputer fileLocal ringThumbnailRootLecture/ConferenceComputer animation
09:32
Computer hardwareCubeUser interfacePatch (Unix)RootElectric generatorScripting languageCubeCuboidMobile appRoutingTopological vector spaceAndroid (robot)Point (geometry)MereologyPatch (Unix)Computer animation
10:20
outputLjapunov-ExponentAndroid (robot)Vulnerability (computing)GoogolPoint (geometry)Patch (Unix)Hacker (term)outputMobile appPublic domainNetwork socketCartesian coordinate systemLocal ringGoogolSoftwarePoint (geometry)Android (robot)Vulnerability (computing)Data storage deviceCuboidType theorySoftware bugPatch (Unix)Computer animationLecture/ConferenceSource code
11:19
RootPhysical systemBlock (periodic table)Data recoveryGoogolSoftware bugNear-ringComputing platformLevel (video gaming)NumberBitDifferent (Kate Ryan album)Medical imagingTopological vector spaceData recoveryComputer animation
12:11
Android (robot)GoogolPartition (number theory)Block (periodic table)Partition (number theory)Data storage deviceTopological vector spaceSoftware bugSlide ruleConfiguration spaceSet (mathematics)Kernel (computing)Android (robot)Process (computing)Computer animation
12:53
WritingRootPartition (number theory)Hydraulic jumpBootingPatch (Unix)Default (computer science)Hacker (term)Block (periodic table)Hash functionComputerDefault (computer science)RootBootingProcess (computing)Medical imagingCuboidPartition (number theory)Kernel (computing)Computer animation
13:41
Computer hardwareCase moddingHacker (term)ArmDuality (mathematics)Core dumpPower (physics)Hacker (term)Computer virusComputing platformFile systemBootingArmFlash memoryImplementationTopological vector spaceTerm (mathematics)Medical imagingMotherboardComputer fileComputer animation
15:10
Flash memoryRootComputer hardwareAsynchronous Transfer ModeHacker (term)PlastikkarteNumberInformation securityBitData storage deviceHookingBootingFlash memoryComputer hardwarePersonal identification numberInterface (computing)Computer animation
16:10
RootCountingCNNComputer filePartition (number theory)InformationRootFile systemHexagonPhysical systemSign (mathematics)GoogolComputer animation
16:52
RootComputer-generated imageryTelnetGastropod shellScripting languageSoftware protection donglePhysical systemBootingMedical imagingFile systemMereologyBinary fileForcing (mathematics)Computer fileScripting languagePartition (number theory)Greatest elementRootGastropod shell
17:47
Kernel (computing)System callRSA (algorithm)Scripting languageDrop (liquid)RootLindenmayer-SystemBootingPhysical systemElectronic signatureCategory of beingBootingFlash memoryDisk read-and-write headComputer hardwarePartition (number theory)Interface (computing)Android (robot)Physical systemComputing platformScripting languageGroup actionComputer animation
19:00
Point (geometry)Hard disk driveKernel (computing)Component-based software engineeringEvoluteComputer hardwareFamilyModal logicKernel (computing)Hard disk driveEmailGoogolComputer animation
19:42
Hacker (term)GoogolComputing platformClient (computing)VideoconferencingPower (physics)Order of magnitudeContent (media)Boom (sailing)Ocean currentShared memoryGoogolComputerComputer animation
20:59
ArmSingle-precision floating-point formatCore dumpFlash memoryBefehlsprozessorComputer hardwareGoogolComputing platformView (database)Topological vector spaceShared memorySimilarity (geometry)BefehlsprozessorFlash memoryKernel (computing)Function (mathematics)Computer animation
21:52
Asynchronous Transfer ModeBootingGoogolHacker (term)Data recoveryAsynchronous Transfer ModePoint (geometry)BootingMachine codeFlash memoryLevel (video gaming)Roundness (object)Information securityMultiplication signRight angleSource codeGoogolEmailKernel (computing)Medical imagingResultantMessage passingIntegerStandard deviationFile formatSign (mathematics)File systemCausalityFormal verificationKey (cryptography)SpacetimeDrop (liquid)Computing platformMereologyCAPTCHAPower (physics)Physical systemElectronic signatureFunction (mathematics)ComputerAndroid (robot)RoutingComputer fileRootPatch (Unix)Direction (geometry)Computer animation
28:24
RootAlgebraBootingKernel (computing)RootEmailMultiplication signBitMachine codeRevision controlAndroid (robot)Computer animation
29:13
CubePrime idealGoogolPulse (signal processing)Information securityElectronic mailing listSoftware developerPatch (Unix)Lenovo GroupPhysical systemPrime idealArrow of timeMoment (mathematics)Pulse (signal processing)Computer animation
30:01
Hacker (term)Information securityPublic-key cryptographyBootingRevision controlHash functionBinary codeElectronic signaturePower (physics)Scripting languageCuboidAddress spaceLevel (video gaming)Dressing (medical)Formal verificationMedical imagingCryptographyWordInformation securitySession Initiation ProtocolCoprocessorMachine codeBefehlsprozessorEntire functionKernel (computing)Structural loadBlu-ray DiscProgram flowchart
32:50
Message passingBootingHacker (term)Android (robot)Kernel (computing)Computer-generated imageryAddress spaceAdaptive behaviorCuboidKernel (computing)FreewareAndroid (robot)Medical imagingEmailInformation securityMultiplicationDisk read-and-write headParameter (computer programming)BootingSource code
33:27
Android (robot)Kernel (computing)EmailComputer-generated imageryElectronic signaturePoint (geometry)Address space2 (number)EmailBootingMedical imagingRevision controlSession Initiation ProtocolKernel (computing)Android (robot)Blu-ray DiscHash functionRight angleWikiStructural loadSoftwareFlash memoryDressing (medical)Parameter (computer programming)Endliche ModelltheorieSubject indexingElectronic signatureHacker (term)RSA (algorithm)Information securityComputer fileCuboidSlide ruleComputer
35:19
Hacker (term)Kernel (computing)Address spaceRead-only memoryMachine codeElectronic signatureAreaAddress spaceStructural loadVotingMachine codeBlu-ray DiscRight angleKernel (computing)BootingCuboidSatelliteLine (geometry)Different (Kate Ryan album)Medical imagingEmailLetterpress printingComputer animation
36:35
Kernel (computing)Process (computing)Data recoveryStructural loadAddress spaceBootingInformation securityComputer-generated imageryMathematicsHacker (term)BitInformation securityDifferent (Kate Ryan album)Blu-ray DiscKernel (computing)Medical imagingAddress spaceUniform resource locatorDressing (medical)Free variables and bound variablesStructural loadComputer animation
37:18
MereologyKernel (computing)Structural loadPatch (Unix)Kernel (computing)BootingRevision controlTopological vector spaceSoftware developerFlash memorySource codeMedical imagingMultiplication signSharewareComputer animationLecture/Conference
38:00
Machine codeCuboidBlock (periodic table)Data recoveryPhysical systemFlash memoryEndliche ModelltheorieKeyboard shortcutNumberMetropolitan area networkRight angleBootingError messageVideoconferencingType theoryMultiplication signGroup actionLatent heatMoment (mathematics)ComputerRootMachine codeYouTubeLevel (video gaming)GoogolAndroid (robot)Buffer solutionGodOpen setTelecommunicationTouchscreenQueue (abstract data type)Cartesian coordinate systemPoint (geometry)Presentation of a groupHacker (term)RoutingSoftware development kitWebsiteFormal languageGoodness of fitState of matterConnected spaceArithmetic progressionRevision controlWritingInternet service providerMedical imagingSharewareLink (knot theory)ComputerAdaptive behaviorPersonal identification numberCompilerKernel (computing)MereologyRoundness (object)Polarization (waves)Computer animation
Transcript: English(auto-generated)
00:00
Greetings, everyone. Welcome to Google TV or how I learned to stop worrying and exploit secure boot. My name is Mike Baker. I'm a firmware developer. I did open WRT. We also
00:21
have Hans Nielsen, who is a senior security consultant at Matasano. We have CJ Hirs, an IT systems administrator. Gynophage, 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 Edmata, who is a
00:51
researcher at AcuVent Labs and also the founder of the GTV hacker group. So GTV hacker is
01:01
a group of 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
01:25
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
01:48
an integrated Google TV. It has a custom version of Chrome and a flash version that I'll talk about later. So why do we hack the platform? We hack the platform because
02:07
unlike the Google Nexus devices, it has a locked boot loader. It has a heavily restricted kernel. And the previous generation, the generation one, is now end of life. And the flash player, I'll get to that in the next slides. So before we start, I'm
02:28
going to do a very quick recap of the stuff we did last year at DEF CON. I'm going to speed through it. So if you 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
02:44
the Sony TV. The Logitech review, they left a root UART. We also have an exploit by Sorek wrote an impactor plug in. Awesome. So the Sony, similar situation, it has a
03:06
no dev bug. We also wrote a custom recovery for it and used K exec 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
03:24
Hulu. You get redirected to a site that says, sorry, this is a Google TV. And the fix for that is literally just changing the version string. So what happened after we hacked these Google TV devices? We found this. This is a nice message from Logitech that they
03:45
hid in the Android recovery. It's a rot 13 cipher that says GTV hacker, congratulations if you're reading this, please post a note on the form and let us know. Let me know. And includes all of our nicknames. Yes, whoever is at Logitech that wrote that, you are
04:04
awesome. This is why we hack devices. So the Boxee 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
04:22
Boxee Plus community. And it's still vulnerable. So that's awesome. So next up is Amir. Hi, everyone. I'm going to continue the presentation. My section regards Gen 2
04:45
hardware and one of the first O days we're going to release for the platform, Gen 2 at least. So Gen 2 hardware, we have a multitude of devices. They increase the amount of devices they had by like a factor of two. And I guess they were going to increase the
05:05
market share. But essentially you have the Korean LG U plus, the S cube, the LG 47 G2 and G3, the Netgear prime, the Sony NSGS7, GS8, the Hisense pulse and the Visio costar. They have a similar hardware design throughout most of the generations short of
05:22
the LG 47, G2 and G3. Gen 2 features a Marvell 88DE3100 based chip set. It's an arm dual 1.2 gigahertz processor dubbed the Armada 1500. It features an on‑dicrypto processor with separate memory and it does secure boot from ROM via RSA verification and AES
05:44
decryption. This particular slide, there's not a whole lot that you really need to pull from this. It was just directly from their marketing stuff for the chip. Yeah, it's just here to show you kind of how they pride the chip set itself. Skip the place holder
06:03
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.
06:22
And impactor wrote his amazing tool ‑‑ sorry ‑‑ wrote his amazing tool impactor. It is not a bionic libc set up. It's a fat G libc set up 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
06:42
gigahertz. Gen 2 is a marvel armada 1500 dual core arm 1.2 gigahertz. Android 4.2 incoming for Gen 2 adds native libraries and bionic libc 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
07:04
eMMC flash inside of the Sony NSCGS7. It has the best remote so if you're going to buy Google TV, we probably recommend this one. Hard to recommend Sony. Larger form factor than some of the other Google TV devices and it has built‑in IR blasters which sounds
07:21
like something that would be throughout the entire platform but it's sadly not. The Visio costar features a smaller form factor, no voice search, a custom launcher, $99 MSRP and updates are actually done through update logic as opposed to the standard Android check‑in system. It's common in all Visio devices. The high sense pulse has the second best
07:41
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 and ADB root and ADB has root privileges. So it was patched shortly after and it has a $99 MSRP. With ADB root, there was also a UART root set up, I guess for debugging and whatnot. And they had
08:06
RO debuggable 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, connect your UART adapters that we give you after this, you could technically connect to that pin out that's right up there. Again,
08:20
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.
08:43
RO.secure is set for like ‑‑ if they're in a debug environment, they'll set RO.secure to zero. And if they're not in a debug environment, they'll set RO.secure to one for just setting up special lockdowns. Then we did the Neo TV Prime root which was essentially
09:00
an exploit that leveraged the update system on the Neo ‑‑ the Netgear Neo TV Prime. Essentially the process involves checking if persist.radio.test mode is enabled and if it is, it extracts a test mode.TGZ from a USB drive to slash temp and then it just straight executes a shell script from that file. So you run ‑‑ you get local command
09:26
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 two hardware, horrible remote again, $139 MSRP, but we really like this box because of this next part, cube root. So we
09:47
had a lot of fun with this. We hadn't actually done an Android APK that actually leveraged one of our exploits up until this point. So it was really neat to be able to put this together and certain members were a big portion of this. So this was great because
10:05
we created an app that not only exploits but it patches your Asus cube because our whole fear was that releasing an exploit into the market, you know, if someone else takes a look at it, they could, you know, put it in their own app and, you know, root all your Google TVs. So we set it up so that it can do patching and it can do rooting.
10:26
But essentially how it worked is it exploited a helper app called Oplay Helper via a world rideable UNIX domain socket. The helper application passed unsanitized input to the mount command resulting in local command execution. We triggered the
10:40
vulnerability from an 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
11:04
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 Oday that I had told you guys about. We haven't ‑‑ we've been using this bug for a while to do our
11:23
investigations on like new devices and research on new devices to kind of just see how things are set up. So this is kind of something that's near and dear to us because it's worked on the entire platform to date. So what it is is we call it the magic USB. We just like saying magic because we're on the Penn and Teller stage, I guess. So if
11:43
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
12:02
without no dev. So this is pretty similar to that. It's NTFS but it's not ‑‑ and it's not done in recovery. But it's just as powerful. So all Google TVs and some other Android devices are vulnerable. What this bug is ‑‑ actually I'll get to that in the next slide. The
12:23
way that this is set up, it requires a user to have an NTFS removable storage device. It requires the device to be mounted no dev when you plug it in. So you can easily just run mount and see if it's no dev. And so it affects more than just Android. It affects
12:40
certain kernel configurations or certain configurations. So with this particular set up, bold mounts NTFS partitions without no dev. And it's a little known feature. It does support block devices. So our magic USB, essentially the process is that you go, you
13:01
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
13:20
partitions are mounted read only, it overwrites them just beautifully. So we dump the device 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.
13:48
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
14:04
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
14:22
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
14:45
it's very upmarket because it's a Google TV. It's cool. So this thing's over $1,000 and, you know, we really didn't want to spend $1,000 on it. So what are we going to do? Well, I mean, we like taking things apart. We like putting things back together. So we did the next best thing, which was on eBay, we just bought a power supply and a
15:03
motherboard from the TV. We didn't actually buy the rest of the TV. And it turns out you can get that for not that much. So as soon as we had this, we did that thing that we love so much. We soldered some wires to it. So this hardware is based around that LG SOC and the storage it uses on this is it uses an EMC flash chip. So it's very
15:26
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
15:42
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
16:05
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 0x100000 hex, we found the partition information that
16:22
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
16:40
more interesting partitions as usual is system because that contains the majority of the files used to actually run Google TV. That's where all the APKs live. That's where they live. 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
17:04
just a manner of unpacking the system image, figuring out what in that system image gets quickly called by the boot loader and then messing with it. So it turns out that the boot partition, you can see on the right side here, there is part of the boot scripts. At the bottom, it calls this vendor bin init force strip dot SH. So that's on
17:28
system. So we just replaced that file to spawn a shell. Connected a UR. Again, we love soldering wires to things. And there we go. Then we have root. All on a device that
17:42
we never actually bought the full thing of. So another device that we did this to was the Sony NSG7 and GS8. They also went with this eMMC flash interface. So on this
18:00
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 dot secure is zero. So that you can just straight up ADB to the device and everything will just be great, easy, simple.
18:21
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 dot secure must be one. Well, so we went around looking at how is the signature stuff working, and it turns out they're
18:40
just not verifying those signatures. So it was pretty simple to just replace init, and then we were able to do whatever we wanted. 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
19:00
fun feature that this device had is it had a SATA port, unpopulated SATA header inside the device, but it did actually have the necessary passive components on the hardware to support this. So we soldered a SATA connector to it and plugged in a hard drive. So far it
19:21
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.
19:43
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
20:03
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 solved
20:20
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 stuff, 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
20:44
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
21:03
could, and it turns out that it has pretty standard stuff that you kind of see for an embedded device. It has RAM, it has Flash, it has a Wi-Fi chip, and it has a CPU. The CPU is a Marvell 88DE3005. Now, this instantly made us go, oh, well, this is cool,
21:25
because the Marvell 88DE3100 is what we've been seeing in most of the Gen 2 Google TVs. So it was very interesting to see this Marvell device in here, and when we saw that, you know, we start getting suspicious. You know, why is this device in here? Maybe this shares similarities to the Google TV platform. So the first thing that we did
21:46
is say, okay, well, this thing is going to have a UART in it. So let's go find that. So we found the UART and started looking at the kernel output from this device. Turns out
22:01
that it is very, very, very similar to a Google TV. It even says booting GTV kernel when you look at the UART output. And other things that it has, it has a USB port on it that you use to power it, but if you plug that into your computer example with a standard USB
22:22
data cable, you don't actually get anything there. The device doesn't show up or anything. That's because it's not actually a USB device. It runs in USB host mode. So you can actually, using a USB on the go cable, plug other devices into the Chromecast directly.
22:41
Another very, very fun feature was that it has the same boot loader as the DE3100. It shares the ‑‑ if you look at the source code drop that Google provided for this device, it's the same boot loader. In fact, there's almost no references to the 3005 in there. The references are pretty much all for the 3100. So it's very, very similar to
23:04
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
23:21
device? It's really restricted. All we have is this UART, we've got this host mode USB port and we've got HDMI. We also have one button. I like buttons. So with this button, because the first thing you do with the button is you press it while it's rebooting, see what happens. And it turns out that holding this button down causes fun things in the boot loader. The boot loader actually has a very special recovery
23:44
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
24:01
level recovery. It runs some code in the boot loader that reads directly from a USB stick. So that host mode USB port turns out to be useful for this recovery mode. So the boot loader is really simple. They tried to put not too much stuff in there. So it's not
24:21
even like it's a file system available for this boot loader. Instead, it just reads directly from the, from OX1000 on that USB key. It leaves just enough space to put a file system, not a fat file system, an MBR header, and then data. So now that we
24:43
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's loading? And it's the, it's actually the same standard Marvell image format that we'd seen on a lot of other Google TV devices. So we found an image. Okay. Well, can we boot stuff? Do we have, you know,
25:05
signed kernels, other signed images we can try running on here, see if we can get anything to run? Well, we spent some time looking at the code. And what we found was a very significant oversight. It turns out that if you don't verify the result of your
25:26
signature check, your secure boot doesn't work very well. So the original route for this thing was actually pretty straightforward. Once you figured out the, all of the weird
25:42
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 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
26:01
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
26:28
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
26:42
guys are all first time. Have to. Give them a big round of applause for their first time. Now we'll see if they can keep going with the presentation and pick up where
27:53
they left off. So that's actually pretty much it for the Chromecast stuff. Very convenient.
28:11
And now I don't have to worry about speaking with a shot at me. So CJ.
28:25
So now my introduction, lovely picture. We have root through the NTFS trick. It works great. We can write whatever we want. But relating back to the SATA header, we want more. We want to run our own kernels. We don't like locked boot motors. So secure boot
28:41
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 relevant 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
29:03
believe that this exploit should also work on pretty much every Android‑based Armada 1000 because the boot loader was provided by Marvel to whoever wanted it and the flaw is in that. So a list of devices it should work on. Left‑hand side, the Sony NSZ GS7, the Netgan Neo TV Prime, Vizio co‑style, Hisense Pulse, Asus Cube, the Sony NSZ GS8,
29:26
the LG U‑plus IPTV, Google's Berlin development device, which is very similar to the Vizio co‑style. 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 two or three
29:41
weeks, though they could patch it by then. The Hisense XT780 TV, which should be out any moment, might also patch it, but sometimes they don't because it's already being produced. The Lenovo S31 slash S61 TV, which is available in China. The TCL Movo that should be out soon and others. There may be other vendors using this chip that we're unaware of. So for a detailed security overview of how the entire system
30:04
boots, starting from the internal secure crypto subprocessor, the box will power on, it will then execute the ROM code that's built into it and it will load stage two. Stage two exists either on NAND, EMMC or over SPI. But when it loads it in, it will first
30:22
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, that's how that works. So if it decrypts and verifies successfully, it will then return ‑‑ it will actually have a return code and it will return a one or a zero depending on how it
30:42
boots and it will either fail or continue. Sorry, I'll slow down. I'll take a sip. Hold on. So next up, stage two will then execute. So assuming it
31:16
verifies, it starts up. And then stage two will finish the initialization on EMMC that we
31:23
could remind you modify to pretty much do whatever we want. And it will then load stage three to 0x0680000. We'll admit these addresses are somewhat important but we'll just consider it boot loader address, kernel address, RAM disk address. So that will load in and assuming it then decrypts and verifies properly, it will then execute stage three.
31:45
Stage three 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,
32:01
send it back to make sure it's good. So upon execution it will then load the kernel to 0x01000800. Assuming then again it decrypts, it verifies and it's all good and it returns a value that it checks. It will then continue to load the RAM disk to 0x, I think that's about 2 million or so. It will call the RAM disk address. Once
32:23
that's done, it will then execute the kernel. The kernel in the command lines that are set inside the boot loader will then set a hash to check the init script to ensure that the init script, I'm sorry, the init binary hasn't been tampered with due to the RSA checking that was somehow broken. Then it will then verify the RSA signatures on the
32:46
init scripts which we know don't work but I'm sure they probably will work within about a week. But back to the U‑art, which keep in mind we are giving away U‑art adapters right after this. They're kind of pointy but they're free. So pulling it up all the boxes have a U‑art and we can see they have the start kernel at
33:05
010080000. So again, keep that address in mind. It is important. A lot of data to throw at you but it will work. So this is a picture of the Android kernel and Marvel secure image. No Android header with the Android magic. Then has some kernel
33:20
arguments which it doesn't use. Then some encrypted gunk below it. So keep that Android kernel header in mind. Now if you take a look at AOSP's boot image dot H, you have a struct for the kernel header itself. Character magic Android with the exclamation point. Then you have the kernel size, kernel address, RAM disk size,
33:43
RAM disk address, second size second address, SHA‑1 hash, some of the stuff that's not really relevant right now. I'm going to pull up a marked version of this image and give you a minute to review while I take a sip of this. So the marked up version of the
34:00
Android kernel and Marvel secure image. Top left you have your Android magic. Keep in mind these slides will be posted up maybe in about an hour on DC21 dot GTB hacker dot com with all of the files. We'll get the stuff up on the wiki rather shortly thereafter. Can't really trust the network here so we might wait until Monday when we're back home. But getting back to this, Android magic, then kernel size, then we
34:24
have the kernel load address. After the kernel load address we have the RAM disk size, the RAM disk load address. Then we have the kernel load arguments which surprisingly are replaced on boot. When we initially started trying to get into this box, we attempted ‑‑ we dumped the image, noticed the Android kernel header, we figured we
34:43
could mess around with command lines. It might work. Tried that but we wanted to fail safe so we went with the EMMC flash back up. 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 SHA‑1 hash which surprisingly we can alter and it will
35:02
not check that. Followed by that is the actual Marvel secure image which includes a key index, a signature, an encrypted data size, then an RSA 1024‑bit signature followed by AES‑128‑CBC encrypted data. So they're not messing around. But let's take a second look at that header. The RAM disk size and the RAM disk load address. In the
35:24
red is the RAM disk size, the black is the RAM disk load address. What we can do for some idiotic reason they do not verify the RAM disk load address. So we can change it to whatever we want and it will execute our code, especially if we place it right where the kernel should be loading. This loads in right after the kernel and since we changed the RAM disk load address, we can then replace the RAM disk with
35:44
our own unsigned kernel with SAT 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 bootloader code looks like. We have a fixed kernel load address. It does an
36:01
emmc read up at line 4. Some printfs. Then it does a ‑‑ we thought this was load image. It turns out it's verify image. A verify image on the kernel image itself. And it actually has an if to check the return code. It does ‑‑ you know, if else. And ‑‑ but if you notice, after the return, it will then load the RAM
36:21
disk ‑‑ it will check the RAM disk header size to see what it is and if it's actually set to something. It will then load in an arbitrary amount of data at whatever address we give it. Which horribly insecure because ‑‑ because of that, we're able to own the box. Now, for the Sony NSE GS7, it was a bit different. Sony went above and beyond with its security. They also signed the RAM disk image so we
36:43
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, 010008000, we could set it to say 0100098000 or something. And then we could
37:05
still get a packed kernel to load in just the right address and still execute. Sony's 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. We can ‑‑ through this exploit,
37:21
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 get it to execute with no issues and we could load a kernel via TFTP, as I said, flash or USB for
37:45
development. So I'm going to skip this future research this time and show you guys a quick demo and I passed that up. Thank you. I don't use Macs. Where's my mouse? Thank
38:01
you. So we're also going to show the ‑‑ come on. I look totally computerized. Seriously? Fix me. Nice. We're going to hide this. So what we're doing right now,
38:26
we're going to ‑‑ there's nothing on the screen. Really? I can't do this. Thanks for that. Yeah, I just ‑‑ this blame isn't totally on me. Blame on you, too. That's
38:41
awesome. There you go. Move to your right. Move to your right. Yay! Let's get a round of sound for everyone in the audience. Sweet. So you're probably not going to make this out. It's going to be on YouTube probably when we're off the stage. Just
39:01
check out our GTB 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
39:21
normal one that doesn't work since we don't have group permissions and then run flash erase and then write on our modified version to then insert a custom recovery that we created. Keep in mind our custom recovery is rather thin. It's not like we can just, you know, port CWM to it and call it a day because CWM's frame buffer uses Android's frame buffer which the Google TV boxes do not have. The Google TV
39:43
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
40:03
erase and now we're going to do the NAND write 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
40:26
and then we're going to show my typo and honestly I do not know what I mistyped but something happened. So there's the error and now we're going to do the actual write of the custom recovery we created. This is the slow part of the video,
40:50
watching everything type and then it picks up. Copy, paste, enter. Right, right, right, right, right, showing that we can write to anything on the box we
41:00
want using that NTFS trick which should work on many, many devices because most people don't know an NTFS device can use block and character devices. So now we're rebooting into our custom recovery that you'll see pop up on the right hand side of the screen. Keep in mind that recovery images, kernel images are signed and encrypted. I'm going to show you on the left hand side that we have put my
41:22
handle for the kernel compiler just showing we're putting in a USB drive with a copy of U-boot on it that we're going to then flash to replace the boot loader. So there's our custom recovery on the right using unsigned code. And now
41:44
scrolling all the way to the top we did a busy box ID to show we have root over ADB and if you want you can modify to whatever else you want. So command line CJ000 GTB package is proving that it is our own custom compiled kernel running on the box. Now pressing one, installing the custom U-boot and it's then completed. We're
42:07
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 boot whatever we need. So that's pretty much it for the demo video. I'm going to shoot it back to MBM to close off. So links to everything that we've covered in this
42:33
presentation is at DC21.GTVhacker.com. We thank you all for attending and we're
42:41
going to hand out some UART adapters. We're looking for questions that 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 some quick questions, anyone? Right here? He
43:06
said what experience do we have getting Android applications that are not built for the Google TV with native code to run on the Google TV? I actually did put together a native development kit for Google TV but it's not in a good state that I feel
43:22
comfortable releasing. I built a connect box APK with just some ‑‑ like it does very minimal ‑‑ like it uses very minimal native code. But it works. I tested the native code, it works fine. If anyone in the community wants to step forward and help out with that, we'd appreciate it. Anyone else? Right here? Can you say that again? He
43:59
asked if we've tried JTAG debugging or if UART is sufficient. UART has been
44:04
sufficient up until this point. We've looked at some of the JTAG pin outs but we haven't made a whole lot of progress with them. In the Gen 1 we did ‑‑ we really honestly haven't needed it at this point. If we got down to it, we'd go that route but we just ‑‑ we haven't yet. If you want to give him one? Anyone? Next question? Right
44:23
here? 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
44:42
people who actually choose to block us or block Google TV in general. He asked how many have we had success bypassing their mitigations, all of them. Essentially we just mimic the desktop flash setup. So if you want to give him one? I think we're running low on
45:04
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 behind him. Can you repeat the
45:20
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. It's Linux at its core. So let me get
45:46
this ‑‑ I'm sorry. And ‑‑ oh, wow, good throw. Black shirt polar. He asked what's next for the Chromecast. We're looking at other avenues of exploitation. But we are
46:04
afraid to mention exactly what they are based on how quickly it was patched and also that we're here. So if we say anything publicly, you know, it could bite us in the butt. So if you want to ‑‑ someone give that gentleman one or throw one at him. Sorry. Please ‑‑ oh, my God. Okay. You know, let's use the honor system and pass that to
46:25
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
46:43
communication with Google about much of anything. I don't know if they hate us or not. And we kind of get the opinion they do because they tend to shy away from ever asking questions. But we ‑‑ let's give him a UART and we'll continue this in the Q&A
47:02
room. Oh, my God, dude. Holy ‑‑ okay. This is ‑‑ this is getting bad. So we'll follow up in the Q&A room where we can hand these things out directly instead of hurting anyone. So, yes, I'm sorry, we don't have time for any more questions, but we will have time in the other room if ‑‑ we will have time in the other room if any of
47:24
you guys want to follow up. Thank you.