The "Foculus Rift" part 3: Spoofing the EDID

The libOVR SDK recognizes if an Oculus Rift is attached to the PC by checking two particular things:

1. The USB tracker with the right VendorID, ProductID must be present (this has been solved in Part 2)
2. The Head Mounted Display (HMD) must be attached, which is nothing more than an ordinary monitor connected over HDMI. The HMD is identified by its so called Extended display identification data (EDID).

Note that the following writeup is specific to changing the EDID data on a RTD2660 based flat panel controller. It involves desoldering and reflashing the I2C chip holding its firmware. There are many things that can go wrong and it is very easy to end up with a bricked device -- so be sure to backup the data before you reflash the chip.

Alternatively, there is a simpler way to spoof the Oculus Rift EDID.
The trick is to directly solder a programmed I2C eeprom to the right pins of the HDMI connector. 
There is a beginner-friendly step-by-step guide by will1384:

• Changing the EDID data
• Hardwareof the spoofer
• Flashing the eeprom with PonyProg

Here is the hard way how to do it ...

The EDID is a 128 byte binary blob, which is transferred over an I2C bus to the PC.
This happens when the display is plugged in over a VGA, DVI or HDMI connection.
What is actually stored in this 128 bytes is nicely explained on Wikipedia.

To make the libOVR believe that the generic LCD panel from eBay is actually an Oculus Rift, 
several parameters in the EDID need to be changed.
In particular, the following bytes need to be set to the values read out from an original DK1:

• Manufacturer ID (byte 8-9)    "OVR"     [0x3E, 0xD2]
• Manufacturer Product Code (byte 10-11)  [0x01, 0x00]
• Serial number (byte 12-15)              [0x00, 0x00, 0x00, 0x00]
• Monitor serial number string            "Serial"  + 0x0A
• Monitor name string                     "Rift DK" + 0x0A

I didn't want to override the other parameters, as they contain important information about the supported resolutions and color modes of the monitor. However, later I found, that this eBay display controller seems to send incorrect EDID data over the HDMI connection -- which didn't allow me to use it at its native resolution. While I was rewriting the EDID data anyway, I have fixed that mistake.

The RTD2660 is a highly integrated chip, which does the format conversion from an VGA (analog) or HDMI (digital) input to a LVDS output. It also does gamma correction, displays the on-screen menu and many more things. To control all that, it contains a 8051 compatible microcontroller core. The slightly bizarre thing about it is, that the chip does not contain any flash memory for storing the program code. In fact, every instruction is fetched from the nearby W25X40 flash chip over a serial SPI connection on the fly and then executed. It was clear, that the EDID information must be stored in this flash memory.

The LCD flat panel controller board in its original state.

So the first step was to desolder the W25X40 chip and read out its data. Before soldering it back, I placed 300 Ohm SMD resistors between the CLK, MOSI and /CS pins. This allowed me to read and write the chip while it is "in circuit".

W25X40 Flash chip decoupled from the RTD2660 LCD panel controller by 300 Ohm resistors

This allows to read and write the Flash memory without the need for desoldering the chip

The STM32F3DISCOVERY board was used to read and write the flash memory

It turns out, there is over half a megabyte of binary data in there, which is quite a lot of program code for a small 8 bit microcontroller.

For reading (and writing) the chip, one possibility is Ponyprog and an easy to build parallel port interface. Another one is to use the Bus Pirate. I actually used the STM32F3 discovery board, with a custom firmware so it acts like a USB to SPI bridge. With some Python code, I could send commands to the chip and read out its data. If you're interested in the USB to SPI source code, let me know.

Having read out the binary data, I could search through it with a Hex editor. The EDID block always starts with these bytes: 

0x00 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0x00. 

So it is quite easy to identify. I found 9 of these blocks! Starting at the following addresses:

(1) 0x00C4F    EDID (128 bytes) sent over VGA

(2) 0x00CFF    EDID (128 bytes) not used. Almost identical to (1)

(3) 0x01E00    EDID + CEA-861 extension block (256 byte) sent over HDMI

(4) 0x10C4F    identical to (1)

(5) 0x10CFF    identical to (2)

(6) 0x20C4F    identical to (1)

(7) 0x20CFF    identical to (2)

(8) 0x30C4F    identical to (1)

(9) 0x30CFF    identical to (2)

I was able to figure out which one is which by comparing the data blocks from the firmware to the EDID data I was reading out in Linux with the get-edid tool. (1) and (2) seemed to contain correct information for the specific LCD panel, which I bought with the controller board -- but (3) was completely wrong and looked like default values which have never been customized.

I modified all of the above EDID blocks and wrote them back to the Flash chip. With this modification, all Oculus Rift compatible games successfully recognize the generic LCD panel as an HMD.

You can find the project files here:

Reprogrammed EDID

This includes the .py files with the commented original and modified EDID data. The binary files of the original and modified Flash image and two iPython notebooks which have been used for the binary manipulations and for flashing the image with the SMT32 board.