Close

Some Semblance of Control

A project log for Lerdge 3d Printer Mainboard Hacking

Breaking the encryption on the Lerdge series mainboards so I can try porting Marlin 2.0 to it.

jc-nelsonJ.C. Nelson 12/09/2018 at 20:480 Comments

Now I had the decrypt broken, the first thing I did was adjust an arduino blink sketch and attempt to use it to blink the status LED.

Failure.

The firmware would update and then the board would hang.

I got fancy and moved to blinking pretty much everything. 

No dice. 

I put code in to buzz the speaker, turn on a fan, nothing.

I could decrypt and re-encrypt existing lerdge firmware and by and large, it would work. But anything else I tried, it simply hung.  I modified a few existing functions, patching the ARM assembly. Failure. 

Then I stepped back and asked myself "Why do I think it's failing?"

I had a fairly decent database of all the operations built up in BinaryNinja, and I simply didn't see it proceed to "Checking the User UI."

It turnes out, that's because that is not in the bootloader - it's in the printer firmware. While my hardware control attempts did not work at all, the hang was because control was being passed to my code.

So I modified my Arduino Variant's startup code to immediately branch to a function, and modified that code to copy "JASON" into ram at the base. Hooked up GDB, rebooted--and there was my name.

I originally planned to reverse engineer the bootloader and make my firmware play nice with theirs, but after a lot of looking, I'm not certain that's what I should do. THe board supports DFU. If we had a complete dump of RAM, we could easily allow users to boot to something not requiring encryption, then DFU back to lerdge if they so decide.

As I have said before, locking people into MY choices is no better than locking people into other choices.

But if I can copy raw bytes to RAM, I can do something ugly ugly. Disable interrupts and copy 10k of data from the base out. Every instance where I connect the STLINK to the lerdge, the lerdge freezes after GDB attaches and never recovers, but if I can get around that, I can make a build which watches a ram location for a flag that it's ok to continue. I attach the debugger, dump 10k. Set the flag, let it copy the next 10k out, and so on, and so on. We have code executing on the lerdge. It's ugly code, difficult to work with. But if we can compile anything, we can make it work.

Discussions