Low-level Hardware Attacks: No Longer an Emerging Threat

As organizations have improved their cybersecurity posture, motivated attackers compensate by looking for other attack vectors to continue to achieve their objectives. Efforts to improve system and device security have produced a greater availability and reliance on hardware security features, and as component and device designers continue to innovate with new security features, attackers continue to innovate and share new tools and attack techniques. Increasingly, this means that to provide solid security posture for a component, device, or system, a full-stack perspective on security is mandatory.

More effort from developers is required to understand and increase resistance to low-level hardware attacks, including:

• Manufacturers of typical microchips and embedded devices that require features such as secure boot and resistance to firmware extraction
• Manufacturers of specialty microchips and integrated circuits (ICs) with security features such as secure elements, secure enclaves, encrypted read only memory (ROMs), hardware root of trust, etc.
• Product manufacturers who depend on microchips with key security features as a core control of their overall product or ecosystem security model

Defending against low-level hardware attacks is critical for most every organization today, but the topic remains largely inaccessible to the key stakeholders who can act to improve security posture to better resist and defend against these attacks. To support improved security posture on these critical components, IOActive is making new materials available to the community to aid in understanding the attack vectors and threats.

IOActive is very pleased to announce the release of our eGuide titled “The State of Silicon Chip Hacking,” which is intended to make the very opaque topic of low-level attacks on microchips and ICs more accessible to security team members, business leaders, semiconductor engineers, and even laypersons.

Furthermore, in the coming months, we will publish some original cybersecurity research related to low-level attacks on specialized memory in microchips and integrated circuits (ICs), and formerly proprietary intelligence (PROPINT) about the capabilities of malicious threat actors targeting microchips and ICs.

BACKGROUND

Evolving Security Posture and Attack Vectors

Within the last decade, low-level hardware attacks at the microchip and IC level have become more appealing to attackers as many organizations have become much better at the fundamentals of cybersecurity that include cyber hygiene, vulnerability management, secure development,[1][2][3] and the many other components in a modern cybersecurity program or framework such as NIST’s CSF. As organizations became more mature in their cybersecurity capabilities, including sophisticated response and threat hunting capabilities offered for their traditional information technology (IT) and operational technology (OT) environments either by an internal security operation center (SOC) or a trusted third-party service provider, threat actors have shifted their focus to other areas of opportunity where less defensive effort had been expended to date, such as supply chain[4][5] and hardware attack vectors.

A recent example of this is the high-impact supply chain attack by Salt Typhoon, a People’s Republic of China (PRC) Ministry of State Security (MSS) affiliated threat actor. This attacker compromised the major U.S. mobile network operators to enable espionage and counterintelligence operations, hyper-targeted cyber operations against high value targets, and the circumvention of the ridiculously weak short message system (SMS) multi-factor authentication (MFA) implementations used far too frequently today.

The more secure an organization itself, the more attractive that organization’s upstream supply chain becomes as an attack vector to a dedicated attacker. A sophisticated threat actor seeks the easiest and least attributable pathway into a target; today the path of least resistance and risk for an attacker is often one of the target’s Tier 1 or Tier 2 suppliers who have an exploitable vulnerability that can provide full access into the target’s network. Other times, the actor has chosen an attack vector of a software library or hardware component. For example, we have recently seen an attacker attempt to compromise the XZ Utils compression library in an effort to subvert the effectiveness of OpenSSH.[6][7]

Greater Reliance on Hardware Security

One outcome of these efforts to improve security is a greater reliance on hardware components and devices to improve the overall system’s security, especially when an attacker has physical access through the protection of key data such as cryptographic keys, whose compromise would result in the compromise of the device or all devices. Key hardware technologies and implementations such as secure boot (e.g., UEFI), trusted execution environments (TEEs), and hardware roots of trust have been created and refined to reduce the likelihood of a software compromise. Many of these key hardware security measures are standardized for the industry or a manufacturer to reuse on multiple products and devices. Perhaps most attractive to device developers, these components are frequently integrated into system-on-a-chip (SOC) components that provide a broad set of features, including hardware security capabilities, into a single package.

This greater availability, utilization, and criticality of hardware security has pushed threat actors to develop new tooling, tactics, techniques, and procedures to achieve their operational or strategic objectives.

Full-stack Perspective

Today’s sophisticated threat actors are capable of successfully attacking at any level of the technology and operational stack including hardware, software, people, processes, and the supply chain. This necessitates much more thoughtful risk management and defense. Moreover, the advanced, low-level hardware attack techniques outlined in our eGuide have become much more democratized and accessible to many of today’s threat actors. There is no expectation that this trend will abate. A successful, low-level hardware attack can compromise an entire organization, its customers, and even its suppliers.

Globalization Consequences

With the admission of the PRC to the World Trade Organization (WTO) in December 2001, the world experienced an extremely rapid period of globalization, which transformed the global economy and its supply chains. This supply chain globalization has actually made our supply chains longer, more geographically dispersed, much more complex and less resilient. Today, a product may have to go through multiple countries and hundreds of suppliers before it’s complete, offering more opportunities for things to go wrong from a supply chain risk perspective, whether accidental or intentional. Within the last several years we have seen numerous high-impact supply chain disruptions.

The 2020 pandemic painfully illustrated the vulnerabilities of the global supply chain to disruption from a virus and the associated government response. Significant microchip shortages beginning in 2021 deeply impacted the automotive industry on a global basis with an estimated impact of a more than 10% reduction in global light-vehicle production in 2021. In March 2021, the container ship Ever Given was grounded in the Suez Canal, causing significant disruptions to shipping and canal transits. In late 2023, we saw huge disruptions to the transit of the Red Sea and Suez Canal, which forms a key link between Asia and Europe, from kinetic attacks by the Houthis, an Iranian proxy group based in Yemen. Arguably, the consequences of the Ever Given incident gave the Houthi strategists a model with which to understand the consequences of severing the link between Europe and the Indo-Pacific through piracy and kinetic strikes.

Perhaps most concerning is the fact that these long, complex supply chains frequently have key nodes in locations under the control of unfriendly, malign,  or adversarial countries who are seeking to penetrate, compromise, and hold at risk critical infrastructure and information of their perceived adversaries.

