reverse-shell-generator: a browser page that assembles payloads instead of running them

A static page that builds strings rather than running anything

There is no backend in the conventional sense and no install step for the person using it. 0dayCTF/reverse-shell-generator is a single page, `index.html`, alongside a `js/` directory and a `css/` directory, and the hosted instance at revshells.com serves roughly that. What the page does is string assembly: you choose a language or platform, choose the listener command, and it renders a one-liner you copy into a terminal. Nothing is sent anywhere. That boundary matters more than the feature list, because it decides whether you can run the tool on a network where outbound traffic would be noticed.

The README describes it as a hosted reverse shell generator with a ton of functionality and puts the parenthetical "great for CTFs" right in the project description. The repository topics agree: ctf, generator, hacking, revshell, security and tryhackme. So the intended audience is someone in a lab or a capture the flag box, not someone looking for a payload delivery service.

Reading the repository tree before the feature list

The tree is short enough to take in one pass: `.all-contributorsrc`, `.gitignore`, `.parcelrc`, `Dockerfile`, `LICENSE`, `README.md`, `assets/`, `css/`, `favicon.ico`, `index.html`, `js/`, `netlify.toml`, `package.json`, `parcel-transformer-obfuscation/` and `server_functions/`. Two entries carry most of the weight.

The first is `package.json`, which is a very small Parcel configuration. Note that the obfuscation transformer is referenced with a `file:` path, so it is a local package inside `parcel-transformer-obfuscation/` rather than something downloaded from a registry at build time, and source maps are switched off for the default target.

{
  "source": "index.html",
  "scripts": {
    "build": "rm -rf ./dist && ./node_modules/.bin/parcel build"
  },
  "targets": {
    "default": {
      "sourceMap": false
    }
  }
}

The second is `server_functions/`, which is the only server-side code in the repository, and it exists for one feature described below. The README also credits 16 contributors, which matches a project built and maintained by a community rather than a company.

Bumping the listening port and encoding the payload

The feature list is where this project is at its most concrete. You get common listeners and reverse shells generated on demand, a save button that downloads the payload from the browser, a button to increment the listening port number by 1, URI and Base64 encoding, and LocalStorage to persist your configuration between visits. It also ships Dark, Light and Meme Modes, which tells you something about the audience.

The port increment button is the feature a working operator would notice first. In practice you start a listener on one port, paste your IP, generate the shell, and then move to the next port because something else grabbed yours. Making that a click rather than a retyped number is a small thing that removes a whole class of silly errors.

The payload definitions themselves live in `js/`, and the README does not enumerate them. What it does say is that both listeners and shells are covered, plus a HoaxShell integration with a custom listener, crediting the t3l3machus project and linking to the hoaxshell repository's revshells directory for the listener documentation. That external link is where the detail lives, not in this README.

Raw mode is the only reason a server exists

Raw mode does something the rest of the page cannot: it makes the generated payload retrievable from a URL so you can curl it onto a target machine instead of typing it by hand. That requires a server function, which is what `server_functions/` and `netlify.toml` are for.

The README's development instruction is a single command, and it is specific about when to use it:

npx netlify dev

That runs the Netlify CLI in local development mode, which serves the static page and the server functions together on one port. It is the correct command if you intend to modify raw link support, because a plain static server will serve the page but the raw links will fail. The README does not document the behaviour of raw mode when the server functions are absent, which is the first thing worth finding out yourself.

One thing to keep in mind when you decide whether this fits your setup: the raw link is a hosted feature. If you fork this and deploy it on a host that does not run Netlify functions, that part needs replacing.

Spinning up your own copy with the bundled Dockerfile

Local hosting is three commands, because the Dockerfile is three lines. The README gives them directly, and the image name contains an underscore rather than a hyphen, which matters if you script around it.

docker build -t reverse_shell_generator .

docker run -d -p 80:80 reverse_shell_generator

After that the README says to browse to `http://localhost:80`. The container contents explain why there is nothing more to configure:

FROM nginx:alpine
COPY . /usr/share/nginx/html
EXPOSE 80
+# nginx base image provides the default CMD

Two consequences follow from that Dockerfile. First, you are serving the checked-out working tree, not a built `dist/` directory, so the obfuscated Parcel output described in `package.json` is not what a Docker user gets. Second, because the comment in the Dockerfile notes that the nginx base image supplies the default command, there is no entrypoint to override and nothing to break.

This is a genuinely useful setup for a lab machine or an airgapped training environment, where reaching out to revshells.com would be either slow or undesirable.

Where the README stops, and what it leaves you to decide

The README is short and does not pretend otherwise. There is no releases page on GitHub, so there is no version number to pin and nothing to diff between versions. The last push was on 2026-04-27, which is recent enough that the payload list changes, and it is not an archived repository. Licensing is MIT, which is about as permissive as it gets for code you might want to fold into a training platform.

The payload catalogue is the real gap. The page claims listeners and shells across many languages, but a reader deciding whether this fits cannot tell from the repository which language pairs are covered or how current the quirks are for each one. Related searches for this tool include "Aspx reverse shell pentestmonkey" and "Reverse shell cheat sheet pentestmonkey", which points at a reader who arrived wanting a static cheat sheet rather than a generator. That is the real comparison: a cheat sheet is faster to read and never out of date in the same way, while a generator is faster to use once you already know which one you need.

So the honest summary is that this is a well-liked, actively used utility with a small, readable codebase, and the value is in the interface rather than in anything clever happening underneath it.

Editorial conclusion

Treat this as a convenience tool for people who already know what a listener and a callback address are, not as a way to learn them. The hosted instance at revshells.com does the whole job with no install, and the local Docker path exists for when you want the same page offline in a lab. The repository has no releases, so there is no versioned artifact to pin, and the last push was on 2026-04-27, which tells you how quickly the payload list moves. Start at the hosted page with a listener you already have running, then read the README's raw mode section and the Dockerfile if you plan to host your own copy.

Frequently asked questions

Official sources

1. 0dayCTF/reverse-shell-generator on GitHub
2. Issues
3. License: MIT
4. Project website
5. README