Android APP 个人信息收集合规自查
2019 年 1 月，中央网信办、工业和信息化部、公安部、市场监管总局四部门在全国范围组织开展 APP 违法违规收集使用个人信息专项治理，并成立 APP 违法违规收集使用个人信息专项治理工作组。个人信息专项治理工作组就 APP 强制授权、过度索权、超范围收集个人信息、未制定并公开隐私政策、未经用户同意收集个人信息、未提供注销账号功能等不合规行为进行检查，并要求 APP 运营者及时整改，严格履行《网络安全法》中规定的责任义务，对获取的个人信息安全负责，采取有效措施加强个人信息保护。
APP 合规标准
如下所示，全国信息安全标准化技术委员会依据法律法规和国家相关标准，编制大众化应用基本业务功能及必要信息规范、APP 违法违规收集使用个人信息治理评估要点，APP 运营者需根据技术标准在企业内部开展自查。
依据各网络安全实践指南及技术检查标准要求，APP 运营者可从权限申请、插件集成、应用行为、流量检查开展技术自查，确保 APP 在处理个人信息时，合规、安全、高效。
APP 权限检查
Android 是一个权限分离的系统，利用 Linux 已有的权限管理机制，通过为每一个 APP 分配不同的 uid 和 gid，从而使得不同的 APP 之间的私有化数据达到隔离目的；与此同时，Android 在此基础进行扩展，提供权限机制对可执行的某些具体操作进行权限细分和访问控制。
1. 权限机制
在默认情况下，任何应用都没有权限执行会对其他应用、操作系统或用户带来不利影响的任何操作，包括读取或写入用户的私有数据、读取或写入其他应用的文件、执行网络访问、使设备保持唤醒状态等。
Android 应用必须请求权限才能访问敏感的用户数据以及某些系统功能。系统可能会自动授予权限，也可能会提示用户批准请求，具体取决于访问的功能。
2. 权限分级
普通权限
应用需访问其沙盒外部的数据或资源，但对用户隐私或其他应用的操作带来的风险很小。根据应用申请，系统安装时向应用 自动授予 权限，系统不会提示，用户无法撤销。
签名权限
根据应用申请，在应用安装时 自动授予 权限，当仅会在尝试使用某权限的应用签名证书为定义该权限 证书一致 时，才会授予。
危险权限
应用所需数据或资源涉及 用户隐私 信息，或者可能对用户存储的数据或其他应用的操作产生影响。危险权限必须由用户向应用 明确授予 权限；在用户批准之前，应用无法提供依赖于该权限的功能，Android 中的危险权限如下图所示
特权权限
SYSTEM_ALERT_WINDOW, 允许应用创建全局窗口，可在其他应用上层覆盖显示；通常应用于小窗播放、录频软件悬浮、音乐软件悬浮等桌面显示场景。
WRITE_SETTINGS，允许应用读、写系统设置。
3. 权限分组
若应用在权限组中没有任何权限，系统会向用户显示权限请求对话框，描述应用要访问的权限组，对话框不描述组内的具体权限。若应用已在相同权限组中被授予另一危险权限，系统立即授予该权限，不会与用户进行任何互动。
4. 检查方式
不一次申请多项，动态弹窗申请，明确告知目的
Android APP 目标 API（targetSdkVersion）不应低于 23，即 >= 23。Android 6.0 系统（API >= 23）之后，用户在 APP 安装时不会收到任何 APP 权限通知，当 APP 权限请求权限时，会出现权限申请弹窗；而在 Android 6.0 之前，系统在 APP 安装时自动向用户请求授予所有危险权限。
5. 参考清单
不同类型应用 APP 所建议的权限不一样
地图导航、网络约车、即时通信、网络社区、网络支付、新闻资讯、网上购物、短视频、快递物流、餐饮外卖
交通票务、婚恋相亲、求职招聘、网络借贷、房屋租售、二手车交易、运动健身、问诊挂号、网页浏览器、输入法
安全管理、旅游服务、酒店服务、网络游戏、在线影音、儿童教育、电子图书、拍摄美化、应用商店、网路直播
APP SDK 检查
APP 运营者应明确 APP 中所集成的 SDK 清单，同时需明确 SDK 收集使用个人信息的类型、方式，同时在 APP 隐私政策中向用户明确说明 SDK 清单、采集信息种类、采集信息目的及第三方插件的隐私政策。
1. 插件分类
根据 APP 中插件或第三方 SDK 业务功能，可进行如下分类，APP 运营者也可根据如下的 SDK 分类，从功能角度对 APP 中的第三方 SDK 开展自查
2. 插件检查
白盒检查
APP SDK 清单排查可采用白盒方式检查，可从 SDK 的分类、功能角度设计问卷并与产品、研发进行确认，几个关键点如下所示
根据各项业务功能，排查 APP 中可能存在第三方 SDK/插件
根据 SDK 分类，排查 APP 中可能存在的第三方 SDK/ 插件
黑盒检查
SDK 清单排查也可采用黑盒方式，通过反编译 APP 包体，通过识别反编译代码的目录结构，进一步梳理出第三方 SDK 清单，防止第三方 SDK 清单出现疏漏。
如下图所示，使用 AndroidStudio 反编译 APP，通过分析代码目录结构来识别 APP 中所集成的第三方 SDK
第三方 SDK 检测规则可如下所示
APP 行为检查
在梳理出 APP 中 SDK 清单之后，作为 APP 运营者仍需进一步确认自身业务代码或第三方 SDK 行为是否不合规，常见的不合规行为如下：
应用启动时，用户未同意隐私政策前，已有采集用户敏感信息行为；
应用采集敏感信息频率是否过高；
应用采集信息与隐私政策披露内容一致；
第三方 SDK 寄生于 APP 已申请权限越权采集敏感信息；
...
1. 系统架构
Android 操作系统是分层架构的，从下往上依次为 Linux 内核、HAL、系统 Native 库和 Android 运行时环境、Java 框架层以及应用层，每一层都包含大量的子模块或子系统，如下图所示
Android 本质是 Linux 系统，Android 进程本质就是一个 Linux 进程，针对 Linux 进程的 Hook，我们需先了解 Linux 进程启动过程。
2. Hook 检测
如下图所示，将 Android Linux 进程由外至内层的拆解：
最外层是 Linux 进程，进程链接了动态链接 SO 库，其中有标准 C 函数库、WebKit 库等；
Linux 进程运行 ART/Davlik 虚拟机，虚拟机包含 ClassLoader、对象管理、线程调度等，虚拟机为 Java 系统运行时环境；
应用若包含 Native 代码，Native 代码与虚拟机一起在 Linux 进程中运行；
虚拟机中，包含 Java FrameWork、Java 代码两部分；
Android 进程和其他进程交换数据，依赖 Linux 内核提供的 Binder、Socket 等；
通过修改不同的组件，可达到 Hook APP 行为的目的，进而实现 APP 行为的合规检查，不同的 HooK 点，方案的优劣也不同：
A 点，作用于 Java 层，反射、动态代理是虚拟机提供的标准编程接口，可靠性高，但只在 Java 层，只能通过替换对象达到目的，适用范围小；
B 点，作用于 Java 和 Native 之间的 JNI 接口调用，稳定性高，但只能 Hook Java 和 Native 之间的调用；
C 点，默认的双亲委派机制保证了 ClassLoader 总是从父类优先加载 Java Class，通过修改 ClassLoader 加载 Java Class 的 Path 路径，稳定性高，但需要提前编译好修改后的 Class 去替换，灵活性降低；
D 点，修改 ART/Dalvik 虚拟机，虚拟机为 Java 提供运行时环境，所有的 Java Method 维护在虚拟机 Map 中，每个 Java Method 均有 JNI 函数标记位，若 JNI 函数则去寻找对应的 Native 函数，通过 Hook 的函数改为 JNI 函数实现 Hook，Java 层所有的 Class 都可修改，灵活性高，但当 ART/Dalvik 发布大版本更新时，需要适配，稳定性较差；
E 点，Android 进程通过 dlopen 函数将 SO 读进当前进程中一个内存区域，当调用 SO 代码时，直接跳转到 SO 内存区域执行，SO 对外的函数表及函数地址都在内存中，通过修改函数地址，可 Hook 所有的 SO 函数，稳定性高，但替换后的函数签名要保持一致，只能 Hook SO 入口，无法 Hook 内部逻辑，并且 SO 调用出现内联调用时无法 Hook；
F 点，在目标函数执行区域插入 Jump 指令，使得 CPU 跳转到 Hook 的函数中，若 Hook 函数和目标函数签名不一致，需额外保存寄存器信息，跳转回原函数时恢复寄存器信息，Hook 实现需要处理细节较多，且因为直接修改 SO，和指令平台强相关，稳定性不高；
Xposed、Cydia、Frida 是常见 Hook 框架，3 个框架对比如下
3. 敏感 API
在对 Android APP 进行行为合规检查时，主要关注可直接采集用户敏感信息的 API 接口的调用，Android 系统部分敏感 API 如下图所示，包括定位、短信、WIFI 等信息获取
4. Hook 日志
如下为笔者在进行 APP 行为合规检查过程中 Hook 日志截图，从图中可看到某插件读取定位、WIFI 信息
如下图为某 APP 中集成的第三方插件，在插件功能使用结束后，仍发现其在周期性读取设备的 WIFI 信息，为违规行为
APP 流量检查
在对 APP 进行合规检查过程中，可以从 APP 的流量中进一步核查 APP 中所集成的第三方 SDK 、同意隐私政策前 SDK 行为等信息。为了检查 APP 流量，可通过使用 Android 系统代理功能，也可使用定制化修改第三方代理库来实现 APP 流量审查。
1. 系统代理
在 Android 系统中，若设备通过 WIFI 进行网络连接，可在 WIFI 设置中，通过设置其代理服务器的主机、端口来实现 Android 设备的流量代理，如下图所示；而同时可以在代理服务器主机上通过 Burpsuite、Fiddler 等软件开启 HTTP 或 HTTPS 代理服务，实现 Android APP 流量截取、审计。
使用 Android 系统代理，只能审查 HTTP 流量，无法审查 TCP 流量；同时如果 Android 应用代码中设置不使用 Android 系统代理，则无法审查对应代码中的 HTTP 行为。
2. SS 代理
为能全面检查 Android APP 流量，可通过 ShadowSocks 流量代理方案。在 Android 设备端安装 ShadowSocks 应用，并且设置选择只代理待审查 APP 流量；而在服务端，通过修改 ShadowSocks 服务端代码，自动将 APP 中所有的流量进行解析，记录 Android APP 的流量日志。
3. 检查日志
如下所示，笔者使用 SS 代理方案，通过检查 Android APP 中所有的流量日志，来检查 Android APP 是否存在境外流量。
通过分析流量日志，确认某 APP 由于访问了境外 Unity 某网站，导致 APP 行为不合规，在中国境外的数据，不能传输至境外，如需要传输至境外，需向监管部门申请、审批。
参考链接
1. 盘点Android常用Hook技术 [链接 https://zhuanlan.zhihu.com/p/109157321 ]