Supernova: a shellcode encryptor that re-emits the payload in twelve languages

What the tool actually does to your shellcode

Supernova is an open-source tool that empowers users to securely encrypt and/or obfuscate their raw shellcode. The input is a path to a raw shellcode file, and the output is the transformed bytes plus a source snippet in a language of your choosing.

The pipeline has three stages, and each is selected by its own flag. The -enc flag picks the cipher, with the help text listing ROT, XOR, RC4, AES, CHACHA20, DES and 3DES, and -key sets the key length size for encryption with a default of 1. The -obf flag picks the obfuscation mode, with IPV4, IPV6, MAC and UUID listed, and -lang picks the output language, with Nim, Rust, C, CSharp, Go, Python, PowerShell, Perl, VBA, Ruby, Java and Raw listed. The -input and -output flags name the files, -var names the dynamic variable with a default of shellcode, -debug turns on debug mode, and -version prints the version.

The two flags that do the real work are -enc and -obf, and they are independent. Encryption transforms the bytes so they no longer read as shellcode, and obfuscation then makes the encrypted bytes look like something else, an IPv4 address, an IPv6 address, a MAC address or a UUID.

The obfuscation modes are described in the project as techniques which make the malicious shellcode appear as if it were one of those things. That phrasing is direct about the intent, and it is the reason the project carries a disclaimer stating that the authors and contributors are not liable for any illegal use of the tool, that it is intended for educational purposes only, and that users are responsible for ensuring lawful usage.

Twelve output languages, and the point of the -lang flag

The feature that distinguishes Supernova from a common shellcode encryptor is the automatic conversion of the encrypted shellcode into formats compatible with various programming languages.

The list is C, C#, Rust, Nim, Golang, Python, Perl, PowerShell, VBA, Java, Ruby, and Raw. Several of the entries carry attribution in the project documentation. Golang is marked as a community request, VBA was implemented by @verydamptowel, and Raw was implemented by @y2qaq.

Raw is the interesting one to understand, because it is the baseline that the others derive from. It is the encrypted and obfuscated bytes with no language wrapper, which is what you would embed in a loader written in assembly or in a position-independent shellcode stub.

The reason the language list matters is about the delivery chain. A payload has to be decoded and executed by something, and that something is written in some language. If your loader is C, a Python emitter of the same bytes is not what you need, because the loader has to be able to parse the output. The -lang flag closes that gap by emitting the bytes in the form the loader expects, so the output is a string literal in the right language rather than a hex blob you have to convert by hand.

The -var flag ties into the same concern. It names the dynamic variable that holds the decoded payload, defaulting to shellcode, so the emitted snippet uses a variable name that matches what your loader expects to read.

The ciphers, and the crypto library behind them

The cipher list covers the classics and a couple of modern choices. ROT for the rotation ciphers, XOR, RC4, and AES in three CBC variants, AES-128-CBC, AES-192-CBC and AES-256-CBC, plus DES, 3DES and Chacha20. Chacha20 was implemented by @y2qaq, who also contributed the Raw output mode.

The Go module shows where the primitives come from. The only two direct dependencies are github.com/fatih/color at 1.19.0, which is for the coloured terminal output, and golang.org/x/crypto at 0.54.0, which is where the symmetric ciphers live. The x/crypto module is what provides the standard library's missing cipher implementations, and it is the reason the tool can offer DES, 3DES and ChaCha20 without vendoring a third party crypto library.

The module targets Go 1.25.0 and is named Supernova. The indirect dependencies are the usual companions of fatih/color, which is mattn/go-colorable, and mattn/go-isatty, plus golang.org/x/sys.

A technical caveat worth stating, because it applies to every tool of this shape. AES in CBC mode with a key and an IV that are both derived predictably, or a one-time pad where the key travels next to the ciphertext, is encoding rather than protection. The README's own phrase is encrypt and/or obfuscate, and the -key flag takes an integer key length with a default of 1, which is a number rather than a passphrase. For a payload whose secrecy depends on the loader not being found, the obfuscation mode and the loader's own stealth are what matter, and the cipher is a second layer on top.

Building it, and the prebuilt binaries

There are two ways to get the tool. The project ships precompiled binaries in the releases, or you can build it yourself, and the requirement in that case is Go installed on your system.

On Linux:

sudo apt install golang -y

On macOS:

brew install go

On Windows, the documentation points to the official Go website for the MSI. Then the repository steps are:

git clone https://github.com/nickvourd/Supernova.git
cd Supernova
go mod download
go build Supernova

The clone and the module download are unremarkable, and go build Supernova produces a single binary named after the module, which is why the module path is Supernova rather than a domain path. The repository is a single main package with Supernova.go at the root, plus a Test-Data directory, a Packages directory and a supernova_deb.deb, so the release artefacts for a Debian package are in the tree rather than produced by a CI pipeline you can inspect from the file listing.

The project is written in Golang, a cross-platform language, making it compatible with Windows, Linux and macOS, which is the practical reason the same tool runs in a Linux red team lab and on a Windows workstation.

The usage instructions are not in the README beyond the flag listing, which points at the project wiki for detailed usage instructions and examples of commands.

Where the boundaries are, and who this is for

The first limitation is the input side. Supernova takes a path to a raw shellcode, so it does not generate a payload, it does not produce a loader, and it does not execute anything. The output is a snippet for a loader you already have. Anyone expecting a payload generator will find a different tool.

The second limitation is the language list. Twelve languages is a lot, but it is not all of them, and a loader in a language outside that list gets the Raw output and the conversion work. The Nim and Golang entries exist because someone asked for them, which is a good way to understand the list: it is driven by what loaders people actually write.

The third limitation is the -key flag, an integer with a default of 1, and the fact that the key has to be known to whatever decodes the payload. Whatever the cipher, the decoding side needs the key, so the security of the output is bounded by where the key is stored and how well the loader hides it.

The fourth is the release story. The versions are named after films, v4.1 is Snake Guam from 2026-07-21, before that v4.0, 3 Stooges, from 2026-01-07, and v3.7, Blade Runner, from 2025-10-21. The last push was on 2026-07-21, and each of those versions has a published release. The project is MIT licensed, and the README asks that bugs be reported through the issue tracker, with a wiki for usage.

On who it is for, the project is explicit about its own framing. It was inspired during the malware development courses of MALDEV Academy, and it carries a disclaimer that it is intended for educational purposes only and that users are responsible for ensuring lawful usage. A researcher who has a payload and needs it in a specific language, inside an authorised engagement, is the intended user. Anyone using it to deliver an unauthorised payload is not, and no obfuscation mode in the tool changes that.

Editorial conclusion

Supernova suits a security researcher or red team operator who already has a working payload and needs to hand it to a loader in a particular language, and who wants the encryption and the byte reshaping chosen from a command line rather than hand-rolled. It is a poor fit if you are looking for a payload generator, because the tool takes shellcode as input and does not create any. Before using it, read the disclaimer in the project, which puts the responsibility for lawful use on the user, and treat the obfuscation modes as encoding of a payload rather than as any kind of protection, since the key travels alongside the output.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. nickvourd/Supernova on GitHub
4. README
5. Releases