Half Close/Half Open projects – Part1

By | May 19, 2021

I recently bought a test device being sold and advertised as open source hardware and software. Out of curiosity I started looking at the firmware source and I got a strange feeling… some of it just didn’t make sense. Went on discord and the support forum and the answers and explanations given only made me more suspicious that something fishy was going on.

After making the project owners know that I was going to get to the bottom of this I was threatened with some copyright bullshit. Not because of that but because I don’t think that is relevant I will not name the project and will redact the information which could be used to identify it.

The hardware

Like many other projects this is using an STM32F103 microcontroller…well a chinese clone of it. The reduced availability of the “real deal” seems to have caused a clone market boom. Together with the microcontroller the usual power conditioning devices are used, a TFT with touchscreen, a couple of buttons and some application specific IC’s. All the schematics are published and as far as I can see they are accurate.

The firmware

The firmware is beautifully written in C++ and is also available on gitHub. It uses the fancy C++14 “style” which finally forced me to read/learn about it. The project uses a bootloader which source is also available. However a version of it is distributed on the forums and discord as a binary blob “signed” for each given hardware ID…hum?…wtf…

Having inquired why this is the explanation was that this was to prevent clones and that the bootloader contained factory calibration for each device. This didn’t make sense to me, not the clone part, but the part that each cheap device was calibrated at factory, that is just too expensive for a cheap device like this.

The motivation

I don’t like being lied to or underestimated, and having a closed box while being told I can’t open it just makes me want to tear the thing up. Also reverse engineering software is a always a good intelectual chalange.

The process

The process of reverse engineering the bootloader binary blob, understanding what it does, how it correlates with the hardware ID and how it interferes with the firmware will require the use of ghidra, IDA pro, qemu, GDB and some coding. At the time of writing this the process is over and I already have all the answers I was looking for. The next posts will describe in some detail all of the steps I needed to accomplish the task, stay tunned.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.