Young hacker smiling

We hack your software

zero false positives

Expert intelligence + effective automation

Technical Challenges

This stage is parallel to the other stages of the process and therefore, the more progress you make on it now, the greater the probability is of being evaluated before the other participants once the other stages finish.

It can also be considered as a kind of lifesaver in the process, because you may not have graduated yet, have no previous work experience, or get a low score on your knowledge test, but if you able to successfully finish this stage, you will show that you have the most valuable competence of all: The ability to learn new things on the fly and apply them to solve real problems. This, along with human warmth and strong values, have more weight than everything else.

1. Philosophy

In this stage, we want you to evidence your technical skills through practical exercises and problems similar to the ones you will face in Fluid Attacks, with which you will be able to solve in an effective manner, our clients’ security issues. It also shows that you will be a valuable addition who can enrich the knowledge of the current members of our team.

The technical challenges are divided into systems-hacking, ctf-hacking and programming challenges. With the former, you demonstrate your technical skill and cunning to surpass security controls in environments designed for pentesting. With the second one, you demonstrate your adaptation and creativity skills when it comes to solving problems and achieving goals in unknown environments with the latter, you show that you are able to quickly understand a program, a language, and thus it will be easier for you to audit source code and find vulnerabilities.

The philosophy is to encourage learning from the active problem solving and discourage passive learning.

The repositories contain solutions to computational challenges built in the previous context. By uploading solutions to the repositories, we look forward to:

  1. Promote the solution of unresolved challenges.

  2. If the challenge is solved, encourage a new solution in a different way (another programming language, another programming paradigm or another radically different algorithm, semantically different or of another order).

  3. If the challenge is solved, make evident the similarity of the new solution to the old one (plagiarism).

  4. Bring to life the solutions financed by Fluid Attacks.

  5. Allow third parties to view the deliverables of our team.

The collateral effects of this decision allow Fluid Attacks to:

  1. Use the GitLab infrastructure to analyze the quality and speed of the development of everyone in the process.

  2. From early stages, familiarize potential talents with the tools (Git, AsciiDoc, Python, Gherkin, etc) and concepts (automation, unit tests, continuous integration, linting, etc.) that they will use in their daily work in Fluid Attacks.

  3. Make the results visible to the community and the team (peer pressure).

2. Objectives

  1. Solve 5 programming challenges.

  2. Solve 5 ctf-hacking challenges.

  3. Solve 5 systems-hacking challenges.

3. Terms

  1. The training is self-directed and independent (on your own without instruction or assistance from others).

4. Criteria

Challenge solutions, regardless if they are programming, ctf-hacking or systems-hacking must always meet the following style guideline.

Programming solutions must additionally comply with the following:

  1. A solution in the same language you chose (in the challenge folder) must not exist already.

  2. They must not have an external indexed solution (links + OTHERS.lst + of the challenge) for the language chosen by you.

  3. The programming language chosen must be accepted by Codeabbey

  4. The compilation (optional for interpreted languages) and 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
    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.
    $ ./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 a DATA.lst file located in the challenge directory. If such file does not exist, you must include it in your commit

ctf-hacking and systems-hacking solutions must comply with the following:

  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 or its related sites.

  4. The solution must have passed, without any errors or warnings, through a linter of the corresponding language in its most rigorous configuration.

Aditionally, ctf-hacking solutions must comply with the following:

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

Aditionally, systems-hacking solutions must comply with the following:

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

  2. They must be challenges that Require exploiting intentionally vulnerable systems (ToE) listed in:

  3. The Gherkin format to be used must strictly meet the the following

  4. All source code in solutions must follow the parameters described in this guide

5. Score

As you go on solving programming or ctf-hacking challenges, you must report your total score, ranking and score obtained for the specific challenged solved, which will allow us to follow your progress in this stage. All this information must be included in the commit message following the format described in the submission requirements

Here’s how to get your scores and ranking for each platform.

