Servers have a pre-installed set of vulnerable services.

The task of the participants is finding vulnerabilities, closing them on your own and using them to retrieve private information (flags) from your opponents. The game is continuously monitored by the checking jury system, regularly placing new flags on the teams' servers. In addition, the system accepts from the teams flags captured from the opponents.

It is difficult to give a complete set of rules for a CTF challenge, so these rules can change without notice at any moment prior to game start. That is why we recommend checking the rules one more time before the competition starts. Just in case :)

A group of people led by the captain. The size of any team except the visiting team shall not exceed 7 members.
A vulnerable application specially prepared by the development team for the game.
A string that matches regex: /^\w{31}=$/. The lifetime of a flag is limited, obsolete flags do not affect the scoring of points.
Check system:
An automatic system that logs flags into the services, checks that the services are working properly and awards points. Scores are shown on the scoreboard along with the status of the services.
A virtual machine that contains all the services. It is provided prior to game start in a form of game image. Game image is identical for all teams.
Game round:
A period of time for the check system to check and score all the teams. Game round usually takes about 1 minute.
A group of people that run the competition. Organizers do their best to provide a quality and fun event to all participants. Still, organizers are to penalize/disqualify teams for rules violation and to solve the critical situations not described in these rules. Teams should be prepared to meet such decisions with understanding. Also, organizers do determine the winner. In general, this decision is based on the scoreboard.
  • Do whatever they want within their network segment.
  • Most likely, the team would like to patch vulnerabilities in their services or block exploitation of vulnerabilities;
  • Attack other teams. Didn't expect that, huh?
  • Attack the game infrastructure operated by organizers;
  • Attack the game infrastructure operated by organizers;
  • Generate excessive amounts of traffic that pose a threat to network stability of any other team
The game starts by issuing the participants identical servers with a pre-defined set of vulnerable services. For the first hour after the game image is issued, the network segments are closed, and teams should concentrate on administering their game server and analysing the vulnerabilities. After this hour, the network opens and for 8 hours teams can exploit vulnerabilities to gain flags from other teams.

Key parameters in the scoring system are SLA and FlagPoints. Their values are individual for each service of each team. Team score is calculated as the sum of the products of the corresponding SLA and FlagPoints of all team's services.

SLA(team, service) is the fraction of the game time in which that service of that team was in the UP state. E.g. if the service was always UP, SLA would be 1. If 4 hours passed from the game start and the service was UP during the first hour and then was not UP for the rest 3 hours, SLA would be 0.25. At the beginning of the game, all teams have SLA equal to 1.

FlagPoints(team, service) is the number that correlates with a team's ‘understanding’ of the service. FlagPoints depend on the team attack capabilities (exploiting vulnerabilities against other teams) and defence capabilities (fixing vulnerabilities in their own service). At the beginning of the game, all teams have equal FlagPoints, and FlagPoints are updated every game round. If during the round the team failed both in attack and defence of the service, the corresponding FlagPoints will decrease, but will never reach 0. If during the round, the team was only able to defend the service, the corresponding FlagPoints will not change. If the team was able both to attack and to defend, the corresponding FlagPoints will grow.

Flag price is the number of FlagPoints got by attackers for stealing the flag from the victim.

Flag lifetime is the amount of time during which the flag must be available in the service for the check system. In RuCTF there are 15 rounds. Teams should steal the flag and post it to the check system until it is expired.

The maximum amount of points awarded/deducted for the flag is equal to the number of the participating teams. If a flag was stolen from a team that was higher on the scoreboard in the previous round, the team that has stolen the flag earns the maximum number of FlagPoints. If a flag was stolen from a team that was below your team on the scoreboard, the number of FlagPoints will decrease based on the difference in teams' positions on the scoreboard, but will never go below 1. FlagPoints for a flag are awarded when that flag expires.

Luckily, all this complex text can be expressed in pseudocode:

  def on_game_start(team):
    team.sla = [1] * number_of_services
    team.flagpoints = [0] * number_of_services

  def on_flag_post(attacker, flag):
    victim = flag.owner
    victim_pos = scoreboard[victim]
    attacker_pos = scoreboard[attacker]
    service = flag.service
    max = number_of_teams

  flag_score = attacker_pos > victim_pos ? max : exp(log(max) * (max - victim_pos) / (max - attacker_pos))

  attacker.flagpoints[service] += flag_score
  victim.flagpoints[service] -= min(victim.flagpoints[service], flag_score)

  def get_score(team):
    return sum(map(lambda x: x[0] * x[1],
    zip(team.sla, team.flagpoints)))

Apart from FlagPoints, SLA and total score, the scoreboard shows the state of each service. There are four possible states of a service:

UP — means that service is online, serves the requests, stores and returns flags and behaves as expected.
CORRUPT — means that service is online, but past flags cannot be retrieved.
MUMBLE — means that service is online, but behaves not as expected, e.g. if HTTP server listens the port, but doesn't respond on request.
DOWN — means that service is offline.