Kernel module crash when reading system call table function address

前端 未结 1 1711
南方客
南方客 2021-01-20 07:06

I am studying rootkits and trying to hook the system call table. As i can already dynamically retrieve the table\'s address from /boot/System.map-$(uname -r), i traced and i

相关标签:
1条回答
  • 2021-01-20 07:41

    (0. Why does it crash and what can i do about it?)

    If the kernel configuration includes CONFIG_RANDOMIZE_BASE=y, the system call table will be at a random offset from the address specified in the System.map file due to kernel address space layout randomization (KASLR). There is not much you can do about the randomization other than use a kernel without this configuration option, or boot with the nokaslr option.

    You can exploit the fact that global symbols are shifted by the same random amount. If sys_call_table has an address of 0x0xffffffff81c002a0 in System.map, and system_wq has an address of 0xffffffff821204b8 in System.map, then you know that sys_call_table will start 0x520218 bytes before system_wq in the live system.

    1. Why does "%p" print a different value than that of "%lx"?

    The kernel's default handling for %p with no appended modifiers for printing pointers to different things is to print a hashed version of the pointer value to avoid leaking addresses to userspace. However, %lx doesn't do that.

    1. Why does "%p" print different values after reboots while "%lx" always prints the correct value?

    The hashed pointer values printed by %p are hashed with a random key set during kernel initialization.

    0 讨论(0)
提交回复
热议问题