2019年末逆向复习系列之知乎登录formdata加密逆向破解

郑重声明：本项目的所有代码和相关文章， 仅用于经验技术交流分享，禁止将相关技术应用到不正当途径，因为滥用技术产生的风险与本人无关。

这篇文章是公众号《云爬虫技术研究笔记》的《2019年末逆向复习系列》的第五篇：《知乎登录formdata加密逆向破解》

本次案例的代码都已上传到Review_Reverse上面，后面会持续更新，大家可以Fork一波。

逆向背景

知乎作为国内最大的、最优质的的问答平台之一，它的高质量回答是作为自然语言处理的最好的语料来源之一，不过想要获取更全的知乎回答数据必须要登录，涉及登录的话必然少不了做自动化登录的处理，不过知乎的登录post请求中的formdata是加密的

因此我们需要去寻找它的加密逻辑，本篇文章就是讲解如何寻找破解formdata的加密，实现自动化登录知乎。

分析流程与逆向破解

因为formdata只要一个加密后的字符串，对于我们来说，没有一个明显的特征让我们去全局搜索，因此我们采用的是xhr断点的方法去寻找哪里加密了formdata，我们通过initiator进入

根据登录api的url: /api/v3/oauth/sign_in来打xhr断点

重复我们之前的登录逻辑，可以看到，xhr断点打在如图所示位置

接下来，我们就可以通过call stack调用栈来寻找哪里加密了formdata，一个个调用分析之后，看到如图所示的地方比较符合我们期待的加密点

url确实是登录的api，并且在post请求的data处，使用了r.decamelizeKeys()方法来处理，初步估计是加密方法，我们再对r.decamelizeKeys打断点，同时去掉之前的xhr断点，这样能够帮助我们更快、更准确的定位到加密处

我们现在定位到decamelizeKeys的加密方法逻辑，这个方法包含两个参数，e和t，t现在我们还不能够准确了解它的含义，e参数的值可以直接在console里面进行打印

captcha: "mdgv"
clientId: "c3cef7c66a1843f8b3a9e6a1e3160e20"
grantType: "password"
lang: "en"
password: "asdd"
refSource: "people"
signature: "f45d273cd16f4f80e4fee3434d1c3009fb2248cf"
source: "com.zhihu.web"
timestamp: 1575300515085
username: "+8617610771895"
utmSource: undefined

我们分析，captcha和signature这两个参数相对其他参数来说还是比较重要，因此我们着重分析这两个参数

1. 寻找signature加密参数的加密逻辑

signature这个参数还是具有明显特征的，我们可以全局搜索

match的地方只有两个js文件，我们具体查看，可以在其中一个文件搜索signature关键字，发现它的相关代码段，这段代码很明显的是hmac算法

涉及到的值有clientId、timstamp、grandType等

插入一句：Hmac算法大致解释如下

Python的简单实现

import hmac
from hashlib import sha1


def hash_hmac(key, code, sha1):
    hmac_code = hmac.new(key.encode(), code.encode(), sha1)
    return hmac_code.hexdigest()

