[ROM] [r02 - 2015-12-13] Flashcast-AutoRoot

Search This thread

metterschling

Senior Member
Before I send you the files/instruction, do you know whether you have adb enabled on regular boot on your rooted chromecast? That would be the easiest way to transfer the needed files to your rooted chromecast's /data/ folder.

Another method is to reboot to flashcast and transfer it while in flashcast.
Yes, ADB is enabled in the rooted CC (still at last Eureka release 44433.001) and I can successfully connect and adb shell into it.

Update: ADB is not really required if you start from the Eureka 44433 release as you can always easily set up a http server with for example "python3 -m http.server 8000" somewhere on a PC and then use "busybox wget ..." (busybox is included on that release) to pull the files on your CC.
In the meanwhile I copied your loopmount.sh script to /cache on the CC, then downloaded the 159268 OTA to a PC and extracted it ... now waiting for your instructions to get/build the modified initrd.sqfs and system.sqfs. I'd prefer a script to create them myself rather than binaries, but that is your choice.

Update2: Played around a bit, generating unmodified system and initrd sqashfs images on my PC to test the process:
Code:
# prereqs
sudo apt install abootimg
git clone https://github.com/ReFirmLabs/binwalk
cd binwalk/
sudo python3 ./setup.py install
# real stuff
mkdir -p ~/tmp/chromecast
cd ~/tmp/chromecast
./adb push ~/tmp/loopmount.sh /cache/
wget http://redirector.gvt1.com/edgedl/googletv-eureka/stable-channel/ota.159268.stable-channel.eureka-b3.adf9f4e6b7ad7068e5f85dbb375236d5d933031b.zip
binwalk -e ota.159268.stable-channel.eureka-b3.adf9f4e6b7ad7068e5f85dbb375236d5d933031b.zip 
cd _ota.159268.stable-channel.eureka-b3.adf9f4e6b7ad7068e5f85dbb375236d5d933031b.zip.extracted/
# get the system image
file system.img 
binwalk -e system.img 
cd _system.img.extracted/squashfs-root/
mksquashfs . ~/tmp/chromecast/system.sqfs -all-root
# test system image
sudo mount -t squashfs -o loop ~/tmp/system.sqfs /mnt/
sudo umount /mnt/
# Now get the initrd
binwalk -e boot.img 
dd bs=256 skip=1 if=boot.img of=~/tmp/chromecast/aboot.img
cd ~/tmp/chromecast/
abootimg -x aboot.img 
file initrd.img 
mkdir rd
cd rd/
xz -d -c ../initrd.img | cpio -i -d -H newc --no-absolute-filenames
mksquashfs . ~/tmp/chromecast/initrd.sqfs -all-root
# test initrd image
sudo mount -t squashfs -o loop initrd.sqfs /mnt/
sudo umount /mnt/
Copied the images to the CC and executed the loopback.sh script. At first run I recognized that the sequence is wrong, as soon as system mount is overloaded, busybox is no longer available. So corrected loopmount.sh looks like:
Code:
#!/bin/sh
/chrome/cast_cli stop cast
mkdir -p /initrd
busybox mount -o loop,ro /cache/initrd.sqfs /initrd
busybox mount -o bind /initrd/lib /lib
busybox mount -o bind /initrd/sbin /sbin
busybox mount -o loop,ro /cache/system.sqfs /system
# cp -a /initrd/root/* /. #### this step is optional
start cast_receiver
Result: CC was still working a minute or so after the script ran, but then the screen turned black and CC was no longer reachable from Google Home app. Shell login (here: adb shell) still was there, so issued a reboot to verify that nothing is broken. After reboot CC came back up successfully so indeed nothing is broken permanently as expected.
So finally I only need your tweaks to the squashfs images for another attempt ;)
 
Last edited:

morchu

Member
Mar 13, 2009
43
15
Try this :

https://drive.google.com/file/d/14zOVskgL4Eo_hxIbl3LJe9VHb9HOXZV5/view
https://drive.google.com/file/d/1HPKz5oRtJ4rWduINUkZCc54dEUFxEW8J/view

Second file is a readme. You want to upload (via adb is easiest) and untar the first file which contains the modified system squashfs and initird squashfs into /data/. This should create a directory /data/newsys in the chromecast. All needed files are in there. The script you want to execute is /data/newsys/newsys.sh

Let me know how it works out.

If this works and gives a stable chromecast in latest system for at least 30 minutes, then we can always restart other services.

One thing to note is that probably the dropbear executable compiled with Eureka may not be compatable with the new libc files. So you may want to execute the dropbear/ssh before executing the loopmount script, if you ever make the script execution automatic. But this is not an issue when doing the script execution manually.


Yes, ADB is enabled in the rooted CC (still at last Eureka release 44433.001) and I can successfully connect and adb shell into it.

Update: ADB is not really required if you start from the Eureka 44433 release as you can always easily set up a http server with for example "python3 -m http.server 8000" somewhere on a PC and then use "busybox wget ..." (busybox is included on that release) to pull the files on your CC.
In the meanwhile I copied your loopmount.sh script to /cache on the CC, then downloaded the 159268 OTA to a PC and extracted it ... now waiting for your instructions to get/build the modified initrd.sqfs and system.sqfs. I'd prefer a script to create them myself rather than binaries, but that is your choice.

Update2: Played around a bit, generating unmodified system and initrd sqashfs images on my PC to test the process:
Code:
# prereqs
sudo apt install abootimg
git clone https://github.com/ReFirmLabs/binwalk
cd binwalk/
sudo python3 ./setup.py install
# real stuff
mkdir -p ~/tmp/chromecast
cd ~/tmp/chromecast
./adb push ~/tmp/loopmount.sh /cache/
wget http://redirector.gvt1.com/edgedl/googletv-eureka/stable-channel/ota.159268.stable-channel.eureka-b3.adf9f4e6b7ad7068e5f85dbb375236d5d933031b.zip
binwalk -e ota.159268.stable-channel.eureka-b3.adf9f4e6b7ad7068e5f85dbb375236d5d933031b.zip 
cd _ota.159268.stable-channel.eureka-b3.adf9f4e6b7ad7068e5f85dbb375236d5d933031b.zip.extracted/
# get the system image
file system.img 
binwalk -e system.img 
cd _system.img.extracted/squashfs-root/
mksquashfs . ~/tmp/chromecast/system.sqfs -all-root
# test system image
sudo mount -t squashfs -o loop ~/tmp/system.sqfs /mnt/
sudo umount /mnt/
# Now get the initrd
binwalk -e boot.img 
dd bs=256 skip=1 if=boot.img of=~/tmp/chromecast/aboot.img
cd ~/tmp/chromecast/
abootimg -x aboot.img 
file initrd.img 
mkdir rd
cd rd/
xz -d -c ../initrd.img | cpio -i -d -H newc --no-absolute-filenames
mksquashfs . ~/tmp/chromecast/initrd.sqfs -all-root
# test initrd image
sudo mount -t squashfs -o loop initrd.sqfs /mnt/
sudo umount /mnt/
Copied the images to the CC and executed the loopback.sh script. At first run I recognized that the sequence is wrong, as soon as system mount is overloaded, busybox is no longer available. So corrected loopmount.sh looks like:
Code:
#!/bin/sh
/chrome/cast_cli stop cast
mkdir -p /initrd
busybox mount -o loop,ro /cache/initrd.sqfs /initrd
busybox mount -o bind /initrd/lib /lib
busybox mount -o bind /initrd/sbin /sbin
busybox mount -o loop,ro /cache/system.sqfs /system
# cp -a /initrd/root/* /. #### this step is optional
start cast_receiver
Result: CC was still working a minute or so after the script ran, but then the screen turned black and CC was no longer reachable from Google Home app. Shell login (here: adb shell) still was there, so issued a reboot to verify that nothing is broken. After reboot CC came back up successfully so indeed nothing is broken permanently as expected.
So finally I only need your tweaks to the squashfs images for another attempt ;)
 

Attachments

  • readme.txt
    353 bytes · Views: 36
Last edited:

morchu

Member
Mar 13, 2009
43
15
i do not think it matters as much on which version of system and boot image you are currently running, to use the above loopmounts over and use latest system, as long as it is rooted (so that you can login and run the scripts). But it may work better with the latest version possible in the system/boot. I beleieve this was 80438 , which was the last version of bootimage which did not had internal key checks. After that Ken made a rooted version of 124602 using an older Eureka kernel. I am not sure which one works better.

The reason is the service definishions in the init.rc is already loaded to kernel memory before you execute any loopmounts, also there is a watchdog running monitoring the application /bin/PE_Single_CPU. So technically even though you can restart every other service from new system, you cannot restart the PE_Single_CPU binary using the above method.

But chromecasts main function.... which is casting is maintained by other binaries (mainly cast application). So I would think it should still functiion properly.
 
Last edited:
  • Like
Reactions: metterschling

metterschling

Senior Member
Tried the process today.
The adb command sequence needs to be modified to
Code:
adb push newsys.tar.gz /data/.
adb shell 'cd /data && busybox tar -zxf newsys.tar.gz'
adb shell '/data/newsys/newsys.sh'
So this is running and the CC still stays alive, and I can confirm that the re-mounts are being performed.
The last command terminates with the following message:
Code:
./adb shell  '/data/newsys/newsys.sh'
[0508/162642:ERROR:cast_cli.cc(480)] failed to stop process_manager; manually deleting pidfile: pid=778
[0508/162642.903771:ERROR:package_utils.cc(432)] Cannot read PID of process manager: path=/tmp/process_manager.pid
however I can see additional tasks in the ps output that were not present before starting the script:
Code:
 1265 1000       0:00 /bin/logwrapper /chrome/cast_cli start cast async --register-pepper-plugins=/system/chrome/plugins/libspotify.so;application/x-spotify
 1266 1000       0:00 /chrome/cast_cli start cast async --register-pepper-plugins=/system/chrome/plugins/libspotify.so;application/x-spotify
Unfortunately I don't see any difference functionality-wise. Google Home still reports 1.16.44433.
The following processes were not impacted by the script:
Code:
  762 1000       0:00 /bin/logwrapper /system/chrome/process_manager --async --register-pepper-plugins=/system/chrome/plugins/libspotify.so;application/x-spotify
  763 1000       0:00 /system/chrome/process_manager --async --register-pepper-plugins=/system/chrome/plugins/libspotify.so;application/x-spotify
so could it be the case that these still do the main work and the new cast_cli is ignored?
 

morchu

Member
Mar 13, 2009
43
15
What was the version of system/kernel you were running originally (before the loopmount of system)?

It appears like the original cast process was not stopped for whatever reason. There are ways to force kill it. Maybe you can try the steps in the shell script individually one at a time and make sure the original cast process was killed properly before doing to loopmounts and restarting of new cast process.


Tried the process today.
.........
so could it be the case that these still do the main work and the new cast_cli is ignored?


---------- Post added at 06:40 PM ---------- Previous post was at 06:19 PM ----------

Ohh I see you have listed it above. So you were using "1.16.44433."

Another local user had reported success with a rooted 80438 system with 1.22 kernel (1.22.80438), and doing loopmount on top of it, with the same exact script. I think that system/kernel combo rooted is in one of the xda threads. If I remember correct, that was the latest kernel /system combination with root builted and did not cause bricks.

But again, I do think it should still work with 1.16 kernel. It is probably just that you might have to stop a different service as well. Check the init.rc file in the root of your device to see the services started at run time. The hint is in the error message "failed to stop process_manager". So see what is the related service in there and see if you can stop that service gracefully.

I think only the PE_Single_CPU service/process is monitored by watchdog. So except that you can kill/restart other service. Even if you disturb the watchdog, the worst that can happen is a reboot.

It would be preferable to get it working on 1.16 kernel (so that no need to make any permanent changes).


What was the version of system/kernel you were running originally (before the loopmount of system)?

It appears like the original cast process was not stopped for whatever reason. There are ways to force kill it. Maybe you can try the steps in the shell script individually one at a time and make sure the original cast process was killed properly before doing to loopmounts and restarting of new cast process.
 
  • Like
Reactions: metterschling

metterschling

Senior Member
It appears like the original cast process was not stopped for whatever reason. There are ways to force kill it. Maybe you can try the steps in the shell script individually one at a time and make sure the original cast process was killed properly before doing to loopmounts and restarting of new cast process.

But again, I do think it should still work with 1.16 kernel. It is probably just that you might have to stop a different service as well. Check the init.rc file in the root of your device to see the services started at run time. The hint is in the error message "failed to stop process_manager". So see what is the related service in there and see if you can stop that service gracefully.

I think only the PE_Single_CPU service/process is monitored by watchdog. So except that you can kill/restart other service. Even if you disturb the watchdog, the worst that can happen is a reboot.

