直接用 requests 发请求常被拒绝,因app接口校验user-agent、authorization、设备指纹、时间戳、签名等参数,且需tls指纹匹配;需抓包分析动态字段、加密方式及登录态,并逆向签名逻辑与自动刷新token。

为什么直接用 requests 发请求经常被拒绝?
多数主流 APP 的接口会校验 User-Agent、Authorization、设备指纹、时间戳、签名参数(如 sign 或 sig),甚至要求 TLS 指纹匹配。单纯伪造一个 User-Agent 基本无效,服务器一验就返回 403 或 {"code":1001,"msg":"非法请求"}。
实操建议:
图片提示词生成器?不止如此。 马甲系统 —— 把脑海中的画面,翻译成AI能理解的专业表达。 用得越多,它越懂你:首次需要多问几句确认方向,用久了几乎一说就懂。 用得越多,它越快:缓存机制让后续对话越来越省。 RAG进化:成功案例持续入库,越跑越聪明。 输入「新手指南」查看完整功能介绍
- 先用抓包工具(如 Charles / mitmproxy / Frida)在真机上完整捕获一次成功请求,重点看 Headers 里有没有动态字段(比如
X-Device-ID、X-Signature、ts) - 检查请求体是否加密(常见:AES/CBC + Base64,或简单 XOR + 时间戳混淆)
- 确认 Cookie 是否依赖登录态(如
sessionid、token),且有效期短(常为 2 小时)
如何复现 APP 的签名逻辑?
签名不是随机拼接,而是按固定规则生成,比如把参数字典按 key 字典序排序后拼成字符串,再加盐哈希(md5(params_str + "salt_2023")),或用 RSA 私钥本地签名。Python 要复现,必须逆向出算法和密钥。
实操建议:
- 用
objection或Fridahook 关键函数,例如com.xxx.util.SignUtil.generateSign(),观察输入输出 - 若签名逻辑在 so 库中,需用
radare2或IDA反编译,再用ctypes或pycparser重写关键计算逻辑 - 别硬猜——直接从 APP 的 Java/Kotlin 或 Swift 代码里抄逻辑,比纯黑盒试错快得多
如何维持登录态并自动刷新 token?
APP 登录后返回的 access_token 通常带过期时间(expires_in: 7200),且刷新接口本身也需签名或携带 refresh_token。用死值 token 发 10 分钟后就失效。
实操建议:
- 把登录流程也自动化:模拟手机号+短信验证码登录 → 提取响应里的
refresh_token和初始access_token - 封装一个
AuthManager类,在每次发请求前检查token_expires_at,若剩余 /auth/refresh 接口更新 - 注意:刷新接口也可能要求设备 ID、时间戳、签名三者联动,漏一个就返回
{"code":401,"msg":"invalid refresh token"}
用 mitmproxy 抓包时 HTTPS 请求全是乱码?
因为 APP 启用了证书固定(Certificate Pinning),它不信任系统代理证书,导致 mitmproxy 无法解密流量。此时看到的全是 TLS 握手失败或空响应。
实操建议:
- 安卓端优先用
Frida绕过证书固定:加载脚本 hookX509TrustManager.checkServerTrusted,直接 return - iOS 需越狱或使用
SSL Kill Switch 2;非越狱环境可尝试Objection的ios sslpinning disable - 别改手机系统时间来“绕过”证书过期——APP 会校验本地时间与服务端时间差,偏差 >30s 就拒收
Python免费学习笔记(深入):立即使用
在学习笔记中,你将探索 Python 的核心概念和高级技巧!










