PSA: The new OTA (build 12840) patches the bootloader exploit used to obtain root
- Thread starter tchebb
- Start date
Sucks Man :/
Every reflash, first thing I do is kill the update_engine service, delete /cache/temp-ota.zip, then edit /data/updater/prefs/preveous-version to say 12840. I think this is tricking it, because every time I do this, it does not create a new temp-ota.zip, which means it is no longer trying to update. We will see though.
well... its too late to save cammys chromecast, but i made a new image without update_engine. I'm working on the recovery, but its not an android boot image. I'll do my best on it, but not sure what it is exactly.
no idea if update_engine is vital to anything except updating. and im not entirely sure its vital to updating.
give me a hour or so and i'll post a couple of different images that kill updating in a few different ways.
no idea if update_engine is vital to anything except updating. and im not entirely sure its vital to updating.
give me a hour or so and i'll post a couple of different images that kill updating in a few different ways.
when killed in logcat, it shows this:
Code:
I/logwrapper( 1473): /chrome/update_engine terminated by signal 15
I/update_engine( 1491): [0801/190057:INFO:main.cc(77)] Eureka Update Engine starting
I/update_engine( 1491): [0801/190057:INFO:update_check_scheduler.cc(64)] Next update check in 2700 seconds
I/update_engine( 1491): [0801/190057:INFO:string_based_ipc_server.cc(59)] Start IPC server: updater
I/update_engine( 1491): [0801/190057:INFO:unix_stream_server_socket.cc(59)] Unix server socket is created: updaterso it seems to only be for updating
looking at the recovery, it appears to create a wifi network with the name eureka_recovery, and starts dnsmasq. there is also adb, but apparently it doesnt have a usb interface for it.
there is a flash_bootloader binary. I'm assuming it flashes the bootloader. so i guess if i remove it, it can't flash the bootloader.
edit: so this recovery seem to have a menu, just like any android recovery. if only we had input and stuff..
edit 2: my chromebooks battery is low, and its update_engine_client is informing me there is an update. I'm going to let it charge and relax for a bit. maybe I'll have more ideas when i get back on.
edit 3: check the permissions on the kernel partition. it may be something a simple chmod could fix
edit 4: the recovery will attempt to install a file called ota.zip from a usb drive if there is no ota on /cache. someone should try it
edit 5: going to go cuddle with the fiancee and let the chromebook update and charge. may be back on later. good luck everyone. I'll post something by midnight
there is a flash_bootloader binary. I'm assuming it flashes the bootloader. so i guess if i remove it, it can't flash the bootloader.
edit: so this recovery seem to have a menu, just like any android recovery. if only we had input and stuff..
edit 2: my chromebooks battery is low, and its update_engine_client is informing me there is an update. I'm going to let it charge and relax for a bit. maybe I'll have more ideas when i get back on.
edit 3: check the permissions on the kernel partition. it may be something a simple chmod could fix
edit 4: the recovery will attempt to install a file called ota.zip from a usb drive if there is no ota on /cache. someone should try it
edit 5: going to go cuddle with the fiancee and let the chromebook update and charge. may be back on later. good luck everyone. I'll post something by midnight
Last edited:
For an idea, dont delete flash_bootloader as that would cause the update zip to fail.
EDIT: Nevermind, ignore my stupidity. Let me know what you come up with!
EDIT2: Permissions seem fine
Last edited:
In the interim, is this still an effective way to keep it from updating? I unplugged mine this morning before I went to work and I'm heading home. Just trying to figure out a way to still be able to use it without it updating.
Just checked again, it still trys to download an OTA.zip file so best thing is to either not use it, or keep an eye on it :/
i'll go ahead and upload the image thats lacking update_engine
later i'll upload a build with a modified recovery image. fiancee is missing me. I've spent too much time on this for now.
---------- Post added at 08:45 PM ---------- Previous post was at 08:11 PM ----------
https://dl.dropboxusercontent.com/u/19978192/gtvhacker-chromecast.bin.gz
this has update_engine replaced by a dummy script. this should kill ota updates, but it might not. again, provided as-is, no warranty, your problem if it breaks, yada yada.
I'll work on this crap more tomorrow.
Works great here!
Now, all I see in the logcat is this
Code:
I/update_engine( 1146): no updates for you!
$#@! Spent the last couple hours getting Linux running to make sure the image is written to the USB drive 100% properly. Now my Chromecast goes to the Updating splash screen, even if I'm holding down the recovery button. I'm not letting it run the update in hopes I can still get root access. It will be collecting dust until there is a solution. Grumble.
as long as you caught it before it flashed the update, you should still be able to get it rooted.
If you can get it to boot normally and were already rooted, you can remove the update and let recovery just error out. If it's attempting to boot into recovery every time without allowing you to boot from usb, there isn't much we can do at this point. The recovery will flash a ota.zip from a USB drive, but only if there isn't one on /cache.
Btw, how big is /cache? And does anyone want to test to see if the eureka_recovery network shows up and if it is used for anything?
Sent from my Evo V 4G using Tapatalk 2
Last edited:
Here are the file system sizes
Code:
/ # df
Filesystem Size Used Free Blksize
/dev 4M 32K 3M 4096
/tmp 32M 32K 31M 4096
/dev/shm 32M 0K 32M 4096
/data 1G 9M 1G 4096
/system 68M 68M 0K 131072
/cache 300M 9M 290M 4096
/factory 16M 6M 9M 4096So, first off sorry that we've been quiet - the entire GTVHacker team is at DEFCON - presenting today, 3PM local time @ the Penn and Teller theater on Google TV Secure Boot exploits, and some of this chromecast stuff.
However, the "I can't dd to /dev/mtd/mtdX" - The kernel forces it to mount RO. It's in arch/arm/mach-mv88de3100/somethongorother.c So either patch it out via memory, or lazy way - use our release, mount the USB drive, and swap out the squashfs that's on a vfat partition (just keep the same filename).
CJ
However, the "I can't dd to /dev/mtd/mtdX" - The kernel forces it to mount RO. It's in arch/arm/mach-mv88de3100/somethongorother.c So either patch it out via memory, or lazy way - use our release, mount the USB drive, and swap out the squashfs that's on a vfat partition (just keep the same filename).
CJ
Hi, I'm following that thread because i'm canadian and need the chromecast to use Unblock-US / Unotelly DNS instead of the hardcoded Google DNS. Is it true that the only way to have the chromeCast use a different DNS is either change it on the ChromeCast when it is Rooted OR using something on the router that intercepts all DNS request coming from the ChromeCast and forward that to UnblockUS DNS instead and re-write the originating source responce to have the chromeCast think it came back from Google's DNS ?
Thanks,
So, I am ripping my Chromecast apart.
What's the easiest way to attach leads to the UART pins?
Might there be some information gained from an update process log that might lead to another exploit vector?
Any brute force way to short out the device and get the update to fail? I'm willing to risk frying the device.
Let me make sure i have this right
So this is the current OTA update with root and trial disable ability for future OTA?
Last edited:
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
11Update
Since this thread seems to have become quite popular, I thought I'd update it to give people all the newest information in one place.
Since I've made this post, there has been another OTA (build 12940) that improves bootloader security even further and prevents some potential root methods which were being developed for 12840. As of now, neither build 12840, build 12940, nor build 13300 has a published root method. New units have the patched bootloader preloaded from the factory and are not rootable. If you buy a unit at this point, there is a good chance that you will get one that is patched. (EDIT 2013-10-22: People are reporting that units they have purchased from Best Buy and Amazon are still running the vulnerable build. It is unclear if this is simply old stock or if there are still vulnerable units being produced.)
As for the methods described below, they cannot be performed through a shell (i.e. telnet) since the root filesystem is formatted as squashfs, which is read-only. Instead, the root images must be manually repacked for each OTA and flashed using a USB drive with an image such as FlashCast. @ddggttff3 maintains a FlashCast mod to update Chromecasts to the latest firmware without losing root, which can be found here.
For those of you who have managed to keep your vulnerable bootloaders, keep your eyes out. There should be some very cool releases in the near future.
Original post
As can be seen in this commit to Google's Chromecast source mirror, firmware version 1.1 adds a check for the result of image verification on line 755. This check will cause GTVHacker's USB image to fail to boot, and you will not be able to obtain root. Even if another root exploit is found, it seems very unlikely that it will be as clean or simple as the one which exists now, which simply uses version 0.7's unlocked bootloader to flash a new system image.
Unfortunately, I don't have a Chromecast to test on, so I cannot recommend a method of disabling OTAs. However, from looking at the system image, there are a few possibilities I see. THE FOLLOWING METHODS ARE UNTESTED AND ARE NOT GUARANTEED TO WORK OR LEAVE YOUR CHROMECAST IN A WORKING STATE. PERFORM THEM AT YOUR OWN RISK.
After telnetting into your rooted Chromecast or otherwise obtaining a root shell, you can try these two possible methods
- Rename otacerts.zip to otacerts.zip.bak in /system/etc/security/. This may remove the OTA signing keys and cause the Chromecast to reject any OTAs. However, I do not know whether this file is actually used or whether is simply a remnant from Chromecast's Android base.
- Replace /chrome/update_engine with an empty, executable, shell script (make sure to make a backup copy first). I am very unsure of this method, since it is simply going off the name of the update_engine binary. If update_engine happens to perform some task core to the system, doing this will leave your device in an unusable state. If this happens, simply re-rooting using GTVHacker's USB image should restore your system to how it was.
Again, I am not responsible for any bricked Chromecasts which may result from attempting this. If you do try either method, please report whether or not it appeared to work or have any ill effects.7Remember my bricked chromecast? I found a way to force it to load from USB. This involves opening the device, and jumping 2 pins at a select time, and UART but check the following boot log:
http://pastebin.com/xHScat0T
I don't know if this would allow circumventing the locked bootloader , but it might be a recovery option for people with bricks.
EDIT: No longer have a bricked chromecast! Will post details in a bit for those who may be interested, or for future reference.
EDIT2: Thread Here: http://xdaforums.com/showthread.php?t=24387156
i'll go ahead and upload the image thats lacking update_engine
later i'll upload a build with a modified recovery image. fiancee is missing me. I've spent too much time on this for now.
---------- Post added at 08:45 PM ---------- Previous post was at 08:11 PM ----------
https://dl.dropboxusercontent.com/u/19978192/gtvhacker-chromecast.bin.gz
this has update_engine replaced by a dummy script. this should kill ota updates, but it might not. again, provided as-is, no warranty, your problem if it breaks, yada yada.
I'll work on this crap more tomorrow.4
Well if you compiled it yourself, you are nearly there. Quick overview of what we had to do:
/arch/arm/mach-mv88de3100/mv88de31xx_android.c , start setting partitions to RW in there, also disable any of the recovery boot options, and you may want to alter the command line in there (if not, arch/arm/kernel/setup.c)
When you build (what I did) was set CONFIG_INITRAMFS / CONFIG_INITRAMFS_SOURCE for your ramdisk, and pull the stock kernel ramdisk, and do some mods to it. Then point the INITRAMFS_SOURCE to where you modified the kernel ramdisk.
Hopefully that will help some, still been meaning to push our modded kernel source, but haven't had the time.
