[原创][JS逆向]Vaptcha逆向分析-WEB安全-看雪安全社区

### 前置分析

#### Chrome设置

vaptcha的验证页面可能为弹出的一个单独标签页，为了方便调试，可以设置一下Chrome的DevTools
![](upload/attach/202509/1045364_M4VZVKQBXUXDGXG.webp)

#### 验证逻辑加载

在类似如下的验证页面加载过程中，会生成VM环境并加载验证逻辑
 ![](upload/attach/202509/1045364_AJZ99Z82RZMPB3C.webp)

VM的执行入口为
 ![](upload/attach/202509/1045364_EFKGDDFXUCA4KTM.webp)

其VM代码就是vaptcha-sdk接口返回的内容
 ![](upload/attach/202509/1045364_2NRZ4VHUB4DTWMN.webp)

返回的内容是混淆过的，可以适当使用AST还原并替换一下。

#### VM逻辑定位

除了单步调试定位外，还可以通过具体要分析的接口的`Initiator`中的`Request call stack`定位，如获取图片的接口
 ![](upload/attach/202509/1045364_WKPVHYWQZR3SJ48.webp)

#### 请求链路

通过对请求流程的分析，可知大致的关键链路

- 请求config接口获取vaptcha服务的配置信息
- 携带配置信息访问get接口获取图片
- 携带配置信息和加密后的验证参数请求validate接口进行验证
- 获取token，携带token访问原始网站数据接口

接下来就是对链路中部分关键的请求体参数做详细的分析

### 图片接口分析

#### 请求体定位

首先看一下请求体中的关键参数

![](upload/attach/202509/1045364_4V87RBZQWF267S9.webp)

多次请求可以发现`vi`是固定的，应为网站标识。

然后根据刚才的链路分析或者搜一下`k`参数的值可知`k`参数就是config接口返回的
 ![](upload/attach/202509/1045364_KBZTCEGVF2J6S82.webp)

对应其中的`knock`参数(这里是不同的两次请求，故图中的值不一样)

接下来重点分析一下`en`参数的生成。

先跟着调用栈进去看一下，找到请求体
 ![](upload/attach/202509/1045364_8G6FBACMCDKBZAX.webp)

`_0x45bdb3["data"]`就是完整的请求体
 ![](upload/attach/202509/1045364_BT67YP8DK9K8PBT.webp)

可以看到`_0x45bdb3`就是当前函数的入参

跟着调用栈回溯看下`_0x45bdb3`是怎么生成的
 ![](upload/attach/202509/1045364_ZCG5AWZSMQM69Q4.webp)

能看到`_0x45bdb3`就是在这里组成的对象，其中`data`的值就等于`_0x26b8e6`，继续跟
 ![](upload/attach/202509/1045364_FBNE3RSU2WWXY6V.webp)

`_0x1e0f55`就是`data`的值，往上面看还能看到`en`就是对应`_0xad7777`，至此就可以专注分析`en`值的生成了。

#### en参数分析

跟一下`en`，也就是`_0xad7777`的生成逻辑
 ![](upload/attach/202509/1045364_CEGMP8QQG55V75F.webp)

`_0xad7777`的生成和`_0x23221c`有关，而`_0x23221c`也是由一堆其他变量相加得到的

```javascript
_0x23221c = _0x392e9d + _0xb049bd + _0x4eecbb + _0x1e45dc + _0xb0124 + _0x2d7772 + _0x1ac30b + _0xc3f820 + _0x1a6817 + _0x37ab28 + _0x101aa8["globalMd5"]["slice"](0, 5);
```

先来挨个分析这些变量的值是怎么生成的，最后再用`encryFunc`处理一下就行了。

##### _0x392e9d

搜一下变量名，找到赋值的地方
 ![](upload/attach/202509/1045364_DK2VXCQSSHTXDG7.webp)

其等于`_0x354394["GenerateFP"]()`，看下这个函数是干啥的(根据函数名猜测和指纹有关)

```javascript
_0x1533a3["prototype"]["GenerateFP"] = function(_0x4d082f) {
    var _0xfe3533 = this["getComplexCanvasFingerprint"](_0x4d082f);
    return this["extractCRC32FromBase64"](_0xfe3533);
}
```

可以看到其中实现和Canvas指纹相关，看下`getComplexCanvasFingerprint`这个函数

```javascript
_0x1533a3["prototype"]["getComplexCanvasFingerprint"] = function(_0xb1e678) {
    if (_0xb1e678 === undefined) {
        _0xb1e678 = '';
    }
    var _0x58de07 = "BrowserLeaks,com <canvas> 1.0" + _0xb1e678;
    var _0x21cb9e = document["createElement"]("canvas");
    _0x21cb9e["setAttribute"]("width", "220");
    _0x21cb9e["setAttribute"]("height", "30");
    var _0x3b1a5e = _0x21cb9e["getContext"]("2d");
    _0x3b1a5e["textBaseline"] = "top";
    _0x3b1a5e["font"] = "14px 'Arial'";
    _0x3b1a5e["textBaseline"] = "alphabetic";
    _0x3b1a5e["fillStyle"] = "#f60";
    _0x3b1a5e["fillRect"](125, 1, 62, 20);
    _0x3b1a5e["fillStyle"] = "#069";
    _0x3b1a5e["fillText"](_0x58de07, 2, 15);
    _0x3b1a5e["fillStyle"] = "rgba(102, 204, 0, 0.7)";
    _0x3b1a5e["fillText"](_0x58de07, 4, 17);
    return _0x21cb9e["toDataURL"]();
}
```