It would be preferable to get it working on 1.16 kernel (so that no need to make any permanent changes).
You are right, executing the steps manually resulted in
Code:
# The stop at the beginning of the script
/chrome/cast_cli stop cast
/chrome/cast_cli: error while loading shared libraries: libcutils.so: cannot open shared object file: No such file or directory
# The stop at the end of the script
/chrome/cast_cli stop cast
[0515/144601.702682:ERROR:cast_cli.cc(564)] Timeout stopping process_manager at pid '765'. Please try again or manually clean package
echo $?
10
# So I waited a couple of seconds, then re-tried
/chrome/cast_cli stop cast
[0515/144631.142633:INFO:cast_cli.cc(586)] Successfully stopped process_manager at pid 765 in 10451 ms
echo $?
0
So if I start cast_receiver afterwards, I can report partial success. Google home is reporting 1.36.159268.
Unfortunately casting does not work, Google home is stuck forever "connecting", other apps start casting then drop back to disconnected state before playback starts.
So the script needs to be changed to wait for the proper exit code - this one works for me:
Code:
cat /data/newsys/newsys.sh
#!/data/newsys/busybox sh

/chrome/cast_cli stop cast

if /data/newsys/busybox test ! -f /initrd/root/build.prop; then
/data/newsys/busybox mkdir -p /initrd
/data/newsys/busybox mount -o loop,ro /data/newsys/initrd.sqfs /initrd
/data/newsys/busybox mount -o bind /initrd/sbin /sbin
/data/newsys/busybox mount -o bind /initrd/lib /lib
/data/newsys/busybox mount -o loop,ro /data/newsys/system.sqfs /system
#/data/newsys/busybox cp -a /initrd/root/* /.
fi

for i in `seq 0 9`; do
  /chrome/cast_cli stop cast
  if [ $? -eq 0 ]; then
    break;
  fi
  sleep 1
done
start cast_receiver
 
Last edited:
  • Like
Reactions: onyx1337

morchu

Member
Mar 13, 2009
43
15
The message "error while loading shared libraries" while trying to stop the cast process indicates the issue.
Really the old cast process should be stopped "BEFORE" the loop mounts, since the libraries changed after the loopmount.

So to exit the process more elegantly, maybe add the wait before the loop mounts, and make sure the old cast process exited before even starting the loop mounts.

Another thing you can try is the command
"stop cast_receiver"

This should also stop the defined cast_receiver service, which has the cast binary process defined in init.rc

Either way, not having the error code on stopping the cast process to guarantee an elegant exit would make sure there are no memory leaks.

But I am glad that you got it working.



You are right, executing the steps manually resulted in
Code:
# The stop at the beginning of the script
/chrome/cast_cli stop cast
/chrome/cast_cli: error while loading shared libraries: libcutils.so: cannot open shared object file: No such file or directory
# The stop at the end of the script
/chrome/cast_cli stop cast
[0515/144601.702682:ERROR:cast_cli.cc(564)] Timeout stopping process_manager at pid '765'. Please try again or manually clean package
echo $?
10
# So I waited a couple of seconds, then re-tried
/chrome/cast_cli stop cast
[0515/144631.142633:INFO:cast_cli.cc(586)] Successfully stopped process_manager at pid 765 in 10451 ms
echo $?
0
So if I start cast_receiver afterwards, I can report partial success. Google home is reporting 1.36.159268.
Unfortunately casting does not work, Google home is stuck forever "connecting", other apps start casting then drop back to disconnected state before playback starts.
So the script needs to be changed to wait for the proper exit code - this one works for me:
Code:
cat /data/newsys/newsys.sh
#!/data/newsys/busybox sh

/chrome/cast_cli stop cast

if /data/newsys/busybox test ! -f /initrd/root/build.prop; then
/data/newsys/busybox mkdir -p /initrd
/data/newsys/busybox mount -o loop,ro /data/newsys/initrd.sqfs /initrd
/data/newsys/busybox mount -o bind /initrd/sbin /sbin
/data/newsys/busybox mount -o bind /initrd/lib /lib
/data/newsys/busybox mount -o loop,ro /data/newsys/system.sqfs /system
#/data/newsys/busybox cp -a /initrd/root/* /.
fi

for i in `seq 0 9`; do
  /chrome/cast_cli stop cast
  if [ $? -eq 0 ]; then
    break;
  fi
  sleep 1
done
start cast_receiver
 
  • Like
Reactions: onyx1337

onyx1337

Member
Jan 23, 2013
9
2
Hi, guys decide to upgrade my cc from 44433.001 [2015-11-15] Eureka-ROM to something new to make spotify work.
I tried several steps from latest messages, but faced issue. Please help me.

