WPS Pixie Dust Attack (Offline WPS Attack)

[soxrok2212]

Don't get discouraged, this is nothing new, and probably won't turn out to be anything sufficient but you miss 100% of the shots you don't take so I might as well try.

Tonight I was doing some research on the LRNG (Linux Random Number Generator) and I came across this interesting document http://eprint.iacr.org/2006/086.pdf

It highlights how the LRNG works in various systems, embedded systems, and directly (but briefly) targets OpenWRT. Mind you I don't have a degree in Computer Science, nor Computer Security bla bla bla, but according to this document, the ONLY source of entropy in kernel 2.6.10 (yes it is pretty old) is from network traffic. Apparently in this version, entropy was not carried across reboots, though I believe most current networking devices that run Linux do save it now, but let's not jump to conclusions yet. I haven't finished reading the whole document as it is very late but I figured I'd share to see what you maybe more, maybe less advanced people think.

Even if this practically exists across a small fraction of routers still in use today, it certainly seems to be something worth looking into. Let me know what you think!

[Quest]

not often I've witnessed a concept based upon vague and obscure notions actually materialize into workable software.

When I first posted I was both interested and skeptical. The skeptical part was proven wrong and quickly dissipated as it unbelievably, happened. This thread is where the actual, workable, revolutionary and delicious program was born, only because soxrok2212 understood then the potential and the mechanics of the Pixie attack well enough to gather the energies here to make it happen for us all. So many thanks guys! To Dominique Bongard for the original R&D, wiire for the actual software that we, common mortal use, DataHead, t6_x, aanarchyy, FrostyHacks, and soxrok2212 for the leadership, but most importantly, your Jedi skills.

Cheers!!

[soxrok2212]

Wasn't just me, primarily Datahead. He was my inspiration, he had all the concepts understood before I did (way before I did, in fact) and he really deserves the trophy on this one. Had it not been for him, I think I would've given up. No I am not just saying this to be nice, it was really Datahead all along, look at me as just the "messenger". Bongard provided the materials, Datahead provided the major concepts I was missing, FrostyHacks also helped me with some pieces I didn't have a grip on, aanarchyy is a bro and kept me inspired all along and provided some critical testing devices, and wiire made it all happen (publicly). But really, hats off to Datahead

[soxrok2212]

More speculation about attacking the Linux Random Number Generator... probably just me rambling because it's late, but why not post? Anyways, my understanding on this post comes from here: http://www.blackhat.com/presentation...-Gutterman.pdf

Now, not being an avid user of OpenWRT, I can't say how much of the research and discovery in this document is still true, but it can't hurt to try. Gutterman, the author of this document claims that both /dev/random and /dev/urandom draw from the same entropy pool. What is the difference between, /dev/random and /dev/urandom? Well, when entropy is low in the entropy pool, /dev/random blocks output until there is sufficient entropy while /dev/urandom will always output data (this is true of all devices using the Linux RNG). Now, if I tell you that Hostapd's WPS implementation uses /dev/random, what do you think? Ponder this a minute before reading the next sentence, see if your gears start ticking!

If we attack an arbitrary protocol that uses /dev/urandom, we can effectively drain the entropy pool without running the WPS protocol and risking lockouts/timeouts/etc. Before anything though, there are a few things that we have to consider, so don't get too excited (most of this is probably just me rambling).

-The WPA/WPA2 protocol: nonces are generated, and it wouldn't seem reasonable to use /dev/random because a device would not be able to join a network assuming a router was just installed, no entropy has been generated and a device wants to join. Could we attack this protocol to drain the entropy pool? Guess we'll have to find out!

-When will the LRNG/WPS protocol stop blocking? How much entropy is required to be able to use the entropy?

-What are sources of entropy in an embedded system such as a wireless router? LAN traffic? WAN traffic? Would WAN traffic make sense in a non-internet connected setup? What if temporary networks are set up and never have internet access? (Lan parties?) There are no hard drives, mice, keyboards or other peripherals in these types of embedded systems (yes a large amount of routers have USB ports, but it can't be assumed that all consumers actually use them).

-Do entropy pools save across reboots? While I don't know of a stone cold answer, t6_x leads me to believe in recent versions of Linux they do.

Update about an hour later: I just remembered that Bongard actually noted something on his slide presentation, low entropy across boot, making note of common states after reboot, though it's something he didn't really touch on. Maybe I'm actually onto something...

[mmusket33]

Ref dev/random and dev/urandom

Maybe you are answering a question MTeams has had for a long time. First we are seeing alot of WPS pin cracks at 12345670 or the default first pin. We have hacked thru the router userame and password and found the pin to be set to another pin

Maybe if dev/random does not have enough random data(you call it entropy) to produce a random number then the firmware just defaults the pin to 12345670 or in the case of dev/urandom the randomness due to lack sufficient data results in a default pin being produced. Hence heavy DDOS the router with processes like mdk3 a -Authentication Dos mode, may in some cases overload the firmware and the dev/random processes themselves fail. Hence it is not necessary to actually reset the router - just deplete it of the of the time to produce complete random numbers and certain operation can again be conducted.

You may have also answered the question as to why the VMR-MDK series works as when you flood the router with short bursts of mdk3 a WPS router sometimes gives up more pins even when locked.

We should look at tying up the router processes rather attempting a reset.

MTeams

[soxrok2212]

Ref dev/random and dev/urandom

Maybe you are answering a question MTeams has had for a long time. First we are seeing alot of WPS pin cracks at 12345670 or the default first pin. We have hacked thru the router userame and password and found the pin to be set to another pin

Maybe if dev/random does not have enough random data(you call it entropy) to produce a random number then the firmware just defaults the pin to 12345670 or in the case of dev/urandom the randomness due to lack sufficient data results in a default pin being produced. Hence heavy DDOS the router with processes like mdk3 a -Authentication Dos mode, may in some cases overload the firmware and the dev/random processes themselves fail. Hence it is not necessary to actually reset the router - just deplete it of the of the time to produce complete random numbers and certain operation can again be conducted.

You may have also answered the question as to why the VMR-MDK series works as when you flood the router with short bursts of mdk3 a WPS router sometimes gives up more pins even when locked.

We should look at tying up the router processes rather attempting a reset.

MTeams

Not sure about this theory but it sure is interesting. Entropy doesn't affect the pin, it affects the secure keys used to protect the pin. Are you able to send me a pixielog of an instance where pin 12345670 is used instead of the sticker pin?

[mmusket33]

To soxrok2212

We will begin checking all the router firmware setting for those routers we can access. We have been seeing the pin reset on occasion. Sometime during a reaver attack the router resets the pin to 12345670. As reaver checks this pin at the beginning of the attack, reaver then climbs to 99% and spins endlessly as it cannot find the pin. In such a case we would either add --pin=12345670 to the command line or simply restart a new reaver attack from start. Reaver would then crack the WPA code when it checked 12345670. It happened enough for use to write a retest pin 12345670 feature in VMR-MDK.

If you remember we previously mentioned to you that if you run mdk3 type alpha (ie type a DDOS) using the same wifi device ie mon0 or wlan0mon as used with reaver, reaver can extract pins thru the mdk3 fog. If you use a different device to run mdk3, then reaver cannot access the router.

In response to your publication of papers dealing with depleting dev/random processes we stopped all other projects and immediately began running tests with simultaneous reaver/mdk3 attacks against WPS locked routers and/or routers which did not respond to reaver even when they were open.

Even after 24 hours of tests we are seeing interesting results.

1. Some WPS locked routers gave up some pins

2. Open WPS enabled router which do not respond at all to reaver begin responding.

3. DDOS during a reaver attack seems to cause some routers to jump channels when just DDOS them alone did not cause channel switching. And such channel switching always resulted in more WPS pins collected in cases where the router was locked

We have only tested this on a few targets.

We suggest running reaver for say 180 seconds and mdk3 type alpha DDOS at the same time for 30 seconds. Thirty seconds after the reaver/mdk3 start, mdk3 terminates and reaver continues for 150 seconds and then restarts

As some WPS locked routers have been giving up pins slowly. We are trying to find a way to keep the pin collection going. We will write these routines into varmacscan??.sh which will automate the process and give us a wider target base for check and we will begin recoding VMR-MDK to allow a short mdk3 process at the start of the reaver attack

As a basic command line example

timeout 180 reaver -i mon0 -b 55:44:33:22:11:00 -vvv

timeout 30 mdk3 mon0 a -a 55:44:33:22:11:00

shutdown processes

spoof macs

restart

These processes need to be automated

MTeams

[sandyuk]

Congrats and well done on the great work. I know some of you guys have put in a great efforts for pixie and other projects. I have been a kali user for a few years now and a reader of the forums so hope you dont mind me asking a question.

I have successfully used the reaver on some listed vulnerable hardware giving me the E-Nonce, PKE, R-Nonce. PKR, AuthKey, E-Hash1, E-Hash2 then running pixie to give me the WPS PIN then the WPA KEY.

However there is one hardware ap that I reaver that gives me the E-Nonce, PKE, R-Nonce. PKR, AuthKey, E-Hash1, E-Hash2 but tells me WPS PIN not found. Im I correct in thinking that the fact that I get the E-Nonce, PKE, R-Nonce. PKR, AuthKey, E-Hash1, E-Hash2 that I have everything I need and the WPS PIN is to be found? Or is in not as simple as that?

I say this because some hardware you get nothing from no E-Nonce, PKE, R-Nonce. PKR nothing at all. But this hardware is feeding back something but reaver cant figure out the alithogram or whatever to get the WPS PIN.

I take it this hardware isn't vulnerable? and what it is spiting out is on no use at all?

Thanks in advance.

[soxrok2212]

The attack is based on the fact that some chipset vendors generate weak security keys to "encrypt" the pin. I don't even think encryption is the right word because it was a very pathetic attempt. Basically, some chipset manufacturers either made the encryption keys 0, or the made them predictable, they could be found from the nonce that was given to use plaintext. In your case, you are probably trying on an invulnerable chipset manufacturer that uses a secure method of generating keys.

[soxrok2212]

Also, for those of you having trouble with Reaver, try Bully! https://github.com/aanarchyy/bully
AAnarchYY recently modded it to support the pixie dust attack! Much faster and will compile on many more devices natively.

[Quest]

hey soxrok, will the new Bully and t6_x Reaver, have to be updated for the new Pixie 1.2.2 ? Or are they completely independent??

[soxrok2212]

They should work fine

[aanarchyy]

Bully works just fine ;-)

[Quest]

well... I knew the answer to that, AH! Was just checking if you guys were paying attention and what's your response time was. 2:15 is kinda slow.

*hides under the desk, pretend that I'm off line*

[soxrok2212]

Maybe someone here knows the answer to this, somewhere on the internets I came across a guy that claimed he found 2 vulnerable Broadcom devices.. anyone know what I'm talking about and have a link?

[Kaushalrocks]

How to install this new bully pixiewps on kali 2.0 ?
Plz send coding to install same and also how to use?
Is there any benefit over reaver or more vulnerabilty to other routers??
Please reply asap.

[Laserman75]

How to install this new bully pixiewps on kali 2.0 ?
Plz send coding to install same and also how to use?
Is there any benefit over reaver or more vulnerabilty to other routers??
Please reply asap.

wget https://github.com/aanarchyy/bully/archive/master.zip && unzip master.zip
cd '/root/bully-master/src'
make
sudo make install

[slmafiq]

why BULLY cant be installed?

*youtube*

[soxrok2212]

why BULLY cant be installed?

*removed*

apt-get install libpcap-dev

Edit: @Quest was that quick enough for you?

[Quest]

5 mins... Not bad not bad.

****

[kcdtv]

Is there any benefit over reaver

Without any doubt If you use a Ralink USB (RT3070, RT3072, RT3570, RT3572 ) as they works very bad with reaver
For the rest of chipset it is more or less the same, try and you wil see which you like more.

