分析CF活动网站请求总结

 近日，朋友委托我做一个CF活动的辅助工具，这种工具都是靠模拟请求来实现的。既然是模拟请求，我们需要知道该网页是怎么进行请求的（主要是查询参数、首都的分析）？它返回的信息是什么？代表什么含义？我们可以通过Firefox开发者工具分析请求信息从而分析其请求的逻辑和要素。网站是这个：https://act.daoju.qq.com/act/a20190701wish/?appinstall=0，一般像这种请求，都是使用ajax进行的，所以我们只需要看XHR的部分，我们来分析选中的这个请求，这个是进行抽奖的请求，主要分析查询参数:

  我们凭借经验判断，iActivityId、sSDID、iMiloTag是可变参数，如果不确定，我们可以选择多刷新几次页面对比参数的变化甚至直接更换账号对比请求的变化来进行判断。

  iActivity是活动id，在活动下是不变的；

 sSDID在刷新后不变，清除缓存重新登录账号未发生变化，推断其是活动不变参数；

 iMiloTag一看就是个磨人的小妖精，参数值有点长，我们现在对它进行解剖，AMS-MILO-在多次请求中前缀不变，238098是活动id，582734是子活动id，o1692238789是uid，其实就是o{qq号}，后面1574682…，我们需要记住157开头的很长的数字一般为时间戳，可能是毫秒，可能是秒，我们可以通过工具转成时间来判断。当然，有些场景下也可能会追加随机数，我们只要进行不断截取测试就能判断。后面MjtUpr这个很难判断，可能是随机数，也可能是某种规则生成的关键信息。

 为了搞清楚sSDID和iMiloTag两个参数的生成策略，我们需要分析js代码，当然不是直接看源码，我们要借助浏览器自带的js调试。首先，我们需要知道这个请求的调用堆栈：

 onmessage看起来像是个事件监听方法，我们进入onmessage方法里可以看到：

 参数是通过e这个对象传递的，open的参数分别为：method、url、是否异步，我们可以分析到data[0]为method, data[1]为url，data[2]是请求体，但是这里看不到任何关于参数的规则，继续往下看onmessage是否被调用：：

 我们从上面代码可以看出，onmessage监听了message事件，这是啥？查阅搜索引擎可知，这是一个跨窗口通信的一组api，跟postMessage配套使用，H5提供，具体参见文档：https://developer.mozilla.org/zh-CN/docs/Web/API/Window/postMessage，我们只要知道postMessage发送消息，会触发onmessage方法。先不管postMessage，我们调试onmessage方法。

 具体调试面板信息参见上图。

 我们重点分析上图，这个是e变量的内容，我一直不知道orgin和source对我找message的源有何用处，这都是站点而已。研读文档可知orgin只是用于区分消息站点来源的，防止别的站点发送消息进行脚本注入。但是source的存在就很莫名其妙，source有多个站点，我对这几个URL对应的文件研究了好久，都没找到postMessage的踪影。线索到这里就断了，我们现在只有一个目标—找到postMessage，我刚开始是一个一个文件扒开找的，但是无果。这里我推荐一个技巧，将所有请求导出来，然后把所有的文件以项目的形式写入到磁盘，再用idea或者sublime打开，使用他们的Find in path就非常方便了。导出步骤如下：

 导出结果其实就是json文件，我们可以通过解析json文件，把响应的内容保存到文件中，然后进行查找就行了。

 回到最初的问题，我们导出了所有js、html文件，并使用idea打开为项目，现在可以为所欲为了，先查找sSDID：

 很明显这个值是文件定义的，活动范围内不变，再看看postMessage:

 简直不要太方便，如果我们需要哪个参数，直接在文件夹中进行查找即可找到规则。读者可以自己进行实践学习更多web方面的知识。我们通过分析别人的站点，可以看到一些相当巧妙的思路，比如首先是postMessage API很新鲜，这是一个新的分析思路，而且也可以在业务中解耦使用；其次我掌握了新的分析web请求的方式：分析HAR文件。HAR分析工具现在代码已经写好了，之后会上传到github上，还有正在开发中的面向配置的活动请求工具。