结合`extractCRC32FromBase64`函数，就是通过Canvas生成一段具有特征的base64，在进行加密处理生成最终的指纹值，其中Canvas绘图时还会根据入参`_0xb1e678`来生成不同的文本
> 不同设备(环境)的Canvas指纹一般是唯一的，在结合具体网站应用上，使用当前浏览器生成的指纹，或用node、playwright、python相关库之类的环境去模拟生成指纹去做请求，大多数情况下都是不稳定的甚至是完全没法用的，如何批量稳定的绕过这里暂且不讨论了

这里的`extractCRC32FromBase64`函数可以整体扣下来或转换为Python代码。

##### _0xb049bd

搜一下变量名，找到赋值的地方
 ![](upload/attach/202509/1045364_5DJ2VE9KDNJTMS4.webp)

可以看到其等于`_0x23367b["sent"]()`，跟一下

> 之后遇到的处理流程中涉及`sent`的en参数的也和接下来要分析的流程类似，故只以当前流程为例进行详细分析

其实现的位置为

```javascript
var _0x4bd611 = {
    "label": 0x0,
    "sent": function() {
        if (_0x1df4cd[0] & 1)
            throw _0x1df4cd[1];
        return _0x1df4cd[1];
    },
    "trys": [],
    "ops": []
}, _0x5d578d, _0x5a9fe5, _0x1df4cd, _0xe388ef;
```

正常情况下应该是能走到`sent`中`return`语句，而`sent`中只有简单的取值，也就是说在调用`sent`之前，即走到`case 1`块之前，`_0x1df4cd[1]`的值就已经生成了，那先看一下这个东西是在哪赋值的

搜一下这个变量名，可以发现对其的赋值操作主要集中在`_0x1e72d1`这个函数中
 ![](upload/attach/202509/1045364_7X36KCRUNYQXCEE.webp)

简单分析一下这个函数的处理逻辑，`_0x1df4cd`的值可能和`_0x49bd55`有关

该函数主要围绕`_0x49bd55`这个入参，同时也会走下面的逻辑重新赋值

```javascript
_0x49bd55 = _0x41c1ce["call"](_0x160280, _0x4bd611);
```

这里的函数调用内容是会发生变化的，暂时只用关注当前`_0xb049bd`这个en参数的流程

可以刷新一下重新跟一下`getImage`流程，看下`_0x49bd55`或`_0x1df4cd`怎么来的
 ![](upload/attach/202509/1045364_DZB7HCMGUQV7J5E.webp)

可以看到`getImage`流程对应的函数返回的是经`_0x52fdcb`函数处理的一个值，稍微看一下这个函数可知最后它返回的是一个Promise对象

然后`_0x52fdcb`的第四个函数参数返回的是一个经`_0x5513de`函数处理的值
 ![](upload/attach/202509/1045364_5JDF9NTVDEMW3YE.webp)

可以看到该函数返回的是一个key指向不同函数执行逻辑的对象，每个执行逻辑都和`_0x1e72d1`函数有关

继续跟(或者结合这些流程稍微梳理一下)，就能看到` _0x41c1ce["call"](_0x160280, _0x4bd611)`的返回值，即`_0x49bd55`是`_0x5513de`函数的第二个函数参数中`case 0`块的返回值，即对应上述分析的第一个en参数的的处理逻辑所在的块

```javascript
return [4, _0x298102["GenerateFP"](false, true)];
```

看一下`_0x298102["GenerateFP"](false, true)`
 ![](upload/attach/202509/1045364_984FP57F39393XN.webp)

其返回的是一个Promise，可以在Promise包裹中的函数下几个断点看看其中的处理逻辑及返回值，将该Promise记为Promise0

return后回到`_0x1e72d1`函数的处理流程中，由于返回的列表第一个值是4，故走下面的逻辑
 ![](upload/attach/202509/1045364_AQ2F969D9MGJ244.webp)

继续跟
 ![](upload/attach/202509/1045364_AVNXG3BH5RX68HM.webp)

根据上述对`_0x5513de`的简单分析，这里走了next的执行逻辑，可以看到上面`_0x1e72d1`的返回值就是`_0x4234aa`函数的入参`_0x4921b0`，可以发现其主要围绕Promise的执行，并逐层传递Promise执行中产生的参数

`_0x4234aa`函数也是在一个Promise内，而上述提到的`getImage`对应的函数返回时也正是调用了返回这个Promise对象的`_0x52fdcb`函数
 ![](upload/attach/202509/1045364_247SV2RBJN72TBK.webp)

如果`done`被标记为`true`，则会取`value`给到`_0x12a155`，即resolve，否则会一直执行`then`，`fulfilled`时执行`_0x910b2a`，其参数简单来说就是Promise执行过程中resolve接收的值，`reject`时执行`_0x447f35`，这里主要关注Promise的`onFulfilled`函数，即`_0x910b2a`，逻辑如下
 ![](upload/attach/202509/1045364_8E4978EGVX352J4.webp)

