雷池WAF逆向思路

DevTool检测

尝试F12打开控制台，抓包看一下,结果提示请关闭 Devtools，然后刷新页面
看来是有控制台检测，根据抓到的包来看，是卡在了sdk.js的位置，那就直接本地替换这个文件,把检测点去掉，这里尝试直接在sdk.js中搜索DevTool直接搜索到了一个方法

 复制代码 隐藏代码
isDevToolOpened: function() {
    return {
        opened: d,
        opening: g
    }
}

看起来这个d和g是控制台开启的状态，在下面不远的地方看到了定义了这两个变量，默认值是false，代表的应该是关闭状态。

 复制代码 隐藏代码
let d = !1
  , g = !1;
u[l(376)]((e=>{
    // e && (d = !0),
    // g = e 
}

代码走到u[l(367)]的位置，可以看到是添加了一个事件监听器，开启了控制台之后会把这两个变量修改成true也就是被检测出来了
直接把代码注释掉，成功的过了检测

在校验完成过后会出现三个cookie

cookie的生成逻辑

猜想

过完检测后，完整的跑完一次cookie生成，根据抓到的包来看，初步的流程猜想：

1. 请求list接口    ->   获取第一个cookie : sl-session
2. 获取sdk.js文件， 在这里面一定做了一些操作
3. 请求seed接口    ->    获取seed
4. 请求inspect接口    ->    获取jwt
5. 请求list接口    ->    获取第二个cookie : sl_jwt_session

需要补充的是，在第3步获取seed的请求中，携带了三个参数

 复制代码 隐藏代码
once_id: cfc561a57ff747b49fc230bc1983c1da_5
v: 1.0.0
hints: webdriver,webDriverValue,vendor,headless,languages,permHook,globalThis

经过多次验证，v和hints都是写死的内容，只有once_id是变化的，那么这个once_id就只能是在前面的sdk.js中生成的或者是list返回的，全局搜索之后果然在第一次list返回的内容中找到了once_id

而第四步中携带的参数seed就是第三步请求返回的，获得jwt之后，将jwt设置为名称为sl_waf_recap的cookie，请求第五步即可

到这里就是cookie的大概逻辑了

inspact的body加密

分析了上面的逻辑可以发现，前三步都是没有任何难度的请求，而第四步中有一个加密的请求体。
通过看seed和inspact的调用栈，可以看出都是oe结尾的，可以猜测这个oe应该是和发送请求有一些关系，往前面则是同名的inspact方法
xhr断点找到请求inspact的位置，跟调用栈回到inspact方法中，可以看到body实际上就是n.ciphertext["toString"]()，这个语法很容易想到AES加密。
而且在上面也看到了一段代码

 复制代码 隐藏代码
return q[n(467)](JSON[n(481)](e), i, {
    iv: o,
    padding: Q
})

不说一定，大概率是熟悉的AES的CBC模式了。
走一遍inspect方法的逻辑，实际上是将seed后面补0填充到16位，并使用Utf8.parse处理后作为key
而iv则是Utf8.parse处理1234567890123456固定值
padding的Q向上看可以看到这样一段代码

 复制代码 隐藏代码
!function(e, t) {
    var n;
    e.exports = (n = D(),
        X(),
        n.pad.Pkcs7
    )
}(K);
var Q = a(K.exports)

很明显，Q就是Pkcs7
经过验证，这个AES就是原生的，而加密的字典中也只有salt是会改变的，其他的全部写死都是没有问题的

salt

解决了加密的逻辑，回来看一下salt是怎么出来的
在inspect中可以看到，当前salt的值是20702，seed是7NzPy5ID，向上跟栈，发现在调用inspect之前出现了20702的数字，

 复制代码 隐藏代码
let a = function(e, t=20) {
  const n = te;
    for (var r = 0; r < 1e8; r++) {
        const a = SHA256(e + "" + r)["toString"]();
        for (var i = 0, o = 0; o < a.length; o++) {
            if ("0" != a[o]) {
                i += 4 - parseInt(a[o], 16)["toString"](2)["length"];
                break
            }
            i += 4
        }
        if (!(i < t))
            return r
    }
    return 0
}(seed, 16);

手动解混淆,这就是生产salt的逻辑了。
到这里为止，所有的加密都已经解决了，按照顺序请求接口即可获得cookie，另外通过纯py协程来请求，同时请求20个用时不到6秒钟，速度上还是可以的