1. 项目概述逆向分析移动端API加密的实战路径在移动应用安全研究和逆向工程领域破解网络请求中的加密参数一直是个核心且极具挑战性的课题。无论是出于安全审计、协议分析还是技术学习的目的理解应用如何保护其数据传输都至关重要。最近我针对一个具体的实战目标——某麦网的移动端应用完成了一次从抓包到逆向的完整分析。这个案例的特殊性在于它同时涉及了iOS和Android两个平台为我们提供了一个绝佳的对比学习机会来观察同一套业务逻辑在不同系统架构下的实现差异与共性。整个逆向过程的核心工具链是Frida特别是其强大的动态追踪组件frida-trace。与传统的静态分析或盲目的Hook尝试不同frida-trace允许我们以极低的认知成本快速、精准地定位到生成特定加密参数如常见的sign、token、x-sign等的关键函数。再结合对调用栈Call Stack的深入分析我们就能像侦探一样层层回溯理清加密算法的输入、处理和输出全流程。这篇文章我将以这次双端实战为蓝本详细拆解每一步操作、每一个决策背后的思考并分享那些在官方文档里找不到的“踩坑”经验和调试技巧。无论你是刚接触Frida的新手还是希望提升动态分析效率的老手相信都能从中获得直接的参考。2. 逆向工程核心思路与工具选型2.1 为什么选择Frida-trace作为突破口在逆向加密逻辑时我们常面临一个困境目标应用可能混淆严重、代码庞大静态分析如同大海捞针。而盲目地Hook系统函数或大量可疑的类方法又效率低下且容易迷失方向。frida-trace的价值就在于它提供了一种“由果溯因”的高效路径。我们的起点通常是抓包工具如Charles、Fiddler或mitmproxy捕获到的加密参数。我们知道这个参数的值结果但不知道它是如何计算出来的过程。frida-trace的核心功能是追踪函数调用。我们可以让它追踪所有包含特定关键词如“sign”、“encrypt”、“md5”、“aes”的函数名。当应用运行并触发网络请求时frida-trace会自动在匹配的函数入口和出口插入桩代码Stub打印出调用参数和返回值。这相当于在加密函数周围安装了监控探头我们能直接看到哪些函数被调用了输入是什么输出又是什么。这种方法比静态分析更直接比手动写Hook脚本更快速尤其适合在未知代码结构中快速定位目标。注意frida-trace本质上是一个自动化生成Frida Hook脚本并执行追踪的命令行工具。它生成的JavaScript脚本位于/__handlers__/目录下我们可以直接修改这些脚本来定制输出格式、打印更复杂的数据类型如对象、数组这是后续深度分析的关键。2.2 调用栈分析还原算法执行上下文仅仅定位到加密函数还不够。一个加密参数比如sign的生成往往不是单个函数的功劳而是一个函数调用链协同工作的结果。它可能涉及对请求参数Query、Body的排序、拼接、添加时间戳或固定盐值Salt然后再进行哈希如MD5、SHA256或加密如AES、RSA。调用栈分析就是用来还原这个完整链条的。当我们通过frida-trace定位到最终输出加密值的函数A后下一步就是分析是谁调用了A父函数以及A又调用了哪些子函数。通过打印并分析调用栈我们可以确定关键数据流向上追溯找到加密原材料的来源即哪些请求参数被用于计算。理解控制流了解在何种业务条件下如登录、查询、下单会触发这条加密路径。识别辅助函数找到负责参数预处理排序、拼接、编码的函数以及可能存在的密钥管理函数。在Frida中我们可以通过Thread.backtrace()或DebugSymbol.fromAddress()等API来获取和解析调用栈信息。将调用栈信息与frida-trace的动态输出结合就能绘制出一幅清晰的加密算法执行地图。2.3 双端分析的必要性与挑战选择iOS和Android双端同时分析并非为了炫技而是有深刻的实践意义交叉验证同一家公司的同一业务其核心加密逻辑在两端通常是相同或高度相似的。在Android端分析得到的算法如拼接规则、哈希类型可以立刻到iOS端去验证反之亦然。这能极大提高逆向的准确性和效率。规避加固一个平台的应用可能使用了更强的加固或混淆方案如iOS的代码混淆、Android的VMP加固导致分析受阻。此时另一个防护相对薄弱的平台就可能成为突破口。先易后难是逆向工程的实用策略。理解平台差异加密算法的核心可能一致但实现方式会因平台而异。例如在AndroidJava/Kotlin中可能是一个类的静态方法在iOSObjective-C/Swift中可能是一个C函数或某个Framework的方法。通过双端对比能加深对移动端安全实现的理解。当然挑战也是并存的。你需要同时熟悉两套工具链Android的ADB、Frida Android ServeriOS的越狱环境、Frida iOS Server或使用corellium等模拟器。两端的调试符号、函数命名规范也完全不同需要一定的经验来适应。3. 前期准备与环境搭建3.1 抓包与关键参数识别一切逆向工作的起点都是数据。首先我们需要捕获应用的真实网络请求。抓包工具配置在电脑上配置好Charles或mitmproxy并安装其CA证书到测试手机无论是Android还是iOS。确保手机的网络代理指向你的电脑并能够成功拦截和解密HTTPS流量对于证书绑定强的App可能需要额外的绕过手段如JustTrustMe模块这是后话。触发目标请求打开某麦网App进行目标操作例如搜索一场演出、点击购买按钮。在抓包工具中过滤出与该操作相关的域名请求。定位加密参数仔细检查请求的URL参数Query String和请求体Request Body通常是JSON或Form格式。寻找那些看起来随机、无规律的长字符串参数常见的命名有sign、signature、token、x-s、encrypt、_st等。将其值记录下来同时完整记录下本次请求的所有其他参数和值这些很可能都是加密算法的“原材料”。3.2 Frida环境部署这是动态分析的核心。Android端在电脑上安装Fridapip install frida-tools。在已Root的Android测试机或模拟器上下载并运行对应架构的frida-server。通过ADB推送并启动adb shell /data/local/tmp/frida-server 。使用frida-ps -U命令检查是否能列出设备上的进程确认连接成功。iOS端需要一台越狱的iOS设备。在Cydia中添加Frida源并安装Frida。在电脑上同样安装frida-tools。通过USB连接设备使用frida-ps -U验证连接。对于非越狱环境理论上可以通过frida-core集成到自定义应用中实现但复杂度极高实战中越狱设备是首选。3.3 目标应用状态确认在开始追踪前需要明确分析对象。获取包名/进程名Android:adb shell pm list packages | grep damai或直接在应用管理界面查看。iOS: 可以通过frida-ps -U查看运行的应用列表或使用ps -A命令在终端中查找。启动应用确保应用处于可调试状态。对于Android如果应用有反调试可能需要先使用frida -U -f com.xxx.damai --no-pause来绕过后再操作。对于iOS越狱后默认支持调试。4. 使用Frida-trace进行动态追踪4.1 制定追踪策略与命令根据抓包结果我们假设关键的加密参数名为sign。我们的策略是追踪所有可能与签名相关的函数。宽泛搜索缩小范围首先使用包含“sign”关键词的宽泛追踪观察在发起网络请求时哪些模块被激活。# Android 示例 (Java层) frida-trace -U -j *!*sign* com.damai # iOS 示例 (Objective-C层) frida-trace -U -m *[* *ign*] DamaiApp这个命令会追踪所有类名或方法名中包含“sign”的Java方法或Objective-C方法。启动命令后操作App触发一次网络请求观察控制台输出。你会看到大量函数被调用其中一些在请求发生时被频繁调用这些就是我们的初级目标。精准定位聚焦核心如果宽泛搜索输出太多可以结合其他关键词如“encrypt”、“md5”、“sha”、“aes”、“crypto”等进行组合或分别追踪。也可以尝试追踪特定包名下的类例如Android端某麦网可能使用了自己的安全SDK包名可能包含security、network、utils等。# 追踪特定包下的所有方法 frida-trace -U -j com.damai.security.* com.damai4.2 分析trace输出并定位关键函数frida-trace会为每个被追踪的函数生成一个.js文件在__handlers__目录下并实时打印调用日志。日志通常包括Enter: 函数进入时的参数。Leave: 函数退出时的返回值。我们的任务是像看流水账一样找到那个“输入”是原始请求参数或接近原始参数“输出”正好等于我们抓包看到的sign值的函数。这个过程需要耐心和一点运气。通常你会看到一串函数调用其中一个函数的输出会作为另一个函数的输入层层传递。实操心得不要只看最后一个输出sign的函数。很多时候最后一个函数只是一个标准的哈希函数如MD5.update().digest()。真正关键的逻辑在于它之前的那个函数这个函数负责将原始参数拼接成一个特定的字符串。找到这个“拼接函数”才是破解加密算法的关键。在trace日志中关注那些输入参数是JSON对象、Map或字符串数组输出是一个长字符串的函数。4.3 修改Handler脚本深化分析默认的trace输出可能信息不全比如对象参数只显示[object Object]。这时就需要修改自动生成的Handler脚本。找到对应关键函数的.js文件路径类似__handlers__/com.damai.security.SignUtils.generateSign.js。编辑该文件。Frida的Handler脚本结构很简单主要修改onEnter和onLeave函数。// 示例修改后的Handler打印更详细的信息 onEnter: function (log, args, state) { log(generateSign() 被调用); // 打印第一个参数假设是Map类型 if (args[0]) { try { var paramMap args[0]; var keys paramMap.keySet().toArray(); var values paramMap.values().toArray(); log(参数Map内容:); for (var i 0; i keys.length; i) { log( keys[i] : values[i]); } } catch(e) { log(解析参数出错: e); } } // 打印调用栈非常重要 log(调用栈:); console.log(Thread.backtrace(this.context, Backtracer.ACCURATE) .map(DebugSymbol.fromAddress).join(\n)); }, onLeave: function (log, retval, state) { log(generateSign() 返回值: retval); // 可以将返回值与抓包的sign对比 }保存脚本frida-trace会自动重载。再次触发请求你就能看到更丰富的参数细节和调用栈信息。5. 调用栈分析与算法还原5.1 解读调用栈信息调用栈信息是一串内存地址或函数名。我们需要利用Frida的DebugSymbolAPI将其解析为可读的函数名。 在修改的Handler中打印的调用栈从上到下显示了从当前函数回溯到最外层调用者的路径。例如0x12345678 generateSign 0x23456789 buildRequestParams 0x34567890 NetworkManager.doSendRequest ...这个栈告诉我们NetworkManager.doSendRequest调用了buildRequestParams来构建请求参数而buildRequestParams又调用了generateSign来生成签名。那么buildRequestParams这个函数就非常值得关注因为它很可能负责收集和准备所有需要签名的参数。5.2 回溯数据流与定位核心逻辑通过分析多个相关函数的调用栈和输入输出我们可以逐步拼凑出完整的算法确定输入源从generateSign向上看它的参数来自哪里是buildRequestParams传递过来的一个Map。那么这个Map里的键值对又是从哪里来的继续向上追溯可能会发现它们来自UI输入、本地缓存、设备信息如IMEI、Android ID以及服务器下发的令牌等。分析参数处理在参数到达加密函数前是否经过了排序是否添加了固定字符串或时间戳我们可以通过HookbuildRequestParams函数打印其返回值即准备交给generateSign的完整参数Map并与最终网络请求中的参数进行对比找出差异。差异部分就是加密前的最后处理逻辑。验证算法当我们推测出算法可能是“将所有参数按Key排序后用和拼接成字符串末尾加上一个固定盐值最后做MD5”之后就需要写一个独立的验证脚本。用Python或JavaScript实现这个算法输入抓包到的原始参数除去sign本身计算出的结果是否与抓包到的sign一致。如果在iOS和Android两端用同一套算法计算都能得到正确结果那么恭喜你核心算法已经破解。5.3 双端对比验证这是确保算法正确性的关键一步。分别获取两端的原始请求数据在相同操作下如查询同一场演出分别抓取Android和iOS的请求包。对比请求参数除了sign其他参数是否完全相同通常会有一些平台特有的参数如os_type、app_version构建号等。这些差异点必须纳入你的算法考虑。应用同一算法将你逆向出来的算法例如参数排序拼接盐值MD5分别用两端的参数注意处理平台特有参数进行计算。校验结果计算出的sign值是否分别与两端抓包到的sign值匹配如果都匹配算法基本无误。如果只有一端匹配说明算法中可能还有未发现的平台相关分支逻辑需要回到trace步骤专门对比两端的函数调用链差异。6. 编写完整Hook脚本与算法复现6.1 从Trace到独立Hook脚本frida-trace适合探索但最终我们需要一个干净、独立的Frida脚本以便持续监控或集成到其他工具中。根据之前找到的关键函数地址或类名方法名编写一个完整的脚本。// damai_sign_hook.js Java.perform(function () { // 假设我们定位到的关键类是 com.damai.security.SignHelper var SignHelper Java.use(com.damai.security.SignHelper); // Hook 生成签名的方法 SignHelper.generateSign.implementation function (paramMap, timestamp, secret) { console.log([] generateSign 被调用); console.log(参数Map:); var iterator paramMap.keySet().iterator(); while (iterator.hasNext()) { var key iterator.next(); var value paramMap.get(key); console.log( key value); } console.log(时间戳: timestamp); console.log(密钥: secret); // 调用原方法获取结果 var originalSign this.generateSign(paramMap, timestamp, secret); console.log(原始签名结果: originalSign); // 在这里可以插入我们自己的算法进行验证 // var mySign myCustomAlgorithm(paramMap, timestamp, secret); // console.log(计算签名结果: mySign); // if (mySign ! originalSign) { // console.warn(签名不一致); // } // 打印调用栈 console.log(Java.use(android.util.Log).getStackTraceString(Java.use(java.lang.Exception).$new())); return originalSign; // 返回原结果不影响App运行 }; });使用frida -U -l damai_sign_hook.js -f com.damai来注入这个脚本。6.2 算法复现与离线签名生成逆向的最终目的是能够脱离原应用独立生成有效的签名。我们将分析得到的算法用Python实现import hashlib import time import urllib.parse def generate_damai_sign(params, secret_key): 根据逆向结果模拟签名生成 params: dict, 请求参数不包含sign本身 secret_key: str, 从代码中逆向得到的固定盐值或密钥 # 1. 参数排序按Key字母序 sorted_keys sorted(params.keys()) # 2. 拼接成 key1value1key2value2 的格式 query_string .join([f{k}{params[k]} for k in sorted_keys]) # 3. 在末尾拼接密钥 string_to_sign query_string secret_key # 4. 计算MD5注意编码通常为UTF-8 m hashlib.md5() m.update(string_to_sign.encode(utf-8)) return m.hexdigest().lower() # 常见的是小写hex # 示例使用 my_params { api: mtop.damai.wireless.search.broadcast.list, appKey: 12574478, data: {key:周杰伦,cityId:110100}, t: str(int(time.time() * 1000)), v: 1.0 } secret xxxxx # 替换为逆向得到的真实密钥 signature generate_damai_sign(my_params, secret) print(f生成的签名: {signature})将这个Python计算出的签名与抓包到的签名进行比对不断调整算法细节例如是否需要对data这个JSON字符串进行URL编码时间戳的格式是毫秒还是秒拼接时是否有多余的空格直到完全一致。7. 常见问题、踩坑记录与排查技巧7.1 Frida-trace无输出或进程崩溃问题运行frida-trace后目标应用闪退或trace没有任何输出。排查应用反调试这是最常见的原因。应用可能检测到Frida或调试状态。可以尝试使用-f参数在应用启动时即注入或使用反反调试插件如frida-unpack、anti-frida脚本的绕过方案。对于Android可以检查android:debuggable属性或使用frida的--no-pause选项。架构不匹配确保设备上运行的frida-server与目标应用的架构arm, arm64, x86匹配。使用adb shell getprop ro.product.cpu.abi查看。关键词不匹配Java方法名是“混淆”后的可能不包含“sign”等常见词。尝试使用更宽泛的通配符*或者先Hook一些基础函数如java.security.MessageDigest.getInstance来观察。权限问题确保设备已RootAndroid或越狱iOS并且frida-server以root权限运行。7.2 调用栈无法解析或显示为地址问题打印的调用栈是一堆0x12345678的地址没有函数名。解决确保在Hook脚本中正确使用了DebugSymbol.fromAddress()。Android应用可能剥离了符号表。可以尝试从调试版本APK或匹配的oat/art文件中获取符号信息但这非常复杂。更实用的方法是结合静态分析工具如Ghidra, IDA, JADX查看对应地址附近的代码进行人工推断。对于iOS如果是从App Store下载的App符号也是被剥离的。越狱后可以通过Cydia Substrate或Frida的ApiResolver尝试解析但效果有限。通常需要依赖已知的Objective-C运行时信息。7.3 算法看似正确但签名不匹配问题按照分析的步骤实现的算法计算结果总是和抓包到的sign对不上。排查步骤编码问题这是最大的坑检查每一步字符串拼接的编码。是UTF-8还是GBKMD5的输入是字符串的字节string.encode(utf-8)还是直接Hex在Hook脚本中打印关键字符串的字节数组bytes进行比对。隐藏参数是否有参数来自本地存储、系统属性或加密文件在抓包时看不到但在代码中被加入了计算Hook参数准备函数打印其最终输出的完整Map。顺序问题参数排序规则是否理解有误是按字母序ASCII还是字典序大小写敏感吗时间戳同步签名算法通常包含时间戳t或timestamp。确保你生成签名时使用的时间戳与发送请求时的时间戳是一致的。网络延迟可能导致微小差异。可以在Hook中打印出用于计算签名的时间戳值。多阶段加密是否不是简单的哈希而是先哈希再对结果进行二次处理如Base64、截取部分字符、再次加密密钥动态获取secret_key可能不是硬编码的而是从服务器动态获取或由其他算法生成。需要追溯这个密钥的来源。7.4 双端算法不一致问题Android端逆向出的算法无法用于iOS端。解决确认核心是否一致分别对两端的generateSign函数输入相同的参数通过Hook强制注入看输出是否相同。如果不同说明核心算法确实不同。查找平台适配层可能存在一个统一的算法核心比如C库或跨平台代码两端只是调用方式不同。尝试在两端搜索相同的字符串常量如盐值、魔术数字或特征码。接受差异有时公司可能为不同平台部署了不同的加密策略。这就需要分别逆向两套算法。但通常业务逻辑的统一性会促使他们使用同一套核心。7.5 应对HTTPS证书绑定SSL Pinning问题抓包工具无法解密某麦网的HTTPS流量显示TLS handshake failed。解决方案这是另一个常见障碍。需要使用工具绕过SSL Pinning。Android使用JustTrustMe或SSLUnpinning等Frida脚本Hook掉证书验证相关的类如TrustManager、SSLContext。在Frida中加载这些脚本即可。iOS可以使用SSL Kill Switch 2Cydia插件或对应的Frida脚本如ios-ssl-bypass来禁用证书绑定。 绕过后抓包工具才能看到明文的请求和响应这是进行API分析的前提。整个逆向过程就像一场耐心的狩猎需要观察、推理、验证、再观察。工具Frida-trace给了我们敏锐的感官而调用栈分析和对业务逻辑的理解则构成了我们的大脑。当你在双端都成功复现出那个神秘的sign值时那种透过层层迷雾看清系统脉络的成就感正是逆向工程最大的乐趣所在。记住每一次失败和排查都是对技术理解的加深。
1. 项目概述逆向分析移动端API加密的实战路径在移动应用安全研究和逆向工程领域破解网络请求中的加密参数一直是个核心且极具挑战性的课题。无论是出于安全审计、协议分析还是技术学习的目的理解应用如何保护其数据传输都至关重要。最近我针对一个具体的实战目标——某麦网的移动端应用完成了一次从抓包到逆向的完整分析。这个案例的特殊性在于它同时涉及了iOS和Android两个平台为我们提供了一个绝佳的对比学习机会来观察同一套业务逻辑在不同系统架构下的实现差异与共性。整个逆向过程的核心工具链是Frida特别是其强大的动态追踪组件frida-trace。与传统的静态分析或盲目的Hook尝试不同frida-trace允许我们以极低的认知成本快速、精准地定位到生成特定加密参数如常见的sign、token、x-sign等的关键函数。再结合对调用栈Call Stack的深入分析我们就能像侦探一样层层回溯理清加密算法的输入、处理和输出全流程。这篇文章我将以这次双端实战为蓝本详细拆解每一步操作、每一个决策背后的思考并分享那些在官方文档里找不到的“踩坑”经验和调试技巧。无论你是刚接触Frida的新手还是希望提升动态分析效率的老手相信都能从中获得直接的参考。2. 逆向工程核心思路与工具选型2.1 为什么选择Frida-trace作为突破口在逆向加密逻辑时我们常面临一个困境目标应用可能混淆严重、代码庞大静态分析如同大海捞针。而盲目地Hook系统函数或大量可疑的类方法又效率低下且容易迷失方向。frida-trace的价值就在于它提供了一种“由果溯因”的高效路径。我们的起点通常是抓包工具如Charles、Fiddler或mitmproxy捕获到的加密参数。我们知道这个参数的值结果但不知道它是如何计算出来的过程。frida-trace的核心功能是追踪函数调用。我们可以让它追踪所有包含特定关键词如“sign”、“encrypt”、“md5”、“aes”的函数名。当应用运行并触发网络请求时frida-trace会自动在匹配的函数入口和出口插入桩代码Stub打印出调用参数和返回值。这相当于在加密函数周围安装了监控探头我们能直接看到哪些函数被调用了输入是什么输出又是什么。这种方法比静态分析更直接比手动写Hook脚本更快速尤其适合在未知代码结构中快速定位目标。注意frida-trace本质上是一个自动化生成Frida Hook脚本并执行追踪的命令行工具。它生成的JavaScript脚本位于/__handlers__/目录下我们可以直接修改这些脚本来定制输出格式、打印更复杂的数据类型如对象、数组这是后续深度分析的关键。2.2 调用栈分析还原算法执行上下文仅仅定位到加密函数还不够。一个加密参数比如sign的生成往往不是单个函数的功劳而是一个函数调用链协同工作的结果。它可能涉及对请求参数Query、Body的排序、拼接、添加时间戳或固定盐值Salt然后再进行哈希如MD5、SHA256或加密如AES、RSA。调用栈分析就是用来还原这个完整链条的。当我们通过frida-trace定位到最终输出加密值的函数A后下一步就是分析是谁调用了A父函数以及A又调用了哪些子函数。通过打印并分析调用栈我们可以确定关键数据流向上追溯找到加密原材料的来源即哪些请求参数被用于计算。理解控制流了解在何种业务条件下如登录、查询、下单会触发这条加密路径。识别辅助函数找到负责参数预处理排序、拼接、编码的函数以及可能存在的密钥管理函数。在Frida中我们可以通过Thread.backtrace()或DebugSymbol.fromAddress()等API来获取和解析调用栈信息。将调用栈信息与frida-trace的动态输出结合就能绘制出一幅清晰的加密算法执行地图。2.3 双端分析的必要性与挑战选择iOS和Android双端同时分析并非为了炫技而是有深刻的实践意义交叉验证同一家公司的同一业务其核心加密逻辑在两端通常是相同或高度相似的。在Android端分析得到的算法如拼接规则、哈希类型可以立刻到iOS端去验证反之亦然。这能极大提高逆向的准确性和效率。规避加固一个平台的应用可能使用了更强的加固或混淆方案如iOS的代码混淆、Android的VMP加固导致分析受阻。此时另一个防护相对薄弱的平台就可能成为突破口。先易后难是逆向工程的实用策略。理解平台差异加密算法的核心可能一致但实现方式会因平台而异。例如在AndroidJava/Kotlin中可能是一个类的静态方法在iOSObjective-C/Swift中可能是一个C函数或某个Framework的方法。通过双端对比能加深对移动端安全实现的理解。当然挑战也是并存的。你需要同时熟悉两套工具链Android的ADB、Frida Android ServeriOS的越狱环境、Frida iOS Server或使用corellium等模拟器。两端的调试符号、函数命名规范也完全不同需要一定的经验来适应。3. 前期准备与环境搭建3.1 抓包与关键参数识别一切逆向工作的起点都是数据。首先我们需要捕获应用的真实网络请求。抓包工具配置在电脑上配置好Charles或mitmproxy并安装其CA证书到测试手机无论是Android还是iOS。确保手机的网络代理指向你的电脑并能够成功拦截和解密HTTPS流量对于证书绑定强的App可能需要额外的绕过手段如JustTrustMe模块这是后话。触发目标请求打开某麦网App进行目标操作例如搜索一场演出、点击购买按钮。在抓包工具中过滤出与该操作相关的域名请求。定位加密参数仔细检查请求的URL参数Query String和请求体Request Body通常是JSON或Form格式。寻找那些看起来随机、无规律的长字符串参数常见的命名有sign、signature、token、x-s、encrypt、_st等。将其值记录下来同时完整记录下本次请求的所有其他参数和值这些很可能都是加密算法的“原材料”。3.2 Frida环境部署这是动态分析的核心。Android端在电脑上安装Fridapip install frida-tools。在已Root的Android测试机或模拟器上下载并运行对应架构的frida-server。通过ADB推送并启动adb shell /data/local/tmp/frida-server 。使用frida-ps -U命令检查是否能列出设备上的进程确认连接成功。iOS端需要一台越狱的iOS设备。在Cydia中添加Frida源并安装Frida。在电脑上同样安装frida-tools。通过USB连接设备使用frida-ps -U验证连接。对于非越狱环境理论上可以通过frida-core集成到自定义应用中实现但复杂度极高实战中越狱设备是首选。3.3 目标应用状态确认在开始追踪前需要明确分析对象。获取包名/进程名Android:adb shell pm list packages | grep damai或直接在应用管理界面查看。iOS: 可以通过frida-ps -U查看运行的应用列表或使用ps -A命令在终端中查找。启动应用确保应用处于可调试状态。对于Android如果应用有反调试可能需要先使用frida -U -f com.xxx.damai --no-pause来绕过后再操作。对于iOS越狱后默认支持调试。4. 使用Frida-trace进行动态追踪4.1 制定追踪策略与命令根据抓包结果我们假设关键的加密参数名为sign。我们的策略是追踪所有可能与签名相关的函数。宽泛搜索缩小范围首先使用包含“sign”关键词的宽泛追踪观察在发起网络请求时哪些模块被激活。# Android 示例 (Java层) frida-trace -U -j *!*sign* com.damai # iOS 示例 (Objective-C层) frida-trace -U -m *[* *ign*] DamaiApp这个命令会追踪所有类名或方法名中包含“sign”的Java方法或Objective-C方法。启动命令后操作App触发一次网络请求观察控制台输出。你会看到大量函数被调用其中一些在请求发生时被频繁调用这些就是我们的初级目标。精准定位聚焦核心如果宽泛搜索输出太多可以结合其他关键词如“encrypt”、“md5”、“sha”、“aes”、“crypto”等进行组合或分别追踪。也可以尝试追踪特定包名下的类例如Android端某麦网可能使用了自己的安全SDK包名可能包含security、network、utils等。# 追踪特定包下的所有方法 frida-trace -U -j com.damai.security.* com.damai4.2 分析trace输出并定位关键函数frida-trace会为每个被追踪的函数生成一个.js文件在__handlers__目录下并实时打印调用日志。日志通常包括Enter: 函数进入时的参数。Leave: 函数退出时的返回值。我们的任务是像看流水账一样找到那个“输入”是原始请求参数或接近原始参数“输出”正好等于我们抓包看到的sign值的函数。这个过程需要耐心和一点运气。通常你会看到一串函数调用其中一个函数的输出会作为另一个函数的输入层层传递。实操心得不要只看最后一个输出sign的函数。很多时候最后一个函数只是一个标准的哈希函数如MD5.update().digest()。真正关键的逻辑在于它之前的那个函数这个函数负责将原始参数拼接成一个特定的字符串。找到这个“拼接函数”才是破解加密算法的关键。在trace日志中关注那些输入参数是JSON对象、Map或字符串数组输出是一个长字符串的函数。4.3 修改Handler脚本深化分析默认的trace输出可能信息不全比如对象参数只显示[object Object]。这时就需要修改自动生成的Handler脚本。找到对应关键函数的.js文件路径类似__handlers__/com.damai.security.SignUtils.generateSign.js。编辑该文件。Frida的Handler脚本结构很简单主要修改onEnter和onLeave函数。// 示例修改后的Handler打印更详细的信息 onEnter: function (log, args, state) { log(generateSign() 被调用); // 打印第一个参数假设是Map类型 if (args[0]) { try { var paramMap args[0]; var keys paramMap.keySet().toArray(); var values paramMap.values().toArray(); log(参数Map内容:); for (var i 0; i keys.length; i) { log( keys[i] : values[i]); } } catch(e) { log(解析参数出错: e); } } // 打印调用栈非常重要 log(调用栈:); console.log(Thread.backtrace(this.context, Backtracer.ACCURATE) .map(DebugSymbol.fromAddress).join(\n)); }, onLeave: function (log, retval, state) { log(generateSign() 返回值: retval); // 可以将返回值与抓包的sign对比 }保存脚本frida-trace会自动重载。再次触发请求你就能看到更丰富的参数细节和调用栈信息。5. 调用栈分析与算法还原5.1 解读调用栈信息调用栈信息是一串内存地址或函数名。我们需要利用Frida的DebugSymbolAPI将其解析为可读的函数名。 在修改的Handler中打印的调用栈从上到下显示了从当前函数回溯到最外层调用者的路径。例如0x12345678 generateSign 0x23456789 buildRequestParams 0x34567890 NetworkManager.doSendRequest ...这个栈告诉我们NetworkManager.doSendRequest调用了buildRequestParams来构建请求参数而buildRequestParams又调用了generateSign来生成签名。那么buildRequestParams这个函数就非常值得关注因为它很可能负责收集和准备所有需要签名的参数。5.2 回溯数据流与定位核心逻辑通过分析多个相关函数的调用栈和输入输出我们可以逐步拼凑出完整的算法确定输入源从generateSign向上看它的参数来自哪里是buildRequestParams传递过来的一个Map。那么这个Map里的键值对又是从哪里来的继续向上追溯可能会发现它们来自UI输入、本地缓存、设备信息如IMEI、Android ID以及服务器下发的令牌等。分析参数处理在参数到达加密函数前是否经过了排序是否添加了固定字符串或时间戳我们可以通过HookbuildRequestParams函数打印其返回值即准备交给generateSign的完整参数Map并与最终网络请求中的参数进行对比找出差异。差异部分就是加密前的最后处理逻辑。验证算法当我们推测出算法可能是“将所有参数按Key排序后用和拼接成字符串末尾加上一个固定盐值最后做MD5”之后就需要写一个独立的验证脚本。用Python或JavaScript实现这个算法输入抓包到的原始参数除去sign本身计算出的结果是否与抓包到的sign一致。如果在iOS和Android两端用同一套算法计算都能得到正确结果那么恭喜你核心算法已经破解。5.3 双端对比验证这是确保算法正确性的关键一步。分别获取两端的原始请求数据在相同操作下如查询同一场演出分别抓取Android和iOS的请求包。对比请求参数除了sign其他参数是否完全相同通常会有一些平台特有的参数如os_type、app_version构建号等。这些差异点必须纳入你的算法考虑。应用同一算法将你逆向出来的算法例如参数排序拼接盐值MD5分别用两端的参数注意处理平台特有参数进行计算。校验结果计算出的sign值是否分别与两端抓包到的sign值匹配如果都匹配算法基本无误。如果只有一端匹配说明算法中可能还有未发现的平台相关分支逻辑需要回到trace步骤专门对比两端的函数调用链差异。6. 编写完整Hook脚本与算法复现6.1 从Trace到独立Hook脚本frida-trace适合探索但最终我们需要一个干净、独立的Frida脚本以便持续监控或集成到其他工具中。根据之前找到的关键函数地址或类名方法名编写一个完整的脚本。// damai_sign_hook.js Java.perform(function () { // 假设我们定位到的关键类是 com.damai.security.SignHelper var SignHelper Java.use(com.damai.security.SignHelper); // Hook 生成签名的方法 SignHelper.generateSign.implementation function (paramMap, timestamp, secret) { console.log([] generateSign 被调用); console.log(参数Map:); var iterator paramMap.keySet().iterator(); while (iterator.hasNext()) { var key iterator.next(); var value paramMap.get(key); console.log( key value); } console.log(时间戳: timestamp); console.log(密钥: secret); // 调用原方法获取结果 var originalSign this.generateSign(paramMap, timestamp, secret); console.log(原始签名结果: originalSign); // 在这里可以插入我们自己的算法进行验证 // var mySign myCustomAlgorithm(paramMap, timestamp, secret); // console.log(计算签名结果: mySign); // if (mySign ! originalSign) { // console.warn(签名不一致); // } // 打印调用栈 console.log(Java.use(android.util.Log).getStackTraceString(Java.use(java.lang.Exception).$new())); return originalSign; // 返回原结果不影响App运行 }; });使用frida -U -l damai_sign_hook.js -f com.damai来注入这个脚本。6.2 算法复现与离线签名生成逆向的最终目的是能够脱离原应用独立生成有效的签名。我们将分析得到的算法用Python实现import hashlib import time import urllib.parse def generate_damai_sign(params, secret_key): 根据逆向结果模拟签名生成 params: dict, 请求参数不包含sign本身 secret_key: str, 从代码中逆向得到的固定盐值或密钥 # 1. 参数排序按Key字母序 sorted_keys sorted(params.keys()) # 2. 拼接成 key1value1key2value2 的格式 query_string .join([f{k}{params[k]} for k in sorted_keys]) # 3. 在末尾拼接密钥 string_to_sign query_string secret_key # 4. 计算MD5注意编码通常为UTF-8 m hashlib.md5() m.update(string_to_sign.encode(utf-8)) return m.hexdigest().lower() # 常见的是小写hex # 示例使用 my_params { api: mtop.damai.wireless.search.broadcast.list, appKey: 12574478, data: {key:周杰伦,cityId:110100}, t: str(int(time.time() * 1000)), v: 1.0 } secret xxxxx # 替换为逆向得到的真实密钥 signature generate_damai_sign(my_params, secret) print(f生成的签名: {signature})将这个Python计算出的签名与抓包到的签名进行比对不断调整算法细节例如是否需要对data这个JSON字符串进行URL编码时间戳的格式是毫秒还是秒拼接时是否有多余的空格直到完全一致。7. 常见问题、踩坑记录与排查技巧7.1 Frida-trace无输出或进程崩溃问题运行frida-trace后目标应用闪退或trace没有任何输出。排查应用反调试这是最常见的原因。应用可能检测到Frida或调试状态。可以尝试使用-f参数在应用启动时即注入或使用反反调试插件如frida-unpack、anti-frida脚本的绕过方案。对于Android可以检查android:debuggable属性或使用frida的--no-pause选项。架构不匹配确保设备上运行的frida-server与目标应用的架构arm, arm64, x86匹配。使用adb shell getprop ro.product.cpu.abi查看。关键词不匹配Java方法名是“混淆”后的可能不包含“sign”等常见词。尝试使用更宽泛的通配符*或者先Hook一些基础函数如java.security.MessageDigest.getInstance来观察。权限问题确保设备已RootAndroid或越狱iOS并且frida-server以root权限运行。7.2 调用栈无法解析或显示为地址问题打印的调用栈是一堆0x12345678的地址没有函数名。解决确保在Hook脚本中正确使用了DebugSymbol.fromAddress()。Android应用可能剥离了符号表。可以尝试从调试版本APK或匹配的oat/art文件中获取符号信息但这非常复杂。更实用的方法是结合静态分析工具如Ghidra, IDA, JADX查看对应地址附近的代码进行人工推断。对于iOS如果是从App Store下载的App符号也是被剥离的。越狱后可以通过Cydia Substrate或Frida的ApiResolver尝试解析但效果有限。通常需要依赖已知的Objective-C运行时信息。7.3 算法看似正确但签名不匹配问题按照分析的步骤实现的算法计算结果总是和抓包到的sign对不上。排查步骤编码问题这是最大的坑检查每一步字符串拼接的编码。是UTF-8还是GBKMD5的输入是字符串的字节string.encode(utf-8)还是直接Hex在Hook脚本中打印关键字符串的字节数组bytes进行比对。隐藏参数是否有参数来自本地存储、系统属性或加密文件在抓包时看不到但在代码中被加入了计算Hook参数准备函数打印其最终输出的完整Map。顺序问题参数排序规则是否理解有误是按字母序ASCII还是字典序大小写敏感吗时间戳同步签名算法通常包含时间戳t或timestamp。确保你生成签名时使用的时间戳与发送请求时的时间戳是一致的。网络延迟可能导致微小差异。可以在Hook中打印出用于计算签名的时间戳值。多阶段加密是否不是简单的哈希而是先哈希再对结果进行二次处理如Base64、截取部分字符、再次加密密钥动态获取secret_key可能不是硬编码的而是从服务器动态获取或由其他算法生成。需要追溯这个密钥的来源。7.4 双端算法不一致问题Android端逆向出的算法无法用于iOS端。解决确认核心是否一致分别对两端的generateSign函数输入相同的参数通过Hook强制注入看输出是否相同。如果不同说明核心算法确实不同。查找平台适配层可能存在一个统一的算法核心比如C库或跨平台代码两端只是调用方式不同。尝试在两端搜索相同的字符串常量如盐值、魔术数字或特征码。接受差异有时公司可能为不同平台部署了不同的加密策略。这就需要分别逆向两套算法。但通常业务逻辑的统一性会促使他们使用同一套核心。7.5 应对HTTPS证书绑定SSL Pinning问题抓包工具无法解密某麦网的HTTPS流量显示TLS handshake failed。解决方案这是另一个常见障碍。需要使用工具绕过SSL Pinning。Android使用JustTrustMe或SSLUnpinning等Frida脚本Hook掉证书验证相关的类如TrustManager、SSLContext。在Frida中加载这些脚本即可。iOS可以使用SSL Kill Switch 2Cydia插件或对应的Frida脚本如ios-ssl-bypass来禁用证书绑定。 绕过后抓包工具才能看到明文的请求和响应这是进行API分析的前提。整个逆向过程就像一场耐心的狩猎需要观察、推理、验证、再观察。工具Frida-trace给了我们敏锐的感官而调用栈分析和对业务逻辑的理解则构成了我们的大脑。当你在双端都成功复现出那个神秘的sign值时那种透过层层迷雾看清系统脉络的成就感正是逆向工程最大的乐趣所在。记住每一次失败和排查都是对技术理解的加深。
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