or more vulnerabilty to other routers??

Both uses pixiewps and will exploit exactly the sames vulnerabilities

[slmafiq]

soxrok2212 tnx for reply
but this is the result
ERROR
I use kali 2.

apt-get install libpcap-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
libpcap0.8-dev......

.................................................. ...........
Cd bully/src
Make
compilation terminated.
Makefile:19: recipe for target 'bully' failed
make: *** [bully] Error 1

[Quest]

download again > decompress in /root so you have a bully-master folder. Then

cd /root/bully-master/src
make
make install

[slmafiq]

download again > decompress in /root so you have a bully-master folder. Then

cd /root/bully-master/src
make
make install

I made it this way
wget https://github.com/aanarchyy/bully/archive/master.zip && unzip master.zip
cd '/root/bully-master/src'
make
sudo make install
But have error

[zimmaro]

I made it this way
wget https://github.com/aanarchyy/bully/archive/master.zip && unzip master.zip
cd '/root/bully-master/src'
make
sudo make install
But have error

what "type of error"??
post here!!
if this is "RELATED to dependancies" try first:

apt-get -y install build-essential libpcap-dev libssl-dev aircrack-ng pixiewps

after

cd '/root/bully-master/src'
make
sudo make install

[slmafiq]

Thanks zimmaro!
I installed bully successfully!

apt-get update
apt-get -y install build-essential
apt-get install libpcap-dev
apt-get install libssl-dev

[kcdtv]

Crazy thing...
I am testing a ZTE device (ZTE H218N) that is used byt the ISP jazztel (spain)
The device had PIN 12345670 enabled by default. A cople of years ago jaztel made un update to "disable" WPS
My guess is that they "unconfigured" the PIN or voluntary broke the protocol at some pòint.
The routers appears in wash....
Majority of time i get a continuous fail with our tools...

But at some point... i get an M1, send an M2 receive an m3 and pixiewps is launched
Look at that :

Incredible....
The PKE is exactly the same than for the realteck devices that are suported by pixiewps
and
E-HASH 1 = E-HASH2

The fact to see again this PKE is pure madness
This PKE repeated all the time was the starting point of the disovery of the breach for realteck....
And we see it again on broadcom chipset ...

And what about this unconceivable same value for Ehash1 and Ehash2?
It would mean that ES1 = ES2 and PSK1=PSK2....
ES1 and ES2 are not equal to 0 like for the ralink otherwise i would have get the results.
PSK1=PSK2 would be only possible if the PIN is 00000000
I tried to launch with 0000000 and didn't get nothing.

