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

[morchu]

For folks who are interested to keep the root in the latest version, I was able to get it boot successfully. I made some random unnecessary changes. But the only change required (on top of the regular rooting changes) are

1. Do not use dmsetup to mount /system. This does check integrity of system partition and will fail.
Essentially in init.rc remove lines
exec /sbin/dmsetup create system -r /dmtable
mount squashfs /dev/mapper/system /system ro nodev noatime
and replace with the old way of mounting system
mount squashfs mtd@rootfs /system ro nodev noatime

2. Do not start process_monitor service
Delete line "start process_monitor" in init.rc
You can just delete /bin/process_monitor from system partition, and it should not execute the init.rc service as well.

3. I also changed the dump_msg service to oneshot in init.rc. But I don't think it matters.

I also did some other random changes, which are unnecessary. I will revert those changes when I get some time, but for now it is booting without any issues for me.

 

[Johan1976]

For folks who are interested to keep the root in the latest version, I was able to get it boot successfully. I made some random unnecessary changes. But the only change required (on top of the regular rooting changes) are

1. Do not use dmsetup to mount /system. This does check integrity of system partition and will fail.
Essentially in init.rc remove lines
exec /sbin/dmsetup create system -r /dmtable
mount squashfs /dev/mapper/system /system ro nodev noatime
and replace with the old way of mounting system
mount squashfs mtd@rootfs /system ro nodev noatime

2. Do not start process_monitor service
Delete line "start process_monitor" in init.rc
You can just delete /bin/process_monitor from system partition, and it should not execute the init.rc service as well.

3. I also changed the dump_msg service to oneshot in init.rc. But I don't think it matters.

I also did some other random changes, which are unnecessary. I will revert those changes when I get some time, but for now it is booting without any issues for me.

Can you possibly make a flashcast image for this?

Is this with autoroot?
Or have you just disabled updates?

Sent from my SM-G950F using Tapatalk

 

[KenMacD]

For folks who are interested to keep the root in the latest version, I was able to get it boot successfully.

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.

 

[danielg4]

TL;DR: DON'T DO WHAT I DID.

So, I started with this:

My Chromecast updated after the Autoroot and I got stuck at the "Chromecast..." screen. No luck using Flashcash or Hubcap, even when I dragged out my old Teensy 2.0 and tried at least a dozen times to get it to take. I was close to giving up and assuming my Chromecast was cooked.

Then I tried a long-shot idea described elsewhere on this thread: power up and down fast many times, and eventually I got into recovery with the Flashcast logo on screen. I was able to ssh into the recovery partition, and then…

However, what I did then instead was this:

[root@flashcast ~]# cat /dev/mtd2ro > /tmp/mtd2ro

Laptop:

$ scp root@chromecast:/tmp/mtd2ro .
Welcome to FlashCast version 1.3!
root@chromecast's password: 
mtd2ro                                        100%   16MB   1.8MB/s   00:09    
$ dd bs=1 skip=256 if=mtd2ro of=mtd2ro.raw
16776960+0 records in
16776960+0 records out
16776960 bytes (17 MB) copied, 34.7652 s, 483 kB/s
$ abootimg -i mtd2ro.raw

Android Boot Image Info:

* file name = mtd2ro.raw 

* image size = 16776960 bytes (16.00 MB)
  page size  = 2048 bytes

* Boot Name = ""

* kernel size       = 2021612 bytes (1.93 MB)
  ramdisk size      = 1580304 bytes (1.51 MB)

* load addresses:
  kernel:       0x00608000
  ramdisk:      0x01600000
  tags:         0x00600100

* cmdline = init=/init console=  mtdblock.ro_fspart="rootfs" ro nooverlayfs

* id = 0x48a1f96a 0x908be401 0x85d4c47d 0xfa540415 0xe42f1e3f 0x00000000 0x00000000 0x00000000 

$ abootimg -x mtd2ro.raw
writing boot image config in bootimg.cfg
extracting kernel in zImage
extracting ramdisk in initrd.img
$ mkdir initrd
$ cd initrd/
$ xzcat ../initrd.img |cpio -vid
app.conf
bin
boot
build.prop
chrome
data
default.prop
dev
dmtable
etc
home
init
init.rc
lib
lib/firmware
lib/firmware/mrvl
lib/firmware/mrvl/sd8787_uapsta.bin
lib/ld-2.23.so
lib/ld-linux-armhf.so.3
lib/libc++.so
lib/libc++.so.1
lib/libc++.so.1.0
lib/libc++abi.so
lib/libc++abi.so.1
lib/libc++abi.so.1.0
lib/libc-2.23.so
lib/libc.so.6
lib/libc_stubs.so
lib/libcrypt-2.23.so
lib/libcrypt.so.1
lib/libcxxrt.so
lib/libcxxrt.so.1
lib/libdl-2.23.so
lib/libdl.so.2
lib/libgcc_s.so.1
lib/libglibc_bridge.so
lib/liblog.so
lib/libm-2.23.so
lib/libm.so.6
lib/libnsl-2.23.so
lib/libnsl.so.1
lib/libnss_compat-2.23.so
lib/libnss_compat.so.2
lib/libnss_dns-2.23.so
lib/libnss_dns.so.2
lib/libnss_files-2.23.so
lib/libnss_files.so.2
lib/libpthread-2.23.so
lib/libpthread.so.0
lib/libresolv-2.23.so
lib/libresolv.so.2
lib/librt-2.23.so
lib/librt.so.1
lib/libutil-2.23.so
lib/libutil.so.1
netflix
oem_cast_shlib
proc
res
sbin
sbin/bluetooth_setup.sh
sbin/boot_complete.sh
sbin/build_info.sh
sbin/collectd_setup.sh
sbin/coredump.sh
sbin/dmsetup
sbin/flash_recovery.sh
sbin/font_setup.sh
sbin/init
sbin/init_properties
sbin/led_feedback.sh
sbin/mount_usb_drive.sh
sbin/netflix_setup.sh
sbin/network_service.sh
sbin/playready_device_id_reset.sh
sbin/retail_demo_reboot.sh
sbin/retail_usb_flash.sh
sbin/ueventd
sbin/update_bootid_and_urandom.sh
sbin/update_engine_prefs_fixup.sh
sbin/watchdog_setup.sh
sbin/wpa_supplicant_setup.sh
sys
system
system/etc
system/etc/ld.so.preload
tmp
ueventd.eureka-b1.rc
ueventd.eureka-b2.rc
ueventd.eureka-b3.rc
ueventd.rc
usr
xbin
6993 blocks
$ vi init.rc

