hcxtools - solution for capturing wlan traffic and conversion to hashcat formats

[fromdusktillpwn]

I might be trippin but this thing is driving me crazy: why hcxhashtool does not accept bitmask-option --type=1? Although, numbers 5, 9 or greater (the ones with the first bit being set) work perfectly to filter pmkids.

Code:

> hcxhashtool -i in.hash --type=1 -o pmkid.22k
only hash types 1 and 2 allowed

Code:

> hcxhashtool -v
hcxhashtool 6.2.0-44-ge302e37 (C) 2021 ZeroBeat

[ZerBea]

Currently 2 hash formats (01 = PMKID, 02 = EAPOL) are accepted by hashcat running hash mode 22000/22001:

Code:

WPA*01*PMKID*...
WPA*02*MIC*...

They are explained here:
https://github.com/hashcat/hashcat/issues/1816

You can use bash tools to get the same result
for PMKID:

Code:

$ cat hash.hc22000 | grep "WPA\*01"

for EAPOL:

Code:

$ cat hash.hc22000 | grep "WPA\*02"

The purpose of --type option is to filter output by that 2 types

Code:

--type=<digit>               : filter by hash type
                               bitmask:
                                1 = PMKID
                                2 = EAPOL
                               default PMKID and EAPOL (1+2=3)

To filter by a bit/byte of a PMKID or a PMKID itself doesn't make sense, because a PMKID is the result of a hash calculation:
https://hashcat.net/forum/thread-7717.html

[fromdusktillpwn]

The purpose of --type option is to filter output by that 2 types

So how do I filter my big 22k-hash file by PMKID? Isnt it --type=1, like help section says?

To filter by a PMKID itself doesn't make sense

I dont understand why not exactly? And why then help section of hcxhashtool still says that --type=1 should work? Actually, the latter question bothers me the most, since im able to export PMKID-hashes by using --type=5.

[ZerBea]

Now I understand your question. For sure, you will get all PMKIDs by --type=5, too
The option field is a bitmask.

Code:

5 = 0101
bit 0 = 1 (if 1 = filter by PMKID)
bit 1 = 0 (if 1 = filter by EAPOL)
bit 2 = 1 (unused)
bit 3 = 0 (unused)

In other words:
--type=1 is the same as type = 5, is the same as type = 9, is the same as type = 13 and so on. In every case bit 0 = 1 and you will get all PMKIDs

I thought this was clear from --help that only bit 0 and 1 (values 1, 2 and 3) is in use.

Now, by latest commit
https://github.com/ZerBea/hcxtools/commi...3f832bb732
I fixed that and you will get an ERROR message if you try values greater than 3:

Code:

$ hcxhashtool -i hash.hc22000 --type=5 -o hashfiltered.hc22000
only hash types 1 and 2 allowed (values 1, 2 or 3)

the same applies if you try 0:

Code:

$ hcxhashtool -i hash.hc22000 --type=0 -o hashfiltered.hc22000
only hash types 1 and 2 allowed (values 1, 2 or 3)

[fromdusktillpwn]

The option field is a bitmask. 
--type=1 is the same as type = 5, is the same as type = 9, is the same as type = 13 and so on. In every case bit 0 = 1 and you will get all PMKIDs

I understand that.

I thought this was clear from --help that only bit 0 and 1 (values 1, 2 and 3) is in use.

Yes, it was. But value 1 didnt work.

I fixed that and you will get an ERROR message if you try values greater than 3:

Now it works as expected (_both_ values 1 and 4+), thanks! Good to know I wasnt tripping after all.

[oayz]

ZerBea, does "hcxhashtool.exe --essid-list=" work on Linux? On windows it doesn't do anything. This option seems to be skipped altogether, I can even specify non-existed file. All other essid filters work as expected.

[ZerBea]

It is working on Linux, as well as --mac-list. It looks like "rb" isn't supported on Windows, e.g.:

Code:

if((fh_essidlistin = fopen(essidlistinname, "rb")) == NULL)
if((fh_maclistin = fopen(macskipname, "rb")) == NULL)
if((fh_maclistin = fopen(macskipname, "rb")) == NULL)

By latest commit I changed the mode from "rb" to "r" and "wb" to "w".

The devil is often in the details:
It isn't enough to compile a file. It has to be ported to the target operating system, too, because then handling some function calls is different.
I don't take care about this, because I use Linux, only.

[oayz]

Well, I always been told C is portable language, just need to recompile ;-) Anyway my C is rusty but I remember if I use fgetc() it's always binary read. fgets() is another story

Thanks for the prompt reply anyway - I don't push you to write for Windows (though you do it anyway - in small steps

[ZerBea]

In this special case, I removed the portability by latest commit.

Code:

The mode string can also include the letter 'b' either as a last
character or as a character between the characters in any of the
two-character strings described above.  This is strictly for
compatibility with C89 and has no effect; the 'b' is ignored on
all POSIX conforming systems, including Linux.  (Other systems
may treat text files and binary files differently, and adding the
'b' may be a good idea if you do I/O to a binary file and expect
that your program may be ported to non-UNIX environments.)

https://www.man7.org/linux/man-pages/man3/fopen.3.html

BTW:
My C is rusty, too - I learned assembler (6502, 6802, 68000/68010).

[oayz]

@ZerBea, I did some debugging and need to apologize - it's not about "r" ("rb" is fine, you can revert it back), it's about my misunderstanding:

1. Expected "--essid-list" filter to work on "--info". Actually it only works on the output, info is always unfiltered (however it is filtered by "--essid" or "--essid-part")

2. Based on the above, didn't provide output file ("-o"). W/o it "--essid-list" is bypassed w/o warning:
if((pmkideapolcount > 0) && (pmkideapoloutname != NULL) && (essidinname != NULL)) processessidfile(essidinname, pmkideapoloutname);

Don't you think that "-essid-list" should basically be multiple of "--essid"? Of cause regexp support would be extremely nice and with it we won't need "essid-part". Effectively "egrep -f" but with ability to convert hex ESSID to text

P.S. I've also started with assm - i8080 (CP/M), i8751, i8088 (PC), 6502 (Sinclair). Even touched your MC6802 (once . Now it's Python and Matlab