3

I have a piece of C code as follows:

int main() {
    char buf[4] = { 'A', 'B', 'C', 'D' };
    buf[3] = 42;
    return 0;
}

When I compile it in Microsoft Visual Studio Community 2015 (debug mode, no optimisations) and debug it, I would expect the compiler to add an additional 8 bytes of 0xCC above and below my buffer as a sanity check with an instruction like sub esp,Fhor something similar before the rep stos. Instead, what I'm actually seeing is sub esp,0D0hwhich results in 196 bytes of 0xCC on the stack above the space allocated for the buffer. I'm just wondering why? It seems excessive for a canary. I've included the full disassembly of the function for reference:

 push        ebp  
 mov         ebp,esp  
 sub         esp,0D0h  
 push        ebx  
 push        esi  
 push        edi  
 lea         edi,[ebp-0D0h]  
 mov         ecx,34h  
 mov         eax,0CCCCCCCCh  
 rep stos    dword ptr es:[edi]  
 mov         byte ptr [buf],41h  
 mov         byte ptr [ebp-0Bh],42h  
 mov         byte ptr [ebp-0Ah],43h  
 mov         byte ptr [ebp-9],44h  
 xor         eax,eax  
 mov         dword ptr [ebp-8],eax  
 mov         eax,1  
 imul        ecx,eax,3  
 mov         byte ptr buf[ecx],2Ah  
 mov         eax,0B100Dh  
 push        edx  
 mov         ecx,ebp  
 push        eax  
 lea         edx,ds:[0F916E0h]  
 call        @_RTC_CheckStackVars@8 (0F91244h)  
 pop         eax  
 pop         edx  
 pop         edi  
 pop         esi  
 pop         ebx  
 mov         esp,ebp  
 pop         ebp  
 ret

Here is a screenshot of the stack (condensed a bit for space).

I've also experimented with just creating a buffer of a single byte, and the compiler allocates 0xCC bytes for this. For a forty byte buffer it allocates 0xF0. I'm just trying to make sense of this. Why is so much space being allocated?

Compiling in 32-bit mode on Windows 10 64, Microsoft Visual Studio Community 2015 Version 14.

Fado
  • 31
  • 2
  • Because you are compiling in debug mode. – Margaret Bloom Jul 14 '16 at 13:56
  • Thanks for your reply. Is there some difference between the debug modes of different versions of Visual Studio in terms of how much space they'll allocate for a buffer? I'm following along a tutorial in which the instructor asks for a 40 byte buffer and the compiler allocates 48. When I ask for a 40 byte buffer my compiler allocates 240. We're both compiling in debug mode. I'm just trying to account for the discrepancy. – Fado Jul 14 '16 at 14:07
  • The compiler always fulfills the ABI alignment (16 bytes for x86_64) for the stack pointer (that explain the use of 48). Plus, in debug mode, the compiler may allocate more space for the debugger to use or just because that would made the code of the compiler easier to maintain. – Margaret Bloom Jul 14 '16 at 14:21
  • I see. Okay, thanks for your help! – Fado Jul 14 '16 at 14:24
  • 1
    You are building your program to support Edit+Continue, more stack is allocated to leave space for local variables that you *might* add while you debug. And the /RTC debugging option initializes variables to 0xcc to help you diagnose uninitialized variables and buffer overruns. – Hans Passant Jul 14 '16 at 15:10
  • That makes sense. Thank you. – Fado Jul 14 '16 at 15:25
  • 2
    See also: http://stackoverflow.com/questions/224500/, http://stackoverflow.com/questions/370195/, http://www.codeguru.com/cpp/w-p/win32/tutorials/article.php/c9535/Inside-CRT-Debug-Heap-Management.htm (BTW, analyzing the assembly code emitted in debug builds is basically a waste of time. All kinds of strange things happen to facilitate debugging that you probably don't need to worry or care about unless you are writing debug tools. If you're interested in assembly, analyze optimized builds. There is a lot less noise, and the signal is far more interesting.) – Cody Gray - on strike Jul 14 '16 at 16:16

0 Answers0