深挖mimic核心原理鉴权头提取逻辑如何让重放请求与真实App无法区分【免费下载链接】mimicIntercept any app, then call it from Python like a library项目地址: https://gitcode.com/gh_mirrors/mimic32/mimicmimic 是一个 App 流量拦截与重放工具它通过 mitmproxy 捕获你手机 App 的真实网络请求用一套鉴权头提取逻辑挑出可复用的身份凭证Bearer Token、Cookie、设备 ID 等再让 Python 客户端携带这些凭证发起新请求——服务器无法区分这是来自真实 App 还是你的脚本。本文将拆解这套提取逻辑的每一步规则。为什么复制鉴权头就能冒充真实 App理解 mimic 的关键是理解移动端 App 的鉴权方式绝大多数 App 对每个请求都携带同一套值一个 Bearer Token、若干设备 ID、一个 Session ID、Cookie。它们在多次调用之间保持稳定。这意味着只要你从一次真实请求中完整捕获这套鉴权包之后用它发起的新请求在服务器眼中就和真实客户端发的一模一样——同一个身份、同一套设备特征。mimic 的全部魔法就藏在这句话里核心实现位于 extract.py 的文件注释中Capture them once from a real request you made, and you can craft new calls that the server cant tell apart from your real client.鉴权头提取的三步过滤留该留的丢该丢的捕获到请求后不能把全部请求头原样搬走——有些头如Content-Length、Host由 HTTP 层自动生成照抄反而会导致请求出错。mimic 用双名单过滤解决逻辑集中在 _keep() 这个函数里。允许名单6 个固定头 一个前缀extract.py 定义了KEEP_EXACT集合只有这 6 个请求头会被保留请求头作用authorizationBearer Token核心身份凭证cookie会话 Cookieuser-agent客户端指纹App 版本、系统信息accept-language语言偏好属于设备/环境特征content-type/accept请求格式协商同时x-前缀的头一律保留KEEP_PREFIX因为 App 常把自定义鉴权放在这里x-device-id、x-session-id、x-app-version、x-api-key……这是移动端 API 的高频命名习惯一个前缀规则就能兜住。阻止名单必须剔除的 HTTP 层噪音DROP 集合 列出了绝不能重放的头content-length、content-encoding请求体变了长度和编码自然要重算host、connection由底层 HTTP 库自动设置accept-encoding压缩协商照抄可能收到解不开的内容x-forwarded-for这是代理链的痕迹带着它重放反而穿帮过滤优先级是阻止名单 允许名单。一个头即使匹配x-前缀只要出现在 DROP 里也会被丢弃。只取最新一次已鉴权请求看 session_headers() 的实现它做了两个精妙决策反向遍历for f in reversed(flows)从最新捕获的请求开始找因为 Token 可能轮转越新的鉴权头越大概率仍然有效已鉴权有明确定义请求头里必须含Authorization或Cookie否则跳过——匿名健康检查、静态资源请求里的头不值得复用。找到目标请求后只提取通过双名单过滤的头组成一个纯净的可复用 header 集合。同时 base_url() 从同一条请求还原出scheme://host:port注意它对 80/443 端口做了归一化避免拼出https://host:443这种别扭地址。运行时重放Session 如何让每个请求以假乱真提取出的头交给 Session 保存。之后你调用的每个.get()/.post()方法request() 都会把这整套捕获的鉴权头附在请求上发出去——从服务端视角这就是你的 App又发来的一个请求。还有一个细节让重放体验接近真实客户端401 自动刷新。Token 轮转后旧凭证会失效mimic 的处理策略是对幂等方法GET / PUT / DELETE 等收到 401 时自动重新执行一遍上面的提取逻辑拉取 mitmweb 里更新的鉴权头重试一次而且只在凭证确实发生变化时才换——如果重新拉取的结果和旧头相同就保留旧头避免刷新失败后变成无鉴权重试POST 这类非幂等请求不会自动重试防止重复提交需要你显式传refreshTrue。这套机制对应 Session.from_mitm() 的入口找不到任何已鉴权请求时会明确提示你先打开 App 用一次让 mitmweb 看到一次真实调用。三种捕获后端喂给同一套提取逻辑鉴权头提取本身与流量来源解耦不管请求从哪来都先被规范化成统一的 flow 结构再走同一个session_headers()。捕获方式适用场景实现位置mitmproxy默认iOS App通过 mitmweb JSON API 读取实时流量sources/mitm.pyHAR 文件任何有 Web 版的 App浏览器直接导出sources/har.pycURL 粘贴最快路径DevTools 里 Copy as cURL 即可Session.from_curl()提取出的端点数据还会经 codegen.py 的提示词交给 AI生成一个带命名方法的 Python 客户端。注意提示词中有条硬规则禁止在生成代码里硬编码 Token——鉴权一律由基类从捕获会话中自动拉取保证 Token 轮转后客户端依然可用。无法区分的边界两种会破功的鉴权方案mimic 的模型建立在鉴权头稳定可复用的前提上有两类方案会破坏它证书固定Certificate PinningApp 拒绝代理证书导致捕获环节看不到任何流量——但注意它挡住的是偷看不是重放。只要能绕过固定mimic 提供 Frida 方案的 unpin 命令后续重放照常工作。详见 docs/pinning.mdDPoP / 发送者约束 Token每个请求都带一个用设备私钥新签的DPoP:头且绑定了方法、URL、时间戳、nonce——复制下来的头一个都放不回去。这直接打穿了 mimic 的静态重放模型目前没有干净的绕过路径。详见 docs/dpop.md。小结mimic 让重放请求与真实 App 无法区分的秘密并不神秘而是三件事的组合拳双名单过滤精确的KEEP_EXACTx-前缀保留身份头DROP 集合剔除会穿帮的 HTTP 层噪音取最新已鉴权请求保证拿到的是当前有效的凭证快照运行时自动刷新401 时重新提取并重试抵消 Token 轮转。记住它的适用边界只在自己的账号和数据上使用尊重各 App 的服务条款遇到 DPoP 类目标静态重放模型本身不成立。【免费下载链接】mimicIntercept any app, then call it from Python like a library项目地址: https://gitcode.com/gh_mirrors/mimic32/mimic创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考