How a TV USB firmware package is built
A firmware file for a USB update looks like one opaque blob, but inside it is a stack of containers: an outer wrapper, a script or table, and partition images, often compressed. Knowing the layers tells you what you can read, change and rebuild.
Part of the Firmware and dumps guide.
Why look inside
- To find the version, model and SoC strings before flashing a file to the wrong TV.
- To see which partitions the package updates and which it leaves alone.
- To adapt a package to a different panel or remote, see the features page.
The layers
- Outer container. Depending on the vendor this may be a plain archive (tar, zip), a vendor format (the program recognises LG EPK, Philips UPG and Android OTA), or a raw binary with a header.
- Script or table. MStar-based packages start with a text script (commands such as
filepartload) that tells the bootloader which part of the file goes to which flash region. Other families use a header table. - Partition images. Typical payloads are a kernel, a DTB, an initramfs (cpio), and file-system images such as squashfs, cramfs, ext4, UBI/UBIFS or JFFS2, plus Android sparse images and boot.img.
- Compression. gzip, xz, lzma, bzip2, zstd and lz4 are all common wrappers around those images, and can be nested.
Reading an unknown file step by step
- Record the size and a hash (MD5 or SHA-256) so you can tell later whether the file changed.
- Look at the header bytes and the readable strings: versions, model names, SoC names, script lines.
- Scan for signatures. A magic number alone proves little, so a good scanner also validates the structure it finds (sizes, headers) to avoid false hits.
- Check the entropy. High, flat entropy means compressed or encrypted data; very low entropy means empty padding; mixed regions usually mean real file-system content.
- Unpack layer by layer, with a limit on nesting depth, into a clean folder.
If an image has high entropy and no recognisable signature, it is probably encrypted or uses a proprietary compression. Do not treat that as damage, and do not try to flash it back after hex editing: signature or checksum checks in the bootloader may reject it, or worse, accept a broken file. UNVERIFIED Which families check signatures varies by model; check the vendor documentation.
Typical mistakes
- Flashing a file chosen only by screen size. Compare the board and panel identifiers in the strings.
- Editing an image in place and keeping the old checksum or size field.
- Unpacking into the same folder twice, so old files mix with new ones.
- Assuming that “unpacked without errors” means “can be repacked identically”. Compression levels and file order change the result.
How this is done in FW Tool
- The “Firmware” tab shows a summary: size, MD5 and SHA-256, header, interesting strings.
- It scans for the signatures listed above and validates them; it also parses MStar scripts and cuts the file by partition.
- An entropy map marks compressed or encrypted areas and padding (a checkbox, on by default).
- Recursive unpacking has a nesting-depth setting (0 to 8, default 3). Some file systems need external tools such as 7-Zip or unsquashfs if they are installed.
- For tar-based packages the program can rebuild the package after you replace files.
- The “Adaptation” tab reads a supported package, shows the panel and remote settings it finds, and builds a changed package. See also LVDS mapping and bit depth.
Before touching a package, take a dump of the working device if you can: see comparing dumps and hashes.
FAQ
Can every firmware file be unpacked?
No. Encrypted or signed containers will show high entropy and no usable structure. The program tells you what it could identify; it cannot decrypt what it has no key for.
Which depth should I use?
Start with the default and raise it only if the result still contains archives. Greater depth means more disk space and time.
Is the unpacked data safe to flash?
Unpacked files are for inspection. Flash only a complete package that you rebuilt or obtained intact, on a device where you have a dump to return to.
A practical checklist before flashing
- The model, board and panel identifiers in the file match the TV you are repairing.
- The file size and hash match what the source states, if it states them. A download interrupted halfway is a common reason for failed updates.
- The USB stick is formatted as the manufacturer requires (FAT32 is the usual choice) and holds only the update file in the expected folder or name. UNVERIFIED File names and folder rules differ by platform; check the vendor instructions.
- You have a dump of the current memory, so a failed update can be reversed.
- The mains supply is stable and the TV will not be switched off during the update.
A package that looks fine on a PC can still fail on the TV for reasons the PC cannot see, such as a version check in the bootloader. Treat the analysis as a way to reduce risk rather than to remove it.