Airdrop-ng is described as being a ‘rule-based Deauth(entication) tool’.
Airdrop is now available through the standard Backtrack repositories, can install with ;
Different from other deauthentication tools, Airdrop provides a means to either allow or deny clients to the same access point at the same time, as well as other nifty functions such as allowing or denying access based on hardware type (hardware name or OUI).
This allowance or denial is based on rules which are entered in a text file read by the application.
The way it works is fairly staightforward, first airodump needs to be started, configured to write out to a .csv file.
Then airdrop is started, linking to the csv file and pointing to a rules configuration file where the drop rules are entered.
So the main thing is to figure out what you want to achieve with this tool running, prepare the file with drop rules accordingly and then let it rip !
First things first, start up airodump and configure to write to a .csv file ;
Now to create a file with the Airdrop drop rules.
The standard format is;
a(allow)/bssid mac(or ‘any’)|client mac(or ‘any’)
d(deny)/bssid mac(or ‘any’)|client mac(or ‘any’)
In the written examples I am using 00-11-22-33-44-55 as AP mac and 55-44-33-22-11-00 as Client mac.
This for simplicity’s sake.
Some of the actual picture examples show different macs addresses as these are taken from an actual test run requiring actual connections.
To start off, I will first create a simple file with a ‘deny all’ rule for a specific AP ;
This rule will deny all clients access to the AP with mac address 00:11:22:33:44:55.
(Can also enter MAC addresses in the standard format; 00:11:22:33:44:55)
So now time to run Airdrop ;
(You can also include the -p option to disable the use of Pysco, gets rid of the ‘Not Found’ message ..)
[Depending on how it was installed, the below commands likely need to be started with ./airdrop-ng]
You can also include the -b option for some more detail (Rule debugging);
Now to edit the rules file to allow a client to access ;
As rules are run in a cascading order (from top to bottom) note that the Allow rules should be placed above the Deny rule ;
With the above when running airdrop, all clients except 55-44-33-22-11-00 will be denied access to AP in question.
(Similar to an access point’s mac-filtering approach)
There is no real need to include “#Allow rule” and the “#Deny rule”, its just for clarity’s sake.
Another nice function is the ability to Allow or Deny access to certain hardware based on OUI codes or (some) hardware names.
The OUI list can be updated in airdrop as follows (of course need to be online);
The OUI list can be found @ /pentest/wireless/airdrop-ng/support/oui.txt
I have only tested this using names on my network with Linksys and Intel equipment.
For instance, you can create a rule to deny all clients access to a Linksys router (WRT54G was tested) as follows ;
The airdrop-ng result ;
Or you can create a rule to deny linksys adapters from accessing a certain AP ;
The airdrop-ng result ;
Each time Airdrop finishes sending packets it re-parses the airodump csv file for changes as well as the rules file, this means that the rules file can be updated even while Airdrop is running.