摘 要：软件完整性校验广泛应用于反篡改防御，保护软件知识产权，防止盗版。因此，了解不同完整性校验方法的强度和弱点很重要。针对传统检测方法处理大规模数据时效率较低的问题，描述了一个基于Spark的大规模软件完整性校验行为识别框架。对于单个文件检测，使用后向污点分析识别可执行或者用来计算可执行位置值的内存位置，然后使用前向污点分析识别校验过程。该方法适用于多种不同完整性校验防御方案，提供的信息可以用来辅助绕过防御。实验表明，该方法可以有效识别常见软件完整性校验行为。
关键词：软件安全;软件反篡改;完整性校验;污点分析
DOI：10. 11907/rjdk. 191219
中图分类号：TP306文献标识码：A文章编号：1672-7800（2019）004-0046-04
0 引言
软件完整性校验广泛应用于软件防篡改保护技术中，其基本思想是对程序指令（或其它与指令相关的数据）计算一个哈希值，当且仅当这个哈希值与预期值相同时，程序才会正常执行[1-7]。任何尝试篡改代码的行为，如关闭或移除一个许可证检测，都会被完整性校验机制检测到，因而可用来防止盗版。衡量不同完整性校验机制的强度和弱点也是安全领域研究热点。
当前已有不少软件防篡改防御工作。Aucsmith[3]提出一种使用多重自修改和自解密代码块检测运行时代码完整性的校验方法;Horne 等[4]、Chang 等[6]讨论了一种使用校验过程网络的完整性校验系统，校验过程之间相互保护，要绕过这种保护，需要同时绕过所有校验过程，无疑增加了破解难度;Tsang 等[8]提出使用大量随机篡改响应的校验过程，通过多个版本函数使得每次程序运行不同代码;Cappaert等[2]、Wang等[9]则利用校验值作为密钥加解密程序，破坏程序完整性会导致解密过程生成错误代码。还有一些方法，如隐式设计篡改响应，使得攻击者难以从篡改响应回溯到校验验证代码[10]。也有通过隐式哈希方法检测代码执行效果是否符合预期，以判断软件是否被篡改[11]。文献[12]使用污点分析指令执行轨迹检测上述软件完整性校验行为。以上方法无法应付大规模软件分析，且存在误报率高的问题。
还有一些反篡改防御工作，通过一个可信的远程服务器完成完整性校验[1，5]。汤战勇等[13]提出一种进程级虚拟机软件防篡改方法，以虚拟指令方式融合校验、哨兵技术和反调试技術。这些方法超出了本文工作范围。
传统单机分析满足不了日益增长的软件发展趋势，亟需多机并行处理提高速度。鉴于此，本文将Spark与完整性检测算法结合，提出基于Spark的大规模软件完整性检验识别框。Spark作为当前最流行的大数据处理平台之一，一直受到各研究领域青睐[14]。如兰云旭等[15]将传统医学图像处理方法与Spark结合起来，提出基于Spark的并行医学图像处理方法;文献[16]和文献[17]利用Spark的机器学习库从海量数据中检测0day恶意软件。
借助Spark的大数据处理平台，本文框架可以较高效率地完成大规模软件的完整性校验行为检测。对于单个文件，检测方法使用动态信息流分析技术，识别软件中多种完整性校验行为。污点分析是二进制代码信息流分析的主要技术，用来追踪污点源与锚如何关联[18]。
本文方法将检测出完整性校验代码的一些关键信息，如：是否有完整性校验发生及被校验代码位置;发生创建的位置（如果校验代码是动态创建的）;计算出的校验值;比较校验值的代码位置;篡改响应机制（通过条件跳转、间接跳转，或者将校验值作为代码解压密钥）等。这些信息包含完整性校验的大量细节，并给出如何绕过完整性校验提示，同时可以指出某个完整性校验机制的弱点以及可能的补救措施。
1 检测框架
Spark操作对象称作弹性分布式数据集（Resilient Distributed Dataset，RDD）。本文框架最主要操作是围绕RDD进行Map/Reduce。
整体检测框架如图1所示。流程如下：
（1）将待检测可执行文件复制到共享空间，路径包装成RDD。
（2）对于每个可执行文件通过黑盒获取执行轨迹。执行轨迹记录程序运行时的指令及地址，执行轨迹可通过二进制插桩工具如Intel Pin Tool，或者基于虚拟机的Ether得到[19，20]，这一步相当于将可执行文件映射成执行轨迹。由于被检测程序可能不会自动关闭（如GUI程序），因此设置执行时间限制及轨迹文件大小上限。
（3）对于一条执行轨迹，搜集其中的已执行代码地址，然后均分成子任务，执行后向污点分析，Map得到污点源后，Reduce各个计算节点结果得到不重复的污点源。
（4）均分上一步得到的污点源，使用前向污点分析Map得到子结果，Reduce汇总过滤得到最后报告。
2 完整性校验检测
2.1 整体流程
一般来说，一个完整性校验首先通过包含代码或者用来创建代码（即脱壳）的内存计算一个值，然后用其影响后续要执行的代码。完整性校验检测本质就是搜索能够控制代码执行的自校验行为。
本文完整性校验检测方法包含如下步骤：
（1）后向污点分析。首先遍历轨迹，搜集已执行的内存地址，标记为污点。后向传播污点识别可能用来创建执行代码的内存地址。
（2）前向污点分析。从后向污点分析得到的污染位置开始，分析前向传播污点状态。
（3）识别完整性校验。这一步识别校验值验证指令，检查执行轨迹中的指令是否满足如下条件之一：①它是一个有污染操作数的控制转移指令;②它写入一个污染值到后续被执行的代码内存位置;③它传入一个污染值到系统输出函数，如printf（）。
然后，进一步分析这些验证指令，得到校验代码的额外细节。
2.2 污点分析
根据问题特点，本文用字节级别的污点分析。污点分析传播方向有前向（与控制流同向）和后向（与控制流反向）。在前向污点分析中，如果指令的源操作数是污染的，则其目标操作数也标记为污染。在后向污点分析中，如果目标操作数是污染的，则源操作数也标记为污染。
后向污点分析识别执行轨迹中已执行代码的源位置，也就是执行代码从这些源位置变化（或者不变化）而来。这个分析是保守的，即若指令目标操作数是污染的，则污染该条指令的所有源操作数，即使实际源操作数中只有一个是污染的。然后，将目标操作数标记为未污染。
2.3 识别完整性校验
首先，使用后向污点分析得到已执行代码的源位置，排除没有被任何指令读写的源位置。
其次，污染第一步得到的源位置，识别操作数被污染指令，对于能够影响程序行为的指令也污染。
第三，每一个能够影响程序行为的指令对应一些源位置，如果这些源位置数量超过（用户定义的）阈值θmin，则该指令被识别为完整性校验验证指令。
在x86中，函数调用通常被转换为push指令和call指令组合，这类call不读写污染的内存地址。为了处理校验值流向系统输出函数，对于call指令，若有其参数是污染的，则此指令也被认为是污染的。
如果被分析文件使用一些压缩工具，如UPX，代码是压缩的，则上述算法会有误报。阈值θmin用来减少误报。在解压缩中（即脱壳），被压缩字节序列会被复制到可执行位置或不可执行位置。不可执行的内存地址有可能会在前向污点传播中被检测到，从而导致误报，因此使用阈值θmin过滤掉这些误报。此外，本文还增加全局阈值θmax，如果被忽略的检测数量超过θmax，则会生成一个警告。
一个软件可以使用多个脱壳软件加密，而完整性校验可能发生在脱壳过程序列的任何一个点。但是，本文算法可以检测任意点的完整性校验。分析如下：
在算法第一步，Cn 中的指令地址以及Φi的代码地址都将被搜集并污染。因为Φn读取了Cn-1，Cn-1的地址也将会被污染。以此类推，所有Ci以及Φi都会被后向污点传播标记。假设校验发生在第k个脱壳步骤之前（1≤k≤n），被校验地址集合为C"k-1[？]Ck-1。
假设C"k-1=C"0，后向污点分析将污染C"0，因此C"0前向传播污点、CHECK（Ck-1）读取的C"k-1以及参与校验计算本身的值，都将被标记为污染。这使得参与完整性校验过程的值都将被污染，完整性校验也就会被识别。
本文方法需要处理大轨迹文件，在时空消耗上都会存在挑战。一方面，可以使用轨迹压缩技术减轻存储和I/O消耗[21]。另一方面，可以使用两个优化技术加速污点分析：消除非相关指令、使用并行处理技术。
可以通过预污点分析，减少前向污点分析中指令的数量，得到一个子轨迹，包含前向污点分析所有相关指令。这个子执行轨迹与原始执行轨迹进行前向污点分析效果是等价的。子轨迹通常远小于原始轨迹，因此可以显著提高性能。前向污点分析中，只读取指令轨迹文件，因此可以并行前向污点分析，可以通过均分污染源完成。
3 实验
3.1 实验配置
使用Intel Pin Tool记录执行轨迹[19]。实验使用5台机器搭建Spark集群，机器配置为：3.70 GHz Intel Core i7-8700K 處理器，32 GB 主存，Ubuntu 18.04;Spark版本为2.0.2;算法θmin、θmax分别设置为16和512。
测试集使用自行编写的各种完整性校验方案程序。在每一个程序中，修改MD5计算程序包含完整性校验。测试包含4种完整性校验。
（1）Horne等[4]、Chang等[6]所描述的多个完整性校验过程校验方案。其用于检测本文方法是否能够正确识别多个重叠的完整性校验过程。本组测试程序中分别有1个（1-guards）、4个（4-guards）、10个（10-guards）、50个（50-guards）完整性校验过程。
（2）Cappaert等[2]、Wang等[9]所描述的校验值作为代码解密密钥校验方案。其用于测试是否能够检测校验值验证和篡改响应使用动态代码修改影响程序执行，而不是使用一个显式的控制流转换到篡改响应。该程序称为decrypt-key。
（3）运行时在代码解压缩过程中进行完整性校验。测试能否检测被校验地址自身是不执行的，而是用来创建执行代码。测试程序中有100层解压缩，在偶数解压层有完整性校验。该程序称为100-layers。
（4）使用完整性校验值生成MD5初始化常数。计算出的MD5值通过函数printf（）输出到屏幕，MD5代码参见http：//people.csail.mit.edu/rivest/Md5.c，程序输入为中华人民共和国国歌歌词。该程序称为chksum-md5。
对于各组实验、插桩程序，在运行时报告被校验的内存地址范围与检测结果进行比较。为了测试集群性能，将上述测试分为若干份输入集群与单机器进行比较。
3.2 实验结果
测试集单份实验结果如表1所示，没有发现任何误报。图2 给出了集群性能测试结果，报告结果与单份相同。从图2可以看出，处理时间大致与份数成线性关系，符合预期。
3.3 精度分析
有重叠完整性校验程序，成功识别了所有完整性校验。不过，检测出的完整性校验代码范围小于实际。原因有两点：首先，本文分析的是指令执行轨迹，属于动态分析方法，而动态分析代码覆盖率低，不是所有被校验代码都会在运行时执行。其次，从已执行的内存地址开始分析，本身就会漏掉一些没有执行的内存地址（其可能会被完整性校验）。
在100-layers中，所有校驗过程被识别出，检测出的完整性校验都有相同校验范围。原因是在源代码中，被校验数据在某一层被变形和校验，然后立即传递到下一层脱壳。
对于decrypt-key，也是同样结果，完整性校验的关键指令和被校验范围被准确识别。
4 结语
本文描述了一种基于Spark的软件完整性校验检测框架。对于单文件检测，基于动态分析，使用后向污点分析识别可执行或者用来计算可执行位置值的内存位置，然后使用前向污点分析识别校验过程。实验表明，本文框架可以有效识别多种完整性校验行为。
本文方法的输入是指令执行轨迹，是一种动态分析方法。动态分析方法优势在于能够透明地处理反分析防御，如运行时代码自修改，但存在代码覆盖率低的问题，可以通过多路径探索技术解决[21]。第二个问题来自离线动态分析，大轨迹文件会带来显著的存储和处理消耗，可通过使用轨迹压缩技术解决[22]。本文方法虽然可以识别完整性校验，但不能自动转化为一个直接屏蔽完整性校验的方法。在对原型工具的测试中，手工验证了检测结果的正确性。但是，若校验代码是在不可预料的内存位置动态创建的，则验证识别会比较棘手。
本文关注动态完整性校验，却没有考虑静态完整性校验。原则上调整本文方法处理静态完整性校验并不困难，需跟踪库或系统函数调用，识别任何程序访问的文件，然后解析文件结构，识别读取文件操作。整合上述逻辑到原型工具将是下一步工作。
参考文献：
[1] AHMADVAND M，PRETSCHNER A，KELBERT F. A taxonomy of software integrity protection techniques[J]. Advances in Computers， 2019， 112： 413-486.
[2] CAPPAERT J，PRENEEL B，ANCKAERT B，et al. Towards tamper resistant code encryption： practice and experience[C]. Information Security Practice and Experience， 2008： 86-100.
[3] AUCSMITH D. Tamper resistant software： an implementation[C]. Information Hiding， 1996： 317-333.
[4] HORNE B，MATHESON L，SHEEHAN C，et al. Dynamic self-checking techniques for improved tamper resistance[C]. Security and Privacy in Digital Rights Management， 2002： 141-159.
[5] MARTIGNONI L，PALEARI R，BRUSCHI D. Conqueror：tamper- proof code execution on legacy systems[C]. Detection of Intrusions and Malware， and Vulnerability Assessment， 2010： 21-40.
[6] CHANG H，ATALLAH M J. Protecting software code by guards[C]. Security and Privacy in Digital Rights Management，2002：160-175.
[7] GIFFIN J T，CHRISTODORESCU M，KRUGER L. Strengthening software self-checksumming via self-modifying code[C]. Computer Security Applications Conference， 21st Annual， 2005：10-32.
[8] TSANG H C，LEE M C，PUN C M. A robust anti-tamper protection scheme[C]. Availability，Reliability and Security（ARES），2011 Sixth International Conference， 2011： 109-118.
[9] WANG P，KANG S，KIM K. Tamper resistant software through dynamic integrity checking[C]. Proceedings of the 2005 Symposium on Cryptography and Information Security，2005： 25-28.
[10] TAN G，CHEN Y，JAKUBOWSKI M H. Delayed and controlled failures in tamper-resistant software[C]. Information Hiding，2007： 216-231.
[11] AHMADVAND M，HAYRAPETYAN A，BANESCU S，et al. Practical integrity protection with oblivious hashing[C]. Proceedings of the 34th Annual Computer Security Applications Conference，2018： 40-52.
[12] QIU J，YADEGARI B，JOHANNESMEYER B，et al. Identifying and understanding self-checksumming defenses in software[C]. Proceedings of the 5th ACM Conference on Data and Application Security and Privacy，2015： 207-218.
[13] 汤战勇，郝朝辉，房鼎益，等. 基于进程级虚拟机的软件防篡改方法[J]. 华中科技大学学报：自然科学版，2016 （3）： 13.
[14] 张恬恬，孙绍华. 基于Spark的云计算平台在实验室的应用与实现[J]. 软件导刊，2018，17（4）：191-193.
[15] 兰云旭，王俊峰，唐鹏. 基于Spark的并行医学图像处理研究[J]. 四川大学学报：自然科学版，2017，54（1）：65-70.
[16] GUPTA D，RANI R. Big data framework for zero-day malware detection[J]. Cybernetics and Systems， 2018， 49（2）： 103-121.
[17] CHUPRAT S，ARIFFIN A，SAHIBUDDIN S，et al. Malware forensic analytics framework using big data platform[C]. Proceedings of the Future Technologies Conference， 2018： 261-274.
[18] 王蕾，李丰，李炼，等. 污点分析技术的原理和实践应用[J]. 软件学报，2017，28（4）：860-882.
[19] LUK C K，COHN R， MUTH R， et al. Pin： building customized program analysis tools with dynamic instrumentation[J]. ACM Sigplan Notices， 2005， 40（6）： 190-200.
[20] DINABURG A， ROYAL P， SHARIF M， et al. Ether： malware analysis via hardware virtualization extensions[C]. Proceedings of the 15th ACM Conference on Computer and Communications Security， 2008： 51-62.
[21] MOSER A，KRUEGEL C，KIRDA E. Exploring multiple execution paths for malware analysis[C]. Security and Privacy，2007： 231-245.
[22] BHANSALI S，CHEN W K，DE JONG S， et al. Framework for instruction-level tracing and analysis of program executions[C]. Proceedings of the 2nd International Conference on Virtual Execution Environments， 2006： 154-163.
（責任编辑：何 丽）
本文来源：https://www.sh-renlong.com/zhuantifanwen/gongwenfanwen/22331.html