[<prev] [next>] [day] [month] [year] [list]
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.
