Understanding memory locations

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?

• 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. Jul 21 '16 at 15:50