1 Introduction

From 2018 to 2021, the cyber attacks on vehicles increased to 125% [1], so automotive cybersecurity has become a research trending topic. In particular, connected vehicles are prone to remote attacks and the infotainment can be considered one of the most vulnerable attack surfaces of the vehicle.

Preliminary studies on vehicle vulnerability assessment trace back to 2010 [2], wherein the authors showcased the ability to inject messages into the CAN bus communication and manipulate the Electronic Control Unit’s (ECU) behavior. This initial analysis was expanded upon in [3], where the authors delved into the attack surfaces of connected vehicles. The pivotal recognition of the need to integrate cybersecurity protection mechanisms and solutions into vehicles emerged in 2014. This realization materialized when Miller and Valasek [4] effectively compromised a Jeep Cherokee. Following these attacks, numerous papers in the literature have documented other highly significant incidents [5,6,7]. The prevalence of cybersecurity attacks in the automotive domain prompted the automotive industry’s supply chain to contemplate solutions for addressing these security issues. In 2022, both the regulation UNECE WP29 R155 [8] and the standard ISO 21434 [9] on vehicle cybersecurity were published, signaling a concerted effort in this direction. Nevertheless, finding a singular, comprehensive solution remains complex. Consequently, vulnerability assessment and penetration testing activities persist as the foremost strategies to mitigate security issues.

For this aim, at the beginning of 2022, we started a vulnerability assessment of the In-Vehicle Infotainment (IVI) system Gen5W_L firmware which is part of Hyundai, Kia, and Genesis vehicles. As result, we found different issues that allow us to create our customized firmware. This study is part of one of our research activities to identify vulnerabilities in complex computer systems and publish the achieved results following the responsible disclosure process. This is not the first work that we have done in this field. At the end 2020, we published the [CVE-2020-8539]Footnote 1 that mainly targeted Gen5 IVI. This activity generated the KOFFEE (Kia OFFensivE)Footnote 2 exploit. It may allow an attacker in Kia Motors Head Unit (HU) to inject unauthorized commands, by executing the micomd executable daemon, to trigger unintended functionalities.

Leveraging the experience got with the Gen5, we analyzed a Gen5W firmware and, from a security perspective, we found a well-defined firmware with several security measures like the combined usage of different cryptosystems as public-key and private-key. However, we were able to discover several security issues, that allow us to create and encrypt a customized firmware and install it on a Gen5W LGE based IVI system of a Hyundai group motor vehicle. Upon concluding our work, we conducted a responsible disclosure with the Hyundai Motor Group, resulting in the publication of the following CVEs: CVE-2023-26243,Footnote 3 CVE-2023-26244,Footnote 4 CVE-2023-26245,Footnote 5 and CVE-2023-26246.Footnote 6

1.1 Contributions and limitations

As already detailed above, we selected a Gen5W_L multimedia device of the Hyundai Motor Group. As reported in [10], the Gen5W_L multimedia devices (radios, head units) have been installed in Kia, Hyundai, and Genesis cars since 2016. To find out the software version in the Head Unit (HU), it is necessary to enter the setup menu of the infotainment and look for the System Information option. In our work, we use an Infinity 96560-G7230VC8 IVI system, which installs LG firmware, and in particular, our version is AE_E_PE_EUR.S5W_L001.001.211214.

Hyundai Motor Group allows anyone car-owner to update its software by using the free available program “Navigation Updater” that enables a user to download the different firmware versions and install it on a USB key or SD card. This program allows us to download the firmware by choosing the model and the country area. On January 2022, we download the last version (AE_E_PE_EUR.S5W_L001.001.211214) for our infotainment system, which was about 27 GB. Thus, the outcome of our activities can be summarized in the following findigs’ list:

  • With respect to the previous work, we replace and customize an entire vehicle component, the IVI firmware, rather than solely exploiting vulnerabilities of a component;

  • Compute and read the encrypted AES-CBC 128 key;

  • Extract the RSA public key;

  • Decode the AES-CBC 128 key using the previous RSA public key;

  • Compute the SHA256 of the content of each file;

  • Discover the algorithm that generates the Initialization Vector (IV) for the AES-CBC cryptosystem;

  • Generate the Initialization Vector (IV);

  • Encode and decode each file with the AES-CBC 128 Key and the IV;

  • Bypass the check of the digital signature during the firmware installation by upgrading AppDMClient binary patch in Head-Unit;

  • Remotely control the Gen5W_L IVI system by injecting remote commands that impact also the CAN bus into M-bus, B-bus and C-bus. In particular, we forge CAN bus frames like we trigger services from the telematic app, e.g., Bluelink. This is possible only leveraging 1-Day exploit (AppNavi) or using our custom firmware;

  • Control and manage the cellular connection of the Head-Unit.

Concerning the limitations, our approach exploits a potential common vulnerability found in the MbedTLS library. However, the firmware exploitation and installation are specifically targeted towards an IVI system within the Hyundai Motor Group. While this does not restrict the application of our process flow to IVIs of other brands, the procedures detailed in our work may vary significantly.

1.2 Structure of the paper