THREATSCAPE: INCREASING RISKS

The confluence of the above trends has created significantly greater risks that as previously favored attack vectors become more challenging, costly, or attributable, organizations almost certainly will be targeted through low-level hardware attacks. There are many more threat actors today capable of launching low-level hardware attacks. The nature of the global semiconductor supply chain gives the most motivated and well-funded threat actors excellent opportunities to compromise microchips, ICs, and digital devices before they make it to the end user. Increasingly, these threat actors will require low-level hardware attack techniques to continue to meet their operational and strategic objectives.

To support improved security posture on these critical components, we are making new materials available to the community to aid in understanding the attack vectors and threats.

Upcoming Research Publications

In the coming months, we will publish some original cybersecurity research related to low-level attacks on specialized memory in microchips and ICs after completion of our responsible disclosure process. In addition, we will publish some previous work we had performed by a third party to help us assess and develop PROPINT about the capabilities of malicious threat actors to reverse engineer microchips and ICs for the purpose of intellectual property theft.

The State of Silicon Chip Hacking

IOActive is pleased to announce the release of eGuide titled “The State of Silicon Chip Hacking,” which is intended to make the very opaque topic of low-level attacks on microchips and ICs more accessible to security team members, business leaders, semiconductor engineers, and even laypersons. This eGuide is meant to be clear, concise, and accessible to anyone interested in the topic of low-level hardware attacks with an emphasis on invasive attacks using specialized equipment. To increase the accessibility of the eGuide to all readers, we made an effort to include high quality graphics to illustrate the key concepts related to these attacks.

---

[1] https://www.sei.cmu.edu/our-work/secure-development/

[2] https://www.microsoft.com/en-us/securityengineering/sdl/practices

[3] https://www.ncsc.gov.uk/collection/developers-collection/principles

[4] https://www.ncsc.gov.uk/collection/supply-chain-security/supply-chain-attack-examples

[5] https://github.com/cncf/tag-security/blob/main/supply-chain-security/compromises/README.md

[6] https://www.darkreading.com/cyber-risk/xz-utils-backdoor-implanted-in-intricate-multi-year-supply-chain-attack

[7] https://nvd.nist.gov/vuln/detail/CVE-2024-3094

Find out why you need a Red Team Service in 2025 and what to watch out for. New threat actors, AI attacks, and more. What’s on the horizon for 2025?

The holidays are upon us, but threat actors won’t be giving any respite to the defenders tasked with protecting organizations, whether or not it is the season of good cheer.

The last year has been incredibly challenging for many organizations with data breaches, global IT outages, new and dangerous vulnerability discoveries, and a persistent shortage of cybersecurity talent impacting business operations, risk management, and growth opportunities.

As 2024 comes to a close, business leaders need to be aware of the cybercriminal activities and trends likely to pose a risk in 2025, and how Red Team security assessments can benefit their organization.

2025: New Year, New Cyberthreats

As we wrap up 2024, cybersecurity experts at IOActive recommend organizations hire a Red Team to help improve your security posture, fast, by identifying new attack paths through exploitation of complex attack chains and challenging your assumptions.

Below, you will find out what the major trends in cybersecurity will be for 2025 and why our predictions highlight the growing need for Red Team engagements. Learn everything there is to know about a Red Team service as you plan for the New Year.

State-sponsored Cyberattackers, New Threat Actors Emerge

IOActive has tracked cyberattacker groups and their movements for over two decades. Our experts predict that during 2025, new entries will emerge in the state-sponsored or Advanced Persistent Threat (APT) category.

State-sponsored groups often have the most resources and backing from ruling country leaders or parties. As cross-border arrests and law enforcement collaboration is difficult or impossible in some circumstances, it can be challenging to combat their activities, which often focus on financial or intellectual property theft and cyberespionage.

We believe that rising geopolitical tensions in the Middle East, the US, and Eastern Europe will contribute to the expansion of state-sponsored hacking and the creation of new groups entirely.

Attacks on Critical Infrastructure, Supply Chains Escalate

As state-sponsored hacking activities increase, we also expect to see an uptick in cyberattacks launched against digital supply chains and critical infrastructure.

These attacks may be for financial gain, destructive purposes, theft, or launched in response to ongoing conflicts or changing political environments. It is possible that some governments may also increase security requirements imposed on critical infrastructure providers or vendors within government software supply chains.

Ransomware

The threat of ransomware will continue to escalate throughout 2025. New strains, variants, and ransomware groups will emerge. With these changes, consumers will continue to feel the effects of their PII becoming compromised.

Let’s take Change Healthcare as an example. In February, the healthcare provider experienced a ransomware attack. It has taken eight months to confirm the number of those impacted, estimated to involve at least 100 million individuals.

Despite being HIPAA regulated, Change Healthcare has now secured the unenviable distinction of being tied to the most significant healthcare information-related data breach in the United States.

We predict that ransomware-related data breaches will increase in size and scope over the next year, and security incidents of this nature and significance will hit the headlines in 2025.

As the ransomware market becomes more lucrative, we also expect new players to enter the field to claim their slice of illicit profits. As noted in the Sophos State of Ransomware 2024 report, ransomware payments have increased by 500% in the last year alone, with organizations now reporting an average ransom payout of $2 million per incident.

The ongoing scourge of ransomware increases the urgency for organizations to conduct frequent security assessments and tackle vulnerabilities that could be used for initial network access.

Artificial Intelligence: A Blessing and a Curse

Artificial intelligence (AI) is set to transform the cybersecurity industry. While still in its infancy, threat actors will experiment with AI applications throughout 2025 to speed up malicious coding, debug malware, launch automated brute-force and phishing attacks, and spread misinformation.

AI also represents a huge opportunity for defenders. AI technologies can also be used to create tools to combat the changes to the cybercriminal landscape, as well as improve threat detection and response. However, cybersecurity experts will need to take great care in ensuring their work does not end up in the wrong hands or used for nefarious purposes.

The Cybersecurity Skills Gap

It is estimated that millions of cybersecurity jobs worldwide remain unfulfilled, and demand for cyber talent continues to increase. Gartner predicts that next year, a lack of human talent could be responsible for over half of significant cyber incidents.

