FORUMS

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

801 posts
Thanks Meter: 1,534
 
By ddggttff3, Inactive Recognized Developer on 13th December 2015, 08:16 PM
Post Reply Email Thread
27th August 2018, 12:06 AM |#371  
Junior Member
Thanks Meter: 0
 
More
Quote:
Originally Posted by prefect472

Stupid me flashed this without reading the whole thread for possible issues ... I also got the "First block failed verification..." error and now my Chromecast (1st gen) is stuck on the "chromecast..." black screen and I can't ssh or telnet to it.
Since I was trying to get as close to non-rooted as I can I might as well unroot. Is there a way to trigger it to reflash the Google OTA? Or how would I do it? I rooted this years ago and barely succeeded so it might just be easier to go and buy a new one if extra hardware is required to unroot.

Edit: I can ssh and also get the "SETUP FAILED: Unsupported Mode! This version of Flashcast can only be ran from the recovery parition of the Chromecast."

I did the same thing, can't get flashcast to take on the usb stick, I'm stuck..
25th December 2018, 04:04 PM |#372  
Member
Thanks Meter: 6
 
More
Quote:
Originally Posted by ImCoKeMaN

I ran this on my eureka rom Chromecast last night and the script seemed successful and then said rebooting, I saw flashcast on my tv but now it just shows white "chromecast..." letters on a black screen. I had it plugged into power on the TV's usb port during the process is there a chance it needed more power during the flash and got corrupt? Any ideas to try to revive it?

I'm a bit late to this party, up til now my CC was working fine with my limited use of the Eureka ROM but I noticed that I couldn't cast from a tab in my laptop's Chrome browser. The Flashcast-AutoRoot method gives the same problems as above on the second reboot after the OTA update so I'm guessing there's an incompatibility with the downloaded OTA & the real OTA. I've had to revert back to stock firmware via this thread (post 58).
https://forum.xda-developers.com/sho...6&postcount=58


Quote:
Originally Posted by Mitsch79

Thx mate. Since autoroot doesn't seem to work with latest 1.24.88007 update for chromecast (it broke mine), reverting to stock is the only option to have a working streaming gadget

Cheers

The Following User Says Thank You to cancunia For This Useful Post: [ View ] Gift cancunia Ad-Free
22nd June 2019, 08:15 PM |#373  
Member
Thanks Meter: 15
 
More
I wish I documented the exact things I did on the boot image and system image last time. I failed to do that at that time and just tried to redo the same to document it for you folks. And ...... I bricked my toy (I guess I was overconfident, since I had done it before).

Essentially there is a chain of trust established from bootloader to bootimage to system image, and if you miss a small step anywhere in that chain.... the chain is broken and you have a brick. It is doable, but very risky, since the exact methods of this chain of trust may change from one image to other. Bootloader does not get modified much. But bootimage does, and with every new bootimage we have to assume there is a new method/too much risk.

So maybe at the top of this thread put a big warning in RED letters. Anyway most of us lost interest in this topic from 2015, and there are so much newer toys to play with now in 2019.


Quote:
Originally Posted by KenMacD

Hi @morchu. I've been trying to follow your work here, but with 104827. Have you tried this one? I haven't managed to make a boot image that'll actually boot.

When you have time could you post more on what you did to get this working? Or post your boot.img and system.img and I can probably figure it out from there.

23rd June 2019, 12:42 AM |#374  
Junior Member
Thanks Meter: 21
 
More
Quote:
Originally Posted by morchu

I wish I documented the exact things I did on the boot image and system image last time. I failed to do that at that time and just tried to redo the same to document it for you folks. And ...... I bricked my toy (I guess I was overconfident, since I had done it before).

Essentially there is a chain of trust established from bootloader to bootimage to system image, and if you miss a small step anywhere in that chain.... the chain is broken and you have a brick. It is doable, but very risky, since the exact methods of this chain of trust may change from one image to other. Bootloader does not get modified much. But bootimage does, and with every new bootimage we have to assume there is a new method/too much risk.

So maybe at the top of this thread put a big warning in RED letters. Anyway most of us lost interest in this topic from 2015, and there are so much newer toys to play with now in 2019.

Hey Morchu, thanks for trying. Provided you always delete the bootloader from updates then it should be impossible to completely brick it, as you can always fall back to booting from USB. Breaking the chain anywhere else fortunately just prevents it from booting.

If you want to see what's up with it you could try soldering on a serial connection (pins: https://www.exploitee.rs/images/2/29...ecast_UART.jpg)

I agree though, I know a lot of people are flashing back to stock.
27th April 2020, 02:40 AM |#375  
Member
Thanks Meter: 15
 