The rest of the paper is organized as follows. Section 2 contains the related work, while Sect. 3 provides an in-depth exploration of the Chimaera attack’s timeline, describing the various phases. Each phase is examined in dedicated sections, spanning from Sect. 4 to Sect. 9, we describe the firmware structure analysis and the custom firmware installation. Section 10 outlines the installation process of the custom firmware, while Sect. 11 delves into post-exploitation attacks utilizing both CAN and cellular connections. Section 12 describes the tool that we created to perform the attack and to be used to replicate it. Then, Sect. 13 offers insights into the lessons learned throughout.

2 Related work

The litterature about cybersecuirty attacks to vehicles has to date back to 2010. In [2], the authors presented the first experimental studies and analysis of vehicle’s vulnerability. They demonstrate the fragility of the underlying intra-vehicle network by proving that an attacker can be able to inject CAN messages and alter the behavior of an ECU. Checkoway et al. [3] analyse the external attack surface of a connected vehicle by considering the I/O channels of the car, both physical and (short and long-range) wireless connections.

In 2014, the first successful attempts to hijack a vehicle was made by Miller and Valasek [4] is the one to the Jeep Cherokee. This proved that modern vehicles can be hacked like traditional PCs or smartphones. In 2015, both AUDI, Tesla and General Motors have been attacked. The AUDI TT airbag system has been hijacked [11] as well as other functions by exploiting a zero-day flaw in third-party software. On the other hand, the Tesla Model S, which is the world’s most connected car, after 2 years of in depth hacking, was hacked by Rogers and Mahaffey [12]. The same model was remotely hacked [13] in 2016 by a team of Chinese researchers that caused a havoc. Then, a 29-year-old software developer figured out a way to attack GM cars by using a personally revised version of OnStar, which is a built-in system built that allows owners to remotely manage some vehicles functionalities. The tampered version, called OwnStar activates some of the functionalities of OnStar by simply attaching a device somewhere on the targeted car. Similarly, the official BMW web domain and ConnectedDrive portal was attacked [14]: a research discovered two zero-day vulnerabilities in both of them. The year after, 2016, other attacks are reported. Mitshubishi Outlander hybrid car was hacked [15]: the alarm can be turned off via security bugs in its on-board Wi-Fi. Nissan Leaf was hacked via Mobile app and Web Browser [16]: once connected, the vehicle’s engine and brakes could be controlled remotely. The proliferation of automotive offensive security studies in the last decades increases over and over. Among the others, we recall the remote attack on the Bosch Drivelog Connector OBD-II Dongle pointed out by the Argus Research Team [17]. The vulnerabilities allowed the attackers to stop the engine of a moving vehicle using the drivelog platform. Also in 2017, Tesla model S was remotely hacked by the Keen Security Lab [18] that discovered a vulnerability allowing a full attack chain to implement arbitrary CAN BUS and ECUs remote controls on Tesla motors with latest firmware is possible. In [19], a social engineering attack was developed to grab information circulating on the CAN bus of a vehicle by using an Android based after market infotainment system while the Keen Security Lab, in 2018, presented a set of vulnerabilities of BMW cars [20] that make them prone to remote access. Also, Subaru [21], Volkswagen [22] and Tesla [23] again were affected by remote attacks. In 2018, the attackers pointed out a vulnerability that may allow a thief to steal a Tesla Model S in seconds by cloning its key fob. In 2019, the attack CANDY CREAM [24] exploited first a remote vulnerability discovered into an after-market infotainment system. In addition, the researcher were able to inject CAN bus frames when the infotainment system was connected to the CAN bus.

Fig. 1
figure 1

The timeline shows the activities, findings, and effort, represented by the diameter of the circles. In bold are reported the main activities for each phase

Full size image

In March 2020, the Keen Security Lab has been performed an experimental security assessment on Lexus Cars [25] pointed out a new vulnerability on the infotainment system of the Toyota Lexus car. Then in November 2020, Belgian researchers demonstrate a third attack on the car manufacturer’s keyless entry system [26] of Tesla Model X. In the spring of 2021, Weinmann and Schmotzle [27] remotely exploited the Tesla Model 3 and they were able to disable the car’s firewall and send a message through the car’s gateway to open its port. More recently, during Pwn2Own Vancouver 2022 [28], the Synacktiv team of David Berard and Vincent Dehors won $75,000 by demonstrating an exploit of the infotainment system with a sandbox escape. Later that same day, they provided this public demonstration. In 2024 [29], by using a device known as Flipper Zero, but potentially replicable with other equipment such as Raspberry Pi, the attacker can create a fake WiFi network called “Tesla Guest” to grab the credentials of the owner and theft the Tesla.

Over the last 15 years, the field of vehicle cybersecurity has grown increasingly complex. Particularly since 2014, numerous new attacks targeting various manufacturers have been recorded annually. Our research aligns with this evolving landscape by introducing a novel approach distinct from previous methodologies. Specifically, in this paper, we delve into the firmware of an infotainment system, aiming to identify vulnerabilities at the firmware level rather than focusing solely on system connectivity or misconfigurations. Leveraging these vulnerabilities, we can develop customized firmware and install it directly into the vehicle.

3 Chimaera working phases

