总结一下关于 JavaScript 反调试技巧方面的内容。本文的目的是收集与 JavaScript 中的反调试有关的小窍门(其中一些已经被恶意软件或商业产品使用)。
对于 JavaScript 来说,你只需要花一点时间进行调试和分析,你就能够了解到 JavaScript 代码段的功能逻辑。而我们所要讨论的内容,可以给那些想要分析你 JavaScript 代码的人增加一定的难度。不过我们的技术跟代码混淆无关,我们主要针对的是如何给代码主动调试增加困难。
本文所要介绍的技术方法大致如下:
- 检测未知的执行环境(我们的代码只想在浏览器中被执行);
- 检测调试工具(例如 DevTools);
- 代码完整性控制;
- 流完整性控制;
- 反模拟;
简而言之,如果我们检测到了 “不正常” 的情况,程序的运行流程将会改变,并跳转到伪造的代码块,并 “隐藏” 真正的功能代码。
函数重定义
这是一种最基本也是最常用的代码反调试技术了。在 JavaScript 中,我们可以对用于收集信息的函数进行重定义。比如说,console.log() 函数可以用来收集函数和变量等信息,并将其显示在控制台中。如果我们重新定义了这个函数,我们就可以修改它的行为,并隐藏特定信息或显示伪造的信息。
我们可以直接在 DevTools 中运行这个函数来了解其功能:
console.log("HelloWorld"); |
运行后我们将会看到:
VM127:1 HelloWorld |
你会发现第二条信息并没有显示,因为我们重新定义了这个函数,即 “禁用” 了它原本的功能。但是我们也可以让它显示伪造的信息。比如说这样:
console.log("Normalfunction"); |
如果一切正常的话:
VM84:1 Normalfunction |
实际上,为了控制代码的执行方式,我们还能够以更加聪明的方式来修改函数的功能。比如说,我们可以基于上述代码来构建一个代码段,并重定义 eval 函数。我们可以把 JavaScript 代码传递给 eval 函数,接下来代码将会被计算并执行。如果我们重定义了这个函数,我们就可以运行不同的代码了:
//Just a normal eval |
运行结果如下:
VM171:1 1337 |
通过这种方式修改程序流是一个很酷的技巧,但是正如我们在一开始所说的那样,它是最基本的技巧,很容易被发现并被击败。这是因为在 JavaScript 中,每个函数都有一个方法 toString(或 Firefox 中的 toSource)返回其自己的代码。因此,仅需要检查所需函数的代码是否已更改。当然,我们可以重新定义方法 toString /toSource,但是我们陷入了同样的情况:function.toString.toString() 。
断点
为了帮助我们了解代码的功能,JavaScript 调试工具(例如 DevTools)都可以通过设置断点的方式阻止脚本代码执行,而断点也是代码调试中最基本的了。
如果你研究过调试器或者 x86 架构,你可能会比较熟悉 0xCC 指令。在 JavaScript 中,我们有一个名叫 debugger 的类似指令。当我们在代码中声明了 debugger 函数后,脚本代码将会在 debugger 指令这里停止运行。比如说:
console.log("Seeme!"); |
很多商业产品会在代码中定义一个无限循环的 debugger 指令,不过某些浏览器会屏蔽这种代码,而有些则不会。这种方法的主要目的就是让那些想要调试你代码的人感到厌烦,因为无限循环意味着代码会不断地弹出窗口来询问你是否要继续运行脚本代码:
setTimeout(function(){while (true) {eval("debugger")}}) |
setInterval(function() {var a = new Date(); debugger; return new Date() - a > 100;}, 100); |
时间差异
这是一种从传统反逆向技术那里借鉴过来的基于时间的反调试技巧。当脚本在 DevTools 等工具环境下执行时,运行速度会非常慢(时间久),所以我们就可以根据运行时间来判断脚本当前是否正在被调试。比如说,我们可以通过测量代码中两个设置点之间的运行时间,然后用这个值作为参考,如果运行时间超过这个值,说明脚本当前在调试器中运行。
演示代码如下:
setInterval(function(){ |
DevTools 检测(I)[Chrome]:getter
这项技术利用的是 div 元素中的 id 属性,当 div 元素被发送至控制台(例如 console.log(div) )时,浏览器会自动尝试获取其中的元素 id。如果代码在调用了 console.log 之后又调用了 getter 方法,说明控制台当前正在运行。
简单的概念验证代码如下:
let div = document.createElement('div'); |
DevTools 检测(II)[Chrome]:大小更改
如果打开了 DevTools(除非将其取消对接打开),则 window.outerWidth / Height 和 window.innerWidth / Height 之间的差异将发生变化,因此可以循环检测。Devtools-detect 使用此技巧:
const widthThreshold = window.outerWidth - window.innerWidth > threshold; |
隐式流完整性控制
当我们尝试对 JavaScript 代码段进行模糊处理时,第一步就是开始重命名一些变量和函数,以阐明源代码。您只需将代码拆分为较小的代码块,然后开始在此处和此处重命名。在 JavaScript 中,我们可以检查函数名称是否已更改或保持相同的名称。或更准确地说,我们可以检查堆栈跟踪是否包含原始名称和原始顺序。
使用 arguments.callee.caller,我们可以创建堆栈跟踪,以保存先前执行的函数。我们可以使用此信息来生成一个哈希,该哈希将成为用于生成用于解密 JavaScript 其他部分的密钥的种子。这样,我们就可以对流的完整性进行隐式控制,因为如果重命名功能或要执行的功能顺序稍有不同,则创建的哈希将完全不同。如果哈希不同,则生成的密钥也将不同。如果密钥不同,则无法解密代码。为了更好地理解它,请参见下一个示例:
function getCallStack() { |
执行此代码时,您将看到字符串 #test1test2test3test4 。如果我们修改(我邀请您这样做)任何函数的名称,返回的字符串也将不同。我们可以使用该字符串计算安全哈希,然后将其用作种子,以得出用于解密其他代码块的密钥。有趣的是,如果由于密钥无效(分析人员更改了函数名称)而无法解密下一个代码块,则可以捕获异常并将执行流重定向到伪路径。
VM50:10 #test1test2test3test4 |
请记住,此技巧需要与强大的混淆功能结合在一起才能使用。
隐式代码完整性控制
在 “函数重新定义” 部分的结尾,我们提到可以使用 toString()方法检索 JavaScript 中函数的代码。就像我们说过的那样,这对于检查函数是否已重新定义很有用,实际上,可以使用相同的想法来知道函数的代码是否被修改。
效果较差的方法是计算函数或代码块的哈希并将其与已知表进行比较。但是这种方法确实很愚蠢。一种更现实,更有效的方法可以重复使用我们之前在堆栈跟踪中使用的相同策略。我们可以计算代码块的哈希值,并将其用作解密其他代码块的密钥。
创建隐式完整性控件的最漂亮方法是在 md5 中使用冲突。基本上,我们可以创建在自己的函数中测试其自己的 md5 的函数。为了在功能内执行检查,我们需要进行碰撞处理(我们想创建类似的东西 function(){ if (md5(arguments.callee.toString() === '<md5>') code_function; } )。
该技术背后的概念与用于生成图像文件的概念相同,在自己的图片中显示了 md5 校验和。这是一个经典示例:显示自己的 md5 校验和的 gif。
(注:本站的图片处理策略可能更改了图片 md5 值,点击查看原图 => 显示自己的 md5 校验和的 gif)
关于如何产生这种冲突,有大量的文章(甚至在 PoC || GTFO 中出现了一些示例),但是我阅读并可以复制的第一个文章是使用 PHP 编写的。您可以非常快速地预先计算生成碰撞所需的块。实际上,这是 @cgvwzq 创建的示例,通过这种方式检查了函数内容的完整性。
如前所述,我们需要对这种技术进行强力混淆。
代理对象 (old, 已弃用)
代理对象是目前 JavaScript 中最有用的一个工具,这种对象可以帮助我们了解代码中的其他对象,包括修改其行为以及触发特定环境下的对象活动。比如说,我们可以创建一个嗲哩对象并跟踪每一次 document.createElement
调用,然后记录下相关信息:
const handler = { // Our hook to keep the track |
接下来,我们可以在控制台中记录下相关参数和信息:
VM216:3 Intercepted a call tocreateElement with args: div |
我们可以利用这些信息并通过拦截某些特定函数来调试代码,但是本文的主要目的是为了介绍反调试技术,那么我们如何检测 “对方” 是否使用了代理对象呢?其实这就是一场 “猫抓老鼠” 的游戏,比如说,我们可以使用相同的代码段,然后尝试调用 toString 方法并捕获异常:
//Call a "virgin" createElement: |
信息如下:
"function createElement() { [native code] }" |
但是当我们使用了代理之后:
//Then apply the hook |
没错,我们确实可以检测到代理:
VM391:13 I saw your proxy! |
我们还可以添加 toString 方法:
const handler = { |
现在我们就没办法检测到了:
"function createElement() { [native code] }" |
代理对象
异常把戏不能再使用了。幸运的是,我们仍然可以通过 toString 长度检测代理对象的使用。例如,document.createElement
的大小为 42(Chrome):
document.createElement.toString().length |
另一方面,当我们创建代理时,此值将更改:
const handler = { |
因此,我们可以执行以下操作:
if (document.createElement.toString().length < 30) { |
此技巧不能在 windoww 对象中使用,但仍然有用。
限制环境
如引言中所述,我们想要做的一件事就是尝试检测代码是否在正确的环境中执行。
我们所谓的 “正确的环境” 是:
- 该代码正在浏览器(不是仿真器,不是 NodeJS 等)中执行。
- 该代码正在指定给它的域 / 资源中执行(不是本地服务器)
例如,我们可以用来证明代码是否在本地执行的简单检查是:
// Pretty stupid idea found in commercial software |
如果我们在本地 html 中运行此 JavaScript 代码段,则会看到以下消息:
VM28:3 Don't run me here! |
按照这个想法,另一个检查选项是用于打开文档的处理程序(类似 if (location.protocol == ‘file:’){…}),或者尝试通过 HTTP 请求进行测试,以确定是否有其他资源(图像,css 等)可用。当然,所有这些方法都非常容易被绕过。
如果代码是在 NodeJS 中执行的(或者正如我们在本文中提到的:将流更改为伪造的路径),则可以避免执行代码。这很危险,但是我在野外看到使用 NodeJS 来解决 JavaScript 挑战并绕过反暴力缓解措施。
我们可以尝试检测仅存在于浏览器上下文中的对象的存在:
//Under NodeJS |
反之亦然:在 NodeJS 中,我们具有浏览器上下文中不存在的对象。
//Under the browser |
我们可以搜索仅存在于浏览器中的大量元数据。我们可以检索到的一些此类想法可以在 Panopticlick Project 中看到。