While working on this kernel module, I noticed IDA somehow resolves some ELF relocations statically. Consider the symbol sys_renameat
, which, according to IDA, resides at 0x8000720
in .bss
segment.
The raw hex bytes corresponding to the mov
instruction at 0x800328
are A3 20 07 00 08
However, looking at bytes at that specific offset with a hex-editor reveals A3 00 00 00 00
. Clearly, there is a relocation which IDA is resolving somehow.
readelf -r rootkit
confirms this.
Relocation section '.rel.init.text' at offset 0x119c contains 26 entries:
Offset Info Type Sym.Value Sym. Name
.
00000059 00001701 R_386_32 00000000 sys_renameat
.
The symbol information as returned by readelf -s rootkit
Symbol table '.symtab' contains 44 entries:
Num: Value Size Type Bind Vis Ndx Name
.
23: 00000000 4 OBJECT GLOBAL DEFAULT 15 sys_renameat
.
However, if I strip
the binary, suddenly IDA fails to resolve (mov
instruction at 0x800328
) the relocations any more.
My understanding is, resolving dynamic relocations never depends on symbol information which strip
removes. I tried to compute how IDA was computing R_386_32
type relocation for sys_renameat
according to ELF specification, but couldn't figure out what's going on.
Is IDA resolving relocation correctly in this case/ If so, can someone please explain this behavior?