The author simply wants to pwn his car! They bought a 2021 Hyundai Ioniq SEL to drive and play with. The author wanted to target In-Vehicle Infotainment (IVI) system. Additionally, there is a mode called Engineering Mode which requires a special code that can be fond in online manuals.
While reviewing the debug diagnostics, they learned they could get some logs by plugging in a USB drive. Another option was ADB over TCP, which would be awesome. The ADB appeared to be off during a network scan so they turned to the logs. The logs had information about running processes and other things.
One thing that stood out from the logs was D-Audio2V IVI for Hydunai. They downloaded the source code for this project to check it out. While on the update website for hyundai, they found firmware files for this, but it was in an encrypted zip file. Yikes!
Zip encryption is vulnerable to plaintext attacks. So, if we know a set of bytes, then we can use the magic tool to recover the key. The known plaintext is a high ask though... one solution is to find similar updates they include some files that are the same. They found a set of files that had the same CRC, indicating they were the same.
Using the tool doesn't work though. How come? Improper settings. While reading the issues page, they learned that the plaintext needs to be the original compressed version. We don't know the settings for the compressed file though! The author brute forced all of the zip settings until it FINALLY worked.
With the file system unencrypted, they started reverse engineering the image. They noticed that the ADB TCP setting in the Engineering Mode set the IP address of eth0 to 192.168.7.110. To make it even harder, the MAC address had to be F4:50:EB:2E:58:00. After many attempts, including the use of ethtool and RtPGtoolUI from Realtek, they were able to burn the MAC address of the adapter. Sadly, the adapter always goes to eth1 instead of eth0.
With this dead end being hit, they went after the firmware update process. The regular image didn't have this update though; instead, it was in an encrypted image file. From reverse engineering the file system, they found a bash script that was decrypting the image - it was the key listed in SP800-38A. The same thing was done for firmware signing as well - they searched for the public key and found the private key.
The reversing process is not always easy! This is an awesome example of defeating the encryption put onto boot images and other things.