因为iOS生态环境的封闭性，针对iOS APP的安全研究相比起针对Android APP来说要困难许多。今年USENIX Security上有一篇关于iOS APP中软件供应链安全的研究论文iHunter: Hunting Privacy Violations at Scale in the Software Supply Chain on iOS，让我们一起去读一下：
把时钟往回拨13年，在2011年的NDSS会议上有一篇分析iOS APP中隐私泄露的研究论文PiOS: Detecting Privacy Leaks in iOS Applications，当时大概是为了对标在2010年问世并且在后来被引用到冒烟的TaintDroid论文，但是在这个方向上继续深入可能技术难度有点大（举个例子，大量的Objective-C消息回调要处理），针对iOS APP的分析并没有在PiOS的基础上得到发扬光大，而Android那边像什么FlowDroid之类的工具不断问世，以及动辄就是针对整个Google Play市场上全体APP进行分析的研究比比皆是。所以每当有新的iOS APP安全分析的工作和大家见面，总是让人觉得有点期待。在今天的论文中，作者针对iOS APP广泛使用 的第三方SDK开展了代码分析，我们接下来就介绍研究工作的细节。
和此前的研究工作不同，本文特别关注的是第三方SDK在APP中对用户隐私数据的访问和可能的滥用。对第三方SDK的分析有它的便利之处——不再需要去大规模收集和解密IPA文件，也有困难之处——传统的针对iOS APP二进制代码的数据流分析技术没法直接应用在SDK上，而且iOS升级了这么多代，学术界对于iOS系统API和隐私数据的关联信息可能都有点过时了，要进行数据流分析（特别是污点分析），source、sink之类的定义都要重新来过。
为了系统性研究第三方SDK的问题，作者首先把有隐私数据侵权问题的第三方SDK分为三类：
根本没提供隐私策略说明的；
隐私策略说明中没有明确说明用户数据是如何处理的；
访问其他第三方SDK收集的用户数据，且其他第三方数据SDK在Term of Service里面明确说明了不允许分享；
然后，作者开发了iHunter工具来解决这些问题，下面这个workflow示意图非常清晰明了，但是也太high-level了，我们后面继续关注一些有意思的细节。
首先，作者用了一系列的NLP技术来分析了Apple开发者文档里面60372页内容，发现里面总共提到了60153个允许开发者使用的public API；然后参考了USENIX Security 2019和2020的两篇论文({PolicyLint}: investigating internal privacy policy contradictions on google play 以及 Actions speak louder than words:{Entity-Sensitive} privacy policy and data flow analysis with {PoliCheck}），定义了什么是隐私泄露源API；最后定义了198个往外发数据的network API、138个往设备上存储数据的API以及62个其他类型的数据收集API作为污点分析的sink，从而支持后面要进行的数据流分析。
iHunter的数据流分析主要处理的是第三方SDK（编译后的可执行代码），这里面就涉及到要对二进制代码进行反汇编和反编译，除了基于Ghidra进行的二进制代码处理，作者还特别介绍了一种基于符号执行来帮助进行分析的技术，主要是为了去处理Objective-C和Swift的动态调用这种比较麻烦的情况（传统的分析遇到这种情况可能就会导致data flow中断）。这个符号执行技术主要参考了KLEE研究团队在USENIX ATC 2016上发表的论文Under-constrained symbolic execution: Correctness checking for real code中提到的Under-constrained symbolic execution技术，并且对于循环和函数调用进行了一定程度的简化，保证分析不会遇到状态爆炸。
在程序分析之后，作者参考了USENIX Security 2018年论文Polisis: Automated analysis and presentation of privacy policies using deep learning中的Polisis工具来分析SDK代码和隐私策略的一致性，然后对6401个iOS上常用的第三方SDK（从三个主要的来源——AppFigures、CocoaPods、GitHub——收集得到）开展了分析，经过分析，总共发现了2585（40.4%）个第三方SDK至少存在一种前面定义的隐私侵权行为，其中2436个存在第一种侵权行为，58个存在第二种侵权行为，45个存在第三种侵权行为。下图展示了这些SDK的用途分布情况：
在所有侵权行为中，比较有趣的是第三类行为——从别的SDK中“偷”数据的行为，下图就用可视化的方式呈现了这种类型的数据流动：
作者还更加细致地统计了不同类型的用户信息（敏感的和不敏感的）被这些SDK访问的情况，如下表所示：
最后，我们特别推荐一下论文的Table 3这种风格，把整个实验过程中各方面的数据都一起呈现，展示了工作量，非常清晰且能够冲击到审稿人的心灵！
论文：https://www.usenix.org/system/files/sec24fall-prepub-85-liu-dexin.pdf