When Athletic Abilities Just Aren't Enough - Scoreboard Hacking Part 1

9/19/2022

When purchasing the scoreboard, only two components are required: a controller and a wireless receiver. Both of these can be seen within Figure 1 and Figure 2 respectively. When purchasing this product, the company will also sell a shot clock receiver and an external horn. However, the main receiver can still perform all of this functionality so that is all my partner in crime Jesse Victors and I purchased. This is a cool idea, since this can scale to as many screens as the operator wants with the one-to-many relationship.

The controller, shown in Figure 2, is how the scoreboard operator would change the scoreboard. They can start or stop the game clock, add or subtract from the scores and control everything else on the scoreboard.

To display the scoreboard information, the receiver has an HDMI output. This display screen is shown in Figure 3. This is an incredibly smart idea, since the screen size is strictly dependent on the TV being used. The cost of the LED bulbs and other components of the scoreboard has been eliminated from this design as well. The standard view is Basketball, which contains scores, game clock, shot clock, fouls and several other fields. There are other views besides basketball, such as badminton and ping pong.

Following Laura Abbott's Advice

Where do you even begin hacking a scoreboard? The main goal is to hijack the wireless signals. So, we should start with signal analysis. For the starting point on signal analysis, we should turn to the Unnamed Reverse Engineering Podcast's advice for this one. In Episode 55 of the show guest Laura Abbott is asked what her favorite tool is. Her response? Documentation. I absolutely love this response. By simply understanding from a first principles perspective the device under question, you learn what is possible, what is not possible and what the developers likely did. Once you understand how something works and how it was built, it becomes much easier to pwn.

In this case, we want to learn how the wireless signals worked for the scoreboard. So, let us dive into the documentation of the RF Module on both the transmitter and receiver: RFM69HCW from HopeRF. This can be found by simply opening up the receiver and looking up the part number on the chip. We can comb through this document several times until we are happy with our understanding of the RF module.

From documentation studying, we find a number of configuration settings for the module that feel important for us to know:

• Modulation supported: Frequency Shift Keying (FSK) and On-Off Keying (OOK). These will be explained in the Modulation section below.
• Two operating modes: packet & continuous mode. The packet mode has many built in Digital Signal Processing (DSP) features, which makes it the easiest thing to use. As developers want to reduce the amount of effort required to develop a product, packet mode is probably the mode being used.
• The packet mode has three different configurations: fixed length, variable length and unlimited length. These are just settings for the size of the packets being sent.
• The packet has several required and optional fields. The required packet information is shown below and in Figure 4:
  • Preamble: 1010 (0xA) continuously. This is used to turn on the receiver.
  • Sync Word: The clock sync for when to start listening for actual data for the scoreboard.
  • Message: The data being transmitted. In our case, the data for the scoreboard to display.
  • CRC: A checksum ensuring the data was properly received.

Now that we have a general idea of how the system works and what is supported, reverse engineering the signal becomes much easier to do.

Signal Analysis

When analyzing signals, there are many components of each waveform to consider. Two of the most important are mentioned below:

• Frequency
• Modulation

Going forward, the article will explain my personal methodology for discovering these settings. At the end of the day, it is just reverse engineering though! As with most blackbox reverse engineering projects, utilizing the inputs and outputs of the system is extremely useful for discovering how everything works. All of your previous reverse engineering will apply to this project! The only new skills are the radio/wireless specific skills.

Frequency

The frequency is the oscillation rate of the signal. Practically, the frequency is the location of the signal that you are trying to listen to. For instance, the 1090 AM radio station is at the 1090 KHz frequency. The two ways that I find the frequency for a device are via the documentation on the FCC website or staring at a spectrogram (a visual way of representing the signal strength) until I see a change in it. For the scoreboard, the frequencies are literally printed on the box and are configurable, as shown in Figure 1 above. The settings go from 863MHz to 925MHz depending on the region in the world.

This specific device appears to not be on the FCC website. Since this company is not based in the United States, it is likely they did not go through the proper certification for the FCC.

Modulation

