Syscall table hacking toy-example does not work on 64 bit

馋奶兔 提交于 2019-12-24 10:11:33

问题


This is a very simple module I'm working on. It simply replaces a sys_ni_syscall with my new syscall log_message. Here the source file template_syscall_hacking.c:

#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/errno.h>
#include <linux/types.h>
#include <linux/unistd.h>
#include <asm/cacheflush.h>
#include <asm/page.h>
#include <asm/current.h>
#include <linux/sched.h>
#include <linux/kallsyms.h>

#define MODNAME "SYSCALL HACKING TEMPLATE"
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Marco");


// 32-bit machine addresses
unsigned long sys_call_table = 0xc1672140;
unsigned long sys_ni_syscall = 0xc10778b0;

// 64-bit machine addresses
//unsigned long sys_call_table = 0xffffffff81a00240;
//unsigned long sys_ni_syscall = 0xffffffff810aa2b0;


asmlinkage int log_message(int x) {

    printk("%s: log_message called\n", MODNAME);

}

int restore;

int init_module(void) {

    unsigned long * p = (unsigned long *) sys_call_table;
    int i;
    unsigned long cr0;

    printk("%s: init_module\n", MODNAME);

    cr0 = read_cr0();
    write_cr0(cr0 & ~X86_CR0_WP);

    for (i=0; i<256; i++){
        if (p[i] == sys_ni_syscall){
            printk("%s: table entry %d keeps address %p\n",MODNAME,i,(void*)p[i]);
            restore = i;
            break;
        }
    }

    p[restore] = (unsigned long)log_message;

    write_cr0 (cr0);

    return 0;
}

void cleanup_module(void) {

    unsigned long * p = (unsigned long *) sys_call_table;
    unsigned long cr0;

    cr0 = read_cr0();
    write_cr0(cr0 & ~X86_CR0_WP);

    p[restore] = sys_ni_syscall;


    write_cr0 (cr0);

    printk("%s: cleanup_module\n", MODNAME);

    return;
}

I tried to install the module on two linux distro, 32 bit (guest OS) and 64 bit (host OS). Follows the output of uname -ri:

3.13.0-128-generic i686
4.10.0-32-generic x86_64

The guest OS is Ubuntu 14.04, while the host OS is Ubuntu 16.04.

I set the variables sys_call_table and sys_ni_syscall to the values obtained with the following commands (on both machines):

sudo cat /boot/System.map-$(uname -r) | grep sys_call_table
sudo cat /boot/System.map-$(uname -r) | grep sys_ni_syscall

For compiling, I use the "standard" Makefile for linux kernel modules:

obj-m += template_syscall_hacking.o

all:
    make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

clean:
    make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean

Finally, I tested the new system call with the following program user.c:

#include <stdlib.h>
#include <stdio.h>

int main(int argc, char** argv){

    int sys_call_num, arg;

    if(argc < 2){
                printf("usage: prog syscall-num\n");
                return;
        }


    sys_call_num = strtol(argv[1],NULL,10);
    syscall(sys_call_num);

    return 0;
}

Test on 32 bit

When I test the module on 32 bit machine it is all ok.

  • First of all, before compile the module, we need to change the addresses for the target machine:

    // 32-bit machine addresses
    //uncomment these lines
    unsigned long sys_call_table = 0xc1672140;
    unsigned long sys_ni_syscall = 0xc10778b0;
    
    // 64-bit machine addresses
    //comment these ones
    //unsigned long sys_call_table = 0xffffffff81a00240;
    //unsigned long sys_ni_syscall = 0xffffffff810aa2b0;
    
  • I run make, which generates template_syscall_hacking.ko

  • I mounted the module with sudo insmod template_syscall_hacking.ko. It generates the following message (output of dmesg | tail):

    [14177.841355] SYSCALL HACKING TEMPLATE: init_module
    [14177.841358] SYSCALL HACKING TEMPLATE: table entry 17 keeps address c10778b0
    
  • Then, I tested the new system call with gcc user.c and ./a.out 17 (17 is the id of the new system call), which gives as output:

    [14181.207843] SYSCALL HACKING TEMPLATE: log_message called
    
  • Removing the module with sudo rmmod template_syscall_hacking gives:

    [14183.901823] SYSCALL HACKING TEMPLATE: cleanup_module
    

