作者声明:本文仅用于文娱、政治、媒体领域的交流与推广,禁止用于任何商业行为或招揽客户。若因此引发任何问题,作者不承担任何责任。如发现侵权,请直接联系作者删除,作者将对违规行为进行公开披露。
目录
目标网站
aHR0cHM6Ly9nZ3p5ZncuZmouZ292LmNuL2J1c2luZXNzL2xpc3Qv
接口分析
首先,访问网站,翻页查看接口,通过CURL复制为任意代码可以先做一次请求,看看是否可以得到我们的响应数据,响应数据是加密的
可以看到这里是我们想要得到的响应结果,观察可以发现请求头中有一个 sign值是比较可疑的,我们可以将它先注释掉,再发一次请求,可以发现我们的请求是跟sign值是有关联的
定位分析
在网站逆向分析中,我主要使用启动器追踪网络请求的代码来源,同时结合关键字搜索、XHR 请求分析和事件监听器检查等方法,快速定位关键逻辑并解析网站功能。
在网站逆向分析中,我主要利用启动器追踪网络请求的代码来源,并在第③步设置断点,因为前置断点无法生效,随后通过重新发包触发请求,断点成功断下,并可以看到如下参数
表单数据显示在这里,上方分析的sign值,要不就是通过表单信息进行加密的,要不就是自写的加密算法,这里其实已经向上跟栈,是没有发现有关sign值信息的
那么sign值的加密肯定是在表单后面进行加密的,我们接下来就要单步进行调试,也可以选择跳出当前的方法,两种方法都可以到下一个步骤
这里,我们通过跳出该方法,直接来到下一个步骤进行观察,发现了request.use,它主要是前端的一个框架中用于拦截和处理HTTP请求的关键钩子函数,开发人员往往会在这里插入加密逻辑,比如计算签名或加工某些请求参数等,它也是我们通过关键字定位的一种方式
接下来继续向下看,大致可以直接看到是通过t.headers["portal-sign"] = f.getSign(e)这一步骤进行加密的,其中e就是我们的表单数据,我们可以先定位到这一步,通过打印结果,先去对比,跟我们请求头中的sign值是否一致,如果是一致的,继续向下进行
重新发包进行单步调试,看清楚每一个步骤都做了哪些步骤,最主要的就是向t.data里面新增了一个时间戳,然后将这个对象作为参数通过f.getSign进行sign的加密
知道加密的地方,我们先将f.getSign(e)扣取下来,其次就是缺少什么,我们就补什么,我们先进入到getSign方法中,查看加密逻辑,分析r['a']是一个固定值,将表单数据传给u方法,进行字符串的拼接,然后传入给s方法,得到的结果转换为小写,返回结果
s方法,先去该函数的头部查找一下,可以看到s是通过n("897d")得到的,这就是webpack的特征,找到后断点下在这一行,重新刷新页面,只有重新刷新页面才会断住,因为webpack自执行,是在网站加载时运行,只有刷新才可以进入该逻辑
点击进入,可以找到加载器的位置,首先需要将加载器部分全部扣出来
扣出来后,首先要在return上方打印,每一次运行要知道我们缺少哪些方法,并导出我们的加载器,在后续使用
拿到后,先将n('897d')方法取出来,放到我们自执行里面,然后调用该函数,报错什么,就去补什么,补到可以正常运行为止,扣的时候,还要注意,尽量不要扣没有用的模块,有的浏览器会放一些方法迷惑我们,导入需要补的环境、方法越来越多
在本地不报错的时候,大概率就是成功了,接下来要在python中进行调用,看看我们的响应数据是否成功拿到,是没有问题的,可以正常拿到我们的响应数据
下面就是要解密响应的数据,可以从我们拿到加密的sign值一直单步向下跟栈,响应的数据肯定是通过我们发起请求后才可以得到的,可以看到t.data就是我们的响应数据,继续向下走,打印可以看到我们的明文数据,说明是通过拿到e.Data传入到b方法中去解密的
找到解密的地方是通过b方法,我们可以向上找一下b有没有在方法头部定义,也可以直接点b方法进去看一下,发现是AES的加密,可以找个网站去做一个验证,看看是不是标准的AES,其中里面的r["a"]和r["i"]是固定值,下面两种方式都会讲到
验证如下,使用的是标准的AES解密
JS代码如下
上面可以看到我们成功解密,这里使用webpack扣取一下,我们进入到b方法中,里面有个h,可以看到h也是自执行加载进来的,
我们把b方法单独扣出来,然后运行,看看报错,这个报错就是缺少某某模块,模块缺少的也已经打印出来了,只需要将浏览器中的代码扣下来,补全就可以了
将模块补齐之后,就可以正常运行,如果报的不是这个错误,可以通过定位去浏览器中,查找一下,大致是什么问题导致的
结尾
"感谢大家的观看!如果文章中有任何疏漏或不对的地方,欢迎随时私信我沟通交流,一起探讨逆向分析的奥秘!"