Follow by Email

Blog Archive

Search This Blog

Advanced use of pyrit

Pyrit database structure. Import and export passwords Let's take a closer look at the components of the Pyrit database. First, it is passwords. The same passwords can be used when hacking different Access Points. Two commands are used to import passwords:
Share it:
The basic use of Pyrit, as well as the most efficient algorithm for implementing an attack, is described in the section “ Breaking a Handshake in Pyrit - the fastest way using graphics processors and preliminary calculation of hashes ”. It is recommended to start reading from it.

The above algorithm for using Pyrit is the most popular. However, Pyrit has many more commands and options.


    Pyrit database structure. Import and export passwords

    Let's take a closer look at the components of the Pyrit database. First, it is passwords. The same passwords can be used when hacking different Access Points. Two commands are used to import passwords:
    • import_passwords
    • import_unique_passwords
    It is the same for these commands that passwords can contain all characters (including NULL-bytes) except the terminating newline characters ("\ n"). Passwords that are not suitable for use with WPA- / WPA2-PSK are ignored. Those. cleaning the password file that we performed was not necessary.

    The difference between these teams is that:
    • The import_passwords command controls the uniqueness of the passwords to be imported, and the import_unique_passwords command does not, it imports all passwords, even those that already exist in the database.
    • The import_unique_passwords command is much faster.
    The names of the commands make you think that there is an error in the documentation. Because import_unique_passwords is more suitable for importing unique passwords. But there is no error.

    Import speed with import_unique_passwords exceeds import speed with import_passwords at times. Therefore, if you have a giant dictionary, the size of which is measured in gigabytes, then you can save a lot of time only on importing passwords. Of course, if you are confident in its "purity" (no duplicate data).

    By the way, passwords can be saved from a database to a file, this is done by the export_passwords command . Example of use:
    pyrit -o myword.txt.gz export_passwords
    As already mentioned, passwords can be used many times. And Pyrit itself monitors the purity of the password database. But importing passwords takes as much time as calculating hashes. Each TD hash has its own TD, since the TD name is the salt in these hashes.

    We created our access point table with the create_essid command . Some commands independently create the necessary table in case it is necessary, but has not yet been created. You can also create many ESSIDs. To do this, after the -i option, you need to specify a file in which there is a list of ESSIDs (each AP on a new line). Re-creating an existing ESSID will not result in an error.

    Pyrit attack implementations

    To calculate the hashes, we used the batch command , and for the subsequent attack (checking on hashes) we used the attack_db command . The following options are possible:

    • attack_batch - if passwords are translated into hashes, then these hashes are used, if there are passwords that are not “counted” in hashes, they are calculated and a check is performed on all these hashes (attack). In fact, attack_batch = batch + attack_db at a time. Supports options -b ,  -e and -o .
    • attack_cowpatty - not only Pyrit can generate Pairwise Master Keys from passwords, for example, genpmk can also do this . If we use a database of hashes that are generated in the cowpatty format , then we use this command.
    • attack_db - conducts an attack on previously calculated (using batch ) hashes. Supports options -b-e and -o .
    • attack_passthrough - this command bypasses the Pyrit database and should be used only if there are problems with storage space (for example, on the LiveCD). Use attack_batch instead . Supports options -b-e and -o .
    • batch - Runs the translation of all passwords in the database to their respective Pairwise Master Keys (paired master keys) and saves the results to the database. You can use the -e option  to limit the use of this command to only one ESSID; if this option is omitted, all ESSIDs will be processed one by one in an undefined order.
    • passthrough - Reads passwords from the file given with  -i  and calculates them as the pairwise master keys for the ESSID given with  -e . The results are written to the file that is specified after  -o  in the cowpatty binary format and are not saved in the database for future use. Those. This command bypasses the need to have a database and should only be used if there are problems with storage space (for example, when using Pyrit on a LiveCD). The batch command provides exactly the same functionality as  passthrough , but can provide much improved performance, since the results can be read from the database instead of recalculating them. If you still do not understand, then passthrough is like batch , only received hashes are not saved to the database, but output to standard output.
     Example of practical use: pre>pyrit -i dirty_words.txt.gz -e NETGEAR -o - passthrough | cowpatty -d --r wpatestcapture.cap -s NETGEAR

    Distributed and remote use of resources with Pyrit

    Pyrit can act as a server and as a client. With a certain skill, you can organize a distributed calculation of hashes.
    relay
    Starts the server to relay another storage device via XML-RPC; another Pyrit client can use this server as storage. This allows it to have network access to its own (like file: // and sqlite: //) or SQL databases hidden behind a firewall and provides multiple client access to the database via Pyrit RPC interface. TCP port 17934 must be open for this feature to work. For example, on the server (where is the database):
    pyrit -u sqlite://var/local/pyrit.db relay
    and client (where is the big GPU):
    pyrit -u http://192.168.0.100:17934 batch
    -u URL
    To connect using the option  -u the URL . It allows you to specify the URL of the device storage in the form:
    driver: // username: password @ host: port / database
    Pyrit can use the file system, the remote Pyrit-Relay-Server and, if the python-sqlalchemy package is installed, a SQL database as storage. The file: // driver sends to its own Pyrit file system, which is located on the disk, http: // links to the Pyrit-Relay-Server and all other URLs go directly to python-sqlalchemy, if available. Device URLs by default can also be specified by the defaultstorage key in the pyrit configuration file (for details, see the help and see the FILES section  ).
    serve
    Launches a server that provides access to local computing equipment to assist Pyrit clients. The server's IP address must be added to the clients configuration file , as a space-separated list in known_clients . The rpc_server-setting setting for clients should also be 'true' . TCP and UDP ports 17935 must be available. For example, on the server (where there is a GPU):
    pyrit serve
    and on clients (the server’s IP address was added to known_clients and rpc_server is set to 'true' ):
    pyrit -r test.pcap -b 00:de:ad:be:ef:00 -i words.txt attack_passthrough

    Handshake Search with Pyrit

    To identify handshakes, there are three commands:
    analyze  - parses one or more files with captured packets (in pcap format, it is possible to work with compressed gzip files) transferred with the -r option   and try to determine the Access Point, Station and EAPOL handsets. Example:
    Handshake Search with Pyrit

    root@Kalitut:~/# pyrit -r DANIELLE2015-01.cap analyze
    Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
    This code is distributed under the GNU General Public License v3+
     
    Parsing file 'DANIELLE2015-01.cap' (1/1)...
    Parsed 35 packets (35 802.11-packets), got 3 AP(s)
     
    #1: AccessPoint 68:72:51:40:78:b5 ('@Office N.Y TMN WiFi 038-249734'):
    #2: AccessPoint 0c:54:a5:c0:24:d6 ('DANIELLE2015'):
      #1: Station e0:99:71:fa:d3:c9
      #2: Station 4c:8d:79:9c:06:54
      #3: Station 00:1f:3a:41:5e:70, 9 handshake(s):
        #1: HMAC_SHA1_AES, good, spread 1
        #2: HMAC_SHA1_AES, good, spread 1
        #3: HMAC_SHA1_AES, good, spread 1
        #4: HMAC_SHA1_AES, good, spread 3
        #5: HMAC_SHA1_AES, good, spread 3
        #6: HMAC_SHA1_AES, good, spread 3
        #7: HMAC_SHA1_AES, good, spread 3
        #8: HMAC_SHA1_AES, good, spread 7
        #9: HMAC_SHA1_AES, good, spread 7
      #4: Station 74:e2:f5:ba:bc:bc
    #3: AccessPoint 20:25:64:16:58:8c ('Mial'):
    strip - Parsing one or more captured packet files sent with the -r option  , extracts only the packets that are needed to detect the EAPOL handshake and writes a new dump to the file passed with the -o option  . You can use the -e and -b options to filter specific Access Points. Example:
    pyrit -r "large_dumps_*.pcap" -e MyNetwork -o tiny_compressed_dump_MyNetwork.dump.gz strip
    stripLive - Parsing a file with captured packets that are passed with the -r option , extracts only the packets that are needed to detect an EAPOL handshake and writes a new dump to the file passed by the -o option . This command differs from strip in that the captured file can be a character device, including sockets and other pseudo-files that look like pcap files. stripLive writes the relevant packets to a new file ( provided by the -o option ) as they stay instead of trying to read the entire capture file first.
    Share it:

    Penetration Testing Tools

    Post A Comment:

    0 comments: