反调试与风控对抗基础

本节目标

有些站点会「反调试」：检测到你开 DevTools 就卡死、或不停弹 debugger。

// 运行环境：Node.js 16+（无需依赖，仅演示逻辑）
// 运行：node jsr-l17.cjs（仅看逻辑，浏览器里另说）
// 常见反调试 1：无限 debugger
function antiDebug() {
  setInterval(() => { debugger }, 100) // 浏览器里会不停暂停
}
// 常见反调试 2：检测 DevTools 宽度差
function detect() {
  if (window.outerWidth - window.innerWidth > 200) console.log('DevTools 可能开了')
}
// 应对（浏览器）：对 debugger 那行下「条件断点 false」让它永远不暂停；
// 或直接用控制台把 antiDebug 函数置空覆盖

// 风控（如滑块、行为指纹）则更复杂，本质是「判断你是不是真人」
console.log('风控对抗属于进阶，且务必合规、仅用于自有系统调试')

合规提醒（再次强调）：反调试/风控分析只用于学习原理、调试你自己的系统。绕过他人产品的风控可能违反其服务条款甚至法律，请勿越界。

名词解释

反调试（Anti-Debug）：网站主动检测「你是否开了开发者工具 / 是否在调试」，一旦检测到就干扰你（卡死、无限暂停、跳转）。常见手段：检测窗口宽高差、定时 debugger、检测 console 被 hook。它是「防守方」增加你分析成本的手段。

风控（Risk Control）：网站判断「这次请求/操作是不是真人、有没有风险」的整套机制（滑块验证、设备指纹、行为轨迹、频率限制）。它比单纯加密更难逆向，因为很多判断在服务端、且依赖「真人行为特征」。逆向风控往往吃力不讨好且易违规，学习原理即可。

课后练习

练习 1：浏览器里遇到「无限 debugger」循环，怎么让它能跑又不暂停？

答案：在 debugger 那行下「条件断点」并设为 false（条件永假，断点不触发），或用控制台把setter/debugger 所在函数覆盖为空。也可在 DevTools 的「Never pause here」选项。核心是「让那条 debugger 不真正暂停」。

练习 2：为什么「风控」比「参数加密」更难逆向？

答案：参数加密的算法在前端 JS 里，你能抠出来复现；风控很多判断在服务端，且依赖「真人实时行为特征」（鼠标轨迹、设备指纹），前端没有完整逻辑，你复现不了「像人」的行为，且绕过易违规。所以难度和合规风险都更高。

总结

反调试与风控是逆向的「深水区」，我的态度非常明确：懂原理可以，动手越界不行。无限 debugger、DevTools 检测这类反调试，本质是「低成本的骚扰」，应对手段（条件断点、函数覆盖）也低成本，了解即可。但风控——滑块、指纹、行为判定——往往判断逻辑在服务端、且依赖真人特征，你既复现不了也容易踩法律红线。我的建议是：把这一节当「认知边界」来学，知道世界上有这些手段、它们大致怎么工作，但真要做产品级对抗时，先问合规。技术能力越强，越要清楚「哪里不能碰」。逆向的价值在「理解与学习」，不在「突破一切」。