Rooting the FireTV Cube and Pendant with FireFU

Posted: October 31st, 2018 | Author: | Filed under: Uncategorized | 2 Comments »

Hello and happy Halloween fellow Today we’re excited to be bringing you something we’ve been working on for the last few months. Today, we’re introducing you to FireFU. FireFU is an exploit chain we’ve created to allow users to unlock (and root) their FireTV Cube and FireTV Pendant.

FireFu Exploit Logo

WARNING would like to remind users that any flashing of unofficial firmware or usage of provided tools is done at your own risk and will likely void your device’s warranty.  

DFU Mode

This exploit chain relies on two primitives, the first being a read/write primitive leveraged from the DFU mode accessible from the Amlogic S905Z SoC. DFU mode can be accessed on these devices by utilizing HDMI’s I2C bus and sending a specific string (“[email protected]”) to the device during boot. An adapter can be made which enters DFU by cutting open a HDMI cable or simply purchasing an HDMI header, then connecting to the appropriate I2C pins from the HDMI to the I2C pins on an Arduino or compatible board. We have provided an arduino “sketch” that can be compiled and loaded onto an arduino then used to perform the software side of entering DFU.

Arduino HDMI I2C

Upon accessing DFU mode, we are given access to read and write portions of the FireTV’s memory. Through this we target the hardware registers for the eMMC controller giving us the new primitive of being able to read and write to the device’s eMMC flash. However, due to both devices having secure boot enabled, we are unable to directly leverage the primitives we currently have to run unsigned code. We however did discover another vulnerability that we can use.

U-Boot Heap Overflow

In a secure boot environment, each portion of the boot process checks and sets up the following. From the SoC ROM all the way to the kernel and some cases even the kernel modules. In order to run unsigned code, a weakness needs to be found in some portion of the secure boots “chain of trust”. After a bit of research, we stumbled onto the perfect vulnerability we could leverage to break the chain. This vulnerability consisted of a heap overflow within U-Boot triggered when reading the RSV info within the devices partition table. This overflow can be seen in the code below.

436 /* get ptbl from rsv area from emmc */
437 static int get_ptbl_rsv(struct mmc *mmc, struct _iptbl *rsv)
438 {
439 struct ptbl_rsv * ptbl_rsv = NULL;
440 uchar * buffer = NULL;
441 ulong size, offset;
442 int checksum, version, ret = 0;
443 struct virtual_partition *vpart = aml_get_virtual_partition_by_name(MMC_TABLE_NAME);
445 size = (sizeof(struct ptbl_rsv) + 511) / 512 * 512;
446 if (vpart->size < size) { 447 apt_err("too much partitons\n"); 448 ret = -1; 449 goto _out; 450 } 451 buffer = malloc(size); 452 if (NULL == buffer) { 453 apt_err("no enough memory for ptbl rsv\n"); 454 ret = -2; 455 goto _out; 456 } 457 /* read it from emmc. */ 458 offset = _get_inherent_offset(MMC_RESERVED_NAME) + vpart->offset;
459 if (size != _mmc_rsv_read(mmc, offset, size, buffer)) {
460 apt_err("read ptbl from rsv failed\n");
461 ret = -3;
462 goto _out;
463 }
465 ptbl_rsv = (struct ptbl_rsv *) buffer;
466 apt_info("magic %s, version %s, checksum %x\n", ptbl_rsv->magic,
467 ptbl_rsv->version, ptbl_rsv->checksum);
468 /* fixme, check magic ?*/
469 if (strcmp(ptbl_rsv->magic, MMC_PARTITIONS_MAGIC)) {
470 apt_err("magic faild %s, %s\n", MMC_PARTITIONS_MAGIC, ptbl_rsv->magic);
471 ret = -4;
472 goto _out;
473 }
474 /* check version*/
475 version = _get_version(ptbl_rsv->version);
476 if (version < 0) { 477 apt_err("version faild %s, %s\n", MMC_PARTITIONS_MAGIC, ptbl_rsv->magic);
478 ret = -5;
479 goto _out;
480 }
481 /* check sum */
482 checksum = _calc_iptbl_check(ptbl_rsv->partitions, ptbl_rsv->count, version);
483 if (checksum != ptbl_rsv->checksum) {
484 apt_err("checksum faild 0x%x, 0x%x\n", ptbl_rsv->checksum, checksum);
485 ret = -6;
486 goto _out;
487 }
489 rsv->count = ptbl_rsv->count;
490 memcpy(rsv->partitions, ptbl_rsv->partitions, rsv->count * sizeof(struct partitions));
492 _out:
493 if (buffer)
494 free (buffer);
495 return ret;
496 }

