Emulating a main board CPU.

[lookimback]

After fixing 8 main boards yesterday and several dozen over the years, all having corrupted firmware, I've started thinking about the usefulness of a program which could run the dumped firmware and emulate the main board. Then I realized it wouldn't have to emulate the board, but rather, just the CPU. If the firmware is good, then the GPIOs should already be mapped and I'd just have to simulate the I/O. The idea being that, if you aren't sure your firmware is the problem, you run it on the emulator and see if you get the same result. If you do, buy an eeprom. If not, then go back to troubleshooting. But then I thought, isn't it possible something like this already exists? I mean, how do they write and test firmware in the first place? Wouldn't they have an IDE that could run and debug their program?

[tom66]

Re: Emulating a main board CPU.

Uh, good luck on that.

Look at a datasheet for even a basic microcontroller e.g. TM4C123GH6PM, I use this a lot in products I develop. It is an ARM Cortex-M4 with 32K of SRAM and 256K of Flash in its biggest configuration, probably ca 2 million transistors.

The datasheet is over 1400 pages long.
https://cdn.badcaps-static.com/pdfs/...07a3b6f488.pdf

You would need to implement something substantially more complicated, like a Cortex-A7, and you'd also need to implement an external environment for it to simulate. You'd need to implement DDR(2,3,4) SDRAM, flash, LCD controllers, clock sources, tuners, etc. etc.

[lookimback]

Re: Emulating a main board CPU.

I was looking at this earlier. https://www.unicorn-engine.org
I'm mainly interested in the MStar SoCs. I find them on the majority of boards I work on. I don't know if that emulator would work with them. I don't even know what architecture they are. Since it has bindings for Java, I could write the code to simulate the external environment.

[tom66]

Re: Emulating a main board CPU.

I honestly think you'd have more luck if you were able to enable debugging or switch on a UART port.
You are not going to be able to emulate an SoC without significant confidential knowledge about how that SoC works.

[lookimback]

Re: Emulating a main board CPU.

Yeah, I agree. What I currently do is I flash firmware from a similar board, like one which uses the same SoC, or at least one from the same manufacturer. At least in the case of MStar SoCs, it works almost every time provided that both firmwares were from the same size TV. I suppose it also matters that they both are either LVDS, or v-by-one. Buttons don't always have the same function, and image may sometimes be upside-down or even solarized, but going from something that powers on and just has a blank screen to something with a picture and responds to inputs is enough to confirm the problem is with the firmware. At that point I order one from SJ. It would probably be easier to just modify a main board for one of my test TVs by adding a burn in socket for testing.

[lookimback]

Re: Emulating a main board CPU.

I honestly think you'd have more luck if you were able to enable debugging or switch on a UART port.
You are not going to be able to emulate an SoC without significant confidential knowledge about how that SoC works.

Regarding how the SoC works, couldn't that be determined by reverse engineering the firmware? Also, maybe there's some other way of determining if the firmware is corrupted. Rather than emulating the CPU, maybe the binary file could be converted back into a file system and then analyzed for missing includes or corrupted files. At least in the case of MStar SoCs, they provide the drivers and a software development kit(SDK) to their customers. The only custom code in the firmware files is going to be the code which implements the functions in the SDK. The core files are going to be from the SDK. That's why I'm able to run firmware from completely different manufacturer on a board as long as it has the same or a similar SoC. So, I think recreating the file structure and parsing each file to find all the required include files, and then checking to see if they exist would be a good start to analyzing the firmware. I probably won't be able to get my hands on the actual SDK, but I could certainly recreate some of it by picking apart working firmware dumps. Binwalk is a pretty useful tool for this. I've been writing my own business software with Java since 2014. I'm certainly not a pro, but I can usually make something work if I put enough time into it. Forget the emulator idea, that's way too complicated and goes well beyond the actual need. The need is to be able to tell if a piece of firmware is corrupted or not and I think I can make a tool to do that.

[tom66]

Re: Emulating a main board CPU.

Regarding how the SoC works, couldn't that be determined by reverse engineering the firmware?

No

