Background
Finally, with some rare free time and a long-lost passion, I quickly got to work. This is also a preliminary experience, so the goal is simply to dump the program and perform basic disassembly.
Toolset Introduction
Software Part
-
OpenOCD
Open On-Chip Debugger, a well-known open-source hardware debugger.
Supports various debuggers like (St-link) and (jlink) that comply with JTAG standards.
Supports multiple MPU debugging, as long as they are mainstream (the STM32F1x used this time already has a configuration file by default).
Here is the download link for the configuration file, where you can choose different mpus:
http://openocd.zylin.com/
-
Arm-none-edbi-*
The toolchain used for ARM bare metal (note that it is none, not linux).
This mainly provides the RunTime for debugging.
-
gdb
GDB, the GNU Project debugger, a famous open-source debugger.
This is used to replace OCD debugging, as it is much more professional.
While the functions we need can be achieved by OCD, using GDB is still much more convenient.
Hardware Part
Since this is also a preliminary attempt, I directly found a ZhiDian YuanZi’s battleship development board (we will be using the JTAG debugging port, which is already connected on the development board).
-
Battleship F1 Development Board * 1
We are using the STM32F1X series MPU, which is a crucial model as it determines the addresses we need to dump.This way we can find flash and sram, etc.
-
Jlink * 1(of course, a domestic imitation)
As long as it works, this one is from Taobao, simple and brutal, widely used, and everyone has one, roaming the rivers and lakes.
Getting Started
Connect everything that needs to be connected (power, jlink, etc.)
Run OCD
openocd -f interface/jlink.cfg -f target/stm32f1x.cfg
#Note not to reverse the connections
The two ‘f’ here specify the configuration files, which are standard for common devices. If they are not present, you can download them from the link above (this is not the full path, but relative to the ocd installation directory).
After running, the effect is as shown in the picture:
Once displayed like this, it indicates that the debugger is connected normally and has entered debug mode.
OCD Commands
After successfully intervening in JTAG, OCD will return a tty console on port 4444, and we can directly telnet into it.
telnet localhost 4444
#Or the universal NC can also be used
#nc -t localhost 4444
This will return an OCD debugging session.
Now we have control of the CPU (help command provides a lot of options, but I won’t elaborate here).
Since we want to dump the firmware, we just need to run it and extract the memory and flash data.
halt
# Execute the halt command (pause the CPU)
GDB Attach
In fact, using OCD directly can achieve the effect, but using GDB as an assistant makes the operation easier (you can use TAB).
gdb # First run GDB
(gdb) target remote localhost:3333
After executing, the GDB attach is complete (now we have obtained the CPU shell and can do whatever we want).
DUMP (Important)
Finally, we arrive at the most crucial step, which is the firmware dump operation.
The most important thing we need is the memory mapping diagram.
This is like our map, telling us where there is data and what things are located where. (Here we need to refer to the chip manual)
In the manual’s fourth section, Memory Mapping:
(The image is quite large, only showing the required part)
The areas we need to dump are:
-
Flash (where the code is stored)
-
SRAM (where interesting things are generated during runtime)
So by checking the mapping diagram, we can obtain the information:
-
The mapping address for flash is 0x08000000 ~ 0x0807ffff (512KB)
-
The mapping address for sram is 0x20000000 ~ 0x2000ffff (64K)
So below we just need to dump them in gdb:
dump binary memory 32_sram.bin 0x20000000 0x2000ffff
dump binary memory 32_flash.bin 0x08000000 0x0807ffff
The above commands dump the memory and flash data in binary format:
Check the files, and the size will be our storage space.
At this point, the DUMP is complete.
Afterword
This is just a preliminary reverse engineering effort; analysis is key.
After obtaining the flash and sram data, use IDA for operation (this is true reverse engineering).
– End –
KanXue ID: LinHaiN
https://bbs.pediy.com/user-753076.htm
This article is originally by LinHaiN from KanXue Forum
Reprint must indicate the source from KanXue community
Recommended Popular Technical Articles:
-
Meterpreter Technical Principles: Payload Execution
-
Overview of Critical Windows Kernel Data Structures (Part 1)
-
OD CE Data Retrieval Summary (Part 2)
-
OD CE Data Retrieval Summary
Official WeChat ID: ikanxue Official Weibo: KanXue Security
Business Cooperation: [email protected]