A PIE binary, when loaded in IDA shows an offset (0x202010) different from gdb (0x2013a1) for instruction located at 0x555555554c68 in (gdb) and 0xc68 (in IDA). How can I explain this discrepancy?
Add a comment
|
2 Answers
For "Position Independent Executable" binaries, the loader is free to relocate the binary using some base address. In the case of GDB, the binary is mapped already into memory, the offset 0x2013a1 in the memory operand is calculated relatively with the current RIP (which is the address of the next instruction). The current instruction size is 0x6f - 0x68 = 0x7 bytes, so in considering with the address of the current instruction, we have an offset:
0x2013a1 + 0x7 = 0x2013a8
In the case of IDA, you see the "static" virtual address, the offset 0x202010 in the memory operand is calculated relatively with the base address of the code segment, so in considering with the address of the current instruction, we have an offset:
0x202010 - 0xc68 = 0x2013a8
These values are coherent for both cases.
-
The offset, which is rip relative, should be the same irrespective of the base address.– sherlockCommented Apr 2, 2017 at 16:34
-
In the case of IDA, the offset
0x20210of the memory operand and the offset0xc68of the instruction are counted from the same base address of the code segment. This is different from the case of DBG, the number0x2013a1is relative with the currentRIP. I give more detail in the answer. Commented Apr 2, 2017 at 17:54 -
This makes perfect sense now. I didn't understand that IDA calculates the offset relative to the base address of the code segment.– sherlockCommented Apr 2, 2017 at 18:37
IDA shows a simplified operand, with the rip+<delta> value resolved, so you don't have to calculate it yourself. If you prefer, you can view the original form of rip-relative instructions by enabling "explicit RIP addressing" in processor-specific options.
answered Apr 2, 2017 at 19:19
