This page describes the technical details for participation in FAUST CTF. If you're looking for a guide on how to get the Vulnbox running, have a look at Basic Vulnbox Hosting.


The Vulnbox image will be available as an x86-64 image in OVA and QCOW2 format. This means it should run at a cloud provider (like GCP or DigitalOcean) or on your own hardware in VirtualBox, QEMU/KVM and other hypervisors. This year the image will be directly bootable without decryption. This way you can upload the image to a cloud provider without time pressure before the CTF. We recommend giving your VM at least 3 CPUs and 6 GB of RAM. Support for hardware virtualization (VT-x) is highly recommended.

A test image to check your virtualization setup (even before the Vulnbox image is released) will be available. To also check your networking setup, the VPN will be online as soon as the test image is available.


There are two different ways to connect to the competition network: Vulnbox and player VPN. Both are based on OpenVPN. When the VPNs are online, you will find OpenVPN configs containing the required secrets in the Files page of your team. We will generate new configs once a day, so you might have to wait some hours.

Vulnbox VPN

Connecting to this VPN is required. It provides access to the competition network for your Vulnbox, and optionally also your team. This is identical to the VPN setup from previous editions of FAUST CTF.

We offer two options for connecting the Vulnbox VM to this VPN. The one to use is selected when booting the Vulnbox for the first time:

  • Separate router machine: OpenVPN runs on a router box under your responsibility. This might be another VM, the box which hosts the hypervisor, or a completely different machine. The Vulnbox sets its IP statically and sends its traffic to the competition network through the router machine. This will allow you to use the remaining addresses from the Vulnbox network for connecting other machines through the same router, e.g. individual team members when playing on-site.
  • VPN on Vulnbox: OpenVPN runs on the Vulnbox itself. The Vulnbox's network interface receives an address via DHCP, which provides connectivity to the VPN gateway through the internet. This is simpler to configure, but does not allow to connect other machines through the same VPN connection. We recommend using the player VPN for individual team members.

We have no firewall in place to filter access to the Vulnbox network, so other teams can access the whole network unrestrictedly. This means that when also using it for team members' machines, you probably want to apply your own filtering.

The Vulnbox VPN uses topology p2p. This means that it's only suitable for connecting two hosts with each other and cannot be used to connect additional machines to the competition network, such as physically distanced players. Use the player VPN config for that.

Player VPN

The player VPN allows individual team members to connect to the team's own Vulnbox and the rest of the competition network.

It can be used in both on-site and remote setups, however, each player will have to use OpenVPN on their individual machine. Multiple connections can be made using the same player VPN config file.

The Vulnbox network and the player network have full access to each other, even before the start of the competition. But unlike on the Vulnbox network, hosts on the player VPN can not be accessed by other teams.

IP Ranges Overview

Graphic of network setup and IP ranges

This edition of FAUST CTF uses only IPv6 within the competition network:

  • Vulnbox VPN routing network (link-local only)
    • fe80::1%tun-faustctf: Competition gateway
    • fe80::2%tun-faustctf: Team router
  • Team networks: fd66:666:<team-number>::/48
    • Vulnbox network (VPN): fd66:666:<team-number>::/64
      • Gateway (separate router machine): fd66:666:<team-number>::1
      • Vulnbox: fd66:666:<team-number>::2
      • Testing Vulnbox: fd66:666:<team-number>::3
    • Player network (VPN): fd66:666:<team-number>:ffff::/64
  • Competition infrastructure: fd66:777::/32
    • Gateways (each team assigned to one)
      • fd66:777::11
      • fd66:777::12
      • fd66:777::13
      • fd66:777::14

Note: <team-number> refers to the team number in decimal format, i.e. IP addresses are constructed using string interpolation and without hex encoding of the number. For example, the Vulnbox of team 123 will have the address fd66:666:123::2.

Teams JSON

We provide a list of all active teams under The JSON contains assigned team numbers and flag ids, more information about both can be found below. The format is the following:

    "teams": [123, 456, 789],
    "flag_ids": {
        "service1": {
            "123": ["abc123", "def456"],
            "789": ["xxx", "yyy"]

Team Numbers

Since team numbers (and therefore IP ranges) are assigned randomly, it is not obvious which team networks are actually assigned. All assigned team numbers can be found in the Teams JSON (see above).

Flag IDs

Some (but not all) services come with flag IDs. Flag IDs are identifiers that help you access the flags that are still valid (like usernames or database IDs), without having to search through all of them. The current set of IDs will be provided in the Teams JSON (see above). Note that flag ids are only stored if the service is up and running. This might lead to active team numbers without flag ids.

NOP Team

A mostly unaltered Vulnbox to check your exploits against will be available with team number 1 (i.e. IP fd66:666:1::2). No vulnerabilities will be patched on this machine, but it will receive new flags (which of course won't be valid for submission) and be checked by the Gameserver.


You run attacks against other teams from your infrastructure, using your own tools.

Flag submission is possible using a plaintext protocol on from within the competition network. The protocol is specified in the CTF Gameserver documentation.

Flag Format

Flags match this regular expression: FAUST_[A-Za-z0-9/+]{32}

Service Status

The Gameserver's checks for the functioning of a service have one of these results:

  • up: Everything is working fine
  • flag not found: The service seems to be working, but flags from past ticks cannot be retrieved
  • recovering: Flags from more recent ticks can be retrieved, but (still valid) flags from previous ticks are missing
  • faulty: The service is reachable, but not working correctly
  • down: The service is not reachable at all, e.g. because the port is closed or a timeout occurred

Info on TCP and HTTP Connections

Please note that we're intercepting TCP connections to the services of other teams and so you won't get any TCP RST or ICMP unreachable packets. Instead, the connections will get closed (HTTP 503 and/or TCP FIN) after a timeout, or when the other Vulnbox is down. Note that when using netcat, you might not notice this immediately as the connection will be in half-open state. If you run into unexplainable TCP or HTTP issues, please contact us.