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.