Figure 1 represents the working weeks with the different phases and the relative activities and findings. The diameters of the circles represent the effort spent for each phase and in bold we report the main activity for each phase. Following, we report a short description of the main phases as reported in Fig. 2. In particular, we describe the analysis of the executable file DecryptToPIPE, which, during the installation, is used to decrypt the firmware. Other significant executable files are AppDMClient and AppUpgrade, both involved in the installation checks like the verification of the digital signature, while the file lge.upgrade.xml contains some firmware information like the version number and date.

  1. 1.

    Firmware structure analysis is the starting point of our activity with the searching of information on the web and the download of the firmware. In this phase, after the download, we study the firmware structure, identifying different hidden files like lge.upgrade.xml. The main findings are the decrypted files, which we retrieve using a “public” RSA key;

  2. 2.

    Reverse Engineering DecryptToPIPE (I) is the first reverse engineering phase, made with Ghidra [30], which is an open-source software with a reverse engineering suite of tools developed by the National Security Agency (NSA). In our context, it is useful to try to extract some information and understand how the firmware works. This first static analysis requires a significant effort to understand the flow of the program and, consequently, rename the variables. Then, we modify the assembly code and execute DecryptToPIPE to exploit a mbedtls_printf vulnerability and print some values like the AES-CBC 128 key;

  3. 3.

    Reverse Engineering DecryptToPIPE (II) is the second step of our reverse engineering activity. Starting from the first findings, we continue to study the functions to understand the decryption flow. In particular, we know the RSA decryption process and, then, the SHA generation and control flow, which DecryptToPIPE executes to check the files’ integrity. At the end of this phase, we know all the steps of the decryption process and the necessary information to reproduce also the encryption;

  4. 4.

    File structure analysis phase, using a HEX analysis, allows us to understand that each file of the firmware is generally composed of the content, a terminator string, a SHA, and a digital signature. This phase is fundamental to being able to modify the content of a file and, then, pack it properly for installation;

  5. 5.

    Customize AppDMClient, AppUpgrade, and DecryptToPIPE. In this phase, we modify the assembly code of the three files, involved in the installation process, to jump some checks like the digital signature. With this operation, we can introduce into the firmware our customized files and install them;

  6. 6.

    Implementation is the phase of testing and installation of a modified firmware into the IVI system. In particular, we modify some files to have a backdoor and we customize some images and icons. Besides, we modify the lge.upgrade.xml file to allow us to install a version with an older firmware date with respect to the already installed version;

Fig. 2
figure 2

CHIMAERA workflow to create the custom firmware and modify the IVI to accept it

Full size image

4 Firmware structure analysis

The target firmware is composed of different folders and files. The only file in clear text is IONIQ5_EU.ver, while all the others are encrypted. IONIQ5_EU.ver contains a list of the firmware files with some related information like the dimension. Besides, in the folders, some files are hidden like .lge.upgrade.xml. By opening this file, we noticed that an error occurred due to the fact that the xml file is not in clear format but it is encrypted together with the other downloaded files. In Fig. 3, we report the most significant files for our work. In particular, AppUpgrade is an executable program in charge to decrypt and install the firmware. Other relevant files are mango.rootfs.tar.gz and new_gui.tar.gz, which are compressed archives.

Fig. 3
figure 3

Firmware file tree

Full size image

Once the firmware file tree has been analyzed, we use an already existing projectFootnote 7 on GitLab to decrypt the DecryptToPIPE file that is in charge of performing the decryption operation of each encrypted file sent as input and it is encrypted into the Gen5W_L IVI system. The Key_file and DecryptToPIPE can be retrieved from the HU using a specific procedure.Footnote 8

5 Reverse engineering DecryptToPIPE (I)

We decode every encrypted file of the Gen5W_L software with the command in Listing 1.

figure a

DecryptToPIPE can be executed as a C program and takes in input the Key_file, the file to decrypt, and 0 which represents an offset of bytes to obtain in the decryption phase. To understand the behavior of DecryptToPIPE, we use Ghidra which allows us to reverse the DecryptToPIPE executable file. In Fig. 4, we show the selected parameters to import DecryptToPIPE ELF file in Ghidra.

Fig. 4
figure 4

Ghidra window to import DecryptToPIPE with selected parameters

Full size image

After the import, Ghidra analyzes the file and returns the assembly and decompiled code. Starting from the main entry, we analyze the code and rename functions variable to make the code more readable. For instance, in Fig. 5, we show the decompiled code of the start main function. There are three different functions that we renamed properly after the complete analysis. The first function, identified is RSA_decrypt_and_AES_key, reads the Key_file and obtains a 128 bits key to decrypt the software file. The second function allocates some area of memory, while the third function calculates the Initialization Vector (IV) and uses it together with the 128 bits key to decode the file using AES-CBC. In any case, before proceeding with the decryption, the third function calculates and compares the SHA256 saved into the input file itself. If this check fails, then the decoding operation is quit and it is not executed.

Fig. 5
figure 5

DecryptToPIPE: decompiled code of the start main function

Full size image

5.1 RSA_decrypt_and_AES_key

As shown in Fig. 6, the function RSA_decrypt_and_AES_key calls six other functions, however, the only interesting to understand the flow is the function that we rename as reading_file that contains the decryption operations.