More
By the way if anyone is still keeping their rooted chromecast and want to get to the latest system and still keep it rooted you can do a loop mount of a system squashfs image and initrd and restart the cast_receiver. This way there is no chance of bricking it since a reboot will just get it back to the way it was. If anyone is interested I can get the image files for this. Since chromecast kernel only supports squshfs,vfat and yaffs2 the image files are going to be in squashfs format.

=============================
sample loopmount script
=============================
#!/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 loop,ro /cache/system.sqfs /system
busybox mount -o bind /initrd/sbin /sbin
# cp -a /initrd/root/* /. #### this step is optional
start cast_receiver
=============================

---------- Post added at 08:40 PM ---------- Previous post was at 08:34 PM ----------

If anyone is still interested I can post the files for you to test. Unfortunately I don't have old chromecasts anymore. But good thing is that the above method only makes temporary changes and wont survive a reboot. So no risk of bricking.

Essentially you would need the below files. I already posted one of the file above (the script).

busybox (for loopmount support)
loopmount script
initrd.sqfs (mainly for the /lib from new boot image)
system.sqfs (rooted new system image)

Let me know if anyone still interested.
The Following 2 Users Say Thank You to morchu For This Useful Post: [ View ] Gift morchu Ad-Free
27th April 2020, 07:11 PM |#376  
bhiga's Avatar
Recognized Contributor
Thanks Meter: 1,027
 
Donate to Me
More
Quote:
Originally Posted by morchu

If anyone is still interested I can post the files for you to test. Unfortunately I don't have old chromecasts anymore. But good thing is that the above method only makes temporary changes and wont survive a reboot. So no risk of bricking.

Essentially you would need the below files. I already posted one of the file above (the script).

busybox (for loopmount support)
loopmount script
initrd.sqfs (mainly for the /lib from new boot image)
system.sqfs (rooted new system image)

Let me know if anyone still interested.

Oooh, this is interesting!

I do still have some root-friendly Chromecasts I've been holding onto, but I'm lacking time/knowledge to really test this out without some pretty major hand-holding and patience.
27th April 2020, 09:00 PM |#377  
Member
Thanks Meter: 15
 
More
I downloaded and looked through the "ota.159268" kernel and system and compared it with "ota.80438".
Essentially they are mostly compatable kernels, but the /libc (which is part of initrd) need to be updated for the new system executables to function.

The risk of bricking is mainly due to the chain of trust established from bootloader to kernel and then from kernel to system. So the issue of all bricking was probably due to the attempt to modify the initird, which in turn breaks the chain of trust. of boot.img.

So we let it boot using the already trusted ota.80438 kernel and initrd (boot.img) and then as part of the init, we could loop mount a new ota.159268 rooted /system and /lib , as long as we still have a way to get the image files to either /cache or /data partitions (via adb or ssh or telnet). Once we prove the concept, we can automate this loopmount as part of our userscripts at early init (without touching the initrd of 80438 boot).

Just for fun I already created the files system.sqfs and initrd.sqfs. But not posting it yet to wide public before someone can try it manually via adb.



Quote:
Originally Posted by bhiga

Oooh, this is interesting!

I do still have some root-friendly Chromecasts I've been holding onto, but I'm lacking time/knowledge to really test this out without some pretty major hand-holding and patience.

28th April 2020, 12:44 AM |#378  
Member
Thanks Meter: 15
 
More
By the way, according to google product page (https://support.google.com/chromecast/answer/7124014)
the latest production firmware version is 1.36.157768

But using the curl method, I am always getting the link for downloading Firmware version 1.36.159268​ , which is apparently a " Preview Program firmware version".

If anyone has the link for 1.36.157768 please let me know. (or just the sha1sum of the file, since we know the download link if we lnow the sha1sum).
29th April 2020, 12:26 PM |#379  
Senior Member
Thanks Meter: 95
 
More
Thank you @morchu for your work! A recent firmware would bring new life to my rooted Chromecast, so I'd be interested to try things out. I think I understood your explanations above, but still would need step-by-step instructions to perform the testing.
30th April 2020, 07:15 AM |#380  
Member
Thanks Meter: 15
 
More
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.

Quote:
Originally Posted by metterschling

Thank you @morchu for your work! A recent firmware would bring new life to my rooted Chromecast, so I'd be interested to try things out. I think I understood your explanations above, but still would need step-by-step instructions to perform the testing.

1st May 2020, 10:04 AM |#381  
Senior Member
Thanks Meter: 95
 
More
Quote:
Originally Posted by morchu

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
Post Reply Subscribe to Thread

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes