15

We are using gdb debugger to read assembly functions.

In assembly, we have the following instructions: mov 0xc(%rsp),%eax jmpq *0x402390(,%rax,8)

At memory location *0x402390 we have the value 0x8e. In register rax, we have the second integer input for this particular function (could use variable y).

From our analysis, we have deduced that this function takes in three variables (x, y, z) and that they can be found at memory location (rsp), (rsp + 8), (rsp + 12) respectively.

We would like to know what is going on in jmpq *0x402390(,%rax,8). Is it jumping to the instruction at (0x8e + rax*8)? If so, how can we find out what that instruction is called?

This is the full dump of assembler code for the function phase_3:

Full assembly function

rkhb
  • 14,159
  • 7
  • 32
  • 60
MichaelGofron
  • 1,310
  • 4
  • 15
  • 29
  • 1
    possible duplicate of [How does the jmp instruction work in att assembly in this instance](http://stackoverflow.com/questions/23418524/how-does-the-jmp-instruction-work-in-att-assembly-in-this-instance). See also [this question](http://stackoverflow.com/questions/26204974/disassembling-why-a-jmp-that-leads-nowhere/26205216) – Jester Oct 24 '14 at 11:53

3 Answers3

22

Bomb-lab right lol?

This operation jmpq *0x402390(,%rax,8) is for jumping directly to the absolute address stored at
8 * %rax + 0x402390

If you do x/16gx 0x402390 in gdb (inspect 16 "giant words" in hexadecimal starting at 0x402390) you will find an address table looks like the following:(i have a different lab so it's not the same as yours)

 0x402880:  0x0000000000400fee  0x000000000040102b
 0x402890:  0x0000000000400ff5  0x0000000000400ffc
 0x4028a0:  0x0000000000401003  0x000000000040100a
 0x4028b0:  0x0000000000401011  0x0000000000401018

Where all these addresses all point back to the a single mov operation immediately after jmpq *0x402390(,%rax,8)

Celsius_Xu
  • 321
  • 2
  • 5
  • 4
    hah it's been four years since I posted about this and almost 2 years out of college now :p – MichaelGofron Jun 21 '18 at 22:33
  • 6
    @MichaelGofron : and in all those years you never accepted an answer to this question despite the fact rkhb gave a proper answer.If you were to accept an answer, possibly others may be less inclined to add new answers years later? ;-) – Michael Petch Jun 22 '18 at 17:44
  • 2
    Yeah, but at this point I don't even remember if that was the right answer to my question now because I've lost the context of how it worked – MichaelGofron Jun 25 '18 at 16:03
15

From the GAS-manual:

An Intel syntax indirect memory reference of the form

 section:[base + index*scale + disp]

is translated into the AT&T syntax

 section:disp(base, index, scale)

where base and index are the optional 32-bit base and index registers, disp is the optional displacement, and scale, taking the values 1, 2, 4, and 8, multiplies index to calculate the address of the operand.

(https://sourceware.org/binutils/docs/as/i386_002dMemory.html#i386_002dMemory)

So you can translate jmpq *0x402390(,%rax,8) into INTEL-syntax: jmp [RAX*8 + 0x402390]. It's an "indirect" jump. At address [RAX*8 + 0x402390] is an address which will become the target of jmp. The next step is to determine, how many addresses can be found at 0x402390 + x and in which case they are used.

rkhb
  • 14,159
  • 7
  • 32
  • 60
1

It's jumping into a table of code that has 8 bytes per entry, sort of like a switch case statement optimization. It's a bit confusing because there is a series of 7 byte sequences just after the jmpq, and the code that the jmpq branches to (starting at 402390) is not shown in the image.

rcgldr
  • 27,407
  • 3
  • 36
  • 61