yashsingh1/xdaforums huggingface dataset:
[Google Chromecast] ghowse:
These links are still valid. It might be worth grabbing a copy of each just in case.

http://pdl.team-eureka.com/recovery/releases/autoroot-recovery-r02.img

http://mcpdigital.com/android/ota.8....750d75cf2b18b7140aeef16fc90d6f7eaed4a376.zip

Cheers
[Google Chromecast] mcpdigital:
Yes, feel free to host it. This is a joint effort.

MCP
[Google Chromecast] oppy:
Good idea - I went ahead and grabbed them just in case. I was hoping they'd stay active for a bit, so I can avoid the extra step of setting up a web server, but it's not a huge deal either way.
[Google Chromecast] ZaneChua:
Just so it doesn't affect you mcpdigital.

I made a hosted version.

To install this, all you need to do is SSH/Telnet into an already rooted Chromecast, and run the following commands:

busybox wget http://chromecastfix.centralus.cloudapp.azure.com/install.sh -O /cache/install.sh
busybox chmod +x /cache/install.sh
/cache/install.sh
[Google Chromecast] theronkinator:
I'm still on:

Build Version: 44433.001 (11/11/2015) w/ web portal

I thought I might finally update but I've come on and seen loads or problems, is it worth it or should I wait, is the post above the best way and is this a temp fix that could fail again in the future? Will Team Eureka fix this?

Thanks.
[Google Chromecast] ghowse:
84839 seems to be working fine for me but I guess everyone is waiting for the next Google OTA update to see if it breaks again.

However, if you still have the hubcap-flashcast image and OTG cable, I think you can revert to the web portal version. I don't think the Teensy is needed. I kept everything and was able to re-do the whole process.

Cheers

Geoff
[Google Chromecast] Asphyx:
Well chances are good it will break at the next OTA but as long as we can continue to use the old boot.img we will probably be able to update.

Just have to go through the same thing again. Hopefully we can find a way to fix Autoroot to work with the new boot they are using.
[Google Chromecast] ghowse:
Hi Asphyx

I would like to thank you and all those who are still supporting Flashcast. It is much appreciated.

Cheers

Geoff
[Google Chromecast] Asphyx:
Thanks should go to [MENTION=4793015]mcpdigital[/MENTION] and [MENTION=2690092]ZaneChua[/MENTION] for actually coming up with the fix and hosting it so Autoroot could work!
[Google Chromecast] ghowse:
Thanks to everyone involved. Come to Australia and I'll buy you a beer!

Cheers

Geoff
[Google Chromecast] bhiga:
For those who want/need the files, I've put them on my AFH

Note: You will need to put this on your own

web

server and modify the wget telnet commands. .

autoroot-recovery-r02.img

https://www.androidfilehost.com/?fid=745425885120728526

ota.84839.stable-channel.eureka-b3.750d75cf2b18b7140aeef16fc90d6f7eaed4a376.zip

https://www.androidfilehost.com/?fid=817550096634766198

autoroot-recovery-r02.img

https://www.androidfilehost.com/?fid=745425885120728526
[Google Chromecast] oppy:
Okay, if my CC is rooted but currently broken because of the update, do I need to do a clean eureka install first? Not sure how to SSH/Telnet into it if it's non-functional.
[Google Chromecast] Mad07:
Yes, you're right
[Google Chromecast] ghowse:
This is the same situation I was in. I repeated the original rooting procedure with the Teensy, then flashed the Flashcast image from a USB drive via the OTG cable. This restored the web panel and allowed me to log in with PuTty and run the commands.

Note that I don't think the Teensy step was actually required - I think the image would have flashed to the CC just by powering up with the USB drive connected.

Good luck.

Geoff
[Google Chromecast] oppy:
Okay, that's what I figured - thanks! Now, to dig up that OTG cable... ;)
[Google Chromecast] Rooksx:
I tried this from a Eureka-rom that I let update to 44433, but after the third line I get this error: "md5sum: WARNING: 1 of 1 computed checksums did NOT match

AutoRoot-Recovery: Failed to verify, Exiting..."

Could this be because I have a non-US version of the Chromecast or am I just doing something wrong?
[Google Chromecast] Asphyx:
You don't need the Teensy at all...Just the Image from the Hubcap zip on a USB drive....