Modulation is the process of changing a base radio wave to encode information inside of it. In most cases, this happens by changing one or more dimensions of a signal, which are listed below. Figure 5 has a visual representation of this as well that demonstrates a 0 and a 1 for all of the signal dimensions.

• Amplitude: The height or intensity of the signal. In the real world, this is the loudness of somebody's voice.
• Frequency: The oscillation rate of the signal. In the real world, this is the pitch of somebody's voice.
• Phase: The degree that the wave is in. There is not a good real world equivalent for this, unfortunately. But, Figure 5 demonstrates phase modulation quite well.

In our case, we are assuming digital forms of communication - either a 0 or a 1. The simplest form of modulation is On-Off Keying (OOK). Simply put: if there is a 1, then turn on the signal. If there is a 0, then turn off the signal. A recognizable usage of OOK is morse code. This should be enough background to understand how the scoreboard works. For more information on modulation, please read through the DEFCON workshop by Trenton Ivy on Shaping the Signal.

Viewing Signal in GQRX

To figure out the modulation, we should turn to GQRX to view the signal.

Now, we turn on the controller and view the frequency in GQRX. What do we see? When analyzing signals, we need to see the data in a more broad perspective instead of all the imperfections. In Figure 6, we can see many smaller spikes. However, there are two gradual humps in the graph; this is what we are looking for, which are indicated with the red lines.

The controller is using a large frequency range (1MHz); this indicates that OOK is likely not being used. Additionally, it is switching between frequencies constantly, which indicates that this is using Frequency Modulation (FM). Specifically, the name of the digital frequency modulation is Frequency Shift Keying (FSK). To encode the data, the high frequency is a 1 and the low frequency is a 0. This is a good preliminary view but we cannot decode the data from this view; we are going to need another tool.

Viewing Signal in Inspectrum

Inspectrum is an amazing tool for analyzing captured signals, primarily from software-defined radio receivers. The graph is structured as follows:

• Y-Axis: The frequency of the signal.
• X-Axis: The time in which the recording took place.
• Color: Represents the amplitude. Black (no signal) to green (more signal) to red (lots of power).

The Fourier Transform is used to pull the unique frequencies from a signal. The term FFT is used constantly in radio DSP; this is just the faster (Fast Fourier Transform) variation of this algorithm. I do not understand all of the specifics of it, but the 3Blue1Brown is a great introduction to it.

While using this algorithm to pull out unique frequencies, we need to define how fine-grained we want these frequency categories to be in the tool. If we looked at every single frequency in Hz, then the small differences between the intended frequency and the actual frequency would make the graph useless. If it is too broad, we do not learn anything about the signal either, since it would be one giant blob. In practice, we need to find something in the middle for our signal analysis.

Eventually, we play with the settings of Inspectrum to get something reasonable to look at; this is shown in Figure 7! In particular, we need to make the FFT as small as possible and zoom in as well. How do we know this is legitimate though? We can see an alternating group of lows and highs (0s and 1s) that resembles the preamble of a packet at the beginning of Figure 6. Additionally, if you look at the green lines in the picture, you will notice there are only two unique frequencies. This indicates that the modulation scheme is binary frequency shift keying (2FSK). A low frequency represents a 0 and a high frequency represents a 1. Hurray!

Pattern Matching the Packet

Now that we understand the modulation scheme being used (2FSK), we can decode the individual bits from the signal. Again, if the frequency is low, then it is a 0. If the frequency is high, then it is a 1. To pull out binary information from the signal, we still need to know the length of a single bit. How long is a bit? We can find the symbol rate by looking for the smallest pulse of data, which is easy to see in Inspectrum. From doing this, we discover that the symbol rate is 250,000 bits per second. Additionally, Inspectrum can pull out the bits from a given signal for us automatically via threshold plots so we do not have to decode this by hand. An example of this is shown in Figure 8.

At this point, our strategy is fairly simple: change an input and see how the output changes. From there, we can start to reverse engineer how the packet is formatted byte by byte. To start with, we want to have a base state of the scoreboard. To identify what each of the bytes mean, we change exactly one item on the scoreboard, such as the score, and compare it with the base state. After this, we have a raw output of 0s and 1s for each of the functionalities on the scoreboard. This bit extraction process happens automagically with Inspectrum but we can now analyze the differences between two recordings meaningfully.