if __name__ == '__main__':
    print(hash_hmac('08F5B4886112BC6F1E04FE42DACDB2E8', 'xinxin', sha1)

大概了解hmac算法是什么之后，我们再回头看看signature的hmac算法的逻辑是什么

具体的思路如图所示，使用sha-1作为hash函数，key是写死的，使用其他四个参数值作为message进行加密，整理思路可以用python表达出来

def _get_signature(timestamp: int) -> str:
    ha = hmac.new(
        b"d1b964811afb40118a12068ff74a12f4",
        digestmod=hashlib.sha1
    )
    grant_type = _login_data["grant_type"]
    client_id = _login_data["client_id"]
    source = _login_data["source"]
    ha.update(
        bytes(
            (grant_type + client_id + source + str(timestamp)),
            "utf-8"
        )
    )
    return ha.hexdigest()

分析完signature参数之后，我们接着来分析captcha参数

2. 分析captcha的不同场景

captcha，顾名思义是验证码结果相关的参数，这个参数的值应该是验证码相关，如图所示，验证码图片是由这个接口来返回的

我们请求了这个接口，返回了图片的base64格式，我们可以这么进行保存

with open("./captcha.jpg", "wb") as f:
            f.write(base64.b64decode(img_base64))

关于captcha的分析呢不涉及到具体的js，因为captcha的值我们可以很明显的看出来

当我们请求中文验证码lang=cn-也就是翻转汉字点选，我们传的值是：

captcha: "{"img_size":[200,44],"input_points":[[43.39996337890625,30.79999542236328],[135.39996337890625,22.79999542236328]]}"
clientId: "c3cef7c66a1843f8b3a9e6a1e3160e20"

当我们请求英文验证码lang=en-也就是四位英文字符，我们传的值是：

captcha: "mdgv"

所以关于captcha，是根据我们请求验证码类型不同传不同的值的，captcha参数也分析到这里，我们再把其他的参数整理一下

3. 分析剩余其他参数

其他的参数就比较好看出来了

clientId: "c3cef7c66a1843f8b3a9e6a1e3160e20"   多次试验，写死的
grantType: "password" 非第三方登录的话都是这个值
lang: "en" 针对不同验证码类型
password: "asdd" 密码
refSource: "people" 不变
source: "com.zhihu.web" 不变
timestamp: 1575300515085 时间戳
username: "+8617610771895" 用户名
utmSource: undefined 不变

到这里我们关于decamelizeKeys加密方法的e参数已经分析好了，t参数还未知，那我们就继续从刚才decamelizeKeys函数那里继续往下找，分析decamelizeKeys函数的加密逻辑

4. 分析decamelizeKeys的加密逻辑

同样是针对decamelizeKeys函数下断点，看到跳到这个地方，m方法返回n方法

查看o方法的具体逻辑

o = function e(t, n, r) {
        if (!d(n) || p(n) || h(n) || v(n) || l(n)) //基本没什么用，可以跳过
            return n;
        var i, o = 0, a = 0;
        if (f(n))  //这里做逻辑判断，可以扣具体js
            for (i = [],
            a = n.length; o < a; o++)
                i.push(e(t, n[o], r));
        else
            for (var s in i = {}, // 循环n（也就是data），不断的和下面那个c函数做处理
            n)
                Object.prototype.hasOwnProperty.call(n, s) && (i[t(s, r)] = e(t, n[s], r));
        return i
    }
c = function(e, t) {
        return function(e, t) {
            var n = (t = t || {}).separator || "_"
              , r = t.split || /(?=[A-Z])/;
            return e.split(r).join(n)
        }(e, t).toLowerCase()
    }

加密的逻辑主要是上面这个部分，没有混淆和平坦化什么的，大家可以自行扣扣

代码实战

根据上面的思路，我们完善代码

关于加密部分

注意下图我们在请求headers中加了两个参数

• "x-zse-83": "3_1.1" 这个参数是用来验证客户端的版本，大概是和clientId相关，如果我们不传的话，会提示请求参数异常，请升级客户端后重试这个错误
• "x-xsrftoken": _get_xsrf() 这个参数是跟跨域相关，是为了防Xsrf跨站的Token认证，访问首页时从Response Headers的Set-Cookie字段中可以找到

关于实战部分

注意，我们获取的是加密方法返回的headers、data、session，之所以要拿headers，是因为我们在请求验证码的时候，返回的Response Headers的Set-Cookie中有个CAPSION_TICKET字段，如果我们在post的时候不传这个cookie字段，会报错

{"error":{"message":"缺少验证码票据","code":120002,"name":"ERR_CAPSION_TICKET_NOT_FOUND"}}

最后注意请求的顺序，先获取验证码，再post，如果你成功的看完这篇文章，那么你会收到登录成功的结果。

复习要点

从这个复习的案例我们可以总结下思路：

1. 在参数没有明显特征的时候，打xhr断点
2. 在做自动化登录的时候，每一步的header都很重要，如果你算出加密的结果却还是报错，看看是不是你漏了哪一个请求返回给你的某样东西

---

作者相关

号主介绍

多年反爬虫破解经验，AKA“逆向小学生”，沉迷数据分析和黑客增长不能自拔，虚名有CSDN博客专家和华为云享专家。

私藏资料

呕心沥血从浩瀚的资料中整理了独家的“私藏资料”，公众号内回复“私藏资料”即可领取爬虫高级逆向教学视频以及多平台的中文数据集

小学生都推荐的好文

2019年末逆向复习系列之今日头条WEB端_signature、as、cp参数逆向分析

2019年末逆向复习系列之百度指数Data加密逆向破解

2019年末逆向复习系列之努比亚Cookie生成逆向分析

2019年末逆向复习系列之淘宝M站Sign参数逆向分析