Medium Duty CAN bus Protocol

[kidturbo]

Here ya go. http://forum.canb.us/discussion/217/gm-infotainment-bus-low-speed-single-wire-33kbps#latest

I ran into a similar problem with my MB E320 which runs a 83.3kbps two wire fault tolerant convenience bus. It's all a Bosch thing.. Derek recently updated the CBT software to include that one. But I haven't tested it yet. I'd managed to get data off it in single wire mode a couple times, before it freaked out the master control module and set a bunch of codes that scared the crap outa me.... Wife's car. LOL

I have a buddy leaving me his 07.5 for a few days to test with. I know when I looked this up before, the tap shift / tow haul controls are wired directly into BCM on LMM. Not sure about the cruise control. It was previously connected to ECM on the LLY, cause I was planning to setup cruise on my boat. Should be possible to capture the BCM shift commands on HS LAN and replicate with the CBT. Others have done this for different vehicles I know.

On the LML security issue, when you get comfortable, the CBT can do a "man in the middle" setup when wired in the bus like a gateway / firewall. Could configure it to forward all data to ECM, then block or change what you wish to filter out. Messing with a single bit in what ya think is VATS data would likely be enough to verify those packets. Once isolated, should be able to spoof it...

-K

PS. My friend who developed that custom CAN-2-CAN gateway I'm using, was also involved with the C5 Vette. He's heavily invested in promoting this hardware for aftermarket uses. We had to do a minimum number of PCB's per run to make all this worth while.

 

[duratothemax]

Here ya go. http://forum.canb.us/discussion/217/gm-infotainment-bus-low-speed-single-wire-33kbps#latest

I ran into a similar problem with my MB E320 which runs a 83.3kbps two wire fault tolerant convenience bus. It's all a Bosch thing.. Derek recently updated the CBT software to include that one. But I haven't tested it yet. I'd managed to get data off it in single wire mode a couple times, before it freaked out the master control module and set a bunch of codes that scared the crap outa me.... Wife's car. LOL

haha! I wonder though if it maybe shorted the bus somehow? Did you just tie the "CAN LO" wire on the CBT to ground, and then the CAN HI wire to the "single wire CAN +" wire? If you directly short the bus and crash the whole thing, it will freak out, but just sniffing packets shouldnt ruin anything.

I have a buddy leaving me his 07.5 for a few days to test with. I know when I looked this up before, the tap shift / tow haul controls are wired directly into BCM on LMM. Not sure about the cruise control. It was previously connected to ECM on the LLY, cause I was planning to setup cruise on my boat.

tow/haul, tap-shift and cruise control are wired directly to the BCM on 2007.5+, and then the BCM sends the appropriate data messages to the ECM and TCM. Brake pedal status (for cruise control etc) is wired to both the BCM and the ECM. There are two separate brake pedal switches for safety/redundancy...a normally open, and a normally closed. The normally open switch is wired right to the ECM, and the normally closed switch is wired to the BCM...when the switch transitions (brake pedal pressed), the BCM and ECM exchange info to make sure the two signals agree/plausible.

Cruise control buttons on the steering wheel are resistance ladder wired right to the BCM on 2007.5-2014. 2015+, the steering wheel controls are smart components that communicate on the LIN bus to the BCM, and then the BCM forwards LIN bus commands to ECM via HS GMLAN.

So to "fake" cruise control on a 2007.5-2014 LMM/LML, you'll have to mimic the HS GMLAN "cruise on/off, resume, etc" messages from the BCM to the ECM....and you'll also have to make sure you send the proper brake pedal status info at the same time, because otherwise the ECM will see its own brake pedal discrete input changing state, but not receiving a coinciding message from the BCM...and it will disable cruise for safety.

And then faking tap-shift and tow/haul is easy, both of those are wired right to the BCM

On 2001-2007 trucks, tap-shift (on 06-07) and cruise control are discrete signals wired right to the TCM and ECM. Tow/haul goes over the Class 2 bus as a message from the BCM. Ive already figured out the tow/haul class 2 messages, so now its easy to keep tow/haul functional on 2001-2007 swaps that want to keep tow/haul without having to keep the BCM wired up.

But havent messed with 2007.5+ yet.

On the LML security issue, when you get comfortable, the CBT can do a "man in the middle" setup when wired in the bus like a gateway / firewall. Could configure it to forward all data to ECM, then block or change what you wish to filter out. Messing with a single bit in what ya think is VATS data would likely be enough to verify those packets. Once isolated, should be able to spoof it...

-K

The 2007.5+ theft deterrent module communicates on LS GMLAN only. The ignition switch is discretely wired to the BCM.

