Read out Start-Up RAM values

[an]

Posted on October 12, 2012 at 11:28

Hey there,

I am pretty new to micrcontrollers and such. I recently bought a STM32VL Discovery, which I am programming with CoCoox IDE. My goal is to read out the start-up values of internal RAM. By start-up values I mean the values of RAM cells just after the power-up of the device when no other application interferred with the ram. Is this possible somehow? Could you guys guide me to some literature or give me some hints? Thanks in advance! #describe-the-goal-not-the-step

[Tesla DeLorean]

Posted on October 12, 2012 at 13:18

Why?

printf(''%08X\n'', *((unsigned long *)0x20002000) ); Read it like any other arbitrary memory location, with pointers. You could read memory using assembler in Reset_Handler()

[Andrew Neil]

Posted on October 12, 2012 at 15:46

''Is this possible somehow?''

Sure, it is possible - but what is the point? As clive1 said, why would you want to do this? If it's just a matter of curiosity, why not just use your debugger to inspect the memory...?

http://www.catb.org/~esr/faqs/smart-questions.html#goal

[an]

Posted on November 13, 2012 at 16:38

Hey Guys,

sorry for not responding for such a long time. Well my task is to read out the unitialized values of SRAM to measure the degree of entropy of these uninitialized data. It might sound a little bit pointless but thats what I am supposed to do. Right now I am developing on windows using CoCoox IDE. I set a breakpoint right at the beginning ofvoid Default_Reset_Handler(void) in filestartup_stm32f10x_md_vl.c as I could not figure out an ''earlier'' place to inspect SRAM. I can't use printf() right now, since this throws some errors in CoCoox IDE. However, using the breakpoint plus usint ST-Link Utility, I can read the values from 0x20000000 to 0x20002000 which is supposed to be the RAM. However, it seems like at this point the SRAM has already been written to, since most of the bytes are exactly the same for every single trial. I assumed to see at least a minimum entropy. Is there another possiblity to access SRAM before any initialization of the RAM values? I thought of using ASM code but I don't know at which position in code it needs to be executed. Thanks for your help, guys!

[frankmeyer9]

Posted on November 13, 2012 at 17:36

Is there another possiblity to access SRAM before any initialization of the RAM values? I thought of using ASM code but I don't know at which position in code it needs to be executed.

The method to adapt startup_stm32f10x_md_vl.c seems right. Not sure if there are assembler startup files involved in Coocox. But you might ask ST if there is any entropy involved at all. A power-on from zero voltage state might ensure an ''initialized'' RAM state by design.

[Tesla DeLorean]

Posted on November 13, 2012 at 17:40

.section .text.Reset_Handler
.weak Reset_Handler
.type Reset_Handler, %function
Reset_Handler:
; <<< LIKE HERE - ADD CODE TO DUMP RAM VIA USART, WITHOUT USING RAM

/* Copy the data segment initializers from flash to SRAM */
movs r1, #0
b LoopCopyDataInit
CopyDataInit:
ldr r3, =_sidata
ldr r3, [r3, r1]
str r3, [r0, r1]
adds r1, r1, #4
LoopCopyDataInit:
ldr r0, =_sdata
ldr r3, =_edata
adds r2, r0, r1
cmp r2, r3
bcc CopyDataInit
ldr r2, =_sbss
b LoopFillZerobss
/* Zero fill the bss segment. */
FillZerobss:
movs r3, #0
str r3, [r2], #4
LoopFillZerobss:
ldr r3, = _ebss
cmp r2, r3
bcc FillZerobss
/* Call the clock system intitialization function.*/
bl SystemInit
/* Call the application's entry point.*/
bl main
bx lr
.size Reset_Handler, .-Reset_Handler

[M0NKA]

Posted on November 14, 2012 at 13:48

Hi,

Why don't you just use the RND HW provided for whatever crypto you are trying to do ? Not sure how good it is, never even read that section as i don't need that, but should be the easiest way. The Cortex core seems bit weird compare to older ARM stuff. The way code execution is passed via table at 0x00, then the hidden save/restore context for interrupts. I will not be surprised if the core is clearing the RAM on startup before even passing the execution to the 0x04 ptr. BR

[Tesla DeLorean]

Posted on November 14, 2012 at 15:56

I will not be surprised if the core is clearing the RAM on startup before even passing the execution to the 0x04 ptr.

It would surprise me. All the evidence suggests it doesn't.

[an]

Posted on November 14, 2012 at 15:58

@clive1: Your s-file should be equivalent to the c-file I am currently putting my code into. The c-file can be seen here http://pastebin.com/evWJtzE0. I put my code in line 186, which should have the same effect.

@M0NKA, what do you mean with RND HW? Do your refer to something like a random number generator? Well, the task is simply to measure the entropy. If there is not enough entropy in it (even though some papers report a sufficient entropy to succesfully pass NIST RNG tests) we still want to extract some kind of ''characterisics'' of the values. Regarding code execution via table I think I have to read a lot more to get some background info. Seems like not too many people tried to do this with an stm32 (probably because this sounds pointless to many :). All i can say is, that 99% of all bits are the same on each startup trial. This seems like I am accessing SRAM after some initalization routine. I guess I will have to search for another way to get around this.. Thanks so far for the help!

[M0NKA]

Posted on November 14, 2012 at 16:01

The chip could be flashed from blank via USB, so i assume there is some kind of

bootrom with USB/USART drivers. The actual reset is probably sent to the bootrom, boot pins checked, and reset vectors then read, and execution passed ? Or the bootrom is not even mapped without boot request, the actual logic reads the reset vector and passes execution to flash ?