Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

The Thermomix TM5 is a multifunctional kitchen appliance. In previous research, Jean-Michel Besnard found a directory traversal flaw in BusyBox's tar implementation. This article describes a lot of reverse engineering of the device and a firmware downgrade vulnerability they found in the process.

The device contained a strangely formatted NAND flash; after considerable effort, they found a tool to decode it. There are cook sticks that hold recipes for use with the Thermomix. Upon looking at the UDP flash drives, they find out they are encrypted. Upon examining the NAND flash firmware, a file named /opt/cookey.txt is found to contain the encryption key. After some reviewing of a customized kernel driver, they are able to decrypt locally, but cannot modify it because the data is signed.

The Cook Key is a special device that enables users to connect the Thermonix to WiFi, download firmware updates, and access additional recipes from a cloud service. It contains a WLAN module, an LED controller, and a UDP flash drive for the file system. The first partition contains a cs.tar and the second partition contains recipes, cloud settings, and a recovery firmware image.

The author wanted to emulate the Cook Key completely. Therefore, they created a custom board with all the pre-signed information. This isn't an issue by itself but it allows for a larger attack surface.

The version section is what we're after. This contains three values: date, comment and force_flag, with the first two being arrays. The original usage of this contained a security issue: the firmware could be downgraded by swapping firmware update file sections between versions. A classic replay issue, but this was the past, and we needed a new vulnerability by swapping these individual sections around.

When verifying the firmware update file, each section is encrypted using the AES-EAX mode. This combines AES-CTR for encryption and OMAC-based tag for integrity. Each section is RSA-signed, but the nonce and tag are excluded from the signature so that they can be tampered with. We know the encryption algorithm in this case, but we're unable to modify anything because of the signature. Or can we?

In AES-EAX decryption, the keystream is generated from the nonce N and the AES key K. PT = C0 XOR K0 in most cases. This can be rearranged to K0' = C0 XOR P0'. If we XOR our plaintext with the ciphertext, we can know what key (nonce starting value) it can be generated with. Since we control the nonce and know the key, we can reverse the encryption process to find a nonce that will match this. Neat!

In practice, we control the first date string but everything else will be a garbled mess. The force_flag is something that we want to be set to 1 though. By brute forcing enough keys, it's possible to set this to 1. All of this works because A) the nonce is not verified and B) the header information with the date, comment, and force_flag is a singular encrypted piece of data with nothing else in it. I find it weird that the signature is unique per section, personally.

Cryptography, particularly AES-CTR mode, is hard to use properly. With both encryption and signatures, this scheme looked perfect but it gave the author just enough room to workaround it. Awesome post!