微信读书网页端逆向

微信网页端基本上没做什么防护，除了一个ob类的混淆几乎就没有了，数据在e_1e_2e_3那四个请求里，对请求的数据做了一些变换，然后拼接再BASE64解密一下就得到一个章节的网页了。

里面有若干个这样的参数：

其他几个基本上都很容易找出来，做不做ast都行，因为真的很简单手找也不难。比较麻烦一点的是pclts这个，转了好几处最后发现还是对一个ct一样的timestamp做上面的e加密。最后还有一个s值：

这里也有点坑，网页端的几次请求里会有一次预请求，里面将上面的这个字典做了拼接字符串，但是额外添加了一个chapterUid的值，导致请求不通过，实际上还是没有仔细去查看整个请求流程，导致没发现第一次请求实际上是虚假请求。

另外cookie的部分，其他都几乎不变，除了每次请求可能这个值要更改一下：

我本来以为还会有其他的请求做预请求，导致我一直没法得到正确结果，但实际上好像这样做的话也有麻烦的地方，可能阻塞请求影响用户体验所以没人做把。

最后这里用到两个很关键的HOOK：

(function() {
    'use strict';

    let cookie_accessor = Object.getOwnPropertyDescriptor(Document.prototype,"cookie");
    let get_cookie = cookie_accessor.get;
    let set_cookie = cookie_accessor.set;

    Object.defineProperty(document, "cookie", {
        get: function () {
            return get_cookie.call(document);
        },
        set: function (cookie) {
            debugger;
            console.log(cookie);
            console.log(new Error().stack);

            set_cookie.call(document,cookie);
        }
    });
})();
//cookie这个没生效，大概是因为我使用位置的问题

var originalSet = Object.getOwnPropertyDescriptor(
  Element.prototype,
  "innerHTML"
).set;

Object.defineProperty(Element.prototype, "innerHTML", {
  set: function(value) {
    // change it (ok)
    debugger;

    //Call the original setter
    return originalSet.call(this, value);
  }
});

不得不说和它请求的东西相比，他的加密确实几乎没做，感觉qidian之类的应该麻烦很多。