DES KPA printf output not as expected
#3
(08-02-2021, 01:39 PM)atom Wrote: Not in bitslice kernels. The 24 bits you are missing are in words_buf_s[pc_pos].b[] but they are transposed.

See m14000_tm() to understand how they were transposed.

Alternatively, you will also find N many of these missing 24 bit entries in mod[gid];

OK that makes sense on where the rest of the bits are found. My end goal is to understand the code well enough to modify it to create a DES output feedback where the output from the first round of encryption is fed into the input of the second round.

Let me know if I'm wrong here but: 

Looking at the code the KPT from the command line is bit-shifted to the right, bitwise AND'ed with 1 and a ternary operation to give either 0xffffffff or 0x00000000 this is stored in d00 and so on.

Code:
  const u32 d00 = (((salt1 >>  0) & 1) ? -1 : 0);

The same happens to the hash provided on the command line:

Code:
  const u32 S00 = (((s0 >>  0) & 1) ? -1 : 0);

The same seems to happen for the passwords as well but there is an extra step for the words_buf_s that I'm yet to get my head around completely.

Code:
  #define K00 (((w0 >> ( 0 + 7)) & 1) ? -1 : 0)
Code:
k00 |= words_buf_s[pc_pos].b[ 0];
 

Now, all that is fed into the DES function, k00-k27 are inputs from the words_buf_s and K28-k55 are password inputs into the DES function either 0xffffffff or 0x00000000 depending on the result of the bitwise AND and ternary operator.

d00-d63 are assigned to D00-D63 which are then passed to the DES function as the plain text input.

The DES function is run and it updates the values in D00-D63 to the output ciphertext.

Then D00 is XOR'd with S00 and assigned by bitwise OR to tmpResult. Every 16 ints is checked that it does not equal 0xffffffff if not it's then passed to COMPARE_S

 From there if it matches hashcat will return the password. Does that sound about right?

To get the output feedback happening I tried duplicating the call to the DES function in the inside loop, D00-D63 should contain the ciphertext from the previous round which would be the input into the next round. The password inputs should be the same as the kernel is still running. 

However nothing is that easy, I have tried it and haven't been able to get it to work, it exhausts the key space and printing out D00-D63 after the last round is not the same output as a single round with the same key. 

Am I on the right track here? is this line of thinking possible or have I got everything totally wrong here?

Thanks.

P.S I've only started learning to code in C this year so I'm not 100% across all topics but will give it a really good go,
Reply


Messages In This Thread
DES KPA printf output not as expected - by Zzzz - 08-02-2021, 01:21 PM
RE: DES KPA printf output not as expected - by Zzzz - 08-10-2021, 12:58 PM