最是那一低頭的溫柔，像一朵水蓮花不勝涼風的嬌羞，道一聲珍重，道一聲珍重，那一聲珍重里有蜜甜的憂愁 —— 徐志摩
ilocker：關注 Android 安全（新手） QQ: 2597294287
符號表 (symbol table) 中保存着符號的定義或者引用信息。對於 android so 文件來說，.dynsym 符號表保存着庫文件的導入和導出符號。
用 readelf 看一下 android liblog.so 的 .dynsym 動態符號表：
符號 __cxa_finalize 的 Ndx(st_shndx) 為 UND，表明該符號在本 so 中未定義，需要去 liblog.so 的依賴庫中去找。那 liblog.so 依賴哪些庫？可以從 .dynamic 中找到。
符號 __cxa_finalize 的定義應該在 libc.so 中。
符號 __android_log_vprint 的 Ndx(st_shndx) 為 8，表示該符號在本 so 中有定義，並且定義該符號的 section 在 section header table 中的索引是 8。看一下 section header table：
可以看到，符號 __android_log_vprint 定義在 .text section 中，這也是理所當然。所以 __android_log_vprint 是一個導出符號，由那些需要打印日志的程序調用。
因為符號 __android_log_vprint 是在本 so 中定義的，所以看到其 Value(st_value) 不為 0。android linker 在做符號重定位工作時，就是由這個 st_value 找到該符號定義在內存中的地址。不過 0x00001539 當然不是符號的最終的內存地址，linker 會再加上 liblog.so 在內存中的基址，所以 st_value 相當於一個地址偏移。
回過頭再看一下，符號表其實就是一個結構體數組，每個結構體描述一個符號的信息。結構體的定義如下：
其中 st_value 和 st_shndx ，上面已經有所介紹。
st_name 是符號的名字，這里保存的只是一個引用字符串表的索引值。
st_size 對於導入符號來說，根本不知道人家有多大，所以為 0。對於導出符號，則會明確標明大小。
st_info 包含了符號的類型和綁定屬性等信息，后續筆記再具體寫。
st_other 保留未用，不必關心。