Can Bus reverse engineering tools

It really has been a while since my last post. Life takes so much time that we found it difficult to continue in our adventure and I am sorry for all the emails that we received and we weren't able to answer.

Recently I have been able to dedicate some time again to this project.
I decided to look for reverse engineering tools that could allow us to listen to the packet received from the Canbus and store and show them.
This is the first step for reverse engineering the messages from the car. We need to associate each message to each actions performed on the car and possibly recognize other useful information passing on the Can Bus.

I had a second look at the tools I talked about in a previous post. I downloaded the socketcan project files again and noticed that it had a lot of changes. Apparently they have been quite active. I set the test can bus up again a began some tests. Cansend and Candump programs are still working and everything seems like before.

I then went on with my search for tools to sniff the bus and reverse engineer the information. I looked at Wireshark tool (formerly known as Ethereal) and I tried it on the local test canbus but it gave me an error. I searched around and found some patches for libpcap (that is used by wireshark to sniff packets) that enabled it to sniff CAN packets.

I downloaded the latest libpcap and tried to apply the patch only to discover that it has already been applied. So if libpcap is CAN ready, why wireshark can't sniff CAN packets?
I went to the wireshark website and discovered a much newer version and decided to try it.
As I am a Debian GNU/Linux user, my first place to look has been the debian repository. Luckily, debian 6 (squeeze) has just been released, and this allowed the newest packages to enter the new debian testing, which is the one I'm using.

So I did apt-get install -t testing wireshark to get it updated to version 1.4.3 and tried again with the can bus. Luckily I did not get the error this time and immediately tried with some packets from cansend. It worked like a charm as you can see in this picture:

Nice and very readable. With a tool as handy and mature as wireshark, reverse engineering will be much easier. Next thing we will have to do is figure a way to collect can packets from our PICs connected to the serial port to the can bus. Stay tuned!

Good news

The chip is here! The brand new scanner has been assembled, and seems to work in our test-can-network. It is able to detect the communications between the other two chips in "listen only" mode, that is snooping the network without interfering in any way. So we can start developing the find-the-right-speed algorithm in a deterministic way.

Soon we will post photos and the first results.

See ya soon!

Time goes by... fast

It's been about a year since we last updated this blog. It's incredible how much time we need to do things, and how it's difficult to get some. Or maybe it's me aging.
Anyway. After building the "demo" can bus, we were hoping that the process of validation of our scanner should be easier. We were wrong. Not only the scanner doesn't work yet, but we faced some unexpected problems that "the pure theory" has not foreseen. The theory says "if you get a packet, you have found the right speed". Yes... but we get many packets at many different speeds, overflows, wrong packets, bursts incompatible with speed settings.... AAAARGH!!!!
We gave up for some time, but now it's revenge time.
The third PIC (PIC18F4685) is coming, and this will let us have a working bus that we know, with known speed and known packets, and we will build a CANscanner that we can test and tune on it.

The battle has begun!

Playing a bit with SocketCan and its utilities

This time I had a better look at the SocketCan utilities that I mentioned in a previous post. As I have already told, you can get and install them with these commands:

svn checkout http://svn.berlios.de/svnroot/repos/socketcan/trunk canbus
cd canbus/can-utils/
make
make install

And you will end up with lots of new programs under /usr/local/bin:

asc2log canbusload candump cangen
canlogserver canplayer cansend cansniffer
isotpdump isotprecv isotpsend isotpsniffer
isotptun log2long slcand slcanpty vcan

To see how canbus works, I tried to setup a virtual can bus with these commands:

modprobe vcan can-raw
ip link add dev vcan-test type vcan
ifconfig vcan-test up

These basically creates a canbus named vcan-test and set the interface up.
Then I opened two terminals and ran the command candump on one terminal and the command cansend on the other terminal. These are the outputs:

# cansend vcan-test 5A1#11.2233.44556677.88
# cansend vcan-test 5A1#11.2233.44556677
# cansend vcan-test 1F334455#1122334455667788

# candump vcan-test
vcan-test 5A1 [8] 11 22 33 44 55 66 77 88
vcan-test 5A1 [7] 11 22 33 44 55 66 77
vcan-test 1F334455 [8] 11 22 33 44 55 66 77 88

