18

I'm currently disassembling some small C programs made in Visual Studio 2012 Express, and i've noticed a trend amongst the binaries.

The first set of instructions executed in the main function are always:

SUB ESP,154                       ; Doesn't have to be 0x154.
.....
.....
.....
LEA EDI,DWORD PTR SS:[EBP-154]
MOV ECX,55                        ; Also doesn't have to be 0x55.
MOV EAX,CCCCCCCC
REP STOS DWORD PTR ES:[EDI]

So, why does the machine fill the stack with this 0xCCCCCCCC? I've read that it is used by VC++, or something, as a mark for uninitialized space?

Then let's say I am going to put something inside my buffer... The compiler or processor decides to put it at some random point inside this space, but I can't see why it would put it there...

EBP-90   > CCCCCCCC  ÌÌÌÌ
EBP-8C   > CCCCCCCC  ÌÌÌÌ
EBP-88   > CCCCCCCC  ÌÌÌÌ
EBP-84   > 00000001  ...  ; Why this place?
EBP-80   > CCCCCCCC  ÌÌÌÌ
EBP-7C   > CCCCCCCC  ÌÌÌÌ
EBP-78   > 41414141  AAAA ; Why this far from both the top and bottom of the stack?
EBP-74   > CCCCCC00  .ÌÌÌ
EBP-70   > CCCCCCCC  ÌÌÌÌ
EBP-6C   > CCCCCCCC  ÌÌÌÌ

And...

EBP-14   > CCCCCCCC  ÌÌÌÌ
EBP-10   > CCCCCCCC  ÌÌÌÌ
EBP-C    > 00000000  ....  ; Why here?
EBP-8    > CCCCCCCC  ÌÌÌÌ
EBP-4    > 7EA7D069  iЧ~  ; I think this is some stack cookie stuff.
EBP ==>  >/0017FEA8  ¨þ.   ; Saved EBP.

Granted the 1 and 0 dwords are stored here is because of some if statements, but i'm simply wondering why they are placed where they are. If there is any logic behind it.

Thank you.

Volatile
  • 677
  • 2
  • 8
  • 17
  • Optimized or debug build? – Kerrek SB Jul 14 '13 at 22:29
  • @KerrekSB I think it's in debug actually... I've never actually noticed that, now that you pointed it out. – Volatile Jul 14 '13 at 22:34
  • If you were a debugging compiler, could you imagine any use such a "predictable pattern" might have? – Kerrek SB Jul 14 '13 at 22:36
  • @KerrekSB So how would I know where to put stuff? – Volatile Jul 14 '13 at 22:41
  • 1
    See the answers to http://stackoverflow.com/questions/127386/in-visual-studio-c-what-are-the-memory-allocation-representations for more information about 0xcccccccc, and from the wikipedia link in the accepted answer: "CC resembles the opcode of the INT 3 debug breakpoint interrupt on x86 processors." – Logan Pickup Jul 14 '13 at 22:45
  • @LoganPickup Yes, that was the one I read about marking uninitialized space. – Volatile Jul 14 '13 at 22:49
  • @Volatile: What has that to do with anything? You put stuff where the stack pointer tells you to put it... – Kerrek SB Jul 14 '13 at 22:50
  • @KerrekSB I don't understand what you mean by where the stack pointer tells me to put it. I'm not pushing the data onto the stack, i'm overwriting random areas marked by the debugging magic number 0xCCCCCCCC. – Volatile Jul 14 '13 at 22:55
  • What's not to understand? Your code pushes 154 bytes onto the stack and fills them with the all-"C" content. So you can now use 154 bytes above ESP for local storage... (Your example actually only fills up 55 bytes above ESP with "C"s.) – Kerrek SB Jul 14 '13 at 23:07
  • Without seeing the code you use to create your buffer, it's impossible to say why the data is at a particular position on the stack. Rest assured, though, that the compiler didn't put it at a "random" place. – Jim Mischel Jul 14 '13 at 23:26
  • @KerrekSB I understand that part. I was asking about what determines where the values, that are overwritten to the stack (like AAAA), go. Also, i'm pretty sure my example fills up 55 `DWORDs` with C, and not 55 bytes. – Volatile Jul 14 '13 at 23:43
  • @Volatile: You're right, 55 dwords, i.e. 220 bytes. Weird, though, since that's bigger than the stack -- perhaps there's some other kind of red zone or reserved area above the usable stack. – Kerrek SB Jul 15 '13 at 08:32
  • Possible duplicate of [When and why will an OS initialise memory to 0xCD, 0xDD, etc. on malloc/free/new/delete?](https://stackoverflow.com/questions/370195/when-and-why-will-an-os-initialise-memory-to-0xcd-0xdd-etc-on-malloc-free-new) – phuclv May 06 '18 at 16:27

2 Answers2

30

You are just seeing the code that's generated by the MSVC compiler when you use the /RTC option. Which enables runtime checks, turned on by default in the debug build. The value 0xcccccccc is magical, it is very good at crashing your program when you use an uninitialized pointer. Or generate a weird int value. Or crash your code when it goes bananas and start to execute data as though it is code. 0xcc is the x86 instruction for INT 3, it invokes a debugger break.

The "why this place" is part of the diagnostics you get from /RTC. It make the compiler allocate local variables with extra space between them. Filled by that magical value. Which makes it very simple to diagnose stack corruption caused by buffer overruns, it just needs to check if the magic values are still there when the function returns.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
4

I can not speak for Visual Studio, but some environments in which I've coded have deliberately filled the stack with a predetermined value (such as 0xcccccccc). This was done so that the stack could be scanned (starting from the bottom) to determine how much had not been used. On embedded systems where the amount of memory can be rather limited, this is rather useful during development so that the memory usage can be optimized.

Hope this helps.

Sparky
  • 13,505
  • 4
  • 26
  • 27