去哪儿pre、__m__、t1000参数分析

声明：本文仅作技术交流，严禁用于任何非法用途（如有冒犯，请联系我删除此文）
网站地址https://flight.qunar.com/

打开chrome调试工具，查看请求，通过分析，得知主要的注意点：

1. 请求头需携带pre参数
2. 请求参数中需携带__m__参数
3. 返回值是乱序的，不能直接拿来使用

1.分析pre请求头

使用chrome调试工具，直接搜索源文件，发现pre请求的值是window.pt

经过分析得知，它是由请求页面中的第一个script标签中的代码赋值的

直接将这段代码复制下来，在当前页面打开snippets下新建个文件，将js代码粘贴进来，先将window._pt_的值设为nuull,然后执行js，发现生成了window_pt_的值，确认是由这段代码生成的window.pt

直接分析这个js文件，复制代码到本地，运行，提示window对象不存在，说明代码中有使用到浏览器的内置对象，在代码前面声明var window = {}（这个时候就是缺啥补啥了），格式化代码，调试一下，发现代码一直在执行中，应该是陷入死循环了，一般这种格式化之后执行结果不一样的情况，都是做了代码完整性判断，然后进入死循环或内存爆破。

直接在每一个for循环和if代码中打上断点，开始了痛苦的调试过程，经过一番痛苦的调试发现，代码中主要是判断window.location、document、navigator、screen等一些参数是否为空，如果为空，则进入死循环，过程比较长，就不一一概述了，补好环境之后，大概是这个样子;

成功运行js，值与浏览器一致

2.__m__参数

跟pre一样，直接搜索，得知，__m__也是由js代码生成的值

进入encrypt方法，调试一会，发现流程基本如下：
1.t是页面返回的一段字符串
2.n是cookie中的参数，然后通过一段转换代码，转换成一个数组，数据计算得出一个时间戳
3.如果时间戳是0就执行md5加密,是1就执行sha加密，然后再进行两次加密
比较简单，调试一下就能得出结果

3.t1000.返回值处理

返回值处理比较简单，直接搜索，发现是调用eval方法执行t1000代码，然后返回一个函数，然后将返回值传入函数，返回格式化好的值，需要注意的是，这段代码跟pre一样，也同样检测了环境

总结

1.最麻烦的是pre参数，里面有很多循环和代码判断，每次返回的都变量名都不一样，但格式基本一样，应该是每次返回都进行了混淆，只要分析出一次，后面其实都一样
2.如果觉得分析麻烦，也可以通过selenium或chrome插件的方式获取pre，也是可行的
3.使用ast反混淆，和hook内置对象的方式，能很大程度提高分析速度
4.耐心、耐心、耐心

再次声明，本文仅作技术交流，严禁用于任何非法用途（如有冒犯，请联系我删除此文）