After seeing the Car Hacking Village at BSides Leeds 2020, I was inspired to use the instrument cluster from a Peugeot 208 as the instrument cluster for Buggy Delight. This is mainly due to the fact that they’re commonly available and cheap – I picked mine up for free from work – but otherwise they’re available for around £30.
The instrument cluster itself is relatively easy to interface to – requiring the below four pins to talk to the cluster.
Once wired, the CAN bus communicates at 125kbps, sample point etc. did not seem to matter.
The CAN IDs for the instrument cluster are listed below. Further documentation on what each ID does is on my Github, but I’ll leave this as an exercise to the reader to figure out what each bit does.
|0x0B6||Speed & RPM gauges|
*Note – 0x0F6 seems to do something with the odometer, so be careful with this.
What bit in each byte CAN IDs becomes obvious, especially if you are watching the instrument cluster at the same time. I found it easier to use a utility like BUSMASTER or Kvaser’s CanKing to send bytes to the cluster. This allowed me to send bytes and observe the response on the cluster, rather than having to try beat a fuzzing script to make observations and notes.
The display will revert to a default “fault” state if nothing is sent on the CAN bus – this includes putting on the service light and MIL indicator. Sending a CAN data frame at least every 1.5-2 seconds seems to avoid this. It is important to note that most of the IDs only seem to respond with a DLC (Data Length Code) of 8, even if certain bytes do not seem to do anything.
My approach of fuzzing the IDs consisted of setting the DLC to 8, and trying every byte zeroed out first, then stepping through each byte trying 0xFF. I then bit shifting left by one bit each time, essentially generating the sequence of 1, 2, 4, 8, 16 etc. This soon lead to a pattern of discovery, in that most of the lights are controlled by single bits, which makes it incredibly easy to be able to control whichever indicator light you want.