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
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
(07-31-2021, 04:15 PM)ZerBea Wrote: [ -> ]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?
(07-31-2021, 04:15 PM)ZerBea Wrote: [ -> ]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.
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)
(07-31-2021, 11:02 PM)ZerBea Wrote: [ -> ]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.
(07-31-2021, 11:02 PM)ZerBea Wrote: [ -> ]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.
(07-31-2021, 11:02 PM)ZerBea Wrote: [ -> ]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.
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.
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.
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
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).
@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