BoostedAero

I am down for this CAN hacking party...

Great Thread, keep it up fellas, once I get my mechanics straightened out I will be able to play some more with the logical side of the car like you guys

In for updates

scotttherobot

What a coincidence that I find this thread, and it's somewhat active, while I'm trying to accomplish the same thing! Awesome! I have a 2005 E320 CDI.

I have a Raspberry Pi set up with an MCP2515 and I've successfully been able to capture and send packets on CAN B, however not from all modules. I'm connected at X30/6 in the passenger side HVAC case (under the knee panel). I chose to connect here as it was the first easy spot I found. I don't really want to tear into my center console just yet.

I have been able to send text to the center line of the Instrument Cluster "TEL" menu using code based on angelovAlex's Arduino code in his github repo and also by simply replaying packets, but that's about it. I have not been able to send custom text to the audio screen or the page headers (where it says "TEL", "FM", etc) and it seems like it's because my packet hashes are not being calculated correctly. I've taken a slew of packet captures and I'm going to spend some time going through angelovAlex's code more thoroughly to hopefully understand the hashing algorithm. My approach is to try to replicate packets sent from the AGM to the IC since I can compare my generated packets to the packet captures.

It seems like if I get connected to CAN B on the other side of N10/1 (driver's side SAM) I should be able to control more things like windows, seat heaters, etc. Where's the best, least-invasive place to do this?

angelovAlex

That's great that more people became active, that helps me be interested in that project and keep finding something new.
I believed that CAN B was the same everywhere and it doesnt matter where to connect. But I had a similar expirience when I was connected to phone plug, when it was sending only internal pacakes between phone and phone control unit. But according to CAN BUS scheme you are connected to a right place.

The code that's on github is messy, as its my working code that I played with during reverse engineering. And many functions can be broken or coded in old way.
I will clean up this code one day to make it more understandable and easier to use. But now a few explanations of how to write custom text to ic screen. In code there's a define AGW_SIMULATION, if you enable it it does all agw-kombo comunication. You can check what it sends and replies, but it's probably wont work in a car as it will interfere with real AGW in a car. Also there's a PRINT_IC_COMMUNICATION that makes a beautiful output of that communication.
And most interesting things for you. One is diag_send function, it does encapsulations of data and calculates a hash for your message if needed. That function can accept any data and I wrote it recently, while you can still find a lot of functions with my first tries of finding out of how hash algo works. To change top line you will need to send package_24, also first byte says to which screen (3 - music, 4 - navi, 5 - phone). this package contains the text at top(can be empty), top icon(if needed, you can play with show_arrows function), and bottom icon or second line text. Also if you set that top line is not empty in package_24, you can just update the top line with package_29.
I will update this code soon as all this stuff in my head and I didnt made an easy to use functions to draw all that things on the screen.
Unfortunatly, you can't do much with music and phone screens, as far as I find.



Of course you can use diagnstic commands to draw on the screen, but it's very slow

scotttherobot

Fantastic, that was very helpful! I do have a few more questions which I can't answer myself because my car is now in the body shop for the next week.

What CAN messages require a hash? Based on your encapsulation code, the hash should come at the byte following the last byte of the message string. I'm noticing in my captures that some of the messages do have hashes (eg, the ones to the AUDIO screen) but some do not (ones to the TEL screen). I noticed this by comparing the last message in multi-part messages that have the same data in the final packet. Similar TEL messages tend to have identical final packets while AUDIO messages do not.

This leads me to my next question: What data should come after the hash? For example, here's a captured message from my car:
Now, here's a message I found in a comment in your code which works when replayed in my car:
And finally, a message I generated using your encapsulation code:
These messages are all identical up to the hash, then they start to vary. The message I found in your comment works in my car, despite being different. I have not been able to test my generated message yet. What is the data after the hash? Is it garbage from memory? Is it significant?

I'm still working on understanding the package 24/26/29 differences. I'm hoping to get to generating more packages this evening.

Mitch Detailed

Im late to the party, but am slowly working on reverse engineering the can-c. while nit directly involved with can-b, can-c does offer a lot of great information.

I use 2 interfaces, cancapture with Windows (1300usd), and 8devices usb2can with Linux terminal on Ubuntu (150usd),

YouTube.com/opengarages has some great information, and his book is now free to download on his website at opengarages.org.

Happy hacking

scotttherobot

I previously suggested that some messages might not require a hash. I now believe that this is false. I realized that the "last packet" I was looking at was not in fact the last packet, and the hash was in the 5th packet!

I believe I'm correctly generating package 26 now. Here's a captured set of packets which displays "AUDIO off" on the IC when you turn off the radio.

And here's my generated package which says the same "AUDIO off" message.

As I mentioned before, I can't test this yet since my car is in the shop, but assuming that the bytes after the hash do not matter (which I have not been able to confirm) this should work. I added support for packages that are more than four packets long, which was trivial.

So I've got 26 and 29 down, now to figure out package 24.

I'd like to clean up my code and share it. I'm working in C for now (compiling on Raspibian and MacOS), generating packets that I can pipe into cansend. I'd also love to contribute to better documentation of each type of can message. The list of PIDs is great but something about package structure would be more helpful.

Welcome Mitch! I'm just getting started as well. The OpenGarages videos are great. If you haven't checked this stuff out as well, it's worth a look! http://illmatics.com/carhacking.html

angelovAlex

Why is it so expensive? I just use Chinese 3$ modules, what's the point to pay over 1500$ just for tools if they are not any better then tiny modules?

Sorry for a long reply.
The bytes after hash are just garbage, you were right. And you were right about saying that not all packages require hash. The most important ones like 24, 26, 27, 29 does require hash, but many of short messages dont.
In the list of PIDs there are also information about package structure, it says what every paramater in package means, its length and offset. We just dont have information about packages that are used for communication between modules. I'm also interested in "external application" packages as I was not able to find any information about it.
To spend more time at home with family I bought another IC unit for tests at home
You can write me in skype, I would be happy to answer to any questions that you have. Just ping me for nickname in pm.

Added: Btw, package 24 is the most interested one. At first I believed that that's a package that sets the layout of strings and icons for a screen and then in other packages you just sends the strings to fill buffers. A confirmation of that was if you send package 24, ic unit asks for all other buffers. But I met a huge limitation, if you get a package 24 from screen 13(service menu) and send it to screen 5(tel), if wont work and just crash that screen (will show only 3 dashes --- and then will redo initialisation). So only limited variants of package 24 can be send to screens, which for me looks like screens have "pre-defined" layout and can be modified only slighly I played a lot(a couple of evenings) with package 24 and didnt find anything very interesting there (except setting 1/2 lines, icons, 3rd line at top right corner, bold/aligment/blinkings), but I still believe that all magic is hidden in this package.

jumph4x

^ Alex is the MVP. Keep the updates coming.

scotttherobot

Does package 28 (show up/down arrows?) require a hash? Comparing frames that I captured from my car to frames that you generated, you're putting your hash in a byte that's always 0x00 for me.

Do you know what package 0x25 does? Is that the frame that "asks" for the other buffers? In my captures, it always goes that I see package 24 to IC, then package 25, and then finally package 26 with the strings. Is this the case?

It's smart of you to get a separate IC for testing, I am working on getting one myself.

My next steps are to blindly implement functionality for controlling windows, seat heaters, sunroof, the rear sun shade, rear head rests, and anything else I can come across in this list of PIDs and hope that they work when I get my car back.

Have any of you played with any of the other CAN buses? I am particularly interested in the Keyless Go module. It would be fascinating to emulate this module (my car is not outfitted with keyless go) to add functionality like remote/keyless start, but it's probably a lot more complicated than that. From what I have seen, the one aftermarket remote start module that I've found needs to be wired into the EIS ignition module directly.

angelovAlex

yes, package 28 sets arrows (not only up and down)
05 28 02 XX 01 XX 02 HH
05 - ic screen
28 - package number
02 - count of icon list (you can send more then two but it won't display anythin new)
XX - first icon
01 - number of icon in list (starts from 1)
XX - second icon
02 - number of icon...
HH - hash
so you can send only one icon if you want: 05 28 01 XX 01 HH

package 26,28... wont work without sending package 24 at first
it's bidirectional comunication and for every package that was sent, a confirmation package goes next
here's more visual example:
5 <<< 24($) 6()
5 <<< 25(%) 1() 0() 0() CA(�)
5 >>> 25(%) 6()
5 <<< 22(") D7(�)
5 >>> 22(") 6()
5 >>> 20( ) 2() 11() C1(�)
5 <<< 20( ) 6()
5 <<< 21(!) 2() 1() D0(�)
5 >>> 21(!) 6()
5 >>> 24($) 2() 0() 1() 2() 0() 0() 0() 13() 0() 1() 0() 2() 0() 3() 0() 54(T) 45(E) 4C(L) 0() 1()
5 <<< 24($) 6()
5 <<< 25(%) 1() 0() 2() C8(�)
5 >>> 25(%) 6()
5 >>> 26(&) 1() 0() 2() B() 10() 4E(N) 6F(o) 20( ) 70(p) 68(h) 6F(o) 6E(n) 65(e) 0() 3() 10() 0() 0() EE(�)
5 <<< 26(&) 6()

you can see that after each long message with hash, there're a short ACK reply with 6(I believe it's SUCCESS) at the end
I believe that package 25 is used to get buffers
in package 24(agw->ic) you set how many strings you have: 24($) 2() 0() 1() 2() 0() 0() 0() 13() 0() 1() 0() 2() 0() 3() 0() 54(T) 45(E) 4C(L) 0() 1()
then ic unit sends package 25(ic->agw) to agw unit saying "hey, agw, you said that I have 2 string, so please give it to me": 5 <<< 25(%) 1() 0() 2() C8(�), there's also offset, so it can ask not for all buffers at once
then package 26(agw->ic) sends buffers: 26(&) 1() 0() 2() B() 10() 4E(N) 6F(o) 20( ) 70(p) 68(h) 6F(o) 6E(n) 65(e) 0() 3() 10() 0() 0() EE(�)
you can see that 1 0 2 part is the same as in package 25
B - length of first buffer
10 - aligment/center/blinking
then text
and it ends with 0
3 - length of second buffer
10 - aligment/center/blinking
0 - zero immediately means that its empty
and then EE is hash

At the moment I played only with Can B, but I'm going to start playing with Can C soon, when I finish my hardware and it will be reliable enough to connect it to Can C without scaring that something can happen during driving.
It would be so nice to emulate Keyless go module, I will definitely play with it soon, hopefully we have jumph4x who has a car with Keyless Go and will be able to collect logs for us But yes, I think that we will have to put some hardware between EZS and can bus, so we can hijack/simulate packages that goes to/from EZS.

Mitch Detailed

Features and benefits, along with a couple references from companies that i may directly work with to push the platform and platforms in the future.

Dbc creation, and graphing on the fly, as well as complete dashboard creation for anything.

jumph4x

Going to leave this here:

scotttherobot

All right, well, I've conquered just about everything. Seat adjustments. Horn. Steering wheel buttons. IC display. Seat heaters/vents. Rear sun shade. Just about everything BUT the windows, which are like the coolest thing. I have been able to control the windows using the 0x044 PID, but that one won't control the driver's side window. And anything I send to 0x050 doesn't seem to do anything at all, despite being the one that Alex is using and explained is apparently a message from EZS to control the windows.

Here's the (English) documentation from the PID list:
So per this, I prepared the can message below expecting it to open all windows
However, it doesn't. Interestingly, sending 0x08 cuases the sunroof to open (0x0A auto) and 0x0C (0x0E auto) causes it to close, as expected. None of the other windows will respond to this PID. Interestingly, any package I send with a leading 1 (eg, with a first byte of 0x8 or 0xF) causes the driver seat ventilator to turn on.

Why is my sunroof the only window that responds to the 0x050 pid?

scotttherobot

Well, I was determined to figure it out so I went back out to the car... And only confused myself more. I started playing with all the PIDs that had reference to the windows (0x050, 0x250, 0x248). I finally got things responding to 0x248, however not reliably.

0x248 doesn't seem to have a bit for the sunroof, but I can at least control the rear windows (auto and manual) reliably, and the front windows sometimes. The front windows only work automatically (they ignore the auto/manual bit that the rear windows respect) and they only respond once (and then not again until you control one of the other windows or wait several minutes). I tried sending a "blast" of the same packet to no avail. I did not think to send a "release" packet of 0x00 though.

I'd much prefer to use the 0x050 address that others are using. Still not sure why that one isn't working.

Mitch Detailed

Is anyone else using can-utils and Linux for logging of canbus information?

Mackhack

CAN Hacker

angelovAlex

I dont use any can-untils, but I ran out of memory on my arduino and decided to move all logic to linux router, instead of having the whole code in arduino. Now arduino is used only as comunication device to send/read packages to/from CAN bus.
Its better as now I can debug the code with a normal debugger and update the code over the internet.

scotttherobot

Indeed, I am. I have my MCP2515 set up as a linux socketcan interface, so I use can-utils (cansend, candump, etc) for logging and playing. For programmatically generating packets, I'm writing my code in C and talking to the can interface over a socket, utilizing the <linux/can.h> headers.

angelovAlex

Are you going to make it as an independent unit that will add some features to your car? Or you just want to play with a can bus using your laptop?

scotttherobot

That's the plan. I'm using a Raspberry Pi plugged into a USB car charger tucked into the glove box, and I wirelessly connect to it from my laptop. I'd like to follow along with what you've done like automatically enabling seat heaters on startup if it's cold, etc, and I'm also exploring building an iOS app to remotely control the locks, windows, etc.

My ultimate goal is to figure out how to emulate keyless go/EZS to enable remote start, but I'm not sure how likely that is to happen. I'm working on buying EZS and ESL modules so I can sniff the two CAN buses and the K-line and see what's going on there. I know it can be done (there's at least one aftermarket module that adds remote start using the factory key fobs) but I don't know if I'm smart enough to figure it out!

Mitch Detailed

Well, here's what I use, And id recommend it to anyone:
Laptop + Linux ubuntu 16.04 LTS , you can alternatively run this in VirtualBox on windows, but I dont prefer to do so.


8Devices usb2can module - $65 usd + Shipping
8Devices Usb2canthere's other tools that have caught my eye, Cantact.io being one, but it's hard to justify when I aready have one.

both of these units have an ending connector of a DB9 connection, so I went to amazon and ordered some Crimp connectors , and the housings
I Used 20 awg /16 wire for my connections, and also utilized a dtm connector for breaking out the connections for easy repurposing (1 module side connection, to many car side connections (can-b, can-c, and can-d). If interested in some type of breakout connection, there's plenty of options readily available, but I prefer DTM 2 pin connectors.

Idk anything about the CAN-B hub, and it's connection options, but Can-D can be utilized from the OBD2 Port,

OBD2 Male Port Here

OBD2 Male Terminals Here

Can C Hub utilizes a Hub along the bottom Left side rail underneath the front Left carpet, it has 13 ports for connections (1 3pin port, 12 2 pin ports)

The 2 port connector is Here
Pin 1 = Can-H
Pin 2 = Can-L

The 2 port connector terminals are Here

(for those wanting an extra hub to play around with, they're only available from dealerships and the p/n is: 003 546 42 40)

I recommend Running White wire for Can-H and Green for Can-L as this is somewhat an industry standard for Can systems.

As for Resources:
Open Garages Main Page
Car Hackers Handbook, A Guide for the Penetration Tester
Cantact.io Using Can-utils page

In linux, i utilize a few other free programs, Vokoscreen primarily. It's simply a screen recording program that i'll use to set up a session , i'll simply start recording video and microphone audio and state everything i'm trying to do, to interpret and review any data at a specific location or time. this has helped me reverse engineer various items on Can-C.
I also utilize libre office in linux for breaking down logs into a binary format, this helps me at times identify patterns and clear up obfuscations.

Link to ODS Spreadsheet for Hex->bin conversion of .log packets from can-utils Here
Link to sample Can-C 0x200 log Here

Mitch Detailed

have you thought about or looked into teensy 3.5/3.6?

scotttherobot

I have not! I have used Teensy2.0 in the past, but 3.6 looks awesome! I will look into it, the two built in CAN interfaces would be a big win. It would definitely be ideal to use something more embedded than the Raspberry Pi, which I targeted mainly because it was the first thing I could get working on the CAN bus. :P

Are you planning to use Teensy3/6?

Mitch Detailed

my goals are a bit different than yours, i'm more focused in reauthorizing control of another configurable ecu vs the oem system, but limitations may require me to utilize one as the interface device between the oem canbus and an aftermarket ecu canbus

Mackhack

www.MidCityEngineering.com.

I'm not sure if you'll get the EZS from MB as it is a theft relevant part that also needs to be coded by MB in Texas. Let us know. You guys make good progress on this. I personally stopped after finding most PIDs.

Btw. did anyone find out if you can open and close the trunk with the power trunk closer? That's what I would be interested in most.