Network protocol description

Protocol Description

To get a better understanding of the network protocol for the controller, it's neccessary to learn some basics about the hardware used.

Techniques

The whole development is powered by network-level sniffing and standard forensic techniques.

The equipment used for recording the network stream is as follows:

• T100k Controller
• HP1810-24G Switch with port mirroring
• A notebook with wireshark to record the network stream
• A notebook with LEDedit to generate valid control signals.

The first step was to just record some data and try to replay the stream which was immediately successful and yielded correct results. The success of the replay attack indicates that there is no access control or encryption when communicating with the controller.

The next step was to generate specific LED pixels (such as all LEDs "red" etc.) that yield specific patterns in the bitstream and search for this bitstream in the packet capture. While this took longer than expected, it eventually lead to the understanding of the protocol.

LED Control

The controllers use a chain of LPD6803 LED drivers, which are controlled using a spi-like bus system. The bus consists of a data signal and a clock signal and the drivers are chained.

The typical application circuit is described in the Datasheet

The protocol used in this bus is fairly simple:

• First shift in 32 zeroes which are used as start of frame signal.
• Then shift in 16-bit of data per controller attached, using a one-bit as start of pixel followed by a 5-bit greyscale value for each channel.
• Shifting is done every rising edge of the clock line.

The controller used for this project is the T100k, having 8 outputs for this bus, each port can drive up to 1024 controllers of this type.

Network

Terms

• Frame - a set of RGB values for the LEDs (all LEDs contained)
• Packet - a network (UDP) packet
• Continuation packet - a packet with 5 byte length to signal the controller that a new frame will be sent.
  • Content: AA 00 66 00 00 (hexadecimal)
• Start packet - a packet with 5 byte length
  • Content: C5 77 88 00 00 (hexadecimal)

The communication runs on Port 5000 using UDP protcol and no encryption or signature. Each frame consists of 16 single packets at 1040 bytes length each having 1024bytes of color data, 12 byte prefix and 4 byte postfix. The packet structure is as follows:

88 id EA 33 F1 88 00 E0 32 22 14 7F // prefix
1kbyte of color data
00 00 00 00 // postfix

where id is replaced by the packet index 0 to 15. The values for prefix and postfix are taken from the original LEDedit software. My educated guess is that the original software configures the controller type and the chain length.

Now the color data need some more explanations:

The controllers take 16 bit per node, and in the data sent over UDP we can see a 16 byte long structure resulting in sending one bit of payload per byte. While this seems inefficient at first, the protocol is built to receive data for all output ports in parallel. So sending the first byte corresponds to the first data bit of not only the first but all output ports. The mapping from packet bytes to output data can be found detailed in the following table:

RGB byte	Bit 0	Bit 1	Bit 2	Bit 3	Bit 4	Bit 5	Bit 6	Bit 7	Value (hex)
Port	Port 0	Port 1	Port 2	Port 3	Port 4	Port 5	Port 6	Port 7
0	startbit (1)	startbit (1)	startbit(1)	startbit(1)	startbit(1)	startbit(1)	startbit(1)	startbit(1)	FF
1	R0	R0	R0	R0	R0	R0	R0	R0
2	R1	...	R1	R1	R1	R1	R1	R1
3	R2		...	R2	R2	R2	R2	R2
4	R3			...	R3	R3	R3	R3
5	R4				...	R4	R4	R4
6	G0					...	G0	G0
7	G1						...	G1
8	G2							...
9	G3	...
10	G4	G4	...
11	B0	B0	B0	...
12	B1	B1	B1	B1	...
13	B2	B2	B2	B2	B2	...
14	B3	B3	B3	B3	B3	B3	...
15	B4	B4	B4	B4	B4	B4	B4	...
where R0 is the least significant bit and R4 the most significant bit of the 'red' channel.

Each packet maps directly to 64 LEDs in the chain, so 16 packets are exactly the 1024 LEDs mentioned in the datasheet of the controllers. After those 16 packets are sent to the controller, the software needs to send a continuation packet, which is answered by the controller if the previously sent packages were understood correctly. If this packet isn't received it means either the controller is offline or not responding (i.e. the firmware hangs) or the controller couldn't understand the packets sent by the user. After receiving the response the software needs to send a start packet to tell the controller that the received data should be written to the output ports.

For additional information/data there is packet capture included in the main repository.