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

[LanceMagnum]

I've got a good compromise, this is the location of the 'other' c bus star connector:

It's behind the door jamb / in front of the rear passenger side wheel well (there's a similar IHS bus version on the drivers side) - just pull back the carpeting to find it.

Will cut the length of my cable run in half or better

Sponsored

 

[Ratbert]

Got a successful tap into the can C bus - not sure why using the DLC did not work. I do have the auto startstop eliminator in place but would not think that would affect it.

Anyway, getting good traffic of TPMS messages seen on the bus, every second or two. Don't yet know how often the data is actually updated from the tire sensors but that's next.

This is the MKR 1010 with CAN shield (stacked) - I'll be adding a relay and also an optoisolator used to know when the compressor is actually running (so I can keep an accurate accumulation of run time, need to account for when the pressure sensor on the ARB decides to turn itself off)

Dash:

Data from can bus sent to web page:

Curious what it will say when I switch to socialism units instead of individual liberty/free market units (while we're still able, don't get me started...)

I'd prefer to mount the controller in the back closer the compressor and fittings but that means running a longer can cable. Even using proper twisted pair and shielding it may be a weak link.

Has anyone tapped into the can bus wires of an existing module? Like the RFH module is very convenient for my project but not sure how I feel about splicing into the factory harness.

It's in PSI? That's unreal.

Note that your pressures are really, really high.

 

[LanceMagnum]

Note that your pressures are really, really high.

Yeah, finally almost spring here in New England, need to bleed them down to 36 or 37

 

[Bill_BCNtoNY]

It's in PSI? That's unreal.

Note that your pressures are really, really high.

I missed that when your post @LanceMagnum, but if you drop your psi to ~30 (or maybe even less, depends on your tire/wheel setup) you will feel quite the difference. Your ride must be like a bouncy castle now! ?

sorry to add one more thing to go experiment on haha

 

[Mitoni]

Today I believe I have a better high-level understanding of the Secure Gateway Module, it's purpose, and it's relationship with the OBD-II port (what Jeep calls the DLC, or Data Link Link Connector) as well as it's relationship with the uConnect radio.

At the bottom of this message, I've included a diagram of the DLC connector (including pinouts) as well as both connectors to the Secure Gateway module. But the what I really want to reference is one of the Wrangler's wiring diagrams.

Below I have pasted a portion of the CAN-C bus wiring diagram. (For our purposes, we can assume that the CAN-IHS bus is wired in a similar manner, so I've not included it.)

The Secure Gateway Module (SGM) receives an ordinary connection to the vehicle's main CAN-C and CAN-IHS bus. What the SGM does is it stands between the radio and the reset of the vehicle. Separately, it also stands between the OBD-II port and the rest of the vehicle. It acts as two separate firewalls with two different sets of rules, designed to limit and protect access to the CAN network.

The Secure Gateway Module allows third-party OBD-II tools to listen in on everything that's happening on the vehicle's two major buses. But when these OBD-II tools try to write to the CAN-C and CAN-IHS bus (for example, they might send a command to bleed the brakes), it prevents it. Not unless they authenticate themselves in a special way that Jeep built into the system. Obviously, some vehicle technicians have questioned if this might be a little self-serving of Jeep, requiring some third-party tools to seek authorization from Jeep to fully function on their vehicles.

At the dealership, when your vehicle is being serviced, a tech will make a connection to the OBD-II port. Aside from being able to read parameters from your vehicle, this can also allow Jeep (corporate) to send a special message to your Secure Gateway Module, authorizing the technician's tool to have read and write access to the vehicle's CAN-C and CAN-IHS bus for a limited time.

I suspect (but have not yet validated) that something different is happening with the Secure Gateway's Module's connection to the radio module.

The uConnect radio normally IS allowed to write certain configuration changes to the CAN bus (where it is stored and relayed by a separate module). For example, when you select the setting on the uConnect touch-screen which enables a horn honk when remote-locking your vehicle, the uConnect radio broadcasts that configuration change to another CAN module where it is permanently stored and made available to other modules. But there are certain other messages that your radio should never be sending (for example, a message that contains the angle of the steering wheel, or the current engine RPMs).

Pre-approved messages on a whitelist ARE allowed. Anything that isn't pre-approved is filtered out. And this is to maintain the security of your vehicle in case the uConnect radio gets hacked (via it's own cellular conection, or via the USB ports, for example). Theoretically, it may be possible for Jeep (corporate) to use the uConnect radio to remotely flash updates individual components on your vehicle (like the transmission). I don't know for certain if the provisioned this capability in the Secure Gateway Module or not, or if they've taken advantage of this in the past or not.

