objdump and udis86 produce different output when disassembling /proc/kcore

Question

I need to disassemble /proc/kcore file in Linux and I need to obtain virtual addresses of some special instructions to put kprobes later on it. According to this document /proc/kcore is an image of physical memory, but in this question someone answered that it is kernel's virtual memory (exactly what I am looking for).

When I use objdump tool to disassemble it, it starts with address something like f7c0b000, but udis86 starts with 0x0 (and totally different instruction). When I try to grep some specific instruction, let's say mov 0xf7c1d60c,%edx, I got:

objdump

f7c0b022 mov    0xf7c1d60c,%edx

udis86

290ec02a mov    0xf7c1d60c,%edx

It looks like the offset between udis86 and objdump is always 0xbffff000. Why so strange offset? How can I obtain virtual address of specific instruction? Somewhere I've read, that kernel is statically mapped at virtual address 0xc0000000 + 0x100000. If /proc/kcore is really physical image, is it correct only to add 0x100000 to addresses returned by objdump and I will get virtual address?

score 3 · Accepted Answer · edited May 23 '17 at 11:48

objdump understands ELF format files (such as /proc/kcore). It is able to extract the executable sections of the file while ignoring non-executable content (such as .note sections).

You can see the structure of an ELF exectuable using the -h flag, for example:

# 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

That's awesome, it works like a charm, thanks. And what about the addresses? How can I get virtual address which can be used e.g. for kprobes? — Peter Krejci, May 07 '12 at 21:09
Ok, I tried to create my own module and dump addresses of some its functions. And when I tried to `grep` these addresses on `objdump -d /proc/kcore`, I really found them there. If you think about it, kcore is in ELF format, so of course there should be virtual addresses, am I right? — Peter Krejci, May 08 '12 at 20:26

objdump and udis86 produce different output when disassembling /proc/kcore

1 Answers1