Install Eureka, Then run autoroot.
[Google Chromecast] oppy:
Thanks. Yeah, I figured that was the case. Of course, my powered OTG cable is nowhere to be found. Ordered a new one, so I'll just hold off for a couple days.
[Google Chromecast] Asphyx:
Yeah it tough to keep track of all the cables I know I got Bins of them laying around! LOL

The Teensy was only needed to get access for the initial root exploit...

Once that has been done one you really have no need for the Teensy other than playing around with all the other fun stuff you can do with it.

I can't tell you how many account passwords that user forgot I have solved with that handy little device!
[Google Chromecast] KenMacD:
Looks to me like the checksum file (http://chromecastfix.centralus.cloudapp.azure.com/autoroot-recovery-r02.img.md5) just contains 'hi'.
[Google Chromecast] oppy:
Hmm good to know. Guess I'll check it out!
[Google Chromecast] ZaneChua:
Woops. Let me fix that when I get back. Must have missed that.

---------- Post added at 01:20 PM ---------- Previous post was at 01:04 PM ----------

Fixed!

---------- Post added at 01:21 PM ---------- Previous post was at 01:20 PM ----------

Should have quoted you. Fixed issue
[Google Chromecast] Rooksx:
Works perfectly, thanks very much.

---------- Post added at 08:14 PM ---------- Previous post was at 08:06 PM ----------

Although it looks like the latest firmware has toughened up the region-blocking measures. Before I only had to set my router's DNS to a smart DNS, but that doesn't seem to be working now. Will try setting up static routes later.
[Google Chromecast] ZaneChua:
If I'm not wrong, you have to create a configuration file to set the dns. The front page info still applies.
[Google Chromecast] Rooksx:
I did that but still no joy. In fact, the Smart DNS previously worked on a Chromecast that didn't have the file as well as one that did after setting the router to a custom DNS.
[Google Chromecast] silverwings2008:
Looking for some assistance please. Been getting the same black screen and chromecast...

Unfortunately the hosted file by Zane Chua doesn't work for me, I assume its US firmware. I need GB (UK) firmware. From autoroot it keeps updating itself to the new firmware and stops working each time.

Has anyone got the link for this firmware so I can busy box it to the chromecast. I don't mind if I loose autoroot, so I could just go stock.
[Google Chromecast] ZaneChua:
It doesn't work for you? What region is your Chromecast?

PM me, i can help you with this.
[Google Chromecast] m4f1050:
Is the first busybox supposed to download index.html???

EDIT: Nevermind, had to scroll to the right more...

BUT I am getting an error...
[Google Chromecast] ghowse:
I also saw an error and I believe this is normal. Your flash was successful and everything should be OK.
[Google Chromecast] ethanhunteg:
So this was my experience going from "Chromecast..." or the flashcast screen with solid red to being fixed on 1.23.84839

1. Make a usb drive with this hubcap image (i used Win32 Disk Imager on windows) http://download.gtvhacker.com/file/chromecast/HubCap.zip

2. Use the OTG setup here to flash https://xdaforums.com/showthread.php?t=2465642 (if you have the actual OTG+power cable that works too). Essentially I had this ready, and held the button while applying power and it started flashing white on the flashcast screen

3. When it boots up it will be on 17977 - At this point I unplugged the flash drive from the hub and I gave it a few minutes and it updated to 44333 ( you can check in google home app https://support.google.com/chromecast/answer/7124014?hl=en&ref_topic=3447927 )

4. I made sure my USB drive was unplugged then once on 44333 I telnet in and ran the 3 commands from ZaneChua found here https://xdaforums.com/showpost.php?p=72105277&postcount=219

5. It ran through the upgrade for about 10 minutes, rebooting to the flashcast screen for a few minutes of it.

6. On reboot it was on 1.23.84839

Thank you!
[Google Chromecast] Pietplezier:
My chromecast is also stuck on "Chromecast..." or the eureka flashcast screen. If i follow your steps, do i keep root?
[Google Chromecast] Asphyx:
Yes...
[Google Chromecast] m4f1050:
Well, I am now getting "Chromecast..." at the bottom on a black screen, all I can do is reflash Eureka. I tried several times to do this with no-go... I guess I will keep this Chromecast with Eureka... My other 3 Chromecasts are working fine.
[Google Chromecast] Asphyx:
Solutions for new autoroot temporary fix to latest is available a few pages before this one...
[Google Chromecast] m4f1050:
I'm seeing a couple different solutions, which one is the legit and won't lose root or telnet?
[Google Chromecast] Asphyx:
None will lose root...But I suggest you use the latest one that someone used and worked....

Even if you try one that fails, Root is still there and you can reflash the Hubcap image to try another.
[Google Chromecast] oppy:
OTG finally showed up today. Worked like a champ! Thanks for the fix - hopefully, someone comes up with a permanent version before the next update!
[Google Chromecast] ddggttff3:
I will take a look into this over the next day or so and see if I can get a fix out, or find a way around the issue.

EDIT: I believe I found a method to fix this, will update if/when the fix is deployed.

EDIT2: Sadly I was unable to find a way to fix this, it looks like the new bootloader uses a new kernel layout, or has some check in the kernel and not initramfs preventing boot :( Until a GPL is out for release 1.23 I can't verify this or really dig for any potential workaround.
[Google Chromecast] KenMacD:
hackmd for chromecast notes

I stared poking at these images, so I've created an online document for notes. It'd editable by anyone, so please feel free to add anything interesting that could help.

So far I've only extracted them and diffed a few things.

https://hackmd.io/EYYwbAhgZiBMUFoCssAmBOBAWMtgIllgEYEBmJMADmKgAYRUBTYpoA==?both

Hopefully useful for: [MENTION=2690092]ZaneChua[/MENTION], [MENTION=2212097]ddggttff3[/MENTION], [MENTION=4793015]mcpdigital[/MENTION]
[Google Chromecast] Asphyx:
Interesting stuff there...But I'm not convinced the signing of the System.img is a problem since we were able to install it with the old boot.img in the hack that was made. That would really mean the issue is somewhere in the boot.img. You did find some new things in there (init.rc) that might be the cause.
[Google Chromecast] KenMacD:
That sounds right to me though. The new boot.img is the one to check the signature, so it would make sense that you'd be able to install and use the new system.img (or any system.img) with the old boot.img. You just can't (yet) use any system.img with the new boot.img.

Right? Or did I miss something?
[Google Chromecast] Asphyx:
I am more engineer than coder...But it doesn't make much sense that the boot.img would only work for one particular system.img unless there was some major reason to do so.

What catches my eye is the 68c74 diff you noted in init.rc

68c74
< mount squashfs mtd@rootfs /system ro nodev noatime
---
> mount squashfs /dev/mapper/system /system ro nodev noatime

That looks to me like System is being mounted from a different location than previous (which would explain the dmtable change as well).

If i had to make my best guess, that mounting of system is failing and that's why we get hung up.

Technically the Unit boots, but it seems to stall right around the time it would load system. I'm guessing because it never got mounted properly.

The Old bootloader works because it simply uses the system.img the same way it did before so it can find it when it comes time to mount it.

So something about where the new boot.img puts things and maps the device is not compatible with Autoroot.
[Google Chromecast] KenMacD:
I think maybe you're missing how it works. It's the boot.img that checks the hash of the system.img, the system.img doesn't/can't check it's own signature.

In the new boot image when the 'dmsetup' is called it creates `/dev/mapper/system`, but it only does this if the signature matches. If the signature doesn't match (because autoroot modified it) then it does not have a rootfs to use and will not boot.

This is to create a chain of trust. It seems previously that the bootloader would check boot, but then the boot would not check the system. They improved the chain now by having boot check system. This means if you had a non-rootable chromecast and decided to pull the chip and write something to system you still couldn't get that code to run.

So that 'something about' is that now boot checks the signature of system, whereas the old boot just mounts anything.
[Google Chromecast] Asphyx:
But the system.img is signed, comes straight from google.

I haven't seen anything that suggests Autoroot changes system.img in any way.

So it should not fail a sig check at all...Unless the boot.img can't find the system.img file in the first place.

And that would be what I put my money on.
[Google Chromecast] johanneswilm:
I don't have my OTG cable around right now (moving). But if I plug and unplug the power, I get 4-5 small dots on the screen. Doing this a second time, I get the flashcast/Team Eureka update screen. And I can SSH into flashcast. In flashcast there is a program flash_mtd_partition, which seems to be similar to flash_image. But even though it seemingly me accepts me flashing the recovery petition, in the end it doesn't make the "Chromecast..." screen go away. Any ideas on how to do this with flashcast, or do I simply have to go via the OTG cable?
[Google Chromecast] ddggttff3:
Autoroot has to modify system.img, how else would it enable telnet, add busybox, and add the other features? ;)
[Google Chromecast] Asphyx:
I stand corrected then...

But wouldn't it make more sense to add those modifications after the system.img was written to the device?
[Google Chromecast] Rooksx:
Set up the static routes. Now the Chromecast says it cannot connect to the internet. VPN may be the only option for accessing content from different regions.
[Google Chromecast] tdhite:
I've been messing around with my 'black screen of death' Chromecast for a while and notice two things:

1) I don't have a USB hub any more, sheesh -- feels like 1920s to go get one ( ;) );

2) If you power down/up quickly, once every so often the Chromecast boots up to flashCast 'update' screen. That is enough 'recovery' to do things, namely SSH in with root/letmein.

