逆向某网站sign签名算法

这家接口的防爬策略太可怕了。
1.签名尝试出错两次，直接封杀ip。甚至我4G的ip都给封了。
2. 访问次数，达到100次也会被封杀ip.

看来是我没有重视这个对手，give you some color see see，看来我要赤膊上阵了。

/n0/home/posts/recommend
url params
start=10×tamp=1587096670288&sign=a514ae100ac2952c23e65f76aef71df690977d28
start 数字,代表当前第几页
timestamp = Date.now()
关键就看sign怎么生产，也就是要通过js反向推算出生成sign的方法

打断点

t和e的值

功夫不负苦心人，通过sign这个关键字，我还是找到了突破口
timestamp = Date.now()
sign = Vo(t.params)

Mo在这里

        function Mo(t) {
            for (var e = 1; e < arguments.length; e++) {
                var n = null != arguments[e] ? arguments[e] : {};
                e % 2 ? No(n, !0).forEach(function(e) {
                    Object(s.a)(t, e, n[e])
                }) : Object.getOwnPropertyDescriptors ? Object.defineProperties(t, Object.getOwnPropertyDescriptors(n)) : No(n).forEach(function(e) {
                    Object.defineProperty(t, e, Object.getOwnPropertyDescriptor(n, e))
                })
            }
            return t
        }

接下来就看Vo是什么

{"start":80, "timestamp":1587101418832}
["start=80", "timestamp=1587101418832"]

然后做一个hash

对应的解析成python代码，太完美了，太爽了。

---

接口响应里面也使用了，这个是和ip关联的
x-ratelimit-limit: 10000
x-ratelimit-remaining: 9681

根据我探测到的信息句子控内部使用了kong作为网关

{"Content-Type": "application/json", "Transfer-Encoding": "chunked", "Connection": "keep-alive", "Server": "nginx/1.10.3 (Ubuntu)", "Cache-Control": "no-cache, private", "Date": "Fri, 17 Apr 2020 07:15:36 GMT", "X-RateLimit-Limit": "10000", "X-RateLimit-Remaining": "9702", "Access-Control-Allow-Origin": "https://www.juzikong.com", "Vary": "Origin", "Access-Control-Allow-Credentials": "true", "X-Kong-Upstream-Latency": "559", "X-Kong-Proxy-Latency": "0", "Via": "kong/1.4.0"}

{"Content-Type": "application/json", "Transfer-Encoding": "chunked", "Connection": "keep-alive", "Server": "nginx/1.10.3 (Ubuntu)", "Cache-Control": "no-cache, private", "Date": "Fri, 17 Apr 2020 07:15:37 GMT", "Access-Control-Allow-Origin": "https://www.juzikong.com", "Vary": "Origin", "Access-Control-Allow-Credentials": "true", "X-Kong-Upstream-Latency": "147", "X-Kong-Proxy-Latency": "0", "Via": "kong/1.4.0"}

为什么使用kong作为网关？

传统型的先访问api,然后在api里面进行限流，速率控制，这样存在问题就是大量重复工作，例如daijingi款产品防止刷单的做法就是这对下单接口做了处理。可后来登陆接口也被人刷了，然后又针对登陆接口进行了频率的限制。
kong可以把网关做到api的前面，这样的话可以让业务开发者不需要关心网关层次的东东，只需要去写业务就好了。

kong
jwt
dubbo
mq
k8s
是不是意味着很容易就可以作出能够承担大量用户系统来呢？
但有一个问题就是用户为什么要用你？能够做im的太多了，但用户只用腾讯家的啊。