uConnect 15.26.1 is buggy; I want to downgrade. - Page 17 - Jeep Garage - Jeep Forum

Go Back   Jeep Garage - Jeep Forum > Jeep Platform Discussion > Grand Cherokee - WK2 - > Audio/Visual/Navigation

Join Jeep Garage Today
Reply
 
Thread Tools Display Modes
 
  #193  
Old 01-03-2016, 03:10 AM
Senior Member
 
Join Date: Sep 2013
Posts: 1,287
Thanks: 46
Thanked 155 Times in 126 Posts
Rep Power: 2809
Roadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond repute
Quote:
Originally Posted by digi View Post
This is exactly the use case. With a replacement RA4 at $1k I'd really like to avoid bricking it.
Reasonable, but it is relatively easy to avoid if one were to code hooks for config that executes files only on removable storage like sd0 or usb0. If there are problems, eject the device, reboot, and everything reverts to stock operation.

Quote:
I was able to decode system_module_check.lua with unluac and at first glance the magical "S" marker still appears to be honored, so it must be patched elsewhere.
The ISO runs a crypto sig check against itself and compares the sig against the checksum result. You have unluac. You have the ISO. You understand the bytecodes. There's zero forward security.

It's been handed to you.

Reply With Quote
Sponsored Links
Advertisement
 
  #194  
Old 02-14-2016, 04:29 PM
Premium Member
My Jeep: 2015 KL
 
Join Date: Jan 2016
Posts: 9
Thanks: 0
Thanked 1 Time in 1 Post
Rep Power: 341
JeepinWA is on a distinguished road
Re: uConnect 15.26.1 is buggy; I want to downgrade.

Quote:
Originally Posted by digi View Post
I was able to decode system_module_check.lua with unluac and at first glance the magical "S" marker still appears to be honored, so it must be patched elsewhere.
I've spent some time on this in the last few days as well. From what I can tell, they moved the magical "S" marker onto the device, specifically, into /dev/fram/mfg:

