好久沒玩hook這種猥瑣的東西裡，今天在linux**驗了一把。
loader在進行動態鏈結的時候，會將有相同符號名的符號覆蓋成ld_preload指定的so檔案中的符號。換句話說，可以用我們自己的so庫中的函式替換原來庫里有的函式，從而達到hook的目的。這和windows下通過修改import table來hook api很類似。相比較之下，ld_preload更方便了，都不用自己寫**了，系統的loader會幫我們搞定。但是ld_preload有個限制：只能hook動態鏈結的庫，對靜態鏈結的庫無效，因為靜態鏈結的**都寫到可執行檔案裡了嘛，沒有坑讓你填。
上**先是受害者，我們的主程式main.c，通過strcmp比較字串是否相等：
#include #include int main(int argc, char *ar**) else return 0; }然後是用來hook的庫hook.c：
#include #include #include typedef int(*strcmp)(const char*, const char*); int strcmp(const char *s1, const char *s2) printf("hack function invoked. s1=<%s> s2=<%s>\n", s1, s2); return old_strcmp(s1, s2); }
因為hook的目標是strcmp，所以typedef了乙個strcmp函式指標。由於hook的目的是要控制函式行為，所以需要從原庫libc.so.6中拿到「正版」strcmp指標，儲存成old_strcmp以備呼叫。
makefile：
test: main.c hook.so執行：gcc -o test main.c
hook.so: hook.c
gcc -fpic -shared -o hook.so hook.c -ldl
$ ld_preload=./hook.so ./test 123其中有一點不理解的是，hack function invoked. s1=<123> s2= incorrect password $ ld_preload=./hook.so ./test test hack function invoked. s1= s2= correct password
dlopen開啟libc.so.6能拿到「正版」strcmp位址，開啟libc.so就是hook後的位址。照理說libc.so不是libc.so.6的乙個軟鏈嗎？為什麼結果會不一樣嘞？ 利用LD PRELOAD給glibc庫函式加鉤子
通過getuid printf等函式講解了基本的加鉤子的方法 如果你希望的不僅僅是替換掉原有庫函式，而且還希望最終將函式邏輯傳遞到原有系統函式，那麼你可能需要用到rtld next。系統可能提示 rtld next未定義，這裡給出了解決方案 我的過程記錄 fork.c，最後編譯成fork.so in...
利用LD PRELOAD給glibc庫函式加鉤子
通過getuid printf等函式講解了基本的加鉤子的方法 如果你希望的不僅僅是替換掉原有庫函式，而且還希望最終將函式邏輯傳遞到原有系統函式，那麼你可能需要用到rtld next。系統可能提示 rtld next未定義，這裡給出了解決方案 我的過程記錄 fork.c，最後編譯成fork.so in...
利用faac進行編碼
利用faac直接對pcm進行aac編碼 下面是我在faac fronted main.c中抽出來 對pcm進行aac編碼的例子 希望對大家有用。片源資訊 output.pcm 44100 2 16 include include include include include include def...