1. 为什么复杂加密逻辑是测试人员的“拦路虎”BurpCrypto如何破局1.1 自研加密协议在Web应用中的普遍存在与测试痛点干过几年Web安全测试的同行应该都有同感现在真正难缠的站点已经不太靠传统WAF和访问控制来防你了它们把更多的精力花在了——前端用JS把请求参数整个加密一遍后端返回数据也加密一遍。你打开Burp Suite的Repeater看到的请求体不是肉眼可读的usernameadminpassword123456而是一长串看起来像a3f8d1e9c0b7...的密文。这时候你连“改一个参数重新发请求”这种最基础的操作都做不到更别说挖逻辑漏洞了。常见的加密方式大致有这么几类一种是简单的AES/DES对称加密密钥写死在JS里一种是RSA非对称加密前端拿公钥加密登录密码还有一类更麻烦是混合加密——客户端生成临时AES密钥用RSA公钥把AES密钥加密后连同密文一起发给服务端服务端先用私钥解出AES密钥再解密业务数据。除了这些还有自定义Base64变种、异或混淆、时间戳签名、参数顺序打乱等等五花八门。几年前遇到这种情况常规解法是拿Python脚本手动模拟加密流程在Burp外面跑脚本生成密文再粘回Repeater里改包。一次两次还行一旦需要测爆破、跑Intruder、批量测越权这种方式就彻底断送效率了——你总不能每跑一个字典都去手动粘一次密文吧于是就有了把加密逻辑“内嵌”到Burp里的诉求。这也就是BurpCrypto这类插件的价值所在它允许你直接把加密解密逻辑配置到Burp的流量处理链路中请求会自动被加密、响应会自动被解密Burp Suite的Repeater、Intruder、Scanner都能在这个前提下正常工作。而BurpCrypto里最灵活、最值得深挖的功能就是自定义JS代码执行——你可以在插件里运行一段你自己的JavaScript实现任何内置加密方式都覆盖不了的复杂逻辑。这篇文章就围绕这个高级玩法展开全程用实战案例讲清楚怎么定位目标加密逻辑、怎么写可复用的JS脚本、怎么调试踩坑希望能给正在跟自研加密接口搏斗的同行省下几个通宵。1.2 BurpCrypto的核心定位把加密逻辑“搬进”BurpBurpCrypto之于Burp Suite相当于一个“翻译层”。它本身不代替你逆向加密算法它干的事情是把你整理好的加解密规则挂到请求/响应经过的路径上。官方提供的功能主要分两类一类是内置的常见算法模板比如AES、RSA、DES、MD5、SHA你可以填密钥、IV、填充模式选择加密还是解密保存后直接调用另一类就是本文的主角——自定义JS代码执行你可以通过编写JavaScript代码块实现内置模板覆盖不了的定制逻辑比如多层嵌套加密、加密前拼接特定盐值、按业务规则截取字段、动态生成时间戳参与签名等。自定义JS这个功能之所以叫“高级玩法”因为它有两层能力。第一层它实际上是在Burp内部嵌入了一个JavaScript脚本引擎你的代码块可以像一个小型Servlet一样接收字符串输入、处理、返回字符串输出。这意味着你在前端混淆代码里分析出来的加密函数可以近乎原样地“搬”到BurpCrypto里执行——你不需要用别的语言重写一遍算法直接用JS再写一次甚至从压缩代码里还原出来的逻辑稍加改造就能用。第二层它可以配合Burp的Session Handling规则和宏来自动处理每次请求的动态参数比如先请求一个Token接口拿到新的Token再用自定义JS去构造带Token签名的密文。这两层能力组合起来就能覆盖大多数自研加密场景。顺带说一句这个思路不只适用于BurpCrypto这一个工具。掌握了“在代理工具中挂载自定义脚本处理加解密流量”的思路后你会发现类似的商业工具和开源工具比如某些流量分析平台操作逻辑都是相通的核心永远是两件事搞清楚目标加密逻辑的输入输出契约然后把这个契约表达成工具能执行的形式。2. 吃透自定义JS代码执行核心概念与配置要点2.1 三种内置加密方式的适用场景判断打开BurpCrypto的界面你会看到几种加密方式的选项。在动自定义JS之前我建议先做个判断这道加密到底能不能用内置模板硬解。内置AES适合标准的、密钥和IV固定的对称加密场景内置RSA适合公钥固定的非对称加密。但问题是真实的站点几乎不会给你这么标准的实现。比如同样叫AES加密前端代码里用的是CryptoJS默认配置CBC模式Pkcs7填充UTF-8编码而后端Java实现可能用的是AES/CBC/PKCS5Padding两边在处理字符串编码时一旦有差异你拿内置模板填进去就会发现加密结果对不上。再比如很多系统会“加密后再做一次URL-safe的Base64替换”把/替换成-_这种变种模板就无能为力了。还有一种更隐蔽的情况加密逻辑本身不复杂但密钥不是写死的而是每次请求前动态生成或者密钥由另一个接口下发。这种情况下内置模板的“固定密钥”思路根本不起作用因为每次会话的密钥都不一样。此时自定义JS的价值就出来了——你可以在脚本里实现完整的密钥交换和加解密流程把“动态”的部分实现在脚本内部。所以我的判断标准很简单密钥和参数如果都是静态的优先试内置模板只要涉及动态生成、数据预处理、多层嵌套、编码转换直接上自定义JS省得在模板的参数组合里来回试错。2.2 JavaScript代码块的接口契约输入输出必须搞清自定义JS代码块虽然叫“自定义”但它不是让你随便写一段浏览器端代码就能跑的。它在BurpCrypto中有自己约定的输入输出接口这个接口契约是第一道门槛没搞明白后面全是坑。简单说插件的JavaScript引擎执行你的代码块时会把你指定的输入内容当作变量传入然后获取你代码块的返回值作为输出。在具体配置界面里一般需要指定几个东西输入来源是取请求体整个body、还是取某个参数值、还是取响应体、处理类型是加密还是解密、关联的JS代码块以及代码块内部的入口函数名。以我常用的配置方式为例JS代码块里通常写一个Java风格调用的函数形如function encrypt(input) { // 这里写你的加密逻辑 return cipherText; }注意这个input插件传进来的不一定是你心理预期的“明文”。它可能带着URL编码、可能带着请求体的整体结构、也可能只是你选中的某个参数的值。所以拿到input之后第一件事往往要做清洗和转换。比如input如果是{username:admin}你最终要加密的可能是usernameadmin这种拼接格式那就得在代码里做一次解析和重组。反过来输出也有讲究插件拿到返回值之后是会把它直接替换到原位置还是会再套一层编码然后附加到请求里需要在配置时选对输出方式。这里教大家一个小技巧在正式写加密代码之前先用一个最简单的“透传函数”跑通链路比如function encrypt(input) { return input; }。如果配置正确请求发出后服务端收到的内容应该和原请求一致说明输入输出链路是通的。这一步确认了后面所有处理都是在此基础上的算法实现排查问题时会省太多事。2.3 代码块注册与启用操作路径与关键细节点实践中的操作路径大致是这样的先通过Extender加载BurpCrypto的jar包在Burp Suite的Tab页里找到BurpCrypto面板然后进入JS代码管理界面新建一个代码块给这段代码起个一眼能认出用途的名字——这一步强烈建议养成好习惯因为你测的站点多了以后代码块列表会很长没有命名规范会非常痛苦。我个人习惯的命名格式是目标名_接口名_加密/解密比如finance_login_encrypt。代码块建好后接着要配置关联规则。这里才是真正跟“拦截”相关的地方你需要明确这条加密/解密规则作用在哪个作用域Scope上是只在某个域名下生效还是全局拦截是只处理POST请求的body还是连URL参数、Header、请求行都要处理。多数情况下加密逻辑集中在请求体上响应内容则是整个包加密后返回。但也有变态的站点会把关键参数放在Header里做签名比如X-Sign字段这时候就需要配置多条规则分别处理body和header。配置完规则还要注意执行的顺序。Burp处理请求和响应时规则是按你定义的顺序依次执行的。比如你先做了一次整体加密紧接着又要往请求头里塞一个签名值这两个步骤的顺序不能反。我在实际项目中就遇到过因为规则顺序放反导致签名永远校验不通过的情况。排查了半天最后发现是明文加密和签名计算的前后顺序颠倒了——服务端要求先拼好明文计算签名再整体加密而我配置成了先加密明文再对密文计算签名那服务端拿到包一验证必挂。3. 实战演示某模拟金融系统AESRSA混合加密接口的完整破解3.1 先做侦察从抓包到定位前端加密JS理论说了一堆接下来用一个实打实的案例把这套流程串一遍。某天我在授权范围内测试一个模拟金融系统目标接口和数据都做了脱敏处理登录接口的请求包长这样POST /api/login HTTP/1.1 Host: target.example Content-Type: application/json X-Timestamp: 1699999999 {k:MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA5x...,d:u3PcG3fYbPdEqzJAJ0vAaQXv7zAeNvN8zNxn7UzqoBmH0k,v:9Wh2e5x7dS0}Body里有三个字段一个超长的字符串k一个Base64密文d一个看起来同样像Base64的字段v。凭经验判断这是典型的混合加密k大概率是RSA加密后的AES密钥d是业务数据用AES加密后的密文v则可能是AES的初始化向量IV。但这里有两个疑点第一v的长度看起来不像标准16字节IV的Base64编码长度16字节的IV做标准Base64编码应该是24个字符第二k那个RSA密文里没有看到标准的BEGIN PUBLIC KEY结构而是直接一段裸Base64说明前端很可能把公钥的Modulus和Exponent做了某种序列化处理。遇到这种情况直接猜加密参数是猜不出来的必须去前端代码里找依据。打开浏览器开发者工具切到Sources面板把登录页引用的所有JS文件都过一遍重点搜索encrypt、RSA、AES、CryptoJS、setPublicKey这类关键字。最终在一个压缩过的工具JS里找到了核心逻辑还原后的伪代码大致如下function doLoginEncrypt(plainText) { // 1. 生成16字节随机IV var iv CryptoJS.lib.WordArray.random(16); // 2. 生成AES密钥128位 var aesKey CryptoJS.lib.WordArray.random(16); // 3. 用RSA公钥加密AES密钥注意这里做了特殊处理 var encryptedKey rsaEncrypt(publicKeyModulus, publicKeyExponent, aesKey); // 4. AES-CBC模式加密业务数据 var encryptedData CryptoJS.AES.encrypt(plainText, aesKey, { iv: iv, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }); // 5. 把结果塞进JSON return { k: encryptedKey.toString(CryptoJS.enc.Base64), d: encryptedData.toString(), v: iv.toString(CryptoJS.enc.Base64) // 这里的v就是IV的Base64 }; }逻辑清晰了唯一需要注意的就是第3步的rsaEncrypt函数它接收的不是标准PEM公钥字符串而是模数和指数两个参数说明实现里的RSA加密是把公钥的Modulus和Exponent手动拼接后做的运算。这部分逻辑需要单独还原不能指望内置模板。3.2 编写可复用的JS加解密代码块既然目标是“让Burp能自动处理这个接口的请求”那我需要写两个代码块一个用于加密请求数据一个用于解密响应数据。不过先说明实际执行时我只写了加密方向因为登录接口的响应在这个系统里并没有做响应体加密返回的是明文JSON所以这里演示以请求加密为主。解密方向代码块的结构其实是镜像的文末我会给出模板。加密代码块的核心逻辑需要分成四步从input里拿到业务参数。这个input是插件从请求体里抽出来的原始字符串在JSON格式的POST请求场景下我配置了整包透传所以input就是完整的JSON体。解析JSON把要加密的业务字段提取出来拼成服务端约定的明文格式。执行AESRSA混合加密流程。返回加密后的JSON字符串。关键是第3步里的RSA加密实现因为该系统的公钥是裸的ModulusExponent所以我需要用JS自己拼一个RSA公钥对象。这里我用的是jsbn库配合RSA算法实现但BurpCrypto的脚本引擎不一定预置第三方库因此在代码块里需要自行引入或者内联实现。实践中我选择把jsbn的核心函数直接内联进代码块再用它完成RSA加密。整体代码如下// 内联一个极简RSA公钥加密实现基于jsbn核心逻辑仅用于加密场景 var RSAGenerate (function() { // ... 这里省略了jsbn/Base64的完整实现实际使用中需将jsbn的BigInteger和RSA加密函数粘贴进来 function rsaEncryptWithModExp(modulusB64, exponentB64, data) { var modulus new BigInteger(Base64ToHex(modulusB64), 16); var exponent new BigInteger(Base64ToHex(exponentB64), 16); var textHex stringToHex(data); var m new BigInteger(textHex, 16); var c m.modPowInt(exponent, modulus); return c.toHex(); } return rsaEncryptWithModExp; })(); function encrypt(input) { // 1. 解析请求JSON var req JSON.parse(input); // 2. 提取明文不同接口提取方式不同这里以登录接口为例 var plainObj { username: req.username, password: req.password, timestamp: req.timestamp }; var plainText JSON.stringify(plainObj); // 3. 生成AES密钥和IV var aesKey CryptoJS.lib.WordArray.random(16); var iv CryptoJS.lib.WordArray.random(16); // 4. RSA加密AES密钥 var rsaPublicKeyMod 从上一步分析中获得的Base64模数字符串; var rsaPublicKeyExp 从上一步分析中获得的Base64指数通常为AQAB; var encryptedAesKey RSAGenerate( rsaPublicKeyMod, rsaPublicKeyExp, CryptoJS.enc.Base64.stringify(aesKey) ); // 5. AES加密业务数据 var encryptedData CryptoJS.AES.encrypt(plainText, aesKey, { iv: iv, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }); // 6. 组装返回 return JSON.stringify({ k: encryptedAesKey, d: encryptedData.toString(), v: CryptoJS.enc.Base64.stringify(iv) }); }这里需要另外注意几个小问题第一RSA加密的对象是AES密钥的Base64字符串还是AES密钥的原始字节前端代码里用的是aesKey对象直接参与加密经过CryptoJS内部处理实际操作时需要逐行对照前端源码确认我在这个例子里选择把AES密钥先转成Base64字符串再加密实测能通过说明服务端对这块做了兼容处理。第二Modulus通常是一长串256字节的Base64直接放在代码块里注意别因为换行导致脚本解析异常建议一行写完。第三jsbn算法要求把Base64转成Hex字符串再进制转换所以代码里的Base64ToHex和stringToHex是辅助函数必须一并内联进去。写好的代码块保存后在BurpCrypto界面选中这个JS配置“请求体处理方向”为加密并绑定到目标域名下的/api/login接口。配置完先别急着自动化先用Repeater手动发一个请求看看返回的服务端响应是不是正常的业务响应。如果响应返回“解密失败”“数据格式错误”之类的提示先别怀疑算法写错回去对照前端源码重点检查明文拼接格式是否一致空格、引号、字段顺序都会导致AES密文对不上IV的编码方式是Base64还是Hex直接影响密文能否正确解密RSA加密时对AES密钥的预处理方式有的系统会对密钥做SHA-1摘要后再加密这种情况我后面专门讲。3.3 在BurpCrypto中配置并验证加解密正确性配置完成后一个非常重要的事情是验证“加密结果的正确性”。BurpCrypto作为一个代理插件它的加密输出不会在界面上高亮提示“成功”或“失败”唯一的验证途径就是把加密后的请求发出去看服务端反应。我当时的方法很粗暴但有效先用Repeater发一次原始未加密的请求如果服务端允许的话记录正常返回再把请求体改成通过BurpCrypto加密后的内容发出去看返回。如果前一次返回错误后一次返回正常说明加密链路已通。但更严谨一点的做法是把前端页面里真实发送的加密包用浏览器抓下来和BurpCrypto处理后的请求体做逐字节比对。理论上同一个明文由于AES密钥和IV是随机生成的两次加密结果必然不同比对的意义在于检查结构是否一致——字段名对不对、类型对不对、k和v的Base64格式是不是和前端产出一致。还有个小坑需要提醒由于我们用了随机AES密钥和随机IV每一次请求生成的密文都不一样。这本身没问题——服务端本来就是为了防重放才这么设计。但如果你的Intruder配置里把时间戳等动态字段固定死了那么每次请求的加密结果虽然在变化但里面的业务明文完全相同服务端依然会校验通过这种情况就暴露不出什么问题。真正要测业务逻辑时需要让时间戳也跟着每次爆破变化这就要靠Session Handling规则或者宏来先取一个动态时间戳再传入自定义JS参与加密。这块在下一节细说。3.4 联动Intruder与Scanner让Burp“听得懂”加密流量加密链路打通之后接下来就要发挥联动价值了——否则我们只是用Burp中转了一下加密请求对测试效率的提升非常有限。先说Intruder怎么用。在Intruder中如果你把整个请求体作为一个Payload位置BurpCrypto的规则会自动对这个请求体先执行加密再把密文发出。更常见的是只爆破某一个字段比如用户名。这时候注意不能只把用户名框选中做Payload位置因为BurpCrypto的加密规则默认作用于整个body如果你只替换了body里的username字段那么替换后的body会再次被整体加密这没问题——执行顺序是Intruder先把Payload替换进请求模板然后BurpCrypto再对这个最终请求体的整体密文做加密替换。也就是说你正常设置Payload位置正常跑就行了加密动作发生在所有替换完成之后。这个设计很关键它意味着你不用在Payload生成器里去预加密直接用字典明文即可。这里有个容易踩的坑如果你在Intruder里同时对多个字段做Cluster Bomb爆破BurpCrypto会把每次组合后的完整body做加密没问题但如果你配置的加密规则只针对body里的某个参数值比如只加密password字段的值那就要把该值单独设为一个Payload位置并且加密规则的处理目标设置为“仅选中参数”而不是整个body。否则plugin listener在处理时无法在已经拆成多段的参数中正确识别哪一段是加密对象。我在早期配置时经常会犯这个错误结果Intruder发出去的请求还是明文或者加密后格式错乱。Scanner联动也是同理。爆破登录接口时Burp的Scanner会对每个响应做漏洞匹配但如果你有一个加密规则在扫描过程中失效了比如时间戳过期Scanner看到的响应就全部是超时或错误页面这会造成大量误报。所以扫描前最好先确认目标系统的加密是否有“时效性”要求——如果签名里包含时间戳那就必须在Session Handling里配置获取当前时间并把它作为变量注入到加密前的请求体中确保每次Scanner发出请求时的时间戳都是新鲜值。具体做法是在Project Options的Sessions里新建一条规则使用宏请求一个无业务副作用的接口获取服务器时间自定义JS代码块内读取这个时间变量参与明文拼接。这样每次Intruder/Scanner执行时时间戳都会自动刷新。至于Scanner本身倒不需要额外配置。只要加密规则在作用域内生效Scanner发出的所有请求体都会自动被加密相当于Burp Scanner变成了一个“懂加密”的扫描器。唯一需要注意的是扫描器发出去的大量自动化请求会显著增加目标服务器的解密压力某些安全设备可能因此触发告警所以建议在授权测试中合理控制扫描速度和线程数不要一上来就拉满。4. 踩坑实录自定义JS最常见的6个问题及排查思路4.1 常见报错速查表自定义JS这东西平时不显山不露水一旦出问题就是连环坑。下面这六个问题是我在实际项目中反复遇到过的整理成了速查表格基本覆盖了90%的异常场景。现象可能原因排查与解法插件报错“JS script load failed”代码块里有语法错误或引用了不存在的全局变量把代码复制到本地Node.js环境跑一遍先保证语法通过加密后的请求服务端返回“Decrypt failed”明文格式与服务端预期不一致或者AES密钥类型/IV编码错误逐字段对照前端源码重点检查JSON.stringify的字段顺序和引号规则同一个明文两次加密结果相同AES密钥或IV没有随机化CryptoJS生成了固定参数检查是否错误地在每次加密时使用了CryptoJS.enc.Utf8.parse(固定key)而不是WordArray.random(16)中文乱码或密文长度异常编码不一致通常是服务端用GBK、前端用UTF-8或者输入里混入了URL编码在代码块里强制指定字符集转换比如使用unescape(encodeURIComponent(str))处理中文后再加密请求能发出但Burp的响应显示乱码响应体也被加密了但只配置了请求加密规则捕获服务端响应还原解密逻辑新增一条响应方向的自定义JS代码块Intruder跑起来后请求体没有任何变化加密规则的作用域没匹配到目标URL或者规则顺序被后续规则覆盖到BurpCrypto规则列表里检查Scope配置和上下行顺序临时把作用域改为“所有请求”做验证提示排查任何自定义JS问题之前先打开BurpCrypto自带的调试日志开关。它会记录每次脚本的输入和输出这个功能能帮你快速定位是脚本逻辑错、还是插件参数传递错。4.2 几个值得专门强调的细节字符串编码、填充模式、随机因子除了上面表格里的表面问题还有三个深水区细节值得单独展开说。第一个是字符串编码。前端JavaScript里的字符串是UTF-16CryptoJS处理时默认按UTF-8解析而Java后端的字符串默认是UTF-16LE但通过HTTP传输时又变成UTF-8字节流。这三层转换中只要有一层理解错中文参数的加密结果就一定对不上。实操中建议把所有参与加密的字符串都先做一次encodeURIComponent再传入加密函数或者反过来在明文拼接时就统一用转义后的字符串——关键是要跟服务端的预期对齐。怎么对齐最靠谱的方法是抓一个前端发出的真实加密包用你自己的代码跑一遍同样的明文比对密文的Base64结果。能对上说明编码链对了对不上就逐个环节试。第二个是填充模式。前端CryptoJS几乎默认使用Pkcs7而Java后端的AES实现里如果用的是PKCS5Padding这两者在块长度为16字节的AES下是完全兼容的——因为PKCS5Padding实际就是PKCS7Padding在8字节块上的别名Java里写PKCS5Padding时底层也是按PKCS7的规则填充。但要注意如果你在自定义JS里用了CryptoJS.pad.NoPadding而后端用的是PKCS5Padding明文最后一块不足16字节时就会出现补位差异导致解密失败。所以尽量别自行处理Padding交给CryptoJS默认就好。第三个是随机因子。AES-CBC模式中IV必须是每次随机且不可预测的。但在测试场景下如果你为了比对密文而不小心把IV固定了那么相同明文会产生相同密文一旦被测系统的防重放机制检测到两次相同密文会直接拒绝请求甚至封IP。这种情况就不是“加密实现不对”而是“随机性被破坏”。在调试阶段我理解大家想固定IV方便比对但上线到Intruder或Scanner前一定记得改回随机IV。另外注意WordArray.random(16)生成的随机数在Java的Rhino引擎里依赖底层熵源某些环境可能出现随机数重复的极端情况——真遇到的话建议在生成IV后加一个时间戳异或的扰动避免完全依赖伪随机序列。4.3 日志分析的正确姿势从一行报错到定位根因BurpCrypto的日志是排查问题时的第一现场。默认情况下它在Error级别只输出最终报错但这往往不够——举个例子如果报错是TypeError: Cannot read property length of undefined你完全不知道是哪个对象没定义。所以我建议在自定义JS代码块的入口处手动加日志输出把input的值打印出来function encrypt(input) { java.lang.System.out.println([BurpCrypto DEBUG] input input); // ...后续逻辑 }这里利用的是Rhino引擎的能力可以直接调用Java的System.out输出到Burp的Extender日志控制台。这样每次执行时你都能看到插件实际传入了什么内容。很多“加密结果不对”的诡异问题其实源头都是——你代码里以为的明文格式和插件实际传进来的input根本不是一个东西。响应方向的调试也同理在整个函数入口打印responseBody的前200个字符看看有没有被截断、有没有额外编码。有一次我调一个响应解密规则前端明明返回的是Hex格式密文但插件把响应体按UTF-8字符串传进来Hex字符串本身没问题问题出在我忘了先做hexToBytes转换就直接按Base64去解了结果自然是乱码。把日志打开之后一眼就看出传进来的字符串是Hex字符集不用瞎猜。另一个建议是在代码块里不要写太多System.out.println。每个请求都打印几百字节的明文日志在Intruder跑几百个包时日志文件会迅速膨胀严重影响Burp性能。实用做法是设一个全局调试开关变量调试时置为true正常跑自动化时置为false只在出错分支里打关键上下文。5. 这套玩法的边界、局限与扩展思路5.1 能解的和不能解的适用边界BurpCrypto的自定义JS功能虽强但它不是万能的认清边界能帮你少走弯路。它擅长的是“逻辑你已经看懂、只差自动化执行”的加密场景——比如AESRSA混合、自定义Base64变种、加盐哈希、带时间戳的签名、动静态密钥组合这类。只要前端JS里能逆向出清晰的处理流程你基本上就能在代码块里复刻一个等效流程然后让Burp自动化跑。但它搞不定的是前端用了重度混淆或WebAssembly的加密逻辑。WASM编译出来的算法模块光靠JS引擎不一定能直接调起来你得先把WASM里的函数接口梳理清楚再在JS里模拟调用这个工作量和直接写Python脚本模拟差不多优势不大。加密算法与服务端会话状态强绑定。比如密钥由前一个接口动态下发且用后即焚这种情况下你要先做一次会话逻辑重放再在BurpCrypto里通过宏去获取密钥。这能做到但需要额外配置好Session Handling的宏跟BurpCrypto做联动链路长了出错率也会上升。非HTTP协议的加密流量比如WebSocket帧内加密、自定义TCP协议加密BurpCrypto的规则体系默认围绕HTTP请求/响应模型设计处理不了这类场景。5.2 配合其他工具组一套完整工作流实战中我从不会只依赖BurpCrypto一个工具。标准的处理流程是先用浏览器DevTools或抓包工具获取前端加密入口再用本地Node.js或在线JS调试环境逐行验证加密逻辑确认逻辑无误后把代码块移植到BurpCrypto中最后用Repeater手动验证一两次再放心地交给Intruder和Scanner去跑自动化。有一个很实用的组合是BurpCrypto处理“请求加密/响应解密”配合另一款流量比较工具做“加密前后对比”再配合Burp的宏做“动态参数同步”。三件套组合下来整个自动化的测试链路才完整。比如我前面提到的金融系统案例实际测试时我用了宏去请求一个心跳接口拿到服务器时间戳然后通过Session Handling把时间戳注入到请求体的明文里再由BurpCrypto的JS代码块完成加密封装。整套流程跑下来Intruder可以像测明文接口一样愉快地爆破而不用关心加密层。另一个值得尝试的扩展是把自定义JS代码块当作一个“加密算法仓库”来管理。测试过的项目多了以后你会发现很多系统的加密逻辑高度相似——都是AES对称加密只是密钥和IV不同。这时候可以把通用的AES加密函数提炼出来做成一个参数化的模板代码块不同项目只需要改密钥和算法模式再复制一份代码块就行。这比每次遇到新项目都从头逆向整个加密链要高效得多。最后说点实在的我用BurpCrypto处理自研加密接口也有不短的时间了最大的感受是这个插件的门槛不在工具本身而在你有没有把前端JS逆向逻辑吃透。工具只是把你的理解“翻译”成自动化流量真正的核心工作永远是打开DevTools、翻压缩JS、还原算法、验证输入输出。所以如果你刚接触我建议不要一上来就写复杂的混合加密代码块先从最简单的场景开始——找一个AES密钥写死在前端JS里的演示站点把加密流程跑通再逐步解锁RSA、动态密钥、响应解密这些进阶玩法。等你把几个典型项目的代码块沉淀下来再遇到自研加密接口你会觉得那只不过是多写几行JavaScript的事。
