Thanks for the report.
First MTeams wishes to point out that you are using varmacscan exactly as it was designed to be used. Varmacscan usually gets the pin and sometimes gets the WPA key. Getting the WPA key may take a bit of effort from the command line.
MTeams is currently rewritting this program.
It will provide several methods of making virtual monitors thru airmon-ng and iw and a mixture of both.
It will brute force the WPS pin then try any pins found and then try default pins such as 12345670 and 00000000 in sequence.We have begun finding routers with the all zero default key which is something new for us.
Several AP activation routines will be added. Aireplay-ng will be made regenerative thru while true loops.
With respect to bully MTeams has made several attempts to integrate bully into these robotic processes but in our areas bully just doesnot function well against the routers found. We therefore cannot test and if we cannot test against real targets we cannot confirm any of the subroutines embedded in the script are actually functioning. However we will again test with Annarchyys version.
We have found that reaver when run thru Kali 2.0 and latter, many times does not get the WPA key even when run from the commandline. We immediately switch to kali1.10 and the WPA key is obtained. There is commentary in Top-Hat-Sec see http://forum.top-hat-sec.com/index.php?topic=5647.0 There are comments about airmon-ng disruptions and using iw instead. We are exploring this issue hence the reason for alternative virtual monitor setups in coming releases.
For us this program has obtained more WPA keys then all other methods combined. This is only because of the robotic nature of the script. MTeams runs constant scans 24 hours a day when the computer is idle then try to obtain the WPA key thru the commandline. We will try bully thru the command line again as you suggested.
I have been testing your "varmacscan" but after updating to "Kali Linux 2016.2" the tools seems to have problem start the "wlan0" in the monitor mode (tried both ways). I have even tried to write a small shell file to overcome this but the problem still persists. It would be better if you add the following to avoid the hardblocked case or "SIOCSIFFLAGS: Operation not possible due to RF-kill". So that the program while creating the "Monitor Mode" doesnt have problem with it.
And can you say the command you use in the file with reaver and also aireplay-ng?
rmmod -f <Wifi Driver Name> #Removing the Driver
rfkill unblock all #Unblocking all device
modprobe <Wifi Driver Name> #Installing the driver module.
MTeams currently has two(2) computers running varmacscan in hard drive installs of i386 kali-linux 2016R2. These computers have been updated but not upgraded and have been running constantly for over two months with no difficulties.
All we can say with the info you provided is to make sure you choose the right program type when asked ie kali 1.10a, 2 and rolling and let the program install the monitors. A common error is to try and write the monitor designation when prompted rather then just selecting the line number next to the device.
The SIOCSIFFLAGS due to RF kill might be caused because you are running kali linux on a laptop which is dual booted with windows or requires windows to turn on the wifi device. If this is the case boot into windows get your internal wifi device functioning then reboot into linux. This would also apply to usb install both live and persistent. Note the computer writing this answer had this problem last month.
All we ask at present is to go thru the setup carefully. If the problem persists write back and give us more info but it is hard to correct if we cannot duplicate. We will also put our RV group on it if this answer does not help you,
You can read the command lines for reaver and aireplay-ng. Just open the file with leafpad and type ctrl - F reaver or aireplay-ng and you will find the various command lines embedded in xterm.
THX for this nice code.
How can i create a whitelist for varmacscan-K1-2-2016-3-3.sh? Only a simple text file list of BSSIDs in /root/VARMAC_WHITELST? Like this:
Same for whitelist handshakeharvest-K1-K2-K2016-4-0?
Networks are whitelisted by writing a text file and naming the file with the mac code of the network then a dash and the word whitelist. This text file must be placed in the VARMAC_WHITELIST folder. Contents of the file are unimportant. The program looks for file names not contents
File name example
The program gives you the option to whitelist Networks during setup and writes the file for you. BUT if you wish to manually whitelist networks prior to running the script then open leafpad enter the mac code of the network in the file as text if you wish then name the file with the mac code then a dash then the word whitelist.
And again for program looks for maccodes of file names not for file contents and each network has its' own file.
It was done this way to protect data. Each time a network is cracked the data is written to a separate file. Those networks are then automatically whitelisted and a text file written to the VARMAC_WHITELIST folder. Manually whitelisted networks have the name whitelist after the maccode and dash. Networks that have had their WPA key cracked have the word WPA_key-FOUND- then the essid.
MTeams decided for data safety each network cracked would have its data written to a individual file in root rather then put all data collected placed in one file. We have seen programs where the user spends hours trying to obtain data and then when found the data iis placed in the /tmp folder.
Last edited by mmusket33; 2017-01-10 at 08:41 AM.