jc-aircrack

jc-aircrack is my own re-implementation of Christophe Devine's aircrack. It implements almost all of the KoreK statistical attacks. The big advantage that it has over the original is that

its written in C++,
it uses libairware
now with FPGA acceleration

I wrote jc-aircrack largely as a platform to experiment with other tricks and optimizations. Though the code has kind of grown haphazardly, it is still probably the most readable implementation of these attacks. If you can't read aircrack, give this version a try. It includes all of the related utilities (pcap2ivs, etc) excluding aireplay. One nice thing is that jc-airodump runs on OSX using the passive airport extreme driver available in kismac. Another nice features is the per-attack success counter at the bottom, which help tell you which heuristic functions are pulling their weight.

The following command tells jc-aircrack to crack a 13 byte key, to load a pcap file (-p) that comes with the distribution, to enable attack debug attacking output (-D A) and to be verbose (-v)

/jc-aircrack -n 13 -p ./test-data/weak-pcaps/00\:11\:22\:33\:44\:55\:66\:77\:88\:99\:AA\:BB\:CC.pcap -D A -v

The following table provides a good estimate as to how much faster the pico-accelerated code is relative to the software only implementation Don't forget. The numbers below indicate how much faster RC4 is running, not how much faster you will recover a key. Of course, being able to test keys faster helps, its just not simple linear relationship. The base speed for a the software only case was generated on my 1.6Ghz AMD machine. The card used for testing was a Pico-e12 Note that even though you can run two or four cores, you only need a single card. They just use different areas of the same card.

FPGA performance comparison
bits	no accelleration	two cores	four cores
16 (-x 2)	base speed	20 x speedup	38 x speedup
24 (-x 3)	base speed	21 x speedup	42 x speedup

you can see from the table that the cards get a little bit more throughput when bruteforcing larger chunks (24 vs 16 bits). Despite this, the best bang-for-your buck is probably the default 16 bit chunk, unless you have abnormally bad luck with the 3rd rightmost byte of the key. The preceeding data was gathered by running by running:
time ./jc-aircrack -n 13 -x 3 -p ./test-data/pico_tests/good-40-bit-test.pcap -F 16 -P 4 16 & sleep 120; killall jc-aircrack
while varying the pertinent arguments (-x and -P) And then doing the math. This data was gathered with 0 delay when changing the state of the pico cards. If bugs crop up due to this, then the cards will run significantly slower. So far it seems Okay.