Reverse Engineering a DTV Converter

I have an old DTV converter sitting around gathering dust, so I thought it would be interesting to take a look inside:

Inside the DTV Converter

As you can see, there’s not much there: a Thomson TV tuner, an IR receiver, 32MB of RAM and a 2MB flash chip (on the underside of the board). What really makes this interesting though is the LGDT1111 SoC; this is a DTV chip manufactured by LG, so it’s a little different than the Broadcom/Atheros/Ralink/etc SoCs found in a lot of other consumer devices. It is very popular with many DTV converters though, so determining its CPU architecture and reversing the underlying firmware could be interesting.

Digging around on the Internet turned up a nice block diagram of the LGDT1111 (courtesy of MVPtek):

LGDT1111 Block Diagram

The MVPtek web site states that the SoC uses an “AMR926EJ-STM” controller…could they mean an ARM926EJ-STM? Hmmm…

According to the block diagram the LGDT1111 does have a UART connection, and indeed there is a four pin connector on the board above the SoC with the pins nicely labeled:

DTV Serial Port

The serial port settings are 115200 baud, 8 bits, no stop bits, 1 parity bit. Here’s the boot messages that are dumped over the serial connection:

There are some other interesting commands sprinkled in there, such as the video_freeze command that allows you to freeze the on screen video without interrupting the audio (an option I couldn’t find anywhere in the menu-driven user interface), or the rating_enable command which allows you to enable/disable the parental content filters without a password (bye-bye V-chip!).

This is all interesting, but if we really want to get down and dirty with this thing we’re going to need some firmware. There are of course no firmware updates for these converter boxes, so instead we’ll remove the flash chip and dump its contents using flashbin and a Gumbi board (raw flash image can be downloaded here):

Based on this and a quick look at the strings, this is definitely looking like the OS code, so let’s get it loaded into IDA. Based on the boot messages obtained from the serial port, the gzipped data we found at offset 0x20800 gets loaded into memory at 0x10000, which is where execution starts (also note the pSymTab address…this will be useful later!):

Loading the extracted code into IDA at the offset 0x10000 results in a decent initial analysis:

IDA initial code analysis

String references also check out, and we have several promising candidates for common library functions, such as snprintf:

Proper string references

sub_3EA1C is probably snprintf

This is encouraging, but with almost 4,000 functions, manually identifying them will take too long. Looking at the strings in IDA, there appears to be a list of strings that correspond to function and symbol names, starting at address 0x222ADF:

Symbol strings

Now we need to find out how to correlate these strings to their appropriate functions. The boot messages mentioned a symbol table at 0x1DFA8C, so we’ll start looking there. At address 0x1DFAAC, we find what appears to be a list of symbol structures:

Applying this structure to the first entry in the above IDA screenshot, the func_address is 0x10000 which is the entry point for our code. Adding its symbol_name_offset value (0x1BAB2) to the address where we found all the symbol strings (0x222ADF), we get: 0x222ADF + 0x1BAB2 = 0x23E591. Here we find the string “start_code”:

Symbol name for the entry point

This looks good! A quick IDAPython script takes care of renaming all of the functions to their appropriate symbol names:

After running this script, 96% of our functions have been named, including the function we previously identified as snprintf:

Named functions

snprintf properly identified and named

Coupling this with the available source code for the uC/OS-II RTOS, we could really go to town on figuring out how exactly this thing works if we were so inclined. But scrolling through the list of functions, one of the function names caught my attention:

Now that’s an interesting function name…

App_CheckRemoteBackdoorKey? 🙂

It turns out that this function is called by the MainRemoteKeyTask function, which passes App_CheckRemoteBackdoorKey the infrared key code received from the IR remote control. If one of several special IR codes is detected by App_CheckRemoteBackdoorKey, MainRemoteKeyTask will preform several actions such as providing a service menu, running a factory test, and even performing and over the air firmware upgrade:

MainRemoteKeyTask

These are actually pretty neat little boxes, and there is a surprising amount of potential for customization and modification. I can envision a wireless microcontroller that provides an enhanced user interface via the serial port and can automate commands, such as switching the channel when your favorite show comes on. Unfortunately, DTV reception is terrible here which really takes all the fun out of any cool mods like this. Oh well, I’m off to watch some Netflix.

It wasn’t really high on my (exceedingly long) todo list, so I worked on it on and off. Probably a total of 6 hours or so, most of which was spent playing around on the serial port – there are a lot of commands in there that aren’t very well documented. IDA plus the boot info from the serial port made short work of the disassembly.

Also you’ll note that there a JTAG port listed; if this is brought out to the board that’s another port of attack. The ARM9 (and possibly others) have a custom scan chain, into which you can push processor instructions.

This was used in the ‘jtag-arm9’ project (no longer maintained) to write small programs into the internal cache space of a ARM940 board I had…. and could have saved you the need to de-solder the flash to dump it.

Yes, I didn’t see any JTAG ports on the board either. They’re probably broken out on some test points or something though.

To be honest, with a cheap hot air gun I’ve found it’s usually faster and easier to just desolder the flash chip and dump it than go through JTAG anyway. Re-soldering is harder, but I do a fair bit of soldering so it’s not that bad. Of course, if I had “proper” JTAG tools like a BDI3000 that may not be the case. 🙂

Very nice work on disassembling and putting together such detailed documentation.

One thing though, µC/OS-II isn’t open source. It is a commercial package with a trial version that comes with source so you can evaluate it. You need to fork out $$$ for a license if you actually want to use it.

8 bits, no stop bits and 1 parity bit (aka, 8N1) are pretty much the de-facto standard – I’ve never seen a serial port on an embedded device that used anything different (though I’m sure there are some out there that like to be different…).

So the only thing left to identify was the baud rate, and for that I used the baudrate utility which technically is just trial and error, but it makes trial and error a lot easier than doing it in minicom/hyperterminal/etc.

The hardware used was a Gumbi board, and the software was the flashdump utility that comes with the Gumbi board.

I didn’t bother re-soldering the chip in this case since I didn’t really need the DTV converter anymore. I’ve done this to other devices before though, and found drag soldering to be a great technique for soldering surface mount IC’s.

Yes, there are various commercial products out there, some more expensive than others. Look for ‘usb flash programmer’ or something similar on ebay; just make sure the programmer supports your traget flash chip(s) (the 29XXXXX series are common parallel NOR flash chips).

I haven’t used them myself, but the Willem programmers are probably the most popular. They usually operate over the parallel port (which is fine as long as you have a parallel port), but there are some USB versions too for a bit more $$.

And yes, usually you can dump the firmware via JTAG or the serial port without desoldering the flash chip. This assumes of course that you can identify the JTAG/serial ports, that JTAG fuses haven’t been blown, that the serial port command line interface allows you to read arbitrary data from memory, etc.

I think this was COOL! I have one of these, a Magnavox DTV TB110MW9 that I wanted to mod, or see if I could install different or newer firmware on. You know, to like improve the UI, and things like that…if someone would be willing to walk me through this, please email me or reply to this comment. Thanks! Again, Cool tutorial/breakdown! 🙂