IDA反汇编会为Visual Studio 2017中编译的exe生成与ASM文件完全不同的代码

Question

I compiled a simple program using Visual Studio 2017

#include <stdio.h>
int main()  
{
    printf("hello, world\n"); 
    return 0; 
}

I compile it with command line

cl 1.cpp /Fa1.asm 

This gives me assembly code that (mostly) makes sense to me

; Listing generated by Microsoft (R) Optimizing Compiler Version 19.14.26429.4 



INCLUDELIB LIBCMT
INCLUDELIB OLDNAMES

CONST   SEGMENT
$SG5542 DB  'hello, world', 0aH, 00H
CONST   ENDS
PUBLIC  ___local_stdio_printf_options
PUBLIC  __vfprintf_l
PUBLIC  _printf
PUBLIC  _main
PUBLIC  ?_OptionsStorage@?1??__local_stdio_printf_options@@9@4_KA ; `__local_stdio_printf_options'::`2'::_OptionsStorage
EXTRN   ___acrt_iob_func:PROC
EXTRN   ___stdio_common_vfprintf:PROC
;   COMDAT ?_OptionsStorage@?1??__local_stdio_printf_options@@9@4_KA
_BSS    SEGMENT
?_OptionsStorage@?1??__local_stdio_printf_options@@9@4_KA DQ 01H DUP (?) ; `__local_stdio_printf_options'::`2'::_OptionsStorage
_BSS    ENDS
; Function compile flags: /Odtp
_TEXT   SEGMENT
_main   PROC
; File c:\users\mr dai\documents\michael\study\cybersecurity\reverseengineering4beg\random\random\random.cpp
; Line 3
    push    ebp
    mov ebp, esp
; Line 4
    push    OFFSET $SG5542
    call    _printf
    add esp, 4
; Line 5
    xor eax, eax
; Line 6
    pop ebp
    ret 0
_main   ENDP
_TEXT   ENDS
; Function compile flags: /Odtp
;   COMDAT _printf
_TEXT   SEGMENT
__Result$ = -8                      ; size = 4
__ArgList$ = -4                     ; size = 4
__Format$ = 8                       ; size = 4
_printf PROC                        ; COMDAT
; File c:\program files (x86)\windows kits\10\include\10.0.17134.0\ucrt\stdio.h
; Line 954
    push    ebp
    mov ebp, esp
    sub esp, 8
; Line 957
    lea eax, DWORD PTR __Format$[ebp+4]
    mov DWORD PTR __ArgList$[ebp], eax
; Line 958
    mov ecx, DWORD PTR __ArgList$[ebp]
    push    ecx
    push    0
    mov edx, DWORD PTR __Format$[ebp]
    push    edx
    push    1
    call    ___acrt_iob_func
    add esp, 4
    push    eax
    call    __vfprintf_l
    add esp, 16                 ; 00000010H
    mov DWORD PTR __Result$[ebp], eax
; Line 959
    mov DWORD PTR __ArgList$[ebp], 0
; Line 960
    mov eax, DWORD PTR __Result$[ebp]
; Line 961
    mov esp, ebp
    pop ebp
    ret 0
_printf ENDP
_TEXT   ENDS
; Function compile flags: /Odtp
;   COMDAT __vfprintf_l
_TEXT   SEGMENT
__Stream$ = 8                       ; size = 4
__Format$ = 12                      ; size = 4
__Locale$ = 16                      ; size = 4
__ArgList$ = 20                     ; size = 4
__vfprintf_l PROC                   ; COMDAT
; File c:\program files (x86)\windows kits\10\include\10.0.17134.0\ucrt\stdio.h
; Line 642
    push    ebp
    mov ebp, esp
