/*
 * NetCrack 1.0 Readme - Salvatore Fresta
 *
 * Index:
 *
 * - About NetCrack
 * - Supported platforms
 * - The protocol
 * - Native supports
 * - Cluster features
 * - Cracking session's example
 *
*/


- About NetCrack


NetCrack is a cluster software developed to distribute an hashing algorithm's cracking process work using the brute force attack.

NetCrack works like a client/server application, where the server is unique for each cluster network and its job is to distribuites the cracking process work, coordinates the nodes and prevents connections and data integrity errors.

Using a TCP/IP based protocol to estabilish and manage the connection, NetCrack widens its domain to the entire web, avoiding complexity in terms of network implementation and cost, allowing any system to contribuite.

The protocol has been made simple and universal to facilitate future supports and to allow the coding of alternate client software using any programming language.


- Supported platforms


NetCrack has been tested successfully on 32 bit platforms only, in particular on Microsoft Windows XP, Microsoft Windows Vista, Max OSX 10.5 Leopard and GNU/Linux (Slackware and Debian distributions). All Unix-Like systems should be compatible.


- The protocol


The protocol developed to manage the client/server connection works on the ISO/OSI application level and it is based on TCP/IP protocol.

Information is transmitted using the string format, the unique platform's universal format. Using this last format, it is too easy to develop alternative client software that uses more features to make the system easier to use and to speed up the cracking process.

The protocol is made-up from a reduced packet set, whose purpose is simply to crack the information transmission and the session checks.

The following is the packet list used by the protocol with a little description for each packet:

* Packets for server use only

AG
Authentication Granted: says to the server that the authentication process is concluded successful.

AD
Authentication Denied: says to the server that the authentication process has failed.

CI base64_charset hash keylen-keyblock-hashid
Cracking information: contains the current cracking session's information. The first argument is the charset to use in the brute force process and it is transmitted in base64 to avoid that the space (0x20) character may be confused with the delimiters. The second argument is the message digest from which we want to recover the plaintext. The third argument is a unique information block. The first block section is the max password length to generate, the second block section is the keyblock value (see cluster features) and the third block section is the hashing algorithm to use to generate the message digest (hashid). If after sending three CI packets, the client doesn't respond, it will be disconnected.

DN
Data Null: this packet is sent to the current cracking session's first client and it tells the client to generate all password combinations from 1 up to the keyblock length.

DT key
Data: this packet contains the work segment to assign to a client.

PING
Ping: this packet allows the server to check the synchro of the client's connection.

BYE
Bye: this packet forces the client to disconnect.

PF
Password Found: tells the client that the password has been found by another host and it is possible to stop the current cracking process. This disconnects the client.

* Packets for client use only

AR password
Authentication Request: this packet sends the password for the authentication process.

IR
Information Received: tells the server that the CI packet has been received.

PONG
Pong: answers to the PING packet.

BYE
Bye: disconnection from server.

CF
Cracking Fail: tells the server that the brute force process has failed.

CS plaintext
Cracking Successful: tells the server that the brute force process has concluded successfully and attaches the plaintext found to the server.


- Native supports


NetCrack supports actually only the two most used hashing algorithms: MD5 and SHA-1. Implementing new algorithms is very simple, just assign a different hashid. For example, if the hashid 3 is free, it is possible to edit both the client and the server in order to assign it to the new hash algorithm.

MySQL: The server supports MySQL. In the attachment there is the required table to insert into the database. Unlike the version that does not support MySQL, in this version it is possible to choose the verbose mode. Furthermore the software will not exit at the end of the session but remains to listen for new data.

The following features are not supported by Microsoft Windows:

daemon mode: both client and server. This option allows you to execute the software in the backgroud.

safe mode: client only. This option allows to start the cracking process only after 1 minute of the system being idle.


- Cluster features


The cluster has been designed to avoid connection errors and data integrity errors. Because of this, the server has a priority list that contains the keys sent to the clients that haven't provided an outcome because of connection errors, for a misuse of the package BYE, for providing an incorrect plaintext, for not replying to PING packets or for sending too many PONG packets.

The priority lists content is analyzed continuously and it is essential for the brute force process to work correctly.

The distribution algorithm is very simple yet strong. The brute force process is made on max 5 characters (keyblock), while the key progress is made by the server. Thus, the client's CPU will perform a task on a max 5 bytes key length, dealing with, in the case of complex keys (alphanumeric and special charset), resources for up to 20 minutes.

The keyblock value is calculated on key length. If the key length is greater than 5, keyblock will be equal to 5, otherwise keyblock will be equal to the key length minus 1.

Example: with a charset as azAZ09 and a key length of 10, the server should send to a client a DT packet like the following:

DT aaaaah

The client will perform the task on the first 5 characters and will send the report to the server (CF or CS packet). In case of failure for all keys previously tested, the absolute last client will receive the following package:

DT aaaaa99999


- Cracking session's example


To distinguish the various clustering networks, the client willdo a simple password authentication process. As you may well understand, this isn't an authentication system designed to protect confidential information.

Client #1:           AR netcrack
Server to Client #1: AG
Server to Client #1: CI YXpBWjA5 6e6bc4e49dd477ebc98ef4046c067b5f 10-5-0
Client #2:           AR netcrackkk
Server to Client #2: AD
Client #3:           AR netcrack
Server to Client #3: AG
Server to Client #3: CI YXpBWjA5 6e6bc4e49dd477ebc98ef4046c067b5f 10-5-0
Client #1:           IR
Server to Client #1: DN
Client #3:           IR
Server to Client #3: DT aaaaaa
Server to Client #1: PING
Client #1:           PONG
Server to Client #3: PING
Client #3:           PONG
Client #3:           CF
Server to Client #3: DT aaaaab
Server to Client #1: PING
Client #1:           PONG
Client #1:           CS mom
Server to Client #1: BYE
Client #4:           AR netcrack
Server to Client #4: AG
Server to Client #4: CI YXpBWjA5 6e6bc4e49dd477ebc98ef4046c067b5f 10-5-0
Client #4:           IR
Server to Client #3: PING
Client #3:           PONG
Client #3:           CF
Server to Client #3: DN
Server to Client #4: DT aaaaac
Server to Client #4: PING
Client #4:           PONG
Client #3:           CS ciao
Server to Client #3: BYE
Server to Client #4: PF
Client #3:           BYE
Client #4:           BYE

In the previous cracking session it is possible to notice some features described previously such as the check of the CS packet's content and the priority list management. In order to notice that the client that has sent an incorrect plaintext (Client #1) was disconnected and its key was inserted into the priority list. When the Client #3 has finish the cracking process, it requests from the server a new key and this last one has been sent to it the DN packet, the key of Client #1. With Client #4, the server resumes the normal progress.
