Monday, March 27, 2017

Lesser known features of Aircrack-ng

I recently received an email suggesting to adding features to aircrack-ng. Even though most of the stuff can be found in the documentation, it might be worth talking about.

Reading from compressed wordlist

Aircrack-ng can read words from a pipe, which is very convenient and you can use pretty much any program to generate words and display them on the screen (each line will be considered a word) and pass them to aircrack-ng.

About compressed files, there are tools to decompress files on the fly and display the output on the screen such as zcat who takes care of gzip compressed files (there are others and most compression/decompression tools have a feature to display decompressed output to the screen).

Here is how it would look like:

zcat file.gz | aircrack-ng pcap_to_crack.pcap -w -

In this example, it decompress file.gz and 'cat' the result to the screen, then we pipe it to aircrack-ng. Aircrack-ng reads wordlists files using -w and in order to tell it to get it from a pipe (to be technical, stdout from the previous command became stdin in aircrack-ng), you have to use the '-' as parameter for -w.

Rainbow tables

airolib-ng can generate tables (in SQLite format) or import them from cowpatty's format. Once the table is generated, use -r in aircrack-ng to read them (instead of a wordlist).

Distributed cracking

There is a tool in the script/ directory to do that called As a matter of fact, check out that entire directory, there are a few useful scripts in there.

Running the script will give you a help screen. Here is what the architecture look like to better understand the different parameters:

The different clients represent the cracking systems, the server coordinates everything based on the performance of each client. Each client joining the server will have its performance assessed and when a wordlist is uploaded, it will be split according to each client's performance so they all take the same amount of time to process the dictionary.

The laptop (you) send commands to the server to upload dictionary, to upload capture files, to start the cracking process and obtain the status of the cracking process (as well as the key).

When uploading a PCAP  file, it is highly recommended to clean it up and just leave a beacon as well as the 4 EAPoL packets (or less if you have less) of the 4-way handshake or you'll risk aircrack-ng choosing the wrong packets when cracking. There is a tutorial about it in the wiki.

Monday, February 20, 2017

iw monitor mode flags

Out of curiosity, I looked at iw to set monitor mode and it has the following flags:

Pretty much all of them seem pretty self-explanatory but it's worth giving more details about each of them:
  • fcsfailFCS (Frame Check Sequence) is the checksum of the frame (CRC32), to make sure it was received correctly. By default, a driver should only forward valid frames to the monitor mode interface. This flag allow you to receive frame that also fail the test. One of the use could be monitoring the quality of a wireless network.
  • control: There are 3 type of frames: data, management and control. Data is pretty obvious. Management help maintain a connection and control (beacons, probe request/response, authentication, association, deauthentication, deassociation, etc). Control help facilitate the transmission of frame between devices (ACK, RTS, CTS, etc). This is hardware-dependent.
  • otherbss: It would allow receiving frames from other BSS (other than the ones to/from the access point the card is connected to or the clients this access point is serving). This is hardware-dependent.
  • cook: Refer to a mode for HostAPd where authentication frames that mac80211 didn't actually look at. It is only for ancient versions of HostAPd.
  • active: ACK is time sensitive and software is too slow to answer it quick enough so this would be done in the hardware itself instead of software. If an ACK is not received within a certain amount of time, the frame will be considered as lost and a new frame with the retry flag will be sent. The only exception would be very long distance links: the longer the links, the longer it takes for a frame to arrive and in some rare cases, software could be fast enough.

TL;DR: none is what you need.