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

[jmccorm]

"My Jeep would be just perfect if only it would..."
This project started because I've said that to myself. Too many times.

PROJECT DESCRIPTION:

This project aims to reverse engineer the Wrangler's CAN bus and use that information to addresses numerous quality-of-life issues that can be solved "if only the Jeep's computer acted just a little bit differently" and to make mods that up until now have not been possible.

This thread is a continuation from redracer's original inspiration thread and my own project discussion here. This serves as a place for like minded individuals to reverse engineer CAN bus messages (and UDS functions), to seek guidance on related issues, and to put that knowledge to work.

It's been over four months since we started connecting to our own vehicle's CAN networks using a Raspberry Pi with a Waveshare 2-Channel CAN adapter. (Arduinos are welcome, too!) Since that time, we've found a low-cost source for Jeep's official CAN connectors.

We've decoded quite a number of CAN messages and started to get our feet wet in the world of Unified Diagnostic Services. We've managed to create tools including: a black box data recorder, a remote keyfob WiFi toggle, an automatic climate control for remote start, and more.

image of CAN-C and CAN-IHS bus connections (located behind the glovebox)​

Looking for tips to get started?
If you have questions, ASK! We're friendly!

If you're not yet ready to hook up your vehicle, but you'd like to simulate the real thing, @Drdyer9051 lists the steps necessary to configure a virtual CAN interface on a Raspberry Pi and play back authentic messages from one of our recorded CAN bus log files.

For those who are ready to connect their vehicle to a Raspberry Pi, this message offers tips on how to initialize your 2-channel Waveshare CAN adapter as well as a general introduction to working with the Wrangler's CAN-IHS and CAN-C bus.

We maintain an online spreadsheet with information on all the CAN bus messages that we've decoded, and you're welcome to access it. All that we ask, in return, is that you share anything new you might discover along the way. Sounds fair?

Third party contributions are welcome as long as your vehicle uses the same modern Chrysler/Dodge/Fiat/Jeep ECU with similar messages and message IDs.

TO VIEW OR DOWNLOAD THE SPREADSHEET:

2018+ Jeep Wrangler "JL"
CAN-C and CAN-IHS Message ID.xls

TO VIEW OR DOWNLOAD RASPBERRY PI CODE SAMPLES, VISIT OUR GITHUB REPOSITORY:

rstellhorn / jeep-jl-powernet-scripts
with special thanks to redracer, repository maintainer
​

All code samples assume that can0 is connected to the vehicle's CAN-IHS network, and can1 is connected to the vehicle CAN-C network. Use at your own risk, no promises or guarantees are given.

Have a question?
Feel free to jump right in and ask! We'll do our best to help you.

LAST UPDATED: March 20th, 2023

Sponsored

 

[jmccorm]

Equipment:
Rapsberry Pi 2 with 2-Channel CAN HAT.
Powered via USB-C media connector.
HDMI monitor powered through rear-seat 110VAC outlet.
Keyboard.

