Notices

All I get is the help screen, it does not do anything

Yup, just as meShell said, but since tony requested it...

wow very nice! would like to try it but at the moment i have to little time / am to lazy to set up the environment for compiling - is it possible anyone upload the compiled reaver binary?
thanks in advance

EDIT: ...just saw that it's now part of Cleven
http://talk.maemo.org/showpost.php?p...&postcount=327 AWESOME!

today, I've tested it with 10+ WPS-compliant AP in work, and the results were quite interesting.

It seems, that WPS-compliant device can mean virtually anything. First router was accepting *every* pin as correct, so reaver reported WPS pin cracked after 2-5 seconds, every time, no matter of PIN tested. Of course, it wasn't giving any WPA passphrase (unfortunately or fortunately, depending on point of view ). when I tried to connect to this AP "godly way", it wasn't using any pre-defined PIN - N900 dialog was asking me to use on-AP button. I was able to choose "PIN method", but that was even more ridiculous - instead of asking me to input PIN on N900, it actually *gave* me PIN via N900 dialog, and requested to input this PIN to AP. every attempt resulted in different PIN created.

So, this Access Point was protected against this attack vector, but, according to WPS standard, it wasn't compliant with *any* obligatory method of establishing WPS connection...

Another router - some kind of damn Livebox - after 4-5 pin attempts just locked further WPS connecting. Using any delay (instead of default 315) haven't helped. Interesting thing is that, when I checked it after 10 hours, it was still in WPS locked state I wonder, if it's going to allow WPS tommorow - maybe, after lockout, it require restart to work properly? That would mean Reaver is performing WPS DoS on this model, as during lockup, no client is able to connect via WPS.

Few other machines were working with Reaver "normally". Yet, the time between effective PIN attempts wasn't particularly awesome - Reaver measured it as average of 27 seconds per PIN. Despite having strong signal, I was getting "response timeouts" many times. This require further investigation, as some times, I was able to check 7 PIN per 10 seconds, and for other situations, same router allowed 1 PIN per minute.

Finally, one router 'seemed' to work, but wasn't responding to PIN attempts at all - Reaver just tried one and only PIN whole testing period. I though it's related to MAC filtering, so I used allowed MAC for 2nd attempt, but results were same. by the way, I also tried allowed MAC for first router (this one that was giving PIN, instead of requesting one), also with no new results.

The bright side, is that it isn't power demanding. Using N900 with 800 mAh (out of 3070 mAh total), I was expecting quick need for charge. Instead, after ~8h, I was still @ ~500 mAh. Power usage resembled regular one with WiFi connected to AP, staying idle (GSM was disabled totally during tests).

Overall, on router working best, 8h30min resulted in 1.45% of 11000 PIN's checked. Far from 'promised' 10-13H to 50%, but it probably depends highly on AP - I haven't noticed anything, that could indicate problems with fast PIN checking on N900 or Reaver side. Probably, never routers, that most strictly follow WPS standards, are - ironically - more prone to quick WPS cracking.

/Estel

// Edit

During actively trying to crack one AP, N900 reported 7-13% of processor usage @ 500mhz - including Conky itself, and of course, other N900 processes. So, Reaver itself was using about 3-9% @ 500 mhz. It never resulted in on-demand jump to higher frequency.

Estel,

What options exactly did you use?
Did you try the --eap-terminate? I noticed that for my friend's router that dropped connection after a few tries it helped.

Yea, I've tried -E (same as --eap-terminate, according to reaver --help) on every router. in case of models I was dealing with, it wasn't making any difference.

Every router was also tested with -S and -a (independently and together) - I haven't noticed any improvement. Same goes for -w option (though, that for some routers mimic'ing win7 behavior may help against dropping connection\).

So, generally, I've tried them in all possible combination. Of course it doesn't mean -E is useless - as You have noted, it works on some APs. I'm pretty sure, that implementation of WPS in existing routers is one big of a mess. WPScrack developer state, that 95% of newly produced router have WPS enabled by default - I hope, that it's more standardized in new batches (routers I've tested wasn't models from last month or two).

/Estel

// Edit

Saturn, while testing it on your friends router, what amount of average second per pin attempt reaver reported (it reports total% and average seconds once a few minutes)?

Yes it does showed up =) Anyway tried a bit older router(sitecom 300N) I had lying around, and it worked fantastically, didn't finish the job. But output gave me the impression it worked like it should.Probably that particular router wasn't "hackable". This confirms Estels experience with different routers.

I think I succesfully compiled my first software of my life.

-vv is for verbose
did you use "-i mon0" or "-i wlan0"?

The rate varied and I could test for almost 6 hours while also finding out stuff. We have rebooted the router maybe 30 times! (that's why I've put the warning)

In a rebooted router it could be 10-15 seconds per attempt going up to 60-70 seconds/attempt after some time. It eventually locked and if you left it running it would eventually reconnect.

By creating some symlinks (they are included in cleven-experimental) I was able to store and recover the session and continue from were it is left.
We will try to leave it running over several nights and see if it will manage to find the pass-phrase. In that way his wife will not be that upset with us

In any case, a few bugs have been reported and in future reaver is expected to have less errors - the wait and retry delays are not working properly.

I tried walsh but it keeps showing the help menu even I loaded moniter mode and injection mode on wlan0 then I tested with

walsh -i wlan0
walsh -interface wlan0
walsh -i wlan0 -c 6
walsh -i mon0 ---- created mon0 using airmon-ng
and
walsh -f mycapfile.cap ---- mycapfile is already have cap file

Of course I was using -vv.. Also, I was enabling monitor mode via fAircrack (just for convenience), so only -i wlan0 was present, and I used it.

I wonder why router You've tested was becoming slower and slower during test. Proper way of "blocking" too many pin attempts would be Rate lock, which reaver detects properly and use longer wait time (315 by default) - that happened with Livebox I've tested (and it's still locked, lol. Just as a curiosity, I'm going to leave it as is and check if it's ever going to unlock without reset).

response timeout are - at least AFAIUI - more likely due to router inability to cope with so many PIN attempts/associations etc. I think that 'Your' router logs/cache/whatever PIN attempts, and slowly, it's (not so high) internal memory become stuffed after some time, to the point of DoS. Of course it's purely an assumption, but I don't see any other reason, why it should become slower and slower, then deny next PIN request and normal working for already connected clients altogether.

On the other hand, some Linksys routers with 16 MB and 32 MB of RAM, seem like "un-Dos-able'' - either they're not logging WPS attempts, or their RAM/NVRAM is big enough to cope with that.

/Estel