(moved to john-dev) Re: [john-users] QNX Neutrino 6.6.0 password hashes
(too old to reply)
2015-12-31 15:59:08 UTC
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.
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
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.
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'
Community volunteer for John the Ripper project.