本篇文章可能不是很适合纯新手来看，倒是很适合正在搞纯算的你。某APP的xbogus算法已经改成了abogus了，虽然xb还能用，但是也该更新了。
"位置 1", "索引m", m, "索引r", r, "值p: ", JSON.stringify(p, function(key, value) {if (value == window) {return undefined} return value})
"位置 2", "索引m", m, "索引r", r, "值p: ", JSON.stringify(p, function(key, value) {if (value == window) {return undefined} return value})
参数加密
可以看到reg里面有一串数组，最开始后面还没有参数，等到第五行的时候，我们的请求参数出现了。
经过了2次不为人知的操作，我们的参数变成了一行数组。
从此处我们就可以得知，这个数组，是参数转化过去的。
所以我们在下面这个索引位置设置条件断点，就可以进入到加密的过程了。
找到加密过程之后自己抠出来或者手动实现都是可以的。
再继续往下看，会发现又经过了reg这个数组，然后嗖的一下，出现了一个新的数组。
而且这个新数组的上一个地方的末尾，嘿，出现了上面的数组。这就说明下面这个数组是上面数组生成出来的，我这么猜测没有问题吧。
突然有一位靓仔就很奇怪，明明我的操作一样，怎么出来的结果不一样啊？
因为看东西要自己看全面，这个参数的最后还加上了cus这三个字符。
有了上面的经验之后，我相信看这篇文章的帅哥美女，已经能下面这个是加密什么的了。
没错，就是加密了cus，把cus的字符串经过了两次数组转换。
如果没有post就只加cus，如果有的话就在post参数的末尾加上cus。这两个参数的加密到这里就完成了，我们得到了两个数组。先放在这里，后面要用。
UA加密
之前研究过某APP的小伙伴一定知道，如果请求的ua改变的话，生成的这个加密参数就会失效。所以呢，ua也肯定是校验的一部分。
我们该怎么知道这个jsvmp是如何操作ua的呢？当然是继续看日志了！
但是好像没对我们的ua操作什么，倒是出现了一个奇怪的unicode。
我们亲切的把它称为小乱码，那这个小乱码是怎么来的呢？
看到这个神奇的小数组没有[0.00390625,1,14]
从这日志上来看，我可以大胆地推测，后三行那一堆乱七八糟葫芦蛋糕的东西，是从这里进入生成的。
重放后一步一步的跟栈，我们会进入一个新的jsvmp。
UA乱码生成
我们刚进入这个jsvmp，就发现这个日志跑了好多东西。
我们直接实现一下
因为我们生成了256位的数组，肯定不是白生成的，要往里面填充东西的。
实际上就是因为前面在计算数值的时候，会把算之前的位数，放到算出来的地方
“u0000u0001u000e”.charCodeAt(2)=14
算出来17之后，把第三位替换成17，然后把1放到第17位上。
新部分就是我们的上面的数组，跟我们亲爱的UA，进行一些不为人知的交易。
a[0]+a[1]
0+218 =>**218**
a[1]=a[218]
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.6045.160 Safari/537.36".charCodeAt(0)
77 a[220]=>216 2+218=>220
77^216=>149
String.fromCharCode(149)
**218**+a[2]=>**235**
a[**235**]=>127
分割线
a[2]=127
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.6045.160 Safari/537.36".charCodeAt(1)
127+17=>144
111 ^a[144]233=>134
String.fromCharCode(134)
**235**+a[3]=>**255**
a[**255**]=>149
a[3]=149
255+a[4]=>280 280-256=24
UA经过这一系列的加密，最后生成了一个超级大的乱码。
UA长字符串
我们去定位生成位置的上面，然后单步调试进入一个新的jsvmp。
这里的部分其实还是之前xb那样，4位一组，如此遍历。
s.chatAt(0) << 16 2293760
s.chatAt(1) << 8 22016
0^1 2315776
^s.chatAt(2)<<0 7
2315783
2315783&16515072
2097152 >> 18
8
2315783&258048
217088 >> 12
53
2315783&4032
1536 >> 6
24
2315783&63
7 >> 0
7
5373952^45056 = 5419008
5419008^240=5419248
5419248&16515072 = 5242880
第一位就这样推出来了，剩下的就靠宝贝你自己了。搞纯算没有耐心是不行的哦。静下心来慢慢看日志，总有一天能搞出来。
然后又对我们的长字符串进行了一个数组的生成，这里直接用我们上面写好的代码就可以。
环境检测点生成
这里倒是没什么难的，其实就是把每一位字符串的ascii码放到了数组里。
炒鸡大数组生成
这个大数组可谓是集百家之长，东边偷一点，西边偷一点。
从这个图上是不是就能看出来。是第一个数组的21位，第二个数组的21位。后面的64，51 就是第二个数组的22位，第二个数组的22位。剩下的就麻烦您多费心了，静下心来看日志，一会就搞出来了。里面有固定的也有不固定的，可以抓两次日志对比着来。
接着我们把写好的数组和之前的环境ascii码数组组合起来。在我们组合起来之前呢，我们要把大数组的每一位进行异或，得到的一个结果，放到我们环境数组的末尾。然后再把这俩数组合起来。得到了最终的超级无敌宇宙爆炸大数组。
最终之战
这篇文章马上就要步入尾声了，虽然写的不是很详细，但是我觉得一定对你有帮助。
从上面的日志来看，我们前面生成了3次乱码，然后合并。接着又把三次合并的乱码跟一个乱码合并。再合并之前呢，这个乱码是先由我们的超级无敌宇宙爆炸大数组，String.fromCharCode生成。
然后经过上述提到的UA乱码生成写的代码，最终加密得到一个乱码。最后，我们把这一个乱码经过上文提到的UA长字符串生成。就得到了我们的a_bogus！
成果展示！
题外话
在搞纯算的时候，网上也不乏有各种教程，但是有的教程还不如不发出来，因为太误导人了。不过大部分大佬写的教程还都是很棒很详细的。
如果你在我这里看到的芝士还不够你搞出来纯算。你还可以利用搜索引擎去寻找一下别人的教程。集百家之长，这样一定可以完成ab纯算。
看雪ID：ius
https://bbs.kanxue.com/user-home-901977.htm
*本文为看雪论坛优秀文章，由 ius 原创，转载请注明来自看雪社区
原文始发于微信公众号（看雪学苑）：WEB逆向之参数纯算分析
