两年前刚学会AST的时候，就编写AST代码还原过某盾的混淆，但一直没有去尝试生成请求参数，测试接口，因为代码将近5000行，那时只会抠代码，忙于业务，疲于奔命，根本没有时间和精力尝试。但自从学会补环境技术后，效率大大提高，于是打算拿着补环境框架锤一下某盾的加密，顺带完善一下补环境框架。

在此之前和波哥讨论过某盾的设备指纹，波哥说会设备指纹会生成不同的加密版本，但其实逆向届有句名言，一个动态的事物，找到动态点之后，动态就会坍缩成静态。所以不管你怎么变，找到总有不变的地方，找到不变的地方，就好办了。在这里，不管你生成多少加密版本，你的检测点一般是不会变的，只要过了这些检测点，加密参数自然能通过校验。

拿到混淆代码，用AST技术还原控制流，再还原字符串，代码好懂很多。只能说这个混淆强度目前已经太容易了，两年前就能还原，现在更不在话下。这两年，AST技术经过蔡老板的推动，控制流混淆还原技术已经炉火纯青，除非加入vmp混淆，要不然一般控制流根本挡不住。

把还原后的代码放到补环境中跑起来，发现代码里使用了Promise异步, 这还是第一次遇到。于是去看看Promise的用法，再看看安佬的课件，再和大佬们讨论某盾后，知道了Promise是怎么一回事，也有了大致的方案。于是尝试生成签名，发现生成一直不正确，主要原因还是没法很好的处理Promise，短时间内估计以自己的能力找不到很好解决的办法，只好下场改加密代码，最终可以通过代码生成请求参数，调用接口取得tokenId。这就违背了补环境技术不改加密代码的原则，但因为平时也遇不到Promise，就先这么处理。

问过同事，这个接口其实作用不大，只有过了业务校验接口，才算真正的通过。那就此打住，不再进行下一步的尝试，意义不大。

这波测试下来，主要就以下几个问题

1. 一是代码的混淆强度不够，这种两年前就能搞定的混淆强度，放到现在根本不堪一击，在蔡老板的推动下，AST还原技术已经快人手必备了。必须得上vmp才行，vmp是真难搞，能力不强真还原不了。
2. 二是代码还是静态的，固定一份代码就行，一直能用，这就好搞很多了。所以还是得动态变化才行，让人没法固定。
3. 三是检测点不够多，还得针对补环境技术增加一些检测点才行

希望还在某盾做混淆的同事如果看到这篇文章，可以根据以上几点意见改进一下，等改进后再来测试一下。