Messages

1

Cosmo Communicator - General Discussion / How do you fix a broken download update tool with a broken download update tool?

« on: January 31, 2020, 07:14:15 am »

Yes, I'm aware that just asking for port 80 with a web browser on the main URL is a VERY crude test. Your findings seems to suggest the servers are still working, which may make the Planet "misconfiguration" hypothesis a bit more plausible. Anyway when you do get a reply from the servers, does that reply imply that V19 should still be available under certain circumstances? Just having V16 doesn't seem to be enough.

Yes. You can test this yourself if you have Python 3 and the 'requests' module by running my script here: https://gist.github.com/Treeki/823ce5e6fafb...dfd61abe2ef557e

Replace the 'softver' field by Cosmo-9.0-Planet-12062019-V16.<20191206_1615> and enter any string into the 'phone_id' field. This is what I get:

Code: [Select]

$ python3 checker_gist.py
{'state': 1, 'patch': {'rstyle': 1, 'dl_type': 0, 'patch_url': 'https://flare02.iofota.com/EASTAEON_FTPRO16945_200118213137.zip', 'patch_version': 'Cosmo-9.0-Planet-01182020-V19', 'patch_name': 'EASTAEON_FTPRO16945_200118213137', 'patch_date': '2020-01-18 21:31:37', 'content_md5': '779a26993a13b8596c7c6368c6f96970', 'patch_intro': '', 'min_mem': 0, 'archive_type': 'zip', 'inst_type': 0, 'inst_time': '', 'mem': 0, 'path2': '', 'patch_id': 19561, 'patch_type': 1, 'app_style': 'S', 'app_id': 20107, 'patch_size': 79845, 'wifi': 1, 'path1': 'data/media/0'}, 'gen': {'project_id': 'FTPRO16945', 'count_succ': 1, 'phone_id': 'dummy string', 'is_gdpr': 1, 'state_device': 0, 'interval_hour': 0, 'path1': 'data/media/0'}}
On the other hand, with the V15 version id (as in the gist) you do not get any updates offered.

2

Cosmo Communicator - General Discussion / How do you fix a broken download update tool with a broken download update tool?

« on: January 31, 2020, 06:39:51 am »

I'm also curious myself as to how this will be resolved...

There are four different situations going on here, all at the same time:

1. The main Digitime website was taken down by repointing www.digitimetech.com to a random IP address - this happened ~3 weeks ago, but this didn't affect the updates as they talk to a different subdomain.

2. Following Planet's release of V19, the Digitime servers stopped offering the V16 update to V15 Cosmos, meaning that they were stuck on the initial version until they manually updated. This still seems to be the case today.

3. The server at eu-app-fota.digitimetech.com (IP address 47.254.145.86) has stopped responding to requests - this is different to point 1, as the IP has not changed!

4. The fall-through logic in the updater which contacts a different domain (eu.fota.digitimetech.com) if a request fails doesn't seem to work properly - that server still works, but the app isn't talking to it

My guess is that Digitime will resolve whatever has broken the eu-app-fota server and that will fix point 3 (and make point 4 irrelevant for now, until something breaks again)... These guys don't seem particularly competent.


re: Daniel W bringing up "Welcome to nginx" - that's just a Digitime hallmark it seems, they don't change the default pages. Indeed, app.fota.digitimetech.com currently has one, but my script is able to contact it under /v3/mob/chk for updates and receive the correct reply. You see a very similar page for OpenResty (instead of nginx) on their malware control server if you go to it: http://statistics.flurrydata.com:10000/

3

Cosmo Communicator - Hardware / Unofficial TWRP build

« on: January 30, 2020, 03:48:57 pm »

Brand new member with a brand new Cosmo.  

I am a bit confused here, because my efforts to get TWRP to boot on the Cosmo are unsuccessful.