5.1 Programming

  1. World Ranking

    1. In codeabbey, go to the “Ranking” tab: World Ranking - codeabbey

    2. Scroll to the bottom of the page and there you will find your position in the world ranking: World Ranking - codeabbey

  2. Country Ranking

    1. While in the “Ranking” rab, select the country: Country Ranking

    2. The page doesn’t directly show your position so you will have to manually count. To make this easier, you should take into account that each page shows 50 users.

You must continue to the next page until you find your username on the ranking board Country Ranking - codeabbey

5.2 CTF-Hacking

Wechall Ranking

6. Submission

Solutions are sent through a Merge Request (MR) to the master branch of the repositories:

  1. writeups for systems-hacking challenges

  2. training for ctf-hacking and programming challenges

Before sending an MR please verify that you meet the following criteria:

  1. You should only work on a branch whose name is exactly your username in Gitlab.

  2. All files related to a challenge’s solution must respect the following structure

  3. If the solutions requires additional files, they must be included in the corresponding challenge directory.

  4. Each challenge solution must be submitted with 10 external solutions (10 URLs in an OTHERS.lst file).

  5. The solution and all files associated to it must be all sent in 1 commit.

  6. The commit for each solution must be sent in only 1 MR.

  7. The MR must only be sent once your branch has successfully finished integrating (green).

  8. If the MR is rejected it must not be reopened. The errors must be fixed and the solution sent in a new MR.

  9. The commit message to send the solution must follow one of the templates according to the type of the solution:

7. External

