dcrack
Differences
This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
dcrack [2018/04/19 02:22] – created mister_x | dcrack [2018/04/20 23:35] (current) – [Client worker] Request indicatig failure mister_x | ||
---|---|---|---|
Line 16: | Line 16: | ||
==== Server set-up ==== | ==== Server set-up ==== | ||
- | Not much power or RAM is required for this system as it mostly receive commands from the user. However, it needs to have TCP port 1337 open | + | Not much power or RAM is required for this system as it mostly receive commands from the user and communicates with clients. |
- | to communicate with the user and the cracking servers. | + | |
./dcrack.py server | ./dcrack.py server | ||
- | Firewall rules are recommended to limit access to the server between the user(s) and the server and between the server and the cracking client(s). | + | It will listen on port 1337 (TCP). |
==== Client set-up ==== | ==== Client set-up ==== | ||
- | This system needs raw power to be able to crack fast. RAM is not that much important. It needs to be able to reach the server. | + | This system needs raw power to be able to crack fast. RAM is irrelevant. It needs to be able to reach the server |
- | Multiple systems will likely have different cracking speeds and the server adapts the workload | + | |
- | (in this case, wordlists) to have all the systems finish at approximately the same time. | + | |
./dcrack.py client < | ./dcrack.py client < | ||
- | It will calculate its cracking speed and report it back to the server along with a client ID. | + | Different systems |
+ | (in this case, wordlists) to have all the systems finish at approximately the same time. | ||
+ | |||
+ | The client will first calculate its cracking speed and report it back to the server along with a client ID. | ||
==== Cracking a capture file ==== | ==== Cracking a capture file ==== | ||
Line 61: | Line 62: | ||
Protocol used is HTTP. There isn't any authentication or encryption for now and thus it is recommended to only use it in a trusted network and use firewall rules to prevent unauthorized access. | Protocol used is HTTP. There isn't any authentication or encryption for now and thus it is recommended to only use it in a trusted network and use firewall rules to prevent unauthorized access. | ||
- | Once initiated, the client will do a benchmark to get the average speed and report back to the server along with a client ID. It will then poll the server for cracking jobs every 60 seconds. Once it receives one, it will gather | + | ==== Server ==== |
+ | |||
+ | Server is mostly passive and responding to requests from clients (cracking servers) and commands from users. | ||
+ | |||
+ | ==== Client worker ==== | ||
+ | |||
+ | All requests from a worker start with **/ | ||
+ | |||
+ | Once initiated, the client will do a benchmark to get the average speed and report back to the server along with a client ID. In the following example, **14501464051314047435** is the client ID and it has an average speed of **3682**: | ||
+ | |||
+ | GET / | ||
+ | |||
+ | The server will respond 200 OK. | ||
+ | |||
+ | It will then poll the server for cracking jobs every 60 seconds | ||
+ | |||
+ | GET / | ||
+ | |||
+ | |||
+ | The server will respond 200 OK and the JSON response may contain a few different possible answers: | ||
+ | * Keep waiting | ||
+ | * A job | ||
+ | |||
+ | === Keep waiting === | ||
+ | |||
+ | It contains the interval to wait in seconds for the next query. It looks like the following: | ||
+ | |||
+ | {" | ||
+ | |||
+ | === Job === | ||
+ | |||
+ | The following JSON response adds **00: | ||
+ | |||
+ | {" | ||
+ | |||
+ | Once receiving this request, the client will request the wordlist referenced by this hash as well as the PCAP capture file and start cracking. Once finished, it will send a request to the server with the results | ||
+ | |||
+ | == Obtaining the wordlist == | ||
+ | |||
+ | The following request will be sent and the server will send the GZIP-compressed file for **1a15d1f10377829ead1fee8299f83f14d539f1e1**: | ||
+ | |||
+ | GET / | ||
+ | |||
+ | == Obtaining the capture file == | ||
+ | |||
+ | The client will request the capture file referencing its BSSID. In this case **00: | ||
+ | |||
+ | GET / | ||
+ | |||
+ | The server will send the GZIPed-compressed file. | ||
+ | |||
+ | == Sending results to server == | ||
+ | |||
+ | In the following request, the client send the result of processing the BSSID **00: | ||
+ | |||
+ | GET / | ||
+ | |||
+ | When the key isn't found, the following request will be sent indicating that passphrase for BSSID **00: | ||
+ | |||
+ | GET / | ||
+ | ==== User ==== | ||
+ | |||
+ | All requests from a user start with **/ | ||
+ | |||
+ | === Upload capture file === | ||
+ | |||
+ | Capture file is cleaned up with // | ||
+ | |||
+ | POST / | ||
+ | |||
+ | The content of the POST request is the compressed capture file. Once successful, the server will respond 200 OK and " | ||
+ | |||
+ | === Uploading a wordlist === | ||
+ | |||
+ | Wordlist is cleaned up, compressed in gzip and hashed. This part is done offline. Following that, it checks if the server already has the wordlist. If not, then it uploads it. | ||
+ | |||
+ | == Check for wordlist existence == | ||
+ | |||
+ | Using the following request, it checks if the server already has the wordlist based on its SHA1 hashsum: | ||
+ | |||
+ | GET / | ||
+ | |||
+ | If the server doesn' | ||
+ | |||
+ | == Wordlist upload == | ||
+ | |||
+ | Using a POST request, the wordlist is then uploaded: | ||
+ | |||
+ | POST / | ||
+ | |||
+ | The server will respond OK if received correctly. | ||
+ | |||
+ | == Setting the dictionary == | ||
+ | |||
+ | In any case, it will tell the server to use a specific wordlist based on its hashsum using a request similar to this one: | ||
+ | |||
+ | GET / | ||
+ | |||
+ | The server will respond " | ||
+ | |||
+ | === Start a job === | ||
+ | |||
+ | In the following request, the user requests to start processing BSSID ****: | ||
+ | |||
+ | GET / | ||
+ | |||
+ | Server will respond with " | ||
+ | |||
+ | === Get job status === | ||
+ | |||
+ | Status of the job can be obtained by sending the following request: | ||
+ | |||
+ | GET / | ||
+ | |||
+ | The server' | ||
+ | |||
+ | { | ||
+ | " | ||
+ | 3682 | ||
+ | ], | ||
+ | " | ||
+ | { | ||
+ | " | ||
+ | " | ||
+ | } | ||
+ | ] | ||
+ | } | ||
+ | |||
+ | === Remove BSSID === | ||
+ | |||
+ | In the following request, the user asks to remove the BSSID **00: | ||
+ | |||
+ | GET / | ||
+ | The server will respond " | ||
===== Tips ===== | ===== Tips ===== | ||
- | * In an untrusted network, use a SSH tunnel or any other protocol allowing authentication and eavesdropping. | + | * In an untrusted network, use a SSH tunnel or any other protocol allowing authentication and prevents |
* If the capture file contains multiple handshakes, the best one will be selected. However, manual selection is strongly recommended in that case. Check out our [[wpa_capture|WPA Capture analysis]] tutorial. Make sure to include at least one beacon in the capture file. If the network is hidden, an association frame is required too. | * If the capture file contains multiple handshakes, the best one will be selected. However, manual selection is strongly recommended in that case. Check out our [[wpa_capture|WPA Capture analysis]] tutorial. Make sure to include at least one beacon in the capture file. If the network is hidden, an association frame is required too. |
dcrack.1524097322.txt.gz · Last modified: 2018/04/19 02:22 by mister_x