I'm TV repair tech and I've found that corrupted firmware is responsible for the failure of a large portion of the TV's I work on. I came up with the idea that if I could reverse engineer the firmware, I could probably write a script which could analyze a fw image and determine if it's corrupted or not. The current method involves buying a preprogrammed eeprom, at a cost of $15, and at least half the time it ends up being a waste of money.

I've done some testing with UART and found that I get the same messages at boot whether the fw is corrupted or not, basically saying everything is OK. That leads me to believe that the problem is with the file system. And that's pretty much where I'm stuck. I've tried binwalk, and after some time I have been able to extract and decompress about 3mb of LZMA compressed data and a JPG which is the splash screen, but I can't find the file system.

Running binwalk on the original binary, I get this:

101602        0x18CE2         MySQL MISAM index file Version 4
145536        0x23880         LZMA compressed data, properties: 0x5D, dictionary size: 67108864 bytes, uncompressed size: 3126792 bytes
2246688       0x224820        JPEG image data, JFIF standard 1.02

For whatever reason, I can't seem to extract the MISAM part.

Running binwalk on the decompressed LZMA part I get this:

1484791       0x16A7F7        PARity archive data - file number 24064
1715704       0x1A2DF8        MySQL MISAM index file Version 4
1764734       0x1AED7E        Boot section Start 0x0 End 0x100

I've tried extracting the PARchive and boot sections with dd, but I can't open them. I think it's because of trailing garbage. I've used hexdump and searched for magic bytes, but can't find any. Any suggestions would be greatly appreciated. I can also provide a copy of the fw if anyone cares to take a stab at it.

  • 2
    Could you go into more details about what you mean by "corrupted firmware is responsible for the failure"? How'd you reach that conclusion? Additionally, if there's a firmware issue, I assume a firmware update or a service restore will fix it. Have you tried that?
    – NirIzr
    Sep 24 '18 at 23:56
  • 1
    Be aware that since binwalk scans for specific byte sequences (signatures) false positives can be an issue. A signature scan needs to be done in conjunction with other methods of analysis in order to be meaningful
    – julian
    Sep 25 '18 at 4:03
  • 1
    First do an entropy scan of the firmware binaries to make sure if there are any compressed or encrypted areas or not. Then see if you can do a diff of the known good firmware binary with a suspected corrupted binary to find out how they differ on a byte-by-byte basis. Perhaps you could share the binaries with us as well
    – julian
    Sep 25 '18 at 5:16
  • 1
    have you tried dumping the flash from a known good chip and flashing the image onto a broken one? did it work?
    – Igor Skochinsky
    Sep 25 '18 at 7:51
  • 1
    Here's the firmware image. The SoC on the boards is made by MStar, and according to their website, they provide software drivers and an SDK to their clients for easy custom development. That's probably why I can find so many similarities in images from unrelated brands. Also, the boards appear to be designed by the same company. I'm hoping to be able to recreate the SDK from extracted samples.
    – Swappart
    Sep 25 '18 at 12:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.