分析可知这里的`next`最终还是要回去执行刚才分析的`_0x1e72d1`函数，来标记`done`的。这里的`_0x243cf0`，即resolve的值，会作为`_0x1e72d1`函数的列表类型的入参的第二个元素

继续跟
 ![](upload/attach/202509/1045364_M3472BMES6DHM2W.webp)

发现先去执行了`_0x3edf5e`函数，看一下`_0x3edf5e`的逻辑，主要是将传入的`_0x48cfb7`，也即resolve的值，包装成类似下面的形式

```json
{
    "value": _0x50a149,  // _0x48cfb7
    "duration": _0x2b048b  // 时间差
};
```

再往下看，可以发现一段流程后又回到了Promise0中的case 2，
 ![](upload/attach/202509/1045364_PNQ74XWV95WG39U.webp)

可以看到这里面components的值和上面说的包装的形式很像，合理怀疑就是刚才的流程中一步步组装起来的，这里暂时不管

简单分析下`case 2`块，根据`_0x4b4666`是否有值，再结合components(这里的compoents对象可以先扣下来固定下来)，组成新的对象`_0x1938e6`，后面经过`hashComponents`得到`_0x297a60`

`_0x4d7c27`就是当时的第二个入参，根据`_0x298102["GenerateFP"](false, true)`可知这里是true，也就是不需要切割，最后将处理好的`_0x297a60`交给Promise0的resolve

根据上面的分析，这里的Promise0处于resolved(进入下一个状态)后，即在`_0x1e72d1`函数中执行完了` _0x49bd55 = _0x41c1ce["call"](_0x160280, _0x4bd611)`，返回了`[2]`，继续跟，走到default块
 ![](upload/attach/202509/1045364_BZEUFZYDC9RH8E7.webp)

在第一个判断条件跳出，然后函数返回

```javascript
return {
    "value": _0x49bd55[0] ? _0x49bd55[1] : undefined,
    "done": true
};
```

此时`done`就标记为了`true`，继续跟，可以看到又执行了Promise0的外层Promise的then，即`_0x4234aa`所在的Promise，然后将resolve接收的参数交给then中的onFulfilled处理，即最终又回到了`_0x1e72d1`函数
 ![](upload/attach/202509/1045364_GW69G687VXNTBTJ.webp)

可以看到，在这次then中，将Promise中的参数赋值给了最开始`sent`中要用到的`_0x1df4cd`，接下来调用函数，
 ![](upload/attach/202509/1045364_TVUS9PWRJVTFY3A.webp)

在这次调用中又回到了最开始的`getImage`方法，跟进去
 ![](upload/attach/202509/1045364_RVTKBTGDSXQE8DN.webp)

到了`case 1`块，通过`sent`获取对应的值，而这里就是刚刚流程中Promise0的`case 2`块中产生的参数，即`_0x592344["hashComponents"]`处理后的值，可以把这个函数整体扣下来处理

至此，围绕`_0x1e72d1`函数的Promise过程就分析完了，后续涉及Promise的取值流程与此类似。

#####  _0x4eecbb

搜一下变量名，定位到赋值的地方
 ![](upload/attach/202509/1045364_CATPM26QQGDSYBE.webp)

这里要注意下`_0x354394["GenerateFP"]`和`_0x298102["GenerateFP"]`不是一个东西

`_0x354394["GenerateFP"]`是前面分析的canvas指纹那套流程

`_0x298102["GenerateFP"]`则是前面分析的Promise流程

`knock`就是前置分析中config接口返回的

所以`_0x4eecbb`就是额外加了`knock`参数来生成文本的canvas指纹生成逻辑得到的参数

#####  _0x1e45dc

定位到赋值的地方
 ![](upload/attach/202509/1045364_TFBSU6G7BWT88GR.webp)

也是通过`sent`拿到的，那按照上述分析的只要关注上个流程，也就是`case 1`块中的返回值就可以了

即`[4, _0x298102["GenerateFP"](_0x2ac95b["knock"]["substr"](-5, 5))];`

`_0x298102["GenerateFP"]`返回的依旧是之前分析过的那个Promise0，第一个参数是切割后的`knock`，第二个参数为`undefined`，在函数内会转换为`false`

那结合之前分析可知`_0x1e45dc`就是在components中额外加入了`knock`参数，再执行`hashComponent`，因为第二个参数是`false`，所以还要再切割一次得到最后的结果

#####  _0xb0124

先搜一下看一下赋值位置
 ![](upload/attach/202509/1045364_7PUUYTQQRA7J6ZZ.webp)

发现运算中有个没看过的变量`_0x323ff4`，定位一下，发现就在上面，是写死的

那就直接把`hex_md5`扣下来算出`_0xb0124`就可以了

#####  _0x2d7772

定位一下
 ![](upload/attach/202509/1045364_WS4KRNMUV556J39.webp)

发现其受`_0x101aa8["ha"]`影响，那先来看下`_0x101aa8`

> 同样的，后面涉及`_0x101aa8`的参与en运算的参数也是跟这次分析差不多的流程，后面不再赘述

![](upload/attach/202509/1045364_276VM9PR7AVMVD2.webp)
![](upload/attach/202509/1045364_WT8X2RM3AVM77ZJ.webp)

