In our last post, in part 1, we purchased a game scoreboard, which we’re calling the Score9, in our quest to deepen our understanding of RF hacking projects and to attack a game scoreboard for the very first time. This post continues the story: covering our investigation and initial building of the attack, and is complementary to Maxwell’s more detailed blog on the same topic.
Part 2: Opening Moves
A good first goal for any project like this is learning as much as possible about the hardware. We started by inspecting the components. As mentioned in part 1, the Score9 comes in two main parts: the controller/transmitter unit and the receiver unit, which are shown below. During a game, we’d expect staff to have the controller while the receiver is stationary and attached to an external display. With this in mind, we pictured a malicious attacker in the stands or at least within the eyesight of these components, so that’s where we imagined ourselves if we were to execute wireless attacks in the field.
From the beginning, we envisioned that the transmitter could interact with the receiver in two possible ways:
- It has direct control, sending a complete game state every time, with data for every field in the message to the receiver; or
- It could just send a short message of small changes to the game state, such as updating a score, decreasing the shot clock, etc.
To do this, we first needed to find fundamental information about the radio signal. What frequency does it use? How does it transmit a binary message? What do the bits mean? How quickly are the bits sent over the air? And so on.
First, finding the frequency. The radio spectrum is valuable and already quite crowded, so all transmitters are assigned to specific frequencies that are unused elsewhere, thus avoiding interference and conflict. In the United States, all radio transmitters of any type must be registered with the FCC. This FCC ID is then printed or embedded on the device. Running that ID through the FCC’s website or FFC.io will usually give you lots of information on the transmitter and PDFs of lab tests.
The Score9 scoreboard has no such ID anywhere, which we found very odd. Isn’t this illegal? But luckily, the receiver has controls to switch to different channels, and the channel frequencies are clearly labeled, as you can see in the images above. After a closer look, nearly all of these frequencies are actually within the Industrial, Scientific, and Medical (ISM) band in the United States, in which unregistered short-range transmitters (such as WiFi routers) can operate freely. The scoreboard, by default, was working at 923 MHz.
Now we got our hardware set up. Software-defined radios like the inexpensive receive-only RTL-SDR and the receive+transmit HackRF One are invaluable for RF hacking projects. We connected the HackRF One to a simple dipole antenna, plugged it into our laptop over a USB cable, and turned on the scoreboard.
Once we could listen to the radio spectrum, we fired up CubicSDR and GQRX, two useful tools for capturing a section of bandwidth and observing a spectrogram or waterfall. We immediately identified frequency-shift keying (FSK) by its characteristic two peaks on either side of the 923 MHz centerline:
Next, we had to discover how quickly the bits were sent over the air. In regular FSK, this is the baud rate, that is to say, the speed of the fluctuations between the upper and lower frequencies on either side of 923 MHz. To find the baud rate, we first needed to capture the scoreboard signal. We used the tool within Universal Radio Hacker (URH) to save all captured frequencies between 922 and 924 MHz to a file. We then opened this recording with Inspectrum.
The baud rate is so fast that Inspectrum can barely draw a spectrogram; nearly ten symbols go by in 40 microseconds. That’s a baud rate of 250,000 bits/second! This was by far the fastest FSK signal that Maxwell and I have ever seen; nothing we had explored before operated anywhere near this speed.
Now that we’ve discovered this, we can decode the recording in Universal Radio Hacker.
At this point, we made two discoveries. First, as you can see in the top half of this screenshot, the controller continually sends bursts, and each burst looks about the same. The controller sends the game state in each burst, answering our earlier question. Second, in the bottom half of the screenshot, we demodulated the FSK signal of one of the bursts, giving us binary that starts with this 1101010101… pattern.
Now we had the binary from the scoreboard. However, we still did not know which bits corresponded to which piece of information on the controller - this is where Maxwell had a brilliant idea, and I highly recommend that you read his blog post on this topic for more detail. He wrote a Python script to compare the extracted bits observed from a basic scoreboard state with the bits observed after making small adjustments to the controller, such as increasing the home score by one or decreasing the shot clock by one second.
We expected a small change like this to only change one or two bits. In fact, we expected to completely reverse-engineer the utility of each bit by repeatedly making small changes and observing the change in the bit sequence. But something odd was happening. The bursts were all the same size, but over a hundred bits within them were changing at once. Changes to the shot clock caused radical changes to bits 60 through 188, whereas changing the guest foul would change bits 188 through 316. What was happening?
It was only through meticulous observation of the numbers that we discovered something interesting. The radical changes only occurred within specific boundaries, groups of 128 bits. It also seemed that about 50% of the bits were changed in this group, not just one or two, as we expected. This became suspicious. Have you heard of 128-bit encryption? Most block ciphers operate in 128-bit blocks, and Maxwell began to suspect that they were using one of these. AES in Electronic Codebook mode (AES-ECB) processes each block one by one, so a slight change to the plaintext input would result in a completely different 128-bit block.
Nothing in the scoreboard’s documentation, product page, or manual said encryption was turned on - the kind of thing that would be advertised. We might have even picked a different scoreboard to attack had we seen this upfront. The discovery of encryption presented quite a challenge. Yet, we knew that attacks were still very possible. After talking it over, we developed two main types of RF attacks:
- Replay attacks, wherein we would prepare and gather many recordings of the binary for different game states, then transmit a particular binary at the right moment during a game, thus disrupting or changing the scoreboard; or
- What I called the “block swapping attack,” which involved replacing one sequence of 128 bits with another, thus injecting specific changes into the scoreboard during the game.
However, we don’t have to do any of that if we can crack the encryption. This is where Maxwell really brought out the big guns for hardware hacking. We’ll get more into that in part three and the rest of our process for completely pwning the scoreboard over the air!
About Jesse Victors, Senior Security Engineer
Jesse Victors is a senior security engineer at Security Innovation. His technical interests include privacy and anonymity systems, password cracking, RF attacks, and applied cryptography. Jesse has also published The Onion Name System: Tor-powered Decentralized DNS for Tor Onion Services and spoken at the Privacy-Enhancing Technology Symposium. In the evening you can often find him in virtual reality games, fiddling with amateur radio antennas, and networking with orbiting satellites. Jesse has pursued information security since 2014. Connect with him on LinkedIn.
About Maxwell Dulin, Senior Security Engineer
Maxwell Dulin is a senior security engineer at Security Innovation who specializes in web application security and IoT security. He has also spoken at DEFCON for his IoT research on the Zyxel NAS and is the founder/creator of the Spokane Cyber Cup. In his free time, he plays dodgeball and enjoys hiking. Connect with him on LinkedIn.
