DES with partial plain text
#1
Lightbulb 
Hi.

I'm hoping someone can tell me how to "white out" a couple of values that are unknown in the plain text for a brute force attack.

I have been searching all over the forums and have been unable to find an answer.

I'm looking at the m14000_a3-pure.cl, but I don't know which lines to modify.

Any assistance would be greatly appreciated Smile
Reply
#2
Could you elaborate with a hypothetical/contrived example?

It sounds like you *might* be looking for masks. For example, if you know that a password is 10 characters and the first four characters are 'hash', but the rest are completely unknown (but 7-bit ASCII), you would use:

hashcat -a 3 targethash 'hash?a?a?a?a?a?a'

Or if you knew that the missing characters were all lower case:

hashcat -a 3 targethash 'hash?l?l?l?l?l?l'

etc.
~
Reply
#3
for -m 14000 = DES (PT = $salt, key = $pass)

the "plain text" is the salt and the password is the encryption key

Therefore, with unknown plain text the "hash" would change or you would need to load multiple hashes etc

I would first suggest to verify if what you are doing is even feasible. what is your strategy to crack those hashes ?

how many bytes of the key are known ? is it even feasible to find the correct password (key) ?
This is of course the first question you need to ask yourself, don't get distracted by unknown plain text bytes (at first). If at all they will only make the problem worse (i.e. not knowing A LOT of bytes of the key and also missing some plaintext bytes, that's just very, very bad in terms of feasibility)
Reply
#4
Hi and thanks for the replies.

Sorry Royce, I didn't explain myself very well, Philsmd is on the right track on what I'm trying to achieve.

I know the first part of the key and my rig here can brute force all of the combinations in 4 hours.

This is part of a DES-OFB stream and 2 bytes on the output are unknown, therefore I figured if I used --keep-guesing i would get 65535 different possible combinations.

Hope I'm making sense Smile
Reply
#5
so you know exactly 4 "bytes" of 8 bytes of the key ? (just remember that of the 8 "bytes" == 8 * 8 bits = 64 bits, 8 of them are parity bits, therefore it's 8*8 - 8 = 64 bits - 8 bits = 56 bits). we have the hashcat charset file (.hcchr) under charsets/DES_full.charset that can be used together with --hex-charset for a mask attack with DES/3DES

One strategy could be to just load the different "hashes", i.e. different hash:plain_text variations in hashcat. That should work already. so at maximum you have as you said 256 * 256 = 65536 hashes. Of course this makes the cracking slower by a constant factor of 65536 almost exactly.

But can't you just limit the plaintext even further ? normally the plain text is not just random bytes and therefore this strategy could work if you reduce the number of variations (charactes used in the unknown plain text bytes). Is it really binary data used as plain text ?
Reply
#6
Allow me to illustrate

Say I feed this into hashcat for cracking

xx??xxxx:xxxxxxxx

And I know the first part of the key xx??????

The above is hexadecimal of course.

The question marks are what I currently don't know, the x's are what I do know. If I could have hashcat "keep guessing" I should have a potfile with a maximum of 65536 combinations (or since DES keys are 56 bit, that would be 32768?)

At the moment, without modification (as far as I can tell) I would have to run every combination (ie guess the 2 missing bytes bytes) and that wouldn't be feasible

With the combinations that are left, it should be simple to work out which from what is left is the correct key Smile

Hope that helps
Reply
#7
now you are confusing ciphertext and plaintext

the format of -m 14000 hashes is
8_bytes_ciphertext_in_hex:8_bytes_plaintext_in_hex
Reply
#8
(06-15-2020, 09:02 AM)philsmd Wrote: now you are confusing ciphertext and plaintext

the format of -m 14000 hashes is
8_bytes_ciphertext_in_hex:8_bytes_plaintext_in_hex

My bad

Should be xxxxxx:xxxx??xx
Reply
#9
yeah, that would work, you just generate the set of hashes with different right part ("salt" aka ciphertext) and try to crack those hashes. In theory it shouldn't be 65536 if the plaintext wasn't random, but 65536 is the worst case (of "hashes").

The 56 bit only have to do with the other input: the mask ! you would run something like this:

Code:
hashcat -m 14000 -a 3 -w 3 --hex-charset -2 charsets/DES_full.charset all_the_hash_variants.txt afaf?2?2?2?2?2?2

(please be aware that if you use --hex-charset, also the constant bytes in the mask need to be in hexadecimal form, e.g. "1" becomes "31" because 0x31 is the hex representation of the ASCII character 1)

of course you need to use --hex-charset and with the hint about the 56 bits from above I wanted to emphasize that you should use the charsets/DES_full.charset hashcat charset file (.hcchr) which already reduces the amount of keys tested to the 56 bits.

of course the hash file all_the_hash_variants must be generated somehow, you could just use any scripting/programming language.

e.g. something like this (perl script):
Code:
#!/usr/bin/env perl
  
use strict;
use warnings;

for (my $i = 0; $i < 256; $i++)
{
  for (my $j = 0; $j < 256; $j++)
  {
    print sprintf ("53b325182924b356:14127810%02x%02x3178\n", $i, $j);
  }
}

This is for the example -m 14000 hash from https://hashcat.net/wiki/example_hashes (password: hashcat1), but you could just change the known bytes above with your target hash (%02x is the thing that gets replaced, in the 2 locations, therefore twice ! with $i and $j counter)
Reply
#10
Thanks for your time to even go as far to provide a script to iterate all of the combinations.

What your describing seems exactly what I was looking for. My only question is wouldn't this be a big performance hit? 
IE would hashcat test every hash individually?
Reply