As in-house positions remain unfulfilled, solutions including Red Team engagements like Assumed Breach Scenarios and Purple Team exercises can help organizations reduce their attack surface and improve their security detection and prevention capabilities.

Moving Forward: How Red Team Services Can Benefit You

Red Teams adopt an attacker’s mindset to simulate real-world attack scenarios. Security experts are then able to probe an organization’s defenses and rapidly identify vulnerabilities before cyberattackers have a chance to exploit them.

Engaging a Red Team demonstrates a proactive commitment to security and a willingness to closely examine and evaluate their existing security controls and abilities to respond to real-world attacks.

When we consider what 2025 and beyond has in store for us, engaging Red Team experts is the best way to start the new quarter. Starting Red Team exercises early in 2025 allows organizations to develop a strategic plan that will progress throughout the year, including addressing vulnerabilities, reducing attack exposure, improving incident response, and integrating security tests with upcoming engineering, development, or infrastructure projects scheduled in Q2 and beyond.

Furthermore, organizations that plan security assessments early can ensure they are factored into the annual budget, and their findings can be used to meet compliance and auditing requirements throughout 2025.

That said, organizations reap the most benefits of Red Team engagements when they have reached a certain cybersecurity maturity level. If you want to learn more about how a Red Team service can help your organization in the New Year, contact us today.

Read on: The IOActive Difference: our approach to helping you plan a Red Team Service in 2025

This is Part-3 of a 3-Part Series. Check out Part-1 here and Part-2 here.

This is the third in a series of three posts in which I break down the creation of a unique key fob badge for the 2024 Car Hacking Village (CHV). Part 1 is an overview of the project and the major components; I recommend that you begin there. In Part 2 I discussed some of the software aspects and the reasoning behind certain decisions.

Background

Before I discuss how to interact with the key fob using a computer, it’s probably a sensible idea to cover some basics of Passive Entry Passive Start (PEPS).

 PEPS is a system that allows for keyless entry and ignition in vehicles. Here’s how it operates:

Key Fob Communication:

The key fob communicates with the car using radio-frequency (RF) signals. These signals are typically in the low-frequency (LF) range (125 kHz or 134 kHz) for car-to-key-fob communication, and in the ultra-high-frequency (UHF) range (sub-1 GHz) for key-fob-to-car.

Proximity Detection:

As the key fob approaches the car, it exchanges unique access codes with the vehicle. The car’s system measures the distance between the key fob and the vehicle. The LF communication operates in the near field, meaning the key fob must be close to the car to receive the signal. The key fob then responds using UHF, which operates in the far field, allowing it to communicate back to the car from a greater distance.

Passive Entry:

When the door handle is touched, the car verifies the key’s presence and unlocks the doors. This can be done through a triggered system, where the car scans for the key fob when the handle is touched, or a polling system, where the car continuously scans for the key fob’s presence.

Passive Start:

Once inside the vehicle, the engine can be started by pressing the ignition button. The car’s system ensures the key fob is inside the vehicle before allowing the engine to start, adding an extra layer of security.

That all makes sense, right? I always find a good sequence diagram helpful to reinforce things like this, so I made one. The process for unlock and start are fundamentally the same, so to avoid repeating myself, I will focus here on the unlock process.

1. Driver touches the door handle
2. Vehicle sends a wake message to the key fob
3. Key fob responds
4. Vehicle sends a cryptographic challenge to the key fob
5. Key fob responds with a correct cryptographic response, which is the result of the cryptographic algorithm, the challenge, and the pre-shared key.
6. Vehicle unlocks.

Anyone with a software-defined radio can capture the UHF signals from the key fob to the car, but capturing the LF signals from the car to the key fob typically require special antenna and a device called an upconverter. This is not intended as a primer on RF or SDR, and if you’d like to learn more, it’s definitely worthwhile to read up on any topics like these that you may be unsure of.

As previously mentioned, the signal from the car to the key fob is LF (125/134KHz) and the key fob to the car is UHF, and interacting with UHF is trivial when using most software-defined radios. However, the LF aspect can be more challenging.

Remember, all we want to do is interact with the key fob. In Part 2 I discuss how the key fob can receive LF messages and then transmit them after some basic checks via an obfuscation algorithm. In this sequence diagram (Figure 2), you can see how the wake-up message is followed by the key fob’s acknowledgement. Any short message we send to the key fob via LF will be echoed back after obfuscation using UHF.

The question is, how can we send LF (125/134KHz) signals to the key fob from a laptop?

Figure 3 shows a laptop with the left side connected to an SDR and the right side connected to a Digital-to-Analog Converter (DAC), an electronic device that converts digital signals into analog signals.

Here’s a more detailed look at how it works and its applications.

Conversion Process

The input to a DAC is a digital signal, typically in the form of binary numbers (0s and 1s).  The output is an analog signal, which can be a continuous voltage or current that varies smoothly over time.

A DAC takes the digital input and converts it into a corresponding analog value. For example, in audio applications, a DAC converts digital audio files into analog signals that can drive speakers to produce sound.

The conversion involves mapping the digital values to specific voltage or current levels. This process is crucial for applications where precise analog output is needed.

Applications

DACs can convert a variety of digital signals, such as:

• Audio: DACs are used in music players, smartphones, and other audio devices to convert digital audio files into analog signals that can be heard through speakers or headphones.
• Video: In televisions and video equipment, DACs convert digital video data into analog signals for display.
• Instrumentation: DACs are used in various measurement and control systems to generate precise analog signals from digital data.

There are a few key elements to focus on in the above description, besides the tasks a DAC is designed for. The interesting part for any hacker is its use for audio conversion. The LF signals our key fob is sending have quite slow data rates, meaning they actually would be audible if not for the carrier. The carrier frequency is 125 or 134KHz, so we would need a DAC capable of 250KHz+ in order to comply with the Nyquist theorem.

Among other things, the theorem states that to accurately reconstruct a continuous signal from its samples, the sampling rate must be at least twice the highest frequency present in the signal. This minimum rate is known as the Nyquist rate.