Fig. 6
figure 6

RSA_decrypt_and_AES_key file tree

Full size image

In reading_file, there is an instruction (Fig. 7) that saves into a variable the result of a function, which takes in input five parameters, where the second last is a clear text string “rsa_decrypt” and the last is the number “11”, which represents the number of characters in the previous string. We use this piece of information to understand that this function is mbedtls_ctr_drbg_seed which requires as the fourth parameter a const unsigned char pers and as fifth parameter strlen (pers). This discovery allows us to understand that DecryptToPIPE uses Mbed TLS for its encryption/decryption process, and also for the SHA generation and controls. Mbed TLS is a C library that implements cryptographic primitives, X.509 certificate manipulation and the SSL/TLS and DTLS protocols with a small code footprint [31].

Another relevant aspect for our Reverse Engineering (RE) activity is that DecryptToPIPE was compiled in a static-mode. This is proved by the fact that the entire Mbed TLS library, together with its implemented functions were available into DecryptToPIPE. The consequence of this is that during the RE process, Ghidra tried to disassemble and decompile all these functions.

Fig. 7
figure 7

Code line to identify the presence of an RSA decryption and the usage of the Mbed-TLS library

Full size image

Hence, the function reading_file takes in input two parameters, one of whom is the buffer of the Public_Key_file, which is read with an fopen64 (file, “rb”). This operation allows us to understand that some information are retrieved from the file before starting the RSA decryption. Then, continuing the reading of the code, we identify two For loops (decompiled as do...while in Ghidra). The first For read the AES-CBC 128 key from Public_Key_file. However, as stated before, the reading of the key is not sequential, but the pointer jumps three positions before reading each character. In Fig. 8, we show in C language the reading process.

The second For is used to retrieve two values, called n and e, necessary to generate the RSA key in the library Mbed TLS. Then, we continue to read the following code of the function reading_file. Reading the code of the called functions, we notice a precise correspondence between the code of the explored functions and the native functions of the Mbed TLS library. In this way, we can rename the functions giving the Mbed TLS names and identify the inputs and outputs of each function.

5.2 Memory leakage vulnerability

With the aim to leak sensitive data from the memory stack, we looked for a weak C instruction that may lead to read the memory. We found a printf function that it is present in the disassembled code that prints the following: “Unexpected error, return code = %08X”, where %08X is the HEX value stored in the specific registry. This function is not intended to be used by DecryptToPIPE but it is part of the “mbedtls_printf”, which is the original printing function of Mbed TLS library, meaning that the vulnerable part was introduced by statically compilating the “mbedtls" code into DecryptToPIPE. Since DecryptToPIPE does not use that printf, the code works without any security reason. However, by editing the assembly code of DecryptToPIPE and by injecting the assembly code that is in charge to print a value obtained in EDX registry we are able to print the values of the registry contains or pointed by it. Listing 2 shows the original assembly code used to print the value stored in the R15D registry. Then, the instruction in the LEA is needed to load the “Unexpected error, return code = %08X” that is sent to the printf when invoked through the CALL.

Fig. 8
figure 8

The first For loop of reading_file function to read the AES-CBC 128 key from the Public_Key_file, reproduced in C language

Full size image
figure b

Exploiting the above codes and injecting them in a place that is subsequent to the value that we wish to print, we read the target value stored in the memory. Note that the injection of that code into DecryptToPIPE in the majority of cases generate a segmentation fault error. However, we can easily tolerate this since we are able to read the interested value before the segmentation fault. By exploiting the memory leak vulnerability, we read from the memory two relevant values that are stored in the Key_file passed to DecryptToPIPE when invoked: the Public key and of the encrypted AES-CBC key. Thus, to retrieve the AES-CBC 128 key (Fig. 8), we replicate in C the reading process that DecryptToPIPE uses to read the Public key and of the encrypted AES-CBC key from the Key_file. Then, to decrypt the key, we implement in C the RSA decryption as provided in the Mbed TLS library, reading the parameters n and e. Finally, we pass to the function the buffer containing the key, decrypt it with Mbed TLS library, and print the AES-CBC 128 key. To summarize, we: 1) Discover the usage of Mbed TLS library for the encryption/decryption process. 2) Understand where and how RSA and AES-CBC 128 keys are read. 3) Discover AES-CBC 128 key.

6 Reverse engineering DecryptToPIPE (II)

This working phase is dedicated to the study of the second and the third function called by the start main function of DecryptToPIPE. The second function seems to be a memory allocation and it does not call any other function, so it is not relevant to our study.

The third function, which we call AES_and_SHA is mainly dedicated to the calculation of the SHA256 and its verification, as well as to the decryption of the software file passed to DecryptToPIPE. In particular, we notice that the third function read the file to decrypt from the bottom and look for a string of two subsequent HEX characters in the file: “TE” (0x54,0x45 in HEX). Then, the function controls the next character after “TE” to determine if it is a “2” or a “R”. In our case, we notice that all firmware files have “2” while checking another firmware for Genesis vehicles the terminators are “R”, so we can state that, according to the vehicle model, the file terminator is different. Continuing analyzing the disassembly and decompiled code from Ghidra of the function AES_and_SHA, we discover that it starts a series of integrity checks that we properly link to mbedtls_sha256_starts, mbedtls_sha256_update, and mbedtls_sha256_finish functions. Moreover, by reverse engineering the HEX values of each file, as reported in Fig. 9, we found that after the “TE2”, there is an extra HEX character, which we call “x”, that can vary from file to file. In any case, we observed that the “x” value is not used.

