為了進行代碼及產(chǎn)品保護，幾乎所有的非開源App都會進行代碼混淆，這樣當收集到崩潰信息后，就需 要進行符號化來還原代碼信息，以便開發(fā)者可以定位Bug。基于使用SDK和NDK的不同，Android的崩潰分為兩類：Java崩潰和C/C++崩潰。Java崩潰通過mapping.txt文件進行符號化，比較簡單直觀，而C/C++崩潰的符號化則需要使用Google自帶的一些NDK工具，比如ndk-stack、addr2line、objdump等。本文不去討論如何使用這些工具，有興趣的朋友可以參考同事寫的另一篇文章《如何定位Android NDK開發(fā)中遇到的錯誤》，里面做了詳細的描述。
基于NDK的Android的開發(fā)都會生成一個動態(tài)鏈接庫(so)，它是基于C/C++編譯生成的。動態(tài)鏈接庫在Linux系統(tǒng)下廣泛使用，而Android系統(tǒng)底層是基于Linux的，所以NDK so庫的編譯生成遵循相同的規(guī)則，只不過Google NDK把相關的交叉編譯工具都封裝了。
Ndk-build編譯時會生成的兩個同名的so庫，位于不同的目錄/projectpath/libs/armeabi/xxx.so和/project path/obj/local/armeabi/xxx.so，比較兩個so文件會發(fā)現(xiàn)體積相差很大。前者會跟隨App一起發(fā)布，所以盡可能的小，而后者包含了很多調試信息，主要為了gdb調試的時候使用，當然NDK的日志符號化信息也包含其中。
本文主要分析這個包含調試信息的so動態(tài)庫，深入分析它的組成結構。在開始之前，先來說說這樣做的目的或者好處。現(xiàn)在的App基本都會采集上報崩潰時的日志信息，無論是采用第三方云平臺（如Testin崩潰分析+），還是自己搭建云服務，都要將含調試信息的so動態(tài)庫上傳，實現(xiàn)云端日志符號化以及云端可視化管理。移動App的快速迭代，使得我們必須存儲管理每一個版本的debugso庫，而其包含了很多與符號化無關的信息。如果我們只提取出符號化需要的信息，那么符號化文件的體積將會呈現(xiàn)數(shù)量級的減少。同時可以在自定義的符號化文件中添加App的版本號等信息，實現(xiàn)符號化提取、上傳到云端、云端解析及可視化等自動化部署。另外，從技術角度講，你將不在害怕看到“unresolvedsymbol” linking errors，更從容地 debugging C/C++ crash或者hacking一些so文件。
首先通過readelf來看看兩個不同目錄下的so庫有什么不同
從中可以清楚看到，包含調試信息的so庫多了8個.debug_開頭的條目以及.symtab和.strtab條目。符號化的本質，是通過堆棧中的地址信息，還原代碼本來的語句以及相應的行號，所以這里只需解析.debug_line和.symtab，最終獲取到如下的信息就可以實現(xiàn)符號化了。
c85 c8b willCrash jni/hello-jni.c:27-29 c8b c8d willCrash jni/hello-jni.c:32 c8d c8f JNI_OnLoad jni/hello-jni.c:34 c8f c93 JNI_OnLoad jni/hello-jni.c:35 c93 c9d JNI_OnLoad jni/hello-jni.c:37
通常，目標文件分為三類：relocatable文件、executable文件和shared object文件，它們格式稱為ELF（Executableand Linking Format），so動態(tài)庫屬于第三類shared object，它的整體組織結構如下：
| ELF Header |
| Program header table optional |
| Section 1 |
| ... |
| Section n |
| ... |
| Section header table required |
ELF Header文件頭的結構如下，記錄了文件其他內容在文件中的偏移以及大小信息。這里以32bit為例。
重慶分公司
重慶分公司
typedef struct {
unsigned char e_ident[EI_NIDENT];
Elf32_Half e_type; //目標文件類型，如relocatable、executable和shared object
Elf32_Half e_machine; // 指定需要的特定架構，如Intel 80386，Motorola 68000
Elf32_Word e_version; // 目標文件版本，通e_ident中的EI_VERSION
Elf32_Addr e_entry; //指定入口點地址，如C可執(zhí)行文件的入口是_start()，而不是main()
Elf32_Off e_phoff; // program header table 的偏移量
Elf32_Off e_shoff; // section header table的偏移量
Elf32_Word e_flags; // 處理器相關的標志
Elf32_Half e_ehsize; // 代表ELF Header部分的大小
Elf32_Half e_phentsize; // program header table中每一項的大小
Elf32_Half e_phnum; // program header table包含多少項
Elf32_Half e_shentsize; // section header table中每一項的大小
Elf32_Half e_shnum; // section header table包含多少項
Elf32_Half e_shstrndx; //section header table中某一子項的index，該子項包含了所有section的字符串名稱
} Elf32_Ehdr;其中e_ident為固定16個字節(jié)大小的數(shù)組，稱為ELF Identification，包含了處理器類型、文件編碼格式、機器類型等，具體結構如下：
| Name | Value | Purpose |
| EI_MAG0 | 0 | 前四個字節(jié)稱為magic number，分別為0x7f、’E’、’L’、’F’，表明文件類型為ELF。 |
EI_MAG1 | 1 | |
| EI_MAG2 | 2 | |
| EI_MAG3 | 3 | |
EI_CLASS | 4 | 表明文件是基于32-bit還是64-bit，不同的方式，對齊方式不同，讀取某些內容的大小不同。 |
| EI_DATA | 5 | 表明文件數(shù)據(jù)結構的編碼方式，主要分為大端和小端兩種 |
EI_VERSION | 6 | 指定了ELF文件頭的版本號 |
EI_OSABI | 7 | 指定使用了哪種OS-或者ABI-的ELF擴展 |
| EI_ABIVERSION | 8 | 指定該ELF目標文件的目標ABI版本 |
EI_PAD | 9 | 保留字段起始處，直到第16個字節(jié) |
| EI_NIDENT | 16 | 代表了e_ident數(shù)組的大小，固定為16 |
Sections
該部分包含了除ELF Header、program header table以及section header table之外的所有信息。通過section header table可以找到每一個section的基本信息，如名稱、類型、偏移量等。
先來看看Section Header的內容，仍以32-bit為例：
typedef struct {
Elf32_Word sh_name; // 指定section的名稱，該值為String Table字符串表中的索引
Elf32_Word sh_type; // 指定section的分類
Elf32_Word sh_flags; // 該字段的bit代表不同的section屬性
Elf32_Addr sh_addr; // 如果section出現(xiàn)在內存鏡像中，該字段表示section第一個字節(jié)的地址
Elf32_Off sh_offset; // 指定section在文件中的偏移量
Elf32_Word sh_size; // 指定section占用的字節(jié)大小
Elf32_Word sh_link; // 相關聯(lián)的section header table的index
Elf32_Word sh_info; // 附加信息，意義依賴于section的類型
Elf32_Word sh_addralign; // 指定地址對其約束
Elf32_Word sh_entsize; // 如果section包含一個table，該值指定table中每一個子項的大小
} Elf32_Shdr;通過Section Header的sh_name可以找到指定的section，比如.debug_line、.symbol、.strtab。
String Table
String Table包含一系列以\0結束的字符序列，最后一個字節(jié)設置為\0，表明所有字符序列的結束，比如：
String Table也屬于section，只不過它的偏移量直接在ELF Header中的e_shstrndx字段指定。String Table的讀取方法是，從指定的index開始，直到遇到休止符。比如要section header中sh_name獲取section的名稱，比如sh_name = 7, 則從string table字節(jié)流的第7個index開始（注意這里從0開始），一直讀到第一個休止符（index=18），讀取到的名稱為.debug_line
Symbol Table
該部分包含了程序符號化的定義相關信息，比如函數(shù)定義、變量定義等，每一項的定義如下：
# Symbol Table Entry
typedef struct {
Elf32_Word st_name; //symbol字符串表的索引
Elf32_Addr st_value; //symbol相關的值，依賴于symbol的類型
Elf32_Word st_size; //symbol內容的大小
unsigned char st_info; //symbol的類型及其屬性
unsigned char st_other; //symbol的可見性，比如類的public等屬性
Elf32_Half st_shndx; //與此symbol相關的section header的索引
} Elf32_Sym;Symbol的類型包含一下幾種
| Name | Value |
| STT_NOTYPE | 0 |
| STT_OBJECT | 1 |
| 2 |
| 3 |
| 4 |
| 5 |
| 6 |
| 10 |
| STT_HIOS | 12 |
| 13 |
| 15 |
其中STT_FUNC就是我們要找的函數(shù)symbol。然后通過st_name從symbol字符串表中獲取到相應的函數(shù)名（如JNI_OnLoad）。當symbol類型為STT_FUNC時，st_value代表該symbol的起始地址，而（st_value+st_size）代表該symbol的結束地址。
回顧之前的提到的.symtab和.strtab兩個部分，對應的便是Symbol Section和Symbol String Section。
DWARF是一種調試文件格式，很多編譯器和調試器都通過它進行源碼調試（gdb等）。盡管它是一種獨立 的目標文件格式，但往往嵌入在ELF文件中。前面通過readelf看到的8個.debug_* Section全部都屬于DWARF格式。本文將只討論與符號化相關的.debug_line部分，更多的DWARF信息請查看參考文獻的內容。
.debug_line部分包含了行號信息，通過它可以將代碼語句和機器指令地址對應，從而進行源碼調試。.debug_line有很多子項組成，每個子項都包含類似數(shù)據(jù)塊頭的描述，稱為Statement Program Prologue。Prologue提供了解碼程序指令和跳轉到其他語句的信息，它包含如下字段，這些字段是以二進制格式順序存在的：
total_length | uword | 整個子項占用的字節(jié)大小，注意并不包括該字段本身 |
versio | uhalf | 該子項格式的版本號，其實也是整個DWARF格式的版本號，目前總共有四個版本。 |
prologue_length | uword | prologue的長度，不包括該字段及前面的兩個字段占用的字節(jié)數(shù)，即相對于本字段，程序語句本身的第一個字節(jié)的偏移量 |
minimum_instruction_length | ubyte | 最小的目標機器指令 |
default_is_stmt | ubyte | is_stmt寄存器的初始值 |
line_base | sbyte | 不同的操作碼，代表不同的含義，只影響special opcodes |
line_range | ubyte | 不同的操作碼，代表不同的含義，只影響special opcodes |
opcode_base | ubyte | 第一個操作碼的數(shù)值 |
| standard_opcode_lengths | array of ubyte | 標準操作碼的LEB128操作數(shù)的數(shù)值 |
include_directories | sequence | 目錄名字符序列 |
file_names | sequence | 源代碼所在文件名字符序列 |
這里用到的機器指令可以分為三類：
special opcodes | 單字節(jié)操作碼，不含參數(shù)，大多數(shù)指令屬于此類 |
standard opcodes | 單字節(jié)操作碼，可以包含0個或者多個LEB128參數(shù) |
extended opcodes | 多字節(jié)操作碼 |
這里不做機器指令的解析說明，感興趣的，可以查看參考文獻的內容。
通過.debug_line，我們最終可以獲得如下信息：文件路徑、文件名、行號以及起始地址。
最后我們匯總一下整個符號化提取的過程：
1、從ELF Header中獲知32bit或者64bit，以及大端還是小端，基于此讀取后面的內容
2、從ELF Header中獲得Section Header Table在文件中的位置
3、讀取Section Header Table，從中獲得.debug_line、.symtab以及.strtab三個section在文中的位置
4、讀取.symtab和.strtab兩個section，最后獲得所有function symbol的名稱、起始地址以及結束地址
5、讀取.debug_line，按照DWARF格式解析獲取文件名稱、路徑、行號以及起始地址
6、對比步驟4和5中獲取的結果，進行對比合并，形成最終的結果
參考文獻：
http://www.csdn.net/article/2014-12-30/2823366-Locate-Android-NDK
http://eli.thegreenplace.net/2011/02/07/how-debuggers-work-part-3-debugging-information/
http://www.sco.com/developers/gabi/latest/ch5.intro.html
http://www.dwarfstd.org/
另外有需要云服務器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內外云服務器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應用場景需求。