So, if our carrier frequency is 125 or 134KHz, we need at least twice that.

If you look to high resolution audio devices, especially DACs, you can often find a maximum conversion rate of 384KHz. This is more than twice the carrier frequency, meaning that we can use readily available high resolution audio DACs such as the device below from iFi.

The other important aspect for conversion is the coil or antenna. Now that we have an audio device that can generate the signals we need, we need an antenna. In the sentence, “a DAC converts digital audio files into analog signals that can drive speakers to produce sound,” the word “speaker” should jump out.

If you have never dismantled a speaker, it is a relatively easy task, and the result will look something like the following image.

Now put all this together, and we have something along the lines of Figure 6:

The physical aspect is now sorted, so I will move on to the software.

I like to use GNU Radio, which is a fantastic tool and open source as well. It is a powerful signal processing tool, and once you get the hang of it, it’s relatively easy to use to build new flowgraphs – charts representing the blocks through which samples flow.

The following chart encodes a message of 0x550102030405060708, unpacks the 8 bit bytes into a bit stream, then modulates it. I have included both a Wav File Sink, for writing the data to a file for replaying later using a tool like Audacity, and an audio sink, for sending the output directly to a high-resolution audio device like the one mentioned above.

Starting on the left side, we have a message strobe which allows us to send out a message every x milliseconds. I have chosen once per second, or every 1000ms. If you follow the arrows, it should all make sense. The message strobe sends a message to the PDU to Tagged Stream block, where the message is converted into a byte stream. Next, we unpack the bytes and convert them into bits, which is ultimately what we want to send in this case.

The next section of the flow chart repeats the symbol enough times to set our data rate. In this instance we want a data rate of 982 baud, so each bit symbol needs to be repeated 391 times. I have added descriptions under each major block to help you follow along.

After converting the byte type into float (where the purple is converted to brown), the flow chart goes through a voltage controlled oscillator (VCO). A VCO is an electronic oscillator whose frequency of oscillation is controlled by an input voltage. The frequency of the output signal varies in direct proportion to the applied voltage.

However, we are not using voltage, and everything here is digital and binary, all represented by ones and zeros. If you think of a 1 as a voltage and 0 as the absence of a voltage, the VCO will output a frequency based on the sensitivity value.

Those are the basics on how we’re using GNU Radio; if you’d like to dive deeper, I’ve made the flowgraph available on the same GitHub location as the software.

Moving along, after the VCO we have a modulated bit stream that represents the original message shown in hex. You may also notice a multiply block. If the VCO receives a 0, it will not change the output, meaning whatever value it was at previously is where it will stay. This will result in a DC offset; that is, a voltage present when the input is 0. To remove this DC offset, which will ultimately upset the audio DAC and potentially the speaker coil, the multiply block takes the output from the VCO and our bit stream. If there is a 0 in our bit stream, the output of the VCO is multiplied by 0, resulting in a 0, so no DC offset. If there is a 1 in our bitstream, the VCO output is multiplied by 1, so the VCO output is maintained.

When the GNU Radio flowgraph is run, you should see something like the following:

The blue signal represents the actual output of the VCO; however, it’s behind the red signal, which is the cleaned output of the VCO. They align perfectly, except for whenever the blue signal has a DC offset, as mentioned earlier.

By enabling the audio sink and connecting the audio DAC, we can now output the LF signals required to energize the LF side of the key fob.

The last piece of the puzzle is to listen to the key fob’s UHF transmissions.

A straightforward RF receiver is at work here. The quadrature (I/Q) data gets transformed into amplitude through a complex-to-magnitude block, followed by a low-pass filter. This process results in clear amplitude changes that correspond perfectly with the ones and zeros transmitted by the key fob.

For the RTLSDR Source, change Center Freq (Hz) to the value of freq. Notice how the variable freq is defined as 433.92M. The other change to make in this source really depends on the antenna you are using but for this purpose, try changing RF Gain to 48. Your particular SDR and antenna may warrant either much lower gain or higher gain.

Moving to the Low Pass Filter properties, configure Decimation along with Cutoff Freq and Transition Width.

Finally, configure the GUI Time Sink. There are lots of configuration items to change here so step through them slowly.

First the Number of Points, then Y min and Y max. The configuration values above adjust the default values used in the blocks if you were to draw this flowgraph in GNURadio. As some of the items are not visually present on the flowgraph itself, I have stepped through each of the blocks and changes to the default values that are required to make this flow graph work.

Stepping through the items on this tab change “Number of Points” to 256, “Y min” to -2 and “Y max” to 2. Then click on the Trigger tab and set the Trigger Mode and Trigger Level.

Once all of those configurations have been set, you should be ready to run the graph.

When the flow chart is run and a button is pressed on the key fob, the trace on screen should look something like the following graph, with the filtered amplitude showing distinct binary states.

You should notice the series of ones and zeros at the start. This is the preamble, as discussed previously. This is followed by two zeros indicating the end of the pre-amble.

And there you go. I could do many more posts on how to demodulate the key fob data and build Python blocks in GNU Radio to remove the obfuscation, but where would be the fun in that? I’ll instead leave that for those who are interested in having a good time.

Stay tuned for other material we will be publishing topics like this, including how-to videos on various software-defined radio techniques.

This is Part-2 of a 3-Part Series. Check out Part-1 here and Part-3 here.

This is the second in a series of three posts in which I break down the creation of a unique key fob badge for the 2024 Car Hacking Village (CHV). Part 1 is an overview of the project and the major components; I recommend you begin there. In this post, I’ll discuss some of the software aspects and the reasoning behind certain decisions.

This blog covers several high-level subjects, including UHF and LF transmissions, receiving signals, modulation schemes like OOK/ASK, basic signal processing within a microcontroller, and the C programming language. While this post isn’t meant to be a tutorial on any specific technology, protocol, or component, if you’re interested, it’s definitely worthwhile exploring the various topics I’ll touch on here.

Let’s dive in. As mentioned in Part 1, the key fob transmits using UHF and receives using LF. It also supports CAN and features two physical touch sensor buttons. In addition to the discussion that follows, there are intentional bugs in the software, so I recommend checking it out for a closer look.