Fig. 9
figure 9

Firmware files’ structure

Full size image

With the mbedtls SHA256 instructions, the AES_and_SHA function computes the SHA256 of the file content starting from the first byte position up to the sequence “TE2+x” (0x54,0x45,0x32,0xFF). When calculating the SHA256, the “TE2+x” sequence is not considered. Then, to verify that the calculated SHA256 corresponds to that one present in the file firmware, DecryptToPIPE starts reading the 32 byte values after the “TE2+x” sequence. If the two SHA256 are equal then DecryptToPIPE goes ahead with the decryption otherwise it quits.

6.1 Getting IV and SHA from DecryptToPIPE

To generate the Inizalization Vector (IV) and SHA256 needed to properly encrypt and validate a file, we exploit the vulnerability in Sect. 5.2 to create two different forks in DecryptToPIPE to leak the HEX values from the memory of relevant information like the initialization vectors for the AES-CBC 128 encryption. In the next listings, we report an example of the assembly code of the print that we implement for each piece of information that we need to retrieve. Note that the registry R13 and the number of printed values can be changed according to the needs.

figure c
figure d
figure e

The other fork we create allows us to print the SHA256 of a file. DecryptToPIPE_generate_IV print the IV of the related file using the following command line. This information is used to encrypt again a file after the modification.

figure f

DecryptToPIPE_print_SHA256 print the SHA of the related file using the following command line. This information is used for the encryption after the modification.

figure g

To summarize, the reverse-engineering work on DecryptToPIPE allowed us to: i) Retrieve the RSA key and use it to find the AES-CBC 128 key. ii) Use the AES-CBC 128 key to decrypt the file. iii) Check the integrity of the file content verifying a hash SHA 256. iv) Generate the IV and SHA256 needed to create a customized encrypted file.

7 File structure analysis

As shown in Fig. 9, each file has a content, which can span from few kB to some GB. Then, we find the file delimiter “TE2” (0x54, 0x45, 0x32 in HEX), which is just a predefined string to delimiter the end of the file. Note that in a file, we find different times the string “TE2”, however, only the last string is considered by DecryptToPIPE. After the string, there is a HEX char, which is the first character of the following digital signature. The next 32-byte are the SHA 256, computed on the file content. After the file content, we have 36-byte which needs to be written in this defined order, however, the firmware installation fails the checks. Then, we find 16,384 byte which contains a digital signature, generated with the private RSA key. In this situation, we can not replicate the digital signature because we have retrieved only the public RSA key and it is not feasible to try to find a private RSA key from a public RSA. With different tests, we discover that the lack or incorrect signature can block the installation of any file generated by us. This happens since AppDMClient first, and AppUpgrade then, are in charge of validating the digital signature of any encrypted file. With the retrieved information, to modify a file correctly, for example, to install a backdoor, we need to follow the next steps:

  • Modify the file content, without any constraints about the dimension, it can be smaller or bigger than the original file content;

  • Paste at the end of the file content the string TE2+x, where x is the HEX value in the original file;

  • Compute the hash SHA 256 of the file content using Mbed TLS library;

  • Paste the hash after TE2x;

  • Copy the digital signature of the original file or create a dumb digital signature made of 16,384 FF bytes;

  • Append the copied digital signature at the end of the file.

Fig. 10
figure 10

AppDMClient difference among the original version and our version with the change of the JZ instruction to JMP to skip the digital signature check. On the third right panel, we underline the code error 0x193, which allows us to discover the control point

Full size image

8 Patching AppDMClient and AppUpgrade

Studying the software process installation into the Gen5W head unit, we noticed that AppDMClient and AppUpgrade, two binaries involved in the installation process, check for the valid digital signature of each encrypted file. Thus, to process with a complete and effective installation process of a customized software into the head unit, we need to i) skip the digital firmware check or ii) create a valid digital signature. Since, we cannot afford the case ii) since we do not have the private key, we can only work on skipping the digital signature check. However, to reach this goal, we need to modify AppDMClient and AppUpgrade:

  • AppDMClient, which is a program stored inside the HU and it calls AppUpgrade after checking the relative digital signature;

  • AppUpgrade, which is called by AppDMClient, that starts the installation process.

8.1 AppDMClient

AppDMClient is responsible for the starting of the installation process and it checks the digital signature of two relevant files: AppDMClient and .lge.upgrade.xml. It computes the digital signature of the file content and compares it with the one present in the file. If the signatures is valid, the installation continues, otherwise, it is stopped. It decrypts the files and, then, copies their decrypted version in a defined internal Head Unit partition. As we can not generate the digital signature, we have to skip this control to continue the installation. To identify where AppDMClient checks the digital signature, we observed the log of AppDMClientFootnote 9 during the installation process. In the logs, we observed that when the digital signature check fails, the error code -403 is displayed. Thus, we searched on Ghidra in the disassembled listing where the 0xfffffe6d value, which corresponds to 0x193 (-403 int) signed value, is present in the code. In Fig. 10, we compare the original version assembly code with our code. In particular, on the right, we underline in red the digital signature code, which allows us to find where the function goes if the digital signature is not correct. Then, we decide to skip the control and, to perform this operation, we patch the assembly by modifying the JZ instruction to JMP. Changing the assemble code with the unconditional “if” instruction allows us to bypass the digital signature check by jumping directly in the correct flow even if the digital signature is not correct.

