接上篇,上篇最后说了要想请求通这个mpaas协议，请求头中的sign是必须的，本篇就来搞搞这个sign，虽然标题里有 AI分析，但是本篇的内容不涉及AI分析，本篇是使用 unidbg 模拟执行，跑出这个sign。

unidbg模拟执行

先把 unidbg 模拟执行的架子搭起来，代码如下

接着就需要往这个架子里面填 JNI 调用的方法，关于怎么在代码中跟踪到这个 JNI 的就不在这里说了，有兴趣的可以自己跟踪下，直接看这个生成sign的 JNI 方法，如下

接着就需要 Hook 这个方法，查看传入的参数和返回数据，可以使用算法助手直接 Hook，Hook 的内容如下

好，现在就可以在 Unidbg 中调用这个 JNI 方法了，代码如下

这里有一点需要注意：算法助手 Hook 的入参和返回值其中一部分是把字节数组转成 Base64 字符串了，在调用 JNI 方法，传递参数的时候要转回来，上面👆的代码中已经有体现了。我就在这里被坑了好久！！！

现在继续，调用这个 sign 方法，传入 Hook 的值

执行下，不出意外的出意外了

提示，找不到EdgeException类，那我们就补一下，代码如下

再次执行代码

很好，补环境有效，但是却出错了，抛出了异常，签名也没有返回！为什么会这样呢？这里就直接给答案了：因为没有调用初始化方法。 从JNI 方法的截图中也能看出蛛丝马迹，这里再看下之前的截图

再看下算法助手 Hook 的内容

可以发现在调用目标方法scpInvokeEvent前，就先调用了一次scpInvokeEvent�和 initSI 方法，第一次调用scpInvokeEvent�传的参数不一样，并且没有返回值，这里就按着这个顺序，在 Unidbg 中执行下，一个一个来，先调用第一个

main 方法成了这样

执行下

初始化了，依然没有签名，那就继续调用initSI这个初始化

继续执行

嗯，又需要补环境，就继续补

继续执行

继续补

继续执行

继续补

继续执行

继续补

好，到这里算是告一段落了，但是还是没出结果，再看日志

发现，这里在读取安装包，那就开始补文件

补了之后再次执行，你会发现又出错了

但是，这次有点不一样了，这次没有让补环境了，啥提示也没了！这可咋办呀！

现在来看下日志最开始的时候

这个 so 依赖android.so而android.so没有加载，那怎么加载这 so呢，unidbg 已经给我准备好了常用的 so，只需要一句代码即可

再次执行

好，现在又出错了，点击去看下

发现是 Arm64 没有实现AAsset_read�方法！直接抛出异常了，现在有两个解决方法：

1. 直接按照 32 的处理，将这类的异常改为return read(emulator, vm);�
2. 自定义一个AndroidModule类，再修改。

这里我选择的是方法 2，这样不会破坏原来的代码，将原来代码中的 AndroidModule 改成 FixedAndroidModule 就可以了

继续运行

又抛出错误了，同时多了几个文件读取，同样补一下文件

再次运行

已经出结果了🎉。

和算法助手 Hook 的返回值比较下，将这个签名 Base64 一下，发现和 Hook 的返回值相同

搞定，收工。

结语

unidbg 模拟执行出结果后，也尝试搞出纯算，能力有限，没搞定！有搞定的大神，可以指点下小弟！如果搞定纯算了，就还有后续文章，没搞定的话这个就是最后的一篇了。

这部分 unidbg 模拟的源码放在了知识星球，需要的自取。