That tells me we should be able to update the CC by just running the updater in the zip provided in earlier posts for the OTA. Why is that not the case? I have to admit, I've not tried quite yet (went on a long hunt through attic boxes looking for a 1863 vintage USB hub).

Anyway, what I really need to test this is a fstab set that shows /cache, /system, etc. I don't know off hand the devices (/dev/???) and where their mountpoints are. I should be able to mount anything I want in the flashCast 'recovery' updater (it's all running fine -- just the update screen on the TV, but who cares).

Thoughts?
[Google Chromecast] ZaneChua:
I think you're mistaken about how autoroot works. [MENTION=5427201]KenMacD[/MENTION] has given you a really detailed explanation about why this fails.

Even if you "write" something after the system.img was written to the device, you would still be breaking the chain of trust because you just modified the system. I believe the boot partition checks the system partition for any modifications by generating a hash of some sort and if that hash is different than what it originally is supposed to be therefore it fails. I don't think you can look at it in terms of .img files.

---------- Post added at 07:34 PM ---------- Previous post was at 07:32 PM ----------

What are you trying to do?
[Google Chromecast] tdhite:
Trying to apply the current fix without OTG (I believe you posted it) after fixing it up to use scp for copying the files to /tmp and /cache as appropriate. Have to mount /data and /cache for space, but they are not mounted in the update mode.

