Galaxy decrypts a site's own traffic through a hook, then hands the plaintext to your scanner

The hook is the product, and you write it yourself

Galaxy is a Burp Suite extension whose purpose is to make testing encrypted traffic as simple and efficient as testing plaintext. The README's own summary of the mechanism is that once you have written a custom hook, the plugin automatically decrypts the traffic that follows through the proxy.

The critical detail is the first half of that sentence. The hook is written by the tester, and it works by calling the application's own client-side code. The applicable scenarios say so explicitly: you can reverse the site's encryption and decryption logic, including by hooking into the client code, and you need to have some coding ability.

That reframes the tool entirely. Galaxy is not a deobfuscator, a key extractor or a crypto breaker. It is the plumbing that lets a hook you have written participate in the proxy's message flow, so that the request and response you see in Burp are the plaintext the application itself would have produced. The encryption is bypassed by reusing the target's own implementation, not by defeating it.

This is why the tool targets a narrow and legitimate case. A pentest where the target encrypts its payloads is otherwise painful: the scanner sees ciphertext, the scanner cannot find anything, and every manual request has to be decrypted by hand before it can be replayed. Galaxy closes that gap for a tester who has already done the hard part.

The project began in June 2024 according to the badge in the README, the primary language is Java, and the licence is Apache-2.0. The last push to the repository was on 2026-08-24 and the repository is not archived, with 3.3.13 released the same day.

Sending plaintext to sqlmap and xray, and which Burp modules it covers

The feature list has three entries, and the second one is the reason to use the tool at all.

The first is automated decryption of traffic, which is the hook mechanism described above. The third is support for several Burp modules, namely Intruder, Proxy, Repeater and Scanner. That coverage matters, because the value of decryption is that it applies to the whole toolchain rather than only to the proxy view.

The second is integration with security tools, specifically sqlmap and xray. The README describes both in the demo section with the same pattern: right click the decrypted plaintext request, send it to the tool, and the tool scans the plaintext request and gets a decrypted response back.

That is a workflow decision rather than a feature list. A scanner that only understands plaintext is useless against an encrypted application, and re-encrypting the payloads a scanner produces is a fiddly, error-prone step. Handing the plaintext across the boundary and receiving plaintext back removes the encryption from the scanner's path entirely.

Both integrations are therefore concrete and both have their own demonstration, which is a good sign for a plugin whose value is a workflow rather than a mechanism. The README also links a companion project, the GalaxyDemo range, as a project corresponding to the plugin, which is the target you would practise against.

The references section credits the projects it learned from, naming HaE, which is a hook based Burp extension for unencrypting encrypted traffic, and sqlmap4burp-plus-plus, which does the sqlmap integration. Both are the direct ancestors of what Galaxy does, and the credit is worth noting because it tells you where to look if you want the underlying technique rather than the packaged workflow.

Installing it needs Burp 2023.10.3.7, a JDK, and a read of the wiki

The installation section is short, and it flags one hard requirement.

The plugin is downloaded from the releases page, and installing it into Burp is the standard flow: Extensions, then Add, then Select File, then Next. Building it yourself is a Gradle operation, with the README saying to run the shadowJar task, so `gradlew shadowJar` from the project root.

The requirements note says the Burp version must be no lower than `v2023.10.3.7`. That is a meaningful floor, because a plugin built on the Burp extension API depends on the API version the extension was compiled against, and an old Burp will either refuse to load the extension or fail in confusing ways at runtime.

The tool links out to the Burp download page and to a JDK 21 download page, and the JDK requirement is the one that catches people out when they build rather than download. A Burp extension is a Java jar, and the JDK it is compiled with has to be new enough for the code in it.

There are three places the README tells you to look before you start, and that is a good sign about the difficulty of the task. There is a first use guide in the wiki, there are notes attached to the corresponding version in the release list, and the FAQ. The project also asks you to read the FAQ and the historical issues before filing a new one.

For support there is a WeChat contact with a request to mention Galaxy when adding them, which is a reasonable route for a project based in that ecosystem, alongside the GitHub issue tracker.

Where the boundary is, and why the demo range matters

The plugin sits close to a line, and the way the project is framed keeps it on the correct side of it.

The technique Galaxy implements is running the target's own client-side code inside the proxy so that its encryption and decryption can be applied to intercepted traffic. That is a legitimate technique for testing an application you have permission to assess, and it is how a tester confirms whether the encryption itself, rather than the business logic behind it, is holding up. It is also the technique an attacker would use, which is why the scope matters more here than for most plugins.

Every scenario the README lists is a penetration testing scenario: you found during a test that the site's HTTP messages are encrypted, the encryption logic is complex with combined algorithms, custom algorithms and dynamic keys, you want to use a scanner against plaintext requests, and you have been able to reverse the encryption and decryption logic. There is no scenario listed for targeting a third party without authorisation, and the companion GalaxyDemo range is a practice target, which is the right way to build the skill before pointing the tool at a client.

The dynamic key case deserves a note. Encryption that mixes a server-provided key into the request body is the case that breaks most manual approaches, because the key changes per request or per session and a static script cannot handle it. A hook that calls the target's own key derivation handles it for free, which is the strongest argument for the approach over a hand written decryptor.

For a team, the realistic reading is that Galaxy is a productivity tool for a specialist, not a feature to hand to a junior tester without a review of the scope of work they are doing. The hook is code you wrote against a target, and reviewing it is part of the engagement.

A small Java plugin with a Gradle build and a versioned changelog

The repository layout is what you would expect from a Burp extension of this size, and the build is Gradle with the Shadow plugin, which is what produces the fat jar that Burp loads.

The top level entries are `build.gradle`, `settings.gradle`, the Gradle wrapper with `gradlew` and `gradlew.bat`, a `gradle/` directory, `src/` for the source, `docs/` for documentation, a `CHANGELOG.md`, a `LICENSE`, and both `README.md` and `README_EN.md`.

The presence of a separate English README alongside the Chinese one is worth a mention, since the primary README is in Chinese and the English one is linked from the header alongside the wiki, the download page and the FAQ.

The release history is regular and versioned in the patch level, which is what you would expect from a tool that has to keep pace with Burp's own releases and with the crypto in whatever application the tester is attacking. Version 3.3.13 came on 2026-08-24, 3.3.12 on 2026-03-20 and 3.3.11 on 2026-02-09.

For anyone evaluating it, the honest assessment is that Galaxy is a convenience and an integration layer over a technique that requires real reverse engineering skill. The technique itself, hooking the client-side crypto, predates the plugin, and the plugin's contribution is making it work smoothly inside the Burp workflow with automated decryption and a clean handoff to the scanners that only understand plaintext.

That is a real contribution for a narrow task, and it is a task with an obvious ethical boundary. A hook that calls the target's own encryption code is only useful against an application you have been authorised to test, and the same hook technique applied to a system you have no permission to assess is not a testing activity. The project's own framing keeps it on the right side of that line, since every scenario listed is a penetration testing scenario.

Editorial conclusion

Adopt Galaxy if you are doing authorised penetration testing of an application that encrypts its HTTP bodies and you have already worked out the crypto, since the hook mechanism is the whole product and the tool does not reverse anything for you. Do not adopt it as a general traffic inspection tool, because it only helps once you can call the target's own code. Verify first that your Burp Suite version is at least v2023.10.3.7, that you have a matching JDK 21 available for building, and that the scope of the engagement you are working under permits hooking the application's client-side encryption routines.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. outlaws-bai/Galaxy on GitHub
4. README
5. Releases