在 BlackBerry Q20（BB10 10.3.3.3216，Android 运行时 API 18） 上，让微信 6.3.13 完成 Facebook 绑定登录。
实测：2026-10-31 首次打通，2026-11-01、2026-11-08 两次从零复现。
⚠️ 性质声明
- 本项目是一份技术可行性记录，仅供研究参考；作者不提供使用指导、技术支持或结果担保；
- 仓库不提供微信 APK、改好的 APK 或任何第三方软件本体；改包由使用者自行完成；
- Facebook 登录要求使用者所在网络本身具备访问条件；本项目不负责、也不提供此类网络环境（不含节点、订阅、代理服务或任何形式的接入）；
- 修改客户端通常违反其用户协议，后果由使用者自负。详见 DISCLAIMER.md。
三条事实叠在一起，把可选空间压到了一个点：
- 新版微信的登录模块已经拿掉了 Facebook，而手机号登录通道对老版本也已关闭——也就是说"绑定 Facebook 后用它登录"这条路，只剩老版本还保留着；
- 具备新登录模块的版本装不上：6.7.3 / 7.0.0 要 minSdk 19，8.x 要 21+，而 BB10 的运行时是 API 18；
- 能装的 6.6.7 改包后会挂：它自带
com.tencent.mm.splash.DexOptService，发现 dex 被改过就每次启动重做 dexopt，Q20 上直接把主线程拖到 ANR。
结论：BB10 上能稳定跑的微信 = 6.3.13；而它唯一还能用的登录方式 = Facebook 绑定登录。
Q20 装完微信后停在登录页，进不了主界面，也就没有"设置"可以点。所以顺序是反过来的：
- 用另一台正常手机（安卓/iPhone）登录这个微信号；
- 在微信里把地区/语言改成海外（例如 United States）——否则看不到 Facebook 入口；
- 微信内搜索
facebookapp，进入 Facebook 绑定入口，完成绑定； - 回到 Q20：装你自己改包的 6.3.13（见 SKILL.md §5），登录时选 Facebook，走本文的代理链路。
微信侧对新号风控很严：即使 token 完全合法，绑定请求也可能被服务端直接拒（点了没反应、或失败但不给原因）。建议用已正常使用过一段时间的号。
绑定好之后，在 Q20 上点 Facebook 登录，Facebook 返回：
insecure tls version detected. Please upgrade to tls 1.2 or higher
原因不是 FB SDK 的 Java 层，而是微信用来显示登录页的那个 2013 年版 WebView：它和 Facebook 只能谈成 TLS 1.0。
而把 TLS 升到 1.2 之后仍然白屏——因为 FB 现在的登录页是 React 应用，那个 WebView 跑不动 ES6。
所以最终方案是：不渲染。 整个 OAuth 交给代理在服务端跑完，只把 fbconnect://success#access_token=… 这个 302 交给微信，微信的 WebViewClient 收到即可完成绑定。
Q20 → 路由器 nft 劫持 → PC Clash → FB-MITM → tap → 桥 → mitmproxy
├─ 对客户端：接受 TLS 1.0
└─ 回源：TLS 1.2/1.3
↓
302 fbconnect://success#access_token=…
动手前先确认这四条，缺一条都会卡在中途。
- 需要一个能正常登录的 Facebook 账号（能走完 OAuth 同意页、可能的身份验证）；
- 不要用刚注册的 FB 号：新号授权第三方 App 极易在授权环节被 checkpoint（要手机号/证件），侥幸绑上也可能几天内被封；
- 绑定步骤见上一节（微信 → 地区改海外 → 搜
facebookapp）； - 绑定用的 access token 约 60 天有效，到期后按 SKILL.md §6 重新取一次。
微信侧对新号的风控等级很高，绑定请求可能被服务端拒绝且不给原因。用已经正常使用、有过真实聊天记录的号，也更有机会在 Q20 上登录成功。
| 版本 | 能装 | 能改包 | 说明 |
|---|---|---|---|
| 6.3.13 | ✅ | ✅ | 本仓库方案。单 dex、无 DexOptService，唯一稳定解 |
| 6.6.7 | ✅ | 能装；改包触发它自己的 DexOptService 反复 dexopt，Q20 上 ANR |
|
| 6.7.3 / 7.0.0 | ❌ | — | minSdk 19 > API 18 |
| 8.x | ❌ | — | minSdk 21+，且登录模块已无 Facebook |
你自己准备一份官方的 6.3.13 安装包，按 SKILL.md §5 打一处 cancel()→proceed() 补丁即可。
本方案的核心是"把手机的 FB 请求引到一台你控制的主机上，由它替手机完成 TLS 升级"。这个"接管"怎么实现由你自己决定（路由器透明代理、手机全局代理都行），本仓库只提供接管之后的部分。
需要满足三点：
- 手机和那台主机在同一局域网，主机上的代理监听
0.0.0.0——不能只监听127.0.0.1，否则路由器连不上（表现为手机侧connection timed out）； - 那台主机能访问 Facebook；
- 手机的 TCP 能被重定向到主机的代理端口。这一步不要求 OpenWrt：可刷固件的路由器、任意 Linux 网关都能做，见
router/ROUTER.md；动不了路由器的情况见该文档末尾。
这一条不是可选的。scripts/ 里的链路依赖 Clash 的运行时配置 API，换成 v2rayN、sing-box、Surge 之类的客户端，脚本直接不可用。具体需要：
| 能力 | 用途 | 脚本依赖 |
|---|---|---|
外部控制 API（Clash Verge 的命名管道，或 external-controller + secret） |
读写运行中的配置 | scripts/mihomo.ps1 |
支持 PUT /configs?force=true 整体重载配置 |
注入 FB-MITM 出站和分流规则 |
make_fb_config.py + mihomo.ps1 |
允许自定义 socks5 出站（指向 11080） |
把 FB 流量交给 mitmproxy | make_fb_config.py |
| 有一个能访问 Facebook 的代理/策略组 | mitmproxy 回源走它，避免环路 | FB_GUARD_TARGET |
allow-lan |
让路由器/手机够得着 7897 |
start-chain.ps1 |
已验证组合：Clash Verge Rev + mihomo 1.19.x（Windows）。别的 mihomo 前端基本也适用，但命名管道的发现方式（MIHOMO_PIPE）和配置路径（CLASH_RUNTIME）可能要调。
如果你的客户端没有这套 API，也不是不能做——但
make_fb_config.py/mihomo.ps1这两个脚本要自己重写成对应客户端的方式（比如手改配置文件后重启），本仓库不提供。
隐私说明：本仓库不含任何节点、订阅、机场、DNS 或账号信息。脚本与文档里的 IP、 Clash 代理组名全部是占位符，必须换成你自己的： 复制
scripts/local.env.example.ps1为scripts/local.env.ps1（已在.gitignore）， 填FB_PC_IP和FB_GUARD_TARGET即可，脚本会自动加载。
仓库不分发任何二进制：微信 APK 由你自己准备，两个构建工具用脚本下载。
| 组件 | 要求 | 用途 | 怎么来 |
|---|---|---|---|
| JDK | 8 或以上（实测 1.8.0_421 跑通全部工具） |
运行下面两个 jar | 自备，需在 PATH 里 |
| apktool | 3.0.3 | 反编译 + 汇编 dex（自带 smali/baksmali） | scripts/fetch-tools.ps1 |
| uber-apk-signer | 1.3.0 | 签名（v1+v2+v3），内置 debug key | scripts/fetch-tools.ps1 |
| Python | 3.12+（mitmproxy 12.3.1 要求；repack.py 本身 3.6+ 即可） |
跑 addon / 桥 / repack.py |
pip install -r requirements.txt |
| 磁盘 | 建议留 500 MB+ | apktool 解包后约 105 MB smali | — |
不需要单独的 smali/baksmali，也不需要 Android SDK。
自查：
java -version # 期望 1.8 或更高
python --version # 期望 3.6+几点说明：
- 不需要 Android SDK：我们不重建资源（WeChat 的资源用 aapt2 必然报
style/xxx not found），apktool b --no-apk会在报错之前把build\apk\classes.dex生成好——这正是我们要的东西（细节见 SKILL.md §5）。 - apktool 首次运行会下载 framework；脚本里用
-p framework指到工作区内的目录，避免污染%LOCALAPPDATA%。 - 签名用的是 uber-apk-signer 内置的 debug key，所以装到设备上会显示为未知开发者，且不能覆盖安装官方版（必须先卸载）。
- 构建产物（
patched-unsigned.apk、signed/、out6313/）都已被.gitignore覆盖。
# 0) 依赖（只需一次；mitmproxy 12.3.1 要求 Python 3.12+）
python -m pip install -r requirements.txt
# 1) 路由器：nft + ipt2socks（见 router/ROUTER.md，重启后会丢，guard 自动补）
# 2) PC：拉起链路（mitmproxy + 桥 + Clash 规则 + fbconnect 协议处理器）
cd scripts
powershell -ExecutionPolicy Bypass -File .\start-chain.ps1
# 3) 设备：装你自己改包的 6.3.13（SKILL.md §5）
# 4) PC 浏览器：登录 FB → 打开 dialog/oauth（见 SKILL.md §6）→ token 自动落盘
# 5) 写进缓存后在手机上点 Facebook 登录完整步骤、验证清单、14 条坑位见 SKILL.md。
| 路径 | 内容 |
|---|---|
README.md / SKILL.md |
总览 / 完整操作手册 |
DISCLAIMER.md / LICENSE |
免责声明 / 本仓库代码的许可 |
repack.py |
通用 zip 重打包：把新 classes.dex 塞回原 APK |
requirements.txt |
mitmproxy==12.3.1 |
scripts/ |
start-chain / stop-chain、mitmproxy addon、SOCKS5 桥、Clash API、fetch-tools |
router/ |
nft 规则、修正版 guard、路由器侧完整说明 |
tools/、pylib/ |
不在仓库里：由 fetch-tools.ps1 和 pip install 自行获取 |
仓库体积 < 1 MB：不含微信 APK、不含改包产物、不含任何第三方二进制。
| 项 | 结论 |
|---|---|
| 6.3.13 + 本方案 | ✅ 2026-10-31 / 11-01 / 11-08 三次绑定成功 |
| 6.6.7 改包 | ❌ DexOptService 反复 dexopt → ANR |
| 6.7.3 / 7.0.0 | ❌ minSdk 19 > API 18 |
| 8.x | ❌ minSdk 21+ |
| 给 FB SDK 开 TLS1.2 | ❌ 卡在 WebView 原生层，不是 Java 层 |
| 移植新版登录 / 抓包复刻 | ❌ MMTLS 非标准 TLS + 设备绑定 session |
- 改包即非官方客户端：腾讯侧可能判定环境异常，支付类功能大概率不可用，账号有被限制的概率。这违反微信用户协议中禁止修改客户端的条款，后果自负。
- APK 补丁放行了 WebView 的所有证书错误（
cancel()→proceed()是无条件的），不只是 Facebook 的。这会削弱该 WebView 对中间人攻击的防护，只在你自己控制的网络里使用。 - 代理端口对局域网开放：
11080/11081监听在0.0.0.0，Clash 的allow-lan也开着。只在你信任的局域网里跑，用完执行stop-chain.ps1并把allow-lan关掉。 - token / cookie 以明文落盘（
fbtoken.txt/fbcookie.txt/fb_capture.txt），stop-chain.ps1不会自动删。用完手动删；fb_capture.txt里是完整的 token URL。 - 借用 FB 会话会触发 Facebook 反自动化风控（本项目实测导致过一次封号 + 一次安全提醒），不要用主号试。
- 撤销授权：Facebook → 设置 → 应用和网站 → WeChat → 移除。
- 本项目只针对自有设备的技术可行性研究，不涉及绕过付费、批量操作，也不用于改造他人设备或账号。
完整声明见 DISCLAIMER.md（含不隶属声明、第三方软件说明、权利通知与删除联系方式）。
本仓库自身代码与文档采用 MIT（见 LICENSE）。
该许可不覆盖微信（腾讯所有）、Facebook 服务、以及 apktool / uber-apk-signer / mitmproxy 等第三方组件—— 它们各自适用其原始许可，且均不由本仓库分发。