If a challenge contains a dockerized component, it shall not include multiple containers but just one.

If the challenge contains docker, the memory usage shall not surpass more than 1 GB of RAM, or contact HTB staff to request an exception.

Flags in the form of HTB{som3_t3xt}, or contact HTB staff to request an exception (for example not having the flag format but just the contents of it, because the exploitation process requires it).

A fully automated solver must be included, or contact HTB staff to request an exception.

Full writeup showing the intended path to own the challenge. A template is provided here (for machines, but also applicable to challenges). Please include an editable format of the write-up (markdown, word).

Description of important processes running on the challenge (ie, HTTP server using Flask, which is started by the service named flask. service).

Description of all automation, including copies of any scripts running on the challenge (crons, schedtasks, etc.)

If using Docker, please include Dockerfiles and other configuration files for containers.

Source code for any custom binaries.

Any details about how future patches might impact the exploit path (ie, this package used for the server deployment should be version pinned, as the exploit path requires this version’s vulnerability).

Try to keep the challenge realistic where possible.

Try to have the exploited code exist for some legit reason.

Don’t include things like todo.txt on a web server.

Don’t include rabbit holes without a good reason.

When picking passwords that are not intended to be cracked, please pick a strong passphrase (something solid but also not that hard to type).

Nothing inappropriate, trolly, offensive, political, or insulting.

Don’t require brute forcing other than above without talking to HTB staff. The challenge should not include unnecessary or unreasonable guessing.

The challenge should present a coherent path containing worthwhile elements. The task is to offer a rewarding challenge experience and “guide” the contestants through the design patterns to the solution.

Don’t make use of commercial (paid) software (including trials).

Do not include copyrighted material in any form.

Good code has a well-thought-out layout and architecture to make managing state obvious.

Don’t repeat code and do use a consistent name scheme.

Avoid writing long code lines and break down big tasks into smaller chunks.

If there’s a docker involved, keep the resulting docker image size as small as possible.

If there’s docker involved, keep your dockerized project simple to run. Just like ./build-docker.sh or similar.