CANcrusher Car Hack / Development Platform

I needed a fun way to test the LIN/KLINE channel with the CANcrusher (and an excuse to hack something) so I guessed that the RF receiver in my 2009 Pontiac Vibe would be using a LIN COM channel to talk with the BCM. (I was close.) Looking at the service manual for my car, I can see that there are only 5 pins with just 4 connections on the "Remote Control Door Lock Receiver (RCDLR)" module.

1. GND

2. Serial Data

3. Keyless Entry Program Enable Signal

4. NA

5. Battery Positive Voltage

This particular module, made by a company called TRW, uses a single wire serial connection which I was hoping was some type of LIN or K-LINE protocol. As it turns out, after connecting to my Picoscope, the data appears to be using a simple USART protocol, 8 bits, 1 start bit, no parity, 2 stop bits, 2400 baud. The nominal voltage on the line is 12V and the data appears to be only 1-direction, from RCDLR to the BCM. When you press a button on a learned keyfob, the serial data will start spitting out repeated 5-byte frames which I assume is the message for a specific button being pressed and held. When you release the button, a single, different frame is sent with some of the bytes only changing by 1 bit, indicating the release. At the beginning of the data stream, there is a 2-byte frame (0xF1, 0x10) which is some type of indicator message sent at the beginning of all data sequences.

Encrypted Data?....

At first I was expecting some type of encryption of the data but I'm not so sure anymore. The Service Manual says that this module can store up to 4 unique keys. When you press and release a button, you might get the following sequence:

F1 10 .... 54 02 00 1B 93 ... 54 02 00 1B 93 ... 54 02 00 1B 93 ...

Then when you release and press the button a second time you get:

F1 10 .... 54 02 00 03 AB ... (only 2 bytes change)

followed by:

F1 10 .... 54 02 00 0B A3 ... followed by

F1 10 .... 54 02 00 13 9B ...

After that, the sequence repeats. There are only 4 unique frames for that button being pressed and the sequence repeats in order. Hackable? Yes!

What's Next:

As you saw from the previous post, one of my prototypes died. Once I get prototype 2 up and running, I'll connect to the serial data line of this module using the LIN transceiver and mimic the data sent by this module to the BCM to control my door locks and panic button. From there, I'll be able to remotely control this feature via Bluetooth and through the SIM808 cell module from my server.

For those interested, this particular module uses an Infineon ASK 315MHz transceiver (TDA5201) and a Microchip PIC16F76 8-bit controller. If the protocol wasn't as straight forward as it was on the serial line, next steps would be to attempt to dump the binary image from the PIC. (Note: I can't imagine TRW would have left the fuse unlocked that would allow me to do that, but one should always try. ;)

One of my prototypes, ok, my main prototype, died a painful death on Monday. Something shorted 3.3V to GND and I couldn't figure out what it was. Typically when this type of thing happens, you start removing the likely components and replace them. I tried doing this, yet each time I removed a component, the short was still there. Long story short, I removed EVERY component and the short is still there. I cleaned the PCB, solder wicked all the excess solder and it still remains. I have a USB microscope on order so I can take a look at the board and see what's up. In the mean time, I do have a second prototype and will continue down the path as soon as I'm able. For those monitoring the progress of the project, sorry for the delay.

CANbus hacking made more simple... In addition to the scrolling CANbus data (the Matrix), I created a "static view" of the data in which all messages with the same Arbitration ID overlay each other in the same row so you can identify what data is changing and what is staying the same. To draw your eye to the changing data, a highlighting feature was added that will highlight in yellow and bold any bytes that are changing...

The software is moving along. Created some interfaces to parse the streaming USB RawHID data into CANbus messages for display in a scrolling table. Next steps is to add some different views such as capturing duplicate ARB IDs and overlaying the data on the same row to discover what data is changing and what data is staying the same. (Sneek Preview: Going to add a new feature called the "Mimic Interface" which will allow you to grab any of the existing messages, select which bits you want to set as a certain value and then the Mimic tool will grab all incoming messages with the same ID, change only the bits you want, and spit the new modified data back onto the bus immediately allowing you to mimic the ECU that is generating that message with your own custom data.)

I reworked the communication interface this weekend and got it to a fairly useful state. This same protocol will be used for USB and Bluetooth communication for interfacing to the diagnostic application. I created a RawHID USB Monitor for verifying the data traffic. Check out the CANcrusher Into video here to see it working on my car.

Hammond Manufacturing has been nice to use for the CANcrusher enclosure. The original box I chose was only going to be 1" thick, but I quickly ran out of vertical room and needed to upgrade (of course, this was after my board layout...) Thankfully, they had a direct replacement with the same L and W but with an extra .7" height for the design. In addition, they provide solid models for planning bezel layout and overall electronic placement. I used ViaCAD to design my enclosure layout and for exporting to MeshCAM to generate the gcode for the Shapeoko.

I finally got to use my Shapeoko for what I bought it for... Electronic project box bezels... Here's a pic of it cutting out the DB9 connectors.

Added some early code to the repository. Development is moving quickly so I hope to have some significant changes in the coming weeks. Check out https://github.com/afterhoursengineering/_CANcrusher_ARM

Worked through some of the major software architecture "snakes" this week. I have the basis of a communication protocol between the CANcrusher and the computer/tablet/whatever whether it's via USB or bluetooth. One of the hurdles I wanted to deal with was how to buffer the transmitted data, how much to buffer, etc. When CAN messages are flowing into the stream in 170-200us bursts and there are multiple CAN channels being monitored and sent off or logged, some of the packets have to be buffered. Since I'm using RawHID for the USB interface, I'm limited to 64 byte frames. I like using circular buffers for this type of thing, but I didn't want a single big buffer of all the frame bytes mashed into a single holding array and I didn't want some kind of rolling buffer of arrays. Instead I ended implementing a circular buffer of array pointers, addresses to the head and tail buffers. This seems to work well. The goal (crazy as it sounds) is to have the basic structure of this concept working this weekend and implemented on both a simple Java app and in the CANcrusher. We'll see how it goes...

• MCP2515 Drivers are done
• External IO functional
• Port Expanders and driver complete
• Bluetooth communication - complete
• SIM808 Driver - complete for GPS data parsing.
• SD logging - complete

I've tested the system on my car and am able to log HSCAN data at 500k rates. GPS is functional. Basic software is complete for extracting the binary log files and exporting to *.csv and Vector/Intrepid log file formats.

TODO: More then I'd like, but the list is shrinking!!