0

Sorry for the noob questions. So I'm given this code. From my understanding it adds two values, however I'm a thrown off the mov [ebp-1], al instruction. What is currently at that address on the stack is the previous value of ecx which is unknown, so does this instruction change the lower byte of the previous value of ecx?

push 0ffffff80h
push 0ffffffffh
call Secretfunc
add esp, 8
mov [ebp - 1], al
nop
Secretfunc
push ebp
mov ebp, esp
movsx eax, [ebp+8]
movsx ecx, [ebp+12]
add eax, ecx
mov [ebp-1], al
mov al, [ebp-1] ; declare a char in c for this
mov esp, ebp
pop ebp
retn

I was also wondering if anyone knew of a good tutorial/manual for inline assembly on visual studio? Most I found were on gcc and not VS, and the Microsoft manual wasn't very helpful.
My professor wants me to turn this code into an inline assembly code on VS. Are there any basic rules that differentiate inline assembly from the code I am given above?
I tried turning secretfunc into a C function with -1, and -128 as its parameters I put all the code below Secretfunc into __asm{...} inside the Secretfunc function I made in C, but that left me not knowing what to do with the code after we return from call Secretfunc
Any information is appreciated.
Thank you

Monica
  • 33
  • 5
  • 3
    I'd recommend *not* using MSVC inline-asm for anything. It's poorly designed and [not well-implemented](https://stackoverflow.com/questions/3323445/what-is-the-difference-between-asm-and-asm/35959859#comment59576185_35959859), and not even supported in 64-bit mode. But if you have to for a class, then I guess you're stuck with it. – Peter Cordes Oct 09 '17 at 03:55
  • I think what your assignment is asking you to do is to change `[ebp-1]` to `my_var` (and get rid of the `push ebp / mov ebp, esp` part: let the compiler do that). Compiling it will probably give you an EBP-relative addressing mode, but it will be the compiler's choice. – Peter Cordes Oct 09 '17 at 03:57
  • 1
    This seems super-weird, because the code in the question falls through into `Secretfunc` after the call to it returns. Also, `Secretfunc` never pops `ebp`, so the `ret` will use the caller's value of `ebp` as the return address. It's basically totally broken code. Also, `[ebp-1]` is below `esp`, so your function doesn't own that stack memory. Something could clobber it asynchronously. (e.g. a signal handler). – Peter Cordes Oct 09 '17 at 04:00
  • Thank you for pointing that out! I fixed my original post. – Monica Oct 09 '17 at 04:11
  • Basic rules: I haven't used MSVC asm, just GNU, but I think don't change `ebp` or `esp`. Or if you do, keep in mind that it will break things like `mov al, my_C_char_variable`, because the compiler generates addresses for those based on the stack frame it created. (Or it's possible that MSVC looks at push/pop instructions in your asm... But more likely it always uses EBP-relative addresses, so you could push/pop, but make sure EBP has the compiler's value any time you want to access a C variable. Or better just don't touch it.) – Peter Cordes Oct 09 '17 at 05:00
  • Inline assembly in MSVC and gcc has absolutely nothing in common. That's the usual disadvantage of coding in assembly language. The starting point for MS documentation is [Inline Assembler](https://msdn.microsoft.com/en-us/library/4ks26t93.aspx), which of course assumes that you already know the x86 instructions (or have an Intel manual for that). It is not a general tutorial on assembly language. And like Peter says in his first comment, you do this because your professor makes you. It is not useful for anything else. – Bo Persson Oct 09 '17 at 10:38
  • One of the problems is, why does professor want to use you broken code (inside `Secretfunc` the `[ebp-1]` usage without `esp` adjusted to cover such local stack space usage). It's basically undefined behaviour, so you can convert that into inline asm just by returning random `char` value from `Secretfunc` (+empty asm {}). It will act weird lot more often then original code (as that would demonstrate UB only in extraordinary rare situation, mostly working as "expected"), but it's not clear why you are being taught how to produce UB-incorrect code, especially if you are new to x86 asm. Ask them? – Ped7g Oct 09 '17 at 15:17
  • That said, the `movsx eax, [ebp+8]` is already ambiguous. That can be assembled into two different instructions, either `movsx eax, word ptr [ebp+8]` using 16 bits of memory as source value for sign-extension into 32b value or `movsx eax, byte ptr [ebp+8]`, using only 8 bits of memory as source value. That's another thing which would not pass through source code review, and would have to be fixed by using explicit syntax. Obscure source code depending on implementation/implicit behaviour is IMO "code smell", and shouldn't be taught at all (or only as example of how-to-not-do-it). – Ped7g Oct 09 '17 at 15:22

0 Answers0