This is roughly what I believe is happening (variable names are my own):
(disclaimer: my reverse engineering-foo is weak and I've never coded in Lua before - so my results might be completely off):

Code:
  byte_to_get = 0
  mfg_mode_flag = installerhelper.ih_get_file_byte("/dev/fram/mfg", byte_to_get)
  print("system_module_check: mfg_mode_flag = ", mfg_mode_flag)
  byte_to_get = 1
  mfg_skip_flag = installerhelper.ih_get_file_byte("/dev/fram/mfg", byte_to_get)
  print("system_module_check: mfg_skip_flag = ", mfg_skip_flag)
  m_byte = string.byte("M")
  if mfg_mode_flag == m_byte then
    s_byte = string.byte("S")
    if mfg_skip_flag == s_byte then
      print("system_module_check: Mfg install mode, skipping file integrity check")
    end
  else
    print("system_module_check: Normal install mode")
    ...

The mess of loops in the 'normal install' block make it difficult to reverse, but it appears to grab keys from '/etc/keys' and validate the ISO's rsa sig via openssl (based on output from 'strings').

It does seem like the best way forward would be use use the vulnerable 14_05_03 installer for the initial jailbreak, which would allow you to compromise the on-device validation of the newer updates. However, I've not been able to find a copy of that ISO to test my theory (anyone have a copy?).

I'm not sure if any of this is helpful, but wanted to contribute what I've found so far.
Reply With Quote
  #195  
Old 02-15-2016, 02:33 AM
Senior Member
 
Join Date: Sep 2013
Posts: 1,287
Thanks: 46
Thanked 155 Times in 126 Posts
Rep Power: 2809
Roadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond repute
Quote:
Originally Posted by JeepinWA View Post
However, I've not been able to find a copy of that ISO to test my theory (anyone have a copy?).
Hey, welcome.

Premium members of the forum have access to the VIP area with firmware images that have been hosted elsewhere. Of course, there's no official SHA1 or whatever published by FCA for the images, so you're rolling the dice there. BTW, the version after 14_05_03 (i.e. 14_25_5) is vulnerable as well and also has various functionality fixes for uConnect. I personally find 14_25_5 superior to the 15_26_1 recall version, because it's more stable on my vehicle—especially the nav functionality. Hell, problems with 15_26_1 are the reason I started this thread.

Returning to the superseding thread topic: 15_26_1 moved the boot.sh file into the crappy harman firmware image format file on the ISO, making it inconvenient to access/analyze. Not that the file is much different from before, but if you're interested in understanding how the system works overall it's quite instructive. You might check the boot.sh from an earlier ISO or online, as at least one person has uploaded the contents of the ISO to github. As a matter of fact, it's probably better to get a good sense of how the old firmware worked before they ineptly tried to obscure how some aspects function in 15_26_1.

Quote:
which would allow you to compromise the on-device validation of the newer updates.
That is true. Semantically, I consider this to be "on-ISO validation" because with this approach the ISO itself is the source of the validation logic.
Reply With Quote
  #196  
Old 02-15-2016, 03:47 AM
Premium Member
My Jeep: 2015 KL
 
Join Date: Jan 2016
Posts: 9
Thanks: 0
Thanked 1 Time in 1 Post
Rep Power: 341
JeepinWA is on a distinguished road
Re: uConnect 15.26.1 is buggy; I want to downgrade.

Thanks for the tips on the VIP area and the other 14 versions, I might give that a go.

I've been working with 15_17_5, which is what uconnect's site says is the latest for my Jeep. I've taken a good read through boot.sh and just about any other plain-text files on the image. I've also been trying to reverse the Lua scripts as I follow the boot/update process.

Quote:
Semantically, I consider this to be "on-ISO validation" because with this approach the ISO itself is the source of the validation logic.
I don't disagree with your 'zero forward security' statement from earlier, but here I was referring to the checks done by the running system to determine whether or not the USB stick contains a valid update image. This is what's got me hung up at the moment. I've been poking at the ISO with a hex editor to see which files cause which step of the validation to fail with the hope of finding a way to prevent the ISO from self-validating.

If you, or anyone else, are working at poking around at the installer, I'd love to compare notes.
Reply With Quote
  #197  
Old 02-15-2016, 08:19 AM
Senior Member
 
Join Date: Sep 2013
Posts: 1,287
Thanks: 46
Thanked 155 Times in 126 Posts
Rep Power: 2809
Roadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond repute
Quote:
Originally Posted by JeepinWA View Post
I've also been trying to reverse the Lua scripts as I follow the boot/update process.
If you have Unix/cygwin and unluac, you can decompile all the lua files on the ISO at once with a one-liner using xargs or find. I definitely recommend doing this... much better than using strings or doing one-off decompilation.

Quote:
This is what's got me hung up at the moment. I've been poking at the ISO with a hex editor to see which files cause which step of the validation to fail with the hope of finding a way to prevent the ISO from self-validating.
When you get to the crypto sig validation script I believe you'll find that flipping a few bytes on a single if statement line is all you need to do.
Reply With Quote
  #198  
Old 02-16-2016, 04:02 PM
Premium Member
My Jeep: 2015 KL
 
Join Date: Jan 2016
Posts: 9
Thanks: 0
Thanked 1 Time in 1 Post
Rep Power: 341
JeepinWA is on a distinguished road
Re: uConnect 15.26.1 is buggy; I want to downgrade.

Quote:
much better than using strings or doing one-off decompilation
I *could* decompile them all at once, but I've only needed to reverse 2 or 3 files, so it wasn't necessary for what I was after. Also, unluac is only the first step - there's a lot of manual work to be done to actually make sense of the recovered scripts. I've also found helpful information from 'strings' that wasn't in the reversed scripts.

Thanks to your suggestion on 14_25_5, which still has the Lua scripts in plain-text, I was able to gain a much better understanding of the ISO validation process (and also confirm some assumptions on the new versions of those scripts).

Quote:
When you get to the crypto sig validation script I believe you'll find that flipping a few bytes on a single if statement line is all you need to do.
The ISO's crypto signature is checked in 2 places. The first is done by the running system (loader.lua) to determine whether or not the ISO is valid 'enough' to start the update procedure. The second validation is done 'on ISO' by system_module_check.lua, using essentially same process (the steps are described in this 2012 post on Toyota's system, although some of the details are a little off http://haxor.fi/?p=187).

The loader.lua check can't be defeated by editing anything on the ISO but after taking a closer look at how the crypto signature was generated, I was able to find where on the ISO it was safe to make edits without disrupting the computed signature. I'd love to get to the point of being able to self-sign a full ISO but for now I'll settle for running a modified boot script.

Unfortunately, system_module_check.lua also computes and compares a hash of the full ISO, which my changes caused to fail. I tried a few different ways of setting the new "magic S" flag before I realized it was easier to allow the script to complete its hash comparison, then force it to discard the result entirely.

This is a long-winded way of saying that I completely agree with you, and thanks for some of the tips. It did come down to changing just a few bytes. I'm now running a modified 15_17_5, and starting to look into how I want to take advantage of my new found access.
Reply With Quote
  #199  
Old 02-16-2016, 04:21 PM
Senior Member
 
Join Date: Sep 2013
Posts: 1,287
Thanks: 46
Thanked 155 Times in 126 Posts
Rep Power: 2809
Roadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond repute
Quote:
Originally Posted by JeepinWA View Post
Unfortunately, system_module_check.lua also computes and compares a hash of the full ISO, which my changes caused to fail. I tried a few different ways of setting the new "magic S" flag before I realized it was easier to allow the script to complete its hash comparison, then force it to discard the result entirely.
Yep. Because this involves in-place editing of the iso with a hex editor, it's far simpler (and safer!) to do it that way.

Quote:
Also, unluac is only the first step - there's a lot of manual work to be done to actually make sense of the recovered scripts.
Curious. Hypothetically speaking, I'd anticipate that the unluac of the 14_25_6 files would be very clear cut and not obfuscated at all, retaining friendly variable names, method names, etc. Overall, I'd anticipate those decompiled lua files would readily lend themselves to human analysis if one were so inclined.

Quote:
I'm now running a modified 15_17_5, and starting to look into how I want to take advantage of my new found access.
Nicely done.

I suggest gaining root ssh access and using the qon command from the shell to run some persistent daemons of your own creation. You will long for bash, but it's not present.

Hook from boot.sh to persistently run those scripts from a removable storage device for easy "unbricking" should things somehow go awry in the future. You will find it is trivial to access d-bus from the command line and thus control the vehicle environment; wholescale unluac will come in handy when you're trying to understand why the d-bus services work the way they do (and how poorly coded they are).

You will be surprised how long it takes for the system to truly boot and get to your hook code in boot.sh. I advise extreme caution with boot.sh mods because these geniuses run the update check at the *end* of a successful boot.sh execution, thereby raising the specter of bricking the unit hard if your mods cause the boot.sh execution to fault.

You can also scp down the contents of the active system, which will include aspects not readily accessible from the ISO.

Several wired ethernet USB chipsets are supported, and supported adapters like the Plugable USB2-E100 are cheap on Amazon. It supports crossover, so you won't need a switch.

I'd also suggest truly enabling the firewall. Though you're using a "secured" recall release, altering the firewall config makes 14_25_6 as safe to use as the subsequent patched releases. As an aside, I can't believe they had the firewall loaded and running in the "hackable" firmware versions... they simply didn't bother to configure it to protect anything. Sheer incompetence. There are true benefits to configuring the firewall: it can allow you to block FCA's creepy vehicle tracking and protect against the security vulnerabilities that continue to exist in the "secured" recall firmware, while also leaving the E-911 button functional.

Have fun.
Reply With Quote
  #200  
Old 02-16-2016, 06:44 PM
Premium Member
My Jeep: 2015 KL
 
Join Date: Jan 2016
Posts: 9
Thanks: 0
Thanked 1 Time in 1 Post
Rep Power: 341
JeepinWA is on a distinguished road
Re: uConnect 15.26.1 is buggy; I want to downgrade.

Quote:
I'd anticipate that the unluac of the 14_25_6 files would be very clear cut and not obfuscated at all, retaining friendly variable names, method names, etc
Most of the scripts in 14_25_? are clear-text. 15_17_5 has everything compiled (not sure if they did it for performance or obsecurity), and reversing the bytecode has been hit-or-miss when it comes to maintaining variable/object naming. Take a look at the previous code snippet posted by Digi for an example. It still took some work to map the function calls and variables back to something meaningful. Not difficult, but the effort was non-zero.

Quote:
You can also scp down the contents of the active system, which will include aspects not readily accessible from the ISO
I used a hook into boot.sh to copy down system files and get snapshots of the OS environment. This is what led me to understanding how the crypto sigs were generated. Having network access will certainly make this much easier, but I wasn't willing to pay to activate the Wifi.

Quote:
Several wired ethernet USB chipsets are supported, and supported adapters like the Plugable USB2-E100 are cheap on Amazon
I just got the 'delivered' notice from Amazon =)

