技术文章

资产加密

资产可以加密，同时结合其他技术，例如类加密（在几个备受瞩目的应用程序中看到）和字节码混淆（控制流混淆、字符串加密、反射 API 访问）。随着大多数字节码混淆被自动清理，资产通过以下方式被访问：

该DecryptorFilterStream对象实现了TEA（微型加密算法）的变体，以实现简单性和出色的性能1着称。

假设加密和解密算法可能并不总是与这个相同，这似乎是合理的。此应用程序保护器在其保护层中广泛使用多态性，在保护阶段，加密原语可能是用户选择的，也可能是半随机选择的。

JEB 可以在整个代码中自动模拟并提取资产，事实上，这就是下一节中描述的加密类被提取以进行分析的方式。但是，此功能在当前的 JEB Release 版本中不存在。由于绝大多数用途都是合法的，我们认为此时为数据和代码提供一键式自动解密器是不必要的，并且会危及一些知名供应商的应用程序安全。

类加密

正如在最近的多个应用程序中所看到的那样，类加密的工作原理如下：

• 要保护的类CP, 被加密、压缩并存储在 app 文件夹内的一个文件中。（文件名是随机的，并且似乎以点结尾，尽管这很容易改变。）一旦解密，文件就是一个 JAR，其中包含一个持有 CP 和相关类的 DEX。

• CP 由自定义ClassLoader管理，CL.

• CL 也被加密、压缩并存储在 app 文件夹内的文件中。解密后，该文件是一个 JAR，其中包含一个包含自定义类加载器 CL 的 DEX。

• 在应用程序中，使用 CP 的代码（即任何加载 CP、调用 CP 方法或访问 CP 字段的客户端）被使用代码替换，该代码使用CM负责提取 CP 和 CL 并加载 CL 的类管理器。CM 为 CP 的客户端提供桥接方法，以实现原始功能。

下图总结了这种机制：

由于受保护的应用程序使用广泛的 RASP（运行时应用程序自我保护）工具来验证它们运行的环境，因此 CL 和 CP 的动态检索可能会很困难。在此分析中，它是由 JEB 静态检索的。

下面，一些客户端代码使用 CM 创建一个加密类对象 CP 并在其上执行一个方法。一切都是通过反射完成的。项目被重命名以提高清晰度。

CM 是一个重类，高度混淆。理解它的第一步是：

• 识别并重命名guard0/guard1字段，以允许混淆流的不透明构造被优化掉

• 禁用使视图混乱的捕获块的渲染。

启用自动解密和自动取消反射后，结果非常可读。以下是几个片段：

一旦检索到这些附加文件，就可以轻松地将这些附加文件“添加”到您的 JEB 项目的当前 DEX 单元IDexUnit.addDex()中。切换到终端片段，激活 Python 解释器 ( use py)，然后发出如下命令：

受保护的类 CP 和其他相关类，存储在“/f”中。包含... 防篡改验证码，这是 RASP 设施的一部分！在查看的其他实例中，受保护的类包含：加密资产管理器、自定义代码、API 密钥映射、更多 RASP 代码等。

全应用加密

“完全”加密通过对应用程序的几乎所有类进行加密，将类加密发挥到了极致。生成一个自定义Application对象，它只是重载attachBaseContext(). 在执行时，将调用加密的类管理器来解密并加载“原始”应用程序（所有其他保护措施仍然适用）。

请注意，活动也可以加密。在上述情况下，主要活动是加密 jar 的一部分。

结论

这就是第 2 部分的内容。我们专注于加密功能。两者都为愿意加倍努力检索原始资产和字节码的逆向工程师提供了相对有限的保护。