Specific Criteria

1.1 programming solutions

1. A solution in the same language you chose must not exist already in the challenge folder (internal solution). Otherwise your solution won't count as a unique solution.

2. A solution in the same language you chose must not exist already in OTHERS.lst file within the challenge folder (external solution). Otherwise your solution won't count as a unique solution.

3. Only one unique solution per user per challenge is counted.

4. The strictest compilation (optional for interpreted languages) and strictest linting (mandatory for all languages) commands used and their output must be included in the prelude at the beginning of the code.

   /*
     $ cargo clippy #linting
     $ rustup run nightly #compilation
     Compiling milogin v0.1.0 (file:///../skhorn)
     Finished dev [unoptimized + debuginfo] target(s) in 0.22 secs
     $ rustc milogin.rs
     $
     */
   
     My solution's first line.

5. The execution commands used and their output must be included in the postlude at the end of the code

   My solution's last line.
   
     /*
     $ cat DATA.lst | ./skhorn
     over obese obese normal obese obese obese obese ...
     */

6. If the solution takes a set of input data, such input must not be hardcoded into the solution. Meaning that the solution must read from stdin the DATA.lst file located in the challenge directory. If such file does not exist, you must include it in your commit

7. Most source codes go through an evaluation process (a.k.a as Pipelines or Jobs) in order to evaluate good coding habits. You can check what linters are currently integrated into our CI (opens in a new tab) in this link (opens in a new tab)

8. Source code must be created by hand (manually). Solutions built as a result of program transformation (compilation, transpilation, etc) or any other kind of automatic generation are not allowed.

9. When presenting several solutions to the same challenge, only one counts as unique.

10. The solutions only allow libraries from the standard library, we only allow specific libs in some langs like rust, you can find out in the apart for that.

11. When you are submitting a solution make sure to always use the functional programming paradigm. In order to promote the use of this paradigm on your solutions, you are asked to avoid using GLOBAL_VARS, state (classes. etc), FOR and WHILE loops, and mutation. When the use of some of these is evident, the MR will be closed and you will be asked to make the respective corrections.

12. All solutions must use an indent of 2 spaces unless the language does not allow that.

1.2 ctf-hacking and vbd-hacking solutions

1. They must not have a solution in Gherkin (*.feature) in the repository (challenge folder).

2. They must not have an external indexed solution (links OTHERS.lst of the challenge).

3. They must be challenges that require a technical level (not mathematical nor riddle) from WeChall (opens in a new tab) or its related sites.

1.3 ctf-hacking solutions

1. They must follow the template hacking-challenges.feature

2. The flag for ctf-hacking challenges must be censored in the evidences and it must be implicit inside the .feature file

1.4 vbd-hacking solutions

1. They must follow the template hacking-vbd.feature

2. They must be challenges that Require exploiting ToE listed in:

3. OWASP Off-Line apps (opens in a new tab)

4. OWASP VMs / ISOs (opens in a new tab)

1.OWASP On-Line apps (opens in a new tab)