All students intending to graduate with a Bachelor of Science in Cybersecurity must complete a relevant project during the CYBER-400 Capstone course at Mount Saint Mary's University. Though there were several ideas for projects to attempt, the final choice was a remote signal exploit reliant on a low-cost software-defined radio. This project presented an opportunity to exhibit skills we already possessed and a hands-on way to gain a multitude of new skills and proficiency in new software. A few walkthroughs on how this process can be accomplished already exist, but after watching several hours of content attempting to follow along, it was apparent that none of them would accomplish what we needed to do, for various reasons. Most of these issues were caused by somewhat outdated software we were attempting to pair up with our modern Raspberry Pi hardware. After many hours of trial and error, this replay attack was able to be performed on a remotely activated power outlet and can be performed in identical fashion on older-style garage doors which do not implement a rolling code security mechanism.
Raspberry Pi 4 8gb Starter Kit by Canakit
Antenna (an unshielded copper wire will work fine)
A device to perform the attack on, in our case a remotely controlled power outlet
Before getting hands on with any hardware, we completed thorough background research including sourcing necessary hardware, determining software needed for various steps in the process, and possibly finding solutions to errors before we encountered them. However, oftentimes encountering an issue during a project is unavoidable, and we faced several along the way.
The first issue we encountered involved running Rpitx on our Pi4. The creator of this software gives compatibility notes for each release of the Raspberry Pi, and unfortunately it is still in beta for the Pi4, with no news of being updated any time soon. The most obstructive bug we discovered is that all video output from the Pi's onboard HDMI output is lost upon running the program, and therefore you cannot use your device at all until the Pi is restarted. Our workaround for this was to RDP into the Pi from a secondary computer. This had its quirks and required tinkering to change user privileges, but overall worked for what we needed it to do.
Another issue we had involved the copper wire we were using as an antenna. With the help of our software-defined radio, several tests could be conducted to measure the clarity of a signal output from the wire, which was attached to GPIO Pin 4 on the Pi. Demo versions of the final antenna chosen varied in length, thickness, if the wire was shielded or not, and the way in which the wire would be attached to the Pi. Here is an image of the final version chosen displaying how it connects to the Pi:
Though there were several other problems we faced along the way, the last one I will mention is that there is not a clear procedure on how to use this software, and any tutorial available online did not work to capture or replay the signal. I suspect the issues are a result of included packages changing between multiple releases, but there were many functions other users relied on that were no longer available at our time of testing. Overall, there is not a surplus of information surrounding this program, but my hope is that this guide can provide some information for other users.
After receiving our Pi4 kit and constructing it, we went through the initial process of installing Raspbian and setting up various users within the OS. Our next steps involved installing our primary software, Rpitx. In addition, SDR# was installed on both our Pi and a Windows machine, mostly for the purpose of debugging. Finally, we needed to install the proper drivers to allow communication between the SDR and the software, which can be found on the website of the SDR manufacturer.
After some troubleshooting, we realized that we would need to remotely access the Pi to use Rpitx due to video output issues with our particular hardware/software combination. Using the Windows PC, we were able to properly launch and use the Rpitx software over RDP, as described previously.
A convenient and intuitive GUI menu is included with the software, but a command-line approach can be utilized if desired. The command-line functionality was beneficial throughout the many hours spent troubleshooting communication and output errors, but ultimately our successful attack was performed using the GUI. Of the available tutorials on YouTube, the majority relied on command-line approaches, and I found that most of these tutorials depended on features that were removed in the more recent releases of Rpitx.
Once we finally had the ability to launch the Rpitx software and demo proper functionality, we were able to begin the attack on the remote control. Using SDR#, we listened at around the range that the remote and receiver were meant to communicate at. By starting in a broad range and tuning in based on actual output, we're able to get a more stable transmission than by simply relying on the manufacturer's stated output.
Below is a screen capture of SDR# by Airspy, the software used to find the actual operating frequency of both the remote outlet and the garage door remote which the attack was tested on as well.
Once the exact frequency of the remote-outlet communications was determined, we fired up Rpitx once again and told it to listen at the frequency we now knew the remote would operate at.
Finally, with these steps in place, we were able to perform the attack, as shown in the video below:
The beginning of this video demonstrates the signal being sent from the remote to the outlet while our Pi listens on the same frequency. After listening to the communications occurring on this frequency, the signal is replayed to mimic the remote attempting to communicate, but instead this signal is actually coming from the Pi. This is an example of a replay attack, a fundamental type of vulnerability studied in cybersecurity, networking, and other fields.
This information repository is a simple to follow guide on a replay attack. The process of carrying it out is relatively simple after all the troubleshooting is complete and radio transmission fundamentals are understood. This attack can be carried out with various operating systems and software-defined radios, but the one common denominator is that Rpitx must be used, as it seems to be one of few software offerings to easily complete this task without specialized hardware. Unfortunately, it doesn't seem to be fully supported on newer hardware, but we managed to find workarounds for the multitudes of issues that presented themselves.
If we were to expand upon this project or have another student pick up where we left off, we would suggest implementing the hardware package in a more portable format. The Pi could likely be powered by a battery and connected to via a laptop, making this a fully portable attack device. If one were to attempt this attack on a vehicle or other system implementing a rolling code security system, it can be relatively easily exploited using a signal jammer to perform a roll jam attack. There already exists plenty of documentation on this process, and using the information already learned in this attack the roll jam could be easily performed. Though this process is not the most technically in-depth process, it provided exposure to radio technologies, new hardware devices, new software programs, and a great example of how those with malicious intent can exploit vulnerabilities with access to very cheap devices. In conclusion, this project provided a great opportunity to place into action the skillset gained from the Bachelors in Cybersecurity at Mount Saint Mary's University.