RuCTFE 2011 Rules

Contents The spirit of the challenge
Gaining points

The spirit of the challenge

It is difficult to give a complete set of rules of CTF challenge. Aim of this challenge is not to find out the best. True professionals are incomparable. The main goal is to share experience and knowlege in the field of computer security. Nevertheless, the luckiest team will become a winner :)

Destructive attacks (like "rm -rf /"), as well as DoS attacks with a great amount of garbage traffic, contradict with the spirit of the challenge.

Be ready for any operating system and any programming language. You're professionals, aren't you?



A group of people with a captain.


A vulnerable application written for the challenge.


A string that matches regex: /^\w{31}=$/.

Team is given points for

  • correct work of their services;
  • capturing flags from others teams' services;
  • sending advisories, which contain description of vulnerability, patch and exploit;
  • solving quests;
  • organizers special decision.
More details about scoring system here.

Teams are prohibited to:

  • filter (by IP or in any other way) other teams;
  • generate large amount of network traffic;
  • run DoS attacks with large amount of network traffic;
  • run destructive attacks (e.g., "rm -rf /");
  • attack teams outside VPN;
  • attack the game infrastructure services provided by organizers.


Teams may patch vulnerabilities in ther services or block exploitation of vulnerabilities.


Advisory is a message on vulnerability in the game image. Organizers evaluate advisories, teams earn scores for them. For complete vulnerability description one can get maximum of 10 points. Maximal score for the advisory depends on the complexity of vulnerability described, its difficulty to find, exploit and patch.

If there is another scored advisory on the same vulnerability then the score for your advisory is difference between these two advisories (but not less that 0). Advisory is published to all teams after 30 minutes after scoring. Advisories will be accepted until one hour before the end of the game.

Full description of vulnerability consists of


  • The class of vulnerability (SQLi, buffer overflow, XSS, misconfiguration ...)
  • Vulnerable part of the code or protocol or logic
  • Description of what you can do with this issue (steal a flag, cookie, other private information, execute code, etc.)


It may be in the following forms:

  • diff (can be in hex mode)
  • location (line or offset) and fix


The source code that exploits this vulnerability on a remote server. The exploit should be at least in a proof of concept format.


  • may specify rules more precisely at any moment before the challenge starts;
  • may penalize/disqualify team for rules violation;
  • determine the winner. Descision is based on teams' earned points.


Teams should meet organizers decisions in critical situations, which may not have been listed here, with understanding.
Still organizers do their best to steer clear of such.