参数介绍

逆向接口：aHR0cHM6Ly93d3cudGlrdG9rLmNvbS9hcGkvc2VhcmNoL2l0ZW0vZnVsbC8=

本篇文章逆向参数为x-gnarly， 下面搜索接口为例，观察发现，是个324位的字符串：

流程分析

搜索参数名，在webmssdk.js找到，和x-b参数生成位置相近，如下：

往下跟值，进入熟悉的S参数，vmp控制函数

在vmp执行指令的位置，d[c](u)，打上日志断点，找到x-g参数生成的地方

发现和x-b生成流程类似。于是分析执行的指令索引，找规律，发现了经过了81次指令的重复执行，不难猜到，81*4 = 324，每次生成4个字符，经过81轮，生成了最终的324个字符。另外，此处有个小坑：在进行进行到第81轮的时候，和之前的指令有些许变化，跟值发现，最后一轮只按照规律生成了3个字符，然后将最后一位拼接上了一个“=”。

和x-b的加密流程类似，都是由一个固定字符串的码表，和一个242位的乱码生成。那么下面的目标就是找到乱码是怎么生成的。

乱码生成

乱码长度为242位，往上观察，发现242位的乱码是由几段其它乱码拼接而成，但是拼接方式不清晰，只知道前面一个K被分离出来的了。

观察现有日志缺少感觉，于是我们把跟值过程中发现的C方法（赋值操作），也打上日志点

搜索K后面的乱码，找到最初出现的位置。长度为193。

初始乱码长度为242，找到了1位字符和193位乱码，还少48位。刚好在初始乱码拼接生成的地方，就看到了一个48位的乱码生成

于是我们将这三段乱码拿下来，发现刚好是由"K"，193位乱码和48位乱码拼接而成。至于拼接位置，不确定。

那么接下来的目标就是：1.寻找193位乱码来源（以下简称乱码1）；2.48位乱码来源 （以下简称乱码2） 3.193位乱码和48位拼接位置

乱码1生成

日志里面全局搜索乱码1，是突然出现的，但是再往上翻，发现同样有另外一段乱码再逐渐生成 ，最后生成的结果也是193位，另外次乱码中还有明显的md5加密的结果，可能和请求参数有关。由此猜测，乱码1和此193位乱码有关（以下简称乱码3）。

经过跟值，发现乱码3生成乱码1位置：

将此段代码扣出，并且将关联的n.A.u[834], n.A.u[835]扣出，整理发现是个chacha加密。

chacha加密参数除了乱码3，还涉及rounds和key。

再往上定位，发现rounds和key来源于另外一次S函数的加载

有趣的是，执行了几次S函数，发现结果都不一样。看上去是随机的，于是可以假设f.key，f.rounds，f.keyString不校验，写死就行。

另外发现， f.keyString是一个48位的数组，经过char转换，刚好是之前我们用于拼接的乱码2。

那么现在的目标就是找到代md5加密字符串的乱码3是怎么生成的

乱码3生成

在乱码3生成的上一步，发现了16位的数组（以下简称数组1）。对比发现，字符按序出现在乱码3中。跟值发现，是按照字符类型进行特定拼接。

各个数组的第一位，类似0-15的索引，往上查询日志，发现了正序版的16位数组。

经过跟值，找到将正序数组转换成乱序数组的算法，涉及到不停将末尾的数组插到前面的发牌算法。

下面的目标就是找到正序16位数组是怎么生成的

往上跟值可以发现，第4位是url的md5加密，第5位是空字符串的加密，第6位是UA的加密，第7位是时间戳，第9位根据计算时间戳和随机数计算得到，第10问是版本号，第11位是算法版本号，第15位是由时间戳计算得到。最后一位有前15位计算得到，最后，第1位，又由16位数组生成。

至此，分析完毕。

效果展示