我最近一直在筛选整个程序集，试图找出程序如何解密某些数据。到目前为止，我已经确定了如何提取IV，IV是16字节长，并且解密方法使用密码块链接。因此，我认为使用的加密方法是AES-128-CBC。
下一步是尝试识别用于解密的密钥，问题是单个分组密码加密的程序集大小约为2.5MB。但是，我观察到的是它是一个非常相似的形式，例如，一个片段：
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进行测试（始终 {{1}然后执行某些操作，XOR，OR，ADD或MOV影响另一个寄存器（在0xff的示例中）。
这对您来说看起来是AES-128吗？您是否同意加密被故意混淆以隐藏密钥？如果是，那么它是如何被混淆的，是否可以找到密钥？
其他信息
Here's a link到块密码加密子例程的完整ASM文件。
和this is a link到使用CBC的子程序并调用主要问题中引用的上述子程序。
答案 0 :(得分：0)
检查是否正在使用AES非常简单 AES / Rijndael使用了一个巨大的魔法常数表 没有那些神奇的数字，AES就无法运作 您可以从任何参考实现中轻松收集这些数字;记得在需要时补偿大/小端（我总是检查两种变体）。
Rijndael也是XOR指令的一个非常重的用户，它不使用or并且它不使用加法。
如果您想确认/排除AES，请查找神奇的数字。例程必须从内存（磁盘）中的某个表读取数字。它无法解码程序集中的数字，因为它使用明文/密文来查找数组中的数字和xor数据。
将数字保存在寄存器中时，不能这样做。
从我所看到的只是看看装配它看起来根本不像AES。
仅使用代码审核测试AES
对于AES而言，仅查看代码的最佳测试可能是将其与init_key的参考实现进行比较。 AES使用特定代码初始化密钥，以便算法可以使用它。
您可以在此处找到AES参考源代码：https://tls.mbed.org/aes-source-code
（或者只是在互联网上的任何地方，如果您更喜欢C语言的另一种语言）。