Why is the stack filled with 0xCCCCCCCC

2019独角兽企业重金招聘Python工程师标准>>>

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.

assembly disassembly

asked Jul 14 '13 at 22:27

Volatile

354312

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

See the answers to stackoverflow.com/questions/127386/… 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

show 7 more comments

投票最多答案：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.

【相关链接】

debugging - In Visual Studio C++, what are the memory allocation representations? - Stack Overflow
http://stackoverflow.com/questions/127386/in-visual-studio-c-what-are-the-memory-allocation-representations

Win32 Debug CRT Heap Internals  （太繁琐了，编译器真的不容易啊！！）
http://www.nobugs.org/developer/win32/debug_crt_heap.html#table

总结：

1. 在C/C++编译器生成的语句中，可能包含一些并不是源代码中的语句对应的汇编语句，也就是说C++语言编译生成的汇编代码，可能一些汇编代码并不是程序员的写的代码生成的，而可能是编译器为了缓冲区溢出检测、或者其他原因（如安全、代码混淆，防止逆向工程）添加的代码。

2.编译器做的许多事情，并不是我们可以从源程序代码中找到的，它可能是为了提高程序的安全性，可靠性，以及检测程序中可能存在的bug而添加一些代码。比如为了检测缓冲区溢出bug，它使用了0xcccccccc这样的magic number,

下面是其他一些计算机程序中用到的magic number:

http://en.wikipedia.org/wiki/Magic_number_(programming)

* 0xABABABAB : Used by Microsoft's HeapAlloc() to mark "no man's land" guard bytes after allocated heap memory
* 0xABADCAFE : A startup to this value to initialize all free memory to catch errant pointers
* 0xBAADF00D : Used by Microsoft's LocalAlloc(LMEM_FIXED) to mark uninitialised allocated heap memory
* 0xBADCAB1E : Error Code returned to the Microsoft eVC debugger when connection is severed to the debugger
* 0xBEEFCACE : Used by Microsoft .NET as a magic number in resource files
* 0xCCCCCCCC : Used by Microsoft's C++ debugging runtime library to mark uninitialised stack memory
* 0xCDCDCDCD : Used by Microsoft's C++ debugging runtime library to mark uninitialised heap memory
* 0xDEADDEAD : A Microsoft Windows STOP Error code used when the user manually initiates the crash.
* 0xFDFDFDFD : Used by Microsoft's C++ debugging heap to mark "no man's land" guard bytes before and after allocated heap memory
* 0xFEEEFEEE : Used by Microsoft's HeapFree() to mark freed heap memory

上面的这类现象用stackoverflow中一个人的话说就是：

转载于:https://my.oschina.net/ray1421/blog/714709