apk随便在百度应用市场下载的，本想找个so加密的apk进行练习……

逆向第一步，当然是抓包看看提交了什么数据，分析数据包看看哪些数据是相对固定的，哪些数据是需要进一步分析的。

01.jpg (103.64 KB, 下载次数: 2)

2019-6-5 00:35 上传

POST https://nuc.api.mgtv.com/MobileLogin?device=vivo%20v3max%20a&osVersion=5.1.1&appVersion=6.3.6&ticket=&userId=0&mac=i865166029270231&osType=android&channel=baidu&uuid=&endType=mgtvapp&androidid=2cb935d1f69cdcb7&imei=865166029270231&macaddress=00%3A81%3Aba%3A79%3A6e%3Aa9&seqId=272a5ff8824479c52a450a0de249f6e2&version=5.2&type=10&abroad=0&src=mgtv&uid=&phonetype=vivo%20v3max%20a&testversion= HTTP/1.1

User-Agent: Dalvik/2.1.0 (Linux; U; Android 5.1.1; vivo v3max a Build/LMY49I) imgotv-aphone-6.3.6

Content-Type: application/x-www-form-urlencoded

Content-Length: 86

Host: nuc.api.mgtv.com

Connection: Keep-Alive

Accept-Encoding: gzip

_support=10100001&invoker=hunantvphone&mobile=15344556677&password=s2345678&smscode=86

依据包分析得知，大部分都是相对固定的数据，其中mac ="i" + macaddress ,macaddress顾名思义就是设备mac。

其中只有seqId加密过，而且从长度判断，应该是一个MD5加密。

于是使用jadx反编译apk，搜索关键字非常容易就找到了数据包组包的地方：

02.jpg (86.84 KB, 下载次数: 1)

2019-6-5 00:39 上传

先跟进y.a看看，果真是一个MD5加密方法。

03.jpg (34.53 KB, 下载次数: 1)

2019-6-5 00:40 上传

退回组包的地方继续分析这个MD5加密传入的数据是什么：

最主要的是d.s()是什么呢？

04.png (156.34 KB, 下载次数: 2)

2019-6-5 00:43 上传

分析前后代码，竟然发现……：mac的值也是d.s(),而从前面的提交数据包已经分析得知:mac = "i" + macaddress。

意思就是说seqId = "i"+macaddress +"."+时间戳

这个帖子想说的重点是：消息摘要算法的特性！

依据消息摘要算法的特性，是没法根据加密后的数据解密出明文的，所以消息摘要算法一般常用于数据校验。而这个apk提交的数据包中，seqId的摘要参数包含了时间戳，而包中却没有传递该时间戳，所以服务器是无法验证此消息摘要的正确性。所以seqId,应该就是一个32个十六进制字符的随机数……至此，就分析完毕了。

上面不是重点，主要是下面对消息摘要算法特性的一些总结：

消息摘要算法有如下特点：不管加密明文有多长，加密后的密文定长

明文不一样，加密后的结果必定不一样

加密后是不可逆的。

这种算法一般常见于校验数据完整性，apk中常见于签名，sign等

由于密文不可逆，所以后台无法还原。也就是说他要验证，就会在后台以跟前台一样的方式去重新签名一遍来比较。也就是说他会把源数据和签名后的值一起提交前台。进行文本比对。

所以逆向的时候如果要保证加密结果是一样的，就必须要保证在签名时候的数据和提交上去的源数据一致。这种算法还特别特别喜欢在内部加入时间戳。所以上面为什么判断得出seqId是一个随机数，因为每次加密的时间戳是不一样的，而数据包并未提交时间戳。