学以致用 | APP瘦身新方案，安全加固在AAB框架下的探索之路

在 Google I/O 大会上，Google 推出了一项全新的动态化框架 Android APP Bundle (AAB)，这被认为是对 Android 未来发展具有颠覆性的解决方案。本文将从 AAB 动态化框架的优势入手，详细分析如何在 AAB 格式下实现高质量加固，并帮助移动应用在国内外市场之间自由切换，以提供更小而优质的应用体验。

架构图以AAB格式呈现

01 AAB应用的瘦身秘籍

与 APK 相比，Google 主推的 APP 打包格式 AAB 在许多方面都具有更出色的优势，主要体现在以下几个方面：

1.1. 动态分发

一个 APK 通常包含多国语言资源、ABI、屏幕密度等资源。然而，对于每个用户来说，通常只需要其中的一部分资源。

目前，国内的开发者普遍将所有资源集中在一个单独的APK文件中，这样会导致APK体积过大。然而，采用AAB格式则在压缩APK体积方面具有明显优势。

为了减小体积，一些开发者会有意缩减APK中的ABI目录。例如，他们会移除arm64-v8a的SO文件，只保留armeabi-v7a的SO文件。然而，这种做法导致64位CPU手机无法充分发挥其64位计算优势，并降低了程序运行速度。

从 Android 5.0 开始，引入了 Split APKs 这一多 APK 构建机制。利用 Split APKs，可以将一个 APK 根据 ABI、屏幕密度和 CPU 架构进行拆分，从而有效减少单个 APK 的大小。当用户下载应用程序安装包时，Google Play 会自动识别用户的语言和 CPU 架构，并自动向用户分发相应平台的 SO 和资源的 APK。

1.2. 动态功能模块 1.2 动态功能模块是指具有实时更新和交互性的特点。

在Android Studio中，新增了一个名为动态功能模块的模块。通过该模块开发的功能可以在用户需要时进行下载，类似于目前国内广泛使用的热更新机制。不同之处在于，热更新主要用于修复功能性BUG，而动态功能模块更倾向于形成一个独立的功能。

当用户安装 APK 时，他们只需下载一个包含 APP 主要功能的 APK 文件，而其他附加功能则可以在需要时进行动态下载和安装。这种方式进一步减小了 APK 的大小，并提升了用户在安装和使用 APP 时的体验。

AAB Reinforcement Solution 02

AAB 格式在给 Android APP 带来便利的同时，也给移动安全领域带来了新的挑战：AAB 格式的安装包，在组织结构和文件内容方面都与 APK 格式有较大差异，传统的 APP 加壳技术无法直接应用在 APP Bundle 模式生成的数据包之上。

经过对 AAB 格式的深入研究，易盾进行了一系列调整和改进，以支持新的 AAB 格式。

那么，当前的加固方案在兼容AAB格式方面遇到了哪些挑战？易盾是如何进行改进的呢？

2.1. 防二次打包

我们都知道，正常的APK在上传应用市场之前会提前进行签名。当破解者从应用市场下载APK后，他们必须对其进行重打包，并且需要修改APK的签名。然而，一般的防二次打包功能会验证APK的签名。如果APK的签名与原始签名不一致，那么APP将直接退出。具体如下所示：

而在加固过程中，防止二次打包的方案是通过预先读取APK中的签名内容来实现的。这些方案会使用加固前APK的签名特征作为校验标准，在APP运行时对APK的签名特征进行验证。如果运行时的APK签名特征与加固前的不一致，那么该APK将会直接闪退。

当使用AAB格式时，Google Play要求用户在下发APK时上传签名证书文件。换句话说，AAB格式无法直接进行签名，但可以尝试使用apksigner对APK进行签名。以下是输出结果：

观察到，apksigner 将尝试在根目录下查找 AndroidManifest.xml 文件。然而，由于该文件是以 AAB 格式存在，导致 apksigner 无法正确解析。

这一问题导致加固厂商无法正确获取 APK 的原始签名，进而无法有效实现防二次打包。那么，易盾是如何解决这个问题的呢？

