Airplay mirroring with HDMI dongles

I was interested in how Apple AirPlay screen mirroring is implemented in this super cheap Chinese HDMI dongles. Apple’s protocol is closed source and was reverse engineered back in in 2004. I couldn’t find an up to date open source project which implements a AirPlay server supporting screen mirroring. So lets see what this HDMI dongles have under the hood.

I purchased a device from ELEGIANT. I think there are also devices, sold under a different brand which are based on the same hardware.

Hardware

Just a quick summery of the found hardware components.

CPU

Rockchip RK3036G
ARM Cortex A7 dual core

RAM

128MB DDR3 SPI
Winbond W691GG6KB

Flash

16MB SPI
Winbond W25Q128BVIG
ID: 0x00ef4018

WiFi

Realtek RTL8188ETV
Connected via USB interface

Serial Console

Fortunately the CPU’s UART is accessible via pads. Couldn’t be easier! I only connected a regular USB-TTL adapter (115200 baud) to the RX/TX pads and powered the system.

Bootlog

The following shows the bootlog of the system. A lot of interesting information can be extracted from this information. You can also find a Gist of the bootlog here.

Now we can confirm that the flash chip is a w25q128.

And know the exact flash layout.

Get an image of the processes, running on the system.

And a quick overview of the root filesystem.

Firmware

In the next step we will try to dump the firmware by reading the flash chip. Unfortunately there are no ways to read the mtd partitions from the running system, due to the fact that no required binaries like dd are available.

Dumping the Firmware

First we need to get physically exclusive access to the flash chip, to dump the contained firmware. To get the pin configuration of the flash chip, I took a look at the Winbond w25q128 datasheet.

I probed all exposed pads, available on the pcb to support different chip footprints, and soldered wires to VCC, GND, DO, DI, CLK, CS, WP and HOLD.

To get exclusive access to the SPI interface, we have to ensure that the main processor doesn’t access the SPI interface. This is often quite complicated, since we have to keep the system offline while the chip needs to be powered.
One solution is to find the cpu’s reset pin and pull it down to keep it in the reset state while the system is powered. For me this didn’t worked, so I finally ended in desoldering the complete flash chip.

To get this done, you will definitely need a hot air rework station. Afterwards I soldered copper wires to the chip and connected it to a Raspberry Pi, acting as SPI master in this setup.

On the Raspberry Pi the pins 17,19,21,23,24 and 25 are used.

Wiring between Raspberry Pi and w25q128.

To read the content of the chip, a program called flashrom was used. It’s acting as SPI master, supports the most common flash chips and runs unter Linux.

To use the SPI interface on the Raspberry Pi, we have to enable it first.

Install the required packages, needed by flashrom.

Clone the lates available flashrom sources and build it.

And finally dump the content of the flash.

I repeated this step multiple times and compared the hash of the dumped file to ensure the reading was consistent.

The extracted firmware dump is available here.

Analyzing the Firmware

Let’s do a binary analysis of the extracted firmware. Binwalk is the perfect tool for this job.

The results of binwalk perfectly matches the already known flash layout, we know from the bootlog. The data partition has a JFFS2 filesystem and the system partition is a xz compressed Squashfs filesystem.

It’s easy to split the firmware dump in it’s mtd partitions.

Now let’s mount the filesystem of the extracted data and system partition.

At this point we have access to the firmware filesystem. I will stop my investigations here. Feel free to dig further in the firmware. Feedback is always welcome.