So when you go to start a 2007.5+ truck, turn the key to start...BCM and TDM communicate on low speed GMLAN to make sure a valid key transponder is being read...then once the TDM accepts the key as valid (its a key that has been previously married to the TDM), the TDM does a challenge/response algorithm/password calculation with the ECM....so its a little more complicated to spoof the TDM/BCM (if you wanted to eliminate those in a standalone swap vehicle)....because you'll have to know the password calculation stuff.

1. key turned to start, BCM sees that the ignition switch was turned to start.

2. BCM tells the TDM via LS GMLAN that the key was turned to start, TDM then reads key transponder

3. TDM reads key, OK, it was the same valid key used at last start...first test passed

3. TDM tells the BCM "yes, its the proper key"

4. BCM tells the ECM over HS GMLAN that engine start has been requested and tells it that the TDM has given the initial "ok"

5. ECM and TDM do the challenge/response password (via the BCM, using the BCM as a translator because TDM only speaks LS GMLAN and ECM only HS GMLAN).

6. Everything matches up and passwords match

7. ECM checks for no shorts or open circuits on the starter relay control circuit (if the starter relay is bad, or theres an issue with the wire going from the ECM crank relay driver to the relay itself, it disables fuel and starting)

8. ECM enables fuel and then ECM actuates the starter relay.

Its complicated....because when first setup, each ECM and TDM have to be married together, and I think they generate/learn eachothers unique password. So theres no "universal" message that will command the ECM to crank the engine....I think?

The only possible way around this, is to maybe spoof the message for remote start....IE, hit the remote start, and then see the message that the BCM sends to the ECM over HS GMLAN. Because that might bypass TDM/antitheft since obviously theres no key being read.

But then the remote start will cancel after 20 minutes or whatever.

So maybe you could first spoof the message for remote start...and then spoof the second message for "the driver unlocked the truck, put the key in the ignition and turned it to ON, ending remote start and enabling normal run"

But then again, maybe when that happens, the same password exchange happens with the TDM...and if it doesnt pass, then the ECM shuts the engine off.

Who knows.

And you cant disable the starter relay checks and anti-theft stuff in the base ECM operating system itself on an LML ECM, because its all locked down via RSA encryption.

Thats why I recommend avoiding a standalone LML setup at any cost...unless the customer wants to transplant the stock LML BCM, TDM, and ignition switch. Which is clunky, expensive and annoying.

Ben

 

[duratothemax]

Also...on that custom CBT firmware update to allow 33.3k LS GMLAN...how are they reflashing/programming the CBT with that custom firmware to allow 33.3k as a valid bitrate?

 

[kidturbo]

On the wife's Benz, I finally broke out the Modus oscilloscope to figure out what was crashing the bus. That 83k network is two wire, then falls back to single wire on errors. It's also non-terminated, and operates at higher voltages than the standard Bosch CAN versions like our high speed GMLAN. With CBT in Listen Only mode, I was finally able to stop the bus from crashing. Now it just locks up the CBT after a few lines of data are captured. Hopefully his firmware code update did the trick.

But when the wife got in her car one morning and saw Red STOP VEHICLE !! Visit Workshop! messages flashing, my hacking privileges were instantly revoked... She'll forget to hide the keys again one day.

When your ready to jump on that LML security, I'll get my underpaid GM mastertech buddy to join us. He's pretty slick. Has saved me and couple others on here from "didn't know everything we thought we did" embarrassments before... He also explained that new rolling key concept to me a while back, but I had no need to remember any of it at the time.

To update the firmware on the CBT, you need the Arduino sketch tool. Link to the basic firmware is on the CBT forum, and full source code development is on github.

-K

 

[duratothemax]

On the wife's Benz, I finally broke out the Modus oscilloscope to figure out what was crashing the bus. That 83k network is two wire, then falls back to single wire on errors. It's also non-terminated, and operates at higher voltages than the standard Bosch CAN versions like our high speed GMLAN. With CBT in Listen Only mode, I was finally able to stop the bus from crashing. Now it just locks up the CBT after a few lines of data are captured. Hopefully his firmware code update did the trick.

Yeah, leave it to the Germans to do something weird and non-standard...

But when the wife got in her car one morning and saw Red STOP VEHICLE !! Visit Workshop! messages flashing, my hacking privileges were instantly revoked... She'll forget to hide the keys again one day.

haha, yeah it took some serious convincing for my girlfriend to let me mess around with the door locks and LED daytime running light settings on her 09 Audi A3.

When your ready to jump on that LML security, I'll get my underpaid GM mastertech buddy to join us. He's pretty slick. Has saved me and couple others on here from "didn't know everything we thought we did" embarrassments before... He also explained that new rolling key concept to me a while back, but I had no need to remember any of it at the time.

