# Binary encryption

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.

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!

• Hi, thank you very much for your response and help. I really appreciate it. I imagined that a weak (probably "custom made") algorithm was used, but it has been almost 3 months that I'm struggling with it and no results so far :-( I also noticed that few 0x00 and 0xFF bytes are repeated so, do you think that a "pure" xor-encryption has been used? I keep continuing with my research :-) Thanks a lot. – Avok78 Feb 25 '18 at 2:25
• I guess that the next step is to perform a frequency analysis on bytes (according to the differences between two versions, block size is most likely a byte). And, if this is a simple xor-encryption, a Kasiski examination could help to discover the length of the Xor mask. But, if you want to know more about cryptanalysis of xor encryption, this should be another question. Also, don’t forget to mark this question as “answered” if you think it is solved. – perror Feb 25 '18 at 9:13
• Hi perror, I marked the question as "answered", however my question was a request for help to understand the algorithm used. Anyway I will proceed with my research and I will try with the kasiski examination and the index of coincidence techniques. Thanks. – Avok78 Feb 26 '18 at 14:26
• Well, I feel like I gave you an answer to what kind of "encryption" is used here. This cannot be a strong one, and the xor-cipher is the most usual one in these cases. If you want a complete cryptanalysis of the files, it will require more work and I think this is out of the scope of this question. As a hint for more investigation, you may refer to this question. – perror Feb 27 '18 at 9:37
• Hi Perror, yes you gave me an answer and I really appreciated that. If you have time to help me more for this task I will appreciate it. It has been a while (almost 3 months) that I'm trying to understand the algorithm that has been used, but no luck so far. If you are interested on this project, [here] (219.84.35.58/brookhex) you can find more firmware released by the same company. I'm pretty sure that they use the same algorithm for each product. Anyway, thank you very much for your help and time. Regards. – Avok78 Mar 1 '18 at 13:58