Charset files don't behave as expected? - Printable Version +- hashcat Forum (https://hashcat.net/forum) +-- Forum: Support (https://hashcat.net/forum/forum-3.html) +--- Forum: hashcat (https://hashcat.net/forum/forum-45.html) +--- Thread: Charset files don't behave as expected? (/thread-10025.html) Pages:
1
2
|
Charset files don't behave as expected? - bbcjared - 04-19-2021 I have a hash of encrypted with Cyrillic password - "хуй", three characters long. whenever I'm trying to use charset file, it fails to crack it. official encoding file Code: >hashcat -d 4 -m 11300 -a 3 --custom-charset1 /home/maxim/tmp/hashcat-6.1.1/charsets/standard/Russian/ru_cp1251.hcchr bt_wallet_huy.hash ?1?1?1 or with my custom file like this: Code: Only those characters in hcchr file See how candidates are shown in HEX? even though my terminal is same encoding as charset file and password ? but whenever I substitute ?1 with double ?1?1 per character (russian encoding is xxxx hex codes) I'm able to find password?! Code: >hashcat -d 4 -m 11300 -a 3 --custom-charset1 custom.[color=#333333][size=small][font=Tahoma, Verdana, Arial, sans-serif]hcchr[/font][/size][/color] bt_wallet_huy.hash ?1?1?1?1?1?1 So why mask behaves like I'm using --hex-charset when charset is actual characters? Thanks RE: Charset files don't behave as expected? - Snoopy - 04-20-2021 this is a basic misunderstanding how hashcat works when it comes to utf-8 or what else encoded chars hashcat works on bytes sized style, so for example the german special char ä is in hex c3a4 which means 2 bytes long and therefore only crackable for example with ?b?b or ?1?1 (with a suitable given charset) so for a human ä is just ONE char, but for hashcat it is always 2 bytes and if you want to attack it, your mask must be at least of size 2, masksize is not always equal to charcount (only for basic asciii) each position of a mask is by default 1 byte so to crack aä your mask must be of lenght 3 (in hex 61 c3a4) ää your mask must be of lenght 4 (in hex c3a4 c3a4) RE: Charset files don't behave as expected? - bbcjared - 04-20-2021 So when searching for 6 character password in Cyrillic using mask, I'd have to double that and now I'm searching for 12 character password?!? i.e. ?1?1?1?1?1?1?1?1?1?1?1?1 Then we have Chinese and Korean character sets that are 3 bytes long in UTF - E384B1 now Korean 6 symbol password becomes ?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1 (18 character long) even though I'm looking for combination of 6 symbols from a charset. RE: Charset files don't behave as expected? - CATuGHTI - 04-22-2021 Would be nice to get a reply from one of the devs if this is actually true, I'm especially interested in Korean charset and it would really suck if each character from the character set would take ?1?1?1 (three!) spots in the mask. RE: Charset files don't behave as expected? - Chick3nman - 04-22-2021 (04-22-2021, 03:56 PM)CATuGHTI Wrote: Would be nice to get a reply from one of the devs if this is actually true, I'm especially interested in Korean charset and it would really suck if each character from the character set would take ?1?1?1 (three!) spots in the mask. Characters that require multiple bytes are handled as multiple bytes. A 3 byte character will require 3 positions to create in a mask. Hashcat works on bytes for a number of reasons, we do not currently support "wide characters" as single things because they are not to the algorithms hashing them or the buffers storing them. There are tricks for cracking this sort of character efficiently, but all of them rely on clever attack designs not extended support in the kernels. I'm not sure if this will be something we look at implementing given the reasons we currently don't. RE: Charset files don't behave as expected? - Snoopy - 04-23-2021 @bbcjared @catughti one of these "clever" tricks mentioned by chick3man to reduce keyspace if you look carefully how eg. cyrillic ist encoded https://www.utf8-chartable.de/unicode-utf8-table.pl?start=1024 all chars starting with d0, d1, d2, d3, d4 so you can modify/optimize you charset file to something like this d0d1d2d3,d4?b,?1?2 d0d1d2d3d4,?b,?1?2?1?2 d0d1d2d3d4,?b,?1?2?1?2?1?2 to search for cyrillic 1char, 2 chars, 3 chars you can optimized this further for the second byte part of the char if needed, dont forget to tell hashcat that charset is given in hex for 3 bytes chars (korean) you have to modify the trick further, i hope you get the point how RE: Charset files don't behave as expected? - CATuGHTI - 04-23-2021 @snoopy. That is what I've been doing for Cyrillic and that's fine for 3 chars password for example: (cyrillic.hcchr has list of all hex codex without d0, d1 prefix.. ) Code: hashcat -d 4,5 -a 3 -m xx -1 D0D1 -2 cyrillic.hcchr --hex-charset hash.hash ?1?2?1?2?1?2 The problem is that it takes 3 spots in the mask for Korean, Chinese (any asian sets) and with max-mask 20 chars.. we are limited to 6 symbol passwords this way. Also, its not this easy and fun in Korean as in Russian with char sets, I get a loooots of junk trying to combine 3 sets same way as with Russian.. Wish hashcat was just smart enough to put one char from .hcchr file and put it into place of ONE ?1 BTW, this behavior is not described in the manual https://hashcat.net/wiki/doku.php?id=mask_attack (Hashcat charset files ) and gives false impression that one char gets in place of ?1 Thanks for answer anyway RE: Charset files don't behave as expected? - Snoopy - 04-23-2021 why max 6 chars / max mask 20? you could mask it again like -1 D0D1 -2 cyrillic.hcchr -3 ?1?2 --hex-charset hash.hash ?3?3?3?3?3 korean and chinese, isnt it there one "char" a whole word? maybe you are better with generating a wordlist with these chars and then going further with princeprocessor or something like this RE: Charset files don't behave as expected? - CATuGHTI - 04-24-2021 @snoopy Well, this was facepalm moment for me thanks much ! )) I can combine char lists, duh Code: ?3 = ?1+?2 As the the Korean, some words are 2 some 3, some 6 characters long . (just one word). also, the character changes and building up when you type, basically https://www.howtostudykorean.com/unit0/unit0lesson1/ I have no idea how they teach this to kids.. And as for wordlists. There are about 2k characters: Code: cat Korean_utf8.txt |wc -l Combining those using combinator to get 3 characters long ls 72G already. Code: >ls -lh Korean_combined_double.txt Will try using price, maybe piping prince to hashcat. Is this still considered good attack? Code: pp64 < wordlist.dict | hashcat [options] target.hash -r prince_optimized.rule My biggest complain about piping anything to hashcat is being unable to save progress with --session Thanks RE: Charset files don't behave as expected? - Snoopy - 04-26-2021 regarding prince and session you can use these options, to limit the putput of prince to a given number --skip=0 --limit=5000000 and after the run --skip=5000000 --limit=10000000 i use badges of 5 million for attacking a list with salted hashes, i get something around 2000 MH/s and took me round 3 days per round dont bother the numbers of progress, there words + rules is counted (i think prince generated has somthing about 1500 rules) so every generated word will be multiplied by 1500) |