inspecting c-sky elf application

Question

I am new to reverse engineering , but as I am home these days , I wanted to hack my sat receiver. The receiver is based on c-sky v1 architecture'

Searching forums, I managed to get the firmware decomposed ( app.squashfs , app_rootfs.jffs2 , loader.bin ,logo.cramfs , upgrade_rootfs.squashfs and zImage )

I then extracted a file called "dvbapp" from app.squashfs which I think is main app that does it all

It is an ELF file , but can not be detected by ghidra as it doesn't support c-sky , radare neither

My question is what can I do further? Can I even inspect the app ins and outs ( qemu maybe ? ) , or disassemble / decompile it ?

the c-sky has a big repository for its toolset ( here: https://github.com/c-sky ) , but I can't understand much about linux development

Answer 1

Yes, that is the main app, telnet into the stb via network, user root, no password. You will find the stb has that block mounted as /dvb/out.elf which is this file.

It's the main app, most command line utils are all in busybox, else a couple of scripts after OS boot and network or usb insertion.

Serial port (maybe not installed to back panel) is used for firmware loading, not tty.

2 versions I know of with C610 processor, GX6605s and GX6622 which have cat5 as well as wifi support, bigger flash and ram.

The tuner/demod, the panel, and the frame buffer dvb output are all loaded as kernel modules which the dvb app uses to control the IO.

Also, there is a working NFS client, the user is gx, the home dir is writable and stored to flash, also /home/gx has a working bin dir where you will find the mentioned scripts.

A lot of different makes sell the same OEM box, and factory tools allow defining your user themes, images and look on the same operating firmware.

I am looking at re-purposing these boxes as they are a cheap and complete sbc with 2 I2C and SPI for $20 in a box although not as powerful as other sbc choices.

The only way seems to be to use the buildroot and Qemu tools and setup with the same kernel etc as the box firmware. I am trying to use it to create binaries for the stb, and run them direct from your linux box over NFS. It will be a learning curve. Assuming dvb user is gx:

mkdir /home/gx/XXX

mount  -t nfs -o rw,tcp,nolock 192.168.XXX.XXX:/home/hca/ /home/gx/XXX/

umount -f -l /home/gx/XXX 

RE ELF, maybe start here. https://linux-audit.com/elf-binaries-on-linux-understanding-and-analysis/

binwalk and readelf are helpful.

Answer 2

Firstly I am using the GX6622 version right now. I have one GX6605s version which requires the usb wifi but not yet powered it up. Still finalising the track layout and pin out under the microscope. But my understanding is both chip versions with different brand names sold here in Indonesia both have telnet. I have seen a few variants of the board layout but all seem to have the same components.

The GX6622 version has 100+ pins, 1gb of external DDR, 8mb SPI flash, RS232, 2 USB and cat5 ethernet. The GX6605S version is 68 pins, 512mb internal, 4mb SPI flash and 2 USB. Uart 3v TTL TXD pin 26 RXD pin 27 to pads under the board if not on top.

There is another version GX????, I suspect latter cpu version which uses a 16mb SPI flash.

The size of your firmware image would confirm the GX chip you have. Because the flash is 8 pin SOIC SPI external it is possible to swap to a 16mbyte flash and mod the code to use it. Also as you can reflash the flash IC so you cant brick the box.

I am using putty by ip on port 23 as per defaults for telnet. Possibly your firmware is different? I cant find those ports you mention open here, only 23.

There is no ssh in the firmware here, I wonder what your open ports are for. The serial is at 115200, in my box it puts out about 10 characters and then seems to wait on something from the uploading program.

I have spend many weeks searching in Chinese and other languages for this project and have accumulated quite some info. The problem is while the Csky C610 processor is documented on github and their site is very active with support of newer Csky cpu's, there is no release of the rest of the Soc data which is produced by another company. Makes it hard without the IO datasheet. There is a helpful pinout Gx 6605s in the Csky dev board schematic on their Github. So reverse engineering the code to use the IO seems unavoidable. Fortunately the IO is separate in modules, not in the main app.

Some of the config and test tools I have found indicate the main app can work with large number of io devices, so expect the main dvb ap code to have may options of tuner and demod code within, somewhere there will be in the flash "data" block definitions of which one is used as they are configurable in the flash with config software tools.

Here is a list of the IO kernel modules I have you may already have found, and an what I think they do.

In /lib/modules/2.6.27.55 av.ko is video output

fe.ko is I2C for the front end, probably GX3211 demod in the Soc and a RDA5815M tuner chip under the shielding.

gpio.ko -still investigating connections.

panel.ko is I2C for a custom chip for which I have a datasheet, drives up to 4 led, 4 press button and the 7 seg displays.

rt5370sta.ko is the wifi.

So I have collected a lot of firmware tools, code and snippets for these chips also some datasheets of devices in the GX family. Shortly I will start uploading it and links to github as linux project, firstly I want to make one into a DVB-S2 weather satellite receiver but have no data on the GX3211 demod in the Soc as yet.

It seems the I2C and Spi Flash are used via standard linux methods like ioctl and mtb, flash tools etc.

As soon as I verify the pinout and schematic of the GX6605s board, I will sort out and start uploading all the info I cave collated and work I have done and as a RE project on my github. It will also take some time. https://github.com/vk-hca

BTW what kink of hack do you wish to implement on the STB?

Answer 3

Me? I'm hoping to be able to use the box to control the tuner, and do one of two things with it:

1. sample and pass the I/Q information to a network destination for demodulation.
2. sample and pass the I/Q data to an application in the box to demodulate and/or display spectrum. Demodulation might be simple FM, AM, 4FSK, or perhaps even wider bandwidth applications such that radio enthusiasts or radio amateurs might find useful or interesting. One application that comes to mind is using direct or powered frequency converter(LNBF) for microwave or satellite experimentation. Having a stable tuning and sampling/demodulation platform with a wide agile frequency input could enable some interesting options for such work.

Here, I have a GX6605 based satellite receiver "KOQIT V5H" , with QH64A 8MByte SPI flash,RDA5815M tuner, 27.0MHz crystal.

The tuner is outputting differential I and Q channel directly to the SOC(4 traces), and is controlled with I2C, and also an analog voltage used for gain control that comes from the SOC. LNBF voltage comes from a DC-DC converter controlled from the SOC, and is bypassed around the tuner chip straight to the coax port.

On my device, the only network connections are through USB dongles for Lan or wifi, but only certain dongles are supported. I have one very old ethernet 10mbps dongle which partially works, but it's unstable. My device also has an "RS-232" port which uses a "headphone" 3-conductor jack to load firmware, using +/- 12V signaling. So far I have tried to get a shell from this exposed serial port but I think it's already established that this port is only for update via application. The bootup process can be observed through this port, I probably saved a log of that output somewhere-it's been a while, but I put the receiver back into service as a feed hunter on my Ku dish for now.

Unfortunately, I'm not a Linux software engineer, so the inner-workings of anything beyond bootloaders, usually requires copy-pasting commands.

I did, however, obtain a clean pull of the ROM chip by se-soldering the chip, reading it with a SPI reader, and verifying it. It survived the process and still works after re-installation on the device. Using binwalk with recursive extraction, I ended up with a folder of 284MB of data with tons of files and subfolders.

This is as far as I was able to get with it. I hadn't thought of looking for another terminal interface on the board, but I think I would have noticed one by now as I went through all of the other components of the board, and left with a basically total understanding of the devices and traces found there. Unless there's some sort of mode that can be triggered to enable access via the exposed serial port, then all else must be done through a network interface.

Is there any possibility that networking via the HDMI port can be utilized? That's probably a fantasy side-project, but cute nonetheless.

I'd be thrilled if even the smallest bandwidth from the tuner(4MHz according to the HW documentation) could be digitized and exfiltrated! It would be ideal if any popular SDR apps could be loaded and run on board, and either displayed on screen, or remotely controlled and output.