8.2 AppUpgrade

AppUpgrade is responsible to continue the installation process and call DecryptToPIPE for the decryption of the files. We modify AppUpgrade to avoid the check of the digital signature of all files and allow us to install firmware versions with any date. In particular, we use the same methods as applied with AppDMClient. In Fig. 11, we report the differences among the original one and our modified version. We change the assembly JZ instruction to JMP, which jumps directly into the correct flow even if the digital signature is not correct.

Fig. 11
figure 11

AppUpgrade difference among the original version and our version with the change of the JZ instruction to JMP to avoid the digital signature check

Full size image

To have the possibility to install firmware versions with different dates, also for downgrade, we have to skip another control. AppUpgrade checks a variable, called iVar4 in the decompiled code, to determine if the firmware date is the same, later or older than the actual. Then, in any case, it prints a string with the result and associates a variable, called local_1a8, the value 1 if the updated version is the same, 0 if it is newer, and 2 if it is older. In the first two cases, there are not any issues during the installation. In the third case, the original version installation fails. we modify the assembly instruction MOV to associate the value 1 also in the case of an older version.

The last issue that we find in AppUpgrade is related to the modification of the date and the version field in a customized .lge.upgrade.xml file as shown in Fig. 12.

Fig. 12
figure 12

.lge.upgrade.xml text file with highlighted the date and the version that, if modified, can block the installation. The solution is to modify the assembly code as shown in Fig. 13

Full size image

To avoid this issue, we need to modify the assembly code as shown in Fig. 13. In particular, JNZ statement is a conditional jump statement, so to avoid this control, we change this instruction to JMP which is an unconditional jump to the same label of JNZ.

Fig. 13
figure 13

AppUpgrade difference among the original version and our version, where we change the assembly instruction JNZ to JMP to avoid the problem with the date change

Full size image

9 Custom firmware creation

Starting from the previous findings, this section describes step-by-step our procedure to create a customized firmware. Firstly, we need the customized files AppDMClient, AppUpgrade. Then, we have to create the files that we want to customize. In our case, we decide to modify three main files:

  • mango-rootfs.tar.gz which is the archive containing the file system files in which we insert our backdoor.

  • new_gui.tar.gz which is the archive containing images and we substitute the original with our customized images.

  • .lge.upgrade.xml is an XML file that contains the number/date firmware version and we modify it to write our desired firmware date.

9.1 mango-rootfs.tar.gz

To customize mango-rootfs.tar.gz, we modify the file content and the relative SHA, while we have to keep the original digital signature, appending at the end of the file, as reported in Sect. 7. In the beginning, we have to decrypt the original tar file, using, for example, DecryptToPIPE and the following command in a shell:

figure h

Then, we have a tar.gz file to be decompressed with the following command on Linux or macOS:

figure i

We can now explore the folder contents and edit them as we wish, e.g., by creating our backdoor.

9.2 new_gui.tar.gz

The file new_gui.tar.gz is a tar.gz archive that contains several images in two different image formats:

  • .astc images that use Adaptive Scalable Texture Compression (ASTC). Each file is divided into two new parts, saved in two different files: the ASTC file header and the file content.

  • astc.lz4 images that have lz4 extension, which is a compressed archive containing an ASTC file.

Both file formats can be decompressed and modified. In particular, we modify the several images. Among them, the home background (Fig. 14a) and the numbers of the radio stations (Fig. 14b).

Fig. 14
figure 14

CHIMAERA IVI customizations

Full size image

After having modified the images, we need to compress them again using the same compression methods. In particular, we use a Python program that we called chimaera_image.py (Sect. 12). Then, we encrypt again the archive with the AES key, the IV, the SHA256 and the dummy digital firmware by using the Python program that we called chimaera_build_docker.py (Sect. 12).

10 Custom firmware installation

To install the custom firmware in the head unit, we firstly replace the original AppDMClient with our modified version to skip the digital signature check. Then to start the installation, we have just to prepare a USB key in which we put the original firmware file but we replace our encrypted version of AppUpgrade plus our encrypted files like new_gui.tar.gz. At this point, we insert the USB stick into the head unit and the update button will be enabled to start the installation of our custom firmware. In addition to the customized images, a proof of our work is the installation of the firmware with a different version number written within the .lge.upgrade.xml file. We create a new .lge.upgrade.xml where the version number is AE_E_PE.EUR.CHIMAERA_CF01.808489, we encrypt and test it on the head unit that reads and accepts it (Fig. 15).

11 Chimaera post-exploitation activities

In this section, we highlight two key functionalities that can be remotely managed using Chimaera: the injection of CAN messages and the remote control of the cellular Head Unit’s cellular connection. We have selected these two functionalities because we believe they are the most security-relevant (Fig. 16).

11.1 Playing with CAN bus

The Gen5W_L IVI that we employed for our research activity belongs to an Hyundai IONIQ Electric Vehicle. The Head Unit, resides in the M-Bus, the Multimedia Bus, and in the same bus it communicates with other ECUs like the Instrument Cluster.

From our reverse engineering activity, we understood that processes running in the Gen5W_L use the DBus protocol to communicate each other.Footnote 10 DBus uses two main buses which are:

  • A “system bus” for communicating between system applications and user sessions.

  • A “session bus” for exchanging data between applications in a desktop environments.

Fig. 15
figure 15

Ioniq IVI system with the new version number read during the upgrade

Full size image
Fig. 16
figure 16

Settings windows screenshot

Full size image

Each application connected to these buses is able to provide services or call for services using Remote Procedure Call or publish-subscribe mechanisms. Remote objects can be called by specifying their “paths”, for instance /Path_name, then the interface name must be indicated together with the name of the method to invoke. We noticed that interfaces and methods are hardcoded in some applications running in the head unit making easier understanding which interfaces and methods are useful to control applications of the head unit and its peripheral that manages the CAN bus. Messages exchanged using DBus can be sniffed using the binary dbus-monitor. It can be instrumented to observe the messages exchanged both on the “system" and “session" bus. Since messages can be monitored in clear on the bus, we are able to see which are the methods called and the corresponding “used” payload. Following, we show an excerpt of “system bus” monitored with dbus-monitor.

figure j

Knowing the DBus structure, we can understand that: an application with ID=1.2 invokes a remote object /Can using the interface com.lge.car.micom.can and the method, aka member, NotifyKeyFrontPannelEvent. Then to this method an array of two bytes is passed, i.e., 0x12 and 0x01. As an application connected to one of the bus, we can exploit the dbus-send binary to invoke the same object as before, i.e., /Can: we can invoke the method NotifyKeyFrontPannelEvent of the /Can in the system.

figure k

By running the previous code, the Head Unit will change the showed window.

We are able to exploit the dbus-send binary to also execute commands in the head unit that impact to the CAN bus, For instance, by triggering the command, we are able to enable the seek up function in the radio application. In addition, the dbus-send generates the CAN Bus frame to the M-Bus that corresponds to the CAN ID 0x122 and modifies last two bytes of the CAN bus frame payload.

figure l

11.1.1 Generating CAN bus frames on behalf of the Telematic Unit

The Gen5W_L IVI that we employed for our study supports the Hyundai Telematic services. The services are part of the BluelinkFootnote 11 feature. The Bluelink service allows users to remotely perform some operations on the car using their own smartphone. We discovered that the TmsRemoteApp binary is in charge of managing the operations sent by a user through the smartphone app. By decompiling the TmsRemoteApp with Ghidra, we noticed some code similar to that one reported in Fig. 17 and 18.

Fig. 17
figure 17

Decompiled TmsRemoteApp lock CAN frame

Full size image
Fig. 18
figure 18

TmsRemoteApp decompiled lock command function

Full size image

If we focus on Fig. 17, we can find some hex variables that refer to a CAN bus frame. In particular, we have the ID, DLC and Payload. Thus, by considering the variables from local_38 to local_2e, we can build the CAN frame: 0x4A2 8 FF FF FF FF FF FF FF FF. Then, we see that the memory location address starting as local_38 is used by the function FUN_00120cc0, see red-rectangle number 2. In particular, this function uses the variable local_98 used by the function FUN_00120d90. It takes as input the string SetCANMicomRecv, which we discovered that being a method of the com.lge.car.micom.can interface. Thus, if we decompile FUN_00120cc0 we obtain the code illustrated in Fig. 19.

Fig. 19
figure 19

TmsRemoteApp—DBus interface function

Full size image

Focusing on Fig. 19, we see two string referring to DBus parameters, which are com.lge.car.micom and com.lge.car.micom.can. In particular, the first one represents the destination bus object and the second one, as we said before, the interface. Then, the DBus message is sent. In a similar way, we can replicate this command using dbub-send.

figure m

By sending the command, we generate that CAN bus frame that is injected in the M-Bus. The TmsRemoteApp manages several telematics services that allow to control, for instance, the heating system, vent, lights, horn, vehicle position and so on. Those services are implemented using the same approach explained before.

11.2 Controlling the Head Unit cellular connection

The Gen5W_L may be connected to the Internet through a SIM already present in the Head Unit. The cellular network can be managed using oFono,Footnote 12 a free project for mobile telephony (GSM/UMTS) applications that uses DBus to control the cellular connection.

figure n

Following, we list three Dbus commands that can be used to get information from the internal Head Unit modem, which manages the cellular connection. The first command shows the installed modems. Then, the second command details the modem, i.e., /lgeivi_0, information. Instead the command in line 3 Powers on the modem. Finally, line 4 shows the command to get the network info. To control the network interfaces in the Head Unit, we use the ConnMan daemon. To easily interact with the ConnMan deamon, we can exploit the software tool connmanctl available in the Head Unit firmware.

figure o