I have been reverse engineering a Samsung control board for a plasma TV out of interest, after a hardware hacking friend of mine was able to dump the firmware.

It took me about 8 hours to get to a basic stage of being able to understand some initialisation and error/exception handling, but I couldn't go any further, because I don't know what a write to register 0x1FE2930 does. I can infer some things, but without datasheets, I'm guessing. I managed to work out 5% of functions.

Also, maybe there's some other way of determining if the firmware is corrupted. Rather than emulating the CPU, maybe the binary file could be converted back into a file system and then analyzed for missing includes or corrupted files. At least in the case of MStar SoCs, they provide the drivers and a software development kit(SDK) to their customers. The only custom code in the firmware files is going to be the code which implements the functions in the SDK. The core files are going to be from the SDK. That's why I'm able to run firmware from completely different manufacturer on a board as long as it has the same or a similar SoC.

So, you can try mounting the filesystem if it is a SquashFS or similar file system. Try looking at the file header and bootloader for clues as to what filesystem it is. For instance SquashFS file systems being with a predictable header. See here:

http://www.devttys0.com/2014/08/muck...with-squashfs/

[lookimback]

Re: Emulating a main board CPU.

I tried to get started on this last night. I need a Linux OS because all the good hacking tools run on it. I installed Ubuntu in VirtualBox, but it was super slow and then crashed and wouldn't load again. I'm going to just partition my drive and add it as a second OS. Then, I'll see what Binwalk and Sasquatch reveal. I've never done much with firmware aside from using compare tools to see the differences between a working file and a non working file. That revealed whole blocks of empty space in the corrupted file. I don't think I really need to know how the firmware works, per say. I think if I can identify it's dependencies and scan for missing or corrupted ones, that would be enough for most cases. If the problem is configuration files altered by users, I probably won't be able to test for that because I'd have no way of knowing what's correct and what isn't, but I suspect that would account for very few cases. Of course, this all assumes that I'm going to open a file and see include or import some file, like in C and Java, and then be able to check the existence of that file.

[lookimback]

Re: Emulating a main board CPU.

Here's the pinout from a common MStar SoC. I noticed it has a UART interface. Is it possible use it read or reflash the eeprom? Or would this require knowing special commands which are probably confidential? Also, same question regarding the SPI interface. I'd like to find a way to do this without removing the eeproms, since it could save me a significant amount of time.

[tom66]

Re: Emulating a main board CPU.

Well, it looks like this CPU is too basic to run Linux, it has no RAM interface.
So the firmware will likely be an ELF blob, ARM or something similar.
It is perfectly normal to have blank spots in the firmware.
You will need SDK & documentation and software like IDA Pro to look at the firmware in detail.

[lookimback]

Re: Emulating a main board CPU.

Well, it looks like this CPU is too basic to run Linux, it has no RAM interface.
So the firmware will likely be an ELF blob, ARM or something similar.
It is perfectly normal to have blank spots in the firmware.
You will need SDK & documentation and software like IDA Pro to look at the firmware in detail.

I think I still have a working copy of IDA pro somewhere. The firmware I was referring to were from 2 identical boards, and same version numbers. They were about 90% the same. Blank areas on the one were full of data on the other.

[tom66]

Re: Emulating a main board CPU.

Well, that could indicate corrupted flash, but it is hard to know without fully analysing the firmware.

[lookimback]

Re: Emulating a main board CPU.

Well, that could indicate corrupted flash, but it is hard to know without fully analysing the firmware.

The one with blank spaces didn't work. It was a while ago and I can't remember exactly what it did. I think it was either no functions from buttons other than power, or it was no backlight. I'm almost certain it was a Seiki SE322FS.

[lookimback]

Re: Emulating a main board CPU.

Regarding that SoC, isn't it possible the RAM is internal?

[tom66]

Re: Emulating a main board CPU.

Regarding that SoC, isn't it possible the RAM is internal?

Almost certain it has some RAM, but not much more than a few hundred K.

