js逆向案例-dy之X-Bogus/signature算法分析【转】

# 目录
## 一、案例分析
## 二、signature定位与分析
## 三、X-Bogus定位与分析
## 四、滑块captchaBody还未研究

## 一、案例分析
- 案例网址如图，研究的是这个接口，获取用户视频的接口

![](/media/202206/2022-06-21_092451_556787.png)

- 研究的参数是请求参数当中的X-Bogus和_signature，并不是所有接口都需要这两个参数，有的并不校验，有的只有cookie即可了，有的有这两个参数即可了，具体接口具体分析，本文只是研究下这两个参数的生成逻辑思路

![](/media/202206/2022-06-21_092516_477906.png)

## 二、signature定位与分析
- 采用xhr定位signature，首先清除缓存，然后刷新网页，会定位到如图位置

![](/media/202206/2022-06-21_092659_687340.png)

- 往前堆栈回溯定位，发现signature的生成逻辑是在这个webmssdk.js里面生成的

![](/media/202206/2022-06-21_092714_503465.png)

- webmssdk.js是混淆的，所以我们直接利用v_jstools插件进行一个变量压缩还原，v_jstools的使用，并将初步解混淆的js保存到本地文件并命名为webmssdk.js

![](/media/202206/2022-06-21_092943_011920.png)

- 然后我们用fiddler进行替换，将网页混淆的js替换成我们本地的解混淆的js

![](/media/202206/2022-06-21_093021_704215.png)

- 此时刷新网页，会报错如下Access-Control-Allow-Origin跨域错误

![](/media/202206/2022-06-21_093034_886101.png)

- 解决Access-Control-Allow-Origin跨域错误，可以用fiddler进行如下设置，在Filters下设置Response Headers的跨域问题

![](/media/202206/2022-06-21_093045_707864.png)

- 此时我们再次清楚缓存，刷新网页，会发现混淆的webmssdk.js变量已经清新了许多

![](/media/202206/2022-06-21_093054_947763.png)

- 开始分析signature算法逻辑，首先在js当中插桩打上如下日志断点，主要是看插桩日志分析逻辑，所以混淆与非混淆的影响不是很大，二选一，不过混淆的还是稍稍费点眼睛的，之前没有分析过，没有经验的话，还是选择还原后的js比较好，如图在184行和431行插桩打上日志
```js
# 混淆的js下打的日志：
"索引A", _0x1ff777, "索引I", _0x188445, " 值：", JSON.stringify(_0x6f0288, function(key, value) {if (value == window) {return undefined} return value})
# 非混淆的js下打的日志:
"索引A", A, "索引I", I, " 值：", JSON.stringify(S, function(key, value) {if (value == window) {return undefined} return value})
```

![](/media/202206/2022-06-21_093143_352042.png)

![](/media/202206/2022-06-21_093148_635495.png)

- 最终打印出来的日志差不多1w行，然后通过搜索日志去分析组成逻辑

![](/media/202206/2022-06-21_093158_000957.png)

- signature：_02B4Z6wo00001ZvTpJQAAIDAEJg.d0yVePmb06AAAATP14由9部分组成

![](/media/202206/2022-06-21_093214_760412.png)

- 第一组是固定的，拿第二组、第三组举例，每一组都是由长数字35392257845541转换而成，每一个字母都是由String.fromCharCode转换而成的，而图中的长数字是怎么来的，char_to_signature函数又是怎么来的，这个在我的jsvmp纯扣算法里面有讲逻辑思路，所以这里不再重复详细介绍，思路流程算法代码几乎一致，只是传参有所变化，至此signature已分析完

![](/media/202206/2022-06-21_093224_086265.png)

![](/media/202206/2022-06-21_093230_221414.png)

## 三、X-Bogus定位与分析
- X-Bogus与signature定位方法是一致的，在前面xhr定位包括插桩日志当中我们其实已经发现X-Bogus的生成结果了，这里的分析算法思路依然是用的jsvmp纯扣算法这篇文章的介绍

![](/media/202206/2022-06-21_093321_468610.png)

- X-Bogus的比signature稍难些，难在分析长数字的组成，signature由9部分组成，x-bogus由7部分组成，DFSzswVOx8zANGR8SRc5oPt/pLv8，这个算法主流程和这篇文章的流程是一致的，区别在于md5_str的生成不一样，x-bogus的会更复杂一些

![](/media/202206/2022-06-21_093329_053732.png)

- 如图第1组和第7组，我们又遇到的长数字196397和934988，如图第7组则是长数字经过转换而成，而每个字符串是由固定的字符串取索引而得，至于这里的长数字和num_to_X_Bogus函数是怎么生成的，我们看接下来的分析

![](/media/202206/2022-06-21_093337_497181.png)

![](/media/202206/2022-06-21_093344_004210.png)

- 然后我们拿第一组的长数字196397其实是由`(2<<16)|(255<<8)|45换算而得，而一些奇怪的数字其实是由乱序的字符\u0002ÿ-%.*ÔË^–\fñŽšš¿N\u000eDL转换而得，具体自行领会了`

![](/media/202206/2022-06-21_093348_830015.png)

- 至于生成长数字的乱序的字符串\u0002ÿ-%.*ÔË^–\fñŽšš¿N\u000eDL又是怎么生成的，这里比较难暂不公布了，但是只要掌握了前面的分析思路都是能扣出来的，其中往前分析会遇到md5，而md5算法没有做改动，用var md5 = require("md5")是一致的，但是用CryptoJS.MD5(a).toString()对于Uint8Arrary进行md5加密是不一样的，所以需要注意下，还会涉及一些Uint8Arrary转数组

![](/media/202206/2022-06-21_093418_042265.png)

- num_to_X_Bogus函数如何生成，这里其实也有开源的代码，看这个文章，我就点到为止了，自行根据插桩回溯条件断点等调试领会

![](/media/202206/2022-06-21_093424_355248.png)

## 四、滑块captchaBody还未研究
- 通过堆栈回溯的方式找到VM的文件，然后插桩打日志分析逻辑，初步猜测和AES-GCM有关，其它后面有空再研究吧

![](/media/202206/2022-06-21_093435_004209.png)

![](/media/202206/2022-06-21_093440_426853.png)