------ 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 业务逻辑相关的代码，这才是“干货”所在！

（未完待续。。。。。。）