Back to the Secure Gateway Module, when an owner replaces it with a bypass cable (or a Tazer), it does two things. First, it makes full access to your vehicle's CAN networks available via the OBD-II port. Any tool that plugs into the OBD-II port now has full CAN access. I imagine that Jeep wanted to prevent this, as it wouldn't be too difficult for a third party to create a small inexpensive OBD-II plugin that sends a few signals in a matter of seconds, and once it is removed, it will have silently made changes to your vehicle's configuration that completely disables it (or worse).

Second, it gives full CAN access to your uConnect radio. Not too long ago, students of cyber security at the University of Tulsa hacked the uConnect radio of an FCA vehicle, giving them remote access to the vehicle's bus (over the vehicle's own built-in cellular connection), allowing them to do things on command, such as completely preventing the brakes from working. In short, the Secure Gateway Module makes it harder for your vehicle to be hacked, and and it makes it harder for your vehicle to be monitored or operated remotely.

So this explains why a Secure Gateway bypass cable is needed for a tool like JScan (which connects to the OBD-II port) to be able to make configuration changes and to perform some of it's adaptation functions. The cable gives it direct access to both CAN networks, and not the filtered read-only access that comes from the factory.

In the case of the Tazer (which replaces the Secure Gateway entirely), this gives it Tazer itself direct access to both CAN networks. Although that position makes it possible for it to maintain separate connections to the uConnect radio and the OBD-II ports, most likely it simply bridges all three connections together, giving itself and everything else full access to the vehicle's CAN networks.

Originally, I had a theory that the Tazer performs some operations by intercepting the signals and modifying them in-flight. When I can, I try to support or refute any theories I've developed (and shared) along the way. While that's possible, that's not what's going on here. That theory is wrong.

I now know that the Tazer performs makes many of it's configuration changes by writing them to specific BUS IDs where the vehicle ordinarily stores them. I have yet to see how certain operations like the Light Show are done, but during that time, I happened to see CAN messages with IDs in the 4Cx, 5xx, and 7xx ranges, which typically aren't seen.

The part of the vehicle I've chosen to focus on is behind the glovebox, which offers direct access to two of the vehicle's 13-way CAN bus connectors. There's still plenty of space for my components, and anything too large can still be placed in the glovebox itself.

Numerous items already plugged into some of the ports, but there are still a number of open ports available, any one of which can provide the access necessary for my own tools. An advantage worth noting is that any one of these open ports can be used without disrupting any of the other existing third-party tools like JScan and the Tazer.

This final benefit of this area is that it also gives us the potential to isolate any of the the major components which plug into the 13-way bus connector. Once isolated, any of those modules can be listened to (or have their signals intercepted and modified) on an individual basis. While those opportunities aren't my immediate area of interest, it's clear to me that they have the potential to create new possibilities that we haven't seen before.

