yashsingh1/xdaforums huggingface dataset:
[Connected Car] willzyliu:
@markkpatel , and any others who have gotten Off Road Pages app running, but exhibit a non-functional Selec-Terrain page.

I've managed to resolve this by tampering with the sensor_properties.xml file.

FULL credit to Mark for his dev work on the modified 1.7.1 ORP app and instructions.

Context

The Off Road Pages app code has the incorrect Terrain Mode Status mapping for older (MY14-16?) WK2 with Selec-Terrain equipped.

Mark's modified version has 1. Correctly mapped Terrain Mode Statuses for MY14-16. 2. Set the sensorName for Terrain Mode Status to TerMdStat. 3. Will get you the app to display Rock Mode by default - this is because the TerrainModeInhibit is not being picked up (therefore is invalid input NULL) and Mark's code has defaulted these responses to the 'Rock Mode' image

The app looks for the output of the two sensors below, which are keys for the ComponentName in sensor_properties.xml

Sensor_properties.xml is just a global config file for mapping sensor data called by uConnect apps, to the corresponding pps can/xlet sensors that the vehicle logs.

TerMdStat - There is a sensor mapping for TerMdStat however, but the componentName is TerrainModeStatus. The modded Off Road App calls TerMdStat, but no such componentName despite data being present. Pulls null data.

TerMdInhbt - There is no sensor mapping for TerMdInhbt. The modded/og Off RoadApp calls TerMdInhbt, but no such componentName and no sensor mapping. Pulls null data.

Prerequisites

- Mark's modified Off Road Pages app installed, AND you are exhibiting Selec-Terrain page not working (thus defaulting to Rock img)

- M14-16 WK2 JGC with selec-terrain enabled