That are the message id and the data. The number between the brackets is the data length and the last case is with an extended id.

This could also be the text format used by the slcan driver to communicate via serial port.

I have tried to use slcanpty to attach the vcan-test interface to a pseudo terminal but without success so far. I will have to try again soon as it could be the way to gather the data on the Linux machine without writing an additional custom layer.

Two interesting CANBUS projects and some links

This CANalyser tool is pretty similar to what we want to do at the moment and is built with very similar chips. The project seems a bit outdated but the information is still very useful.
The tool is composed by a PIC microcontroller PIC18F458, and a MCP2551 CAN transceiver. The main features are listen to the CAN bus in active or passive mode and forward data to the serial port to the PC and send data to the CANBUS. This is exactly what we need now.
Digging further in the web pages I discover that they have built a real-time kernel to run their software on the PIC. There is a company behind this (Pragmatec) but they have released the sources under a GPL license. The website of the os is at PICOS18
There is a new version of the pages here but the page about the CANalyser tool is the same.

Another very similar tool is CAN2PIC. This one uses PIC18F248 and MCP2551 CAN.
You can find there all the schematics of the circuit used and also all the software! So this page should provide all we need to get started and running very fast!

There are some other interesting links I found tonight:

• GNUPIC: a small directory site with information on PIC programming with GNU/Linux
• Another very good CANBUS learning page at CERN (yes they used it in LHC)
• PICMICRO WebRing: A collection of websites about the Microchip PIC microcontroller and related projects

Canbus programming under linux: SocketCAN

Well the good news is that someone already did the hard part for us!
The Linux kernel includes since several versions the support to the can protocol and provides what seems to be a very easy interface to it. It's called SocketCAN and it is modeled after the standard unix socket API.
The project page is at BerliOS and hosts the kernel patches (not needed anymore as it is included in mainstream) and some user space tools that I just downloaded and installed without a glitch. You can get them by accessing the project subversion repository with this command: svn checkout http://svn.berlios.de/svnroot/repos/socketcan/trunk canbus

More info on what is and how to use SocketCan can be found in the linux kernel documentation directory (available on the web here)

As for the device drivers, SocketCAN supports a few drivers alreay, two of which are particularly interesting: vcan and slcan. Vcan is a virtual CAN interface driver and is there for testing when there is no hardware available. This will be probably the first to try once I realize how the user space utilities work. The slcan driver is "For a bunch of CAN adaptors that are attached via a serial line ASCII protocol (for serial / USB adaptors)" and should match exactly what we are trying to do. I just wonder what is the data format the slcan drivers expects to receive from the serial port. I have only found a strange document here so far but the semantic is not clear to me and I will have to investigate this further.

Can Bus specifications

The official (I think) CANBUS specification can be found at CIA, that stands for Can In Automation. There are both base and extended protocol. They seems to be very clear and intuitive and I think they will be very helpful as soon as we start coding some CAN sniffer or similar. I have to start thinking about how big the sniffed data will be and where to store that so that we can study it easily. Maybe the only choice for this is a database (for which I guess mysql would do pretty well).
We'll see soon. Coding time is approaching!

Great Can Bus hacked page on a Saab

I have found this really interesting page here. It is from a guy who reverse engineered the instrument bus on a Saab. This bus is called I-bus and is based on CAN bus. He gives a lot of information on how he did it, starting from locating the connector, attaching to the bus and interfacing with the PC, along with the tools he used.
It is very similar to what we would like to do and thus we can get lots of advices from it. There are important differences though. He bought ready-to-use CANBUS connectors while we are trying to do it by ourselves. Well actually he says that he tried to do it himself but could not make it work so he switched to commercial products, but he does not give much information on how he tried and what did not work.
The other big difference is that as he is using commercial products, he also has access to programs on Windows platform that can decode bus messages and help during reverse engineering. We won't have these programs because of our do-it-yourself choice and also because we plan to use Linux to get access to the bus by using a serial interface. This is clearly much harder to do but I hope it is not so hard that we will eventually be forced to switch to commercial products.
We will also have to develop our own programs on the Linux platform, but this should not be a big problem. We have to look around for already existing projects to see if we can reuse some code.

