Post by: Charlie Stross on October 12, 2019, 08:02:11 am
(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 root-only functions of t-ui launcher (https://github.com/fAndreuzzi/TUI-ConsoleLauncher/wiki/Root-commands).)
Post by: Vistaus on October 13, 2019, 04:00:09 pm
Post by: Zarhan on October 24, 2019, 03:38:56 am
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).
Post by: Vistaus on October 24, 2019, 05:36:55 am
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.
Post by: shinkamui on November 09, 2019, 02:08:37 am
Quote from: Vistaus
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...
Post by: Vistaus on November 09, 2019, 05:38:06 am
Quote from: shinkamui
Quote from: VistausDunno. 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.
Post by: gidds on November 09, 2019, 11:05:24 am
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.
Post by: ZimbiX on November 14, 2019, 08:59:52 pm
According to the official Magisk installation instructions, the app can patch an arbitrary kernel image file. https://topjohnwu.github.io/Magisk/install....-image-patching (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.
Post by: gidds on November 16, 2019, 05:26:56 am
Post by: ZimbiX on November 17, 2019, 06:49:54 am
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 =\
Post by: ZimbiX on November 17, 2019, 08:53:33 am
- 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) (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).
Post by: ZimbiX on November 17, 2019, 09:52:53 am
I don't have any more time to look into this for a while! =\
Post by: v3ritas on November 17, 2019, 04:13:16 pm
Quote from: ZimbiX
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 (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).
Post by: ZimbiX on November 17, 2019, 06:23:38 pm
Quote from: v3ritas
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 from: v3ritas
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 (https://forum.hovatek.com/thread-21839.html). It looks recently developed enough that it might just work once we extract the stock recovery image These Hovatek people are champs.
Good luck! And let us know what you learn
Post by: gidds on November 18, 2019, 04:29:03 am
Post by: v3ritas on November 18, 2019, 07:37:07 am
Quote from: ZimbiX
Quote from: v3ritasI 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 from: v3ritasDo 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 (https://forum.hovatek.com/thread-21839.html). It looks recently developed enough that it might just work once we extract the stock recovery image 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
...
? ~
Post by: v3ritas on November 18, 2019, 09:02:35 pm
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.
Post by: ZimbiX on November 21, 2019, 07:51:43 am
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
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
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 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
Post by: ZimbiX on November 21, 2019, 09:46:10 am
boot.img: https://mega.nz/#!x8lXTKjT!kXjEjYGD...36v2Tbht3a4n1yQ (https://mega.nz/#!x8lXTKjT!kXjEjYGDxrDmRLD4H5kJXjWTL1rA36v2Tbht3a4n1yQ)
boot-magisk.img: https://mega.nz/#!U8sFVACI!J-TS3q11...V1YIVDipez05BvE (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!
Post by: peter on November 21, 2019, 10:56:42 am
Quote from: ZimbiX
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!kXjEjYGD...36v2Tbht3a4n1yQ (https://mega.nz/#!x8lXTKjT!kXjEjYGDxrDmRLD4H5kJXjWTL1rA36v2Tbht3a4n1yQ)
boot-magisk.img: https://mega.nz/#!U8sFVACI!J-TS3q11...V1YIVDipez05BvE (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:QuoteBad 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-bootl...fastboot-guide/ (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-magi...ndroid-devices/ (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.
Post by: v3ritas on November 21, 2019, 08:27:30 pm
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 here (https://forum.xda-developers.com/apps/magisk/official-magisk-v7-universal-systemless-t3473445).
Post by: peter on November 22, 2019, 12:06:41 am
Quote from: v3ritas
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 here (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:
[ You are not allowed to view attachments ]
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.
Post by: ZimbiX on November 22, 2019, 12:33:14 am
Quote from: peter
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!
I've just had a go, and got it working on mine After tapping 'ok' on the 'Requires additional setup' popup, it runs a spinner for a few seconds, then reboots. Root confirmed working via Termux
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
Post by: v3ritas on November 22, 2019, 06:38:42 am
Quote from: ZimbiX
Quote from: peterWhen 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!
I've just had a go, and got it working on mine After tapping 'ok' on the 'Requires additional setup' popup, it runs a spinner for a few seconds, then reboots. Root confirmed working via Termux
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.
Post by: peter on November 25, 2019, 12:21:18 pm
Quote from: ZimbiX
I've attached the scatterfile for anyone else interested in playing around
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...
Post by: AP756 on November 25, 2019, 03:15:46 pm
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
Post by: xopher on November 26, 2019, 12:10:43 pm
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!
Post by: gidds on November 26, 2019, 02:35:18 pm
Quote from: AP756
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!)
Post by: MadAdy on November 26, 2019, 06:11:50 pm
Tap on Build Number in About Phone.
Post by: v3ritas on November 27, 2019, 07:13:37 am
Quote from: gidds
Quote from: AP756We'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 from: MadAdy
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).
Post by: NormMonkey on November 27, 2019, 11:12:20 am
Quote from: xopher
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!
Post by: v3ritas on November 27, 2019, 11:28:08 am
Quote from: NormMonkey
Quote from: xopherI'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.
Post by: gidds on November 27, 2019, 05:25:21 pm
Quote from: v3ritas
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...
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 this post (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
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)?
Post by: Robert on November 28, 2019, 10:19:36 am
Quote from: v3ritas
Quote from: giddsQuote from: AP756We'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 from: MadAdyHi 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!
Post by: Ignatz on November 29, 2019, 05:15:10 pm
Quote from: Robert
Quote from: v3ritasQuote from: giddsQuote from: AP756We'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 from: MadAdyHi 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
Post by: AP756 on December 02, 2019, 02:24:19 pm
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
Post by: TauPan on December 06, 2019, 05:18:26 pm
Quote from: ZimbiX
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 (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.
Post by: TauPan on December 06, 2019, 05:38:21 pm
Quote from: TauPan
Quote from: ZimbiXAt 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 (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.
Post by: ZimbiX on December 07, 2019, 01:43:55 am
Quote from: TauPan
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
Post by: ZimbiX on December 07, 2019, 01:51:31 am
Post by: TauPan on December 07, 2019, 04:42:14 am
Quote from: ZimbiX
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 (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.)
Post by: ZimbiX on December 07, 2019, 11:19:46 am
You might have luck with Helium (https://play.google.com/store/apps/details?id=com.koushikdutta.backup), or using ADB backup directly (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! 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
Post by: TauPan on December 07, 2019, 01:05:51 pm
Quote from: ZimbiX
Oh, I'm sorry, I was mixed up!
You might have luck with Helium (https://play.google.com/store/apps/details?id=com.koushikdutta.backup), or using ADB backup directly (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! 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.
Post by: ZimbiX on December 07, 2019, 01:13:02 pm
Quote from: TauPan
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 from: TauPan
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 from: TauPan
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?
Post by: Robert on December 08, 2019, 09:29:44 pm
Quote from: Ignatz
Quote from: RobertQuote from: v3ritasQuote from: giddsQuote from: AP756We'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 from: MadAdyHi 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 (https://developer.android.com/studio/run/win-usb)
And I tried to install them using the instructions here: https://developer.android.com/studio/run/oe...nstallingDriver (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
Post by: TauPan on December 09, 2019, 04:25:35 am
Quote from: ZimbiX
Good news, everyone!
What is it, professor?
Quote from: ZimbiX
I've attached the scatterfile for anyone else interested in playing around
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.)
Post by: TauPan on December 09, 2019, 05:52:21 am
Quote from: TauPan
RPMB Size: 0x1000000
Replay Protected Memory Block, apparently.
Quote from: TauPan
(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/med...host/Kconfig#37 (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
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.)
Post by: TauPan on December 09, 2019, 06:03:28 am
Post by: TauPan on December 09, 2019, 10:58:49 am
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
(Edit: Attachment deleted, see corrected version below.)
Post by: TauPan on December 09, 2019, 04:05:05 pm
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 (https://source.android.com/security/trusty) ... Also see http://www.lieberbiber.de/2015/07/04/media...-and-preloader/ (http://www.lieberbiber.de/2015/07/04/mediatek-details-partitions-and-preloader/) )
Quote from: TauPan
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.)
Post by: AP756 on December 10, 2019, 08:29:48 am
1. TWRP (Team Win Recovery Project)
2. Debian using KDE/Plasma
3. Debian using LXQT
4. Rooted Android
( https://www.indiegogo.com/projects/cosmo-co...59#/updates/all (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
Post by: TauPan on December 10, 2019, 08:39:01 am
Quote from: AP756
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-co...59#/updates/all (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!
Post by: ZimbiX on December 10, 2019, 09:55:57 am
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
Post by: TauPan on December 11, 2019, 03:34:19 pm
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=&...st&p=293139 (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
Wish me luck!
Post by: TauPan on December 12, 2019, 07:22:50 am
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).
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 from: TauPan
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=&...st&p=293139 (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
Wish me luck!
Post by: TheProfessorNQ on December 12, 2019, 10:18:27 am
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
Post by: TauPan on December 12, 2019, 01:21:04 pm
Quote from: TheProfessorNQ
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.
Post by: TheProfessorNQ on December 12, 2019, 08:07:25 pm
Quote from: TauPan
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
Post by: PNuT on December 12, 2019, 10:23:19 pm
Post by: TauPan on December 13, 2019, 02:49:13 am
Quote from: TheProfessorNQ
Quote from: TauPan
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 from: PNuT
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).
Post by: TheProfessorNQ on December 13, 2019, 05:05:53 am
Post by: TauPan on December 13, 2019, 01:54:21 pm
Post by: TauPan on December 13, 2019, 01:58:51 pm
Quote from: TheProfessorNQ
I would qualify flashing your preloader as progress! I'm back to an endless loop, at least, though the screen remains black. I should have stock boot.img on there, but I went ahead and re-flashed that. You know, I'm not confident That I didn't flash the boot.img to the recovery partition at some point. Specifically because, for reasons unknown, I keep trying to go there first before I have to stop myself, and its been a couple real late nights trying to fix this thing.
I don't understand why flashing boot.img from stock or from this post https://www.oesf.org/forum/index.php?s=&...st&p=292918 (https://www.oesf.org/forum/index.php?s=&showtopic=35879&view=findpost&p=292918) doesn't fix your problems. Maybe something else is broken.
Post by: ZimbiX on December 14, 2019, 08:37:38 am
I updated with the OTA the other day, but have just got around to re-rooting. My first attempt to install the update without doing anything failed halfway through, as I'd expected it to, since the boot image wouldn't pass match the checksum the OTA was expecting. After that, I re-flashed the stock boot image with fastboot; retrying the update then succeeded.
I've readback the updated boot image with SP Flash Tool and patched it with Magisk. The stock image is uncut - I guess SP Flash Tool readback doesn't strip off the unnecessary zeros, whereas WwR and Magisk do.
Enjoy
boot-ota1-stock.img: https://mega.nz/#!lwMAmYRZ!5HM2cvms...yqJYgVvnF-rQBvw (https://mega.nz/#!lwMAmYRZ!5HM2cvms8peRCKQ27hU8l9YbC5zTyqJYgVvnF-rQBvw)
boot-ota1-magisk.img: https://mega.nz/#!50dwTYpA!KvKxUtcP...dXi2MgRBn5mtANY (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
Post by: ZimbiX on December 14, 2019, 09:08:36 am
Code: [Select]
$ du -b *
9537536 boot.img
4277 boot_para
2146836 cache.img
1652753 cam_vpu1.img
10118081 cam_vpu2.img
142001 cam_vpu3.img
58049 dtbo.img
20971015 expdb
1048576 frp
674561 lk.bin
674561 lk2.bin
5317681 logo.bin
6885761 md1dsp.img
22674625 md1rom.img
8487 metadata
10719736 nvcfg
7866476 nvdata
66977808 nvram
262225 para
4960760 persist
6089 pgpt
271540 preloader_k71v1_64_bsp.bin
184 proinfo
278696 protect1
278696 protect2
14790656 recovery.img
60 seccfg
52689 spmfw.img
503249 sspm.img
2292108904 system.img
6291456 tinysys-scp1.bin
6291456 tinysys-scp2.bin
5242880 trustzone1.bin
12582912 trustzone2.bin
347449104 vendor.img
$ md5sum *
7df30852bb6d2a5d3b3dd3be37d73544 *boot.img
a94559473f7bb6c41b512cd48c8a2b4a *boot_para
3a0de5c3bbb8c7567a446cac48250a8f *cache.img
d505d4e8a5e908738653d22782aa9fcc *cam_vpu1.img
dbbcc085cf867c7ddf346d4d7e0a5d9e *cam_vpu2.img
e61a41f09c04c5865271a24c1bc82826 *cam_vpu3.img
7643eb9fdcbb59ba53e341a5c5d972eb *dtbo.img
e10e6ac974941e9124db1bd09249e9f9 *expdb
3f30f8fe6ebe6a57c2d2a3eb5594a023 *frp
e6b1f20509d5f31c40a644d744d88ce7 *lk.bin
e6b1f20509d5f31c40a644d744d88ce7 *lk2.bin
2944eac6637ddf9315dc6c1e23dc4d6e *logo.bin
cca69d02a837946e6f2cf2fc8316113e *md1dsp.img
75a4bbd0d62510ff9345bfa50f1cc01c *md1rom.img
99b7444e6613088128ec4aa9b0d1dd2d *metadata
aeb16d38ebb20368a7665bd670b0dab3 *nvcfg
242c9ff8a1f35229a1d389ce7c7ffa7d *nvdata
d0fc1bc3b823245c1684c926561dd3c7 *nvram
e37b4ed5b0618496397bdf1c9eef52ae *para
8ad3c777f99f95e43967431d5e69d8cc *persist
3b92df67290c2dbc41c7757433a9dbb4 *pgpt
34838abdb1141bf2999032050b940d7f *preloader_k71v1_64_bsp.bin
6f02d4c074e985c9df1e68c029914889 *proinfo
d306e4a4758acbd5629a53345a12b0dc *protect1
01b55313c8c37421d554563dffe06cbf *protect2
ae7ea13d10f61b546602812b8a9526cd *recovery.img
c40d4aae966d0d8aa7c92bab3845cc22 *seccfg
ccdd0de6fde53b041f9f81c4c3f52cec *spmfw.img
f9ad858bae8d49bcf5f26792521332e5 *sspm.img
bb3ba37c2d5dc7f010c0048a008e2480 *system.img
3d01da91f8b562ddd5fc3e1562b90a10 *tinysys-scp1.bin
3d01da91f8b562ddd5fc3e1562b90a10 *tinysys-scp2.bin
d2bbcf6e83eac78dadcf967690bd64eb *trustzone1.bin
cad0ef7a770f26a2509bbe7b100dee72 *trustzone2.bin
63b7a63a58baa25f12329d2ee060b3b1 *vendor.img
Post by: TauPan on December 14, 2019, 10:18:34 am
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!
Post by: Ninji on December 14, 2019, 02:37:39 pm
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.
Post by: peter on December 14, 2019, 06:41:32 pm
Quote from: ZimbiX
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!
Post by: Ninji on December 14, 2019, 07:58:27 pm
Here they are, if anyone finds them useful: https://drive.google.com/open?id=12LyxhvLuf...83kU-qKdduQFtjV (https://drive.google.com/open?id=12LyxhvLufT4RNDidS83kU-qKdduQFtjV)
I used the following commands from bootloader mode:
Code: [Select]
fastboot flash cam_vpu1 cam_vpu1.img
fastboot flash cam_vpu2 cam_vpu2.img
fastboot flash cam_vpu3 cam_vpu3.img
fastboot flash dtbo dtbo.img
fastboot flash lk lk.img
fastboot flash scp1 scp.img
fastboot flash spmfw spmfw.img
fastboot flash sspm_1 sspm.img
fastboot flash tee1 tee.img
fastboot flash md1dsp md1dsp.trim
fastboot flash md1img md1img.trim
fastboot flash boot boot_191209104700_magisk.img
fastboot flash system new_system.img
fastboot flash vendor new_vendor.imgI 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?
Post by: TheProfessorNQ on December 14, 2019, 09:01:38 pm
Post by: Ninji on December 15, 2019, 08:50:10 am
Quote from: TheProfessorNQ
Wow! You're amazing and thank you! All the flashing went smoothly. The device is automatically booting into recovery mode every time I try to reboot it. I had been doing this before the flashing. I'm using your TWRP from the other thread, as my manufacturer recovery hadn't been accessible. Any ideas about this? This constant progress has me very hopeful, at least!Hm.. The Cosmo appears to be super temperamental about what it will boot into in my testing -- sometimes it goes straight to Android, sometimes it goes straight to recovery, sometimes it just loops on screen on/off with the CoDi doing weird things. I've not identified a pattern.
Have you tried using Reboot > System from TWRP rather than just power cycling the Cosmo? This usually seems to do the trick for me.
If that doesn't work, I'd be very interested in seeing what your 'para' partition (NOT 'boot_para'!) contains. Please run this:
Code: [Select]
xxd /dev/block/by-name/para | grep -v "0000 0000 0000 0000 0000 0000 0000 0000"It's mostly zeroes, but appears to contain some pertinent information within the first two pages. Here is what I get from my Cosmo, split up:
Code: [Select]
00000000: 626f 6f74 6f6e 6365 2d62 6f6f 746c 6f61 bootonce-bootloa
00000010: 6465 7200 0000 0000 0000 0000 0000 0000 der.............
00020000: 454e 565f 7631 0000 6f66 662d 6d6f 6465 ENV_v1..off-mode
00020010: 2d63 6861 7267 653d 3100 756e 6c6f 636b -charge=1.unlock
00020020: 5f65 7261 7365 3d70 6173 7300 0000 0000 _erase=pass.....
00023ff0: 0000 0000 454e 565f 7631 0000 010d 0000 ....ENV_v1......
00040000: 0100 0000 34d9 63c8 aacb 3f77 e355 44f1 ....4.c...?w.UD.
00040010: 0000 0000 0000 0000 1f56 44f1 3c00 0000 .........VD.<...
00040030: 0000 0000 e355 44f1 fe5e c800 0000 0000 .....UD..^......
00040040: ea56 44f1 3500 0000 0000 0000 0200 0000 .VD.5...........
00040050: d000 0000 0000 0000 0000 0000 0000 0000 ................At 00000000 is a text string which determines what the Cosmo will do on next boot - right now on mine (within Android) it is "bootonce-bootloader".At 00020000 is what appears to be called the "env" data (relevant code in Gemini LK source (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 reads it in its Picachu module (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 Picachu module (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 Kconfig file in the Gemini kernel (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.
Post by: TheProfessorNQ on December 15, 2019, 09:23:35 am
Here's my dump from the xxd command:
Code: [Select]
00000000: 626f 6f74 2d72 6563 6f76 6572 7900 0000 boot-recovery...
00000040: 7265 636f 7665 7279 0a2d 2d75 7064 6174 recovery.--updat
00000050: 655f 7061 636b 6167 653d 2f63 6163 6865 e_package=/cache
00000060: 2f75 7064 6174 652e 7a69 700a 2d2d 6c6f /update.zip.--lo
00000070: 6361 6c65 3d65 6e2d 5553 0a0a 0000 0000 cale=en-US......
00020000: 454e 565f 7631 0000 6f66 662d 6d6f 6465 ENV_v1..off-mode
00020010: 2d63 6861 7267 653d 3100 756e 6c6f 636b -charge=1.unlock
00020020: 5f65 7261 7365 3d70 6173 7300 7065 7273 _erase=pass.pers
00020030: 6973 742e 7665 6e64 6f72 2e72 6164 696f ist.vendor.radio
00020040: 2e63 6675 2e71 7565 7279 7479 7065 3d30 .cfu.querytype=0
00020050: 006d 645f 7479 7065 3d31 3200 0000 0000 .md_type=12.....
00023ff0: 0000 0000 454e 565f 7631 0000 951e 0000 ....ENV_v1......
00040000: 0100 0000 1537 5d7a 518f b5fa e355 44f1 .....7]zQ....UD.
00040010: 0000 0000 0000 0000 1d56 44f1 3a00 0000 .........VD.:...
00040030: 0000 0000 e355 44f1 e05e c600 0000 0000 .....UD..^......
00040040: 8f56 44f1 3600 0000 0000 0000 0600 0000 .VD.6...........
00040050: 7000 0000 0000 0000 0000 0000 0000 0000 p...............
Post by: Ninji on December 15, 2019, 09:43:04 am
Quote from: TheProfessorNQ
Ran that. We can certainly see that it's being directed to boot into recovery every time. Thanks for this! I spent an eternity last night trying to find a file somewhere that would be directing this.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.
Here's my dump from the xxd command:
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...
Post by: TheProfessorNQ on December 15, 2019, 11:23:08 am
Quote from: Ninji
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.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!!!
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...
Post by: Ninji on December 15, 2019, 12:43:47 pm
Quote from: TheProfessorNQ
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...
Post by: TheProfessorNQ on December 15, 2019, 01:02:07 pm
Post by: TauPan on December 15, 2019, 03:51:20 pm
Quote from: ZimbiX
In the interest of finding out which partitions are safe to share (e.g., not leaking device-specific keys) in order to create a full firmware for factory restore, here are the sizes and checksums of the partition images after my original extraction from WwR with the option that gave the most partitions (I can't remember what that was called, sorry!). It'd be great if someone with their own backup of these from the pre-OTA firmware could compare to see what's the same/different. We can then package up all the partitions that are the same between each device. TauPan? Hopefully posting checksums of the private partitions is not too much of an information leak
Quote from: Ninji
I can confirm I have matches on the following partitions: boot, cam_vpu{1,2,3}, dtbo, lk, lk2, logo, md1dsp, md1rom, scp1/2, spmfw, sspm, trustzone1/2
Different: boot_para, frp, metadata, nvcfg, nvdata, nvram, para, persist, proinfo, protect1/2
My preloader dump (via SP FlashTool) is clipped slightly at the end for some reason, and my system and vendor dumps are far bigger (also done via SP FlashTool). I would expect these to have only one version though because the OTA updater expects them to be the same for everybody.
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-que...nulls-file.html (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
Post by: irukandji on December 27, 2019, 01:00:37 am
Post by: Oran on January 20, 2020, 12:44:18 am
I've rooted my Cosmo successfully using the boot-magisk.img you provided (unlocked the bootloader and flushed it with fastboot).
Thanks!!
Now there's a firmware update ready and it fails to install.
I understand that if i'll flush the original boot.img that's provided in post #19, i'll be able to run the firmware upgrade?
but then i won't be able to root again, right? and even after Planet eventually release the pre-rooted image, i won't be able upgrade without loosing my data (and since i'll be un-rooted, i can't use Titanium for backup).
any advise?
Post by: PNuT on January 20, 2020, 05:35:01 am
Quote from: Oran
Hi guys.
I've rooted my Cosmo successfully using the boot-magisk.img you provided (unlocked the bootloader and flushed it with fastboot).
Thanks!!
Now there's a firmware update ready and it fails to install.
I understand that if i'll flush the original boot.img that's provided in post #19, i'll be able to run the firmware upgrade?
but then i won't be able to root again, right? and even after Planet eventually release the pre-rooted image, i won't be able upgrade without loosing my data (and since i'll be un-rooted, i can't use Titanium for backup).
any advise?
Reflash the first ota boot.img contained in this thread, it will need to be the correct one or it will fail.
post # 64 has the correct images.
Post by: mibry on January 20, 2020, 07:49:35 am
Post by: PNuT on January 20, 2020, 11:09:10 am
Quote from: mibry
Has anyone posted updated boot image from yesterdays update yet?
I have not seen any yet!
Post by: Ninji on January 21, 2020, 09:13:35 pm
Boot partition, unmodified: https://drive.google.com/file/d/1PHL6IlE3lq...iew?usp=sharing (https://drive.google.com/file/d/1PHL6IlE3lqqITq7w_32SZm34QcIKEmtl/view?usp=sharing)
Boot partition, rooted with Magisk: https://drive.google.com/file/d/1UqXZHeuPjr...iew?usp=sharing (https://drive.google.com/file/d/1UqXZHeuPjrlsbet0hZYUcW1024rQ2eUd/view?usp=sharing)
Full images (~1.2GB): https://drive.google.com/open?id=1A9K04eyaX...sVVt3e6pVZGRA0Y (https://drive.google.com/open?id=1A9K04eyaXglgBX9y5sVVt3e6pVZGRA0Y)
Post by: Oran on January 22, 2020, 03:37:20 am
Quote from: Ninji
Here's images for the V19 update:
Boot partition, unmodified: https://drive.google.com/file/d/1PHL6IlE3lq...iew?usp=sharing (https://drive.google.com/file/d/1PHL6IlE3lqqITq7w_32SZm34QcIKEmtl/view?usp=sharing)
Boot partition, rooted with Magisk: https://drive.google.com/file/d/1UqXZHeuPjr...iew?usp=sharing (https://drive.google.com/file/d/1UqXZHeuPjrlsbet0hZYUcW1024rQ2eUd/view?usp=sharing)
Full images (~1.2GB): https://drive.google.com/open?id=1A9K04eyaX...sVVt3e6pVZGRA0Y (https://drive.google.com/open?id=1A9K04eyaXglgBX9y5sVVt3e6pVZGRA0Y)
Thanks!!
used the flushed image in post #64, upgraded with no problems, no data loss, flushed the new magisk image, works like a charm..
Post by: mibry on January 22, 2020, 03:56:23 am
Thanks!!
used the flushed image in post #64, upgraded with no problems, no data loss, flushed the new magisk image, works like a charm..
[/quote]
Is it possible to flash the root image once the Linux partition has been done?
Post by: cam1965 on January 22, 2020, 11:00:01 am
Post by: steeph on January 25, 2020, 10:00:31 am
Quote from: Oran
I've rooted my Cosmo successfully using the boot-magisk.img you provided (unlocked the bootloader and flushed it with fastboot).So, is there a guide I can follow to do the same or would you maybe willing to write one?
Post by: PNuT on January 25, 2020, 10:28:25 am
Quote from: cam1965
I am not an expert. But I've heard about kingoroot, but I am afraid about testing it. I don't want to brick my phone if everything goes wrong.
Do you not have access to a computer you can fastboot from?
Post by: PNuT on January 25, 2020, 10:38:09 am
Quote from: steeph
Hi!Quote from: OranI've rooted my Cosmo successfully using the boot-magisk.img you provided (unlocked the bootloader and flushed it with fastboot).So, is there a guide I can follow to do the same or would you maybe willing to write one?
It doesn't need much of a guide as you only need to unlock the bootloader and then fastboot the magisk.img that matches your firmware...
It is possibly the easiest device I have ever rooted!
Post by: steeph on January 25, 2020, 11:52:39 am
Quote from: PNuT
It doesn't need much of a guideI guess I have to improve my search terms then. I didn't find anything helpful yet.
Post by: PNuT on January 25, 2020, 11:55:07 am
Quote from: steeph
Quote from: PNuTIt doesn't need much of a guideI guess I have to improve my search terms then. I didn't find anything helpful yet.
Do you have fastboot set up on a computer?
Post by: steeph on January 25, 2020, 12:22:21 pm
Quote from: PNuT
Do you have fastboot set up on a computer?I have now. I've improved my search terms and did find something and thought I'd have a go. But apparently I did a factory reset. I wanted root access to backup my stuff, so my plan is now obsolete anyway.
Post by: rasva on January 25, 2020, 12:36:17 pm
- I succesfully flashed V19 using SP flash tool (was stuck at v16)
- I enabled USB debugging and OEM unlocking
- I ran "adb reboot bootloader"
- Cosmo rebooted to fastboot mode
Win10 recognises Cosmo in fastboot mode, I can see it in the devices. I installed google usb drivers and also tried MTK 1.0.8. drivers mentioned in previous posts (I think they are actually same)
I tried to assign it all three options one by one (ADB, bootloader and ADB combo). Still nothing, fastboot says <waiting for device>. If I reboot cosmo to recovery instead, it is at least recognised by adb, but this does not help.
Post by: rasva on January 25, 2020, 12:47:34 pm
Post by: Oran on January 28, 2020, 11:19:02 am
Quote from: steeph
Hi!Quote from: OranI've rooted my Cosmo successfully using the boot-magisk.img you provided (unlocked the bootloader and flushed it with fastboot).So, is there a guide I can follow to do the same or would you maybe willing to write one?
on the phone:
1) install magisk (https://forum.xda-developers.com/apps/magisk) manager (you'll need to download the APK, and enable unknown sources)
2) activate "OEM unlocking" in developer settings (need to click on the build number repeatedly to get that)
NOTE that this will put some warning message on the display visible every time you boot, and possible make your device un-trusted by some apps, but IIUC there's a way to work around it if it'll ever become a problem with some magisk plugin.
on the PC: install adb and run these:
3) adb reboot bootloader
IIRC you'll need to press the volume up (right cover toggle button) to resume
4) fastboot flashing unlock
IIRC you may also need to press the right toggle button. (THIS WILL RESET ALL YOUR DATA)
5) reboot to bootloader again, see step 3 - (not sure if necessary)
6) download the patched boot image that matches your ROM version, and run:
fastboot flash boot boot-magisk.img
fastboot reboot
in order to be able to run OTA upgrades, you'll need to revert to the original boot image of the previous ROM version (by repeating steps 5 and 6)
note, if you want to use AdAway, you'll need to install a magisk module named: Systemless Hosts
Post by: steeph on January 29, 2020, 11:27:55 pm
Post by: ehem on January 30, 2020, 12:19:13 am
Quote from: Ninji
Here's images for the V19 update:Mind advising us as to the origin of these? Did you get your Cosmo updated to V19 and then download images from it? I would much rather have "official" images from Planet Computers in some format which is signed so I can check signatures before installing them on a device.
Boot partition, unmodified: https://drive.google.com/file/d/1PHL6IlE3lq...iew?usp=sharing (https://drive.google.com/file/d/1PHL6IlE3lqqITq7w_32SZm34QcIKEmtl/view?usp=sharing)
Boot partition, rooted with Magisk: https://drive.google.com/file/d/1UqXZHeuPjr...iew?usp=sharing (https://drive.google.com/file/d/1UqXZHeuPjrlsbet0hZYUcW1024rQ2eUd/view?usp=sharing)
Full images (~1.2GB): https://drive.google.com/open?id=1A9K04eyaX...sVVt3e6pVZGRA0Y (https://drive.google.com/open?id=1A9K04eyaXglgBX9y5sVVt3e6pVZGRA0Y)
Quote from: Oran
on the phone:I would tend to link to the source (https://github.com/topjohnwu/Magisk/releases) rather than this site which appears to be making money by advertising someone else's work (they may be doing some valuable service, but it wasn't immediately obvious).
1) install magic manager (you'll need to download the APK, and enable unknown sources) - https://magiskmanager.com/ (https://magiskmanager.com/)
Post by: ZimbiX on January 30, 2020, 12:39:29 am
Quote from: ehem
Mind advising us as to the origin of these? Did you get your Cosmo updated to V19 and then download images from it? I would much rather have "official" images from Planet Computers in some format which is signed so I can check signatures before installing them on a device.
I presume the procedure is the same as what I did the first time, as described earlier in this thread:
- Flash the original boot image back (matching the version)
- Apply the OTA update
- Extract the new boot image from the device using SP Flash Tool (and then optionally trim zeros somehow)
- Use the Magisk Manager Android app to manually patch that extracted file, producing the Magisk'd file
Feel free to do that yourself if you're wary of trusting random image files. It would be nice to have a signed image from Planet to avoid the boot warning, but I'm glad we don't need to wait on them, or we'd still be out in the cold.
Quote from: ehem
Quote from: Oranon the phone:
1) install magic manager (you'll need to download the APK, and enable unknown sources) - <URL redacted>
I would tend to link to the source (https://github.com/topjohnwu/Magisk/releases) rather than this site which appears to be making money by advertising someone else's work (they may be doing some valuable service, but it wasn't immediately obvious).
Yeahh, I'd recommend you both edit your posts to avoid giving that dodgy site any more visits and ad revenue.
Post by: Oran on January 30, 2020, 12:48:01 am
Quote from: ehem
I would tend to link to the source (https://github.com/topjohnwu/Magisk/releases) rather than this site which appears to be making money by advertising someone else's work (they may be doing some valuable service, but it wasn't immediately obvious).
@ehem sorry i wasn't aware of that.
github doesn't seem to have apk files, i updated my post with a link to xda, and also added a note about AdAway and Systemless Hosts.
Post by: ZimbiX on January 30, 2020, 12:55:00 am
Quote from: Oran
github doesn't seem to have apk files, i updated my post with a link to xda, and also added a note about AdAway and Systemless Hosts.
Haha, it does actually, but it confused me the first time too - the releases are titled as either 'Magisk' or 'Magisk Manager' https://github.com/topjohnwu/Magisk/releases (https://github.com/topjohnwu/Magisk/releases)
Actually, I'd probably link the XDA thread since that contains info on what it is: https://forum.xda-developers.com/apps/magis...emless-t3473445 (https://forum.xda-developers.com/apps/magisk/official-magisk-v7-universal-systemless-t3473445)
Post by: Ninji on January 30, 2020, 09:18:26 am
Quote from: ehem
I dumped all the partitions when I originally received my Cosmo (on V15), and have manually applied the OTA patch files to them, first V16 and then V19. You can reproduce these steps by using FlashTool to dump the partitions, the OTA zips from the official server and the tools from this GitHub repository: https://github.com/erfanoabdi/imgpatchtools (https://github.com/erfanoabdi/imgpatchtools)Quote from: NinjiHere's images for the V19 update:Mind advising us as to the origin of these? Did you get your Cosmo updated to V19 and then download images from it? I would much rather have "official" images from Planet Computers in some format which is signed so I can check signatures before installing them on a device.
Boot partition, unmodified: https://drive.google.com/file/d/1PHL6IlE3lq...iew?usp=sharing (https://drive.google.com/file/d/1PHL6IlE3lqqITq7w_32SZm34QcIKEmtl/view?usp=sharing)
Boot partition, rooted with Magisk: https://drive.google.com/file/d/1UqXZHeuPjr...iew?usp=sharing (https://drive.google.com/file/d/1UqXZHeuPjrlsbet0hZYUcW1024rQ2eUd/view?usp=sharing)
Full images (~1.2GB): https://drive.google.com/open?id=1A9K04eyaX...sVVt3e6pVZGRA0Y (https://drive.google.com/open?id=1A9K04eyaXglgBX9y5sVVt3e6pVZGRA0Y)
Take the V19 zip as an example: https://flare02.iofota.com/EASTAEON_FTPRO16...00118213137.zip (https://flare02.iofota.com/EASTAEON_FTPRO16945_200118213137.zip)
This is signed using an OTA certificate trusted by the Cosmo ( how to verify: https://android.stackexchange.com/a/83931 (https://android.stackexchange.com/a/83931) )
The following partitions just have .img files directly included in the zip: cam_vpu1, cam_vpu2, cam_vpu3, dtbo, lk, preloader, scp, spmfw, sspm, tee
So, you can trust these based off the zip itself.
Next, look at the META-INF/com/google/android/updater-script file.
The following partitions have simple patches: boot, md1dsp, md1img
You can look at the definitions in the script file for these:
Code: [Select]
apply_patch("EMMC:/dev/block/platform/bootdevice/by-name/boot:9538464:107496ed0ae9031b7356beeb6d6ae5e9d405025b:9538464:58d69f9ee544f6b994fa5082feb7f6265076992e",
"-", 58d69f9ee544f6b994fa5082feb7f6265076992e, 9538464,
107496ed0ae9031b7356beeb6d6ae5e9d405025b,
package_extract_file("patch/boot.img.p"))
apply_patch("EMMC:/dev/block/platform/bootdevice/by-name/md1dsp:6885776:c703010283918d319aa37824f75113e714806543:6885776:b0a02f072aca1f17764bdc81f114a2879449bb61",
"-", b0a02f072aca1f17764bdc81f114a2879449bb61, 6885776,
c703010283918d319aa37824f75113e714806543,
package_extract_file("patch/md1dsp.img.p"))
apply_patch("EMMC:/dev/block/platform/bootdevice/by-name/md1img:22674640:96f23e1ba17c7297c5dd41556d4585b64064e625:22674640:b362aef593db9b1aee7b2589c6d5c693c2bd5824",
"-", b362aef593db9b1aee7b2589c6d5c693c2bd5824, 22674640,
96f23e1ba17c7297c5dd41556d4585b64064e625,
package_extract_file("patch/md1img.img.p"))These give you the size and SHA1 hashes for the new and old versions of the partitions:
Code: [Select]
$ shasum -a1 boot_191209104700_orig.img EASTAEON_FTPRO16945_191209104700/patch/md1{dsp,img}.trim
107496ed0ae9031b7356beeb6d6ae5e9d405025b boot_191209104700_orig.img
c703010283918d319aa37824f75113e714806543 EASTAEON_FTPRO16945_191209104700/patch/md1dsp.trim
96f23e1ba17c7297c5dd41556d4585b64064e625 EASTAEON_FTPRO16945_191209104700/patch/md1img.trim
$ shasum -a1 EASTAEON_FTPRO16945_200118213137/{boot_200118213137_orig.img,md1dsp.img,md1img.img}
58d69f9ee544f6b994fa5082feb7f6265076992e EASTAEON_FTPRO16945_200118213137/boot_200118213137_orig.img
b0a02f072aca1f17764bdc81f114a2879449bb61 EASTAEON_FTPRO16945_200118213137/md1dsp.img
b362aef593db9b1aee7b2589c6d5c693c2bd5824 EASTAEON_FTPRO16945_200118213137/md1img.imgNext there's the partitions that use block image patches: system, vendor
These are, frustratingly, harder to verify as there is no single hash for the whole image. Instead, the script hashes certain blocks together in the original image (so in this case it would be V16, not V19) and also checks the hashes of certain regions specified in the transfer.list file (basically a script determining how to transform the old image to a new image):
Code: [Select]
if (range_sha1("/dev/block/platform/bootdevice/by-name/system", "56,1,446,698,32770,32959,32960,33466,65537,66043,98306,98495,98496,99002,131
73,131579,163842,164031,164032,164538,196609,197115,229378,229567,229568,230074,
62145,262651,294914,295103,295104,295610,327681,328187,360449,360955,393217,3937
3,425985,426491,458753,459259,467545,468034,491521,492027,524289,524795,557057,5
7563,558453,753664,753665,774155,780254,780261,786432") == "cf46d4c3a45898f5917dd2662e6f2aadc1989163" || block_image_verify("/dev/block/platform/bootdevice/by-name/system", package_extract_file("system.transfer.list"), "system.new.dat", "system.patch.dat")) then
[...]
if (range_sha1("/dev/block/platform/bootdevice/by-name/vendor", "22,1,155,538,32770,32822,32823,33306,65537,66020,82931,98304,98306,163840,16
842,196608,196609,215706,216486,216998,217408,217415,219136") == "e0dbc2e034534cef4053222528d0db5a3571f35f" || block_image_verify("/dev/block/platform/bootdevice/by-name/vendor", package_extract_file("vendor.transfer.list"), "vendor.new.dat", "vendor.patch.dat")) then
[...]Then the last partition is the recovery. This one is encoded in an odd way: the patch is not in the OTA zip itself. The system partition contains a small script that runs on boot and applies an image patch to the boot image, producing the recovery image.
You can find this inside /system/bin/install-recovery.sh on the Cosmo:
Code: [Select]
applypatch EMMC:/dev/block/platform/bootdevice/by-name/boot:9538464:58d69f9ee544f6b994fa5082feb7f6265076992e EMMC:/dev/block/platform/bootdevice/by-name/recovery a23d8adb309934aabb1e75b937da6855f8fe3580 15319968 58d69f9ee544f6b994fa5082feb7f6265076992e:/system/recovery-from-boot.p && log -t recovery "Installing new recovery image: succeeded" || log -t recovery "Installing new recovery image: failed"Code: [Select]
$ shasum -a1 recovery_200118213137.img
a23d8adb309934aabb1e75b937da6855f8fe3580 recovery_200118213137.imgFinally, here's the commands I used to produce the images in that dump:
Code: [Select]
$ unzip -d EASTAEON_FTPRO16945_200118213137 EASTAEON_FTPRO16945_200118213137.zip
$ cd EASTAEON_FTPRO16945_200118213137
$ ../IMG_Patch_Tools_0.3/macOS/ApplyPatch newboot.img - 107496ed0ae9031b7356beeb6d6ae5e9d405025b 9536416 7e58e6005f7fc2f50ef3227f889898d67f689313 patch/boot.img.p
$ cp ../boot_191209104700_orig.img boot_200118213137_orig.img
$ ../IMG_Patch_Tools_0.3/macOS/ApplyPatch boot_200118213137_orig.img - 58d69f9ee544f6b994fa5082feb7f6265076992e 9538464 107496ed0ae9031b7356beeb6d6ae5e9d405025b patch/boot.img.p
$ adb push boot_200118213137_orig.img /sdcard/
$ # Patched from Magisk Manager on device
$ adb pull /sdcard/Download/magisk_patched.img
$ mv magisk_patched.img boot_200118213137_magisk.img
$ cp ../EASTAEON_FTPRO16945_191209104700/patch/md1dsp.trim md1dsp.img
$ cp ../EASTAEON_FTPRO16945_191209104700/patch/md1img.trim md1img.img
$ ../IMG_Patch_Tools_0.3/macOS/ApplyPatch md1dsp.img - b0a02f072aca1f17764bdc81f114a2879449bb61 6885776 c703010283918d319aa37824f75113e714806543 patch/md1dsp.img.p
$ ../IMG_Patch_Tools_0.3/macOS/ApplyPatch md1img.img - b362aef593db9b1aee7b2589c6d5c693c2bd5824 22674640 96f23e1ba17c7297c5dd41556d4585b64064e625 patch/md1img.img.p
$ cp ../new_system.img system_200118213137.img
$ cp ../new_vendor.img vendor_200118213137.img
$ ../IMG_Patch_Tools_0.3/macOS/BlockImageUpdate system_200118213137.img system.transfer.list system.new.dat system.patch.dat
$ ../IMG_Patch_Tools_0.3/macOS/BlockImageUpdate vendor_200118213137.img vendor.transfer.list vendor.new.dat vendor.patch.dat
$ # Flashed the new image
$ adb pull /system/system/recovery-from-boot.p
$ cp boot_200118213137_orig.img recovery_200118213137.img
$ ../IMG_Patch_Tools_0.3/macOS/ApplyPatch recovery_200118213137.img - a23d8adb309934aabb1e75b937da6855f8fe3580 15319968 58d69f9ee544f6b994fa5082feb7f6265076992e recovery-from-boot.pUsing these steps and existing images from your Cosmo you should be able to reproduce the exact same files.
Post by: mithrandir on February 04, 2020, 08:16:54 pm
What happens if we disable oem unlock afterwards?
Is there a way to install twrp without loosing the repartition tool recovery?
Post by: aard on February 06, 2020, 11:17:33 am
Quote from: mithrandir
Just being curious. What happens if we lock the bootloader again after rooting? Locked out?
What happens if we disable oem unlock afterwards?
Both unlocking and locking the bootloader wipes the device, unfortunately.
Locking the bootloader after rooting will send it into a boot loop due to failed signature verification. I've found the only way to drop out of that is to press and hold both cover display buttons until the recovery screen shows up (easier with the device closed - just hold until the regular vibrating stops). From there, go to bootloader, unlock, it'll wipe again, and let you boot back into the rooted device.
Post by: Zarhan on February 07, 2020, 02:16:11 am
Anyway, just to be clear, could somebody give a couple of clarifications? I'm mostly concerned about firmware upgrades after I've rooted my device.
- When starting to root the phone you need to unlock the bootloader. This will wipe all data. However, this is the only situation where data wipe is required - afterwards my data will stay even if I change to different firmwares. Correct?
- One thing that troubles me is that how can I get the system to remain rooted when new firmware versions arrive. The problem is that I don't want to unroot, relock bootloader (wipe data), upgrade, unlock bootloader (wipe data), and root.
=> If there are prebuilt rooted images (either by the Community or planet), I can just apply a new FW directly. E.g. if I had a rooted V16, I could just install Ninji's rooted V19 and device would stay rooted, no data loss?
- This tutorial at https://github.com/topjohnwu/Magisk/blob/ma...ta-installation (https://github.com/topjohnwu/Magisk/blob/master/docs/tutorials.md#ota-installation) shows that if a device has A/B partitions (active and inactive one), it can make upgrades a breeze by restoring unrooted image to inactive partition and then just applying update to it, and then re-patching Magisk in there.
=> Does Cosmo actually have this A/B partition setup or not? Seems very straightforward method of both maintaining your upgrade level and staying rooted.
Essentially: If I don't want to lose my data at every OTA upgrade, do I need to always wait for community or Planet to publish pre-rooted images?
Post by: Noppe on February 07, 2020, 02:45:10 am
Quote from: Zarhan
- When starting to root the phone you need to unlock the bootloader. This will wipe all data. However, this is the only situation where data wipe is required - afterwards my data will stay even if I change to different firmwares. Correct?
Correct. You need to unlock the bootloader only once, and that is the only action that will wipe your data. Best to do it early!
Quote
- One thing that troubles me is that how can I get the system to remain rooted when new firmware versions arrive. The problem is that I don't want to unroot, relock bootloader (wipe data), upgrade, lock bootloader (wipe data), and root.
OTA updates don't care if your bootloader is unlocked. If the OTA requires the untouched boot.img, you can flash the unrooted image back, apply the OTA, flash the new rooted boot.img, and be back to rooted. You won't be touching the bootloader at all in this process, and your data are safe.
Quote
=> If there are prebuilt rooted images (either by the Community or planet), I can just apply a new FW directly. E.g. if I had a rooted V16, I could just install Ninji's rooted V19 and device would stay rooted, no data loss?
Correct, as long as you started with your bootloader already unlocked.
Quote
Essentially: If I don't want to lose my data at every OTA upgrade, do I need to always wait for community or Planet to publish pre-rooted images?
Nope, you can certainly follow the method of using SP Flash Tool or equivalent to extract the new boot.img, patch it in unrooted Cosmo userland with Magisk Manager, and then flash it back with SP Flash Tool. Again, as long as you've got your bootloader unlocked, your data are fine. (Although obviously when doing any of this stuff, it's a good idea to have backups.)
Post by: TauPan on February 07, 2020, 04:25:22 am
In theory it should even be possible to reflash your userdate after repartitioning this way, but I'm not sure which partitions beside userdata you need to reflash in order to be able to decrypt your userdata successfully. (Can't test at the moment, my Cosmo is in London since December for repairs.)
Quote from: Noppe
Quote from: Zarhan- When starting to root the phone you need to unlock the bootloader. This will wipe all data. However, this is the only situation where data wipe is required - afterwards my data will stay even if I change to different firmwares. Correct?
Correct. You need to unlock the bootloader only once, and that is the only action that will wipe your data. Best to do it early!Quote- One thing that troubles me is that how can I get the system to remain rooted when new firmware versions arrive. The problem is that I don't want to unroot, relock bootloader (wipe data), upgrade, lock bootloader (wipe data), and root.
OTA updates don't care if your bootloader is unlocked. If the OTA requires the untouched boot.img, you can flash the unrooted image back, apply the OTA, flash the new rooted boot.img, and be back to rooted. You won't be touching the bootloader at all in this process, and your data are safe.Quote=> If there are prebuilt rooted images (either by the Community or planet), I can just apply a new FW directly. E.g. if I had a rooted V16, I could just install Ninji's rooted V19 and device would stay rooted, no data loss?
Correct, as long as you started with your bootloader already unlocked.QuoteEssentially: If I don't want to lose my data at every OTA upgrade, do I need to always wait for community or Planet to publish pre-rooted images?
Nope, you can certainly follow the method of using SP Flash Tool or equivalent to extract the new boot.img, patch it in unrooted Cosmo userland with Magisk Manager, and then flash it back with SP Flash Tool. Again, as long as you've got your bootloader unlocked, your data are fine. (Although obviously when doing any of this stuff, it's a good idea to have backups.)
Post by: Zarhan on February 07, 2020, 04:49:02 am
Quote from: Noppe
Nope, you can certainly follow the method of using SP Flash Tool or equivalent to extract the new boot.img, patch it in unrooted Cosmo userland with Magisk Manager, and then flash it back with SP Flash Tool. Again, as long as you've got your bootloader unlocked, your data are fine. (Although obviously when doing any of this stuff, it's a good idea to have backups.)
Thanks for clarifying... I was a bit worried about this warning at http://support.planetcom.co.uk/index.php/L..._Flashing_Guide (http://support.planetcom.co.uk/index.php/Linux_Flashing_Guide) about the fact that if I flash the wrong thing (NVRAM), my IMEI codes and stuff like that might end up hosed.
So, would this be the correct procedure in a generic case? I'm really trying to gather complete instructions in the sense that I know my way around Linux, but Android architecture is a completely new beast for me.
Initial rooting:
1. Install ADB and Fastboot
2. Set developer options: Go to "About device", tap it 7 times to get into developer settings. In developer settings:
- Remove automatic updates
- Allow USB debugging
- Allow OEM unlocking
(Anything else?)
3. Turn off Cosmo. Attach to PC via USB. Turn it back on while holding Power and Volume buttons (ESC on keyboard + fingerprint sensor on the cover) for 10 seconds. As an alternative, just issue "adb reboot-bootloader" in ADB.
4. Issue 'fastbood flashing unlock'. This will wipe data and allow installation of custom images. Due to the wiping of data, you need to boot back to android and enable developer settings again.
5. Extract boot.img to memory card. This can be done in adb shell by ???? (Can it even be done if you are still unrooted?). Also make a copy with e.g. name boot-orig.img so that you can revert for OTA updates later on.
6. Boot to Android as usual.
7. Install magisk manager from https://github.com/topjohnwu/Magisk/releases (https://github.com/topjohnwu/Magisk/releases) (allow unknown sources).
8. Patch the boot.img on your memory card.
9. Transfer the boot.img and boot-orig.img to PC.
10. Reboot back to fastboot mode as in Step 3.
11. issue "fastboot flash boot boot-patched.img" (where the filename is the image patched by Magisk manager).
12. Reboot to rooted Android.
OTA update is pending:
1. Reboot to fastboot mode as in Step 3 of previous set of instructions.
2. issue "fastboot flash boot boot-orig.img" (where the filename is the original boot image).
3. Reboot to Android. Android is now unrooted and you can apply OTA as normal.
4. Apply OTA update and restart phone.
5. Extract boot.img and a copy boot-orig.img to memory card like in step 5 of the previous set.
6. Boot to Android.
Follow the steps 8-12 in the previous set (flash with your newly-patched boot.img from the OTA-upgraded firmware release).
Only thing that I'm missing that how are you actually supposed to get the extract the boot image (Step 5).
Other than that, is this accurate?
I'm a bit worried about warnings in using SP Flash Tool since there are warnings about the possibility of essentially bricking your device if you wipe the wrong partition (NVRAM) by accident. Then again, if it is required and I only use the readback function, I should be reasonably safe, right?
Post by: Noppe on February 07, 2020, 10:27:28 am
Quote from: Zarhan
Only thing that I'm missing that how are you actually supposed to get the extract the boot image (Step 5).
Other than that, is this accurate?
I'm a bit worried about warnings in using SP Flash Tool since there are warnings about the possibility of essentially bricking your device if you wipe the wrong partition (NVRAM) by accident. Then again, if it is required and I only use the readback function, I should be reasonably safe, right?
Your listed procedure is correct, and you're right about the problem with step 5. You can't do that on a non-rooted device using adb. You have to extract the boot.img using SP Flash Tool, and the scatter file you can pick up earlier in this thread. You can then transfer the resulting file back into the booted, non-rooted device however you like, and then patch it using Magisk Manager, pull it back off the device, and then use either SP Flash Tool or fastboot to flash it. (Unfortunately for situations like this one, fastboot is write-only, so you cannot use it to extract the image, only to write it back.)
As long as you are using SP Flash Tool only for readback (and you don't *need* to use it for writing anything here), and as long as you follow the procedure correctly (i.e. "fastboot flash boot ..."), your nvram is safe. But it is still recommended to make a backup using SP Flash Tool. Just use SP Flash tool to pull everything from 0x0 to 0x11b000000 (that's where cache starts) and you'll get ~400 MB of output, which you can then save for the day you accidentally trash your nvram. (You could of course just back up the nvram partition, but since 400 MB is not a lot of data, I personally like the idea of saving the whole thing this way, because you just never know.)
Post by: Zarhan on February 07, 2020, 10:39:20 am
I could of course just grab Ninji's images off the links above and flash with those. However, what about when the next OTA upgrade comes up?
So...question: Suppose I use the available V19 images just for the initial rooting. Can I do without external tools like SP Flash Tool afterwards, after I got root and just rely on adb?
Essentially it comes down to this: At what time in the OTA process does boot partition get patched?
According to ADB shell (unrooted)
Code: [Select]
1|Cosmo_Communicator:/ $ ls -al /dev/block/platform/*/by-name | grep boot
lrwxrwxrwx 1 root root 21 2020-02-07 16:17 boot -> /dev/block/mmcblk0p30
lrwxrwxrwx 1 root root 20 2020-02-07 16:17 boot_para -> /dev/block/mmcblk0p1
lrwxrwxrwx 1 root root 23 2020-02-07 16:17 preloader_a -> /dev/block/mmcblk0boot0
lrwxrwxrwx 1 root root 23 2020-02-07 16:17 preloader_b -> /dev/block/mmcblk0boot1Could I do the following for the OTA upgrade? Before using dd you need to 'su'.
1. Restore boot image to stock using dd if=/sdcard/boot-orig.img of=/dev/block/mmcblk0p30
2. Apply OTA update, DO NOT restart device after upgrade has been installed
3. Copy new boot image to memory card (dd if=/dev/block/mmcblk0p30 of=/sdcard/boot-new.img), make another copy and patch using magisk
4. Copy the new magisk boot image back in using dd
5. Restart to new version, rooted
Essentially: After firmware update is installed, does the boot.img get modified *right away* or only after the first restart to the new version?
Post by: Zarhan on February 07, 2020, 11:02:43 am
Quote from: Noppe
As long as you are using SP Flash Tool only for readback (and you don't *need* to use it for writing anything here), and as long as you follow the procedure correctly (i.e. "fastboot flash boot ..."), your nvram is safe. But it is still recommended to make a backup using SP Flash Tool. Just use SP Flash tool to pull everything from 0x0 to 0x11b000000 (that's where cache starts) and you'll get ~400 MB of output, which you can then save for the day you accidentally trash your nvram. (You could of course just back up the nvram partition, but since 400 MB is not a lot of data, I personally like the idea of saving the whole thing this way, because you just never know.)
400 MB? 0x11b000000 is about 4 Gigabytes. Are you certain? I can see the scatterfile indeed have cache start at that address.
I also cannot seem to be able to read back the boot partition using SP Flashtool. I put start address as 0x2170000 and length of 0x2000000 and I get an alignment error. Both of those figures are divisible by 512 (as well as 4096), so I'm not sure what the problem is... Mostly I'd like to do this part to check if I'm able to extract the boot image and have the same result as Ninji.
Post by: Zarhan on February 07, 2020, 11:12:30 am
Quote from: Zarhan
I also cannot seem to be able to read back the boot partition using SP Flashtool. I put start address as 0x2170000 and length of 0x2000000 and I get an alignment error. Both of those figures are divisible by 512 (as well as 4096), so I'm not sure what the problem is... Mostly I'd like to do this part to check if I'm able to extract the boot image and have the same result as Ninji.
Ok, this was apparently due to some quirk in SP Flashtool. I needed to input 0x00000000002000000 (with the leading zeroes) instead of just 0x2000000. I could grab off the boot partition, and then cut if to same size as Ninji's image and sha1sums indeed match.
Now going to try to see if Magisk happens. Still concerned about OTA upgrade process.
Post by: Zarhan on February 07, 2020, 11:45:34 am
Quote from: Zarhan
Now going to try to see if Magisk happens. Still concerned about OTA upgrade process.
OMG. Magic indeed happened. I now have a rooted phone with an image I built "myself".
However, my speculated process about being able to put the original boot image into place without resorting to external tools ran into a snag.
If I ran
dd if=sdcard/Boot.img of=/dev/block/mmcblk0p30 bs=65536
The end result was that I'm *not* unrooted. I even tried pushing in the full 32 MB of padded zeroes, didn't help.
I could of course fastboot and flash the stock rom back in, but then I cannot do the next level of patching.
My next guess is that I actually attempted to write to the wrong block device. Luckily I have backups...
Post by: Noppe on February 07, 2020, 01:52:28 pm
Quote from: Zarhan
400 MB? 0x11b000000 is about 4 Gigabytes. Are you certain? I can see the scatterfile indeed have cache start at that address.
Eh, what's a factor of ten between friends? (Yeah, you're right, sorry about my error.)
Quote
dd if=sdcard/Boot.img of=/dev/block/mmcblk0p30 bs=65536
I can't really speak to this process. I've only used SP Flash Tool and fastboot for flashing the boot image.
Post by: Zarhan on February 08, 2020, 05:39:22 am
Quote from: Noppe
I can't really speak to this process. I've only used SP Flash Tool and fastboot for flashing the boot image.
Oh well, at least I now have *some* process of getting this done, although I'd really want to get rid of the requirement for a PC whenever an OTA upgrade rolls around.
Maybe TWRP would help...
Post by: Charliest on February 17, 2020, 07:57:29 am
Post by: sup on March 02, 2020, 03:17:16 am
Quote from: TauPan
I'd like to add that it's possible to do a full backup (make sure to include *every* partition from my scatter file) unlock the bootloader, backup seccfg again and then flash your complete backup and replace the boot img with the rooted one and the seccfg with the unlocked file. This way you can unlock and root without losing any data.
In theory it should even be possible to reflash your userdate after repartitioning this way, but I'm not sure which partitions beside userdata you need to reflash in order to be able to decrypt your userdata successfully. (Can't test at the moment, my Cosmo is in London since December for repairs.)
Any news on this? I would love to backup my data (including userdata, which, if I understand it correctly, are the most important anyway) before reflashing.
Also, now that there are official root images from Planet, is there any advantage at using procedures in this thread?
Also, regarding the official way - can I root the phone without changing partitions so that I do not lose my data?
Post by: Zarhan on March 02, 2020, 09:29:48 am
Quote from: sup
Also, now that there are official root images from Planet, is there any advantage at using procedures in this thread?
Considering that Planet's own rooted image apparently causes your SIM card to stop functioning then yeah...I'd rather keep rolling my own image.
Post by: cam1965 on March 26, 2020, 10:13:36 am
Post by: Zarhan on March 26, 2020, 10:56:19 am
Quote from: cam1965
There is a new version of firmware today ( ota update ) . I've rooted android the unnoficial way following the steps in this forum. But this firmware update from Planet didn't install ( error ). Can someoone help ? Thank you.
You need to unroot your device first, obviously. I haven't tested the process myself, but you need to essentially install the original boot image via fastboot. Then boot, patch, and re-root (you need to create a new rooted image or wait for someone to publish one here).
Post by: mibry on March 26, 2020, 11:03:40 am
Thanks in advance.
Regards
Mibry
Post by: wapsi on March 26, 2020, 11:20:23 am
Post by: cam1965 on March 26, 2020, 12:39:23 pm
Quote from: Zarhan
OK. Thank you . I will try.Quote from: cam1965There is a new version of firmware today ( ota update ) . I've rooted android the unnoficial way following the steps in this forum. But this firmware update from Planet didn't install ( error ). Can someoone help ? Thank you.
You need to unroot your device first, obviously. I haven't tested the process myself, but you need to essentially install the original boot image via fastboot. Then boot, patch, and re-root (you need to create a new rooted image or wait for someone to publish one here).
Post by: Zarhan on March 26, 2020, 01:00:16 pm
To get back root, you need to use sp_flashtool to grab the image off it, then use magisk manager to re-patch that image, and then flash it using fastboot again. I haven't done this yet.
Post by: PNuT on March 26, 2020, 02:32:34 pm
Quote from: Zarhan
To get back root, you need to use sp_flashtool to grab the image off it, then use magisk manager to re-patch that image, and then flash it using fastboot again. I haven't done this yet.
I just selected the rooted android version in the boot menu & it appears to be rooted and working as it should
Post by: mibry on March 26, 2020, 06:34:44 pm
Quote from: mibry
I was wondering if someone could help me. I was trying to be smart by deleting google system files off my cosmo. When I try to apply the v20 patch it fails. I have downloaded the system dump files from post 83 and when I try to restore my cosmo from the scatter files it is missing some files. So far I have been able to resolve some of the error I am getting but I have hit a road block. I seem to be missing the bin files for scp1, scp2, lk, lk2, logo, tee1, tee2, cache and userdata. If I am able to restore without these file please let me know.
Thanks in advance.
Regards
Mibry
Reply to my own post. I was able to fix my problem by using fastboot to restore the system.img file from the dump that was done by Ninji. Thanks for the dumped files.
Post by: wapsi on March 27, 2020, 07:28:40 am
Quote from: wapsi
I'm using Ninji's images which I flashed by using SP Flash Tool. It would be really nice if someone could upload the new boot (Magisk patch installed) and system images to somewhere again. Otherwise I don't know how to flash the update because the installation by using the official flashing tool fails. I don't know if the OTA zip file is flashable via fastboot?
Replying to my post: I was able to update from rooted V19 to V20 by re-flashing Ninji's V19 images and original (unrooted) boot img using SP Flash Tool. Then I did the upgrade manually by putting OTA.zip into phone's storage root and flashing it by using PlanetCom's update tool in Android (accessible via Settings). Upgrade was OK now. After that I re-flashed the rooted boot img provided by PlanetCom.
Post by: cam1965 on March 27, 2020, 12:48:47 pm
Quote from: cam1965
Quote from: ZarhanOK. Thank you . I will try.Quote from: cam1965There is a new version of firmware today ( ota update ) . I've rooted android the unnoficial way following the steps in this forum. But this firmware update from Planet didn't install ( error ). Can someoone help ? Thank you.
You need to unroot your device first, obviously. I haven't tested the process myself, but you need to essentially install the original boot image via fastboot. Then boot, patch, and re-root (you need to create a new rooted image or wait for someone to publish one here).
Installed the original image. Updated the firmware. Did a boot in Debian and extracted the android boot image.Copied it to a folder in android. Did a boot in android and patched it with magisk. Copied the image to my computer and did a fastboot to flash the new patched image from magisk. Worked !
Post by: irukandji on April 10, 2020, 05:57:51 am
(Probably posted in wrong part of forum: https://www.oesf.org/forum/index.php?showtopic=36230) (https://www.oesf.org/forum/index.php?showtopic=36230))
Post by: cam1965 on April 10, 2020, 01:11:51 pm
Quote from: irukandji
I got myself into a boot loop, does someone maybe know what partitions to restore with twrp (i have created backup with v19 while I got into into bootloop with firmware v21)?
(Probably posted in wrong part of forum: https://www.oesf.org/forum/index.php?showtopic=36230) (https://www.oesf.org/forum/index.php?showtopic=36230))
You can restore to v19 firmware . Please see my post below :
https://www.oesf.org/forum/index.php?showto...15&start=15 (https://www.oesf.org/forum/index.php?showtopic=36215&st=15&start=15)
Post #24.
Post by: irukandji on April 11, 2020, 04:55:20 am
Quote from: cam1965
Quote from: irukandjiI got myself into a boot loop, does someone maybe know what partitions to restore with twrp (i have created backup with v19 while I got into into bootloop with firmware v21)?
(Probably posted in wrong part of forum: https://www.oesf.org/forum/index.php?showtopic=36230) (https://www.oesf.org/forum/index.php?showtopic=36230))
You can restore to v19 firmware . Please see my post below :
https://www.oesf.org/forum/index.php?showto...15&start=15 (https://www.oesf.org/forum/index.php?showtopic=36215&st=15&start=15)
Post #24.
Thank you, i have seen this post before but restoring from twrp is much more simple, thats why I am asking, I intend to play around android quite a bit and I would love to have a fast way to restore and backup and twrp is perfect for this. But I am confused by the amount of partitions and I would like to know which should be restored.
Post by: mithrandir on June 22, 2020, 05:02:23 pm
Thanks!
Post by: ZimbiX on June 24, 2020, 10:29:42 am
So here are the latest boot images =)
- boot-v22-stock.img: https://mega.nz/file/5w1TgKiQ#fwko3-fXJ1U8O...-SbgIUGUNj3Cgac (https://mega.nz/file/5w1TgKiQ#fwko3-fXJ1U8Or0aWSjD1tShl_Cb-SbgIUGUNj3Cgac)
- boot-v22-magisk.img: https://mega.nz/file/14tjyQRQ#hvDW6EwCXGdZo...IkLeMogzPwbhpA8 (https://mega.nz/file/14tjyQRQ#hvDW6EwCXGdZon1z4opNJrXaxsE0IkLeMogzPwbhpA8)
I'm on Linux on a new computer, and just got SP Flash Tool readback working on Arch Linux for the first time, iirc. Reminder/note to self:
With SP Flash Tool v5.2020 for Linux (https://spflashtools.com/linux/sp-flash-tool-v5-2020-for-linux):
Code: [Select]
$ cat /etc/udev/rules.d/20-mm-blacklist-mtk.rules
ATTRS{idVendor}=="0e8d", ENV{ID_MM_DEVICE_IGNORE}="1"
ATTRS{idVendor}=="6000", ENV{ID_MM_DEVICE_IGNORE}="1"
$ sudo udevadm control --reload
$ sudo ./flash_toolThen according to the scatterfile, readback from 0x21700000 for length 0x2000000 (This is the original location for the boot partition as I have not yet tried installing Linux on my Cosmo).
Post by: Zarhan on June 25, 2020, 01:15:28 am
Second, when you use spflashtool to extract the boot partition, how do you remove padding from the end of the image (the actual boot image does not fill the entire partition)?
Post by: ZimbiX on June 26, 2020, 04:31:51 am
Quote from: Zarhan
Thanks for the images, but a question: From where do you acquire the scatterfile (or rather, how do you generate it)?Sure. I suppose I didn't describe that well earlier in the thread.
Back when I first worked out the process to root, I used this 'Wwr MTK tool (https://forum.hovatek.com/thread-21970.html)' on Windows to generate a scatterfile that's compatible with SP Flash Tool. It has a great deal of functionality, but can be confusing. iirc, not having root, I had to follow the convoluted process documented there to do something like first generate a partial scatterfile, then use that to readback the whole device from SP Flash Tool as one image, then get Wwr to analyse that and generate the full scatterfile. Just follow the steps there. Or, I suspect that by starting from a rooted device, you'd be able to use a different function of Wwr to read the partition layout directly from the device to generate the scatterfile.
Let us know how you go! =)
Quote from: Zarhan
Second, when you use spflashtool to extract the boot partition, how do you remove padding from the end of the image (the actual boot image does not fill the entire partition)?Haha, good question; I don't know how to do that yet. There is a function in Wwr for that, iirc, but the free version startup wait time is too annoying to bother. I think Wwr is just wrapping an open source partition editing binary for that though, so I suspect you could Google for like 'linux strip empty space from partition image'.
Post by: Zarhan on June 26, 2020, 12:16:57 pm
Quote from: ZimbiX
Haha, good question; I don't know how to do that yet. There is a function in Wwr for that, iirc, but the free version startup wait time is too annoying to bother. I think Wwr is just wrapping an open source partition editing binary for that though, so I suspect you could Google for like 'linux strip empty space from partition image'.
Thanks for the answers. Ok, it's not exactly a showstopper since there is really no harm in flashing a bunch of junk at the end of the image except for slightly increased size.
Post by: Zarhan on July 07, 2020, 12:28:01 pm
Just extract boot image with Sp_flashtool, patch with magisk and then install using fastboot.
Post by: ZimbiX on July 09, 2020, 08:38:39 am
- boot-v23-stock.img: https://mega.nz/file/Yls1nBIZ#EmKsTeq_RL-FM...0Eont4py0F5kFgc (https://mega.nz/file/Yls1nBIZ#EmKsTeq_RL-FMQpM6oTURZN9mvPC0Eont4py0F5kFgc)
- boot-v23-magisk.img: https://mega.nz/file/E99n1bZC#oZtgWinlygLqT...rD06MiHhGFE7H78 (https://mega.nz/file/E99n1bZC#oZtgWinlygLqTwNaZO7xdlpV3mzWrD06MiHhGFE7H78)
Post by: Mindsupply on August 07, 2020, 08:04:04 am
Now I want to start installing Devuan Linux inside Android (reference topic on this site from jjrv). It states:
"Unlock bootloader, install Magisk and Get Ninji's rooted boot image and flash it". Image only suitable for V19 and then continues..
Now my question: Is the rooted Android provided by PC (V23) different than the custom images (like Ninji's) and still needs to be flashed? Or has the rooted Android boot the same functionality (as it is rooted already)? If so, I can continue the installation provided by jjrv. If not, do I need to flash the boot image provided by ZimbiX for V23?
Thanks in advance.
Post by: Zarhan on August 07, 2020, 11:20:56 am
1) Planet's own images are signed, so no need to unlock bootloader, however
2) Planet's own images are built for their partition scheme, where you need to set up partitions like 90/30 Android/Linux - even if you are interested in just using the rooted Android, because you don't even get the "rooted android" partition without using *some* scheme where a bit of space is allocated for Linux
The multiple partitions approach do allow you to boot to unrooted android since it's preserved.
The problem is that Planet's bootloader does not seem to allow you to set the "default" boot partition. So you always have to manually select that you want root...
Post by: Mindsupply on August 08, 2020, 04:00:11 am
That makes it clear.. I don't have to flash an other boot image again, as PC's rooted image is suitable enough now.
I can do a normal boot to install OTA's and yeah, I have to select rooted Android with each reboot, but I don't find that a problem at all..
So now I'm going to struggle to get the Devuan Linux to work..
As I saw you already did this.. If you have any additional tips on top of the instructions of jjrv, it is much appreciated.. : )
Post by: Zarhan on August 08, 2020, 04:02:12 am
As I saw you already did this.. If you have any additional tips on top of the instructions of jjrv, it is much appreciated.. : )
Not really - I've commented on that thread with my own additions.
Post by: Mindsupply on August 08, 2020, 04:15:32 am
Have a good day..
Post by: usagi87 on March 16, 2021, 02:35:53 pm
Post by: Zarhan on March 17, 2021, 09:26:46 am
Hey, read the anwsers but still bit confused never done anything like this. How do I create the scatter file for my cosmo and create an original boot image from cosmo? Trying to root but sd card wont working so trying different ways.
Hi, for scatter file, just use this:
https://www.oesf.org/forum/index.php?topic=35879.msg292916#msg292916
And I wrote a summary of rest of the process, read my specific summary post at
https://www.oesf.org/forum/index.php?topic=35879.msg294633#msg294633
The only thing is that in my step 5, when you are supposed to extract the boot.img you are pretty much forced to use the SP flashtool (https://spflashtool.com/) and a PC. Just use the readback functionality, do not write anything, and you are safe.
I would like to run Planet's official, signed image for root, but that will require wiping my phone again so I have been avoiding that.
I've just un-rooted my phone in anticipation of the V25, hopefully it lands soon.
Post by: usagi87 on March 17, 2021, 02:58:02 pm
Post by: Zarhan on March 17, 2021, 04:37:56 pm
Thanks for the information. Can the sp flash tool used to create a backup of the boot image?
That's what it's for. You use it to grab the boot image. (Do not use it for writing to the device unless you know what you are doing). This is also your backup - keep it to allow for OTA upgrades to work.
You then create the rooted boot image using magisk manager.
You can then flash the rooted or original boot image using fastboot.
Post by: usagi87 on March 19, 2021, 02:33:56 pm
Post by: usagi87 on March 19, 2021, 03:14:27 pm
Post by: Zarhan on March 20, 2021, 03:20:13 am
How do I use the scatter file to readback the boot image? When tried first time loaded the scatter file and then from readback selected emmc_boot_1 but the file size is only 4kb.
Hi, when you input the scatter file, you see the following output for "download" tab. We are interested in the "boot" region:
Then go to Readback tab and click add, enter same value as the start of "boot" for starting location, in this case 0x21700000, and size 32 megabytes (0x2000000). That 32M is simply 0x23700000 - 0x21700000 (difference from start of next partition, "logo"). Actually, I had to enter the size with leading zeroes (0x00000000002000000) back when I did this originally, but this may have changed in recent flashtool versions. I did not need to do that now when I took the screenshot, for some reason.
No, I do not know how to get the endpoint of the boot image "cleanly". The patched image (from Magisk) is correct size. But 10 megs vs 32 - no difference really.
Post by: usagi87 on March 22, 2021, 04:36:20 pm
Post by: Zarhan on March 23, 2021, 03:06:51 am
Note that if you are planning to root your device I think it would be better to just use Planet's official rooted image. Only reason I'm using this method and will use for V25 too is that rooting with Planet methods requires wiping all data from my device and I really don't want to do that. Maybe once they release that PlanetBackup solution.
Post by: usagi87 on March 23, 2021, 03:04:54 pm
Post by: Zarhan on March 25, 2021, 02:09:05 pm
Post by: usagi87 on March 31, 2021, 01:47:54 pm
Post by: Zarhan on April 01, 2021, 12:26:40 am
Manages to brick cosmo in a endless boot loop. Can't boot to recovery wont responde to any keys. Any idea what to do?
Did you document your steps? What exactly did you do to achieve this?
You should always be able to boot to fastboot mode by turning off the device and then holding up power button and the volume "up" key (on the cosmo, the rocker switch) for 10+ seconds. If you are stuck in boot loop, do that for 20 seconds instead.
Post by: usagi87 on April 02, 2021, 02:51:03 pm
Does not responed to any keys not even turning the power off just keeps booting. Only way to stop it booting was to use sp flash tool by downloading something it stop the boot loop.
Post by: AP756 on April 02, 2021, 03:16:44 pm
Post by: Zarhan on April 03, 2021, 01:40:14 am
I rooted the android like instructed work fine but after I rooted it I coul not boot to recovery. So I tried to unroot the device by installing the original boot rom back it work. On boot I still could not boot to recovery, I just kept telling that the device was untruested because it was oem unlock so I lucked it a again. Now I some how brick it when it booting tells me that the device is not verified ask to insert I verified image the after 5 second it boot again says the same thing the boots again and again ....
Does not responed to any keys not even turning the power off just keeps booting. Only way to stop it booting was to use sp flash tool by downloading something it stop the boot loop.
Ok, re-locking the device is what caused the bootloop, since it cannot verify the image signature of the rooted bootloader (of course). That is the key difference to Planet's official rooted image - that one is signed. Just re-unlock the device again if you can.
I have not even tested booting to recovery with this method, so cannot really help you there.
Post by: usagi87 on April 03, 2021, 09:15:50 am
Post by: Zarhan on April 03, 2021, 01:55:39 pm
Post by: usagi87 on April 03, 2021, 02:49:24 pm
Just wondering what is preloader file?
Post by: HAL on April 07, 2021, 03:45:16 am
using instruction https://www.oesf.org/forum/index.php?topic=36523.msg297493#msg297493 I was able install cosmo firmware v23 but did loose IMEI information. Is it possible to recover them?
I had the same problem after flashing v23 and was able to solve it by restoring the NVRAM partition from a previous TWRP backup.
Also the problem of the constantly changing WLAN MAC was solved.
After the following update v23 to v25 everything works fine for me now.
Only my smartwatch can not be paired at the moment.
When starting the Wear OS app it always says:
"the currently installed build of companion will not work
on this phone. Uninstall it and make sure you install a
signed companion on a user phone."
Neither the latest Wear OS App, nor the old version that was installed before flashing, currently works.
Does anyone have an idea to the companion problem?
Post by: Oran on April 07, 2021, 03:47:49 am
Post by: usagi87 on April 20, 2021, 12:41:34 pm
Post by: ZimbiX on January 15, 2022, 09:47:12 am
- boot-v25-stock.img (https://mega.nz/file/Mw92lI4S#OozP1SNSh5_ru57p4V5-PRpvooZTNkSnXRVAGY_O3B0)
- boot-v25-magisk.img (https://mega.nz/file/9x92CAIY#sfDTt50BbaLv0_PZEw2OqxIyLfwSKiBcw42z7GrJta8)
This is very late, haha - I've only just gotten around to updating. I'm finally also about to try repartitioning for Linux :D
Post by: TauPan on January 15, 2022, 11:21:41 am
Instructions for upgrading magisk are in a different thread, which I'm still following.
Post by: forcella on January 31, 2022, 03:59:00 am
I've just stopped following this topic since I've been using the official planet procedure for rooting and I suggest everybody to do the same.
Does this mean that the problem with the version of Rooted Android provided by Planet that does not recognise the SIM card has been fixed? As I understand it, the status quo is still that you have to manually root the system for SIM card recognition to work.