JEEP HACKING CAN-C / CAN-IHS / UDS ! (Reverse Engineering)

[jmccorm]

FYI for anyone similarly situated: JScan does not report any information from the drivetrain module on the 2.0 Turbo. (I've been eager to get my hands on some turbo parameters such as spooled RPMs and wastegate duty-cycles.) I reported this to the author who acknowledged the situation.

His reply was: "Yes, you are right. This is our error. We are working on app update. Please be patient update should be available soon."

Sponsored

 

[Temperance]

also, looks like I found most of the can data around the sway bar and lockers...

0x26F 00 40 FF FF FF 7F 7F 7F Sway Bar Request - unlock / lock toggle - need to test this.
0x371 51 02 00 00 00 00 00 00 sway bar unlock in progress
0x371 70 01 00 00 00 00 00 00 sway bar unlocked
0x371 42 02 00 00 00 00 00 00 sway bar lock in progress
0x371 61 00 00 00 00 00 00 00 sway bar locked

Thank you!

My hope is that I can use those messages without enabling the sway bar. Here's to hoping...

0x2C2 14 B3 78 00 Locker unlocked
0x25D 23 FC 00 00 7F 7F 7F 7F Rear Locker Request
0x2C2 14 B3 77 00 Locker (s) locked , not sure if this designates rear only or any
0x25D 13 FC 00 00 7F 7F 7F 7F Front + Rear Locker Request
0x277 ??? this seems related to locker operation, but I can't correlate the changes yet.
0x25D 43 FC 00 00 7F 7F 7F 7F Unlock both request

I have not found the front locker status yet, or the correct front / rear locker status yet. need more seat time with cansniffer.

The front and rear differential report their status separately. I don't know if it's in the same message or not, but there is locked and unlocked status. I don't personally need this information. I added an ARB air locker to the front axle on a Mojave which is activated by using a Rubicon off road panel switch. However, I developed an electronic module that spoofs the locker hall sensor status according to air pressure at the axle. It also turns the compressor on and activates the locker solenoid.

 

[jmccorm]

NOTE: IF SOMEONE COULD HELP ME FIGURE OUT HOW TO DECODE CABIN TEMPERATURE (TYPE: REAL48) USING SHELL SCRIPT, I'D APPRECIATE IT. THE VALUE IS: $FF 90 74 AC 00 34​

Cabin Temperature (+17.0xxx or +18.0xxx or a little more C)

  can0  783   [8]  03 22 D0 1E 00 00 00 00
  can0  503   [8]  10 09 62 D0 1E FF 90 74  [Real48 Value TBD]
  can0  783   [8]  30 00 01 00 00 00 00 00
  can0  503   [8]  21 AC 00 34 00 00 00 00
  can0  783   [8]  03 22 D0 1E 00 00 00 00
  can0  503   [8]  10 09 62 D0 1E FF 90 74
  can0  783   [8]  30 00 01 00 00 00 00 00
  can0  503   [8]  21 AC 00 34 00 00 00 00

I figured it out! When I asked for Cabin Temperature, I thought it was replying back with a six byte value:

can0 503 [8] 10 09 62 D0 1E FF 90 74
can0 503 [8] 21 AC 00 34 00 00 00 00

So I thought THOSE six values represented the temperature, and as a floating point number (instead of an integer). The only floating point ("real") format I was aware of was Real48. But all those assumptions were wrong. Instead, here's what was going on:

can0 503 [8] 10 09 62 D0 1E FF 90 74
can0 503 [8] 21 AC 00 34 00 00 00 00

When asking for a temperature, any one of those six bytes could be the one that we're looking for, but it turns out that the byte we're interested in is the one which holds the value $74. The hexadecimal number $74 is equal to the decimal number #116.

But our cabin temperature couldn't have been 116 degrees warm. What you also have to know is that you need to subtract #54 from the number to arrive at the true temperature in degrees F. (This formula appears to hold true when measuring other things, such as the temperature of the steering wheel.)

So to complete the math:
$74 converts to #116 , and #116 - #54 = 62
The cabin temperature was 62 degrees fahrenheit.

TODO: I'll see if I can't make a function which automatically sends the UDS query and returns the result as standard output.

 

[jmccorm]

YAY! More progress towards my AUTO-HVAC plug-in for the Wrangler.

BACKGROUND: By default, when a Wrangler is remotely started, it will not cool the cabin and it is very restricted by how much heating it will do (if any at all). The aim of this device is to allow a remotely started vehicle to have a cozy owner-defined environment after a remote start, and then to normalize HVAC controls once the driver enters the vehicle. For this device to function properly, a lot of little pieces have to fall into place. This is yet another piece in that journey.​

Below we have a Linux shell script called cabintemp. It prints the current cabin temperature. The output seems accurate and up-to-date. It is not known if there are any dependencies (such as an 8.4" uConnect radio) or if this variable is avalble on all models. It is also not known if there might be some global variable which would change the units from Fahrenheit to Celsius.

If it doesn't work for you, please let me know. (Also try running it a second time to see if the second attempt was successful where the first one wasn't.)

#!/bin/bash

error() {
  echo "N/A"
  # Exit with a failure result code
  exit 1
}

# Just in case the CAN bus is asleep, wake it up with a fake button press.

cansend can0 2D3#0700000000000000 ; sleep 0.5

# 1/10th of a second from now, send the UDS query for Cabin Temperature
# NOTE: It currently responds with cabin temperature in Fahrenheit. It is
#       not known if there is a switch which might also make it output
#       instead of Celsius.

( sleep 0.1 ; cansend can0 783#0322D01E00000000 ) &

# Collect any messages on CAN-IHS which have an ID of 0503.
# After 0.5 seconds, stop collecting.

COMMAND="timeout -s 1 0.6 /usr/bin/candump -L can0,0503:0FFF"

# Only look for messages which are a successful response to our
# UDS query. If we received more than one response, only use
# the last one. And isolate the output so it only contains the
# byte that we're looking for.

RESPONSE=$( $COMMAND | grep \#100962D01E | cut -d# -f2 | cut -c15-16 | tail -1 )

# If no response was found, exit gracefully with an error.

if [ "$RESPONSE" == "" ] ; then error; fi

# Convert out byte from hexadecimal to decimal.

RESPONSE=$( printf "%d" 0x$RESPONSE )

# Subtract 54 (an arbitrary magic number) from the response so that we have
# an accurate reading which can range from -54 to 201 degrees Fahrenheit.

RESPONSE=$( expr $RESPONSE - 54 )

# Print the temperature to standard output.

echo ${RESPONSE}F

 

[redracer]

YAY! More progress towards my AUTO-HVAC plug-in for the Wrangler.

BACKGROUND: By default, when a Wrangler is remotely started, it will not cool the cabin and it is very restricted by how much heating it will do (if any at all). The aim of this device is to allow a remotely started vehicle to have a cozy owner-defined environment after a remote start, and then to normalize HVAC controls once the driver enters the vehicle. For this device to function properly, a lot of little pieces have to fall into place. This is yet another piece in that journey.​

Below we have a Linux shell script called cabintemp. It prints the current cabin temperature. The output seems accurate and up-to-date. It is not known if there are any dependencies (such as an 8.4" uConnect radio) or if this variable is avalble on all models. It is also not known if there might be some global variable which would change the units from Fahrenheit to Celsius.

If it doesn't work for you, please let me know. (Also try running it a second time to see if the second attempt was successful where the first one wasn't.)

#!/bin/bash

error() {
  echo "N/A"
  # Exit with a failure result code
  exit 1
}

# Just in case the CAN bus is asleep, wake it up with a fake button press.

cansend can0 2D3#0700000000000000 ; sleep 0.5

# 1/10th of a second from now, send the UDS query for Cabin Temperature
# NOTE: It currently responds with cabin temperature in Fahrenheit. It is
#       not known if there is a switch which might also make it output
#       instead of Celsius.

( sleep 0.1 ; cansend can0 783#0322D01E00000000 ) &

# Collect any messages on CAN-IHS which have an ID of 0503.
# After 0.5 seconds, stop collecting.

COMMAND="timeout -s 1 0.6 /usr/bin/candump -L can0,0503:0FFF"

# Only look for messages which are a successful response to our
# UDS query. If we received more than one response, only use
# the last one. And isolate the output so it only contains the
# byte that we're looking for.

RESPONSE=$( $COMMAND | grep \#100962D01E | cut -d# -f2 | cut -c15-16 | tail -1 )

# If no response was found, exit gracefully with an error.

if [ "$RESPONSE" == "" ] ; then error; fi

# Convert out byte from hexadecimal to decimal.

RESPONSE=$( printf "%d" 0x$RESPONSE )

# Subtract 54 (an arbitrary magic number) from the response so that we have
# an accurate reading which can range from -54 to 201 degrees Fahrenheit.

RESPONSE=$( expr $RESPONSE - 54 )

# Print the temperature to standard output.

echo ${RESPONSE}F

I just ran this. it looks like the first reply was not accurate, but after that it looks good!

pi@pican:~ $ ./cabintemp.sh


27F


pi@pican:~ $ ./cabintemp.sh


52F


pi@pican:~ $ ./cabintemp.sh


52F


pi@pican:~ $ ./cabintemp.sh


52F

 

[jmccorm]

I just ran this. it looks like the first reply was not accurate, but after that it looks good!

Perfect, that's just what I needed!

For my own code, I'm probably going to work around it by not reading the cabin temperature when the vehicle is asleep. But let's try this: change "sleep 0.5" to "sleep 1". I figure that the vehicle just needs a little bit more time to read those thermistors correctly.

 

[redracer]

and, after letting it sleep a bit more, i get 27f again for the first response.

 

[redracer]

ugh, i wrote this before i saw your reply. I'll wait a while for the modules to go to sleep again then try again with a longer sleep after wakeup.

 

[jmccorm]

No problem. Also, do you have heating seats/steering? Either way, let me know. Can you try out my wheeltemp script? The last script ran on the CAN-IHS bus. This one runs on the CAN-C bus, and talks to a different module address (and looks for a different byte). But the principal is the same.

I need to create a more generalized script to handle these, but for now, here's what I got for pulling the steering wheel temperature:

#!/bin/bash

error() {
  echo "N/A"
  # Exit with a failure result code
  exit 1
}

# Just in case the CAN bus is asleep, wake it up with a fake button press.

cansend can1 2D3#0700000000000000 ; sleep 1.0

# 1/10th of a second from now, send the UDS query for Cabin Temperature
# NOTE: It currently responds with cabin temperature in Fahrenheit. It is
#       not known if there is a switch which might also make it output
#       instead of Celsius.

( sleep 0.1 ; cansend can1 620#0322A01000000000 ) &

# Collect any messages on CAN-IHS which have an ID of 0504.
# After 0.5 seconds, stop collecting.

COMMAND="timeout -s 1 0.6 /usr/bin/candump -L can1,0504:0FFF"

# Only look for messages which are a successful response to our
# UDS query. If we received more than one response, only use
# the last one. And isolate the output so it only contains the
# byte that we're looking for.

RESPONSE=$( $COMMAND | grep \#100A62A010 | cut -d# -f2 | cut -c11-12 | tail -1)

# If no response was found, exit gracefully with an error.

if [ "$RESPONSE" == "" ] ; then error; fi

# Convert out byte from hexadecimal to decimal.

RESPONSE=$( printf "%d" 0x$RESPONSE )

# Subtract 54 (an arbitrary magic number) from the response so that we have
# an accurate reading which can range from -54 to 201 degrees Fahrenheit.
RESPONSE=$( expr $RESPONSE - 54 )

# Print the temperature to standard output.
echo ${RESPONSE}F

 

[redracer]

Okay. cabintemp gave a good first answer after a 1s sleep change.

as for wheeltemp, it's reporting 107F haha.

 

[LooselyHeldPlans]

@SmartStopStart.com
Do you know if the parameters of ESS are able to be configured? I keep ESS turned off because I hate when it only stays stopped for a few seconds. Instead, if an ESS event could be triggered only after a hard break press, I might be more open to using the system.

 

[Temperance]

also, looks like I found most of the can data around the sway bar and lockers...

0x26F 00 40 FF FF FF 7F 7F 7F Sway Bar Request - unlock / lock toggle - need to test this.
0x371 51 02 00 00 00 00 00 00 sway bar unlock in progress
0x371 70 01 00 00 00 00 00 00 sway bar unlocked
0x371 42 02 00 00 00 00 00 00 sway bar lock in progress
0x371 61 00 00 00 00 00 00 00 sway bar locked

Does anyone know how often TPMS information is put on the CAN C bus? Is this information updated when the vehicle is not moving? My ultimate goal is to use the sway bar button to turn on and off the on board air compressor; which is pretty useful. But what would be really useful is if one button press turns on the compressor and shuts it off when a tire is at pressure. I fill all 4 tires at the same time so this could be very useful (yes I know there are kits out there already). Two button presses will turn the compressor on. A final press will turn it off. Mode indication can be displayed using the 4 states to the sway bar button led: off, on, slow blink, and fast blink.

 

[jmccorm]

@SmartStopStart.com
Do you know if the parameters of ESS are able to be configured? I keep ESS turned off because I hate when it only stays stopped for a few seconds. Instead, if an ESS event could be triggered only after a hard break press, I might be more open to using the system.

I don't see an ESS module, which would have been awesome. I do see a bunch of qualifications for ESS under the Powertrain Control Module, but those are all pass/fail kind of switches. No tuneable values. (One value for the number of seconds which ESS has been active.)

I share your grief in that I have to keep my foot firmly planted on the brakes for ESS not to turn the engine back on prematurely. But if there are any variables which control at what level that happens, I'm not seeing it. It could be that it isn't exposed. Or it could be that it's out there, just it doesn't have a nice human-readable label attached to it.

There doesn't seem to be any easy answers here.

 

[jmccorm]

Does anyone know how often TPMS information is put on the CAN C bus? Is this information updated when the vehicle is not moving? My ultimate goal is to use the sway bar button to turn on and off the on board air compressor; which is pretty useful.

Sorry, Temperance. At least, using the methods I'm using over here, I don't think I'll be finding TPMS data anytime soon.

If you're looking to hunt that down, there really only seems to be one of two ways. The first would be ACTIVELY experimenting with tire pressures and looking for CAN messages which change in response to it. (That would be ideal.) The other would be to use JScan to look through the various modules to see if they've got Live Data on any of the various TPMS parameters. (That would then require you to poll with UDS on a regular basis to pull the data you want.)

I have to admit, you've got some interesting things going on over there!

PS: I share your observation that in ordinary day-to-day use, the tire pressures only seem to update while you're driving the vehicle. *HOWEVER* if you use the tire fill feature that's built into the Tazer (upgrade your Tazer firmware if necessary), it is able to do immediate pressure reads while the vehicle is stationary. So that's probably an idea candidate to reverse-engineer the traffic from! If not, then the Selectable Tire Fill Alert app which some Wrangler models do and don't have.

 

[SmartStopStart.com]

@SmartStopStart.com
Do you know if the parameters of ESS are able to be configured? I keep ESS turned off because I hate when it only stays stopped for a few seconds. Instead, if an ESS event could be triggered only after a hard break press, I might be more open to using the system.

Brake pedal pressure is definitely detected by the system. I do not know though if that data is available over CAN or in any way accessible though I expect it would be. It would be great if the parameters were programmable, but even if not, they probably can be spoofed.

Sponsored