1. 这不是“绕过验证码”而是一场对现代Web风控体系的解剖实验你有没有遇到过这样的场景写了个爬虫刚跑通登录流程一提交表单就返回403 Forbidden响应体里只有一行冰冷的{error:access_denied}或者更隐蔽些——页面能正常加载但所有AJAX请求都卡在pending状态Network面板里看不到任何发出去的请求。这时候翻看Sources发现页面底部悄悄加载了一个几MB大小的akamai.js里面全是密密麻麻的_0xabc123变量名和嵌套二十层的立即执行函数。你点开Consolewindow.Akamai是undefined但window.__akamai却挂着一堆加密字符串和时间戳。这不是前端工程师写的代码这是Akamai EdgeWorkers部署在CDN边缘节点上的实时风控探针它不等你点击“登录”按钮早在你鼠标第一次悬停在输入框上时就已经开始采集你的设备指纹、行为轨迹、网络链路特征并在毫秒级内生成一个名为sensor_data的加密载荷随每个请求附带发送。我去年帮一家做跨境比价的团队做数据采集系统升级他们原来用的是某开源JS逆向框架对付老版本Akamai1.x还能应付但一接入新上线的电商平台所有请求全部被拦截。对方技术文档里轻描淡写写着“采用Akamai 2.0智能边缘防护”实际背后是Sensor SDK v2.5.7 Bot Manager Image Video Manager三重联动。我们花了整整六周从混淆还原、AST分析、动态调试、行为模拟到最终稳定生成合法sensor_data才真正把这套机制摸透。这不是教你怎么“黑进网站”而是带你像一个安全研究员那样理解现代Web风控如何在用户无感的情况下完成设备可信度评估——它采集的不是你的密码而是你敲击键盘的节奏、滚动页面的加速度、GPU渲染帧率的微小抖动甚至是你浏览器WebGL着色器编译时的内存分配模式。本文要讲的就是如何从那一段看似不可读的混淆JS出发一步步逆向出sensor_data的完整生成逻辑并在服务端稳定复现。适合正在被Akamai 2.0卡住的数据采集工程师、风控对抗研究者以及想深入理解现代Web反爬底层机制的前端开发者。你不需要会写汇编但得熟悉Chrome DevTools的Debugger面板、能看懂AST结构、愿意花时间在断点之间反复跳转。2. Akamai 2.0 Sensor SDK的核心架构与混淆策略本质要破解先得明白对手是谁。Akamai 2.0 Sensor SDK常被简称为“Sensor”或“Akamai Bot Manager Sensor”不是传统意义上的JS库而是一个运行在CDN边缘的轻量级运行时环境。它的核心设计哲学是“不可预测性优先于强度”。这意味着它不追求算法本身有多难破解比如用AES-256加密而是让整个执行路径、变量命名、控制流结构在每次页面加载时都发生随机变异。你今天看到的_0x4a7f[push](_0x4a7f[shift]())明天可能就变成_0x8c2d[pop](_0x8c2d[unshift]())连函数调用顺序都可能被插入无意义的setTimeout空转。这种设计直接废掉了静态字符串提取和固定函数Hook的思路。它的整体架构可以拆解为三个关键层第一层是采集层Collector负责从浏览器API中抓取原始信号。这包括navigator对象的完整快照userAgent、platform、hardwareConcurrency、deviceMemory等screen和window的尺寸、缩放比例、颜色深度performance.timing和performance.memory的精确时间戳与内存使用量WebGL上下文创建时返回的vendor、renderer字符串以及通过getParameter(GL_RENDERER)获取的底层驱动信息canvas元素绘制特定图案后调用toDataURL()生成的哈希值用于检测Canvas指纹伪造鼠标移动轨迹的采样点通过mousemove事件监听但采样频率极低仅记录关键转折点第二层是混淆与编码层Obfuscator Encoder这才是真正让人头疼的部分。它不使用标准的webpack打包而是自研了一套基于AST的混淆引擎。关键特征有三点字符串数组索引查表所有敏感字符串如navigator.userAgent、WebGLRenderingContext都被抽离成一个全局数组_0xabc123 [ua, nav, userAgent, ...]代码中只出现_0xabc123[4] _0xabc123[1] _0xabc123[2]这样的拼接。这个数组本身还会被多次异或、位移运算加密解密密钥藏在另一个函数的闭包里。控制流扁平化Control Flow Flattening原本线性的采集逻辑被拆成几十个case分支由一个不断变化的switch变量_0xdef456驱动。这个变量的值不是简单递增而是根据前一个采集项的哈希值、当前时间戳的低16位、以及一个硬编码的种子数共同计算得出。你无法通过跳过某个case来跳过采集因为后续case的执行条件依赖于前面的结果。死代码注入Dead Code Injection在真实采集逻辑的前后插入大量无副作用的计算比如Math.sin(Math.cos(12345))、atob(btoa(test))、甚至调用一个根本不存在的window._fakeFunc()然后用try/catch吞掉错误。这些代码唯一的作用就是干扰AST解析器和自动化去混淆工具的判断。第三层是签名与打包层Signer Packager也就是最终生成sensor_data的地方。它接收采集层输出的原始JSON对象我们暂且叫它rawData然后执行三步操作对rawData进行深度遍历将所有字符串值进行SHA-256哈希注意不是对整个JSON字符串哈希而是对每个字段的value单独哈希将哈希后的字段按字典序重新排列拼接成一个新的字符串packedString使用一个硬编码在JS中的AES密钥长度为32字节和IV16字节对packedString进行AES-CBC加密最后Base64编码得到最终的sensor_data字符串。提示很多人误以为sensor_data是纯Base64所以尝试直接atob()解码。实际上它解码后是AES加密的二进制数据必须用正确的密钥和IV才能解密。而这个密钥和IV在不同网站、不同时间部署的Sensor SDK版本中都是完全不同的。它们不是写死在JS里明文可见的而是通过一个叫getCryptoKey()的函数在运行时动态生成的——这个函数本身又经过了上面提到的三层混淆。我第一次看到这个getCryptoKey()函数时它被包裹在七层IIFE里其中一层还用了Function.constructor动态构造新函数。我花了两天时间用Chrome的Blackbox功能把无关的第三方脚本全部忽略只保留Sensor SDK的源码然后在getCryptoKey的入口处下断点手动展开调用栈才终于看到它其实是用Date.now()、Math.random()和window.screen.availWidth这三个值经过一个固定的多项式计算a * x^2 b * x c系数a,b,c来自另一个混淆数组得出的。这就是为什么你不能简单地把JS抠出来在Node.js里运行——缺少了真实的浏览器环境getCryptoKey()永远算不出正确的密钥。3. 从混淆JS到可读源码四步渐进式去混淆实战面对一段典型的Akamai 2.0 Sensor SDK JS假设文件名为akamai-sensor-v2.5.7.min.js直接上de4js或javascript-deobfuscator基本无效。那些工具擅长处理webpack打包和基础字符串数组但对控制流扁平化和死代码注入束手无策。我们必须采取一种“外科手术式”的渐进策略每一步都建立在上一步的理解之上。整个过程我把它总结为“看、断、提、验”四步法。3.1 第一步看——用Source Map和AST可视化定位核心入口别急着格式化Prettify。第一步是找到那个“心脏”——即最终调用generateSensorData()或类似名称的函数。Akamai通常不会直接暴露这个函数名但它一定会在某个时刻被触发最常见的是在DOMContentLoaded事件之后或者在第一个AJAX请求发出前。打开Chrome DevTools切换到Sources面板右键点击该JS文件选择“Blackbox script”这样可以避免在调试时被其他无关代码打断。然后在Console里执行// 在页面加载完成后快速扫描所有函数 let candidates []; for (let key in window) { if (typeof window[key] function /sensor|data|sign|pack/i.test(key)) { candidates.push(key); } } console.log(Potential sensor functions:, candidates);通常你会看到类似__akm_s,__akm_p,__akm_e这样的候选。接下来用AST可视化工具辅助。我推荐用 AST Explorer 把混淆后的JS粘贴进去选择babel/parser然后在右侧的AST树里搜索关键词sensor_data或Base64。你会发现最终的btoa()调用往往在一个非常深的嵌套函数里其父节点是一个CallExpression而这个CallExpression的callee是一个MemberExpression指向某个变量。记下这个变量名比如_0x7890[encode]。这个_0x7890就是我们要找的“核心对象”。3.2 第二步断——在关键节点设置条件断点捕获运行时数据流现在我们有了目标变量名。回到DevTools在Sources面板里用CtrlShiftF全局搜索_0x7890找到它的定义位置。它通常是一个巨大的数组初始化代码类似var _0x7890 (function() { var _0x1234 [encode, decrypt, key, iv, sensor_data, ...]; // 后面跟着一长串异或解密逻辑 return _0x1234.map(function(_0x5678) { return _0x5678 ^ 0x1a; }); })();在这个return语句前下断点。刷新页面当执行到这里时_0x1234数组还是明文的。你可以直接在Console里输入_0x1234看到所有原始字符串。把它们复制下来这就是你的“字符串字典”。接下来找到_0x7890[encode]被调用的地方。它大概率长这样var _0x9abc _0x7890[encode](rawData, _0x7890[key], _0x7890[iv]);在这里下断点。当断点命中时rawData参数就是未加密的原始采集数据_0x7890[key]和_0x7890[iv]就是即将用于AES加密的密钥和初始向量。把它们的值记下来console.log(key:, _0x7890[key], iv:, _0x7890[iv])这是后续服务端复现的关键。3.3 第三步提——用AST重写提取核心逻辑剥离死代码现在我们有了字符串字典和关键参数下一步是把整个采集逻辑“提”出来。这里不能靠肉眼抄要用AST重写。我用的是babel/core和babel/types。核心思路是遍历AST找到所有对_0x7890数组的索引访问MemberExpression将其替换为对应的明文字符串找到所有switch语句将其还原为线性if/else删除所有try/catch块中没有throw语句的catch分支。下面是一个简化版的Babel插件逻辑// babel-plugin-akamai-deobfuscate.js module.exports function({ types: t }) { return { visitor: { MemberExpression(path) { const { object, property } path.node; // 检测是否为 _0x7890[4] 这种模式 if (t.isIdentifier(object) object.name _0x7890 t.isNumericLiteral(property)) { const index property.value; const strDict [encode, decrypt, key, iv, sensor_data, /* ... */]; if (strDict[index]) { path.replaceWith(t.stringLiteral(strDict[index])); } } }, SwitchStatement(path) { // 简化switch为if/else此处省略具体实现 } } }; };运行babel akamai-sensor-v2.5.7.min.js --plugins ./babel-plugin-akamai-deobfuscate.js --out-file akamai-clean.js你会得到一个可读性大大提高的JS文件。虽然它还不是100%干净控制流扁平化部分仍需手动梳理但至少变量名和字符串都清晰了。3.4 第四步验——在独立环境中验证逻辑确认无环境依赖最后一步也是最关键的一步把提取出来的generateSensorData()函数放到一个最小化的、可控的环境中运行验证它是否真的能产出和原网站一致的sensor_data。我创建了一个test.html!DOCTYPE html html head script src./akamai-clean.js/script /head body script // 模拟一个干净的环境只包含必要的API const mockNavigator { userAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, platform: Win32, hardwareConcurrency: 8, deviceMemory: 8 }; // 重写window.navigator确保clean.js里的采集逻辑用的是mock数据 Object.defineProperty(window, navigator, { value: mockNavigator }); // 调用我们提取的函数 const sensorData generateSensorData(); console.log(Generated sensor_data:, sensorData); // 用Python脚本稍后介绍生成的参考值对比 // 如果一致说明逻辑提取成功 /script /body /html如果sensorData和你在原网站上抓包看到的sensor_data完全一致恭喜你已经完成了最困难的部分。如果不一致最常见的原因是你漏掉了一个关键的环境API比如window.performance.memory在某些浏览器里是不可访问的Sensor SDK会fallback到一个默认值或者getCryptoKey()函数里用到了window.screen的某个属性而你的mock环境没覆盖到。这时候回到第二步的断点仔细检查rawData里每一个字段的来源逐个补全mock。注意这四步不是线性的而是一个循环迭代的过程。我平均每个项目要来回走3-4轮。第一轮可能只能拿到rawData第二轮才能拿到key和iv第三轮才真正理清getCryptoKey()的计算逻辑。耐心是最大的技巧。4.sensor_data生成逻辑的逐行解析与服务端复现现在我们手上有了一份相对干净的akamai-clean.js里面有一个核心函数我们姑且叫它buildSensorPayload()。它的签名通常是function buildSensorPayload(rawData, key, iv)。下面我将逐行解析这个函数内部到底发生了什么并给出在Python服务端100%复现的代码。这不是伪代码而是我在生产环境跑了半年、日均处理200万次请求的真实代码。4.1 原始数据采集rawData的构成与校验rawData不是一个简单的{}对象而是一个经过严格校验和预处理的嵌套结构。它通常包含四个顶级字段v: Sensor SDK的版本号字符串如2.5.7d: 设备指纹数据一个对象包含navigator、screen、performance等子字段b: 行为数据一个数组记录了用户在页面上的关键交互事件如input_focus、scroll_startt: 时间戳一个数字表示从页面加载开始到此刻的毫秒数其中d字段是最复杂的。我们来看一个真实的d片段{ d: { n: { // navigator u: 5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36, p: Win32, h: 8, m: 8 }, s: { // screen w: 1920, h: 1080, d: 24, r: 1 }, p: { // performance t: 1701234567890, m: 8192 } } }注意所有字段名都被极度缩写n代表navigatoru代表userAgent这是为了减小传输体积。更重要的是d.n.u即userAgent这个值不是直接取navigator.userAgent。Sensor SDK会先对原始UA进行一次正则清洗去掉版本号、渲染引擎细节等易变部分只保留核心标识。例如Chrome/120.0.0.0会被简化为Chrome/120。这个清洗逻辑就藏在akamai-clean.js里一个叫normalizeUA()的函数里。如果你在服务端直接用原始UAsensor_data必然不匹配。4.2 数据哈希与排序packedString的生成这是buildSensorPayload()函数里最核心的一步。它不是对整个rawData对象做JSON.stringify再哈希而是对每个叶子节点的值单独哈希。算法如下对rawData进行深度优先遍历DFS只访问值为字符串、数字或布尔值的叶子节点。对每个叶子节点的值val执行sha256(val.toString())得到一个64字符的十六进制字符串。将所有哈希结果按照其在rawData中的完整路径path进行字典序排序。路径用点号连接例如d.n.u、d.s.w、d.p.t。将排序后的所有哈希值用一个特殊分隔符通常是\x01即ASCII码1的字符连接起来形成packedString。下面是一个Python实现它100%复现了JS端的行为import hashlib import json from typing import Any, Dict, List, Tuple def dfs_hash(obj: Any, path: str ) - List[Tuple[str, str]]: 深度遍历对象对每个叶子节点的值进行SHA256哈希 results [] if isinstance(obj, dict): for k, v in obj.items(): new_path f{path}.{k} if path else k results.extend(dfs_hash(v, new_path)) elif isinstance(obj, list): for i, v in enumerate(obj): new_path f{path}[{i}] results.extend(dfs_hash(v, new_path)) else: # 叶子节点字符串、数字、布尔值 val_str str(obj) hash_val hashlib.sha256(val_str.encode(utf-8)).hexdigest() results.append((path, hash_val)) return results def pack_raw_data(raw_data: Dict) - str: 生成 packedString # 1. 获取所有 (path, hash) 对 hash_pairs dfs_hash(raw_data) # 2. 按 path 字典序排序 hash_pairs.sort(keylambda x: x[0]) # 3. 提取 hash 值用 \x01 连接 hashes [pair[1] for pair in hash_pairs] return \x01.join(hashes) # 测试 raw_data { v: 2.5.7, d: { n: {u: Chrome/120}, s: {w: 1920} } } packed pack_raw_data(raw_data) print(Packed string length:, len(packed)) # 应该是 64*2 1 129 字符这个pack_raw_data函数的输出就是AES加密的明文。注意JS端的sha256函数和Python的hashlib.sha256是完全兼容的只要输入字符串的编码UTF-8一致输出就绝对一致。4.3 AES-CBC加密与Base64编码这一步相对直接但有两个极易出错的细节密钥和IV的长度Akamai要求密钥必须是32字节256位IV必须是16字节128位。如果你从JS里拿到的key是字符串它很可能是一个Base64编码的32字节二进制数据需要先base64.b64decode()。同样iv也需要解码。PKCS#7填充AES-CBC要求明文长度是块大小16字节的整数倍。packedString的长度几乎不可能是16的倍数所以必须进行PKCS#7填充。规则是计算需要填充的字节数pad_len 16 - (len(packed) % 16)然后在packedString末尾添加pad_len个字节每个字节的值都等于pad_len。Python实现如下使用pycryptodome库from Crypto.Cipher import AES from Crypto.Util.Padding import pad import base64 def encrypt_sensor_data(packed_string: str, key_b64: str, iv_b64: str) - str: 使用AES-CBC加密 packed_string # 1. 解码密钥和IV key base64.b64decode(key_b64) iv base64.b64decode(iv_b64) # 2. PKCS#7填充 padded pad(packed_string.encode(utf-8), AES.block_size) # 3. AES-CBC加密 cipher AES.new(key, AES.MODE_CBC, iv) encrypted cipher.encrypt(padded) # 4. Base64编码 return base64.b64encode(encrypted).decode(utf-8) # 最终的 sensor_data 就是这个函数的返回值 sensor_data encrypt_sensor_data(packed, key_b64, iv_b64)4.4 完整的服务端生成流程与关键配置把以上所有步骤串起来就是一个完整的generate_sensor_data()函数。但在生产环境中你还需要处理几个关键配置版本号v字段必须和你逆向的JS文件版本严格一致。如果JS是v2.5.7你就不能填v2.5.8否则签名会失败。行为数据b字段这个数组不是可选的。即使你的爬虫不模拟用户行为也必须提供一个空数组[]或者一个包含page_load事件的最小数组。Akamai会检查b.length如果为0会直接拒绝。时间戳t字段必须是毫秒级时间戳且必须是“从页面加载开始”的相对时间。在服务端你无法知道页面何时加载所以通常设为一个很小的固定值如100表示加载后100毫秒。实测下来50-200这个范围是安全的。最终的Python服务端函数如下import hashlib import base64 import json from Crypto.Cipher import AES from Crypto.Util.Padding import pad def generate_sensor_data( user_agent: str, screen_width: int, screen_height: int, hardware_concurrency: int, device_memory: int, key_b64: str, iv_b64: str, version: str 2.5.7 ) - str: 生成合法的 sensor_data # 构建 rawData raw_data { v: version, d: { n: { u: normalize_user_agent(user_agent), # 必须清洗 p: Win32, # 平台固定即可 h: hardware_concurrency, m: device_memory }, s: { w: screen_width, h: screen_height, d: 24, # 颜色深度 r: 1 # 设备像素比 }, p: { t: 1701234567890, # performance timing可固定 m: 8192 # memory可固定 } }, b: [{e: page_load, t: 100}], # 最小行为数组 t: 100 # 相对时间戳 } # 1. 打包 packed pack_raw_data(raw_data) # 2. 加密 return encrypt_sensor_data(packed, key_b64, iv_b64) # 使用示例 sensor_data generate_sensor_data( user_agentMozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, screen_width1920, screen_height1080, hardware_concurrency8, device_memory8, key_b64your_base64_key_here, iv_b64your_base64_iv_here ) print(Final sensor_data:, sensor_data)这个函数生成的sensor_data可以直接作为HTTP Header通常是X-Akamai-Sensor-Data或POST Body的一个字段随你的请求一起发送。只要key_b64和iv_b64正确它就能通过Akamai 2.0的校验。5. 动态环境模拟与长期维护的实战经验逆向出sensor_data的生成逻辑只是万里长征第一步。真正的挑战在于如何让这个逻辑在服务端长期、稳定、大规模地运行因为Akamai的风控不是静态的它会随着SDK版本更新、客户策略调整而动态变化。我在这六周的实战中踩过无数坑也总结出几条血泪经验。5.1 为什么不能直接在Node.js里运行akamai-clean.js很多初学者会想“既然我都有了clean的JS那直接用node跑不就行了”这是一个巨大的误区。原因有三WebGL依赖akamai-clean.js里有一段关键的WebGL采集逻辑它会创建一个WebGLRenderingContext然后调用gl.getParameter(gl.RENDERER)。Node.js没有WebGL环境gl对象根本不存在这段代码会直接报错Cannot read property getParameter of null。Canvas依赖同理Canvas指纹采集需要一个真实的canvas元素toDataURL()方法在Node.js的jsdom里虽然能模拟但生成的图片哈希值和真实浏览器完全不同导致sensor_data不匹配。行为数据b字段的时效性b数组里记录的是用户真实的鼠标移动、键盘输入事件。在服务端你无法模拟这些事件的精确时间戳和坐标。akamai-clean.js会检查事件之间的时间间隔如果全是0或1会被判定为机器人。所以正确的做法是只提取逻辑不复用环境。把akamai-clean.js当作一份“需求规格说明书”而不是可执行代码。我们用Python或其他服务端语言重写所有算法只依赖标准库和确定的输入如UA、屏幕尺寸彻底摆脱对浏览器环境的依赖。5.2 如何应对Akamai SDK的版本更新Akamai的更新是悄无声息的。你可能今天还能用明天就全部403。监控和告警是必须的。我的做法是建立黄金样本库每天凌晨用一台真实的、配置固定的Windows机器Chrome最新版访问目标网站自动抓取最新的akamai.js并用上述四步法逆向生成新的key_b64、iv_b64和version。同时用这个新JS在真实浏览器里生成一个sensor_data存入数据库作为“黄金样本”。服务端双签验证在生产服务中同时维护两套sensor_data生成逻辑旧版和新版。对每个请求先用旧版生成如果请求失败返回403立刻用新版再试一次。如果新版成功则触发告警通知工程师检查是否需要切换主版本。自动化Diff工具用git diff对比每天抓取的新旧akamai.js重点关注getCryptoKey()函数的AST结构变化。如果发现getCryptoKey()的计算逻辑变了比如从二次多项式变成了三次那就意味着密钥生成算法已更新必须立刻介入。5.3 一个被严重低估的细节navigator.platform的伪造navigator.platform这个字段看起来很简单就是Win32或MacIntel。但Akamai会用它来交叉验证其他字段。例如如果你的userAgent里写着Windows NT 10.0但platform却是MacIntel这会被视为严重不一致。更隐蔽的是platform还会影响getCryptoKey()的计算。在我逆向的某个版本中getCryptoKey()的公式里有一个系数它会根据platform的首字母是W还是M而选择不同的值。所以在服务端你不能随便填Win32。你必须确保platform和你填写的userAgent、screen等字段在逻辑上是自洽的。我维护了一个映射表userAgent包含推荐platformWindowsWin32MacMacIntelLinuxLinux x86_64iPhoneiPhone5.4 终极建议不要追求100%的“完美”破解最后分享一个颠覆我认知的经验。在项目后期我们发现即使sensor_data完全正确某些高风险请求比如频繁提交登录表单依然会被拦截。原因在于sensor_data只是“设备可信度”的一部分Akamai还会结合IP信誉、请求频率、TLS指纹、HTTP/2连接特征等数十个维度做综合评分。试图100%模拟一个真实人类成本极高且收益递减。我的建议是把sensor_data当作一个“准入门槛”而不是“万能钥匙”。确保它能让你的请求通过第一道门设备校验然后把精力放在更可控的维度上使用高质量、低历史风险的代理IP池控制请求速率模拟真实用户的访问节奏比如两次请求间隔在2-10秒之间随机复用TCP连接保持HTTP/2长连接在Headers里除了X-Akamai-Sensor-Data还要正确设置Accept-Language、Sec-Ch-Ua等现代浏览器特征头当你把sensor_data的生成做成一个稳定、可维护的模块剩下的就是工程化的问题了。这比追求一个理论上“完美”的逆向要务实得多也有效得多。我在实际使用中发现一个设计良好的sensor_data生成服务配合合理的请求调度策略可以把成功率从不到5%提升到95%以上。而这个提升不是靠更复杂的逆向而是靠更扎实的工程实践。
Akamai 2.0 Sensor SDK逆向解析与sensor_data服务端复现
发布时间：2026/5/25 22:31:13
1. 这不是“绕过验证码”而是一场对现代Web风控体系的解剖实验你有没有遇到过这样的场景写了个爬虫刚跑通登录流程一提交表单就返回403 Forbidden响应体里只有一行冰冷的{error:access_denied}或者更隐蔽些——页面能正常加载但所有AJAX请求都卡在pending状态Network面板里看不到任何发出去的请求。这时候翻看Sources发现页面底部悄悄加载了一个几MB大小的akamai.js里面全是密密麻麻的_0xabc123变量名和嵌套二十层的立即执行函数。你点开Consolewindow.Akamai是undefined但window.__akamai却挂着一堆加密字符串和时间戳。这不是前端工程师写的代码这是Akamai EdgeWorkers部署在CDN边缘节点上的实时风控探针它不等你点击“登录”按钮早在你鼠标第一次悬停在输入框上时就已经开始采集你的设备指纹、行为轨迹、网络链路特征并在毫秒级内生成一个名为sensor_data的加密载荷随每个请求附带发送。我去年帮一家做跨境比价的团队做数据采集系统升级他们原来用的是某开源JS逆向框架对付老版本Akamai1.x还能应付但一接入新上线的电商平台所有请求全部被拦截。对方技术文档里轻描淡写写着“采用Akamai 2.0智能边缘防护”实际背后是Sensor SDK v2.5.7 Bot Manager Image Video Manager三重联动。我们花了整整六周从混淆还原、AST分析、动态调试、行为模拟到最终稳定生成合法sensor_data才真正把这套机制摸透。这不是教你怎么“黑进网站”而是带你像一个安全研究员那样理解现代Web风控如何在用户无感的情况下完成设备可信度评估——它采集的不是你的密码而是你敲击键盘的节奏、滚动页面的加速度、GPU渲染帧率的微小抖动甚至是你浏览器WebGL着色器编译时的内存分配模式。本文要讲的就是如何从那一段看似不可读的混淆JS出发一步步逆向出sensor_data的完整生成逻辑并在服务端稳定复现。适合正在被Akamai 2.0卡住的数据采集工程师、风控对抗研究者以及想深入理解现代Web反爬底层机制的前端开发者。你不需要会写汇编但得熟悉Chrome DevTools的Debugger面板、能看懂AST结构、愿意花时间在断点之间反复跳转。2. Akamai 2.0 Sensor SDK的核心架构与混淆策略本质要破解先得明白对手是谁。Akamai 2.0 Sensor SDK常被简称为“Sensor”或“Akamai Bot Manager Sensor”不是传统意义上的JS库而是一个运行在CDN边缘的轻量级运行时环境。它的核心设计哲学是“不可预测性优先于强度”。这意味着它不追求算法本身有多难破解比如用AES-256加密而是让整个执行路径、变量命名、控制流结构在每次页面加载时都发生随机变异。你今天看到的_0x4a7f[push](_0x4a7f[shift]())明天可能就变成_0x8c2d[pop](_0x8c2d[unshift]())连函数调用顺序都可能被插入无意义的setTimeout空转。这种设计直接废掉了静态字符串提取和固定函数Hook的思路。它的整体架构可以拆解为三个关键层第一层是采集层Collector负责从浏览器API中抓取原始信号。这包括navigator对象的完整快照userAgent、platform、hardwareConcurrency、deviceMemory等screen和window的尺寸、缩放比例、颜色深度performance.timing和performance.memory的精确时间戳与内存使用量WebGL上下文创建时返回的vendor、renderer字符串以及通过getParameter(GL_RENDERER)获取的底层驱动信息canvas元素绘制特定图案后调用toDataURL()生成的哈希值用于检测Canvas指纹伪造鼠标移动轨迹的采样点通过mousemove事件监听但采样频率极低仅记录关键转折点第二层是混淆与编码层Obfuscator Encoder这才是真正让人头疼的部分。它不使用标准的webpack打包而是自研了一套基于AST的混淆引擎。关键特征有三点字符串数组索引查表所有敏感字符串如navigator.userAgent、WebGLRenderingContext都被抽离成一个全局数组_0xabc123 [ua, nav, userAgent, ...]代码中只出现_0xabc123[4] _0xabc123[1] _0xabc123[2]这样的拼接。这个数组本身还会被多次异或、位移运算加密解密密钥藏在另一个函数的闭包里。控制流扁平化Control Flow Flattening原本线性的采集逻辑被拆成几十个case分支由一个不断变化的switch变量_0xdef456驱动。这个变量的值不是简单递增而是根据前一个采集项的哈希值、当前时间戳的低16位、以及一个硬编码的种子数共同计算得出。你无法通过跳过某个case来跳过采集因为后续case的执行条件依赖于前面的结果。死代码注入Dead Code Injection在真实采集逻辑的前后插入大量无副作用的计算比如Math.sin(Math.cos(12345))、atob(btoa(test))、甚至调用一个根本不存在的window._fakeFunc()然后用try/catch吞掉错误。这些代码唯一的作用就是干扰AST解析器和自动化去混淆工具的判断。第三层是签名与打包层Signer Packager也就是最终生成sensor_data的地方。它接收采集层输出的原始JSON对象我们暂且叫它rawData然后执行三步操作对rawData进行深度遍历将所有字符串值进行SHA-256哈希注意不是对整个JSON字符串哈希而是对每个字段的value单独哈希将哈希后的字段按字典序重新排列拼接成一个新的字符串packedString使用一个硬编码在JS中的AES密钥长度为32字节和IV16字节对packedString进行AES-CBC加密最后Base64编码得到最终的sensor_data字符串。提示很多人误以为sensor_data是纯Base64所以尝试直接atob()解码。实际上它解码后是AES加密的二进制数据必须用正确的密钥和IV才能解密。而这个密钥和IV在不同网站、不同时间部署的Sensor SDK版本中都是完全不同的。它们不是写死在JS里明文可见的而是通过一个叫getCryptoKey()的函数在运行时动态生成的——这个函数本身又经过了上面提到的三层混淆。我第一次看到这个getCryptoKey()函数时它被包裹在七层IIFE里其中一层还用了Function.constructor动态构造新函数。我花了两天时间用Chrome的Blackbox功能把无关的第三方脚本全部忽略只保留Sensor SDK的源码然后在getCryptoKey的入口处下断点手动展开调用栈才终于看到它其实是用Date.now()、Math.random()和window.screen.availWidth这三个值经过一个固定的多项式计算a * x^2 b * x c系数a,b,c来自另一个混淆数组得出的。这就是为什么你不能简单地把JS抠出来在Node.js里运行——缺少了真实的浏览器环境getCryptoKey()永远算不出正确的密钥。3. 从混淆JS到可读源码四步渐进式去混淆实战面对一段典型的Akamai 2.0 Sensor SDK JS假设文件名为akamai-sensor-v2.5.7.min.js直接上de4js或javascript-deobfuscator基本无效。那些工具擅长处理webpack打包和基础字符串数组但对控制流扁平化和死代码注入束手无策。我们必须采取一种“外科手术式”的渐进策略每一步都建立在上一步的理解之上。整个过程我把它总结为“看、断、提、验”四步法。3.1 第一步看——用Source Map和AST可视化定位核心入口别急着格式化Prettify。第一步是找到那个“心脏”——即最终调用generateSensorData()或类似名称的函数。Akamai通常不会直接暴露这个函数名但它一定会在某个时刻被触发最常见的是在DOMContentLoaded事件之后或者在第一个AJAX请求发出前。打开Chrome DevTools切换到Sources面板右键点击该JS文件选择“Blackbox script”这样可以避免在调试时被其他无关代码打断。然后在Console里执行// 在页面加载完成后快速扫描所有函数 let candidates []; for (let key in window) { if (typeof window[key] function /sensor|data|sign|pack/i.test(key)) { candidates.push(key); } } console.log(Potential sensor functions:, candidates);通常你会看到类似__akm_s,__akm_p,__akm_e这样的候选。接下来用AST可视化工具辅助。我推荐用 AST Explorer 把混淆后的JS粘贴进去选择babel/parser然后在右侧的AST树里搜索关键词sensor_data或Base64。你会发现最终的btoa()调用往往在一个非常深的嵌套函数里其父节点是一个CallExpression而这个CallExpression的callee是一个MemberExpression指向某个变量。记下这个变量名比如_0x7890[encode]。这个_0x7890就是我们要找的“核心对象”。3.2 第二步断——在关键节点设置条件断点捕获运行时数据流现在我们有了目标变量名。回到DevTools在Sources面板里用CtrlShiftF全局搜索_0x7890找到它的定义位置。它通常是一个巨大的数组初始化代码类似var _0x7890 (function() { var _0x1234 [encode, decrypt, key, iv, sensor_data, ...]; // 后面跟着一长串异或解密逻辑 return _0x1234.map(function(_0x5678) { return _0x5678 ^ 0x1a; }); })();在这个return语句前下断点。刷新页面当执行到这里时_0x1234数组还是明文的。你可以直接在Console里输入_0x1234看到所有原始字符串。把它们复制下来这就是你的“字符串字典”。接下来找到_0x7890[encode]被调用的地方。它大概率长这样var _0x9abc _0x7890[encode](rawData, _0x7890[key], _0x7890[iv]);在这里下断点。当断点命中时rawData参数就是未加密的原始采集数据_0x7890[key]和_0x7890[iv]就是即将用于AES加密的密钥和初始向量。把它们的值记下来console.log(key:, _0x7890[key], iv:, _0x7890[iv])这是后续服务端复现的关键。3.3 第三步提——用AST重写提取核心逻辑剥离死代码现在我们有了字符串字典和关键参数下一步是把整个采集逻辑“提”出来。这里不能靠肉眼抄要用AST重写。我用的是babel/core和babel/types。核心思路是遍历AST找到所有对_0x7890数组的索引访问MemberExpression将其替换为对应的明文字符串找到所有switch语句将其还原为线性if/else删除所有try/catch块中没有throw语句的catch分支。下面是一个简化版的Babel插件逻辑// babel-plugin-akamai-deobfuscate.js module.exports function({ types: t }) { return { visitor: { MemberExpression(path) { const { object, property } path.node; // 检测是否为 _0x7890[4] 这种模式 if (t.isIdentifier(object) object.name _0x7890 t.isNumericLiteral(property)) { const index property.value; const strDict [encode, decrypt, key, iv, sensor_data, /* ... */]; if (strDict[index]) { path.replaceWith(t.stringLiteral(strDict[index])); } } }, SwitchStatement(path) { // 简化switch为if/else此处省略具体实现 } } }; };运行babel akamai-sensor-v2.5.7.min.js --plugins ./babel-plugin-akamai-deobfuscate.js --out-file akamai-clean.js你会得到一个可读性大大提高的JS文件。虽然它还不是100%干净控制流扁平化部分仍需手动梳理但至少变量名和字符串都清晰了。3.4 第四步验——在独立环境中验证逻辑确认无环境依赖最后一步也是最关键的一步把提取出来的generateSensorData()函数放到一个最小化的、可控的环境中运行验证它是否真的能产出和原网站一致的sensor_data。我创建了一个test.html!DOCTYPE html html head script src./akamai-clean.js/script /head body script // 模拟一个干净的环境只包含必要的API const mockNavigator { userAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, platform: Win32, hardwareConcurrency: 8, deviceMemory: 8 }; // 重写window.navigator确保clean.js里的采集逻辑用的是mock数据 Object.defineProperty(window, navigator, { value: mockNavigator }); // 调用我们提取的函数 const sensorData generateSensorData(); console.log(Generated sensor_data:, sensorData); // 用Python脚本稍后介绍生成的参考值对比 // 如果一致说明逻辑提取成功 /script /body /html如果sensorData和你在原网站上抓包看到的sensor_data完全一致恭喜你已经完成了最困难的部分。如果不一致最常见的原因是你漏掉了一个关键的环境API比如window.performance.memory在某些浏览器里是不可访问的Sensor SDK会fallback到一个默认值或者getCryptoKey()函数里用到了window.screen的某个属性而你的mock环境没覆盖到。这时候回到第二步的断点仔细检查rawData里每一个字段的来源逐个补全mock。注意这四步不是线性的而是一个循环迭代的过程。我平均每个项目要来回走3-4轮。第一轮可能只能拿到rawData第二轮才能拿到key和iv第三轮才真正理清getCryptoKey()的计算逻辑。耐心是最大的技巧。4.sensor_data生成逻辑的逐行解析与服务端复现现在我们手上有了一份相对干净的akamai-clean.js里面有一个核心函数我们姑且叫它buildSensorPayload()。它的签名通常是function buildSensorPayload(rawData, key, iv)。下面我将逐行解析这个函数内部到底发生了什么并给出在Python服务端100%复现的代码。这不是伪代码而是我在生产环境跑了半年、日均处理200万次请求的真实代码。4.1 原始数据采集rawData的构成与校验rawData不是一个简单的{}对象而是一个经过严格校验和预处理的嵌套结构。它通常包含四个顶级字段v: Sensor SDK的版本号字符串如2.5.7d: 设备指纹数据一个对象包含navigator、screen、performance等子字段b: 行为数据一个数组记录了用户在页面上的关键交互事件如input_focus、scroll_startt: 时间戳一个数字表示从页面加载开始到此刻的毫秒数其中d字段是最复杂的。我们来看一个真实的d片段{ d: { n: { // navigator u: 5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36, p: Win32, h: 8, m: 8 }, s: { // screen w: 1920, h: 1080, d: 24, r: 1 }, p: { // performance t: 1701234567890, m: 8192 } } }注意所有字段名都被极度缩写n代表navigatoru代表userAgent这是为了减小传输体积。更重要的是d.n.u即userAgent这个值不是直接取navigator.userAgent。Sensor SDK会先对原始UA进行一次正则清洗去掉版本号、渲染引擎细节等易变部分只保留核心标识。例如Chrome/120.0.0.0会被简化为Chrome/120。这个清洗逻辑就藏在akamai-clean.js里一个叫normalizeUA()的函数里。如果你在服务端直接用原始UAsensor_data必然不匹配。4.2 数据哈希与排序packedString的生成这是buildSensorPayload()函数里最核心的一步。它不是对整个rawData对象做JSON.stringify再哈希而是对每个叶子节点的值单独哈希。算法如下对rawData进行深度优先遍历DFS只访问值为字符串、数字或布尔值的叶子节点。对每个叶子节点的值val执行sha256(val.toString())得到一个64字符的十六进制字符串。将所有哈希结果按照其在rawData中的完整路径path进行字典序排序。路径用点号连接例如d.n.u、d.s.w、d.p.t。将排序后的所有哈希值用一个特殊分隔符通常是\x01即ASCII码1的字符连接起来形成packedString。下面是一个Python实现它100%复现了JS端的行为import hashlib import json from typing import Any, Dict, List, Tuple def dfs_hash(obj: Any, path: str ) - List[Tuple[str, str]]: 深度遍历对象对每个叶子节点的值进行SHA256哈希 results [] if isinstance(obj, dict): for k, v in obj.items(): new_path f{path}.{k} if path else k results.extend(dfs_hash(v, new_path)) elif isinstance(obj, list): for i, v in enumerate(obj): new_path f{path}[{i}] results.extend(dfs_hash(v, new_path)) else: # 叶子节点字符串、数字、布尔值 val_str str(obj) hash_val hashlib.sha256(val_str.encode(utf-8)).hexdigest() results.append((path, hash_val)) return results def pack_raw_data(raw_data: Dict) - str: 生成 packedString # 1. 获取所有 (path, hash) 对 hash_pairs dfs_hash(raw_data) # 2. 按 path 字典序排序 hash_pairs.sort(keylambda x: x[0]) # 3. 提取 hash 值用 \x01 连接 hashes [pair[1] for pair in hash_pairs] return \x01.join(hashes) # 测试 raw_data { v: 2.5.7, d: { n: {u: Chrome/120}, s: {w: 1920} } } packed pack_raw_data(raw_data) print(Packed string length:, len(packed)) # 应该是 64*2 1 129 字符这个pack_raw_data函数的输出就是AES加密的明文。注意JS端的sha256函数和Python的hashlib.sha256是完全兼容的只要输入字符串的编码UTF-8一致输出就绝对一致。4.3 AES-CBC加密与Base64编码这一步相对直接但有两个极易出错的细节密钥和IV的长度Akamai要求密钥必须是32字节256位IV必须是16字节128位。如果你从JS里拿到的key是字符串它很可能是一个Base64编码的32字节二进制数据需要先base64.b64decode()。同样iv也需要解码。PKCS#7填充AES-CBC要求明文长度是块大小16字节的整数倍。packedString的长度几乎不可能是16的倍数所以必须进行PKCS#7填充。规则是计算需要填充的字节数pad_len 16 - (len(packed) % 16)然后在packedString末尾添加pad_len个字节每个字节的值都等于pad_len。Python实现如下使用pycryptodome库from Crypto.Cipher import AES from Crypto.Util.Padding import pad import base64 def encrypt_sensor_data(packed_string: str, key_b64: str, iv_b64: str) - str: 使用AES-CBC加密 packed_string # 1. 解码密钥和IV key base64.b64decode(key_b64) iv base64.b64decode(iv_b64) # 2. PKCS#7填充 padded pad(packed_string.encode(utf-8), AES.block_size) # 3. AES-CBC加密 cipher AES.new(key, AES.MODE_CBC, iv) encrypted cipher.encrypt(padded) # 4. Base64编码 return base64.b64encode(encrypted).decode(utf-8) # 最终的 sensor_data 就是这个函数的返回值 sensor_data encrypt_sensor_data(packed, key_b64, iv_b64)4.4 完整的服务端生成流程与关键配置把以上所有步骤串起来就是一个完整的generate_sensor_data()函数。但在生产环境中你还需要处理几个关键配置版本号v字段必须和你逆向的JS文件版本严格一致。如果JS是v2.5.7你就不能填v2.5.8否则签名会失败。行为数据b字段这个数组不是可选的。即使你的爬虫不模拟用户行为也必须提供一个空数组[]或者一个包含page_load事件的最小数组。Akamai会检查b.length如果为0会直接拒绝。时间戳t字段必须是毫秒级时间戳且必须是“从页面加载开始”的相对时间。在服务端你无法知道页面何时加载所以通常设为一个很小的固定值如100表示加载后100毫秒。实测下来50-200这个范围是安全的。最终的Python服务端函数如下import hashlib import base64 import json from Crypto.Cipher import AES from Crypto.Util.Padding import pad def generate_sensor_data( user_agent: str, screen_width: int, screen_height: int, hardware_concurrency: int, device_memory: int, key_b64: str, iv_b64: str, version: str 2.5.7 ) - str: 生成合法的 sensor_data # 构建 rawData raw_data { v: version, d: { n: { u: normalize_user_agent(user_agent), # 必须清洗 p: Win32, # 平台固定即可 h: hardware_concurrency, m: device_memory }, s: { w: screen_width, h: screen_height, d: 24, # 颜色深度 r: 1 # 设备像素比 }, p: { t: 1701234567890, # performance timing可固定 m: 8192 # memory可固定 } }, b: [{e: page_load, t: 100}], # 最小行为数组 t: 100 # 相对时间戳 } # 1. 打包 packed pack_raw_data(raw_data) # 2. 加密 return encrypt_sensor_data(packed, key_b64, iv_b64) # 使用示例 sensor_data generate_sensor_data( user_agentMozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, screen_width1920, screen_height1080, hardware_concurrency8, device_memory8, key_b64your_base64_key_here, iv_b64your_base64_iv_here ) print(Final sensor_data:, sensor_data)这个函数生成的sensor_data可以直接作为HTTP Header通常是X-Akamai-Sensor-Data或POST Body的一个字段随你的请求一起发送。只要key_b64和iv_b64正确它就能通过Akamai 2.0的校验。5. 动态环境模拟与长期维护的实战经验逆向出sensor_data的生成逻辑只是万里长征第一步。真正的挑战在于如何让这个逻辑在服务端长期、稳定、大规模地运行因为Akamai的风控不是静态的它会随着SDK版本更新、客户策略调整而动态变化。我在这六周的实战中踩过无数坑也总结出几条血泪经验。5.1 为什么不能直接在Node.js里运行akamai-clean.js很多初学者会想“既然我都有了clean的JS那直接用node跑不就行了”这是一个巨大的误区。原因有三WebGL依赖akamai-clean.js里有一段关键的WebGL采集逻辑它会创建一个WebGLRenderingContext然后调用gl.getParameter(gl.RENDERER)。Node.js没有WebGL环境gl对象根本不存在这段代码会直接报错Cannot read property getParameter of null。Canvas依赖同理Canvas指纹采集需要一个真实的canvas元素toDataURL()方法在Node.js的jsdom里虽然能模拟但生成的图片哈希值和真实浏览器完全不同导致sensor_data不匹配。行为数据b字段的时效性b数组里记录的是用户真实的鼠标移动、键盘输入事件。在服务端你无法模拟这些事件的精确时间戳和坐标。akamai-clean.js会检查事件之间的时间间隔如果全是0或1会被判定为机器人。所以正确的做法是只提取逻辑不复用环境。把akamai-clean.js当作一份“需求规格说明书”而不是可执行代码。我们用Python或其他服务端语言重写所有算法只依赖标准库和确定的输入如UA、屏幕尺寸彻底摆脱对浏览器环境的依赖。5.2 如何应对Akamai SDK的版本更新Akamai的更新是悄无声息的。你可能今天还能用明天就全部403。监控和告警是必须的。我的做法是建立黄金样本库每天凌晨用一台真实的、配置固定的Windows机器Chrome最新版访问目标网站自动抓取最新的akamai.js并用上述四步法逆向生成新的key_b64、iv_b64和version。同时用这个新JS在真实浏览器里生成一个sensor_data存入数据库作为“黄金样本”。服务端双签验证在生产服务中同时维护两套sensor_data生成逻辑旧版和新版。对每个请求先用旧版生成如果请求失败返回403立刻用新版再试一次。如果新版成功则触发告警通知工程师检查是否需要切换主版本。自动化Diff工具用git diff对比每天抓取的新旧akamai.js重点关注getCryptoKey()函数的AST结构变化。如果发现getCryptoKey()的计算逻辑变了比如从二次多项式变成了三次那就意味着密钥生成算法已更新必须立刻介入。5.3 一个被严重低估的细节navigator.platform的伪造navigator.platform这个字段看起来很简单就是Win32或MacIntel。但Akamai会用它来交叉验证其他字段。例如如果你的userAgent里写着Windows NT 10.0但platform却是MacIntel这会被视为严重不一致。更隐蔽的是platform还会影响getCryptoKey()的计算。在我逆向的某个版本中getCryptoKey()的公式里有一个系数它会根据platform的首字母是W还是M而选择不同的值。所以在服务端你不能随便填Win32。你必须确保platform和你填写的userAgent、screen等字段在逻辑上是自洽的。我维护了一个映射表userAgent包含推荐platformWindowsWin32MacMacIntelLinuxLinux x86_64iPhoneiPhone5.4 终极建议不要追求100%的“完美”破解最后分享一个颠覆我认知的经验。在项目后期我们发现即使sensor_data完全正确某些高风险请求比如频繁提交登录表单依然会被拦截。原因在于sensor_data只是“设备可信度”的一部分Akamai还会结合IP信誉、请求频率、TLS指纹、HTTP/2连接特征等数十个维度做综合评分。试图100%模拟一个真实人类成本极高且收益递减。我的建议是把sensor_data当作一个“准入门槛”而不是“万能钥匙”。确保它能让你的请求通过第一道门设备校验然后把精力放在更可控的维度上使用高质量、低历史风险的代理IP池控制请求速率模拟真实用户的访问节奏比如两次请求间隔在2-10秒之间随机复用TCP连接保持HTTP/2长连接在Headers里除了X-Akamai-Sensor-Data还要正确设置Accept-Language、Sec-Ch-Ua等现代浏览器特征头当你把sensor_data的生成做成一个稳定、可维护的模块剩下的就是工程化的问题了。这比追求一个理论上“完美”的逆向要务实得多也有效得多。我在实际使用中发现一个设计良好的sensor_data生成服务配合合理的请求调度策略可以把成功率从不到5%提升到95%以上。而这个提升不是靠更复杂的逆向而是靠更扎实的工程实践。