- One of your vehicle config settings are 0 (In my case, I had SRTPresent=0 as I don't care for the SRT GUI look)

Solution

Update the sensor_properties.xml file and load to /fs/mmc1/kona/data/sensor_properties.xml

Make sure you take a backup of this file first, so you can rollback if required.

1. Find the <ComponentName>TerrainModeStatus</ComponentName> and replace value TerrainModeStatus with TerMdStat

2. Find the sensor lines for VC_SRT_PRSNT and copy everything from the first <sensor> to the ending </sensor>

N.B. Doesn't have to be VC_SRT_PRSNT. You can use any sensor that you know for a fact is always going to be set to '0'.

Paste the above at the bottom of the file, just before the ending line </sensor

s

> and after the very last sensor declaration.

Change the ComponentName value to TerMdInhbt. You can leave the rest.

Reset uConnect or power cycle the car. You're done.

ORP App will now look to sensor_properties.xml for sensor data, and call the sensor via componentNames TerMdStat and TerMdInhbt - these will both return INT values as expected by the app.

Limitations/Risks

Whichever sensor you decide for the permanent '0' value for TerMdInhbt, I am unsure of the implications if the uConnect app were to make multiple calls to the same CAN sensor at the same time.

In my case, I chose SRTPresent, as I believe this is only ever called for uConnect GUI initiation, and App initiation - so it would be rare to be called more than once at a time.
[Connected Car] markkpatel:
Excellent team work - It worked for me also.

NOTE: my 2015 Jeep Grand Cherokee Summit (United Kingdom) version 16.16.13 has file /fs/mmc1/kona/data/sensor_properties.json and my json file already has entry for TerMdInhbt.

So if you have a json file instead of xml file just change "componentname": "TerrainModeStatus" to "componentname": "TerMdStat". Also if you do not already have an entry for "TerMdInhbt" then just create one by copy paste method as stated above.

If you have an xml file check to see if you already have an entry for "TerMdInhbt", I get the impression that we may not all have the same data on our Uconnect systems.

** Now to sort out Transfer Case Status which is showing as "--" on the status bar **
[Connected Car] willzyliu:
Stoked to hear it worked for you.

RE: Json file - good point. I was digging through a MY15 ISO yesterday and saw that the sensor_properties was a json file, but the file didn't have TerMdInhbt. The ISO was 14.XX.XX so potentially later FW updates expanded out the sensor mappings.

RE: TerMdInhbt - out of curiosity, would you be able to provide the json segment for your TerMdInhbt? Might experiment to see if the CAN sensor actually exists by configuring it properly into my sensor_properties.xml

RE: Transfer Case Status - I think my ORP app displays correct status luckily. I'll check tomorrow. I did check my pps\can logs but nothing logged here about TCASE_STAT

Here is the sensor mapping in my xml if it helps:

TBC: Pitch/Roll - I reckon the only way forward is to grab a bunch of MY17+ ISOs, which are out of reach for me. If anyone can figure it out it would be much appreciated.

Also wondering how you went about updating the original ORP app? I originally attempted to code out the terrain inhibit conditions on a decompiled TerrainModeStatusInfo_t, then recompiled to class via javac command line feeding in the ORP.jar app for dependencies, and then updated the jar app via jar -uf command line. The app loaded, but crashed out - I get the feeling the recompile wasn't clean.

I did also try setting it all up as a project, but could not be bothered resolving all package and library dependencies.
[Connected Car] markkpatel:
I loaded my full sensor_properties.json file to my ORP files (link on previous page 17).

As far as Tcase status: I am talking about the bar at the bottom of each page, the last item is always "--" on mine ( I think it should say "4HI" or "4LO" ).

For Pitch and Roll we need to get Uconnect data from someone that has Pitch and Roll working.

To edit the ORP classes I use DirtyJoe (Java bytecode programming), now also in my ORP files (link on previous page 17).

To use dirtyjoe unzip ORP.jar file then from dirtyjoe select individual classes to be edited, when done rezip all files and rename .zip to .jar (replace original jar file with same name).

These are the steps I use:

Note <app> = "OffRoadPages_1.7.1_0906"

1. Copy the app folder you want to modify to a new folder ( folder "f1de6bac-9876-3250-8dc2-c729b755a600" )

2. Start 7zip, open file, navigate to new app "jars" folder, select the <app>.jar file, Press "Extract " button

3. In new Extract window add zzz to the end of the directory name and press OK button

4. You now have a zzz folder (in the "jars" folder) with all the <app>.jar files unzipped

......( should not have a <app> sub-folder in zzz folder -> the files should be directly under the zzz folder )

......( new folder is "f1de6bac-9876-3250-8dc2-c729b755a600/prog/jars/zzz" )

5. *** Use dirtyjoe to modify class files in folder zzz ***

6. Start 7zip, open file, navigate to zzz folder, Edit->Select All, Press "Add" button

7. In new window press OK button, Close 7zip (This creates a zzz.zip file in the zzz folder)

8. Move the zzz.zip file from folder zzz to the "jars" folder (1 level below)

9. You are now in the "jars" folder with <app>.jar, zzz folder and zzz.zip file (also key.jar and magic.txt)

10. Delete the zzz folder

11. Copy the file-name of the <app>.jar file, then Delete the <app>.jar file

12. Rename zzz.zip to <app>.jar ( <app>.jar = file-name you just copied = "OffRoadPages_1.7.1_0906.jar" )

13. Lucky 13. All done. The modified app is ready to use.

Also don't ask me about java bytecode as I am just learning as I go.
[Connected Car] willzyliu:
I checked today - and:

1. Transfer Case Status does change to 4WDLO for me on StatusBar, but does not display anything if I am in 4WDHIGH.

The DrivetrainPage does let me know whether I’m in high or low range however.

See attached pics below

2. The last column displays “- -“ for me. I believe this status relates to the Hill Descent status (ref to StatusBarInfo_t), which I assume would only update if in hill descent mode. Haven't yet tested hill descent since I've had the app set up, so unsure if the data flows through.

3. Sensor_properties.xml

I updated my newly created 'TerMdInhbt' sensor parameters with the values taken in your .json file (thank you for uploading!). Selec-Terrain page still works a treat and is now calling the TerMdInhbt pps can/xlet data (presumably).

I’m with you for all of your steps for updating the app jar, except for the byte code bit. I did actually attempt to update via byte code in my numerous attempts to update the app, but byte code was way too steep a learning curve for me. Kudos to you for taking the bytecode approach
[Connected Car] markkpatel:
Mine is the same, shows or blank. I was mistaken about the "--".

I notice your screen does not show current mode in the bar at the bottom of the screen. It should show text "AUTO", "SAND", "MUD" etc on every screen. Maybe try downloading the app from my ORP files again as I might have changed it since you first downloaded.

Yeah :confused:bytecode is fun to work with, but just like you I first tried and failed with the decompile/recompile method on the jar file.
[Connected Car] congar58:
Thank You :)

But I need modified UPD Files. Because my uconnect starts only upd files. I tried with iso files but it's happening nothing.

The ONLY way is, to find a way to modify upd files or its contents (installer.iso, primary.iso, secondary.iso)

But I think i need only the modified installer.iso with keeping its Hash Value :D

Because otherwise I get authentication failed message.

So what can I do? I mean how can I edit the UPD File with hexEdit or Notepad ?
[Connected Car] markkpatel:
You are out of luck.

