大土豆安全笔记 | 污点传播追踪的后续
前两周说要找份工作，很多师傅都提供了很棒的机会，在这里小王谢谢您各位
有个村里的厂子很给力，四天完成了全部面试流程，四轮面试，一轮笔试加一个奇奇怪怪的测试，现在在审批Offer
但是我毕竟只有一个人，我也不是那种喜欢拿Offer到处去找其它厂Argue更高待遇的人，只能先来先得了
书接上文，如果遇到拥有分支的逻辑，我们是不能直接从头到尾执行的，需要先对目标方法构建基本块，遍历出所有的基本块执行路径，然后按照不同路径来进行运行环境的污染分析
举个例子，上面的基本块是入口，通过调用方法getIntent()和方法getStringExtra()对两个类变量进行污染，中间左边和右边两个基本块是if/else分支，左边简单输出了一个日志，右边将被污染的两个类变量置为空，也就是清除污染标记
在一次只能选择分支逻辑中一个基本块运行的情况下，我们会得到两种完全不同的污染环境
再次回顾下我们目前讨论的漏洞模型：startActivity()调用onCreate()形成污染环境，startActivityForResult()调用onActivityResult()，startActivityResult()里的关键方法使用到了被前者污染的数据
onCreate()在创造污染环境的时候，由于逻辑不同，会形成n条不同的执行路径，这n条路径会产生n种不同的污染环境
onActivityResult()运行在被污染的环境里，由于自身也有m条不同的执行路径，所以我们需要交叉运行n * m次
这里有部分逻辑可以优化，比如前者创造环境的时候，如果不产生被污染的类变量，那后续的分析就没有意义，同理，后者在使用污染环境的时候，那些不包含关键节点的路径，我们也没有必要进行分析，所以我们要交叉运行(n - x)*(m - y)次
基于以上思路我们实现具体的代码
[*] 开始进行交叉污染分析
[*] 污染环境 Lcom/wnagzihxa1n/simpletaintanalysis/MainActivity;->onCreate(Landroid/os/Bundle;)V
[*] 执行路径 ['basic_block_41efa3bbb2cee7758cf9b836e0c993e9', 'basic_block_ccf9f6b60e11e2ec9ae3f85bd2a0692a', 'basic_block_9e548c5545dcf322ba53f4c90b184ff7']
[*] 分析 Lcom/wnagzihxa1n/simpletaintanalysis/MainActivity;->onActivityResult(IILandroid/content/Intent;)V
[*] 执行路径 ['basic_block_5dd2bb5092cb701f0cb23e696f1e7d56']
[*] 执行路径 ['basic_block_41efa3bbb2cee7758cf9b836e0c993e9', 'basic_block_590e90c0006c484c24a82a85bdd90481', 'basic_block_9e548c5545dcf322ba53f4c90b184ff7']
[*] 分析 Lcom/wnagzihxa1n/simpletaintanalysis/MainActivity;->onActivityResult(IILandroid/content/Intent;)V
[*] 执行路径 ['basic_block_5dd2bb5092cb701f0cb23e696f1e7d56']
[!] ==========> 发现漏洞 <==========
[*] 污染环境 Lcom/wnagzihxa1n/simpletaintanalysis/MainActivity;->onActivityResult(IILandroid/content/Intent;)V
[*] 执行路径 ['basic_block_5dd2bb5092cb701f0cb23e696f1e7d56']
[*] 分析 Lcom/wnagzihxa1n/simpletaintanalysis/MainActivity;->onCreate(Landroid/os/Bundle;)V
[*] 执行路径 ['basic_block_41efa3bbb2cee7758cf9b836e0c993e9', 'basic_block_ccf9f6b60e11e2ec9ae3f85bd2a0692a', 'basic_block_9e548c5545dcf322ba53f4c90b184ff7']
[*] 执行路径 ['basic_block_41efa3bbb2cee7758cf9b836e0c993e9', 'basic_block_590e90c0006c484c24a82a85bdd90481', 'basic_block_9e548c5545dcf322ba53f4c90b184ff7']
把结果画在图里就是这个样子，这张图有不少缺点，比如入口没有标出来，污染的全局变量没有标出来，函数执行路径没有标出来，不知道方法onCreate()走的是哪个分支语句等等问题
简单的逻辑还好，手动看看就差不多了，如果出现了复杂的循环，是不是一下子压力就起来了
那大家都知道，有大土豆的地方，就有图论，绿色代表本次执行路径，红色高亮出污点传播路径
说到循环，如果使用存储基本块的方式来搜索所有的路径，大家觉得会不会出问题？
肯定是出问题的，比如当前搜索到了0x7c所在基本块，它有两个后继0x80和0x88，先搜索0x80，0x80所在的基本块后继是0x7c，但此时0x7c所在基本块已经被加入到搜索的路径里，再次进入就会产生环，所以搜索会回退，最后跳到0x88所在基本块，体现在搜索结果上就是循环体被错过了
学过图论的同学会很熟悉，就是带有环的有向图是不能直接做深搜的
那要怎么搜索呢？
大家可以思考一下，真的算下来也就多了一步，有的同学可能会想到Tarjan缩点，但这里可能不太方便，环缩成点，最后也得对环里的逻辑进行路径遍历
测一下前段时间TikTok一个任意私有组件越权调用导致的本地代码执行漏洞，虽然这个漏洞用控制流图或者方法调用关系图都能找到，但我想要的是能确定Sink方法参数可控
以上我们讨论的都是Intraprocedural Analysis，也就是过程内分析，不考虑任何的方法调用产生的影响，但实际情况下漏洞场景都比较复杂，尤其是客户端攻防发展到现在这个阶段，显而易见的漏洞几乎绝迹，所以Interprocedural Analysis就非常有必要了
过程间分析我这里不过多描述，具体实现比较简单
我写这个东西的时候也没有奔着一次性写完的想法去做，自己写测试样例，从简单到复杂，对照着AndroGuard生成的控制流图对比，哪里不对改哪里
目前来说，这一套框架是没有办法跟FlowDroid对比的，因为本身只是我零碎的一些想法，并没有太多学术基因和理论指导在里面，实现目的也不一样，所以对比运行速度，内存占比没什么意义，FlowDroid作为学术界相关领域非常具有指导意义的工具，是很值得我深入学习的，如果有时间我会很乐意将其中优秀的思想移植过来
关于Smali代码与Java代码的对应我可以简单提一下，Smali代码里有行数信息，使用Jadx的反编译接口就可以实现Smali代码与Java代码的对应了，我现在还是以扫描准确度为准，扫描报告界面美化的工作留到后面有时间再做
华为最近更新了智慧办公全家桶，我个人对这一套东西是非常感兴趣的，我不喜欢去追求极致的性能和性价比，我比较在意这个东西好不好看，能不能满足我的使用需求，价格虚高一些我无所谓
所以华为新推出的一体机我先列入观望列表，这个价格在承受范围之内，但也是需要看一下评测，如果有比较致命的缺陷就等下一个版本吧
打印机也完全击中了我的审美，之后一定会来一台
我接下来工作可能会有亿点点忙，就不会像之前更新的那么频繁，也有可能很长一段时间不会再更新了
但咱们可以技术交流嘛
关于技术交流，大家有问题可以发邮件找我，加我微信的话其实一年到头也不会说几句话，我这人又是社交恐惧，不太愿意花时间去吹水互捧维护关系，好友列表里一堆陌生账号我真的害怕
如果是技术讨论的邮件，我可以慢慢思考，不用担心需要及时回复的问题，可以把想法写的比较详细，我的邮箱地址：wnagzihxa1n@gmail.com