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!

New tool: CAN USB Cable

Some time before last Christmas, we noticed we were wasting too much time in determining the right way to connect to the car CANBUS and thus decided to buy a CAN connector. Looking for it on ebay we came across some affordable USB to can cables and we placed an order on both the items.

Now, after a month and a half, they finally arrived. This is the content of the USB cable package:

The cable seems pretty well made. We'll see how it behaves when we'll start using it.

The software that came in the cd is only for Microsoft Windows, as expected. It contains only a folder, no setup tools, with a poorly made program, very old Visual Basic style. This is what the main screen looks like:

This is the Opel car models list "supported" by the software:

Choosing Vectra-C from 2002 unfortunately reveals that support for that model is under development.

And this is the settings page. Our hope to have a tool that could tell us the bus speed and the other connection parameters vanished after seeing this screen:

First impression is that this is a poorly useful tool. We hoped to get some data on the correspondence between CAN packet identifiers and actual devices in the car, but it seems we are out of luck.

We hope to have some time soon to plug it to the car and see what this software can tell.

Ping? Pong!

Hi all!

As you may remind (maybe not ;-) ) we had not so much success in our can-bus experiments. The Vectra bus details are near totally unknown (at least for us), and we can't ever debug our interface, and this sense of vagueness is very frustrating. We felt like a blind man in a sandstorm.

To minimize this effect we try to build a cornerstone, developing a working can-bus scanner, replicating our interface. But the results are describend in the last post. So we have intensified our efforts in this direction. And finally...

IT WORKS! :D

We have successfully connected two PIC18F4682 with a Can-bus, at a speed of 95kbit, which should be the speed of MScan of Vectra. We checked communications, message type, payload etc. All work now. We implemented a progressive encoded (well... take it easy...) message passing to check that the messages we were exchanging were really the ones we espected.

This step should give us a good starting point for interfacing: the receive() function works for sure, now we can do a functional sniff routine.

The quest now is: will we find the right bus speed?

After our last unsuccessful try to communicate with the Vectra CANBUS, we decide to take a step backward and ensure that we were doing things the right way. In particular, we were interested in knowing if the CANBUS chip was connected right and if the logic of the program was correct.

To test this we got another breadboard and tried to replicate our current circuit so that we would eventually have two CANBUS connected PICs that could talk together, confirming we were doing things right.

So this was the breadboard at the actual state of the project:

And this one is the new breadboard with the essential part of the circuit cloned:

We went on and attached the programmer to the new breadboard but it did not work. The programmer simply could not find the PIC. We feared we had burned some chip due to incorrect power connections and proceeded checking differences with the original circuit. There weren't any.

To check whether we had really burnt the chip, we put it in the original breadboard and worked as expected. After putting it back in the new breadboard we could not figure what was wrong and spent really a lot of time trying to iron this out. In the end, we removed every chip and connection from the board and put them back in a different position paying extra attention to any connection. This time the chip worked and could be finally programmed and run.

We proceeded to connect the boards and wrote a different program on each chip, one that transmitted one message and the other that printed to the serial port the messages received (only the original breadboard has serial port chips). It didn't work. We tried to change the programs but it was already too late and we had to stop there.

Next time we hope to have the two boards communicate via CANBUS.

BZZZAAP!!!

Hi ALL!! After a long, long time we are back! Holidays, work and H1N1 (well... not really, only ordinary flu :-) ) have delayed our serious work, but yesterday we restarted it. As you can see...

some ruffled wires were connected to the EODB port. This is not really the first time that we interface our circuit to the car, but the last try was a failure. After some changes (both in code and wires) we do it again.

Results:

not many, really. We detect correctly the start of trasmission on the bus: when we turn on the ignition switch our circuit start receiving packets. Unfortunately the PIC module signals "overflow" status on CAN receiver, so we haven't received nothing meaningful. We hope we have guessed right the bus transmission speed, but we have to investigate further.

We did some exeriments on receiving packets (echoing on serial port, binking led...) to locate the problem, but the available time runs out quickly. But there will be the second round. :-)

Looking in the photos (sorry about the quality, the pictures are taken with a cellular phone in the dark, so noise is clearly visible) you can see the wires connecting EOBD in the hole above the shift lever and the circuit. The grey cable (a chunk of CAT5) on the right is connected to the serial port of laptop (not shown), you can see it a little better on the above photo. The dark box with leds turned on is PICkit2, the PIC programmer (also connected to laptop). We were doing real-time debugging of firmware :-)

That's all folks! We will be back as soon as possible, to continue this first part of the project. Stay tuned!