It depends on what it needs to do, but image scaling can be done with just two/three video line memory (if you don't really care how it looks) so you can build a TV SoC without external RAM these days. No way you could do that if you wanted anything remotely smart or advanced image scaling or video decoding.

[lookimback]

Re: Emulating a main board CPU.

Almost certain it has some RAM, but not much more than a few hundred K.

It depends on what it needs to do, but image scaling can be done with just two/three video line memory (if you don't really care how it looks) so you can build a TV SoC without external RAM these days. No way you could do that if you wanted anything remotely smart or advanced image scaling or video decoding.

I'm guessing that's one of the big differences between the cheap Chinese brands, and the quality brands like Samsung, LG, and Sony.

I finally got Ubuntu installed. I wanted to install it alongside of Windows on my desktop, but the HD is 9 years old. I ran CrystalDiskInfo and it said its healthy, but with over 17000 hours, I think it could fail at any time. Messing with partition tables could push it over the edge. Ironically, I cloned it to a 1tb drive I recovered from a DVR box which only had 16 hours on it, and after only one successful boot it started saying short DST failure. CrystalDiskInfo says it's fine, but I couldn't get it to boot before. Anyway, I installed Ubuntu on a drive I took out of my old laptop, so I'll be able to start messing with some of these firmware images and see what architecture they are and whatever else I can get from them.

[lookimback]

Re: Emulating a main board CPU.

Ok, I just ran binwalk on a firmware image from a Hisense 32H3E. Some of the output is below. It was too long so I cut out some in the middle. I'm going to work on decompressing the file system now.

[/CODE]DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
98819 0x18203 Unix path: /eden/pm/core/interrupt.c
98966 0x18296 Unix path: /eden/pm/core/timer_cb.c
101602 0x18CE2 MySQL MISAM index file Version 4
2246688 0x224820 JPEG image data, JFIF standard 1.02
2768406 0x2A3E16 Copyright string: "Copyright (c) 2003-2005, SIL International (http://scripts.sil.org/)."
2770028 0x2A446C Copyright string: "copyright statement."
2770147 0x2A44E3 Copyright string: "Copyright Holder."
2771125 0x2A48B5 Copyright string: "copyright notice and this license. These can be"
2771541 0x2A4A55 Copyright string: "Copyright Holder. This restriction applies to all "
2771776 0x2A4B40 Copyright string: "Copyright Holder or the Author(s) of the Font"
2771956 0x2A4BF4 Copyright string: "Copyright Holder and the Author(s) or with their explicit written"
2773064 0x2A5048 Copyright string: "Copyright (c) 2010, NHN Corporation (http://www.nhncorp.com),"
2773665 0x2A52A1 Unix path: /help.naver.com/ops/step2/faq.nhn?faqId=15879
2773730 0x2A52E2 Unix path: /dev.naver.com/projects/nanumfont/download/259?filename=NanumGothic_Coding.zip
3998921 0x3D04C9 LZMA compressed data, properties: 0x64, dictionary size: 65536 bytes, uncompressed size: 131072 bytes
3999041 0x3D0541 LZMA compressed data, properties: 0x64, dictionary size: 65536 bytes, uncompressed size: 131072 bytes
3999065 0x3D0559 LZMA compressed data, properties: 0x64, dictionary size: 65536 bytes, uncompressed size: 131072 bytes
3999185 0x3D05D1 LZMA compressed data, properties: 0x64, dictionary size: 65536 bytes, uncompressed size: 131072 bytes
3999209 0x3D05E9 LZMA compressed data, properties: 0x64, dictionary size: 65536 bytes, uncompressed size: 131072 bytes
3999329 0x3D0661 LZMA compressed data, properties: 0x64, dictionary size: 65536 bytes, uncompressed size: 131072 bytes
3999353 0x3D0679 LZMA compressed data, properties: 0x64, dictionary size: 65536 bytes, uncompressed size: 131072 bytes
3999425 0x3D06C1 LZMA compressed data, properties: 0x64, dictionary size: 65536 bytes, uncompressed size: 131072 bytes
3999473 0x3D06F1 LZMA compressed data, properties: 0x64, dictionary size: 65536 bytes, uncompressed size: 131072 bytes
3999497 0x3D0709 LZMA compressed data, properties: 0x64, dictionary size: 65536 bytes, uncompressed size: 131072 bytes
3999617 0x3D0781 LZMA compressed data, properties: 0x64, dictionary size: 65536 bytes, uncompressed size: 131072 bytes
3999641 0x3D0799 LZMA compressed data, properties: 0x64, dictionary size: 65536 bytes, uncompressed size: 131072 bytes
3999761 0x3D0811 LZMA compressed data, properties: 0x64, dictionary size: 65536 bytes, uncompressed size: 131072 bytes
3999785 0x3D0829 LZMA compressed data, properties: 0x64, dictionary size: 65536 bytes, uncompressed size: 131072 bytes
3999905 0x3D08A1 LZMA compressed data, properties: 0x64, dictionary size: 65536 bytes, uncompressed size: 131072 bytes
4000049 0x3D0931 LZMA compressed data, properties: 0x64, dictionary size: 65536 bytes, uncompressed size: 131072 bytes
4007113 0x3D24C9 LZMA compressed data, properties: 0x64, dictionary size: 65536 bytes, uncompressed size: 131072 bytes
4007233 0x3D2541 LZMA compressed data, properties: 0x64, dictionary size: 65536 bytes, uncompressed size: 131072 bytes
4007257 0x3D2559 LZMA compressed data, properties: 0x64, dictionary size: 65536 bytes, uncompressed size: 131072 bytes
4007377 0x3D25D1 LZMA compressed data, properties: 0x64, dictionary size: 65536 bytes, uncompressed size: 131072 bytes
4007401 0x3D25E9 LZMA compressed data, properties: 0x64, dictionary size: 65536 bytes, uncompressed size: 131072 bytes
4007521 0x3D2661 LZMA compressed data, properties: 0x64, dictionary size: 65536 bytes, uncompressed size: 131072 bytes
4007545 0x3D2679 LZMA compressed data, properties: 0x64, dictionary size: 65536 bytes, uncompressed size: 131072 bytes
4007617 0x3D26C1 LZMA compressed data, properties: 0x64, dictionary size: 65536 bytes, uncompressed size: 131072 bytes
4007665 0x3D26F1 LZMA compressed data, properties: 0x64, dictionary size:

Post too long, cut out some here.

4106137 0x3EA799 LZMA compressed data, properties: 0x64, dictionary size: 65536 bytes, uncompressed size: 131072 bytes
4106257 0x3EA811 LZMA compressed data, properties: 0x64, dictionary size: 65536 bytes, uncompressed size: 131072 bytes
4106281 0x3EA829 LZMA compressed data, properties: 0x64, dictionary size: 65536 bytes, uncompressed size: 131072 bytes
4106401 0x3EA8A1 LZMA compressed data, properties: 0x64, dictionary size: 65536 bytes, uncompressed size: 131072 bytes
4106545 0x3EA931 LZMA compressed data, properties: 0x64, dictionary size: 65536 bytes, uncompressed size: 131072 bytes
4131299 0x3F09E3 Unix path: /4/F/X/j/
4164067 0x3F89E3 Unix path: /4/F/X/j/
[/CODE]

[lookimback]

Re: Emulating a main board CPU.

Well, here's the splash screen image. Now, if I could figure out how to replace that image I have a Polaroid 50GSR3000 I could fix. SJ has an eeprom for an Element which uses the same board and panel, but doesn't have it for the Polaroid.

[tom66]

Re: Emulating a main board CPU.

have you discovered if it is a SquashFS type filesystem or something else?

[lookimback]

Re: Emulating a main board CPU.

have you discovered if it is a SquashFS type filesystem or something else?

I just got the LZMA decompressed a few minutes ago. What I ended up with is another binary file.

Scan Time:   2018-09-22 03:52:45
Target File:  /home/swappart/Documents/extracted/_Hisense-tp.ms3393.pb851-173397.bin-0.extracted/23880
MD5 Checksum: 520e7b535b76afb4b035a23be016e069
Signatures:  386

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