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.
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.
The inevitable has happened, the GTVHacker “CubeRoot” Android application has been removed from the Google Play Store. At 11:14 AM CST, I received the following automated message from “Google Play Support”:
This honestly came as no surprise, we suspected that based on Google’s previous stance on the matter, our application would be removed from the market. However, it is interesting to be told the exact clause of the “Content Policy” that our app supposedly violated. Also, let it be noted that the GTVHacker CubeRoot application was listed on the Play Store for a total of 5 days.
As of today the Asus Cube is still vulnerable to the CubeRoot exploit. So even if you don’t plan on rooting your device with our exploit, you may want to consider using it solely for patching your device from attacks from malicious applications.
You can find a link [HERE] to download CubeRoot.apk.
After almost 3 years of GTVHacker, we have continued to strive to bring the Google TV community the best “root” methods on the platform. To date we have released multiple methods for gaining root access on the first and second generations of devices. We’ve also released hardware roots and software roots but have yet to venture into Android application development, until now:
Let me introduce you to Cuberoot, a brand new root for the Asus Cube. This root leverages a local command execution vulnerability within a Unix socket for NFS mounting. This socket interfaces with a helper application that doesn’t properly sanitize input allowing local code execution. Luckily for us, this particular vulnerability is made better by being able to be exploited from within an Android app. “But with great power comes great responsibility”, and with such we’ve decided to not only provide the method for rooting the Asus Cube but also allow users an easy method of patching their device to prevent another application from exploiting the bug for nefarious reasons.
So, what will Cuberoot do?
Root your Asus Cube.
Modify the Flash Player to bypass website blocks on streaming media sites.
Disable automatic updates.
Collect anonymous statistical information about your device.
Allow you to patch this vulnerability, which prevents malicious applications from using this bug.
Download the app [Here] or Check out Cuberoot in action below:
UPDATE: Now in the Google Play Store!
Search for Cuberoot in the Play store, or click [Here] to install.
We first broke news of the Netgear NeoTV Prime back in December, and have since been anxiously awaiting its roll out. Today the day arrived and we received our NeoTV Prime.
The NeoTV Prime uses the same form factor and hardware design as the Vizio Co-Star and Hisense Pulse. The box’s UI is a stock Google TV interface and is identical to some of the other Google TV devices.
Netgear NeoTV Prime Remote
The remote however is much different than the rest, with a smaller size and thickness plus a clickable mouse, the remote is much easier to hold and use. Although the remote is well thought out, the D-Pad leaves room for improvement. Furthermore, there does not appear to be a microphone which means the voice search additions coming with version 3 may require an additional purchase.
On to the exploits!
What would be the point of a simple first look post without some exploits!? In fact, this root method may be simpler than the method we previously disclosed for the Hisense Pulse. While the last one required ADB, this method only needs a properly set up USB drive.
The NeoTV Prime runs a debug service called “testmode” which checks for a USB drive with a file named “.testmode” containing the magic string “testmodemark”. The system then checks to see if the file contains the magic string “testmodemark”. If the system finds the file, it sets the “persist.radio.testmode.enabled” property to 1 and reboots. Then, if the device detects this property as 1 upon boot, it attempts to copy and then extract a file named “test_mode.tgz” from the USB drive to /tmp/. After extracting, the system tries to run a sh file named “/tmp/test_mode/test_mode.sh”. Assuming we set the permissions correctly this file will allow us to run the payload of our choosing as root.
Netgear NeoTV PrimePwn Root Process
The Following are Automatically Performed:
Disables automatic updates
Modifies flash plug-in to allow streaming of Hulu and other previously blocked content providers
Neo TV “PrimePwn” Root Process:
1.) Download PrimePwn.zip
2.) Extract the PrimePwn.zip to a Fat32 formatted USB drive. (test_mode.tgz, .testmode, README)
3.) Put the USB drive into your NeoTV Prime and reboot.
4.) Let the process run, it will reboot a few times and then will end at the home screen. (Approximately 3 minutes later)
5.) Remove your USB drive.
Netgear was kind enough to add an extra line in the init script that forces the hardware (UART) console to spawn as root. The box can be difficult to take apart and the software root is an easy process so we don’t recommend you use this method. We just wanted to mention its existence.
Posted: January 1st, 2013 | Author:zenofex | Filed under:Hisense | Comments Off
If you remember our previous post about the Hisense Pulse and its original shipping configuration then you’ll remember that the device, unlike all others in the Google TV line, came almost completely unlocked. Specifically, it shipped with a hardware root shell in recovery and normal boot modes, as well as allowed adb to be rebooted as root with a simple command. At the time we were wondering based on how open this device was shipped, was this an accident or was this a show of support to the “customizing” Google TV community? Well the verdict is in after an update was released this morning patching all current Hisense Pulse root methods. In particular, the update that was released today (BOX_2.31a.C1204_E_release , download here ) changes the “ro.debugabble” prop to 0 causing the hardware root method as well as the “adb root” command to no longer work. At the moment there is no other public root method but don’t worry, if you haven’t updated yet you can still run our “Pulse Modification Package” from the Hisense Pulse section of the wiki which disables automatic updates. Also, if you haven’t purchased a Pulse yet or have one already on the way, the Pulse will continue to ship “unlocked” for the time being. If we use the Logitech Revue as a reference point, since it shipped with hardware root shell in recovery mode until it was discontinued, newly purchased Pulse units may never be patched but will need to be rooted before their initial setup.
It’s sad to find out that the little bit of hope we had about this being a show of community support, as opposed to an accident, is now gone. We will continue to help the community “free” their devices as we have on the rest of the Google TV platform while hoping for the much needed release of a true Google TV “Nexus” device.
The day has finally arrived, the Hisense Pulse has launched and is finally in our hands. Upon first look we were impressed with the speed of navigation from within the menus. If you have experience with the previous generation of the Google TV platform then you’ll recognize the Pulse’s UI which seems to be almost identical to that of the Logitech Revue. The form factor of the Pulse is similar in size and shape to that of the already released Vizio Co-Star, and the motherboard layout makes it seem like they used a similar design. One difference between the Co-Star and the Pulse is that the Pulse’s remote is much more intuitive and its use feels more natural. All together it’s exactly what someone would expect for another device in the Google TV family but with one of the cheapest prices in its generation.
Our biggest and most unexpected surprise came within moments of our first examination of the Pulse. Upon receiving any new hardware, partially because of our previous experience with the Revue, we like to start off disassembling the hardware even before powering on a device. After doing so in this particular instance we found that a hardware root-shell is enabled by default through the serial console header on the device’s motherboard. Better yet, the root-shell is available in both recovery and normal boot which allows for tinkering of the device in both modes of operation. While we’ve seen serial consoles left in prior Google TV devices (see: Logitech Revue), we had yet to see a Google TV device that included a shell within both normal and recovery mode, let alone one in the second generation of the Google TV platform. While leaving a hardware shell leaves the box almost completely vulnerable its use still requires some soldering experience. However, after further exploration we noticed a 4 pin header on the Pulse PCB which allowed us to simply plug in a common connector and avoid soldering all together! This adapter is conveniently in a location that can be accessed by either temporarily opening the device and plugging in the adapter, or for more permanent use, by cutting a hole in the side of the case. The ease of access to the pin header as well as the obvious oversight of the serial console was just the beginning of our findings.
After finishing up our quick analysis of the hardware we finally had the opportunity to explore how the device’s software side was configured. We found that even with the hardware root oversight being as unexpected and less secure than any of its counter parts, the software side was worse. After browsing through the system’s init scripts, and checking the props, we noticed that a simple “adb root” to the device would restart adb as root therefore providing us with a root shell via adb.
Why is this device so much less secure than any of the other Google TV devices? Is this an oversight, or did someone at Hisense purposely leave it there to show community support? We hope that someone did this purposely as it would be great if a manufacturer or Google finally embraced the modding community, but it was probably just an oversight.
Knowing this, we thought it would be best to release our findings for the community as soon as possible as it will likely be patched quickly with the next automatic update. However, if you do have a Hisense Pulse and would like to take advantage of root before it’s possibly patched. We have a package that will perform a few community desired modifications such as:
Install Superuser.apk and su binary to device.
Patch flash player to allow content to be played from previously blocked websites (Hulu, Fox, CBS, NBC, etc.).
Disable automatic updates to preserve root (can easily be reversed).
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:
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.
It’s been a bit since we’ve made a blog post, however exciting times are coming. To
start, we have cleaned up the wiki and reorganized some sections. The NSZ-GS7 section of our wiki has been updated with lots
of new info, including a tear down and pictures of the new Sony recovery. You can check the teardown pics and the new recovery out here: GTVHacker Wiki: Sony NSZ-GS7
We’ve also started a page for the new LG devices, the LG 47g2 and the 55g2. The LG section is lacking since none of the GTVHacker team members currently have the TV, so we are counting on the community to fill in the blanks. We are also looking for a few users to help us with some remote debugging of the TV. If you’d like to help out you can find a few things we are looking for on our forums in the new LG section at:
A source has told us that Sony has already started testing a fix for the recent exploit and plans to have it coming out as soon as Monday as an OTA update. If this is correct that means that after you receive this automatic over-the-air update you will no longer be able to run the “recovery downgrade” or perform the recovery exploit to root your Sony GoogleTV. We advise all users to perform the recovery downgrade as well as the software root as soon as possible. The current custom kernel included in the root works very well and there are more custom kernels coming soon! If anything, the main reason to perform the exploit is to preserve your box from receiving the next update (which from what we’ve heard is only a security update). Then you will still have the option to revert back to the normal OTA at anytime. You will also however have the option to run one of our new upcoming kernels which we guarantee will make you all very happy. Otherwise, if you haven’t already performed our root, and your box does take this automatic update you will be stuck with using only official Sony GoogleTV builds, no Hulu/content provider bypass and no root.
As we’ve stated in the previous post, the guide and information about the process can be found at our wiki. Also just a note, the guide below states that you need 4 thumb drives to accomplish the exploit but with a little more work you are able to accomplish the entire process with 1.