1 
#include <stdio.h>
int main() {

    int number1, number2, sum;

    printf("Enter two integers: ");
    scanf("%d %d", &number1, &number2);

    
    sum = number1 + number2;

    
    printf("%d + %d = %d", number1, number2, sum);
    return 0;
}

So this is my simple C code and it has only three variables only but when I'm debugging it in disassembly the value of eax is also copying in other 'variable looked' like r/m32 addresses, I can't figure out why it is doing this. It can't be compiler generated code because I've switched off those options.

Here's the starting disassembly see the value of eax is going to variables (sum, number2, number1) but why it is going to [ebp-18h] and so on. Also these [ebp-18h] is not used in any other place in disassembly. It's just shown here. And other question is why 0CCCCCCCCC is moved into eax.

Improve this question
3
  • see the adresses like [ebp-18h] and so on... are these variables???
    – Ramesses II
    Commented Jan 31, 2021 at 8:23
  • Plus these r/m32 address aren't used in any other place but only here.
    – Ramesses II
    Commented Jan 31, 2021 at 8:33
  • Hi, would be great if you could substitute the image for a textual representation of the assembly. It's better for search engines.
    – 0xC0000022L ♦
    Commented Jan 31, 2021 at 10:44

2 Answers 2

Reset to default
3

From the looks of it that's an easy one. Yes, these are variables on the stack and the magic number in EAX is used to denote uninitialized values. Quote:

CCCCCCCC Used by Microsoft's C++ debugging runtime library and many DOS environments to mark uninitialized stack memory. CC resembles the opcode of the INT 3 debug breakpoint interrupt on x86 processors.

So in all likelihood you built a debug configuration with MSVC.

Improve this answer
7
  • So you mean the value assigned to these r/m32 addresses is due to debug configuration with MSVC? I don't find the purpose why the values are being assigned to these r/m32 addresses.
    – Ramesses II
    Commented Jan 31, 2021 at 12:26
  • 1
    @RamessesII correct. The idea behind these is in all likelihood to provide a visual help to the developer. Also in the past it likely would have caused the debugger to trip upon uninitialized data on the stack which happened to be executed in error cases (the last part is more or less a guess from me).
    – 0xC0000022L ♦
    Commented Jan 31, 2021 at 14:48
  • 1
    Well! Sir Thank you so much! 😃
    – Ramesses II
    Commented Jan 31, 2021 at 16:23
  • 1
    since post msvc 20xx iirc this pattern filling has been replaced by Security Cookies and such for example 2017 community will not emit this pattern filling is your msvc version relatively new ? or is it clang mingw ,others
    – blabb
    Commented Feb 1, 2021 at 8:34
  • 1
    I'm using Visual Studio 2017 community version
    – Ramesses II
    Commented Feb 1, 2021 at 17:55
2

if visual studio 2017 community is generating the pattern fill
then compiler option /RTCsu is being used
this also switches on Incremental linking (*.ilk files will be generated)

earlier versions of compiler used /GZ option which if used now will generate a deprecation warning

your code is also not using scanf_s a secure version of vulnerable scanf(); that should also generate a warning

shown below is the warning and pattern filling and alternate /RTC1 or RTCsu suggestion by compiler

your code

:\>type magic.cpp
#include <stdio.h>
int main() {
    int number1, number2, sum;
    printf("Enter two integers: ");
    scanf("%d %d", &number1, &number2);
    sum = number1 + number2;
    printf("%d + %d = %d", number1, number2, sum);
    return 0;
}
:\>dir /b
magic.cpp

compiled with /GZ

:\>cl /Zi /GZ magic.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27035 for x86
Copyright (C) Microsoft Corporation.  All rights reserved.

cl : Command line warning D9035 : option 'GZ' has been deprecated and will be removed in a future release
cl : Command line warning D9036 : use 'RTC1' instead of 'GZ'
magic.cpp
Microsoft (R) Incremental Linker Version 14.16.27035.0
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:magic.exe
/debug
magic.obj

disassembly showing pattern filling and other stack checking constructs like RTCCheckESP

:\>cdb -c "uf magic!main;q" magic.exe | awk "/Reading/,/quit/"
0:000> cdb: Reading initial command 'uf magic!main;q'
*** WARNING: Unable to verify checksum for magic.exe
magic!main:
00d37a70 55              push    ebp
00d37a71 8bec            mov     ebp,esp
00d37a73 83ec1c          sub     esp,1Ch
00d37a76 b8cccccccc      mov     eax,0CCCCCCCCh <<<<<<<<<<
00d37a7b 8945e4          mov     dword ptr [ebp-1Ch],eax
00d37a7e 8945e8          mov     dword ptr [ebp-18h],eax
00d37a81 8945ec          mov     dword ptr [ebp-14h],eax
00d37a84 8945f0          mov     dword ptr [ebp-10h],eax
00d37a87 8945f4          mov     dword ptr [ebp-0Ch],eax
00d37a8a 8945f8          mov     dword ptr [ebp-8],eax
00d37a8d 8945fc          mov     dword ptr [ebp-4],eax
00d37a90 6850aed900      push    offset magic!__xt_z+0x108 (00d9ae50)
00d37a95 e8b799ffff      call    magic!ILT+1100(_printf) (00d31451)
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
00d37ae0 e834b8ffff      call    magic!ILT+8980(_RTC_CheckStackVars (00d33319) <<<<<<<
00d37ae5 58              pop     eax
00d37ae6 5a              pop     edx
00d37ae7 83c41c          add     esp,1Ch
00d37aea 3bec            cmp     ebp,esp
00d37aec e8bbb6ffff      call    magic!ILT+8615(__RTC_CheckEsp) (00d331ac) <<<<<<<<<<<<
00d37af1 8be5            mov     esp,ebp
00d37af3 5d              pop     ebp
00d37af4 c3              ret
quit:
Improve this answer
1
  • Helpful! You people are really generous in sharing knowledge! Thank you 😊, This platform is really beginner friendly also! đŸ”„
    – Ramesses II
    Commented Feb 3, 2021 at 11:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.