Not to dis your buddy, but unfortunately no GM "outside" training, dealer or otherwise, goes into anywhere near as much depth as would be needed to reverse engineer this. After using the GM dealer service manual daily for years and memorizing countless "electronic component theory/description of operation" documents for most every GM late model vehicle...im sad to say that they just dont publish the required info...beyond what I described in the above post.

The actual stuff that we would need is strictly proprietary GM internal information, and short of finding a high-level contact at GM Software/Electronic Component Design, is going to be extremely difficult to reverse engineer.

Even the seed/key/password calculation would be extremely complicated, if not impossible to figure out...depending how many bits/bytes long the password algorithm is. Probably have to log dozens of different trucks to get enough data points so that a mathematician/cryptography expert could break them down and figure out the original mathematical calculation/equation that is used by the TDM and BCM/ECM to come up with the passwords in the first place.

Basically like creating a keygen/hack for a piece of computer software.

I can maybe try logging immobilizer stuff on my truck, because its a 2005 so its all Class 2...which is obviously a lot slower and less congested bus compared to GMLAN.

I know the module ID for the TDM on my truck is $C0, so maybe if I have some time later on, Ill log messages that pass between $C0 (TDM) and $10 (ECM). The BCM isnt used for immobilizer stuff on my truck, all immo stuff happens directly between the TDM and ECM on the Class 2 bus, no middle man or translator/gateway or anything like that.

I have a 3rd key for my truck that is unlearned/wrong transponder, which obviously wont start the truck, so Ill try that back to back with the proper learned key, and see if I can spot any patterns or anything when the ECM and TDM perform immobilizer calculations and what exactly happens when the ECM and TDM pass anti-theft and fail anti-theft on startup...

Probably useless though, because like I said, my truck is Class 2 and the immobilizer is setup completely differently.

To update the firmware on the CBT, you need the Arduino sketch tool. Link to the basic firmware is on the CBT forum, and full source code development is on SourceForge.
-K

Ill have to look into that...I use PIC microcontrollers for all of my products/modules, so I know very little about Arduino and the different programming language they use....basically starting from scratch, total noob with that.

 

[duratothemax]

Ok I did some logging and testing.

It seems all of the complicated challenge/response mathematics happens only between the TDM and the transponder chip in the key itself.

The TDM and ECM dont do any challenge/response or calculations. This is good!!

Theres simply a "everythings all good, enable fuel/allow starting" message, and a "wrong key, no key disable fuel/disable starting" message that the TDM and ECM exchange.

I assume this password is created randomly when the ECM and TDM are setup initially. So when the ECM or TDM is replaced or new keys are learned, the ECM and TDM come up with a random "agreed upon" password, and they both store it in their memory.

Obviously a common universal "fuel enable" message would be worthless because you could simply broadcast that message on the bus and bypass the anti-theft system...its a randomly generated password that is decided once, and then used every time...unless the ECM or TDM is replaced and re-learned manually.

The password is only transmitted once the TDM first determines that the key being used is "known good/proper"

The fuel enable password looks like its two bytes long...so that gives 65,535 possible passwords. Or I guess 65,533 possible passwords, because you obviously arent going to have the password be 0x00 0x00 or 0xFF 0xFF

Fuel disable password looks like:

$28, $93, $C0, $01, $FF, $FF, and then the checksum

$28 $93 $C0 is the header, high priority functional address message, destination/receiving node is $93 and $C0 is the transmitter (which is the TDM)

the actual password is in the 5th and 6th bytes of the message string with $00 $00 being invalid, and $FF $FF is fuel disable.

Obviously Im not going to post my actual data message logs from my truck because then everyone would know the fuel enable password for my truck, duh.

So what this means, is that the TDM could be very easily spoofed IF you knew the correct fuel-enable password. But to get that password, you would need to data log a running truck with a proper BCM, TDM, and good key.

So if you were to first log that password, and THEN take the truck apart, swap the powertrain into your marine application, you could easily build a little module (or just have the CBT transmit it upon engine start) to just send out the fuel enable password to the ECM, and it would work fine with the BCM and TDM eliminated.

All speculation. Unfortunately I dont have as much time to devote to figuring this out as I would like to...but right now, it looks doable...now that I know there is no actual complicated calculations being passed between the ECM and TDM...its just a single pre-determined password. The day-to-day annoyances and mundane housekeeping/order filling of running the business cuts into my R&D time, and for me to prioritize, I have to decide if the R&D is worth it....for the amount of people that contact me about making a standalone LML setup vs all other Duramax's, I cant justify it.

