[Roadkill]

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?

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?

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.

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.

 

[JeepinWA]

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.

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):

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.

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.

 

[BearHunterCO]

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

 

[JeepinWA]

(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).

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.

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.

 

[BearHunterCO]

Thanks a bunch, JeepinWA. I was afraid that it might be due to a new ProductID. I'm not sure if I'll try digging around for an older version, or if I might try the Linksys USB300m if I can find it for a reasonable price. Maybe that one doesn't have the same issue.

I am currently running the 15x software, as my friendly dealer updated it the last time I went in for some warranty work. So I'll probably downgrade it back to a 14x version so I can hopefully utilize the byte 128 trick to build a new swdl.iso of the 15x with some modified scripts to inject a userid/password pair in to the filesystem. I would probably also carry forward the system_module_check if I can so that I can continue to utilize the byte 128 bypass.

 

[JeepinWA]

I'll probably downgrade it back to a 14x version so I can hopefully utilize the byte 128 trick to build a new swdl.iso of the 15x with some modified scripts

The 'byte 128' trick is only half of the validation process. In order for your new ISO to be started up by the running system, you'd need to generate a new digest, sign that digest with a valid rsa key, then inject that signed digest into the ISO header. That's mostly academic, though, because you don't have a valid rsa key to begin with (although I have an untested theory on how to hijack loader.lua to allow for custom ISOs).

That said, a new ISO is unnecessary, as the 15_17_5 (and likely 15.26.1) ISO is just as vulnerable to similar attack vectors.

 

[BearHunterCO]

The 'byte 128' trick is only half of the validation process. In order for your new ISO to be started up by the running system, you'd need to generate a new digest, sign that digest with a valid rsa key, then inject that signed digest into the ISO header. That's mostly academic, though, because you don't have a valid rsa key to begin with (although I have an untested theory on how to hijack loader.lua to allow for custom ISOs).

That said, a new ISO is unnecessary, as the 15_17_5 (and likely 15.26.1) ISO is just as vulnerable to similar attack vectors.

Hmmmm...sounds like I'm further away from doing this than I had thought. I'm just now getting in to looking at the lua scripts from the 14.x versions, and I had misunderstood the byte 128 trick. I thought that it pretty much bypassed the entire ISO hash/digest check altogether, and would allow changes to some of the .sh files.

Guess it's time to re-read that whitepaper and dig through more of the code to try and wrap my brain around this...

 

[JeepinWA]

I thought that it pretty much bypassed the entire ISO hash/digest check altogether, and would allow changes to some of the .sh files.

Check out my previous post in this thread regarding loader.lua and system_module_check.lua.

 

[BearHunterCO]

Check out my previous post in this thread regarding loader.lua and system_module_check.lua.

Well, I'm getting a little bit closer. I have successfully gained root access in to the system. But of course, all of the really good stuff is in read-only mode. So, I'm going to try downloading all of it in to a virtual machine and see if I can figure out how to modify the file system and maybe write my own set of rsa keys in to the system. I've certainly learned a lot about how this system works. But I have a lot more to learn still.

My goal is actually a pretty simple one. I just want my truck to connect to my home wi-fi when it's parked out front. Then my home computer can connect to it and download any interesting data before the system powers down. Maybe make my own "Vehicle Health Report". Could also grab GPS info and keep track of where all I've driven...

 

[NetworkTV]

My goal is actually a pretty simple one. I just want my truck to connect to my home wi-fi when it's parked out front. Then my home computer can connect to it and download any interesting data before the system powers down. Maybe make my own "Vehicle Health Report". Could also grab GPS info and keep track of where all I've driven...

That's a feature I really wish my Jeep had - and would actually be willing to pay the monthly UConnect Fee if that's what was required to have it.

If I could also use that function to upload planned GPS routes as well music and playlists from my computer to the Jeep, that would be a major upgrade.

 

[Roadkill]

Well, I'm getting a little bit closer. I have successfully gained root access in to the system. But of course, all of the really good stuff is in read-only mode. So, I'm going to try downloading all of it in to a virtual machine and see if I can figure out how to modify the file system and maybe write my own set of rsa keys in to the system.

A QNX Neutrino VM is a good idea for learning/basic testing, but in order to really test a lot of the crap (like the inner proprietary filesystem image junk from Harman) you'll need full virtualization and a source for Neutrino for ARM. The libraries on the ISO are compiled for the ARM architecture and won't work on something like VirtualBox running one of those free x86 Neutrino development/evaluation VM images.

My goal is actually a pretty simple one. I just want my truck to connect to my home wi-fi when it's parked out front. Then my home computer can connect to it

One might imagine there are several ways to accomplish the overall goal without necessarily having to deal with the pain of trying to configure Wi-Fi as a client on the head unit. For example, an inexpensive virtual private server with a static IP where you can dump data from anywhere the Sprint network has coverage. Granted, connecting to home Wi-Fi has advantages for certain use cases.

...and download any interesting data before the system powers down.

One might find that it's rather painful to try to hook something on shut down. For example, if your code is expecting to trap a SIG_TERM/SIG_KILL/SIG_PWR type signal during shutdown you might find that if those execute at all then they happen after the network stack is down. There are DBUS services to register a shutdown callback, but again one might find that's tough to use in practice.

 