Best case it seems possible the OTA could be applied in the update mode as one would normally run a zip flash within a flash. That is, unzip it (need space) and run the update-binary directly from the unzipped files. That would be just one (last) remote ssh command.
[Google Chromecast] ZaneChua:
The OTG is actually only necessary for installing a clean version of Eureka. It's not required at all for the "fix" so theoretically if you could get SSH access then it should be fairly easy to adjust the commands and get it working.

But of course buying an OTG cable to have on hand really is just a few dollars.
[Google Chromecast] tdhite:
Lol. OTG I have aplenty. USB hub, not so much. As for the command adjustment, agreed, I just need the /dev/mtd??? to mount point maps if anyone has it. The OTA is large enough to need at least /data or /cache.
[Google Chromecast] ZaneChua:
The OTG Cable I'm referring to is this : http://www.ebay.com/itm/201486975349

I think someone posted something before. Can't advise you on the actual commands at the moment though.
[Google Chromecast] Lizard:
Well, if magisk would exist for the chromecast, it might be possible. ;)
[Google Chromecast] Asphyx:
So basically the only solution is to replace the boot.img (which is also signed I presume) with either the old one or hack the signing after modifying the new boot.img...

Sounds an awful lot like we will all be moving back to stock soon.
[Google Chromecast] strifej:
I wrote this in the return to stock thread, but looking for more feedback. Don't wnat to clutter forum with new threads and you peeps are the best to ask :)

***

I found a chromecast I bought before (refurb Groupon from a few years back) and see it's firmware 15098. so, it's still rootable by hubcap. From what I've been reading, not much point to root anymore? I can order a teensy clone (very cheap) and otg and root it.. but just wondering if there are any more compelling reasons to do so?

I only plan to stream local media (from laptop/phone) to tv.. nothing else. Don't even watch netflix (don't have account).

Should I just let it update to latest official and forget about root too?
[Google Chromecast] Pietplezier:
Working chromecast again, thanks!
[Google Chromecast] Asphyx:
I would hold onto it and not do anything until a permanent solution is found for the Autoroot situation.

