如何在64位ubuntu中截獲內(nèi)核模塊的導(dǎo)出函數(shù)？

leishaoweiwu

我想在64位ubuntu中截獲內(nèi)核模塊的導(dǎo)出函數(shù)，求思路，最好是代碼

firocu

回復(fù) 1# leishaoweiwu
首先這ubuntu, 沒什么關(guān)系.

模塊的通過__EXPORT_SYMBOL把符號(hào)導(dǎo)出到

    __attribute__((section("__ksymtab_strings")

如果你只是想將模塊文件中的導(dǎo)出函數(shù)"截獲", 以auth_rpcgss為例
/lib/modules/3.19.5-200.fc21.x86_64/kernel/net/sunrpc/auth_gss/auth_rpcgss.ko.xz

1. readelf  -s auth_rpcgss.ko | grep __ksymtab_
   
2.    220: 0000000000000020    16 OBJECT  GLOBAL DEFAULT   10 __ksymtab_gss_pseudoflavo
   
3.    238: 0000000000000020    16 OBJECT  GLOBAL DEFAULT   12 __ksymtab_g_verify_token_
   
4.    247: 0000000000000010    16 OBJECT  GLOBAL DEFAULT   10 __ksymtab_gss_mech_put
   
5.    288: 0000000000000030    16 OBJECT  GLOBAL DEFAULT   12 __ksymtab_gss_mech_regist
   
6.    303: 0000000000000000    16 OBJECT  GLOBAL DEFAULT   10 __ksymtab_gss_mech_get
   
7.    365: 0000000000000010    16 OBJECT  GLOBAL DEFAULT   12 __ksymtab_g_token_size
   
8.    366: 0000000000000000    16 OBJECT  GLOBAL DEFAULT   12 __ksymtab_g_make_token_he
   
9.    367: 0000000000000040    16 OBJECT  GLOBAL DEFAULT   12 __ksymtab_gss_mech_unregi
   
10.    379: 0000000000000050    16 OBJECT  GLOBAL DEFAULT   12 __ksymtab_svcauth_gss_fla
    
11.    383: 0000000000000060    16 OBJECT  GLOBAL DEFAULT   12 __ksymtab_svcauth_gss_reg

復(fù)制代碼

or 這么做

1. readelf -p __ksymtab_strings auth_rpcgss.ko
   
2. 
   
3. String dump of section '__ksymtab_strings':
   
4.   [     0]  g_verify_token_header
   
5.   [    16]  g_make_token_header
   
6.   [    2a]  g_token_size
   
7.   [    37]  gss_mech_put
   
8.   [    44]  gss_pseudoflavor_to_service
   
9.   [    60]  gss_mech_get
   
10.   [    6d]  gss_mech_unregister
    
11.   [    81]  gss_mech_register
    
12.   [    93]  svcauth_gss_register_pseudoflavor
    
13.   [    b5]  svcauth_gss_flavor

復(fù)制代碼

我覺得這應(yīng)該不是你的需求, 你或許是在運(yùn)行的內(nèi)核中動(dòng)態(tài)的檢測(cè)截獲加載的內(nèi)核的符號(hào)導(dǎo)出表.
簡(jiǎn)單看了下load module的代碼
你可以注冊(cè)一個(gè)module 通知鏈
register_module_notifier
這個(gè)notifier block會(huì)在do_init_module調(diào)用, 正好是模塊加載最后一步執(zhí)行.
struct module的成員
const struct kernel_symbol *syms;正好指向__ksymtab這個(gè)section
你試著看看應(yīng)該能找到所有export的代碼

個(gè)人見解.

nswcfd

學(xué)習(xí)了，不過樓主這是要解決什么問題呢？安全問題？

leishaoweiwu

謝謝您，我是想在64位的ubuntu中hook某個(gè)函數(shù)，比如說鉤住usb_submit_urb這個(gè)函數(shù)，在執(zhí)行這個(gè)函數(shù)之前先截獲這個(gè)函數(shù)所提交的urb信息，再和我的白名單中的策略作對(duì)比，要是符合的話，就允許相應(yīng)的外設(shè)訪問，否則就禁止。32位ubuntu下的我已經(jīng)實(shí)現(xiàn)了，現(xiàn)在在64位下研究，想在64位下找到相應(yīng)的hook函數(shù)，或者還有沒有其他的方法？回復(fù) 2# firocu


   

leishaoweiwu

在64位的ubuntu中hook某個(gè)函數(shù)，比如說鉤住usb_submit_urb這個(gè)函數(shù)，在執(zhí)行這個(gè)函數(shù)之前先截獲這個(gè)函數(shù)所提交的urb信息，再和我的白名單中的策略作對(duì)比，要是符合的話，就允許相應(yīng)的外設(shè)訪問，否則就禁止。回復(fù) 3# nswcfd


   

leishaoweiwu

請(qǐng)問有什么好的思路嗎？回復(fù) 5# leishaoweiwu


   

nswcfd

不好意思，不明白為什么32位跟64位有區(qū)別？跟hook機(jī)制有關(guān)系嗎？

如果性能不是特別concern的話，可以使用kprobe/jprobe/kretprobe之類的。
* jprobe可以查看入口的參數(shù)值，但是怎么影響原始的控制流還有待研究（比如修改urb的某個(gè)字段為非法值？）。
* kretprobe在函數(shù)返回的時(shí)候起作用，作為訪問控制的時(shí)機(jī)有些晚。
* 最強(qiáng)大的是kprobe，不過這就跟反匯編緊密的耦合起來，受版本變化影響。

還有一種方法，就是在你的訪問控制模塊里面，重新實(shí)現(xiàn)一遍usb_submit_urb函數(shù)，在入口的時(shí)候加上訪問控制的代碼。此外，把原始的usb_submit_urb的入口替換為一個(gè)jmp命令。

PS，如果允許重新編譯vmlinx的話，就在usb_submit_urb的入口處插入一個(gè)callback（函數(shù)指針），導(dǎo)出這個(gè)符號(hào)。在訪問控制模塊中實(shí)現(xiàn)callback，注冊(cè)函數(shù)指針。

leishaoweiwu

恩，我在32位ubuntu中就是用第二種方法的，在原始的usb_submit_urb的入口替換為一個(gè)jmp命令，執(zhí)行usb_submit_urb之前跳轉(zhuǎn)到訪問控制函數(shù)，然后再執(zhí)行執(zhí)行usb_submit_urb。已經(jīng)能夠成功實(shí)現(xiàn)，我現(xiàn)在想在64位ubuntu中用類似的思路實(shí)現(xiàn)，可是有問題，在32位ubuntu中要想hook函數(shù)必須將CPU寄存器CR0的寫保護(hù)位置為0，我現(xiàn)在的不知道是不是64位ubuntu下只有把CPU寄存器CR0的寫保護(hù)位置0才能hook函數(shù)？回復(fù) 7# nswcfd


   

nswcfd

不好意思，不太了解這個(gè)細(xì)節(jié)。最好參閱一下intel的cpu手冊(cè)。

不過跟蹤register_kprobe的反匯編，沒有發(fā)現(xiàn)mov %cr0……

不管需不需要，先嘗試一下唄，大不了crash一下，:p