Quote:
As an aside, I can't believe they had the firewall loaded and running in the "hackable" firmware versions... they simply didn't bother to configure it to protect anything. Sheer incompetence.
They're not completely incompetent...I mean, they did a great job of protecting private IP space *from* the headunit.

Code:
TRANSLATION RULES:
nat on en0 from (uap0:network) to any -> (en0) round-robin
nat on ppp0 from (uap0:network) to any -> (ppp0) round-robin

FILTER RULES:
scrub in all fragment reassemble
pass in all
pass out all
block drop out on ppp inet from any to 10.0.0.0/8
block drop out on ppp inet from any to 172.16.0.0/12
block drop out on ppp inet from any to 192.168.0.0/16
block drop out on ppp inet from any to 255.255.255.255
My background is in large-scale *NIX and network engineering - so I plan on treating this just like any other box I run, and locking it down as much as possible.
Reply With Quote
  #201  
Old 02-16-2016, 11:17 PM
Senior Member
 
Join Date: Sep 2013
Posts: 1,287
Thanks: 46
Thanked 155 Times in 126 Posts
Rep Power: 2809
Roadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond reputeRoadkill has a reputation beyond repute
Re: uConnect 15.26.1 is buggy; I want to downgrade.

Quote:
Originally Posted by JeepinWA View Post
Most of the scripts in 14_25_? are clear-text.
I believe you'll find that's not the case once you analyze how the services work. Have you gotten to those yet?