Finding a rootable unit is rare these days and while having root at this point doesn't seem like much of a boon other than bragging rights, you never know what will happen with the unit years down the road.

But if Autoroot can't be fixed then it makes sense to just let it go and stay stock. As I write this there really isn't anything gained by having root. But you never know, tomorrow someone could post here and change that.

I would keep that unit in the box and not power it up until the Autoroot situation is clear.

Or root it with the knowledge that in two months time you may have no choice but to go back to stock because Google beat the Autoroot system.

I had a ton of fun playing with the Teensy outside of just rooting my CCast so getting and rooting the unit sure can't hurt it. But if Autoroot can't be fixed and Google adds some capability in a future update we can't get around to install, then it will all be for naught. And we will have to go back to stock to get those features.
[Google Chromecast] ghowse:
I'm just wondering why Google has bothered to put a spanner in the works of Autoroot - or even if it was their intention. With such a small percentage of the Chromecast universe being rooted, it seems unlikely that they would see the need to devote resources to blocking Autoroot. Maybe it was just some security improvement they introduced into the update system that coincidentally borked Autoroot?
[Google Chromecast] Asphyx:
I doubt they even knew what they would do...

They just got some new programmer who dotted an I and crossed a T for this update would be my first guess.
[Google Chromecast] bhiga:
+1 to Asphyx's comment. Google made a change and it just so happened to be incompatible with what autoroot does to hack the update.

Once the source is public we'll know if autoroot can be made to work.

If it's just the partition layout, I doubt big G will go messing with that in every update just to mess with the tiny percentage of rooted units.
[Google Chromecast] kekos321:
i have the same problem.....the thing is i need to return to stock rom from Google....any help on this ?

Thanks !
[Google Chromecast] Asphyx:
Worst case scenario I see here is a different approach will be required (and need to be coded) to install...

We know simply replacing the boot.img with the old allows it to install the system so additional code to replace the boot.img at the same time it changes the system.img might work. I assume something checks the signing of the boot.img as well so that may only work for so long or until something needed in the newer boot.img is required to make the new system.img work.

For the measly price of a new CCast I don't see a big issue with not having root or having a rooted CCast that needs special attention when updates arrive...

I'll just go buy a new unit to use until a solution is found and use the rooted one for playing around and hacking use.
[Google Chromecast] Asphyx:
Question for someone with a netflix account and a Rooted CCast....

Has your Netflix service stopped working? Apparently they are now blocking rooted devices from access which might explain why this release has a tighter lock on it than previously...I say that because I note that a new keystore for netflix was added to the boot.img

As noted in Ken's Diff comparison...

> # set KEYSTORE for cast_crypto_keys_marvell.cc
> export KEYSTORE /data/netflix/AACS
>
[Google Chromecast] ghowse:
Yes, 84839 still working fine.
[Google Chromecast] adammw:
So, in this spirit, I wanted to try modifying the new boot.img to modify the way it mounts the system back to the old way (or alternatively still via device mapper but without the verity module so it does not integrity checking). I unpacked a boot.img using unpackbootimg from mkbootimg and tried repacking it without any modification to see if the tooling can at least get a bootable image. Diffing it with the original boot.img shows that I probably didn't have the arguments right as the cmdline was stored at a different hex offset, but I tried anyway. I used cc-mangle-bootimg (assuming that it's required as a second step after mkbootimg) but it seems that I still don't have the right steps, rebooting still shows the "Chromecast..." screen, only this time it's flickering.

[MENTION=744716]Asphyx[/MENTION] [MENTION=2212097]ddggttff3[/MENTION] [MENTION=5427201]KenMacD[/MENTION] - any idea how to generate a bootable boot.img (and/or modify the official one from 84839)?

My thinking is also if somehow we can modify the later boot.img to correctly mount the system without verification we can potentially get it working again reliably. Or at least install further debugging into the initramfs so we can work out what's going wrong.

---------- Post added at 01:13 AM ---------- Previous post was at 12:24 AM ----------

Also.. seems like bad news incoming.. after updating to 84839 with kernel from 80438, I got a new ota from Google, 88007. This one seems to not work with the older kernel and stays on the "Chromecast..." screen. I couldn't capture the original ota url but I copied the zip off if anyone wants to see what's changed: https://mega.nz/#!x34zVKzA!1Do37qYyXUUwcAAV0uIFQ4brADucgkKBdjdkdn_mLuw