What happened:
I opened the glove box and attempted to plug my FCA CAN connection into the IHS bus (Interior High Speed CAN bus). The connection just wouldn't go into place! I realized that FCA might have used different connectors for the IHS bus and the Body bus, so I tried to plug my connector into one of the Body slots. That wasn't the plan, but it worked perfectly! (I've got an IHS connector on order.)

I issued a few command-line directives to configure my CAN bus for the higher speed body CAN bus connection, and in listen-only mode:

# ip link set can0 up type can bitrate 500000 listen-only on
# ifconfig can0 txqueuelen 65536
# ifconfig can1 txqueuelen 65536

Then I went back inside. From my desktop PC, I logged into the raspberry Pi and checked to see if I could see any traffic.

# candump -tA -a -c -d -e -x any

Nothing. CRAP!

I was probably doing something wrong... but where? And then it hit me. I connected to the body instead of the interior bus as I had planned. The vehicle wasn't running, and it need to be. So I hit my keyfob's remote start, and wow, traffic started to fly!

(09:28:23.700004) can0 RX - - 023 [8] 10 05 10 00 00 00 C4 5F '......._'
(09:28:23.700125) can0 RX - - 077 [2] 44 21 'D!'
(09:28:23.700739) can0 RX - - 0B5 [8] 00 00 04 1C 00 00 00 00 '........'
(09:28:23.701732) can0 RX - - 027 [8] 89 DE 07 F0 00 00 E2 0E '........'
(09:28:23.701982) can0 RX - - 128 [8] 00 3B 38 6D 00 F6 06 41 '.;8m...A'
(09:28:23.703070) can0 RX - - 02F [8] 00 00 00 00 01 1C 7D 00 '......}.'
(09:28:23.703320) can0 RX - - 087 [8] 00 01 00 00 00 6A D0 E9 '.....j..'
(09:28:23.703563) can0 RX - - 089 [8] 80 07 80 6D 80 81 D0 81 '...m....'
(09:28:23.703811) can0 RX - - 08B [8] 00 00 00 00 00 00 00 00 '........'
(09:28:23.704047) can0 RX - - 0A7 [8] 00 00 00 9D 40 9A D0 72 '[email protected]'
(09:28:23.704697) can0 RX - - 0B1 [3] 00 80 98 '...'
(09:28:23.706531) can0 RX - - 037 [8] 1F FE 00 00 10 68 F0 02 '.....h..'
(09:28:23.707541) can0 RX - - 0AB [8] 00 00 0D 0D 00 00 F0 92 '........'
(09:28:23.707797) can0 RX - - 035 [8] 07 D4 07 CC 00 46 F3 1A '.....F..'
(09:28:23.708200) can0 RX - - 02B [8] 08 08 07 F1 08 03 F0 2D '.......-'
(09:28:23.708574) can0 RX - - 0B3 [8] 00 00 00 00 04 00 F0 73 '.......s'
(09:28:23.708802) can0 RX - - 07B [7] C7 D4 00 08 70 80 2F '....p./'
(09:28:23.709047) can0 RX - - 08D [8] C6 C0 FF FF FF FF FF FF '........'

(Hopefully that's nothing unique to my vehicle that I'll need to sanitize later.)

It looks like I'm getting live data and everything is good. I wanted the interior bus but I'll have to experiment (read-only) and try to sift out what's what on the body's CAN bus. Redracer has already provided some clues which I can start with, which is awesome.

That data which I captured above? It was less than 1/100th of a second long. There's a mountain of information to pour through. But at least I'm off to the races!

 

[nsfw_andy]

check out this guys video series, lots of good info here, especially on filtering data easily.



once I get my 2022 Jeep delivered in a few months (hopefully), I’ll join you down this rabbit hole

 

[jmccorm]

once I get my 2022 Jeep delivered in a few months (hopefully), I’ll join you down this rabbit hole

Awesome! I'll be happy to have more eyes to find things and share with! I'm watching the video now. (He put a lot of time into that, didn't he?)

A few minor discoveries made while I'm learning the ropes:
3E0 - A repeating multipart message with Vehicle VIN
328 - Used to display song title/artist/input source on the EVIC
07F - Unsigned bytes which seem to increase with movement from each of the four wheels (and sticks an FF in one field when a few feet of movement has been made)

For 07F, I was actually looking for the TILT/ROLL sensor and I finally was able to make sense of what I was seeing. There's plenty more waiting to be discovered!

EDIT: I'm obviously seeing some Interior CAN messages mixed in here.

 

[jmccorm]

Let me dive into one of these in more detail...

Earlier, I identified 328 as the CAN ID to display text on the EVIC display's radio menu (artist name, song title, input source). The bottom line (input source) is also what the Tazer JL uses to display its menu choices on your display.

Here are enough specifics to display anything you want for all three lines.

EVIC DISPLAY OF SONG NAME
328 LINE CODES:              +-> 2=Artist, 3=Song Title,
                             |   1=Radio Input Name
      4=Start of new line---+|
Lines remaining----------+  ||
                         |  ||
can0  RX - -  328   [8]  30 42 00 42 00 6C 00 75   '0B.B.l.u' <--Artist
can0  RX - -  328   [8]  20 02 00 65 00 46 00 6F   ' ..e.F.o'
can0  RX - -  328   [8]  10 02 00 78 00 4D 00 75   '...x.M.u'
can0  RX - -  328   [8]  00 02 00 73 00 69 00 63   '...s.i.c'
can0  RX - -  328   [8]  00 00 00 00 00 00 00 00   '........' <--END OF MESSAGE

can0  RX - -  328   [8]  50 43 00 45 00 6C 00 65   'PC.E.l.e' <--Song Title
can0  RX - -  328   [8]  40 03 00 63 00 74 00 72   '@..c.t.r'
can0  RX - -  328   [8]  30 03 00 6F 00 20 00 50   '0..o. .P'
can0  RX - -  328   [8]  20 03 00 65 00 72 00 66   ' ..e.r.f'
can0  RX - -  328   [8]  10 03 00 65 00 63 00 74   '...e.c.t' <--TOO MANY CHARS
can0  RX - -  328   [8]  00 03 00 6F 00 00 00 00   '...o....' <--WILL NOT SHOW
can0  RX - -  328   [8]  00 00 00 00 00 00 00 00   '........' <--END OF MESSAGE

    Always transmit 8 bytes. Use "00" for any unused characters.

<--- SCROLL LEFT AND RIGHT IF NEEDED --->​

For a programmer, this will be pretty much self-explanatory. Using CAN ID 328, you must always transmit 8 bytes at a time. Follow the format shown above.

Each display character is two bytes long (with the high byte as 00 for standard ASCII characters). If a field has too many characters, the EVIC display will accept the message but truncate the extra characters on the display with "..." at the end.

Top line is artist, then song title, then below the logo (in the center of the screen) is name of the input type (bluetooth, fm radio, etc). A message must be terminated with a message of all zeros.

This should be enough information to display a message on the EVIC display (when the radio screen is selected). But this has not yet been real-world tested.

MATCHING EVIC DISPLAY FOR CAN CODES​

EDIT: Replaced an image.

 

[jmccorm]

I stumbled across something that I wanted to make note of...

I ran 'canbusload can0@500000' and saw that the vehicle's main CAN-C network was constantly 58% - 59% saturated while the engine was running idle. That's very saturated! Jeep might be getting away with it by carefully timing the order in which modules communicate on the bus... but that's speculation.

At first I wanted to blame one of those SGW (Secure Gateway) bypass/replacement devices for the excess traffic, but I did my homework and plugged the vehicle's own SGW module back into place and re-ran the test. The saturation level remained the same!

What does this mean? When you've used a product like Jscan or the Tazer JL Mini, you may have noticed that commands sometimes have problems taking effect, or that they have to be repeated. I think this does a great deal to explain why. Assuming those tools wait until the bus is silent before broadcasting, there is a 58% chance that any operation will collide with another message on the vehicle's main bus.

Just an interesting fact that I wanted to share along the way.

 

[beaups]

What does this mean? When you've used a product like Jscan or the Tazer JL Mini, you may have noticed that commands sometimes have problems taking effect, or that they have to be repeated. I think this does a great deal to explain why. Assuming those tools wait until the bus is silent before broadcasting, there is a 58% chance that any operation will collide with another message on the vehicle's main bus.

Just an interesting fact that I wanted to share along the way.

That load is perfectly common and acceptable. The missed inputs on Tazer and the like aren't related to bus saturation but just the fact that they are racing with the frequency of "correct messages" that the affected modules are broadcasting and receiving. For instance, if the radio is broadcasting what should display on your EVIC 10x/sec the tazer might need to do it 100x/sec to "win". Same goes for the steering wheel controls etc. It's not any indication of bus saturation.

 

[jmccorm]

The missed inputs on Tazer and the like aren't related to bus saturation but just the fact that they are racing with the frequency of "correct messages" that the affected modules are broadcasting and receiving. For instance, if the radio is broadcasting what should display on your EVIC 10x/sec the tazer might need to do it 100x/sec to "win". Same goes for the steering wheel controls etc. It's not any indication of bus saturation.

I hate to be argumentative, but you described the exact effects of what you would see if there was excessive saturation in a collision-oriented broadcast network. That, and the use of a tool designed to measure saturation on CAN networks reported its level at 58%... which in ordinary circumstances would be at a high level. As it turns out, this is a topic I've had some involvement with. In another life, I ran the technical operations of a regional Internet Service Provider.

Now, this isn't saying that Jscan or Tazer are bad. Quite the contrary. What I am saying is that these are the headwinds faced as "an outsider" when performing operations on the CAN-C bus. (Headwinds that I too will have to face.) This was intended more as a pulling back of the curtains to explain why people see some of the behavior they do in their existing tools.

* - I currently suspect that 58% saturation isn't a problem for the Jeep's own modules because they're carefully timing their responses to avoid stomping on each other. This behavior would be outside the defined behavior of the CAN protocol, but it's also not disallowed.

PS: We both may be saying the same things, but in different ways.

 

[jmccorm]

Here's a big gift for someone just starting to get their feet wet. (If visiting this a year later, hopefully we're well past this point.) This contains my findings AND GUESSES so far. PLEASE CONSIDER THIS INFORMATION UNRELIABLE AND NEEDING TO BE VERIFIED, AND REFINED.

Some text (below) may be too wide, requiring you to scroll left-and-right or to enlarge your window.

Refinements and additions are totally welcome!

# Modules ON THE CAN-C BUS (PER SYSTEMS DIAGRAM)
================================================
Secure Gateway, Radio, Emergency Assistance, Occupant Restraint Controller,
Power Steering Pump, Instrument Cluster, Powertrain Control,
Steering Column Control, Anti-lock Brakes, Transmission Control,
Body Control, Tire Pressure Monitoring System, Radio Frequency Hub,
Automatic Sway Bar, Electronic Shift, Steering Column Lock,
Exhaust Temperature, Occupant Classification System, Drivetrain Control,
Driver Detection, Star CAN-C Body Hub, Star CAN-C IP Hub, Diagnostic OBD2 Port

Optional Safety System: Park Assist
Optional Export:        Headlamp Leveling System
Optional Diesel:        Diesel Powertrain Control Unit
Optional eTorque:       Battery Pack Control, Motor Generator Unit,
                        eTorque Powertrain Control Unit

#MODULES ON THE IHS BUS (PER SYSTEMS DIAGRAM)
=============================================
Secure Gateway, Body Control Module, HVAC Module,
Integrated Center Stack Switch Bank Module, Lamp Assembly Tail (Left),
Lamp Assembly Tail (Right), Radio Module, Emergency Assistance Module,
Radio Amplifier, Comfort Seat Steering Wheel, Star CAN-IHS IP Hub,
Star CAN-IHS Body Hub, Data Link Connector 1

Optional Sky One Touch: Power Top Module
Optional Export:        Intrusion Transciever Module


#ITEMS ON A PRIVATE BUS (PER SYSTEMS DIAGRAM)
=============================================
Electronic Shift Module to:
    Transmission Control Module

Powertrain Control Module to:
    Sensor NOX (1 of 2)
    Sensor NOX (2 of 2)
    Sensor Particulate Matter

#JSCAN uses these IDs for some interior control bitmaps
504? 620?

#TURN SIGNAL
318 TURN SIGNAL STALK
291 TURN SIGNAL SWITCH / FOG SWITCH / headlight knob in off position
    (LIGHTS CAN ACTIVATE WITHOUT THESE VALUES, NOT RELAYS)

#COMMAND: TURN PARKING LIGHT OFF (unverified)
291#00.46.2B.00.00.28.00.00
   SOURCE: https://www.jlwranglerforums.com/forum/threads/canbus-codes.36782/

#DRIVER DOOR STATUS?
09B

#SWAY BAR DISCONNECT?
4CA

#TAZER LIGHTSHOW IN PROGRESS
4C2 FIRST 5 BYTES
504
620
742 - NOT SEEN ELSEWHERE

# CLEARING DTCs - POSSIBLY ENUMERATES EACH CONTROL MODULE
# Might use Tazer, JScan or another tool to see which ID is what module.
4C0, 4C7, 4C9, 4CB, 504, 620, 740, 743, 747, 749, 74B, 762,
7DF, 7E0, 7E1 and possibly with a different use: 7E8, 7E9

#STEERING WHEEL POSITION
023 Starting with 10 00 is dead center
    Additional bytes for... force applied? Resistance? Motor strain?

#GAS PEDAL
081 and 09D -- contained in a byte
               its inverse value is mirrored in several different locations.

#POWER USED? BITS CHANGE UPON PRESSING AUX BUTTONS OR USING HEADLIGHTS
                                       OR WIPERS
13F

#BRAKE
087 then 028, 079, 09B 093 083 127 12B Various bits
407 ACTIVATION IN THE BITMAP? 3rd light?

#EVIC DISPLAY OF SONG NAME
328 LINE CODES:              +-> 2=Artist, 3=Song Title,
                             |   1=Radio Input Name
      4=Start of new line---+|
Lines remaining----------+  ||
                         |  ||
can0  RX - -  328   [8]  30 42 00 42 00 6C 00 75   '0B.B.l.u' <--Artist
can0  RX - -  328   [8]  20 02 00 65 00 46 00 6F   ' ..e.F.o'
can0  RX - -  328   [8]  10 02 00 78 00 4D 00 75   '...x.M.u'
can0  RX - -  328   [8]  00 02 00 73 00 69 00 63   '...s.i.c'
can0  RX - -  328   [8]  00 00 00 00 00 00 00 00   '........' <--END OF MESSAGE

can0  RX - -  328   [8]  50 43 00 45 00 6C 00 65   'PC.E.l.e' <--Song Title
can0  RX - -  328   [8]  40 03 00 63 00 74 00 72   '@..c.t.r'
can0  RX - -  328   [8]  30 03 00 6F 00 20 00 50   '0..o. .P'
can0  RX - -  328   [8]  20 03 00 65 00 72 00 66   ' ..e.r.f'
can0  RX - -  328   [8]  10 03 00 65 00 63 00 74   '...e.c.t' <--TOO MANY CHARS
can0  RX - -  328   [8]  00 03 00 6F 00 00 00 00   '...o....' <--WILL NOT SHOW
can0  RX - -  328   [8]  00 00 00 00 00 00 00 00   '........' <--END OF MESSAGE

    Always transmit 8 bytes. Use "00" for any unused characters.

#MUTE AUDIO ACTIVE (but does not track MUTE BUTTON)?
25D

#STEERING WHEEL BUTTONS -- LEFT/RIGHT/UP/DOWN/OK (ON LEFT):
22D

#STEERING WHEEL BUTTONS -- CRUISE CONTROL:
0B1 - Highest byte (next two are counters)

#FOUR WHEEL TRAVEL (UNSIGNED)
#All four wheels get their own byte which increments with any wheel movement.
#Will increment regardless of if the movement is forward or backwards.
#After about five feet of movement, an FF flag is created in another byte.
07F

#ACCELEROMETER? PITCH/ROLL? (SEAT PRESSURE?)
02B 089

#VEHICLE VIN (MULTIPART) -- NULL TERMINATED
#My own VIN has been replaced with the valid ID for a 2020 Rubicon.
#These three messages constantly repeat themselves over and over.
#Each line is almost exactly 0.1 seconds apart every time.
(1636391583.192313)  can0  RX - -  3E0   [8]  00 31 43 34 48 4A 58 46   '.1C4HJXF'
(1636391583.292118)  can0  RX - -  3E0   [8]  01 4E 36 4D 57 37 35 36   '.N9LW246'
(1636391583.392040)  can0  RX - -  3E0   [8]  02 35 33 30 00 00 00 00   '.350....'

#HVAC FAN SPEED AND TEMPERATURE (source for some: redracer):
332 - SENSING OF _ACTUAL CURRENT FAN SPEED_ IN 6th BYTE
2B1 - FAN KNOB/AUTO in first byte, others SWITCHING A/C BAFFLES FOR HOT/COLD
2b1#01 - 07 hvac fan speed status
2b1#00.00.?? Temperature status

#BUTTONS (source: redracer):
230#?? 01 ac off 03 ac on 07 defrost 00 all off status
22d#00.00.00.??.?? 10 00 left arrow, 00 01 right arrow, 40 00 down, 00 04 up
318 ?? : 01 left blinker stalk, 02 right, 08 moment high beam, 04 hold high beam, 10 wipers moment,


#REMOTE LOCK / UNLOCK:
1C8 1C0 291... unclear if 02B and 07B involved.

#SHUTDOWN INVOLVED:
401 402

#COUNTERS (NOTE: Some counters also seem to store important
#                information. Perhaps as a timestamp for those events?)
023
02F
071
079   [8]  80 00 00 00 00 00 60 3F   '......`?' Lowest two bytes incrementing
079   [8]  80 00 0F FF 00 00 70 28   '......p(' Unknown meaning of 0F FF
083   [8]  80 04 00 00 00 00 10 63   '.......c' COUNTER
083   [8]  80 04 00 00 00 00 20 29   '...... )'
087   [8]  00 02 00 00 00 6E 40 E5   '.....n@.' COUNTER
087   [8]  00 02 00 00 00 6E 50 28   '.....nP('
087   [8]  07 FF 00 00 00 6E 60 69   '.....n`i'
089   [8]  FF FF FF 6D FF FF E0 FF   '...m....' COUNTER
089   [8]  FF FF FF 6D FF FF F0 FF   '...m....'
089   [8]  FF FF FF 6D FF FF 00 FF   '...m....'
089   [8]  FF FF FF 6D FF FF 10 FF   '...m....'
0A7
0AD
0B1


#General OBD-II PIDs:
#SOURCE: http://obdcon.sourceforge.net/2010/06/obd-ii-pids/
===========================================================
$01 = Show current data

                Bytes                                   Min     Max
Mode    PID     returnd Description                     value   value   Units   Formula (in decimal)
01      00      4       PIDs supported [01 - 20]                                Bit encoded [A7..D0] == [PID 0x01..PID 0x20]

01      01      4       Monitor status since DTCs cleared.                      (Includes malfunction indicator lamp (MIL) status
                                                                                and number of DTCs.) Bit encoded. See below.
01      02      8       Freeze DTC
01      03      2       Fuel system status                                      Bit encoded. See below.
01      04      1       Calculated engine load value    0       100     %       A*100/255
01      05      1       Engine coolant temperature      -40     215     °C      A-40

                                                        (RICH)  (LEAN)
01      06      1       Short term fuel % trim—Bank 1   -100    99.22   %       (A-128) * 100/128
01      07      1       Long term fuel % trim—Bank 1    -100    99.22   %       (A-128) * 100/128
01      08      1       Short term fuel % trim—Bank 2   -100    99.22   %       (A-128) * 100/128
01      09      1       Long term fuel % trim—Bank 2    -100    99.22   %       (A-128) * 100/128

                                                                        kPa
01      0A      1       Fuel pressure                   0       765     (gauge) A*3
                                                                        kPa
01      0B      1       Intake manifold abslt pressure  0       255     (abslt) A

01      0C      2       Engine RPM                      0       16383.75 rpm    ((A*256)+B)/4
01      0D      1       Vehicle speed                   0       255     km/h    A

                                                                        ° relative
01      0E      1       Timing advance                  -64     63.5    to #1
                                                                        cylindr A/2 – 64

01      0F      1       Intake air temperature          -40     215     °C      A-40
01      10      2       MAF air flow rate               0       655.35  g/s     ((A*256)+B) / 100
01      11      1       Throttle position               0       100     %       A*100/255
01      0D      1       Vehicle speed                   0       255     km/h    A

                                                                        ° relative
01      0E      1       Timing advance                  -64     63.5    to #1
                                                                        cylindr A/2 – 64

01      0F      1       Intake air temperature          -40     215     °C      A-40
01      10      2       MAF air flow rate               0       655.35  g/s     ((A*256)+B) / 100
01      11      1       Throttle position               0       100     %       A*100/255

    [More data continues, see original document.]

CODE FRAGMENTS FOUND IN OTHER PROJECTS:
=======================================

# Some general Chrysler values found in another project.
#https://github.com/karlyamashita/common_libraries/blob/master/CHRYSLER_CAN_ID.h
#-------------------------------------------------------------------------------

#ifdef CHRYSLER_V5
// MSCAN (IHS)
// Dodge Durango 2017 // // hands free on BOTH front speaker outputs
// Dodge Charger 2016 // hands free only on front RIGHT speaker output
// Jeep Grand Cherokee 2017 // hands free only on front RIGHT speaker output
// Dodge Ram 2017 // hands free only on front RIGHT speaker output

#define POWER_MODE_ID 0x122
#define RADIO_AUDIO_STATUS_ID 0x30F
#define RADIO_PHONE_AUDIO_STATUS_ID 0x30D // Hands free uses seperate volume
#define SWC_TURN_SIGNAL_ID 0x318// SWC BT Command VR and Answer in Dodge Ram Diesle Truck
#define SWC_ID 0x22D // basic audio controls. Dodge Ram SWC ID is 0x318
#define LIGHTING_STATUS_ID 0x3B2
#define DIMMER_DOOR_PARKING_BRAKE_ID 0x2FA
#define BRAKE_GEAR_INFO_ID 0x332
#define RAP_ID 0x12B
#define DASH_BUTTONS_ID 0x2D3
#define AMP_STATUS_ID 0x354
#define VEHICLE_SPEED_ID 0x340 // or 0x322?
#define VIN_ID 0x3E0
#define DASH_BUTTONS_ID 0x2D3
#define VOLUME_TUNE_KNOB_ID 0x273
#define RPM_SPEED_ID 0x322
#define TURN_SIGNALS_SWITCH_ACTIVE_ID 0x2A8

// below for Jeep Cherokee 2015-2017, 52 pin connector
#define POWER_MODE_JEEP_CHEROKEE_ID 0x20B
#define HYDRALIC_BRAKE_JEEP_CHEROKEE_ID 0x5DC
#define GEAR_INFORMATION_JEEP_CHEROKEE_ID 0x190
#define TURN_SIGNAL_JEEP_CHEROKEE_ID 0x4A1
#define DIMMER_JEEP_CHEROKEE_ID 0x5CA
#define LIGHTING_STATUS_JEEP_CHEROKEE_ID 0x337
#define DOOR_STATUS_JEEP_CHEROKEE_ID 0x339
#define RAP_JEEP_CHEROKEE_ID 0x192
#define VIN_JEEP_CHEROKEE_ID 0x3D3
#define VOICE_ANSWER_HANGUP_ID 0x4A3
#define HYDRAULIC_BRAKES_ID 0x5DC
#define DIMMER_ID 0x5CA // 34-200

// Steering Wheel Controls
#define SWC_BUTTON_RELEASE 0x00
#define SWC_LEFT_UP 0x10
#define SWC_LEFT_DOWN 0x20
#define SWC_LEFT_MIDDLE 0x40
#define SWC_RIGHT_UP 0x04
#define SWC_RIGHT_DOWN 0x08
#define SWC_RIGHT_MIDDLE 0x01

//Power Mode
#if defined CHRYSLER_V5 // need to check if this is for CRYSLER_V4 or V3
#define POWER_MODE_OFF 0x00
#define POWER_MODE_ACCESSORY 0x03
#define POWER_MODE_IGNITION 0x04
#define POWER_MODE_CRANK 0x15
#define POWER_MODE_MASK 0x1F

// Gear Information
#define GEAR_PARK 0x0D
#define GEAR_REVERSE 0x0B
#define GEAR_NUETRAL 0x00
#define GEAR_DRIVE 0x01

// 74HCT4052 or FSAV331 switches
#GUESS: Video switchers only for those who have built-in trail camera?
#define NO_VIDEO 0xFF
#define REAR_VIDEO 0
#define FRONT_VIDEO 1
#define LEFT_VIDEO 2
#define RIGHT_VIDEO 3

#JK SCAN DOCUMENT
#These values are completely wrong for us, and it is in OpenDocument
#format. But I think he sets the bar for how we should be documenting these.
https://github.com/BiggRanger/CANBUS-Vehicle-Reverse-Engineering


PERSONAL NOTES FOR USING CAN-BASED COMMANDS ON RASPBIAN:
========================================================
# initialize to 500kbps for CAN-C network listen-only mode
ip link set can0 up type can bitrate 500000 listen-only on
ifconfig can0 txqueuelen 65536
ifconfig can1 txqueuelen 65536
#ip link set can1 up type can bitrate 1000000 dbitrate 8000000 restart-ms 1000 berr-reporting on fd on

#check status of CAN network
ifconfig | more

#listen to any CAN message:
candump any
candump can0
candump -ta -c -a -d -e -x any
candump -ta -c -a -d -e -x can0,087:fff   # ID FILTER:MATCHING BITMAP
candump -ta -c -a -d -e -x can0,ffff:0400 # IDs 400-4FF

#sniffer
cansniffer -B -c -v 0x3ff -m 0xf00 can0
cansniffer -B -c -v 0x2ff -m 0xf00 can0
cansniffer -B -c -v 0x03ff -m0xf00 -v 0x04ff -t 100 -h 20 -l 4 can0

#send something
cansend can0 111#FF
cansend can1 000##11.22.33.44

#get module status
dmesg | grep -i can

[    6.082632] CAN device driver interface
[    6.109042] mcp251x spi0.0 can0: MCP2515 successfully initialized.
[    6.122284] mcp251x spi0.1 can1: MCP2515 successfully initialized.
[  104.418340] IPv6: ADDRCONF(NETDEV_CHANGE): can0: link becomes ready
[  108.789716] IPv6: ADDRCONF(NETDEV_CHANGE): can1: link becomes ready
[  123.985383] can: controller area network core
[  124.000906] can: raw protocol

#shutting down
ifconfig can0 down

#automatically enable can0 interface at boot time
#(example only, values need to be changed)
/etc/network/interfaces -----
auto can0
iface can0 inet manual
    pre-up /sbin/ip link set can0 type can bitrate 500000 listen-only on
    up /sbin/ifconfig can0 up
    down /sbin/ifconfig can0 down

EDIT FEBRUARY 2021: Replaced accidental usages of "bitmask" with the proper term "bitmap".

 

[beaups]

I hate to be argumentative, but you described the exact effects of what you would see if there was excessive saturation in a collision-oriented broadcast network. That, and the use of a tool designed to measure saturation on CAN networks reported its level at 58%... which in ordinary circumstances would be at a high level. As it turns out, this is a topic I've had some involvement with. In another life, I ran the technical operations of a regional Internet Service Provider.

Now, this isn't saying that Jscan or Tazer are bad. Quite the contrary. What I am saying is that these are the headwinds faced as "an outsider" when performing operations on the CAN-C bus. (Headwinds that I too will have to face.) This was intended more as a pulling back of the curtains to explain why people see some of the behavior they do in their existing tools.

* - I currently suspect that 58% saturation isn't a problem for the Jeep's own modules because they're carefully timing their responses to avoid stomping on each other. This behavior would be outside the defined behavior of the CAN protocol, but it's also not disallowed.

PS: We both may be saying the same things, but in different ways.

We aren't saying the same thing. It's not bus saturation. You could take every device off the bus except for a few things and products like the Tazer will behave the same way. The EVIC is programmed to refresh it's display on some interval - let's pretend 10x/second. At that point it looks at the last message it received. Did it come from the Tazer or from the radio? Devices that work like the Tazer "win" by sending their packets much more often. It's not a bus collision by any means.

Same as when I did my hack on the giulia - if I sent my packet at a similar rate to the official module, I'd wind up with traction control turning on and off repeatedly. Instead, I send much faster and whenever the ABS module decides to check what mode to be in, my packet is ~always the last one received.

There are also some nuances that can present themselves with sequencing etc as well, but none of this represents any sort of bus collision.

Many of these modules have little/no tolerance for missed or out-of-order messages. If there's a bus issue happening you'll end up with stored trouble codes.

 

[jmccorm]

We aren't saying the same thing.

I'll admit. I was trying to be friendly. But now I'm seeing where things went sideways. We'll get this sorted out.

It's not bus saturation. You could take every device off the bus except for a few things and products like the Tazer will behave the same way. The EVIC is programmed to refresh it's display on some interval - let's pretend 10x/second. At that point it looks at the last message it received. Did it come from the Tazer or from the radio? Devices that work like the Tazer "win" by sending their packets much more often. It's not a bus collision by any means.

Let's take your example. Looking at actual traffic, nobody is regularly writing to the EVIC in a way that updates or competes with the Tazer for its display on the music screen. The uConnect radio only writes to that screen when it has something new (a new song, a new selected input)... typically one time every few minutes as an irregular refresh that's held static in the EVIC's memory. And no other time.

I understand the concept you're relating. It's something different and just as familiar to my cybersecurity background. It's called a race condition. (Because it is usually a race to be first... but in this case, last!). You were exploiting a race condition to override a contradictory control.

If the Tazer wasn't filtering traffic, that's something that it could be facing too (particularly when it comes to controls). With its Live features, it takes the interior bus's input, filters it against what it wants to happen on the CAN-C bus, and then transmits THAT. And it can do that because it replaces the gateway between the interior bus and the CAN-C bus as a MITM (man-in-the-middle). When it wants something, it can lie to the CAN-C bus about what's going on in the IHS bus, and the IHS bus never has a chance to contradict it. In most cases, there are no other inputs for it to compete with on the CAN-C bus. (Its use of the EVIC display is a great example... and the Tazer itself isn't regularly refreshing those either.)

So what happens with a control is that it sends a message, "turn on the headlights" which goes through, then it says "turn off the headlights" (which it can send without fear of contradiction). Unfortunately, it collides with an unrelated message from the Powertrain Control Module (that has nothing to do with headlights), and the message is lost. Or it'll update the EVIC with a new menu display, and it'll collide with an update from the Tranmission Control Module (that has nothing the EVIC cares about). The 11.3.1 Tazer JL update made some changes to their retry mechanism which has at least improved how it handles these collisions.

But back to what I was seeing Tazer and JScan messages on the CAN-C bus. There's a ton of traffic on the CAN-C bus that they need to compete with just to get any complete CAN message out (with a 60% chance of failure, regardless of what it is trying to do). At least where I was looking, they weren't racing against another input, they were fighting against a very busy bus!

But I totally understand the challenges you faced and the solution you used on the Giulia. You were fighting another input, last is right, so you updated at a much tighter interval so that your message would be the last one in memory, and so the last one used. It had to have been fun!

UPDATE (December 2021): We have since confirmed that the Tazer usually isn't in a race condition with another module to try to have "the last" message that takes hold. Instead, many of those features (like how it overrides your vehicle inputs) for the Light Show feature, are done over CAN using a more complex protocol known as Unified Diagnostic Services (UDS). UDS allows the Tazer to directly override vehicle outputs with mechanisms designed for testing.

 

[beaups]

I'll admit. I was trying to be friendly. But now I'm seeing where things went sideways. We'll get this sorted out.

Let's take your example. Looking at actual traffic, nobody is regularly writing to the EVIC in a way that updates or competes with the Tazer for its display on the music screen. The uConnect radio only writes to that screen when it has something new (a new song, a new selected input)... typically one time every few minutes as an irregular refresh that's held static in the EVIC's memory. And no other time.

I understand the concept you're relating. It's something different and just as familiar to my cybersecurity background. It's called a race condition. (Because it is usually a race to be first... but in this case, last!). You were exploiting a race condition to override a contradictory control.

If the Tazer wasn't filtering traffic, that's something that it could be facing too (particularly when it comes to controls). With its Live features, it takes the interior bus's input, filters it against what it wants to happen on the CAN-C bus, and then transmits THAT. And it can do that because it replaces the gateway between the interior bus and the CAN-C bus as a MITM (man-in-the-middle). When it wants something, it can lie to the CAN-C bus about what's going on in the IHS bus, and the IHS bus never has a chance to contradict it. In most cases, there are no other inputs for it to compete with on the CAN-C bus. (Its use of the EVIC display is a great example... and the Tazer itself isn't regularly refreshing those either.)

So what happens with a control is that it sends a message, "turn on the headlights" which goes through, then it says "turn off the headlights" (which it can send without fear of contradiction). Unfortunately, it collides with an unrelated message from the Powertrain Control Module (that has nothing to do with headlights), and the message is lost. Or it'll update the EVIC with a new menu display, and it'll collide with an update from the Tranmission Control Module (that has nothing the EVIC cares about). The 11.3.1 Tazer JL update made some changes to their retry mechanism which has at least improved how it handles these collisions.

But back to what I was seeing Tazer and JScan messages on the CAN-C bus. There's a ton of traffic on the CAN-C bus that they need to compete with just to get any complete CAN message out (with a 60% chance of failure, regardless of what it is trying to do). At least where I was looking, they weren't racing against another input, they were fighting against a very busy bus!

But I totally understand the challenges you faced and the solution you used on the Giulia. You were fighting another input, last is right, so you updated at a much tighter interval so that your message would be the last one in memory, and so the last one used. It had to have been fun!

Sorry I didn't mean to give the impression things are going sideways. IT's a good conversation and I thought you were seeking feedback from people like myself that have done some prior work here.

Most hacks that interface with canbus and I assumed (albeit possibly incorrectly) including the Tazer itself aren't filtering traffic, they just continuously race when they want control of something...even though the Tazer's unique location would make it a candidate for filtering. (As a holder of a few CVE's I also understand race conditions quite well.)

Typically these types of devices just race forever to maintain control of the module/display/etc. If the device sends messages @ 10x the frequency of the other device, it has a 90% chance of having the last/most recent packet at the time the receiver/display decides to poll or handle interrupt etc to decide what to refresh the display with. None of it ultimately really matters, it just should not be confused with bus contention/saturation/overutilization, because it isn't.

It's been a year or so since I've dug into this stuff but the last time I did there was no easy way to accurately measure bus utilization anyhow. The publicly available tools had to make a lot of assumptions. Knowing the tools weren't great and the bus limitations aren't well defined, I like to assume the engineers knew what they were doing.

 

[Bullwinkle]

Sorry I didn't mean to give the impression things are going sideways. IT's a good conversation and I thought you were seeking feedback from people like myself that have done some prior work here.

Most hacks that interface with canbus and I assumed (albeit possibly incorrectly) including the Tazer itself aren't filtering traffic, they just continuously race when they want control of something...even though the Tazer's unique location would make it a candidate for filtering. (As a holder of a few CVE's I also understand race conditions quite well.)

Typically these types of devices just race forever to maintain control of the module/display/etc. If the device sends messages @ 10x the frequency of the other device, it has a 90% chance of having the last/most recent packet at the time the receiver/display decides to poll or handle interrupt etc to decide what to refresh the display with. None of it ultimately really matters, it just should not be confused with bus contention/saturation/overutilization, because it isn't.

It's been a year or so since I've dug into this stuff but the last time I did there was no easy way to accurately measure bus utilization anyhow. The publicly available tools had to make a lot of assumptions. Knowing the tools weren't great and the bus limitations aren't well defined, I like to assume the engineers knew what they were doing.

Holy Cow Batman, I thought following GMRS was complicated!

 

[jmccorm]

Sorry I didn't mean to give the impression things are going sideways. IT's a good conversation and I thought you were seeking feedback from people like myself that have done some prior work here.

Indeed, good deal. I absolutely want to bounce ideas off of other people, and I'm more than willing to help others with their own efforts, too.

(As a holder of a few CVE's I also understand race conditions quite well.)

I'll pick that conversation up with you later down the road. I'd like to hear it!

Typically these types of devices just race forever to maintain control of the module/display/etc. If the device sends messages @ 10x the frequency of the other device, it has a 90% chance of having the last/most recent packet at the time the receiver/display decides to poll or handle interrupt etc to decide what to refresh the display with.

I'm thinking of three approaches, each with their own trade-offs...

1. The approach as described (above) which you used on the Giulia.

2. Synchronization and selective timing. If the clock is as regular as I'm hoping (or a broadcast is otherwise predictable), we could know exactly when to time our counter-broadcast. Or along those lines, if we kept an empty FIFO buffer, we could send our counter-message as soon as the target message broadcasts. (Repeat this for all codes in play.)

3. I suspect (but would not know until testing) that the CAN-C bus has a direct connection from the back of the SGW and into the glovebox's CAN-C hub. If so, we could position OURSELVES as a MITM regardless of anything else (including a Tazer). We'd perform our own filter-and-forward operation. Of course, if the authentic SGW is still present, it could end up filtering something we'd want to use.

So far, this appears to be the furthest any public effort has gotten on reverse-engineering any of the JL's CAN bus activity. I'd love to encourage you to dip your toe back in the water. I'm sharing my findings as I go and I hope to encourage others to do the same (Arduino is just as welcome).

There are so many CAN IDs with (mostly) 8 byte messages that this is going to take any number of eyeballs to significantly reverse-engineer.

PS: I think my next useful step may be a very limited broadcast. Perhaps a simple replay attack on the EVIC's audio screen text? Or one of the well known OBD-II codes?

PPS: I just realized that I don't know exactly how to unhook my CAN-C connector from the bus. HA!

 

[jmccorm]

Good news...

Success!
I displayed 3 lines of text on the EVIC's music screen. Along the way I learned two lessons. First, I cannot immediately send message after message to the EVIC. I have to insert a small delay to give it time to process each line. Second, when you send the bottom line, it automatically clears all the text on the screen, so you want to do that first and not last.

Code follows:

#!/bin/bash
# Bottom line (must be done first - clears all other fields)
cansend can0  328#20.41.00.42.00.6C.00.75   # '0B.B.l.u' <--Input Name
sleep 0.01
cansend can0  328#10.01.00.65.00.46.00.6F   # ' ..e.F.o'
sleep 0.01
cansend can0  328#00.01.00.78.00.00.00.00   # '...x....'
sleep 0.01
cansend can0  328#00.00.00.00.00.00.00.00   # '........' <--END OF MESSAGE
sleep 0.1
# Second line
cansend can0  328#30.42.00.42.00.6C.00.75   # '0B.A.B.C' <--Artist
sleep 0.01
cansend can0  328#20.02.00.65.00.46.00.6F   # ' ..D.E.F'
sleep 0.01
cansend can0  328#10.02.00.78.00.4D.00.75   # '...G.H.I'
sleep 0.01
cansend can0  328#00.02.00.73.00.69.00.63   # '...J.K.L'
sleep 0.01
cansend can0  328#00.00.00.00.00.00.00.00   # '........' <--END OF MESSAGE
sleep 0.1
# Top line
cansend can0  328#30.43.00.41.00.42.00.43   # '0B.B.l.u' <--Title
sleep 0.01
cansend can0  328#20.03.00.44.00.45.00.46   # ' ..e.F.o'
sleep 0.01
cansend can0  328#10.03.00.47.00.48.00.49   # '...x.M.u'
sleep 0.01
cansend can0  328#00.03.00.4a.00.4b.00.4c   # '...s.i.c'
sleep 0.01
cansend can0  328#00.00.00.00.00.00.00.00   # '........' <--END OF MESSAGE
sleep 0.1

Finally, if I'm going to be taking any more pictures, time for me to clean the display really well. (You just don't see those imperfections in real life!)

Sponsored