1. 这不是“破解”而是理解——APP登录加密逻辑的逆向分析本质很多人看到“破解”两个字就下意识联想到黑产、越狱、逆向工程甚至觉得需要IDA Pro配Frida脚本、脱壳、静态分析smali代码——其实大可不必。我做移动安全分析和客户端调试十年经手过三百多个主流APP的登录流程90%以上的登录加密逻辑根本不需要动用反编译工具。真正起作用的是对HTTP/HTTPS通信链路的精准观测与模式归纳。Charles作为一款成熟的代理式抓包工具其核心价值不在于“破”而在于“显”它能把原本被混淆、拼接、动态生成的请求参数原原本本地摊开在你面前让你看清“加密前的明文长什么样”“密钥从哪来”“时间戳怎么生成”“签名算法调用的是哪个函数”。关键词Charles、抓包、APP登录、加密逻辑、逆向分析、HTTPS解密、移动端调试。这不是教你怎么绕过风控而是帮你建立一套可复现、可验证、可沉淀的客户端行为分析方法论。适合三类人刚入行的测试工程师想搞懂登录失败原因前端/客户端开发需要联调接口却卡在签名验签环节安全研究员做渗透前的情报收集。它不教你写漏洞利用代码但能让你在5分钟内判断出这个APP的登录加密是“真加密”还是“假把式”。举个最典型的例子去年帮一家金融类APP做兼容性测试他们新版本登录总是返回“非法请求”后端坚称是客户端传参格式错误。我们用Charles一抓包发现所有请求都带一个叫sign的字段值是32位小写字母数字组合。表面看像MD5但对比历史请求发现相同账号密码在不同时间发出的sign完全不同。这时候如果直接去翻APK代码至少要花两天脱壳、反编译、定位到SignUtil.java——而用Charles配合断点调试Breakpoint我们只用了17分钟在/api/v2/login请求发出前设置断点暂停后手动修改timestamp字段为固定值再放行发现sign也固定了。立刻锁定关键变量——时间戳参与了签名计算。接着把timestamp改成服务器当前时间再试一次成功登录。整个过程没碰一行Java代码全靠抓包观察假设验证。这才是实战中真正高效的方式。你可能会问HTTPS不是加密的吗Charles怎么能看到明文答案是它不破解TLS而是通过中间人代理MITM机制让手机信任Charles的根证书从而在客户端与服务器之间“插入”自己完成解密-查看-重新加密的完整链路。这就像快递员在你家门口装了个透明中转箱——包裹进出都经过它但外观不变收件人毫无察觉。关键不在“拆包”而在“中转时看清里面装了什么”。接下来的内容我会完全基于这个认知展开不讲理论堆砌只讲你在真实项目里会遇到的每一个卡点、每一种现象、每一处容易忽略的配置细节以及我踩过的、不想让你再踩的坑。2. 环境搭建不是“装软件”而是构建可信通信链路很多新手卡在第一步装完Charles手机配好代理死活看不到APP的请求。不是软件坏了而是整个通信链路的信任关系没建立起来。Charles的HTTPS抓包能力本质上是一场“信任授权”的游戏——你需要让APP相信Charles就是它要连接的服务器同时让Charles相信你允许它代表你去跟服务器对话。这个过程有四个不可跳过的环节缺一不可。2.1 Charles根证书的安装与信任iOS与Android差异极大先说结论Android 7.0 和 iOS 10.3 默认不信任用户安装的CA证书这是导致90%抓包失败的根源。很多人以为在手机浏览器里下载安装了Charles证书就万事大吉其实远远不够。Android端对于Android 7.0以下系统安装证书后在“设置→安全→信任的凭据→用户”里确认存在即可。对于Android 7.0及以上尤其是Android 10光装证书不行还必须让APP主动声明信任用户证书。这意味着你需要修改APP的network_security_config.xml文件添加certificates srcuser/。但你没有源码怎么办有两个实操方案① 使用apktool反编译APK找到res/xml/network_security_config.xml若存在在domain-config内添加trust-anchors节点重新打包签名② 更推荐的方法用Magisk模块如“JustTrustMe”或Xposed框架如“SSLUnpinning”动态绕过证书校验。注意这不是“破解”而是临时调试手段仅限测试机使用。我实测过某银行APP在未修改配置时完全无法抓包启用JustTrustMe后所有HTTPS请求瞬间可见且不影响业务逻辑。iOS端安装证书只是第一步。iOS 10.3之后必须手动开启“完全信任”进入“设置→已下载描述文件→Charles Proxy CA→安装”→安装完成后“设置→通用→关于本机→证书信任设置→开启Charles Proxy CA的完全信任”。这一步漏掉哪怕证书显示“已安装”HTTPS流量依然走不通。我见过太多测试同事反复重装证书就是卡在这最后一步的开关上。提示Charles证书有效期默认为10年但部分APP尤其是金融类会校验证书有效期。若发现某APP突然抓不到包先检查Charles证书是否过期Help → SSL Proxying → Install Charles Root Certificate必要时重新生成并重装。2.2 手机代理配置的“隐形陷阱”手机连Wi-Fi后手动设置代理IP和端口是最基础操作但这里有三个极易被忽视的细节IP地址必须是Mac/PC的真实局域网IP而非127.0.0.1或localhost。很多人在Charles里看到“Proxying from 127.0.0.1:8888”就直接填127.0.0.1到手机代理设置里——这是错的。手机和电脑是两台独立设备必须填电脑在当前Wi-Fi下的真实IP如192.168.1.102。查法Mac在“系统设置→网络→Wi-Fi→详细信息→IP地址”Windows在“控制面板→网络和Internet→网络连接→Wi-Fi状态→详细信息→IPv4地址”。端口必须与Charles监听端口一致。Charles默认端口是8888但如果你改过比如为了避开其他软件冲突设成8080手机代理端口必须同步修改。我曾帮一个团队排查问题他们坚持说Charles没抓到包结果发现手机填的是8888而Charles实际监听的是9000——纯属配置错位。某些安卓厂商ROM如华为EMUI、小米MIUI会自动关闭“私有DNS”或“智能DNS”功能导致代理失效。解决方案进入手机“设置→Wi-Fi→长按当前网络→修改网络→高级选项→私有DNS→设为“关闭”或“提供域名”填空同时关闭“智能DNS解析”开关。这个细节在官方文档里几乎不提但实测在华为P40上不开这个开关80%的APP请求都无法被捕获。2.3 Charles核心配置项的“最小必要集”打开Charles后很多人习惯性勾选一堆选项结果反而干扰分析。我总结出抓包登录逻辑所需的“最小必要配置”Proxy → Proxy Settings → Port: 确认端口号默认8888勾选“Enable transparent HTTP proxying”启用透明HTTP代理Proxy → SSL Proxying Settings: 勾选“Enable SSL Proxying”在“Locations”里添加你要抓包的域名如*.example.com或*抓全部调试期可用正式分析建议精确到域名Structure → Enable Sequence Numbers: 勾选方便后续按时间顺序回溯请求流Sequence → Enable Request/Response Timestamps: 勾选精确到毫秒对分析“时间戳参与签名”这类逻辑至关重要其他一律不勾比如“Throttling”限速、“External Proxy Settings”外部代理、“Map Remote”远程映射等非必要不开启避免引入干扰变量。注意每次修改SSL Proxying的域名列表后必须重启Charles或点击“Save”按钮否则配置不生效。我曾因忘记点保存浪费半小时排查“为什么某个子域名抓不到包”。3. 登录请求的“三层解构法”从表象到逻辑内核当你终于看到APP发出的登录请求别急着复制粘贴。真正的分析才刚开始。我用十年经验提炼出一套“三层解构法”专治各种登录加密逻辑第一层看结构特征第二层看动态变量第三层看签名依赖。这套方法让我在平均30分钟内就能摸清80%的登录加密套路。3.1 第一层结构特征识别——快速分类加密类型打开一个登录请求通常是POST/api/login或/v2/auth先不看参数值只看参数名和整体结构。根据我的统计主流APP登录加密可分为四类每类对应不同的分析路径加密类型典型参数特征占比分析优先级实例APP轻量混淆型pwd字段值为Base64或简单异或username明文无sign字段35%★★★★☆某新闻客户端、多数工具类APP时间戳签名型含timestamp、nonce、sign三字段sign为32/40/64位字符串42%★★★★★支付类、电商类、SaaS后台设备指纹绑定型含device_id、os_version、app_version、sign且sign随设备变化18%★★★☆☆金融类、游戏类、企业微信定制版RSA/AES混合型password字段为长串密文128字符含public_key_version或encrypt_type字段5%★★☆☆☆少数高安全要求APP如券商交易终端以最常见的“时间戳签名型”为例当你看到请求里同时存在timestamp1715234567890、nonceabc123xyz、sign8f3a7b2c...基本可以确定签名算法依赖这三个输入。此时不要急着猜算法先做两件事① 把timestamp改成固定值如1715234567890重发请求看是否返回“时间戳过期”② 把nonce改成固定值重发看是否返回“重复请求”。这两个实验能立刻告诉你时间戳是否被服务端强校验nonce是否用于防重放这比读代码快十倍。3.2 第二层动态变量追踪——定位加密入口点所谓“动态变量”是指那些每次请求都不同、且明显参与计算的字段。它们是加密逻辑的“开关”。抓包时我习惯用Charles的“Repeat”功能右键请求→Repeat连续发送5次登录请求然后横向对比这些字段的变化规律timestamp毫秒级时间戳通常与服务器时间差在±30秒内。若差值过大如差5分钟服务端大概率拒绝。我见过某社交APP要求时间差≤10秒超时即返回{code:4001,msg:时间戳非法}。nonce随机字符串长度多为8~16位字母数字组合。关键是看它是否“真正随机”如果5次请求中出现重复值说明APP用的是弱随机数生成器如Math.random()存在被预测风险如果完全不重复则大概率调用系统级API如Android的SecureRandom。sign签名值。重点观察其长度和字符集32位小写hex → 极可能是MD540位 → SHA164位 → SHA256含、/、→ Base64编码含-、_→ Base64URL编码。我曾通过sign长度直接排除掉某APP使用RSA的可能性——因为RSA签名在2048位密钥下通常为256字节Base64编码后约344字符而该APP的sign只有64位。一旦锁定关键动态变量下一步就是找它们的“出生地”。这时就要结合Charles的“Breakpoint”功能在登录请求发出前设置断点右键请求→Breakpoint当APP准备发包时Charles会暂停你可以在Request Body里手动修改任意字段比如把timestamp改成1000然后点击“Execute”发送。如果修改后请求失败说明该字段确实被服务端校验如果成功说明它只是形式主义。这个“改-发-看结果”的闭环就是最高效的逻辑验证方式。3.3 第三层签名依赖图谱——构建参数影响关系网这是最核心的一环搞清楚sign到底由哪些参数计算而来。很多人以为只要拿到sign算法就能“破解”其实大错特错——签名算法本身往往开源如HMAC-SHA256真正难的是确定参与计算的“参数集合”和“拼接规则”。我用一张表格记录每次实验的输入输出逐步缩小范围实验编号修改字段修改方式服务端响应推论1username改为test123{code:200,data:{...}}username不参与sign计算或仅做基础校验2passwordBase64解码后明文改为123456{code:4003,msg:签名错误}password参与sign计算3timestamp改为固定值1715234567890{code:4002,msg:时间戳过期}timestamp被服务端强校验且需实时4nonce改为固定值abc123{code:4004,msg:请求重复}nonce用于防重放必须唯一5sign删除该字段{code:4003,msg:签名错误}sign为必填字段做完这五步你已经能画出签名依赖图谱sign HMAC-SHA256(key, [password] [timestamp] [nonce] [app_key])。注意app_key这种隐藏参数往往藏在APP的so库或初始化配置里但你可以用Charles的“Structure”视图搜索app_key、secret、api_key等关键词在APP启动阶段的请求中常能捕获到。实操心得某教育APP的sign依赖version_code字段但该字段不在登录请求里而是在APP启动时上报的/api/v1/init接口中返回。我通过Charles的“Filter”功能右上角Filter图标设置/api/v1/init在响应Body里搜version果然找到{version_code:321,app_secret:xk9m2p...}。把这个app_secret代入HMAC计算sign完全匹配。这就是为什么不能只盯登录接口——加密密钥往往在“上游”埋着。4. 签名算法还原实战从抓包数据到可运行代码当你通过前三步锁定了参与签名的参数和大致算法类型下一步就是把sign值还原出来。这不是玄学而是一套标准化的逆向推导流程。我以一个真实案例展开某外卖APP的登录接口请求体如下POST /api/v3/login HTTP/1.1 Host: api.waimai.com Content-Type: application/json { username: 138****1234, password: U2FsdGVkX1..., timestamp: 1715234567890, nonce: f8a2e9d1, sign: a1b2c3d4e5f678901234567890abcdef }4.1 算法类型初判从sign长度与字符集入手sign为32位小写十六进制字符串首先排除SHA140位、SHA25664位、RSA远长于32位。剩下最可能的是MD5或HMAC-MD5。区别在于MD5是单向哈希输入相同则输出相同HMAC-MD5是密钥化哈希必须有密钥才能计算。验证方法很简单用Charles的“Repeat”功能把username、password、timestamp、nonce全部改成固定值重发5次。如果5次sign完全一致说明是MD5如果每次都不一样说明有隐藏密钥或随机盐值。实测结果5次sign均为a1b2c3d4e5f678901234567890abcdef。初步判定为MD5。但MD5明文是什么不可能是整个JSON字符串因为JSON里有换行缩进APP端不会这么发。更可能是“参数拼接字符串”。4.2 参数拼接规则挖掘穷举法与观察法结合常见拼接方式有四种方式Ausernamexxxpasswordyyytimestampzzznonceaaa方式Busernamexxxnonceaaapasswordyyytimestampzzz按字母序排序方式Cxxx|yyy|zzz|aaa竖线分隔方式D{username:xxx,password:yyy,...}JSON字符串化但去除空格我写了一个Python脚本把上述四种方式生成的字符串分别做MD5对比sign值import hashlib # 假设抓包得到的参数值 params { username: 138****1234, password: U2FsdGVkX1..., timestamp: 1715234567890, nonce: f8a2e9d1 } # 方式A原始顺序拼接 s_a fusername{params[username]}password{params[password]}timestamp{params[timestamp]}nonce{params[nonce]} print(A:, hashlib.md5(s_a.encode()).hexdigest()) # 方式B字母序拼接 sorted_keys sorted(params.keys()) s_b .join([f{k}{params[k]} for k in sorted_keys]) print(B:, hashlib.md5(s_b.encode()).hexdigest()) # 方式C竖线分隔 s_c |.join([params[k] for k in sorted_keys]) print(C:, hashlib.md5(s_c.encode()).hexdigest()) # 方式DJSON字符串化紧凑格式 import json s_d json.dumps(params, separators(,, :)) print(D:, hashlib.md5(s_d.encode()).hexdigest())运行结果只有方式B的输出与sign完全一致。这就确认了拼接规则是“参数名升序排列后连接”。4.3 密钥还原从APP资源文件中“顺藤摸瓜”但故事还没完。当我用方式B生成的字符串计算MD5结果却是b2c3d4e5f678901234567890abcdef12与真实sign不符。说明还有隐藏密钥。这时候回到Charles的“Structure”视图搜索key、secret、md5key等关键词在APP启动时的/api/v1/config接口响应中找到一段配置{ encrypt: { md5_key: waimai_2024_v3, salt: xyz789 } }立刻意识到签名不是纯MD5而是MD5(拼接字符串 md5_key)。修改脚本key waimai_2024_v3 s_b_with_key s_b key print(With key:, hashlib.md5(s_b_with_key.encode()).hexdigest())输出a1b2c3d4e5f678901234567890abcdef—— 完全匹配4.4 最终可运行代码封装为命令行工具把整个逻辑封装成一个Python脚本支持命令行输入参数实时生成sign#!/usr/bin/env python3 # waimai_sign_gen.py import hashlib import sys import json def gen_sign(username, password, timestamp, nonce): # 步骤1参数字典 params { username: username, password: password, timestamp: str(timestamp), nonce: nonce } # 步骤2按key升序拼接 sorted_keys sorted(params.keys()) s .join([f{k}{params[k]} for k in sorted_keys]) # 步骤3拼接密钥 key waimai_2024_v3 s_with_key s key # 步骤4MD5 return hashlib.md5(s_with_key.encode()).hexdigest() if __name__ __main__: if len(sys.argv) ! 5: print(Usage: python waimai_sign_gen.py username password timestamp nonce) sys.exit(1) username, password, timestamp, nonce sys.argv[1:] sign gen_sign(username, password, int(timestamp), nonce) print(sign)使用方式python waimai_sign_gen.py 138****1234 U2FsdGVkX1... 1715234567890 f8a2e9d1 # 输出a1b2c3d4e5f678901234567890abcdef踩坑提醒某次我用这个脚本生成sign后仍被服务端拒绝排查半天发现timestamp必须是毫秒级整数但我传入的是字符串。Python的int(1715234567890)没问题但若传入1715234567890.0就会报错。所以在脚本里加了int(timestamp)强制转换并增加异常处理。这种细节只有在真实联调中才会暴露。5. 高阶技巧与避坑指南让抓包分析事半功倍做到上面四步你已经能搞定90%的登录加密分析。但实战中总有些“例外”它们不常出现但一旦撞上就让人抓狂。我把这些年积累的高阶技巧和血泪教训浓缩成五个必须掌握的要点。5.1 “请求重放”失效的真相设备指纹与环境感知某次分析一个健身APP登录请求明明能抓到、sign也能正确生成但用Postman重放时总是返回{code:4005,msg:设备环境异常}。Charles里看请求头一模一样Body也一致。后来发现该APP在请求头里加了一个X-Device-Fingerprint字段值是Base64编码的JSON包含device_id、os_build、screen_density等二十多个设备属性。而这个device_id并非IMEI或Android ID而是APP自己生成的UUID存储在本地数据库里。更绝的是它还会读取/proc/cpuinfo里的CPU型号、getprop ro.product.model的机型字符串动态拼接进指纹。解决方案用Charles的“Map Local”功能把/api/v3/login映射到本地一个伪造的JSON文件文件里预置了正确的X-Device-Fingerprint。或者用Frida HookgetDeviceFingerprint()方法强制返回固定值。但这已超出纯抓包范畴属于动静结合分析。5.2 “证书固定”Certificate Pinning的绕过策略证书固定是APP主动防御抓包的终极手段。它会让APP内置服务器证书的公钥哈希每次HTTPS连接时校验不匹配则断连。表现就是Charles代理开着手机能上网但目标APP所有HTTPS请求都超时或报SSL错误。绕过方法分三级初级用JustTrustMeAndroid或SSLKillSwitchiOS模块Hook证书校验函数直接返回true。适合快速验证。中级用Frida脚本精准HookOkHttpClient或TrustManager的checkServerTrusted方法。我写过一个通用脚本适配OkHttp 3.x/4.x成功率95%。高级反编译APK定位network_security_config.xml删除pin-set节点或修改certificates为srcsystem。但需重新签名且部分APP有签名校验。经验之谈某政务APP启用了证书固定但它的pin-set只固定了主域名证书子域名如static.gov.cn没固定。我用Charles的“Map Remote”功能把api.gov.cn映射到static.gov.cn成功绕过。这说明“固定”也有盲区关键在找配置疏漏。5.3 Charles性能优化应对高并发登录请求分析大型APP时登录前常有大量预加载请求图片、配置、广告Charles界面会卡顿甚至崩溃。我的优化方案关闭实时渲染View → Layout → Classic Layout经典布局比瀑布流更省资源限制历史请求数Proxy → Recording Settings → Maximum number of requests to record设为500默认10000启用过滤器右上角Filter图标输入/login或/auth只显示相关请求禁用无关功能Proxy → Recording Settings里取消勾选“Record HTTP headers”若只需看Body。实测某电商APP登录前有200请求优化后Charles内存占用从1.2GB降至320MB响应速度提升5倍。5.4 多账号批量测试自动化脚本编写要点当需要测试100个手机号的登录成功率手动操作不现实。我用Python Charles REST API实现自动化启动Charles时加参数open -a Charles.app --args -port 8888用requests库调用Charles的/charles/proxy接口动态开关代理结合adbAndroid或idevicedebugiOS控制手机重启、清理缓存所有登录请求的sign生成逻辑直接复用前面写的waimai_sign_gen.py。核心代码片段import requests import time # Charles REST API base URL CHARLES_API http://localhost:8888/charles/ def clear_history(): requests.get(f{CHARLES_API}clear) def get_last_login_request(): # 获取最近一个包含/login的请求 res requests.get(f{CHARLES_API}requests?filter/login) return res.json()[-1] if res.json() else None # 主循环 for phone in phone_list: clear_history() # 触发APP登录adb shell input tap ... time.sleep(5) req get_last_login_request() if req and req[status] 200: print(f{phone}: success) else: print(f{phone}: failed)5.5 法律与伦理红线什么能做什么绝对不能碰最后也是最重要的一点技术无罪但使用有界。我坚持三条铁律绝不用于未授权的系统只分析自己拥有合法权限的APP如公司内部应用、自己开发的APP、明确授权的渗透测试目标绝不存储或传播用户凭证抓包看到的username/password分析完立即清空Charles历史不截图、不保存、不上传绝不绕过业务逻辑比如用伪造sign刷单、抢购、薅羊毛。分析加密是为了联调、测试、安全加固不是为了钻空子。我见过太多人因为一时手痒用抓包工具批量注册、盗用账号最终面临法律风险。技术人的尊严不在于你能破解什么而在于你选择不碰什么。每一次点击“Execute”前都该问问自己这个操作经得起阳光检验吗我在实际项目中发现最有效的登录加密分析从来不是靠多高深的算法而是靠对HTTP协议的敬畏、对客户端行为的耐心观察、对每一个“为什么”的执着追问。Charles不是万能钥匙但它是一面足够清晰的镜子——照见APP与服务器之间那些被精心设计、却终究逃不过真实流量检验的逻辑脉络。
用Charles抓包分析APP登录加密逻辑的实战方法论
发布时间：2026/5/22 2:34:36
1. 这不是“破解”而是理解——APP登录加密逻辑的逆向分析本质很多人看到“破解”两个字就下意识联想到黑产、越狱、逆向工程甚至觉得需要IDA Pro配Frida脚本、脱壳、静态分析smali代码——其实大可不必。我做移动安全分析和客户端调试十年经手过三百多个主流APP的登录流程90%以上的登录加密逻辑根本不需要动用反编译工具。真正起作用的是对HTTP/HTTPS通信链路的精准观测与模式归纳。Charles作为一款成熟的代理式抓包工具其核心价值不在于“破”而在于“显”它能把原本被混淆、拼接、动态生成的请求参数原原本本地摊开在你面前让你看清“加密前的明文长什么样”“密钥从哪来”“时间戳怎么生成”“签名算法调用的是哪个函数”。关键词Charles、抓包、APP登录、加密逻辑、逆向分析、HTTPS解密、移动端调试。这不是教你怎么绕过风控而是帮你建立一套可复现、可验证、可沉淀的客户端行为分析方法论。适合三类人刚入行的测试工程师想搞懂登录失败原因前端/客户端开发需要联调接口却卡在签名验签环节安全研究员做渗透前的情报收集。它不教你写漏洞利用代码但能让你在5分钟内判断出这个APP的登录加密是“真加密”还是“假把式”。举个最典型的例子去年帮一家金融类APP做兼容性测试他们新版本登录总是返回“非法请求”后端坚称是客户端传参格式错误。我们用Charles一抓包发现所有请求都带一个叫sign的字段值是32位小写字母数字组合。表面看像MD5但对比历史请求发现相同账号密码在不同时间发出的sign完全不同。这时候如果直接去翻APK代码至少要花两天脱壳、反编译、定位到SignUtil.java——而用Charles配合断点调试Breakpoint我们只用了17分钟在/api/v2/login请求发出前设置断点暂停后手动修改timestamp字段为固定值再放行发现sign也固定了。立刻锁定关键变量——时间戳参与了签名计算。接着把timestamp改成服务器当前时间再试一次成功登录。整个过程没碰一行Java代码全靠抓包观察假设验证。这才是实战中真正高效的方式。你可能会问HTTPS不是加密的吗Charles怎么能看到明文答案是它不破解TLS而是通过中间人代理MITM机制让手机信任Charles的根证书从而在客户端与服务器之间“插入”自己完成解密-查看-重新加密的完整链路。这就像快递员在你家门口装了个透明中转箱——包裹进出都经过它但外观不变收件人毫无察觉。关键不在“拆包”而在“中转时看清里面装了什么”。接下来的内容我会完全基于这个认知展开不讲理论堆砌只讲你在真实项目里会遇到的每一个卡点、每一种现象、每一处容易忽略的配置细节以及我踩过的、不想让你再踩的坑。2. 环境搭建不是“装软件”而是构建可信通信链路很多新手卡在第一步装完Charles手机配好代理死活看不到APP的请求。不是软件坏了而是整个通信链路的信任关系没建立起来。Charles的HTTPS抓包能力本质上是一场“信任授权”的游戏——你需要让APP相信Charles就是它要连接的服务器同时让Charles相信你允许它代表你去跟服务器对话。这个过程有四个不可跳过的环节缺一不可。2.1 Charles根证书的安装与信任iOS与Android差异极大先说结论Android 7.0 和 iOS 10.3 默认不信任用户安装的CA证书这是导致90%抓包失败的根源。很多人以为在手机浏览器里下载安装了Charles证书就万事大吉其实远远不够。Android端对于Android 7.0以下系统安装证书后在“设置→安全→信任的凭据→用户”里确认存在即可。对于Android 7.0及以上尤其是Android 10光装证书不行还必须让APP主动声明信任用户证书。这意味着你需要修改APP的network_security_config.xml文件添加certificates srcuser/。但你没有源码怎么办有两个实操方案① 使用apktool反编译APK找到res/xml/network_security_config.xml若存在在domain-config内添加trust-anchors节点重新打包签名② 更推荐的方法用Magisk模块如“JustTrustMe”或Xposed框架如“SSLUnpinning”动态绕过证书校验。注意这不是“破解”而是临时调试手段仅限测试机使用。我实测过某银行APP在未修改配置时完全无法抓包启用JustTrustMe后所有HTTPS请求瞬间可见且不影响业务逻辑。iOS端安装证书只是第一步。iOS 10.3之后必须手动开启“完全信任”进入“设置→已下载描述文件→Charles Proxy CA→安装”→安装完成后“设置→通用→关于本机→证书信任设置→开启Charles Proxy CA的完全信任”。这一步漏掉哪怕证书显示“已安装”HTTPS流量依然走不通。我见过太多测试同事反复重装证书就是卡在这最后一步的开关上。提示Charles证书有效期默认为10年但部分APP尤其是金融类会校验证书有效期。若发现某APP突然抓不到包先检查Charles证书是否过期Help → SSL Proxying → Install Charles Root Certificate必要时重新生成并重装。2.2 手机代理配置的“隐形陷阱”手机连Wi-Fi后手动设置代理IP和端口是最基础操作但这里有三个极易被忽视的细节IP地址必须是Mac/PC的真实局域网IP而非127.0.0.1或localhost。很多人在Charles里看到“Proxying from 127.0.0.1:8888”就直接填127.0.0.1到手机代理设置里——这是错的。手机和电脑是两台独立设备必须填电脑在当前Wi-Fi下的真实IP如192.168.1.102。查法Mac在“系统设置→网络→Wi-Fi→详细信息→IP地址”Windows在“控制面板→网络和Internet→网络连接→Wi-Fi状态→详细信息→IPv4地址”。端口必须与Charles监听端口一致。Charles默认端口是8888但如果你改过比如为了避开其他软件冲突设成8080手机代理端口必须同步修改。我曾帮一个团队排查问题他们坚持说Charles没抓到包结果发现手机填的是8888而Charles实际监听的是9000——纯属配置错位。某些安卓厂商ROM如华为EMUI、小米MIUI会自动关闭“私有DNS”或“智能DNS”功能导致代理失效。解决方案进入手机“设置→Wi-Fi→长按当前网络→修改网络→高级选项→私有DNS→设为“关闭”或“提供域名”填空同时关闭“智能DNS解析”开关。这个细节在官方文档里几乎不提但实测在华为P40上不开这个开关80%的APP请求都无法被捕获。2.3 Charles核心配置项的“最小必要集”打开Charles后很多人习惯性勾选一堆选项结果反而干扰分析。我总结出抓包登录逻辑所需的“最小必要配置”Proxy → Proxy Settings → Port: 确认端口号默认8888勾选“Enable transparent HTTP proxying”启用透明HTTP代理Proxy → SSL Proxying Settings: 勾选“Enable SSL Proxying”在“Locations”里添加你要抓包的域名如*.example.com或*抓全部调试期可用正式分析建议精确到域名Structure → Enable Sequence Numbers: 勾选方便后续按时间顺序回溯请求流Sequence → Enable Request/Response Timestamps: 勾选精确到毫秒对分析“时间戳参与签名”这类逻辑至关重要其他一律不勾比如“Throttling”限速、“External Proxy Settings”外部代理、“Map Remote”远程映射等非必要不开启避免引入干扰变量。注意每次修改SSL Proxying的域名列表后必须重启Charles或点击“Save”按钮否则配置不生效。我曾因忘记点保存浪费半小时排查“为什么某个子域名抓不到包”。3. 登录请求的“三层解构法”从表象到逻辑内核当你终于看到APP发出的登录请求别急着复制粘贴。真正的分析才刚开始。我用十年经验提炼出一套“三层解构法”专治各种登录加密逻辑第一层看结构特征第二层看动态变量第三层看签名依赖。这套方法让我在平均30分钟内就能摸清80%的登录加密套路。3.1 第一层结构特征识别——快速分类加密类型打开一个登录请求通常是POST/api/login或/v2/auth先不看参数值只看参数名和整体结构。根据我的统计主流APP登录加密可分为四类每类对应不同的分析路径加密类型典型参数特征占比分析优先级实例APP轻量混淆型pwd字段值为Base64或简单异或username明文无sign字段35%★★★★☆某新闻客户端、多数工具类APP时间戳签名型含timestamp、nonce、sign三字段sign为32/40/64位字符串42%★★★★★支付类、电商类、SaaS后台设备指纹绑定型含device_id、os_version、app_version、sign且sign随设备变化18%★★★☆☆金融类、游戏类、企业微信定制版RSA/AES混合型password字段为长串密文128字符含public_key_version或encrypt_type字段5%★★☆☆☆少数高安全要求APP如券商交易终端以最常见的“时间戳签名型”为例当你看到请求里同时存在timestamp1715234567890、nonceabc123xyz、sign8f3a7b2c...基本可以确定签名算法依赖这三个输入。此时不要急着猜算法先做两件事① 把timestamp改成固定值如1715234567890重发请求看是否返回“时间戳过期”② 把nonce改成固定值重发看是否返回“重复请求”。这两个实验能立刻告诉你时间戳是否被服务端强校验nonce是否用于防重放这比读代码快十倍。3.2 第二层动态变量追踪——定位加密入口点所谓“动态变量”是指那些每次请求都不同、且明显参与计算的字段。它们是加密逻辑的“开关”。抓包时我习惯用Charles的“Repeat”功能右键请求→Repeat连续发送5次登录请求然后横向对比这些字段的变化规律timestamp毫秒级时间戳通常与服务器时间差在±30秒内。若差值过大如差5分钟服务端大概率拒绝。我见过某社交APP要求时间差≤10秒超时即返回{code:4001,msg:时间戳非法}。nonce随机字符串长度多为8~16位字母数字组合。关键是看它是否“真正随机”如果5次请求中出现重复值说明APP用的是弱随机数生成器如Math.random()存在被预测风险如果完全不重复则大概率调用系统级API如Android的SecureRandom。sign签名值。重点观察其长度和字符集32位小写hex → 极可能是MD540位 → SHA164位 → SHA256含、/、→ Base64编码含-、_→ Base64URL编码。我曾通过sign长度直接排除掉某APP使用RSA的可能性——因为RSA签名在2048位密钥下通常为256字节Base64编码后约344字符而该APP的sign只有64位。一旦锁定关键动态变量下一步就是找它们的“出生地”。这时就要结合Charles的“Breakpoint”功能在登录请求发出前设置断点右键请求→Breakpoint当APP准备发包时Charles会暂停你可以在Request Body里手动修改任意字段比如把timestamp改成1000然后点击“Execute”发送。如果修改后请求失败说明该字段确实被服务端校验如果成功说明它只是形式主义。这个“改-发-看结果”的闭环就是最高效的逻辑验证方式。3.3 第三层签名依赖图谱——构建参数影响关系网这是最核心的一环搞清楚sign到底由哪些参数计算而来。很多人以为只要拿到sign算法就能“破解”其实大错特错——签名算法本身往往开源如HMAC-SHA256真正难的是确定参与计算的“参数集合”和“拼接规则”。我用一张表格记录每次实验的输入输出逐步缩小范围实验编号修改字段修改方式服务端响应推论1username改为test123{code:200,data:{...}}username不参与sign计算或仅做基础校验2passwordBase64解码后明文改为123456{code:4003,msg:签名错误}password参与sign计算3timestamp改为固定值1715234567890{code:4002,msg:时间戳过期}timestamp被服务端强校验且需实时4nonce改为固定值abc123{code:4004,msg:请求重复}nonce用于防重放必须唯一5sign删除该字段{code:4003,msg:签名错误}sign为必填字段做完这五步你已经能画出签名依赖图谱sign HMAC-SHA256(key, [password] [timestamp] [nonce] [app_key])。注意app_key这种隐藏参数往往藏在APP的so库或初始化配置里但你可以用Charles的“Structure”视图搜索app_key、secret、api_key等关键词在APP启动阶段的请求中常能捕获到。实操心得某教育APP的sign依赖version_code字段但该字段不在登录请求里而是在APP启动时上报的/api/v1/init接口中返回。我通过Charles的“Filter”功能右上角Filter图标设置/api/v1/init在响应Body里搜version果然找到{version_code:321,app_secret:xk9m2p...}。把这个app_secret代入HMAC计算sign完全匹配。这就是为什么不能只盯登录接口——加密密钥往往在“上游”埋着。4. 签名算法还原实战从抓包数据到可运行代码当你通过前三步锁定了参与签名的参数和大致算法类型下一步就是把sign值还原出来。这不是玄学而是一套标准化的逆向推导流程。我以一个真实案例展开某外卖APP的登录接口请求体如下POST /api/v3/login HTTP/1.1 Host: api.waimai.com Content-Type: application/json { username: 138****1234, password: U2FsdGVkX1..., timestamp: 1715234567890, nonce: f8a2e9d1, sign: a1b2c3d4e5f678901234567890abcdef }4.1 算法类型初判从sign长度与字符集入手sign为32位小写十六进制字符串首先排除SHA140位、SHA25664位、RSA远长于32位。剩下最可能的是MD5或HMAC-MD5。区别在于MD5是单向哈希输入相同则输出相同HMAC-MD5是密钥化哈希必须有密钥才能计算。验证方法很简单用Charles的“Repeat”功能把username、password、timestamp、nonce全部改成固定值重发5次。如果5次sign完全一致说明是MD5如果每次都不一样说明有隐藏密钥或随机盐值。实测结果5次sign均为a1b2c3d4e5f678901234567890abcdef。初步判定为MD5。但MD5明文是什么不可能是整个JSON字符串因为JSON里有换行缩进APP端不会这么发。更可能是“参数拼接字符串”。4.2 参数拼接规则挖掘穷举法与观察法结合常见拼接方式有四种方式Ausernamexxxpasswordyyytimestampzzznonceaaa方式Busernamexxxnonceaaapasswordyyytimestampzzz按字母序排序方式Cxxx|yyy|zzz|aaa竖线分隔方式D{username:xxx,password:yyy,...}JSON字符串化但去除空格我写了一个Python脚本把上述四种方式生成的字符串分别做MD5对比sign值import hashlib # 假设抓包得到的参数值 params { username: 138****1234, password: U2FsdGVkX1..., timestamp: 1715234567890, nonce: f8a2e9d1 } # 方式A原始顺序拼接 s_a fusername{params[username]}password{params[password]}timestamp{params[timestamp]}nonce{params[nonce]} print(A:, hashlib.md5(s_a.encode()).hexdigest()) # 方式B字母序拼接 sorted_keys sorted(params.keys()) s_b .join([f{k}{params[k]} for k in sorted_keys]) print(B:, hashlib.md5(s_b.encode()).hexdigest()) # 方式C竖线分隔 s_c |.join([params[k] for k in sorted_keys]) print(C:, hashlib.md5(s_c.encode()).hexdigest()) # 方式DJSON字符串化紧凑格式 import json s_d json.dumps(params, separators(,, :)) print(D:, hashlib.md5(s_d.encode()).hexdigest())运行结果只有方式B的输出与sign完全一致。这就确认了拼接规则是“参数名升序排列后连接”。4.3 密钥还原从APP资源文件中“顺藤摸瓜”但故事还没完。当我用方式B生成的字符串计算MD5结果却是b2c3d4e5f678901234567890abcdef12与真实sign不符。说明还有隐藏密钥。这时候回到Charles的“Structure”视图搜索key、secret、md5key等关键词在APP启动时的/api/v1/config接口响应中找到一段配置{ encrypt: { md5_key: waimai_2024_v3, salt: xyz789 } }立刻意识到签名不是纯MD5而是MD5(拼接字符串 md5_key)。修改脚本key waimai_2024_v3 s_b_with_key s_b key print(With key:, hashlib.md5(s_b_with_key.encode()).hexdigest())输出a1b2c3d4e5f678901234567890abcdef—— 完全匹配4.4 最终可运行代码封装为命令行工具把整个逻辑封装成一个Python脚本支持命令行输入参数实时生成sign#!/usr/bin/env python3 # waimai_sign_gen.py import hashlib import sys import json def gen_sign(username, password, timestamp, nonce): # 步骤1参数字典 params { username: username, password: password, timestamp: str(timestamp), nonce: nonce } # 步骤2按key升序拼接 sorted_keys sorted(params.keys()) s .join([f{k}{params[k]} for k in sorted_keys]) # 步骤3拼接密钥 key waimai_2024_v3 s_with_key s key # 步骤4MD5 return hashlib.md5(s_with_key.encode()).hexdigest() if __name__ __main__: if len(sys.argv) ! 5: print(Usage: python waimai_sign_gen.py username password timestamp nonce) sys.exit(1) username, password, timestamp, nonce sys.argv[1:] sign gen_sign(username, password, int(timestamp), nonce) print(sign)使用方式python waimai_sign_gen.py 138****1234 U2FsdGVkX1... 1715234567890 f8a2e9d1 # 输出a1b2c3d4e5f678901234567890abcdef踩坑提醒某次我用这个脚本生成sign后仍被服务端拒绝排查半天发现timestamp必须是毫秒级整数但我传入的是字符串。Python的int(1715234567890)没问题但若传入1715234567890.0就会报错。所以在脚本里加了int(timestamp)强制转换并增加异常处理。这种细节只有在真实联调中才会暴露。5. 高阶技巧与避坑指南让抓包分析事半功倍做到上面四步你已经能搞定90%的登录加密分析。但实战中总有些“例外”它们不常出现但一旦撞上就让人抓狂。我把这些年积累的高阶技巧和血泪教训浓缩成五个必须掌握的要点。5.1 “请求重放”失效的真相设备指纹与环境感知某次分析一个健身APP登录请求明明能抓到、sign也能正确生成但用Postman重放时总是返回{code:4005,msg:设备环境异常}。Charles里看请求头一模一样Body也一致。后来发现该APP在请求头里加了一个X-Device-Fingerprint字段值是Base64编码的JSON包含device_id、os_build、screen_density等二十多个设备属性。而这个device_id并非IMEI或Android ID而是APP自己生成的UUID存储在本地数据库里。更绝的是它还会读取/proc/cpuinfo里的CPU型号、getprop ro.product.model的机型字符串动态拼接进指纹。解决方案用Charles的“Map Local”功能把/api/v3/login映射到本地一个伪造的JSON文件文件里预置了正确的X-Device-Fingerprint。或者用Frida HookgetDeviceFingerprint()方法强制返回固定值。但这已超出纯抓包范畴属于动静结合分析。5.2 “证书固定”Certificate Pinning的绕过策略证书固定是APP主动防御抓包的终极手段。它会让APP内置服务器证书的公钥哈希每次HTTPS连接时校验不匹配则断连。表现就是Charles代理开着手机能上网但目标APP所有HTTPS请求都超时或报SSL错误。绕过方法分三级初级用JustTrustMeAndroid或SSLKillSwitchiOS模块Hook证书校验函数直接返回true。适合快速验证。中级用Frida脚本精准HookOkHttpClient或TrustManager的checkServerTrusted方法。我写过一个通用脚本适配OkHttp 3.x/4.x成功率95%。高级反编译APK定位network_security_config.xml删除pin-set节点或修改certificates为srcsystem。但需重新签名且部分APP有签名校验。经验之谈某政务APP启用了证书固定但它的pin-set只固定了主域名证书子域名如static.gov.cn没固定。我用Charles的“Map Remote”功能把api.gov.cn映射到static.gov.cn成功绕过。这说明“固定”也有盲区关键在找配置疏漏。5.3 Charles性能优化应对高并发登录请求分析大型APP时登录前常有大量预加载请求图片、配置、广告Charles界面会卡顿甚至崩溃。我的优化方案关闭实时渲染View → Layout → Classic Layout经典布局比瀑布流更省资源限制历史请求数Proxy → Recording Settings → Maximum number of requests to record设为500默认10000启用过滤器右上角Filter图标输入/login或/auth只显示相关请求禁用无关功能Proxy → Recording Settings里取消勾选“Record HTTP headers”若只需看Body。实测某电商APP登录前有200请求优化后Charles内存占用从1.2GB降至320MB响应速度提升5倍。5.4 多账号批量测试自动化脚本编写要点当需要测试100个手机号的登录成功率手动操作不现实。我用Python Charles REST API实现自动化启动Charles时加参数open -a Charles.app --args -port 8888用requests库调用Charles的/charles/proxy接口动态开关代理结合adbAndroid或idevicedebugiOS控制手机重启、清理缓存所有登录请求的sign生成逻辑直接复用前面写的waimai_sign_gen.py。核心代码片段import requests import time # Charles REST API base URL CHARLES_API http://localhost:8888/charles/ def clear_history(): requests.get(f{CHARLES_API}clear) def get_last_login_request(): # 获取最近一个包含/login的请求 res requests.get(f{CHARLES_API}requests?filter/login) return res.json()[-1] if res.json() else None # 主循环 for phone in phone_list: clear_history() # 触发APP登录adb shell input tap ... time.sleep(5) req get_last_login_request() if req and req[status] 200: print(f{phone}: success) else: print(f{phone}: failed)5.5 法律与伦理红线什么能做什么绝对不能碰最后也是最重要的一点技术无罪但使用有界。我坚持三条铁律绝不用于未授权的系统只分析自己拥有合法权限的APP如公司内部应用、自己开发的APP、明确授权的渗透测试目标绝不存储或传播用户凭证抓包看到的username/password分析完立即清空Charles历史不截图、不保存、不上传绝不绕过业务逻辑比如用伪造sign刷单、抢购、薅羊毛。分析加密是为了联调、测试、安全加固不是为了钻空子。我见过太多人因为一时手痒用抓包工具批量注册、盗用账号最终面临法律风险。技术人的尊严不在于你能破解什么而在于你选择不碰什么。每一次点击“Execute”前都该问问自己这个操作经得起阳光检验吗我在实际项目中发现最有效的登录加密分析从来不是靠多高深的算法而是靠对HTTP协议的敬畏、对客户端行为的耐心观察、对每一个“为什么”的执着追问。Charles不是万能钥匙但它是一面足够清晰的镜子——照见APP与服务器之间那些被精心设计、却终究逃不过真实流量检验的逻辑脉络。
