logo

Academy

DocumentationSubmit a solution

Specific criteria

The extra criteria for each challenge type: programming, ctf-hacking and vbd-hacking.

1.1 programming solutions

  1. The folder of the challenge must have no solution in your language. Such a solution is an internal solution. Your pipeline fails when the folder already has a file with the extension of your solution. A reviewer closes your merge request when the folder has a different extension of the same language. Uniqueness gives the two conditions.

  2. The OTHERS.lst file of the challenge must have no solution in your language. Such a solution is an external solution. If one exists, your solution is not a unique solution.

  3. Fluid Attacks counts only one unique solution for each talent and each challenge.

  4. Put the lint command and its output in the prelude, at the start of the code. The prelude is the comment block before your first line of code. For a compiled language, put the compilation command and its output after the lint command.

    You must use the chgs-<ext> linter of the project. Fluid Attacks does not accept a direct compiler command or a linter from a different source. Run chgs list to see all the supported languages.

    $ nix run .#chgs-<ext> -- lint path/to/<username>.<ext>
    [INFO] Linting: /path/to/<username>.<ext>

    This is an example of a prelude for Rust, which is a compiled language:

    /*
    $ nix run .#chgs-rs -- lint code/spoj/1025/milogin.rs
    [INFO] Linting: /path/to/academy/code/spoj/1025/milogin.rs
    $ rustc code/spoj/1025/milogin.rs -O
    */
    
    My solution's first line.
  5. Put the commands that you executed and their output in the postlude, at the end of the code. The postlude is the comment block after your last line of code.

    My solution's last line.
    
      /*
      $ cat DATA.lst | ./skhorn
      over obese obese normal obese obese obese obese ...
      */
  6. If your solution reads a set of input data, do not write that data in the solution. The solution must read the DATA.lst file of the challenge folder from stdin. If that file does not exist, add it to your commit. The existing file sometimes does not agree with your solution. You can change it in the same commit.

  7. The CI examines almost all the source code, and it measures good habits in the code. The nix/pkgs folder gives the linters that the CI uses now.

  8. You can use an AI tool. GitHub Copilot, ChatGPT and Claude are examples. But you must declare the tool in the prelude of the source code:

    // model, client
    // prompt: XXXX

    Example:

    // opus 4.6, claude code
    // prompt: make a program that XXXX

    Fluid Attacks does not accept a solution that a program made, with no human author and with no human review. Compilation and transpilation are examples of that transformation.

  9. If you send more than one solution for the same challenge, only one of them counts as unique.

  10. Your solution must use only the standard library of the language. Some languages, such as Rust, also permit specific libraries. Libraries gives the list.

  11. Each solution must use the functional programming paradigm. Thus, do not use a GLOBAL_VAR, state such as a class, a FOR loop, a WHILE loop, or mutation. If a reviewer finds one of these, the reviewer closes the merge request. Correct the solution and send it in a new merge request. General criteria gives this rule.

  12. All solutions must use an indent of 2 spaces. Use a different indent only when the language does not permit 2 spaces.

NOTE: Obey these instructions. They prevent corrections, and thus they save your time.

1.2 ctf-hacking and vbd-hacking solutions

  1. The folder of the challenge in the repository must have no Gherkin solution. A Gherkin solution is a *.feature file.

  2. The OTHERS.lst file of the challenge must have no link to an external solution.

  3. The challenge must be a technical challenge from WeChall or from a related site. A mathematical challenge or a riddle is not applicable.

1.3 ctf-hacking solutions

  1. The solution must obey the template hacking-challenges.feature.

  2. The flag of a ctf-hacking challenge must be implicit in the .feature file. Do not write the flag.

  3. Every shell command in a """...""" docstring block must start with $ . A line of tool output must not have this prefix. This rule is applicable to every command in every scenario, with no exception.

    """
    $ nmap -p- 10.10.10.1
    22/tcp open  ssh
    80/tcp open  http
    """

1.4 vbd-hacking solutions

  1. The solution must obey the template hacking-vbd.feature.

  2. The challenge must exploit a ToE from one of these three lists:

On this page