Inside the UE55MU6452U big screen TV, analysis, decoding and flash simulation for the agent

Ever wondered what sits in the Flash memory from a modern TV? I invite you to a short presentation of the inside of the Samsung UE55MU6452U 55" 4K UHD Smart TV combined with reverse engineering and emulation of the T-Con controller firmware. Here I will show how such a TV is built, how its backlighting is realised and what components can be recovered from inside. Finally, I will also try to rip the contents of the Flash memory from inside, decode it properly, determine its architecture, UART addresses and fire it up in a simple emulator.

Disassembly and backlighting
I started the disassembly with the screen itself. In LCD TVs, the image is generated by the liquid crystal matrix, while the backlight is a separate module behind it. This used to be implemented using CCFL fluorescent tubes, but now we have LED TVs. The LED strip is only on the bottom edge of this unit, but their light passes through several layers of diffusers and diffuser films that evenly illuminate the entire panel surface.

With the back cover removed, you can see the two main modules of the TV - the power supply and the motherboard. There are also, of course, the speakers.

Power supply L55E6R_KHS
The power supply is essentially built from two modules. Here we have a separate power supply for the motherboard, in this case 12.8 V at just over 5 A, and separately we have a constant-current power supply for the LED backlight, depending on the version this can be 198 V 370 mA at 300 Hz.

These types of power supplies are usually single-sided boards. Some of the components, especially the larger ones, are threaded and some, including the ICs, are SMT. Interestingly, the pulse transformers and the 400 V capacitor have been specially mounted in the PCB cutouts to reduce the height of the PCB.

Of the components here, we have 10N60M2 MOSFETs, 60S380CE transistors and U10A6C1 ultrafast diodes.



Main board
The motherboard is realised using surface mount assembly. The PCB is double-sided, but the components are only on the top. What we have here is essentially a small computer, complete with processor, memories, inverter and I/O section.

The loudspeakers are driven by a TAS5749M class-D audio amplifier:

With the heatsink removed:

Components such as the CPU, RAM and Flash are already assembled using BGA (Ball Grid Array) technology. This provides higher interconnect packing density, better electrical properties and a more compact chip design, while unfortunately making manual repair and soldering of these components more difficult.

After cleaning the paste, the CPU can be identified - SDP1601 ver. 05:

I couldn't find any information about it on the web, except for a wikimedia page with a gallery from a rather similar TV:
https://commons.wikimedia.org/wiki/File:Samsu...E40MU6409U_-_board_-_Samsung_SDP1601-5286.jpg


Flash memory from T-Con?
The T-Con (Timing Controller) is the controller that controls the LCD matrix and is responsible, among other things, for generating control signals for the pixels. The first bone of the 25Q80DVSIG is located at the edge of the PCB. Its SPI line leads to the pads from the missing connector.

The data entropy is quite high, but only up to offset 0x19000. Beyond that, the memory is empty.
Here I've already found interesting sections that look like subtitles, but in some strange language. Or maybe something is messed up?

A quick analysis of the letters shows that we have the byte order changed. I have given examples to confirm my idea in the table:

Rough (as in file)	Decoded (32-bit byte-swap)
	locnIcerrhc tskce	Incorrect checksum
oB dnito!! g	Booting!!!
	CIMPATS_ER_TT_DA_EPYS	SYS_TYPE_AD_TT_RE_STAM PIC
NOCTamI I eg ofns%	TCON Image Info sd%

I made a program to flip all the bytes:

In the subtitles I found information about the processor - aeabi Cortex-M0. In addition, there are a lot of error messages, about Flash memory and about T-Con:

It also looks like there is a command line:

Various types of Flash are supported:

What is Demura? Demura is an LCD matrix calibration technique that compensates for brightness and colour imbalances between individual pixels. The correction data is usually stored as LUT arrays.

LUT? Lookup table? But what is an SDC? Is it about colour mapping?



Flash memory from T-Con - part 2 - analysing and defining the UART registers
I loaded the Flash into Ghidr, used the ARM:LE:32:Cortex settings. The instructions and functions are decoded correctly.

You can quickly find there references to subtitles, for example to UART_RDY, in the screenshot below we have the ldr instruction which loads a pointer to this subtitle, just after that the 74f8 function is called. I wonder what it can do with this write....

A first glance doesn't explain it yet, but let's not give up:

One of the subfunctions looks like an iteration of a null-terminated byte:

Each character is processed by another routine, which first seems to wait in a loop until the UART is free, and then sends one byte:

FUN_00004d60 just investigates lighting up the third bit on the value with address DAT_00004d6c. Ready flag? Whereas something writes to the value with DAT_00004de0.... but DAT_00004de0 is a pointer, what is there in memory?

There is the address of the UART_TX_DATA register there, which is 0x009D0E20! It is this register that continues to send characters. Similarly, the other registers can be specified:
- 0x009D0E00 = UART_CTRL (on/off, value 0x3)
- 0x009D0E04 = UART_BAUD (baud, value 0x3085)
- 0x009D0E10 = UART_STATUS (bit 2 = TX ready)
- 0x009D0E20 = UART_TX_DATA (byte to be sent)
- 0x009D0E28 = UART_FIFO_CFG (FIFO depth 0x50?)
The correctness of this can only be verified.

Flash memory from T-Con - part 3 - emulation
Finally, I prepared a simple emulator PoC (Proof of concept) in Capstone deassembler and Unicorn emulator in Python. In addition, the whole thing emulates basic peripherals and has patches for some instructions. I captured operations on the extracted UART registers. The result is the following boot log:

This confirms the identification of the registers and gives hope that after compiling the firmware ourselves we would also be able to display text.


Flash memory at the CPU
The second Flash memory found is located right next to the CPU. Its designation is 25Q40CLSIP, from which its size can be deduced: 512 KB. I was betting that here, as on the computer, sits some BIOS.

I unsoldered and ripped it with CH341:

I started with an entropy analysis. Entropy is a measure of the disorderliness of data - the higher it is, the more random the bits in memory are. In the context of flash memory, it allows you to quickly assess which bits are ordered and which bits contain random or compressed data.

Here, too, the subtitles are rearranged:

You can quickly find interesting identifiers. Compilation date:

I2C bus:

HDMI (Consumer Electronics Control) CEC controller:

ADC messages:

MiCom - communication with the microcontroller?

Here too everything loads nicely into Ghidr when ARM Cortex mode is selected, Little Endian byte order. I also reverse the words beforehand so that the subtitles look correct:

The more important features are even conspicuous. Let's take a look at this random code snippet for example - what is FUN_00010068?

It's probably displaying error messages, the argument is a Flash write:


Third Flash memory
Finally, a little curiosity - there was also a memory bone on the matrix itself, but I did not keep it after disassembly and did not examine its contents. I need to do this on my next TV:




Summary
What a surprise, this was supposed to be a demonstration of the inside of a TV, and along the way it turned into an attempt to reverse-engineer flash memory from TCON. In a similar way, it also managed to slightly decode the other memory, the one around the CPU. Both were characterised by a reversal of bytes in words, which was evident from the various messages left behind after a simple 32-bit byte-swap was performed the memory writes started to arrange themselves into readable debug messages, which made firmware analysis much easier. This made it possible to determine that the T-Con controller uses an ARM Cortex-M0 processor and to identify parts of the multitasking system and UART support. The code analysis also identified the addresses of the UART registers, which made it possible to create a simple Proof-of-Concept emulator that can capture the firmware boot log. The second Flash memory, the one next to the CPU, I spent slightly less time on, but it looks like a small initialisation firmware. In its contents you can find support for various peripherals such as I2C, HDMI-CEC or ADC, as well as communication with an additional microcontroller. It is not, however, a BIOS.
Ultimately, it turns out that even individual TV modules have their own microcontrollers and firmware, which can be analysed just like other embedded systems. Even a simple analysis of the binaries can reveal quite a lot of information about the operation of the entire device.
The results are quite encouraging and give hope, in a way, for compiling and running one's own programme on this type of chip. Even a simple LED flashing classic would be enough to start with, although analysis of the UART also gives hope of displaying custom messages. Perhaps I will also attempt such a thing, although I admit that I must first find a board where the clip from CH341 works, or find a way of programming without dumping the memory, because, however, repeatedly re-soldering circuits somewhat increases the time-consumption of such a game.
I don't know how much I'll divide myself yet in the context of this particular board, but I already have a few others in stock, complete and in working order, from smash-and-grab TVs, and there I've determined that there is room for experimentation.
Will it be possible to turn a TV into an Arduino? We will find out soon enough!