Printable Version of Topic

Click here to view this topic in its original format

OESF Portables Forum _ Cosmo Communicator - Hardware _ Rooting the Cosmo Communicator

Posted by: Charlie Stross Oct 12 2019, 04:02 AM

Does anyone have any insight into how to go about rooting the Cosmo?

(Yes, yes, I know they've only just begun shipping ..!)

NB: directions to enable a relative noob to root a Communicator would be welcome. (I want to be able to use some of the https://github.com/fAndreuzzi/TUI-ConsoleLauncher/wiki/Root-commands.)

Posted by: Vistaus Oct 13 2019, 12:00 PM

It should be easy. I don't have a Gemini, but there is official root support for the Gemini and it seems easy enough. So I think the process for the Cosmo will be very similar. I want to root it too smile.gif

Posted by: Zarhan Oct 23 2019, 11:38 PM

Actually...can someone point to a good tutorial on rooting Android in general?

The phone I'm using daily is still good old Nokia N900 (only big problem with it is the lack of TLS 1.2 support). Syncing with MS Exchange Online (O365) works. Anyway, this means that I really have no in-depth experience with Android apart from occasionally seeing my wife use her Samsung.

I'm finding a bunch of tutorials by googling for them, but the basics, such as "What are the differences between Supersu and Magisk and why do I need them in the first place" is missing. Same applies for TWRP. (Well, for that I could find info on what it is - essentially a boot manager with partition backup functions), but no one has exactly told why it's needed and why TWRP is the one everybody recommends...

So by "good" tutorial I'm looking for information that besides telling "Do X, then do Y" actually also tells WHY you should do X and why Y is the best choice (instead of Z).

Posted by: Vistaus Oct 24 2019, 01:36 AM

Dunno. Sometimes rooting is device-specific. But to get you started: DON'T ever use SuperSu. It has been abandoned for a long time and contains security holes. Magisk is the only good way to root, plus it's more flexible as you can add Magisk repos to customize your device after rooting it.
TWRP is needed because the default bootloader iis never really flexible nor easy to use and often doesn't even allow you to flash Magisk and custom ROMs and stuff. There are a few other bootloaders out there, but TWRP is the most flexible and widely supported.

Posted by: shinkamui Nov 8 2019, 11:08 PM

QUOTE(Vistaus @ Oct 24 2019, 04:36 AM) *
Dunno. Sometimes rooting is device-specific. But to get you started: DON'T ever use SuperSu. It has been abandoned for a long time and contains security holes. Magisk is the only good way to root, plus it's more flexible as you can add Magisk repos to customize your device after rooting it.
TWRP is needed because the default bootloader iis never really flexible nor easy to use and often doesn't even allow you to flash Magisk and custom ROMs and stuff. There are a few other bootloaders out there, but TWRP is the most flexible and widely supported.


TWRP isn't a bootloader, its a custom recovery environment...

Posted by: Vistaus Nov 9 2019, 02:38 AM

QUOTE(shinkamui @ Nov 9 2019, 08:08 AM) *
QUOTE(Vistaus @ Oct 24 2019, 04:36 AM) *
Dunno. Sometimes rooting is device-specific. But to get you started: DON'T ever use SuperSu. It has been abandoned for a long time and contains security holes. Magisk is the only good way to root, plus it's more flexible as you can add Magisk repos to customize your device after rooting it.
TWRP is needed because the default bootloader iis never really flexible nor easy to use and often doesn't even allow you to flash Magisk and custom ROMs and stuff. There are a few other bootloaders out there, but TWRP is the most flexible and widely supported.


TWRP isn't a bootloader, its a custom recovery environment...


I know, I just wanted to keep it simple.

Posted by: gidds Nov 9 2019, 08:05 AM

TWRP is certainly not necessary to install rooted Android, as the Gemini I'm typing this on was rooted without it!

It can be done using the Windows or Linux Flash Tool to install the rooted Android OS that Planet supply. (It's pretty fiddly, but doable.)

Assuming the same tool works with the Cosmo -- and I suspect it will -- all we'll need will be Planet to supply the rooted Android image for the Cosmo.

Posted by: ZimbiX Nov 14 2019, 05:59 PM

I need root to be able to migrate from my Gemini properly. I've been carrying around three phones this week =P

According to the official Magisk installation instructions, the app can patch an arbitrary kernel image file. https://topjohnwu.github.io/Magisk/install.html#boot-image-patching

I'm thinking the desktop flash tool would be able to flash that patched kernel image to the Cosmo. It would just need a scatterfile to know where the partitions are.

I did some Googling, and apparently an MTK Tool can generate a scatterfile by analysing the device. The flash tool might support doing this too.

So lastly, we need to first read the kernel image from the device so the Magisk app can patch it. The MTK Tool can apparently make a backup of the device. Hopefully that means it stores the partitions as individual img files. Again, the flash tool might also support this.

I've been thinking about this for a few days, but haven't tried any of it yet. Sadly, I haven't been able to get the flash tool working on my Arch Linux in the past, so I'll have to have a go on Windows on the weekend.

Posted by: gidds Nov 16 2019, 02:26 AM

On my Mac, the only way I was able to run the Flash Tool was by setting up a USB stuck with Debian and booting from that. (It didn't work on Ubuntu.) I had a second stick with the Flash Tool and scatter file and images, but I first needed to install the non-free Debian tools to read it...

Posted by: ZimbiX Nov 17 2019, 03:49 AM

Unfortunately, it turns out the MTK Tool is unmaintained and has not supported new devices for some years.

I found another tool called Miracle Thunder, which was described as rather capable, but it looked sketchy and I couldn't get it to load up past the splash screen.

There's info on a more manual process (https://forum.xda-developers.com/showthread.php?t=2540400) which I haven't made much headway with. The various partition info files in /proc which it mentions do not exist. I guess the Cosmo's using a newer/different Android storage system?

I've spent the better part of today researching and experimenting, and at this point I'm afraid I'm about ready to give up and wait for Planet to eventually release something =\

Posted by: ZimbiX Nov 17 2019, 05:53 AM

In case it's useful, I've just worked out how to boot to recovery and show the menu:
- Reboot the device while holding down the right-hand side of the fingerprint rocker switch until the screen turns on (info from https://github.com/gemian/gemian/wiki/Bootloader) - or alternatively, run `adb reboot recovery`
- Once in recovery, press Fn + Esc + right-hand side of the fingerprint rocker switch

I tried the ADB sideload option to flash the Magisk zip, but predictably, it responds with "Signature verification failed" - since I'd reckon the bootloader's still locked (so zips require manufacturer signing). Now, if there was a way to unlock the bootloader...

I've had a play with the 'Reboot to bootloader' option with fastboot - hoping to try something like `fastboot oem unlock` (which is the bootloader unlock method for other Androids I've used) - but annoyingly, it doesn't show up with `fastboot devices` and Windows keeps making device plugged and unplugged noises (alternating about every ten seconds).

Posted by: ZimbiX Nov 17 2019, 06:52 AM

At a glance, this looks quite interesting - using a 'Wwr MTK tool' to create a full backup of the device: https://forum.hovatek.com/thread-21970.html
I don't have any more time to look into this for a while! =\

Posted by: v3ritas Nov 17 2019, 01:13 PM

QUOTE(ZimbiX @ Nov 17 2019, 09:52 AM) *
At a glance, this looks quite interesting - using a 'Wwr MTK tool' to create a full backup of the device: https://forum.hovatek.com/thread-21970.html
I don't have any more time to look into this for a while! =\


Thanks for your work on this. I just got my Cosmo yesterday & have started to play around with it a little as well, looking into rooting.

I was trying to do the same thing with the bootloader unlock: `fastboot oem unlock`, but didn't have any luck.

Going to keep playing with it & see what I can get. On other systems I've been able to patch the boot image through Magisk Manager, flash through fastboot, & then be set. I forget how I was getting root on my Gemini while using stock firmware, but may be similar to this.

Do we have recovery images yet for the Cosmo? May need those (either for root or when I inevitably break something while trying to root).

Posted by: ZimbiX Nov 17 2019, 03:23 PM

QUOTE(v3ritas @ Nov 18 2019, 08:13 AM) *
I forget how I was getting root on my Gemini while using stock firmware, but may be similar to this.


For the Gemini, Planet provided a pre-rooted boot.img for us to flash with the SP Flash Tool. Unless you're saying you might have done something else.

QUOTE(v3ritas @ Nov 18 2019, 08:13 AM) *
Do we have recovery images yet for the Cosmo? May need those (either for root or when I inevitably break something while trying to root).


Not that I know of. I did come across this last night though: 'Mediatek (MTK) Auto TWRP recovery porter by Team Hovatek' - https://forum.hovatek.com/thread-21839.html. It looks recently developed enough that it might just work once we extract the stock recovery image biggrin.gif These Hovatek people are champs.

Good luck! And let us know what you learn

Posted by: gidds Nov 18 2019, 01:29 AM

(I can't add anything useful, but just wanted to encourage you all to let us know what you find! I'll need to root my Cosmo when it arrives, as I rely on my Gemini being rooted to do things like backups and file transfers over ssh, adblocking via the hosts file, checking for runaway processes, and much more.)

Posted by: v3ritas Nov 18 2019, 04:37 AM

QUOTE(ZimbiX @ Nov 17 2019, 06:23 PM) *
QUOTE(v3ritas @ Nov 18 2019, 08:13 AM) *
I forget how I was getting root on my Gemini while using stock firmware, but may be similar to this.


For the Gemini, Planet provided a pre-rooted boot.img for us to flash with the SP Flash Tool. Unless you're saying you might have done something else.

QUOTE(v3ritas @ Nov 18 2019, 08:13 AM) *
Do we have recovery images yet for the Cosmo? May need those (either for root or when I inevitably break something while trying to root).


Not that I know of. I did come across this last night though: 'Mediatek (MTK) Auto TWRP recovery porter by Team Hovatek' - https://forum.hovatek.com/thread-21839.html. It looks recently developed enough that it might just work once we extract the stock recovery image biggrin.gif These Hovatek people are champs.

Good luck! And let us know what you learn


It's using the "new" unlocking commands (`fastboot flashing unlock`), but currently hung at the prompt because I can't find out what's bound as the volume keys on the device. Going to try to play around with it while I'm at work today.

Here's some info from `fastboot getvar all` though:
? ~ fastboot getvar all
(bootloader) max-download-size: 0x8000000
(bootloader) variant:
(bootloader) logical-block-size: 0x200
(bootloader) erase-block-size: 0x80000
(bootloader) hw-revision: ca00
(bootloader) battery-soc-ok: yes
(bootloader) battery-voltage: 3734mV
(bootloader) partition-size:flashinfo: 1000000
(bootloader) partition-type:flashinfo: raw data
(bootloader) partition-size:otp: 2b00000
(bootloader) partition-type:otp: raw data
(bootloader) partition-size:userdata: 1be53f8000
(bootloader) partition-type:userdata: ext4
(bootloader) partition-size:cache: 1b000000
(bootloader) partition-type:cache: ext4
(bootloader) partition-size:system: c0000000
(bootloader) partition-type:system: ext4
(bootloader) partition-size:vendor: 35800000
(bootloader) partition-type:vendor: ext4
(bootloader) partition-size:tee2: c00000
(bootloader) partition-type:tee2: raw data
(bootloader) partition-size:tee1: 500000
(bootloader) partition-type:tee1: raw data
(bootloader) partition-size:dtbo: 800000
(bootloader) partition-type:dtbo: raw data
(bootloader) partition-size:logo: 800000
(bootloader) partition-type:logo: raw data
(bootloader) partition-size:boot: 2000000
(bootloader) partition-type:boot: raw data
(bootloader) partition-size:lk2: 100000
(bootloader) partition-type:lk2: raw data
(bootloader) partition-size:lk: 100000
(bootloader) partition-type:lk: raw data
(bootloader) partition-size:nvram: 4000000
(bootloader) partition-type:nvram: raw data
(bootloader) partition-size:gz2: 1000000
(bootloader) partition-type:gz2: raw data
(bootloader) partition-size:gz1: 1000000
(bootloader) partition-type:gz1: raw data
(bootloader) partition-size:cam_vpu3: f00000
(bootloader) partition-type:cam_vpu3: raw data
(bootloader) partition-size:cam_vpu2: f00000
(bootloader) partition-type:cam_vpu2: raw data
(bootloader) partition-size:cam_vpu1: f00000
(bootloader) partition-type:cam_vpu1: raw data
(bootloader) partition-size:sspm_2: 100000
(bootloader) partition-type:sspm_2: raw data
(bootloader) partition-size:sspm_1: 100000
(bootloader) partition-type:sspm_1: raw data
(bootloader) partition-size:scp2: 600000
(bootloader) partition-type:scp2: raw data
(bootloader) partition-size:scp1: 600000
(bootloader) partition-type:scp1: raw data
(bootloader) partition-size:spmfw: 100000
(bootloader) partition-type:spmfw: raw data
(bootloader) partition-size:md1dsp: 1000000
(bootloader) partition-type:md1dsp: raw data
(bootloader) partition-size:md1img: 6400000
(bootloader) partition-type:md1img: raw data
(bootloader) partition-size:proinfo: 300000
(bootloader) partition-type:proinfo: raw data
(bootloader) partition-size:sec1: 200000
(bootloader) partition-type:sec1: raw data
(bootloader) partition-size:persist: 3000000
(bootloader) partition-type:persist: ext4
(bootloader) partition-size:seccfg: 800000
(bootloader) partition-type:seccfg: raw data
(bootloader) partition-size:protect2: 978000
(bootloader) partition-type:protect2: ext4
(bootloader) partition-size:protect1: 800000
(bootloader) partition-type:protect1: ext4
(bootloader) partition-size:metadata: 2000000
(bootloader) partition-type:metadata: raw data
(bootloader) partition-size:nvdata: 4000000
(bootloader) partition-type:nvdata: ext4
(bootloader) partition-size:nvcfg: 2000000
(bootloader) partition-type:nvcfg: ext4
(bootloader) partition-size:frp: 100000
(bootloader) partition-type:frp: raw data
(bootloader) partition-size:expdb: 1400000
(bootloader) partition-type:expdb: raw data
(bootloader) partition-size:para: 80000
(bootloader) partition-type:para: raw data
(bootloader) partition-size:recovery: 2000000
(bootloader) partition-type:recovery: raw data
(bootloader) partition-size:boot_para: 100000
(bootloader) partition-type:boot_para: raw data
(bootloader) partition-size:preloader: 80000
(bootloader) partition-type:preloader: raw data
(bootloader) serialno: << Redacted >>
(bootloader) off-mode-charge: 1
(bootloader) warranty: yes
(bootloader) unlocked: no
(bootloader) secure: yes
(bootloader) kernel: lk
(bootloader) product: k71v1_64_bsp
(bootloader) slot-count: 0
(bootloader) version-baseband: MOLY.LR12A.R3.MP.V66.11
(bootloader) version-bootloader: k71v1_64_bsp-7c4ca86-20191029135153-201
(bootloader) version-preloader:
(bootloader) version: 0.5
all: Done!!
Finished. Total time: 0.015s
? ~


EDIT: Added the unlocking command above: `fastboot flashing unlock`

EDIT2: Okay, got the bootoader unlocked -- it looks like the button(s) in the fingerprint sensor are bound to volume. After hitting that I was able to actually get it through the unlock process. Now to see about getting a boot image to modify with Magisk for root.
? ~ fastboot getvar all
...
(bootloader) unlocked: yes
(bootloader) secure: no
...
? ~

Posted by: v3ritas Nov 18 2019, 06:02 PM

I'm pretty much stuck. Tried a few different things I found online related to getting a dump of the current firmware, but wasn't successful. Trying to avoid using any app I come across (also running Linux), but through one of the tutorials I have a template for the scatter file. I'm attaching it here in case it helps anyone else out.

Going to keep trying, but don't think I'll be able to accomplish anything before Planet releases the firmware or a way for us to root themselves.

EDIT: Might have the wrong chip there -- the MT6771 appears to be for MediaTek P60, not the Cosmo's P70.

 MT6771_Android_scatter.txt ( 1.01K ) : 20
 

Posted by: ZimbiX Nov 21 2019, 04:51 AM

Good news, everyone!

I've managed to make decent progress with WwR. The UI in the latest version is a bit different from the tutorial I linked, but I've managed to generate a full scatterfile, and have commenced a full readback of the device! It looks like that's going to take a very long time to finish, so I thought I'd update here in the meantime.

Next up would be to use WwR to split the backup into individual image files.

Given it seems so easy to do that, I think I'll do a factory reset of my Cosmo and upload a full stock backup so no one else has to go through the same process. That way it'll be easy for anyone to use the SP Flash Tool to do a factory reset cool.gif

The blocking two-minute donation prompt on launching WwR is pretty annoying, haha. I would donate to get rid of it - plus they really deserve the money - but the PayPal form's loaded in the app, which is pretty dodgy. I think I'd prefer the delays than risk having my payment details stolen via man-in-the-middle tongue.gif

Actually, I've just realised I could have simply readback only the boot image partition now that I know the partition layout from the scatterfile laugh.gif I think I'll do that next before working out the splitting.

Going at 29.53MB/s, it's 32% done as I post this! I'm excited, haha.

I've attached the scatterfile for anyone else interested in playing around biggrin.gif

 MT6771_Android_scatter__cosmo_full_stock.txt ( 17.63K ) : 65
 

Posted by: ZimbiX Nov 21 2019, 06:46 AM

Ok, I've extracted the boot image from the partition called 'boot' (using WwR on my full device backup), and patched it in Magisk Manager on the Cosmo. Here are the original and Magisk'd images:

boot.img: https://mega.nz/#!x8lXTKjT!kXjEjYGDxrDmRLD4H5kJXjWTL1rA36v2Tbht3a4n1yQ
boot-magisk.img: https://mega.nz/#!U8sFVACI!J-TS3q11Hak-zWt1_nyTyv4m87GkV1YIVDipez05BvE

Flashing the Magisk'd image (with Sp Flash Tool v5.1916 using the scatterfile I uploaded), I'm unfortunately seeing this message on top of the splash screen:

QUOTE
Bad State

Your device has failed verification and may not
work properly.
Please download boot image with correct signature
or disable verified boot.
Your device will reboot in 5 seconds.


Flashing the original boot image back at least gets the Cosmo working again.

I'm terribly late for bed, so sadly I'll have to wait until the weekend to continue. We're so close now!

I'm guessing this error is where the bootloader unlocking comes in - @v3ritas: your turn!

 

Posted by: peter Nov 21 2019, 07:56 AM

QUOTE(ZimbiX @ Nov 21 2019, 10:46 AM) *
Ok, I've extracted the boot image from the partition called 'boot' (using WwR on my full device backup), and patched it in Magisk Manager on the Cosmo. Here are the original and Magisk'd images:

boot.img: https://mega.nz/#!x8lXTKjT!kXjEjYGDxrDmRLD4H5kJXjWTL1rA36v2Tbht3a4n1yQ
boot-magisk.img: https://mega.nz/#!U8sFVACI!J-TS3q11Hak-zWt1_nyTyv4m87GkV1YIVDipez05BvE

Flashing the Magisk'd image (with Sp Flash Tool v5.1916 using the scatterfile I uploaded), I'm unfortunately seeing this message on top of the splash screen:

QUOTE
Bad State

Your device has failed verification and may not
work properly.
Please download boot image with correct signature
or disable verified boot.
Your device will reboot in 5 seconds.


Flashing the original boot image back at least gets the Cosmo working again.

I'm terribly late for bed, so sadly I'll have to wait until the weekend to continue. We're so close now!

I'm guessing this error is where the bootloader unlocking comes in - @v3ritas: your turn!


Last night I had success unlocking the bootloader using adb and fastboot per the instructions here: https://www.thecustomdroid.com/unlock-bootloader-android-using-fastboot-guide/

This morning I installed the boot-magisk.img file using fastboot starting at step 12 of Method 2 here: https://www.thecustomdroid.com/install-magisk-root-android-devices/

Successfully booted, and Magisk is now installed, so I've got root? Maybe? I've always used SuperSU, so I need to learn how Magisk works.

Posted by: v3ritas Nov 21 2019, 05:27 PM

Ah, this is great~ Thanks ZimbiX!

Didn't get a chance to check on this while I was at work today so this is a nice surprise. Getting mine rooted now.

Glad you were able to get the app working to dump the scatter file. I don't have a Windows laptop anymore & it was not going well for me when I tried do it through VMware Fusion on my Mac.

peter: Yes, if you have Magisk then you're rooted. If you have any apps that use root you can go ahead & give them a try, or if you already have you can check what has rights in Magisk Manager > Superuser.

I'm getting it flashed now, as soon as my Cosmo finishes charging.

EDIT: I forgot, since we're just flashing the modified boot image, Magisk Manager needs to be installed separately. You can download it from the XDA thread https://forum.xda-developers.com/apps/magisk/official-magisk-v7-universal-systemless-t3473445.

Posted by: peter Nov 21 2019, 09:06 PM

QUOTE(v3ritas @ Nov 21 2019, 08:27 PM) *
peter: Yes, if you have Magisk then you're rooted. If you have any apps that use root you can go ahead & give them a try, or if you already have you can check what has rights in Magisk Manager > Superuser.

I'm getting it flashed now, as soon as my Cosmo finishes charging.

EDIT: I forgot, since we're just flashing the modified boot image, Magisk Manager needs to be installed separately. You can download it from the XDA thread https://forum.xda-developers.com/apps/magisk/official-magisk-v7-universal-systemless-t3473445.



Thanks for your reply, v3ritas. Unfortunately, what I'm seeing on my Cosmo doesn't match the descriptions I'm reading about. Magisk Manager was pre-installed. Even after unlocking the bootloader, flashing the modified .img, and updating Magisk and MM, I'm left with the following:



When I hit Ok, I get a small pop-up saying "Setup failed." I couldn't find anywhere to toggle superuser permissions. The info I've read at xda so far seems to assume that the additional setup has been completed successfully.

I'd be grateful for any tips! Tomorrow when my brains are fresh, I'll try un- and then re-installing, but I'd really rather not.

Posted by: ZimbiX Nov 21 2019, 09:33 PM

QUOTE(peter @ Nov 22 2019, 04:06 PM) *
When I hit Ok, I get a small pop-up saying "Setup failed." I couldn't find anywhere to toggle superuser permissions. The info I've read at xda so far seems to assume that the additional setup has been completed successfully.

I'd be grateful for any tips! Tomorrow when my brains are fresh, I'll try un- and then re-installing, but I'd really rather not.


Damn, that's annoying! blink.gif

I've just had a go, and got it working on mine biggrin.gif After tapping 'ok' on the 'Requires additional setup' popup, it runs a spinner for a few seconds, then reboots. Root confirmed working via Termux happy.gif

I flashed boot using the SP Flash Tool rather than using fastboot if that makes any difference. I can't work out what the key combination is to boot straight to fastboot - maybe there isn't one..?

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

Edit 2: It's amusing that the only way to tell a Cosmo and Gemini apart in these kinds of photos is by the subtle presence of the third hinge in the centre =P

 

Posted by: v3ritas Nov 22 2019, 03:38 AM

QUOTE(ZimbiX @ Nov 22 2019, 12:33 AM) *
QUOTE(peter @ Nov 22 2019, 04:06 PM) *
When I hit Ok, I get a small pop-up saying "Setup failed." I couldn't find anywhere to toggle superuser permissions. The info I've read at xda so far seems to assume that the additional setup has been completed successfully.

I'd be grateful for any tips! Tomorrow when my brains are fresh, I'll try un- and then re-installing, but I'd really rather not.


Damn, that's annoying! blink.gif

I've just had a go, and got it working on mine biggrin.gif After tapping 'ok' on the 'Requires additional setup' popup, it runs a spinner for a few seconds, then reboots. Root confirmed working via Termux happy.gif

I flashed boot using the SP Flash Tool rather than using fastboot if that makes any difference. I can't work out what the key combination is to boot straight to fastboot - maybe there isn't one..?

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

Edit 2: It's amusing that the only way to tell a Cosmo and Gemini apart in these kinds of photos is by the subtle presence of the third hinge in the centre =P


I did get the same prompt about needing additional setup, hit okay & think mine clocked a little too. After that I was set though. Tested through ADB shell & worked as expected. I also flashed the Magisk boot.img through fastboot, so I don't think that would be causing the issue.

I wasn't sure about the key combo for direct fastboot either. I think using the Assistant button just works on the different OS boot methods, but I usually just go through `adb reboot bootloader` instead of fumbling around with the required keys per device.

Posted by: peter Nov 25 2019, 09:21 AM

QUOTE(ZimbiX @ Nov 21 2019, 07:51 AM) *
I've attached the scatterfile for anyone else interested in playing around biggrin.gif


So, here's a question. Would it be possible to manually tweak the Cosmo scatter file by comparing it to a Gem file and use the Debian .img provided by Planet for the Gem to set up a dual boot Cosmo? Or is that Debian .img too heavily customized for the Gem to work on our new devices?

I'd just go ahead and try it myself, but I still haven't wrangled Magisk Manager successfully. I'm aiming to do that so I can use Titanium Backup before moving on to further experiments...

Posted by: AP756 Nov 25 2019, 12:15 PM

Thank you all contributing to this thread. With the scatter.txt and boot-magisk.img provided by ZimbiX I was able to root my Cosmo about 4h after receiving it :-).

Now I'm going to "improve" it the way I used to optimize my Gemini.

Update 1: Started Magisk manager, within Magisk installed Riru-Core and then Riru-EdXposed (SandHook), installed edXposed manager.apk, rebooted and started edxposed. It works!

Update 2: Within edXposed I installed GravityBox [P] v 9.1.3, updated modules list and rebooted. It works :-)

Regarding "Your device has failed verification and may not work properly..." I think this message is most probably located in lk (21500000). In another forum someone tweakd this area, the text is gone, but the 5 sec waiting time still exists. We'll know when the Planet Computers solution of rooting is published. For the time being I just ignore that message ;-)

Bye for now

Posted by: xopher Nov 26 2019, 09:10 AM

These steps do work, I had to update my ADB Fastboot Driver to get the bootloader to unlock (curse words happened during that process). I don't want to provide the source of the updated driver in case the source I used is not altruistic.

Now, I wait for someone knowledgeable and/or brave enough to make a new scatter file with an empty partition to add some Linux spice to my device. I wonder if PC will host a partition tool before the community provides and figures out the key combos.

I imagine PC doesn't want to open the floodgates so they can focus on general support first. Their undertaking is not a small feat even at 4000. Imagine the possibility of having 4000 hungry infants to feed at once with only a few baby feeding bottles, YIKES!

I'm pretty sure since bootloader is unlocked NFC payments are out of the question since the device is "untrusted", it is possible your banking apps may no run on it post bootloader unlock since you broke the trust (if the app checks for that sort of thing). This is something to consider before unlocking ("tampering") with bootloader, you know your use case.

I might be wrong but thought I'd throw that last bit out there since no one else mentioned it. An LG Watch I had became ineligible for NFC payment until I reverted it back to "natural" state and Samsung has Knox, all the same principal, and I could be wrong.

Time to tame battery drain. My Gemini has a lot more stamina than Cosmo ATM (what are others using for power mgmt and background process control these days?? That is another question for another subforum).

BTW, hi; I'm new here, thanks for allowing me to fly the OESF skies!

Posted by: gidds Nov 26 2019, 11:35 AM

QUOTE(AP756 @ Nov 25 2019, 08:15 PM) *
We'll know when the Planet Computers solution of rooting is published.

Is that definitely ‘when’, rather than ‘if’?  Have they said anything on the issue?

(My Cosmo is scheduled to be delivered tomorrow, but I won't be able to set it up and transfer everything from my Gemini without having rooted Android…  At first glance, the above posts looks pretty daunting; I'd be much happier if Planet provided downloadable firmware for the Cosmo, the way they did for the Gemini — after a lot of pain, I know how to use that!)

Posted by: MadAdy Nov 26 2019, 03:11 PM

Hi owners, FYI Bootloader Unlock is in Developer Options.

Tap on Build Number in About Phone.

Posted by: v3ritas Nov 27 2019, 04:13 AM

QUOTE(gidds @ Nov 26 2019, 02:35 PM) *
QUOTE(AP756 @ Nov 25 2019, 08:15 PM) *
We'll know when the Planet Computers solution of rooting is published.

Is that definitely ‘when’, rather than ‘if’? Have they said anything on the issue?

(My Cosmo is scheduled to be delivered tomorrow, but I won't be able to set it up and transfer everything from my Gemini without having rooted Android… At first glance, the above posts looks pretty daunting; I'd be much happier if Planet provided downloadable firmware for the Cosmo, the way they did for the Gemini — after a lot of pain, I know how to use that!)


It's not as bad as it looks above. That was mostly just work when we were figuring out how to get root working. Right now the process is just to unlock the bootloader (which will wipe the device) & either backup & modify your own boot.img from the device, or use the already Magisk'ed one that ZimbiX has posted.

I'm waiting for those recovery images too. Hopefully will have some time this weekend to make a proper backup, so I have something to restore if I ended up doing harm to my device with root. That's part of the reason I haven't done anything crazy with root right now.

QUOTE(MadAdy @ Nov 26 2019, 06:11 PM) *
Hi owners, FYI Bootloader Unlock is in Developer Options.

Tap on Build Number in About Phone.


Also need to then boot to the bootloader & run `fastboot flashing unlock`. The button(s) in the fingerprint scanner worked as volume keys to confirm I wanted to unlock (& wipe the device in the process).

Posted by: NormMonkey Nov 27 2019, 08:12 AM

QUOTE(xopher @ Nov 26 2019, 12:10 PM) *
I'm pretty sure since bootloader is unlocked NFC payments are out of the question since the device is "untrusted", it is possible your banking apps may no run on it post bootloader unlock since you broke the trust (if the app checks for that sort of thing). This is something to consider before unlocking ("tampering") with bootloader, you know your use case.

I might be wrong but thought I'd throw that last bit out there since no one else mentioned it. An LG Watch I had became ineligible for NFC payment until I reverted it back to "natural" state and Samsung has Knox, all the same principal, and I could be wrong.


I thought that was the Magisk advantage, it supposedly allows Google SafetyNet and other tamper checks to pass so that various secured apps like Google Pay still work.
I haven't tried this yet. Perhaps others can clarify if the Magisk'd image is indeed passing checks?
Big thanks to everyone working on this!

Posted by: v3ritas Nov 27 2019, 08:28 AM

QUOTE(NormMonkey @ Nov 27 2019, 11:12 AM) *
QUOTE(xopher @ Nov 26 2019, 12:10 PM) *
I'm pretty sure since bootloader is unlocked NFC payments are out of the question since the device is "untrusted", it is possible your banking apps may no run on it post bootloader unlock since you broke the trust (if the app checks for that sort of thing). This is something to consider before unlocking ("tampering") with bootloader, you know your use case.

I might be wrong but thought I'd throw that last bit out there since no one else mentioned it. An LG Watch I had became ineligible for NFC payment until I reverted it back to "natural" state and Samsung has Knox, all the same principal, and I could be wrong.


I thought that was the Magisk advantage, it supposedly allows Google SafetyNet and other tamper checks to pass so that various secured apps like Google Pay still work.
I haven't tried this yet. Perhaps others can clarify if the Magisk'd image is indeed passing checks?
Big thanks to everyone working on this!


I'll get Google Pay installed on mine to check, but it's passing from within Magisk Manager. Will be a problem if the app specifically checks the bootloader status though.

EDIT: Looks like mine is fine with Google Pay. Didn't finish verifying my card, but was able to get up to that part. No notifications about it being blocked because of root.

 

Posted by: gidds Nov 27 2019, 02:25 PM

QUOTE(v3ritas @ Nov 27 2019, 12:13 PM) *
It's not as bad as it looks above. That was mostly just work when we were figuring out how to get root working. Right now the process is just [...]

I'm afraid that's as far as I understood... sad.gif

I've read the previous posts, but they didn't mean much to me because I don't know how to 'unlock the bootloader', nor what adb or fastboot are or how you use them.? (I've gained access to the developer options by clicking seven times on Settings -> System -> Advanced -> About phone -> Build number, but I can't see anything relevant in there.)

Can anyone describe in foolproof terms exactly what to do to get root access on my Cosmo?? (By which I mean: allow me to use 'tsu' to get a root shell in Termux, which is the only thing I need it for so far.)

I have a Mac running macOS, which I suspect is not supported by anything you're likely to be talking about.? (No access to Windows.)? I also have a stick set up letting me boot into Debian, along with the SP Flash Tool from MediaTek and the other bits and pieces that I've successfully used to flash my Gemini.? I documented that process in lots of detail in https://developer.planetcom.co.uk/showthread.php?tid=39&pid=323#pid323.

If anyone could explain in a similar level of detail how to do the same to my Cosmo, I expect I wouldn't be the only grateful person smile.gif

Also: having done so, can we tell how it might interact with future firmware updates (whether Over-The-Air or downloadable from the Planet support site)?

Posted by: Robert Nov 28 2019, 07:19 AM

QUOTE(v3ritas @ Nov 27 2019, 07:13 AM) *
QUOTE(gidds @ Nov 26 2019, 02:35 PM) *
QUOTE(AP756 @ Nov 25 2019, 08:15 PM) *
We'll know when the Planet Computers solution of rooting is published.

Is that definitely ‘when’, rather than ‘if’? Have they said anything on the issue?

(My Cosmo is scheduled to be delivered tomorrow, but I won't be able to set it up and transfer everything from my Gemini without having rooted Android… At first glance, the above posts looks pretty daunting; I'd be much happier if Planet provided downloadable firmware for the Cosmo, the way they did for the Gemini — after a lot of pain, I know how to use that!)


It's not as bad as it looks above. That was mostly just work when we were figuring out how to get root working. Right now the process is just to unlock the bootloader (which will wipe the device) & either backup & modify your own boot.img from the device, or use the already Magisk'ed one that ZimbiX has posted.

I'm waiting for those recovery images too. Hopefully will have some time this weekend to make a proper backup, so I have something to restore if I ended up doing harm to my device with root. That's part of the reason I haven't done anything crazy with root right now.

QUOTE(MadAdy @ Nov 26 2019, 06:11 PM) *
Hi owners, FYI Bootloader Unlock is in Developer Options.

Tap on Build Number in About Phone.


Also need to then boot to the bootloader & run `fastboot flashing unlock`. The button(s) in the fingerprint scanner worked as volume keys to confirm I wanted to unlock (& wipe the device in the process).


I'm having trouble getting this to work. I did do the bootloader unlock procedure above. When I boot to the bootloader and run `fastboot flashing unlock` it hangs with `< waiting for any device >`.

Also, `fastboot devices` returns a blank line, and `adb devices` returns what appears to be a device identifer, followed by the word `unauthorized`.

For what it's worth, when I boot into regular Android, `adb devices` returns the device code and the word `device` -- meaning the devices is apparently `authorized` after a normal boot, but not in bootloader.

Any ideas?

Thanks!


Posted by: Ignatz Nov 29 2019, 02:15 PM

QUOTE(Robert @ Nov 28 2019, 04:19 PM) *
QUOTE(v3ritas @ Nov 27 2019, 07:13 AM) *
QUOTE(gidds @ Nov 26 2019, 02:35 PM) *
QUOTE(AP756 @ Nov 25 2019, 08:15 PM) *
We'll know when the Planet Computers solution of rooting is published.

Is that definitely ‘when’, rather than ‘if’? Have they said anything on the issue?

(My Cosmo is scheduled to be delivered tomorrow, but I won't be able to set it up and transfer everything from my Gemini without having rooted Android… At first glance, the above posts looks pretty daunting; I'd be much happier if Planet provided downloadable firmware for the Cosmo, the way they did for the Gemini — after a lot of pain, I know how to use that!)


It's not as bad as it looks above. That was mostly just work when we were figuring out how to get root working. Right now the process is just to unlock the bootloader (which will wipe the device) & either backup & modify your own boot.img from the device, or use the already Magisk'ed one that ZimbiX has posted.

I'm waiting for those recovery images too. Hopefully will have some time this weekend to make a proper backup, so I have something to restore if I ended up doing harm to my device with root. That's part of the reason I haven't done anything crazy with root right now.

QUOTE(MadAdy @ Nov 26 2019, 06:11 PM) *
Hi owners, FYI Bootloader Unlock is in Developer Options.

Tap on Build Number in About Phone.


Also need to then boot to the bootloader & run `fastboot flashing unlock`. The button(s) in the fingerprint scanner worked as volume keys to confirm I wanted to unlock (& wipe the device in the process).


I'm having trouble getting this to work. I did do the bootloader unlock procedure above. When I boot to the bootloader and run `fastboot flashing unlock` it hangs with `< waiting for any device >`.

Also, `fastboot devices` returns a blank line, and `adb devices` returns what appears to be a device identifer, followed by the word `unauthorized`.

For what it's worth, when I boot into regular Android, `adb devices` returns the device code and the word `device` -- meaning the devices is apparently `authorized` after a normal boot, but not in bootloader.

Any ideas?

Thanks!



I had the same Problems, found the solution with some help.

You need to install Google USB Drivers.

If that doesent help, reboot to fastboot and go to your device manager.

Locate your cosmo (For me it said it cant find driver, and was just namend "Android")

Update the driver through the driver manager, and select the google ubs driver (download it manually if needed)

If it cant autodetect it, select it manually and choose "Bootloader Interface"

After thet you should be able to use fastboot command.

Kind Regards,
Ignatz

Posted by: AP756 Dec 2 2019, 11:24 AM

The driver problem is solved by installing the MTK driver package MTK_USB_All_v1.0.8 (you'll find that on Inet).

When Cosmo is booted goto Settings -> System -> Advanced -> Developer options and enable USB debugging (If there is no developer options goto About phone and tap 7 times on Build number). Now start a CMD window (as administrator) and connect Cosmo. You'll be prompted with a message where you'll be asked to authorize the USB debugging connection. Do so and then issue the command "adb devices". It should prompt you with your device name without unautorized.

Bye for now Fred

Posted by: TauPan Dec 6 2019, 02:18 PM

QUOTE(ZimbiX @ Nov 17 2019, 05:52 PM) *
At a glance, this looks quite interesting - using a 'Wwr MTK tool' to create a full backup of the device: https://forum.hovatek.com/thread-21970.html
I don't have any more time to look into this for a while! =\


I'm just dumping my Cosmo following this howto.

The only stumbling block so far was that the "memory check" method of determining the dump length does not work with recent SP flash tool so you have to use the method of loading the incomplete dump of the EMMC_USER partition and let Wwr analyze it to determine the length.

(That and my wife's windows laptop was set to 125% magnification so I could not see some buttons in the Wwr tool at first.)

Dumping takes loooong... the full 128MB + system partitions are being dumped. My hope is that if I re-flash all of this after unlocking the bootloader via "fastboot flashing unlock" I can get *all* my data back.

I'm not quite sure how to verify the dump other than flashing it. I guess I'll just have to trust Smartphone Flash Tool from MTK. After all it's a tool from the chipset vendor. They should know what they're doing.

I'd certainly appreciate input on this.

Posted by: TauPan Dec 6 2019, 02:38 PM

QUOTE(TauPan @ Dec 7 2019, 01:18 AM) *
QUOTE(ZimbiX @ Nov 17 2019, 05:52 PM) *
At a glance, this looks quite interesting - using a 'Wwr MTK tool' to create a full backup of the device: https://forum.hovatek.com/thread-21970.html
I don't have any more time to look into this for a while! =\


I'm just dumping my Cosmo following this howto.

The only stumbling block so far was that the "memory check" method of determining the dump length does not work with recent SP flash tool so you have to use the method of loading the incomplete dump of the EMMC_USER partition and let Wwr analyze it to determine the length.

(That and my wife's windows laptop was set to 125% magnification so I could not see some buttons in the Wwr tool at first.)

Dumping takes loooong... the full 128MB + system partitions are being dumped. My hope is that if I re-flash all of this after unlocking the bootloader via "fastboot flashing unlock" I can get *all* my data back.

I'm not quite sure how to verify the dump other than flashing it. I guess I'll just have to trust Smartphone Flash Tool from MTK. After all it's a tool from the chipset vendor. They should know what they're doing.

I'd certainly appreciate input on this.


Oh dear, it appears I've missed some pages here. I'm not used to reading forums any more.

Well, I'll compare my scatter file to ZimbiX's (I expect them to be identical). Indeed using the scatter file in SP flash tool seems to be an easier for dump + restore.

I'd still like to know if my hunch is correct that I can reflash (most of) my backup after unlocking the bootloader (perhaps excluding the bootloader itself?) to regain my data?

Regarding Magisk there is *one* addon I use on my other phone to fool netflix *and* my banking software. I think it's magisk hide props config, but I'd need to boot the phone to be sure. This needs busybox for magisk to work.

Posted by: ZimbiX Dec 6 2019, 10:43 PM

QUOTE(TauPan @ Dec 7 2019, 09:38 AM) *
Well, I'll compare my scatter file to ZimbiX's (I expect them to be identical). Indeed using the scatter file in SP flash tool seems to be an easier for dump + restore.

I'd still like to know if my hunch is correct that I can reflash (most of) my backup after unlocking the bootloader (perhaps excluding the bootloader itself?) to regain my data?


Mmm, I'd been wondering that too. I'd tried to restore my data after unlocking the bootloader by flashing the data partition using SP Flash Tool with my data partition image, but it didn't work properly afterwards, with Android saying something like "Unable to decrypt user data partition" and showing a button to factory reset. I couldn't find any info on doing this - I'd imagine it's not a common thing to be able to get a dump of a device before unlocking the bootloader, so maybe people just haven't investigated it.

The encryption key must be stored separately to the encrypted data, so it's probably on a different partition. I was wondering if unlocking might be generating a new key to ensure security of the original data. I'd only flashed the data partition back, so maybe it would have worked if I'd flashed more. Or maybe processing of the same key is altered/incompatible between locked and unlocked.

I'd split out the data partition from my full backup using WwR rather than doing a readback with SP Flash Tool once I had the scatterfile, so the problem could be with that, but I'd hope not.

I hadn't done much setup on it before unlocking, so I ended up factory resetting.

Oh, and regarding payment for WwR, I'd found the dev's PayPal address in the HTML source of the donation prompt. I tried sending the money, but PayPal was blocking the transaction for some reason. I emailed vvaaavv about it on Nov 22 to ask if he'd accept another form of payment such as Bitcoin, but he hasn't responded (yet). I'm all for financially supporting development efforts, but at this point I'm getting more tempted to reverse engineer the thing to disable the timeouts =P

Posted by: ZimbiX Dec 6 2019, 10:51 PM

TauPan, if you can't work it out and need to factory reset, I tweeted about the process I used to transfer my data: https://twitter.com/ZimbiX/status/1202220166446080000

Posted by: TauPan Dec 7 2019, 01:42 AM

QUOTE(ZimbiX @ Dec 7 2019, 09:51 AM) *
TauPan, if you can't work it out and need to factory reset, I tweeted about the process I used to transfer my data: https://twitter.com/ZimbiX/status/1202220166446080000


I'm a tiny bit confused now.

From re-reading all the previous posts in this thread and you tweet, it appears to me that:

- We can modify the boot image on device with magisk and flash that via SP flash
- But it won't boot, ,if the bootloader is still locked, so the device will reject it?
- fastboot flashing unlock will delete all data

(The last part seems pointless if SP flash tool provides low level access to all the data anyway. But you can confirm that unlocking the bootloader will remove all user data?)

My use-case is that I've spent the previous two weeks to get my cosmo set up properly, so I'd really like to have a working backup of the cosmo.

Most of the stuff from my previous daily driver (Nexus 6p) is backed up with Titanium, which apparently doesn't work properly in some cases.
Both Titanium and Swift backup won't be able to backup app data if the device isn't rooted.

I do have a full backup of my user data now, but it's encrypted.

Maybe I should just try to dump everything with the scatter file, do a factory reset (unlock the bootloader) and then try to reflash everything. If that doesn't work I'll just go through the setup process again. I do have most stuff in the cloud anyway, it's mostly just busywork getting it all back, setting up accounts, etc.

(And in some cases, request account verifycation codes via snail mail, from banks, insurances, etc.)


Posted by: ZimbiX Dec 7 2019, 08:19 AM

Oh, I'm sorry, I was mixed up!

You might have luck with https://play.google.com/store/apps/details?id=com.koushikdutta.backup, or using https://9to5google.com/2017/11/04/how-to-backup-restore-android-device-data-android-basics/ (which is what Helium uses). That used to be a great way to keep appdata when unlocking the bootloader, but sadly, nowadays a bunch of apps block themselves from being backed up this way.

Do a backup with that before trying the full reflash just in case it doesn't work. But I'm keen to hear whether it does! biggrin.gif Good luck

Titanium restores of just appdata once you've already installed the app would probably work actually.

Woah, having to get verification codes by snail mail is nuts! I guess I'm lucky I've never had to do that

Posted by: TauPan Dec 7 2019, 10:05 AM

QUOTE(ZimbiX @ Dec 7 2019, 07:19 PM) *
Oh, I'm sorry, I was mixed up!

You might have luck with https://play.google.com/store/apps/details?id=com.koushikdutta.backup, or using https://9to5google.com/2017/11/04/how-to-backup-restore-android-device-data-android-basics/ (which is what Helium uses). That used to be a great way to keep appdata when unlocking the bootloader, but sadly, nowadays a bunch of apps block themselves from being backed up this way.

Do a backup with that before trying the full reflash just in case it doesn't work. But I'm keen to hear whether it does! biggrin.gif Good luck

Titanium restores of just appdata once you've already installed the app would probably work actually.

Woah, having to get verification codes by snail mail is nuts! I guess I'm lucky I've never had to do that


Yeah, quite a lot of apps block adb backups. I got a list created with Adebar. Also adb backup is quite annoying because you have to keep the screen awake or disable auto-locking. If I have to make a list of what to backup how, I might as well set up everything again.

Btw. How did you manage to extract the user data partition with WwR? Every way I cut my dump, the user data is always missing from the result. I think I'll try a readback with SP flash tool with the full scatter file this evening.

Account verification via snail mail is slow, but beats someone stealing your money along by stealing your phone number.

Posted by: ZimbiX Dec 7 2019, 10:13 AM

QUOTE(TauPan @ Dec 8 2019, 05:05 AM) *
Yeah, quite a lot of apps block adb backups. I got a list created with Adebar. Also adb backup is quite annoying because you have to keep the screen awake or disable auto-locking. If I have to make a list of what to backup how, I might as well set up everything again.


Mmm, fair enough. I'm glad I haven't needed to do it in a long time.

QUOTE(TauPan @ Dec 8 2019, 05:05 AM) *
Btw. How did you manage to extract the user data partition with WwR? Every way I cut my dump, the user data is always missing from the result. I think I'll try a readback with SP flash tool with the full scatter file this evening.


Yeah, I don't understand why. The descriptions are misleading. I'd ended up using its cutting tool and supplied the offsets manually. It was really slow though - like 2MB/s. Readback's probably a better idea, actually, for speed. And takes any potential issues with that WwR process out of the picture.

QUOTE(TauPan @ Dec 8 2019, 05:05 AM) *
Account verification via snail mail is slow, but beats someone stealing your money along by stealing your phone number.


Hah. But what about stealing your mail? tongue.gif

Posted by: Robert Dec 8 2019, 06:29 PM

QUOTE(Ignatz @ Nov 29 2019, 05:15 PM) *
QUOTE(Robert @ Nov 28 2019, 04:19 PM) *
QUOTE(v3ritas @ Nov 27 2019, 07:13 AM) *
QUOTE(gidds @ Nov 26 2019, 02:35 PM) *
QUOTE(AP756 @ Nov 25 2019, 08:15 PM) *
We'll know when the Planet Computers solution of rooting is published.

Is that definitely ‘when’, rather than ‘if’? Have they said anything on the issue?

(My Cosmo is scheduled to be delivered tomorrow, but I won't be able to set it up and transfer everything from my Gemini without having rooted Android… At first glance, the above posts looks pretty daunting; I'd be much happier if Planet provided downloadable firmware for the Cosmo, the way they did for the Gemini — after a lot of pain, I know how to use that!)


It's not as bad as it looks above. That was mostly just work when we were figuring out how to get root working. Right now the process is just to unlock the bootloader (which will wipe the device) & either backup & modify your own boot.img from the device, or use the already Magisk'ed one that ZimbiX has posted.

I'm waiting for those recovery images too. Hopefully will have some time this weekend to make a proper backup, so I have something to restore if I ended up doing harm to my device with root. That's part of the reason I haven't done anything crazy with root right now.

QUOTE(MadAdy @ Nov 26 2019, 06:11 PM) *
Hi owners, FYI Bootloader Unlock is in Developer Options.

Tap on Build Number in About Phone.


Also need to then boot to the bootloader & run `fastboot flashing unlock`. The button(s) in the fingerprint scanner worked as volume keys to confirm I wanted to unlock (& wipe the device in the process).


I'm having trouble getting this to work. I did do the bootloader unlock procedure above. When I boot to the bootloader and run `fastboot flashing unlock` it hangs with `< waiting for any device >`.

Also, `fastboot devices` returns a blank line, and `adb devices` returns what appears to be a device identifer, followed by the word `unauthorized`.

For what it's worth, when I boot into regular Android, `adb devices` returns the device code and the word `device` -- meaning the devices is apparently `authorized` after a normal boot, but not in bootloader.

Any ideas?

Thanks!



I had the same Problems, found the solution with some help.

You need to install Google USB Drivers.

If that doesent help, reboot to fastboot and go to your device manager.

Locate your cosmo (For me it said it cant find driver, and was just namend "Android")

Update the driver through the driver manager, and select the google ubs driver (download it manually if needed)

If it cant autodetect it, select it manually and choose "Bootloader Interface"

After thet you should be able to use fastboot command.

Kind Regards,
Ignatz



Ignatz,

Thanks for the ideas. I tried to post a reply several days ago, but apparently it didn't get through.

I found what I thought were Google USB drivers here: https://developer.android.com/studio/run/win-usb

And I tried to install them using the instructions here: https://developer.android.com/studio/run/oem-usb.html#InstallingDriver (for Win10).

The install utility always said that I already had "the most up to date drivers" installed, and when I told it to install anyway (even using the "Have disk" option to point it to the right place) kept insisting that there weren't any drivers there.

So, I am back where I started.

--Robert


Posted by: TauPan Dec 9 2019, 01:25 AM

QUOTE(ZimbiX @ Nov 21 2019, 03:51 PM) *
Good news, everyone!


What is it, professor? wink.gif

QUOTE(ZimbiX @ Nov 21 2019, 03:51 PM) *
I've attached the scatterfile for anyone else interested in playing around biggrin.gif


As promised, I have compared your scatterfile with the one I got from analyzing the EMMC_BOOT_1 and EMMS_USER areas with WwR.

Surprisingly I have found a difference between the two, which may be significant:

Yours gives:

partition_size: 0x100000

and mine:

partition_size: 0x40000

for the preloader partition.

I think mine is correct (Edit: Spoiler: I was wrong about this!), because when I have SP Flash Tool (latest version) connected to the Cosmo, it gives:

Boot 1 Size: 0x40000
Boot 2 Size: 0x40000
RPMB Size: 0x1000000
GP(1-4) Size: 0x0
UA Size: 0x1d1f000000

Actually that last number is the coveted size for the full EMMS_USER dump with WwR, so it appears there are easier ways if you just want to get just that number than running WwR.

Any idea what RPMB Size is?

However, WwR has proved invaluable to get that scatter file. I've come across some other tools to analyze the partial dumps via google, but didn't really take a closer look, because SP Flash Tool only works on windows for me, and for CLI/programming stuff I strongly prefer Linux.

I now have the full readback of the cosmo, done with SP Flash tool and I'm going to just root it. I'll see if I can recover the userdata.img afterwards, but I doubt it which is why I just updated all the app backups I could round up.

(Final thought: There's a reserved partition called OTP, which apparently cannot be read back with SP flash tool. OTP refers to "One Time Pad" in cryptographic terms. I didn't check the android developer documentation on that so this is just a guess, but if that partition is used as a one-time-pad for encrypting userdata and it is reset while unlocking the bootloader, there's not a chance in hell you could use the encrypted userdata.img dumped with the previous OTP. Hm... Maybe I should try to read back the reserved partitions by putting in the numbers. I'm going to try that now, before resetting. But maybe the data will be incompatible for other reasons.)

Posted by: TauPan Dec 9 2019, 02:52 AM

QUOTE(TauPan @ Dec 9 2019, 12:25 PM) *
RPMB Size: 0x1000000


Replay Protected Memory Block, apparently.

QUOTE(TauPan @ Dec 9 2019, 12:25 PM) *
(Final thought: There's a reserved partition called OTP, which apparently cannot be read back with SP flash tool. OTP refers to "One Time Pad" in cryptographic terms. I didn't check the android developer documentation on that so this is just a guess, but if that partition is used as a one-time-pad for encrypting userdata and it is reset while unlocking the bootloader, there's not a chance in hell you could use the encrypted userdata.img dumped with the previous OTP. Hm... Maybe I should try to read back the reserved partitions by putting in the numbers. I'm going to try that now, before resetting. But maybe the data will be incompatible for other reasons.)


On Google I only found a reference to a part of the linux kernel config with support for "One Time Programming" area. See https://android.googlesource.com/kernel/mediatek/+/android-mtk-3.18/drivers/mmc/host/Kconfig#37

Both of these may or may not have anything to do with encryption of userdata. I obviously lack the knowledge and I don't even know where to look wink.gif

I've rooted my Cosmo now and I'm just downloading the userdata.img to the device. I get a constant 30MB/s and it's at 52% currently, so it should take another half hour or so, until I know if that worked.

(Funny thing: I can only use SP flash tool from windows and fastboot only works on linux for me. I even tried installing the google drivers on the windows laptop, as suggested here, but fastboot would still not find the cosmo.)

Posted by: TauPan Dec 9 2019, 03:03 AM

Hm... wondering if this might work on newer MediaTek devices as well: https://forum.xda-developers.com/hd8-hd10/orig-development/fire-hd-8-2018-downgrade-unlock-root-t3894256/post78774211#post78774211 ... but no need to do this kind of funny stuff to the Cosmo, since we'll get a signed rooted android image at some point, so we can lock the bootloader again. (Linked from here http://www.lieberbiber.de/2015/07/04/mediatek-details-partitions-and-preloader/ found while searching for RPMB Mediatek.)

Posted by: TauPan Dec 9 2019, 07:58 AM

Ok, I did it, apparently!

Process is:

- Get scatter file (see attachment)
- Take full Readback of all partitions (all possible are enabled in scatter file)
- fastboot flashing unlock (wiping all data)
- Download all partitions except *drumroll* seccfg along with boot-magisk.img (see other post)

Edit: Important point: You can't take OTA updates if you modified any partitions this way. So at least you must revert to your original boot partition before taking an update!

To clarify: flash everything with SP flashing tool *except* seccfg and *do* flash the magisk-modified root image, then reboot!

Takes an hour for me, and now I have all my data on a rooted cosmo.

(Edit: Nonsense... Apparently my Fingerprint Data *and* my Password are still as they were. Wondering what else seccfg contains, as the partition is not very small.)

I almost completely ruined my work productivity for this today, but that was totally worth it wink.gif

(Edit: Attachment deleted, see corrected version below.)

Posted by: TauPan Dec 9 2019, 01:05 PM

I need to say that I figured this out by trial and error. When I tried to find information on this, I either found documents that were very vague, or that made no sense without appropriate background knowledge.

When I ticked *all* partitions in SP flash tool, I got "verified boot is enabled" at some point during the flashing (Download) process, so apparently one partition re-enabled secure boot (locked bootloader). But apparently the error did not occur directly after flashing the partition which reset the bootloader.

So if I flash everything including stock boot.img, I can get back to stock, without a trace of root.

And then I flashed the partitions one my one, noting which one would cause the error to appear.

Point of note: It's enough to unplug the device while it is in download mode in order to flash the next partition, which makes this process a bit faster.

Everything went well when I left out seccfg.img until I came to userdata.img. Then I rebooted and got all my configuration back, installed Magisk Manager, which said that magisk was already installed. \o/

Quick test in termux confirmed I had root.

I don't have the slightest idea what all these partitions contain, other that the names give hints in some cases. I also don't know what seccfg contains. Maybe it would be wortwhile to read back seccfg now and do a binary comparision with the stock version.

So you might be able to get your userdata back, if you reflash just the right partition(s) together with userdata. I suspect it may be the ones named "tee.." and/or "*sec*", maybe others. (See https://source.android.com/security/trusty ... Also see http://www.lieberbiber.de/2015/07/04/mediatek-details-partitions-and-preloader/ )

QUOTE(TauPan @ Dec 9 2019, 06:58 PM) *
ossible are enabled in scatter file)
- fastboot flashing unlock (wiping all data)
- Download all partitions except *drumroll* seccfg along with boot-magisk.img (see other post)

To clarify: flash everything with SP flashing tool *except* seccfg and *do* flash the magisk-modified root image, then reboot!


Downloading / readback takes 60 - 90 minutes for me with constant 30 M/s. ("M/s" is from the SP flash tool.)

Posted by: AP756 Dec 10 2019, 05:29 AM

This morning Planet Computers announced an update for the Cosmo. It will include

1. TWRP (Team Win Recovery Project)
2. Debian using KDE/Plasma
3. Debian using LXQT
4. Rooted Android

( https://www.indiegogo.com/projects/cosmo-communicator/x/17943959#/updates/all )

According to the message on Indiegogo we can expect the update within the next days...

Bye for now Fred

Posted by: TauPan Dec 10 2019, 05:39 AM

QUOTE(AP756 @ Dec 10 2019, 04:29 PM) *
This morning Planet Computers announced an update for the Cosmo. It will include

1. TWRP (Team Win Recovery Project)
2. Debian using KDE/Plasma
3. Debian using LXQT
4. Rooted Android

( https://www.indiegogo.com/projects/cosmo-communicator/x/17943959#/updates/all )

According to the message on Indiegogo we can expect the update within the next days...


I think "In this update we would like to discuss plans regarding Linux support on the Cosmo Communicator." and "First Cosmo Firmware update - this week!" mean something different regarding the timeline.

We'll see if the firmware update this week already includes support for TWRP, linux and rooted android. That's not the way I understood those messages, though.

Edit: The output from the partition editor looks really cool, though. They're using parted to resize the partitions, which I think means that you can try out linux variants without losing data on your android installation. This would be really nice!

Posted by: ZimbiX Dec 10 2019, 06:55 AM

Wow, TauPan, that's great research! Thanks so much for your work. I'm sure that process will be extremely useful for a great many Cosmo users biggrin.gif

I had the same issue with fastboot, where that would only work on Linux for me. I'm not sure what Windows driver I was using - probably the one they supplied for the Gemini way back. No biggie for me, but I'm hoping others don't have too much trouble.

Not to get too off-topic: I'm looking forward to Planet's OTA and Linux news, but I expect a Linux release will not be provided for a good while. The screenshots are encouraging, and I'm impressed to see we might be able to have TWRP installed simultaneously with the expanded stock recovery. Keep up the good work, those working on Linux support happy.gif

Posted by: TauPan Dec 11 2019, 12:34 PM

A word of warning:

Yesterday I tried to reflash my cosmo because I thought this might fix the main display issue from another thread. (Not thinking very clearly apparently. I was in a bit of panic.) (Edit: Talking about this issue: https://www.oesf.org/forum/index.php?s=&showtopic=35944&view=findpost&p=293139 )

I did this with the preloader.bin that I read back using my scatter file. This gives the error:

preloader format invalid

from SP flash tool.

I thought I had bricked my cosmo, because it had spontaneously rebooted during flash.

Just now I tried again with the preloader file that fell out of the WwR analysis of the EMMC_BOOT_1 partition and this just worked.

The preloader.bin from WwR is just a tiny bit longer than the one from the readback (just a few bytes). Not sure what might have caused this, but be extra careful! Maybe my scatter file is not exactly correct, but it is consistent with the output from SP flash tool itself.

The display issue is very bad for me though, my Cosmo is completely unusable since yesterday afternoon. I filed an issue in the Cosmo support sheet sad.gif

Wish me luck!

Posted by: TauPan Dec 12 2019, 04:22 AM

Ok, this inconsistency is bugging me, so I did a tiny analysis:

The preloader.bin that WwR generated out of the EMMC_BOOT_1 block dump has the following characteristics:

271540 bytes, 0x424B4 sha256sum: a4f77dc5392620f8743ef15ed3bc89e11c10ae6cdb6e5768a78d440cfda53763

As 0x424B4 is clearly quite a bit longer than 0x40000 (exactly 256K), my scatter file is wrong, and the (exactly 0x4000 bytes long) preloader.bin file from doing a readback with my scatter file is too short.

I wonder how WwR arrived at that value of 0x400000 for me... My initial (empty) scatter file had 0x800000 as preloader partition size.

It appears the initial (empty) scatter file has 0x800000, the scatter file from the analysis of the partial dump in WwR has 0x400000 and the scatter file from the analysis of the full dump has 0x1000000 (the complete size of the RPMB area, but I'm not sure if that's related).

Attaching the correct scatter file. (The only change: partition size goes up from 0x400000 (256K) to 0x1000000).

Also for anyone attempting the same: Be sure to dump seccfg after unlocking the bootloader. Flashing the unlocked seccfg partition is quite a bit more convenient than having to go through fastboot again (e.g. after accidentally flashing the locked one). wink.gif

And another important thing: I can only flash my dumps with an unlocked bootloader. Apparently the files from the readback do not contain the verification signature or whatever, so SP flash tool complains that they're not verified if I try to flash them if the bootloader is locked!

QUOTE(TauPan @ Dec 11 2019, 11:34 PM) *
A word of warning:

Yesterday I tried to reflash my cosmo because I thought this might fix the main display issue from another thread. (Not thinking very clearly apparently. I was in a bit of panic.) (Edit: Talking about this issue: https://www.oesf.org/forum/index.php?s=&showtopic=35944&view=findpost&p=293139 )

I did this with the preloader.bin that I read back using my scatter file. This gives the error:

preloader format invalid

from SP flash tool.

I thought I had bricked my cosmo, because it had spontaneously rebooted during flash.

Just now I tried again with the preloader file that fell out of the WwR analysis of the EMMC_BOOT_1 partition and this just worked.

The preloader.bin from WwR is just a tiny bit longer than the one from the readback (just a few bytes). Not sure what might have caused this, but be extra careful! Maybe my scatter file is not exactly correct, but it is consistent with the output from SP flash tool itself.

The display issue is very bad for me though, my Cosmo is completely unusable since yesterday afternoon. I filed an issue in the Cosmo support sheet sad.gif

Wish me luck!


 Cosmo_MT6771_Android_full_stock_edited_scatter.txt ( 17.7K ) : 15
 

Posted by: TheProfessorNQ Dec 12 2019, 07:18 AM

Yesterday, while applying the android firmware update via OTA, I invoked some kind of ancient magic that got my Cosmo stuck in an endless boot loop. Key/button presses were of no help. I was boot loader unlocked and rooted. After the first two failed attempts at the OTA, I flashed the original boot.img back to the device via fastboot. Cosmo booted right up. This time, attempting the OTA seemed successful until it did its restart after updating.

Begin the endless boot loop. Attempts to power on. Shows only the splash screen with the unlocked bootloader unsafe whatever - not the boot animation. 5 seconds pass. Goes black for something like 7 seconds. Powers back on. Repeat until dead.

Then I learned about using SP Flash Tool, downloaded the scatter file from here and tried re-flashing the stock boot image that way. Now I get no screen display, but the SP Flash tools can, at least, still connect.

Hoping with growing desperation that someone may have some suggestions. I'm no fool when it comes to tech stuffs, but this is a little outside my usual realm these days.

Thanks!
-Prof

Posted by: TauPan Dec 12 2019, 10:21 AM

QUOTE(TheProfessorNQ @ Dec 12 2019, 06:18 PM) *
Yesterday, while applying the android firmware update via OTA, I invoked some kind of ancient magic that got my Cosmo stuck in an endless boot loop. Key/button presses were of no help. I was boot loader unlocked and rooted. After the first two failed attempts at the OTA, I flashed the original boot.img back to the device via fastboot. Cosmo booted right up. This time, attempting the OTA seemed successful until it did its restart after updating.

Begin the endless boot loop. Attempts to power on. Shows only the splash screen with the unlocked bootloader unsafe whatever - not the boot animation. 5 seconds pass. Goes black for something like 7 seconds. Powers back on. Repeat until dead.

Then I learned about using SP Flash Tool, downloaded the scatter file from here and tried re-flashing the stock boot image that way. Now I get no screen display, but the SP Flash tools can, at least, still connect.

Hoping with growing desperation that someone may have some suggestions. I'm no fool when it comes to tech stuffs, but this is a little outside my usual realm these days.


Oh dear! Looks like we broke the OTA upgrade. I've read in another thread that another rooted user managed to upgrade by completely reverting (flashing original boot and locking the bootloader) before upgrading.

I'd be able to provide the original firmware files from my dump, but I see several potential problems here:

1.) I read in you other post that you have a Verizon device. I have a European one. I don't know if the firmware files are completely compatible.
2.) I'm not sure if it's ok to attach them to this forum wrt. Copyright and forum rules. It may be, because they're publically downloadable anyways and we did not reverse engineer them or anything.
3.) I'm not 100% confident that my dumps are ok, as I already had problems with preloader.bin having the wrong length. Maybe Zimbix and I could compare checksums.

In turn, I would be very interested in your unlocked seccfg partition (see my scatter file) as I have unlocked myself and my display is broken and the Cosmo doesn't boot.

I think 2. is pretty much a non issue, so I can provide the files with checksums later. Maybe someone can shed some light if the files are compatible. We don't want to make the bricks worse than they already are.

Posted by: TheProfessorNQ Dec 12 2019, 05:07 PM

QUOTE(TauPan @ Dec 12 2019, 01:21 PM) *
Oh dear! Looks like we broke the OTA upgrade. I've read in another thread that another rooted user managed to upgrade by completely reverting (flashing original boot and locking the bootloader) before upgrading.

I'd be able to provide the original firmware files from my dump, but I see several potential problems here:

1.) I read in you other post that you have a Verizon device. I have a European one. I don't know if the firmware files are completely compatible.
2.) I'm not sure if it's ok to attach them to this forum wrt. Copyright and forum rules. It may be, because they're publically downloadable anyways and we did not reverse engineer them or anything.
3.) I'm not 100% confident that my dumps are ok, as I already had problems with preloader.bin having the wrong length. Maybe Zimbix and I could compare checksums.

In turn, I would be very interested in your unlocked seccfg partition (see my scatter file) as I have unlocked myself and my display is broken and the Cosmo doesn't boot.

I think 2. is pretty much a non issue, so I can provide the files with checksums later. Maybe someone can shed some light if the files are compatible. We don't want to make the bricks worse than they already are.


Balls. I cant seem to make things happen today. No. That's not right. I can't make things happen positively. I can still connect, and it still tries flashing. I was going to attempt various pieces of the OTA update. I'd love to get you the seccfg file, but I can't seem to connect to do a readback. Ha! Finally connected for a readback while I was typing this. I am uploading a copy of thr error along with this message. Invalid preloader, or some such debauchery. Same error for both download and readback attempts. I might, at this point, be willing to try your preloader.bin, if you'd be willing.

Again, and every time,
Thank you!
-Prof

 

Posted by: PNuT Dec 12 2019, 07:23 PM

I just fastbooted the original boot img back & it upgraded fine.....

Posted by: TauPan Dec 12 2019, 11:49 PM

QUOTE(TheProfessorNQ @ Dec 13 2019, 04:07 AM) *
QUOTE(TauPan @ Dec 12 2019, 01:21 PM) *


In turn, I would be very interested in your unlocked seccfg partition (see my scatter file) as I have unlocked myself and my display is broken and the Cosmo doesn't boot.


Balls. I cant seem to make things happen today. No. That's not right. I can't make things happen positively. I can still connect, and it still tries flashing. I was going to attempt various pieces of the OTA update. I'd love to get you the seccfg file, but I can't seem to connect to do a readback. Ha! Finally connected for a readback while I was typing this. I am uploading a copy of thr error along with this message. Invalid preloader, or some such debauchery. Same error for both download and readback attempts. I might, at this point, be willing to try your preloader.bin, if you'd be willing.


On second thought, I think uploading your seccfg to a public forum might be a bad idea. It's 8MB and I don't know what else it contains, other than the flag that the bootloader is unlocked. Might be sensitive data in there.

The error message is the exact same I get when I try to flash the preloader that's too short. If you used my first scatter file to read it, then it will be too short.

I'll upload my preloader, but keep in mind that it's for a EU Wifi + 4G Cosmo.

Hm... Forum tells me "You are not permitted to upload this kind of file", even when I put it into a 7z archive. So I put into a crypted zip archive, password is "secret". sha256sum of the unzipped file is a4f77dc5392620f8743ef15ed3bc89e11c10ae6cdb6e5768a78d440cfda53763

I see no reason why your preloader image should need reflashing, so maybe:

QUOTE(PNuT @ Dec 13 2019, 06:23 AM) *
I just fastbooted the original boot img back & it upgraded fine.....


@Professor You should try just unticking the box next to the preloader image (or anything else) and just reflash the un-magisked boot.img (provided by ZimbiX earlier).



 preloader.zip ( 160.25K ) : 3
 

Posted by: TheProfessorNQ Dec 13 2019, 02:05 AM

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.

Posted by: TauPan Dec 13 2019, 10:54 AM

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

Posted by: TauPan Dec 13 2019, 10:58 AM

QUOTE(TheProfessorNQ @ Dec 13 2019, 01:05 PM) *
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=&showtopic=35879&view=findpost&p=292918 doesn't fix your problems. Maybe something else is broken.

Posted by: ZimbiX Dec 14 2019, 05:37 AM

New boot images from OTA 1

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

boot-ota1-stock.img: https://mega.nz/#!lwMAmYRZ!5HM2cvms8peRCKQ27hU8l9YbC5zTyqJYgVvnF-rQBvw
boot-ota1-magisk.img: https://mega.nz/#!50dwTYpA!KvKxUtcPRQ3aDt4MEZYtY_zQZ8ZudXi2MgRBn5mtANY

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

Posted by: ZimbiX Dec 14 2019, 06:08 AM

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

CODE
$ 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

Posted by: TauPan Dec 14 2019, 07:18 AM

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!

Posted by: Ninji Dec 14 2019, 11:37 AM

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.

Posted by: peter Dec 14 2019, 03:41 PM

QUOTE(ZimbiX @ Nov 22 2019, 12:33 AM) *
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!

Posted by: Ninji Dec 14 2019, 04:58 PM

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 https://github.com/erfanoabdi/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=12LyxhvLufT4RNDidS83kU-qKdduQFtjV

I used the following commands from bootloader mode:

CODE
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?

Posted by: TheProfessorNQ Dec 14 2019, 06:01 PM

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!

Posted by: Ninji Dec 15 2019, 05:50 AM

QUOTE(TheProfessorNQ @ Dec 15 2019, 02:01 AM) *
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
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
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 (https://github.com/dguidipc/gemini-lk-android8/blob/master/lk/platform/mt6797/env.c), 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 https://github.com/dguidipc/gemini-android-kernel-3.18/blob/56760a6e806bb4399d70626dd2e6cf22f7c9e9c1/kernel-3.18/drivers/misc/mediatek/base/power/mt6797/mt_picachu.c (same location, different format), and while the Cosmo has a https://github.com/gemian/cosmo-linux-kernel-4.4/blob/master/drivers/misc/mediatek/base/power/mt6771/mtk_picachu.c has well, it doesn't read from the para partition. There is also a https://github.com/dguidipc/gemini-android-kernel-3.18/blob/56760a6e806bb4399d70626dd2e6cf22f7c9e9c1/kernel-3.18/drivers/misc/mediatek/base/power/Kconfig 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.

Posted by: TheProfessorNQ Dec 15 2019, 06:23 AM

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

Posted by: Ninji Dec 15 2019, 06:43 AM

QUOTE(TheProfessorNQ @ Dec 15 2019, 02:23 PM) *
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...


Posted by: TheProfessorNQ Dec 15 2019, 08:23 AM

QUOTE(Ninji @ Dec 15 2019, 09:43 AM) *
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!!!

Posted by: Ninji Dec 15 2019, 09:43 AM

QUOTE(TheProfessorNQ @ Dec 15 2019, 04:23 PM) *
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...

Posted by: TheProfessorNQ Dec 15 2019, 10:02 AM

Not to worry! It has been a great instructional experience for us all! A real solid crash-course to re-learning android stuff for me. It'd been six years or so since I've had a device that wasn't super locked down (samsung flagships), and thus, fell worlds behind.

Posted by: TauPan Dec 15 2019, 12:51 PM

QUOTE(ZimbiX @ Dec 14 2019, 05:08 PM) *
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 tongue.gif



QUOTE(Ninji @ Dec 14 2019, 10:37 PM) *
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.


Ok, I finally got around to comparing those lengths and checksums and
I was a bit surprised by the results:

That's a bit strange. I have lots of mismatches. I've truncated my
images I dumped with SP flash tool and my scatter file with this
program:
https://www.unix.com/unix-for-beginners-questions-and-answers/266604-remove-truncate-trailing-nulls-file.html
(The c-programm in comment #4, not the clearly wrong tr command).

(I have backups of the untruncated versions in my Nextcloud, but I'm
very sure the program is correct and it probably hardly matters.)

Mismatches in boot_para, cache, nvdcfg, nvdata, boot_para, para,
persist are not surprising, as those are well known to contain device
specific information.

The same is probably true for expdb, frp, metadata, proinfo, protect.

sefcfg also appears to contain device specific information. (I've found a 32 byte string in the hexdump, which changes from locked to unlocked state, along with one byte which changes from 01 to 03)

Cache and userdata are highly volatile, so we don't even need to look
at them.

However my (unrooted) boot image is longer (and also has a different checksum).

I have different system and vendor images! Even the recovery is
different! Also the trustzone (tee) images differ.

The only matches I have are: cam_vpu1, 2, 3, dtbo, lk2, lk, logo,
md1dsp, md1rom, preloader, spmfw, sspm (1 and 2).

I have the following sizes and md5sums on files which would be
certainly be included in a flashable firmware:

a616f4eec2c67991587d7cedcaf7cf99 9536401 boot.img
5d684efa830778c340887ef9211db608 14789521 recovery.img
593cb99172165ed468f89ad7779d06a2 3221225472 system.img
ac95bc9994673c2e99b5d170d68474ac 897581056 vendor.img

The following are from my build.prop:

ro.product.first_api_level=28
ro.vendor.build.date=Tue Oct 29 14:01:27 CST 2019
ro.vendor.build.date.utc=1572328887
ro.vendor.build.fingerprint=Planet/Cosmo_Communicator/Cosmo_Communicator:9/PPR1.180610.011/1563439284:user/release-keys
ro.vendor.build.security_patch=2019-07-05
ro.vendor.product.cpu.abilist=arm64-v8a,armeabi-v7a,armeabi
ro.vendor.product.cpu.abilist32=armeabi-v7a,armeabi
ro.vendor.product.cpu.abilist64=arm64-v8a
# begin build properties
# autogenerated by vendor_buildinfo.sh
ro.product.board=k71v1_64_bsp
ro.board.platform=mt6771
ro.product.vendor.manufacturer=Planet
ro.product.vendor.model=Cosmo_Communicator
ro.product.vendor.brand=Planet
ro.product.vendor.name=Cosmo_Communicator
ro.product.vendor.device=Cosmo_Communicator

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)