Monday, April 7, 2014

From Boot to Root, Reverse Engineering your Satellite TV Receiver

Hello guys,

Sorry for not posting anything the last couple of months, but usually, long time, means a fancy post.

Today, we are going to talk about something interesting/unusual, today's trip will be into hardware hacking.
We are going to talk about hacking a TV receiver, from watching your TV, to getting a shell inside.

Before starting, I must mention some names that helped me a lot in my journey toward getting my first hardware shell from within my tiny laptop:
- Ahmed Mamdouh Ahmed, A teacher assistant in computer and communication department, Alexandria University, Egypt.
- Ahmed Hamdy, A teacher assistant in computer and communication department, Alexandria University, Egypt.
- Google, DuckDuckgo, and the result pages inside.

Thanks for wasting time answering my boring questions, really.
Okay, so here starts our journey, have a seat, and a nice cup of coffee.

Important Notes:
- First, it's important to make sure that you have some electronics and serial communication basis, since this will be the base of all our work.
- We are going to use two basic tools in order to reverse engineer our RS-232 serial port:
Multimeter-USB to UART adapter.
- Personally, I'm going to work on a Linux machine (Arch 64-bit), and minicom serial communicator script (you are always free to get your favorite set of software tools, as long as they get the job done).
- I'm making sure to generalize the explanation as wide as possible, so that it can be applied on any kind of serial port attached with (almost) any piece of hardware.
- If you doubt making any (I really mean ANY) of this post steps, please do NOT continue following, since some of the steps can fry your hardware if you are not aware of, which is not the intended aim here.
- A brain is a big plus, so make sure you have/can use one.

Now we are ready to dig in, our target hardware is Prifix 9500 Digital Satellite TV Receiver, here is a photo of it before taking the cover apart:

After getting out the cover and the power circuit, we end up with the main board of the receiver, mine looks like this:

Pretty fancy, isn't it?

Now, from the photo above, we can notice some of the on-board chips:
-Right most chip: Hyundai HY57V28162XX DRAM family series, it's a synchronous CMOS Dynamic RAM, with a capacity of 4 blocks, each 2M, with 16-bit bandwidth.
-Middle big chip: Conexant CX24303 ARM CPU, a 32-bit RISC processing unit, also includes a tv tuner, MPEG decoder, and many other features.
-Left most chip: Spanion S29AL016D70TF, a 16-Megabit CMOS ROM for bootstrapping process, and firmware storage.

Also, we can notice some JTAG's, in the middle of the upper part of the photo (which of course we can make use of).

So far so good, we have now an overview of the chips, the board in general, what we need now is to find 4 pins, GND, Tx, Rx, and Vcc, in order to start our communication with Conexant CPU.

After some fuzzing, I've seen in the back of the board, 4 individual pins, I guess with more than 50% that this is the right serial header we are looking for, and the cause of giving it a probability of more than 50%, is that I've found only 2 4-pins headers, one was related to some capacitors in the circuit, and the other was connected to nothing.

Now, our next mission is divided into making sure that these 4-pins are the right serial header, and playing a bit with the pins in order to discover what each pin does.

In order to make sure that this is the right serial header, and as mentioned previously, it must have at least 4 pins: GND, Tx, Rx, Vcc.
Let's start with the simpler one, the ground pin, in order to know which of the 4 pins is the ground, open your multimeter on the continuity test, put one probe on the pin you are testing, and the other probe on any conducting metalic surface you have on the board, personally, I love the co-axial LNB female port, so I'll stick with it.
My multimeter buzzed at pin number 4, and this is the GND pin.
Now, let's move to the other simpler one, Vcc pin, Connect your board to the power board, switch it on, switch your multimeter, set it to Voltage reading, and put one probe on the GND pin (or of course a conducting metal in the board), and move the other probe on each of the remaining 3 (or more) pins, if your probe is on the Vcc pin, you should see some voltage on your multimeter LCD (most probably 3.3 ~ 5 volts).
Make sure to keep measuring the pin under test for a while (about 5 seconds), since that Transmitter pin gives some voltages too, for a very small amount of time, we are going to use this trick to identify Tx pin the next step.
My Vcc was at pin directly next to the ground pin.
Now we have two remaining pins, the Tx and Rx ones, it's nearly impossible to know which is the Rx one using your multimeter only, since that the Rx pin is only receiving data, so if you put your probes on, it won't give you any readings, but we can of course identify the Tx, after that, concluding that the last remaining one (of the 4 pins header) will be the Rx.
To measure Tx pin, keep your multimeter settings on voltage reading, and put your probe on one of the remaining pins, if it's the Tx, it will give you a non-stable signal, oscillating from zero to 3.3 (or 5), and here is the Tx pin.

Now, that we found our serial header, and identified each of the 4 pins, we are ready to connect our receiver to our computer via USB-Serial adapter.

So why we are using an adpater here?
Actually, Receiver serial header uses RS-232 protocol, which uses the standard of logical zero bit between +3 ~ +25 volts (+5 to +15 on load), and logical one bit between -3 ~ -25 volts (-5 to -15 on load), while our USB uses differential protocol type, and it uses 5V Vcc power, so we here need to make sure that RS-232 logical power level is decreased to the USB logical level, as well as reversing the bits (so that 0 becomes 1 and 1 becomes 0, because they are reversed in the RS-232 protocol as you noticed earlier).

Just before connecting our computer to the receiver, we have to identify the communication parameters of the RS-232 protocol.
Most devices use 8N1, and 9600/115200 baud rates for asynchronous serial communications, which means we are using 8-bit data, 1 stop bit, 1 start bit, and no parity bits, and the communication is set to the speed 9600 or 115200 symbols/seconds, but as long as we have time, we can for sure play with every parameter to make sure this is the right one.

After some trials (and a lot of errors), I identified that my communication runs on 8N1, and uses 115200 baud rate, so I connected my USB-Serial adapter, set minicom settings to open a listener on my /dev/ttyUSB0 port with the serial parameters mentioned before, turned on my receiver, and finally got some *readable* data on my minicom (yes readable, since that I was trying to get any useful data for 3 months of trial and errors, and always getting garbage on screen).

Also, make sure that you are connecting your Rx (second pin of the DB-9 port) of your USB-Serial adapter with Tx pin in your receiver, and Tx (third pin of the DB-9 port) with Rx pin in your receiver, since that RS-232 protocol is a half-duplex single ended protocol, so it can only connect 2 devices at maximum, and each device is either reading or writing data at a time.
Now, here is the output I got from my Prifix receiver when turned on, on my laptop:

As you can see here, all of these data are the bootloader's info of the receiver, trying to load the firmware in memory, and after some seconds, we are getting a shell from which we can execute some commands (stack and heap dump's, CPU status, upgrading firmware, etc...).

Voila, We started from knowing nothing about the device, until getting a code execution inside the Conexant ARM chip.
From here on, we can do any (even evil) thing with our friendly receiver, we can try reversing the firmware (or maybe dump it from the ROM), and play a bit with it in order to exploit some of its services, and maybe getting some more interesting stuff.
Finally, this was a walkthrough on a part of my journey with reverse engineering hardware, If you came across the same journey (or a similar hardware hack(s)), or if you do have any questions about this one, you can always reach me on: