Volvo's EX60 introduces Gemini AI, massive range, and immersive audio to the mid-size EV SUV class, positioning it as a pivotal model in the automaker's electrification push.
The post Volvo’s first EV with Gemini AI integration and a 28-speaker audio system is here appeared first on Digital Trends.
Next week, Volvo shows off its new EX60 SUV to the world. It's the brand's next electric vehicle, one built on an all-new, EV-only platform that makes use of the latest in vehicle design trends, like a cell-to-body battery pack, large weight-saving castings, and an advanced electronic architecture run by a handful of computers capable of more than 250 trillion operations per second. This new software-defined platform even has a name: HuginCore, after one of the two ravens that collected information for the Norse god Odin.
It's not Volvo's first reference to mythology. "We have Thor's Hammer [Volvo's distinctive headlight design] and now we have HuginCore... one of the two trusted Ravens of Oden. He sent Hugin and Muninn out to fly across the realms and observe and gather information and knowledge, which they then share with Odin that enabled him to make the right decisions as the ruler of Asgard," said Alwin Bakkenes, head of global software engineering at Volvo Cars.
"And much like Hugin, the way we look at this technology platform, it collects information from all of the sensors, all of the actuators in the vehicle. It understands the world around the vehicle, and it enables us to actually anticipate around what lies ahead," Bakkenes told me.
© Aurich Lawson
Once upon a time, a car phone was a great way to signal to the world that you were better than everybody else. It was a clear sign that you had money to burn, and implied that other people might actually consider it valuable to talk to you from time to time.
There was, however, a way to look even more important than the boastful car phone user. You just had to rock up to the parking lot with your very own in-car fax machine.
Today, the fax machine is an arcane thing only popular in backwards doctor’s offices and much of Japan. We rely on email for sending documents from person A to person B, or fill out forms via dedicated online submission systems that put our details directly in to the necessary databases automatically. The idea of printing out a document, feeding it into a fax machine, and then having it replicated as a paper version at some remote location? It’s positively anachronistic, and far more work than simply using modern digital methods instead.
Back in the early 90s though, the communications landscape looked very different. If you had a company executive out on the road, the one way you might reach them would be via their cell or car phone. That was all well and good if you wanted to talk, but if you needed some documents looked over or signed, you were out of luck.
Even if your company had jumped on the e-mail bandwagon, they weren’t going to be able to get online from a random truck stop carpark for another 20 years or so. Unless… they had a fax in the car! Then, you could simply send them a document via the regular old cellular phone network, their in-car fax would spit it out, and they could go over it and get it back to you as needed.
Of course, such a communications setup was considered pretty high end, with a price tag to match. You could get car phones on a wide range of models from the 1980s onwards, but faxes came along a little later, and were reserved for the very top-of-the-line machines.
Mercedes-Benz was one of the first automakers to offer a remote fax option in 1990, but you needed to be able to afford an S-Class to get it. With that said, you got quite the setup if you invested in the Büro-Kommunikationssystem package. It worked via Germany’s C-Netz analog cellular system, and combined both a car phone and an AEG Roadfax fax machine. The phone was installed in the backrest of one of the front seats, while the fax sat in the fold-down armrest in the rear. The assumption was that if you were important enough to have a fax in the car, you were also important enough to have someone else driving for you. You also got an AEG Olyport 40/20 laptop integrated into the back of the front seats, and it could even print to the fax machine or send data via the C-Netz connection.
Not to be left out, BMW would also offer fax machines on certain premium 7 Series and L7 limousine models, though availability was very market-dependent. Some would stash a fax machine in the glove box, others would integrate it into the back rest of one of the front seats. Toyota was also keen to offer such facilities in its high-end models for the Japanese market. In the mid-90s, you could purchase a Toyota Celsior or Century with a fax machine secreted in the glove box. It even came with Toyota branding!
Ultimately, the in-car fax would be a relatively short-lived option in the luxury vehicle space, for several reasons. For one thing, it only became practical to offer an in-car fax in the mid-80s, when cellular networks started rolling out across major cities around the world.
By the mid-2000s, digital cell networks were taking over, and by the end of that decade, mobile internet access was trivial. It would thus become far more practical to use e-mail rather than a paper-based fax machine jammed into a car. Beyond the march of technology, the in-car fax was never going to be a particularly common selection on the options list. Only a handful of people ever really had a real need to fax documents on the go. Compared to the car phone, which was widely useful to almost anyone, it had a much smaller install base. Fax options were never widely taken up by the market, and had all but disappeared by 2010.
The Toyota Celsior offered a nice healthy-sized fax machine in the 1990s, but it did take up the entire glove box.
These days, you could easily recreate a car-based fax-type experience. All you’d need would be a small printer and scanner, ideally combined into a single device, and a single-board computer with a cellular data connection. This would allow you to send and receive paper documents to just about anyone with an Internet connection. However, we’ve never seen such a build in the wild, because the world simply doesn’t run on paper anymore. The in-car fax was thus a technological curio, destined only to survive for maybe a decade or so in which it had any real utility whatsoever. Such is life!
Imagine you’re cruising down the highway in your brand-new electric car. All of a sudden, the massive multimedia display fills with Doom, the iconic 3D shooter game. It completely replaces the navigation map or the controls menu, and you realize someone is playing it remotely right now. This is not a dream or an overactive imagination – we’ve demonstrated that it’s a perfectly realistic scenario in today’s world.
The internet of things now plays a significant role in the modern world. Not only are smartphones and laptops connected to the network, but also factories, cars, trains, and even airplanes. Most of the time, connectivity is provided via 3G/4G/5G mobile data networks using modems installed in these vehicles and devices. These modems are increasingly integrated into a System-on-Chip (SoC), which uses a Communication Processor (CP) and an Application Processor (AP) to perform multiple functions simultaneously. A general-purpose operating system such as Android can run on the AP, while the CP, which handles communication with the mobile network, typically runs on a dedicated OS. The interaction between the AP, CP, and RAM within the SoC at the microarchitecture level is a “black box” known only to the manufacturer – even though the security of the entire SoC depends on it.
Bypassing 3G/LTE security mechanisms is generally considered a purely academic challenge because a secure communication channel is established when a user device (User Equipment, UE) connects to a cellular base station (Evolved Node B, eNB). Even if someone can bypass its security mechanisms, discover a vulnerability in the modem, and execute their own code on it, this is unlikely to compromise the device’s business logic. This logic (for example, user applications, browser history, calls, and SMS on a smartphone) resides on the AP and is presumably not accessible from the modem.
To find out, if that is true, we conducted a security assessment of a modern SoC, Unisoc UIS7862A, which features an integrated 2G/3G/4G modem. This SoC can be found in various mobile devices by multiple vendors or, more interestingly, in the head units of modern Chinese vehicles, which are becoming increasingly common on the roads. The head unit is one of a car’s key components, and a breach of its information security poses a threat to road safety, as well as the confidentiality of user data.
During our research, we identified several critical vulnerabilities at various levels of the Unisoc UIS7862A modem’s cellular protocol stack. This article discusses a stack-based buffer overflow vulnerability in the 3G RLC protocol implementation (CVE-2024-39432). The vulnerability can be exploited to achieve remote code execution at the early stages of connection, before any protection mechanisms are activated.
Importantly, gaining the ability to execute code on the modem is only the entry point for a complete remote compromise of the entire SoC. Our subsequent efforts were focused on gaining access to the AP. We discovered several ways to do so, including leveraging a hardware vulnerability in the form of a hidden peripheral Direct Memory Access (DMA) device to perform lateral movement within the SoC. This enabled us to install our own patch into the running Android kernel and execute arbitrary code on the AP with the highest privileges. Details are provided in the relevant sections.
The modem at the center of our research was found on the circuit board of the head unit in a Chinese car.
Circuit board of the head unit
Description of the circuit board components:
| Number in the board photo | Component |
| 1 | Realtek RTL8761ATV 802.11b/g/n 2.4G controller with wireless LAN (WLAN) and USB interfaces (USB 1.0/1.1/2.0 standards) |
| 2 | SPRD UMW2652 BGA WiFi chip |
| 3 | 55966 TYADZ 21086 chip |
| 4 | SPRD SR3595D (Unisoc) radio frequency transceiver |
| 5 | Techpoint TP9950 video decoder |
| 6 | UNISOC UIS7862A |
| 7 | BIWIN BWSRGX32H2A-48G-X internal storage, Package200-FBGA, ROM Type – Discrete, ROM Size – LPDDR4X, 48G |
| 8 | SCY E128CYNT2ABE00 EMMC 128G/JEDEC memory card |
| 9 | SPREADTRUM UMP510G5 power controller |
| 10 | FEI.1s LE330315 USB2.0 shunt chip |
| 11 | SCT2432STER synchronous step-down DC-DC converter with internal compensation |
Using information about the modem’s hardware, we desoldered and read the embedded multimedia memory card, which contained a complete image of its operating system. We then analyzed the image obtained.
The modem under investigation, like any modern modem, implements several protocol stacks: 2G, 3G, and LTE. Clearly, the more protocols a device supports, the more potential entry points (attack vectors) it has. Moreover, the lower in the OSI network model stack a vulnerability sits, the more severe the consequences of its exploitation can be. Therefore, we decided to analyze the data packet fragmentation mechanisms at the data link layer (RLC protocol).
We focused on this protocol because it is used to establish a secure encrypted data transmission channel between the base station and the modem, and, in particular, it is used to transmit higher-layer NAS (Non-Access Stratum) protocol data. NAS represents the functional level of the 3G/UMTS protocol stack. Located between the user equipment (UE) and core network, it is responsible for signaling between them. This means that a remote code execution (RCE) vulnerability in RLC would allow an attacker to execute their own code on the modem, bypassing all existing 3G communication protection mechanisms.
3G protocol stack
The RLC protocol uses three different transmission modes: Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM). We are only interested in UM, because in this mode the 3G standard allows both the segmentation of data and the concatenation of several small higher-layer data fragments (Protocol Data Units, PDU) into a single data link layer frame. This is done to maximize channel utilization. At the RLC level, packets are referred to as Service Data Units (SDU).
Among the approximately 75,000 different functions in the firmware, we found the function for handling an incoming SDU packet. When handling a received SDU packet, its header fields are parsed. The packet itself consists of a mandatory header, optional headers, and data. The number of optional headers is not limited. The end of the optional headers is indicated by the least significant bit (E bit) being equal to 0. The algorithm processes each header field sequentially, while their E-bits equal 1. During processing, data is written to a variable located on the stack of the calling function. The stack depth is 0xB4 bytes. The size of the packet that can be parsed (i.e., the number of headers, each header being a 2-byte entry on the stack) is limited by the SDU packet size of 0x5F0 bytes.
As a result, exploitation can be achieved using just one packet in which the number of headers exceeds the stack depth (90 headers). It is important to note that this particular function lacks a stack canary, and when the stack overflows, it is possible to overwrite the return address and some non-volatile register values in this function. However, overwriting is only possible with a value ending in one in binary (i.e., a value in which the least significant bit equals 1). Notably, execution takes place on ARM in Thumb mode, so all return addresses must have the least significant bit equal to 1. Coincidence? Perhaps.
In any case, sending the very first dummy SDU packet with the appropriate number of “correct” headers caused the device to reboot. However, at that moment, we had no way to obtain information on where and why the crash occurred (although we suspect the cause was an attempt to transfer control to the address 0xAABBCCDD, taken from our packet).
The first and most important observation is that we know the pointer to the newly received SDU packet is stored in register R2. Return Oriented Programming (ROP) techniques can be used to execute our own code, but first we need to make sure it is actually possible.
We utilized the available AT command handler to move the data to RAM areas. Among the available AT commands, we found a suitable function – SPSERVICETYPE.
Next, we used ROP gadgets to overwrite the address 0x8CE56218 without disrupting the subsequent operation of the incoming SDU packet handling algorithm. To achieve this, it was sufficient to return to the function from which the SDU packet handler was called, because it was invoked as a callback, meaning there is no data linkage on the stack. Given that this function only added 0x2C bytes to the stack, we needed to fit within this size.
Stack overflow in the context of the operating system
Having found a suitable ROP chain, we launched an SDU packet containing it as a payload. As a result, we saw the output 0xAABBCCDD in the AT command console for SPSERVICETYPE. Our code worked!
Next, by analogy, we input the address of the stack frame where our data was located, but it turned out not to be executable. We then faced the task of figuring out the MPU settings on the modem. Once again, using the ROP chain method, we generated code that read the MPU table, one DWORD at a time. After many iterations, we obtained the following table.
The table shows what we suspected – the code section is only mapped for execution. An attempt to change the configuration resulted in another ROP chain, but this same section was now mapped with write permissions in an unused slot in the table. Because of MPU programming features, specifically the presence of the overlap mechanism and the fact that a region with a higher ID has higher priority, we were able to write to this section.
All that remained was to use the pointer to our data (still stored in R2) and patch the code section that had just been unlocked for writing. The question was what exactly to patch. The simplest method was to patch the NAS protocol handler by adding our code to it. To do this, we used one of the NAS protocol commands – MM information. This allowed us to send a large amount of data at once and, in response, receive a single byte of data using the MM status command, which confirmed the patching success.
As a result, we not only successfully executed our own code on the modem side but also established full two-way communication with the modem, using the high-level NAS protocol as a means of message delivery. In this case, it was an MM Status packet with the cause field equaling 0xAA.
However, being able to execute our own code on the modem does not give us access to user data. Or does it?
The full version of the article with a detailed description of the development of an AR exploit that led to Doom being run on the head unit is available on ICS CERT website.
Modern vehicles are transforming into full-fledged digital devices that offer a multitude of features, from common smartphone-like conveniences to complex intelligent systems and services designed to keep everyone on the road safe. However, this digitalization, while aimed at improving comfort and safety, is simultaneously expanding the vehicle’s attack surface.
In simple terms, a modern vehicle is a collection of computers networked together. If a malicious actor gains remote control of a vehicle, they could be able not only steal user data but also create a dangerous situation on the road. While intentional attacks targeting a vehicle’s functional safety have not become a widespread reality yet, that does not mean the situation will not change in the foreseeable future.
The modern vehicle is a relatively recent invention. While digital systems like the electronic control unit and onboard computer began appearing in vehicles back in the 1970s, they did not become standard until the 1990s. This technological advancement led to a proliferation of narrowly specialized electronic devices, each with a specific task, such as measuring wheel speed, controlling headlight modes, or monitoring door status. As the number of sensors and controllers grew, local automotive networks based on LIN and CAN buses were introduced to synchronize and coordinate them. Fast forward about 35 years, and modern vehicle is a complex technical device with extensive remote communication capabilities that include support for 5G, V2I, V2V, Wi-Fi, Bluetooth, GPS, and RDS.
Components like the head unit and telecommunication unit are standard entry points into the vehicle’s internal infrastructure, which makes them frequent objects for security research.
From a functional and architectural standpoint, we can categorize vehicles into three groups. The lines between these categories are blurred, as many vehicles could fit into more than one, depending on their features.
Obsolete vehicles do not support remote interaction with external information systems (other than diagnostic tools) via digital channels and have a simple internal architecture. These vehicles are often retrofitted with modern head units, but those components are typically isolated within a closed information environment because they are integrated into an older architecture. This means that even if an attacker successfully compromises one of these components, they cannot pivot to other parts of the vehicle.
Legacy vehicles are a sort of transitional phase. Unlike simpler vehicles from the past, they are equipped with a telematics unit, which is primarily used for data collection rather than remote control – though two-way communication is not impossible. They also feature a head unit with more extensive functionality, which allows changing settings and controlling systems. The internal architecture of these vehicles is predominantly digital, with intelligent driver assistance systems. The numerous electronic control units are connected in an information network that either has flat structure or is only partially segmented into security domains. The stock head unit in these vehicles is often replaced with a modern unit from a third-party vendor. From a cybersecurity perspective, legacy vehicles represent the most complex problem. Serious physical consequences, including life-threatening situations, can easily result from cyberattacks on these vehicles. This was made clear 10 years ago when Charlie Miller and Chris Valasek conducted their famous remote Jeep Cherokee hack.
Modern vehicles have a fundamentally different architecture. The network of electronic control units is now divided into security domains with the help of a firewall, which is typically integrated within a central gateway. The advent of native two-way communication channels with the manufacturer’s cloud infrastructure and increased system connectivity has fundamentally altered the attack surface. However, many automakers learned from the Jeep Cherokee research. They have since refined their network architecture, segmenting it with the help of a central gateway, configuring traffic filtering, and thus isolating critical systems from the components most susceptible to attacks, such as the head unit and the telecommunication module. This has significantly complicated the task of compromising functional safety through a cyberattack.
Modern vehicle architectures make it difficult to execute the most dangerous attacks, such as remotely deploying airbags at high speeds. However, it is often easier to block the engine from starting, lock doors, or access confidential data, as these functions are frequently accessible through the vendor’s cloud infrastructure. These and other automotive cybersecurity challenges are prompting automakers to engage specialized teams for realistic penetration testing. The results of these vehicle security assessments, which are often publicly disclosed, highlight an emerging trend.
Despite this, cyberattacks on modern vehicles have not become commonplace yet. This is due to the lack of malware specifically designed for this purpose and the absence of viable monetization strategies. Consequently, the barrier to entry for potential attackers is high. The scalability of these attacks is also poor, which means the guaranteed return on investment is low, while the risks of getting caught are very high.
However, this situation is slowly but surely changing. As vehicles become more like gadgets built on common technologies – including Linux and Android operating systems, open-source code, and common third-party components – they become vulnerable to traditional attacks. The integration of wireless communication technologies increases the risk of unauthorized remote control. Specialized tools like software-defined radio (SDR), as well as instructions for exploiting wireless networks (Wi-Fi, GSM, LTE, and Bluetooth) are becoming widely available. These factors, along with the potential decline in the profitability of traditional targets (for example, if victims stop paying ransoms), could lead attackers to pivot toward vehicles.
Will attacks on vehicles become the logical evolution of attacks on classic IT systems? While attacks on remotely accessible head units, telecommunication modules, cloud services or mobile apps for extortion or data theft are technically more realistic, they require significant investment, tool development, and risk management. Success is not guaranteed to result in a ransom payment, so individual cars remain an unattractive target for now.
The real risk lies with fleet vehicles, such as those used by taxi and carsharing services, logistics companies, and government organizations. These vehicles are often equipped with aftermarket telematics and other standardized third-party hardware that typically has a lower security posture than factory-installed systems. They are also often integrated into the vehicle’s infrastructure in a less-than-secure way. Attacks on these systems could be highly scalable and pose significant financial and reputational threats to large fleet owners.
Another category of potential targets is represented by trucks, specialized machinery, and public transit vehicles, which are also equipped with aftermarket telematics systems. Architecturally, they are similar to passenger cars, which means they have similar security vulnerabilities. The potential damage from an attack on these vehicles can be severe, with just one day of downtime for a haul truck potentially resulting in hundreds of thousands of dollars in losses.
Improving the current situation requires investment in automotive cybersecurity at every level, from the individual user to the government regulator. The driving forces behind this are consumers’ concern for their own safety and the government’s concern for the security of its citizens and national infrastructure.
Automotive cybersecurity is already a focus for researchers, cybersecurity service providers, government regulators, and major car manufacturers. Many automotive manufacturing corporations have established their own product security or product CERT teams, implemented processes for responding to new vulnerability reports, and made penetration testing a mandatory part of the development cycle. They have also begun to leverage cyberthreat intelligence and are adopting secure development methodologies and security by design. This is a growing trend, and this approach is expected to become standard practice for most automakers 10 years from now.
Simultaneously, specialized security operations centers (SOCs) for vehicles are being established. The underlying approach is remote data collection from vehicles for subsequent analysis of cybersecurity events. In theory, this data can be used to identify cyberattacks on cars’ systems and build a database of threat information. The industry is actively moving toward deploying these centers.
For more on trends in automotive security, read our article on the Kaspersky ICS CERT website.
Login
