某音a_bogus纯算分析

由于不会补环境，所以只能去搞纯算了

本篇文章可能不是很适合纯新手来看，倒是很适合正在搞纯算的你

某音的xbogus算法已经改成了abogus了，虽然xb还能用，但是也该更新了

jsvmp插桩：

"位置 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这个数组，然后嗖的一下，出现了一个新的数组

而且这个新数组的上一个地方的末尾，嘿，出现了上面的数组。这就说明下面这个数组是上面数组生成出来的，我这么猜测没有问题吧。

测试一下，果然一样

a961d79795d4bd27e1f3844b8f9ca8c

4580cbd88b31853d37fb40a6d3026c0

至此我们迈出了历史性的一小步

突然有一位靓仔就很奇怪，明明我的操作一样，怎么出来的结果不一样啊？

因为看东西要自己看全面，这个参数的最后还加上了cus这三个字符

千万不要全听全信，写教程的也不一定的是对

有了上面的经验之后，我相信看这篇文章的帅哥美女，已经能下面这个是加密什么的了

没错，就是加密了cus，把cus的字符串经过了两次数组转换。

如果没有post就只加cus，如果有的话就在post参数的末尾加上cus

这两个参数的加密到这里就完成了

我们得到了两个数组

先放在这里，后面要用。

UA加密

之前研究过某音的小伙伴一定知道，如果请求的ua改变的话，生成的这个加密参数就会失效。

所以呢，ua也肯定是校验的一部分。

我们该怎么知道这个jsvmp是如何操作ua的呢

当然是继续看日志了！

没往下滑几行，就看见了我们亲切的ua。

但是好像没对我们的ua操作什么，倒是出现了一个奇怪的unicode

我们亲切的把它称为小乱码，那这个小乱码是怎么来的呢

看到这个神奇的小数组没有[0.00390625,1,14]

我们把他扔到控制台里，然后获取对应字符

嗯，一模一样啊

什么？你想知道0.00390625是怎么来的？

那我就满足你的好奇心

其实是这么得到的

不过这个乱码是有好几个类型的

这个倒是无所谓，我就根据第一个来

还没走几步呢，我们的日志又出现新东西了

从这日志上来看，我可以大胆地推测，后三行那一堆乱七八糟葫芦蛋糕的东西，是从这里进入生成的

为了确定我们的推测，肯定不能光靠眼睛看了

我们去插日志点的位置打上条件断点

m==17&&r==1379

重放后一步一步的跟栈，我们会进入一个新的jsvmp

进入之后不要慌，我们直接在老地方插上日志点

继续分析

UA乱码生成

我们刚进入这个jsvmp，就发现这个日志跑了好多东西

慢慢往下滑，滑到256这里

可以发现是生成了长度为256的空数组

搞纯算，不能光看，还得写

我们直接实现一下

然后继续看

这里我就直接把我当时的记录放上来吧

然后给大家演示几个

大家看不懂很正常，因为我现在都有点看不懂了

我就演示一个给大家看看，你们多加油

因为我们生成了256位的数组，肯定不是白生成的

要往里面填充东西的

我截图的是演示的第三位

为什么第一个红框的第三位是1呢

正常来说应该是0,1,2,3，应该是2才对

实际上就是因为前面在计算数值的时候，会把算之前的位数，放到算出来的地方

比如，从日志可以看出

2+1=3

"\u0000\u0001\u000e".charCodeAt(2)=14

3+14=17

算出来17之后，把第三位替换成17，然后把1放到第17位上

就是这样循环的，直到最后一位

然后我们得到了一个新数组

接着，就是新的一部分

新部分就是我们的上面的数组，跟我们亲爱的UA，进行一些不为人知的交易

这里我就用文字描述一下吧

把新数组设为a

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