Commented out the lines "exec /sbin/dmsetup create system -r /dmtable" and "mount squashfs /dev/mapper/system /system ro nodev noatime" with "mount squashfs mtd@rootfs /system ro nodev noatime" inserted in their place, and also commented out the "start process_monitor" line, like @morchu said.

$ find .|cpio --create --format='newc'|xz > ../myinitrd.img
6994 blocks
$ cd ..
$ abootimg --create myboot.img -f bootimg.cfg -k zImage -r myinitrd.img
reading config file bootimg.cfg
reading kernel from zImage
reading ramdisk from myinitrd.img
Writing Boot Image myboot.img
$ dd of=mtd2ro bs=1 seek=256 if=myboot.img
16776960+0 records in
16776960+0 records out
16776960 bytes (17 MB) copied, 34.5113 s, 486 kB/s
$ scp mtd2ro root@chromecast:/tmp/
Welcome to FlashCast version 1.3!
root@chromecast's password: 
mtd2ro                                        100%   16MB 963.8KB/s   00:17

Chromecast:

[root@flashcast ~]# flash_mtd_partition kernel /tmp/mtd2ro 
Flashing /tmp/mtd2ro to kernel (mtd2)
[root@flashcast ~]# sync
[root@flashcast ~]# sync
[root@flashcast ~]# reboot
[root@flashcast ~]# Connection to chromecast closed.

From that point forward, applying power has no effect except a solid white LED. I don't know exactly where I went wrong, nor what to do now. So, I opened the case and found the UART pinout. Without soldering anything, I held pins to the Tx and GND pads and got no output on power-on. I do have an STM32F3 Discovery board, which apparently can somehow be used to interface with the NAND chip externally, but I haven't found further instructions for such a thing on a hardware level. Thoughts? Attached is the resulting file I flashed, but bzipped.

P.S. - I didn't think it mattered, but before I rebooted it to a brick, out of curiosity, I mounted and unmounted as yaffs2 mtdblock's 4, 5, 9, and 11.

 

[Idontwantausername]

I was able to ssh into the recovery partition.

How were you able to SSH? Does flashcast connect to WiFi?

 

[danielg4]

How were you able to SSH? Does flashcast connect to WiFi?

Since the Chromecast was already set up for my Wi-Fi network, Flashcast somehow read the settings and connected to it.

 

[ghostd0g]

If you create a flashcast 1.3 usb and copy the 44433.001 - 2015-11-15 Eureka-ROM into the root of the new flashcast partion ... using a OTG cable .. my Chromecast did re flash the older firmware

just follow the 44433.001 - 2015-11-15 Eureka-ROM - Based on OTA 44433 instructions after creating a flashcast 1.3 usb

 

[ImCoKeMaN]

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.

Do you have the system.img to play with? It seems like copying a new init.rc and maybe deleting the update file would be an easy to create flashcast mod. I was curious about making a sed script even that could mod new versions, but seems nobody is developing because few are interested too with all the newer toys.

Edit:
I looked at the system.img file from the newest OTA and I don't see where the init.rc is, I was planning to modify as you mentioned, but don't know where to find it while in flashcast to make a mod.

Edit2: looks like it's in boot.img and that is harder to modify, from what i'm seeing in this thread including the issue above. Is this the right steps to make a boot.img: https://github.com/team-eureka/Eureka-ROM/tree/master/initramfs and has anyone been successful with this?

Edit3: Tested with that info and info from this link posted in post 254: https://hackmd.io/vGr8L1LZRiuiITVoHwzeHg?both#
I was able to get it to boot back to Chromecast... after some failed boot.img creations so I think I mangled it back properly this time, but I still can't see how morchu made this version work and it looked like ddggttff3 said it was more than just init.rc in the newer kernel that wasn't working.

 

[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."

 

[KenMacD]

Okay. I managed to get an image that would work by building the older eureka_linux kernel and putting it together with a modified initramfs and system from 124602. It seems to work for me, but I make no guarantees. I started a new thread to discuss it at https://xdaforums.com/android-tv/chromecast/rom-unnamed-test-t3834330.

 

[davidj7479]

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..

 

[cancunia]

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://xdaforums.com/showpost.php?p=72094986&postcount=58

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

 

[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.

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.

 

[KenMacD]

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/Chromecast_UART.jpg)

I agree though, I know a lot of people are flashing back to stock.

 

[morchu]

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.

 

[bhiga]

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.

 

[morchu]

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.

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.

 

[morchu]

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).

 

[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.

 

[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.

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.