Another major feature of upcoming version 0.2.5 made it’s way to svn for testing: Pyrit’s storage code was abstracted and refactored which makes it possible to use relational databases like postgresql or mysql as storage devices for Pyrit. The actual database code is fully transparent and there is no visible difference for the client.

The benefit: Create a central mysql/pgsql/mssql/oracle/firebird/sqlite-server somewhere on your network and let multiple Pyrit-clients access and work on the central server for good; enjoy the blessings of ACID, partitioning, automatic backup, replication and fine-grained user authentication.

Here is a rough guideline on creating a postgresql-server for Pyrit.:

* Install and start the postgresql-server.
* Install sqlalchemy and psycopg2
* Switch to user postgres (‘su – postgres‘) and start the interactive shell (‘psql template1‘)
* Create a new user (‘create user pyrit;‘) and a new database (‘create database pyrit owner pyrit;‘). You do not need to create any tables, Pyrit will do that for you.
* Edit /var/lib/pgsql/data/pg_hba.conf (may be a different path for you) and add the lines “host pyrit pyrit 127.0.0.1/32 trust” and “host pyrit pyrit 192.168.0.1/24 trust” to the top of the file; this allows password-less access to the pyrit database on the local network. Restart the postgresql-server. See postgresql’s documentation for more information about authentication.
* Use the new option ‘-u‘ to tell Pyrit that it should use a server (instead of the default filesystem-driven storage). This option takes a URL which includes protocol, host, user, password and database to use. The special protocol ‘file://‘ refers to the filesystem, all other URLs are passed directly to sqlalchemy. You may want to see the documentation for details about the syntax.
* Run ‘pyrit -u postgres://pyrit:@127.0.0.1/pyrit -e test create_essid‘ to test the connection and create a new ESSID ‘test‘ in the database. All other of Pyrit’s functions also work as usual.

I’ve tried sqlite- (‘-u sqlite:///mydb.db‘), postgresql- and mysql-databases; all other rdms should work as well as long as they are supported by sqlalchemy. You should expect some rough behaviour (read: crashes with tracebacks) in case you do something which Pyrit does not expect to magically happen – deleting a ESSID from the database while a client is processing it falls under that definition.

I’ve just updated the Wiki with new entries about two of the visible changes in upcoming version 0.2.5 which are already in svn.

The new command attack_cowpatty takes PMKs from a file in cowpatty-format to attack a handshake found in a capture-file. The cowpatty-database may have been generated by genpmk or (more likely :-)) by export_cowpatty; the file can be gzip-compressed. This new command allows you to use cowpatty-databases as a more easily movable and/or manageable storage device than Pyrit’s own database. After computation has completed, you may export your PMKs to a cowpatty-file (export_cowpatty), put that single file on DVD and use it later on with attack_cowpatty…

The other new command is stripLive. As the name suggests, it works very similar to strip but is targeted more towards live capture sources. Kismet for example can create a fifo (a pseudo-file) that can be read by Pyrit. The packets captured from the air through Kismet are then fed directly into Pyrit which filters the relevant packets and immediately writes them to a new dump file. This turns Pyrit into a decent packet-sinkhole that only writes those few packets to disk that are really interesting.