————————————————————————————————————————————————————————
《概覽》
tor 的源碼包可以從官網下載，可能需要預先利用其它=*翻^=*牆*軟件才能訪問該站點。分析 tor 源碼有助於我們理解當代最強大之一的
互聯網匿名、隱身、審查規避軟件的運作原理。
為了從整體上把握住程序的邏輯與功能，本系列會將源碼重要部分通過函數調用流程圖總結，以便站在設計思想的高度來考察 tor。
《約定》
當引用函數/結構體/宏/定義/聲明時，我會在圓括號內給出它所在源文件的完整路徑，必要時還會給出代碼行號，例如：
tor_main()（\tor-0.3.1.8\src\or\main.c）——3682
中間的路徑省略掉解壓至磁盤上的驅動器號，假定存放於根目錄下
源碼的版本為 0.3.1.8（引用代碼片段的截圖中也會在右下角給出完整路徑，以及代碼行號）
《要求》
tor 以 C 編程語言開發，故需要各位具備關於 C 的基本知識和開發經驗，才能有較佳的源碼分析體驗。
此外，tor 為了實現跨 OS 平台兼容性，源碼中經常出現 OS 相關的“條件編譯”代碼塊，因此也要求各位對主流操作系統的用戶態編程接口有一定程度的了
解。
《反饋》
由於本人知識水平有限，加上工作的關系，本系列內容可能存在謬誤之處，且會不定期更新。
歡迎反饋任何勘誤，或者加入行列提高分析進展，可在評論處提交自己感興趣分析的模塊和自己的分析博文 URL！
————————————————————————————————————————————————————————
tor 主程序的入口點從 tor_main()（\tor-0.3.1.8\src\or\main.c）開始，實際上它是被 main()（\tor-0.3.1.8\src\or\tor_main.c）所調用的。
把 main() 從 main.c 中分離的原因在於——其它實現單元測試的源文件（test_*.c）中的 main() 函數，就可以鏈接 main.c ，
因為后者中不存在同名的 main() 函數，不會產生名稱沖突。三者的關系請參考下圖：
首先來看 main()，它把調用 tor_main() 返回的整型值保存到局部變量 r 中，然后根據 r 的值來作出相應處理：
如果 0 <= r <= 255 ，則返回 r 的具體值到 main() 的調用者（通常會是負責初始化 Tor 進程運行環境的 CRT 啟動例程），否則返回 1。
進一步而言，tor_main() 的開頭部分就定義了一個整型變量 result，並初始化為 0， tor_main() 的內部邏輯會根據不同場景把
result 設定為相應的值然后返回給 main()。相關的代碼片段如下：
從上兩張圖可知，main() 把自己收到的兩個參數：argc（執行 tor 命令時的參數數量）和 argv（包含具體參數的列表/數組）原封不動的傳遞給
tor_main()，后者會在特定情況下用到這兩個參數，比如調用 tor_init() 時傳遞過去，而 tor_init() 的主要任務之一，就是通過解析 argv 中攜帶的命令行
參數信息，來按照用戶的意圖初始化 tor 系統。
關於 Tor 命令行參數字串與個數的傳遞部分流程，請參考下圖：
tor_main() 初始化自身的返回值后，我們遇到了第一個代碼條件編譯塊，它是與 Windows 平台相關的。塊中的內容僅在滿足
特定條件時才被構建為可執行代碼。相關的代碼片段如下：
對於 32 位 windows 平台，且沒有定義“當堆數據損壞時，終止進程的功能（HeapEnableTerminationOnCorruption）”，則按照
MSDN 文檔的描述，將其枚舉常量的值定義為 1
（HeapEnableTerminationOnCorruption 的作用是，假設 OS 的堆管理器檢測到由進程使用的任意堆中有錯誤，
堆管理器會調用 WER 服務[Windows 錯誤報告]，然后終止進程，該功能打開后，無法由進程關閉）
若已定義該功能，則調用 HeapSetInformation() ，為它的第二個參數傳入 HeapEnableTerminationOnCorruption，來打開該功能；
HeapSetInformation() 的第一個參數是到要設置的堆句柄，通常由 HeapCreate() 或 GetProcessHeap() 返回;
由於在此之前，tor_main() 並沒有創建堆，所以堆句柄為 NULL；從 Windows Vista 開始，默認就啟用了“低碎片堆”
（low-fragmenation heap，LFH），所以應用程序會使用或創建 LFH；關於 LFH，請參考：
https://msdn.microsoft.com/en-us/library/windows/desktop/aa366750(v=vs.85).aspx
注意，即便 HeapSetInformation() 調用失敗， OS 也會讓應用程序繼續運行，所以應該對 HeapSetInformation() 的返回值進行
檢測：如果無法打開該功能，則 Tor 進程應該返回失敗並退出——這正是源碼中所遺漏的邏輯。
例如，在 Windows 平台，更健壯的代碼如下：
1 BOOL bResult; 2 bResult = HeapSetInformation(NULL, 3 HeapEnableTerminationOnCorruption, 4 NULL, 5 0); 6
7 if (bResult != FALSE) { 8 _tprintf(TEXT("Heap terminate-on-corruption has been enabled.\n")); 9 } 10 else { 11 _tprintf(TEXT("Failed to enable heap terminate-on-corruption with LastError %d.\n"), 12 GetLastError()); 13 return 1; 14 }
上圖關鍵之處在於調用 SetProcessDEPPolicy()，永久打開 Tor 主進程的數據執行保護（DEP）功能，
因為 Tor 是一個網絡應用程序，需要通過網絡頻繁收發數據，程序中的任何編碼缺陷，都可能導致遠程代碼執行，所以
添加此一調用可以緩解緩沖區溢出/堆棧溢出攻擊造成的危害。
SetProcessDEPPolicy() 是位於 Kernel32.dll 中的 API 函數（參見相關 MSDN 文檔中的“系統要求”），
而 Kernel32.dll 采用“加載時動態連接”到 Tor 進程的內存映射中，所以首先要以 GetModuleHandleA() 取得該模塊的句柄，
（采用“運行時動態鏈接”的應用程序會調用 LoadLibrary/Ex()）
在成功獲取的前提下，以 GetProcAddress() 取得 SetProcessDEPPolicy() 函數的地址，將其賦給以“typedef”類型定義和
聲明的函數指針“setdeppolicy”，如能解析到該函數的地址，就可以直接通過調用 setdeppolicy 來“嘗試”打開 DEP。
為啥我要強調“嘗試”呢？
在較早版本的 Windows 中，通過 GetProcAddress() 來獲取 SetProcessDEPPolicy() 的地址會解析失敗，所以需要對返回的函數
指針進行檢查，如果為空，就不該，也無法對 Tor 主進程啟動數據執行保護（DEP）；另外，假使系統能夠解析到
SetProcessDEPPolicy() 的地址，而對它的調用失敗卻不會導致危險，所以無需錯誤處理，只管調用即可——就算無法
開啟 DEP，Tor 也要繼續運行下去，這就完全依賴於安全的編碼意識了。。。。。
而根據 MSDN 文檔的描述，為 SetProcessDEPPolicy() 的 DWORD 型參數 dwFlags 傳入 0x3
表明 PROCESS_DEP_ENABLE（0x00000001）與 PROCESS_DEP_DISABLE_ATL_THUNK_EMULATION（0x00000002）特性被同時打開，這與
源碼中的注解相符。
最后，PROCESS_DEP_ENABLE（0x00000001）標志的設定，意味着在整個 Tor 進程的生命周期內，都無法關閉 DEP（如果成功啟用）。
第一個條件編譯塊到此結束，其充分利用了 Windows 平台為應用程序提供的額外安全機制。
經過平台特定的代碼塊后，為了讓 Tor 進程在崩潰時轉儲棧信息，以便后續的調試分析？調用了 configure_backtrace_handler()
函數（\tor-0.3.1.8\src\common\backtrace.c），來配置回溯處理程序。相關的代碼片段如下：
configure_backtrace_handler() 接受一個指向字符常量的指針，這可以通過 get_version() 輔助例程獲取到 Tor 應用程序的版本信息。
configure_backtrace_handler() 首先調用宏 tor_free()（\tor-0.3.1.8\src\common\util.h——83），來釋放由 backtrace.c 靜態
分配的全局變量 bt_version，它是一個 NULL 指針，而 tor_free() 可以安全地釋放 NULL 指針，而且把它引用的內存位置也設為
NULL。
根據是否獲取到版本信息，它調用 tor_asprintf() 向控制台/shell 輸出相應的程序啟動信息，然后調用
install_bt_handler() （在同一份源文件內），並將其返回值傳遞給 tor_main()。
如果注冊崩潰回調函數失敗，install_bt_handler() 返回 -1；否則返回 0，最終通知 tor_main() 成功“掛鈎”！
閱讀 backtrace.c 我們可以了解到：如果沒有在編譯時指定 USE_BACKTRACE 選項，則 install_bt_handler() 僅僅只是返回 0 到
調用者——不會實際注冊回溯處理程序。否則，install_bt_handler() 將針對包含崩潰在內的一些信號
（SIGSEGV, SIGILL, SIGFPE, SIGBUS, SIGSYS, SIGIO），安裝一致的回溯處理程序 crash_handler()，
后者調用 backtrace() ，最終成生棧回溯信息。
這里我們要明確一點，當程序啟動並正常運行時，只會調用 configure_backtrace_handler() 與 install_bt_handler()；當程序
崩潰或收到上述六種信號之一，crash_handler() 與 backtrace() 就會被調用（因此后兩者才是 CallBack）。
我們可以從 crash_handler() 內部最后的 abort() 調用邏輯得證——只有在崩潰時才需要中止繼續運行。
相關的代碼片段如下：
上面的長篇大論用下面一張圖清晰地總結：
至此，我們解剖了 tor 程序入口點 tor_main() 中，到 configure_backtrace_handler() 為止的代碼意圖，但這僅僅只是開場白
而已，在后面的博文我將繼續分析與 tor 業務邏輯相關的代碼，這才是“干貨”所在！
（未完待續。。。。。。）