; Line 643
    mov eax, DWORD PTR __ArgList$[ebp]
    push    eax
    mov ecx, DWORD PTR __Locale$[ebp]
    push    ecx
    mov edx, DWORD PTR __Format$[ebp]
    push    edx
    mov eax, DWORD PTR __Stream$[ebp]
    push    eax
    call    ___local_stdio_printf_options
    mov ecx, DWORD PTR [eax+4]
    push    ecx
    mov edx, DWORD PTR [eax]
    push    edx
    call    ___stdio_common_vfprintf
    add esp, 24                 ; 00000018H
; Line 644
    pop ebp
    ret 0
__vfprintf_l ENDP
_TEXT   ENDS
; Function compile flags: /Odtp
;   COMDAT ___local_stdio_printf_options
_TEXT   SEGMENT
___local_stdio_printf_options PROC          ; COMDAT
; File c:\program files (x86)\windows kits\10\include\10.0.17134.0\ucrt\corecrt_stdio_config.h
; Line 85
    push    ebp
    mov ebp, esp
; Line 87
    mov eax, OFFSET ?_OptionsStorage@?1??__local_stdio_printf_options@@9@4_KA ; `__local_stdio_printf_options'::`2'::_OptionsStorage
; Line 88
    pop ebp
    ret 0
___local_stdio_printf_options ENDP
_TEXT   ENDS
END

However I open the exe with IDA and the disassemble spits out something completely unintelligible.

Why is this the case? Does visual studio automatically obfuscate assembly code by default? I googled but this doesn't seem to be the case. If so, how do I turn obfuscation off?

Thanks

Answer 1

main is not the entry point of you program, at this level.

The C language is an abstraction, before main can ran the runtime must be initialised .
C++ is even more complicated but the idea is the same: there is some code that is run before main (otherwise who would initialise cout for example?)

At the end of the day, all languages compile down to a binary PE, it's important to get familiar with that.

I've compiled your program in order to show how to find main .
Note however that, based on your code, I assumed you were compiling a C file while looking at the disassembly it seems you compiled a C++ file. C++ is notoriously more complex to reverse engineer.

The example below will differ from yours, mine is an x86 debug build.

---

First of all, IDA tells you where the PE entry point is in the Exports tab

If you double click it and follow the path the jmp and call instructions (there is only one path, you can't get lost) you arrive at a routine with two calls

VS generate a security cookie as the first thing and that's what the first function called does:

Note that this routine is pretty recognisable even without the IDA hints because it make very spot-on API calls, you can Google some of the function names in the picture to find the documentation.

Assessed that this is the security cookie generation routine we then get back to the previous one and enter the second call

This is the body of your program, not main but where the CRT is initialised and finalised, including calling main .
Take a look at the flow-chart in the lower left corner and see that most of the work is in the left branch (meaning that the right branch is an error condition).

main is usually called a few call s before _exit or _cexit . We then move close to these calls:

If you hover over a function call IDA will show the function code.
Functions that are a single jmp are present in the the debug build to help the debugger and are more often than not runtime functions.
The first circled function, when hovered, show a call to an "enviroment" routine, this is good since main needs the program arguments (Windows don't pass the argument to the program, there is a specific API to get them).

This looks like a call to main , the arguments match.
In fact, if we enter the call we get to main :

---

Of course, you could have found main by simply looking for the "Hello, world!" string in the "String view" ( Shift + F12 ) but in a real world scenario of reverse engineering this almost always not possible.

Making program and then reverse engineering them is a very good approach, if you have VS installed, you may have the MS DIA SDK that allows IDA to read the pdb files.
This greatly help with the reverse engineering, you can load two IDAs, one with the PDB and one without and compare.
Unfortunately, getting the MS DIA SDK may not be so easy.

Also, IDA FLIRT is a must.
It's a library of method signature, it allows IDA to recognise the runtime functions, making it very easy to focus on the application real code. It's hard to find (and harder to generate) the signature though but they are totally worth it.

---

Finally, note that debug build may be harder to reverse engineer due to the type of code generated.
If you make a release build and reverse engineer it, you'll see it's easier to get to main .