Rooting the Cosmo Communicator

[TheProfessorNQ]

I would qualify flashing your preloader as progress! I'm back to an endless loop, at least, though the screen remains black. I should have stock boot.img on there, but I went ahead and re-flashed that. You know, I'm not confident That I didn't flash the boot.img to the recovery partition at some point. Specifically because, for reasons unknown, I keep trying to go there first before I have to stop myself, and its been a couple real late nights trying to fix this thing.

[TauPan]

Additional steps required for updating rooted Cosmos: https://www.oesf.org/forum/index.php?s=&...st&p=293493

[TauPan]

I would qualify flashing your preloader as progress! I'm back to an endless loop, at least, though the screen remains black. I should have stock boot.img on there, but I went ahead and re-flashed that. You know, I'm not confident That I didn't flash the boot.img to the recovery partition at some point. Specifically because, for reasons unknown, I keep trying to go there first before I have to stop myself, and its been a couple real late nights trying to fix this thing.

I don't understand why flashing boot.img from stock or from this post https://www.oesf.org/forum/index.php?s=&...st&p=292918 doesn't fix your problems. Maybe something else is broken.

[ZimbiX]

[size=]New boot images from OTA 1[/size]

I updated with the OTA the other day, but have just got around to re-rooting. My first attempt to install the update without doing anything failed halfway through, as I'd expected it to, since the boot image wouldn't pass match the checksum the OTA was expecting. After that, I re-flashed the stock boot image with fastboot; retrying the update then succeeded.

I've readback the updated boot image with SP Flash Tool and patched it with Magisk. The stock image is uncut - I guess SP Flash Tool readback doesn't strip off the unnecessary zeros, whereas WwR and Magisk do.

Enjoy

boot-ota1-stock.img: https://mega.nz/#!lwMAmYRZ!5HM2cvms...yqJYgVvnF-rQBvw
boot-ota1-magisk.img: https://mega.nz/#!50dwTYpA!KvKxUtcP...dXi2MgRBn5mtANY

I didn't keep track of what the Build number & Custom build version originally said before the OTA in Settings -> System -> About phone, but flashing back the factory boot image doesn't change the version numbers from:

Build number: Cosmo-9.0-Planet-12062019-V16
Custom build version: alps-mp-p0.mp1-V5.117

[ZimbiX]