I first attempted a "fastboot boot twrp.img" (because I generally avoid overwriting stock recovery unless I need to) and fastboot thinks everything went fine, but the Cosmo goes black screen, vibrates, pauses about three seconds, vibrates again, and then boots Android.

Okay, so I decided to use fastboot to flash the image and used "fastboot flash recovery twrp.img", and once again fastboot thinks everything worked fine, but now when I boot into recovery, I'm getting stock recovery.

So, last thing I knew to try, I flashed the recovery partition using SP Flash Tool, which again appears to have gone fine, and yet I am still getting stock recovery on the Cosmo.

Any hints what might be happening here?

It's a bit tricky to get bootstrapped for a couple of reasons:
- in my experience, half the time the Cosmo ignores buttons and just decides to boot into normal Android anyway
- when booting into normal Android, the recovery partition automatically gets replaced by stock recovery*

So, you must flash it and then boot straight into recovery without starting up normal Android.

*: The caveat is that if the boot partition has been modified in any way (e.g. replaced with a rooted version), this replacement will not occur. So, if you flash a rooted boot.img (which you can do using fastboot or Flashtool) then it will not replace your recovery at all.

4

Cosmo Communicator - Hardware / Rooting the Cosmo Communicator

« on: January 30, 2020, 09:18:26 am »

Here's images for the V19 update:

Boot partition, unmodified: https://drive.google.com/file/d/1PHL6IlE3lq...iew?usp=sharing
Boot partition, rooted with Magisk: https://drive.google.com/file/d/1UqXZHeuPjr...iew?usp=sharing
Full images (~1.2GB): https://drive.google.com/open?id=1A9K04eyaX...sVVt3e6pVZGRA0Y

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

