Ok, honestly I could even probably just do with a crypto teenager at this point.

tl;dr for the non-technically minded: Things are coming along well, protocol documentation work is happening (See latest protocol docs here), but still working on firmware extraction.

Now, for the nerds:

First off, please check out the firmware reverse engineering document on the erosoutsider github site. This outlines our goals, attack vectors, and status. I'm trying to keep these as up to date as I can. But for those that hate reading:

  • We're trying to extract firmware for an ATMega16 with JTAG/OCD off and lock fuses set.
  • It has 512 bytes of bootloader.
  • We have some knowntext.

Last week, using a string overflow and a logic analyzer on the LCD pins, I managed to extract around 1600 bytes of ET-312 firmware. Yay! Previously we only had 255 bytes.

For those interested, the extracted blob is in our github repo. I believe this is all of the .data and .bss sections, followed by some garbage data (explained in a bit).

So now we have:

What we don't have:

  • Knowledge of the position of the knowntext in flash or in the firmware upgrade file. I modified a multiplier to get the string overrun to work, but the offset the multiplier is working on is a constant in flash.
  • Knowledge of whether the encrypted upgrade file is in flash load order from 0 to 15872 (we're assuming it is).

We want is the full, unencrypted firmware. The problem is, I'm running out of ways to access memory. I don't have access to the stack space via the serial protocol, and things get very rebooty if I try to change the stack pointer origin.

Now we get to the part where things turn a bit handwavey and I need a crypto grownup. From the XOR of the two upgrade files, it seems like there's a noticable lack of entropy in the encryption even though the files have different contents. Also, the bootloader is only 512 bytes, meaning it's not the usual AES/DES provided in Atmel Application Notes, which requires a minimum of 2k bytes of space.

Also, when inspecting the XOR, some parts show patterns, while some are garbage. I have a feeling the garbage parts may just be random bytes used in something like an srec_cat call to fill unused flash space. In our knowntext, the transition from .data/.bss to garbage is pretty obvious, meaning we /might/ be able to guess a vague position of the knowntext in the encrypted file, not that the search space is all that huge to begin with.

So, there's a chance this is just some set of operations (XOR, arithmatic, etc) on a multibyte key. However, using the known text as a sliding window and searching for repeating substrings hasn't resulted in much. I'm sure I'm probably missing some pretty obvious attacks, but this is why we've got neighbors, right?

If you've got any tips, either:

Together, we can help people shock themselves in the butt better.

UPDATE: Twitter has been helpful already! See this thread for more info, but current thought is that it may be a 32-bit LFSR. Thanks to scanlime for the help!