JS逆向实战：OB 混淆代码分析+快速绕过 OB 混淆的格式化检测的方法

发表于 更新于 分类于

大家好，今天来分享一个 OB 混淆的代码分析以及一种快速绕过 OB 混淆的格式化检测的方法。

OB 混淆

做逆向的小伙伴应该很熟悉 OB 混淆了，一般遇到 OB 混淆，我常用做法是抠出解密函数，使用 AST 将字符串解密出来，然后程序的逻辑基本上就能看懂了。再合并一些字符串，就可以根据逻辑对 OB 混淆进行删减了，主要是反调试的删减，只保留业务逻辑的部分。后续可以根据业务逻辑写出请求代码或者抠出加解密方法进行远程调用。

但是有的时候遇到比较复杂的逻辑或者多个 JS 之间有相互调用，静态分析无法了解所有的逻辑，这时就需要在浏览器调试 OB 混淆。

但是 OB 混淆有格式化检测，一旦 AST 解混淆后的代码被替换到浏览器中或者控制台被打开，浏览器会直接崩溃或者不断地跳 debugger，严重影响调试。

image-20250409214427866

image-20250409214514689

猿人学的 match14 题就是上面这样的反调试，本篇文章以此为例，讲一下如何去除反调试并且绕过格式化检测。

AST 解密

image-20250409214856136

原始的代码是这样的，字符串是十六进制的格式，并且字符串都被加密了。

image-20250409215051401

首先将十六进制的代码还原成正常的字符串，并做一些简单的处理，例如去除逗号表达式，这样可以使代码更加易于分析。

image-20250409215210326

然后使用 AST 将字符串解密，解密后可以看到一些正则表达式，并且代码的逻辑也比之前清晰了许多。

image-20250409215415715

将代码折叠后可以看到整体的逻辑就是一些自执行函数和两个 window 属性的赋值，注意这两个属性赋值，后面会说到。

到这里 AST 能做的基本上就做完了，因为字符串也已经还原，可以根据具体的代码来分析反调试逻辑了。

反调试

image-20250409215822089

这个函数看起来会不停地调用 debugger 语句，看起来是反调试，并且上面还有一个死循环，可能会导致浏览器卡死，经过分析可以删除。

image-20250409220005770

这个函数里面有 console，对 console 的一些方法进行了覆盖，这样就无法在调试的时候使用 console 输出日志，可以删掉。

image-20250409220345858

这里使用正则判断了自增运算符和 function 关键字，匹配的是上面删除的 $_0x4feea2 函数的返回结果，如果不匹配则会调用 $_0x4feea2 让程序陷入死循环，可以删除。

image-20250409221406414

这个函数意义不明，暂时不确定是干嘛的，不过看起来也不是业务代码可以先删除。剩下的两个函数一个是 OB 混淆大数组还原函数，另一个就是解密函数了，格式化检测在两个函数里面都存在。

格式化检测

image-20250409221847046

先看字符串解密函数，很明显的正则表达式匹配，如果匹配上会返回索引 1 的值，如果匹配不上会返回索引 0 的值，如果这里被检测到，那后续的流程就会执行到一个死循环，直接卡死浏览器或者不停地执行一个 for 循环 push 数据直到 push 报错，这里是一个检测点。

image-20250409222447854

这里是另一个检测点，检测 removeCookie 函数是否被格式化，如果格式化的话下面会执行死循环逻辑，注意这里的 getCookie 和 removeCookie 其实和 cookie 没有任何关系，只是为了迷惑而起的名字。

绕过格式化检测

经过上面的分析，基本上 OB 混淆就算是解开了，因为格式化检测不太好修改，为了防止出现问题，这里我们选择绕过它。那应该如何绕过呢？

要想绕过它，先要直到它的原理，格式化检测的原理就是使用正则匹配函数的 toString 结果是否可以和预定的正则规则匹配上，如果匹配上则说明没有格式化，如果没有匹配上则说明代码被格式化了。

那反过来想想，既然我们格式化后一定会被检测到格式化，那我 hook 正则函数，让它每次都返回相反的结果不就好了？

也就是说我运行格式化后的代码，然后正则本应该匹配不上的，但是在正则的结果取反了，就变成了可以匹配，这样就可以绕过格式化检测了。

原理说完了，来试一下：

在代码的开头添加以下代码：

1
2
3
4
5
window=global;
const originalTest = RegExp.prototype.test;
RegExp.prototype.test = function(str) {
  return !originalTest.call(this, str);
};

因为是 nodejs 环境，没有 window，所以这里将 global 赋值给 window，防止报错。

image-20250409223130255

整体的代码就是这样的，现在来运行上面的代码，会发现不会卡死了，这样只需要添加几行代码就可以绕过 OB 的格式化检测了。

有效代码

删减到这里，可能有的小伙伴发现了，OB 混淆后的 300 多行代码中，真正有用的业务代码竟然只有最后这两行 window 属性的赋值语句，其他都是解密函数或者反调试代码！可见 OB 混淆的力度还是挺大的，也添加了足够多的反调试，调试起来难度不小。

注：上面的代码在猿人学联系平台上的难度为困难。

总结

分析到这里就结束了，文章中分析了一个难度为困难的 OB 混淆代码，大家可以根据以上思路来分析其他的 OB 混淆，这样以后在见到 OB 混淆时就不用怕了，感谢大家的阅读。

本文章首发于个人博客 LLLibra146’s blog

本文作者：LLLibra146

更多文章请关注公众号 (LLLibra146)：LLLibra146

版权声明：本博客所有文章除特别声明外，均采用 © BY-NC-ND 许可协议。非商用转载请注明出处！严禁商业转载！

本文链接：
https://blog.d77.xyz/archives/1a416200.html