UHF transmissions

The raw format of a typical UHF frame doesn’t play nicely with standard serial communication, which includes start and stop bits. This made it crucial to choose an interface that matched the physical signaling requirements for transmitting UHF packets.

In Part 1, I mentioned using the MICRF113 UHF transmitter, which operates with OOK (on-off keying). The MICRF113 transmits whatever speed or state is sent to the DATA signal. This meant I needed to send a simple bit stream from the microcontroller to the MICRF113, without start or stop bits or gaps between bytes. For this I chose a Serial Peripheral Interface (SPI).

SPI is a synchronous serial communication protocol used for short-distance communication, primarily in embedded systems. It uses a controller/peripheral architecture with a single controller. The typical physical signals used in SPI include:

Clock (SCLK): Synchronizes the data transmission.

Data Out, or Peripheral In Controller Out (PICO): The line for sending data from the controller to the peripheral.

Data In, or Peripheral Out Controller In (POCI): The line for sending data from the peripheral to the controller.

Chip Select (CS): Selects the peripheral device.

In my case, I only needed the Data Out line to send the bit stream to the MICRF113. This setup allowed for a continuous stream of data without the interruptions caused by start or stop bits, making it ideal for UHF transmission.

Figure 1, courtesy of SparkFun, illustrates the typical physical signals used in SPI:

For more detailed information on SPI, you can refer to the SparkFun SPI Tutorial.

By choosing SPI, I ensured that the physical aspect of signaling aligned perfectly with how I wanted the UHF packet to be transmitted, resulting in a more efficient and reliable communication setup.

One of the great things about most microcontrollers is the flexibility to assign physical pins to specific functions. In this case, we’re dealing with the signals SCK, OUT, IN, and CS.

I took a bit of a creative approach here. Instead of assigning pins to SCK, IN, or CS, I left them unallocated. This means that whenever I write to the SPI bus, the only physical signal coming from the microcontroller is via the OUT pin. This pin toggles high and low according to the bit stream I send out.

This “hacky” method simplifies the setup and ensures that the data stream is transmitted exactly as needed, without any unnecessary signals getting in the way. It’s a neat trick that leverages the microcontroller’s flexibility to achieve a clean and efficient communication setup.

The frame format of the UHF packet is structured as follows: {pre-amble}{frame counter}{length of payload}{variable length data}.

• Pre-amble: This is a sequence of bits sent at the beginning of the packet to help the receiver synchronize with the incoming data stream.
• Frame counter: This is a value that increments with each packet sent, helping to keep track of the sequence of packets.

In the code snippet below, you’ll see the pre-amble being set on line 73 as hex values 55, 55, 54. As a bitstream, this translates to 0101 0101 0101 0101 0101 0100. Notice the two zeros at the end, which are crucial for synchronization.

On line 76, the frame counter is added to the byte stream, although it’s calculated earlier on line 65. This counter ensures each packet is uniquely identifiable. Next, on line 79, the length of the payload is appended to the byte stream. This tells the receiver how much data to expect.

Finally, on line 82 through 86, the payload itself is added byte by byte to the output array. This is where the actual data is transmitted. Or is it? This code represents a simple obfuscation. How would you go about recovering the original payload data if you received this UHF transmission?

Take a close look at the stack-defined buffer in this function. Can you spot the calculation error? It’s a great exercise to understand not only how these elements come together to form a complete UHF packet, but also how easily security vulnerabilities can occur in code.

POST (Power On Self Test)

It’s important to remember that this badge was created for the DEFCON 2024 security conference, and the amazing team at the CHV had to program these badges before they were sold. But how could they ensure the badges were working correctly? The simple answer: a Power On Self Test (POST).

Two key functions of the badge are tested in the code snippet below. First, on line 124, the output on Port B5 is turned on. This signal, as mentioned in the previous blog, is directly connected to the LED on the board via a resistor. This LED serves as a general status indicator.

On line 126, there’s a remark indicating that the loop will run 8 times with a delay, transmitting a test message each time. The test message, defined on line 129, is the word “TESTING”. Immediately following this, on line 130 the send function transmits the test packet. Keep in mind, the send function processes the payload, so you won’t see the actual “TESTING” message being directly transmitted.

Lines 133 through 136 introduce a delay. After the delay, on line 139 the Port B5 output is XORed with itself, meaning it will change state with each loop iteration. This results in the LED flashing while the test UHF transmissions are performed. Finally, after the self-test, on line 146 the LED is turned off by setting the state of Port B5 to 0.

This POST ensures that the badge is functioning correctly and could be tested by the CHV team before it reaches the hands of DEFCON attendees, providing a reliable and engaging experience for all participants.

Main program code

Now we get to the heart of the code. I saved this part for last because it’s more involved (well, nearly last; there is one final aspect, but I will get to that). This isn’t the most elegant piece of code, but as I explained in Part 1, time was a big constraint on the project. The code works, but it was written in a matter of days and definitely has room for improvement.

The main part of the code polls the ADC (line 152), which is connected via an internal op-amp to the LF antenna. The ADC is configured to sample around 250,000 samples per second. Sometimes, due to the nature of the code—like checking button states—the actual sampling rate drops below that, but it’s still high enough to capture the various energized states of the LF antenna.

The LF signal is alternating current (AC), meaning it alternates above and below zero. Components in the schematic shift this offset so the actual received signal at the microcontroller is always within the range of 0V to 3.3V.

On line 157, this AC offset is added back into the sample so that the LF signal is now measured as positive and negative amplitude, and the value is stored in lf_coil_val. Figure 4, courtesy of Wikipedia, shows an example AC signal on the left. The middle schematic is a full-wave bridge rectifier, and the image on the right is the rectified signal.

This section of the code is crucial for ensuring accurate signal processing, and it demonstrates the complexity and slightly novel approach involved in the project.

How does this apply to our LF signal? If you recall from the previous blog, the LF signal at the antenna looks much like the left image. The reason there’s no bridge rectifier on the PCB is that the signal we’re dealing with is often too small for a bridge rectifier to handle effectively. Instead, I’ve implemented an equivalent in software after amplifying the signal using an onboard op-amp.

