Does hashcat suppor "cutted" hashes ?

[overguard]

Hello everyone, I'm new in hashcat community.  So back to my problem.
I've got "cutted" MD5 hashes, they don't have the last symbol. I can send examples, if it necessery.

So losing 1 symbol of the hash isn't a big deal. How can I setup hashcat to crack hashes without "looking" on the last symbol.

Sorry for possible mistakes, my english isn't perfect.

[philsmd]

how many hashes ?


if there is only 0-9a-f missing from the end, why don't you just add 0, 1, 2, 3, 4, .... d, e, f to each hash ?
It's way easier and elegant solution (at least as long as you have only a few hashes and a few chars a missing) instead of trying to mess with the code (aka change the source code) and risk to not do it correctly.

[overguard]

how many hashes ?


if there is only 0-9a-f missing from the end, why don't you just add 0, 1, 2, 3, 4, .... d, e, f to each hash ?
It's way easier and elegant solution (at least as long as you have only a few hashes and a few chars a missing) instead of trying to mess with the code (aka change the source code) and risk to not do it correctly.

Thanks for you answer. Actually I have 3544 hashes to crack, so this solution isn't what I'm looking for

[philsmd]

why ?

That isn't really many hashes: 16 * 3544 = 56704

by many MD5 hashes I meant something like millions of hashes.

of course there is another solution... but I'm not comfortable of writing that down here or letting you know in PMs how to do it because I had a lot of bad experience with it. users can't apply patches, they can't compile hashcat, they have problems to clear the kernel cache folder, they have problems of creating a new/separate hashcat folder for which they know that it is manipulated etc ... so of course you could just clear the bytes (a bit mask) in the kernel files, but it's an advanced change of the source code and as said, it seems that the general forum user can't manage it even if you give them a perfect diff file and very clear instructions, unfortunately (it even happened that users complaint that something is not working correctly and the only reason was that they changed the source and didn't realize that their manipulated hashcat code is the reason why the "normal" cracking code didn't work anymore. The problem therefore was that some users seem to be not careful and clever enough to distinguish 2 hashcat versions).

the hash file manipulation is much easier and more elegant, many text manipulation tools can do it with very little effort:

Code:

sed -E 's/(.*)/\10\n\11\n\12\n\13\n\14\n\15\n\16\n\17\n\18\n\19\n\1a\n\1b\n\1c\n\1d\n\1e\n\1f/' hash_truncated.txt > hash_full.txt

with awk:

Code:

awk '{print $0"0\n"$0"1\n"$0"2\n"$0"3\n"$0"4\n"$0"5\n"$0"6\n"$0"7\n"$0"8\n"$0"9\n"$0"a\n"$0"b\n"$0"c\n"$0"d\n"$0"e\n"$0"f"}' hash_truncated.txt > hash_full.txt

etc

[royce]

Pie in the sky ... imagine a flag for hashcat like --cut-hash that takes a paired argument like mp64 [integer]:[integer], with the absolute range of characters that should be matched in the hash, starting with 1 to make the math easier.

For example, for 31-character truncated MD5, the syntax would be

Code:

--cut-hash 1:31

Of course, this might not be possible for optimized kernels, etc. But it sure would be handy to be able to do this quickly with hashcat.