These days modern cars are nothing if not a grouping of networked software held together by bits of hardware. This is reflected not only in the rapidly increasing number of ECUs, but also infotainment systems and all-glass cockpits. For better or worse, this offers many exciting hacking possibilities, which [greenluigi1] was more than happy to explore with their new 2021 Hyundai Ioniq SEL last year. Naturally, Hyundai then proceeded to ‘fix’ these vulnerabilities, offering the exciting chance to test the Hyundai engineers’ homework, and proceed to bypass it again.
When we last left off in [greenluigi1]’s adventures, the Hyundai D-Audio 2V Linux-based infotainment system (formally called in-vehicle entertainment, or IVI) in question had been convinced to run custom applications after a fair bit of effort to get root access via the Engineering Menu and some firmware image hacking. Joyous hacking and exploration of the car’s CAN network and RPC messaging system ensued. Then Hyundai released a new firmware image, after months of silence and all old firmware images pulled from the download page.
In this new firmware image, big changes were visible right off the bat, with two different ZIP files instead of the single one from before. One of these ZIP files also couldn’t be decrypted any more with the old key. Unfortunately for Hyundai, the curse of backwards compatibility with older IVIs meant that the ZIP targeting headunits running the older firmware also contained the key for the new ZIP file.
Other changes included some further obfuscation to this key and the public key used for firmware hash verification, which also involved using a Micom RPC call via the CAN bus to obtain some vehicle specific information. Unfortunately, this is where Hyundai’s engineers seemed to have stopped copying reference code samples, and used a unique RSA private key to sign firmware images with. Fortunately, they did not bother to check whether the updater actually always verifies the signature, allowing for unsigned code to be installed.
All in all, a fascinating bit of reverse-engineering and sheer stubborn persistence, just so that the IVI that’s in your car can run the applications which you developed. We’re looking forward to the next installments in this series as the ball is once again firmly in Hyundai’s court.
I wonder who actually makes the IVI for Hyundai. Car manufacturers are most often merely integrators of components manufactured by Tier 1 suppliers. From earlier reports on Ioniq’s bead unit hacks it appears that that Tier 1 may be LGE, in which case it would be LGE’s (or LGE’s subcontractor’s/subsupplier’s) homework and not Hyundai’s that was challenged. Can someone please confirm.
Notu sure about Hyundai, but part of Ford’s ECU code was done by underpaid group of 25 year old guys, working remotely and scattered all over small towns in Poland. Their work was then “reviewed” and “approved” by another contractor in Warsaw (where review was “does it compile? good enough then.”) and likely sent further to teams in US.
You surely have an emotional view of this situation. However, I question your “data points” and your allusions. You end up sounding angry, but I’m not sure at whom, Poles who did and the work, the lower cost of living in Poland, contacting, remote work, Americans who accepted the work, Ford? … As much as i think the phrase is dismissive, i think an “OK boomer” response is appropriate to your rambling post.
I can’t speak for Hyundai vehicles, but after reverse-engineering my Honda Civic’s IVI, it seems that most of the software (custom Android apps and Android native libraries) is written by Mitsubishi and licensed to Honda. I wouldn’t be surprised if other manufacturers do something similar. Although from first glance it seems like the Hyundai software is more custom/low-level, whereas Honda just leverages Android on top of an NVIDIA Tegra 3 SoC. As for hardware, the physical display looks similar to the Honda one, basically a tablet with buttons on either side.
That sounds very plausible. Car manufacturers are for the most part specifiers and integrators of high level components made by automotive suppliers. There days when a mass production car is designed and manufactured more or less wholly by the car manufacturer are long gone, if they ever even existed. Perhaps the Model T was made from raw materials wholly by Ford.
The Hyundai Ionic’s brake lights are terrible, could get the car hit from behind, especially in single pedal mode where they don’t light up until the car is completely stopped. https://www.youtube.com/watch?v=U0YW7x9U5TQ
Instead of trying to keep people from fiddling with the entertainment software, Hyundai’s software people should fix the dangerous brake lights.
Again, probably not Hyundai’s software people since Hyundai probably wrote no brake controller software, but Hyundai’s safety people surely wrote the specs for the lights. Sounds like a safety issue that should be reported to NHTSA (or it’s equivalent outside the US).
I saw a video describing the brake issue. It does look like an integration issue between the powertrain controller and the brake or exterior lights controller (not sure of Hyundai’s architecture, but I’m guessing that the two functions aren’t integrated into one unit). Anyway, the responsibility for the integration is likely with Hyundai’s engineers who would have written the specs. However, it appears that although the behavior is unexpected to a typical driver, the car may actually comply with the regulations. This, all bets are off whether and when this issue will be addressed.
Automotive security and updates are too important to be left to corporations with limited incentives to improve. Software (including non-standard CAN messages) for vehicles should be publicly documented. It would make repairs cheaper for consumers and make it easier for the open source community to audit vehicles. I’ve been trying to gather support for a common reverse engineering effort for Hondas: https://github.com/librick/ic1101. Glad to see other work being done for Hyundai.
You’re merely making a political argument for open source. There are plenty of open source programs out there that aren’t secure. While there are many clear benefits to open source, security isn’t one of them. In the end, open source development takes resources, e.g. time and money, just like “commercial/proprietary/etc.” software. Merely exposing security issues doesn’t get them fixed.
Note, in case this helps anyone: this car is called the Ioniq 5, and the trim level is the SEL. The original post left out the “5”.
There is also an Ioniq 6, which shares most of the same parts but is in a differently-shaped body. The Kia EV6 and Genesis GV60 also share most of the base architecture.
Actually the car in question here was the original Ionic Hybrid which was recently discontinued after they released the newer EV-based Ionic line.
https://www.hyundai.com/worldwide/en/eco/ioniq-hybrid/highlights
My car is actually the Hyundai Ioniq. Without a 5 in the name. It is a compact liftback and was Hyundai’s first series of vehicle that used the Ioniq name. They stopped production of them in 2022.
https://en.wikipedia.org/wiki/Hyundai_Ioniq
Great hacking! Hyundai should hire you as a consultant. Though they probably would urge you to sign an NDA.
“Unfortunately, this is where Hyundai’s engineered” – Typo?