This page also gives us a real example of what the message on CANBUS looks like and how they are used by the car. He also explains how the information is spread on multiple messages as for the case of the radio display. Definitely an helpful page!

About CAN BUS

Here I have found a good introduction to the CAN bus.
It is a link level protocol, similar to ethernet, with CDMA (Collision Detect, Multiple Access) policy.
Every CAN bus peripheral can receive and send data on the same bus and has the capabilities to recognize where someone else is using the bus at the same time. A priority mechanism ensures that in this case only one transmission is completed.
Unlike ethernet, this protocol is content oriented, that means the each message does not have destination and source fields, but just an identifier that specifies the meaning of the data associated to the message. The meaning of the identifier is not specified in this standard as it is choosen by higher level applications.

Each message consists of an identifier, some flags and crc and the payload.
The identifier is 11bit wide in CAN bus version 2.0A and 29bits wide in version 2.0B

There are four different message types:

• Data frame: a frame containing node data for transmission
• Remote frame: a frame requesting the transmission of a specific identifier
• Error frame: a frame transmitted by any node detecting an error
• Overload frame: a frame to inject a delay between data and/or remote frames

The arbitration on the bus is based on the identifier. As the bus is AND wired, each time two components send a signal on the bus, the result on the bus is the logical AND between the two signals. This means that when collision happen, only one of the identifiers of the messages gets trasmitted to the bus (the one with most zeros); the transmitter can simultaneously read what is on the bus and if the identifier coincides they proceed to transmit the complete message.

This info on Wikipedia will probably be very useful to get data structures written in C or any other language I might choose for this adventure.

Getting the tools: part 1

After some time spent to think of what tools we need in this adventure, now the heart of the project has arrived:

This beauty is a PIC 18F4682 from Microchip. Among many other features, it spots:

• Enhanced CAN controller on board ( CAN version 2.0B up to 1Mbps)
• 1 EUSART ( for RS232 )
• 10 MIPS @ 40Mhz

This is another voyeuristic closeup of the microcontroller:
The microcontroller will be our interface to CAN bus, where we will try to listen communications on the bus and to talk with the other peripherals. It is not possible to interface directly a PC for electric problems (signals are transmitted on the bus by differential voltage) and protocol reasons (need of a dedicated hardware to understand message on the lines that normal PC doesn't have on board). Unfortunately this is not the only device that we need for the project. More has to come.

Stay tuned!

EOBD Connector Pin Layout

According to the info found on this page this should be the pin layout for the EOBD connector:

Pin 1 - Ignition positive
Pin 2 -
Pin 3 - Data Tacho / MUX network Late generation
Pin 4 - Chassis ground
Pin 5 - Chassis ground
Pin 6 - Data Climate control/CAN High ('IS' Late generation)
Pin 7 - K Line Data Engine management / Automatic gearbox management
Pin 8 - Cooling fan control information / MUX network Late generation
Pin 9 - Charge information
Pin 10 -
Pin 11 - Data BSI
Pin 12 - K Line Data ABS/ESP/GEP/Suspension control
Pin 13 - Data Air Bag/Headlight control
Pin 14 - CAN Low('IS'.. Late generation)
Pin 15 - Data Engine management
Pin 16 - Battery positive

The OPEL/Vauxhall Vectra should use the CAN BUS to exchange information between the various components. I wonder how the pin are placed on the actual connector, since it seems a bit different. We will have to attach probably to pins 6 and 14 to get access to the bus.

EOBD on board diagnostic connector on the Vectra

Seems like my 2002 Vauxhall/OPEL Vectra supports the EOBD connector. I have found it near the gear shift lever and I'm now pretty sure about it thanks to this image:

found with Google Images. I'll post a picture of the exact location as soon as I can download photos from my mobile or get a decent camera.
This connector should provide access to all the internal diagnostic informations from the car like tire pressure, engine parameters, temperatures and more.
I have found some more info on it on Wikipedia. Seems like it's a standard for European vehicles since 2001 and should also include the CANBUS interface I'm interested in.
Now that I think about it, it should also be present on the other Vauxhall our family owns. I have to check this sooner or later!