Specifically, by providing a high enough value to the number of entries in the RSV table (rsv->count on line 490), we are able to overflow the heap allocation and obtain a new write primitive. Through this primitive (and all within the exploit’s payload) we modify values in memory for U-Boot tricking the device into believing it is unlocked and disabling all signature verification. Due to the exploit being ran during each boot, the U-Boot code needs to only be patched in memory. However, because the exploit is now being stored in the original RSV location in flash, we must move the old RSV values to a new area and fixup any addresses pointing to the previous location. After a reboot and successful exploitation, the Fire TV device will be able to run unsigned code.


To simplify flashing of new images, we’ve chosen to use flashboot to flash a new recovery and boot.img to the device, this new recovery only provides the fixups needed to point to the new RSV location. The boot.img however includes “magisk”, a popular android root application, to facilitate providing the user root access to the device.

Technical Details & Instructions

Technical details for the exploit chain is available on our wiki as well as usage instructions, source code, and information on needed hardware/tools.

FireFu Exploit Flow Chart

Video Demo Wiki – FireFU Exploit


Hack The Planet

All Your Things Are Belong To Us

Posted: August 18th, 2017 | Author: | Filed under: Uncategorized | Comments Off on All Your Things Are Belong To Us

We’re back from Vegas and it’s time to reflect. This year in Las Vegas, we were given the opportunity to present our research at both BlackHat USA 2017 and DEFCON 25. At BlackHat, we presented on reverse engineering embedded devices with eMMC flash in our talk, “Hacking Hardware With A $10 SDCard Reader.” At DEFCON, we came back and did a remake of one of our most popular presentations (“Hack All The Things“) with, “All Your Things Are Belong To Us.” The experience was amazing and we’re grateful to both conferences for letting us come out and present to you all. This blog post will be a summary of everything we revealed from both conferences and will hopefully guide visitors around all of the new stuff we’ve posted.

At BlackHat, our presentation was geared toward giving attendees a strategy for attacking devices with eMMC flash storage. In this presentation we showed attendees how to identify eMMC pinouts as well as tips on how to connect to an eMMC flash with a standard SD card reader and as few as 4 wires. If you’re interested in checking out the research, you can find the slides on our wiki along with our white-paper on the subject.

At DEFCON, our “All Your Things Are Belong To Us” presentation showcased exploits for a variety of new embedded devices. Below is a list with the corresponding new wiki pages for the new material we’ve added.

AOBO Hidden Spy Camera 720PMUZO Cobblestone
Aluratek WiFi RadioNetgear WN3000RP
Amazon TapQNAP Turbostation
Belkin N300Samsung SDR-3102N
Chromecast (Gen 1)Samsung SL-M3320ND
CujoTenvis T8810
D-Link DCS-936LVeraEdge-US Smart Home Controller
GGMM E3 Smart SpeakerVizio P602UI
LG BPM350Vudu Spark
Linksys WRT1200ACWD MyCloud
Lutron L-BDG2-WH Caseta Smart BridgeZmodo Greet (ZH-CJAED)

We dropped a lot of vulnerabilities on the audience at DEFCON, but a few of the highlights include bugs such as the remote root vulnerability we found within the QNAP NAS devices. This vulnerability affects a network transcoding service and allows for command injection as the root user. Then, there are the two vulnerabilities we found within the Western Digital MyCloud series of devices, a series of devices we’ve released multiple bugs for in the past; these pre-auth bugs both allow for remote code execution. The first one has the primitive of being able to write a file anywhere on disk, allowing us to write a PHP shell to the device for remote code execution as root. The other vulnerability is an authentication bypass which can be paired with any of our previously released (and unfixed) post authentication bugs for remote code execution as root. Beyond just the 3 NAS bugs, we’ve documented multiple hardware (UART/eMMC) roots, USB roots, and even a pre-auth root vulnerability affecting an SDK used in dozens of products.

You can find the slides for “All Your Things Are Belong To Us” and all of our previous presentations on the front page of our wiki (or HERE)

Finally, at DEFCON and BlackHat, attendees of our presentations received some new hardware we recently created. Particularly, they received our new SD & Micro SD Breakout boards which can be used with SD card readers to read 3.3v logic eMMC flash storage devices. These new boards will be available for sale in our online store soon and will be given away with orders from our online store (1 with every order).

