A note to users using code from trunk: You need to svn-update, recompile and reinstall the extension modules as they are now part of the ‘cpyrit’-package. The ‘_cpyrit’-package is gone.
0.2.4 gaining attack-capabilites
I’ve decided to take Pyrit one step further and add actual “attack capabilities”. I have some difficulties with this as the actual legal situation in germany is – putting it mildly – undefined. On the other hand I’m disappointed with the state of tools that currently are available….
So here is the juicy stuff: Pyrit 0.2.4-dev rev146 adds four new commands to the commandline-client:
- ‘analyze’ parses a pcap-dump and shows some information about AccessPoints, Stations and the presence of WPA-PSK handshakes.
- ‘attack_passthrough‘ is the most basic attack mode and resembles piping PMKs to other tools like cowpatty. It takes a pcap-dump and attacks available handshakes using passwords read from a file. The database is not touched at all by this. Good for LiveCDs but you lose the advantage of having pre-computed PMKs.
- ‘attack_batch‘ uses passwords and PMKs stored in the database to attack the handshake. The PMKs are taken from the databased if already computed. Otherwise the passwords are translated into their respective PMKs which are stored on-the-fly for later re-use.
- ‘attack_db‘ uses only PMKs that are already in the database. Handy if you don’t want your box to get crushed under load.
And here is what it looks like:
pyrit -r test.pcap -e dlink attack_batch
Pyrit 0.2.4-dev (svn r146) (C) 2008, 2009 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3Parsing file ‘test.pcap’… 426 packets (375 802.11-packets), 4 APs
Picked AccessPoint [hidden] automatically…
Attacking handshake with Station [hidden]…
Tried 3443172 PMKs so far; 675577 PMKs per second.The password is ‘12345678′.
Notice the number of 675,577 passwords per second :-) Oh and by the way: Pyrit will from now on require scapy to be installed, so check your package manager…
Ubuntu repository down…
Festor has shut down his launchpad repository so no more binary packages for you Ubuntu 9.04 users out there. Maybe one of you wants to create&submit a package for Ubuntu’s official repository?
Pyrit 0.2.3 goes live
Ok Pyrit 0.2.3 has been packaged and is now considered the currently stable version. How is that?
Apart from the *much* improved source-code, the more or less visible changes are already described here. There is also a lot of new documentation for Installation, Usage and Troubleshooting.
All the code can once again be found here.
Oh and did I mention Pyrit 0.2.3 seems to be the first open-source program *ever* that has working OpenCL-code in a regular release? “But nobody can use it!” you say? Details!
Enjoy Blackhat & defcon.
No binary packages for 0.2.3
I’ve decided that I will no longer provide any binary packages for Pyrit – therefor 0.2.3 be released as source-code only. Maybe someone wants to fill the gap and register a package on rpmfusion ?
Approaching 0.2.3
After almost exactly four months into the making, it should soon be time for Pyrit 0.2.3.
In order get 0.2.3 on the road before/around Black Hat and defcon, I have decided to cut out the network functionality and delay it until 0.2.4. Right now I want to focus on stability and (yes!) some documentation… Please report any errors and glitches you might find in the svn repository.
Some of the changes since 0.2.2:
* Added CLI-function ‘delete_essid’
* Added CLI-function ‘verify’
* Added CLI-function ’selftest’
* Added Core for OpenCL
* Added SSE2-path to CPU-Core
* Added docstrings to the code
* Fixed ‘CUDA_ERROR_INVALID_IMAGE’ when using CUDA 2.2
* Fixed process exit codes
* Improved scheduling between client and hardware
* Improved storage-code
* Improved performance for almost all CLI-functions
* Builds from SVN-directories now carry their revision-number
| Changes since 0.2.2: |
| * Added docstrings |
| * Added CLI-function 'delete_essid' |
| * Added CLI-function 'verify' |
| * Added CLI-function 'selftest' |
| * Added Core for OpenCL |
| * Added SSE2-path to CPU-Core |
| * Fixed 'CUDA_ERROR_INVALID_IMAGE' when using CUDA 2.2 |
| * Fixed process exit codes |
| * Improved scheduling between client and hardware |
| * Improved storage-code |
| * Improved performance for almost all CLI-functions |
| * Builds from SVN-directories now carry their revision-number |
Packages for Ubuntu 9.04, better documentation
Festor has posted a hint about his Personal Package Archive that provides builds of Pyrit (including CUDA and Stream support) for Ubuntu Jaunty. I know some of you have waited for this… Please note however that this repository is maintained outside of this project and that I have no control over what get’s installed from there.
I’ve also taken the opportunity and did a major overhault of Pyrit’s installation documentation which now also includes a paragraph on how to get the juice from Festor’s archive.
Combining passthough and batchprocess
It seems an often overlooked feature is that you can batchprocess (compute and write results to disk for use later on) and passthrough (compute and write results to stdout for immediate use) at the same time. All you have to do is specify ‘-f -’ as an option to the command batchprocess.
What happens is that Pyrit processes passwords for a single ESSID (given by ‘-e’), stores the results on disk and writes them to stdout. Results that already have been computed are immediately written to stdout. Batchprocess continues silently if stdout becomes unavailable (e.g. because the target program/shell closed the pipe). If all results have already been computed, batchprocess behaves almost exactly as passthrough does.
This way you can stop and resume a passthrough-run quite easily. It also prevents the need to re-compute in case Pyrit should brake down.
SSE2-support in SVN r112
Thanks to a initiative by Nathan Grennan we now have support for SSE2 in svn-revision r112. Get the latest code from trunk and enjoy a ~3x performance increase on recent CPUs. The SSE2-code was originally written by Alvaro Salmador.
In other news: Pyrit no longer uses psyco as it causes problems with SSE2 and Padlock and the project seems to be dead. Goodbye and thanks for all the fish.
Network functionality
Pyrit 0.2.3-dev (C) 2008, 2009 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3The following cores seem available…
#1: ‘CUDA-Device #1 ‘GeForce 8600M GT”
#2: ‘Network-Core @192.168.56.3′
#3: ‘CPU-Core (x86)’
Rev103 that was just committed to svn includes support for clustering multiple machines over the local network. This feature was often requested as it allows to use hardware much more effectively.
How it works:
- Pyrit has a new command ‘serve‘ that starts a server on the current host. A server listens for connections on port 19935 (setup those firewalls…) and can use the local hardware to compute for other clients.
- Clients can use multiple servers and each server can support multiple clients simultaneously.
- This is not a distributed database! The clients transfer their workunits to the servers and the servers compute the results and send them back. Bandwidth is a problem: 10.000 PMKs/s require about 30kb/s from the client to the server and about 300kb/s from the server to the client. This makes internet-connections too slow for most of us…
How to use:
- Get Pyrit-0.2.3-dev from trunk
- On the servers, the machines with the fast hardware:
- Start Pyrit with ‘pyrit serve‘.
- The server uses all available (local!) hardware just like a pyrit-session would do…
- Kill it with ctr+c when you are done. Beware that clients which are still waiting for results from that server will die…
- On the client, the machine that hosts the database:
- Edit ‘~/.pyrit/hosts‘. Add one IP/hostname per line for every server you have.
- Check if the server is reachable by opening ‘http://[Server-IP]:19935/‘ in your web-browser.
- Run ‘pyrit list_cores‘. It should list the new Network-Cores.
- The servers do not have to be online when you start Pyrit. Inactive servers get ignored…
- Use Pyrit like you would normally do. All functions (benchmark/batchprocess/passthrough) use the servers transparently and without further interaction.
I think the implementation is already quite reasonable; however you should expect some rough edges like unhandled exceptions/crashes caused by network timeouts and such…
