Binary encryption

Question

I'd like to ask your help to understand the algorithm used to encrypt these hex/bin firmware (for an ARM-Cortex M4 microcontroller).

In the tar file above you can find different firmware versions. In particular, the V16 version has been released encrypted, plain and also an encrypted TE version (I don't know what does TE mean).

It has been a while since I started to analyze these files (I also asked another question here in the past) but, so far, I didn't find the solution. I tried to invert the bytes, swap the nibbles, xor but no luck.

As you can see, the encrypted version is 276 bytes longer than the plain. I expect that in those bytes are defined the header/footer and the key sections used by the bootloader to decrypt the binary before flashing.

Personally I think that a simple algorithm has been used (something like Salsa20 or ChaCha), nothing complicated (SHA, etc.). Thank you.

Answer 1

In fact, I doubt that they use Salsa20 on this firmware file... Let me just first explain what is my method to investigate such cases. For the rest, I will mainly use the binwalk tool.

1. What I do first is to evaluate the global entropy of the file. This is a very quick way to evaluate if we are looking at encryption or not.

   binwalk -E firmware.bin
   

   For the example, I encrypted a file with Salsa20 (filled only with ABCDEFGHIJKLMNOPQRSTUVWXYZ strings). I got the following result:

   

   Note that the obtained entropy is close to 1, which is exactly what is desired when we use any encryption algorithm.

2. The second step in my process is to try to get two successive versions of the firmware and analyze the differences. It is amazing what you can learn from looking at the differences between two files. So, for the example I encrypted the string ABCDEFGHIJKLMNOPQRSTUVWXYZ repeated several times in the first file and the same in the second file execpt for the first string where I replaced the N of the first string by a Z.

   binwalk -W firmware-1.bin firmware-2.bin
   

   

   As you may noticed, Salsa20 is a stream cipher, so I modified one byte and, then, only one byte is modified.

   In fact, the differences between two versions of the firmware will give you information about the block size of the encryption algorithm and its mode (such as ECB, CBC or others). Once you have this, you may discard some algorithms or target the most probable ones.

3. Once you gathered all these information, there are no real rule of thumb. Be creative and try to deduce the more you can with what you have and make some good and intuitive assumptions.

Now, lets go back to you firmware. I took ZPK0J020_V16_20161206_AP-D7D1.hex and ZPK0J020_V17_20170310_AP-1E6A.hex. And, I applied the method I described previously.

First, the difference between the two versions of the firmware is not against the assumption of Salsa20, but the entropy is way too low to be a strong encryption as Salsa20.

My conclusion is that the encryption of these firmware files is probably something weak. I would go for a xor-encryption or something similar. But, I did not investigate further as I think I disqualified Salsa20 and answered to your question. It is up to you to dig a bit now!