Lines 4 and 5 indicate that the interface is powered and it is connected to the network. However, from our test we noticed that this not always corresponds to a working Internet connection. So, we used the services command of “connmanctl” and we observed two available services. By connecting to the second services connect cellular_SOMENUMBERS_context2 we enable a second cellular network interfaces named as rmnet_usb1. Instead, the first available service, i.e., connect cellular_SOMENUMBERS_context1, enabled the rmnet_usb0 interface. Unfortunately, rmnet_usb0 did not provide a working Internet connection but through rmnet_usb1 we got the working cellular connection. Now, we set up it as default interface to route the traffic through the Internet. This setting can be performed with the following commands.

figure p

Command at line 1 removes the current default gateway. The command in line 2 disables the rmnet_usb0 interface, and in line 3 we set the new default gateway using the rmnet_usb1. Now a simple ping test reveals a default working Internet connection through the cellular network of the Head Unit.

12 Chimaera tools

To perform a proper and seamless firmware customization, we developed two Python scripts with different aims: the first, chimaera_build automatically reproduces the encryption process and encrypts the custom firmware to install; the second, chimaera_image, to compress in the right format the images of the custom firmware.

12.1 Chimaera build

The chimaera_build tools handles all required operations for file encryption and, in particular, it exploits two docker containers that run our patched version of DecryptToPIPEFootnote 13 to leak from the memory the correct IV and SHA256. The tool can be accessed by entering the following command line for any decrypted file:

figure q

Then, the tool starts the following operations and outputs an encrypted file. In particular, the chimaera_build steps are the follow. It:

  1. 1.

    Encrypts the source file with the correct AES-CBC 128 key and a fake-random IV;

  2. 2.

    Adds a dummy digital-signature to the just encrypted file;

  3. 3.

    Changes the filename of the source cleartext file with _org suffix;

  4. 4.

    Renames the encrypted file at step 1 as the source filename;

  5. 5.

    Generates the correct IV from DecryptToPIPE_generate_IV using the encrypted file at step 1;

  6. 6.

    Generates the SHA 256 from DecryptToPIPE_print_SHA256 using the encrypted file at step 1;

  7. 7.

    Encrypts again the clear-text source file with the correct generated IV;

  8. 8.

    Appends the generated SHA256 plus the digital-signature to the new encrypted file;

As final and validating step, the chimaera_build tool asks if we want to check the correctness of the encryption process, executing the decryption. If the decryption ends correctly, the encryption was executed rightly.

12.2 Chimaera image

The process to customize firmware images is not straightforward on this IVI. Images are stored in an optimized way to speed up the loading process when displayed in the User Interface (UI). We noticed that the majority of the images in the firmware have the following extensions: .astc, .astc.lz4 and .astc.gz. From our reverse activity we understood that the .astc and .astc.gz files can be decompressed using the standard .astc.Footnote 14 Instead, the .astc.lz4 is a sort of double compression where first we have unpack .lz4 and then decompress the .astc.

The particular aspect that we observed that decompressing the .lz4 using the standard tool like,Footnote 15 the decompression is not properly performed. So, by opening the .astc.lz4 with a HEX editor we noticed that the first 14 bytes are 094C5A5F 454E4A4F 59544F4F 4C53 that in is ASCII corresponds to LZ_ENJOYTOOLS. By googling this, we landed on this github project https://gist.github.com/edp1096/a791c659b0da4473c4139a9297f77dab that provides a C file to compress and decompress a .lz4 file. Starting from this project, we customized it a bit and we were able to decompress the .lz4 file obtaining a file compressed onlysas .astc format. The decompression of this latter one is can be done using the standard .astc.

In addition to what we explained above and as described in Sect. 9, each .astc image is divided into two parts, saved in two different files: the ASTC file header and its content on another file. We developed chimaera_image to easily decompress any type of .astc, .astc.lz4 and .astc.gz image and compress a PNG image into .astc, .astc.lz4 format compatible with the Gen5W_L firmware. So, by utilizing the chimaera_image tool, developers can ensure that their custom firmware can easily incorporate the necessary firmware images without any compatibility issues.

13 Conclusion, discussion and future works

In conclusion, our research on the security vulnerabilities within the IVI system firmware of Hyundai, Kia, and Genesis vehicles has unveiled critical weaknesses that could be exploited by malicious actors. The Chimaera attack, utilizing a printf function in the statically compiled mbedtls library, allows for a format string attack leading to the injection of malicious code and manipulation of the IVI system. Performing a reverse engineering process, we were able to exploit these vulnerabilities, bypass digital signature checks, and remotely control the IVI system. The importance of our findings lies in the potential risks associated with compromised IVI systems in modern vehicles. The number of connected vehicles has increased the vulnerability to remote attacks, and the IVI, as a crucial entry point, demands cybersecurity measures. Our responsible disclosure of these vulnerabilities aims to prompt necessary actions to address and correct these issues, ensuring the safety and security of vehicle systems.

Future activities could include collaborative efforts with automotive manufacturers to implement robust cybersecurity measures, conduct thorough security audits, and develop intrusion detection and prevention systems for IVI systems. Additionally, ongoing research should explore emerging technologies like generative language model-based that can be used by attackers to generate malicious code in a relative short amount of time.