此文所提供的信息只为网络安全人员对自己所负责的网站、服务器等（包括但不限于）进行检测或维护参考，未经授权请勿利用文章中的技术资料对任何计算机系统进行入侵操作。利用此文所提供的信息而造成的直接或间接后果和损失，均由使用者本人负责。本文所提供的工具仅用于学习。
随着DeepSeek的爆火，这款以低廉成本撬动本土化应用的大模型被广泛使用在各个领域。其中，DeepSeek在逆向也发挥了巨大的作用。例如ida反编译后的伪C代码、短片段的ob混淆、js算法还原等，如果人力去看不仅耗费大量的时间，还原起来也是挺困难的。对于不是那么复杂的代码大模型还可以完成上述任务，有一些要配合人工+大模型。
在逆向的时候，师傅们应该也遇到过与服务器交互后生成的动态密钥，这个时候加密和解密的密钥必须使用服务器返回给你的，否则发送过去的请求服务器会解析错误。本次案例和其他的静态key不同，属于和服务器交互拿到的密钥，归类到动态密钥一类。
请求小程序抓包，发现请求被加密,另外在加密请求之前还发现了一个获取token的请求，铺垫一下，后面会重点讲一下这个数据包
我来说一下，我是如何实现自动化的，以上测试都是在微信开发者中给师傅们的讲解的，微信开发者去抠代码比较方便，pc端不能打卡的小程序，反编译下来放到开发者就可以打开。
工具为作者开发，正在内测中，师傅们可以使用网上公开的自动化反编译工具即可，如Ackites大佬的KillWxapkg：
https://github.com/Ackites/KillWxapkg
-
定位加密位置，师傅们可以全局搜索encrypt，或者一步一步跟站（这个后面再补）,如果是f12有时候是无法全局搜索的，那么我这里使用微信开发者，这里为了方便大家理解，就直接搜了，一眼顶真，DES算法
其实直接搜encrypt，105个匹配，大家要学会排除无关字段，有很多都是字符串，例如h.cheateencryptor这种忽略就好了，明显不是加密的地方。加密位置一眼顶真，直接断点，断点来到这里，显示密钥和请求明文.对于这种原生算法大家是不用去扣的，直接用原生js，或者python的库都可以。
DES是对称算法，找到密钥就能实现加解密，那么我们再向上跟一个站去查找密钥
r是由n.token赋值来的，查找n,n又是a的一个变量，找一下a是怎么来的，找到a是webpack加载来的(图二)，那我们再去跟到webpack模块里面去看
找到webpack模块，这里token是被赋值进去的,是谁调用了setToken这个方法
到这里有些师傅估计已经麻木了，giao,逆向2小时，挖洞3分钟。
结合之前铺垫的数据包，作者猜测大概就是这个服务器返回给客户端token密钥，然后客户端对token做了一些处理生成了新的token密钥。
1.有的师傅就要问了，为什么不是客户端生成的token密钥。答：如果是客户端生成的密钥，密钥是要跟随加密的数据包发送到服务端的， 而我在数据包中并没有发现任何多余的请求头，所以并没有把处理后的token发送给服务器.2.客户端生成的密钥，为什么要把密钥发送给服务器？答：密钥不发送给服务器，服务器不知道你的加密密钥，如何去解密你发送的密文请求，所以无法正常响应.以上问题，最后的流程图就可以得到答案
作者太懒，这里当时就去刷抖音了，抖音打开第一个界面，deepseek大模型满血复活版帮助xxx赚了100万。啊！，别人拿deepseek赚到了第一桶金，为什么我不能让deepseek帮我挖洞，灵机一动，一个大胆的想法，萌生了。
我先多发了几次请求获取服务器返回的token，然后通过断点，多次获取处理后的token.这样我就有了字典
{"token1": "客户端处理后的token1","token2": "客户端处理后的token2","token3": "客户端处理后的token3",.........}
嘿嘿，我如果把上述的字典，发送给满血deepseek，然后让他通过大量的计算与测试。是否能把客户端的这个处理token的函数给我模拟出来。
有时候大模型会忽悠你，他会给你出符合你上述的提供字典的解密函数，最终是否成功，还需要解密一下试试
说干就干，直接用手机打开小程序，抓包，即可，首先抓到服务端返回的token，拿去解密key函数去处理，得到处理后的key,然后再拦截到他的密文拿去DES解密。得到密钥：rLgC6i6v
根据我们定位到的加密算法，得知加密使用的是DES原生算法，填充模式是ECB,pkcs7。直接通过WT-JS工具套原生即可，成功解密
deepseek牛逼！！！，大模型去处理简单的逆向还是很快速的，让我们在众测项目中更快的挖掘出高质量漏洞。
那么既然是原生DES算法+解密key的算法都拿到了，直接编写自动化解密脚本就好了，解密脚本中去判断生成token的url，拿到token再去处理，放到DES的key中即可实现自动化逆向
编写的脚本有很多，encode插件等，甚至你自己也可以写一个python flask去监听处理请求。
总结上述加解密的交互流程，让师傅们更好的理解交互型动态密钥。
作者猜测师傅们的问题大致如下，如果还有想问的，私聊公众号，或者评论都可以
有的师傅就说了：服务器返回的密钥到客户端，定位到解密密钥的函数，然后拿到这个密钥，替换到脚本当中不就行了吗。答：确实可以，那么如果密钥每隔10分钟就失效，重新发起请求到服务端获取新的密钥，还要再次重复上述步骤，断点+替换密钥 甚至有些小程序的功能无法在pc端使用，例如（人脸识别等），就无法通过断点的方式获取处理后的密钥说白了：挖洞就是挖别人无法挖掘的资产和功能，假如这个资产或者功能别人都没有挖过。 而你可以挖，这就像一个没上过众测的新项目一样，漏洞很多，师傅们应该有类似的经历。
随着大模型的不断迭代，白帽师傅甚至可以拥有属于自己的Ai，通过自己挖掘到的漏洞案例、漏洞思路投喂给大模型不断训练、学习，训练成属于自己的大模型。漏洞挖掘过程中流量数据包可以选择性的发送到AI,让其根据自己的思路去分析可能存在的漏洞点，从而提高挖洞效率。
再细化一点，我们甚至可以做成Agent智能体，如xss智能体，通过投喂的漏洞案例，智能体可以自动构造payload,根据返回包的内容去生成payload。
原文始发于微信公众号（零壹安全）：js逆向之动态密钥+deepseek（0基础）
评论