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.
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.
Pyrit 0.2.3-dev (C) 2008, 2009 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3
The 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…
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…
[root@localhost ~]# pyrit benchmark
Pyrit 0.2.3-dev (C) 2008, 2009 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3
After months in the standardization-pipeline, OpenCL seems to be finally somewhere around. OpenCL generalizes the access to parallel-computing technologies such as Nvidia’s CUDA, AMD’s Stream, IBM’s Cell/B.E., FPGA- or similar platforms by defining a common API that talks to the devices and a C-derived language to define the kernels. The goal is “write once, run everywhere”…
A few days ago Nvidia has pre-released a “conformance candidate” for it’s OpenCL-implementation to registered developers. Although this is a early stage, the quality of the tools and libraries already seems very promising. Nvidia clearly took a run for OpenCL with the changes to the CUDA-API since 2.0 and the transition from CUDA to OpenCL is nice and easy. I took Sunday afternoon and implemented a OpenCL-core for Pyrit; the new code was committed to svn as rev100.
End-users are actually not able to take use of the new core right now as the required GPU- and OpenCL-drivers are not available to the general public yet. In the long term however, the OpenCL-core will replace the CUDA-/AMD-specific code and provide access to other platforms like Cell/B.E. (->Pyrit on Playstation 3). This looks very promising…
Pyrit patched for MPI-support and running on a cluster with 16 GeForce 8800 GT has reached 89.300 PMKs/s according to this post. This is equivalent to around 1.460.000.000 rounds of SHA-1 or 749 Gbit of data processed every second.
Update: The author of the posting mentioned above sent a link to a video showing Pyrit on 14+1 nodes…
There is a bug in 0.2.2 regarding Null-bytes in imported passwords that causes Pyrit’s blobspace to get corrupted. Fixing this bug requires a slight change in the binary format of the blobspace. This means that databases handled by current svn-versions and upwards will not be compatible with those created by 0.2.2.
On the other hand we got more performance improvements e.g. by taking advantage of pyco if available. Importing 10.000.000 passwords takes just 30 seconds on my MacBook now – down from 137 seconds in 0.2.1…
Note that Pyrit’s current svn-versions require nvcc from CUDA 2.2 which is not yet publicly available. Please also note that Pyrit on MacOS now requires CUDA 2.1 (download here) as we no longer circumenvent the CU_CTX_SCHED_YIELD-bug that was present in 2.0-beta.
The last couple of days brought some very important performance improvements to Pyrit’s backend. Importing of passwords, writing to cowpatty files, evaluation of the blobspace etc. are *much* faster than before; the CPU-time consumed by the backend during batchprocessing is about 30% of what it was before.