If you attended either of our presentations, we’d like to say thank you for coming out and we hope you enjoyed getting to hear our latest round of research. If you didn’t, we hope you’ll check out our videos or slides. We love getting to spend time with the community and we hope we inspire you to “Hack Everything.”

Hacking Hardware With A $10 SDCard Reader:

All Your Things Are Belong To Us:

Re-Hacking The Samsung Smartcam

Posted: January 14th, 2017 | Author: | Filed under: Uncategorized | 1 Comment »

Today we’re re-visiting a device that we’ve hacked in a previous session. At DEFCON 22, we released exploits for the Samsung Smartcam network camera in our “Hack All The things” presentation. These exploits allowed for remote command execution and the ability to arbitrarily change the camera’s administrator password. After being alerted to the vulnerabilities, Samsung reacted by removing the entire locally accessible web interface and requiring users to use the Samsung SmartCloud website. This angered a number of users [Example 1, Example 2] and crippled the device from being used in any DIY monitoring solutions. So, we decided to audit the device once more to see if there is a way we can give users back access to their cameras while at the same time verifying the security of the devices new firmware.

Web Interface

When a user visits the updated web interface on the Samsung Smartcam, they are now greeted with a “404 – Not Found” message. The interface previously in place, which allowed for users to view and configure their camera, is now completely removed with only backend scripts left. Seemingly all vulnerabilities found by us as well as those found by others are patched. There was however one set of scripts that were not removed or modified, the php files which provide firmware update abilities for the camera through its “iWatch” webcam monitoring service were left untouched. These scripts contain a command injection bug that can be leveraged for root remote command execution to an unprivileged user.

iWatch Install.php Root Command Execution

The iWatch Install.php vulnerability can be exploited by crafting a special filename which is then stored within a tar command passed to a php system() call. Because the web-server runs as root, the filename is user supplied, and the input is used without sanitization, we are able to inject our own commands within to achieve root remote command execution. You can find the technical writeup and fix for the vulnerability as well as instructions for re-enabling the Smartcams’s web administration panel on our wiki along with a video demonstration below.

Hack Everything

In support of the legality of rooting

Posted: February 9th, 2015 | Author: | Filed under: Uncategorized | Comments Off on In support of the legality of rooting

As the Exploiteers, we believe in both open software and open hardware. We’ve worked tirelessly to come up with roots for all sorts of devices, and software modifications to make these rooted devices more awesome.

We are convinced that this is a good thing, and to ensure that we (and others) can continue to do awesome hacks, we are participating in the political process to ensure full control of your devices is legal in the United States.

One of the more pesky laws governing digital devices and their security is the Digital Millenium Copyright Act. It criminalizes breaking electronic locks for copyrighted works – which might include things such as the firmware update mechanism for your smart TV. The authors of the law recognized that there are reasons to circumvent digital locks that aren’t copyright infringement, and made an exemption process to formally recognize valid reasons to circumvent these locks. The exemption process happens every three years, with the US Copyright Office evaluating proposed exemptions. One of the newly proposed exemptions (by the Software Freedom Conservancy) this year is “Jailbreaking—Smart TVs”, which is a category we have a lot of experience with.

As a group of people who encounter these kind of locks every day, we submitted a comment through the comment process to advocate for formally stating that jailbreaking / rooting of smart TVs and streaming media players is legal in the US. We strongly support all of our users watching the content they want and running the apps they choose on whatever device they may own.

View the comment we submitted below, or as a PDF!

Read the rest of this entry »

A New Year With (The)

Posted: December 31st, 2014 | Author: | Filed under: Uncategorized | Tags: , | 1 Comment »

When GTVHacker started, we were a group of researchers who met on a popular Android developer forum and simply wanted more from our newly purchased and heavily fortified Logitech Revue Google TV devices. We would have never thought that our simple goal of utilizing our hardware would turn into GTVHacker. We moved to an IRC (Internet Relay Chat) channel and began researching how our devices worked and how we could make them better. This eventually turned into an obsession until we released our first root exploit for the Revue. Flash forward 4 years to today, and the irony of the situation is that we (as a group named “GTVHacker”) have released exploits for 40+ devices, and only 1/3 of them have been for the Google TV platform. Within the same time period Google itself has ditched the Google TV name in place for “Android TV” guaranteeing an experience more in line with that of its Android mobile devices.

