So to start with, I grabbed the Lerdge firmware from their website, and unpacked it, then read up about the update process. Like most firmwares, there's an update from the UI and a force update mode in which the bootloader forcibly updates the firmware.

Step one was to test force update and make sure I could make the firmware update.

Step two? Open a hex editor and zero out some random bytes in the firmware, then force the update. 

What we're looking for here is that the bootloader refuses to update because it's checking a CRC of the firmware. 

Nope, it updated just fine, which puts us in business. At this point, I asked for help from a friend with amazing soldering skills, and he soldered leads to the SWD and reset pins, so I could hook up an ST-LINK to the board.

But...

Read protection was set. Not surprising at all - it's the least effort possible and it's completely expected, so no worries. I can't dump the bootloader without being able to load a trojan, and to load  a trojan, I need to know how the ROM works.

So...to the hex editor.

These project logs will likely be heavy on hex dumps. Get used to it.

Here we have the first few bytes of the firmware:

8B7D5D65 A6919D5F 2BCB9D5F ABCB9D5F 
2CCB9D5F ACCB9D5F 2DCB9D5F 5D5D5D5D 
5D5D5D5D 5D5D5D5D 5D5D5D5D B5CB9D5F 
36CB9D5F 5D5D5D5D B6CB9D5F 37CB9D5F 
AD919D5F AE919D5F AF919D5F A8919D5F 
A9919D5F AA919D5F AB919D5F AC919D5F

Wow, that looks like a mess. Just to compare, let's look at an unencrypted one:

D8FF0020 FD020708 C9020708 CD020708 
D1020708 D3020708 D5020708 00000000 
00000000 00000000 00000000 D7020708 
D9020708 00000000 DB020708 15770308 
6D030708 71030708 75030708 79030708 
7D030708 81030708 49000708 91760308 

 First off, it helps to know that this is an ARM processor, and the first few bytes are most likely the NVIC table. The NVIC table has a very particular layout, and in particular, it requires a few fields to be zero at the beginning.

Right where we have zeros in the unecnrypted one, we have 0x5D bytes in the lerdge one.

So the first thing to do is break out an xor tool. I ran one and not surprisingly, it calculated that the most likely XOR key would be 0x5D.

It does so based on zero being the most likely byte, and we can see that 5D XOR'd with 00 would yield it. But the xored result was garbage. We can be fairly certain it's not a nibble substitution, either. Why?

Because we know some particulars of STM32Fx hardware. First, let's start with the last byte to the right in that first row. That's an interrupt vector, and it *must* be 0x08 on this hardware.

Similarly, the first word? That one is the stack pointer and it MUST end in 0x20. If it's a nibble swap, we'd see the same nibble values in the 0x08 and 0x20.  

The other thing we can be fairly sure of is that it's not a true encryption. The reason has to come from scanning the OTHER end of the firmware. Many toolchains put things together in a very similar fashion and we see zeros laid out in pretty much exactly the right places--if 5D is a zero.

So we're probably looking at a byte substitution, not a rolling encryption, and we can tell three  byte values for sure:

0x5F must be 0x80.

0x65 must be 0x20.

0x5D must be 0x00.

 And everything else is unknown. So we start.