Young hacker smiling

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 FLUIDAttacks, 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 hacking challenges and programming challenges. With the former, you demonstrate your skill and wit to surpass security controls, 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 repository contains the solutions to computational challenges built in the previous context. By uploading solutions to the repository, we look to:

  1. Promote the solution of unresolved challenges.

  2. If the challenge is solved, encourage a new solution in a different way.

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

  4. Bring to life the solutions financed by FLUIDAttacks.

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

The collateral effects of this decision allow FLUIDAttacks to:

  1. Use the GitLab infrastructure to analyze the quality and speed of the development of the 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 FLUIDAttacks.

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

2. Objectives

  1. Solve 10 programming challenges.

  2. Solve 10 hacking challenges.

3. Terms

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

4. Criteria

The solutions to challenges, regardless if they are hacking or programming, must always meet the following style guideline. The programming solutions must additionally comply with the following:

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

  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 and/or linting commands used and their output must be included in the prelude at the beginning of the code.

    milogin.rs
    1
    2
    3
    4
    5
    6
    7
    8
    9
    /*
    $ rustup run nightly cargo clippy
    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.

    1
    2
    3
    4
    5
    6
    My solution's last line.
    
    /*
    $ ./skhorn
    over obese obese normal obese obese obese obese ...
    */
    
  6. If the solution takes a set of input data, it should not be hardcoded into the solution.

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. (Optional) They can be challenges that Require exploiting intentionally vulnerable systems (ToE) listed in:

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

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

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

5. Score

As you go on solving 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 Hacking

Wechall Ranking

6. Submission

The solutions are sent through a Merge Request (MR) to the master branch of the training repository. Before sending a 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 of a challenge with a complexity of 9.63, with 17 previous external solutions (out) and 8 within the repo (in) that took 4.5 hours to complete during the challenges phase is as follows:

commit-msg.txt
solution(challenges): codeabbey, 78 (9.63)

- others: 8 in, 17 out, 25 total.
- score: 25665 initial, 25723 final, 58 progress.
- global-rank: 797 initial, 795 final, 2 progress.
- national-rank: 38 initial, 38 final, 0 progress.
- effort: 4.5 hours during challenges phase.

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 to 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 also be of systems hacking.

  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 programming solution the URLs must be ordered alphabetically by extension.

  5. If it is in github the URL must be to its raw version (https://raw.githubusercontent.com/).

8. Examples

Here are the links to the different types of MR:

Examples of MR accepted in the past:

  • Hacking MR: 1, 2, 3

  • 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. To do this, You can lean on the following script.

  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. Repository

All submissions must be sent to this git repository

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:

Folder

challenges

system

Description

Folder to store programming and hacking challenges.

Folder to exclusively store vulnerable system challenges.

Structure

  • site (directory)

    • challenge ID (directory)

      • login-gitlab.ext (solution file)

  • name of the vulnerable machine (directory)

    • name of the exploit performed (directory)

      • login-gitlab.feature (solution file)

Example

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 Archivos

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 respective 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 (Only for vulnerable system challenges): Contains the specifications of the vulnerable machine you are working on. You can see an example here

11. Get Started

To begin 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. Joing our Slack channel, where you can interact with FLUIDAttacks personnel and other candidates who are currently in the same stage to solve doubts or issues.

  3. Request access rights to the 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 repository With my GitLab username [username].

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 repo) 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: careers@autonomicmind.co

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 repository. To do so, you must execute the following commands:

  • For GNU/Linux Operating Systems:

Install curl
1
2
sudo apt-get update
sudo apt-get install curl
Install Nix
1
curl https://nixos.org/nix/install | sh
Set your credentials
1
2
export DOCKER_USER=usuario-gitlab
export DOCKER_PASS=contraseña-gitlab
Compile and test
1
./build.nix
If the integration was successful,do a commit and add the changes to your local branch.
1
2
3
git add .
git commit -m "Ejemplo"
git push origin rama-personal
  • For Windows: A guide to run the integration locally Is not yet available for Windows and the fact that the integration is based on Linux makes the process that much more complicated for Windows.

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 repository are defined in the file COPYRIGHT.

  • The license and privileges that users of this repository have are defined in the file LICENSE.

  • Carrying out a merge request implies the transfer of copyrights. Therefore, all information contained herein may be used by FLUIDAttacks 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.

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


Service status - Terms of Use