I have this disassembled code generated by MSVC++ 2010. This code is generated everytime i do a function call. This code is placed right after the function finishes saving all the volatile registers onto the stack and right before executing any code inside the function. All i can see is that it tries to save a copy of certain values from one place to another but what is the point of it?

009A13FC  lea         edi,  
009A1402  mov        ecx,3Bh 
009A1407  mov        eax,0CCCCCCCCh 
009A140C  rep stos    dword ptr es: 
Posted on 2011-07-22 02:23:14 by banzemanga
It is initializing some variable or variables (which are defined as Locals in this case, so exist in the Stack Frame of the procedure) to a default value, in this case it appears to be a "canary value" to indicate that these variables have not yet been set to a legal value, ie "have not been touched".
It's quite unlikely that the value CCCCCCCCh would ever be generated accidentally  - the odds are one in 4.3 billion, roughly.
This is typical behavior for a Debug build, to set things to 'some known value' at the start of a run.
Some compilers ALWAYS do this - the idea is that there is some runtime debugger in the background who is watching for values who got changed or did not change so they can update their debugging context and/or debugger gui elements.
Over time, you'll end up seeing a lot of these 'canary values'... programmers have a sense of humor:

0xDEADBEEF
0xF00DF00D
0x05318008 (boobies, upside down and backwards)
etc etc
Posted on 2011-07-22 03:12:14 by Homer
Thanks. You were right about generating values for debugging. All those lines of codes disappeared when i compiled in 'release' mode. Your explanation about watching values also made sense. And i liked the canary values you presented. XD
Posted on 2011-07-22 05:04:28 by banzemanga
Somewhat related: You'll find 0xCAFEBABE used within Java  ;)
Posted on 2011-07-22 05:53:36 by p1ranha
I should have noticed straight away since I've seen CC so many times.
This is the opcode for INT 3 (cpu step breakpoint).
So if somehow we try to execute code in memory filled with that value, it would trigger a break in the debugger, at that point. I guess this doesn't really apply to modern operating systems, it's one of those relics of the days when code could run from anywhere in memory without any effort.

A lot of compilers use this as a filler/padding between procs in the exe, rather than putting zeroes in there, I guess they just shove CC everywhere and wait for the user's code to run into one :D
Posted on 2011-07-22 08:26:39 by Homer