紧接着上一篇，我们看下正常运行的结果

trace一下 call_doCommandNative_sig3

在tace.txt中搜索f1e7,e7f1发现没有匹配数据，改搜索e7，从匹配的trace文件从最底部往最前查找可疑点会发现

从w1=0xa6接着往上分析

接着双击x21往上找

双击x0往上找

双击0xbffff470往上找

IDA定位也可以看到代码

就一个简单算法，求和，取反，异或对照着直接译出来即可。算法输入参数就是v374，结合trace文件，我们可以打印下v374的0至23位，并找到对应的赋值点并编上号便于后面进行分析

①比较明显就是设置的固定值，我们从②开始分析

可以比较明显的发现和0x404d8220地址有关系，直接trace一下

定位到的位置是callJNI_OnLoad的时候操作的，所以也是固定值。

同样的追查流程找下③④也都是固定值，不想追流程其实也可以直接修改入参，这几个标注段基本都不会改变与入参无关。现在我们看下⑤直接定位到IDA赋值位置看一下

点进函数sub_120d8内部没有发现明显特征，转回来看下入参就会发现unk_56188有crc32的明显特征

百度或谷歌搜一下0x04c11db7

确定是CRC32之后我们在看一下另外两个入参

大概率能猜出是数据跟长度，拿出去试算一下

试算结果符合我们的猜测是标准的CRC32，在回过头来看下算法，分析trace会发现

通过0x4c11db7 算出0xedb88320，然后采用直接计算法计算CRC32值，下面是直接计算法部分的截图

分析完第一个算法我们接着往后，trace一下入参地址0x404ff000

结合trace文件定位一下发现是memcpy

我们继续trace地址 0x404d3330

根据地址可以定位到函数

再看一下函数体，找到可以看一下的数据可疑点byte_59080

打个断点看一下

大小端切换搜一下，最后搜0x05040706

搜到的项中有这么一项，应该不是明显的特征值，暂且先记录一下。我们在看一下函数输入参数

pkcs7填充，简单调试下会发现总共调用sub_25980三次，每次16个字节，一般这么玩的也就aes和sm4，sm4在app参数加密中用的比较少，结合前面的搜索结论大概率是aes，如果是aes还需要判断是ecb还是cbc，从入参看并没有看到类似的iv向量之类的，但是我们还是做一个试验看看，输入三组16字节数据

判断是ecb应该没错了，看了下其他几个入参并没有类似key的参数，怀疑是白盒aes，如果是白盒aes我们就需要找state块了。我们看一下函数部分代码，主要逻辑部分也就下面两个块

第一部分执行10次，第2部分执行9次，有点类似查表法的逻辑（字节转换 行移位 列混合），第一部分中sub24f48函数内容像是在变动赋值

找到了state接下来就是dfa攻击了，先修改一位试一下

前后数据对比，很明显第1，8 ，11， 14个字节不同，符合注入特征

现在修改为批量随机注入

批量跑完后，将存在文件中的数据用phoenixAES和aes_keyschedule处理下，具体可以网上搜索下用法，这里就不介绍了

算出key我们验证一下

白盒aes验证完了，现在我们继续往后，trace一下入参地址

按前面的分析方法一级一级分析最后会定位到

加上断点看一下

结合IDA可以定位加密函数

很明显0x6a09e667为sha256特征，搜索一下

在看下函数入参

大致调试一下可以得出结论a1未知，a2为输出，a3为输入HandsomeBro，a4为长度，a5、a6未知，按sha256试算一下发现明显对不上

[培训]科锐逆向工程师培训第53期2025年7月8日开班！