------ Tor（洋蔥路由器）匿名網絡源碼分析——主程序入口點（一）------

 

————————————————————————————————————————————————————————
《概覽》

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 業務邏輯相關的代碼，這纔是「乾貨」所在！

（未完待續。。。。。。）