加解密对抗历程随笔

出差上班缓一缓，把加解密的对抗历程给简单写了，没有写的特别详细，也懒的排盘了。里面也提到了几种方法，这些网上大佬都写过，搜索下就好了。

之前国家密码局公布了sm2 sm3 sm4 商用密码改造，做不做→必须做到。

V1：对称加密固定密钥

其实没公布之前金融行业是AES大部分都是ECB模式固定密钥格式进行改造，这种F12无论是任何资产都能把密钥给调试出来。

V2:AES的CBC模式

开始是iv、key都固定。后来是iv固定，Key不固定。这种因为是前端随机key，并不是其他固定key，可能觉得不知如何下手，但是这种也容易过。

1.只要是把随机key固定就行了

2。每次都找到key，然后进行加解密，这种方式不够优雅。

后来用到了对数据加上签名进行唯一性、不可重复性校验

V3：加密+签名(sign)

签名通常是 md5(数据+路径+时间戳),sha256(数据+路径+时间戳)，这种来实现。但是这种也有痛点，就是签名算法找到以后数据也能被破解，对于系统有waf也是爽到飞起了，犹如无人之境。

V4:混淆(加密+签名(sing))

再后来通过混淆，大部分都是OB混淆，开启了混淆模式，这样极大增强了找到加密算法，签名算法的难度，导致很多人都卡在了这里。但是也有一些逆向大佬能够快速的从OB混淆中，找到了其中的算法。

V5:增强版本(后端给前端传输一个一次性随机key+对称加密)

RSA算法随机生成一个密钥，这个密钥是用来对数据进行加密的。每次密钥都是随机的，这样就保证了无法对数据进行加解密了。但是依然有方法，就是在控制台强硬调试，在数据都是明文的时候，对数据进行控制调试，这样可以避免了。如果没有混淆，这个方法虽然不够优雅，但是还算是可以解决问题。如果有混淆了，极大的拖延了调试时间。

V6:混淆((后端给前端传输一个一次性随机key+对称加密+签名))

再到现在关键代码混淆，服务器通过RSA算法给前端一个随机的AES密钥，让密钥对数据进行加密，同时对数据有签名校验，对关键代码有混淆。把Web方面的渗透拉到了一个新的难度层次。

最后还有一个禁止调试Js，打开F12会禁止在F12中调试Js，控制台中出现debugger字样。这个在上面每一个过程都碰到过。。

总结：

从V1-V6每个过程加解密对抗都是越来越复杂，攻击的难度直线上升。只能是慢慢学习，不断对抗加解密。其实还有一个相对核心的技术，rpc技术，这个不展开细讲，有兴趣的可以搜索下。

针对Web的限制就是比较多，针对APP的限制相对就没那么多。APP可以直接hook加解密函数的地方，只要寻找到加解密函数的地方，就可以无缝去找这些事情了。

本文仅用于技术讨论与学习，利用此文所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，文章作者及本公众号不为此承担任何责任。

原文始发于微信公众号（呼啦啦安全）：加解密对抗历程随笔