xiv3r/Burpsuite-Professional: a Shell installer that repackages Burp Suite Pro

What xiv3r/Burpsuite-Professional actually is, and who it is for

The repository does not contain Burp Suite. It contains packaging. The top level holds install.sh, install.ps1, install_macos.sh, update.sh, help.sh, flake.nix, default.nix, loader.jar and a pair of icon files, which is the profile of a distribution wrapper rather than an application. The README frames the target audience in one sentence: Burp Suite Professional is described as "the web security tester's toolkit of choice", and the scripts exist so that a tester on Linux, NixOS, Windows or macOS does not have to assemble the runtime, the JAR and a launcher by hand.

The person this suits is someone who already works with Burp Suite Pro and wants a repeatable way to put it on a machine. The person it does not suit is anyone looking for a free substitute for a PortSwigger subscription. The repository has no licence file, and its own setup instructions include a manual activation exchange, so it is a convenience layer wrapped around a commercial product, not an alternative to it.

How the install scripts, the loader and the JAR fit together

The data flow is short and worth tracing before you run anything. On Linux, install.sh is fetched over HTTPS from raw.githubusercontent.com and piped into sudo bash. That script is what pulls down the Burp Suite JAR from the PortSwigger CDN and places loader.jar alongside it. The NixOS path is different in kind: flake.nix exposes a package, and the README notes that loader.jar is symlinked to burpsuite.jar "so burpsuite recognizes the license keys". That symlink is the mechanism, and it is the one detail in the whole repository that explains why the loader works at all.

The Windows path ships install.ps1 plus a Burp-Suite-Pro.vbs launcher and burp_suite.ico, and the macOS path ships install_macos.sh plus a generated burp shell script. Four platforms, four entry points, one shared idea: get the JAR, put the loader next to it, start Java with the right options. Nothing here patches the Burp Suite binary in the sense of rebuilding it; the wrapper sits between you and the upstream download.

Installing on Linux and running burpsuitepro for the first time

The README gives a single line for Debian-derived systems. It updates the package index, installs wget, then downloads install.sh and runs it as root.

sudo apt update && sudo apt install -y wget && wget -qO- https://raw.githubusercontent.com/xiv3r/Burpsuite-Professional/main/install.sh | sudo bash

After that finishes, the documented command to start the application is a single word. If the shell cannot find it, the install did not complete rather than the command being wrong.

burpsuitepro

There is an update path, marked optional in the README. It removes the checked-out directory and re-runs a separate update script. Note that the removal happens in your home directory, so any local notes you kept inside that folder go with it.

cd && sudo rm -rf Burpsuite-Professional && wget -qO- https://raw.githubusercontent.com/xiv3r/Burpsuite-Professional/refs/heads/main/update.sh | sudo bash

If the application starts but behaves oddly, the README points at the Java runtime and asks you to pick the default OpenJDK entry interactively. Only the default is documented as supported.

sudo update-alternatives --config java

The activation step follows the install: the README instructs you to copy the license from the loader into Burp Suite under manual activation, then move the Burp Suite request key to the loader and the response key back. That exchange is manual, and the README does not document an automated alternative.

NixOS, Windows and macOS: three more entry points with different failure modes

On NixOS the repository is consumed as a flake input. The README shows adding it under inputs with nixpkgs following your own, then installing inputs.burpsuitepro.packages.${system}.default through either environment.systemPackages or home.packages. The README adds a constraint that is easy to miss: the loader command is available from the terminal only, so a desktop launcher is not part of the NixOS story.

inputs = {
  burpsuitepro = {
    type = "github";
    owner = "xiv3r";
    repo = "Burpsuite-Professional";
    inputs.nixpkgs.follows = "nixpkgs";
  };
};

Windows is the least automated of the four. You create C:\Burp, download the repository zip, extract install.ps1 into that directory, relax the execution policy for the current process, change into the directory and run the script.

Set-ExecutionPolicy -ExecutionPolicy bypass -Scope process
cd C:\Burp
./install.ps1