[vecais_dumais_laacis]

Hi. Can someone explain how/from where dc.sh is executed? I'm currently trying to "europeize" 15' grand cherokee. Seems that there is no problem adding additional maps to navigation. Only thing i'm not sure - if there is a way to override fm frequency hop.

knowledge base:
iso header contains two signatures
1) 0-63rd byte - short iso signature - only first 2048 bytes of each file checked ( or first 2048 bytes of each volume info )
this is used by loader.lua
2) 64-127th byte - full iso signature - used by system_module_check.lua

this allows to modify sytem_module_check.lua to execute some commands while installing
all modifications must be after 2048 position to pass 1st check. it is possible to patch loader.lua to skip iso check. that would allow to use any swdl.iso

currently i'm not sure on which fs this loader.lua exists
mount command on running system doesnt explain much

/dev/umass0t12 on /mnt/usb0 type dos (fat32)
/dev/umass0t12 on /fs/usb0 type dos (fat32)
/dev/etfs2 on /fs/etfs type etfs
/dev/mmc0t178 on /fs/mmc1 type qnx6
/dev/mmc0t177 on /fs/mmc0 type qnx6

 

[vecais_dumais_laacis]

source code for automatic script injection into 14.05.3 MY15 VP4 NA iso ( for others you should change offset/limits )

[C++] uconnect script injecter - Pastebin.com

this allows simpler code execution from usb than manually hex editing every time
it also adds return false to abort update process - whole idea of this script patching is to execute custom lua script and abort update without waiting for whole update install

you can make changes in existing filesystem from lua script like that:

--this code should copy tuner config from usb to device on startup
os.execute(mountpath.."/usr/share/scripts/mmc.sh start")

os.execute("echo 'mount -uw /fs/mmc0' >      /fs/mmc0/app/bin/booo.sh")
os.execute("echo 'cp /fs/usb0/tuner/* /etc/tuner/'   >> /fs/mmc0/app/bin/booo.sh")
os.execute("chmod 777 /fs/mmc0/app/bin/booo.sh")

os.execute(mountpath.."/usr/share/scripts/mmc.sh stop")

note: i already have patched boot.sh to exec booo.sh as last command
you should be very careful with boot.sh - you wont be able to enter update mode if you accidently break boot process. maybe there is some fallback - i'm not sure

 

[vecais_dumais_laacis]

by using modified engineering menu ( which allows service menu item ) it is possible to enable wifi

seems that it is enough to create file /fs/etfs/disableDRM and reboot unit to remove need to pay for wifi

also there is possibility to use wifi in client mode

edit: just tested - disableDRM hack works - wifi shows up and wifi app allows to see/change access settings. sucks that there is no sprint network in .eu

 

[vecais_dumais_laacis]

* got ssh access!
* frequency tuning to non .usa frequencies works by calling lua script - so it is possible to alter software for .eu frequencies

todo: find out where i lost navigation button after reset

 

[vecais_dumais_laacis]

* got back navigation ( factory reset somehow removed some links to files and didnt put them back )
* patched navigation to accept any map with license

todo: radio frequency unlock


edit: aaaaaand done it.

head unit is europe ready

 

[Cag340]

Hi, I'm trying to get my MY15_RA3_16_16_13 to support non-English fonts in media and contact list, looks like these are what I need based on what I see so far, listing them out for reality check:

1. Flash the recall rom into my 15 Grand Cherokee
2. Gain root access through what's documented in the whitepaper
3. Find out where the fonts are stored, hopefully not in a readonly place?
4. Copy over new fonts

Is this correct?

 

[vecais_dumais_laacis]

user interface is made in flash - you'll need to decompile some swf files and replace font with your own - then update swf back

probably these ones

HelveticaNeueLTStd-Roman.swf
MHeiM.swf
NimbusSanL-Regu.swf
UbuntuRegular.swf

in /fs/mmc0/app/share/hmi/skins/default/themeSwfs/fontSwfs/

 

[Cag340]

I'll take a look and see if the files and structure is still the same on this one. It's interesting because mHeim is supposed to be Chinese font. Could it be that the system only loads certain font under the English language setting?

It will be interesting to see if it's possible to enable other languages that seem to be present here as well, so to avoid renaming / replacing font files.

 

[vecais_dumais_laacis]

for languages look under /fs/mmc0/app/share/hmi/textarchive/
there are xmls for multiple languages

font switching code from main.swf

if (Global.region == TunerRegion.CHINA)
{
this.mCurrentFontSWFFileName = "MHeiM.swf";
}
else if (Global.market == TunerRegion.JAPAN)
{
this.mCurrentFontSWFFileName = "HangulGothic.swf";
}
else if (Global.market == TunerRegion.KOREA)
{
this.mCurrentFontSWFFileName = "HeiseiKaku.swf";
}
else if (this.mLoadedThemeSWF.hasOwnProperty( "fontSWFFileName"))
{
this.mCurrentFontSWFFileName = this.mLoadedThemeSWF.fontSWFFileName;
}
else
{
this.mCurrentFontSWFFileName = null;
}