HMAC Support about findcrypt-ghidra HOT 3 CLOSED

The problem with single byte patterns is that I can find probably thousands of occurences of \x36 and \x5c.

Encryption algorithms such as AES use the SBoxes to do the substitution, thus, we can find these blocks of bytes equally everywhere. This is a block of numbers, that just gets compiled and stored in the executable.

The same would go for SHA1 but in a different case, what I'm scanning in the hashing algorithm are either the default states as specified in the RFC-3174 (page 11) or clib's implementation:

context->Intermediate_Hash[0]   = 0x67452301;
context->Intermediate_Hash[1]   = 0xEFCDAB89;
context->Intermediate_Hash[2]   = 0x98BADCFE;
context->Intermediate_Hash[3]   = 0x10325476;
context->Intermediate_Hash[4]   = 0xC3D2E1F0;

Or if you are assisted by some static analysis, daring to tryhard a little, you could scan for the R0...4 operations constants.

This works in our case because we have enough data size for which we can assume safely(ish) those algorithms are being used and wouldn't produce too much noice either.

When you have single byte patterns such as '0x36' or '0x5c', used in the calculation of ipad and opad in HMAC as described in RFC-2104 (page 3), you are scanning for a single byte in the whole executable, this would produce far too much noise as you would get hundreds if not thousands of findings.
Since HMAC is not a hashing algorithm but a "put a symmetric key on top of your hashing algorithm of choice", we don't have reliable constants to figure out the exact key location, the workload is left to the reverse engineer by dealing with the application logic.

One could actually make it work, if instead we would be scanning the compiled bytecode pattern of HMAC SHA-1 implementation, but this would introduce the variations of bytecode produced for x86, AMD64 or ARM.

Feel free to Reply if you disagree, I'm glad to discuss and to learn my mistakes.
Also sorry for the late reply from my end.

from findcrypt-ghidra.

I think you identified the problem spot on. It just isn't realistic to search a non-trivial binary for single bytes. There are far too many false-positives that you are likely to receive. Something a bit more intelligent would be searching for xor / eor instructions that use a HMAC magic byte as an immediate value. That would normally work, but in the case of my binary it turned out the author was using a whitebox crypto implementation. Had this not been the case, I would have been able to easily identify the HMAC patterns and recover a key. This particular HMAC implementation stored the prehashed states for the HMAC opad and ipad inside of tables. The tables were used to populate the SHA1 states without an actual in-memory key. This was one of the more complex crypto implementations I've reversed.

It worked out though and I managed to recover the key after a lot of work. Your library has proven useful to me many times. Thank you.

from findcrypt-ghidra.

Glad to hear that 👍🏻 feel free to open an issue whenever needed, I promise I'll reply one day or another

from findcrypt-ghidra.