可以看到其就是一个立即运行的函数，本质等于其返回值`_0x57c9c0`，也是个函数，而在`_0x101aa8`函数内部有很多给`_0x57c9c0`属性赋值的地方，其中就包括上述提到的`ha`，也可以看到`ha`的初始值为空

其实可以同时看到紧接着`_0x101aa8`的下面的变量也是个立即执行的函数
 ![](upload/attach/202509/1045364_TN9GZNDFJDEAA8Y.webp)

其接收的参数正是`_0x101aa8`，而它返回的也是它内部的函数`_0x5918e4`，简单看一下`_0x5918e4`的逻辑可以发现它会调用`_0x101aa8`

所以在`_0x101aa8`中不能只关注那些属性值的初始值，还要找到其他可能的二次赋值的地方

对于`ha`，可疑的只有下图中的位置
 ![](upload/attach/202509/1045364_6CPMF8SGYY45HS4.webp)

然后`_0x582300`也是通过`sent`得到，那看一下上一步返回的地方

```javascript
return [4, _0x4c9b3b["getImage"](_0x1cc39a)];
```

正是正在分析的获取图片的流程，那也就是说此时`ha`还是初始值空，走完图片获取流程才会给`ha`再次赋值

那回到`_0x2d7772`这个参数的分析，根据判断逻辑，`ha`为空，那它就是一个固定值，至此该参数也分析完了

#####  _0x1ac30b

定位一下
 ![](upload/attach/202509/1045364_RRABPQJ7Y57AHMG.webp)

`_0x1ac30b`等于`_0x3d86c7`

`_0x3d86c7`赋值的地方有两个，取决于`case 2`块中的返回值
 ![](upload/attach/202509/1045364_R7V87P6GKW3YN76.webp)

如果`hb`不为空就会走到`case 3`，那`_0x3d86c7`就是`_0x94b78b`和`sent`的结果拼起来的，`_0x94b78b`就等于`hb`，`sent`对应的是上一步的返回值，即

```javascript
return [4, _0x298102["GenerateFP"](_0x101aa8["hb"])];
```

也就是处理后的canvas指纹值

但根据上述`_0x101aa8`流程的分析可知`hb`此时是为空的，不会走到`case 3`，那`_0x3d86c7`也就是`case 2`中得到的固定值了，之后直接走到`case 5`，被赋给`_0x1ac30b`

#####  _0xc3f820

定位一下
 ![](upload/attach/202509/1045364_CCF9AGPM4YTCP5S.webp)

精简一下逻辑

```javascript
_0x397b35 = _0x17f508["canStorageUse"]();
_0xe75d98 = _0x2ac95b["dfu"],
_0x26f33d = _0x397b35 ? localStorage["getItem"]("vaptchanu") ? localStorage["getItem"]("vaptchanu")["split"](",")[0] : _0x101aa8["staticDfu"] : _0x101aa8["staticDfu"];
_0xc3f820 = _0x17f508["compareDfu"](_0xe75d98, _0x26f33d);
```

先找到`canStorageUse`
 ![](upload/attach/202509/1045364_C6ZSCESYK84ZGXQ.webp)

`canStorageUse`在正常浏览器环境下返回的应该都是`true`，即`_0x397b35`为`true`

回到`_0xc3f820`的生成逻辑继续往下看，`_0x2ac95b`是`getImage`对应函数的入参，定位一下传入的位置
 ![](upload/attach/202509/1045364_BC25JH3SJ9FBRRU.webp)

在`loadFirstImg`返回的函数中首次调用的`getImage`，入参为`_0x1cc39a`，主要用到的是`this`的属性，也就是`_0x57c9c0`的属性(又回到了`_0x101aa8`函数内的处理逻辑)，这里主要看一下`options`赋值的地方
 ![](upload/attach/202509/1045364_PZQCQTJ9JQGPKV2.webp)

只有一个地方，也就是`_0x57c9c0`函数的入参就是对应后面的`options`，那调用栈往回看一下这个入参怎么生成的

下图中能看到这个入参是在验证码HTML页面渲染时绑定的时间监听中拿到的
 ![](upload/attach/202509/1045364_AAXSCWXQM9U8ATA.webp)

那看一下该HTML的请求堆栈，其中有一个verify.xx.js(反不反混淆影响不大)，搜索`dfu`能看到很像这个入参生成的地方
 ![](upload/attach/202509/1045364_XS6V6GBRYGPBYWE.webp)

刷新一下发现最后定位在`case 2`中赋值的地方，其实对比一下逻辑，verify.xx.js中两处`dfu`赋值的地方的逻辑基本是一致的，至于走哪个分支里的赋值应该和缓存有一定的关系

用到的`this['config']`中的值也就是config接口返回的值，然后这里得到的`newconfig`就对应要找的入参

接着继续在verify.xx.js中看一下`dfu`生成逻辑中`vaptchanu`是在哪里设置的
 ![](upload/attach/202509/1045364_AWGSWXK378F56CQ.webp)

可以看到是在`setToken`中将传入的参数切割后在localStorage中存成了`vaptchanu`，在这打断点没断住，那就是目前的流程不涉及verify.xx.js中的这个赋值流程，可以暂时不用管。