In the interest of finding out which partitions are safe to share (e.g., not leaking device-specific keys) in order to create a full firmware for factory restore, here are the sizes and checksums of the partition images after my original extraction from WwR with the option that gave the most partitions (I can't remember what that was called, sorry!). It'd be great if someone with their own backup of these from the pre-OTA firmware could compare to see what's the same/different. We can then package up all the partitions that are the same between each device. TauPan? Hopefully posting checksums of the private partitions is not too much of an information leak

Code: [Select]

$ du -b *
9537536     boot.img
4277        boot_para
2146836     cache.img
1652753     cam_vpu1.img
10118081    cam_vpu2.img
142001      cam_vpu3.img
58049       dtbo.img
20971015    expdb
1048576     frp
674561      lk.bin
674561      lk2.bin
5317681     logo.bin
6885761     md1dsp.img
22674625    md1rom.img
8487        metadata
10719736    nvcfg
7866476     nvdata
66977808    nvram
262225      para
4960760     persist
6089        pgpt
271540      preloader_k71v1_64_bsp.bin
184         proinfo
278696      protect1
278696      protect2
14790656    recovery.img
60          seccfg
52689       spmfw.img
503249      sspm.img
2292108904  system.img
6291456     tinysys-scp1.bin
6291456     tinysys-scp2.bin
5242880     trustzone1.bin
12582912    trustzone2.bin
347449104   vendor.img

$ md5sum *
7df30852bb6d2a5d3b3dd3be37d73544 *boot.img
a94559473f7bb6c41b512cd48c8a2b4a *boot_para
3a0de5c3bbb8c7567a446cac48250a8f *cache.img
d505d4e8a5e908738653d22782aa9fcc *cam_vpu1.img
dbbcc085cf867c7ddf346d4d7e0a5d9e *cam_vpu2.img
e61a41f09c04c5865271a24c1bc82826 *cam_vpu3.img
7643eb9fdcbb59ba53e341a5c5d972eb *dtbo.img
e10e6ac974941e9124db1bd09249e9f9 *expdb
3f30f8fe6ebe6a57c2d2a3eb5594a023 *frp
e6b1f20509d5f31c40a644d744d88ce7 *lk.bin
e6b1f20509d5f31c40a644d744d88ce7 *lk2.bin
2944eac6637ddf9315dc6c1e23dc4d6e *logo.bin
cca69d02a837946e6f2cf2fc8316113e *md1dsp.img
75a4bbd0d62510ff9345bfa50f1cc01c *md1rom.img
99b7444e6613088128ec4aa9b0d1dd2d *metadata
aeb16d38ebb20368a7665bd670b0dab3 *nvcfg
242c9ff8a1f35229a1d389ce7c7ffa7d *nvdata
d0fc1bc3b823245c1684c926561dd3c7 *nvram
e37b4ed5b0618496397bdf1c9eef52ae *para
8ad3c777f99f95e43967431d5e69d8cc *persist
3b92df67290c2dbc41c7757433a9dbb4 *pgpt
34838abdb1141bf2999032050b940d7f *preloader_k71v1_64_bsp.bin
6f02d4c074e985c9df1e68c029914889 *proinfo
d306e4a4758acbd5629a53345a12b0dc *protect1
01b55313c8c37421d554563dffe06cbf *protect2
ae7ea13d10f61b546602812b8a9526cd *recovery.img
c40d4aae966d0d8aa7c92bab3845cc22 *seccfg
ccdd0de6fde53b041f9f81c4c3f52cec *spmfw.img
f9ad858bae8d49bcf5f26792521332e5 *sspm.img
bb3ba37c2d5dc7f010c0048a008e2480 *system.img
3d01da91f8b562ddd5fc3e1562b90a10 *tinysys-scp1.bin
3d01da91f8b562ddd5fc3e1562b90a10 *tinysys-scp2.bin
d2bbcf6e83eac78dadcf967690bd64eb *trustzone1.bin
cad0ef7a770f26a2509bbe7b100dee72 *trustzone2.bin
63b7a63a58baa25f12329d2ee060b3b1 *vendor.img

[TauPan]

No information leak even with md5s.

However if those images are padded with 0s they will have different checksums than unpadded ones. Your file lengths look like yours are unpadded, though.

I can post mine later.

Also you've earned extra karma points for posting those boot images. Thanks!

[Ninji]

I can confirm I have matches on the following partitions: boot, cam_vpu{1,2,3}, dtbo, lk, lk2, logo, md1dsp, md1rom, scp1/2, spmfw, sspm, trustzone1/2

Different: boot_para, frp, metadata, nvcfg, nvdata, nvram, para, persist, proinfo, protect1/2

My preloader dump (via SP FlashTool) is clipped slightly at the end for some reason, and my system and vendor dumps are far bigger (also done via SP FlashTool). I would expect these to have only one version though because the OTA updater expects them to be the same for everybody.

[peter]

Edit: Did you retry it? Maybe the download failed somehow. And maybe there's logs somewhere - adb logcat while you do it?

After much faffing about, I did a factory restore.  Following through the steps, I now have root!

[Ninji]

I couldn't get the OTA zip to work properly on my setup, but I've managed to wrangle together a set of images that are flashable with Fastboot from the bootloader mode, by using imgpatchtools to apply the various patches to partitions dumped from my Cosmo. Using this I was able to successfully update to the latest version, and everything still seems to be working.

Here they are, if anyone finds them useful: https://drive.google.com/open?id=12LyxhvLuf...83kU-qKdduQFtjV

I used the following commands from bootloader mode:

Code: [Select]

fastboot flash cam_vpu1 cam_vpu1.img
fastboot flash cam_vpu2 cam_vpu2.img
fastboot flash cam_vpu3 cam_vpu3.img
fastboot flash dtbo dtbo.img
fastboot flash lk lk.img
fastboot flash scp1 scp.img
fastboot flash spmfw spmfw.img
fastboot flash sspm_1 sspm.img
fastboot flash tee1 tee.img
fastboot flash md1dsp md1dsp.trim
fastboot flash md1img md1img.trim
fastboot flash boot boot_191209104700_magisk.img
fastboot flash system new_system.img
fastboot flash vendor new_vendor.img
I deliberately left the preloader untouched.

The lk, scp, sspm and tee partitions appear to have alternate copies on lk2, scp2, sspm_2 and tee2. I didn't flash these myself, but the official OTA script does, so perhaps doing that would be a good idea?

[TheProfessorNQ]

Wow! You're amazing and thank you! All the flashing went smoothly. The device is automatically booting into recovery mode every time I try to reboot it. I had been doing this before the flashing. I'm using your TWRP from the other thread, as my manufacturer recovery hadn't been accessible. Any ideas about this? This constant progress has me very hopeful, at least!

[Ninji]

Wow! You're amazing and thank you! All the flashing went smoothly. The device is automatically booting into recovery mode every time I try to reboot it. I had been doing this before the flashing. I'm using your TWRP from the other thread, as my manufacturer recovery hadn't been accessible. Any ideas about this? This constant progress has me very hopeful, at least!

Hm.. The Cosmo appears to be super temperamental about what it will boot into in my testing -- sometimes it goes straight to Android, sometimes it goes straight to recovery, sometimes it just loops on screen on/off with the CoDi doing weird things. I've not identified a pattern.

Have you tried using Reboot > System from TWRP rather than just power cycling the Cosmo? This usually seems to do the trick for me.

If that doesn't work, I'd be very interested in seeing what your 'para' partition (NOT 'boot_para'!) contains. Please run this:

Code: [Select]

xxd /dev/block/by-name/para | grep -v "0000 0000 0000 0000 0000 0000 0000 0000"
It's mostly zeroes, but appears to contain some pertinent information within the first two pages. Here is what I get from my Cosmo, split up:

Code: [Select]

00000000: 626f 6f74 6f6e 6365 2d62 6f6f 746c 6f61  bootonce-bootloa
00000010: 6465 7200 0000 0000 0000 0000 0000 0000  der.............

00020000: 454e 565f 7631 0000 6f66 662d 6d6f 6465  ENV_v1..off-mode
00020010: 2d63 6861 7267 653d 3100 756e 6c6f 636b  -charge=1.unlock
00020020: 5f65 7261 7365 3d70 6173 7300 0000 0000  _erase=pass.....
00023ff0: 0000 0000 454e 565f 7631 0000 010d 0000  ....ENV_v1......

00040000: 0100 0000 34d9 63c8 aacb 3f77 e355 44f1  ....4.c...?w.UD.
00040010: 0000 0000 0000 0000 1f56 44f1 3c00 0000  .........VD.<...
00040030: 0000 0000 e355 44f1 fe5e c800 0000 0000  .....UD..^......
00040040: ea56 44f1 3500 0000 0000 0000 0200 0000  .VD.5...........
00040050: d000 0000 0000 0000 0000 0000 0000 0000  ................At 00000000 is a text string which determines what the Cosmo will do on next boot - right now on mine (within Android) it is "bootonce-bootloader".

At 00020000 is what appears to be called the "env" data (relevant code in Gemini LK source), mine simply contains 'off-mode-charge=1' and 'unlock_erase=pass' as you can see above.

At 00040000 is data which I believe relates to power management - my hardware-fu isn't good enough to determine precisely what it does but I'm 100% confident it's not sensitive in any way. I don't know if it varies on different Cosmo units, and I suspect that it may be left-over data which the Cosmo doesn't actually use - the Gemini kernel reads it in its Picachu module (same location, different format), and while the Cosmo has a Picachu module has well, it doesn't read from the para partition. There is also a Kconfig file in the Gemini kernel which expands Picachu to "PI CAlibration and CHaracterization Utility".

Anyway, while writing this post I've managed to once again get my Cosmo into a state where it won't boot into anything other than the Preloader. I'm going to see if I can figure out why it's doing this and if I can come up with a solution.

[TheProfessorNQ]

Ran that. We can certainly see that it's being directed to boot into recovery every time. Thanks for this! I spent an eternity last night trying to find a file somewhere that would be directing this.

Here's my dump from the xxd command:

Code: [Select]

00000000: 626f 6f74 2d72 6563 6f76 6572 7900 0000  boot-recovery...
00000040: 7265 636f 7665 7279 0a2d 2d75 7064 6174  recovery.--updat
00000050: 655f 7061 636b 6167 653d 2f63 6163 6865  e_package=/cache
00000060: 2f75 7064 6174 652e 7a69 700a 2d2d 6c6f  /update.zip.--lo
00000070: 6361 6c65 3d65 6e2d 5553 0a0a 0000 0000  cale=en-US......
00020000: 454e 565f 7631 0000 6f66 662d 6d6f 6465  ENV_v1..off-mode
00020010: 2d63 6861 7267 653d 3100 756e 6c6f 636b  -charge=1.unlock
00020020: 5f65 7261 7365 3d70 6173 7300 7065 7273  _erase=pass.pers
00020030: 6973 742e 7665 6e64 6f72 2e72 6164 696f  ist.vendor.radio
00020040: 2e63 6675 2e71 7565 7279 7479 7065 3d30  .cfu.querytype=0
00020050: 006d 645f 7479 7065 3d31 3200 0000 0000  .md_type=12.....
00023ff0: 0000 0000 454e 565f 7631 0000 951e 0000  ....ENV_v1......
00040000: 0100 0000 1537 5d7a 518f b5fa e355 44f1  .....7]zQ....UD.
00040010: 0000 0000 0000 0000 1d56 44f1 3a00 0000  .........VD.:...
00040030: 0000 0000 e355 44f1 e05e c600 0000 0000  .....UD..^......
00040040: 8f56 44f1 3600 0000 0000 0000 0600 0000  .VD.6...........
00040050: 7000 0000 0000 0000 0000 0000 0000 0000  p...............

[Ninji]

Ran that. We can certainly see that it's being directed to boot into recovery every time. Thanks for this! I spent an eternity last night trying to find a file somewhere that would be directing this.

Here's my dump from the xxd command:

Interesting! Your Cosmo has very slightly different data in the Picachu region at 00040000 - this is probably generated at manufacture time and specific to each unit somehow... So that answers one of my questions.

What happens if you use Reboot > System from TWRP? Does that override things sufficiently enough to boot into Android?

If not, I would be inclined to suggest dumping that partition (via either TWRP or FlashTool readback), replacing everything from 00000000 to 0001FFFF with the string from mine and re-flashing that to see if it makes LK behave...

[TheProfessorNQ]

Interesting! Your Cosmo has very slightly different data in the Picachu region at 00040000 - this is probably generated at manufacture time and specific to each unit somehow... So that answers one of my questions.

What happens if you use Reboot > System from TWRP? Does that override things sufficiently enough to boot into Android?

If not, I would be inclined to suggest dumping that partition (via either TWRP or FlashTool readback), replacing everything from 00000000 to 0001FFFF with the string from mine and re-flashing that to see if it makes LK behave...

Haha!!!! That did it!! Dumping my partition and replacing the section with data from yours, and I have been able to boot into android! Oh, man, this feels good! A hundred Thank You's!!! Gonna reboot a couple time now to make sure it sticks, and then try to remote in to my work computer where I had a Titanium Backup of everything I had on here before this nightmare began. Once more - THANK YOU!!!

[Ninji]

Haha!!!! That did it!! Dumping my partition and replacing the section with data from yours, and I have been able to boot into android! Oh, man, this feels good! A hundred Thank You's!!! Gonna reboot a couple time now to make sure it sticks, and then try to remote in to my work computer where I had a Titanium Backup of everything I had on here before this nightmare began. Once more - THANK YOU!!!

Awesome, really glad to hear that..! Since you mentioned that your Cosmo stopped working after a failed OTA update, I suspect something went awry in the process and your recovery partition got messed up - so LK kept on trying to boot into it and nothing would happen.. until you flashed TWRP, at which point it would successfully boot into that but still not complete the update.

After doing a bit more investigation I've realised why my TWRP build didn't fix it - I mapped the 'para' partition to /para in my fstab, but Android expects it to be called /misc in order for this information to be updated correctly. If I had gotten that right, then rebooting from TWRP into System should have sorted things out correctly. Ah well, lesson learned...