0

I wrote a simple program on my STM32F4 Disco MCU which only turns a LED on, and I am trying to RE my compiled binary. After decompiling the binary, I started my analysis at the first instruction set and treated it like a main function because it calls the other subroutines in the program. These subroutines are comparing, adding, subtracting, ... memory from addresses in the Flash, SRAM, or RAM. Example:

LDR             R1, =0x80003EC  // r1 = 0x80003EC
LDR             R2, [R1]        // r2 = 0x80003EC
LDR             R3, [R1,#4]     // r3 = 0x80003F0
ADD.W           R4, R1, #0xC    // r4 = *(0x8000404) + 12
LDR             R0, [R1,#8]     // r0 = 0x80003F4

In the example above, the content of R1 (memory address 0x80003EC) is getting 12 added to it and stored in R4 but I have no idea what value resides in that memory address (0x80003EC)! The program continues to use the mysterious value stored at 0x80003EC. Example:

LSR             R0, R1     // r0 << r1

The cycle of referencing unknown numbers keeps continuing. Without knowing the original value, there is no way to figure out the logic flow. All I see is mathematical operations to unknown numbers and flow control that is determined from the operations.

How can a program like this be reverse engineered? Is there a way to view the original values of memory?

2
  • 1
    You have the indexed/non indexed addressing wrong. LDR R2,[R1] means R2=*R1, not R2=R1. LDR R3,[R1, 4] isn't R3=R1+4 but R3=*(R1+4) (if you ignore the pointer scaling C does). And ADD.W R4, R1, #0xC is R4=R1+12, no pointer here. Jul 21 '16 at 15:45
  • I apologize, I know that LDR dereferences the memory address but I did not communicate it properly in my comments. Thanks for pointing it out.
    – Tyler
    Jul 21 '16 at 15:50
0

Most likely, your program is intended to be loaded at 0x80000000, has a size of more than 1004 bytes (0x3EC = 1004 decimal), and the values at that location are intended to be initialized from the data section of your program when your program starts.

Also, there could be some hardware at that specific address but that's unlikely seeing how those addresses seem to contain pointers.

A third possibility is that your OS, whichever you're using, puts some global information at those locations when it loads your program.

To know which of those possibilities is correct we'd need more information about your hard- and software, but i strongly tend to the first possibility.

1
  • I looked at 0x0800 03E8 in IDA and found it was mapped to 0x1000 0000 which can be several things like CCMDATARAM_BASE, AHB2PERIPH_BASE, ADC_CR2_EXTEN_0, or GPIO_MODER_MODER14_0 etc. (it's probably not GPIO_MODER_MODER14_0 because I used GPIO 12). I will do some further investigation. Thanks for the help!
    – Tyler
    Jul 21 '16 at 16:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.