简介这份资源面向移动应用、小程序与网站开发者聚焦数字签名与加密的实战代码整理覆盖自如、小红书、蛋壳公寓、瑞幸咖啡等生活服务类App的签名与加密实现思路适合需要研究接口安全、逆向分析或加固方案的中高级开发者参考。压缩包共15个文件以11个Python脚本为主辅以2个JavaScript文件、1份README说明和1份LICENSE授权文件整体约26KB按项目模块分目录组织包含各App的初始化与入口脚本便于对照阅读不同平台的签名逻辑。目前已有435人学习下载。读者可从中获取多款主流App的签名算法实现片段、加密参数构造方式以及模块化目录结构用于理解请求签名生成、参数加密与校验流程也可作为自研接口安全方案的对照素材快速定位关键代码并迁移到自己的项目中。1. 从自如、小红书到瑞幸App 请求签名与加密码到底在防什么抓过自如房源、小红书笔记、蛋壳公寓账单、瑞幸咖啡优惠券接口的人大概率都撞过同一堵墙请求发出去返回的不是数据而是一句冷冰冰的「签名错误」或「invalid sign」。你明明把 URL、Header、Body 都抄对了可服务端就是不认。问题不在参数在于你没带对那串由客户端动态算出来的签名或加密码。App、小程序、网站这三类客户端只要涉及登录态、订单、优惠、房源这类有价值的数据几乎都会在请求里塞一个由密钥、时间戳、随机数和业务参数共同算出来的校验值。它防的不是普通用户而是脚本、爬虫和批量薅羊毛。这篇文章讲的就是这套机制怎么识别、怎么还原、怎么在本地复现出可用的签名适合做数据采集、接口联调、自动化测试的工程师也适合想搞懂自家 App 接口为什么被刷的安全同学。核心词就三个签名、加密码、请求校验。下面从识别到落地一步步拆。2. 先判断目标用的是签名还是加密码四种常见形态2.1 从抓包结果反推校验类型拿到一个 App 或小程序的请求第一步不是急着写代码而是看它到底把什么当成了「凭证」。常见的校验形态有四种识别方式差别很大。第一种是明文签名请求里直接带sign、signature、_sign这类字段值通常是一串 32 位或 64 位十六进制。这种最常见也最好还原因为算法基本就是 MD5、SHA-1、SHA-256 或 HMAC 系列。第二种是加密码字段可能叫encrypt、data、cipher值是一段 Base64 或十六进制密文长度明显比原文长。这种是先把业务参数整体加密再传输服务端解密后校验常见 AES、DES、RSA 混合使用。第三种是 Header 签名签名不在 Body 里而在X-Sign、Authorization、X-Auth-Token这类请求头中往往还配合时间戳X-Timestamp和随机串X-Nonce。第四种是协同签名客户端只负责一部分计算真正的签名由服务端下发的动态密钥或 SDK 内部完成比如某些加固后的 App 会把签名逻辑放进 so 库或小程序底层框架里。判断方法很直接把同一个请求的 Body 改一个无关紧要的字段重放一次。如果返回签名错误说明签名覆盖了全部或部分业务参数如果还能通说明签名只跟时间戳和固定密钥有关。这一步能帮你省掉大量瞎猜的时间。2.2 用最小改动定位签名覆盖范围定位签名覆盖范围是还原工作的分水岭。我一般会做一组对照实验每次只改一个变量观察服务端反应。改动项观察结果推断只改时间戳报签名错误时间戳参与签名只改随机数 nonce报签名错误nonce 参与签名只改业务参数报签名错误业务参数参与签名只改 Header 顺序通常不影响签名与字段顺序无关改 Body 里未参与签名的字段请求成功该字段被排除在签名外这张表看着简单但血泪经验是很多人一上来就假设「所有参数都参与签名」结果算出来的值永远对不上。实际上不少接口会把sign本身、文件流字段、以及某些展示用字段排除在外。你要做的是先确定参与集合再确定拼接顺序最后确定算法。提示改参数重放时务必保持时间戳新鲜。很多接口的时间戳窗口只有 60 秒过期后即使签名正确也会被拒容易让你误判算法错了。2.3 小程序和 App 的差异点在哪小程序和 App 虽然都叫「客户端」但签名逻辑的藏身之处完全不同。App 的签名逻辑通常在 Java/Kotlin 或 OC/Swift 层加固后可能下沉到 native 层。你用 jadx 反编译能看到 Java 层的调用链但关键算法可能只是一个 native 方法声明真正的实现藏在.so里。这时候要么用 Frida 动态 hook要么直接找 so 里的导出函数。小程序的签名逻辑则跑在 JavaScript 里但代码经过打包和混淆变量名全是a、b、c。微信小程序的包体可以在本地缓存目录找到解包后是app-service.js这类文件。还原时重点看wx.request调用前的参数组装签名函数往往就在附近。网站相对最透明前端 JS 直接可读但可能被压缩成一行需要格式化后再找sign关键字。三类客户端的共同点是签名一定发生在请求发出前的最后一刻且依赖的密钥要么硬编码要么从服务端动态获取。找到密钥等于拿到后悔药。3. 还原签名算法从关键字到可运行脚本3.1 静态搜索与动态 hook 的配合还原算法的第一步是找到计算入口。静态搜索的关键字包括sign、signature、md5、sha、hmac、aes、encrypt、secret、appKey、appSecret。在 App 里这些字符串可能被混淆但算法库的调用特征很难完全抹掉比如MessageDigest.getInstance(MD5)这种系统 API 调用。如果静态搜索找不到就上动态 hook。Frida 是常用工具思路是 hook 常见的加密函数打印入参和返回值。下面是一段 hook Java 层 MD5 的示例// Frida hook Java 层 MessageDigest观察签名输入输出 Java.perform(function () { var MessageDigest Java.use(java.security.MessageDigest); var update MessageDigest.update.overload([B); update.implementation function (bytes) { // 打印待摘要的原始字节转成字符串便于观察 console.log(MD5 input: bytesToHex(bytes)); var result update.call(this, bytes); return result; }; var digest MessageDigest.digest.overload(); digest.implementation function () { var res digest.call(this); console.log(MD5 output: bytesToHex(res)); return res; }; }); function bytesToHex(bytes) { var hex []; for (var i 0; i bytes.length; i) { hex.push((0 (bytes[i] 0xff).toString(16)).slice(-2)); } return hex.join(); }这段脚本的逻辑是在MessageDigest.update被调用时打印输入字节在digest返回时打印摘要结果。参数说明上overload([B)表示匹配字节数组参数bytesToHex负责把字节转成可读十六进制。跑起来后你在 App 里触发一次请求就能看到签名前的原始字符串长什么样。这一步的价值在于它直接告诉你拼接格式比如是appKeyxxxtimestampxxxnoncexxx还是keyvaluekeyvalue的顺序。3.2 用 Python 复现一个 HMAC-SHA256 签名拿到拼接格式和密钥后用 Python 复现是最快的验证方式。下面是一个 HMAC-SHA256 的典型实现import hmac import hashlib import time import uuid def build_sign(params: dict, app_secret: str) - str: # 1. 过滤空值和 sign 字段本身 filtered {k: v for k, v in params.items() if v is not None and k ! sign} # 2. 按 key 的字典序排序 sorted_keys sorted(filtered.keys()) # 3. 拼接成 keyvaluekeyvalue 形式 raw .join(f{k}{filtered[k]} for k in sorted_keys) # 4. 用 app_secret 做 HMAC-SHA256 sign hmac.new( app_secret.encode(utf-8), raw.encode(utf-8), hashlib.sha256 ).hexdigest() return sign # 构造请求参数 params { appKey: your_app_key, timestamp: str(int(time.time() * 1000)), nonce: uuid.uuid4().hex[:16], userId: 123456, page: 1 } params[sign] build_sign(params, your_app_secret) print(params)逻辑说明先剔除sign自身和空值再按字典序排序拼成标准查询串最后用密钥做 HMAC-SHA256。参数上app_secret是核心密钥timestamp用毫秒级nonce用随机十六进制。常见翻车点是排序规则有的接口按参数名 ASCII 升序有的按参数出现顺序还有的只对 value 排序。你必须用抓到的真实请求反推不能想当然。3.3 加密码的还原AES 与 RSA 的分工加密码比签名多一层因为你要先解密才能看到业务参数。常见组合是 AES 加密业务数据RSA 加密 AES 密钥。还原时先找 AES 的 key 和 iv再看它们是不是被 RSA 保护。from Crypto.Cipher import AES from Crypto.Util.Padding import unpad import base64 def aes_decrypt(cipher_text: str, key: bytes, iv: bytes) - str: # Base64 解码密文 encrypted base64.b64decode(cipher_text) # 创建 AES-CBC 解密器 cipher AES.new(key, AES.MODE_CBC, iv) # 解密并去除 PKCS7 填充 decrypted unpad(cipher.decrypt(encrypted), AES.block_size) return decrypted.decode(utf-8) # 假设 key 和 iv 已从客户端提取 key bytes.fromhex(0123456789abcdef0123456789abcdef) iv bytes.fromhex(fedcba9876543210fedcba9876543210) plain aes_decrypt(你的密文字段, key, iv) print(plain)参数说明key长度必须是 16、24 或 32 字节对应 AES-128/192/256iv长度固定 16 字节模式常见 CBC也有 ECB。如果解密出来是乱码先检查 key 和 iv 是否取错再检查填充方式。RSA 部分通常只用来保护 AES 密钥用私钥解密即可但私钥往往不在客户端这时候要么找服务端下发的动态密钥要么放弃纯静态还原。注意加密码的还原难度明显高于签名因为密钥可能一次一密。遇到动态密钥优先考虑 hook 密钥生成函数而不是硬啃算法。4. 避坑与排查签名还原路上最常见的五个翻车点4.1 时间戳单位搞错导致签名永远过期现象本地算出来的签名和抓包值一模一样但请求返回「签名过期」或「timestamp invalid」。原因客户端用毫秒你用了秒或者客户端用秒你用了毫秒。差 1000 倍签名窗口直接失效。解决抓包看timestamp字段的位数。13 位是毫秒10 位是秒。统一后再算签名并且确保本地时间和服务器时间偏差在允许窗口内。4.2 参数拼接顺序与编码方式不一致现象算法、密钥、参数都对签名就是差几位。原因拼接顺序不是字典序或者 value 做了 URL 编码而你没做或者空格被编码成了而不是%20。解决用 hook 打印出的原始字符串逐字符对比。重点看分隔符是还是空字符串value 是否 encode中文是否 UTF-8。这一步没有捷径只能靠原始输入反推。4.3 密钥硬编码在 so 里Java 层搜不到现象jadx 里翻遍所有类找不到appSecret或sign的赋值逻辑。原因签名逻辑下沉到 native 层Java 只留一个 native 方法声明。解决用 Frida hook native 层的常见加密函数比如MD5_Update、SHA256_Update、EVP_DigestUpdate。或者直接 hookJNI_OnLoad附近的注册函数找到 native 方法地址后反汇编。工具上 IDA 配合 Frida 是常规组合。4.4 小程序包体更新后签名逻辑变了现象昨天还能用的脚本今天全部签名错误。原因小程序热更新或发版后签名算法、密钥、拼接格式任一改变都会导致失效。解决建立版本监控每次抓包先比对sign字段长度和请求参数结构。如果长度从 32 位变 64 位说明算法从 MD5 换成了 SHA-256。不要假设一套逻辑能永久用。4.5 忽略设备指纹和风控参数现象签名完全正确但请求返回「环境异常」或直接封号。原因除了签名服务端还校验设备 ID、安装 ID、行为轨迹等风控参数这些参数也在请求里且参与签名。解决把风控参数一并纳入签名计算并保证每次请求的指纹一致。如果风控参数由 SDK 动态生成需要 hook 生成函数而不是伪造固定值。5. 进阶把签名逻辑做成可复用的本地服务5.1 用 Flask 暴露一个签名接口当你需要批量请求时把签名逻辑封装成本地 HTTP 服务是最省事的做法。这样采集脚本、测试脚本、Postman 都能调用同一套逻辑改算法时只改一处。from flask import Flask, request, jsonify import hmac import hashlib import time app Flask(__name__) APP_SECRET your_app_secret def calc_sign(params: dict) - str: filtered {k: v for k, v in params.items() if k ! sign and v is not None} raw .join(f{k}{filtered[k]} for k in sorted(filtered)) return hmac.new(APP_SECRET.encode(), raw.encode(), hashlib.sha256).hexdigest() app.route(/sign, methods[POST]) def sign_api(): data request.get_json() # 自动补时间戳和随机数 data.setdefault(timestamp, str(int(time.time() * 1000))) data[sign] calc_sign(data) return jsonify(data) if __name__ __main__: app.run(host127.0.0.1, port5000)逻辑说明接口接收业务参数自动补时间戳计算签名后原样返回。参数上APP_SECRET从配置文件读取更安全端口按需改。调用方拿到返回的 JSON 直接作为请求参数即可。这个服务的价值在于把「签名」从脚本里解耦出来多个项目共用。5.2 验证签名正确性的三个手段写完签名逻辑别急着上量先做三组验证。第一用抓包到的真实请求做回归。把当时的参数、时间戳、nonce 原样输入看输出是否与抓包sign完全一致。一致说明算法和拼接都对。第二做时间窗口测试。把时间戳往前调 30 秒、60 秒、120 秒观察服务端在哪个点开始拒绝确认窗口边界。第三做参数扰动测试。随机改一个参与签名的参数确认签名变化改一个不参与签名的参数确认签名不变。这能验证你的参与集合是否准确。5.3 我踩过的坑和现在的习惯我最早做这类还原时总想一次把算法完全静态分析出来结果在 so 库上耗了两天。后来养成习惯先动态 hook 拿到输入输出用真实数据反推算法再回头静态确认。动态优先静态验证这个顺序帮我省了大量时间。另一个习惯是给每个目标建一个「签名档案」记录算法、密钥来源、拼接格式、时间戳单位、参与字段列表、失效日期。下次接口一变对照档案就能快速定位差异。签名还原不是一劳永逸的事它更像持续维护的适配工作。把每次踩坑记下来比记住某个具体算法更有用。希望帮到你。本文还有配套的精品资源点击获取