之前转载过该app的文章，今天翻版重新整理下，版本号:576O5Zu+56eA56eAYXBwIHY5MDgw (base64 解码)。
上来先抓个包：
jadx搜索关键词 "sigTime"，然后定位到这里
看这行代码 cVar.addForm(INoCaptchaComponent.sig, generatorSig.sig); ，看下INoCaptchaComponent.sig 其实就是 "sig"，感觉是这里大差不差。
sig 是由 generatorSig.sig 计算出来的，跟进去。
这里是定义了一个 静态 SigEntity，看下大概的功能就是做下参数拼接，底部是调用nativeGeneratorSigOld(str, bArr, str2) 方法，继续跟进去。
这里最终是调用了public static native SigEntity nativeGeneratorSigOld(String str, byte[][] bArr, String str2) 方法，是一个native方法，用到的so是release_sig。
用ida pro 打开这个so 看看，继续跟进。
先看看导出表
搜索"java_"，可以看到java层注册的函数名，没错是个静态注册的，而且没有什么混淆。
先看 Java_com_meitu_secret_SigEntity_nativeGeneratorSig 函数
先看下 v10 = ValidateKey::getValidateResult() 大概就是检验是否合规的key
进来这里调用了 JavaHelper::getAndroidAPKKeyHash 函数，看起来像是校验 apk 签名
然后再看下 GeneratorSIG 函数，看字段命名 就像是，瞎猜的。
刚开始掉用了一个 GetSecretKey 函数，获取 key，接着是拼接一些不明的字符串，最后调用了 MD5_Calculate 计算函数。
着重分析下这个
这个MD5_Calculate 函数 重要的是由三部分组成 MD5_Init， MD5_Update， MD5_Final。
init 这里 全都是MD5标准的常量
最核心的加密都是在MD5_Update里面。
静态分析到此结束，开始上 frida 动态调试下。
先hook下 com.meitu.secret.SigEntity和_Z13MD5_CalculatePKcjPc函数看看。
打印下看看
把MD5_Calculate 方法的入参参数2 用hexdump转换成正常的字符串，在md5加密下，是cb67c671be0f0de69cfa310007eb146c，果然和hook出来的so层加密是一样的。
但是会发现 so层加密 cb67c671be0f0de69cfa310007eb146c 和 SigEntityB-结果:bc766c17ebf0d06ec9af130070be41c6 值不一样，仔细对比会发现他们是相邻的两个字符互换得来。
把_Z13MD5_CalculatePKcjPc 函数的入参参数 和抓包拿到的请求参数对比，我们会发现，它其实是把get请求后面的参数，先排序，然后再拼接，在拼接的过程中各拼接了2个盐值(xxxxxx 手动马赛克)，最后MD5计算出来的。
最后 最后当然是 python 算法还原了。
看看效果：
水文一篇，再接再续。
