2

I am doing the CMU bomb challenge and am stuck at ( phase 6 ) .

While debugging using GDB I couldn't understand two things , please look into the screenshots for clarity.

Doubt 1 :

As you can see the current instruction to be executed is 

mov    eax,DWORD PTR [edx+ecx*1]

and the value in registers :

EDX : 0xc
ECX : 0x1

Before Execution : 1st Screenshot

Before Execution

So after calculation the value moved should be 0xd , however it is 0x4 , as you can see in the 2nd screenshot below.

After Execution : 2nd Screenshot

After Execution

Doubt 2 :

In the above screenshot ( where it's marked as 2 ) , what is eiz, as gdb is showing ?

IDA disassembly of the same 2 instructions

IDA Disassembly



Update :

After some comments although Doubt 2 was cleared but raised some basic doubts about register addressing

Doubt 3:

Assume :
edx = 0xffffd120 and [edx] = 2
ecx = 0xffffd130 and [ecx] = 3
[0x4ffff15e0] = 7

mov    eax,DWORD PTR [edx+ecx*4]

Is the above expression equivalent to this : eax = [edx] +[ecx]*4 (i.e. 2 + 3*4 = 0xd ) ?

Or to this : eax = [edx + ecx*4] ( i.e. 7 )
i.e. 0xffffd120+0xffffd130*4 = 0x4ffff15e0 ==> [0x4ffff15e0]

jame
  • 328
  • 3
  • 11
  • 4
    EIZ is a pseudo register. It simply evaluates to zero. The `lea esi,[esi*eiz*1+0x0]` in fact is just along _NOP_ that doesn't do anything except load ESI into itself. This type of NOP exists to align the top of a loop to a 16-byte boundary for performance reasons. You'll notice that the next instruction is on an address `0x8048e30` evenly divisible by 16 (lower 4 bits of address are 0) – Michael Petch Oct 26 '17 at 07:34
  • 3
    `mov eax,DWORD PTR [edx+ecx*1] ` takes what is at memory address pointed to by `edx+ecx*1` and places the 32-bit value into _EAX_ – Michael Petch Oct 26 '17 at 07:38
  • 1
    The `ecx` in first step is `0xffffd130`, not `0x01`. That `1` looks as value which is stored in memory at that address, but I would prefer to see memory view to be sure, which bytes are stored in memory. By a guess I would say it shows `dword` value. If it would be 1, the `mov eax,[edx+ecx*1]` would try to fetch value from address `0x0d`, which would any modern OS in user-mode cause segfault due to invalid memory access (the low addresses around zero are off limits for reading). – Ped7g Oct 26 '17 at 07:40
  • 2 totally separate questions, but now that SO supports multiple duplicate targets, we can take care of them both. (You apparently were thinking that `mov eax, [edx + ecx]` did `eax=edx+ecx` instead of a load.) – Peter Cordes Oct 26 '17 at 08:25
  • Thanks @PeterCordes. Looked into those two links , seems to answer my question but not totally ( second doubt was answered perfectly ) – jame Oct 26 '17 at 08:39
  • @MichaelPetch do you mean value at **0xffff1d30 + 0xc i.e. [0xffff1d3c]** ? – jame Oct 26 '17 at 08:44
  • 1
    Yes, exactly `[0xffff1d30 + 0xc]` (EDX+ECX) is the memory address that the value was read from, and according to the output that value happened to be 4 (as that was loaded into _EAX_) – Michael Petch Oct 26 '17 at 08:48
  • @MichaelPetch Thanks a lot – jame Oct 26 '17 at 08:48
  • doubt3: no, that's not how x86 addressing modes work. It's an address calculation, not multiple loads. I added another duplicate to the list. – Peter Cordes Oct 26 '17 at 08:51

0 Answers0