The swdl.upd can not be changed (or at least after a certain version number). The Uconnect knows that the swdl.upd has changed and will give an error.

It is believed that a modified swdl.upd can be run if the Uconnect is first in manufacters mode, but nobody can figure out how to turn on that mode.
[Connected Car] devmihkel:
@congar58 on the 8.4 versions up to 16.33.x or so the UPD is perfectly exploitable #328

But it takes bit more than Notepad and no ready-made UPD around, you need to have your own :)
[Connected Car] markkpatel:
PITCH and ROLL for Off Road Pages app

@willzyliu @devmihkel and others the pitch and roll data comes from the YAW sensor. I was looking at a site where people were trying to map can codes for 2018 - 2022 Jeep wranglers by reading raw data via the obd2 and they found that the YAW sensor returned values for Yaw, Pitch and Roll.

Since our cars have Yaw sensors we should have that data.

The sensor_properties file has definitions for yaw, pitch and roll. (This is for reading from PPS files only)

But the PPS files do not have yaw, pitch or roll data. The Uconnect is not mapping Yaw sensor can data to PPS files.

We need to find the code in the Uconnect that reads from can data and writes out to the PPS files.

If we find the program code that does this on the Uconnect, we can then work out how to write our own code to read the Yaw sensor data and update the PPS files ourself.
[Connected Car] willzyliu:
Concur with your findings.

Actually stumbled across the same wrangler thread I think (https://www.jlwranglerforums.com/fo...-can-c-can-ihs-uds-reverse-engineering.82139/)

Potential limitation may be that the yaw/dynamics sensor part changed over in 2018, which could mean that the sensory output also changed

2011-2018 56029469aa

2018+ 68411966ab

JL Wrangler (wasn’t able to track down the part number)

Got to find someone with a trailhawk with ORP and perform a full dir dump and go through all the files.

I do find it odd that the uConnect/Jeep engineers had thought to even include the pitch and roll app/sensor mapping as early as 2013/14. I suppose they were thick in the R&D for 2017 at that time, which is when pitch/roll screens became a thing I believe
[Connected Car] Wattsbg:
So for Uconnect 8.4 on GC Summit 2014, version 18.45.01, is there way to convert it to EU to install EU maps? Should I downgrade it and is there way to do it? The old posts with software are expired. Anyone with new links?
[Connected Car] willzyliu:
ORP Update

Managed to source an 18.45.01 update ISO for a MY18 TH.

1. DRM.jar - I am now using the DRM.jar from the KIM24 xlets directory, which has DRM exceptions for both ORP and Performance pages! My Performance pages now also work. Woohoo

2. Sensor_properties.json - the json file contains a few new entries for YAW data, Terrain Status LED (1-5, which I assume represents the five different selec-terrain statuses auto/snow/sand/mud/rock), and GlobalDriveModeStatus.

This is where things get super confusing to me. GlobalDriveModeStatus defines itself as an INT data type, with values being 0 or 1. ORP uses GlobalDriveModeStatus and expects the value to be either of {4, 13, 1, 12, 6}. I must be missing something, but I can't seem to work out how the selec-terrain page could possibly work with this sensor mapping. There must be some form of data transformation layer between the received sensor data, and other inputs.

As a test, I reloaded the original ORP app, and updated my own sensor_properties file with all mappings present in the 18.45.01 update. Selec-terrain page doesn't work even though I have defined GlobalDriveModeStatus and all other terrain-related sensor mappings. Changed it back to Mark's version as it overrides the terrain mode status to TerMdStat which is supported for earlier WK2 (MY14-MY16?)

3. Now that I have this ISO, I will commence the grueling task of searching for the holy grail CAN PPS definition for Pitch and Roll degrees. Will update if/when I find something.

Navigation update

I have tried to load the Squithy ROW 2019 and 2016 nav content and licenses, but always comes back with a prompt for my navigation activation code, despite the fact I already have a VP4 model.

Strangely the 'Original ROW' upload licenses pass the nav activation detection.

Have already switched over the NaviServer2.

I suppose Squithy's license files arent pre-activated?

Next step will be to pull my finger out and actually buy an iGo license and load the Aus content/license. Will provide an update - but if anyone has encountered the same issue it would be great to get some guidance. Potentially there's something very very obvious that I've missed.
[Connected Car] markkpatel:
Drive Mode and Drive Mode sub menus is an actual thing like Terrain Mode Module that can be selected by alfaOBD. Look at the swf files and you will see many menu screens for Drive Mode stuff. Things like Drive Mode Launch Control etc., but not relevant to most of our cars. Terrain status LED (the LED that lights up when you select AUTO, SAND, MUD etc) is on our cars, but like yaw is not mapped from CAN to PPS files.

The directory list from page 1: https://pastebin.com/BKfSptbH

The IPC stuff looks like it could be relevant.

/dev/ipc/ch2 thru /dev/ipc/ch28

These channels appear to be used to send and maybe recieve data.

From boot.sh

echo "**********Resetting the hardware********************"

echo -n "\\0021" > /dev/ipc/ch4

Hopefully the CAN to PPS file conversion is not hardcoded in a compiled bin or lib.
[Connected Car] devmihkel:
For what I understand from the original (IOActive) research - yes it is hardcoded... in hardware 😇 because Uconnect (QNX) is not directly connected on CAN and PPS messages are proxied by so called IOC (V850) chip. And its firmware (cmcioc.bin) has predefined CAN messages and values hard-coded, so you might never see CAN messages and stuff like AlfaOBD does 🤷‍♂️
[Connected Car] markkpatel:
Page 48 onwards of the original whitepaper hacking report talks about the V850 chip and how to reprogram it from the Uconnect. So in theory it is possible to do, but in practical terms for me its a HELL NO, just looks too difficult for me. But I was kind of right about the IPC stuff, it uses /dev/ipc/ch4 to upload the new/modified cmcioc.bin file to the V850 chip from the Uconnect. Also uses other ipc channels to read and write stuff between V850 and Uconnect.

From the whitepaper:

The IOC application code is pushed to the V850 from the Uconnect system via the ‘iocupdate’ executable, which can be seen being called from ‘ioc.lua’.

iocupdate -c 4 -p usr/share/V850/cmcioc.bin

It now looks like the CAN to PPS file conversion is done via the V850 chip.

So good luck to anyone that wants to try to decode and make sense of the cmcioc.bin file(s). ;)

