1. General criteria
Before sending an MR please verify that you meet the following criteria:
You should only work on a branch whose name is exactly your username in Gitlab.
All files related to a challenge’s solution must respect the Structure
If the solutions require additional files, they must be included in the corresponding challenge directory.
Each challenge solution must be submitted with 10 external solutions (10 URLs in OTHERS.lst files).
You are allowed to add new (just make sure to follow the Structure):
- Challenge sites or challenges for existing sites for programming and ctf-hacking
- ToE's or new vulnerabilities to existing ToE's for vbd-hacking
If you add new sites/ToE's or challenges/vulnerabilities, you are allowed to add solutions to their OTHERS.lst files
The solution and all files associated with it must be all sent in 1 commit.
The commit for each solution must be sent in only 1 MR.
The MR must only be sent once your branch has successfully finished integrating (green).
If the MR is rejected it must not be reopened. The errors must be fixed and the solution sent in a new MR.
The commit message to send the solution must follow one of the templates according to the type of the solution:
Challenge solutions, regardless if they are programming, ctf-hacking or vbd-hacking must always meet the following style guideline.
2. Specific criteria
2.1 programming solutions
A solution in the same language you chose (in the challenge folder) must not exist already.
They must not have an external indexed solution (links OTHERS.lst of the challenge) for the language chosen by you.
Only one unique solution per user per challenge is counted.
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.
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 ... */
If the solution takes a set of input data, such input must not be hardcoded into the solution. Meaning that the solution must read the DATA.lst file located in the challenge directory from stdin. If such file does not exist, you must include it in your commit
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.
When presenting several solutions to the same challenge, only one count as unique.
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.
When you are submitting a solution make sure that you avoid using GLOBAL_VARS and state (classes. etc) and always abstract using functional programming in your solution.
2.2 ctf-hacking and vbd-hacking solutions
They must not have a solution in Gherkin (*.feature) in the repository (challenge folder).
They must not have an external indexed solution (links OTHERS.lst of the challenge).
They must be challenges that require a technical level (not mathematical nor riddle) from WeChall or its related sites.
2.3 ctf-hacking solutions
- They must follow the template hacking-challenges.feature
2.4 vbd-hacking solutions
They must follow the template hacking-vbd.feature
They must be challenges that Require exploiting ToE listed in:
3. OTHERS.lst links rules
In this section, you will find all the rules that apply to the 10 OTHERS.lst URL's you must provide when uploading a MR:
- They must be direct links (HTTP 200) without redirection (HTTP 301/302).
- They don’t need to be solutions for the same challenge that you solved or the same website.
- They must be hacking links if you solved a hacking challenge.
- The links must be unique, in other words, two links can't be the same in an OTHERS.lst file.
- If you send a vbd-hacking solution, the external solutions must be vbd-hacking solutions.
- If you send a ctf-hacking solution, the external solutions can be ctf-hacking or vbd-hacking solutions.
- They must be programming solutions
if you solved a programming challenge.
- You must not add external solutions for a language that already has an external solution.
- Within the OTHERS of a programming solution the URLs must be ordered alphabetically by extension.
- Programming OTHERS must only include sources from repositories; no websites, no video tutorials. The URL to the external solution must be provided on its raw version: raw.githubusercontent.com.
All solutions, if compliant with all the previously given requirements, will have a unique status.
For a programming solution to lose its uniqueness:
- An external solution in the same language must be added to its OTHERS.lst file.
For ctf-hacking and vbd-hacking solutions to lose their uniqueness:
- An external solution must be added to their OTHERS.lst file.
As you already know, scores obtained from your solved challenges need to be included in your MR. You can learn how to get your scores here.
Examples of MR that have been accepted recently can be found here
7. Other tools
7.1 Local Builds
It is possible to run local integrations in order to identify any errors before running a git push or sending a MR to the repositories. To do so, please read the instructions provided here.
7.2 Commit syntax
At Fluid Attacks we use a specific syntax for commits and MR's, this with the purpose of doing data analysis. All commit and MR messages will be evaluated by the continuous integrator (CI). More information about such syntax can be found here.