objdump和udis86在反汇编/ proc / kcore时会产生不同的输出

时间:2012-05-05 16:28:33

标签: linux disassembly objdump

我需要在Linux中反汇编/proc/kcore文件,我需要获取一些特殊指令的虚拟地址,以便稍后放置kprobes。根据{{​​3}} /proc/kcore是物理内存的图像,但在this document中,有人回答说它是内核的虚拟内存(正是我正在寻找的内容)。

当我使用objdump工具对其进行反汇编时,它的地址类似f7c0b000,但this question以0x0开头(完全不同的指令)。当我尝试grep一些特定的指令时,让我们说mov 0xf7c1d60c,%edx,我得到了:

objdump的

f7c0b022 mov    0xf7c1d60c,%edx

udis86

290ec02a mov    0xf7c1d60c,%edx

看起来udis86objdump之间的偏移始终为0xbffff000。为何如此奇怪的抵消?如何获取特定指令的虚拟地址?我读过的地方,内核静态映射到虚拟地址0xc0000000 + 0x100000。如果/proc/kcore确实是物理图像,那么只有将{100}添加到objdump返回的地址才能正确吗?我将获得虚拟地址吗?

1 个答案:

答案 0 :(得分:3)

objdump了解ELF格式文件(例如/proc/kcore)。它能够提取文件的可执行部分,同时忽略不可执行的内容(例如.note部分)。

您可以使用ELF标记查看-h exectuable的结构,例如:

# objdump -h /proc/kcore
/proc/kcore:     file format elf64-x86-64

Sections:
Idx Name          Size      VMA               LMA               File off  Algn
  0 note0         00001944  0000000000000000  0000000000000000  000002a8  2**0
                  CONTENTS, READONLY
  1 .reg/0        000000d8  0000000000000000  0000000000000000  0000032c  2**2
                  CONTENTS
  2 .reg          000000d8  0000000000000000  0000000000000000  0000032c  2**2
                  CONTENTS
  3 load1         00800000  ffffffffff600000  0000000000000000  7fffff602000  2**12
                  CONTENTS, ALLOC, LOAD, CODE
(...)

看起来来自udcli的{​​{1}}工具可能会从文件的开头开始反汇编,这表明你的输出可能会从一堆无关的输出开始,这取决于你找出执行开始的地方。

<强>更新

这是验证。我们使用this answer从/ proc / kcore中提取第一个udis86部分,如下所示:

load

现在,如果我们使用# dd if=/proc/kcore of=mysection bs=1 skip=$[0x7fffff602000] count=$[0x00800000] 查看:

udcli

我们发现它看起来几乎与# udcli mysection 0000000000000000 48 dec eax 0000000000000001 c7c060000000 mov eax, 0x60 0000000000000007 0f05 syscall 0000000000000009 c3 ret 000000000000000a cc int3 000000000000000b cc int3 的输出相同:

objdump -d /proc/kcore