监守自盗成常态？揭弊APP加固厂商盗取个人信息 (8月23日更新)
【编者按】
昨天（8月22日）本篇博客发布后不久，我们收到了文章提到的其中一家厂商的反馈，他们表示在其提供给APP开发者的《InfoBeat数据服务条款》第6.1.4条中已有如下声明：
“可以通过本公司提供给您的软件、插件或其他工具收集并存储的数据包括但不限于：SDK 或 API 版本，平台，时间戳，应用标识符，应用程序版本，应用分发渠道，开放性独立设备标识符 (Open UDID)，iOS 广告标示符(IDFA)，网卡(MAC) 地址，国际移动设备标示码 (IMEI)，设备型号，终端制造厂商，终端设备操作系统版本，会话启动/停止时间，语言所在地，时区和网络状态(WiFi等)。本公司还可能收集并存储以下数据：您最终用户在您的服务中的标示符，经度和维度，性别，年龄，用户触发的时间，错误和页面浏览量，还可能包含您最终用户的IP地址，设备类型，地区等信息。”
根据我们分析发现，该厂商收集的用户信息包括：wifi_ssid，链路速度，信号强度，网络状态，IP地址，wifi mac地址，网卡mac地址，系统版本，设备型号，经纬度，android_id，IMEI，IMSI，电话号码，CPU型号，CPU负载，剩余电量，屏幕分辨率，内存占用等。
国家互联网信息办公室近日公布的《信息安全技术移动互联网应用(App)收集个人信息基本规范(草案)》中明确说明“App不得收集与所提供的服务无关的个人信息”。该厂商所收集的以上数据明显已超出“与提供服务相关的个人信息”的范围。更何况，《InfoBeat数据服务条款》是加固厂商与APP开发商之间的协议，使用APP的用户事实上对其个人信息被收集的情况并不知情。因此，我们认为类似的个人信息收集情况被称为“盗取”并不为过。
有意思的是，今天我们发现已无法在该安全厂商的网页上找到InfoBeat数据服务条款的相关信息，相信该服务已被该厂商下架。
我们重申，任何厂商在收集用户个人信息时都应合法、合理、合规，征得用户同意，并对用户的隐私和数据安全负责到底！
移动互联网应用对用户个人数据的收集行为，几乎已是公开的秘密。市面上甚至出现了专职App打包黑产，通过破解和反编译apk文件，植入广告甚至病毒后，再将APP重新打包投入市场，造成用户的利益严重受损。
随着国家工信部对移动APP安全要求的日益提高，诸多提供App加固服务的厂商应运而生，成为移动应用研发工程师为APP进行安全加固最便捷的选择。
然而，这些高举“保护用户移动安全”旗帜的App加固厂商们，真的都如他们所描述的那样靠谱吗？
一次偶然的机会，我们注意到了一些不寻常的网络流量：
经调查，我们发现这些流量都来自某些著名的安全厂家的APP加固服务。更令人发指的是，这一切都发生在开发者及用户不知情的情况下。换句话说，原本应该为开发者和使用者提供安全服务的APP加固厂商，却监守自盗，暗地里进行着越权检测，成为了用户移动隐私安全的隐患！
由于用户无法得知自己下载的APP是否使用过加固服务，因此对其个人数据被盗取的情况几乎一无所知。而开发者也可能对其所选择的加固服务商缺乏深入研究，在不知情或强制授权的情况下，被加固服务商绑架，导致了用户移动安全出现漏洞。
为了更深入了解APP加固行业的现状，我们深入调查了目前市面上共6家主流的加固服务商，发现经其中2家加固过的移动应用具有数据收集行为。为了保证测试的准确性，我们编写了一个“Hello World”程序，赋予了其绝大多数的安卓权限，用于观察加固过的APP行为，但该程序本身的正常运行是不需要任何权限的，不具备任何有意义的功能，仅用作测试。
在第1家加固服务的后台页面，我们发现在其加固应用时，拥有数据服务的选项，尽管已经告知开发者会对数据进行采集与分析，但并没有直接的显式链接对该服务具体收集与分析的具体内容进行说明。
此外我们对网络数据包进行了分析，发现其收集了如下的设备信息：
wifi_ssid,链路速度,信号强度,网络状态,IP地址,wifi mac地址,网卡mac地址,系统版本,设备型号,经纬度,android_id,Imei,Imsi,电话号码,CPU型号,CPU负载,剩余电量,屏幕分辨率,内存占用等。
更为可怕的是，其中大部分信息是明文传输的，此外还周期性收集用户行为并加以追踪与分析。
而第2家的加固服务，在后台上传待加固的应用时，默认勾选了“加固数据分析”以及“崩溃日志分析”的选项，但我们在其用户协议中才得以找到其收集的信息范围，此时我们才发现，“应用盗版监测”这个选项是无法被取消的，协议中也隐晦的阐明了借由此功能收集用户的隐私数据。
在分析的过程中，我们也遇到了种种挑战，通过反编译加固过的app的manifest文件，并通过被修改掉的application信息来到保护壳的入口点：
原本的应用代码已经被隐藏了起来，无法通过简单的反编译获得原始代码，而异常的流量发起逻辑也不在其中，这里我们仅仅看到了根据不同的arch加载so库的逻辑，因此我们需要对so动态库libjiagu.so进行分析。
在libjiagu.so中，我们仍未找到可疑的请求的发起逻辑，且入口点的控制流程图极为可怕，显然针对我们的逆向行为做出了反抗：
但观察代码的构成，发现该so有着远多于代码段的数据段，这引起了我们的注意，并加以动态调试进行分析，但过程依旧没有那么顺利，我们的调试器在附加上应用程序后，APP自动退出了，显然还有反调试在作怪，在我们的逐步分析下，我们找到了以下反调试手段：
- 检测ida arm调试器的默认端口
- 代码执行时间检测（反断点调试）
- 调试器是否附加检测
- 父进程检测
- 文件dump检测
在绕过上述反调试手段后，我们发现数据段在经过一系列的解密解压后，是另外一个so动态库，而为了掩人耳目，该so使用了不寻常的加载方式——自实现linker加载，显然一个so的加载，离不开链接器，而自实现的linker作为so的loader，被加载的so的信息便不会出现在模块列表中。
同样的，原本的soinfo结构也被改写了，直接dump下来的so是无法被ida正常分析的：
通过对loader的分析与还原，我们最终提取出正确的ELF信息，并修复到了dump出来的so中，这种不落地式的内存加载方式有效的拖延了逆向分析所用时间。
我们也最终在核心的so中找到了这个请求的发起代码：
因请求是不对称加密的，无法被直接解密，我们尝试通过静态分析的方式找出请求所上传的内容：
上面的一些收集数据已经清晰可见，但由于数据量庞大，动态调试的过程又过于繁琐，因此我们接下来使用了hook技术，在适当的位置截获到了未加密的，用于上传的数据原文，发现与其用户协议中所描述的，仅取部分数据的“md5值”的说法并不相符，其实际收集的内容为：
Imei,Imsi,android_id,电话号码,iccid,dns_ip,所有的安装应用及其版本号,系统版本,设备型号,网卡mac地址,构建版本,内核版本,屏幕分辨率,wifi_ssid,链路速度,信号强度,IP地址。
此外每次启动应用时，在特定的条件下，均会上传用户所安装的所有应用的包名，版本号等信息。
到此为止，我们与棘手的保护壳过程对抗也告一段落了。
近日，全国信息安全标准化技术委员会发布了《百款常用App申请收集使用个人信息权限情况》以及《信息安全技术移动互联网应用(APP)收集个人信息基本规范(草案)》，更是表明了个人信息安全的重要性，以及整治不合规的用户信息收集行为。
我们始终认为，任何厂商在收集个人数据时，都应合法、合理、合规，并事先征得用户同意，同时应保证用户的个人信息安全，不使用明文传输，而使用不对称加密和安全链接的方式来保护传输过程中数据的安全。同时，我们也呼吁所有开发者提高安全警觉性，对其开发或使用的第三方SDK、代码、插件所加工、收集的数据有所了解，选用安全可靠的第三方服务商，对用户的隐私和数据安全负责到底。