A rectifier is an electrical device that converts AC, which periodically reverses direction, to direct current (DC), which flows in only one direction. This process is essential for detecting the amplitude of the LF signal.

To detect the amplitude, which is ultimately what we need, the first step is to rectify the signal on line 158 by multiplying it by itself. This transforms the signal into the image on the right side of Figure 4. From a signal processing perspective, the actual signal is the square of that, so the peaks are much higher.

Remember that all I want to do is determine a high state and a low state, which form the basis of receiving 1s and 0s. This software-based approach allows us to accurately process even the smallest signals, ensuring reliable reception.

Line 161 provides a simple IIR averaging filter to the amplitude data we now have following line 158. The variable ‘delta_lf_coil_val’ now contains a filtered signal strength value, which we must convert into binary. Line 163 compares the variable to our threshold value. If it is higher than this, we have a 1, so count the number of cycles in which it remains a 1. The more cycles, the more symbols of 1 we have. Each symbol is many cycles wide, which is how the code determines how many symbols of 1 are present.

If the filtered signal strength variable ‘delta_lf_coil_val’ is less than the threshold, we have a 0. Again, count the number of cycles in which the value stays below the threshold. On every change of state from 1 to 0 and 0 to 1, the code calculates how many of the changed symbols are present. These counts of number of cycles per state are stored on line 171 in the code above, and 188 in the code below.

To detect the end of a frame, the code on line 194 looks for a large number of 0 symbols. If sufficient 0 symbols are present, the code can continue with the checks, form a message, and ultimately send a UHF frame on line 225.

Line 224 builds the payload; however, prior to that, line 216 through 220 are where the various counts are converted into the actual 1’s and 0’s.

What this code essentially does is receive an LF frame. If it passes some basic checks, it then transmits the LF frame using an obfuscation algorithm and a secret value. This code is a simplified version of how some key fob systems work. It’s designed for some fun capture-the-flag opportunities and as a platform for building cool systems. However, it also demonstrates some basic principles used in passive entry and passive start systems.

Now imagine replacing the obfuscation algorithm with a proper encryption algorithm and a pre-shared key known only to the key fob and the vehicle. You’d have a simple yet effective way to determine which key fob is nearby. Extrapolate this to a real-world scenario, and you can start to see the basics behind these technologies.

This code serves as a great starting point for understanding and experimenting with the fundamental concepts of secure communication in key fob systems. It’s a blend of practical application and a bit of playful exploration, perfect for anyone looking to dive into the world of passive entry and start systems.

Touch Buttons

The last aspect of this code I’ll cover here is that for the touch buttons. In Part 1 I discussed the touch buttons implemented using two circular PCB traces. A tiny amount of electricity flows across your skin when you touch them, and the microcontroller detects that electricity, turning it into an on or an off.

To keep the main code running as fast as possible, the button testing code runs periodically. When the code does run, it checks the AN3 analogue input on line 245, it applies a simple filter on line 246, and if the filtered value is above the dynamic  threshold on line 249, it runs the transmit code, where is builds a packet with the payload of “UNLOCK”. This word forms one of the CTF challenges. Remember, the send function obfuscates the payload, so you would have to first work out the obfuscation algorithm and the secret value in order to recover the flags sent by the key fob.

I hope this was interesting and informative. What I love about this sort of project is solving a problem using a generic microcontroller. To produce these in volume, the design would have to change, but for the purpose of a fun platform the approach really works, providing a means to interact with systems that are usually not so accessible.

That brings us to the end of the second of our three-part look at IOActive’s CHV key fob badge. In Part 3, I’ll address how to interact with the badge using your computer by means of a software-defined radio.

Introduction

A few years ago we started analyzing the platform security of AMD systems. This research led to a number of blog posts and presentations at several technical security conferences. The presentations covered issues from SMM modules, the AMD SMM Supervisor and even a decades old CPU bug. The theme of the research was dubbed “Back to the Future”, this was tongue in cheek due to the types of vulnerabilities that we were finding for AMD systems that have not affected Intel platforms for many years, such as failures to lock down SPI flash. Another bug that inspired the concept was what we reported regarding the SMM Supervisor, which involved x86 Call-Gates, something that you would never see related to modern exploitation in today’s world. Although the reported issue received a CVE, we realized we never made the details public, hence this blog post.

Overview

The SMM Supervisor is essentially a new operating system within SMM, with the purpose of deprivileging SMI handlers. This is a new security boundary to help mitigate constant SMM vulnerabilities in various vendor custom SMI handlers. If you’re ever reverse engineering a modern SMM module you may see a pattern like the following, this is checking the CPL and if it is running under Ring-3 then it knows the SMM Supervisor is initialized and will call into the new interface, else it will operate normally for legacy purposes or if no supervisor is running.

The details in this blog post are specifically regarding the AMD SMM Supervisor implementation, if you have an interest in the Intel implementation detailed blog posts and presentations have been given by Satoshi Tanda which you can review.

The SMM Supervisor implementation lives in the SmmSupervisorBinRelease module.

During its initialization, the module does essentially four things:

1. Retrieves the Trusted SMI Entry Code
2. Installs an SMM Interface for PiSmmCpuDxeSmm
3. It sends the DRTMInfo message to the PSP
4. It reserves the required memory to hold information per core such as the Syscall Entry Point, SMM Base Address, GDT and GDTR

This post is only going to cover steps 1 and 2, if you’re interested in a full overview of the flow please reference our presentation on it.

The Trusted SMI Entry Code is the code that is going to be executed upon the System Management Interrupt (SMI). This code is part of a Raw Freeform file that comes in the BIOS image and has a guid of 83E1F409-21A3-491D-A415-B163A153776D. 

The Supervisor has functions to parse this blob of data and extract the specific sections as required. The beginning of the file starts with a PSP header (0x10 bytes long), which at offset 0x08 indicates the number of sections that follow (5 in this case). 

Each section is represented with the following struct:

Struct policy_section {
    int type;
    unsigned int size;
    unsigned int offset;
    int unused;
};

The Trusted SMI Entry Code is type 0xC1, it has a size of 0x2A4 and starts at offset 0x600. The following image shows the beginning of the supervisor code.