Quote:
reversing the bytecode has been hit-or-miss when it comes to maintaining variable/object naming.
That's unfortunate. I'd expect it to be substantially more straightforward when analyzing the compiled lua from the 14_* series... in fact, I'd venture that "zero effort" would be an apt description. For example, does your unluac handle decompilation of the isochk.lua file from 15_* with zero effort? How about all those dbus-related compiled lua scripts from the 14_* series?

Quote:
I used a hook into boot.sh to copy down system files and get snapshots of the OS environment. This is what led me to understanding how the crypto sigs were generated.
That's definitely one way to do it.

Quote:
They're not completely incompetent...I mean, they did a great job of protecting private IP space *from* the headunit.
Heh. That doubled the "WTF". I tried to envision an environment where this would 1) be a real problem, 2) where this would be a reasonable solution to the putative problem... and 3) no one decided to protect the actual device itself while they were in there.

Hey, maybe all those unprotected headunits in their dev lab were remotely exploited, turned into a botnet, and then started to destabilize their LAN—so some bright spark decided to solve the problem by configuring the on-device firewall to drop those packets. See? It all makes sense now... haha.
Reply With Quote
  #202  
Old 02-17-2016, 01:12 PM
Premium Member
My Jeep: 2015 KL
 
Join Date: Jan 2016
Posts: 9
Thanks: 0
Thanked 1 Time in 1 Post
Rep Power: 341
JeepinWA is on a distinguished road
Re: uConnect 15.26.1 is buggy; I want to downgrade.

Quote:
Have you gotten to those yet?
I have not. I'm still working on getting SSH access. Fun fact: the new D-Link DUB-E100 models aren't supported by existing drivers on the headunit. It took almost 3 hours and many,many Google searches, before I finally got it loaded. Next step is to rewrite and reload the firewall rules, then package everything else into clean boot script.

A quick tip for anyone else following along - I got tired of resetting the radio to run my scripts from boot.sh, so I uploaded a modified version of 'dc.sh' that can be run on-demand from inside the Engineering Menu.

Quote:
I tried to envision an environment where this would 1) be a real problem, 2) where this would be a reasonable solution to the putative problem... and 3) no one decided to protect the actual device itself while they were in there.
That kind of filter is usually seen at a network edge, where you want to prevent garbage (spoofed or accidental) from leaving your network. I'm wondering if it has something to do with the network environment, or a misunderstanding of it. It's possible they thought they *were* protecting it by dropping all traffic to the "outside".