Relaxing the execution policy with -Scope process limits the change to that one PowerShell session, which is the right scope for a one-off install. The remaining Windows steps are manual: point Burp-Suite-Pro.vbs at burp-suite.ico, create a desktop shortcut, and copy the .vbs into C:\ProgramData\Microsoft\Windows\Start Menu\Programs if you want a Start Menu entry.

macOS installs Homebrew and openjdk@17 first, then runs install_macos.sh, then makes the generated burp script executable and copies it to /usr/local/bin. The README's own note is the sharpest limitation in the file: the script uses $(pwd) to reference the JARs, so it only works from the directory that holds loader.jar and burpsuite_pro_v2025.5.6.jar, and global use requires replacing $(pwd) with absolute paths yourself.

Where this wrapper breaks, and when it is the wrong tool

The macOS launcher is the clearest example. A script that resolves JAR paths relative to the current directory will fail the moment you run burp from anywhere else, and the README acknowledges this rather than fixing it. If you move the installation directory, the launcher needs editing.

The Linux update path is the second rough edge. It deletes the working directory before re-downloading, which means the update is not incremental and any local state inside that folder is lost. There is no documented rollback, so a bad update leaves you re-running the install line.

The third limitation is not technical. The repository has no licence file and no stated terms, while its setup instructions depend on a keygen loader whose credit line points to h3110w0r1d-y/BurpLoaderKeygen. The README does not explain what a PortSwigger subscription entitles you to do with a self-managed JAR, and it does not discuss whether running the loader is permitted under your agreement with PortSwigger. That question is outside what the repository answers, and it is the reason to treat this as a tool for people who already have an entitlement rather than a way to avoid buying one. If you need a no-cost option, Burp Suite Community Edition is the supported route, and this repository is the wrong tool for that job.

How this differs from installing Burp Suite the official way

PortSwigger's own installer and the Community Edition download are the direct alternative, and the difference is architectural rather than cosmetic. The official route gives you a signed installer or a JAR plus a licence key you enter into the application. This repository gives you a shell script that fetches the JAR for you and then asks you to shuttle a request key and a response key between Burp Suite and loader.jar.

That extra step buys cross-platform convenience. The official Windows installer does not produce a .vbs launcher with a custom icon, and it does not give you a NixOS flake. What it does give you is a supported upgrade path and a vendor relationship. The trade is straightforward: you accept a manual activation dance and an unaudited third-party loader in exchange for one-command setup on four platforms, including NixOS, which the official distribution does not target at all.

If your environment forbids third-party loaders, or if you need vendor support when something breaks, the official installer is the correct choice and this repository adds nothing.

Maintenance, updates and what the licence situation means in practice

The last push to the default branch was on 2026-07-27, and the repository is not archived. The most recent release listed is burpsuite-pro, dated 2025-10-02. The README references burpsuite_pro_v2025.5.6.jar in its macOS notes, and the repository title says 2026, so the version strings across the README and the release metadata do not line up. That is worth knowing before you assume an update script will hand you the newest JAR.

The upgrade cost is low in effort and non-trivial in risk. Rerunning update.sh re-downloads rather than patching, so the main cost is redoing any manual configuration you made inside the installation directory. There is no documented rollback and no changelog in the repository, so you cannot tell from the README what changed between releases.

The licence position is the part to settle before you install. The repository carries no licence identifier, which means you have no grant of rights from the repository itself, and the loader it depends on comes from a separate project. The README does not state the terms under which loader.jar may be used or redistributed. That is a question for PortSwigger's terms and for whoever maintains the loader, not something this repository resolves, and it is not legal advice to say so.

Editorial conclusion

Use this repository only if you already hold a valid Burp Suite Professional licence and want the JAR fetched and launched for you on Linux, NixOS, Windows or macOS, and read install.sh, install.ps1 and install_macos.sh before running any of them with sudo. Do not use it if you expect a lawful free copy of Burp Suite Pro: the README's own activation note routes a request key through loader.jar, and the repository carries no licence file, so the terms of use are yours to establish before you install anything. Verify first whether your PortSwigger entitlement covers a self-managed JAR, then check which Java runtime update-alternatives points at, then confirm the JAR filename your install produced matches the one the macOS launcher script expects.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. xiv3r/Burpsuite-Professional on GitHub