Mstar Semiconductor are a relatively-new player in the ARM eLinux/Android world, probably best known today for SoC’s that power budget-orientated smart TV’s from Kogan and ALDI and the like. Over the last few years they’ve had significant growth, especially since the launch of the impressive MSO9180 chipset which powers devices such as the Xtreamer Prodigy 4k. Up until now there has been no way for the general public to unpack (disassemble) and repack their firmware bundles (i.e. MstarUpgrade.bin) – hackers rejoice, now you can!
As a contributor to Xtreamer devices, these scripts were written out of necessity. As is the case with a lot of horizontal business, Xtreamer do not have access to the Mstar SDK for editing firmwares but instead collaborate with the ODM (who serve other companies that operate in different markets to request desired changes) – a process typically known as “rebadging”. This is a painful system for development and 0-day bugfixes when the retailer has their own developers like myself, waiting for their changes when it’s something I could theoretically do in a fraction of the time.
If you want to check it out, the AutoIt scripts are located on my github repo here. Though please consider the scripts as proof of concept only, along with the following:
- The scripts experimental and may contain bugs. Currently, it has only been tested on the release-model MSO9180 chipset (specifically, the Xtreamer Prodigy 4k)
- They’re written in AutoIt, which means Windows-only. Please don’t ask me for any Linux port – any decent developers/engineers should have access to both really ?
- The script is very fast but has a relatively high memory requirement. Peak commit charge of the script will be roughly four-times that of the firmware bundle filesize – this is because the entire thing is loaded into RAM. As said, it’s fast but if you have too little RAM then paging may occur and you’ll get a significant speed loss. Testing a ~650MB bundle, on my old 4GB Notebook (DDR3 @ 1066) the HDD gets a thrashing and it takes about 4 minutes to unpack (paging/swapping, obviously) however my main development machine with 16GB (DDR3 @ 1333) takes about 30 seconds for the same bundle.
- Repacking is much faster than unpacking and has far lower memory requirements.
- Currently it relies on hard-coded values that must be manually adjusted in the header script (chunk sizes and offsets) – again, proof of concept. Keep an eye on commit logs for improvements to this. Read on for details on the structure of these firmware bundles.
- Bootloader script file – always 16KB (padded to fill)
- Chunk 1
- Chunk 2
- Chunk n […]
- Unknown 8-bytes, plain digits (serial number?)
- Bootloader script CRC32 (byte-swapped)
- Unknown CRC32 (research pending – preserved as-is for now) (should be byte-swapped too)
- Unknown bootloader commands (Not sure what these are for – they’re preserved as-is regardless)