NMPA加密逻辑:
声明:本文内容仅供学习交流,严禁用于商业用途,否则由此产生的一切后果均与作者无
关,请于24小时内删除。
前言
一、本地替换
二、cookie逻辑分析
1.定位cookie生成位置
2.算法扣取
一.第二个字符串逻辑扣取
二.第三个字符串生成逻辑扣取
第一个数组生成
第二个数组生成
总结
药监局-js逆向③后缀生成算法扣取(写作中.....)
前言
在上篇文章中,介绍了请求药监局返回数据的一整套请求流程和请求流程中的加密类型,这篇文章将介绍如何定位cookie生成位置且如何扣取cookie生成算法,在node环境中生成cookie,请求url,返回状态码为200的主页面。
一、本地替换
众所周知,rs最大的特点就是动态混淆加密,还有无限debugger。面对动态混淆加密,有点无从下手,因为每次请求返回的代码都是不同的(其实就是变量名不同,方法和逻辑还是没有变化),这样给扣取算法带来了很大的难度,所以我们要在本地保存一份静态的网页进行调试扣取算法。
从上图的抓包可以看出,请求到状态码为200的主页之前,只有三个发包请求,可以分析出cookie生成逻辑在状态码为412的html和加载的js文件中,将这两个请求的返回体本地保存然后替换。使用Fiddler进行替换。
注意:因为cookie的生成与412html中meta标签中content的值有关,且这个值是随机且有时效性的,如果本地替换了这两个文件所生成的cookie是请求不到状态码为200的主页面的,但是cookie生成逻辑是没有问题的。
如果想动态调试rs,可以使用mitmproxy这个抓包程序,定制py脚本(拦截服务器返回混淆代码,使用ast对混淆的代码进行反混淆,最后替换混淆代码),具体操作可以看这篇文章:
某数和某5秒-反混淆动态注入调试的一种方案
二、cookie逻辑分析
1.定位cookie生成位置
一般定位cookie生成,最通用的方法就是Hook了,使用油猴注入cookie hook代码,代码如下:
var cookie_cache = document.cookie?document.cookie:"";
Object.defineProperty(document,'cookie',{
get:function get(){
console.log('获取了cookie ===>' + cookie_cache)
return cookie_cache
},
set:function set(val){
var new_val = val.split(';')[0]
console.log('写入了cookie ===>' + new_val)
debugger;
var cookie = cookie_cache + ';' + new_val
return cookie
}
})
结果如下:
只定位到了cookie赋值地点,并没有hook到cookie生成位置,这时候一般都是打断点,跟栈调试,但是rs的cookie有个特点,几代rs,cookie开头就是几,5代rs的cookie开头就是5,4代rs的cookie开头就是4,因为药监局是五代rs,开头肯定是5,猜测cookie肯定做了字符串拼接生成,可以全局搜索下'5'(大部分关键字都保存一个数组中,利用数组下标取关键字)
四代rs的cookie中'4'是赋值给了一个变量,全局搜索赋值的变量,就可定位到四代rs的cookie生成地点。
2.算法扣取
可以看出cookie的生成是由三个字符串拼接而成,第一个是字符串’5’,第二个是已经生成的字符串,第三个是加密数组而得到的字符串。所以重点就是第二个和第三个字符串生成算法。
一.第二个字符串逻辑扣取
第二个字符串生成是由加密函数加密16位数组生成而得,扣取加密函数和16位数组的生成逻辑就可还原第二个字符串生成。
二.第三个字符串生成逻辑扣取
处理第三个字符串生成算法,将加密函数和数组扣取下来,在本地将算法扣取后,测试本地生成值的长度和浏览器生成得值长度是否相同(数组保持不变)。扣取算法后,然后扣取这两个数组元素生成。
第一个数组生成
cookie生成了三次,每次cookie生成,第一个数组的长度都不一样。我扣取的是第三次cookie生成第一个数组,长度为160。
第二个数组生成
可以看出第二个数组是由两个16位数组合并而成。扣取这两个16位数组生成算法,合并成32位数组,参与第三个字符串加密生成。
总结
以上就是今天要讲的内容,本文介绍了cookie定位和生成逻辑,虽然是动态混淆,变量会发生改变,需要进行本地替换扣取逻辑,但是代码的行号是不会改变的(药监局的rs是这样,其他的就不清楚了),也可以根据行号来定位,扣取代码。