也就是说在verify.xx.js目前走过的流程中，`dfu`就是空，那再回到`_0xc3f820`的生成逻辑继续往下看，自然的`_0x26f33d`也就只和`_0x101aa8["staticDfu"]`有关

定位一下`_0x101aa8["staticDfu"]`赋值的地方，发现在图片获取流程和验证流程中都存在赋值的地方，同时这两处也都有对`vaptchanu`和`vaptchaut`的赋值

目前只用关注图片获取流程中的处理逻辑即可
 ![](upload/attach/202509/1045364_2HVRBXTNT4NSHZK.webp)

打断点到赋值的地方，发现在请求完图片接口之后才会走到这来赋值，也就是`staticDfu`在图片接口的参数分析中可以理解为都是`undefined`，包括下面的`staticDfuTrust`目前也是`undefined`

即`_0xe75d98`和`_0x26f33d`这两个参数都没有值，那看一下`compareDfu`的逻辑
 ![](upload/attach/202509/1045364_QFF5BQHVH6PFE77.webp)

`compareDfu`简单分析下就是根据两个入参的长度来选择返回两个入参中的其中一个或返回一个固定值

综上所述，`_0xc3f820`就是`compareDfu`中返回的那个固定值

#####  _0x1a6817

定位看一下逻辑

```javascript
_0x1a6817 = _0x397b35 ? localStorage["getItem"]("vaptchaut") ? localStorage["getItem"]("vaptchaut") : _0x101aa8["staticDfuTrust"] ? _0x101aa8["staticDfuTrust"] : "0123456789qwertyuiopasdf87654321" : _0x101aa8["staticDfuTrust"] ? _0x101aa8["staticDfuTrust"] : "0123456789qwertyuiopasdf87654321";
```

跟上面`_0x26f33d`这个值的分析差不多，在`getImage`流程中取的就是一个固定值

#####  _0x37ab28

看下赋值逻辑

```javascript
_0x260187 = _0xfa172["uaDelExtra"](navigator["userAgent"]) + location["host"] + _0x101aa8["secretC"]["substr"](0, 10);
_0x37ab28 = _0x23081c["hex_md5"](_0x260187)["slice"](0, 5);
```

`uaDelExtra`对应的函数为
 ![](upload/attach/202509/1045364_3H9UQHDDFCMKAHZ.webp)

`navigator["userAgent"]`，`location["host"]`，`_0x101aa8["secretC"]`都相当于是定值，那拼出来的`_0x260187`也是定值，然后经过`hex_md5`处理再切割一下就得到了`_0x37ab28`

#####  _0x101aa8

这里实际取的是`globalMd5`，看一下其对应的生成逻辑

可以定位到两个地方

先看第一个地方
 ![](upload/attach/202509/1045364_B29K6XGX5DYBYRY.webp)

这是在`_0x101aa8`内部的`_0x57c9c0`函数中，`_0x4bcc6c`是`_0x57c9c0`的入参，这个入参上面分析过了，这里直接看verify.xx.js

搜索`md5`能看到很像这个入参生成的地方
 ![](upload/attach/202509/1045364_HUG7CN6HGDT8UWU.webp)

刷新一下发现最后定位在`case 2`中赋值的地方，对比一下逻辑，verify.xx.js中两处md5赋值的地方的逻辑也基本是一致的

用到的`this['config']`中的值也就是config接口返回的值，可以把md5生成中用到的`hex_md5`和`splicingObj`扣下来进行运算，这里的`hex_md5`和之前分析中出现的是一样的，那对应的`globalMd5`的值也就是这里`md5`的值

而定位到的另一处`globalMd5`赋值的地方是在`getImage`流程之后才会走到的，故`getImage`流程中不用管

#### 图片获取及还原

结合算出来的en值拼成请求体后请求拿到图片，得到的图片是乱序的，还需要根据图片接口返回的数据来还原图片的顺序

根据图片接口返回的字段，搜一下`img_order`，发现有两个地方，其中一个地方存在`Decrypt`函数，可以在那里断一下
 ![](upload/attach/202509/1045364_6QDFX9W77CHMS5D.webp)

`_0x39a52f`就是接口返回的数据，主要看一下`_0xef75b5`怎么来的

其由`_0x15d835`、`_0x11835f`、`parseInt(_0x57c9c0["secretC"])`、`_0x17f3de`拼接而来，那接下来主要看一下这几个参数的赋值逻辑

##### _0x15d835

定位一下，可以发现其初始值为0，后面还有一个赋值逻辑
 ![](upload/attach/202509/1045364_A3UKDRK9RFMNH4G.webp)

简单分析下，就是如果接口中存在`ha`字段且`ha`不为空，就再次给`_0x15d835`赋值

可以把这里的`hex2int`函数扣下来，`_0x354394["GenerateFP"]`之前分析过，是涉及canvas指纹的地方，这里加了一个`ha`作为额外的文本内容来辅助生成canvas指纹

##### _0x11835f

定位一下，其初始值也为0，后面有个二次赋值的地方
 ![](upload/attach/202509/1045364_P4FE4X8NCRTWG7A.webp)

这里又出现了`sent`，那就看一下上一步的逻辑

判断接口中`hb`字段的情况，如果`hb`有值才会走到二次赋值的地方，二次赋值时主要关注这个返回值

```javascript
return [4, _0x298102["GenerateFP"](_0x39a52f["hb"])];
```

