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.
The Mstar firmware “bundles” (as I call them, not sure of any tech term) are of similar design to a CPIO archive – no compression, and each chunk is just appended to the end of the other. Structure is as follows from header to footer, but keep in mind this research is based only on MSO9180 bundles – older Mstar SoC bundles do follow a different structure:
  • 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)
From what I can tell, each chunk is padded to an 8KB boundary. A “chunk” is usually a partition of some sort – in the case of Android, this could be recovery.img, userdata, etc. I’ve noticed that “system” (and possibly others for other devices) are “multi-volume” LZO archives – unpacking of these is not implemented. Such a thing will likely only be useful on Linux in order to preserve filesystem permissions.
None of this would have been possible if it weren’t for the script file at the header – plain bootloader commands reveal the chunk names (i.e. target partitions), offsets and sizes – among other things.
Before flashing a modified firmware bundle, I highly recommend you ensure to have working TTL access to whatever Mstar device you’re flashing. Not only will you get verbose output during the flash process for debugging, but it will allow you to recover your device manually in the case of a brick.
Any questions or issues? Just let me know via a new comment. Also, pull requests welcome for other Mstar SoC support. Enjoy!