Are you tired of reading endless news stories about ethical hacking and not really knowing what that means? Let's change that!
This Post is for the people that:
Have No Experience With Cybersecurity (Ethical Hacking)
Have Limited Experience.
Those That Just Can't Get A Break
OK, let's dive into the post and suggest some ways that you can get ahead in Cybersecurity.
I receive many messages on how to become a hacker. "I'm a beginner in hacking, how should I start?" or "I want to be able to hack my friend's Facebook account" are some of the more frequent queries. Hacking is a skill. And you must remember that if you want to learn hacking solely for the fun of hacking into your friend's Facebook account or email, things will not work out for you. You should decide to learn hacking because of your fascination for technology and your desire to be an expert in computer systems. Its time to change the color of your hat 😀
I've had my good share of Hats. Black, white or sometimes a blackish shade of grey. The darker it gets, the more fun you have.
If you have no experience don't worry. We ALL had to start somewhere, and we ALL needed help to get where we are today. No one is an island and no one is born with all the necessary skills. Period.OK, so you have zero experience and limited skills…my advice in this instance is that you teach yourself some absolute fundamentals.
Let's get this party started.
What is hacking?
Hacking is identifying weakness and vulnerabilities of some system and gaining access with it.
Hacker gets unauthorized access by targeting system while ethical hacker have an official permission in a lawful and legitimate manner to assess the security posture of a target system(s)
There's some types of hackers, a bit of "terminology". White hat — ethical hacker. Black hat — classical hacker, get unauthorized access. Grey hat — person who gets unauthorized access but reveals the weaknesses to the company. Script kiddie — person with no technical skills just used pre-made tools. Hacktivist — person who hacks for some idea and leaves some messages. For example strike against copyright.
A bit over a month ago I had the chance to play with a Dell KACE K1000 appliance ("http://www.kace.com/products/systems-management-appliance"). I'm not even sure how to feel about what I saw, mostly I was just disgusted. All of the following was confirmed on the latest version of the K1000 appliance (5.5.90545), if they weren't working on a patch for this - they are now.
Anyways, the first bug I ran into was an authenticated script that was vulnerable to path traversal:
That bug is neat, but its post-auth and can't be used for RCE because it returns the file as an attachment :(
So moving along, I utilized the previous bug to navigate the file system (its nice enough to give a directory listing if a path is provided, thanks!), this led me to a file named "kbot_upload.php". This file is located on the appliance at the following location:
This script includes "KBotUpload.class.php" and then calls "KBotUpload::HandlePUT()", it does not check for a valid session and utilizes its own "special" means to auth the request.
The "HandlePut()" function contains the following calls:
The server checks to ensure that the request is authorized by inspecting the "checksum" variable that is part of the server request. This "checksum" variable is created by the client using the following:
// our tracking of ips really sucks and when I'm vpn'ed from // home I couldn't get patching to work, cause the ip that // was on the machine record was different from the // remote server ip. return md5("$filename $machineId $mac" . 'ninjamonkeypiratelaser#[@g3rnboawi9e9ff'); }
The "secret" value is hardcoded into the application and cannot be changed by the end user (backdoor++;). Once an attacker knows this value, they are able to bypass the authorization check and upload a file to the server.
In addition to this "calcTokenChecksum" check, there is a hardcoded value of "SCRAMBLE" that can be provided by the attacker that will bypass the auth check (backdoor++;):
Once this check is bypassed we are able to write a file anywhere on the server where we have permissions (thanks directory traversal #2!), at this time we are running in the context of the "www" user (boooooo). The "www" user has permission to write to the directory "/kbox/kboxwww/tmp", time to escalate to something more useful :)
From our new home in "tmp" with our weak user it was discovered that the KACE K1000 application contains admin functionality (not exposed to the webroot) that is able to execute commands as root using some IPC ("KSudoClient.class.php").
The "KSudoClient.class.php" can be used to execute commands as root, specifically the function "RunCommandWait". The following application call utilizes everything that was outlined above and sets up a reverse root shell, "REMOTEHOST" would be replaced with the host we want the server to connect back to:
I get emails from readers asking for specific malware samples and thought I would make a mini post about it.
Yes, I often obtain samples from various sources for my own research.
I am sometimes too lazy/busy to post them but don't mind sharing. If you are looking for a particular sample, feel free to ask. I might have it.
Send MD5 (several or few samples). I cannot provide hundreds/thousands of samples or any kind of feeds. If you ask for a particular family, I might be able to help if I already have it.
Unfortunately, I do not have time to do homework for students and provide very specific sets for malware with specific features as well as guarantee the C2s are still active. Send your MD5(s) or at least malware family and I check if I have it :) If i have it, I will either send you or will post on the blog where you can download.
If you emailed me in the past and never got an answer, please remind me. Sometimes emails are long with many questions and I flag them to reply to later, when I have time and they get buried or I forget. It does not happen very often but accept my apologies if it happened to you.
A lot can go wrong when validating SAML messages. When auditing SAML endpoints, it's important to look out for vulnerabilities in the signature validation logic. XML Signature Wrapping (XSW) against SAML is an attack where manipulated SAML message is submitted in an attempt to make the endpoint validate the signed parts of the message -- which were correctly validated -- while processing a different attacker-generated part of the message as a way to extract the authentication statements. Because the attacker can arbitrarily forge SAML assertions which are accepted as valid by the vulnerable endpoint, the impact can be severe. [1,2,3]
Testing for XSW vulnerabilities in SAML endpoints can be a tedious process, as the auditor needs to not only know the details of the various XSW techniques, but also must handle a multitude of repetitive copy-and-paste tasks and apply the appropriate encoding onto each message. The latest revision of the XSW-Attacker module in our BurpSuite extension EsPReSSo helps to make this testing process easier, and even comes with a semi-automated mode. Read on to learn more about the new release!
SAML XSW-Attacker
After a signed SAML message has been intercepted using the Burp Proxy and shown in EsPReSSO, you can open the XSW-Attacker by navigating to the SAML tab and then the Attacker tab. Select Signature Wrapping from the drop down menu, as shown in the screenshot below:
To simplify its use, the XSW-Attacker performs the attack in a two step process of initialization and execution, as reflected by its two tabs Init Attack and Execute Attack. The interface of the XSW-Attacker is depicted below.
XSW-Attacker overview
The Init Attack tab displays the current SAML message. To execute a signature wrapping attack, a payload needs to be configured in a way that values of the originally signed message are replaced with values of the attacker's choice. To do this, enter the value of a text-node you wish to replace in the Current value text-field. Insert the replacement value in the text-field labeled New value and click the Add button. Multiple values can be provided; however, all of which must be child nodes of the signed element. Valid substitution pairs and the corresponding XPath selectors are displayed in the Modifications Table. To delete an entry from the table, select the entry and press `Del`, or use the right-click menu.
Next, click the Generate vectors button - this will prepare the payloads accordingly and brings the Execute Attack tab to the front of the screen.
At the top of the Execute Attack tab, select one of the pre-generated payloads. The structure of the selected vector is explained in a shorthand syntax in the text area below the selector. The text-area labeled Attack vector is editable and can be used to manually fine-tune the chosen payload if necessary. The button Pretty print opens up a syntax-highlighted overview of the current vector. To submit the manipulated SAML response, use Burp's Forward button (or Go, while in the Repeater).
Automating XSW-Attacker with Burp Intruder
Burp's Intruder tool allows the sending of automated requests with varying payloads to a test target and analyzes the responses. EsPReSSO now includes a Payload Generator called XSW Payloads to facilitate when testing the XML processing endpoints for XSW vulnerabilities. The following paragraphs explain how to use the automated XSW attacker with a SAML response.
First, open an intercepted request in Burp's Intruder (e.g., by pressing `Ctrl+i`). For the attack type, select Sniper. Open the Intruder's Positions tab, clear all payload positions but the value of the XML message (the `SAMLResponse` parameter, in our example). Note: the XSW-Attacker can only handle XML messages that contain exactly one XML Signature. Next, switch to the Payloads tab and for the Payload Type, select Extension-generated. From the newly added Select generator drop-down menu, choose XSW Payloads, as depicted in the screenshot below.
While still in the Payloads tab, disable the URL-encoding checkbox in the Payload Encoding section, since Burp Intruder deals with the encoding automatically and should suffice for most cases. Click the Start Attack button and a new window will pop up. This window is shown below and is similar to the XSW Attacker's Init Attack tab.
Configure the payload as explained in the section above. In addition, a schema analyzer can be selected and checkboxes at the bottom of the window allow the tester to choose a specific encoding. However, for most cases the detected presets should be correct.
Click the Start Attack button and the Intruder will start sending each of the pre-generated vectors to the configured endpoint. Note that this may result in a huge number of outgoing requests. To make it easier to recognize the successful Signature Wrapping attacks, it is recommended to use the Intruder's Grep-Match functionality. As an example, consider adding the replacement values from the Modifications Table as a Grep-Match rule in the Intruder's Options tab. By doing so, a successful attack vector will be marked with a checkmark in the results table, if the response includes any of the configure grep rules.
Credits
EsPReSSO's XSW Attacker is based on the WS-Attacker [4] library by Christian Mainka and the original adoption for EsPReSSO has been implemented by Tim Günther. Our students Nurullah Erinola, Nils Engelberts and David Herring did a great job improving the execution of XSW and implementing a much better UI.
Information gathering can be broken into seven logical steps. Footprinting is performed during the first two steps of unearthing initial information and locating the network range.
Footprinting
Footprinting is defined as the process of establishing a scenario or creating a map of an organization's network and systems. Information gathering is also known as footprinting an organization. Footprinting is an important part of reconnaissance process which is typically used for collecting possible information about a targeted computer system or network. Active and Passive bothcould be Footprinting. The example of passive footprinting is assessment of a company's website, whereas attempting to gain access to sensitive information through social engineering is an example of active information gathering. Basically footprinting is the beginning step of hacker to get hacked someone because having information about targeted computer system is the main aspect of hacking. If you have an information about individual you wanna hack so you can easily hacked that individual. The basic purpose of information gathering is at least decide what type of attacks will be more suitable for the target. Here are some of the pieces of information to be gathered about a target during footprinting:
Domain name
Network blocks
Network services and applications
System architecture
Intrusion detection system
Authentication mechanisms
Specific IP addresses
Access control mechanisms
Phone numbers
Contact addresses
Once this information is assemble, it can give a hacker better perception into the organization, where important information is stored, and how it can be accessed.
Footprinting Tools
Footprinting can be done using hacking tools, either applications or websites, which allow the hacker to locate information passively. By using these footprinting tools, a hacker can gain some basic information on, or "footprint," the target. By first footprinting the target, a hacker can eliminate tools that will not work against the target systems or network. For example, if a graphics design firm uses all Macintosh computers, then all hacking software that targets Windows systems can be eliminated. Footprinting not only speeds up the hacking process by eliminating certain tool sets but also minimizes the chance of detection as fewer hacking attempts can be made by using the right tool for the job. Some of the common tools used for footprinting and information gathering are as follows:
Domain name lookup
Whois
NSlookup
Sam Spade
Before we discuss these tools, keep in mind that open source information can also yield a wealth of information about a target, such as phone numbers and addresses. Performing Whois requests, searching domain name system (DNS) tables, and using other lookup web tools are forms of open source footprinting. Most of this information is fairly easy to get and legal to obtain.
Footprinting a Target
Footprinting is part of the preparatory pre-attack phase and involves accumulating data regarding a target's environment and architecture, usually for the purpose of finding ways to intrude into that environment. Footprinting can reveal system vulnerabilities and identify the ease with which they can be exploited. This is the easiest way for hackers to gather information about computer systems and the companies they belong to. The purpose of this preparatory phase is to learn as much as you can about a system, its remote access capabilities, its ports and services, and any specific aspects of its security.
DNS Enumeration
DNS enumeration is the process of locating all the DNS servers and their corresponding records for an organization. A company may have both internal and external DNS servers that can yield information such as usernames, computer names, and IP addresses of potential target systems.
NSlookup and DNSstuff
One powerful tool you should be familiar with is NSlookup (see Figure 2.2). This tool queries DNS servers for record information. It's included in Unix, Linux, and Windows operating systems. Hacking tools such as Sam Spade also include NSlookup tools. Building on the information gathered from Whois, you can use NSlookup to find additional IP addresses for servers and other hosts. Using the authoritative name server information from Whois ( AUTH1.NS.NYI.NET ), you can discover the IP address of the mail server.
Syntax
nslookup www.sitename.com
nslookup www.usociety4.com
Performing DNS Lookup
This search reveals all the alias records for www.google.com and the IP address of the web server. You can even discover all the name servers and associated IP addresses.
Understanding Whois and ARIN Lookups
Whois evolved from the Unix operating system, but it can now be found in many operating systems as well as in hacking toolkits and on the Internet. This tool identifies who has registered domain names used for email or websites. A uniform resource locator (URL), such as www.Microsoft.com , contains the domain name ( Microsoft.com ) and a hostname or alias ( www ). The Internet Corporation for Assigned Names and Numbers (ICANN) requires registration of domain names to ensure that only a single company uses a specific domain name. The Whois tool queries the registration database to retrieve contact information about the individual or organization that holds a domain registration.
Using Whois
Go to the DNSStuff.com website and scroll down to the free tools at the bottom of the page.
Enter your target company URL in the WHOIS Lookup field and click the WHOIS button.
Examine the results and determine the following:
Registered address
Technical and DNS contacts
Contact email
Contact phone number
Expiration date
Visit the company website and see if the contact information from WHOIS matches up to any contact names, addresses, and email addresses listed on the website.
If so, use Google to search on the employee names or email addresses. You can learn the email naming convention used by the organization, and whether there is any information that should not be publicly available.
"Ettercap is a suite for man in the middle attacks on LAN. It features sniffing of live connections, content filtering on the fly and many other interesting tricks. It supports active and passive dissection of many protocols (even ciphered ones) and includes many feature for network and host analysis." read more...
Why ethical hacking? Legality of Ehical Hacking Ethical hacking is legal if the hacker abides by the rules stipulated in above section on the definition of ethical hacking. Ethical hacking is not legal for black hat hackers.They gain unauthorized access over a computer system or networks for money extortion.
Is an elf32 static and stripped binary, but the good news is that it was compiled with gcc and it will not have shitty runtimes and libs to fingerprint, just the libc ... and libprhrhead This binary is writed by Ricardo J Rodrigez
When it's executed, it seems that is computing the flag:
But this process never ends .... let's see what strace say:
There is a thread deadlock, maybe the start point can be looking in IDA the xrefs of 0x403a85 Maybe we can think about an encrypted flag that is not decrypting because of the lock.
This can be solved in two ways:
static: understanding the cryptosystem and programming our own decryptor
dynamic: fixing the the binary and running it (hard: antidebug, futex, rands ...)
At first sight I thought that dynamic approach were quicker, but it turned more complex than the static approach.
2. Static approach
Crawling the xrefs to the futex, it is possible to locate the main:
With libc/libpthread function fingerprinting or a bit of manual work, we have the symbols, here is the main, where 255 threads are created and joined, when the threads end, the xor key is calculated and it calls the print_flag:
The code of the thread is passed to the libc_pthread_create, IDA recognize this area as data but can be selected as code and function.
This is the thread code decompiled, where we can observe two infinite loops for ptrace detection and preload (although is static) this antidebug/antihook are easy to detect at this point.
we have to observe the important thing, is the key random?? well, with the same seed the random sequence will be the same, then the key is "hidden" in the predictability of the random.
If the threads are not executed on the creation order, the key will be wrong because is xored with the th_id which is the identify of current thread.
The print_key function, do the xor between the key and the flag_cyphertext byte by byte.
And here we have the seed and the first bytes of the cypher-text:
With radare we can convert this to a c variable quickly:
And here is the flag cyphertext:
And with some radare magics, we have the c initialized array:
radare, is full featured :)
With a bit of rand() calibration here is the solution ...
First we have to patch the anti-debugs, on beginning of the thread there is two evident anti-debugs (well anti preload hook and anti ptrace debugging) the infinite loop also makes the anti-debug more evident:
There are also a third anti-debug, a bit more silent, if detects a debugger trough the first available descriptor, and here comes the fucking part, don't crash the execution, the execution continues but the seed is modified a bit, then the decryption key will not be ok.
Ok, the seed is incremented by one, this could be a normal program feature, but this is only triggered if the fileno(open("/","r")) > 3 this is a well known anti-debug, that also can be seen from a traced execution.
Ok, just one byte patch, seed+=1 to seed+=0, (add eax, 1 to add eax, 0)
before:
after:
To patch the two infinite loops, just nop the two bytes of each jmp $-0
Ok, but repairing this binary is harder than building a decryptor, we need to fix more things:
The sleep(randInt(1,3)) of the beginning of the thread to execute the threads in the correct order
Modify the pthread_cond_wait to avoid the futex()
We also need to calibrate de rand() to get the key (just patch the sleep and add other rand() before the pthread_create loop
Adding the extra rand() can be done with a patch because from gdb is not possible to make a call rand() in this binary.
With this modifications, the binary will print the key by itself.
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.
Related articles
