U Can’t Debug This
U Can't Debug This: Detecting JavaScript Anti-Debugging Techniques in the Wild
还是草稿，凑合着看
Abstract
1.恶意软件分析的重要性
2.反调试技术阻碍了我们的分析
3.引入了9种反调试技术，对其中6个进行了大规模研究
4.提出一种基于网站重放的新方法和JavaScript代码覆盖率的比较自动化检测剩余三个基于事件的反调试技术
Introduction
1.阐述浏览器本身代码量庞大，其中可能包含一些错误，说明检测和分析JavaScript代码的重要性
2.严重的混淆和运行时生成新代码的能力使得恶意JavaScript的完全静态分析是不可行的，依赖于动态测试和两者结合
3.我们可以手动分析调试，不过攻击者引入了反调试技术来干扰分析
4.反调试技术用于恶意目的，如一旦F12被打开，就会停止挖掘加密货币。另一个例子是记录信用卡信息的脚本，将其发送给攻击者的服务器，如果F12被打开就停止发送数据。这说明反调试技术已经在野外滥用它们，阻止安全研究人员通过手动分析它们。
5.本文中介绍了9种不同的反调试技术，并对这一现象进行了两项调查研究，反调试行为的代码分布差异很大，在某些网站上的分布更为普遍，如可以非法，恶意网站
6.我们对这些技术（反调？）严重程度最高的2000个站点进行了第二项研究。这项研究中，研究了三种复杂技术的存在，这些技术使用时序侧信道来分析网站是否处于调试状态
7.为了检测这些技术，使用了一种通用的方法，基于同一页面的多个确定性重放测量代码覆盖率。这种比较多个环境中记录的执行方法是本地可执行文件恶意软件检测领域的一个经过验证的方法[
Efficient detection of split personalities in malware(ndss10)，Barecloud: bare-metal analysis-based evasive malware detection（sec14），Detecting Environment-Sensitive Malware]
8.发现12%的可疑站点在分析下执行不同的代码
总结贡献：
（1）收集了9种反调试技术
（2）对其中6种技术使用我们的自动框架进行测量，评估其普遍性和严重程度
（3）基于网页重放和代码收敛对其中3种技术进行针对性调查研究
2 Background and Scenario
本节简要介绍了如何在浏览器中检查和调试JavaScript代码，然后是通用场景，然后是本文涉及的范围以及范围之外的内容
2.1Debugging JavaScript Code
2.2Threat Model and Scope
3Basic Anti-Debugging
3.1.Impeding the analysis 阻碍分析
3.2.Altering the analysis 改变分析
3.3 Detecting the analysis 检测分析
3.4.Systematization
我们检测基本反调试通过他们的四个属性：Effectiveness, stealth, versatility, and resilience.
Effectiveness？
stealth，隐蔽性,WIDTHDIFF是一种隐蔽性技术，尽管依赖于检测devtools可能没那么隐蔽。而TRIGBREAK可能更相反
versatile，通用性。一种通用的技术可用于实现许多不同的结果，而不是非常具体的东西。因此，MODBUILT 是一种通用技术，因为它可以将内置函数重新定义为其他任何东西，如果 DevTools 检测到，LOGGET 可以以许多不同的方式做出反应。
resilient，弹性，即使用户知道它的存在，也不容易规避弹性技术。例如，LOGGET 是一种弹性技术，因为没有很好的对策
而 DEVCUT 很容易通过使用菜单栏绕过。表 1 显示了我们针对每个技术的系统化的完整结果。由于从攻击者的角度来看，所有四个属性都是可取的，因此 WIDTHDIFF、LOGGET 和 MODBUILT 技术提供了最有潜力
4.Large-Scale Study of BADTs 基本反调试技术的大规模研究
前面提到的 devtools-detect 包以及 StackOverflow 上的问题已经表明了对反调试技术的一些兴趣，特别是在检测 DevTools 是否打开时。然而，到目前为止，还没有对这些技术在野外的流行进行全面的研究。因此，在本节中，我们将介绍一种全自动方法来检测上一节中的每个 BADT，并报告我们在 100 万个网站上测量的结果
4.1.Study I – Methodology
ShortCut
TrigBreak
ConClear
ModBuilt
WidthDiff
LogGet
4.2.Study I – Experiment Setup
对于我们的大规模研究，我们根据 2020 年 12 月 21 日生成的 Tranco 列表 [33] 访问了 100 万个最受欢迎的网站。我们在 22 Dec 上使用 Chromium 87.70.4280 启动了 80 个并行爬虫，并在以后完成了爬行 3 天
在每个页面上，我们的爬虫等待多达 30 秒的时间来触发负载事件，否则我们将站点标记为失败并移动。在加载事件之后，我们等待挂起的网络请求长达 3 秒，以解决更好地处理动态加载额外内容的页面。最后，我们在每个加载页面上停留另外 5 秒，因此采用 TRIGBREALK 或 WIDTHDIFF 等重复动作的技术有足够的时间触发多次。
5.Sophisticated Anti-Debugging
与迄今为止看到的 BADTs 相比，本章中以下复杂的反调试技术 (SADTs) 更加难以捉摸。他们使用侧通道来了解正在进行的分析，然后巧妙地改变网站的行为，即使它们被触发，否则保持休眠状态。
5.1 Timing-Based Techniques
5.2 Systematization II
使用与之前对基本技术的系统化相同的属性，我们现在查看表 5 中这些新引入的复杂技术。所有这些都是通用的，因为它们只检测分析的存在，并且不会阻止某些特征的使用。NEWBREADKis 更隐蔽但效率较低，因为根据用户的行为，它可能根本不触发。虽然如果禁用断点，MONBREADKstops 工作，但其他技术相当具有弹性，因为它们很难破坏，除非在代码中找到它们的确切位置
6 Targeted Study of SADTs 复杂反调试的针对性研究
在野外检测这些复杂反调试，检测它们的挑战是它们更加灵活，因此
6.1 Study II – Methodology
虽然这些SADTs在实现方式上有所不同，但它们仍然有一些共同点:他们试图找出它们目前是否被分析，然后表现相应。因此，一旦检测到分析，代码执行必须偏离默认的良性情况。如果我们以某种方式可以两次监视执行的代码，一次使用DevTools打开，一次关闭它们，然后比较这两个执行，我们将能够隔离SADT。因此，我们的方法基于两个概念：确定性网站重放和代码收敛
7 Discussion
7.2限制
完整性：无法确定本文包含了所有的反调试技术
误报：
漏报：
7.3未来工作
我们将我们的论文视为对 Web 上反调试世界的第一个尝试，其中我们量化了问题并提高了对这种现象的认识。然而，还有很多工作要做，特别是在可靠地检测先进的自我检查和部署有效的反制措施方面。
Advanced self-inspection
JavaScript environment to the C++
Countermeasures
一些提出的技术很容易绕过，例如，DEVCUT 只是阻止使用某些热键，而不是菜单栏来打开 DevTools。然而，就像阻止执行的 JavaScript 代码学习断点命中是一个更难的问题一样，正如我们在 MONBREADK 技术中看到的。这将只能通过修改浏览器及其底层 JavaScript 引擎本身来实现
冻结时间是一个特别困难的壮举，因为脚本也可以从远程服务器获取时间信息，从而轻松检测任何间隙或时钟漂移。