Ill keep messing around with it though, maybe spend a little time on it here and there.

Ben

 

[henery97]

So when you go to start a 2007.5+ truck, turn the key to start...BCM and TDM communicate on low speed GMLAN to make sure a valid key transponder is being read...then once the TDM accepts the key as valid (its a key that has been previously married to the TDM), the TDM does a challenge/response algorithm/password calculation with the ECM....so its a little more complicated to spoof the TDM/BCM (if you wanted to eliminate those in a standalone swap vehicle)....because you'll have to know the password calculation stuff.

1. key turned to start, BCM sees that the ignition switch was turned to start.

2. BCM tells the TDM via LS GMLAN that the key was turned to start, TDM then reads key transponder

3. TDM reads key, OK, it was the same valid key used at last start...first test passed

3. TDM tells the BCM "yes, its the proper key"

4. BCM tells the ECM over HS GMLAN that engine start has been requested and tells it that the TDM has given the initial "ok"

5. ECM and TDM do the challenge/response password (via the BCM, using the BCM as a translator because TDM only speaks LS GMLAN and ECM only HS GMLAN).

6. Everything matches up and passwords match

7. ECM checks for no shorts or open circuits on the starter relay control circuit (if the starter relay is bad, or theres an issue with the wire going from the ECM crank relay driver to the relay itself, it disables fuel and starting)

8. ECM enables fuel and then ECM actuates the starter relay.

Its complicated....because when first setup, each ECM and TDM have to be married together, and I think they generate/learn eachothers unique password. So theres no "universal" message that will command the ECM to crank the engine....I think?

The only possible way around this, is to maybe spoof the message for remote start....IE, hit the remote start, and then see the message that the BCM sends to the ECM over HS GMLAN. Because that might bypass TDM/antitheft since obviously theres no key being read.

But then the remote start will cancel after 20 minutes or whatever.

So maybe you could first spoof the message for remote start...and then spoof the second message for "the driver unlocked the truck, put the key in the ignition and turned it to ON, ending remote start and enabling normal run"

But then again, maybe when that happens, the same password exchange happens with the TDM...and if it doesnt pass, then the ECM shuts the engine off.

Who knows.

And you cant disable the starter relay checks and anti-theft stuff in the base ECM operating system itself on an LML ECM, because its all locked down via RSA encryption.

Thats why I recommend avoiding a standalone LML setup at any cost...unless the customer wants to transplant the stock LML BCM, TDM, and ignition switch. Which is clunky, expensive and annoying.

Ben

So has anyone been able to decipher the LMM ECM/TDM code for standalone LMM use?

 

[duratothemax]

So has anyone been able to decipher the LMM ECM/TDM code for standalone LMM use?

See my post above...the fuel enable password looks easy to spoof, as long as you know it and can log a running truck with a valid key.

Once the password is known, just send it to the ECM over the databus when you go to crank the truck, format the message properly and time it as if it came from the TDM....and the ECM will start normally and never know the difference. :thumb:

Ben

 

[henery97]

Is there a way to eliminate the TDM completely and send the "passcode" directly to the ecm for fuel enable or do you have to have the TDM there for other purposes?

 

[duratothemax]

In thinking about this more...

Maybe for a standalone setup, we could mimic the anti-theft learn process (where you sit with the key on for 10 minutes, wait for security light to go out, key off, key on, etc)...then you could force the ECM learn whatever password you wanted (anything from 1 to 65,534)...and then just have a little standalone module broadcast that known password, and it would work perfectly.

Or, even easier...set the ECM up on the bench with a BCM and TDM hooked up...and put the ECM/TDM through the learn procedure...then grab the password once its learned/decided upon by the ECM and TDM....and theres your password right there, dont need to log it from a running truck, just need a bench harness with a TDM and BCM, and 30 minutes of your time. :thumb:

Ben

 

[duratothemax]

Is there a way to eliminate the TDM completely and send the "passcode" directly to the ecm for fuel enable or do you have to have the TDM there for other purposes?

From what I can tell, YES...as long as you knew the password, you can theoretically eliminate the TDM, and then just send that known password right to the ECM from any little microcontroller and databus interface...and the ECM will never know the difference.

Ben

 

[henery97]

See my post above...the fuel enable password looks easy to spoof, as long as you know it and can log a running truck with a valid key.

Once the password is known, just send it to the ECM over the databus when you go to crank the truck, format the message properly and time it as if it came from the TDM....and the ECM will start normally and never know the difference. :thumb:

Ben

Ya you posted that as I was typing and I didn't see it until I had already posted mine.

 

[henery97]

