Pyrit allows to create massive databases, pre-computing part of the IEEE 802.11 WPA/WPA2-PSK authentication phase in a space-time-tradeoff. Exploiting the computational power of Many-Core- and other platforms through ATI-Stream, Nvidia CUDA, OpenCL and VIA Padlock, it is currently by far the most powerful attack against one of the world’s most used security-protocols.
WPA/WPA2-PSK is a subset of IEEE 802.11 WPA/WPA2 that skips the complex task of key distribution and client authentication by assigning every participating party the same pre shared key. This master key is derived from a password which the administrating user has to pre-configure e.g. on his laptop and the Access Point. When the laptop creates a connection to the Access Point, a new session key is derived from the master key to encrypt and authenticate following traffic. The “shortcut” of using a single master key instead of per-user keys eases deployment of WPA/WPA2-protected networks for home- and small-office-use at the cost of making the protocol vulnerable to brute-force-attacks against it’s key negotiation phase; it allows to ultimately reveal the password that protects the network. This vulnerability has to be considered exceptionally disastrous as the protocol allows much of the key derivation to be pre-computed, making simple brute-force-attacks even more alluring to the attacker. For more background see this article on the project’s blog.
The author does not encourage or support using Pyrit for the infringement of peoples’ communication-privacy. The exploration and realization of the technology discussed here motivate as a purpose of their own; this is documented by the open development, strictly sourcecode-based distribution and ‘copyleft’-licensing.
Pyrit is free software – free as in freedom. Everyone can inspect, copy or modify it and share derived work under the GNU General Public License v3+. It compiles and executes on a wide variety of platforms including FreeBSD, MacOS X and Linux as operation-system and x86-, alpha-, arm-, hppa-, mips-, powerpc-, s390 and sparc-processors.
All code can be found at http://pyrit.googlecode.com
A more theoretical background of Pyrit can be found here.
You can contact the author at lukas.lueg@gmail.com.
13 Comments
Comments RSS TrackBack Identifier URI
Pyrit 
hi there,
can you please explain, why the attack over the network has been removed? i mean the “serve” cmd.
best regards,
stephan
The implementation was based on HTTP and did not meet my expectations. Therefor it was removed in order not to block the release of version 0.2.3.
It will probably come back some time around 0.2.5
Have you seen the open source project GPU at: gpu.sourceforge.net? Unfortunately right now they only have a windows version of this, however, I’m wondering if it is possible to implement a similar functionality in pyrit to share cpu resources via a p2p platform….
Hey,
Very nice job!
I got only one question:
The new Intel integrated GPUs (4500MHD) can help in decoding HD-movies, so they are able to do some generic computing – which means, in my opinion, that perhaps pyrit can use it (sure it needs work, but it seems to be possible).
Can you confirm this?
Thank you!
AFAIK the 4500MHD has no generic API.
So no Pyrit-support for it
how python pyrit communicate with cuda, atistream, and opencl??
some source said to use PyCUDA, but pyrit not
did you make your own communication for pyrit??
Pyrit has a number of extension modules written in C that talk to the CUDA/Stream/OpenCL-drivers. The Wiki at http://code.google.com/p/pyrit/wiki/ExtendPyrit should give you a general idea.
Do you plan to support aircrack-ng .ivs rather than just .cap? It doesn’t look like there’s a simple way to reassemble a pcap file once the handshake has been stripped out. Thank you for making your code public and for sharing with the community.
there is no point in IVs, pyriz is no intended for wep
When using aircrack-ng with the –ivs option, both IVS and handshakes are stored in the same (small) file. The idea is that pcap files store more information than necessary and .ivs store just the authentication data.
We should incorporate attack against 2 wpa’s ‘inline’ simultaneously. Has anyone thought of this yet? If the bssid’s are the same, why not? Even if the bssid’s are different wouldn’t it save time?
Hi this sounds promosing, but first I would like to thank you for pyrit its an exceptional peice of software – great work.
Ok, so please correct me if I am wrong,
1. this new attack is cpu based and not gpu related.
2. it requires a pyrit database to be created using the ssid and dictionary to precompute the pmk’s
I am in the UK, and one of the largest suppliers of broadband here uses wpa as standard on their home routers. On all of these routers the standard key is comprised of 8 characters A-Z.
My setup is a couple of ati 5850’s and using : pyrit, cal++ and crunch I can bruteforce at around 125000 pmk’s per second.
now there are 209 billion combinations for this key, so this would take approx 19 days of 24×7 processing to obtain it.
given the new CCMP implementation, with a precomputed table and a i7 sb cpu @7.9m passwords per sec this would take just 30 mins.
If I just used crunch to create a brutefore dictionary file for these 209 billion permutations, I would be looking at a 1.7 tb file.
is there a limit to the size of database file pyrit can work with ?
The is no limit on the database-size imposed by Pyrit itself. There are however practical limits. For example, the filesystem-based database stores all workunit-files in the same directory, resulting in thousands of files in one directory. Some filesystems like EXT4 have *very* bad performance with such workloads.
The best way to create such a huge dataset would probably be to split the whole thing into different jobs. Each job works on a range of characters and outputs it’s result in cowpatty’s format. You end up having e.g. 1000 jobs, each doing 209 million passwords in roughly 30 minutes and creating 1000 files in the end. These files are much easier to handle than one giant 1.7tb database.
You can do all this with < 20 lines of shell- or python-scripts.