Raw data in hand sounds great. But, when you are staring at a list of five hundred 0s & 1s, it is hard to learn anything from it. An example of the beginning of the raw data recorded data would be 1010001011011101010011100110 (0xA2DD4E6). So, we should change the data from binary to hex to make it more approachable for further analysis. Additionally, the extraction process is not perfect; we need to clean up the data to fix the errors. The easiest way to identify a problem is to take several recordings and take the bit that is the most common.

Preamble + Sync Word

This is where reading the documentation pays off! The first group of bytes are all 1010 (0xA). From reading the documentation, we know that this is the preamble to the signal.

Directly after the preamble, the bytes are always 0x2DD4. From Figure 4 on the packet structure, we can see this is likely the sync word. Diving into the documentation shows us that the default sync word is 0x2DD4. Who changes the defaults!? Since nobody does, this is likely our sync word. This also confirms the use of packet mode because the continuous mode does not use the sync word. Progress!

Maybe a Length Byte

If the recordings were taken with all of the changes, then you would notice that changing the team name on the scoreboard increased the amount of bytes being sent. In the smaller packet, the byte following the sync word is 0xE6. In the larger packet, the byte following the sync word is 0xCB. Since these are the main bytes that are different, we can temporarily assume this is the length byte. However, the sizes do not make sense; 0xE6 is larger than 0xCB, even though this is not true with the packet sizes in the air.

At this point, Jesse and I had no idea what was going on with the supposed length byte. From seeing the differences in size, we did know that this was either variable length or unlimited length packet mode at least. Since only the one byte changed between the two packet sizes, this was likely the variable length packet mode though. Narrowing down the options via inductive reasoning! The information for the packet that we know is in Figure 9.

Striking Out (For Now)

Normally, changing the inputs and outputs makes the locations of specific data obvious in the packet. This is how I analyzed my parents Garage Door. For instance, one would expect that adjusting the score would only change a few bytes in the packet. However, these minor changes lead to substantial differences in the entire packet. Why is this?

This is where Jesse and I hit a real road block on finding more about the packet format. After trying more analysis techniques, we eventually wrote up a Python script to compare the differences between two packets. All this script would do is output all of the indexes of the packet that were different between the two packets. From this, we would make a startling discovery: the changes were coming in groups. In particular, changing a single field on the scoreboard would either change bits 60-188 or bits 188-316. It was either one of these groups or nothing at all.

How big are these groups? About 128 bits. What else is 128 bits? Several block ciphers! After seeing this, it should dawn on you: this is using Electronic Codebook (ECB) block cipher mode. This is otherwise known as the naive method of encrypting data. How do we know this? The ECB cipher mode encrypts each block of data separately, as seen in Figure 10. This has one important quirk for security: the previous blocks does not affect future blocks. If data is changed in one block, only the single block is altered in the ciphertext; this means that not the entire ciphertext is changed for every encryption operation performed. In Figure 10, an example of this is shown with two small changes done to different parts of the plaintext, where green is the base state and red a change.

Now, for the scary part. If ECB is being used, then the scoreboard traffic is using encryption. From reading the documentation the RF module supports AES-128 encryption, we know this must be true. Additionally, it does not say ECB explicitly but the description of the cipher makes it apparent. While prepping for this project, I jokingly said to a friend that the scoreboard may encrypt the traffic, and of course karma came back to haunt me on this one.

Where to Next?

The scoreboard manufacturing company has taken an early lead in this baseball game at 1-0 from the use of encryption. The payload of the packet is using encryption! If we ever want to hijack the scoreboard signal, we will need to find the AES key being used. Thankfully, the encryption was not a showstopper. In part 2 of this post, we will go through the process of extracting the AES key from the scoreboard. Tune in next week to find out how to extract the AES key from the scoreboard :)

Feel free to reach out to me (contact information is in the footer) if you have any questions or comments about this article. I'm happy to correct anything in here for the sake of the community. Cheers from Strikeout (ꓘ).