In a previous log we saw how the contents of the SPI flash chip can be dumped to a binary file over USB, the .bin file of this dump is attached in the Files area. We will now examine that file using a variety of linux-based tools (hex dump, binwalk, strings).

Here is my best guess of the map of the 16MiB flash chip, the table will be updated as we learn more:

The U-boot image starting at 0x010400 is LZMA compressed with a unique string of bytes as a footer. Removing this footer and uncompressing with unlzma reveals a binary containing MIPS instructions.

A JPEG image is held at address 0x070000 and is displayed during boot via HDMI. The image is the Manhattan branding for this unit and has a resolution of 720 x 576 pixels, it is displayed during the boot of the main application. A cool little hack might be to replace this image with something of your own :-) Image shown below.

The two blocks starting at 0x2E8000 and 0x2F0000 are identical redundant copies, clearly containing some important data that must be conserved should a write action to this area fail and brick the unit. Reverse engineering of the U-boot binary reveals them to be CRC checksums related to the main application image, the format of these will be explored later. The third block starting at 0x2F8000 is of unknown format at present.

The application images are compressed with a mixture of LMZA compression and ZLIB compression. They are uncompressed and executed by the U-boot boot sequence. Uncompressing these reveals an eCOS real-time operating system. This is the operating system for the satellite receiver application. One is a separate 'upgrader' application for software updates (more on this later). Disappointingly, it's not Linux, so we won't be able to hack our way to a root shell :-(

Finally we have application data and the 2x identical copies of the U-boot environment variables, again for important redundancy protection.

The initial boot sequence (up to U-boot) has been examined by studying the firmware dump and the M-boot manual (attached in the files area):

1.) Reset vector 0xBFC00000, BootROM code execution direct from flash
2.) DRAM, UART and other initializations
3.) BootRAM code copied to DRAM, at address 0x81000000 and executed
4.) U-boot LMZA image copied to DRAM at address 0x81100000
5.) U-boot image uncompressed to DRAM at address 0x871F0180
6.) Execution of U-boot MIPS code from same address.

From this point, the U-boot boot sequence takes over. In standard U-boot, the boot sequence should be specified in the environment variables (bootcmd). However, we know in this version of U-boot the sequence is instead hardcoded and the bootcmd is a inoperable. In fact, if we modify the bootcmd to include an echo statement + saveenv we do not get any feedback in the console during the full boot flow. It is highly likely the bootcmd is ignored in this version of U-boot and a hardcoded sequence is instead executed. How we therefore modify this sequence to autoboot a future custom OS is unclear, the only viable option at present to boot something custom using the U-boot command prompt.

So what and where is the hardcoded boot sequence in the U-boot binary? The DEBUG level commands in the console can provide some insight. However, to dive deeper we need to dissemble the U-boot code. I will aim to look at this in a future update.

Updated 24th November 2023