if you remember were they are or find them again, plz share! I have some ideas for custom images!
PSA: The new OTA (build 12840) patches the bootloader exploit used to obtain root
- Thread starter tchebb
- Start date
if you remember were they are or find them again, plz share! I have some ideas for custom images!
In 12940, you definitely replaced one frame toward the end of the approximately 50-60 frames(IIRC) of the normal chrome boot logo with a handwritten "tvall" image. I haven't flashed 12940 yet, so I can't visually confirm it actually appears. It may be that frame does not appear if the boot process is short enough, or if it does, the one frame may not stay on screen long enough to notice. I guess the other hidden thing is the update_engine message.
BTW, I don't know how much difference it makes; but since your update_engine script runs then terminates, logcat indicates that it is continually restarted every few seconds. The real update_engine remains running as a service and checks for updates every 2700 seconds. Maybe it would be better for your script to run and not terminate but just sleep and do nothing?
I'll change that in my next release. I'll write something entertaining in c for fun instead of a crappy shell script.
I've done the reverse and used the busybox tftp feature to send files from the Chromecast to a temp tftp server I setup.
I've tried it with the different firmware version of Chromecast, different version of the Chromecast app and the different versions of Aircast (I disabled the time check) and couldn't get it to work. The Chromecast just black screens when you try and cast.
@tvall:
Does your image remove the files /factory/otp.pkg & /factory/custk.img. I notice the updater-script in the official 12940 does and I'm wondering if I should back them up first (or what they are).
Also thank you for the work. I have a chromecast on the way so I look forward to trying your image. I'll try to get you some pcaps of of the update process as well. I've tried some wgets with the earlier request data but I can't get it to send me an update link.
Does your image remove the files /factory/otp.pkg & /factory/custk.img. I notice the updater-script in the official 12940 does and I'm wondering if I should back them up first (or what they are).
Also thank you for the work. I have a chromecast on the way so I look forward to trying your image. I'll try to get you some pcaps of of the update process as well. I've tried some wgets with the earlier request data but I can't get it to send me an update link.
My image currently only touches /system. Nothing else. So those files will probably be left there, unless the chromecast removes them later on.
Not sure if this will help or not, but I have been doing research into this bad backupsys partition and boot mode that "bricked" my first chromecast. First off, It doesn't seem to boot, but in reality it is. its a old version of the chrome recovery image. so, here is a dump of backupsys for anyone interested. it is based on build 12069.
build.prop dump
http://pastebin.com/Kkj95MFP
partition image + dump
https://mega.co.nz/#!aZgRARBb!ZK_kk0n4QkecqNuARSSLb263iG9aqrPz3qKqHw0aaCE
EDIT: Found this link as well hiding in net_mgr labeled as speedtest
It goes to a 404, but there might be a way to get it. NOTE it is b1 though, so it may not even work on our devices, IF the file even exists anymore. It looks like there is a way to call it using curl, but I don't know it good enough, nor can I reverse engineer binaries.
build.prop dump
http://pastebin.com/Kkj95MFP
partition image + dump
https://mega.co.nz/#!aZgRARBb!ZK_kk0n4QkecqNuARSSLb263iG9aqrPz3qKqHw0aaCE
EDIT: Found this link as well hiding in net_mgr labeled as speedtest
Code:
http://dl.google.com/googletv-eureka/dogfood-channel/eureka-b1_ota_9284.zipIt goes to a 404, but there might be a way to get it. NOTE it is b1 though, so it may not even work on our devices, IF the file even exists anymore. It looks like there is a way to call it using curl, but I don't know it good enough, nor can I reverse engineer binaries.
Last edited:
On a normal nexii device, changing
is enough to effectively mask as the desired rom for OTA purposes, the biggest issue on doing this is that build.prop is in the ramdisk and not /system.
Wonder if it's possible to move build.prop into /system for ota sniffing purposes
Eureka-B1 is supposed to be an older hardware revision if I read the source correctly (I could very well be wrong though), B3 is the revision seen in shipping chromecasts of course.
Though it's an ota and not a factory image (there's little functional difference in full rom otas and factory images, the difference is political), goog tends to remove files when they're no longer relevent.
Code:
ro.build.date.utc=
ro.build.fingerprint=Wonder if it's possible to move build.prop into /system for ota sniffing purposes
Eureka-B1 is supposed to be an older hardware revision if I read the source correctly (I could very well be wrong though), B3 is the revision seen in shipping chromecasts of course.
Though it's an ota and not a factory image (there's little functional difference in full rom otas and factory images, the difference is political), goog tends to remove files when they're no longer relevent.
Last edited:
Another simpler idea for blocking ota updates I just had: hex editing update_engine and changing the app_id to something random. That should leave it running exactly like stock, but never finding any updates.
Not sure if there is any benefit to having the original binary installed. I assume it only does update checking, but I haven't examined thoroughly enough yet.
And tomorrow I'll see if I can get a pcap of chrome checking for updates. Been lazy this weekend
Not sure if there is any benefit to having the original binary installed. I assume it only does update checking, but I haven't examined thoroughly enough yet.
And tomorrow I'll see if I can get a pcap of chrome checking for updates. Been lazy this weekend
I'd be afraid of Google starting to respond to the modified app_id to force updates on rooted users...
I doubt there are enough of them for Google to care.
We could use something like all 0's, or we could use the app_id of a different product. Or this is a bad idea I didn't think about thoroughly and I should stop posting when I'm falling asleep.
Well, in that case, I'm kinda confused... If a Chromecast is successfully flashed with a rooted version of the v.12072 firmware that has the auto-updates disabled AND the user tries to "Cast" a movie to the Chromecast using that "Fling" Java PC app that WAS working before Google blocked the casting of local media, it SHOULD work, shouldn't it? It's theoretically like goin back in a time machine to when Chromecasts were on a firmware version that Google hadn't blocked the casting of local media AND when the "Fling" Java PC app was working just fine and dandy with the Chromecast...lol WHY wouldn't it work?? That just doesn't make sense to ME. I'm sorry, but I'm not an expert at this kinda stuff, so if you can please educate me and others on WHY it's not working, that'd be awesome and greatly appreciated!! Thanks man!
My understanding is that the chromecast calls home - and Google servers will not allow Fling or allcast to work. The blame had been on the new chromecast firmware update, but it was actually a Google server side change. That's what I read here a few weeks ago.
That is also the impression I was under, Koush mentions the server side changes here;
https://plus.google.com/110558071969009568835/posts/HbrpBbVGWvS
Remember 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=2438715
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=2438715
Last edited:
Remember 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!
This is GOLD.
I used the modified bin to root and flash my chromecast so I am on the original firmware with a dummy updater, supposedly. I was able to telnet into my chromecast. My chromecast should be safe from updates now, right?
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.
New posts
-
-
Question SAMSUNG S22 ULTRA NEED HELP PLZ!!!!!!!!!!!!!!!
- Latest: nguyenlucky
