9

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.

Improve this question
10
  • 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? Commented Sep 24, 2018 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 Commented Sep 25, 2018 at 4:03
  • 2
    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 Commented Sep 25, 2018 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? Commented Sep 25, 2018 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. Commented Sep 25, 2018 at 12:22

0

Reset to default

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.