做iOS安全测试这些年我破解过不少App的通信加密但每次遇到这种请求带签名动态token的组合还是得老老实实走一遍完整的逆向链路。今天把某藤之恋这款社交App的请求加密校验算法分析过程完整复盘一下不是说教你怎么绕过风控而是帮大家理清一条思路当你在抓包里看到一个加密字段如何从网络层一路回溯到算法层把它的加密逻辑完整还原出来。先交代背景。某藤之恋是当下还挺火的一款陌生人社交应用iOS端每个业务请求都会带上两个额外字段一个类似签名一个类似动态会话token。测试过程中我用改包工具改了其中一个文本参数服务端直接拒绝返回一串密文错误码。这激起了我的兴趣于是花了两个晚上把整套加密链路拆了个底朝天。这篇文章适合三类人看一是做iOS安全测试的朋友想系统了解抓包到算法还原的完整流程二是App开发工程师想知道客户端加密防护是怎么设计和被攻破的从而写出更可靠的方案三是刚接触逆向的新手想搞清楚Frida、Hopper这类工具到底能派上什么用场。文中所有测试均在取得授权的测试设备上完成各位拿去研究协议时也要注意合规边界。1. 先看流量为什么抓包工具拿不到一条完整请求任何协议分析的起点都是抓包。但某藤之恋这个App第一次上手就给我来了个下马威——Charles挂着SSL代理看起来请求都正常发出去可点进Detail一看body里全是密文header里有两个字段一个叫Zz-Token一个叫X-Sign长度远超常规的session id我开始意识到这两段东西就是加密校验的核心。1.1 抓包失败的第一现场更麻烦的是部分核心接口在Charles下完全看不到。表现是请求发出去后服务器正常返回但Charles的会话列表里压根没有这条记录。一开始我以为是自己证书配置有问题后来才反应过来这是App在传输层做了手脚。iOS应用不走系统代理的常见原因有两个使用了Network.framework或URLSession的ephemeral配置某些底层实现不读系统代理设置直接走NSStream或自研的socket通信HTTP代理看不到。某藤之恋属于第二种情况部分长连接消息通道走的是自研协议普通抓包工具确实无能为力。这时候不要死磕代理设置换思路在越狱设备上做流量转发或者直接上动态分析。1.2 绕过证书校验的常规思路和注意点对于走HTTPS的标准接口抓不到包的时候第一反应应该是证书固定SSL Pinning。常规做法是通过越狱环境配合SSL Kill Switch类工具或者用Frida绕过证书校验逻辑让App信任我们的CA证书。这里有个很重要的注意点现在很多iOS App会检测调试状态越狱机上一旦装了Substrate或FridaApp可能直接闪退所以要先解决反调试问题后面详细讲。还有一条更省事的路子在开发阶段就让客户端临时关闭Pinning。但正式版本的App没有这个开关所以这只能作为辅助手段。我的经验是能动态调试和改包的情况下优先做运行时分析不要一开始就盯着静态反汇编。动态分析能看到加密输入和输出的真实数据比对着汇编代码猜快得多。经过一番折腾我用越狱设备配合Frida成功绕过了证书校验终于看到了核心接口的完整请求包。header里三个关键字段字段名示例值初步判断Zz-Token8f3c2a...64位十六进制会话标识或动态密钥X-Signb0e1d5...128位十六进制请求签名X-Ts1735432100000毫秒级时间戳X-Ts的出现说明有防重放机制X-Sign的存在说明服务端校验了请求完整性。有了这个基本盘下一步就是顺着这些字段的生成位置往App内部挖。2. 动态注入在运行时把App的加密逻辑“问”出来拿到字段名之后最直接的问题就是这个X-Sign到底是谁生成的在Object-C的运行时环境里这个问题可以通过Method Swizzling或者Frida Hook来解决。动态分析的核心优势是直接拿到运行时上下文比纯静态分析推理快得多。2.1 为什么先做动态分析再开静态反编译很多逆向新手上来就用Hopper打开Mach-O文件一头扎进汇编代码里这其实效率很低。对于OC写的App运行时信息比汇编直观得多——方法名、类名、参数类型全都暴露在Mach-O的__objc_methname段里。先用动态分析摸清调用链再针对性地打开静态工具思路会清晰很多。我习惯的做法是用Frida附加到进程先hook网络层再顺着调用栈往业务层回溯。2.2 从网络层往业务层回溯第一步hookNSMutableURLRequest的setValue:forHTTPHeaderField:方法把设置header的调用栈打出来。这一步能直接告诉我们X-Sign是在哪个类、哪个方法里被塞进请求的。// Frida脚本示意打印所有自定义header设置点 var hook ObjC.classes.NSMutableURLRequest[- setValue:forHTTPHeaderField:]; Interceptor.attach(hook.implementation, { onEnter: function(args) { var value ObjC.Object(args[2]).toString(); var field ObjC.Object(args[3]).toString(); if (field.indexOf(X-) 0 || field.indexOf(Zz-) 0) { console.log([ field ] value); console.log(Thread.backtrace(this.context, Backtracer.ACCURATE) .map(DebugSymbol.fromAddress).join(\n)); } } });跑起来之后看到堆栈里出现了SGRequestSigner这个类里面有一个- signRequest:timestamp:方法。名字起得这么直白基本就锁定目标了。第二步直接hook这个signRequest方法看它的入参和返回值。Frida可以很方便地打印ObjC方法的参数和返回值这里就不过多展开了。2.3 跑到非基础库里的黑盒部分然而事情没有这么简单。我hook了signRequest之后发现它内部调用了一个C函数函数名经过符号剥离在Frida里只能看到一个地址。更关键的是这个方法执行完我拿不到中间过程的明文。这时候就需要hook底层的加密API了。iOS开发中常见的加密API都集中在CommonCrypto和Security框架里包括但不限于函数名功能CCCrypt对称加密核心入口AES/DES/3DESCCHmacHMAC计算CC_SHA256/CC_SHA1哈希摘要SecKeyEncrypt非对称加密RSA我在CCCrypt上下了一个断点观察它的参数。Frida脚本长这样// 观察CommonCrypto的加密调用参数 var s Module.findExportByName(libcommonCrypto.dylib, CCCrypt); Interceptor.attach(s, { onEnter: function(args) { var op args[0].toInt32(); // 0加密, 1解密 var alg args[1].toInt32(); // 算法编号 var keyLen args[4].toInt32(); // 密钥长度 console.log(CCCrypt op op alg alg keyLen keyLen); } });结果很快就出来了alg0也就是kCCAlgorithmAESkeyLen32字节表示是AES-256。op0说明是加密操作。但值得注意的是加密前的数据并不是我们业务参数的明文而是已经经过一层变换的字节串——这说明AES之上还套了一层其他逻辑。2.4 实际发现请求签名不是单纯MD5而是一段自定义摘要继续深挖我发现整个签名流程分了两段第一段是“摘要”过程将业务参数、时间戳、设备标识、一个固定字符串按特定顺序拼接然后做了一次类似SHA256的哈希输出64位十六进制字符串。这个固定字符串看起来像盐值salt是以硬编码形式存在二进制里的。第二段是“加密”过程把上一步得到的哈希字符串作为明文用AES-256-ECB模式加一次密最终得到请求头里的X-Sign。注意ECB模式没有IV这也给识别工作省了事。动态分析到这一步加密链路的主干已经摸清了。但要完整还原算法细节、确认盐值内容、找到密钥来源还得靠静态拆解二进制。3. 静态拆解Mach-O把加密算法从二进制里抠出来动态分析解决了这是什么算法的问题静态分析解决具体参数是什么的问题。某藤之恋的App是标准未加固的Mach-O二进制这就好办多了。如果碰到加了壳或者做了混淆的难度会指数级上升这里不谈。3.1 拿到Mach-O之后先干三件事第一件事用class-dump导出OC头文件看业务类的命名。这个App没有做OC层面的混淆SGRequestSigner的完整接口直接暴露出来了连方法参数名都没怎么变。这一步能帮你建立整个代码的地图。第二件事用strings在二进制里搜关键字诸如salt、secret、signKey之类的字符串。某藤之恋这里我直接就搜到了xTengSign_SALT_v2这个奇葩字符串显然就是盐值还标注了版本号。这提醒我们很多开发者觉得硬编码盐值没事其实在逆向面前就是一层窗户纸。第三件事检查二进制是否嵌入了反调试检测代码。常见的有ptrace函数调用、sysctl检测跟踪状态、或者__attribute__((constructor))注入的检测逻辑。如果发现这些静态分析前得先想办法绕过或者干脆以动态分析为主。3.2 从系统加密API的交叉引用回推调用链因为签名流程里用了CommonCrypto的CCCrypt和CC_SHA256这两个是系统库的导出符号在二进制里一定会有引用。在反汇编工具里搜索CCCrypt的交叉引用XREF就能找到所有调用它的代码位置。我用的是Hopper做的这个分析操作路径是搜索符号CCCrypt查看调用它的地址然后顺着地址往上回溯进入了SGRequestSigner的- signRequest:timestamp:方法对应的汇编区域。这一步不但确认了动态分析的结果还把密钥的由来搞清楚了——密钥不是硬编码在二进制里的而是由Zz-Token经过一次MD5后取前16字节得到的。这里有个小细节值得说用AES-256算法但密钥是16字节也就是说实际加密强度只有AES-128的水平。开发者的意图可能是统一用256比特的算法框架但密钥长度没跟上。这算是很常见的防护实现瑕疵。3.3 当算法被“白盒”封装时怎么办某藤之恋的加密很简单但如果我们的目标是更复杂的App很可能碰到白盒AES或者自研算法。所谓白盒AES就是把密钥融合到查表操作里你就算能看到S盒、看到轮运算也直接抠不出密钥字节。这种情况下搜AES的S盒特征63 7c 77 7b往往搜不到因为S盒已经被合并进了别的查找表。我的建议是不要试图在二进制里还原白盒算法成本太高。更聪明的做法是让App自己算——你在运行时给它一组已知输入观察输出用“选择明文分析”的思路反推接口语义。有经验的话还能直接hook白盒库的公开函数很多商业白盒方案包装得并不好照样能抓到入参和出参。4. 算法还原与验证从AES-CBC到签名链路的完整拼图动态分析静态交叉引用把整个链路拼齐了。现在把信息整理成一份伪代码然后在真实环境里去验证这套还原是否正确。这个过程是逆向里最容易出错也最需要耐心的地方我建议一定不要跳过验证直接写报告。4.1 把动态观测到的参数表整理成伪代码整理后的签名算法逻辑如下基于分析结果还原的协议语义等价描述并非原始实现代码import hashlib import time from Crypto.Cipher import AES SECRET_SALT xTengSign_SALT_v2 def sign_request(params: dict, token: str): # 第一步参数拼接 盐 ts str(int(time.time() * 1000)) parts [params.get(uid, ), params.get(roomid, ), ts, SECRET_SALT] raw .join(parts) # 第二步SHA256摘要 digest hashlib.sha256(raw.encode()).hexdigest() # 第三步取token的MD5前16字节作为AES密钥 key hashlib.md5(token.encode()).hexdigest()[:16].encode() # 第四步AES-256-ECB加密摘要 cipher AES.new(key, AES.MODE_ECB) sign cipher.encrypt(digest.encode().ljust(64, b\x00)) return sign.hex()有几件事要在这里说清楚某藤之恋的时间戳用的X-Ts字段参与拼接时是十进制字符串形式params的排序不是固定字典序而是固定顺序uid、roomid、ts、salt。这个顺序是怎么试出来的不是猜的是抓了几十组请求把时间戳、uid、roomid代入各种排列组合逐一验证签名结果。这也是签名还原的核心难点——顺序不对其他全白搭。4.2 服务端校验逻辑推断把请求签名还原出来了服务端的校验逻辑其实也能顺势猜个大概。从实际测试反应来看服务端至少做了三件事时间戳反重放X-Ts与服务器当前时间相差超过5分钟直接拒绝错误码是固定的一串签名完整性校验服务端用同样的参数顺序重新计算签名比对不一致就返回业务错误设备绑定校验Zz-Token与设备标识绑定同一账号在不同设备间登录会挤出前者。推断服务端逻辑对逆向者来说很有用因为这意味着就算你改了X-Ts为合法值但签名没跟上照样过不去。所以在写自动化脚本时签名的实时性必须保证时间一长就失效。4.3 验证还原正确性的三个步骤还原正确与否不能靠肉眼看。我建议做下面三个步骤尤其是第一步如果做不通后面的就别提了第一步离线重建。打开抓包工具随便抓一串正常请求把里面的原始参数、时间戳、token全部拿到用自己写的伪代码跑一遍签名对比抓包里的X-Sign是否一致。这一步能完成基本说明算法结构、拼接顺序、密钥方案全对了。第二步在线验证。在测试账号下用伪代码生成签名拼一个完整的请求发给服务端看能否拿到和正常请求一样的业务响应。这里建议用一个完全没有业务意义的、已废弃的测试接口来做避免影响线上数据。第三步变体测试。故意把业务参数改掉但签名保持原样发出去看服务端是否拒绝。如果拒绝说明参数确实参与了签名如果不拒绝说明服务端可能根本没校验业务参数只校验了时间戳——这种情况下前面的算法还原意义就要打折扣了。我在某藤之恋上做的结果是三步全部通过。签名算法还原正确服务端也确实做了校验。到这里分析工作基本完成但随之而来的问题是这套加密链路到底能扛住多大强度的攻击5. 反调试、越狱检测与加固对抗别以为拿到包就万事大吉逆向分析不只是算法还原还有一堆乱七八糟的“环境问题”要处理。某藤之恋虽然算法简单但开发者在设备环境上做的安全措施还不少典型的就是越狱检测和反调试。5.1 打开App直接崩溃越狱检测是怎么回事我在越狱设备上安装App后启动不到两秒就闪退怎么看都像是“检测到越狱环境直接退出”。定位越狱检测点首先是看崩溃日志。某藤之恋崩溃日志里出现了access(/Applications/Cydia.app)很明显是文件路径检测。常见的越狱检测点就那几类检测方式原理常见标识文件路径检测检查越狱工具安装后的路径是否存在/Applications/Cydia.app、/bin/bash环境变量检测检查特定进程环境变量DYLD_INSERT_LIBRARIES沙盒逃逸检测尝试写系统分区外的路径fork()access()组合绕过的方式是在动态库加载之前就hook住检测函数比如用Frida的早期注入模式在access或stat返回前改成“文件不存在”。这里不详细展开绕过代码的编写重点在于理解它的套路越狱检测本质上就是一堆文件路径和系统调用的检查知道它查什么就知道怎么对症下药。5.2 断点一打就崩溃反调试机制ptrace/sysctl即使越狱检测被绕过了调试器还是会触发反调试。某藤之恋在启动阶段调用了ptrace(PT_DENY_ATTACH)这是iOS上最老牌的反调试手法。原理是进程主动拒绝调试器附加一旦有调试器试图attach进程直接崩溃或退出。ptrace对抗之前先看符号。Mach-O的__TEXT段里如果有ptrace的导入符号那基本就是它了。处理思路是让ptrace的调用失效技术上要么在动态分析时hook掉这个函数要么在静态层面修改汇编指令跳过调用。但我自己的经验是非必要不要死磕反调试。如果只是做协议分析完全可以不附加调试器走“抓包日志黑盒测试”的非侵入式路线。某藤之恋这次我实际上就没有在调试器下跑完整流程而是用Frida的早期执行脚本做的hook这就够了。5.3 输出一份“协议与安全评估报告”整个分析最后落地的不是破解脚本而是一份“协议与安全评估报告”。内容包括请求签名算法结构与参数参与顺序密钥来源与硬编码盐值位置时间戳防重放窗口越狱检测与反调试机制的绕过方式服务端校验逻辑推断修复建议。报告里最核心的结论是这套加密链路只能防住改包脚本小子防不住有技术能力的逆向者。原因是密钥管理的根本问题——客户端持有的任何密钥最终都会被提取。这是所有客户端加密方案的天花板某藤之恋只是其中一个典型案例而已。6. 复盘与合规边界这个分析过程里最重要的三件事说了这么多技术细节最后复盘一下整件事。逆向分析看起来是技术活其实最考验的是边界感和判断力。有三件事我想拿出来单独说说。6.1 责任边界什么情况下能逆向iOS逆向是敏感操作不是所有情况都能做的。我这次之所以可以放开手脚分析是因为拿到了明确授权的测试环境且只用于协议理解与安全评估。如果你只是个普通用户想“破解”某款App获得额外权限那不在本文讨论范围内。我的建议是研究请求加密算法的正确姿势是站在防御者视角看攻击者如何思考然后告诉开发团队“你的防护哪里不行”。技术本身是中性的但用途必须选好方向。6.2 复盘发现这套加密链路能防住谁、防不住谁某藤之恋的加密设计在同类App里算中等偏上水平但层级很清晰能防住只会用改包工具的普通用户——他们不会算签名改了参数直接废能防住只会抓包的新手——他们看不懂密文更不知道时间戳和签名是联动的防不住有Frida实操经验的分析者——只要肯花时间算法的参数顺序和密钥来源都会被还原出来。结论很扎心客户端加密的目标从来不是“绝对安全”而是提高攻击成本、延长被攻破所需的时间。服务器端的风控模型才是最后一道防线。6.3 给开发者的启示如果是我重新设计这套防护如果某藤之恋的开发团队问我要修复建议我会给出以下三点第一密钥永不硬编码。签名密钥由服务端在登录后动态下发过期时间至少比session短这样就算攻击者提取到了一次性密钥也无法长期复用。第二引入时间戳和nonce防重放。现在已经有时间戳但缺少nonce随机数。服务端可以针对timestamp nonce sign做幂等校验同一条签名只允许用一次。这会大大增加自动化脚本的编写难度。第三敏感接口要做服务端行为风控。单一请求的签名可以还原但请求频率、操作序列、设备指纹这些行为特征很难伪造。服务端一旦检测到异常节奏直接吊销Zz-Token迫使攻击者重新走登录流程。个人实际测试中的体会是安全防护要做到“内功”扎实而不能只做表面功夫。某藤之恋这个案例里开发者花了心思但核心密钥管理没跟上最后的结果就是密码学算法层面对安全架构层面脆弱。这类问题在现网App里非常普遍也是客户端安全测试中最高频的洞察点。如果你也正在研究一款App的请求加密记住我上面说的三个验证步骤和“非侵入式优先”的思路能帮你少走很多弯路。别一上来就想着绕过反调试先把算法本身吃透后面的事情自然水到渠成。