So we as a group have decided it’s finally time to retire the name “GTVHacker” and transition into our new form as (the) “Exploiteers”. Over the next few days we will be transitioning all of the rest of the content from the GTVHacker network on to  We will be changing site logos and themes but the archived content will stay the same. If you happen to notice something that’s not working right, feel free to contact us at [email protected] to let us know.

In the mean time, here are a few things to look forward to from the

  • New exploits!
  • New custom hardware!
  • A new storefront to sell our custom hardware (and other future items).

TLDR, We’re now the and we’re hacking more than ever before!

Happy New Year!


Breaking Secure-Boot on the Roku

Posted: December 28th, 2013 | Author: | Filed under: Roku, Uncategorized | 12 Comments »
Hello Universe, welcome back. It’s been a while since our last post due to a lack of new Google TV hardware and developments. When we have free time we tend to look at other interesting opportunities that come our way and recently we came into just such a situation when we found ourselves auditing multiple Roku devices.
Roku-PileYou may not know it by looking at the device, but the Roku is considerably more secure than most entertainment devices in its genre (even our namesake). The engineers at Roku not only implemented a decently hardened grsec kernel, they did it where we hadn’t seen before, on ARM. The layers above that contain a miscellaneous assortment of secure boot and encryption methods with configurations varying between the different chipsets throughout the platform. Our package leverages one such configuration, the bcm2835 chipset, in which user accessible per box keys are used to sign the initial “stage 1” portion of the bootloader. This allows us, from the initial root bug, to modify a portion of the system boot and remove signature verification checks. Effectively breaking the “chain of trust” established and allowing us to load any compatible image desired.
Now for the details. The initial root exploit utilizes a local command execution vulnerability within the developer settings menu of the device. Specifically, the bug is within the development password field, and due to poor sanitation of input, the bug lets us run commands as root. This affects the majority of updated Roku devices and was ironically introduced as a security improvement.  The downside to this bug is that it does not provide a persistent root method (or, in short, a method that continues beyond system restarts). This left us looking for a method to persist root on the device, which is when we noticed the configuration of the bcm2835 Roku devices. In this chipset, the bootloader is signed by a per box key which, in all tested bcm2835 devices, is included on the box.  By having the per box key we are able to break the chain of trust and load a modified “stage 2” bootloader image. In our case we modify the stock U-Boot to include the “dev=1” kernel cmdline argument that identifies a developer device. We then take advantage of a init.d script which allows us to place files in a non-signature validated portion of the file system that is executed when the “dev=1” kernel cmdline argument is set. We use this file to place commands to mount a replacement version of “/bin/Application”, Roku’s main content shell binary, to allow us to disable automatic updates on each boot.
We’ve packaged up all of the above into a nicely commented script which can be downloaded from our download servers at:

The file above contains a script with a cpio archive that includes the following 5 files:

  •     bpatch – compiled for the device and used to apply binary patches to files
  •     mtd1-uboot.patch – a patch file for bpatch used to patch the U-Boot portion of mtd1
  •     nandboot.patch – a patch file for bpatch used to patch nandboot.bin (stage1 bootloader)
  •     roku2-nandwrite.ko – a custom kernel module used to modify kernel cmdline in memory and trick the NAND driver into allowing bootloader writes.
  •     Application.patch – a patch file for bpatch used to patch /bin/Application to disable updates.
The entire GTVHacker team has put a lot of work into this release and we hope the Roku community enjoys it. We invite others to continue our work and are happy to share progress made while we work to further leverage the current exploits before a patch is released. In the mean time, if you have a second generation Roku, root it. And if you don’t, buy one quick!
This bug will probably get patched soon. So in other words, exploit now or forever hold your peace.

Google TV Or: How I Learned to Stop Worrying and Exploit Secure Boot

Posted: August 3rd, 2013 | Author: | Filed under: Uncategorized | 1 Comment »

Yesterday at the DEF CON 21 security conference we released our custom recovery package and 2 individual exploits for the Google TV platform. The 2 exploits leveraged together allow users to install the first custom recovery ever created on the Google TV. The first exploit is a vulnerability which affects certain Linux configurations, in particular those that mount NTFS drives without the nodev flag. This is very similar to a vulnerability we leveraged last year for unsigned kernels on the Gen 1 Sony Google TV where as both exploit poorly mounted flash drives. The difference in this being that the NTFS bug affects every device within the platform and allows users to rewrite previously non write-able (RO) mtdblock partitions. We use this exploit to drop a SU binary on the device within the /system partition which is not mounted nosuid.  Of note, another valid method we could have used would have been to modify the build.prop file. Unfortunately,  even as the root user, security features within the kernel prevent this from being used to allow much for the Google TV community.We can however leverage this exploit to obtain a larger attack surface on the device.

