I'm surprised no-one has commented on this.
I'll give it a go and report back on results etc.
Keep up the good work guys.
Musket Teams have voted to release an updated handshakeharvest for community use as of 6 July 2016. Program supports kali 1.10a 2.0 and 2016R.
This script incorporates the additions as provided by MajorTom in this thread. And without his/her input this newer version would not have been written. For MTeams the use of handshakeharvest definitively ends the need to sit in front of computers attempting to collect handshakes. The robotic script easily obtained many .cap files containiing handshakes with little effort from the user.
The program has been tested in Kali 1.10a, 2.0 and 2016R. The slowest computer was used running a persistent usb install of kali2016. All versions were tested using an external AWUSO36H wifi device attached to a 5 meter extension cable to insure the mac changing routines had time to function. All versions ran for 24 hours with no interruption.
MTeams does not support kali-light, luks encryption or ARM.
You can download here thru kali or at:
This script is a completely robotic WPA Handshake collector.
Supports a general deauth of all WPA networks found.
Supports specific deauth of clients found associated to target network
Features added at community request.
The ability of error handling during program setup to be turned on or off.
After program setup a scan of all WPA encrypted networks within reception range is conducted and a list of targets made.
Program then enters active deauth phase.
Each target in list is attacked in turn as follows.
Airodump-ng is then started to collect a handshake on channel and bssid of target.
Using aireplay-ng -0 two general deauths are directed at target
If no handshake obtained
Program searches for associated clients
If clients found program attempts to deauth three clients associated to the network. Program selects the top three clients measured by activity and sends two deauth pulses at each network-client pair.
After all targets found in the list have been attacked the program enters a passive phase collecting data.
When passive phase has time expired, program re-scans the area and restarts the active phase.
If a handshake has been collected program ignores that network in any further scans.
Program supports the collection of essidprobes and constructs dictionaries for use in brute forcing a WPA handshake.
Program is time and activity driven. Time of passive scan and activity such as deauth count for aireplay-ng is setup by the user.
MTeams attempted to upload to github and was unable therefore you can download at:
Last edited by mmusket33; 2016-07-06 at 01:41 AM.
I'm surprised no-one has commented on this.
I'll give it a go and report back on results etc.
Keep up the good work guys.
OK as promised a little bit of feedback.
I have 2 laptops with Kali 2.0 installed (fresh installs), up to now I've been using Kali 1.10a.
I don't konw if it's a problem with Kali 2.0 or aircrack version that comes wit it but:-
The first run of the script is fine, however when my usb wlan0 is stopped after the first passive scan, on the script restarting it cannot be found and looking into iwconfig it's been renamed to wlan2, therefore subsequent runs fail.
I reinstalled 1.10a into one of the laptops and it ran perfectly with the exception of selection of the number of cycles to run.
On first run I selected 2 cycles and left it while I was busy on my main PC. On return the number of cycles remaining was -4. It had carried on into minus figures!
When running on Kali 2 it created both the HANDSHAKEHOLD and the PROBEESSID_DATA folders but in kali 1.10a only the PROBEESSID_DATA folder. HANDSHAKEHOLD folder had to be created manually.
I'm willing to carry on testing and if you want screen caps providing just tell me what you want.
Can't get my head around wlan0 being renamed though, any thoughts on that?
Thanks for your input.
Reference the essidprobe problem we are aware of this bug between kali1.1 ans 2.0. We are currently rewritting our ESSIDPROBEWPA2. The program is being tested. Once we release this we will turn and correct the code in handshakeharvest.
We will retest handshakeharvest under kali2.0 again but we have not experienced the dropping of wlan0. We have had reports that this occurred because the user entered the device rather then the line number of the device.
As for the negative number we will run some tests and correct that.
We will run the program under k2 for 24 hours again and see what occurs
handshakeharvest-K1-K2-K2016-3-8.sh has been released for community use as of 17 Jun 2016.
See top of this thread for program overview and download details.
Thanks for sharing.
It's good you made the confirmations optional
But call them just what they are - confirmations, not error handling
I run Kali 16.1 Light and noticed a few issues.
1. Only small fraction of WPA enabled APs in the range are selected for collection. You should probably rewrite that part to parse airodump scan output.
2. For some APs airodump and aireplay wouldn't start and the screen capture then looks like this:
This seems to happen to the same APs on every cycle.Code:[+] current SSID : XXXX [+] current BSSID : Load: [+] current Device Mac : 00:13:0C:2B:F5:E9 [+] Channel : 9 [+] Total WPA Handshakes Collected = 7 [+] See /root/HANDSHAKEHOLD for .cap files [+] Opening airodump-ng to collect handshake. [+] Sending first deauth burst at target network Load:. [+] Waiting for any handshake exchange to be completed and processed. [+] Checking .cap file for presence of handshake from first deauth burst. open failed: No such file or directory [+] No Handshake FOUND for XXXX [+] Sending second deauth burst at target network Load:. [+] Waiting for any handshake exchange to be completed and processed. [+] Checking .cap file for presence of handshake from first deauth burst. open failed: No such file or directory [+] No Handshake FOUND for XXXX [+] [+] ************Standby************ [+] Looking for associated clients. [+] wpaclean: open(): No such file or directory [+] [+] Starting test looking for cap files for YYYY. [+] Checking /root/HANDSHAKEHOLD for Load:.cap files.
BTW why FOUND is capitalized when no handshake is found?
Also note that it says "from first deauth" both times.
3. Even when airodump shows client stations, files in VARMAC_AIRCRACK are empty or not created at all. Script also always says that no clients were found.
We ran tests with -i386 both hard drive and persistent usb installs of kali 1.1, 2 and 2016 without seeing your issues.
Four different computers were used.
The wifi devices were AWUS036H - Four different usb devices.
We collected approx 20 handshakes in one overnight session.
MTeams does not support kali 16.1 light or any luks encrypted operating systems.
For example wpaclean looks to be not installed in light. There may be other programs like awk and sed which do not exist.
The confirmations actually do two things. They allow you to reconfirm what you typed is correct and they check to insure what you entered falls into what variables are expected hence are not in error.
We will correct the first and second deauth burst text output - Thanks
MTeams added a check and ran the program in a Live install of kali 2016R.
The number of Networks found by the iw scan equaled what airodump-ng found.
Handshakes were immediately collected. We could not duplicate your major issues.
If you run into bugs with the full version let us know and we will try and duplicate.
Thanks for taking the time to test.
Last edited by mmusket33; 2016-06-19 at 03:31 AM.
I've tried the script in official WMVare image of Kali 16.1 (on a desktop PC with the same Alpha NHA card) with very similar but marginally better results. Script usually (meaning not always) picks up client stations correctly and "BSSID : Load:" became "BSSID : LoAD:"
If you run
the very last line of the output will be
Do NOT screenscrape this tool, we don't consider its output stable.
You should have listened
If you examine this extract from output of my iw scan you will see both where that "Load:" comes from and why script doesn't pick up all WPA stations
Both stations have WPA, but there's no WPA section in the output, only RSN, so none is picked up by the script and as can be seen sections RSN, BSS Load and HT Operation can appear in any order. And it seems that unlike WPA, RSN section is present for every WPA AP. When present, WPA section has the same content as RSN section.Code:BSS xx:xx:xx:xx:xx:xx(on wlan0) TSF: 97430810122 usec (1d, 03:03:50) freq: 2412 beacon interval: 100 TUs capability: ESS Privacy SpectrumMgmt ShortSlotTime RadioMeasure (0x1511) signal: -65.00 dBm last seen: 3408 ms ago Information elements from Probe Response frame: SSID: SSIDNAME1 Supported rates: 1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 DS Parameter set: channel 1 Country: SG Environment: Indoor/Outdoor Channels [1 - 13] @ 36 dBm Power constraint: 0 dB TPC report: TX power: 19 dBm ERP: Barker_Preamble_Mode Extended supported rates: 6.0 9.0 12.0 48.0 RSN: * Version: 1 * Group cipher: CCMP * Pairwise ciphers: CCMP * Authentication suites: PSK * Capabilities: 16-PTKSA-RC 1-GTKSA-RC (0x000c) BSS Load: * station count: 3 * channel utilisation: 61/255 * available admission capacity: 0 [*32us] HT capabilities: Capabilities: 0x8bc HT20 SM Power Save disabled RX Greenfield RX HT20 SGI TX STBC No RX STBC Max AMSDU length: 7935 bytes No DSSS/CCK HT40 Maximum RX AMPDU length 65535 bytes (exponent: 0x003) Minimum RX AMPDU time spacing: 8 usec (0x06) HT RX MCS rate indexes supported: 0-15 HT TX MCS rate indexes are undefined HT operation: * primary channel: 1 * secondary channel offset: no secondary * STA channel width: 20 MHz * RIFS: 1 * HT protection: no * non-GF present: 1 * OBSS non-GF present: 0 * dual beacon: 0 * dual CTS protection: 0 * STBC beacon: 0 * L-SIG TXOP Prot: 0 * PCO active: 0 * PCO phase: 0 Extended capabilities: Extended Channel Switching, BSS Transition WPS: * Version: 1.0 * Wi-Fi Protected Setup State: 2 (Configured) * Response Type: 3 (AP) * UUID: 0cc0d50d-2f54-6e7f-64f6-8a26d0b61c67 * Manufacturer: Broadcom * Model: Broadcom * Model Number: 123456 * Serial Number: 1234 * Primary Device Type: 6-0050f204-1 * Device name: BroadcomAP * Config methods: Label, Display * RF Bands: 0x1 * Unknown TLV (0x1049, 6 bytes): 00 37 2a 00 01 20 WMM: * Parameter version 1 * u-APSD * BE: CW 15-1023, AIFSN 3 * BK: CW 15-1023, AIFSN 7 * VI: CW 7-15, AIFSN 2, TXOP 3008 usec * VO: CW 3-7, AIFSN 2, TXOP 1504 usec BSS yy:yy:yy:yy:yy:yy(on wlan0) TSF: 18880511011335 usec (218d, 12:35:11) freq: 2427 beacon interval: 100 TUs capability: ESS Privacy ShortSlotTime APSD (0x0c11) signal: -58.00 dBm last seen: 1496 ms ago Information elements from Probe Response frame: SSID: SSIDNAME2 Supported rates: 1.0* 2.0* 5.5* 11.0* 9.0 18.0 36.0 54.0 DS Parameter set: channel 4 ERP: Barker_Preamble_Mode Extended supported rates: 6.0 12.0 24.0 48.0 HT capabilities: Capabilities: 0x11ee HT20/HT40 SM Power Save disabled RX HT20 SGI RX HT40 SGI TX STBC RX STBC 1-stream Max AMSDU length: 3839 bytes DSSS/CCK HT40 Maximum RX AMPDU length 65535 bytes (exponent: 0x003) Minimum RX AMPDU time spacing: 4 usec (0x05) HT RX MCS rate indexes supported: 0-15, 32 HT TX MCS rate indexes are undefined HT operation: * primary channel: 4 * secondary channel offset: above * STA channel width: any * RIFS: 0 * HT protection: no * non-GF present: 0 * OBSS non-GF present: 0 * dual beacon: 0 * dual CTS protection: 0 * STBC beacon: 0 * L-SIG TXOP Prot: 0 * PCO active: 0 * PCO phase: 0 RSN: * Version: 1 * Group cipher: CCMP * Pairwise ciphers: CCMP * Authentication suites: PSK * Capabilities: 1-PTKSA-RC 1-GTKSA-RC (0x0000) WMM: * Parameter version 1 * u-APSD * BE: CW 15-1023, AIFSN 3 * BK: CW 15-1023, AIFSN 7 * VI: CW 7-15, AIFSN 2, TXOP 3008 usec * VO: CW 3-7, AIFSN 2, TXOP 1504 usec BSS Load: * station count: 0 * channel utilisation: 32/255 * available admission capacity: 31250 [*32us] Overlapping BSS scan params: * passive dwell: 20 TUs * active dwell: 10 TUs * channel width trigger scan interval: 300 s * scan passive total per channel: 200 TUs * scan active total per channel: 20 TUs * BSS width channel transition delay factor: 5 * OBSS Scan Activity Threshold: 0.25 % Extended capabilities: HT Information Exchange Supported Country: SG Environment: Indoor/Outdoor Channels [1 - 13] @ 16 dBm WPS: * Version: 1.0 * Wi-Fi Protected Setup State: 2 (Configured) * Response Type: 3 (AP) * UUID: bc329e00-1dd8-11b2-8601-e03f499684c0 * Manufacturer: ASUSTeK Computer Inc. * Model: WPS Router * Model Number: DSL-N55U * Serial Number: 00000000 * Primary Device Type: 6-0050f204-1 * Device name: ASUS WPS Router * Config methods: Label, Display, PBC * RF Bands: 0x1
I suppose that output of airodump scan would be not only much more stable but also easier to parse, because it's a "square" csv.
Noticed a small bug - if AP name contains a space then .cap file in HANDSHAKEHOLD folder will only contain part of the name before the space.
Also seems like script is not able to handle presence of hidden SSIDs correctly - may start mixing SSIDs and BSSIDs from different APs.
Last edited by MajorTom; 2016-06-20 at 11:16 AM.
Your comment on BSS is interesting. We will try and get some captures that have BSS and no WPA on them. Keep in mind that we can only code for our areas of operation as everything we release is tested in the field and we are not seeing this. Coding csv in aerodump-ng is tricky but we will look into it. It is even less consistent over the three operating systems. As for hidden ssid that was handled early on in code construction as only bssids are used for the scan. You will probably find a REM statement in the script concerning this. The space problem was considered but as it only is used in file names after the bssid it was not considered significant as everything is based on the bssid.
Again thanks for the input
Last edited by mmusket33; 2016-06-20 at 03:18 PM.
If you don't see RSNs in you captures then I suppose it's about card's chipset/driver rather than area of operation. If you want I can send you my capture, but I see no option to PM you. If you can PM me, then I may be able to reply.