[+] Trying pin 02835679
[+] Sending EAPOL START request
[+] Received identity request
[+] Sending identity response
[+] Received M1 message
[+] Sending M2 message
[+] Received M3 message
[+] Sending M4 message
[+] Received WSC NACK
===================
正常情況下在M4后,會(huì)收到WSC NACK包。這是就知道當(dāng)前的0283是錯(cuò)誤的。然后開始試下一個(gè)pin.
缺省情況下,如果在M4后沒有收到任何包,等待超時(shí)后,也會(huì)認(rèn)為當(dāng)前的pin是錯(cuò)誤的,然后開始試下一個(gè)pin.
如果是因?yàn)閬G包的原因,沒有收到M5包,顯然正確的pin就會(huì)當(dāng)作錯(cuò)誤的pin.因此就會(huì)出現(xiàn)99.99%的問題。
解決辦法很簡(jiǎn)單:
加上 -n 參數(shù)即可。
reaver -vvnS -d 0 -b xxxx
注意:reaver 會(huì)為每個(gè)AP創(chuàng)建一個(gè)pin序列文件,這個(gè)文件存放在
/etc/reaver/ 或 /usr/local/etc/reaver,
文件名字是"AP的MAC".wpc, 例如:AP的MAC是:FF:FF:FF:FF:FF:FF,那么文件名是
FFFFFFFFFFFF.wpc
這個(gè)文件也記錄,Reaver已經(jīng)檢測(cè)到了哪個(gè)pin值。例如已經(jīng)檢測(cè)到了99985767,這個(gè)值在pin序列
中的位置會(huì)被記錄到文件中,這樣就可以中途停掉reaver.下次開始時(shí),還是從99985767開始。
因此在重新啟動(dòng)reaver之前要先刪除這個(gè)pin序列文件。
高級(jí)用法:
注意如果是90.00%那么前四位是沒有跑出來的.直接刪除文件即可。
如果是99.99%,pin的前四位已經(jīng)找到了。在刪除.wpc文件之前,用reaver 加上-vv參數(shù),記下前四位
的值。然后再刪除.wpc文件。重新開始pin時(shí),使用-pin 設(shè)置上面記下的前四位pin.這樣就直接開始找
后四位的pin值了。
根據(jù)reaver的幫助,reaver缺省情況下會(huì)自動(dòng)檢查AP是否回應(yīng)NACK.因此不需要加-n參數(shù)才對(duì)。
我看了一下代碼,這確實(shí)是一個(gè)bug. 但是通過加-n參數(shù),可以繞過這個(gè)bug.
PS:有時(shí)候可能還會(huì)漏碼 產(chǎn)生死循環(huán)情況
這個(gè)時(shí)候把-S參數(shù)去掉 加入延遲 -d 3 -t 3 -n這個(gè)參數(shù)一定要加,切記。