This leads us to our next bug which only affects the boot-loader on the second generation of Google TV devices. This bug is found within the initial loading of the Google TV kernel after the device performs its RSA verification. This can best be summed up by the picture below.

Boot process for second gen Google TV devices.

Boot process for second gen Google TV devices.

As you can see by the above picture, multiple levels of AES decryption and RSA verification are performed. In a secure boot environment this setup is called a “Chain of Trust” which, in more descriptive terms, means that each segment loaded during the device’s boot is signed and verified to establish that it is provided by the manufacturer and not a third party (like GTVHacker). Our attack is actually performed directly after the last AES decrypt and verification routine, which in particular verifies the authenticity of the kernel image being loaded. The bug lies in the fact that the majority of Gen 2 devices do not perform any verification on the loaded RAMdisk address which is stored in the kernel image header. By changing the RAMdisk load address in the image to actually point to the kernel load address and by attaching an unsigned kernel image to the RAMdisk. We are able to load an unsigned kernel directly on top of the actual signed kernel after all decryption and verification routines are performed.  This method works on every device in the platform except the second gen devices by Sony. The Sony devices actually do check the RAMdisk that is supplied, but fail to do so correctly. By simply attaching another kernel and RAMdisk after the signed versions, and pointing the RAMdisk load address to this new kernel and RAMdisk we are able to bypass their signature checks.  By using either of these techniques on the generation 2 devices we are able to  completely destroy the chain of trust the device attempts to establish during boot and we are allowed to run any code needed, which in our case is a custom recovery image that does not perform any signature validation on update images.

Today we are releasing instructions on performing both attacks as well as our slides and content for the presentation.  Please note that this process does involve flashing portions of the device, and in doing so there is a risk of bricking your Google TV. We’ve attempted to make this process as fail-proof as possible in order to prevent bricked devices, however we can’t guarantee that your device won’t become a glorified paperweight.  With that being said, proceed at your own caution.

We will be open sourcing our code as well as compiling more custom recovery images for Google TV devices in the coming days. Keep checking our wiki, blog and Twitter for more info. In the mean time enjoy our DEF CON 21 content that we’ve spent a portion of our free time over the last year working on, and check out the video of the demo from our presentation below.

Chromecast: Exploiting the Newest Device By Google.

Posted: July 28th, 2013 | Author: | Filed under: Uncategorized | 10 Comments »

Chromecast-stockOn Wednesday, July 24th Google launched the Chromecast. As soon as the source code hit we began our audit. Within a short period of time we had multiple items to look at for when our devices arrived. Then we received our Chromecasts the following day and were able to confirm that one of the bugs existed in the build Chromecast shipped with. From that point on we began building what you are now seeing as our public release package.

Exploit Package:
Our Chromecast exploit package will modify the system to spawn a root shell on port 23. This will allow researchers to better investigate the environment as well as give developers a chance to build and test software on their Chromecasts. For the normal user this release will probably be of no use, for the rest of the community this is just the first step in opening up what has just been a mysterious stick up to this point. We hope that following this release the community will have the tools they need to improve on the shortfalls of this device and make better use of the hardware.

Is it really ChromeOS?

No, it’s not. We had a lot of internal discussion on this, and have concluded that it’s more Android than ChromeOS. To be specific, it’s actually a modified Google TV release, but with all of the Bionic / Dalvik stripped out and replaced with a single binary for Chromecast. Since the Marvell DE3005 SOC running this is a single core variant of the 88DE3100, most of the Google TV code was reused. So, although it’s not going to let you install an APK or anything, its origins: the bootloader, kernel, init scripts, binaries, are all from the Google TV.

We are not ruling out the ability for this to become a Google TV “stick”.

Speaking of Google TV – if you are in Vegas for DEF CON 21, check out our talk – “Google TV: Or How I Learned to Stop Worrying and Exploit Secure Boot” this Friday August 2nd at 3PM in the Penn and Teller Theater! We’ve got secure boot exploits for the Google TV (unsigned kernels and roots anyone?) and more – don’t miss it!

Chromecast - GTVHacker

How does the exploit work?

Lucky for us, Google was kind enough to GPL the bootloader source code for the device. So we can identify the exact flaw that allows us to boot the unsigned kernel. By holding down the single button, while powering the device, the Chromecast boots into USB boot mode. USB boot mode looks for a signed image at 0×1000 on the USB drive. When found, the image is passed to the internal crypto hardware to be verified, but after this process the return code is never checked! Therefore, we can execute any code at will.

ret = VerifyImage((unsigned int)k_buff, cpu_img_siz, (unsigned int)k_buff);

The example above shows the call made to verify the image, the value stored in ret is never actually verified to ensure that the call to “VerifyImage” succeeded. From that, we are able to execute our own kernel. Hilariously, this was harder to do than our initial analysis of exploitation suggested. This was due to the USB booted kernel needing extra modifications to allow us to modify /system as well as a few other tweaks.

We then built a custom ramdisk which, when started, began the process of modifying the system by performing the following steps:

  • Mount the USB drive plugged in to the chromecast.
  • Erase the /system partition (mtd3).
  • Write the new custom system image.
  • Reboot.

Note: /system is squashfs as opposed to normally seen EXT4/YAFFS2.

The system image installed from our package is a copy of the original with a modified /bin/clear_crash_counter binary. This binary was modified to perform its original action as well as spawn a telnet server as root.

After the above process, the only modification to the device is done to spawn a root shell. No update mitigations are performed which means that theoretically, an update could be pushed at any moment patching our exploit. Even with that knowledge, having an internal look at the device is priceless and we hope that the community will be able to leverage this bug in time.

Downloads and instructions for exploitation can be found on our wiki at: GTVHacker Wiki: Google Chromecast

Looking for help rooting your device or just want to ask us a question? Check out our Chromecast forum

GTVHacker at DEF CON 20: Oh the Exploits!

Posted: August 4th, 2012 | Author: | Filed under: Uncategorized | Comments Off on GTVHacker at DEF CON 20: Oh the Exploits!

As previously mentioned, we were invited to speak at the DEFCON 20 security conference, covering what else – Hacking the Google TV. We all had an awesome time at DEFCON and it was great to meet the rest of the team, both current and past members.

If you haven’t seen our slides from our DEFCON 20 presentation you can find them online here

If you notice in the DEFCON slides, we released multiple exploits, including:

WARNING: The links above contain the until now unreleased Revue root. As bliss described it, “it is like punching the device in the face while telling it that it’s not getting hit”. It is incredibly unstable and we are providing it unpackaged to prevent it from being used by someone who may end up damaging their box. If you are looking to get root to help achieve some form of optimal Android experience from the box, then please wait for a better packaged version with persistence. If you are technically savy and are willing to risk damaging your box, gambling on how skilled you are, then feel free to give it a shot. We will note that you are likely to brick your device much like we have bricked ours (but we have fancy-pants hardware recovery mechanisms).

The Revue root is an interesting one, at the moment it is not persistent; upon each reboot the Revue will need to be rooted again. We are working constantly to get past this road block. Unfortunately, every last item on the box has a signature that is verified at boot, so it makes keeping root across boots difficult. However, rest assured – we will do our best to get some form of persistence out soon. In the meantime, if you are worried, just unplug your Revue from the Internet.

Finally – we kept track of what we did while at the conference, and roughly how much time everything took:


We’ll be at DefCon!

Posted: July 23rd, 2012 | Author: | Filed under: Uncategorized | 2 Comments »

A few members of the GTVHacker team will be presenting at the Defcon security conference in Las Vegas this week regarding our newest exploits for the gen-1 GoogleTV line. If you are nearby come check out our talk schedule for Sunday July 29th 3:00pm.  A brief description of the talk and info on the presenters can be found on the Defcon Speakers page:

“The GoogleTV platform is designed to bring an integrated web experience, utilizing the Chrome web browser and Android applications, to your television. GoogleTV is based on the Android operating system, which is mainly used in tablets and smart phones, but customized with security features not normally seen on most Android devices. The current version of the platform utilizes signatures to establish a “chain of trust” from bootloader to system applications.

This presentation will focus on the current GoogleTV devices, including X86 platform details, and the exhaustive security measures used by each device. The presentation will also include video demonstrations of previously found bugs and exploits for each GoogleTV device and includes specific details about how each bug works. Furthermore, we will include interesting experiences that the team has encountered along the way. Finally the talk will be capped off with the release of multiple unpublished GoogleTV exploits which will allow unsigned kernels across all x86 devices (Revue / Sony GoogleTV).”

We also have other surprises in store for the community. Make sure to check out our presentation if you are at or around Defcon, otherwise check our twitter (@GTVHacker) and blog after the conference for public releases.