Reversing microcontroller firmware
Today we will talk about reverse engineering, but not about software reverse, but about hardware reverse. As the term suggests, reverse engineering is the process of disassembling a designed product or device into its elementary engineering components. The motivation for such an action can vary: from competitive analysis and detection of patent violations to restoration of the design of a project whose source code has been lost. However, they all involve a need or desire to understand how a product or device was created. The word “how” is used here in its broadest sense, including questions about “what was used to create it,” “where each element is located,” “when certain events occur,” etc.
Reverse engineering in the electronics world can take many forms, from software to hardware, from black box to intrusive use. Hardware reverse engineering can be as simple as disassembling a product to identify internal components and circuit board circuits, or as complex as removing semiconductor circuits and testing on site.
Speaking of electronics reversal, we can add to the above list of motives the need to research a finished device with the aim of producing a similar one (a very hot topic in the last two years), as well as reversing devices to solve various information security issues. In particular, we may need to reverse a suspicious spy device found in the office. Of course, devices planted by specialists from serious organizations are unlikely to allow themselves to be so easily, let alone reversed, but simply removed, since they will simply self-destruct. But if we did manage to disassemble such a device, it would be very interesting for us to try to find out what it does. And for this we need to read the firmware from the existing microcircuits.
Of course, many devices have ports on the board for serial connection and debugging. However, we will consider a situation where the firmware can only be read from a microcontroller or chip directly. You can't count on help from the debugging ports on the board.
Getting to know the soldering gun
In order to read the firmware from the chip, we obviously need to physically connect to it. Depending on the form factor, you can try to hook onto the microcircuit directly on the switched off board using special pliers with contacts.
Such tongs are connected to the microcircuit and to the programmer, with which you can read the firmware. However, in practice, I was never able to read the firmware using such a device.
And in this case, only the most hardcore option remains – desoldering the microcircuit from the board. Of course, this option requires some preparation. Again, depending on the form factor of the chip, you can try to desolder it using a regular soldering iron. However, it is not so easy to heat up several legs, so it is better to use a special device called a soldering hair dryer. Carefully holding the microcircuit with tweezers, we heat it with a stream of hot air, while trying not to touch other parts too much, until we can separate the microcircuit from the board.
Let the resulting part cool slightly and place it in a programmer, for example in this MiniPro:
A little offtopic:
Once I needed to upload OpenWRT firmware to a cheap router, but due to the wrong choice of firmware, I so-called “bricked” the hardware. Of all the treatments offered on the Internet, nothing helped. In particular, attempts to connect to the board via the debug port failed. In order to still try to revive the device, it was necessary to unsolder the external non-volatile memory module (EEPROM) and reflash it. To solve these problems, a soldering iron and a programmer came in handy. As a result, I reflashed the memory module and the device came to life under the new firmware. So you shouldn’t consider the process of desoldering a microcircuit from a board an extremely difficult task.
So, we got the trophy, what to do next?
Protection methods
Of course, there are various methods for protecting firmware from being read, and for the ATMega microcontrollers we are considering below, there are special protection (FUSE) bits.
Fuses in the AVR family of microcontrollers are special configuration bits (switches), by changing which (that is, setting them to 0 or 1) we can change some operating modes of the microcontroller or use any of its special features that are not available in its default configuration “.
We will not dive into this topic in detail, since there are plenty of other publications on this topic. We will assume that the authors of the device did not bother to protect the microcontroller from reading the firmware. For example, we used the Arduino IDE with default settings and the bootloader, also with default settings.
In this case, we can use MiniPro or another programmer to read the firmware from our soldered chip, or rather a microcontroller, in the case of Arduino.
But at the output we will just get a HEX file. We won't be able to convert the code back into a high-level language. Here we can draw an analogy with EXE files, which also in the general case (we do not consider .NET and the like) cannot be turned back into high-level code.
Let's reverse the firmware
In order to turn a set of code into something human-understandable (well, if Assembly can be considered a human-understandable language), we need… that's right, the IDA Pro disassembler. Free IDA Free will not help us here, so try to “buy” the Pro version somewhere.
In the IDA interface, select Binary file and then in the list the desired family of processors or microcontrollers.
We get something like this:
Next, to properly organize the code presentation, we indicate the creation of a ROM Section, starting from address zero:
In the next step, IDA asks us to select the exact model of our “stone”:
As a result, we will get something similar to the one shown in the following figure:
Next we see a set of assembly instructions grouped into procedures. Even a reader who is not very experienced in reversing can see that the assembler instructions and registers here are slightly different and differ from the Intel instructions we are already familiar with.
We will not dive into the jungle of Atmel Assembler, since there are also many quite interesting publications on this topic. And besides, you may have to deal with PIC, STM or Milandro and these MKs will have a completely different set of assembly instructions.
Conclusion
In this article we talked about how you can read the firmware from a microcontroller and how you can then convert it into assembly code. Of course, this problem is not always solved so simply, but we have considered the basic points.
You can learn more practical cases in our information security courses. More details in the catalog.
