Reverse-Engineering the Peugeot 207’s CAN bus

Here’s a classic “one thing led to another” car hack. [Alexandre Blin] wanted a reversing camera for his old Peugeot 207 and went down a rabbit hole which led him to do some extreme CAN bus reverse-engineering with Arduino and iOS. Buying an expensive bezel, a cheap HDMI display, an Arduino, a CAN bus shield, an iPod touch with a ghetto serial interface cable that didn’t work out, a HM-10 BLE module, an iPad 4S, the camera itself, and about a year and a half of working on it intermittently, he finally emerged poorer by about 275€, but victorious in a job well done. A company retrofit would not only have cost him a lot more, but would have deprived him of everything that he learned along the way.

Adding the camera was the easiest part of the exercise when he found an after-market version specifically meant for his 207 model. The original non-graphical display had to make room for a new HDMI display and a fresh bezel, which cost him much more than the display. Besides displaying the camera image when reversing, the new display also needed to show all of the other entertainment system information. This couldn’t be obtained from the OBD-II port but the CAN bus looked promising, although he couldn’t find any details for his model initially. But with over 2.5 million of the 207’s on the road, it wasn’t long before [Alexandre] hit jackpot in a French University student project who used a 207 to study the CAN bus. The 207’s CAN bus system was sub-divided in to three separate buses and the “comfort” bus provided all the data he needed. To decode the CAN frames, he used an Arduino, a CAN bus shield and a python script to visualize the data, checking to see which frames changed when he performed certain functions — such as changing volume or putting the gear in reverse, for example.

The Arduino could not drive the HDMI display directly, so he needed additional hardware to complete his hack. While a Raspberry Pi would have been ideal, [Alexandre] is an iOS developer so he naturally gravitated towards the Apple ecosystem. He connected an old iPod to the Arduino via a serial connection from the Dock port on the iPod. But using the Apple HDMI adapter to connect to the display broke the serial connection, so he had to put his thinking cap back on. This time, he used a HM-10 BLE module connected to the Arduino, and replaced the older iPod Touch (which didn’t support BLE) with a more modern iPhone 4S. Once he had all the bits and pieces working, it wasn’t too long before he could wrap up this long drawn upgrade, but the final result looks as good as a factory original. Check out the video after the break.

It’s great to read about these kinds of hacks where the hacker digs in his feet and doesn’t give up until it’s done and dusted. And thanks to his detailed post, and all the code shared on his GitHub repository, it should be easy to replicate this the second time around, for those looking to upgrade their old 207. And if you’re looking for inspiration, check out this great Homemade Subaru Head Unit Upgrade.

Post navigation

52 thoughts on “Reverse-Engineering the Peugeot 207’s CAN bus”

reminds me of poking around in memory of video games 10+ years ago. Snapshot memory, get more in-game money, diff against current memory, get more money, diff again, keep going until you’re pretty sure that you’ve isolated what memory location the money’s at, change it and see.

I did something similar in the 90s on my cable system. I reverse engineered the in-band addressing protocol for the cable boxes enough to change the address of my box to one which was being told it could get all channels.

Yes, it worked. No, I didn’t get caught. And no, there was nothing worth watching on the “premium” channels, either. But it was fun as heck to figure out the protocol and demonstrate that I had done it correctly by picking an address off the data stream, setting it into my box and seeing all the channels.

Peugeot have made some absolutely awesome cars which I suspect never made it to the US – the 205GTi was one of the best hot hatches ever. In recent years (2000’s) they have turned out dreary crap but in the 80’s and early 90’s they did some brilliant work.

Check out some of their rally/dakar cars from the era, look up “Climb Dance” on youtube and sit back.

Similar to Citroen TBH, they also lost their way a bit but at least Citroen are now back to being a bit nuts in a stylish and Gallic sort of way.

Why does using a cheap computing platform which supports a development environment with which he was already familiar ruin it for you? I admit it’s not the way I’d have gone with this project, but I’ve not played with iOS for a few years, and as he mentioned in the write-up he gets all the benefits of having a phone in the car.

Where do you see a cheap computing platform? He used APPLE stuff. Apple is the opposite of “cheap”, for me Apple is synonymous to ridiculously overpriced gear for “religious believers” which need to sacrifice their money to their gods to achieve their epiphany.
But of course, using a platform you know already, even an expensive one, can be well worth it, when you save some time.