Here's the link to the whitepaper ( autoloads to page 48 )

https://ioactive.com/pdfs/IOActive_Remote_Car_Hacking.pdf#page=48

** Update **

I don't think we need to change the V850 cmcioc.bin file, we can just replace it with a V850 cmcioc.bin file from a newer Uconnect swdl.upd that has the pitch and roll working/showing in the PPS files. The V850 firmware should be similar to the CAN data, i.e. it does not really get updated/changed each year but rather new stuff gets added to it while the existing stuff remains where it is. Therefore new versions will work on older cars.

Example: I can signon to alfaOBD with my 2015 JGC and override alfaOBD to use the 2021 body computer to correctly make changes to existing stuff on my car because all the old existing CANids remain the same. They do not move existing stuff in the CAN data, they put new stuff into empty slots.

Uconnect update 18.45.01 is the latest one I have files for and in that update I can see that the V850 chip is the same as the one used on my 2015 Jeep version 16.16.13, so those files should work for me. But I am not sure if that update is too early for the pitch and roll stuff to be working.

*** Another Update ***

In alfaOBD from Body computer:MY2018 thru Body computerMY2021

there is the following option CBC Features-Pitch and Roll Present

Therefore we need to get a V850 cmcioc.bin file from a swdl.upd that includes MY2018 or later.

Prefer MY2019 onwards as year 2018 is tricky because there is also a Body computerMY2017-18 that does not have that option present.
[Connected Car] willzyliu:
Agree with you both @devmihkel , @markkpatel

Definitely looks like the journey to attaining pitch and roll data is steering us towards the very real possibility of potentially bricking the uConnect via forced firmware update haha.

I, too, found the whitepaper, and have been trying to understand more about how CAN data is logged through to uConnect. Summary ordered by proximity to user:

1. uConnect apps refer to sensor_properties for sensor definitions

2. Sensor_properties refers to logged CAN attributes

3. CAN attributes log through IPC channels

4. The type of CAN attributes that are logged through IPC channels is defined at the firmware level

can_utils in /USR can also retrieve CAN data via IPC, using attributes defined in can_utils_matrix. Not much help if the firmware indeed does not feed the CAN data we're after into the IPC channels for uConnect to utilise.

Looking at the ISOs I have available:

MY14 14.05.03 - cmc v850 app version is 14.2.0

MY14 16.13.13 - cmc v850 app version is 16.01.00

MY15 14.32.3 - cmc v850 app version is 14.28.01

MY13-17 18.45.01 - cmc v850 app version is 17.31.90 **EDIT actually theres a number of versions here - 14.2.0, 17.31.90, 14.15.91, 17.41.81

