new bing copilot 爬虫逆向

[bincooo]

其实new bing的对话接口逆向，十分简单，甚至不需要太大的篇幅就能说完。

入口

web js 类的逆向爬虫，必然是需要先找到你想爬取的接口入口
F12网络面板：
我们在页面上操作一次对话动作，可以看到请求wss://copilot.microsoft.com/c/api/chat

可以看到这个接口需要两个参数 api-version: 2、accessToken: xxx，api-version是固定的，所以只需要从混淆的js代码中还原accessToken 即可。

eyJhbGCi0iJSU0xxx 这种开头一般就是jwt token了，做过站类开发的同学因该很熟悉，这个一般是会在登陆的时候下发，所以想要知道它的来源，我们就需要看看登陆的过程了。

果不奇然，重新登陆后我们发现了https://login.microsoftonline.com/common/oauth2/v2.0/token接口，里面就有accessToken参数。

但是，了解过jwt的朋友都知道，下发的token都是有时限的，有的站点有效期长达1、2个月，但短的也只有区区1个小时，而new bing便是后者。

所以我们还得看看它是如何请求后台下发的， 我们查看它的请求参数：

细心观察可以发现，主要参数为 code 、code_verifier ，其它参数假定它不重要。

code参数是登陆后得到的，而且通过不断试错。我们发现它保存到了localStorage中，且长期有效。

接下来我们查看一下这个 code_verifier 是怎么出现的：

进入Initator tab 栏，可以看到发起这个请求的所有函数栈
我们选择一个executePostToTokenEndpoint进入js代码，添加断点并重新登陆：

在 body: n，n 变量中存在code_verifier。继续往外跟踪。。。

可以看到它的js混淆不是很彻底，特征其实满明显的。
在这里加上断电，继续。。。

最后发现这个code_verifier来自于acquireToken函数体里，我们继续跟进去：
情况十分明朗

const n = await Re(CQ, L.GeneratePkceCodes, this.logger, thi 这里只有CQ是回调函数，这种泛式的函数可以进去看看：

async function CQ(t, e, n) {
    t.addQueueMeasurement(L.GeneratePkceCodes, n);
    const r = Eu(SQ, L.GenerateCodeVerifier, e, t, n)(t, e, n)
      , i = await Re(wQ, L.GenerateCodeChallengeFromVerifier, e, t, n)(r, t, e, n);
    return {
        verifier: r,
        challenge: i
    }
}

很意外吧，看来这里就是我们要找的最终函数了！
它的生成已经知道了分别是SQ 、wQ ，用golang来实现一下：

func genVerifier() (challenge, verifier string) {
	data := make([]byte, 32)
	rand.Read(data)
	verifier = base64.StdEncoding.EncodeToString(data)
	verifier = strings.ReplaceAll(verifier, "=", "")
	verifier = strings.ReplaceAll(verifier, "+", "-")
	verifier = strings.ReplaceAll(verifier, "/", "_")

	data = []byte(verifier)
	sum256 := sha256.Sum256(data)
	challenge = base64.StdEncoding.EncodeToString(sum256[:])
	challenge = strings.ReplaceAll(challenge, "=", "")
	challenge = strings.ReplaceAll(challenge, "+", "-")
	challenge = strings.ReplaceAll(challenge, "/", "_")
	return
}

但是我们还不清楚challenge的作用是什么
既然如此，我们不如再从网路面板里找找线索吧。

从这个302请求的Location中，发现了code=M.C550_SN1.2.U.2，这和我们之前找的code一样，

并且从请求参数中，存在一个code_challenge值。大胆猜测它是否和code_verifier 有所关联呢？

追宗到这里其实已经ok了。

1. 请求https://login.microsoftonline.com/common/oauth2/v2.0/authorize并携带code_challenge参数
2. 请求https://login.live.com/oauth20_authorize.srf并携带code_verifier参数，顾名思义，就是用来验证上个请求的
3. 最后请求https://login.microsoftonline.com/common/oauth2/v2.0/token获取access_token以及refresh_token

最后总结一下

做爬虫十分费精力，需要不断猜想、思考和试错。
对web端需要有比较深入的了解，不然思维会被局限。
对于一些类似乱码的字符串，实际上只是一些base64编码，其内容完全可以由我们自行伪造。

逆向爬虫代码：https://github.com/bincooo/edge-api/blob/657cb89a05af42d289d74278f01f9567fae3f816/oauth20.go#L19