还是之前分析过的`_0x298102["GenerateFP"]`，在components拼接的逻辑中额外加了`_0x39a52f["hb"])`，后面又经过了`hashComponents`和切割

##### _0x17f3de

初始值为0，二次赋值的逻辑如下

```javascript
_0x17f3de = _0x57c9c0["globalPow"];
```

所以要看一下`globalPow`是怎么生成的，这在下面`_0x57c9c0`中一起分析

##### _0x57c9c0

这个其实也是在图片获取流程中分析过的，是`_0x101aa8`函数内部定义的一个函数，其中存在很多给自己属性赋值的操作，那就看一下`globalPow`和`secretC`是哪里赋值的

`secretC`之前定位过，是个定值，接下来主要看`globalPow`

定位到可疑的赋值位置
 ![](upload/attach/202509/1045364_F8CWX7M6Y2RMAMU.webp)

这里的`_0x101aa8`定位过去可以看到其实就是`_0x57c9c0`

`globalPow`是在`onmessage`里赋值的，那对应的看一下`postMessage`
 ![](upload/attach/202509/1045364_QCT93GD4E2DWX9N.webp)

其中涉及一个`_0x58df75`参数，也就是`pow`对应的函数的入参，定位一下看下哪里调用的`pow`
 ![](upload/attach/202509/1045364_VMU2E2TKVYSDR58.webp)

在`_0x57c9c0["prototype"]["insertCaptchaImage"]`函数的处理逻辑中调用的，而这里刚好也是初始化`globalPow`的地方，这里的`_0x39a52f`也是这个函数的入参，定位一下可以发现就是图片接口返回的数据

回到`postMessage`，跟进去发现真实的处理逻辑在work2.js中
 ![](upload/attach/202509/1045364_DKYRCGDKXF8T36S.webp)

这里可以把`pow`函数扣下来，`e.data.str`就是上述图片接口返回的数据中的`r`参数，走到`self.postMessage`后就能进入刚刚`onmessage`的地方，精简下逻辑，即`globalPow`等于`pow(r)`

综上得到`_0xef75b5`后就可以看下`Decrypt`函数

```javascript
function _0x2f0939(_0x5f38f0, _0x411a42) {
    var _0x5f0d56 = '';
    _0x5f0d56 = (parseInt(_0x5f38f0) - _0x411a42)["toString"]();
    if (_0x5f0d56["length"] < 10) {
      _0x5f0d56 = "0" + _0x5f0d56;
    }
    return _0x5f0d56;
}
```

很简单的逻辑，可以直接用python复现一下

这样图片的真实顺序就还原完成了

### 验证接口分析

按照上述图片接口的分析直接定位到关键参数en生成的地方
 ![](upload/attach/202509/1045364_8ZJQYTFAW4D7BBY.webp)

可以看到和图片接口的en值整体上的加密逻辑差不多

#### en参数分析

看一下`_0x263810`怎么来的

```javascript
_0x263810 = '' + _0x4a3f5d["dt"] + _0x4a3f5d["ch"] + _0x4a3f5d["cw"] + _0x1ce3a4["toString"]()["substr"](0, 5) + _0x2d4eff + _0x252e18 + _0x3992aa + _0x5063a0 + _0xcde9a6 + _0x277cc1 + _0x2133f8 + _0x1b799c + _0x101aa8["globalMd5"]["slice"](0, 5) + _0x4a3f5d["v"];
```

还是由一堆值拼接而来，继续一个个看

##### _0x4a3f5d

定位一下
 ![](upload/attach/202509/1045364_9GBR92VAX9JG7KC.webp)

可以看到是`verify`对应函数的参数，和`getImage`中的`_0x2ac95b`分析流程类似，先看一下哪里调用的`verify`
 ![](upload/attach/202509/1045364_D74A54FKE2GTZQY.webp)

在`_0x57c9c0["prototype"]["validateVaptcha"]`里，同时`verify`的入参也是`_0x57c9c0["prototype"]["validateVaptcha"]`的入参

也可以看到入参`_0x2a9d5a`在`_0x57c9c0["prototype"]["validateVaptcha"]`中也增加了几个额外的参数

先定位一下哪里调用了`validateVaptcha`，可以搜一下这个关键字或者调用栈往回找
 ![](upload/attach/202509/1045364_P682JJRQ2NCPJDF.webp)

可以看到是在`_0x57c9c0["prototype"]["canvasMouseUp"]`里调用的，实际`verify`的部分入参也是在这里拼起来的，结合`_0x57c9c0["prototype"]["validateVaptcha"]`中增加的几个额外的参数，根据里面的逻辑来看一下几个关键的参数

- dt

`dt`生成的逻辑如下

```javascript
  _0x3b81b6 < 100 ? "00" + _0x3b81b6 : _0x3b81b6 < 1000 ? "0" + _0x3b81b6 : _0x3b81b6
  ```

在上面就能看到`_0x3b81b6`的生成逻辑，是个时间差，带入上面的逻辑就能得到`dt`

- ch

canvas画布的高度，定值(注意需要和实际的验证码区域区分一下)

- cw

canvas画布的宽度，定值(注意需要和实际的验证码区域区分一下)

- v

对应`_0x3b0f05`

