Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <568550CC.4010802@openwall.net>
Date: Thu, 31 Dec 2015 09:59:08 -0600
From: jfoug <jfoug@...nwall.net>
To: john-dev@...ts.openwall.com, ls@...r.so
Subject: (moved to john-dev) Re: [john-users] QNX Neutrino 6.6.0 password
 hashes

Ok, with a bit more work, it appears that bytes [116 to 119] are not 
being cleaned.  To me, it looks like they used a 32 bit int to clean the 
data from [112-115] instead of a 64 bit int, and then perform the BE bit 
count using a 64 bit value, so the last 8 bytes are prepared properly.

I believe I can get this 'working' using my generic sha2 code, and then 
I am pretty sure we can do this in the SIMD code, or at least 'inline' 
in the format without having to modify the SIMD code.

On 12/31/2015 9:14 AM, jfoug wrote:
> I have been able to get 'correct' hash value for a 99 iteration 
> password '3' for sha512.  I am using my 'generic' sha512 code.  I made 
> a tiny change within sha512_final
>
> ```C
> void jtr_sha512_final(void *_output, jtr_sha512_ctx *ctx)
> {
>     ARCH_WORD_32 last, padcnt;
>     ARCH_WORD_64 bits;
>     union {
>         ARCH_WORD_64 wlen[2];
>         unsigned char mlen[16];  // need aligned on sparc
>     } m;
>     unsigned char *output = (unsigned char *)_output;
>
>     bits = (ctx->total <<  3);
>     m.wlen[0] = 0;
>     OUTBE64(bits, m.mlen, 8);
>
>     last = ctx->total & 0x7F;
>     padcnt = (last < 112) ? (112 - last) : (240 - last);
>
>     jtr_sha512_update(ctx, (unsigned char *) padding, padcnt);
> +   //m.mlen[0] = '3';
> +   //m.mlen[1] = '3';
> +   //m.mlen[2] = '3';
> +   //m.mlen[3] = '3';
> +   m.mlen[4] = 0x80;
>     jtr_sha512_update(ctx, m.mlen, 16);
>     // ....
> ```
>
> So, by placing a 0x80 into the location where the 0x80 'would' have 
> been placed in the first buffer, I get the same hash.  So this looks 
> like a 'classic' off by one bug within the QNX code. They are cleaning 
> the buffer, BUT forgetting about the 0x80 byte 'added'. Why 112, 113 
> and 114 length hashes are working, is beyond me. Likely, this is not 
> the only bug, but it lets me continue to look.
>
> On 12/31/2015 8:36 AM, jfoug wrote:
>> A new test was performed, using just a 1 byte password and 16 byte 
>> salt.  It appears that hashes (salt+passwords) up to 114 bytes 
>> 'work', but after that, they are broken (but consistently broken) for 
>> sha512.  It may be that the buffer cleaning is not being properly 
>> done (the final 'bit length' buffer).  Hopefully this can be figured 
>> out, and replicated, so that sha512 can also be cracked by jtr.  It 
>> is especially important, since sha512 is the 'default'
>>
>> https://moar.so/tmp/qnx_sha512_broken_2.txt 
>

-- 
Community volunteer for John the Ripper project.

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.