Second Generation 2015 Ultimate Nav Research

[emulamer]

I recently traded in my 2013 coupe for a 2015 ultimate sedan. The amount of tech in this car is borderline insane, and it appears that a good portion of it is interfaced with the "Driver Information System" (DIS 2.0).

So, I'm going to research how the software running on the unit is put together and how to gain access to it.

There is inherent risk with anything of this nature. I strongly suggest you don't do any of this at all, ever. You could brick your car, void your warranty or potentially cause dangerous software malfunctions.

That said....

"Dealer mode" (engineering mode lite) can be accessed by:

1. Go to the home screen.
2. Click "Settings"
3. Scroll to the bottom and click "System Info"
4. Tap and hold on the circle in the center of the menus (the one with the arrows on it)

This is a very scaled down subset of the full engineering mode, but I haven't yet found a way in the UI to access that.

Each of the available functions is protected by a PIN code. Here are pin codes (including some for functions that aren't visible):

• software: 1358
• hardware: 4763
• dynamics: 0716
• update: 4590
• logsetting: 4259
• autotest: 4260
• password: 0428
• variant: 6172
• diagnosis: 5173
• mapcaremode: 3649

Since I don't see any obvious way to go forward with accessing the full engineering mode in the UI, I'm going to have to find a way to launch it with code....

Fortunately, the "Update" in System Info appears like it may blindly launch an executable "AppUpgrade" from the root of a connected USB drive, so I'll see where that gets me.

 

[OneFunGenesis]

sub'd because interested

 

[FLGen]

Subscribed as well. Very interested in this

 

[emulamer]

After a little further research, it does appear that the update functionality in the settings will relatively blindly execute a file called AppUpgrade on a USB drive. I made a straight script file chmod'ed +x with a few commands to get dumps of log files, directory lists, etc. to see what all exists in the environment. Looks like it copies it to /tmp/AppUpgrade and then executes it with an additional arg of -USB. As ROOT. Sweet. Based on my preliminary explorations of the partial system images copied to and booted in a VM (hooray for it being x86!) I have reason to believe that the entire root FS can be mounted writeable, and modified at will. There appears to be some level of (hardware?) firewall through the micomm (the lower level hardware/car interface that the nav unit communicates with) and that very selectively marshals any traffic through wifi/3G. Thank you Hyundai for being responsible with this. My biggest fear was getting in here and seeing that a simple hack would gain full remote access to a high level system. Looks like they are better than that, and I feel better driving the car knowing it isn't trivial to access the system! However, that isn't going to stop me investigating the rest of the system, as long as I can do it without risk of messing up the car. Next step, going to see if I can find a way to keep gathering/logging more information about the subsystems of the nav, and attempt to launch the "full engineering" mode one way or the other. Initial attempts of launching the AppEngineering binary through an AppUpgrade script weren't successful.




Non geek translation: Hyundai did a reasonable job of securing the car against unauthorized remote access via wifi or 3G. But... With access to the car and the USB port, with "root" access, it is likely possible to do anything imaginable to the car's infotainment/nav system, including anything the ECU, micomm, etc. provides access to. VERY good news for those who wish to make modifications, whether you're interested in "how do I change the splash screen" or "how do I write my own Bluelink".

 

[silver]

Keep up the good rev-engineering! I'm going to check out the menu's myself as i'm indeed interested as well to see if I can see any further information about the system itself. Out of curiosity how did you discover the "dealer mode", did you get your hands on a service manual for service techs?

 

[FLGen]

Amazing wow

 

[emulamer]

Keep up the good rev-engineering! I'm going to check out the menu's myself as i'm indeed interested as well to see if I can see any further information about the system itself. Out of curiosity how did you discover the "dealer mode", did you get your hands on a service manual for service techs?

I paid for a week of access to HyundaiTechInfo and there was a TSB about installing an update to the DIS. It helpfully mentioned a part number for a USB drive containing the update (96560-DHN15) so I googled it and found a place to buy one for about $24 ($12 + $12 shipping). The update USB stick has partclone images for the root filesystem, boot and voice recognition partition, so I just wrote them to a virtual disk. (It also has a bunch of firmware images for the other embedded systems in the car, I haven't even tried to open them up yet.)

I found the pin codes in plain text in a UI file related to "AppEngineering". I found several vague references to "engineering" in "AppSettings", plus a few references to a "pressAndHold" event, so I just went into settings and started pressing and holding on things until I found it.

 

[OneFunGenesis]

so I just went into settings and started pressing and holding on things until I found it.

LOL this is funny but how reverse engineering works sometimes!

 

[photostu]

I got $50 for a working remote start hack. Any other backers?

 

[PMCErnie]

I got $50 for a working remote start hack. Any other backers?

The Webmaster has rules against that.

______________________________

Help support this site so it can continue supporting you!

 

[OneFunGenesis]

The Webmaster had rules against that.

Approved vendors and all

 

[emulamer]

Further efforts to get the car's software running in a VM haven't been entirely successful. I found the source to rebuild the kernel (although an older revision) on lge's open source site, so I was able to get the virtual box extensions compiled and installed. It looks like it uses a multi display configuration that virtual box is not easily going to support, and there is A LOT of additional hardware that is going to be impossible to emulate, and it is questionable whether the UI will ever start without it.

One interesting thing I found, and the next path I'm going to take, is that sshd is running and root can connect (password: meego). In addition, there are kernel modules available for a couple of USB to Ethernet adapters, and also there is some interesting script of some sort in the USB code which looks like it will automatically load the module, bring up the interface and assign it an IP if a specific type of USB 2 Ethernet chipset is plugged in.

 

[emulamer]

Went ahead and ordered myself a cheap USB to ethernet adapter which has the right chipset and hopefully the right product ID (Moschip MCS7830) to trigger the built in debugging stuff to load the kernel module and give it an IP, if it's still actually enabled in the code.

In the mean time, I pulled apart the "ibox" part of the firmware update.... The ibox actually appears to be a nearly complete, mostly separate android (2.3.3) based subsystem that's glued together with the primary one through the MOST bus. This is what I'm guessing is handling the wifi and cell radios, and what is running the bluelink stuff (lots of interesting strings in the app called HKMC_TAppService).

I also think this is where the apps (all one of them) run through, and that the primary nav system has some sort of video switcher in it that handles switching between the output of the primary unit and the output from the ibox. Looking at the service manual, there's a video input connector from the ibox to the primary, then an output from the primary to the screen. Looks like the touch events from the touchscreen must go through the CAN bus so both the ibox and primary can listen.

Didn't have any luck booting these images up in in an android emulator. Best I can tell, it's based on a freescale imx53 which I thought may have a chance running in the emulator, but I know even less about the inner workings of android than I do about linux, so I'll give up on that for now and just continue digging around in the binaries until the USB adapter gets here.

It actually makes the topic of the whole android auto and apple car play even more interesting.... the primary head unit runs an intel x86 chip, so the likelihood of either being ported to that probably isn't super great... BUT this car seemingly has an additional ARM based system too (I'd be willing to bet probably the same or very similar to the system in the non-ultimate, but with the rest of the functionality running on it). So could/would Hyundai completely disable the "upgraded" half of the system in order to put carplay or android auto on it?

 

[OneFunGenesis]

Jeez, this is a lot of work and well done! You surely know your stuff .

I am surprised you don't know too much about android since it is basically a skinned linux shell. And the ARM being the "mobile" processor should be able to run Android auto...probably not apple carplay though since Apple would never put their ecosystem on something that is not tightly controlled by them....

 

[FLGen]

Wow this is impressive. Alot of information

 

[nexizen]

Does anyone know what (hardware) the 2015 Sonata is running? It supports CarPlay and if it's using the same hardware, we might have a very interesting situation on our hands.

Also of note: CarPlay and Android Auto are both available on some cars. The late-2015 Sonata for example. (Here is a video of both services being used in the same car: http://www.hyundainews.com/us/en/media/videos/42180)

 

[emulamer]

Does anyone know what (hardware) the 2015 Sonata is running? It supports CarPlay and if it's using the same hardware, we might have a very interesting situation on our hands.

Also of note: CarPlay and Android Auto are both available on some cars. The late-2015 Sonata for example. (Here is a video of both services being used in the same car: http://www.hyundainews.com/us/en/media/videos/42180)

That's actually really interesting, and implies it's not a difficult integration. After seeing this, I went and grabbed a firmware for an aftermarket head unit that supports CarPlay, and it actually runs android under the hood and is surprisingly similar to the architecture of the ARM half of the Genesis nav. Thanks for the link! Depending on how the USB port is physically hooked up and what Hyundai decides to invest, CarPlay could still be a real possibility for the ultimate nav units!

 

[OneFunGenesis]

And the ARM being the "mobile" processor should be able to run Android auto...probably not apple carplay though since Apple would never put their ecosystem on something that is not tightly controlled by them....

Quoting myself on this one haha.

 

[emulamer]

TL;DR: I have gained root SSH access to the operating DIS 2.0 system via a particular usb to ethernet adapter.

I finally got the USB adapter with the MCS7830 chipset in the mail, plugged it in, and nothing happened. Looked further into the DHAVN_UcsDaemon executable that had references to the driver module, and found some strings referencing the interesting paths /etc/lgeconfig/usb_eth_debug and /tmp/force_eth_debug. /etc/ is on the root filesystem which is mounted read-only, but /tmp/ is not! Altered the fake AppUpgrade file on the USB drive to touch /tmp/force_eth_debug, verified the file was created, then tried the adapter again.... still nothing, only the power light. Swapped back to the USB drive and pulled the logs again, and saw that the device wasn't actually even being identified, dmesg was showing: "device descriptor read/64, error -71" which is apparently some sort of generic protocol error. Google's best, vague suggestion on the matter was that it is a hardware/connection/power issue. I tried adding a powered USB hub to the mix.... USB thumb drive isn't recognized. So then I used the USB thumb drive with the fake AppUpgrade first to create /tmp/force_eth_debug, then unplugged it and plugged in the powered USB hub + 7830 ethernet adapter, and.... Link! Based on the strings in the UcsDaemon, it should have an IP of 100.1.1.100, so I gave my macbook's ethernet interface the address of 100.1.1.2, and....

Root SSH access!!

Password's "meego" if I haven't mentioned it already in another post. So... the down side of this level of access is that with the fake AppUpgrade on the USB drive, after you hit the "Upgrade" button in the UI, it looks like some parts of the UI processes get stopped (probably expecting an incoming update) until you turn the car off and back on, because none of the buttons, knobs, back button, etc. work.

Second step was getting access to the fully working system without having to do the USB upgrade trick. Looking in /etc/rc.local, there's a section with comments actually referring to IP configuration in engineering mode, one of the lines is /home/meego/myip.sh and /home/ is on a writeable partition, plus myip.sh doesn't even exist. After verifying very carefully, and double checking with one of my more linux savvy friends, I created the file, chowned it meego:meego, chmodded it 777, and added:
#!/bin/sh
touch /tmp/force_eth_debug

Crossed fingers, turned it off and back on, and verified I now have root SSH access to the full running system just by plugging in the 7830 usb ethernet adapter through a powered usb hub.

Next, I'm going to trace the dbus messages, the can0 interface, etc. to see what all the system has access to, and also see if I can determine a way to launch full engineering mode. With a little more information, hopefully I will be able to determine how I can pivot to the android "ibox" system, which is where all of the background remote control stuff seems likely to live.

 

[OneFunGenesis]

Wow! This is great work and a great force on the USB link! This had to take multi hours and is seriously impressive. I am following this thread very closely