2

我需要/proc/kcore在 Linux 中反汇编文件，并且需要获取一些特殊指令的虚拟地址，以便kprobes稍后放置。根据这个文件 /proc/kcore是物理内存的图像，但在这个问题中有人回答说它是内核的虚拟内存（正是我正在寻找的）。

当我使用objdump工具反汇编它时，它以类似的地址开头f7c0b000，但udis86以 0x0 开头（和完全不同的指令）。当我尝试grep一些特定的指令时，比如说mov 0xf7c1d60c,%edx，我得到了：

对象转储

f7c0b022 mov    0xf7c1d60c,%edx

udis86

290ec02a mov    0xf7c1d60c,%edx

看起来和之间的偏移udis86量objdump总是0xbffff000。为什么这么奇怪的偏移量？如何获取特定指令的虚拟地址？我读过的某个地方，该内核被静态映射到虚拟地址 0xc0000000 + 0x100000。如果/proc/kcore真的是物理图像，只将 0x100000 添加到返回的地址是否正确objdump，我将获得虚拟地址？

4

1 回答 1

3

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

您可以ELF使用该-h标志查看可执行文件的结构，例如：

# 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
(...)

It looks like the udcli tool from udis86 probably starts disassembling things from the beginning of the file, which suggests that your output will probably start with a bunch of irrelevant output and it's up to you to figure out where execution starts.

UPDATE

Here's the verification. We use this answer to extract the first load section from /proc/kcore, like this:

# dd if=/proc/kcore of=mysection bs=1 skip=$[0x7fffff602000] count=$[0x00800000]

And now if we view that with udcli:

# udcli mysection
0000000000000000 48               dec eax                 
0000000000000001 c7c060000000     mov eax, 0x60           
0000000000000007 0f05             syscall                 
0000000000000009 c3               ret                     
000000000000000a cc               int3                    
000000000000000b cc               int3

We see that it looks almost identical to the output of objdump -d /proc/kcore:

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


Disassembly of section load1:

ffffffffff600000 <load1>:
ffffffffff600000:       48 c7 c0 60 00 00 00    mov    $0x60,%rax
ffffffffff600007:       0f 05                   syscall 
ffffffffff600009:       c3                      retq   
ffffffffff60000a:       cc                      int3   
ffffffffff60000b:       cc                      int3
于 2012-05-07T17:57:29.633 回答