Introduction
The Hisense 50A6N is a chinese smart TV which offers 4K resolution. While the TV seems solid and is sold at a cheap price, it failed right after it went out the warranty, a defect in the screen’s backlight board. This gave me an oportunity to pry it open and take a look at the insides of the boards.
Internal Photos
The TV has 4 boards, not counting the flexible PCBs that the display uses.
Main Board
It’s main board houses the power section, the on-board computer (since this is a smart TV, I assumed it used Android).
The main board’s name is he50a6109fuwts. Taking a close look at it, we can segment the more interesting parts from the “dumb” components.
The CPU sits behind the black heatsink, and if that doesn’t give it away, maybe the backside of the board with all the fine traces leading to it may give it away. To see the CPU the heatsink needs to be desoldered.
| Component | Name | Image | Datasheet |
|---|---|---|---|
| CPU | MStar MSD6886NQGAT-8-00GH |  |
Not available |
| RAM | Samsung 512MB DDR3L K4B4G1646E |  |
Alldatasheet |
| EMMC Flash | Toshiba 4GB THGBMDG5D1LBAIL |  |
Alldatasheet |
The other ICs are not interesting, they are audio amplifiers, inverter ICs, etc.
We will take a closer look at the flash storages after inspecting the other boards.
Display Board
The second board’s name is CV500U2-T01-CB-1 and is the board that connects to the display. This display board is the second largest board, and is connected with a ribbon cable to the main board, and with other 2 big connectors to the display.
| Component | Name | Image | Datasheet |
|---|---|---|---|
| CPU | CHOT CCU1221A11N |  |
Not available |
| SPI Flash | Boya Microelectronics 2MB 25D16ASSIG |  |
Lcsc |
WiFi Board
The third board is named WTA1. This board also has an FCCID on the EMI shield. This board is the WiFi/Bluetooth interface of the TV, and the patch antennas are on the side.
If searching on the fccid.io website, we can find some useful info about it. It has a microcontroller, MediaTek MT7638GUN controlling the WiFi/Bluetooth interfaces. shoutwiki has a database of these microcontrollers, since the official Mediatek no longer has it on their website.
The FCC external photos also say which antennas are used for WiFi and which is the Bluetooth antenna.
The PCB has interesting markings on the backside and on the topside, which are USB, used as the default communication protocol, and UART, for programming/debugging, I assume.
IR Board
The last board’s name is RSAG7.820.8441 (I think). This last board can be found seated in the case of the TV, and it is used for controlling the infrared remote, since it also has IR receiver. Also, it has the physical button to turn on the computer.
Taking a closer look at the pinout, on the PCB are neatly written the pins’ role. The board has an I2C bus, LED signal input and keys/infrared outputs.
Flash Analysis
The flash contents of these boards was extracted using a flash reader, an XGecu T48.
Display board flash
The first flash chip I analyzed is the flash chip, since it is much smaller, and easier to read, since it’s an SOP8, as opposed to the BGA153 package of the main board’s EMMC memory. The flash contents for the display board can be found in the GitHub repo.
Most of the memory is empty, and the contents that are not empty are semi-readable, and it looks like a logging memory.
Searching for “demura” on the internet yields some info about the Demura display calibration technology, which improves the quality of the display - in other words, boring for us. It must contain some factory calibration data.
Main board flash
The other memory was harded to acquire, since it’s in a BGA153 format. This requires chip-off extraction, with a hot air gun. I didn’t bother to reflow it to the PCB again. If you want to analyze it further, you can try at this Mega upload link, since it’s almost 1.5GB in size.
I unpacked the firmware using binwalkv3, since the firmware is big, and original binwalk takes a long time. I found lots of partitions, so I decided to use emba to automatically analyze it in parallel with me, since it will take some time (it took 20 hours, in retrospect) to analyze the firmware.
Manual findings
I entered manually every partition on the flash storage, inspected the files of this Linux distribution (was expecting to find an Android OS), then compiled a list of interesting files.
As a shorter list of findings, these were found:
- Private keys
- WiFi SSID & password
- Device ID
- Certificates
- Network configuration files
- Local TV channels database
- Users and their hashed passwords
- Bash scripts
For the users, I tried brute-forcing them using the breachcompilation wordlist, but it didn’t yield any result.
EMBA findings
The automated EMBA scan finished after 20 long hours, the logs can be downloaded from this Mega link.
After the report was generated, I already had a general view of the firmware, so I jumped directly to what vulnerabilities it discovered on the system, in the F20 vulnerability aggregator module.
While it contained lots of CVEs, most of them didn’t have an exploit available that was also marked as remotely exploitable. Two of them, however, were exploitable:
CVE-2020-12351 is also called BleedingTooth, and it’s based on an improper input validation in the BluZ Bluetooth protocol stack. BleedingTooth can be used by an attacker to get remote code execution by sending a specially crafted L2CAP packet to the target device. A demo has been uploaded on YouTube by TheFloW:
The other, CVE-2017-18202, is based on the __oom_reap_task_mm in mm/oom_kill.c in the Linux kernel. Before version 4.14.4, it mishandles gather operations, which allows attackers to cause a DoS by TLB entry leak or use-after-free. It can also leverage a copy_to_user call within a certain time window, which is used to copy data from the kernel’s memory space to the memory space of a user-level process - meaning it can leak kernel data.
While I wanted to try the BleedingTooth exploit, the board wasn’t in a working condition, so I couldn’t test it.