【问题标题】:objdump and udis86 produce different output when disassembling /proc/kcore反汇编 /proc/kcore 时,objdump 和 udis86 产生不同的输出
【发布时间】:2012-05-14 21:06:44
【问题描述】:

我需要在Linux中对/proc/kcore文件进行反汇编,并且我需要获取一些特殊指令的虚拟地址以便稍后将kprobes放在上面。根据this document/proc/kcore 是物理内存的映像,但在this question 有人回答说它是内核的虚拟内存(正是我要找的)。

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

objdump

f7c0b022 mov    0xf7c1d60c,%edx

udis86

290ec02a mov    0xf7c1d60c,%edx

看起来udis86objdump 之间的偏移量总是0xbffff000。为什么这么奇怪的偏移量?如何获取特定指令的虚拟地址?我读过的某个地方,该内核被静态映射到虚拟地址 0xc0000000 + 0x100000。如果/proc/kcore真的是物理镜像,那么只在objdump返回的地址上加上0x100000就可以得到虚拟地址是正确的吗?

【问题讨论】:

    标签: linux disassembly objdump


    【解决方案1】:

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

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

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

    看起来udis86 中的udcli 工具可能从文件开头开始反汇编东西,这表明您的输出可能会从一堆不相关的输出开始,由您决定执行位置开始。

    更新

    这是验证。我们使用this answer 从/proc/kcore 中提取第一个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 的输出几乎相同:

    # 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   
    

    【讨论】:

    • 太棒了,它就像一个魅力,谢谢。地址呢?如何获得可以使用的虚拟地址,例如对于 kprobes?
    • 好的,我尝试创建自己的模块并转储它的一些功能的地址。当我尝试在objdump -d /proc/kcoregrep 这些地址时,我真的在那里找到了它们。仔细想想,kcore是ELF格式的,所以当然应该有虚拟地址吧?
    猜你喜欢
    • 2020-07-09
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多