The Cryptography is derived from the Greek words "Kryptos". This is the study of secure communication techniques that allow only the sender and recipient of a message to view it's contents of transforming information into nonhuman readable form or vice versa is called cryptography.
As we know that information plays a vital role in running of any business and organizations etc, sensitive details in the wrong hands can leads to loss of business.
Cryptography is the science of ciphering and deciphering messages.To secure communication organizations use cryptology to cipher information .
Or
Cryptography is a method of protecting information and communication through the use of codes so that only those whom the information is intended can read and process it.
In Computer Science, Cryptography refers to secure information and communication techniques derived from mathematical concepts , a set of rule based calculations called algorithm to transform message in ways the hard to readable for human.
This is one of the secure way of communications for a hacker with the help of virtual private network(VPN) like Tor Browser which is also very helpful to change the IP Address(Location of the sender ) for illegal purpose to perform crime in cyberspace . I will discuss in brief about the VPN .
How to Encrypt and Decrypt the text in Cryptography?
Open this website with the help of internert surfing for encryption-"http://wwwmd5online.org"
Open the link for Decrypt the code text-"http://www.md5online.org/md5-decrypt.html"
Type whatever you want for encryption and it will crypt in the code form, copy that code and forward to the intended person whom you want for secure communication and then he/she will Decrypt in the real form.
Bob was tasked to break into XYZcorporation, 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.
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. Weneed 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.
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:
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:
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:
down down up up up down down down down
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 analyzeRF 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.
Since last month the foundation has been busy working towards enabling our project leaders and community members to utilize funds to work on nurturing and developing projects. So far there has been huge uptake on this initiative. It's great to see so many people passionate about collaborating at project summits.
Our Global AppSec Tel-Aviv is nearly upon us, for members, there is an extra incentive for attending this conference, in the form of a significant discount. This and the sandy beaches and beautiful scenery, not to mention the great speakers and trainers we have lined up, is a great reason to attend. If you have not done so we would encourage you to attend this great conference - https://telaviv.appsecglobal.org.
One of the key things I've noticed in my Board of Director tenure is the passion our community emits, sometimes this passion aids in growing the foundation, but sometimes it also forces us to take a step back and look at how we do things within the foundation. With Mike, our ED and staff we have seen a lot of good change from an operations perspective, with more in the pipeline. Mike's appointment has allowed the Board of Directors to take a step back from operations and enable us to work on more strategic goals. To this end at a recent Board meeting we discussed each Board member taking up one of the following strategic goals, as set out at the start of the year:
1.Marketing the OWASP brand 2.Membership benefits 3.Developer outreach
Improve benefits
Decrease the possibility of OWASP losing relevance
Reaching out to management and Risk levels
Increase involvement in new tech/ ways of doing things – dev ops
4.Project focus
Get Universities involved
Practicum sponsored ideas
Internships
5.Improve finances 6.Improve OWAP/ Board of Directors Perception 7.Process improvement 8. Get consistent ED 9.Community empowerment
I would encourage the community to come forward if you have any ideas on the above and are happy to work with one of the 7 Board of Directors and community members on one of these initiatives.
Thanks and best wishes, Owen Pendlebury Vice Chair
OWASP FOUNDATION UPDATE FROM INTERIM EXECUTIVE DIRECTOR:
OWASP Foundation welcomes aboard Emily Berman as Events Director. Emily was most recently with the Scrum Alliance where she planned high-profile functions for upwards of 2,000 guests. Emily brings a fresh approach to events planning and her 12 years of experience planning and organizing large-scale events worldwide well in advance will greatly benefit our Global AppSecs.
We have had the following projects added to the OWASP inventory. Please congratulate these leaders and check out the work they have done:
Project
Type
Leader(s)
Risk Assessment Framework
Documentation
Ade Yoseman Putra, Rejah Rehim
QRLJacker
Tool
Mohammed Baset
Container Security Verification Standard
Documentation
Sven Vetsch
Find Security Bugs
Code
Philippe Arteau
Vulnerable Web Application
Code
Fatih Çelik
D4N155
Tool
Julio Pedro de Lira Neto
Jupiter
Tool
Matt Stanchek
Top 10 Card Game
Documentation
Dennis Johnson
Samurai WTF
Code
Kevin Johnson
DevSecOps Maturity Model
Documentation
Timo Pagel
Also, we will have the following projects presenting at the Project Showcase Global AppSec Tel Aviv:
Final Schedule
Wednesday, May 29th
Thursday, May 30th
Time
Project
Presenter(s)
Confirmed
Time
Project
Presenter(s)
Confirmed
10:45 a.m.
Glue Tool
Omer Levi Hevroni
Yes
10:30 a.m.
API Security
Erez Yalon, Inon Shkedy
Yes
7
11:55 a.m.
IoT & Embedded AppSec
Aaron Guzman
Yes
11:50 a.m.
Mod Security Core Rule Set
Tin Zaw
Yes
12:25 p.m.
Automated Threats
Tin Zaw
Yes
12:30 p.m. Lunch Break
12:55 p.m. Lunch Break
2:35 p.m.
SAMM
John DiLeo
Yes
3:10 p.m.
Application Security Curriculum
John DiLeo
Yes
3:10 p.m.
Damned Vulnerable Serveless Application
Tal Melamed
Yes
Finally, if you are able to help participate in the Project Reviews at the Conference, please send me an email at harold.blankenship@owasp.com. We have a large line-up of projects to review this time around:
Google Summer of Code Update: We were allocated 13 students this year! The current timeline is as follows:
Google Season of Docs: We were accepted into the Google Season of Docs. There will be a single technical writer resource. The current timeline is as follows:
COMMUNITY
New OWASP Chapters Riyadh, Saudi Arabia Guayaquil, Equador Lome, Togo Natal, Brazil Nashua, New Hampshire Gwalior, India Louisville, Kentucky Nainital, India Liverpool, United Kingdom Syracuse, New York
MEMBERSHIP
We would like to welcome the following Premier and Contributor Corporate Members.