All processor type = V850ES/FJ3, and all OS name = uC/OS-II, so in theory it would just take a firmware update. The whitepaper does tell us the other .bin files that would be updated outside of cmcioc.bin, as well as the scripts that support the firmware upgrade, and the general process guide for doing so. But certainly still a real risk.

Outside of the pitch/roll discussion, I have updated my kona.jar to the 18.45.01 version, which supports sensor_properties json file instead of xml, so I've loaded the 18.45.01 json file in as well. Obviously no change to the ORP app, however there's some interesting references to a new 'ecoDrive' reports app which there are files present for in the base directory (not KIM directories) of this ISO.

Trying to work out how to get this going currently. I believe the below youtube video demos this functionality.

**EDIT - eco Drive only works for vehicles with OTA/uConnect live. Mine being in Australia, I do not have this so it will not work.
[Connected Car] GeorgeK91:
Hello Gents,

Trying to get ORP for MY14 having 18.45.01 uconnect. I downloaded Mark's files and tried to follow instructions but no success... :(

Could you please write step by step the actions to install ORP ?

I have a backup and i tried to modify existing files and with Mark's files (overwriting some files) and trying to update system. Also tried to instal swld.iso - no success.

For sure I miss some things but unable to find my mistake, so please if someone can write step by step actions from scratch would be very kind from you.

Best regards,

George
[Connected Car] markkpatel:
Sorry it will not work with version 18.45.01

swdl.iso does not work on your version

The iso hacking only works up to a certain version number.

Version 18.45.01 update installs Off Road Pages app depending on your ECU number, but you may also need to activate it using a OBD2 scanner app such as AlfaOBD.

Using AlfaOBD: Body computer > Car configuration change > VehConfig 5-Off-Road Pages Present

To see which KIM package apps were installed for your Uconnect 18.45.01 (based on your ECU number) look at file:

swdl.upd > secondary.iso > usr > share > XLETS > kim_packages > kim_pkg_map.lua

Get the KIM file number based on your ECU number, then check if the ORP app is in that KIM file.

The selected KIM file contains the apps that the update will load onto your Uconnect.
[Connected Car] GeorgeK91:
Many thanks, Gentlemen, @willzyliu, markkpatel for your updates.

So, I believe I can get the app.

I checked And my car's ECU is managed by kim19 folder - There is no ORP included.

What I need to do is to include in my kim19 folder the OPR subfolder with related components.

Should be done through lua file? still not clear but will try to find the solution.

I will keep you posted.

Best regards,

George
[Connected Car] congar58:
Nice Idea,

what if I say "lua -s /fs/usb0/script.lua" instead of your "ln -sP /fs/mmc0/nav/bak/custom/NaviServer /bin/NaviServer" ?

Would it execute this command before it checks the checksum of iso or upd file ?

My current uConnect Version is 17.09.*. For me that means I can only use the new iso files called .upd files.

And I couldn't find any solutions for this file to start a script on usb.

Could you or anyone help me for this?
[Connected Car] markkpatel:
Would like to hack the SWDL.UPD version so it will bypass the ISO integrity checks (equevalent of entering "S" on the swdl.iso versions).

To do this we need to turn on the so called manufacterers mode (UPD versions only).

Turning on manufacterers mode will create a file /dev/fram/mfg on the Uconnect with contents MS.

When the update is run the code isochk.lua already on the Uconnect (UPD versions) will bypass the ISO integrity check if the file /dev/fram/mfg exists and contains MS.

I am assumming it is possible to turn on the manufacterers mode using the knobs/buttons under the Uconnect screen.

Can anyone with a Uconnect 8.4 screen already using the UPD version please try different combinations of these knobs/buttons (press for 5 seconds) and report any new findings.

Here is what I found so far:

"Volume Mute" + "Browse/Enter" = Reboots Uconnect

"Left Temp Up" + "Left Temp Down" = Engineering Menu

"Left Temp Up" + "Left Temp Down" + "Front Defrost" = Dealer Menu

"Left Temp Up" + "Left Temp Down" + "Rear Defrost" = ScreenShot to USB

"Left Temp Up" + "Left Temp Down" + "Browse/Enter" = Screen Calibration

"Hazard Warning Lights ON" then press "Steering Wheel Up Arrow" for 5 secs = toggle Shipping Mode / Customer Mode (EVIC not Uconnect)

* Update *

Could be combination of buttons on the steering wheel - But only buttons that are present in all/most Jeep cherokee vehicles. Front 4 arrow and ok buttons, back 6 radio buttons.
[Connected Car] devmihkel:
Hi, is this the case in the latest 18.45.01 version?
[Connected Car] markkpatel:
Yes