The code puts the content the section 0xC1 and its size into global variables, followed by the installation of an SMM Protocol Interface with the GUID SmmSupervisorInterfaceProtocolGuid (1738B3B1-762F-454B-9779432877A062F6).

This interface exposes the size of the Trusted SMI Entry Code, and four functions:

Using UEFITool to search for the GUID across the entire BIOS image, there is a single module that consumes this interface, which is PiSmmCpuDxeSmm. 

In EDK-II, it is PiSmmCpuDxeSmm the module that prepares SMRAM and installs the first set of SMM Protocols that are used for SmmCore. In this case, the module invokes the first exported function in the Supervisor interface, which returns the Trusted SMI Entry Code that is going to be copied into SMM_BASE+0x8000, which is the SMI Handler Entry Point.

The purpose of the Supervisor SmmCpuFeaturesInstallSmiHandler function is to patch the Trusted SMI Entry Code with the arguments received from PiSmmCpuDxeSmm (e.g. IDTR, Cr3, SmiRandezvous function pointer) and return the modified version back so it gets copied into the proper SMRAM location.

Analysis of SmmCpuFeaturesInstallSmiHandler

This function starts by allocating memory for the GDT and initializing it with predefined values. The predefined values are the following:

These values translate to the following:

This new GDT is where the new call-gates are configured. An x86 call-gate is a mechanism in the x86 architecture used to facilitate controlled transitions between different privilege levels in the processor. It allows code running in a lower-privileged ring (ring-3) to call a into a higher-privileged ring (ring-0). If you need a refresher on x86 internals we recommend you review the OST2 Architecture 2001: x86-64 OS Internals course.

The function that initializes the GDT also receives an argument that is used to patch the entry 0x60 (the first call-gate), but SmmCpuFeaturesInstallSmiHandler sets this argument to NULL.

The predefined values have the two call-gates set with a DPL of 3 (Ring-3) and the selector points to 0x38, which is a 64-bit Code Segment with DPL 0 (Ring-0).

Following the initialization of the GDT, the code parses the memory content of the 0xC1 Section (the Trusted SMI Entry) and gets a pointer to the end of the section minus 4.

The code performs a calculation using this value to get a pointer to a table that is located right after the code ends:

pTable = pC1Section + C1SectionSize - 4 - 0x78
C1SectionSize = 0x2A4
pTable = pC1Section + 0x228

EDI holds the pointer to the table located at +0x228.

The code uses the table bytes to get offsets into locations that will be used to store the arguments passed to the function and function pointers like the high-level SmiEntry and SmiExit.

The table at the end looks like this:

The Trusted SMI Entry Code references these offsets taking into account the SmmBase and the SmiEntry Point (0x8000). Note the various comments regarding when GDTR, SmiEntry, SmiExit, Smi Randezvous, etc. are referenced.

At offset +0x15D the SmiEntry function pointer is retrieved from the table and then is invoked at +0x16B. The code builds a structure in the stack of 0x80 bytes in size and passes it through RCX. 

At offset 0x28, this structure holds a pointer to the Call-Gate offset. This offset is passed into the InitializeGDT function as part of the SmiEntry execution:

After the SmiEntry code finishes, the code follows and executes the SmiRandezvous, which will be executed with Ring-3 privileges (Usermode) and will invoke the proper OEM’s SMI Handlers.

The problem here is that the GDT set by the Supervisor contains a Call-Gate with DPL3 that can be abused by a malicious (or compromised) SMI Handler to elevate privileges.

Because the Call-Gate code is also part of the SMI Entry, it expects that RDI will always contain the value of SmmBase. Nevertheless, a malicious SMI Handler can control the value of RDI. This allows for the attacker to escalate to Ring-0 privileges.

In addition to the Call-Gate issue, you can see at offset +0x78, the code initializes CR0 to 0x668. This means SMEP is not enabled in this configuration, which means that an attacker can point RDI to a function in Ring-3 and take control of Ring-0 by abusing the Call-Gate. Also, UMIP is not enabled in this context. This translates into Supervisor pointer leakages from Ring-3 via the instructions Store IDT (sidt) and Store GDT (sgdt). These additional misconfigurations make it easier for an attacker to exploit the Call-Gate vulnerability.’

Timeline

These issues were reported to the AMD PSIRT team on 5/9/2023. The AMD PSIRT team issued CVE-2023-20596 and released the following AMD-SB-7011 bulletin on 11/14/2023.

This is Part-1 of a 3-Part Series. Check out Part-2 here and Part-3 here.

IOActive recently sponsored the DEF CON 2024 Car Hacking Village (CHV) by designing one of the exclusive badges sold at the event. This took the form of a key fob badge that mirrors the functionality of everyday car key fobs, which support keyless entry and keyless start, also known as Passive Entry Passive Start (PEPS).

This post kicks off a three-part series explaining the creation of this unique device. In this first post we’ll explore the hardware. Part 2 will look at the technologies involved and the corresponding code. Finally, in the third part, we’ll dive into using signal processing tools and a software-defined radio tool to interact with the key fob.

IOActive created a design that allows anyone interested to learn what it does and how it does it, and to modify it to do all sorts of interesting things. For our design, we settled on a few key features that would allow the overall design to progress smoothly.

Key Features of the Badge:

• UHF Transmitter: Enables communication with the vehicle for keyless entry.
  
• Touch Buttons: Provides user interaction similar to standard key fobs.
  
• LF Receiver: Supports the keyless start functionality.

The fun part is that CHV and IOActive open-sourced this project to inspire both seasoned hackers and those new to the field.

Overcoming Constraints

As with any project, we faced certain constraints, particularly regarding time and budget. Despite these challenges, we’re proud of the innovative and educational badge we’ve created. We hope it sparked curiosity and creativity among all participants at the Defcon Car Hacking Village 2024.

Constraints and considerations included the following categories:

Budget and Time Constraints:

• Cost Efficiency: Developing a badge that costs $50 per unit to manufacture would yield the project financially impractical DEFCON attendees.
  
• Time Management: Extensive design work had to be balanced with our primary responsibility of supporting our clients.

Single Prototype Design:

• Limited Prototyping: We were allowed only one prototype PCB design before moving to production.
  
• Time Constraints: Unlike commercial OEMs, we had limited time to transition from concept to production.

Design Requirements:

• UHF Transmitter: Designed to be simple with minimal components, ensuring a low bill of materials (BOM) count.
  
• LF Receiver: Features a PCB printed coil for reception and integrates touch buttons for user interaction.
  
• Microcontroller: Must support CAN bus communications and provide sufficient analog resources.
  
• CAN Bus Support: The key fob acts as an ECU, communicating via the CAN bus.

These constraints and considerations guided our design process, ensuring we created an innovative and educational key fob badge for the CHV. Despite the challenges, we were excited to see how this badge would inspire and educate participants.

Technical Bits

Now that you understand the project and what we wanted to achieve, let’s get into the technical details as to how it actually works. Sorry in advance, as this is going to get very techy very quickly.

When it came to selecting the microcontroller for our key fob badge, we had to ensure it met several critical requirements as mentioned earlier:

• CAN Bus Support: Essential for the key fob to act as an ECU and communicate effectively.
  
• Analog Support: Needed for both ADC and OP-AMP functionalities. The OP-AMP amplifies the small signal from the LF coil, while the ADC converts this amplified signal into a digital format for software processing.
  
• UHF Transmitter Communication: The UHF transmitter, a Microchip Technology MICRF113, requires a single wire serial input to control the RF output. Using SPI with the CLK and MISO disabled in the microcontroller provides an ideal method for sending messages to the MICRF113.

Given my personal experience with Microchip parts, ranging from the latest ARM cores to legacy signal processors, and the fact that I had the necessary development studios, programmers, and tools already installed, I decided to run with what Microchip had to offer. The next step was to use Microchip’s parametric search tool. By inputting our requirements and sorting by cost, I was able to identify a suitable part.

The Chosen Microcontroller

The microcontroller we selected is the Microchip dsPIC33CK32MP502. This automotive-grade part not only supports CAN bus communication but also includes the necessary analog components to handle the LF receiver and touch buttons.

This choice ensures that our key fob badge is both functional and cost-effective, meeting all of its design requirements while staying within budget and time constraints.

Once I had the basic parts selected, it was time to start drawing the schematic:

Let’s start off by going through the critical sections of the schematic. If you’re following along, look for the names, pin numbers, etc., and it should all make sense.

LF_ANT Net and Buttons

The LF_ANT net connects to the LF coil (LF_COIL) and is crucial for receiving signals. BUTTON_1 and BUTTON_2 nets on the left side connect to pins 2, 3, and 4, respectively. On the right side, MB_RX and MB_TX, along with DATA, connect to the main badge via the CAN bus. The DATA net serves as an output connection to the MICRF113 UHF transmitter. Additional components include a 2×3 pin header and a programming connector.

Amplification and Gain Control

Note the 47K resistor connecting pin 28 and pin 1 of the microcontroller. This resistor controls the gain or amplification of the LF signal. The gain ratio depends on R3 and R5, with doubling R3 doubling the amplifier gain. Choosing a low gain is essential due to the background electromagnetic energy at DEF CON and CHV events. High gain could lead to a low signal-to-noise ratio, affecting signal detection by the receive software.

LF Antenna Implementation

The LF antenna design is intriguing and adds to the key fob’s functionality:

• LF_COIL Net: The LF antenna design is intriguing and enhances the key fob’s functionality. The LF_COIL net represents a track from C1 to C2, with C2 being a 0-ohm resistor chosen after tuning the coil. The actual LF coil is a spiral track on the PCB. Ideally, a dedicated component for the spiral track would be preferable, but time constraints led to this design.
  
• C1 and High Pass Filter: C1 forms a high-pass filter, allowing the connection between R1 and R2 to center around half of VDD (1.65V in this case). Analog pins on the microcontroller can handle voltages within the 0V to 3.3V range only.
  
• Protection with D1: Component D1 is a rail-to-rail Schottky diode that protects the microcontroller (connected via the LF_ANT net) from strong LF coil signals. When the key fob is close to an LF transmitter in a car, D1 clips the signal outside safe limits. The green LF_ANT signal oscillates between 0V and 3V, while the blue LF_COIL signal oscillates between +12V and -12V.

• Signal Strength Variation: As the key fob moves away from the car, the LF signal weakens, and the D1 diode, which acts as a protection component, no longer clips the signal. The LF_ANT signal now oscillates between 0.8V and 2.4V, while the blue LF_COIL signal oscillates between +0.8V and -0.8V.

Conclusion

In summary, our key fob badge design balanced functionality, cost-effectiveness, and development constraints. This microcontroller-based design also balanced functionality, protection, and practicality within tight time constraints. With the dsPIC33CK32MP502, we achieved CAN bus support, analogue capabilities, and seamless communication with the UHF transmitter to keep the total number of components to a minimum and speed up the overall development time.

Part 2 of this series will delve into the firmware, including where to find all the resources and how to modify it. The final part of this three-part series will discuss interacting with the key fob using LF, working with LF tools like GNU Radio, capturing UHF transmissions from the fob, and demodulating and interpreting those signals.

KARMA v1.0 (Key Attribute and Risk Management and Analysis) is a risk-rating system developed by IOActive to assess a system’s ability to avoid negative outcomes based on specific key attributes. It uses the expertise of subject matter experts (SMEs) to identify the factors that best predict risks in real-world scenarios. “System” refers to the asset (e.g., application, software, device, or component) evaluated in its likely deployment context.

KARMA has been used for over 20 years and is effective across various security assessments, including web, mobile, infrastructure, embedded systems, code reviews, and design reviews.

KARMA evaluates vulnerabilities based on two factors: likelihood (the probability of an attacker finding and exploiting the vulnerability) and impact (the consequences of exploitation). Ratings are contextualized based on the system’s environment, and the risk score is computed as the product of likelihood and impact, where each range from 1 (informational) to 5 (critical).

Karma stands out as a crucial rating system to use due to its simplicity and elegance. Its design ensures that both technical and non-technical audiences can easily understand and engage with it, making it an accessible tool for a wide range of users.