Millions of dollars are commonly lost on DeFi hacks. In any other industry, this would mean lawsuits and jail time. In DeFi, as shown by Rekt leaderboard of hacks, this is just another day.

The most recent victim was a days-old contract: a Router from the Automated Market Maker (AMM) SushiSwap. A whitehat partially saved the funds of one user, but this triggered the MEV bots and blackhats to swoop in to clear everything else out. How was this done? In this article, we will dive into the vulnerability and write a full proof of concept exploit for the security issue. Included in this post is a demo environment to tinker around with the exploit code and understand this deeper. If you want to watch this in a video form, go watch the livestream with OpenSense.

Background

Before diving into the technical details, some context is required. My goal is to provide everything needed to understand this vulnerability with links to dive deeper, but some basic programming knowledge and some familiarity with Solidity (addresses, msg.sender, tokens, etc.) will help understand the bug in full. Have fun!

High Level Issue

Figure 1: Simplified Vulnerable Code

The Sushiswap vulnerability is complicated when looking at the system as a whole. So, above in Figure 1, is a super simple version of the exploitable contract like you would find in a CTF.

The smart contract takes in an address as the parameter in func1(). The call sets the pool variable to be the user provided address parameter. In a different function, func2(), restricts access to the code based on the pool parameter.

Since a malicious user controls the pool parameter from the previous call, an attacker can bypass the restriction to perform sensitive operations. In this case, an attacker stole funds from other users. And that's basically it! You now have a high level understanding of the bug! After the general background section, we'll get into the nitty-gritty details of how this works.

This is the final installment of a three part series on scoreboard hacking. Please go read parts 1 and 2 first if you have not been following along; they provide much of the background and context of this post. The sections are listed below:

• Introduction & Signal Analysis - Part 1
• Stealing the AES Key via Hardware Hacking - Part 2
• Full Protocol replication in Python and GNU Radio - Part 3 (This Post)

In the previous post, we found the AES key used for encrypting the packets via hardware hacking. To end the series, we will go through creating legitimate packets with Python and using GNU Radio to put the bits in the air. With the ability to create arbitrary packets, we will launch attacks against the scoreboard to impact real sporting events. Enjoy all of the shenanigans required to get this working :)

For a packet to be accepted, everything has to be perfect. Encryption, data whitening, CRC, baud rate... everything. Since we do not have a packet in an intermediate state, such as encrypted but not whitened, this complicates the matter further. We will have to perform both de-whitening and decryption consecutively to get our original data back. From a reverse engineering perspective, this is less than ideal but we must move forward! To start with this task, we will dive into the data whitening process.

Data Whitening

Data whitening is the process of randomly permuting bits being transmitted; the goal of the randomization is to guarantee no consecutive long string of only 0s or only 1s. In the case of the RF module, the benefit of the lack of consecutive strings is better clock synchronization between the transmitter and receiver. To replicate the effect of data whitening on the RF module, we will need to learn how the data whitening is performed. This is shown in Figure 1, which is from the RF module documentation.

Figure 1: Data Whitening in Documentation

Random data (more on this generation later) is XORed with the data to be transmitted ("transmit data" in Figure 1) that we want to send. The resulted is the whitened byte, which is the byte that is sent over the air. For example, 0x19 ^ 0xFF = 0xE6, where 0x19 is the transmit data, 0xFF is the random data and 0xE6 is the whitened(output) byte. The data whitening is why the length of the packets was wrong originally in part 1.

The documentation shows that a Linear Feedback Shift Register (LFSR) with a polynomial of X9 + X5 + 1 is used generate the random numbers for data whitening. "Woah woah woah," I hear you saying "What is an LFSR anyway?" Well, let's find out.

This is part two of a three part series. Please go through the first post in order to understand the background on the device. The sections are listed below:

• Introduction & Signal Analysis - Part 1
• Stealing the AES Key via Hardware Hacking - Part 2 (This Post)
• Full Protocol replication in Python and GNU Radio - Part 3

In the previous post, we discovered that the wireless traffic is encrypted using AES-128 ECB mode. In this post, we will go through how to uncover the AES key. Since this is done via hardware hacking, we must map out the hardware before we hack anything. It is hard(ware) to hack something without understanding how it works first!

PCB Mappings

Mapping out the entire PCB from a complete electrical level is not required. When I reverse engineer boards I think of three things: main components, communication lines and test points. All of this will be explained below.

Components on the Board

Figure 1: Receiver Teardown - Custom hat and Raspberry Pi

The chips on the boards have part information on them; nothing is scraped off or blank. For instance, one chip is labeled as Atmel ATMega328PB. Additionally, the silk screen is quite nice for documentation as well. This makes it substantially easier for us to reverse engineer what each component is doing. We can simply google the component identifier to find the documentation for the chip. Once we have the documentation for every component, we can understand what's the CPU, what's storage and everything else you need to know about the board to perform attacks.

The components on the scoreboard controller and receiver are listed below, with a picture of the receiver in Figure 1:

• ATMega328PB: An ARM MCU from Microchip. I commonly refer to this as the Atmel Processor and main processor below.
• RFM69HCW: RF module from HopeRF.
• Raspberry Pi 3 Model A+: A Raspberry Pi with HDMI, SD Card and other easy ways to interface.
• Splatch Antenna: A surface mount antenna.

Reading up on the part information provides a clean story for what is going on. The Atmel processor is the only large compute and storage on the board. Hence, it must decide what data to send wirelessly by sending it to the RF module. The RF module is magically converting the data and sending it wirelessly through the antenna. At this point, the RF module on the receiver interprets the data from the air and sends this to the Atmel processor on the receiver. Finally, the Raspberry Pi is receiving the data from the Atmel processor and displaying it over HDMI. With this, we now generally understand what every part does from reading about the documentation for the chips on the board. One of this understanding comes from recognizing the capabilities of the component and drawing logic conclusions from there. A generalization of this is shown below in Figure 2.

Communication Lines

Figure 2: Transmitter Communication Flow

Figure 3: Receiver Communication Flow