Add H3C/Huawei/HPE hash format

[SamuraiOcto]

This adds support for hashes with $h$6$ prefix that are used in various H3C/Huawei/HPE network devices. The SHA512-based format is described in this hashcat issue and this PR.

[solardiz]

Thank you for the contribution @SamuraiOcto!

Can you please add test vectors for the maximum supported password lengths (with and without SIMD)?

I wonder if this hash is implementable as a dynamic format. If so, maybe we'd need to switch this format to a "thin" wrapper around dynamic, as we already have in a few formats.

[SamuraiOcto]

Is it possible to include the null bytes with a dynamic format, like sha512($p."\x00".$s.$p."\x00")? It doesn't seem to be possible to include null bytes in the wordlist. It is possible to merge the first null byte with the salt and provide the salt as hexadecimal, but that won't work for the second null byte. It is probably possible to create a rule that appends a null byte to all plaintexts, but then it will be annoying if a user wants to use another rule file.

[magnumripper]

I wonder if this hash is implementable as a dynamic format. If so, maybe we'd need to switch this format to a "thin" wrapper around dynamic, as we already have in a few formats.

We could, but why "need"? This one doesn't look too bad. Perhaps we could avoid using scalar buffers for a small boost if we really wanted to.

[solardiz]

We could, but why "need"?

Oh, I used the wrong word. We certainly can accept this as a separate format as well. I just thought we could prefer to reduce code size / duplication at some point. Formats like these have rather simple logic, but much code shared with other formats.

[solardiz]

I made some comments, but really those can be addressed separately.

[solardiz]

I see we have similar logic in sha512_common_valid_nsldap, and in both places we don't fully check that the base64 encoding is valid (= only used as padding). We might want to enhance both with a test base64_convert run and checking its return value. A way to do that may be to have get_binary return NULL if base64_convert fails to provide the expected length data, call get_binary from valid and check its return value. Since we would also be fixing the pre-existing code, this (or at least that part) should be a separate commit (may also be separate PR).

[solardiz]

It's good that we adjust for endianity on get_binary. I am puzzled why we also have such adjustments in crypt_all and cmp_exact. I think we could have the binary in the byte order that is expected by further code and that's it.

[solardiz]

I think we don't need a fully implemented cmp_exact at all. We could instead compare the full computed hash in cmp_one.

[solardiz]

Is it possible to include the null bytes with a dynamic format, like sha512($p."\x00".$s.$p."\x00")?

Oh, I don't know. Maybe not. Good point.

[solardiz]

hashes with $h$6$ prefix that are used in various H3C/Huawei/HPE network devices

Did the two test vectors here come from actual devices?

[magnumripper]

We could, but why "need"?

Oh, I used the wrong word. We certainly can accept this as a separate format as well. I just thought we could prefer to reduce code size / duplication at some point. Formats like these have rather simple logic, but much code shared with other formats.

True. Another possibility could be to amend the SSHA512 format to accept these hashes, but maybe it's different enough it would cause a regression from added logic.

Anyway, format code like this current PR is the nicest start for implementing an OpenCL version. Easy to follow and easy to move valid/binary/salt to shared code. And a big problem with dynamic is it doesn't have an active maintainer.

[magnumripper]

I tried doing this in dynamic compiler format just for the hell of it (re-encoding the Base64 into hex manually), but it failed with no clue as to why (possibly the NUL constant - or maybe \xHH isn't even supported but taken as-is, there's very little documentation).

I then looked into doing it with the config style dynamic but the various docs contradict each other so I gave up. In that case \xHH is said to be supported but it doesn't mention \x00 so that is an unknown already.