Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Thu, 20 Feb 2014 23:17:28 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
CC: atom <atom@...hcat.net>
Subject: SAP-B obscure bug or intended behavior?

Thanks for reporting!

I'm passing it on to john-dev to start with. Anyone got a clue? I know 
we tested this format with a whole lot of real SAP hashes. I'll dig out 
older versions of our format and check if it behaves differently.

magnum

On 2014-02-20 22:42, atom wrote:
> Hey Magnum,
>
> I was recently adding SAP-B to oclHashcat and used jtr as a reference for
> implementing. I found a problem in the implementation that I think goes
> back to the reversal of the algorithm. Since I don't know who it reversed
> maybe you can forward it to the right person?
>
> Problem is in the waldorf_magic function in this section:
>
> while(I2 < sum20) {
> if (I1 < len) {
> if (temp_key[DEFAULT_OFFSET - I1] & 0x01)
> destArray[I2++] = bcodeArr[BCODE_ARRAY_LENGTH - I1 - 1];
> destArray[I2++] = key(I1); I1++;
> }
> if (I3 < cur_salt->l)
> destArray[I2++] = cur_salt->s[I3++];
> destArray[I2] = bcodeArr[I2 - I1 - I3];
> destArray[++I2] = 0; I2++;
> }
>
> The purpose of this function is to generate N byte of data. The number N is
> calculated and stored in the sum20 variable. Problem is that, depending on
> the salt and the password chosen, the I2 variable can overflow the sum20
> variable by at least 1. That means, the function produced for example 37
> bytes even if sum20 only asked for 36 bytes.
>
> JtR in that case seems to truncate the overflowing byte, but when I rewrote
> it in perl for my unit tests I was unaware of the problem and I wrote it in
> a way that it does not truncate it, resulting in a complete different hash
> result.
>
> The question is, how does SAP react in that case.
>
> Heres's the hash that can be used for reproduce:
>
> 12850413$1470EF2F683C956D:46813230
>
> You should be able to crack the hash with jtr and oclhashcat, but I think
> we have a problem here-.
>


Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