Finding AES Key in binary using Ghidra and FindCrypt

Question

I would like to learn more about RE.

I wrote a simple program on a STM32F107 which does nothing else than encrypting and decrypting a text once using AES128-ECB.

Here is the C code (I intentionally left out the key so far):

    struct AES_ctx TestAes;
uint8_t key[16] =
        { MY_KEY_IS_HERE };
uint8_t InputText[16] =
        { 1, 2, 3, 4, 5, 6, 7, 8, 9, 0xa, 0xb, 0xc, 0xd, 0xe, 0xf, 0 };
AES_init_ctx(&TestAes, key);
AES_ECB_encrypt(&TestAes, InputText);
AES_ECB_decrypt(&TestAes, InputText);

Now I want to find the 16 byte private key in my binary.

When I open the binary in a hex editor and search for my key I find all 16 bytes in a row.

I loaded the binary in Ghidra, installed FindCrypt before and now run the analysis.

FindCrypt now finds AES_Decrytion_SBox_Inverse and AES_Ecryption_SBox.

But both are not my AES key but the SBox. How does it go on after that? In all tutorials I find it looks quite simple, because the Functions Finder finds the AES functions - but since the project is Bare Metal this will probably not work.

I thought FindCrypt looks for some kind of hex pattern which could result in a key...

I have attached the binary. endian is little, architecture is ARM Cortex (I think?!)

Answer 1

I thought FindCrypt looks for some kind of hex pattern which could result in a key...

That would literally be any sequence of 16 or 32 bytes.

When reverse engineering larger apps, this is often a bit easier because the key will tend to be surrounded by a sea of zeros for uninitialized memory. So you just hunt for exactly 16/32 aligned bytes of "no more than 1 zero in a row surrounded by lots of zeros" and you'll probably find keys. But given your program structure, this may not happen. There are never any promises when you're reverse engineering. You'll often have to use lots of different approaches.

In your case, you'd want to hunt for the call to AES_init_ctx, which will reference the key, but it's a little harder to find the key itself automatically.

The important lesson here is that proper (random) AES keys have absolutely no structure other than their length. So it's impossible to look at a sequence of bytes and say "that's definitely an AES key." On the other hand, because they have no structure (and most data does), it's often quite easy to look at a sequence of bytes and say "that's almost certainly an AES key."

(It's also worth noting that almost everyone creates their AES keys incorrectly, basing them on a human-readable password, so that they have quite a lot of structure. Looking for ASCII strings that happen to be exactly 16/32 bytes long is often much more rewarding than looking for 16/32-bytes of random binary data.)