so I tried firmware from @morchu

with changes from @metterschling
cat /data/newsys/newsys.sh
#!/data/newsys/busybox sh

/chrome/cast_cli stop cast

if /data/newsys/busybox test ! -f /initrd/root/build.prop; then
/data/newsys/busybox mkdir -p /initrd
/data/newsys/busybox mount -o loop,ro /data/newsys/initrd.sqfs /initrd
/data/newsys/busybox mount -o bind /initrd/sbin /sbin
/data/newsys/busybox mount -o bind /initrd/lib /lib
/data/newsys/busybox mount -o loop,ro /data/newsys/system.sqfs /system
#/data/newsys/busybox cp -a /initrd/root/* /.
fi

for i in `seq 0 9`; do
/chrome/cast_cli stop cast
if [ $? -eq 0 ]; then
break;
fi
sleep 1
done
start cast_receiver

But something go wrong. It seems that flashed but after reboot nothing changed (spotify and other apps still doesn't work) and now in phone in chromcast settings I get next message 'Device is invalid or out of date. Please wait for software update to install or factory reset'


P.S.: after I made factory reset through web interface , I had a chance to go into settings and find out that firmware still 1.16.444333, but then several minutes later it showed previous error .
 
Last edited:

metterschling

Senior Member
Note that the above method does not really flash anything, it just live patches the system, so all changes are lost after a re-boot. Also note that my last post might have been misleading as it includes "worked for me". That was referring to the patching process, not the overall result.

In short: I got the patching script running as described, but the overall result did not work, casting was not possible with the patched system. I gave up.
 
  • Like
Reactions: onyx1337

metterschling

Senior Member
Hi, finnaly I found needed cable, but can you help and show me where I can find how to return to stock firmware using FlashCast, because In thread I can't find reset tutorial
Take a look at this parallel thread and the FlashCast instructions linked there for instructions to go back to a working Eureka: https://forum.xda-developers.com/showthread.php?t=2578653
It is simply too long ago since I did it last time so I don't have the exact steps at the top of my head.
If you want to switch to stock and lose root forever, a search in one of these threads should reveal the instructions. I never did that, want to keep root access for my device.
 
  • Like
Reactions: onyx1337

Top Liked Posts

  • There are no posts matching your filters.
  • 34
    What is it?

    This is my final gift to the Chromecast community, called Flashcast-AutoRoot. This is a special recovery image for the Chomecast v1 device that will allow it to take official Google OTA's, and then root them during the flashing process. This means you get to keep root, while staying up to date with Google images!

    Features:

    • Auto roots any official Google OTA sent to your device
    • Supports automatic Recovery Image updates
    • Spawns a root telnet server
    • Supports a custom startup script
    • DHCP and Custom DNS
    Q and A:

    Q: How do I setup a custom startup script?

    A: Just write your script to a file at /data/user_boot_script.sh, and set the executable bit for the file. Once done, it will be loaded on next boot.

    Q: How do I setup custom DNS servers?

    A: Put the IP addresses of the DNS servers in a file at /data/dns.conf, one per line. On next boot these will be used for DNS requests. Note if you are coming from EurekaROM, it will already have your old settings in place. :)

    Q: How do I setup the EurekaROM Web Panel?

    A: By default this ROM has no Web Panel, but this can be added by bootstrapping onto the custom startup script, but I will leave this up to you. ;)

    Q: Can Google unroot my device in the future?

    A: Technically yes, but they would have a hard time doing so. To get technical, the bootloader partition can't be updated from the stock OS due to the kernel hard-setting it to "ro". While the recovery image can be flashed from the OS, the root process replaces the included recovery image with it's self to prevent any update. The recovery is also unable to update the bootloader partition, so you should always be able to re-flash using a OTG cable. With that said, I have also put in an update method so I can push updates to the recovery image if needed, but at this time I have no plans on doing so unless required, so use this image at your own risk.

    Installation:
    To install this, all you need to do is SSH/Telnet into an already rooted Chromecast, and run the following commands:
    Code:
    busybox wget http://pdl.team-eureka.com/recovery/install.sh -O /cache/install.sh
    busybox chmod +x /cache/install.sh
    /cache/install.sh
    Note:
    If this is ran on a different ROM than Eureka-ROM there may be an error when ran, but rest assured the flashing process will still work. :)

    GPL/Source:
    https://github.com/team-eureka/flashcast-flasher/tree/newmode-alpha
    15
    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.
    8
    Deleting, I think you already provided it with the boot.img from 1.22 if I understood correctly. Thanks

    ZaneChua, updated using the modded 1.23 with 1.22 Kernel. It worked, it is now on the 80438 version.
    Let´s hope the next update won´t mess with it again. Until then we have to wait.
    Just to clarify. I started with the Hubcap Eureka and then I took the risk and entered the commands only, no script no factory reset.
    Now it is easy to copy and paste to the telnet terminal.
    I will leave the file that I used in my server for a day so users can install. It is a small hosting plan so not that much bandwidth available.
    *** Remember, I did that and it worked, but I'm not responsible for any damage this can make to your CC ****
    An thanks to ZaneChua for finding the 1.22 Kernel (boot.img)
    Copy and Paste in you telnet:

    Code:
    busybox wget http://pdl.team-eureka.com/recovery/releases/autoroot-recovery-r02.img -O /data/temp/root-recovery.img
    busybox wget http://mcpdigital.com/android/ota.84839.stable-channel.eureka-b3.750d75cf2b18b7140aeef16fc90d6f7eaed4a376.zip -O /data/temp/ota.84839.stable-channel.eureka-b3.750d75cf2b18b7140aeef16fc90d6f7eaed4a376.zip
    busybox cp /data/temp/ota.84839.stable-channel.eureka-b3.750d75cf2b18b7140aeef16fc90d6f7eaed4a376.zip /cache/ota.zip
    flash_image --scan-all recovery /data/temp/root-recovery.img
    // *** WAIT FOR 5 SECONDS 
    reboot recovery
    Update: Did the same procedure in other 2 CCs.
    So now I went from stuck at Chromecast.... straight to the update:
    Step1: create a HubCap Eureka USB from image
    Step2: install the HubCap (OTG+USB, Reset Button, and Power) * no need to root CC again so it is like the second step of the original Eureka.
    Step3: wait until it updates itself from 17977 to 44333 , it shouldnt take long
    Step4: telnet your CC and run the busybox commands as showed by ZaneChua
    Step5: enjoy

    MCP
    6
    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:
    Code:
    busybox wget http://chromecastfix.centralus.cloudapp.azure.com/install.sh -O /cache/install.sh
    busybox chmod +x /cache/install.sh
    /cache/install.sh
    6
    That looks like it comes from Eureka and not Google....
    Is it as simple as maybe Eureka just got a bad copy of the firmware?
    Or have you tried that already?

    Did you see the link? It's from Google. Not Eureka. The chromecast device codename is eureka.


    Following adammw's suggestion.

    He didn't really give instructions or anything to help you do this though. Something in the boot.img has changed and therefore breaks autoroot. I decided to use the boot.img from 1.22.80438 to replace the original one in 1.23.84839.

    You need to reinstall eureka rom and be on a clean installation of eureka rom. Means you need to do a factory reset before you try any of the steps below.

    You can find the new OTA from: https://drive.google.com/open?id=0B3jenDHaF8AJMFZMbHVMNmFyeFE
    The script is slightly changed to : https://gist.github.com/zanechua/672f741de2add4186e59dd1973663305

    You still need to modify the script, host it on your own http server and modify the script accordingly.

    You could however do it manually but this may/may not break your chromecast. I'm not at fault here if you do.

    I HAVE NOT PERSONALLY TESTED THE FOLLOWING COMMANDS. THESE COMMANDS ARE FOR EXPERTS ONLY. IF YOU HAVE NO IDEA WHAT THESE COMMANDS DO, DO NOT DO IT. THIS CIRCUMVENTS A LOT OF CHECKS IN THE SCRIPT.

    The commands would be:
    busybox wget http://pdl.team-eureka.com/recovery/releases/autoroot-recovery-r02.img -O /data/temp/root-recovery.img
    busybox wget http://fromsomewhere/ota.84839.stable-channel.eureka-b3.750d75cf2b18b7140aeef16fc90d6f7eaed4a376.zip -O /data/temp/ota.84839.stable-channel.eureka-b3.750d75cf2b18b7140aeef16fc90d6f7eaed4a376.zip
    busybox cp /data/temp/ota.84839.stable-channel.eureka-b3.750d75cf2b18b7140aeef16fc90d6f7eaed4a376.zip /cache/ota.zip
    flash_image --scan-all recovery /data/temp/root-recovery.img
    (Wait 5 seconds after flashing of the recovery)
    reboot