```javascript
  var _0x9a77c0 = this["drawPredicate"]();
  var _0x3b0f05 = _0x3dfad4["assemblyCoordData"](_0x9a77c0);
  ```

`_0x9a77c0`就是处理后的轨迹坐标，`_0x3dfad4["assemblyCoordData"]`函数可以直接扣下来

- p

对应`_0x57c9c0["globalPow"]`，这个上面也分析过了，直接拿来用即可

- dfu

对应`this["options"]["dfu"]`，这个上面也分析了，在verify.xx.js中有相关生成逻辑，其中涉及到的`vaptchanu`也可以在相应的地方断一下，在这一步可以看到`dfu`最终得到的是空

这几个参数弄清楚之后就可以带到en参数的生成逻辑中

##### _0x1ce3a4

定位到赋值的地方

```javascript
_0x1ce3a4 = _0x4a3f5d["p"]
```

就是上面刚分析的`p`参数

##### _0x2d4eff

定位一下

```javascript
_0x2d4eff = _0x354394["GenerateFP"]();
```

还是之前分析过的，和canvas指纹相关

##### _0x252e18

定位到赋值的地方
 ![](upload/attach/202509/1045364_QKM3WVKYQECRWJZ.webp)

和`sent`相关，那看一下上一步的返回值，也就是

```javascript
return [4, _0x298102["GenerateFP"](false, true)];
```

也是分析过的`hashComponents`那个流程

##### _0x3992aa

定位一下

```javascript
_0x3992aa = _0x101aa8["ha"] === '' ? "0123456789qwe" : _0x101aa8["ha"] + _0x354394["GenerateFP"](_0x101aa8["ha"]);
```

和`_0x101aa8["ha"]`有关，这个`ha`也是之前分析过的，由于现在`getImage`流程走完了，所以可以看一下二次赋值的地方
 ![](upload/attach/202509/1045364_ZPQTX7NEYJVFY66.webp)

断住可以看到`_0x582300`就是图片接口返回的数据，那就按这边的逻辑挨个对应上就行了

然后带入`_0x3992aa`的处理逻辑就能得到结果

##### _0x5063a0

定位一下
 ![](upload/attach/202509/1045364_TDQ68EUEKKM9U38.webp)

`_0x5063a0`就等于`_0x3fbc4c`，根据前面的分析这里也是个分支赋值，取决于`_0x101aa8["hb"]`的值，精简一下就是

```javascript
_0x5063a0 = _0x101aa8["hb"] === '' ? "0123456789qwe" : _0x101aa8["hb"] + _0x298102["GenerateFP"](_0x101aa8["hb"]);
```

这里的`_0x298102["GenerateFP"]`也就是`hashComponents`流程

##### _0xcde9a6

定位一下

```javascript
_0x2f01c2 = _0x4a3f5d["dfu"],
_0xb14203 = _0x55865d ? localStorage["getItem"]("vaptchanu") ? localStorage["getItem"]("vaptchanu")["split"](",")[0] : _0x101aa8["staticDfu"] : _0x101aa8["staticDfu"];
_0xcde9a6 = _0x17f508["compareDfu"](_0x2f01c2, _0xb14203);
```

根据之前涉及`vaptchanu`的相关分析流程，在图片接口请求完成之后`vaptchanu`就会被赋值，对应的就是图片接口返回的响应体中的`u`参数和时间戳拼接而成的值

##### _0x277cc1

定位一下

```javascript
_0x277cc1 = _0x55865d ? localStorage["getItem"]("vaptchaut") ? localStorage["getItem"]("vaptchaut") : _0x101aa8["staticDfuTrust"] ? _0x101aa8["staticDfuTrust"] : "0123456789qwertyuiopasdf87654321" : _0x101aa8["staticDfuTrust"] ? _0x101aa8["staticDfuTrust"] : "0123456789qwertyuiopasdf87654321";
```

根据之前涉及`vaptchaut`的相关分析流程，在图片接口请求完成之后`vaptchaut`就会被赋值，对应的就是图片接口返回的响应体中的`ut`参数

> 如果在验证接口中给`_0xcde9a6`和`_0x277cc1`设置为固定值，则最后即使验证成功，返回的token也会变成000000000000000000000

##### _0x2133f8

定位到赋值逻辑

```javascript
_0xaffae = _0xfa172["uaDelExtra"](navigator["userAgent"]) + location["host"] + _0x101aa8["secretC"]["substr"](0, 10);
_0x2133f8 = _0x23081c["hex_md5"](_0xaffae)["slice"](0, 5);
```

和图片接口中的`_0x37ab28`参数的分析一样

##### _0x1b799c

定位到赋值的地方

```javascript
_0x49090c = "61fecae0460";
_0x1b799c = _0x23081c["hex_md5"](_0x4a3f5d["knock"] + parseInt(_0x49090c)["toString"]())["slice"](0, 5);
```

`_0x4a3f5d["knock"]`还是config接口返回的那个值，其他就按上述分析的处理一下就行

##### _0x101aa8["globalMd5"]

第一处`globalMd5`的赋值在图片接口的`_0x101aa8`中分析过了，这里看第二处
 ![](upload/attach/202509/1045364_RYXV4CFKXPYPKN6.webp)

其实和第一处的逻辑几乎一样，就是把`splicingObj`的参数换一下，换成图片接口返回的`data`的值

