]]>pull_requesthttps://github.com/aircrack-ng/aircrack-ng/pull/2030
https://github.com/aircrack-ng/aircrack-ng/pull/2030Mon, 18 Mar 2019 00:28:02 +0000issuehttps://github.com/aircrack-ng/aircrack-ng/pull/2030
https://github.com/aircrack-ng/aircrack-ng/pull/2030Mon, 18 Mar 2019 00:28:00 +0000In save_network(), open_pcap() is called for each detected network
in the input capture files. open_pcap() truncates the existing
file, and starts from zero with each network it finds.
So only call open_pcap() on the first network/handshake it detects,
so that subsequtent handshakes are added to the output capture file.]]>issuehttps://github.com/aircrack-ng/aircrack-ng/issues/2033
https://github.com/aircrack-ng/aircrack-ng/issues/2033Mon, 18 Mar 2019 00:08:27 +0000I have not encountered any errors.
Did everything according to the instructions https://github.com/aircrack-ng/aircrack-ng/tree/master/scripts/airdrop-ng

System information

Aircrack-ng version

Version: 1.5.3

Commit Revision hash: eccf8cc5

Defect

How to reproduce the issue

FYI: all my byte counts are WITHOUT newlines. So as I mention I'm using "echo -n" to ensure I'm not picking up newlines.

Running aircrack-ng with a PMKID with a 4-character ESSID gives the error "Input is too short !". This PMKID works just fine in hashcat itself. The short nature of the ESSID seems to be what is triggering this based on the format laid out in:

An SSID has no minimum length. 0 indicates a probe. So for a non-probe, I would assume the minimum is 1-byte. So then the minimum length for the PMKID check would be 61 bytes ? (I'm testing this with echo -n and wc -c). The only variable length that I see in the PMKID format is the ESSID. So then the range would be 61 - 123 bytes (ascii)?

Also I suppose we have to be really clear as the string itself is ascii, but it represents the raw data (i.e. hex values for ASCII characters for the ESSID). Hopefully that makes sense and I'm not needlessly confusing things.

If you want some of the PMKIDs let me know and also how to get them privately to you.

System information

Aircrack-ng version

Version: 1.5.3

Commit Revision hash: eccf8cc5

Defect

How to reproduce the issue

FYI: all my byte counts are WITHOUT newlines. So as I mention I'm using "echo -n" to ensure I'm not picking up newlines.

Running aircrack-ng with a PMKID with a 4-character ESSID gives the error "Input is too short !". This PMKID works just fine in hashcat itself. The short nature of the ESSID seems to be what is triggering this based on the format laid out in:

An SSID has no minimum length. 0 indicates a probe. So for a non-probe, I would assume the minimum is 1-byte. So then the minimum length for the PMKID check would be 61 bytes ? (I'm testing this with echo -n and wc -c). The only variable length that I see in the PMKID format is the ESSID. So then the range would be 61 - 123 bytes (ascii)?

Also I suppose we have to be really clear as the string itself is ascii, but it represents the raw data (i.e. hex values for ASCII characters for the ESSID). Hopefully that makes sense and I'm not needlessly confusing things.

If you want some of the PMKIDs let me know and also how to get them privately to you.

System information

Aircrack-ng version

Version: 1.5.3

Commit Revision hash: eccf8cc5

Defect

How to reproduce the issue

FYI: all my byte counts are WITHOUT newlines. So as I mention I'm using "echo -n" to ensure I'm not picking up newlines.

Running aircrack-ng with a PMKID with a 4-character ESSID gives the error "Input is too short !". This PMKID works just fine in hashcat itself. The short nature of the ESSID seems to be what is triggering this based on the format laid out in:

An SSID has no minimum length. 0 indicates a probe. So for a non-probe, I would assume the minimum is 1-byte. So then the minimum length for the PMKID check would be 61 bytes ? (I'm testing this with echo -n and wc -c). The only variable length that I see in the PMKID format is the ESSID. So then the range would be 61 - 123 bytes (ascii)?

Also I suppose we have to be really clear as the string itself is ascii, but it represents the raw data (i.e. hex values for ASCII characters for the ESSID). Hopefully that makes sense and I'm not needlessly confusing things.

If you want some of the PMKIDs let me know and also how to get them privately to you.

System information

Aircrack-ng version

Version: Error reproduced using 1.5.2-3 . Working flawlessly on 1.2-rc4
The error could be on any revision between them.

Defect

How to reproduce the issue

Just launch an airodump process to capture IVs for WEP network while in other trying to crack it. The expected behavior is aircrack starting to crack when 5000 IVs are reach. It starts at 5000. obviously, it can't crack it using only 5000... then it is suppossed that it will try again on 10000 IVs, but on new 1.5.2 this never happens. The cracking proccess stuck waiting for 10000 ivs ... even if you capture 50000 IVs. It works on 1.2 rc4 flawlessly.

I'll put a couple of screenshots from the airgeddon script. The use of airgeddon here is not important, this can be done manually, I just detected the bug using it.

My first guess would be that the packet selection is not the same as cowpatty, so wpa handshake detection should be reworked to display the different possibilities (there might be several useable handshake in a pcap file, so don't display only one, display more than one).

]]>issuehttps://github.com/aircrack-ng/aircrack-ng/issues/1903
https://github.com/aircrack-ng/aircrack-ng/issues/1903Thu, 07 Mar 2019 15:48:11 +0000Airodump-ng can read pcap files. However, it keep reading packets until it reaches the end without waiting at all.

Add an option to allow to play the capture file in real time according to the timestamps in the PCAP.

1989 describe two bugs and one of them, the segfault, has been solved.

I got this AP that is shown as WPA2 and WPA (TKIP, CCMP) in the CSV. After checking the beacon (attached), it turned out that the AP uses WPA (and not WPA2) but has CCMP for unicast packets and TKIP for multicast packets.

So, the WPA2 flag shouldn't be set.

]]>issuehttps://github.com/aircrack-ng/aircrack-ng/issues/1999
https://github.com/aircrack-ng/aircrack-ng/issues/1999Thu, 07 Mar 2019 15:48:11 +0000John and hashcat allow users to crack a PMKID with a simple text file.
The big advantage is that the strings necessary can be easily grabbed without monitor mode or capturing the traffic.
It would be very convenient to be able to use such files with aircrack-ng too.
I think that the implementation could be totally unattended with no extra option.
User should introduce the path to his hash file instead of the cap.
Aircrack-ng would automatically use PMKID crack if the file has the following format:
PMKID from Authenticator(hexdump, len=16)*bSSID(hexdump, len=6)*MacClientStation(hexdump, len=6)*eSSID(hexdump, len=14)
4 hexadecimal strings with fixed length, separated by asterisks
That the hash file given in example by atom in his full-disclosure:
2582a8281bf9d4308d6f5731d0e61c61*4604ba734d4e*89acf0e761f4*ed487162465a774bfba60eb603a39f3a]]>issuehttps://github.com/aircrack-ng/aircrack-ng/issues/1046
https://github.com/aircrack-ng/aircrack-ng/issues/1046Thu, 07 Mar 2019 15:48:11 +0000Reported by misterx on 9 Nov 2012 01:38 UTC

In this case, airodump-ng first shows the AP is WEP which is correct and suddenly changes to WPA2.

It is probably due to invalid frames, so we have to check if the management frames are complete before processing them (or while processing).
It could also be due to a bug in airodump-ng that doesn't decode the WPA IE correctly; several different IE have the same value as WPA.

When reading in a pcap file collected using tcpdump that has a handshake, you will briefly see the handshake message followed quickly by the finished reading input file message.

Problem is that you dont know which bssid the handshake belongs to without having to open the file using aircrack-ng.

Suggestion: Make a column or even an optional column that just specifies that a handshake was collected. That way if there is a mark in the handshake column the operator will know that the corresponding bssid has a handshake.