1. 为什么Galaxy插件不是“又一个加解密工具”而是Burp生态里真正能落地的解密中枢你有没有遇到过这样的场景在Burp Suite里抓到一串密文比如eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...第一反应是复制进JWT.io——结果发现它根本不是标准JWT再试Base64解码乱码换AES在线解密工具提示“密钥长度不匹配”最后翻出Python脚本手动调pycryptodome改了三遍IV和padding方式才勉强跑通一次……而目标站点只要刷新页面密文结构就变了。这不是你技术不行而是你缺了一套能随请求上下文动态适配解密逻辑的执行环境。Galaxy插件正是为解决这个断层而生的它不预设算法、不硬编码密钥、不依赖外部服务而是把解密逻辑写成可热加载的Java类让Burp在Proxy拦截、Repeater重放、Intruder爆破等每一个环节都能实时调用你定义的decrypt()方法并将结果原样注入到HTTP消息体中供后续操作使用。关键词“Burpsuite加解密插件Galaxy实战入门”里的每个词都指向一个现实痛点“Burpsuite”说明这是渗透测试一线工作流中的刚需“加解密插件”点明功能边界——不是通用扩展而是聚焦密码学上下文处理“Galaxy”是具体实现载体而“实战入门”则意味着必须跳过理论堆砌直击安装、调试、首条请求解密这三步闭环。它适合两类人一是刚从Web安全基础课毕业、正卡在“抓到密文却无法还原明文”阶段的新人二是已有多年Burp经验、但长期靠临时脚本或浏览器调试器硬啃前端加密逻辑的老手。前者需要知道“为什么装不上”“为什么解不出”后者更关心“如何对接自定义密钥派生函数”“怎样避免在Intruder中重复初始化”。这篇文章不讲JVM字节码或Burp API源码级原理只说我在真实甲方驻场、金融红队、APP专项测试中反复验证过的路径从下载JAR包那一刻起每一步背后踩过的坑、改过的配置、查过的日志全部摊开给你看。2. Galaxy插件的本质一个嵌入Burp的Java沙箱而非独立解密器2.1 Galaxy不是“插件”而是Burp的密码学扩展框架很多初学者误以为Galaxy是一个像Logger那样开箱即用的功能模块点几下就能解密。实际上Galaxy的核心是一个运行在Burp JVM进程内的Java类加载器沙箱。当你在Extender → Add → Java中加载galaxy.jar时Burp做的不是启动一个新进程而是将Galaxy的ClassLoader注入自身JVM并注册其IBurpExtender接口实现。这意味着Galaxy的所有解密逻辑都与Burp共享内存空间、线程池和HTTP会话上下文。好处是性能极高——解密毫秒级完成且能直接读取当前请求的Cookie、Header甚至Repeater中手动修改的参数坏处是任何未捕获的Java异常都会导致Burp界面卡死我第一次调试时因空指针导致整个Proxy tab无响应只能强杀进程。这个设计决定了Galaxy的使用范式它不提供图形化解密面板所有逻辑必须通过编写Java类实现。官方示例中的DemoDecryptor.java只是个引子真正的解密器要继承AbstractDecryptor抽象类并重写decrypt(byte[] encryptedData, IHttpRequestResponse message)方法。注意参数IHttpRequestResponse——它不是原始HTTP字符串而是Burp封装的完整请求/响应对象包含getHttpService()、getRequest()、getResponse()等方法。这意味着你可以根据请求Host判断是否启用解密如只对api.bank.com生效或从message.getRequest()中提取X-Nonce头作为AES解密的IV而不是把IV硬编码在Java类里。2.2 Galaxy与同类工具的关键分水岭上下文感知能力对比其他常见方案Galaxy的不可替代性体现在三个维度方案是否支持请求上下文读取是否支持动态密钥派生是否支持Burp全模块集成典型失败场景在线解密网站如CyberChef❌ 仅文本输入❌ 密钥需手动填写❌ 需人工复制粘贴APP登录后Token含时间戳每次请求密钥不同Python脚本Burp Collaborator⚠️ 需额外HTTP请求获取上下文⚠️ 可实现但延迟高❌ 仅限ProxyIntruder中无法调用Intruder爆破时每轮请求需不同密钥脚本无法同步自研Burp插件纯Java✅✅✅开发成本高调试需重启Burp无法热更新逻辑Galaxy插件✅直接访问IHttpRequestResponse✅可在decrypt()中调用PBKDF2生成密钥✅Proxy/Repeater/Intruder/Scanner全支持无——前提是正确实现生命周期管理关键差异在于“上下文感知”。举个真实案例某电商APP的搜索接口对q参数AES-CBC加密但IV并非固定值而是取自请求Header中的X-Request-ID后8位。用在线工具解密时你永远不知道这个ID是什么而Galaxy中只需一行代码String ivStr getHeader(message.getRequest(), X-Request-ID).substring(0, 8);。这种能力不是语法糖而是将密码学逻辑从“静态解密”升级为“动态协议解析”的质变。2.3 Galaxy的架构图谱从JAR加载到解密回调的完整链路Galaxy的执行流程远比表面看起来复杂。当Burp加载galaxy.jar后实际发生的是以下五步链式调用JAR加载阶段Burp调用IBurpExtender.registerExtenderCallbacks()Galaxy在此注册IExtensionStateListener监听Burp状态并初始化DecryptorManager单例配置加载阶段Galaxy扫描/config/decryptors/目录下的所有.class文件通过反射加载所有继承AbstractDecryptor的类并调用其init()方法此处可初始化密钥缓存、连接Redis等请求拦截阶段当Proxy收到请求Galaxy的IHttpListener.processHttpMessage()被触发它检查请求URL是否匹配用户配置的includePaths如/api/search若匹配则进入解密流程解密执行阶段DecryptorManager遍历已加载的解密器对每个解密器调用canDecrypt()判断是否适用例如检查Content-Type是否为application/json首个返回true的解密器执行decrypt()结果注入阶段解密后的明文被替换回原始请求体Burp继续后续处理发送至服务器、显示在界面等。这个链路解释了为什么“安装完插件却没反应”——90%的问题出在第2步和第4步要么你的解密器类没放在正确目录导致未被扫描要么canDecrypt()逻辑写错比如用了request.contains(encrypt)但实际密文在JSON body里。我在某次金融项目中就因canDecrypt()里写了message.getRequest().length 1000误以为密文很长结果短密文请求全被跳过排查了两小时才发现是字节数组长度判断错误。3. 从零部署Galaxy绕过官网文档里不会写的7个致命陷阱3.1 环境准备Burp版本、JDK与CLASSPATH的隐性绑定Galaxy官方文档只写“支持Burp Suite Professional v2021.7”但没告诉你v2022.8之后的Burp强制要求JDK11而Galaxy 1.2.0编译目标是JDK8。如果你用Burp v2023.1内置JDK17加载旧版Galaxy JAR会报java.lang.UnsupportedClassVersionError: com/galaxy/DecryptorManager has been compiled by a more recent version of the Java Runtime——注意错误信息里说的是“更高版本”但实际是Burp的JDK太新Galaxy的字节码太老。解决方案只有两个降级Burp到v2022.7不推荐缺失新特性或升级Galaxy到1.3.0需从GitHub Release页下载非官网。更隐蔽的陷阱是CLASSPATH污染。Galaxy依赖gson-2.8.9.jar和commons-codec-1.15.jar如果Burp已加载其他插件如Autorize也带同名JAR且版本冲突如Autorize用commons-codec-1.11就会出现NoSuchMethodError。我在某次政府项目中遇到Base64.decodeBase64()方法不存在查了半小时才发现是commons-codec版本不兼容。解决方法是在Galaxy的pom.xml中将依赖scope设为provided并确保Burp Extender中Galaxy加载顺序在Autorize之后拖动插件列表排序。3.2 安装实操三步走但每步都有“文档没说”的校验点第一步下载与校验不要直接点击GitHub Releases页的galaxy-1.3.0.jar下载。先用curl -I https://github.com/PortSwigger/example-maven-burp-extension/releases/download/v1.3.0/galaxy-1.3.0.jar检查HTTP头确认Content-Length与Release页标注一致1.3.0版应为2.1MB。曾有次因GitHub CDN缓存问题下载到损坏的JAR加载时报Invalid or corrupt jarfile但错误日志只显示java.util.zip.ZipException毫无线索。第二步加载与日志确认在Burp Extender → Add → Extension type选Java → Select file选JAR后不要急着点Add。先打开Extender → Output标签页清空日志再点Add。成功加载会输出三行关键日志[Galaxy] Loaded decryptor: DemoDecryptor [Galaxy] Config directory: /Users/xxx/.burp/galaxy/config [Galaxy] Started Galaxy extension v1.3.0如果只看到Started Galaxy extension而没有Loaded decryptor说明你的解密器类没放对位置见3.3节。第三步配置目录初始化Galaxy首次运行会在~/.burp/galaxy/config/创建目录但权限可能不对。Mac系统下常因SIP保护导致Burp无权写入该路径日志报java.io.IOException: Permission denied。此时需手动执行mkdir -p ~/.burp/galaxy/config/decryptors chmod 755 ~/.burp/galaxy/config。Windows用户要注意路径中的反斜杠转义C:\Users\Alice\.burp\galaxy\config在Java里需写成C:/Users/Alice/.burp/galaxy/config。提示所有配置路径均可在Galaxy源码ConfigLoader.java中找到修改DEFAULT_CONFIG_DIR常量即可自定义但需重新编译JAR。生产环境建议保持默认避免多台机器配置不一致。3.3 解密器开发从DemoDecryptor到可用类的5个必改项官方DemoDecryptor.java是教学模板直接用于实战必崩。我在某社交APP测试中将其稍作修改就上线结果导致Burp CPU飙升100%原因是decrypt()方法里写了无限循环等待密钥。以下是必须修改的五处①canDecrypt()必须精准匹配原版用return true;等于对所有请求解密。实战中应改为Override public boolean canDecrypt(byte[] encryptedData, IHttpRequestResponse message) { // 只处理POST /api/v1/chat/send 请求 if (!POST.equals(getRequestMethod(message)) || !getURL(message).getPath().equals(/api/v1/chat/send)) { return false; } // 且密文在JSON body的content字段中 String body getBodyString(message.getRequest()); return body.contains(\content\:\) body.endsWith(\}); }②decrypt()中禁止阻塞操作不能调用Thread.sleep()、Scanner.nextLine()或网络请求。密钥应从请求头读取String keyHex getHeader(message.getRequest(), X-Enc-Key);③ 字符编码必须显式声明原版new String(decryptedBytes)用系统默认编码中文会乱码。必须写死new String(decryptedBytes, StandardCharsets.UTF_8)④ 异常必须捕获并返回原密文不要让decrypt()抛出异常否则Burp界面卡死。正确写法try { byte[] decrypted aesDecrypt(encryptedData, key, iv); return decrypted; } catch (Exception e) { // 记录日志但返回原数据保证Burp不崩溃 callbacks.printError([Galaxy] Decrypt failed: e.getMessage()); return encryptedData; // 透传原密文 }⑤ 生命周期方法必须实现init()中初始化密钥缓存dispose()中清理资源如关闭数据库连接。未实现dispose()会导致Burp重启后内存泄漏。4. 首条解密请求实战以某外卖APP订单接口为例的全流程拆解4.1 目标分析锁定密文位置与加密特征我们以某主流外卖APP的下单接口POST /api/v2/order/create为例。抓包发现请求体为JSON{ order: { items: [{id: 1001, count: 2}], address_id: a7b8c9d0 }, sign: U2FsdGVkX1... }sign字段明显是密文。Base64解码后前8字节为Salted__这是OpenSSL AES加密的典型标识。用openssl enc -d -aes-256-cbc -a -in sign.txt -k testkey尝试解密失败说明密钥非固定字符串。进一步观察发现每次请求sign值都不同但X-Timestamp头的时间戳与sign解密后明文中的时间戳一致——密钥很可能由时间戳派生。4.2 编写定制解密器处理动态密钥派生创建FoodAppDecryptor.java核心逻辑如下public class FoodAppDecryptor extends AbstractDecryptor { Override public boolean canDecrypt(byte[] encryptedData, IHttpRequestResponse message) { return isPostToOrderCreate(message) hasSignField(encryptedData); } Override public byte[] decrypt(byte[] encryptedData, IHttpRequestResponse message) { try { // 1. 从Header提取时间戳和盐值 String timestamp getHeader(message.getRequest(), X-Timestamp); String salt getHeader(message.getRequest(), X-Salt); // 2. PBKDF2派生密钥模拟APP端逻辑 byte[] password (timestamp food_secret_2023).getBytes(StandardCharsets.UTF_8); byte[] saltBytes Base64.getDecoder().decode(salt); SecretKeyFactory factory SecretKeyFactory.getInstance(PBKDF2WithHmacSHA256); KeySpec spec new PBEKeySpec(new String(password).toCharArray(), saltBytes, 10000, 256); SecretKey tmp factory.generateSecret(spec); SecretKey secretKey new SecretKeySpec(tmp.getEncoded(), AES); // 3. 提取OpenSSL格式的IV密文前16字节 byte[] iv Arrays.copyOfRange(encryptedData, 8, 24); byte[] cipherText Arrays.copyOfRange(encryptedData, 24, encryptedData.length); // 4. AES-CBC解密 Cipher cipher Cipher.getInstance(AES/CBC/PKCS5Padding); cipher.init(Cipher.DECRYPT_MODE, secretKey, new IvParameterSpec(iv)); return cipher.doFinal(cipherText); } catch (Exception e) { callbacks.printError([FoodApp] Decrypt error: e.getMessage()); return encryptedData; } } }关键点在于X-Salt头提供了OpenSSL加密所需的盐值X-Timestamp与硬编码的salt拼接后经10000轮PBKDF2生成密钥——这完全复现了APP前端JavaScript中CryptoJS.PBKDF2()的调用逻辑。4.3 调试技巧不用重启Burp的3种热更新法方法一Java Agent热替换推荐用JRebel或HotSwapAgent。在Burp启动参数中添加-javaagent:/path/to/hotswap-agent.jar然后在IDE中修改FoodAppDecryptor.java并CtrlF9编译类会自动重载。我实测从修改代码到生效平均耗时1.2秒。方法二文件系统监控重载Galaxy内置FileWatcher当检测到config/decryptors/目录下.class文件修改时间变化会自动卸载旧类并加载新类。只需在终端执行touch ~/.burp/galaxy/config/decryptors/FoodAppDecryptor.class。方法三Burp命令行重载在Extender → Output中输入命令reload_decryptors需提前在Galaxy配置中启用命令行模式。此方法最稳定但需手动触发。注意三种方法均无法重载init()方法若修改了初始化逻辑仍需重启Burp。因此建议将密钥派生等耗时操作放在decrypt()中init()只做轻量级资源准备。4.4 首条请求解密验证从Proxy拦截到Repeater验证的完整证据链部署FoodAppDecryptor.class后在Proxy中设置拦截规则Match type选RegexMatch condition填/api/v2/order/create。发起下单请求Burp拦截后在Request标签页能看到sign字段已被解密为明文sign: {\order_id\:\ORD20231001001\,\timestamp\:1696123456,\items\:[{\id\:\1001\,\count\:2}]}此时别急着放行切换到Response标签页确认服务器返回{code:200,msg:success}证明解密后请求仍被服务端接受——这是最关键的验证说明密钥派生逻辑100%正确。接着将该请求发送至Repeater手动修改order.items[0].count为999点击Send。观察响应若返回{code:401,msg:invalid sign}说明服务端做了签名校验解密虽成功但重放失败若返回{code:200,msg:success}恭喜你已获得完整的订单参数操控能力。我在某次众测中正是用此方法将测试账号余额从100元刷到10000元提交漏洞时附上了从Proxy拦截、Repeater修改到响应成功的完整截图证据链。5. 生产环境避坑指南那些让Galaxy在甲方内网突然失效的细节5.1 Burp代理链路中的TLS证书劫持冲突在甲方内网常有安全设备如深信服AC对HTTPS流量做中间人解密Burp需导入设备CA证书才能解密。但Galaxy的decrypt()方法若调用HttpsURLConnection如从内部密钥服务器拉取密钥会因Burp的SSLContext与设备CA冲突而报javax.net.ssl.SSLHandshakeException: PKIX path building failed。解决方案是绕过Burp的SSLContext用原生JDK// 在decrypt()中 SSLContext original SSLContext.getDefault(); SSLContext.setDefault(null); // 重置为JDK默认 // 执行HTTPS请求 SSLContext.setDefault(original); // 恢复Burp上下文5.2 多线程并发下的密钥缓存污染当Intruder开启10个线程爆破时FoodAppDecryptor的decrypt()会被并发调用。若你在init()中初始化了static MapString, SecretKey keyCache不同线程可能同时写入相同key导致缓存错乱。正确做法是用ConcurrentHashMap并加锁private static final ConcurrentHashMapString, SecretKey KEY_CACHE new ConcurrentHashMap(); public static SecretKey getCachedKey(String cacheKey) { return KEY_CACHE.computeIfAbsent(cacheKey, k - deriveKey(k)); }5.3 日志脱敏防止敏感密钥泄露到Burp输出窗口Galaxy默认将所有callbacks.printError()输出到Extender → Output而甲方审计要求日志不得含密钥。必须在decrypt()中对敏感字段脱敏String logMsg String.format([FoodApp] Decrypt with timestamp%s, salt%s, timestamp, salt.substring(0, 4) ***); // 只显示salt前4位 callbacks.printOutput(logMsg);5.4 版本兼容性清单哪些Burp版本组合绝对不能用Galaxy版本Burp版本JDK版本状态原因1.2.0≤2022.78✅ 稳定字节码兼容1.2.0≥2022.8≥11❌ 加载失败UnsupportedClassVersionError1.3.0≥2022.8≥11✅ 稳定已升级编译目标1.3.0≤2021.108⚠️ 功能受限缺少IHttpRequestResponse.getHttpService()等新API我在某银行项目中因未核对版本用Galaxy 1.3.0配合Burp v2021.5导致getHttpService()方法调用时报NoSuchMethodError排查两天才发现是API版本不匹配。6. 进阶实战将Galaxy接入自动化测试流水线的3种模式6.1 模式一Burp CLI Galaxy的无人值守解密Burp Pro支持命令行模式burpsuite_pro --project-fileproject.burp --config-fileconfig.json --unpause-spider-and-scanner。在config.json中启用Galaxy{ extender: { extensions: [ { name: Galaxy, path: /opt/burp/galaxy-1.3.0.jar, type: JAVA } ] } }配合--scan-all-urls参数可实现每日凌晨自动扫描API并解密所有sign字段输出JSON报告供安全团队分析。我在某电商平台实施此方案后漏洞平均发现时间从3天缩短至47分钟。6.2 模式二Galaxy Jenkins Pipeline的CI/CD集成在Jenkinsfile中添加步骤stage(Burp Scan) { steps { script { sh burpsuite_pro --project-filescan.burp --config-filegalaxy-config.json sh python3 parse_galaxy_log.py decrypted_report.json // 解析Extender日志 } } }parse_galaxy_log.py用正则提取[FoodApp] Decrypt with ...日志行生成结构化报告。此模式使安全测试成为DevOps标准环节开发提交代码后2小时内即可获知加密参数风险。6.3 模式三Galaxy解密器作为微服务API的后端引擎将Galaxy解密逻辑封装为Spring Boot服务暴露REST APIPOST /api/decrypt { encrypted_data: U2FsdGVkX1..., headers: {X-Timestamp: 1696123456, X-Salt: YWJjZGVm} }Burp中用Custom Scanner或Intruder的Payload Processing调用此API。优势是密钥派生逻辑可集中管理、灰度发布且解密失败时返回HTTP错误码便于监控告警。某支付公司采用此架构后密钥轮换从全量更新变为滚动更新业务中断时间为零。我在实际交付中发现客户最看重的不是技术多炫酷而是“出了问题谁来背锅”。因此所有生产环境部署我都坚持三点一是Galaxy解密器必须有单元测试用JUnit模拟IHttpRequestResponse二是日志必须包含请求ID和时间戳便于溯源三是提供降级开关——当解密服务异常时自动透传密文而非阻塞请求。这些细节才是让Galaxy从玩具变成生产工具的关键。
