这次分析的是某车号的一个列表请求头参数加密
网站: aHR0cHM6Ly9oYW8ueWljaGUuY29tLw==
接口: aHR0cHM6Ly9oYW8ueWljaGUuY29tL3NpdGVfd2ViL2hhby9hcGkvZ2V0X2xhdGVzdF9hcnRpY2xlX2xpc3Q=
参数分析:
初步抓包发现部分可疑参数:
x-sign: 目测疑似md5加密
CIGUID, UserGuid,x-user-guid: 相等, 看似uuid之类的随机生成id
至于其他的x-city-id, x-ip-address应该是记录该次请求的ip和ip所在地域, 其他参数并无可疑之处
直接全局搜索x-sign之后只有一个结果, 点击进去查看发现就只有一个地方有x-sign:
打断点后重新发起请求发现r值是32位大写的字符串, 并且下面的sign加密是需要用到该值的, 所以需要分析r值的获取方法
分析o的方法之后 发现这个值可以固定, 是由e.headerEncryptKeys对象里面根据请求头的x-platform获取的不一样的固定值, 因为他的默认请求是phone所对应的value所以r就可以固定为该值
u值就是由字符串拼接而成的, e.cid也是固定默认值601, i是请求体的json格式, r是上面所获得的固定值, e.timestamp自然就是13位的时间戳
u值获取之后, 就到了下面的yicheUtils.md5方法, 看名字是md5, 但是需要验证一下是否md5和是否标准加密. 可以在console里面试一下加密固定值的md5(例如123456) 是否跟标准md5加密一致
确认是标准md5加密算法, 本次分析完毕.
再加一句, 里面的x-user-guid其实是随机的py的uuid随便搞