It is also strange to be able to send an m2 sometimes and that maybe something to dig for other purposes (check https://forums.kali.org/showthread.p...ight=reboot+ap)

This unsupported broadcom device with PIN mode broken has a very strange behavior....

the chipset is according to the wiki devi :

SoC Ram Flash Network USB Serial JTag
Broadcom BCM5357 64MiB 16MiB 5 GbE Yes 2x v2.0 ? ?

[soxrok2212]

If you supply PIN 12345670 does it still recover the PSK? I think we briefly discussed this a LOOOOOONG time ago in a chat... The only reason I can think of off the top of my head is that the PIN is not configured and the router is just sending random data... but then again the static PKe is too... provoking to ignore. Do you have any more ZTE H218N's you can test this on?

UPDATE: I wonder if the network is using another device to as the enrollee. Perhaps something like this is going on? Or try deauthing all the clients and see if you get the same result.

[wiire]

The new pixiewps when modes are not specified uses the Pke to try to determine the target. This means it's trying only for Realtek. You should trying manually specifying all the modes --mode 1,2,3,4,5.

Also in case of Ralink devices with push button active, the 2 hashes are identical because of pin and secret hashes equal to 0.

In the beacon frame there could be the chipset vendor. It's under 'Tag vendor specific'.

UPDATE: seems aanarchyy 's Bully doesn't run with --force. The nonce generated seems to be compatible with a Realtek device. I recommend again to test it manually and check in the beacon frame if the vendor information is present.

[kcdtv]

Hi soxrok2212, Hi wiire

first of all it seems that the "wikidevi" is wrong or they may be several version of the device... The point is that the chipset appears to be a realteck one instead of a BCM:

thanks for the trick wiire : i always looked in the WPS tags and didn't noticed that information could be gathered there.
That would explain the presence of our "provocative PKE" in the M' messages.
It doesn't explain why pixiewps didn't launched a long bruteforce (i tried with --force or mode 3 --force / and i tryed every mode separatly)
This case is definitely less weird/interesting than what i thought first as i thought it was a broadcom device.
i managed to repeat once this "fake" pixie dust and i got the realtek PKE (as expected) and two identical ehash again. (like the first time, not the same ehash than the first time but the same ehash1 and ehash2 )
i get a strange error if i put the stdout here (with our without code-quote)... If somebody wants it ask me by PM and i will PM it to you. (or you can get it form here : https://www.wifi-libre.com/topic-335...ado.html#p1776)

If you supply PIN 12345670 does it still recover the PSK?

Never ever since the firmware update (around 2014)
Just from time to time you would get enough for a pixiedust... nothing else (never get a M5 or more)

discussed this a LOOOOOONG time ago in a chat... The only reason I can think of off the top of my head is that the PIN is not configured and the router is just sending random data

Yes indeed.
By seeing this realteck PKE in what was supposed to be braadcom router i got emotionalized and thought that this datas may lead to something to discover another weakness in some unsupported broadcom.
But this ZTE router definitely have a realteck chipset...
Thanks for your "lights" about this.

[wiire]

That's what I suspected. It's Realtek without a doubt.

What do you mean pixiewps didn't launched the full bruteforce? I'm pretty confident it found the seed but couldn't recover the pin if it stopped right away.

Try compiling with 'make debug' and see if at some point it says 'Seed found' or something similar.

The two hashes should be identical only in case of the PBC pin as you pointed out (in case es1 and es2 are the same as well).

When testing the program I did test it against PBC so I'm sure it works properly.

[kcdtv]

that's what i get in stdout with adding --force -v 3

 Pixiewps 1.2

 [-] WPS pin not found!
[*] Time taken: 1 s 908 ms

pixiewps seems to work properly as it is suggested to use "force" when i don't use it :

 Pixiewps 1.2

 [-] WPS pin not found!
[*] Time taken: 1 s 903 ms

 [!] The AP /might be/ vulnerable. Try again with --force or with another (newer) set of data.

It doesn't explicitly stdout that seed is found so i am gonna install in debug mode...
see you in 5 minutes...

... You are absolutely right
I didn't doubt it but I just wanted to see the debug mode in action... And I will leave it in debug mode, i prefer like this
- edit : well , I won't because that would break the compatibility in automatized pixie dust mode with reaver 1.5.2 or bully revisited by aanarchyy. I precise this in case people would compile in debug mode

It is not as interisting as i thought first but it still useful to know : As every manufascturer do what they want with PROBES and there is not a way to distinguish beetwen routers with WPS PIN correctly enabled and the others... well, this seems to be the way!
If our ehash-1 and ehash2 are equals in our M3 message it means that only PBC is fully enabled and that PIN mode will not lead to anything.
I don't have broadcom device or atheros device to check it out but at least that is the case for realtek and ralink.
That's pretty cool, we still learned something somehow

[aanarchyy]

@kcdtv debug mode works just fine with bully, i had pixie with debug mode on for quite a while, just extra printing,

oh and i added --force to the pixiepws command, i wasn't aware that was still in as wiire had removed it from the
help.
also added the ESSID and BSSID to the final output per request of soxrok2212

[wiire]

If our ehash-1 and ehash2 are equals in our M3 message it means that only PBC is fully enabled and that PIN mode will not lead to anything.

Just to clarify, the PBC method is - protocol-wise - identical to the PIN method. The only difference is the method of activation (a button) and that the PIN is already known, being '00000000'.

I successfully recovered the WPA of my router after pressing the button, using Reaver and Pixiewps some time ago.

If you want you can pass me the data and I can try to to experiment a bit. But maybe the two equal hashes are part of the 'patching work' of the devs. We know for sure Realtek devices are weird.

[kcdtv]

Just to clarify, the PBC method is - protocol-wise - identical to the PIN method. The only difference is the method of activation (a button) and that the PIN is already known, being '00000000'.

ok

If you want you can pass me the data and I can try to to experiment a bit. But maybe the two equal hashes are part of the 'patching work' of the devs. We know for sure Realtek devices are weird.

And it is a .... ZTE ... low coast and low security.... with above all a touch from jazztel for who it took more than one year to understand that all their device had PIN 12345670 enabled.
So weirdness is expected...
here are the datas : http://www78.zippyshare.com/v/y3wuTRzz/file.html
if you need something more, just ask

also added the ESSID and BSSID to the final output per request of soxrok2212

The same guy that requested a tool for pixiedust one day ... i think i remember now... be carefull with him, you never know where it can stop!

[soxrok2212]

Glad to see it's all sorted out!

[eddie]

hi to all
I'm studying on WiFi vulnerabilities and specially on WPS. I found this article on the web

Can it be a new attack or not?! it claims that:

even by completely disabling the WPS on the routers, all vulnerabilities are not covered

[Laserman75]

hi to all
I'm studying on WiFi vulnerabilities and specially on WPS. I found this article on the web

Can it be a new attack or not?! it claims that:

In the article, nothing is described new

[eddie]

In the article, nothing is described new

Really?? .So the name should be "repetitive attacks on WPS!!".....
i think first scenario is not possible ... But about second, is there any tools for performing that scenario in kali?

Where can I find documents for original source of this attacks??

[soxrok2212]

"But if the attacker could somehow change his role in this exchange and could be the enrollee, he can use two arbitrary values instead of E-Hash1 and E- Hash2 and sends it as M3 message."

First off, the author doesn't sound very informed on the topic in general. A little "somehow" magic and it should work, right? Unfortunately, that's not how the protocol works. Reminds me of the "Blackjack Attack" that was quickly deemed unsuccessful, http://méric.fr/blog/blackjack.html though they are using a rouge AP. I don't think it is possible.

As for the second attack, well, I don't really understand what they are trying to say. It is written in pretty poor English, though I can't point them out on this because it's just a language barrier.

The author should have done practical analysis of the suggested ideas instead of documenting theoretical analysis. Would've made much more interesting document if they found proof for any of the suggested ideas.

[wiire]

The fake AP attack to get the first half of the pin is nothing new. The procedure is described in the specification (2.02) as well in Bogard's slides. The problem with it is that usually one is never prompted to insert a WPS pin when trying to connect to a WPS AP.

The "second attack" is more interesting. Instead of setting up a fake AP with the Pin method, set up one with the PBC method (same name, same encryption) with a greater power level in attempt to cover the legitimate AP and disconnect the client (same procedure of an evil twin). Then when the user tries to connect, make the fake AP start a PBC session. The Windows victim computer should automatically starts a PBC WPS session, grab the new configuration and eventually automatically connect to the fake AP.

Now the attacker could potentially set up dns spoofing, sslstrip, redirection etc.

I honestly never tried, but this would be a flaw in Windows security rather than WPS.

[eddie]

@soxrok2212

thanks .I read that hypothetical "Blackjack" attack, but it's difference.I think theoretically first attack has no problem, but as @wiire said, practically it's not possible.

@wiire

thanks. Really helped me. I want to implement second attack to try it. Do you think this is worth trying?

[carshiv]

i tried cracking dlink router's pin with --force option but pin was not found . Means the router is in-vulnerable ? (Pixie version 1.2 , kali 2.0)

[kcdtv]

About this second "PBC" attack (4.2) "evil twin"
It is one of the "PBC Rogue attack" described by koala some time ago and It doesn't work as "smoothly" as they affirm.
Because windows offer the possibility of a PBC connection only the first time when you connect to an AP, just when you create a new profile.
So you have to create a fake AP where the essid is slightly changed otherwise windows will never activate the PBC connexion : It has to be a new profile.
Than it works, as it is a different name-AP, windows propose you to press the PBC on the router side and you could get the client connected to your fake AP
That's how it would look like from the victim side :

As you can see the legitimate profile Livebox-XXXX appears with a red cross ( effects of mdk3 + airebase used for desauth ) and the fake network reachable is livebox-XXXX (lower case instead of lower)
If the victim clic on "livebox (fake)" than it would be connected

So it is not as simple and straight as they described and and depends on the user active intervention to fall in the trap.
Complete and documented tutorial here : [Tuto] Rogue AP discrète en full WPA avec hostapd
It is in french, sorry, but you have snapshots with kali linux every two lines and code blocks, so you will follow the story.

[eddie]

Because windows offer the possibility of a PBC connection only the first time when you connect to an AP, just when you create a new profile.

Not agree! I think whenever PBC support announced in beacons, windows offers the possibility of PBC connection. I tried it at home with my router.
Also there is no need to create fake AP with slightly changed ESSID, it's possible to have two access point(or more maybe!) with same ESSID and same encryption.

[soxrok2212]

Also in the event of using a Rouge AP, the best option would just be to redirect to a fake page requesting the WPA key, not the WPS pin. Both of the author's ideas are pretty useless to me, if a router supports WPS then 99.99% of the time it is running WPA2-CCMP and it would just be easier to grab the PSK and then from there just grab the WPS pin from the router config.

[eddie]

I think poor English in that article makes this misunderstanding. The goal in both idea is not requesting WPS pin instead of WPA key! I think wiire is completely right.

[kcdtv]

I think whenever PBC support announced in beacons, windows offers the possibility of PBC connection. I tried it at home with my router.

Maybe you use windows 8.1? Anyway i doubt that it changes anaything.
Koala did his tests with windows 7 and i did the test with windows 10
PBC connexion is just proposed for the first time you connect to the network.
Once you have a profile created windows just try the PMK and will not propose again PBC.
Even if you push the button on the router side...
I connect through PBC to a router that i sue for the test, once i am successfully connected I changed the WPA passphrase (simulating a fake AP with same bssid and essid) and i try to connect to my AP again
Windows network manager stop to try after a certain time and that it.
That's all you get... No PBC is proposed (as the profile is already created)

I think wiire is completely right.

No one said he is not
Both ideas are not news... the authors of the paper present them as new vulnerabilities and it has been demonstrated that it is not the case.

[eddie]

Maybe you use windows 8.1? Anyway i doubt that it changes anaything.
Koala did his tests with windows 7 and i did the test with windows 10
PBC connexion is just proposed for the first time you connect to the network.
Once you have a profile created windows just try the PMK and will not propose again PBC.
Even if you push the button on the router side...
I connect through PBC to a router that i sue for the test, once i am successfully connected I changed the WPA passphrase (simulating a fake AP with same bssid and essid) and i try to connect to my AP again
Windows network manager stop to try after a certain time and that it.
That's all you get... No PBC is proposed (as the profile is already created)

I found my mistake! you are completely right as well

Both ideas are not news... the authors of the paper present them as new vulnerabilities and it has been demonstrated that it is not the case.

exactly! So is there any tool for test this attack using kali or other linux OS?

I have another question : How can I get routers firmware source code?

[soxrok2212]

exactly! So is there any tool for test this attack using kali or other linux OS?

Either way, both are not vulnerabilities in WPS, I would just consider it a workaround. No there are no designated tools for this, though I'm assuming hostapd and some magic could make it work.

I have another question : How can I get routers firmware source code?

Either google the model number followed by "source code" or you could try extracting the compiled firmware with binwalk and look at the binaries.