Considering that my wife is on her 3rd iPad (her first one didn’t have the built in phone, the second has a cracked screen and she didn’t want to put $180 into repairing one that was already several years old…

I agree it’s not ideal for every project. But I bought the iPhone from a friend for ~80€. It has WiFi/Bluetooth/GPS built-in, and a battery. It was not THAT much more expensive than a Pi with the appropriate dongles (when I started the Pi 3 wasn’t released yet). Considering I already knew the platform really well, it was an obvious choice for me.

Great project!
I’ve noticed on some articles, that reading the comments ends up being as interesting as reading the article.

I’m still trying to reverse engineer the I2C bus (yes, it’s really an I2C bus running over one or two meters of wires) that connects the radio to its head unit and the dashboard. Not being able to operate a scope inside the car does not helps.
Once this works, I’m thinking about putting a display (I was considering e-ink displays) and probably end up reverse engineering the KWP bus (the car is not that new).

I’ve noticed that most “back-lit” e-ink readers use edge LEDs, so I can either get a complete tablet or copy their design, as shown on this page: http://e-ink-reader.ru/e-ink_backlight_en.php
I’ve seen a couple of paragliding, and boat navigation devices based on e-ink tablets, and it’s so much better than any LCD or OLED display in a sunny environment.

You mean like how you can’t see regular car gauges at night? OH WAIT YES YOU CAN because of lighting!

I actually reckon e-ink is an excellent idea for a dashboard / gauge as it’s not flickery/bright and can be lit with ambient light. I dislike LCD’s / TFT’s / OLED’s in cars, and dimmable dash lighting is a much overlooked feature.

What’s the problem with operating a scope inside the car? There are voltage converters which make mains voltage from 12V. There are battery operated scopes like the QDSO and extension cords.
For your task I would recommend one of this tiny 24MHz 8bit logic analyzers conencted to the USB port (SALEA clone), you can use this on your notebook computer (if you have one or are able to borrow it for this tests.)
E-Ink is very slow and only some types are front-lit (like in the Amazon Paperwhite). Do you really need/want this for the radio?

I got used to take things apart and debug them using the company’s scope (which is quite comfortable with bus decoders, word triggers and lots of samples memory), but obviously, I can’t take apart all the front of the car while parked in the street nor take the scope out of the company building.
For most things, I’ve been using a random logic analyzer with a Cypress chip (probably also a SALEA clone). It’s able to read the bus, but I can’t see any analog issue (either slow edges, weak pullups or noise pickup). But it’s already a good start.
Actually, I was only starting to think about putting a display, but I first need the I2C bus reverse engineered before going any further. Anyways I still consider your observations about e-ink being slow and not that readable in the dark.

When you’re doing the initial data collection and processing, don’t go with Arduino + Bluetooth to a mobile OS (iOS or Android)

You’ll be spending large amounts of time just getting code working vs. collecting and analyzing piles of data – for the initial sniffing and analysis, a laptop with Wireshark, Linux, and a Canable (canable.io) or similar cheap USB-to-CAN adapter is much easier.

Note that if you prototype with a laptop and Canable, migrating to a Pi 3 + PiCAN2 is not difficult since the software interfaces are identical. However, the PiCAN2 with built-in regulator can barely keep a Pi3 running, and definitely can’t keep a Pi3 with a monitor running.

I would like to run a digital dash in my truck, and was thinking of using a Raspberry Pi to drive the display.

The digital dash would be HTML5 and Java Script based, running in a Chrome browser.
And all the displayed data would be from CAN packets.

I would assume that a Raspberry Pi 3 would have enough processing power to draw the gauges and the the such. But I am not sure how I would get the CAN packet data into the browser to decode them with Java Script…

It all began when someone decided to call it “Google Chrombie™ and Fitch”. Then it gained more popularity than M$ Internet Exploder, became an operating system for *low-end* ARM laptops, and started including Google spyware and supporting crappy DRM’ed stuff (I’m looking at you Netflix).

> But I am not sure how I would get the CAN packet data into the browser to decode them with Java Script…
It’s not Javascript (especially not “Java Script”), it’s called ECMAScript. And does this guy know what’s AJAX?

In your situation, I’d use python-can to create a basic system to forward the data over websockets to the browser. Rather than just the Chrome browser though, your best off putting it into Electron instead, not a lot of extra effort but it will act more like software instead.

All I want to do is have a CD changer emulator for a 1997 Ford Taurus that plays MP3 files from six folders on an SD card, with up to 99 files per folder. Needs to have a stereo analog output, pretend to be a CD changer, and accept disc and track change commands from the head unit.

Such a thing would work in millions of circa 1995 to early 2000’s American Ford, Mercury and Lincoln vehicles.