[js逆向补环境专栏]过xhs的x2 x-s环境检测 -- part1

[补环境]过xhs的x2环境检测 – part1
Xhs的jsvmp用算法逆向确实容易头秃，扣代码对vmp而言也用处不大，此时补环境的重要性就出来了，通过把运行js的环境伪造得像浏览器一样，就能模拟出好像请求都是通过浏览器发起的一样。

这里要区分两个问题:

1.补环境是为了补充nodejs没有的一些方法，对象等

2.补环境同样是为了规避nodejs被检测

这两个听起来很类似但确实不同

比如如果node运行代码提示没有window对象，那么这个属于情况1

但是如果代码里有这么一段代码:

let nd = global==undefined
if (!nd){
X2=“此人不是浏览器”
//做一些见不得人的检测勾当，把你的调试引入歧途……
}

这样的代码即为检测nodejs的代码，这些代码悄悄地进行检测，然后把xhs的x2参数变得和浏览器不一样，让你无法得到正确的x2，

为了生动形象，加深对技术本质的理解，本着知其然还要知其所以然的态度，我们以xhs的代码为例，一步一步深入挖掘，看看补环境的是是非非……

故事开始……

今天我拿到了xhs的加密js源码，我直接一个Ctrl c把所有的代码，复制到本地，添加下面的代码测试加密函数:

var u = “/api/sns/web/v2/comment/page?note_id=648723c9000000001300a677&cursor=”;
function get_xsxt(url, json_data){
let ans = window._webmsxyw(url, json_data)
return ans
}
let ans = get_xsxt(u,“”)
console.log(ans)

保存为xhs.js，好！打开终端，输入node xhs.js，坐等结果，好！逆向真简单！

不出意外的话还是出意外了，提示没有window对象，这就是补环境的发源之地，行吧，那我就补上window对象！也就是说这份代码会使用到window对象里面的一些东西，包括但不限于使用里面的对象啊、方法啊、值啊等的，这个时候补充window=global、（或者window={}，然后一步一步的补充需要的对象），但是window=global简单粗暴但是也容易被检测到你使用的js runtime和浏览器不一样，那么你就坐等被检测吧……，但是！我们由浅入深，就看看他妈的，他能怎么检测，我就用window=global试试先：

提示没有RegExp这个东西，但是明明global对象是有这个函数的啊：

不管他，我们按照浏览器的将RegExp补充在window对象上，我们补上：

window.RegExp = function RegExp(){};
再次运行：

好家伙，还是有问题，于是，我们一观察调用位置，也许_ace_0a916._ace_936这个对象就不是window呢？

于是我们直接打个断点来进行调试看看，到底是谁调用了RegExp属性！

我勒个去去，调用者936是undefined……，那肯定是没有RegExp属性的……，那么这条路走到这，是不是意味着走不下去了呢？如果就自己手动往上跟栈的话，是比较头疼的……那么，我们不妨试试一开始补window={}看看效果如何？

结果出乎意料的相似，是一样的，那么现在怎么办呢？打开思路，我们去浏览器同样断下来看看这个地方正确的应该是什么？

那么就奇了怪了，为什么我们补充了window对象却没有？？

这时候，我们请出所谓的补环境框架，看看这框架到底是如何解决我们这些问题的？：

通过补环境的框架可知，它是因为有circle的引用，导致我们上面的补法出现问题，因为我们上面的补法，window下面并没有window，于是我们加上看看！：

let window = global
window.RegExp = function RegExp(){};
window.window = window
再次运行：

这个RegExp的报错我们就通过了，那么为什么这个补环境的框架能够捕捉到这种情况，而我们手动没法捕捉到呢？这就是得益于proxy的运用，每次一旦访问和设置proxy代理的对象的值,都会hook到，也就是链式的hook，于是，便有了补环境框架的由来。

书归正传，我们现继续手动补着看！

现在需要补充createElement，这个定义在了document上，我们直接补充：

let document = {};
document.createElement = function createElement(tagName) {
let tagname = tagName.toLowerCase() + ‘’
debugger;
return {}
}
运行看看：

还是这个错，借鉴上面的思路，我们需要把document作为window的属性加入进去，于是调整补充的代码：

let document = {};
document.createElement = function createElement(tagName) {
let tagname = tagName.toLowerCase() + ‘’
debugger;
return {}
}

let window = global
window.RegExp = function RegExp(){};
window.document = document;

window.window = window
运行看看：

补充这个getAttribute，这个有过正向设计的经验的人都知道，这是HTML元素获取自己的属性的方法，那么假如你是没有正向设计的经验的人，也可以通过这个网站去查看，（不过我建议最好学习正向设计，后面看效益也会在星球发布教程，主打一融会贯通和深入理解）。

getAttribute 如下资料：

这个方法应该定义在被创建的元素的对象上，那么我们这次仅仅针对xhs就直接这样补：

let document = {};
document.createElement = function createElement(tagName) {
let tagname = tagName.toLowerCase() + ‘’
debugger;
return {
“getAttribute”:function getAttribute(attName){
debugger;
return “”
}
}
}

let window = global
window.RegExp = function RegExp(){};
window.document = document;

window.window = window
运行看看：

也不行，这个就奇怪了……，
那么答案只可能有一个就是，调用者不是创建的元素，而是另有其人！
那么我们可以，在这个地方打上断点，去浏览器看是什么元素调用的getAttribute属性:

通过断点能看到是documentElement,查资料如下:

因此补充为：

document.documentElement = {}
document.documentElement.getAttribute = function getAttribute(attName) {
console.log(“getAttribute->”,attName)
}

再次运行：

这里也是老方法，打上断点对比浏览器得出，8721是getContext方法，于是补充：

let window = global;
let document = {};

document.documentElement = {}
document.documentElement.getAttribute = function getAttribute(attName) {
console.log(“getAttribute->”,attName)
}
document.createElement = function createElement(tagName) {
let tagname = tagName.toLowerCase() + ‘’
console.log(“createElement->”,tagname)
const canvas = new (function () { })
canvas.getContext = function getContext(pixs) {
console.log(“getContext->”, pixs)
debugger;
return {}
}
return canvas
}
window.RegExp = function RegExp(){};
window.document = document;
window.window = window;
再次运行：

终于输出值了，很明显值不对，此时的x2为：

而浏览器的x2为：x2=0|0|0|1|0|0|1|0|0|0|1|0|0|0|0，显然是不正确的

肯定是某些环境检测没有通过，导致的，就比如我们的cookie是必须的，但是手动补的方法，从头到尾对于我们来说对cookie的关键性都是无感知的，因此，这种错误驱动型的补环境策略并不靠谱。

因此，我们需要引入proxy代理，便于对那些不抛出异常的检测点进行捕捉，然后补上环境，我们放在下一篇part2中介绍。
记得加入我们的学习群呀！
529528142