Hi hulley.
Thanks for the test. Maybe I should not drop wlandump-ng, but implement all new features from hcxdumptool in there.
So that we have at least 2 different versions (a raw version and a libpcap version).
That will take a little bit time, as we are working on some other projects (wpa-sec and RADIUS inclusive detection of more authentication variants).
Is the hcxpcaptool (converter) working for you?
(02-13-2018, 11:14 AM)ZerBea Wrote: [ -> ]Hi hulley.
Thanks for the test. Maybe I should not drop wlandump-ng, but implement all new features from hcxdumptool in there.
So that we have at least 2 different versions (a raw version and a libpcap version).
That will take a little bit time, as we are working on some other projects (wpa-sec and RADIUS inclusive detection of more authentication variants).
Is the hcxpcaptool (converter) working for you?
---------------
Hi ZerBea.
Yes that's sound like a good idea. It would also allow not so perfect chips/devices to work in passive like mode. I also tested a known problem child with hcxdumptool, the Alfa RTL8188RU driver:rtl8192cu !!! It did manage to get a few hundred packets each time (varied), but wlandump-ng usable with it, wlandump-ng options that work fine -d,-U,-B,-c,-t, options that fails in seconds, minutes (varied) -R and -D. so keeping wlandump-ng is a good idea, but more work.
hi ZerBea
I'm sorry but (think) I tried everything in the last week using OSX and k.a.li rolling as guest and ALFA awus036h
active-passive and mobile from wlandump-ng
first: the passive mode disconnects to all and myself!
I reconnect several times but my key (and almost all) does not appear in testlist_sorted
can be that hc does not recognize the exported hash?
What mystery is there in all this?
second: the plainmasterkeys does not respond to hc 2501
I see than all possibles and probables numerical and alphanumerical passwords are missing in the .txt
I don't know what I can do
thanks for your help.
regards
https://forum.hashkiller.co.uk/topic-vie...465#155465
Hi diegodieguex.
I sent you a mail. Maybe something in your installation is broken. I did a quick run on your caps:
There are many, many clear passwords in the captured files (but only some of them matches to the captured handshakes).
It's a good idea to collect them for later use, or test them on older cap files.
There are also many, many ap-less handshakes inside and the quality is very good.
Session..........: hashcat
Status...........: Exhausted
Hash.Type........: WPA/WPA2
Hash.Target......: test.hccapx
Time.Started.....: Wed Feb 21 23:49:56 2018 (8 secs)
Time.Estimated...: Wed Feb 21 23:50:04 2018 (0 secs)
Guess.Base.......: File (testwordlist)
Guess.Queue......: 1/1 (100.00%)
Speed.Dev.#1.....: 356.5 kH/s (0.44ms) @ Accel:32 Loops:16 Thr:1024 Vec:1
Recovered........: 52/261 (19.92%) Digests, 21/76 (27.63%) Salts
Progress.........: 3459444/3459444 (100.00%)
Rejected.........: 0/3459444 (0.00%)
Restore.Point....: 45519/45519 (100.00%)
Candidates.#1....: -> ١٢٣٤٥٦٧٨٩
HWMon.Dev.#1.....: Temp: 57c Fan: 39% Util: 93% Core:1898MHz Mem:5005MHz Bus:16
Cheers
Some words about the "Wireless regulatory database for CRDA":
If your device doesn't work, like you expected (not all channels / high not power available), take a look into the wireless regulatory database (crda must be installed):
https://git.kernel.org/pub/scm/linux/ker...xt?id=HEAD
choose a country with less restrictions:
country VE: DFS-FCC
(2402 - 2482 @ 40), (30)
(5170 - 5250 @ 80), (23), AUTO-BW
(5250 - 5330 @ 80), (23), DFS, AUTO-BW
(5735 - 5835 @ 80), (30)
and set it (as super user) on your machine:
$ iw reg set VE
to make it permanent edit (as super user) the config file:
$ nano /etc/conf.d/wireless-regdom
and uncomment this line:
#WIRELESS_REGDOM="VE"
If that doesn't work, the device is firmware coded (like my TL-WN722N). In that case you must patch the firmware to get full access to all channels.
Mostly all(!) issues (hashcat - OpenCL, hcxtools - interfaces) are related to a misconfigured host system (inclusive missing access rights) or driver incompatibility.
I wrote this, because I fell into this trap, like a beginner, due to a kernel upgrade.
I just want to say that: Check your environment after an update/upgrade!
thank you I'll keep trying
Getting kinda confusing haha
The same applies to me...
But joking aside:
More and more vendors activate MAC randomizing. In theory, this makes it difficult to track the device by seeing which networks have spotted its MAC address.
The bad thing is, that we can not prevent attacks against randomized MAC's anymore as now packetfilters become useless....
hi ZerBea,
I saw that hcxdumptool is not there anymore?
and wlandump-ng don't allow put my AP in the blacklist
there is something else that we can take advantage of all these beautiful tools? congrats!
regards from EZE
Hi diegodieguex.
I splitted the repository:
https://github.com/ZerBea/hcxtools (see changelog)
https://github.com/ZerBea/hcxkeys (the OpenCL stuff)
https://github.com/ZerBea/hcxdumptool (see changelog)
and
https://github.com/ZerBea/hcxdumptool_bleeding_testing (this will be the successor of hcxdumptool)
At this time we are playing around with some endian stuff for OpenWRT.
No beautifull status, but full functionality of a passive dumper (MGMT, EAPOL, EAP, IPv4 and IPv6)
and two active parts (we simulate a client transmitting active probes to broadcast, and we simulate an AP transmitting broadcast beacons). There are some compiler warnings, because not all functions are added, yet (just ignore them).
Technical:
- dropped timer (both)
- only one raw socket
- use threads (Raspberry Pi LED flash and channelswitch)
- improved scan engine
- simulating a client and an AP
- using SIOCGSTAMP in combination with FD-ZERO and FD_SET to answer time-dependent
- optimized internal ringbuffer
- and more...
So, if you have some feature requests, improvements, the issue tracker of hcxdumptool_bleeding_testing is open.
Also, testers are welcome.