某行学习笔记

看看某行的加密

链接：aHR0cDovL3d3dy5wYmMuZ292LmNuLw==

流程

1. 请求分析
2. 逆向分析
3. 测试结果

请求分析

打开网页，F12打开开发者工具，依次点击Application==》Storage==》Clear site data，清除缓存

刷新后可以看到进入了debugger，选中debugger所在行，右键选择Never Parse Here跳过debugger

回到Network项，可以看到有三个包是很可疑的，估计就是先发送一次请求，然后验证了某个东西，之后才是真正的数据包，可以看到第三个包才有数据返回；我也勾选了Preserve log和Disable cache两个选项，这两个分别是保留抓包和禁止缓存，都可以先勾上

看了下，第三个包没有什么可疑的参数，那可能就是cookies的问题了，可以全局搜一下cookies的值，只有第二个包set-cookies的

再看第二个包，可以看到url上带有一个不明字符串和一个可疑参数wzwschallenge，全局搜索都是没有的，同时这个包是document发的包，那就好玩了

掏出我们的小花瓶，重新抓包看一下，这里说一下，浏览器抓到的包都是经过处理的，只有抓包工具抓到的才是真正返回的响应；重新抓包后搜索可以看到，在第一个包的响应中返回了这个可疑的url值

小结

请求的流程大概就是：

1. 第一个先发送请求，响应返回一大堆js
2. 然后由js生成第二个请求的url值和参数，响应set-cookies了
3. 最后第三个请求带着第二个数据包set的cookies请求获得数据

逆向分析

直接把第二个请求返回的js复制到vscode中，大概长这样子；一般document返回的js代码是可以直接运行的，可以直接跑一下，会有个报错说缺个window，在顶部补全个var window = {}; 就行，因为他操作了window，那我也在尾部直接打印个window看看做了什么操作

惊喜来得太突然，他这就直接返回了第二个请求所需要的东西了

ok，我们继续研究他到底是怎样加密的；一般像这样压缩过的js代码，都比较难看出运行，就会习惯性格式化一下，但是注意，这个代码格式化后运行导致栈溢出的，这样子就是检测了格式化了，而格式化通常是通过正则匹配去检测的，可以直接搜索RegExp，为了分析代码，还是要先格式化后才能阅读，但是记住格式化后就别运行了，会直接卡死的，搜索后可以看到就是检测了EHgJgn这个方法

接下来直接进入调试，看看到底是检测了多少，可以在之前那一行代码前打上debugger; 然后新开一个浏览器运行，新开别的浏览器主要是为了仿真栈溢出导致原来的浏览器卡死，可以直接在console上直接粘贴运行

可以看到浏览器已经在debugger上停止了，直接在浏览器上搜索RegExp，并且都打上断点，点击跳到下一个断点就可以分析正则是怎样检测的了

可以看到就检测了函数是否格式化了

接下来就是一步一步的去修改检测的点了，把检测的函数在自己的编辑器上都取消格式化，然后就会到对很长的一个函数的检测，这个取消不了格式化，就把编辑器上的这个！取反给去掉了过了这里的检测

然后！我把所有可以搜索到的格式化检测过掉后还是会出现栈溢出！彪得太厉害了，我直接把他停了

其实栈溢出主要的原因就是一些死循环或者是函数互调，把可以看到的检测过掉后还会有，那就说明还有一些字符换算后再用正则匹配去检测的，但是这样子找太难找了，要一步一步的去跟，tmd，我直接找加密的，赋值了window，那肯定调用了get的了，可以直接hook了，但是我一搜索就有找到了window，那直接下debugger;然后跟调试了

放到浏览器上运行，就可以看到加密的地方了，手动还原一下这些没什么好说的了，都是时间活，可惜我ast学得不咋滴，哭死；再跟一下就可以找到加密的算法了，他加密算法不算难，难得是各种检测，反正暴力一点的就是直接在源代码上下debugger;这样就可以理清他逻辑了

ok，不想继续跟了，就到这吧，有需要算法源码的找我聊

小结

这个其实就是sojson的加密，主要做了的事情就是代码混淆、格式化检测、死代码注入等等，加密的算法不算难

测试结果

成功率测试：