From what I can tell, YES...as long as you knew the password, you can theoretically eliminate the TDM, and then just send that known password right to the ECM from any little microcontroller and databus interface...and the ECM will never know the difference.

Ben

Have you logged long enough to know if the tdm sends a heartbeat to the ECM periodically?

 

[henery97]

In thinking about this more...

Maybe for a standalone setup, we could mimic the anti-theft learn process (where you sit with the key on for 10 minutes, wait for security light to go out, key off, key on, etc)...then you could force the ECM learn whatever password you wanted (anything from 1 to 65,534)...and then just have a little standalone module broadcast that known password, and it would work perfectly.

Or, even easier...set the ECM up on the bench with a BCM and TDM hooked up...and put the ECM/TDM through the learn procedure...then grab the password once its learned/decided upon by the ECM and TDM....and theres your password right there, dont need to log it from a running truck, just need a bench harness with a TDM and BCM, and 30 minutes of your time. :thumb:

Ben

How would you trick the ECM into a relearn procedure when there is no tdm to read from?

 

[duratothemax]

Have you logged long enough to know if the tdm sends a heartbeat to the ECM periodically?

Yes, ALL modules on the databus broadcast a regular heartbeat (technically called a "state of health" message) once every couple seconds. And then all the other modules make a note of that, and if one module drops offline, all the other modules make a note of that and set a code, or act accordingly.

A state of health message is very simple and easy to spoof.

"0x03" is a general "Im online and here" state of health/heartbeat message, and generally the state of health messages are never directed from one module to another specifc module...each module just addresses the message to all modules simultaneously ($FF)

So you can spoof a state of health message from any module, as long as you know the address..

$10 is ECM
$40 is BCM
$C0 is TDM
$80 is radio
$98 is HVAC
etc etc...

2003+ trucks all have at least 10 or so modules communicating on the bus, and depending on options (onstar, XM, Bose, etc), could have up to 20 or more.

So, given 0x03 is a "alive" message, you could simply broadcast

$08 $FF $C0 $03 (and then the checksum)

$08 = highest priority, functional address message
$FF = destination of message, $FF=all modules
$C0 = origin of message ($C0 is TDM)

$03 = the actual message itself, 0x03 = im alive and here

So just send that out every couple seconds, and everything will be all set.

 

[duratothemax]

How would you trick the ECM into a relearn procedure when there is no tdm to read from?

You could either set it up on the bench with an actual TDM and ECM, and then it will do the relearn normally, and you can just spy on the bus and get the password.

OR

Watch the bus and copy the entire string of messages that the ECM and TDM go through to learn a password. Then send that whole string of messages out so the ECM thinks its initiating password learn with an actual TDM, but its actually just initiating a learn with your little spoofer module.

Probably easier to setup a TDM on the bench, then you dont have to spoof a whole bunch of messages, let the existing factory TDM do all the work, and just eavesdrop on it while it learns.

 

[THEFERMANATOR]

One could also set G0302 and G0304 lower, then you would have virtually no wait for it to learn a new pass code for the theft learn.

 

[henery97]

You could either set it up on the bench with an actual TDM and ECM, and then it will do the relearn normally, and you can just spy on the bus and get the password.

OR

Watch the bus and copy the entire string of messages that the ECM and TDM go through to learn a password. Then send that whole string of messages out so the ECM thinks its initiating password learn with an actual TDM, but its actually just initiating a learn with your little spoofer module.

Probably easier to setup a TDM on the bench, then you dont have to spoof a whole bunch of messages, let the existing factory TDM do all the work, and just eavesdrop on it while it learns.

I dont have the TDM/BCM but it would be faster/easier/better to just grab a TDM & BCM and make up a bench harness.

Also, would it be better to spoof the ECM into thinking ALL of the main modules are alive & well instead of letting it send fault codes when a module doesn't appear on the heartbeat? Im just thinking it would be easier to interrupt what I would be watching if the bus wasn't full of fault codes because the network is missing most of its nodes. But that would probably require a canB for each module that I would be eliminating, unless the heartbeat messages dont need to be synchronized. Does the ecm just receive a message within xx time and it is happy?

 

[henery97]

One could also set G0302 and G0304 lower, then you would have virtually no wait for it to learn a new pass code for the theft learn.

Its not the time that would be the issue, it is knowing what kind of information the ecm needs to see from the tdm to initiate the relearn process, without a tdm this would probably be impossible?? You would need to have it setup and just spy on it as it relearned so you could see the password, then eliminate the tdm.

 

[clrussell]

I'm over here mind blown and you guys are getting a chub..

Glad someone knows this stuff! It's gibberish to me mostly.


Sent from my iPhone using Tapatalk