I say this because they have these same prefixes in a table called 'public' on the new versions (and because I'm hoping nobody is that incompetent):
Code:
table <public> const { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 255.255.255.255/32 }
Although, I don't see that table actually used in the running filters. I'm tempted to find this 'RChen' guy and ask.

Quote:
Originally Posted by digi View Post
I'm thinking about taking some ballsy shortcuts like using the Lua update tooling from 14.05.03 and seeing if it'll install 15.17.5. If it works, it would save me the hassle of analyzing the new bytecoded Lua scripts and figuring out exactly how FCA/HK mitigated the sum bypass trick.
Not sure if you're still following this thread, but I believe I now know enough about the update process to be of some help with that version.
Reply With Quote
  #203  
Old 03-02-2016, 02:54 PM
Premium Member
 
Join Date: Mar 2016
Posts: 4
Thanks: 2
Thanked 0 Times in 0 Posts
Rep Power: 0
BearHunterCO has disabled reputation
Re: uConnect 15.26.1 is buggy; I want to downgrade.

I am also looking to get access to the UConnect system. Basically, I am trying to get either SSH or Telnet access in to it so that I can run dc.sh and collect data from it via automation. I purchased one of the DUB-E100 adapters, but as you pointed out, the current hardware version apparently doesn't work (I have h/w version C1 of the DUB-E100, and it won't even turn on the link light for me).

Alternatively, I may just set up a Raspberry Pi to listen to the D-Bus if that port is still wide open...but that is dependent on getting a working network connection.

If you have any pointers on how to get this done, I would greatly appreciate hearing about it. Otherwise, I'll just keep watching this thread :-)

--BJ
Reply With Quote
  #204  
Old 03-02-2016, 04:02 PM
Premium Member
My Jeep: 2015 KL
 
Join Date: Jan 2016
Posts: 9
Thanks: 0
Thanked 1 Time in 1 Post
Rep Power: 341
JeepinWA is on a distinguished road
Re: uConnect 15.26.1 is buggy; I want to downgrade.

Quote:
Originally Posted by BearHunterCO View Post
(I have h/w version C1 of the DUB-E100, and it won't even turn on the link light for me).
It looks like C1 has the same PID (0x1a02) as the D1 series, which makes me think it might require the new ASIX drivers as well. Either way, the headunit knows nothing about that PID, so it won't autoload any drivers (thus, no lights). You'll either need an older E100 that matches the expected PID (0x3C05), or you'll need to manually load the drivers (as done in dlink.sh).

Quote:
Alternatively, I may just set up a Raspberry Pi to listen to the D-Bus if that port is still wide open...but that is dependent on getting a working network connection.
You haven't specified which uconnect version you have, but in the 15_* versions I've seen, D-Bus is no longer listening on the network (the config block is commented out with a note about it being 'for security'). Even if it were listening on tcp, the default pf (firewall) rules block access to most ports.

Quote:
If you have any pointers on how to get this done, I would greatly appreciate hearing about it. Otherwise, I'll just keep watching this thread :-)
I believe telnet access is wide open to the the local (USB) network, so if you can find a version of the E100 that works (is auto-configured), that's probably your fastest way in. I haven't tried telnet, so I can't tell you if it requires credentials - or what those might be.

Any other method will require you to gain shell access. For that, I would suggest reading the IOActive whitepaper which was posted earlier in the thread. The specific methods they used won't work for 15_*, but should give you a pretty good starting point.
Reply With Quote
The Following User Says Thank You to JeepinWA For This Useful Post:
Reply

Tags
uconnect

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Oil life algorithm still buggy Roadkill 2014+ Jeep Grand Cherokee Ecodiesel 3.0 7 01-19-2015 09:33 PM
Want to Downgrade from my 2005 REC NAV jsquire1 Troubleshooting/Problems 3 11-14-2013 08:45 PM
The Buggy :: 2012 Jeep Grand Cherokee SRT8 Challenger15 Member Garage Discussions 0 01-04-2013 08:48 AM
My system downgrade - Finished w87will Audio, Video, Navigation & Electronic Modifications 80 10-27-2010 11:49 PM

Powered by vBadvanced CMPS v3.2.3

All times are GMT -5. The time now is 01:16 AM.


Powered by vBulletin® Version 3.8.8 Beta 4
Copyright ©2000 - 2016, vBulletin Solutions, Inc.
Copyright 2012 - JeepGarage.Org
The Jeep Grand Cherokee Owners Community

JeepGarage.org is in no way associated with or endorsed by FCA US LLC. Chrysler, Dodge, Jeep, Ram, Mopar and SRT are registered trademarks of FCA US LLC.