The major downside? While it is a little less convenient to access than the OBD-II connector., it's major problem appears to be that there's no direct source of power in the immediate area. (If I'm overlooking something, please, add what you know!) Power might be routed over through the center console or through the engine bay, but there doesn't seem to be major 12v feeds to tap into.

So, I hope this information helps someone along the way when they go to look at the OBD-II port, Secure Gateway Module, or one of the CAN bus connections as their source for vehicle connectivity. I've typed quite a bit here, so I might have made a mistake or two along the way. If so, let me know.

For completeness, here are diagrams of the OBD-II and Secure Gateway Module connectors, with labels for each pin. Where you see a "DIAGNOSTIC CAN C" or "DIAGNOSTIC CAN IHS" bus, those are the the filtered bus lines for the OBD-II connector. Where you see "CAN C AT" and "CAN IHS AT", those are filtered bus lines for the radio module. (Maybe someone else knows what AT stands for?)

If you've read this far, wow, you must be interested! Thanks, and any comments are welcome.

So necroing your thread here just to point out, if you happen to break the little plastic bar over the lock on connector, and wish to replace it:

Molex STAC64 - 34729-0080 for the 8 pin connector
Molex STAC64 - 34729-0120 for the 12pin connector

They are like a buck a piece on Mouser. (the picture shown on the links is a different size, but i confirmed the appearance is correct key/polarization in the Drawing files linked on the datasheet. The guys out there selling pigtailed connectors want like $98 for them >.< I'm just glad my Google-Fu is strong because I was going by nothing but a picture.

 

[dstevens]

I'm curious. I have a Tazer and enjoy the added capabilities it includes. I really like the idea of swaykill individual locker control etc. But I'm not fond of the steering wheel buttons being used for multiple purposes. I have accidentally set and engaged light show while driving and thought my Jeep was having a seizure. Is it possible to add an arduino controller to the network, and add physical buttons that the arduino can use to trigger Tazer commands?

I started down the same path using the same keypad as everyone else in the industry (blink marine) and got it as far as getting locker, winch mode, force fan on partially working from the keypad. Swaykill I believe I didn't need a button because if you get the logic correct then the factory button works. I also made a bracket that picked up the dash mounting screws to mount the keypad and it was a fairly tidy install apart from the giant connector blink uses.
My motivation was the same - the key combinations from Tazer are ridiculous and when you are on trail, with the steering wheel clocked, you never can get the combinations correct. Never allow a hardware engineer to do anything involving user interaction.
One day I'll have time to continue the project.

 

[jeepingib]

I started down the same path using the same keypad as everyone else in the industry (blink marine) and got it as far as getting locker, winch mode, force fan on partially working from the keypad. Swaykill I believe I didn't need a button because if you get the logic correct then the factory button works. I also made a bracket that picked up the dash mounting screws to mount the keypad and it was a fairly tidy install apart from the giant connector blink uses.
My motivation was the same - the key combinations from Tazer are ridiculous and when you are on trail, with the steering wheel clocked, you never can get the combinations correct. Never allow a hardware engineer to do anything involving user interaction.
One day I'll have time to continue the project.

That's very cool. Would love to see what you have gotten figured out. Did you flash the Tazer unit to have it look for the unique inputs from your keypad?

 

[dstevens]

That's very cool. Would love to see what you have gotten figured out. Did you flash the Tazer unit to have it look for the unique inputs from your keypad?

My original plan was for the keypad to just send out the tazer key combinations on the bus for the tazer.

The Tazer did not work that well on the 24 so I replicated the functionality I used on new hardware. Ess memory. TC memory, which the Tazer did not have. Sway disconnect, which does not work correctly on the Tazer. Force fan on, which I never got working correctly. Winch idle up, which worked ok.

 

[LanceMagnum]

So my project is basically down to software development at this point. I've got my Arduino with CAN transceiver tapped into the C bus and also a control relay that is in series with the pressure cutoff switch on the ARB.

Since the ARB itself, as well as the relay on the ARB circuit, cause voltage dropouts and noise some significant protection circuitry is needed. I have a big cap and diode to keep the μC power stable for when the ARB kicks on, and I also added a flyback protection diode to the ARB relay:

(the diode is hiding under those 2 pieces of heat shrink)

My previous project was battery powered because I did not put the design effort into cleaning up the noise but with the latest steps it's been very stable and it's convenient having it powered from the same aux circuit that powers the ARB.

I did some test deflation/inflation and the psi updates from the sensors are better than expected, maybe every minute or so. Hopefully this means I can program an accurate prediction curve to know when to pause the compressor as it hits setpoint (and I think a v1 can skip the prediction stuff but still be 'close enough' to be useful)

 

[C.Sco]

Navigating the menus and selections is by far the weakest link in the Tazer experience IMHO, but it does add a lot of flexibility.

Agreed. I don't understand why Tazer can't just give us a basic LCD screen and keypad to stick to our dash somewhere, to use independently from the steering wheel and dash screen interface.

 

[THAW]

I did some test deflation/inflation and the psi updates from the sensors are better than expected, maybe every minute or so. Hopefully this means I can program an accurate prediction curve to know when to pause the compressor as it hits setpoint (and I think a v1 can skip the prediction stuff but still be 'close enough' to be useful)

I don't know how much it matters to your project, but my understanding is stationary (i.e. wheels not rotating) TPMS sensors send updates based on pressure differential (perhaps 2 PSI), not time. It could be you're seeing fairly regular time intervals because the compressor CFM output is reasonably steady. Does that jibe with data you're seeing?

 

[LanceMagnum]

Does that jive with data you're seeing?

Yes it does, that was my hope - that the sensors themselves are looking for a psi change and will transmit more frequently when detected (otherwise save the sensor battery power)

I've noticed when leaving the driveway on a cold morning that that it can take a bit for the dash to update, so maybe the sensors don't detect the slow temp-related psi change in the same way.

 

[Ratbert]

Agreed. I don't understand why Tazer can't just give us a basic LCD screen and keypad to stick to our dash somewhere, to use independently from the steering wheel and dash screen interface.

Agreed. I eventually removed my Tazer since it kept engaging the sway bar disconnect whenever I'd pull off the interstate.

 

[THAW]

Yes it does, that was my hope - that the sensors themselves are looking for a psi change and will transmit more frequently when detected (otherwise save the sensor battery power)

I've noticed when leaving the driveway on a cold morning that that it can take a bit for the dash to update, so maybe the sensors don't detect the slow temp-related psi change in the same way.

Again, this information is just my understanding and not necessarily 100% correct, but:

I believe TPMS sensors have several different modes, one of which is a driving mode (triggered when the Jeep hits about ~15 mph) with time based update intervals. That's probably what you're seeing in the mornings after being parked overnight.

 

[THAW]

Agreed. I eventually removed my Tazer since it kept engaging the sway bar disconnect whenever I'd pull off the interstate.

Sounds like you had a button mapped to swaykill and were unknowingly triggering it after disabling cruise control post freeway?

Sponsored