Take the V19 zip as an example: https://flare02.iofota.com/EASTAEON_FTPRO16...00118213137.zip
This is signed using an OTA certificate trusted by the Cosmo ( how to verify: 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.img
Next 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.img
Finally, 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.p
Using these steps and existing images from your Cosmo you should be able to reproduce the exact same files.

5

Cosmo Communicator - CoDi / Cover Display Subforum?

« on: January 23, 2020, 09:36:15 pm »

I just tried it and I got to see "Hello world      this is a static image" followed by a pattern of pixels  

I'll play around with it these days

Yep, I've managed to fix most of the issues and in my local branch I am very close to having all the groundwork needed for a functioning CoDi replacement. I'm experimenting with using LittlevGL for a GUI but am unsure if I will stick with it - it will depend on what performance I can get out of it.

At the moment I am fighting with a weird freeze bug that occurs at random times, where the main loop locks up inside HAL_Delay but interrupts continue to fire. It's quite hard to figure this out without a debugger...

6

Cosmo Communicator - CoDi / Cover Display Subforum?

« on: January 22, 2020, 06:58:49 pm »

I was afraid I had to root my Cosmo. I'm not sure if rooting the cosmo would leave me without the dual-boot update. I want to run GNU/Linux on my cosmo, so I'll think I'll wait until the update.

You can always flash the original boot image back and use the OTA updater that way, or you can just flash the partitions manually (which is the approach I take as I've been rooted since I got my Cosmo).

Then I'll root my cosmo. Even so, I think by then it will be easier to work with CoDi from Linux.

Sort of - there is no way to flash the CoDi from Linux right now. There's no technical limitations to it, mind you, it just needs code to be written...

On the meanwhile, I can still flash custom firmware with the assistant and then just reboot the device, right?

No need to reboot, it loads up immediately after flashing.

Also, once I want to go back to the original firmware, will the assistant just download it as an update or I have to manually download it?

Yep, the assistant will happily re-flash the original firmware as an update.

What happens if you simply try painting one quadrant of the screen (width/2 x height/2) a certain color?

Judging from how slowly the LCD redraws during a "swipe" gesture, my guess is the CoDi hardware doesn't even support a hardware blit (or at least isn't using it), probably just buffer swapping.

I don't know if it's possible to update just part of the screen, with the way the APIs work, but there might have been something I missed. The chip does seem to have some accelerated blitting features but I've not looked into these just yet as I've been trying to just get a simple framebuffer up and running.



edit: After a bunch of faffing about I managed to fix the issues. The code needs a lot of cleanup but it's now in a state where you could feasibly implement some initial stuff, it now accepts packets from the Android service (albeit almost all of them are ignored) and tells the CoDi assistant what version number it is. More soon, hopefully...

7

Cosmo Communicator - CoDi / Cover Display Subforum?

« on: January 22, 2020, 10:02:22 am »

Nice work! I took a quick look at your main.c and your twitter GIF of the screen issue.  Without my spending too much time studying the code, it looks possibly like an issue with your img.h data array or your blit not being matched to the screen's pixel format and/or width.  The LCD layer appears to be initialized with a size of 240x536 with RGB888 pixels: that's three bytes per pixel.  screen_buffer[] is the right size, but make sure your img[] array is of the same RGB888 format and that it's exactly 240 pixels wide (240*3=720 bytes per row).  One more thing to watch out for is rotation. If it's really a 536x240 display rotated 90 or 270 degrees, you'll want to rotate your img[] array first before blitting.  And a real pain of a problem is if the LCD timing is mismatched to the actual panel (ltdcHandle.Init.* parameters). It's a pain if you don't have docs for the panel you're stuck debugging!  This can cause odd sliding or flashing effects. Finally, if 240x536 or RGB888 isn't the real size or pixel depth of the panel used, your blit might jump all over the place if it's not static on the screen (or if it doesn't move, it'll be badly warped or discolored).

All of these are things I've tested already. The values I'm using for the LCD timing, DSI commands, etc are all taken from my disassembly of the CoDi firmware - I tried to replicate what they are doing as closely as possible, seeing as I don't have actual info on the CoDi hardware. I'm also not doing any blitting using the hardware yet; I'm keeping it simple by just telling it to draw a static framebuffer from 0x20000000, and that's still messing up.

I have a couple of thoughts on what to try next but haven't had the time to. I dumped the registers from all the peripheral memory regions while running the official CoDi FW so I could compare them to the values they have while running mine, but haven't gotten round to the latter yet. I also want to disassemble my resulting binary and compare it to the original one, just in case there's some discrepancy I've overlooked because of STM32 HAL changes between my version and whatever Planet used.

I'd like to test it, could you please give some instructions on how to reproduce what you were trying?

I do have some experience working with ARM microcontrollers with C and assembly. It would be nice to combine that with your advancements.

You will need:
- A copy of https://github.com/STMicroelectronics/STM32CubeL4
- The GNU ARM toolchain: https://developer.arm.com/tools-and-softwar...nu-rm/downloads (I used the latest version at the time of posting, 9-2019-q4-major)
- ADB and a rooted Cosmo (for debugging)

You will probably need to adjust the SDK_DIR in the Makefile to point to the STM32CubeL4 checkout (I should take that out of the Makefile when I get round to poking at this again) and then run as follows:

Code: [Select]

$ make GCC_PATH=/Users/ash/src/cosmo/gcc-arm-none-eabi-9-2019-q4-major/bin
$ adb push build/OpenCodi.bin /sdcard/Cosmo_firmware_custtest.bin
Then, flash the binary via the manual option in the Cover Display Assistant. You will want to keep a couple of adb shells open so you can send commands:

Code: [Select]

$ su
# cat /dev/ttyS1
# echo -n 1 > /proc/AEON_RESET_STM32; sleep 2; echo -n 0 > /proc/AEON_RESET_STM32Upgrading via the Assistant usually seems to terminate the 'cat' (probably because it changes the baud rate on the TTY) so you will have to re-run it. You'll probably miss some of the initial output that way so if I need to view something I will update it, run the 'cat' command and then do a reset in another terminal.

I've not yet implemented anything to let the CoDi go to sleep or turn off the screen while running this, so after flashing it will just stay in that mode until you flash the original firmware back. It does seem to reboot every so often, I'm not sure if this is some kind of watchdog mechanism in the STM32 that I'm not handling properly, or if this is the Android code forcing it to reboot because it doesn't reply to ping commands.

8

Cosmo Communicator - Hardware / Rooting the Cosmo Communicator

« on: January 21, 2020, 09:13:35 pm »

Here's images for the V19 update:

Boot partition, unmodified: https://drive.google.com/file/d/1PHL6IlE3lq...iew?usp=sharing
Boot partition, rooted with Magisk: https://drive.google.com/file/d/1UqXZHeuPjr...iew?usp=sharing
Full images (~1.2GB): https://drive.google.com/open?id=1A9K04eyaX...sVVt3e6pVZGRA0Y

9

Cosmo Communicator - CoDi / Cover Display Subforum?

« on: January 21, 2020, 09:07:50 pm »

The CoDi is exposed to the main OS via a UART on /dev/ttyS1 for general communication and files in /proc/ that map to certain bits of functionality (wake up, reset, enter-FW-update-mode button). Updates are handled via the same UART - the CoDi bootloader detects whether the update "button" is being "pressed" (obviously not a real button ) and if so, loads into an updater mode which accepts a file via a YModem transfer. Like most of the CoDi code it's heavily based off STM32 SDK samples.

I've been trying to write custom firmware for it, and I've gotten to the point where I have a binary I can flash that boots up, sends debug information over the UART and displays an image on the screen, but there's an issue with the display interface that I've not figured out yet.

My current code for this is here, if you're curious: https://github.com/Treeki/OpenCodi
And, an example of what it's doing right now: https://twitter.com/_Ninji/status/1219362735378530306

10

Cosmo Communicator - Hardware / Partitioning the Cosmo for multi-boot without losing your Android data

« on: January 18, 2020, 01:09:32 pm »

Planet have finally released the promised multi-boot option. Unfortunately, using their Recovery, you cannot reformat the Cosmo without losing all your existing data. I didn't want to wipe my Android install, so...

How it works

Stock, the Cosmo's partition map includes a very large userdata partition (combined Android /data and /sdcard) at number 38, followed by otp (39) and flashinfo (40).

When you partition the Cosmo, the userdata partition is deleted and replaced by these, in this order:
- 38: 32MB EMPTY_RECOVERY_BOOT_2
- 41: 32MB EMPTY_NORMAL_BOOT_3
- 42: 32MB EMPTY_NORMAL_BOOT_4
- 43: 30/60/90GB linux
- 44: 30/60/90GB userdata (Android)

The tricky thing is that the userdata partition is encrypted using Android's FDE system (using some metadata stored in the 'metadata' partition); getting access to this from recovery mode is quite a pain.

Also, to match the Cosmo's 'intended' configuration, your userdata partition needs to be physically located after the other partitions. I have not done this; I've left userdata where it started. The partition numbers and names are correct, but the exact sector boundaries are different. Hopefully this won't cause issues!

Planet's 60GB Linux/60GB Android split is defined as follows (start sector number, end sector number):
- 38: 10158080 - 10223615 (65536 sectors)
- 41: 10223616 - 10289151 (65536 sectors)
- 42: 10289152 - 10354687 (65536 sectors)
- 43: 10354688 - 127542188 (117187501 sectors / 55.87GB)
- 44: 127543296 - 244164543 (116621248 sectors / 55.6GB)

I have defined mine as follows, to keep userdata (44) starting at the same original position:
- 38: 126779328 - 126844863 (65536 sectors)
- 41: 126844864 - 126910399 (65536 sectors)
- 42: 126910400 - 126975935 (65536 sectors)
- 43: 126976000 - 244163436 (117187437 sectors / 55.87GB)
- 44: 10158080 - 126779327 (116621248 sectors / 55.6GB)

How to do it

Caution: This is extremely experimental; try it at your own risk!

First, you will need my build of TWRP installed: https://www.oesf.org/forum/index.php?showtopic=35988
You will also need ADB set up, and easy access to a hex editor of some kind.

- Boot into TWRP and run 'adb shell' to get a shell on the Cosmo.
- Run ls /data/ to check that userdata has been decrypted successfully: you should see some stuff in there.
- Tap Mount on the TWRP main menu and uncheck Data.
- Run mount to view mounted filesystems: /dev/block/dm-0 should NOT be mounted and should not show up in the list in any form.
- Use ADB to push parted_static (from the official Cosmo recovery) to /tmp: https://wuffs.org/files/parted_static
- Run chmod +x /tmp/parted_static

You are now ready to re-partition your Cosmo.

Run the following commands:

Code: [Select]

resize2fs /dev/block/dm-0 116621248s
/tmp/parted_static /dev/block/mmcblk0 rm 38
/tmp/parted_static /dev/block/mmcblk0 u s mkpart primary 126779328 126844863
/tmp/parted_static /dev/block/mmcblk0 name 38 EMPTY_RECOVERY_BOOT_2
/tmp/parted_static /dev/block/mmcblk0 toggle 38 msftdata
/tmp/parted_static /dev/block/mmcblk0 u s mkpart primary 126844928 126910463
/tmp/parted_static /dev/block/mmcblk0 name 41 EMPTY_NORMAL_BOOT_3
/tmp/parted_static /dev/block/mmcblk0 toggle 41 msftdata
/tmp/parted_static /dev/block/mmcblk0 u s mkpart primary 126910464 126975999
/tmp/parted_static /dev/block/mmcblk0 name 42 EMPTY_NORMAL_BOOT_4
/tmp/parted_static /dev/block/mmcblk0 toggle 42 msftdata
/tmp/parted_static /dev/block/mmcblk0 u s mkpart primary 126976000 244163436
/tmp/parted_static /dev/block/mmcblk0 name 43 linux
/tmp/parted_static /dev/block/mmcblk0 toggle 43 msftdata
/tmp/parted_static /dev/block/mmcblk0 u s mkpart primary 10158080 126779327
/tmp/parted_static /dev/block/mmcblk0 name 44 userdata
/tmp/parted_static /dev/block/mmcblk0 toggle 44 msftdata
Do not paste the entire block in at once; do one command at a time. You may receive warnings from parted about the partition being in use, since devicemapper keeps it open - type I and press enter to ignore these.

Once all these commands have been run, your Cosmo has been re-partitioned.
You may wish to check your resulting partition table against what I received:

Code: [Select]

# /tmp/parted_static /dev/block/mmcblk0 u s p
Model: MMC hDEaP3 (sd/mmc)
Disk /dev/block/mmcblk0: 244285440s
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start       End         Size        File system  Name                   Flags
 1      64s         2111s       2048s                    boot_para              msftdata
 2      2112s       67647s      65536s                   recovery               msftdata
 3      67648s      68671s      1024s                    para                   msftdata
 4      68672s      109631s     40960s                   expdb                  msftdata
 5      109632s     111679s     2048s                    frp                    msftdata
 6      111680s     177215s     65536s      ext4         nvcfg                  msftdata
 7      177216s     308287s     131072s     ext4         nvdata                 msftdata
 8      308288s     373823s     65536s                   metadata               msftdata
 9      373824s     390207s     16384s      ext4         protect1               msftdata
10      390208s     409599s     19392s      ext4         protect2               msftdata
11      409600s     425983s     16384s                   seccfg                 msftdata
12      425984s     524287s     98304s      ext4         persist                msftdata
13      524288s     528383s     4096s                    sec1                   msftdata
14      528384s     534527s     6144s                    proinfo                msftdata
15      534528s     739327s     204800s                  md1img                 msftdata
16      739328s     772095s     32768s                   md1dsp                 msftdata
17      772096s     774143s     2048s                    spmfw                  msftdata
18      774144s     786431s     12288s                   scp1                   msftdata
19      786432s     798719s     12288s                   scp2                   msftdata
20      798720s     800767s     2048s                    sspm_1                 msftdata
21      800768s     802815s     2048s                    sspm_2                 msftdata
22      802816s     833535s     30720s                   cam_vpu1               msftdata
23      833536s     864255s     30720s                   cam_vpu2               msftdata
24      864256s     894975s     30720s                   cam_vpu3               msftdata
25      894976s     927743s     32768s                   gz1                    msftdata
26      927744s     960511s     32768s                   gz2                    msftdata
27      960512s     1091583s    131072s                  nvram                  msftdata
28      1091584s    1093631s    2048s                    lk                     msftdata
29      1093632s    1095679s    2048s                    lk2                    msftdata
30      1095680s    1161215s    65536s                   boot                   msftdata
31      1161216s    1177599s    16384s                   logo                   msftdata
32      1177600s    1193983s    16384s                   dtbo                   msftdata
33      1193984s    1204223s    10240s                   tee1                   msftdata
34      1204224s    1228799s    24576s                   tee2                   msftdata
35      1228800s    2981887s    1753088s    ext2         vendor                 msftdata
36      2981888s    9273343s    6291456s    ext2         system                 msftdata
37      9273344s    10158079s   884736s     ext4         cache                  msftdata
44      10158080s   126779327s  116621248s               userdata               msftdata
38      126779328s  126844863s  65536s                   EMPTY_RECOVERY_BOOT_2  msftdata
41      126844864s  126910399s  65536s                   EMPTY_NORMAL_BOOT_3    msftdata
42      126910400s  126975935s  65536s                   EMPTY_NORMAL_BOOT_4    msftdata
43      126976000s  244163436s  117187437s               linux                  msftdata
39      244164544s  244252607s  88064s                   otp                    msftdata
40      244252608s  244285375s  32768s                   flashinfo              msftdata
Now, in order to make the smaller userdata partition decrypt correctly, you'll need to modify the size inside the metadata partition. Run this on the Cosmo:

Code: [Select]

dd bs=512 count=32 if=/dev/block/by-name/metadata of=/tmp/meta.binUse adb pull /tmp/meta.bin to pull the metadata partition out and open it in a hex editor. The file will begin as follows...

Code: [Select]

C4 B1 B5 D0 01 00 03 00 30 09 00 00 00 00 00 00
10 00 00 00 01 00 00 00 C0 A7 F2 0D 00 00 00 00
                        ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^The eight bytes highlighted above, C0 A7 F2 0D 00 00 00 00, are what you need to change - these must match the little-endian encoding of the userdata size. For my size of 116621248, these are: C0 7F F3 06 00 00 00 00. Replace these and save the file. Then, use adb push meta.bin /tmp/ to send it back to the Cosmo, and run this on it:

Code: [Select]

dd if=/tmp/meta.bin of=/dev/block/by-name/metadataYou can now exit the shell and reboot your Cosmo. You should receive the bootloader menu and all your Android data should be there.

11

Cosmo Communicator - Hardware / Keys getting stuck

« on: January 16, 2020, 08:20:18 am »

The one area I have noticed this from the time I received the Cosmo is in the top row keys. Numbers either don't work or type double. It makes entering passwords challenging. I've gotten used to it, as I use a very slow, deliberate quick, forceful press and release on these keys and it works most of the time. It does slow me down, but I'm hoping that the keys (or whatever) will settle over time and become more reliable.

Do you get this everywhere or just in certain apps? I have noticed that certain input fields give me double inputs on numbers, but it seems like a software issue as most fields handle them properly.

12

Cosmo Communicator - General Discussion / The unofficial official my cosmo has arrived thread

« on: January 14, 2020, 06:18:00 am »

Here are my details:

- Contribution ID 877, backed 5th November 2018
- UK keyboard/adapter
- Standard UK/EU radios

I'm not sure exactly when mine was locked, but I received separate dispatch emails from Planet and from Indiegogo 25th November 2019, along with a Royal Mail tracking number, and received my Cosmo the next morning.

The amount of delays and setbacks from the ODM is quite impressive, you'd think they would have figured things out after having built the Gemini where presumably they also had to deal with issues like different keyboard layouts. But no, they just keep on missing promised deadlines, and then you get these silly quality control issues, like people receiving devices without a SIM tray, or mine where they left a microSD card and a SIM card inside the tray...

13

Cosmo Communicator - Android / Once my Cosmo arrives, do I actually dare to use it?

« on: January 13, 2020, 07:59:51 am »

Would you be able to confirm that for updates targeted to different regions than yours?

As far as I know the updater used in every region is exactly the same, so this should affect all Cosmo units. (Are there even region-specific Cosmo ROMs?)

That is and has always been under Planet's control; they receive a package containing the updater APK and then incorporate it into the ROM. I highly doubt they would want to keep a backdoored updater in for any devices - in my communications with Planet, they were very adamant that they wanted to get rid of it ASAP. The reason I can confirm this is because they actually allowed me to examine the new updater just to make sure Digitime were not pulling a fast one on them.

I'm a bit disappointed they've not made any public comment yet, especially considering they promised an update on Indiegogo before the end of the week and it is now Monday. Hopefully we will hear something soon.

So good to hear PC takes this seriously and are willing to deal with it in the next(?) firmware update. --- @Ninji, I can't speek in the name of every Cosmo owner, but I feel like everyone of us owe you at least a cup of coffee or glass of beer. Without any intension to insult anyone or to break any rules of this forum, I suggest you to put your PayPal or crypto address in your signature or something, if you feel like it... Thank you anway.

I'd be fearful of coming across as just wanting money because that's not the case - I do things like this for fun and for the betterment of the software/hardware I use, not to make money. If anyone really wants to throw a pound or two at me then I have some links on my website's homepage, but please don't feel obligated to!

I'll have to color myself a bit skeptical of being overtly malevolent.  More likely this is encouraged by intelligence agencies in China.  They're not all that likely to think they can successfully target interesting European or US people.  Likely their main target is surveillance of Chinese citizens.  If the code leaks to the wider world, they may not be all that worried and will happily gather information from whomever ends up with an appropriately contaminated device.

It could probably be used for that purpose, but all the evidence I've seen so far points to Digitime just using it to install adware. One of the APKs I found, distributed through their CDN, just sits in the background and occasionally opens up ads sourced from an obscure domain (omuchain[.]com) that just so happens to be registered with the same false WHOIS info as one of their corporate domains (qimingiot[.]com).

Of course, all we can do is speculate about their motives - they're a secretive business based in China that only deals with other businesses, most of which also seem to be based in China. I would for sure like to know what they are, but I don't know if I'll ever find out.

(Speaking of, today is the 6th day of all their public-facing websites being entirely dead... ?)

14

Cosmo Communicator - Android / Once my Cosmo arrives, do I actually dare to use it?

« on: January 10, 2020, 09:55:53 pm »

So, amusingly, Digitime have now even taken down their websites. Caught red-handed??

I can confirm that the next Cosmo firmware update removes all the backdoors, both local and remote. I think Planet may also be shifting away from Digitime in the long term, but regardless of that, the changes in the next update get rid of Digitime's ability to download arbitrary code and applications, so the app behaves like the legitimate updater it purported to be all along.

(While in theory, Digitime could push a rogue update through it, the Android recovery system will reject OTA packages that are not signed with the manufacturer's certificate and private key, so unless they got hold of those keys, that should not be possible...)

15

Cosmo Communicator - Android / Once my Cosmo arrives, do I actually dare to use it?

« on: January 08, 2020, 02:00:17 pm »

I disagree; I'm certain that there is malevolent intent on Digitime's part. Why would they go so far to hide it, otherwise? The code is obfuscated, the server URLs used by the malware component use domains like 'flurrydata.com' and 'facebook-3rd.com' in an attempt to look like legitimate services, and moreover, today I discovered that Digitime actually pushed some new worker packages just 2-3 days after my email to Planet - a new empty feature-less one for the Cosmo, and a new build of the standard version for the Gretel A7.

I suspect that Planet talked to them and they went "oh crap, we've been discovered"... Curiously, they don't seem to have replaced the Gemini's (albeit I may have made a mistake in the check commands, as I don't have example packet dumps from a Gemini as I do for the Cosmo and the A7).

It's also quite amusing that the 'statistics.flurrydata.com' server that the boot module reports to appears to have stopped working; for every request it just returns a {"errinfo":"Too many connections","errcode":3} error. Probably not intentional...

I will write a follow-up blog post soon, but for now I need to catch up on university work. In the meantime, here is my reply to Planet which provides some more information:

Hello Davide,

It's great to hear from you about this, and to know that Planet is on the ball regarding the situation. My research has given me no reason to doubt Planet's privacy/security practices; my assumption all along was that Digitime was doing this without the knowledge of Planet or EastAeon.

There are more issues with the Digitime software, not just the Cosmo-only IOrgX/Y/Z backdoors. Note that there are effectively two 'sides' to the Digitime app. There is the legitimate OTA update process, which connects to the 'app.fota.digitimetech.com' server and fetches update information. This is somewhat insecure (it is vulnerable to SSL man-in-the-middle attacks) but that seems like a mistake, not malice.

The second side is the Lua service I documented in my blog posts, which is present in every Digitime SystemFota updater I have seen, including the Gemini's. It downloads arbitrary 'worker' code from domains like 'statistics.flurrydata.com' and 'facebook-3rd.com', which appears to be a deliberate attempt to hide by pretending to be part of a legitimate service. This is the system which was used to distribute malware on other devices like the Gretel A7.

There is one interesting development in this area which I only noticed today (as I had the SystemFota app disabled): Digitime have sent my Cosmo a new 'worker' package, which removes all of its functionality and leaves an empty shell. The code files in it are dated the 4th December 2019 (two days after my initial email to Planet Computers), whereas the other workers are all dated months/years older. The timing makes me wonder: did they suddenly do this in an attempt to save face after an enquiry from PC?

From my understanding, this doesn't actually disable their control over the device, as the 'boot' package (which is baked into the Android ROM's SystemFota.apk) still checks home regularly, and has the ability to download a new worker if Digitime changes their mind. This is all device-specific, so in theory, Digitime could for example decide to send a malicious code package to IP addresses connecting from certain countries, and this empty shell to IP addresses connecting from the UK (like you and I).

I have also experimented by sending requests to their server with the IDs of other known devices. If I pretend to be a Gemini, I get the regular worker that I started with on the Cosmo - not the empty shell that the Cosmo now has. If I pretend to be a Gretel A7, I get a newly built version of that worker, with a different version number, dated the 5th December 2019 - which furthers my suspicions that Digitime are trying to cover their tracks after this exposure.

I appreciate that Digitime has agreed to remove the OS backdoors, and that they seem to have disabled part of the malware-like functionality for the Cosmo, but none of these things should have been there in the first place. I personally would not trust an operator with this track record. Ultimately, however, it is Planet Computers who must decide if they want to trust Digitime with software distribution on their devices, not me - I am after all an outsider and not privy to the complex decisions that go into building a device like this.

Thank you for the detailed response and for taking my concerns seriously; it's a refreshing attitude in a world where many tech companies just sweep security issues under the carpet. Despite the teething software issues, I really enjoy the Cosmo and I can't wait to see it get better - I'm especially excited for the release of multi-boot so that I can experiment with OSes more.

Kind regards,
Ash