阿里系bx-ua:231!逆向分析

阿里系bx-ua:231!逆向分析

文章仅做技术研究、违规请联系删除

定位关键调用入口

• 直接搜索定位即可、这里比较简单

• 省事直接搜索getFYToken直接找到入口

• 不同站点也都差不多

• 单步进入是在fireyejs.js文件

扣代码

1. 全复制补环境运行
2. 逐个扣调用调用函数、对象、变量等

• 感觉补环境省事简单一点、如果是简单代码量少的扣函数还行、这文件两万多行一看就比较麻烦
• 所以这里以补环境分析，有兴趣的可以先做一下补环境分析完再去扣函数也会熟悉一些

补环境

• 这里也只能提供一些思路和麻烦点解决方案

• 如果每个步骤都细写那文章就太长了，重要点我会在后面都提出、只要认真看多尝试都可以成功跑出正确结果的

• 补环境也可以用一些库比如jsdom|canvas来减少一些代码量，后面也是根据这些库来补环境的

• 多说一句，先达到目的后面想去研究再去全手补，个人感觉其实都差不多，性能方面也是微乎其微

• 先创建对象

  delete global;
  delete Buffer;
  delete globalThis.navigator;
  delete globalThis.Navigator;
  window = dom.window;
  top = window;
  self = window;
  document = window.document;
  navigator = window.navigator;
  ocation = window.location;
  history = window.history;
  screen = window.screen;
  location = window.location;
  performance = window.performance;

• 代理函数其实都是差不多的写法、能用就行、也贴个我的版本

• 然后根据上面定位的关键调用入口，带上携带的参数调用调试不停的补上环境即可了

• 其实补一会就看到set window.__fyModule所以调用这个也行，就不用定义变量赋值调用了

• 我就不跟着一步步去补了后面贴一些关键点和麻烦点

• iamge | canvas

• 这里说下canvas，如果不使用canvas模块的话手补要根据watch出的流程顺序一步步在浏览器执行再补结果到环境中才会得到正确结果

• toString检测以及一些检测点

• setTimeout | setInterval 在node中这两个内置函数和在浏览器有点区别，浏览器中多个计数

  (function(){
    let timeoutIdCounter = 0;
    // const nativeSetTimeout = setTimeout;
    setTimeout = (callback, delay, ...args) => {
      // nativeSetTimeout(callback.bind(this, ...args), delay);
      // callback.apply(this, ...args);
      return timeoutIdCounter++;
    };
    let intervalCounter = 0;
    // const nativesetInterval = setInterval;
    setInterval = (callback, delay, ...args) => {
      // nativesetInterval(callback.bind(this, ...args), delay);
      // callback.apply(this, ...args)
      return intervalCounter++;
    };
  })()

• 可以看到我上面只用了计数功能，注释掉了功能实现，其实补到后面就知道为什么了，自执行函数中有一些延时执行会挂起node线程导致出值后不结束

• 继续补补补。。。

• navigator一些检测点

• plugins其实这里检测没这么严格可以看到我打了很多watch其实并没有用到，从浏览器顺便扣一下就行了

• localStorage | sessionStorage简单实现一个类就行了

• 继续补补补。。。补的时候把捕获异常打上断点，其实也是断try

• 其实补出值并不麻烦、花点时间心思要不了多久就能出值

• 出值后大概率是不可用的、继续通过监控出的调用对象对比一些本地和浏览器环境补上

• 直到你感觉监控代理的对象都补完了也能出值了就完成了一半了

• 为什么说完成一半了，这时候你可以根据你的逆向站点使用出的值提交试一下

• 如果能过说明压根就没校验，随便给个值就行

• 如果不能过其实是正常的，因为还有一些地方没有补到

• 回到扣出的代码、单步跟到加密函数处

• 另一个案例

• 往下看可以看到其实是一个for函数包裹一个很大的switch控制流，控制变量就是上图中的p

• 在自执行外部定义一个数组来存储控制变量，记录下每次控制变量的值就能知道执行流程

• 在浏览器和本地扣出的代码中加上数组记录控制变量

• 分别执行加密出值后取出记录值然后找个txt diff 对比两个环境的执行流程找不同、打断点就能知道是哪个环境差异导致控制流不同了

• 如果值判断赋值控制变量那就往上找控制流记录肯定能找到赋值处的

• 这里就可以找到差异环境了、都是一些监控不到的环境还有一些漏掉的环境

• 为什么不一开始就这样补？还有监控补？

  • 如果一开始就记录控制流流程分析那跟逐步跟也没啥区别了工作了反而更大了

• 其中canvas环境检测是最多的、多根据浏览器对比补上，宁多不少

• 继续补补补。。。

• 补到控制流程也完全一样了基本也就结束了

• 我的环境补完也有一千多行来、其中包括一些注释以及一些多余的监控和环境，估摸真正用到的也就千把行左右吧

• 然后就再去目标站点使用出值测试能过就可以了

• 如果还不能过就是上面为什么说基本结束了，这时候可以对比一下浏览器和node的结果长度会发现node环境出值比浏览器短一截

• 在自执行底部初始化完成后打断

• 另一案例

• 单步观察数组

• 现在是138长度，这里浏览器和本地的值应该是非常接近的、可以逐个对比一下

• 放开断点执行到加密函数处

• 往下找到自执行底部再次查看数组

• 两个案例不同结果、不过补法都是一样的、上面143长度的带有滑块

• 138长度的前段时间我看的时候还是145长度、不过都一样

• 然后再对比本地的node环境的数组值就会发现改变了一些元素值或者增加了一些元素

• 这些就是轨迹或者一些无感数据了

• 把这些差异的值补到环境中就可以了

• 两个案例我之前都有补过

• 轨迹和无感环境这样补能用？不用动态？

  • 能用！我试了几个案例固定长期用没都问题。

总结

• 在补环境的时候，补完感觉基本没问题了拿去用只要有校验基本是过不了的
• 因为有一些环境差异通过代理是监控不到的
• 大部分我上面都贴出来了
• 找差异方法也给出了、就是通过记录控制流流程，再对比一点点去分析补齐，一直补到流程相同
• bx-ua补环境的方法难点基本上都提出了，细心点相信都能补的出来
• 最后贴的成功图

下期预告

• 后面再发两篇阿里系的其他加密bx-pp | x5sec
• 其实搞明白了bx-ua其他加密就简单许多了、或者说搞通了bx-ua大多数补环境都不是难题了