大家都知道，Android在使用第一代签名工具时是采用的jarsigner而不是apksigner。而jarsigner是JAVA SDK中自带的用于对JAR包进行签名的工具。既然jarsigner可以对JAR和APK进行签名，那么是否也可以对AAB进行签名呢？

肯定的答案是，我们尝试使用jarsigner对AAB文件进行签名。签名后的AAB文件结构如下：

实际上，jarsigner是一种用于对ZIP格式压缩包进行签名的工具。不论是JAR、APK还是AAB，它们本质上都属于ZIP格式。因此，只要用户在应用加固之前使用jarsigner对AAB进行签名，加固厂商就能够准确获取到APK的签名特征。

2.2. 资源混淆

资源混淆是一种常见的技术手段，旨在减小 APK 的大小并保护其中的资源。

有些应用程序可能会将关键数据存放在res文件中，这使得破解者可以通过代码中资源的ID轻松找到相应的资源文件，并在不修改代码的情况下轻松修改APK的重要逻辑。然而，通过资源混淆，APK中的res资源名称将被修改为无意义的名称，从而使破解者难以轻易地找到与代码对应的资源文件。

通过对资源文件名进行混淆，将长文件名变为短文件名，从而实现 APK 的“瘦身”效果。根据每个 APK 的具体情况，经过资源混淆后可减小 1 至 N MB 的体积。

在 APK 中，所有的资源都被记录在资源索引文件 resource.arsc 中，具体如下所示：

然而，在AAB中，资源索引文件的格式和名称也发生了改变：

2.3. AndroidManifest.xml修改

尽管VMP方案和JAVA2C方案已经存在多年，但由于性能原因，目前市场上主流的加固方案仍然是DEX加固。VMP方案和JAVA2C只被用于核心类的保护。而DEX加固的基本原理是通过修改应用的入口Application来接管应用的启动逻辑，并在执行DEX动态加载等一系列操作后将程序逻辑还给APP的原始入口Application，具体如下所示：

图片展示了经过易盾加固后的入口应用程序。

有些粗心的开发者甚至会将APP的debuggable开关设置为true，这样一来APK就可以轻松地被调试。易盾在加固过程中会自动检测到这种情况，并将相应的开关改为false。

上述提到的数据都记录在 AndroiManifest.xml 文件中，而经过打包出来的 APK，其 AndroidManifest.xml 是经过编译之后的二进制格式，其中还涉及到一些和 APK 中的资源相关的数据，并不像开发阶段的明文那么容易修改，编译后的 AndroidManifest.xml 内容如下所示：

观察到，编译后的 AndroidManifest.xml 相较于开发阶段的版本，含有许多不可见字符。这些字符通常对应着一些数据结构。若欲进行修改，则需要对 AndroidManifest.xml 有深入的了解。

然而，AAB中的AndroidManifest.xml与APK中的AndroidManifest.xml相比，发生了一些变化。然而，原始的修改方案并不能直接复用。

Google并没有在文档中记录上述AndroiManifest.xml的变化。易盾在原有修改方案基础上，进一步研究了Android Bundle Tool的打包源码，并成功提取出了AAB中AndroiManifest.xml文件的格式，从而实现了对AAB格式中AndroiManifest.xml文件的修改。

2.4. DEX和SO的增强措施

实际上，在AAB格式中，DEX文件和SO文件的内容并没有被更改，只是它们在APK中的目录结构发生了变化。具体如下：

对这部分变化的兼容方式较为简单，我们只需要将相对应的文件抽离出来，重新按 APK 的目录结构组织成一个伪 APK。在加固之后，我们再将加固处理后的文件还原到 AAB 中，即可在不修改原有加固方案的前提下完美适配 AAB 格式。

03 总结

相对于APK格式，AAB格式在DEX和SO格式上并没有太多变化，这也使得保护DEX和SO的方案能够更轻松地迁移到AAB。

而其中较困难的地方在于，各种配置文件和资源文件的格式发生了较大的变化，导致原始的方案直接无法使用了。

易盾从用户的角度出发，充分考虑到广大出海应用的加固需求。他们积极对AAB格式进行适配，确保原有的加固方案能够完整地迁移到AAB格式上。这一举措助力应用安全地轻松适应各种改变。

标签： 格式 文件 资源 方案