Everything is OK, nothing more, nothing less as I expected.

Test on 64 bit

As before I need to change the addresses for the new machine, taken from the System.map file.
It compiles correctly, but when I tried to mount the module it fails with these messages (from dmesg):

[47672.950671] SYSCALL HACKING TEMPLATE: init_module
[47672.950699] BUG: unable to handle kernel paging request at ffffffff81a00240
[47672.950715] IP: init_module+0x46/0xd0 [template_syscall_hacking]
[47672.950719] PGD 16720c067 
[47672.950722] PUD 16720d063 
[47672.950726] PMD 0 

[47672.950737] Oops: 0000 [#4] SMP
[47672.950741] Modules linked in: template_syscall_hacking(OE+) template_sys_call_table_hacker(OE+) virtual_to_physical_memory_mapper(OE+) sys_call_table_hacker(OE+) ccm vboxdrv(OE) uas usb_storage rfcomm bnep binfmt_misc nls_iso8859_1 hid_multitouch intel_rapl i2c_designware_platform i2c_designware_core asus_nb_wmi asus_wmi sparse_keymap mxm_wmi arc4 x86_pkg_temp_thermal intel_powerclamp kvm_intel iwlmvm mac80211 kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel aes_x86_64 crypto_simd glue_helper btusb btrtl uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core videodev joydev media snd_hda_codec_realtek snd_hda_codec_generic idma64 intel_lpss_acpi virt_dma cryptd input_leds serio_raw iwlwifi cfg80211 processor_thermal_device int3403_thermal snd_hda_intel
[47672.950819]  int340x_thermal_zone snd_hda_codec snd_hda_core snd_hwdep intel_lpss_pci intel_soc_dts_iosf snd_pcm intel_lpss int3400_thermal intel_pch_thermal tpm_crb acpi_thermal_rel asus_wireless snd_seq_midi snd_seq_midi_event snd_rawmidi nvidia_uvm(POE) snd_seq snd_seq_device snd_timer snd hci_uart btbcm btqca btintel mac_hid bluetooth soundcore shpchp mei_me mei wmi acpi_als kfifo_buf industrialio acpi_pad coretemp parport_pc ppdev lp parport autofs4 hid_generic usbhid nvidia_drm(POE) nvidia_modeset(POE) nvidia(POE) drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops r8169 ahci drm mii libahci i2c_hid hid video pinctrl_sunrisepoint pinctrl_intel fjes
[47672.950900] CPU: 5 PID: 29722 Comm: insmod Tainted: P      D    OE   4.10.0-32-generic #36~16.04.1-Ubuntu
[47672.950904] Hardware name: ASUSTeK COMPUTER INC. GL502VMK/GL502VMK, BIOS GL502VMK.300 12/27/2016
[47672.950910] task: ffff9e6922c74500 task.stack: ffffb42e93cdc000
[47672.950919] RIP: 0010:init_module+0x46/0xd0 [template_syscall_hacking]
[47672.950923] RSP: 0018:ffffb42e93cdfc88 EFLAGS: 00010246
[47672.950929] RAX: 0000000080040033 RBX: 0000000000000000 RCX: ffffffff810aa2b0
[47672.950934] RDX: 0000000000000000 RSI: ffff9e693ed4dc88 RDI: 0000000080040033
[47672.950939] RBP: ffffb42e93cdfc98 R08: 00000000000e818f R09: 00000000000011a3
[47672.950943] R10: ffff9e6795f39d20 R11: ffffffffa9c487ed R12: ffffffff81a00240
[47672.950948] R13: 0000000000000000 R14: ffff9e672e6bf900 R15: 0000000000000001
[47672.950953] FS:  00007fc22bbce700(0000) GS:ffff9e693ed40000(0000) knlGS:0000000000000000
[47672.950958] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080040033
[47672.950962] CR2: ffffffff81a00240 CR3: 0000000393e2a000 CR4: 00000000003426e0
[47672.950967] Call Trace:
[47672.950977]  ? log_message+0x20/0x20 [template_syscall_hacking]
[47672.950986]  do_one_initcall+0x53/0x1c0
[47672.950996]  ? kmem_cache_alloc_trace+0x152/0x1c0
[47672.951005]  do_init_module+0x5f/0x1ff
[47672.951014]  load_module+0x1825/0x1bf0
[47672.951022]  ? __symbol_put+0x60/0x60
[47672.951030]  ? ima_post_read_file+0x7d/0xa0
[47672.951038]  ? security_kernel_post_read_file+0x6b/0x80
[47672.951047]  SYSC_finit_module+0xdf/0x110
[47672.951055]  SyS_finit_module+0xe/0x10
[47672.951077]  entry_SYSCALL_64_fastpath+0x1e/0xad
[47672.951078] RIP: 0033:0x7fc22b702499
[47672.951079] RSP: 002b:00007ffc41fe31f8 EFLAGS: 00000202 ORIG_RAX: 0000000000000139
[47672.951081] RAX: ffffffffffffffda RBX: 00007fc22b9c5b20 RCX: 00007fc22b702499
[47672.951082] RDX: 0000000000000000 RSI: 0000564b4889826b RDI: 0000000000000003
[47672.951083] RBP: 0000000000001011 R08: 0000000000000000 R09: 00007fc22b9c7ea0
[47672.951084] R10: 0000000000000003 R11: 0000000000000202 R12: 00007fc22b9c5b78
[47672.951085] R13: 00007fc22b9c5b78 R14: 000000000000270f R15: 00007fc22b9c61a8
[47672.951086] Code: 8b 25 c7 1f 00 00 e8 ad e8 4a e7 e8 15 86 36 e7 66 90 48 25 ff ff fe ff 48 89 c7 e8 15 86 36 e7 66 90 48 8b 0d 9c 1f 00 00 31 db <49> 39 0c dc 74 5f 48 83 c3 01 48 81 fb 00 01 00 00 75 ed e8 e2 
[47672.951110] RIP: init_module+0x46/0xd0 [template_syscall_hacking] RSP: ffffb42e93cdfc88
[47672.951111] CR2: ffffffff81a00240
[47672.951112] ---[ end trace 538c9fde5e05cd81 ]---

Can anyone explain me what is wrong? I thought that the same code should have worked also in the 64 bit case. I'm missing something?


回答1:


I still didn't solved the problem directly; however using OpenSUSE (64 bit) it works.

uname -a output is:

Linux linux-6783.suse 4.4.79-19-default #1 SMP Thu Aug 10 20:28:47 UTC 2017 (2dd03e8) x86_64 x86_64 x86_64 GNU/Linux

EDIT:

Solved: the problem was that the actual addresses are in /proc/kallsyms. Hence, instead of grepping System.Map file, you should grep /proc/kallsyms in the following way:

sudo cat /proc/kallsyms | grep sys_call_table
sudo cat /proc/kallsyms | grep sys_ni_syscall

and use those addresses in the code of above.




回答2:


First of all, this is an awful way to do anything in kernel, messing with cr0 like that.

However, the kernel panic message tells what really happened:

PGD 16720c067 
PUD 16720d063 
PMD 0 

The Page middle directory entry was 0, thus your address ffffffff81a00240 was invalid.



来源:https://stackoverflow.com/questions/45769966/syscall-table-hacking-toy-example-does-not-work-on-64-bit

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!