硕士生
 
- 金币
- 3833
- 好评
- 25
- 信誉
- 120
|
发表于
2025-11-29 18:42:28
来自手机
|
显示全部楼层
| 阅读模式
来自 广东
又成功水一天。叠甲完成而且代码模糊化完成，只剩思路强制走 QQ 网页登录通道
1. 登录入口的两条路径
APK 里的 Tencent OpenSDK 在初始化后会先执行“能力检测”例程：
- 路径 A：SSO 通道（客户端授权）
构造 Intent，setClassName 到 {minihd.qq|mobileqq|tim|qqlite}，startActivityForResult。
- 路径 B：Web 通道（OAuth2 授权码模式）
启动 WebView，访问
`https://graph.qq.com/oauth2.0/authorize?response_type=code&client_id=xxx&redirect_uri=xxx&scope=all`
用户输入账号密码 → 302 带回 code → 用 code 换 access_token。
框架的默认策略是：
“只要路径 A 可用，就隐藏路径 B；只有 A 完全失败才降级到 B。”
2. 能力检测的判定条件
OpenSDK 内部有一个辅助方法 `b(String)`，职责是“给我一个可启动的 SSO-Intent”。
它的返回值被上层这么用：
```
Intent ssoIntent = b(clazzName);
if (ssoIntent != null) {
startActivityForResult(ssoIntent, REQ_SSO);
} else {
loadWebView(); // 进入路径 B
}
```
因此，ssoIntent == null 是框架决定是否打开 WebView 的唯一信号。
3. 包名校验为何不可伪造
Android 的 Intent.resolveActivity 在 PKMS 里会做“包名-签名”双重校验；空字符串或随意包名一定返回 null。
我们不必浪费时间伪造，直接把整个方法剪成“return null”即可。
这相当于告诉框架：“系统里没有任何能响应 SSO 的 QQ 客户端”，于是自动进入路径 B。
4. Web 通道的 Cookie 隔离问题
QQ 网页登录依赖 qq.com 域下的 skey 系列 Cookie。
首次打开时 WebView 里没有 Cookie，服务器会 302 到登录页；用户输入后 Set-Cookie，随后 302 回 redirect_uri 并带上 code。
只要 WebView 的 `android:host` 允许第三方 Cookie（默认允许），流程就能走完。
不需要额外设置 User-Agent，官方 Web 接口对移动端 UA 完全兼容。
5. 安全性与合法性边界
- 我们只是把“是否存在客户端”的探针结果硬编码成 false，并未破解签名、未插入凭证，属于“绕过能力检测”而非“伪造身份”。
- 重打包后必须重新签名，Android 会把它当作全新应用，与原签名不同，因此无法更新安装；先卸载原版即可。
- 该改动仅影响本地 UI 路由，OAuth2 的 code/token 交换仍走 HTTPS+官方接口，令牌有效性由腾讯服务器保证。
一句话总结：
把 SSO 探针方法永真改为永假，框架的降级逻辑就会把你带到 Web 登录页，除此之外什么都不用动。 |
|
苏公网安备 32010602011309号
|
苏ICP备19064627号
变色卡