至此验证接口的en值需要用到的参数就分析完了，之后再经过`_0xfa172["encryFunc"](_0xfa172["selectFrom"](3, 15), _0x263810)`处理一下就是最终的en值

#### 验证接口返回的code及其含义

在官网和分析的js中都能找到，这里只列几个经常出现的

| code | 含义                     |
| ---- | ------------------------ |
| 0101 | 验证超时                 |
| 0103 | 验证成功                 |
| 0104 | 验证失败(一般是轨迹不对) |

回复或点赞可查看完整内容

冰与火的战歌：Windows内核攻防实战高级班！从零到实战，融合AI与Windows内核攻防全技术栈，打造具备自动化能力的内核开发高手。

最后于 2025-9-24 09:48 被LotusRain编辑，原因：补充

最新回复 (26) 1 2 ▶
apxar 雪币： 410 活跃值： (1998) 能力值： ( LV3，RANK：20 ) 在线值：发帖 71 回帖 231 粉丝 0 关注私信	apxar 2 楼 6 2025-9-19 15:14 0
魔童雪币： 946 活跃值： (2387) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 113 粉丝 1 关注私信	魔童 3 楼 6666666666 2025-9-20 19:25 0
mb_cbgtaveo 雪币： 292 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 259 粉丝 0 关注私信	mb_cbgtaveo 4 楼 66666 2025-9-20 21:28 0
MaYil 雪币： 9446 活跃值： (8072) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 485 粉丝 2 关注私信	MaYil 5 楼感谢分享 2025-9-21 11:27 0
夫人十八岁雪币： 7 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 38 粉丝 0 关注私信	夫人十八岁 6 楼感谢分享 2025-9-21 15:24 0
咖特雪币： 56 活跃值： (368) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 3 粉丝 0 关注私信	咖特 7 楼感谢分享 2025-9-21 20:04 0
Imxz 雪币： 110 活跃值： (9576) 能力值： ( LV2，RANK：10 ) 在线值：发帖 6 回帖 775 粉丝 9 关注私信	Imxz 8 楼 tql 2025-9-22 09:29 0
lovepd 雪币： 444 活跃值： (532) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 9 粉丝 0 关注私信	lovepd 9 楼提供一份反混淆后的js，仅供参考上传的附件： vaptcha-sdk.1.2.35.669f69e6-fix.js （386.30kb，19次下载） 2025-9-22 18:23 1
AK1988DA 雪币： 74 活跃值： (875) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 112 粉丝 0 关注私信	AK1988DA 10 楼 2 2025-9-22 18:59 0
Snowman_Liam 雪币： 2 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 142 粉丝 1 关注私信	Snowman_Liam 11 楼 666 2025-9-23 11:43 0
我不是卷王雪币： 547 能力值： ( LV1，RANK：0 ) 在线值：发帖 5 回帖 123 粉丝 36 关注私信	我不是卷王 12 楼 111 2025-9-23 13:09 0
mb_fshbrtpq 雪币： 200 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 5 粉丝 0 关注私信	mb_fshbrtpq 13 楼 666 2025-9-23 17:28 0
mb_mrjjcxgk 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 82 粉丝 0 关注私信	mb_mrjjcxgk 14 楼 666 2025-9-26 14:03 0
mb_uulqeyon 雪币： 1165 活跃值： (3406) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 37 粉丝 2 关注私信	mb_uulqeyon 15 楼 1 2025-9-28 07:11 0
lsmjj 雪币： 266 活跃值： (444) 能力值： ( LV2，RANK：10 ) 在线值：发帖 5 回帖 86 粉丝 0 关注私信	lsmjj 16 楼 2025-9-29 08:58 0
假装在纽约啊雪币： 30 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 4 粉丝 5 关注私信	假装在纽约啊 17 楼 6666 2025-9-29 16:12 0
威兹曼雪币： 317 活跃值： (650) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 62 粉丝 0 关注私信	威兹曼 18 楼 6666 2025-9-29 16:39 1
ulong9527 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 67 粉丝 0 关注私信	ulong9527 19 楼 666 2025-11-18 09:44 0
guijingwen 雪币： 7377 活跃值： (7605) 能力值： ( LV2，RANK：10 ) 在线值：发帖 13 回帖 312 粉丝 0 关注私信	guijingwen 20 楼 66666 2025-11-18 10:18 0
mb_pkdeuevs 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 2 粉丝 0 关注私信	mb_pkdeuevs 21 楼大佬，招资深JS逆向，有意愿的话，请联系我 2025-11-24 18:27 0
mb_qimctavn 雪币： 5329 活跃值： (6790) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 402 粉丝 1 关注私信	mb_qimctavn 22 楼 6 2025-11-24 19:20 0
弹指瞬间雪币： 118 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 6 粉丝 0 关注私信	弹指瞬间 23 楼 666666 2026-1-14 10:46 0
小灰灰爬虫雪币： 106 活跃值： (145) 能力值： ( LV2，RANK：10 ) 在线值：发帖 4 回帖 2 粉丝 2 关注私信	小灰灰爬虫 24 楼 666666 2026-2-6 16:10 0
和风起雪币： 157 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 6 粉丝 0 关注私信	和风起 25 楼 666 2026-3-3 12:41 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复