往linux核心掛鉤子–什麼應該什麼不應該

總是在網上看到有人討論攔截linux的系統呼叫，方法數量可謂海量，幾乎都是自己寫的核心模組，可是這種方式有什麼意義呢，模組都能載入了還有什麼做不 到的呢，要知道linux的可載入核心模組功能十分強大，再加上linux核心本身就是開放原始碼的，如果說你能載入模組了，那麼就可以說你完全控制了核心，你再搞什麼攔截系統呼叫實際上一點意義都沒有，用模組別說攔截系統呼叫了，攔截任何函式都小菜一碟，當然如果核心匯出的函式你可以直接攔截，沒有匯出 的函式有很多辦法可以找到，比如/proc/kallsyms，大不了一個一個對，肯定能找到其地址。 

在網上我幾乎看到了兩種方法來攔截，對於2.4以前的核心，核心匯出了大部分的函式，這樣在模組中攔截很方便，可到了2.4核心以及2.6核心中，很多以 前匯出的函式現在不再匯出了，於是就要費一番周折了，常見的方式有搜尋核心符號表。在所有的攔截動作中，以攔截檔案操作的動作居多，我們想象一下真的需要那麼麻煩的從符號表找沒有匯出的函式地址嗎（這個操作實際上一點也不麻煩）？想想看sys_read,sys_write等操作僅僅是一個二傳手，執行緒只是經過它們一下，它們的地址不再匯出不是為了更加安全，你都通過模組進入核心了就說明沒有什麼是安全的了。linux具有的虛擬檔案系統是一個很好的機制 

，這說明真正做事情的就是vfs中的回撥函式們，你直接攔截回撥函式不就結了，每個開啟的檔案在記憶體中都有一個file結構體，而此結構體中有 file_operations結構，該結構就是該檔案的回撥函式集合，現在問題是你要攔截一個回撥函式不得先開啟該檔案找到這個 file_operations結構嗎？如果有此疑問的，說明這位兄弟還是對核心不熟悉，仔細看一下核心，所有的file_operations都是以全 局的靜態方式提供，也就是說所有的一類檔案公用一個file_operations結構體，這就好辦了，隨便開啟一個檔案，將其替換了就可以了。上面說的所有的file_operations被公用可以從以下程式碼看出來：

void ext2_read_inode (struct inode * inode)

 本文轉自 dog250 51CTO部落格，原文連結:http://blog.51cto.com/dog250/1273424