Info

Info

Flags

Flags will follow the format: FLAG_[A-Za-z0-9/+]{32}

Servers

Each team will be assigned a server on which 5 challenges will be running, the team can access their specific server over SSH using the private key provided in their folder. bash ssh -i <key file> adctf<team server ip>
The challenge data and so on can be found in the folders /srv/<challenge-name> and in some cases privileges is need to access the folders, which can be achieved using the password password.

Server ips:
- Team 1 = 10.8.0.4
- Team 2 = 10.8.0.5
- Team 3 = 10.8.0.6

VPN

The VPN is using Wireguard just like Haaukins and each team will be provided with five configuration files. Distribute the configuration files between your team members, if multiple users connect using the same file the connection will break for both. To connect to the VPN run the command bellow in the folder where the configuration file is located, and ping the VPN server to ensure that the connection is established.

bash sudo wg-quick up <filename> ping 10.8.0.1

Submission

Flag submission is possible using FaustCTFs plaintext protocol on the address 10.11.2.2:6666

Definitions

  • Whitespace: consists of one or more space (ASCII 0x20) and/or tab (ASCII 0x09) characters.
  • Newline: is a single \n (ASCII 0x0a) character.
  • Flags: are sequences of arbitrary characters, except whitespace and newlines.

Protocol

The client connects to the server on a TCP port specified by the respective CTF. The server MAY send a welcome banner, consisting of anything except two subsequent newlines. The server MUST indicate that the welcome sequence has finished by sending two subsequent newlines (\n\n).

If a general error with the connection or its configuration renders the server inoperable, it MAY send an arbitrary error message and close the connection before sending the welcome sequence. The error message MUST NOT contain two subsequent newlines.

To submit a flag, the client MUST send the flag followed by a single newline. The server's response MUST consist of: - A repetition of the submitted flag
- Whitespace
- One of the response codes defined below
- Optionally: Whitespace, followed by a custom message consisting of any characters except newlines - Newline

During a single connection, the client MAY submit an arbitrary number of flags. When the client is finished, it MUST close the TCP connection. The server MAY close the connection on inactivity for a certain amount of time.

The client MAY send flags without waiting for the welcome sequence or responses to previously submitted flags. The server MAY send the responses in an arbitrary order; the connection between flags and responses can be derived from the flag repetition in the response.

Response codes

  • OK: The flag was valid, has been accepted by the server and will be considered for scoring.
  • DUP: The flag was already submitted before (by the same team).
  • OWN: The flag belongs to (i.e. is supposed to be protected by) the submitting team.
  • OLD: The flag has expired and cannot be submitted anymore.
  • INV: The flag is not valid.
  • ERR: The server encountered an internal error. It MAY close the TCP connection. Submission may be retried at a later point.

The server MUST implement OK, INV, and ERR. Other response codes are optional. The client MUST be able to handle all specified response codes. For extensibility, the client SHOULD be able to handle any response codes consisting of uppercase ASCII letters.

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