動態連線的訣竅：使用 LD_PRELOAD 去欺騙、註入特性和研究程式 | Linux 中國

我相信，它足夠簡單吧。我不使用任何引數來編譯它，如下所示：

gcc random_num.c -o random_num

我希望它輸出的結果是明確的：從 0-99 中選擇的十個隨機數字，希望每次你執行這個程式時它的輸出都不相同。

現在，讓我們假裝真的不知道這個可執行程式的出處。甚至將它的源檔案刪除，或者把它移動到別的地方 —— 我們已不再需要它了。我們將對這個程式的行為進行重大的修改，而你並不需要接觸到它的原始碼，也不需要重新編譯它。

因此，讓我們來建立另外一個簡單的 C 檔案：

unrandom.c：

int rand(){
    return 42; //the most random number in the universe
}

我們將編譯它進入一個共享庫中。

gcc -shared -fPIC unrandom.c -o unrandom.so

因此，現在我們已經有了一個可以輸出一些隨機數的應用程式，和一個定製的庫，它使用一個常數值 42 實現了一個 rand() 函式。現在 …… 就像執行 random_num 一樣，然後再觀察結果：

LD_PRELOAD=$PWD/unrandom.so ./random_nums

如果你想偷懶或者不想自動親自動手（或者不知什麼原因猜不出發生了什麼），我來告訴你 —— 它輸出了十次常數 42。

如果先這樣執行

export LD_PRELOAD=$PWD/unrandom.so

然後再以正常方式執行這個程式，這個結果也許會更讓你吃驚：一個未被改變過的應用程式在一個正常的執行方式中，看上去受到了我們做的一個極小的庫的影響 ……

等等，什麼？剛剛發生了什麼？

是的，你說對了，我們的程式生成隨機數失敗了，因為它並沒有使用 “真正的” rand()，而是使用了我們提供的的那個 —— 它每次都傳回 42。

但是，我們告訴過它去使用真實的那個。我們程式設計讓它去使用真實的那個。另外，在建立那個程式的時候，假冒的 rand() 甚至並不存在！

這句話並不完全正確。我們只能告訴它去使用 rand()，但是我們不能去選擇哪個 rand()是我們希望我們的程式去使用的。

當我們的程式啟動後，（為程式提供所需要的函式的）某些庫被載入。我們可以使用 ldd 去學習它是怎麼工作的：

$ ldd random_nums
linux-vdso.so.1 => (0x00007fff4bdfe000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f48c03ec000)
/lib64/ld-linux-x86-64.so.2 (0x00007f48c07e3000)

正如你看到的輸出那樣，它列出了被程式 random_nums 所需要的庫的串列。這個串列是構建進可執行程式中的，並且它是在編譯時決定的。在你的機器上的具體的輸出可能與示例有所不同，但是，一個 libc.so 肯定是有的 —— 這個檔案提供了核心的 C 函式。它包含了 “真正的” rand()。

我使用下列的命令可以得到一個全部的函式串列，我們看一看 libc 提供了哪些函式：

nm -D /lib/libc.so.6

這個 nm  命令列出了在一個二進位制檔案中找到的符號。-D 標誌告訴它去查詢動態符號，因為 libc.so.6 是一個動態庫。這個輸出是很長的，但它確實在列出的很多標準函式中包括了 rand()。

現在，在我們設定了環境變數 LD_PRELOAD 後發生了什麼？這個變數 為一個程式強制載入一些庫。在我們的案例中，它為 random_num 載入了 unrandom.so，儘管程式本身並沒有這樣去要求它。下列的命令可以看得出來：

$ LD_PRELOAD=$PWD/unrandom.so ldd random_nums
linux-vdso.so.1 =>  (0x00007fff369dc000)
/some/path/to/unrandom.so (0x00007f262b439000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f262b044000)
/lib64/ld-linux-x86-64.so.2 (0x00007f262b63d000)

註意，它列出了我們當前的庫。實際上這就是程式碼為什麼得以執行的原因：random_num 呼叫了 rand()，但是，如果 unrandom.so 被載入，它呼叫的是我們所提供的實現了 rand() 的庫。很清楚吧，不是嗎？

更清楚地瞭解

這還不夠。我可以用相似的方式註入一些程式碼到一個應用程式中，並且用這種方式它能夠像個正常的函式一樣工作。如果我們使用一個簡單的 return 0 去實現 open() 你就明白了。我們看到這個應用程式就像發生了故障一樣。這是 顯而易見的， 真實地去呼叫原始的 open()：

inspect_open.c：

int open(const char *pathname, int flags){
  /* Some evil injected code goes here. */
  return open(pathname,flags); // Here we call the "real" open function, that is provided to us by libc.so
}

嗯，不對。這將不會去呼叫 “原始的” open(...)。顯然，這是一個無休止的遞迴呼叫。

怎麼去訪問這個 “真正的” open() 函式呢？它需要去使用程式介面進行動態連結。它比聽起來更簡單。我們來看一個完整的示例，然後，我將詳細解釋到底發生了什麼：

inspect_open.c：

#define _GNU_SOURCE
#include <dlfcn.h>
typedef int (*orig_open_f_type)(const char *pathname, int flags);
int open(const char *pathname, int flags, ...)
{
    /* Some evil injected code goes here. */
    orig_open_f_type orig_open;
    orig_open = (orig_open_f_type)dlsym(RTLD_NEXT,"open");
    return orig_open(pathname,flags);
}

printf("The victim used open(...) to access '%s'!!!\n",pathname); //remember to include stdio.h!

gcc -shared -fPIC  inspect_open.c -o inspect_open.so -ldl

LD_PRELOAD=$PWD/inspect_open.so gnome-calculator