rmin 发表于 2022-10-21 16:09

针对控制流平坦化进行ast反混淆时出现的死循环问题解决方案

最近在研究某里还有一些js加密算法中,经常会看到多层控制流平坦化混淆的方式,通过3层及以上的switch-case以及大量三元表达式来进行混淆,降低代码的可读性以及代码的调试。
后面通过渔哥的帖子还有哲哥的ast_tools的一键解混淆脚本有了一些思路。成功逆向了某里的140版本解密。
目前看最近某里的223版本的加密算法,又发现了新的反ast语法数的策略,我研究哲哥写的对控制流平坦化的思路是通过对控制流平坦化的所有分支运行情况进行遍历来进行代码拼接生成从上到下执行的代码。
但针对223的加密算法,出现了一种新的情况。针对控制流平坦化进行遍历的时候会陷入死循环,因为它使用了大量的不可能执行的分支来进行干扰。比如
cr = (a = (a = (b = 8 == b) * b) > -78) ? 4867 : 12642;
在上面的执行逻辑下,就cr=12642的情况就无法出现,但是在进行反控制流平坦化时,要对所有的分支进行遍历,这样就会陷入死循环。目前,没想到什么比较好的解决方案,我只能进行遍历测试在陷入死循环的地方进行手动剪枝。
不知道大家有什么好的想法可以交流一下。

悦来客栈的老板 发表于 2022-10-22 08:22

本帖最后由 悦来客栈的老板 于 2022-10-22 08:38 编辑

一个bool类型的数值的平方怎么也比 负数大吧。这不一眼就能看出

cr = 4867;

代码也是同样处理。

编写第一个插件将其还原成:

b = 8 == b;
a = b * b;
a = a > -78;
cr = a ? 4867 : 12642;

编写第二个插件,将其还原成

cr = 4867;

rmin 发表于 2022-12-1 09:41

悦来客栈的老板 发表于 2022-10-22 08:22
一个bool类型的数值的平方怎么也比 负数大吧。这不一眼就能看出

cr = 4867;


主要我在遍历控制流平坦化时 是没有去进行代码逻辑的判断的,而且他的方式不止布尔值数值平方这一种,还有移位等好多种方式。现在我是这么处理的,观察了很多这种混淆的方式,发现这种混淆方式他的变量名是固定的,就它定义的a,b这几个变量名,全文下来就是做这种混淆的事情,所以我直接按照变量名去删了这个逻辑

hxs1 发表于 2022-12-9 16:50

哪里有ast反混淆,教程,那种网站是混淆啊?
页: [1]
查看完整版本: 针对控制流平坦化进行ast反混淆时出现的死循环问题解决方案