1. 项目概述与核心价值最近在分析一些移动端应用的数据交互时遇到了一个名为“考试宝”的应用。它的接口请求中携带了一个关键的sign参数这个参数显然是服务端用来校验请求合法性、防止数据篡改和重放攻击的核心。对于开发者、安全研究员或者对数据抓取有需求的朋友来说逆向分析这个sign的生成算法就像是拿到了一把打开数据大门的钥匙。这不仅能让你理解其背后的安全机制更能为后续的自动化数据获取、协议模拟或安全审计提供基础。今天我就把自己逆向分析“考试宝”sign的完整过程、思路和踩过的坑毫无保留地分享出来。整个过程不涉及任何敏感操作纯粹是技术原理的探究适合对移动端逆向、密码学应用感兴趣的中高级开发者参考。2. 逆向分析前的环境与工具准备工欲善其事必先利其器。逆向分析的第一步永远是搭建一个稳定、高效的作战环境。这里的选择直接决定了后续分析的效率和成功率。2.1 核心工具链选型与配置我的主力分析环境是一台 Windows 11 主机配合 Android 模拟器。为什么不直接用真机因为模拟器在动态调试、文件管理和快照恢复方面有巨大优势。我选择的是雷电模拟器9它基于 Android 9兼容性好并且Root权限获取简单。核心静态分析工具Jadx-GUI这是逆向 Android APK 的瑞士军刀。它能将 DEX 文件反编译成可读性极高的 Java 代码。对于快速理清代码结构、定位关键类和方法至关重要。我通常使用其“搜索”功能全局搜索关键词如 “sign”、“md5”、“sha”、“encrypt”等。GDA一款国产的 Android 逆向工具在反混淆方面有时有奇效。当 Jadx 反编译出的代码因为混淆而难以阅读时可以用 GDA 交叉验证它的某些反混淆算法能更好地恢复变量名和逻辑。Android Killer / APKDB用于 APK 的解包、打包和签名。在需要修改 Smali 代码或资源文件进行动态插桩时它们是必不可少的。核心动态分析工具Frida动态插桩框架的王者。它允许你在应用运行时注入自己的 JavaScript 脚本去 Hook挂钩任何 Java/Native 函数查看参数、修改返回值、追踪调用栈。这是破解加密算法的“终极武器”。Objection基于 Frida 的命令行工具可以快速实现内存搜索、绕过 SSL Pinning证书绑定等常见需求。对于快速评估应用防护等级非常有用。HttpCanary / Charles / Fiddler抓包工具。用于拦截和查看应用发出的网络请求直观地看到sign参数出现在哪个请求、哪个字段以及它的明文形态是怎样的。这是分析的起点。环境配置要点模拟器设置在雷电模拟器的设置中开启 Root 权限。安装 Frida-server 对应架构通常是 x86_64的版本到/data/local/tmp/并赋予执行权限。主机与模拟器连通使用adb connect 127.0.0.1:5555连接模拟器。确保adb devices能列出设备。Frida 环境在主机 Python 环境中安装frida-tools。运行frida-ps -U确认能列出模拟器上的进程表示 Frida 通道已打通。抓包证书安装将 Charles 或 Fiddler 的根证书导出拖入模拟器安装并设置为受信任的凭据以解密 HTTPS 流量。注意有些应用会检测模拟器或 Root 环境。如果遇到这种情况可能需要使用真机也需要Root或者寻找针对该模拟器的隐藏 Root 和模拟器特征的 Magisk 模块。在“考试宝”的分析中雷电9 未触发明显的环境检测。2.2 目标确认与初步抓包安装好“考试宝”的 APK 后首先启动抓包工具和 App。进行登录、查看题目列表等关键操作。很快在抓包工具中我发现了目标请求。例如一个获取试卷列表的接口GET /api/exam/list它的 URL 或者 Request Body 里包含了一个sign字段值是一长串看似随机的十六进制字符串像是某种哈希值。初步观察几个不同请求的sign发现它们长度固定比如32位或64位且同一操作重复请求时sign会变化但使用相同参数在短时间内请求sign可能相同。这提示我们sign很可能由“请求参数 时间戳 某种密钥”通过哈希算法如 MD5, SHA256生成并且可能加入了防重放的随机数nonce。3. 静态代码分析与入口定位有了抓包数据接下来就要在代码的海洋里找到生成这个sign的“工厂”。3.1 关键词搜索与代码定位将“考试宝”的 APK 用 Jadx-GUI 打开。首先进行全局搜索 (CtrlShiftF)。第一轮搜索直接搜索sign。结果可能非常多因为“签名”在 Android 中也是一个权限android.permission。需要过滤。我重点关注作为变量名、参数名出现的sign。在网络请求相关类如OkHttpClient拦截器、Retrofit接口定义、自定义的RequestInterceptor中出现的sign。字符串常量中包含sign的。第二轮搜索搜索常见的哈希算法类或方法名如MD5,MessageDigest,SHA-256,Hmac,DigestUtils(来自 Apache Commons Codec)encrypt,encode等。第三轮搜索搜索抓包看到的接口路径关键词如/api/exam/list找到对应的 API 接口定义顺藤摸瓜找到处理请求的类。在“考试宝”中通过搜索/api/我很快定位到了一个名为ApiService的接口类里面用 Retrofit 注解定义了各个网络请求。然后我寻找为 Retrofit 设置的OkHttpClient和其添加的拦截器Interceptor。通常sign的添加会在拦截器中统一处理。果然我找到了一个名为SignInterceptor的类。这就是我们的主战场。3.2. 核心算法初步还原打开SignInterceptor类它的intercept方法大致逻辑如下获取原始请求originalRequest。从originalRequest中获取请求方法GET/POST、URL、请求体如果有。从 URL 中提取查询参数从请求体中提取表单参数或 JSON 参数将它们全部放入一个 Map 中。对 Map 中的参数按照键名进行字典序排序。这是非常常见的防篡改手段确保参数顺序不影响最终签名。将排序后的键值对拼接成字符串格式通常是key1value1key2value2...。在这个字符串的首部或尾部拼接上一个固定的密钥secret。这个密钥是硬编码在代码中或者从某个配置接口获取的。在静态分析中我们首先寻找硬编码的。对拼接后的完整字符串调用某个方法比如MD5Util.encode(...)或HmacSHA256(...)进行计算。将计算得到的字节数组进行十六进制编码或 Base64得到最终的sign字符串。将这个sign作为一个新的查询参数添加到请求 URL 中或者放入请求头如X-Sign然后放行请求。至此算法的整体框架已经清晰。但关键点在于密钥Secret在哪里可能是一个明文字符串也可能是经过简单变换如 Base64 解码后的字符串。拼接的细节是什么键值对拼接时值是原样拼接还是经过了 URLEncode空值参数如何处理布尔值true/false是转成1/0还是字符串具体调用哪个哈希函数是 MD5、SHA1 还是 SHA256有没有进行多次哈希这些细节的差异会导致你计算出的sign与服务端计算的不匹配。必须 100% 还原。4. 动态调试与细节验证静态分析给出了蓝图但魔鬼在细节里。动态调试是验证和捕获这些细节的不二法门。4.1 使用 Frida 进行函数 Hook我编写了一个 Frida JavaScript 脚本主要目标是 Hook 那个关键的签名生成函数。假设在SignInterceptor中最终调用的是com.xxx.utils.CryptoUtils.getSign(Map params)这个方法。// frida_script.js Java.perform(function () { var CryptoUtils Java.use(com.xxx.utils.CryptoUtils); // Hook getSign 方法 CryptoUtils.getSign.overload(java.util.Map).implementation function (params) { console.log(\n[] getSign() called!); // 打印传入的参数 Map console.log([*] Input Params Map:); var iterator params.keySet().iterator(); while (iterator.hasNext()) { var key iterator.next(); var value params.get(key); console.log( key value); } // 调用原方法获取结果 var result this.getSign(params); console.log([*] Generated Sign: result); // 打印调用栈帮助理解调用链 console.log([*] Call Stack:); console.log(Java.use(android.util.Log).getStackTraceString(Java.use(java.lang.Exception).$new())); return result; }; // 如果发现拼接字符串的方法也Hook它 var SignHelper Java.use(com.xxx.utils.SignHelper); if (SignHelper.buildSignString) { SignHelper.buildSignString.implementation function (map) { var str this.buildSignString(map); console.log([*] Built Sign String: str); return str; }; } // Hook 常见的哈希函数作为辅助验证 var MessageDigest Java.use(java.security.MessageDigest); MessageDigest.getInstance.overload(java.lang.String).implementation function (algorithm) { console.log([*] MessageDigest.getInstance called with algorithm: algorithm); return this.getInstance(algorithm); }; });使用命令frida -U -f com.kaoshibao -l frida_script.js --no-pause启动应用并注入脚本。然后在 App 内触发一个网络请求如刷新列表。脚本输出会清晰显示传入getSign方法的参数 Map 具体内容包括每个键值对。这验证了我们从抓包中看到的参数是否齐全以及是否有隐藏参数如设备ID、时间戳。生成的sign值。我们可以立刻与抓包工具里看到的sign进行比对确认这个函数就是目标。调用栈告诉我们这个函数是被谁调用的有助于理解整个流程。如果 Hook 到了字符串拼接函数我们就能直接看到待哈希的原始字符串是什么样子。这是最关键的证据。4.2 关键细节的捕获与验证通过动态调试我发现了“考试宝”sign生成的几个关键细节这些是静态分析容易遗漏的时间戳与单位参数里有一个timestamp值是13位数字毫秒级Unix时间戳。服务端会校验这个时间戳如果与服务器时间相差太大如超过5分钟请求会被拒绝。随机数Nonce参数里还有一个nonce是一个较短的随机字符串可能是6-8位数字字母。它和timestamp一起用于防止重放攻击。同一个nonce在短时间内不能重复使用。参数排序与空值处理所有参数包括timestamp和nonce都参与排序和拼接。空值参数会被直接忽略不参与拼接。这是很多算法容易出错的地方。拼接格式拼接的字符串格式是key1value1key2value2secretxxxxxx。注意密钥secret是作为一个普通的键值对拼接在最后的而不是直接字符串相加。并且所有的value都是字符串形式布尔值true被转成了1。哈希算法通过 HookMessageDigest.getInstance确认了算法是MD5。并且是对拼接后的整个字符串进行一次性 MD5 计算。输出格式MD5 输出是16字节的二进制数据然后被转换成了32位小写的十六进制字符串。这就是我们最终看到的sign。至此算法已经完全清晰。我们可以用 Python 来模拟这个流程。5. 算法复现与Python实现基于动态分析的结果我们可以用 Python 完美复现sign的生成过程。import hashlib import time import random import string def generate_sign(params, secret): 根据考试宝的规则生成 sign :param params: dict, 所有的请求参数不包括sign本身 :param secret: str, 密钥 :return: str, 计算得到的sign # 1. 过滤空值参数 filtered_params {k: v for k, v in params.items() if v is not None and v ! } # 2. 参数按照键名 ASCII 码升序排序 sorted_items sorted(filtered_params.items(), keylambda x: x[0]) # 3. 拼接键值对值为字符串形式 # 注意布尔值 True/False 需要转换这里假设外部已处理好 sign_string_parts [] for key, value in sorted_items: # 确保value是字符串 str_value str(value) sign_string_parts.append(f{key}{str_value}) # 4. 拼接密钥 sign_string_parts.append(fsecret{secret}) # 5. 用 连接所有部分 sign_string .join(sign_string_parts) print(f[DEBUG] String to be hashed: {sign_string}) # 调试时打开 # 6. 计算 MD5 (32位小写) md5 hashlib.md5() md5.update(sign_string.encode(utf-8)) sign md5.hexdigest() return sign # 模拟一次请求 def mock_request(): # 假设的密钥实际应从反编译代码中获取 app_secret y0ur_53cr3t_k3y_h3r3 # 这只是示例真实密钥不同 # 构造请求参数 request_params { page: 1, size: 20, timestamp: int(time.time() * 1000), # 13位毫秒时间戳 nonce: .join(random.choices(string.ascii_letters string.digits, k8)), # 8位随机数 deviceId: 模拟设备ID123, # ... 其他业务参数 } sign generate_sign(request_params, app_secret) request_params[sign] sign # 将sign加入最终请求参数 print(fGenerated params with sign: {request_params}) return request_params if __name__ __main__: mock_request()运行这个脚本生成的sign与通过 Frida Hook 看到的结果以及实际抓包得到的结果进行比对。如果完全一致恭喜你逆向成功。6. 逆向过程中的难点与解决方案在实际操作中不可能总是一帆风顺。以下是几个常见的“坑”及我的应对策略。6.1 代码混淆与对抗“考试宝”的代码进行了一定程度的混淆。类名、方法名变成了a,b,c字符串常量也被加密。这增加了静态分析的难度。应对策略动态分析为主这正是 Frida 大显身手的时候。不管代码怎么混淆它最终都要调用系统 API如MessageDigest或执行关键逻辑拼接字符串。Hook 这些确定的点就能绕过混淆。字符串解密如果发现关键字符串如密钥、API域名被加密存储在运行时必然有一个解密函数。用 Frida Hook 所有可能进行字符串操作的方法如StringBuilder.append,某些解密类的decrypt方法在调用时打印输入和输出往往能定位到解密逻辑进而用 Python 复现。调用栈分析在 Frida Hook 到关键函数后打印调用栈。即使上层调用者都是混淆的a.a()、b.b()通过多次操作观察规律也能推断出这些混淆类的大致职责。6.2 密钥的隐藏与获取密钥 (secret) 是签名的核心。它可能硬编码在代码中直接搜索字符串或搜索其 Base64 编码后的形式。从本地文件或数据库读取可能是在 App 初始化时从服务器获取并保存的。动态生成由设备信息、时间等因子通过固定算法生成。应对策略全局搜索在 Jadx 中搜索可能的密钥片段或搜索secret、key、appKey等变量名。Hook 构造函数和初始化方法Hook 应用的主Application类或网络库初始化类查看启动时加载了哪些配置。Hook 网络请求Hook 应用第一次启动时或定期发出的配置请求看服务器是否下发了密钥。内存扫描如果密钥以明文形式在内存中存在过可以使用 Objection 的memory search命令或者 Frida 的Memory.scan()来搜索特征值。在“考试宝”的例子中密钥是硬编码在SignInterceptor类的一个静态常量字段中虽然字段名被混淆但通过分析赋值语句和交叉引用很容易定位。6.3 哈希算法的变种与加盐有时算法不是标准的 MD5(参数串)可能是多次哈希如 MD5(MD5(str))。加盐位置多变盐值密钥可能加在字符串开头、结尾或者参数中间。使用 HMACHmacSHA256(secret, param_str)。应对策略对比实验用 Frida Hook 拿到原始的待哈希字符串后用 Python 尝试各种可能的变化改变拼接顺序、尝试多次哈希、尝试 HMAC直到计算结果与 Hook 到的结果一致。Hook 底层哈希函数如前所述HookMessageDigest.getInstance和MessageDigest.digest()可以准确知道算法类型和输入数据。关注工具类应用通常会封装一个CryptoUtils或HashHelper类仔细分析这个类的所有静态方法。7. 成果应用与注意事项成功逆向sign算法后你可以编写爬虫或自动化脚本模拟请求稳定获取数据。进行安全评估分析其签名机制的安全性。例如“考试宝”的算法属于“参数排序后MD5加盐”如果密钥泄露则签名机制完全失效。如果nonce或timestamp校验不严可能存在重放攻击风险。协议研究与学习理解一套完整的客户端-服务端身份验证和数据防篡改流程。重要的法律与道德提醒本技术分享仅用于安全研究、学习交流目的。请严格遵守目标应用的服务条款。不要对目标服务进行未经授权的大规模数据抓取、攻击或干扰其正常运行。逆向分析得到的算法、密钥等切勿用于商业用途或非法目的。尊重开发者的劳动成果你的目的是学习其设计思路而非破坏。整个逆向分析的过程就像一场侦探游戏需要耐心、细心和严谨的逻辑。从抓包发现线索到静态分析理清框架再到动态调试验证细节最后用代码复现。每一步的突破都带来巨大的成就感。希望这篇详尽的记录能为你打开移动端逆向分析的大门更重要的是理解一套安全设计背后的逻辑。安全是攻防对抗的螺旋上升今天你学会了分析“签名”明天也许就能设计出更难以破解的机制。这才是技术交流与学习的真正价值所在。