0

I was playing with a shellcode example and put some code on the stack. Here is a relevant fragment from it, as seen in the memory view of VS2013:

Memory view:
0x0018FEB4  90 90 90 83 ec 28 eb 0b e8 66 2a 1a 75 50 e8 9d 80 18 75

Now, when I see the same code in the disassembly view, interpreted in x86 machine language, all goes as expected, except for the addresses( in little endian) I see for the call instructions (opcode E8):

Disassembly view:
0018FEB4  nop  
0018FEB5  nop  
0018FEB6  nop  
0018FEB7  sub         esp,28h  
0018FEBA  jmp         0018FEC7  
0018FEBC  call        75332927  
0018FEC1  push        eax  
0018FEC2  call        75317F64

If I change the view to disassembly with code bytes, I get the same type of delta between the address that I have written to memory and the address that gets called:

Disassembly view, with code bytes as well:
0018FEBC E8 66 2A 1A 75       call        75332927

I think I may be missing some big theoretical fact with this one, but could some one explain it to me? The addresses I wanted to call are specific function addresses from kernel32.dll, but I had to make some arithmetic on them to actually make the code execute and call the correct addresses.

octo
  • 75
  • 8
  • 2
    Pretty unclear, I'd guess that you don't realize that the CALL instruction uses a *relative* offset. 0x18fec1 + 0x75a1a266 == 0x75332927 – Hans Passant Apr 20 '14 at 17:36
  • Thank you, that was it, I hadn't taken into account the offset relative to the next instruction which CALL uses! – octo Apr 20 '14 at 19:00
  • check this question [Address of function is not actual code address][1] [1]: http://stackoverflow.com/questions/2485336/address-of-function-is-not-actual-code-address – Mohammed Abdulmonem Aug 18 '14 at 12:17

0 Answers0