f1yin9_0x5hark

------ 任何人对于内存的需求都不会超过 640k ------

My Links

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

(未完待续。。。。。。)

 

posted on 2018-03-13 21:26 f1yin9_0x5hark 阅读(...) 评论(...) 编辑 收藏