The rules for the links (URLs) to external solutions (OTHERS.lst) are the following:

  1. They must be direct links (HTTP 200) without redirection (HTTP 301/302).

  2. They don’t need to be solutions for the same challenge you solved.

  3. They must be hacking links if you solved a hacking challenge.

    1. The OTHERS.lst must be new links. in other words, external solutions to challenges to which we have no previous external solutions.

    2. If you send a systems-hacking solution, the external solutions must be systems-hacking solutions.

    3. If you send a ctf-hacking solution, the external solutions must be ctf-hacking and systems-hacking solutions.

  4. They must be programming solutions if you solved a programming challenge.

    1. You must not add external solutions for a language that already has an external solution.

    2. Within the OTHERS of a programming solution the URLs must be ordered alphabetically by extension.

  5. If it is in github the URL must be to its raw version (

8. Examples

Here are the links to the different types of MR:

Examples of MR accepted in the past:

  • Exemplary systems-hacking MR: 1, 2

  • Exemplary ctf-hacking MR: 1, 2, 3

  • Exemplary Programming MR: 1, 2, 3

Note These exemplary links do not necessarily follow all the above rules as the rules evolve and therefore, at the time the examples were made, they could have been different. The examples never have priority over the rules, however, they are listed for learning purposes.

9. Recommendations

  1. In order to fulfill the previously stated objectives, we suggest looking for challenges that don’t have a solution in the OTHERS file nor in the repository and solving the challenge in its respective platform.

  2. When solving programming challenges, we suggest using a language that is not widely used.

  3. Submit your solution immediately after you solve the challenge. Do not accumulate solutions on your computer without sending them, because this way, you will never receive feedback in order to know what you are doing wrong and could result unnecessary repetition.

10. Repositories

All submissions must be sent the the following repositories:

It is ideal that you become familiar with the versioning and the structure that we detail below.

10.1 Structure

Challenge solutions are stored in the following folders depending on the repository you are currently in:








Folder to store programming and ctf-hacking challenges.

Folder to store vulnerable systems-hacking challenges.


  • <site> (directory)

    • <challenge-id> (directory)

      • <login-gitlab.ext> (solution file)

  • <name-of-the-vulnerable-machine> (directory)

    • <cwe-code>-<exploit-name> (directory)

      • <login-gitlab.feature> (solution file)


The naming of all files and folders, with the exception of special files, must not exceed 35 characters, written in lowercase, without any special characters and In case a space is needed use a - (dash) to replace it.

10.2 Files

Some of the folders described in the structure contain special files:

  • LINK.lst: Contains the challenge URL. (example). This file must only have one line with the challenge link and it must give a HTTP 200 response when visiting it (No redirection).

  • DATA.lst: Contains the test cases with which the challenge was validated. This file should only contain test cases that are immediately processable by any solution file.

  • OTHERS.lst: It contains the links to the external solutions found on the Internet for said challenge which must not be read or used as a reference to solve the challenge. This file allows an automatic script to perform a similarity analysis with the challenges sent by the candidates. They must comply with what is specified here

  • SPEC.txt (in systems-hacking and programming) and spec.yml (in WeChall challenges): Contains the specifications of challenges site or the vulnerable machine you are working on, like number of challenges or vulnerabilities, URL and difficulty. You can see an example here

11. Stage steps

To successfully finish this stage, you must:

  1. Register on GitLab using your personal email and a username of your liking. Your username must not exceed 12 characters in length and only contain lowercase letters and numbers.

  2. Join our Slack channel, where you can interact with Fluid Attacks personnel and other candidates who are currently in the same stage to solve doubts or issues.

  3. Request developer permissions to the writeups repository through Slack Introducing yourself to everyone In the #general channel with the following message:

    I have read and understood all documentation pertaining to technical challenges, I agree to all of the terms and therefore request access to the git writeups repository With my GitLab username [username].

  4. Complete five (5) systems-hacking challenges in the writeups repository

  5. Request developer permissions to the training repository through Slack In the #general channel with the following message:

    I have completed five (5) systems-hacking challenges in the writeups repo therefore request access to the git training repository With my GitLab username [username].

  6. Complete one ctf-hacking challenge, then one programming challenge… And repeat this until you reach five (5) completed challenges of each type

    1. Each programming challenge completed must be one (1) score point (blessing for codeabbey) higher than the previous one.

12. End

The challenge stage ends under any of the following conditions:

  1. You have met all objectives and Sent an email with the links to your solutions in the master branch.

  2. If there is no activity (push to the git repos) in 14 calendar days.

  3. If you reach the maximum of 10 failed MR, this means the MR was rejected and not merged due to its failure to meet the requirements.

  4. If you explicitly manifest your desire to end the process in an email.

  5. If you present someone else’s complete or partial solutions as your own (plagiarism).

  6. If you solve a challenge with the help of others.

In all cases, the email address for these steps is:

If you were removed from the process due to any of these circumstances, except for the last two, You may apply again at any time and start over the process by clicking here

13. Builds

It is possible to run local integrations in order to identify any errors before doing push or sending a merge requests to the repositories. To do so, you must execute the following commands:

  • For GNU/Linux Operating Systems:

Install curl
sudo apt-get update
sudo apt-get install curl
Install Nix
curl | sh
Set your credentials
export DOCKER_USER=gitlab-user
export DOCKER_PASS=gitlab-pass
Compile and test
If the integration was successful,do a commit and add the changes to your local branch.
git add .
git commit
git push origin rama-personal
  • In Operating Systems different from Linux (Windows, Mac, etc): Continuous integration will never be available for OS different from Linux. Additionally in your everyday life at Fluid Attacks you will need to familiarize with Linux and its weapons. Hence we strongly recommend you to install it on your computer, or at least, to work with a Linux virtual machine.

We recommend installing virtualization software (VMware, Virtualbox) and creating a virtual machine based on a Linux distribution (e.g. Ubuntu, or another one of your liking). Then, follow the same procedure described above for Linux.

14. Questions

15. Property

  • The proprietary rights of all content in the repositories are defined in the files:

  • The license and privileges that users of the repositories have are defined in the files:

  • Carrying out a merge request implies the transfer of copyrights. Therefore, all information contained herein may be used by Fluid Attacks for any commercial purpose, always preserving the moral rights of their authors.

16. Plagirism

Having the solutions available at everyones disposal poses an opportunity for plagiarism, How do we show the solutions to the world and avoid plagiarism? Plagiarism is not a technical problem, It is a moral problem of presenting someone else’s work as your own.

To avoid plagiarism we seek visibility and an explicit declaration of the authorship of each algorithm in a centralized place. This provides clear evidence of the attribution of authorship and allows for public scrutiny in case of plagiarism.

In other words, the current model avoids plagiarism through total transparency.

Fluid Attacks actively applies algorithmic similarity detection techniques on all solutions submitted. In particular using:

Service status - Terms of Use