|
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.