New tutorial

The most basic steps with Pyrit are now explained in a new tutorial as part of the wiki.

Pyrit 0.3.0 released

Pyrit 0.3.0 was just tagged and is now the currently stable version. Enjoy.

Due to the numerous changes after 0.2.4, I’ve advanced Pyrit’s “major-minor” revision number to 0.3. Highlights from the changelog include:

  • SSE2-support for the EAPOLCracker, making all attack-modes roughly 3x faster
  • Much improved lazy-loading of files, giving another 20% to 30% performance to all attack-modes
  • Support for using SQL-databases as a storage backend
  • Support for sharing GPUs and databases over the network

You can get the new version right here.

ATI Catalyst 10.2

Word of advice: Do not update to ATI’s 10.2 drivers. After the usual ~1 hour to get my system working again after the update, i had to find out that the new driver produces random segfaults in libaticaldd.so.

More on this on AMD’s Praise-And-Glory blog where the announcement is completed by (as the time of writing) 52 comments mostly about bugs and crashes…

Oh the irony

Using Pyrit in shell scripts

Pyrit 0.2.5-svn r216 now understands the option ‘-o’ (output-filename) in all attack-commands. The password – if found at all – is written to the given filename, which can be “-” to indicate stdout. This makes it very easy to integrate Pyrit into your own shell scripts.

Also note that Pyrit sets it’s process exit code depending on the result of the command. This behaviour has been integrated some time ago but seems to be pretty unknown. Pyrit signals failure in case…

  • the attack-commands do not find the password
  • the command verify stumbles upon a corrupted workunit
  • analyze can’t find at least one handshake in the capture-file
  • any runtime-error occurs

When combined, you can do things like:

# Save the password to a file (file is not touched if password is never found)
pyrit -r wpa2psk-linksys.dump.gz -i linksys.cow.gz -b 00:0b:86:c2:a4:85 -o 000b86c2a485_linksys.txt attack_cowpatty

# Send password by eMail via mailx
pyrit -r wpa2psk-linksys.dump.gz -i dict.gz -b 00:0b:86:c2:a4:85 -o – attack_passthrough | mailx -s “Password found” “myemail@mydomain”

# Batchprocess the database and then shutdown the computer
pyrit batch && shutdown -h now

We’ll have to go right to… Ludicrous Speed!

A recent update brought a SSE2-based execution path for Pyrit’s HMAC-SHA1 implementation and thereby a very compelling performance improvement for attack_db or attack_cowpatty when used with handshakes based on WPA2-PSK. The older WPA-PSK however utilises MD5 instead of SHA1 so that case could not equally benefit.

I’ve taken yesterday’s and today’s evening and the latest “Pyrit 0.2.5-svn r215” has shiny SSE2-code for MD5 now too. The numbers speak for themselves: Crunching a 2gb, 50 million entries cowpatty-file against a WPA-PSK handshake on my MacBook Pro 2×2.5Ghz took 1 minute and 27 seconds with r213 (575.000 passwords per second). The new r215 walks through the same file in just over 33 seconds (1.5 million passwords per second).

GC object already fucking tracked

I recently had a problem with the python interpreter crashing within it’s garbage-collector after changing some code in Pyrit’s C-extensions. More specifically, the interpreter sometimes crashed with the following error:

Fatal Python error: GC object already tracked

Crashes that involve referencing counting are hard to debug because the cause of the error (e.g. deallocating an object although there are still references to it) and the effect (assertion errors, random segfault) are usually temporal- and location-independent from each other. Searching for other cases of the error shown above via google revealed almost no valuable information for me.

I’ve found the problem and now write this blog-enry for google to bring it up to other people looking for an answer. The solution is found within the last sentence of CPython’s documentation about the PyTypeObject.tp_free-field. When an object’s type is subclassed, the object may suddenly become a target of CPython’s cyclic garbage collection. In that case, the default PyObject_Del that is usually found in your object’s PyTypeObject.tp_free becomes PyObject_GC_Del. My fault was to call PyObject_Del directly within PyTypeObject.tp_dealloc, ripping the object from the loving hands of the garbage collector.

Long story short:

PyObject_Del((PyObject*)self);
self->ob_type->tp_free((PyObject*)self);

Remember kids: Always use the slots of self->ob_type. Crash fixed.

Even better numbers…

… come with “Pyrit 0.2.5-dev r213” which improves performance of attacking WPA2 via precomputed (cowpatty-like) tables by about 30% to 40% for my little MacBook Pro. The new version does a 50 million entries, 2GB cowpatty file in about 37 seconds (1.3 million keys per seconds).

WPA-PSK will not benefit as much as WPA2-PSK as it partly uses MD5 instead of SHA1 for which we don’t have a SSE2-path yet.

Parsing bug fixed

Please notice that Pyrit 0.2.5-svn r210 fixes a quite serious bug that caused Pyrit to sometimes pick the wrong KeyScheme (e.g. HMAC_MD5_RC4 instead of HMAC_SHA1_AES) when parsing packet data. This in turn caused Pyrit to miss the correct passphrase even if it was supplied.

This does not affect computation of Pairwise Master Keys so databases/cowpatty-files created by Pyrit are not affected by this.

ATI Catalyst 10.1 working again…

With Catalyst 10.1 all I got was a blank screen after starting X. If you get an error like

[fglrx:fireglAsyncioIntDisableMsgHandler] *ERROR* IRQMGR returned error 1 when trying to disable interrupt source ff000066

you may want to try disabling Catalyst’s ACPI-functionality and remove some magic file:

aticonfig –acpi-services=off
mv /etc/ati/amdpcsdb /etc/ati/~amdpcsdb

It made my Xorg work again….

ATI Catalyst 10.1

Word of advice: Do not update to ATI’s 10.1 drivers. Besides glitches (like ATI apparently forgot to update the driver’s identification string so it still looks like 9.12) the driver seems to just not work for most people and leave them with nonworking systems. This includes myself :-(

More on this on AMD’s Praise-And-Glory blog where the announcement is completed by (as the time of writing) 134 comments mostly about bugs and crashes…

Follow

Get every new post delivered to your Inbox.