Gmail Sanitizer 深度拆解：8 步全链路凭据切断的自动化实现
联系方式 & 交流群
- 微信: gzs-47
进微信群请联系博主，各位觉得文章对你有帮助的话可否打赏一些呀~
一分钟速读：Gmail Sanitizer 不是简单的”改密码工具”，而是一套 8 步全链路凭据切断系统——从恢复邮箱、恢复手机、Passkey、2FA 密钥到 OAuth 授权，把卖家在账号上留下的所有后门逐一切断，最后用新凭据重新登录验证。底层用 DrissionPage 驱动真实 Chrome 绕过 Google 反自动化检测，配合 Cloudflare Email Worker 实现验证码秒级推送，AES-256-GCM 加密冷库保护敏感数据，asyncio 任务队列 + 死信队列实现批量并发 + 失败自愈。本文从攻防对抗、引擎架构、接码管道三个维度逐层拆解。
引言
先问一个问题：你从卡网买了一个 Google 账号，改了密码，是不是就安全了？
不是。
改密码只切断了 6 条”绳子”中的 1 条。卖家仍然可以通过以下方式盗回你的账号：
| 后门 | 盗回方式 |
|---|---|
| 恢复邮箱 | 通过”忘记密码”流程，Google 会把重置链接发到卖家的恢复邮箱 |
| 恢复手机号 | 同上，短信验证码直接发到卖家手机 |
| Passkey | 卖家的设备上注册了 Passkey，无需密码即可登录 |
| TOTP 2FA 密钥 | 卖家手里有 Base32 密钥，能随时生成你的 2FA 验证码 |
| 旧会话 / Cookie | 卖家的浏览器可能还保持着登录状态 |
| OAuth 授权 | 授权过的第三方应用可以读取邮件、通讯录等数据 |
你只改了密码？卖家用恢复邮箱就能把密码改回来。你改了密码又关了 2FA？Passkey 还在。你把 Passkey 也删了？OAuth 授权的第三方应用还在偷偷读你的数据。
Gmail Sanitizer 要做的事情，就是一口气把这 6 条绳子全部切断。
一、核心功能：8 步全链路凭据切断
这个系统的核心是一条 8 步流水线，每一步精确对应一个后门：
| 步骤 | 操作 | 切断的后门 | 关键难点 |
|---|---|---|---|
| Step 1 | 登录验证 | 验证旧凭据有效性 | 2FA 挑战、Account Chooser、中间提示页 |
| Step 2 | 替换恢复邮箱 | 卖家的恢复邮箱 → 买家自建接码邮箱 | Google 可能要求邮箱验证码 |
| Step 3 | 移除恢复手机 | 卖家绑定的手机号 | 可能需要 Sudo 二次验证 |
| Step 4 | 删除所有 Passkey | 卖家设备的无密码登录凭据 | 循环删除，最多 20 个 |
| Step 5 | 重置 2FA | 旧 TOTP 密钥 → 新 Base32 密钥 | 需要提取页面上的 Base32 密钥文本 |
| Step 6 | 修改密码 + 全设备登出 | 旧密码 + 旧会话 | 密码强度校验、设备登出确认 |
| Step 7 | 撤销 OAuth 授权 | 所有第三方应用权限 | 循环撤销，最多 30 个 |
| Step 8 | 新凭据验证 | 确认所有切断生效 | 用新密码 + 新 2FA 重新登录 |
注意步骤顺序不是 1-2-3-4-5-6-7-8，而是 1-2-5-4-3-6-7-8——Step 5（重置 2FA）被提前到 Step 4（删除 Passkey）之前执行。为什么？因为 Step 5 需要在 Sudo Gate 中输入旧 TOTP 码来验证身份，如果先删了 Passkey 可能导致 Google 挑选 Passkey 作为 Sudo 验证方式却找不到，引发意外的验证失败。
1.1 Sudo Gate：Google 的二次验证拦截
这是整个系统最精巧的部分。
Google 在你修改安全设置时，会弹出”Sudo Gate”——一个二次身份验证页面。问题是，Sudo Gate 不是固定的，Google 会根据你的账号状态动态选择挑战方式：
def handle_google_sudo_gate(self, page, password, totp_secret=None, gmail=None, recovery_email=None): for cycle in range(6): # 最多循环 6 次 current_url = page.url
# 1. Account Chooser（会话过期） if "accountchooser" in current_url: # 点击账号重新选择
# 2. 2FA 方式选择页 if "challenge/selection" in current_url: # 智能选择：优先 recovery email > TOTP
# 3. 恢复邮箱验证 (challenge/kpe) if is_rec_email_challenge and recovery_email: # 输入恢复邮箱地址
# 4. 密码重输 (challenge/pwd) if is_pwd_challenge: # 重新输入当前密码
# 5. TOTP 二次验证 (challenge/totp) if is_totp_challenge and totp_secret: # 生成并输入 TOTP 验证码关键设计：while 循环。Google 可能在一次操作中连续弹出多种挑战（先要密码，再要 TOTP），所以 Sudo Gate 处理器设计为最多循环 6 次，每次检测当前 URL 和页面元素，动态选择对应的处理策略。不是 if-else，而是 for cycle in range(6)。
1.2 TOTP 密钥提取：从页面 HTML 中挖掘 Base32
Step 5 重置 2FA 时，需要从 Google 的 Authenticator 设置页面提取新的 Base32 密钥。这个密钥显示在页面上的格式是 4 字符一组、空格分隔的文本（如 ABCD EFGH IJKL MNOP）。
提取策略是两层漏斗：
# 第一层：正则匹配 4-8 组 Base32 字符块m_groups = re.search( r"\b(?:[a-zA-Z2-7]{4}\s+){3,7}[a-zA-Z2-7]{4}\b", dialog_text)if m_groups: candidate = m_groups.group(0).replace(" ", "").upper() if len(candidate) in (16, 24, 32): new_secret = candidate
# 第二层：暴力遍历所有元素文本if not new_secret: for e in page.eles("xpath://div[@role='dialog']//..."): m = re.search(r"\b([a-zA-Z2-7]{16,32})\b", txt.replace(" ", "")) if m and candidate not in ("AUTHENTICATOR", "VERIFICATION", ...): new_secret = candidate提取到密钥后，立即用 pyotp.TOTP(new_secret).now() 生成验证码填入确认框，完成 2FA 重置闭环。
1.3 断点续跑：任意步骤中断后恢复
每完成一个步骤，引擎立即将进度持久化：
account.mark_step("step2_email_changed")self._save_sync(account)StepProgress 用 10 个布尔字段精确记录每一步的完成状态。重试时，引擎检查哪些步骤已完成，直接跳过：
if not account.step_progress.step2_email_changed: ok = self._step2_recovery_email(page, cred, account) # ...这意味着如果 Step 5 因为网络超时失败，重试时会跳过 Step 1-4 直接从 Step 5 开始。
二、技术架构
2.1 双引擎设计
系统提供两套浏览器引擎，适配不同场景：
| DrissionPage 引擎 | Playwright 引擎 | |
|---|---|---|
| Chrome 类型 | 真实 Chrome 进程 | Chromium 内核 |
| 反检测能力 | 天然通过——就是真 Chrome | 需要 JS 注入伪装 |
| 并发模式 | 每个任务独立端口 + Profile | 每个任务独立 BrowserContext |
| 适用场景 | 生产环境（高通过率） | 开发调试（API 更友好） |
| 进程隔离 | 每个账号独立 Chrome 进程 | 同一 Browser 下的 Context 隔离 |
DrissionPage 引擎是生产首选。它直接控制真实 Chrome 浏览器，Google 的反自动化检测基本无效——因为从 Google 的角度看，这就是一个普通用户在操作浏览器。
进程隔离的实现很巧妙：
def _make_options() -> ChromiumOptions: port = _find_free_port() # 每个任务随机端口 opt.set_local_port(port) # 独立 Profile 目录，防止 Chrome SingletonLock 死锁 profile_dir = f"data/chrome_profiles/profile_{port}" opt.set_user_data_path(profile_dir)每个账号对应一个独立的 Chrome 实例（独立端口 + 独立 Profile），彻底避免了并发时的 Cookie 串扰和 SingletonLock 死锁。
2.2 反检测体系
Playwright 引擎需要额外的反检测处理。stealth_browser.py 实现了完整的指纹随机化：
// 隐藏 webdriver 属性Object.defineProperty(navigator, 'webdriver', {get: () => undefined});
// 伪造 plugins（无头浏览器默认为空）Object.defineProperty(navigator, 'plugins', { get: () => [ {name: 'Chrome PDF Plugin', filename: 'internal-pdf-viewer'}, // ... ]});配合随机 User-Agent、随机分辨率、随机时区和随机语言：
_USER_AGENTS = ["Chrome/125.0", "Chrome/124.0", ...] # 5 种_VIEWPORTS = [1920x1080, 1440x900, ...] # 5 种_LOCALES = ["en-US", "zh-CN", ...] # 5 种_TIMEZONES = ["America/New_York", "Asia/Shanghai", ...] # 5 种每个 BrowserContext 从这些池子中随机组合，确保指纹不重复。
2.3 任务队列 + 死信队列
并发调度用经典的 asyncio 生产者-消费者模型：
┌──────────────┐ ┌──────────────┐│ 任务入队 │────▶│ asyncio.Queue │└──────────────┘ └──────┬───────┘ │ ┌─────────────┼─────────────┐ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ Worker 0 │ │ Worker 1 │ │ Worker N │ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ ▼ ▼ ▼ ┌──────────────────────────────────┐ │ DrissionEngine.run_sync(task) │ └──────────┬───────────────────────┘ │ ┌────────┴────────┐ ▼ ▼ ┌──────────┐ ┌──────────┐ │ VERIFIED │ │ FAILED │──▶ 死信队列 └──────────┘ └──────────┘ (指数退避重试)死信队列的设计很讲究：
- 不可重试类型自动隔离：
WRONG_PASSWORD（密码错误）、ACCOUNT_DISABLED（封号）、CAPTCHA_BLOCKED（风控拦截）—— 这些重试也没用，直接进人工审核 - 可重试类型指数退避：
STEP_TIMEOUT（超时）、PROXY_ERROR（代理挂了）—— 等 2^n 秒后重试，最多 3 次 - Passkey 误判恢复：如果失败详情包含
passkeyenrollment或speedbump，说明不是真正的失败而是卡在了中间提示页，强制纳入可重试队列
2.4 AES-256-GCM 加密冷库
所有敏感字段（新密码、TOTP 密钥、Cookie）在存入数据库前经过 AES-256-GCM 加密：
class _Cipher: def encrypt(self, plaintext: str) -> str: nonce = os.urandom(12) # 96-bit 随机 nonce ct = self._aesgcm.encrypt(nonce, plaintext.encode(), None) return (nonce + ct).hex() # nonce 和密文拼接后存储GCM 模式提供认证加密——不仅保密，还防篡改。即使数据库被拖库，没有 32 字节主密钥也无法解密。而且每次加密使用随机 nonce，相同明文产生不同密文，抵抗已知明文攻击。
三、验证码邮件管道
Step 2（替换恢复邮箱）可能触发 Google 的邮箱验证码。系统通过 Cloudflare Email Worker 实现秒级接码：
Google 发送验证码邮件 ↓Cloudflare Email Routing（Catch-All 规则） ↓Email Worker（正则提取 6 位验证码） ↓HTTP POST → 主程序回调接口 ↓主程序轮询取码 → 填入浏览器Email Worker 的正则提取覆盖了 Google 验证码邮件的多种模板：
const codePatterns = [ /\b([0-9]{6})\b(?=\s*(?:is your|是您的|verification|验证|code))/i, /(?:verification code|验证码)[^\d]*([0-9]{6})/i, /G-([0-9]{6})/i, // Google 特定格式 "G-123456" /\b([0-9]{6})\b/, // 兜底：提取第一个 6 位数字];如果邮件通道超时（30 秒），系统还有一个优雅降级——直接在终端提示操作者手动输入验证码：
if sys.stdin.isatty(): user_code = input("6-digit code (or Enter to skip): ").strip()四、安全设计亮点
| 设计 | 实现 | 目的 |
|---|---|---|
| 进程隔离 | 每账号独立 Chrome 进程 + 独立端口 + 独立 Profile | 防 Cookie 串扰、防 SingletonLock |
| 加密存储 | AES-256-GCM + 随机 Nonce | 数据库脱库也无法解密 |
| 人类行为模拟 | random.uniform(0.8, 2.0) 秒操作间隔 + Worker 领任务前 1.5-5.0 秒抖动 | 降低 Google 风控触发率 |
| 中间提示页自动跳过 | 智能识别 Passkey 引导、恢复邮箱确认等弹窗 | 防止流程卡死 |
| 密码强度保证 | 18 位、大小写 + 数字 + 符号、secrets 模块生成 | 通过 Google 密码强度校验 |
| 密码热切换 | Step 6 修改密码后立即 cred.password = new_password | 后续步骤用新密码通过 Sudo Gate |
五、与同类方案对比
| 维度 | 手动操作 | 简单脚本 | Gmail Sanitizer |
|---|---|---|---|
| 覆盖后门数 | 取决于经验（通常漏 2-3 个） | 1-2 个（通常只改密码） | 全部 6 类后门 |
| 单号耗时 | 15-30 分钟 | 3-5 分钟 | 1-3 分钟 |
| 并发能力 | 1 | 1-3 | 20+（可配置） |
| 断点续跑 | 不支持 | 不支持 | 支持（10 步粒度） |
| 失败自愈 | 手动重试 | 无 | 死信队列 + 指数退避 |
| 凭据保护 | 明文 | 明文 | AES-256-GCM |
| 反检测 | 不需要 | Selenium（易被检测） | 真实 Chrome / 指纹随机化 |
| Sudo Gate 处理 | 人工判断 | 通常卡住 | 6 种挑战类型自动适配 |
写在最后
Gmail Sanitizer 这个项目的技术含量不在于”自动化”本身——Selenium 填表单谁都会。它的价值在于对 Google 安全机制的深度理解：知道 Google 有哪些后门、知道 Sudo Gate 有哪些挑战类型、知道 Base32 密钥在页面上以什么格式显示、知道修改密码后旧 TOTP 密钥还能用多久。
从工程角度看，断点续跑 + 死信队列 + 加密冷库 的组合，让它从”一次性脚本”变成了”可运维的生产系统”。这是大多数同类工具缺失的维度。
对于大体量的 Google 账号采购场景，先批量跑一遍 8 步清洗，再投入使用——这是成本最低的安全保障。
文章分享
如果这篇文章对你有帮助，欢迎分享给更多人！
