Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WPS networks not displaying as WPS networks #8

Closed
NovaCygni opened this issue Sep 23, 2016 · 16 comments
Closed

WPS networks not displaying as WPS networks #8

NovaCygni opened this issue Sep 23, 2016 · 16 comments
Labels

Comments

@NovaCygni
Copy link

Im looking into the issue atm of the WPS networks not being detected as WPS thus, unable to be attacked when they should be able to, roughly know whats causing it so ill leave this bug-report open till ive submitted the code changes required to fix this issue (* will likely change the WPS method in 2 ways, 1) use Wash to confirm Lock status 2) allow a "IgnoreWPSNotDetected" toggle to attempt attacks on routers regardless of WPS status *)

@weedy
Copy link

weedy commented Nov 3, 2016

This is still broken in master, which basically kills a lot of the reason you would use this.

Please reopen this @NovaCygni

@NovaCygni NovaCygni reopened this Nov 4, 2016
@yuri-sevatz
Copy link

Possibly related (Pentoo, which uses wifite2 and reaver-wps-fork-t6x)

pentoo/pentoo-overlay#139

... Looks like reaver-wps-fork-t6x inverts the meaning of '-C' command in wash, hence nothing shows up as WPS-capable in wifite2 when using that version.

@yuri-sevatz
Copy link

@NovaCygni What version of reaver is Wifite2 meant to use?

@blshkv
Copy link

blshkv commented Dec 21, 2016

Removing my previous comment. reaver fork guys seems agreed to revert it:
t6x/reaver-wps-fork-t6x#106

P.S. Need to wait https://www.youtube.com/watch?v=vifwar7jxcQ

@NovaCygni
Copy link
Author

@yuri-sevatz It was supposed to use the t6x-github fork but derv appears to have gone awol on this project. If you want im planning on actually redoing the whole Wifite and the required Reaver as a StandAlone "Wifite3" in Python 3.5, so far willing contributors appears to be just myself but id love a extra hand working on it.
Wifite2 is currently broken thus:
Entire WPS code section missing, missing "Wash" status, redundant code methods, not auto down/up/monitor mode on all distros. No Error-Logic checking, faulty resuming from previous scans method.
Wifite original itself is flawed also, ie, it relies upon Reaver doing the Assositation with AP's this is known to be highly unstable on almost all Push-Button WPS enabled routers and will often results in false attack results that go up to 99.99% but never actually do anything. It also doesnt if a a previous attack on a AP is detected, offer the choice of resuming the old attack, resuming old attack with modified switches compared to before, or starting a new one.

@weedy
Copy link

weedy commented Dec 22, 2016

I'm highly interested in a new version that has a focus on error checking.
I've made some ugly edits to a couple versions of wifite on github, all of which made me wonder how it ever worked.

Is py3 out of familiarity?

@NovaCygni
Copy link
Author

@weedy Partially but also because itl allow Async to be used so when a error is thrown rather than Except to deal with it I can use "Await" to chain the fix for error thrown then continue on which would be alot more efficient as it means fewer dropped exchanges due to timeout... nothing worse than a couple M2 or M3 out of Sync that causes an entire false "Run Through".

Id love to check the "Ugly Edits" :p Always amazed me what little gems of genius people casually put in to solve x problem :)

@blshkv
Copy link

blshkv commented Jan 5, 2017

Please do not call wash with "-C" parameter. This is a default behaviour now and the flag has been removed (i.e. it will throw an error)

@derv82
Copy link
Owner

derv82 commented May 27, 2017

Also got this error. Removed the -C option in the commit above. Should resolve the issue.

@wifiuk
Copy link

wifiuk commented May 27, 2017

i was getting WPS networks displayed until the recent change, now i get none

@derv82
Copy link
Owner

derv82 commented May 27, 2017

@wifiuk

  1. What OS are you running? What version of wash is installed (wash 2>/dev/null | head -5)?
  2. Are you seeing n/a or no under the WPS column?
  3. Do any networks appear with the --wps option?
  4. Can you run with -vvv (very verbose mode) and paste the output of the wash command? Full output might be useful as well.

@wifiuk
Copy link

wifiuk commented May 27, 2017

wps is displaying fine with the new change

the change before it was displaying no under the wps column

wash 2>/dev/null | head -5
Wash v1.5.3 WiFi Protected Setup Scan Tool
Copyright (c) 2011, Tactical Network Solutions, Craig Heffner
mod by t6_xt6_x@hotmail.com, DataHead, Soxrok2212, Wiire, AAnarchYY & rofl0r

@derv82
Copy link
Owner

derv82 commented May 27, 2017

Ok cool. Closing this issue, but anyone can reopen if it's still a problem.

@derv82 derv82 closed this as completed May 27, 2017
@blshkv
Copy link

blshkv commented May 27, 2017

@derv82 users are getting lost between wifite(which is outdated and broken), wifite-fork (with non-technical and unfriendly developers) and wifite2. Can you take an initiative, port back any changes from the fork and release a one version which actually works?

@derv82
Copy link
Owner

derv82 commented May 28, 2017

@blshkv Are you asking for an update to the old wifite?

I'm choosing to ignore the old version of wifite indefinitely. It was one of my first Python scripts I wrote while learning programming, and it's 3.5K lines of ugly, untested, unmaintainable code.

I created #19 for tracking the backport of features from wifite forks into this repo (wifite2). Once this repo is "good enough" and has feature-parity, I will update the old Wifite repo to point users here.

Feel free to create a new issue for each feature you want Wifite2 to have.

@blshkv
Copy link

blshkv commented May 28, 2017

I'm asking to put a bit more afford into wifite2 with more active development (until "good enough" stage) which would overtake other forks. It shouldn't take 5 months for a simple patch like in this bug report.
Thanks for listening.

@ritiek ritiek mentioned this issue Jun 30, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants