Q&A

Logic of the Features

Does "Static Container" in the challenge type mean that all participants share one container?

No. A static container, like a dynamic container, is unique to each participating team.

However, the content inside the static container is the same and there will be no dynamic flags. Flags submission can only be verified using one or more static flags hardcoded within the challenge configuration, hence the term "static".

What is the current teaming logic?

A user can participate in multiple teams. Each team member needs to enroll independently for each competition. The same player can participate in multiple contests with different team identities. When enrolling, player need to choose which team to participate with.

During the enrolling process, you can withdraw the enrolling while waiting for approval or if it is rejected. Once the registration is approved or banned, it cannot be withdrawn and the team cannot be changed, the team will be locked.

After the competition ends, the team will still be displayed as locked. If there are no other ongoing competitions and there is a need for personnel changes, the team will be automatically unlocked.

Does it support multi-container challenges?

Currently, due to compatibility issues with some container backends, multiple container challenges are not supported.

Is it possible to have multiple people editing a challenge at the same time?

Currently, the challenge editing logic is pulling data once, updating the database after local update. If multiple challenge admin edit the same challenge at the same time, it may cause data conflict or loss. The final data is subject to the last update, so it is not recommended for multiple people to edit the same challenge at the same time.

Does it support multi-stage challenges?

For multi-stage challenges, it is recommended to slice the flag during injection and distribute it to different locations or combine it in the desired way according to the requirements of the challenge.

Suggestions for Writing Challenge Descriptions

After a period of testing and usage, we have discovered a better way to write challenge descriptions. This method does not occupy the position of the attachment download button and provides more information about the challenge:

**Author:** GZTime
**Difficulty:** Baby
**Category:** Misc
 
---
 
Description of the challenge...

It should be noted that in the Markdown writing specification, if you need to break the line without starting a new paragraph, you need to add two spaces at the end of the line.

When writing challenge description on GZCTF, please pay attention to adding spaces after appropriate lines or when line break is needed. Also, please try to use line breaks if needed and ensure that the width of each line for short sentences is within 490px for better display result.

Platform Deployment Related

Suggestions for Deployment?

For users who want deploy to multi-node cluster, we recommend using K3s as the distribution of K8s, which can provide all the required features for deployment and is easy to install.

The most convenient deployment method in general is Docker + K3s separate deployment. You only need to execute docker-compose to complete the deployment of the GZCTF platform, and the deployment of K3s only requires exporting the kubeconfig after installation and mounting it to GZCTF.

If you need to deploy internally in a K3s cluster, you need to provide two PVCs (for the database and attachment storage), one ConfigMap (for storing appsettings.json), and one Secret (for storing the kube-config.yaml pointing to your own cluster). You can deploy the database and Redis as needed. If you are running only one GZCTF instance, you can choose not to deploy Redis.

After testing, due to database performance considerations, it is not recommended to use multi-instance distributed deployment. A single instance is sufficient to support most competitions.

Anything worth noting when deploying to a multi-node cluster?

GZCTF supports running multiple instances simultaneously, but requires the same database instance and Redis instance (multiple instances are mandatory) and shared storage (such as NFS) as PVC. The database instance and shared storage are used to ensure data consistency, and the Redis instance is used for caching synchronization of backend data and Scale-Out broadcasting of SignalR.

To ensure SignalR which is based on websockets can work as expected, it is necessary to configure Sticky Session in the load balancer.

Platform Furture Plan Related

Is there any plan to support AWD / AWDP competitions?

As a free and open-source project, GZCTF will not support AWDP.

Although the compatibility of the current envisioned solution is high enough to support it and it is not impossible to do, implementing it would require a significant amount of time and would likely require three additional projects. It is not acceptable to invest such a large amount of time and effort without any revenue. Additionally, if it were to be implemented, it could potentially impact the profit channels of some companies, which would not be ideal.

The Jeopardy mode itself is already capable of training, and fixing/patching can be achieved through direct teaching and distributing local experiment images. The original intention of GZCTF is to help universities better train their CTF teams, rather than hosting formal competitions. From an educational perspective, building an AWD platform is not that necessary. If you want to train AWD / AWD skills, it is better to participate in an onsite competition, which is another aspect of our consideration.