Towards the end of last year, I found myself playing around with some basic amplitude modulation (AM)/On-off keying (OOK) software defined radio. That resulted in ooktools being built to help with making some of that work easier and to help me learn. A little while ago, the Metasploit project announced new ‘rftransceiver’ capabilities that were added to the framework with a similar goal of making this research easier.
How things fit together
First things first. I had to try and understand how this new functionality actually works. From the Metasploit blog post, it was possible to see that the additions allowed you to communicate with a RFCat capable device from Metasploit and run modules over a session. A session is started by connecting to a small JSON API (with a python helper) that bridges HTTP requests to
Basically, the setup is:
metasploit HWBride Module ---> HTTP API from rfcat_msfrelay ---> rflib methods (and dongle)
All of this is still pretty new and experimental. In fact, not everything seems to be working 100%, yet. Regardless, I set out to port some of the signaling features I have in ooktools to pure Metasploit modules.
If this sounds a little foreign to you, I suggest you have a bash at googling some of the terms you don’t know. Google is an incredible teacher as the RF hacking world is becoming more of a thing™. The most valued resource I have found to date on the topic (specifically for on-off keying anyways) is part of Michael Ossmann’s (that cool SDR dude) “Software Defined Radio with HackRF” series. More specifically, lesson 8 was an amazing catalyst in fooling me into thinking “oh, I get this stuff!”.
The testing setup
For testing the new goodies, I have a yardstickone (which comes with the
rfcat firmware out the box). The updated modules were not part of Metasploit bundled with Kali yet, so I quickly built a docker container with the latest Metasploit HEAD cloned and setup in it. To get the api bridge I mentioned earlier, I cloned the RFCat repository and ran the rfcat_msfrelay script on my laptop (outside of the docker container) as Metasploit and the relay script talk using tcp/ip (duhr). This script will also work outside of the repository on its own if you have already installed the rfcat python module. It must be able to import
To start, the relay needs to be up. You can use the
--noauth flag so that the relay does not ask for credentials. Without it, the defaults are
msf_relay:rfcat_relaypass (which you can change).
The output is not very exciting, but alas, port 8080 opens up and we can connect a session from Metasploit. Over time, you should see the HTTP requests Metasploit makes to the bridge appear much like a web servers access log.
Connecting the hwbridge session
Next, we connect the HWBridge session from Metasploit. If you have ever used Metasploit, this will feel very familiar. Just
use auxiliary/client/hwbridge/connect, set the IP where the
rfcat_relay is running with
set RHOST <ip_address> and
run the module.
sessions -l will show you have a new session to your radio. It is possible to interact with the session and send some basic commands. In reality, these are just translated to API calls to the bridge, and the rflib methods called.
“Out of the box” Metasploit released two modules that were supposed to allow for transmitting signals and allow for some brute forcing to happen. I tested out the brute forcing module first just to get a feel for how things are supposed to work.
Hah! Brute forcing RF from Metasploit. I never thought I would see this day. The
rfcat_relay output started filling up with the API requests that were made from Metasploit to the bridge and I could see the signals from the brute force run using gnuradio too.
Nice! This was enough to convince me to write some modules! Considering there already was a brute force tool, I chose port the following remaining features from ooktools; sending an AM/OOK signal, searching for PWM encoded keys and a frequency jamming module.
Most of the hard work for this was already done and I just had to translate them really. The sending of signals module was the first to be built and works quite flawlessly with my lab light I have at home.
My remote sends a long flat line at the start, so I had to set the start padding. If you don’t set
RAW to true, the module will automatically PWM encode the binary you give it.
The next was the signal searcher. This one proved to be a bigger pain as it seems like the receiver code has not really been tested yet both in the relay script as well as in Metasploit itself. I made a PR upstream to fix up the bugs I encountered in Metasploit itself, and had to implement a new Metasploit method call and api bridge method to lowball to allow for some noise to come through when scanning. Nonetheless, the scanning seems to have worked reasonably ok.
Lastly, and arguably the easiest module of them all was the signal jammer. All I did here was send total rubbish until the user cancels the module running. With my testing, this makes a valid 433mhz remote on the right frequency (and a little bit off too) useless until the jam is stopped. Obviously range is also a thing.
I am very excited to see what else these new possibilities will bring to metasploit. If you want to play with the modules, I have them on github here: https://github.com/leonjza/metasploit-modules. A PR to see if these can be added to metasploit to will follow soon!