seteve / reaver-wps

Automatically exported from code.google.com/p/reaver-wps
0 stars 0 forks source link

Keep found pin and real number of tries in database #164

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
After a successful run, the sqlite database keeps the found WPA key. The number 
of tried keys is set to 11000, probably because this field is used to keep 
track of where to continue when interrupted.

It would be nice if the database would also keep track of the correct PIN it 
found, and maybe also how many real tries it did until it found that PIN.

So I would suggest adding 2 fields to the history table: "pin" and "tries" 
(since "attempts" is used already):

CREATE TABLE history (bssid TEXT PRIMARY KEY NOT NULL, essid TEXT, timestamp 
TEXT DEFAULT CURRENT_TIMESTAMP, attempts INTEGER DEFAULT 0, key TEXT, pin 
INTEGER, tries INTEGER);

PS: Thanks a lot for sharing this great tool!!

Original issue reported on code.google.com by rduk...@gmail.com on 22 Jan 2012 at 3:06

GoogleCodeExporter commented 8 years ago
The history table is not used for tracking the state of the attack; the session 
files are used for that. So I guess this data could be added to the database, 
but it's a bit redundant since it's already in the session files and I'm not 
sure how much use it would be.

Original comment by cheff...@tacnetsol.com on 22 Jan 2012 at 7:35

GoogleCodeExporter commented 8 years ago
Maybe an explanation of the session files layout would be enough? But it would 
seem neater to have it right in the database.

The point is to find out how many access points use the same few simple PINs. I 
see in my scans that many are cracked after just a few tries. But now I don't 
know how many or which APs were in this case.

Original comment by rduk...@gmail.com on 22 Jan 2012 at 11:51

GoogleCodeExporter commented 8 years ago
Ah, I see said the blind man. :)  Keeping the pins in the database would be 
much easier for things like that. I'll add this in, although I can't promise 
when (quite busy ATM).

Original comment by cheff...@tacnetsol.com on 23 Jan 2012 at 12:24