混淆的 AES 解密程序集答案

【问题标题】：Obfuscated AES decryption assembly混淆的 AES 解密程序集
【发布时间】：2016-05-18 20:47:44
【问题描述】：

我最近一直在筛选整个程序集，试图确定程序如何解密某些数据。到目前为止，我已经确定了 IV 的提取方式，IV 的长度为 16 个字节，并且解密方法使用密码块链接。因此，我相信正在使用的加密方法是 AES-128-CBC。

下一步是尝试识别用于解密的密钥，问题是单个分组密码加密的程序集大小约为 2.5MB。然而，我观察到的是，它都是一个非常相似的形式，例如，sn-p：

add.w      r0, r12, #0x13
str.w      r0, [lr, #0x44]
tst.w      r0, #0xff
mov        r0, r12
it         eq
eoreq      r0, r12, #0x75

add.w      r1, r12, #0x5d
str.w      r1, [sp, #0xf00]
tst.w      r1, #0xff
it         eq
addeq      r0, #0x3b

r12 包含加密数据，从传入的参数 (r0) 加载，如下所示：

mov        r4, r0
add.w      lr, sp, #0x1000
ldrb.w     r12, [r4]

子程序中的所有程序集都是示例形式，一些偏移量被添加到加密数据中，存储，针对0xff进行测试（总是 0xff) 然后执行一些操作，结果是 XOR、OR、ADD 或 MOV 影响另一个寄存器（在示例中为 r0）。

这在您看来是 AES-128，您是否同意加密被故意混淆以隐藏密钥？如果是这样，那么它是如何被混淆的，是否有可能找到密钥？

其他信息

Here's a link 到块密码加密子例程的完整 ASM 文件。

和this is a link 到使用 CBC 并调用主要问题中引用的上述子例程的子例程。

【问题讨论】：

我认为reverse-engineering 比security 更适用，但可以随时恢复。然而，我们确实需要架构标签。 PS：我通常很快就会投反对票，但这次不是我；）
@Jester 听起来不错。你已经清除了你的名字：P 如果它对我来说离题/广泛，我总是可以将它移到逆向工程或安全 SE。
我明白你的意思。是的，如果它保存了密钥，那么它基本上可以归结为混淆。
@Jester 我没有投反对票，但我注意到几乎有人对每个可以远程视为利用代码进行恶意目的的问题投反对票。我认为有人甚至发表了一篇关于此类反对票的元帖子。不管是同一个人，也许不是，但可以有相同的观点。
如果 AES 实现有展开的回合，你会期望重复。这很可能是因为它可以用来加速算法。

标签： assembly encryption arm aes reverse-engineering

【解决方案1】：

检查是否使用 AES 非常简单。
AES/Rijndael 使用了一个巨大的魔法常数表。
没有这些神奇的数字，AES 就无法工作。
您可以从任何参考实现中轻松收集这些数字；如果需要，请记住补偿大/小端（我总是检查两个变体）。

Rijndael 也是XOR 指令的重度用户，它不使用or，也不使用加法。

如果您想确认/排除 AES，请寻找神奇的数字。该例程必须从内存（磁盘）中某处的表中读取数字。它无法解码程序集中的数字，因为它使用明文/密文来查找数组中的数字并与之异或数据。

在寄存器中保存数字时不能这样做。

从我看到的程序集来看，它根本不像 AES。

仅使用代码审查测试 AES
对于 AES 的最佳测试（仅查看代码）可能是将其与 init_key 的参考实现进行比较。 AES 使用特定代码来初始化密钥，以便算法可以使用它。

您可以在此处找到 AES 参考源代码：https://tls.mbed.org/aes-source-code
（如果您更喜欢 C 语言，也可以在 Internet 上的任何地方找到）。

【讨论】：