Pragyan CTF 2020--2022

Dependency Hell

The Subtle Art of Sumptuous Code



* * * * *

### Dependency Hell

![](https://cdn-images-1.medium.com/max/1600/1*0yByAkzxQxAORlQxDQYhxA.png)

image source: <https://assets.browserlondon.com/>

Have you ever come across a situation where the application you have been working on, it just starts behaving abruptly in some environments while it works fine in the other ones or maybe something like a ***Class Not Found*** error or worst of all the build itself doesn't go through without giving a proper error. You just entered the Dependency Hell my friend --- where your sanity goes to die, and your project decides to take a spontaneous vacation to Dysfunction Junction. If you've ever found yourself wondering why your seemingly innocent codebase has turned into a volatile powder keg, congratulations! You might just be a lucky victim of the dreaded dependency hell.

![](https://cdn-images-1.medium.com/max/1600/1*kP_1tI5UyJ8g_P51uMyGyA.jpeg)

image source: <https://sourcegraphstatic.com/>

> Dependency hell is a situation that occurs when a software application is unable to access the additional programs it requires to function properly. These additional programs, known as dependencies, are necessary for the software to run, but they can sometimes cause conflicts and issues. It can also be referred as Jar hell (in case of jar dependencies), Class Conflict and Version Skew.

* * * * *

Imagine there are three modules: A, B, and C. A requires B at v1.0, and C also requires B, but at v2.0. We can visualize this like so:

![](https://cdn-images-1.medium.com/max/1600/1*lRn8L-iRm4e8JeMhK_Jukg.png)

image source: <https://npm.github.io/>

Now, let's create an application that requires both module A and module C.

![](https://cdn-images-1.medium.com/max/1600/1*GRFIkljbno12TF2larIl4g.png)

image source: <https://npm.github.io/>

A package manager would need to provide a version of module B. In all other runtimes, this is what a package manager would try to do. This is dependency hell:

![](https://cdn-images-1.medium.com/max/1600/1*L2QSduFU6wTwbpEf76weIw.png)

image source: <https://npm.github.io/>

Now what do you think can happen here? Your App just got confused my dear developer. Now either it will result in build failure (if it is a compile time dependency) or something like class not found error or even it might run but the behaviour will be unexpected, some functions might just not run (if it is a runtime dependency).

Let's dive into the signs that your project is in this delightful state and how you can confirm your misfortune.

#### Signs You've Entered Dependency Hell

1.  **Runtime Exceptions:**\
    Ah yes, the comforting sight of errors like `NoClassDefFoundError`, `NoSuchMethodError`, and `ClassCastException`. Nothing says "fun" like tracking down why your perfectly fine code just imploded because two libraries can't agree on which version of a class to use.
2.  **Build Failures:\
    **Ever tried to build your project and got greeted with messages about version conflicts or missing dependencies? It's like your build tool is laughing at you, saying, "Nice try, but no."
3.  **Inconsistent Behavior:\
    **Does your code work in development but break in production? Perfect! You've achieved the ultimate developer paradox, thanks to different environments resolving dependencies in their unique, chaotic ways.
4.  **Dependency Resolution Errors:\
    **Tools like Maven, Gradle, npm, or pip love to throw cryptic dependency resolution errors. These little gems tell you that your dependencies are at war, and you're the unfortunate peacemaker.
5.  **Excessive or Redundant Dependencies:\
    **When your project's dependency list starts looking like a hoarder's garage, with multiple versions of the same library cluttering up your classpath or module path, you know you've hit the jackpot.

* * * * *

For your information Dependency hell is a common issue not just in Java or JavaScript, but in many other programming languages and ecosystems. Here are examples from several other languages where developers can encounter similar issues:

### JavaScript / Node.js

-   npm / yarn:\
    Dependency hell can occur due to the nested nature of dependencies. Different packages might depend on different versions of the same library, leading to issues with modules not being compatible.
-   Tools like `npm dedupe` and `yarn resolutions` can help mitigate these issues.

### Python

-   pip / conda:\
    Python's dependency issues often arise from conflicting versions of packages. This can lead to errors if different parts of a project require different versions of a package.
-   Virtual environments (venv, virtualenv) and tools like `pipenv` or `poetry` help manage dependencies and isolate them to avoid conflicts.

### Ruby

-   RubyGems / Bundler:\
    Ruby projects can face dependency hell when gems (Ruby packages) have conflicting dependencies or when gem versions are incompatible.
-   Bundler manages gem dependencies and versions, helping to mitigate these issues by ensuring that all dependencies are compatible with each other.

### PHP

-   Composer:\
    In PHP, dependency hell can occur with Composer when different packages require different versions of the same dependency.
-   Composer uses a dependency resolution algorithm to try to find a set of versions that satisfy all constraints, but manual intervention is sometimes required to resolve conflicts.

### .NET

-   NuGet:\
    .NET projects using NuGet can encounter issues with package versions, especially when multiple libraries depend on different versions of the same package.
-   Tools and features within NuGet, such as dependency version conflict resolution and assembly binding redirects, help manage these issues.

### C / C++

-   Package Managers (e.g., vcpkg, Conan):\
    Dependency management in C/C++ can be complex due to binary compatibility issues and different versions of libraries.
-   These package managers help manage dependencies, but conflicts can still arise when different libraries require different versions of a common dependency.

### Rust

-   Cargo:\
    Rust's package manager, Cargo, can also encounter dependency conflicts, known as "dependency hell," when different crates (Rust packages) require incompatible versions of the same dependency.
-   Cargo uses a resolver to find a compatible set of dependencies, but sometimes developers need to manually intervene to resolve conflicts.

### Haskell

-   Cabal / Stack:\
    Haskell projects using Cabal or Stack can face dependency hell due to conflicting versions of packages (Hackage packages).
-   Stack's curated snapshots help mitigate this issue by ensuring that a set of package versions are tested to work together.

### Elixir

-   Mix:\
    Elixir projects using Mix can also face dependency hell when dependencies have conflicting requirements.
-   Mix provides tools to specify and resolve dependencies, but manual resolution might be necessary when conflicts arise.

In all these languages and ecosystems, dependency hell generally stems from the same root cause: different parts of a project (or different projects) requiring incompatible versions of the same dependencies. Effective dependency management tools and practices are crucial in mitigating these issues, but understanding the specific tools and techniques for each ecosystem is essential for developers.

* * * * *

Now the question arises, how to get out of this stupid and really confusion place.

![](https://cdn-images-1.medium.com/max/1600/1*9vzVTUFm4WtHqYOcTi-EFQ.jpeg)

image source: <https://cdn.activestate.com/>

1.  **Inspect Dependency Tree**\
    Why not start by peering into the abyss? Use your build tool to vomit out the full dependency tree and see the carnage for yourself:\
    Maven: `mvn dependency:tree`Gradle: `./gradlew dependencies`npm: `npm ls`pip: `pip list` or `pipdeptree` Composer: `composer show -t`
2.  **Analyze Classpath or Module Path**\
    Just to add to your misery, check the classpath or module path. Ensure there are no duplicate or conflicting JARs or modules. It's like searching for a needle in a needlestack.
3.  **Review Error Messages**\
    Those error messages and stack traces? They're your new bedtime reading. They often drop hints about which classes or modules are causing the drama and the versions involved.
4.  **Check for Duplicate Libraries**\
    Wander through your project's dependencies folder and revel in the sight of multiple versions of the same library. Nothing like redundancy to make your day!
5.  **Use Dependency Management Tools**\
    Because who doesn't love more tools to learn? Employ plugins and commands to wrangle your dependencies:\
    Maven Enforcer Plugin:

```
<plugin>\
    <groupId>org.apache.maven.plugins</groupId>\
    <artifactId>maven-enforcer-plugin</artifactId>\
    <version>3.0.0-M3</version>\
    <executions>\
        <execution>\
            <id>enforce</id>\
            <goals>\
                <goal>enforce</goal>\
            </goals>\
            <configuration>\
                <rules>\
                    <DependencyConvergence/>\
                </rules>\
            </configuration>\
        </execution>\
    </executions>\
</plugin>
```

Gradle Resolution Strategy:

```
configurations.all {\
    resolutionStrategy {\
        force 'com.fasterxml.jackson.core:jackson-databind:2.12.3'\
    }\
}
```

6\. **Manual Inspection**\
When all else fails, roll up your sleeves and manually inspect your dependency declarations (`pom.xml`, `build.gradle`, `package.json`, `requirements.txt`). Because why automate when you can suffer?

### Conclusion

In the end, recognizing and escaping from dependency hell is just another rite of passage in the developer's journey. With enough patience and a pinch of masochism, you too can navigate through this labyrinth of conflicts. Or, you know, consider a career change.


### Pragyan CTF 2020--2022

![](https://cdn-images-1.medium.com/max/1600/1*rSYbMDXLI6n8aplgj7eR8A.jpeg)

image source: dailydot.com

A slight jump in the past, and we are back to the start of 2020, those nice Pre-covid vibes, where we used to be sitting together coding day and night while having loads of discussions and idea-sharing of course, for the upcoming Pragyan'20. For those of you who don't know what is Pragyan, well it is the Techno managerial festival of NIT Trichy, and I belong to the team which handles all the software-related things. CTF enthusiasts might recall Pragyan, because of the wonderful experiences they had with us during Pragyan CTF'20.

It's been almost 4 years, and we are still thriving to be better with every such mistake, of course, that's what we do, we are developers, we develop things, make them better and learn from mistakes. AND yes, I was the part of Pragyan CTF'20 developer team as well, just a member of that group with four sophomores, who just entered the realm of CTF, trying to host an event as large for the first time. These four kids weren't aware of the upcoming roller coaster ride.

Pragyan CTF is a 36-hour long jeopardy style capture the flag event, where around 1000 individuals participate from all around the world. I am not exaggerating, that is the number, and that was a surprise for us as well back then. Well, a scary surprise I must say.

We four, each of us responsible for one category each namely --- Forensics (That was handled by me), Binary and Reversing, Cryptography and finally Web. Starting from January we begin creating questions and working on our Infra along with it. That year we decided to go with [Mellivora](https://github.com/Nakiami/mellivora) as our CTF engine (built with PHP) because of its easily scalable structure.

A week before the event goes live we started the final stress testing for the questions among our group mates. Like any other normal CTF, we hosted rooms for discussion over discord. Finally on 23rd Feb 2020, at 8:00 PM sharp the event went live and people started solving challenges one by one.\
That was the moment of relief because that's what we have been working on for the past 2 months. The discussions over discord were also going great, people liked the challenges we made. We had our "Sorta Happy Moment" there. But how is it possible, everything is perfect on the very first go. We were very well aware of our extremely incredible luck.\
Sometime around 10:00 pm, there was a discussion over discord about the platform going down all of a sudden. Not even a second of relaxation and the platform actually went down, the reason still being unknown at that moment.

And it was at this moment we realised, we.... Never mind.

The server was turned off by one of our group mates because of some suspicious behaviour in the logs he noticed. There was a discussion over CTFtime and discord about the same, because of some mistake we made in one of the challenges. We started working, trying to keep each other's morale up. Obviously, nothing worse could have happened. And.....

At the very same moment, we lost access to the mod permissions of the discord server as well. The night couldn't have been better, to be honest.

![](https://cdn-images-1.medium.com/max/1600/1*oUCGfdd00VBXW-HQzMAyWg.png)

Sarcasm!!! Image source: <https://giphy.com/gifs/bazinga-YWZPFFCblEqsw>

The things kept going worse. Internet is definitely a boon for many, we became a source of entertainment when participants started posting memes over CTFtime instead of solving challenges.

![](https://cdn-images-1.medium.com/max/1600/1*Ev2aI_mLX-LwVPyL0LJG9Q.jpeg)

image source: one of our amazing participant teams

Scratching our heads, we were confused about what could have possibly happened. The discussions described that one of our challenges allowed RCE over our server when we knew that we tried to prevent it in every possible way. It took us a while to figure out the actual issue why it happened. Apparently, we forgot to test one of the Web challenges.\
The challenge was fixed and the server went up again, we took a heavy breathe to relax. Nope! not that easily.\
We forgot that the challenge was fixed, but we didn't fix the damage it made already. It was because of the lovely participants we had to witness this over CTFtime.

![](https://cdn-images-1.medium.com/max/1600/0*qE_8G-FMiC9M3-1e.png)

image credits: again the same set of participants

Yes, all the flags were leaked by one team. But we had to forget the unprofessional behaviour and focus on how to fix it whole. And yet again we had to turn our server down immediately (it was 3:23 AM). Our morale totally went down. But thanks to some good participants we had, who kept motivating us, especially the super friendly people from [Team-BI0S](https://bi0s.in/).

**The whole reason behind this mess was:**

One of our Web challenges named Brutus had a small issue in PHP unserialise which gave RCE privileges to every user. We forgot to implement a time-out check over the challenge and in no time the users figured out the bug and comfortably used it to create a reverse shell to the server.

```
www-data@5841bda2da57:/code$ cat /etc/hosts\
127.0.0.1       localhost\
::1     localhost ip6-localhost ip6-loopback\
fe00::0 ip6-localnet\
ff00::0 ip6-mcastprefix\
ff02::1 ip6-allnodes\
ff02::2 ip6-allrouters\
172.26.0.4      5841bda2da57
```

Users used this to check the `/etc/hosts` file which gave the IP address of the internal server i.e. `172.26.0.4` After that, it was pretty easy to guess that the host server could have the IP address `172.26.0.1` .

```
www-data@5841bda2da57:/code$ curl 172.26.0.1\
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">\
<**html**>\
 <**head**>\
  <**title**>Index of /</**title**>\
 </**head**>\
 <**body**>\
<**h1**>Index of /</**h1**>\
  <**table**>\
   <**tr**><**th** valign="top"><**img** src="/icons/blank.gif" alt="[ICO]"></**th**><**th**><**a** href="?C=N;O=D">Name</**a**></**th**><**th**><**a** href="?C=M;O=A">L\
ast modified</**a**></**th**><**th**><**a** href="?C=S;O=A">Size</**a**></**th**><**th**><**a** href="?C=D;O=A">Description</**a**></**th**></**tr**>\
   <**tr**><**th** colspan="5"><**hr**></**th**></**tr**>\
<**tr**><**td** valign="top"><**img** src="/icons/folder.gif" alt="[DIR]"></**td**><**td**><**a** href="mellivora/">mellivora/</**a**></**td**><**td** align="right">\
2020-02-21 22:08  </**td**><**td** align="right">  - </**td**><**td**> </**td**></**tr**>\
   <**tr**><**th** colspan="5"><**hr**></**th**></**tr**>\
</**table**>\
<**address**>Apache/2.4.29 (Ubuntu) Server at 172.26.0.1 Port 80</**address**>\
</**body**></**html**>
```

Now, as I mentioned that we were using Mellivora CTF-engine to host the platform, it was available at `172.26.0.1/mellivora` .

```
www-data@5841bda2da57:/code$ curl 172.26.0.1/mellivora/\
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">\
<**html**>\
 <**head**>\
  <**title**>Index of /mellivora</**title**>\
 </**head**>\
 <**body**>\
<**h1**>Index of /mellivora</**h1**>\
  <**table**>\
   <**tr**><**th** valign="top"><**img** src="/icons/blank.gif" alt="[ICO]"></**th**><**th**><**a** href="?C=N;O=D">Name</**a**></**th**><**th**><**a** href="?C=M;O=A">Last modified</**a**></**th**><**th**><**a** href="?C=S;O=A">Size</**a**></**th**><**th**><**a** href="?C=D;O=A">Description</**a**></**th**></**tr**>\
   <**tr**><**th** colspan="5"><**hr**></**th**></**tr**>\
<**tr**><**td** valign="top"><**img** src="/icons/back.gif" alt="[PARENTDIR]"></**td**><**td**><**a** href="/">Parent Directory</**a**></**td**><**td**> </**td**><**td** align="right">  - </**td**><**td**> </**td**></**tr**>\
<**tr**><**td** valign="top"><**img** src="/icons/unknown.gif" alt="[   ]"></**td**><**td**><**a** href="Dockerfile">Dockerfile</**a**></**td**><**td** align="right">2020-02-17 12:37  </**td**><**td** align="right">720 </**td**><**td**> </**td**></**tr**>\
<**tr**><**td** valign="top"><**img** src="/icons/unknown.gif" alt="[   ]"></**td**><**td**><**a** href="LICENSE">LICENSE</**a**></**td**><**td** align="right">2020-02-17 12:37  </**td**><**td** align="right"> 34K</**td**><**td**> </**td**></**tr**>\
<**tr**><**td** valign="top"><**img** src="/icons/text.gif" alt="[TXT]"></**td**><**td**><**a** href="README.md">README.md</**a**></**td**><**td** align="right">2020-02-17 12:37  </**td**><**td** align="right">2.8K</**td**><**td**> </**td**></**tr**>\
<**tr**><**td** valign="top"><**img** src="/icons/text.gif" alt="[TXT]"></**td**><**td**><**a** href="benchmarks.md">benchmarks.md</**a**></**td**><**td** align="right">2020-02-17 12:37  </**td**><**td** align="right">6.4K</**td**><**td**> </**td**></**tr**>\
<**tr**><**td** valign="top"><**img** src="/icons/unknown.gif" alt="[   ]"></**td**><**td**><**a** href="codeception.yml">codeception.yml</**a**></**td**><**td** align="right">2020-02-17 12:37  </**td**><**td** align="right">340 </**td**><**td**> </**td**></**tr**>\
<**tr**><**td** valign="top"><**img** src="/icons/unknown.gif" alt="[   ]"></**td**><**td**><**a** href="composer.json">composer.json</**a**></**td**><**td** align="right">2020-02-17 12:37  </**td**><**td** align="right">696 </**td**><**td**> </**td**></**tr**>\
<**tr**><**td** valign="top"><**img** src="/icons/unknown.gif" alt="[   ]"></**td**><**td**><**a** href="composer.lock">composer.lock</**a**></**td**><**td** align="right">2020-02-17 12:37  </**td**><**td** align="right">106K</**td**><**td**> </**td**></**tr**>\
<**tr**><**td** valign="top"><**img** src="/icons/unknown.gif" alt="[   ]"></**td**><**td**><**a** href="docker-compose.dev.yml">docker-compose.dev.yml</**a**></**td**><**td** align="right">2020-02-22 06:35  </**td**><**td** align="right">1.1K</**td**><**td**> </**td**></**tr**>\
<**tr**><**td** valign="top"><**img** src="/icons/unknown.gif" alt="[   ]"></**td**><**td**><**a** href="docker-compose.test.yml">docker-compose.test.yml</**a**></**td**><**td** align="right">2020-02-17 12:37  </**td**><**td** align="right">1.2K</**td**><**td**> </**td**></**tr**>\
<**tr**><**td** valign="top"><**img** src="/icons/folder.gif" alt="[DIR]"></**td**><**td**><**a** href="htdocs/">htdocs/</**a**></**td**><**td** align="right">2020-02-17 12:37  </**td**><**td** align="right">  - </**td**><**td**> </**td**></**tr**>\
<**tr**><**td** valign="top"><**img** src="/icons/folder.gif" alt="[DIR]"></**td**><**td**><**a** href="include/">include/</**a**></**td**><**td** align="right">2020-02-20 13:35  </**td**><**td** align="right">  - </**td**><**td**> </**td**></**tr**>\
<**tr**><**td** valign="top"><**img** src="/icons/folder.gif" alt="[DIR]"></**td**><**td**><**a** href="install/">install/</**a**></**td**><**td** align="right">2020-02-17 12:37  </**td**><**td** align="right">  - </**td**><**td**> </**td**></**tr**>\
<**tr**><**td** valign="top"><**img** src="/icons/text.gif" alt="[TXT]"></**td**><**td**><**a** href="rules.txt">rules.txt</**a**></**td**><**td** align="right">2020-02-21 22:08  </**td**><**td** align="right">826 </**td**><**td**> </**td**></**tr**>\
<**tr**><**td** valign="top"><**img** src="/icons/folder.gif" alt="[DIR]"></**td**><**td**><**a** href="tests/">tests/</**a**></**td**><**td** align="right">2020-02-17 12:37  </**td**><**td** align="right">  - </**td**><**td**> </**td**></**tr**>\
<**tr**><**td** valign="top"><**img** src="/icons/folder.gif" alt="[DIR]"></**td**><**td**><**a** href="writable/">writable/</**a**></**td**><**td** align="right">2020-02-17 12:37  </**td**><**td** align="right">  - </**td**><**td**> </**td**></**tr**>\
   <**tr**><**th** colspan="5"><**hr**></**th**></**tr**>\
</**table**>\
<**address**>Apache/2.4.29 (Ubuntu) Server at 172.26.0.1 Port 80</**address**>\
</**body**></**html**>
```

If you look at the Github repo for Mellivora, you will find a docker-compose.dev.yml file that was easily accessible now.

```
www-data@5841bda2da57:/code$ curl 172.26.0.1/mellivora/docker-compose.dev.yml\
version: '3'\
services:\
  mellivora:\
    image: mellivora\
    ports:\
      - 4000:80\
      - 4002:443\
    build:\
      context: .\
      dockerfile: Dockerfile\
    environment:\
      MELLIVORA_CONFIG_DB_ENGINE: mysql\
      MELLIVORA_CONFIG_DB_HOST: db\
      MELLIVORA_CONFIG_DB_PORT: 3306\
      MELLIVORA_CONFIG_DB_NAME: [redacted]\
      MELLIVORA_CONFIG_DB_USER: [redacted]\
      MELLIVORA_CONFIG_DB_PASSWORD: [redacted]\
    volumes:\
      - .:/var/www/mellivora\
      - composer dependencies:/var/www/mellivora/include/thirdparty/composer\
    links:\
      - db\
  db:\
    image: mysql:5.6\
    ports:\
      - 13306:3306\
    environment:\
      MYSQL_DATABASE: [redacted]\
      MYSQL_USER: [redacted]\
      MYSQL_PASSWORD: [redacted]\
      MYSQL_ROOT_PASSWORD: [redacted]\
    volumes:\
      - dbdata:/var/lib/mysql\
      - ./install/sql:/docker-entrypoint-initdb.d\
  adminer:\
      image: adminer\
      restart: always\
      ports:\
        - 15246:8080\
volumes:\
  composerdependencies:\
  dbdata:

```

This file gave the user the password to our database container. Therefore, using these details some teams were able to get access to all the flags, and one of them leaked them over CTFtime apparently.

$con = new mysqli('172.26.0.1','[redacted]','[redacted]','[redacted]');\
$res = $con->query('show databases')->fetch_all();\
var_dump($res);

Basically, the host server and the challenges could have been separated in the beginning itself, which could have prevented this huge mess.

We worked overnight and changed all the flags, resolved the bug in the challenge, and we were able to host the CTF up the next day successfully. We had to deal with a lot of criticism, but at the end of the day, we were able to finish the event happily.

Fast forward to 2021, time for a totally new Pragyan edition. Now we were aware of the mistakes we made last year, and we planned to improve them this time.\
The idea was to host a scalable CTF platform, and so we chose [HaProxy](https://www.haproxy.org/) + [Kubernetes](https://kubernetes.io/) for the challenges.

The first step was to set up a **K8 cluster** on Google cloud.

```
$ echo "deb [signed-by=/usr/share/keyrings/cloud.google.gpg] https://packages.cloud.google.com/apt cloud-sdk main" | sudo tee -a /etc/apt/sources.list.d/google-cloud-sdk.list

# Install depssudo\
$ apt-get install apt-transport-https ca-certificates gnupg

# Import google cloud public key\
$ curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key --keyring /usr/share/keyrings/cloud.google.gpg add -

# Update apt package index, install cloud sdksudo\
$ apt-get update && sudo apt-get install google-cloud-sdk

The next step was to create a cluster, based on the number of nodes we needed and the regions we wanted them to deploy in.

$ `gcloud compute machine-types list`

$ `gcloud compute zones list`
```

After this, we can simply run the following command to create a cluster

```
$ gcloud container clusters create cluster-name \\
    --zone compute-zone \\
    --machine-type <machine-type you chose> \\
    --num-nodes <number of nodes in the cluster> \\
    --tags challenges

```

Note the **tags** option, these will assign a tag to each VM instance on the node.

Now, the final step was to use kubectl to deploy challenges on the cluster. For this step, we had to create docker images for all the challenges locally and push them to a registry. Once the images were pushed, all that remained was to write a YAML file to deploy them, something similar to this

Followed by `kubectl apply -f deployment.yml`

### Setting up a HaProxy Load Balancer in front of your cluster

To create a load balancer, we just provisioned a separate VM and installed HaProxy over it. Now all that was left to do was configure the HaProxy config file in a way similar to this.

And that's it. The events went live and ended successfully with no issues till the end.

You can check the questions out at

[**GitHub - Bhavesh0327/pctf_20**\
*You can't perform that action at this time. You signed in with another tab or window. You signed out in another tab or...*github.com](https://github.com/Bhavesh0327/pctf_20 "https://github.com/Bhavesh0327/pctf_20")[](https://github.com/Bhavesh0327/pctf_20)

[**GitHub - Bhavesh0327/PCTF21**\
*Contribute to Bhavesh0327/PCTF21 development by creating an account on GitHub.*github.com](https://github.com/Bhavesh0327/PCTF21 "https://github.com/Bhavesh0327/PCTF21")[](https://github.com/Bhavesh0327/PCTF21)

Well, this was it. Do not miss out upcoming editions of the Pragyan CTF.


### The Subtle Art of Sumptuous Code

To be able to code is a skill, which needs good knowledge to be appreciated. And I can say that many developers aren't able to perceive the art behind a piece of code when they see it.

![](https://cdn-images-1.medium.com/max/1600/1*MRlmex6sJOmw7GDAQTQH6g.jpeg)

Image source: [Raspberrypi.org](https://www.raspberrypi.org/app/uploads/2017/04/002_presSeries-500x250.jpg)

Being a good programmer isn't just about writing a few lines of code but is also about writing readable and productive programs that are easy to manage and upgrade if needed in the future. Coding has become one of the most common activities people do. However, their coding practices are often unpolished.

Each one of us has our own way of writing those magical lines. Some use white-spaces while some press a tab; some use comments while others find them useless. As time passes, it's not just the quality of code that gets upgraded, but the practices followed as well. Here, I have tried to sum up the best coding practices, which may seem trivial to a few readers, but are certainly not something to be overlooked. For new programmers, these can be the mantras that will stick with them till the end. So why not dive right into it!

![](https://cdn-images-1.medium.com/max/1600/1*S2ODiZvDCYBlV3DLbPY6-A.gif)

Image source: [wordpress.com](https://runninginthehamsterwheel.files.wordpress.com/2014/11/diving-animationwip3.gif)

### ***Writing readable code***

On the surface, readability may seem subjective, something which may vary with languages, codebases, and teams. But when you look underneath, there are core elements within all pieces of code that make them readable. Here are a few of the good practices that I've learned throughout my experience with coding:

-   **Getting rid of dead code:** While writing programs, we often add irrelevant pieces of code. They create nothing more than confusion for the programmer when they go through them at some point in the future. Try to get rid of such pieces of dead and useless code.
-   **Proper Formatting:** Code formatting is one of those things that you notice only when it is absent. Usage of proper indentation, capitalization and naming conventions, etc., may seem obsolete, but it is actually one of the most important qualities a good programmer possesses.
-   **Objects over procedure:** Using objects while writing code is advantageous over procedural methods. It helps the coder in terms of code reusability, data redundancy, security, code maintenance, and better productivity.
-   **Understandable Naming conventions:** Using proper and understandable naming conventions to name functions and variables is a practice followed by good programmers.
-   **Commenting:** Providing brief and descriptive comments in front of every important portion of the code can help others understand what that piece of code actually does in the main program.
-   **Following Symmetry:** Last but not least, following symmetry, while writing code is highly appreciated and is one sign of being a good programmer. Equal indentations and white-spaces used throughout the code makes it look clean and easy to read, and even easier to debug.

### ***Understanding Version Control***

Whether it is for personal projects or organization-level projects, version control is one of the most important skills for a developer. It is a tool that helps developers/programmers to tackle some everyday problems, such as tracking changes in the code, maintaining code, and allowing them to work on the same source code files without affecting each other's workflow.

![](https://cdn-images-1.medium.com/max/1600/1*gz8vbnIqYkd9d20aJDDUew.png)

Image source: [pics.me.me](https://pics.me.me/starting-a-new-job-and-discover-they-dont-do-unit-21434272.png)

The concept of version control is often facilitated through special kinds of systems called *Version Control Systems (VCS).* These systems have gone through many developments over recent years.

![](https://cdn-images-1.medium.com/max/1600/1*F04Q05x8e08H1V87o7gDQQ.jpeg)

Image source: [images3.memedroid.com](https://images3.memedroid.com/images/UPLOADED29/5b7d571106c71.jpeg)

Version control systems are special types of software development tools designed to help software developers track any changes made on a specific application's source code. The most popular VCS nowadays used by millions of developers and programmers around the world is [*Git*](https://git-scm.com/). However, there are also other VCS like [*PerForce*](https://www.perforce.com/solutions/version-control), [*Beanstalk*](https://beanstalkapp.com/), etc., that are quite common.

Version control in itself has become one of the essential parts of a programmer's life. Using a VCS has various benefits like:

-   **Collaborative contribution:** The main benefit of VCS is that it allows us to contribute to projects we like despite being at different places without disturbing the actual program.
-   **Testing purposes:** Having different clones of the same software project can help people test new features if any, and make sure they function properly.
-   **Keep history:** These systems help us keep a backup and a record of the changes made in a specific code file that could help others understand how a specific piece of that code came to be.
-   **Backups:** One of the most vital benefits of using a version control system is that every time a contributor clones a repository, they are, in a sense creating an additional backup of the current version of that repository.

VCS may sound very sketchy to a few, but honestly, it is not. It is just one of the toolkits designed to make a developer's life easy-peasy, although...

![](https://cdn-images-1.medium.com/max/1600/1*sLzQ6ypKa1c56-8t8o67uA.png)

Image source: [i.pinimg.com](https://i.pinimg.com/originals/de/f5/2f/def52fe41d695d8feebd2cdc194da929.png)

### ***The art of googling bugs --- Debugging***

Coders spend long hours debugging, staring at the codebase, and figuring out what exactly went wrong. That's something ubiquitous among developers who don't know the correct techniques to find the bugs and fix them. It becomes easy to learn the correct approach to follow to kill that bug hidden inside your code like those cockroaches in your kitchen.

![](https://cdn-images-1.medium.com/max/1600/1*znulCBO71Ym3pYDOUN8kwg.png)

Image source: [cdn-images-1.medium.com](https://cdn-images-1.medium.com/max/1600/1*TVLjRkMw1QngSiMEcklAFw.png)

-   **Googling:** I'm not going to sort those tips by usefulness, but [*googling*](https://www.google.com)error messages is first for a reason. If you can't understand an error message at first encounter, the easiest way to solve the problem is to google the error message.
-   **Log(everything):** Logging is one of the most popular ways of debugging code. Using statements like console.log() or print() at correct positions may help you understand what's wrong with your code.
-   **Program localization:** The problem localization method's key idea is to comment/remove a code step by step until you figure out what went wrong. It is beneficial when you are writing an algorithm for a pretty long time without compiling and executing the application.
-   **Analyze logs:** Yes, I can understand. Going through those boring and lengthy logs can be hectic most of the time, but it may help you understand the issues with your code.
-   **Ask a friend:** One of the best but underrated methods of debugging is simply asking a friend. Good developers are always ready to help.
-   **Rubber duck debugging:** This is so far the best thing I have learned in my entire coding experience. The method suggests starting to explain your code to a rubber duck line by line, and you will end up noticing the tiny details about your code, which might create the actual issues. You can read more about it at [*rubber duck debugging*](https://rubberduckdebugging.com/).

![](https://cdn-images-1.medium.com/max/1600/1*0O_dzLbZIE4ZuM8aEKLBVw.jpeg)

Image source: [friarmusings.files.wordpress.com](https://friarmusings.files.wordpress.com/2012/05/sunglass-rubber-duck.jpg)

It's funny how a small rubber duck can help you fix a large chunk of bugs in your code.

-   **Debugger at the rescue:** I presume most developers are already familiar with how debuggers work and why to use them. But as a personal opinion, using debuggers kills your analytical and thinking skills, which is why I am keeping this point as the last option for you to consider.

### ***Good documentation***

Being able to write good code is good, but being able to write good docs, well... that's a talent. But why write those lengthy docs after hours of code writing? The answer to this question is simple: to tell other people about your code's key features.

Documenting your programs is considered one of the best practices in a coding culture. It helps not only others but also ourselves. A good way to start would be simply updating [README.md](https://blog.bitsrc.io/how-to-write-beautiful-and-meaningful-readme-md-for-your-next-project-897045e3f991) for your projects. Remembering large chunks of codes can be hard sometimes (actually most of the time), but going through well-framed docs can help you to understand the code later at some point of time while you might be scratching your head trying to understand why you wrote that particular part of the code.

![](https://cdn-images-1.medium.com/max/1600/1*X4_vEaNMzmS7DNTkx02a3A.gif)

Image source: [media1.tenor.com](https://media1.tenor.com/images/5f8fef11a34cce64bb0cd4e4c74d9adc/tenor.gif?itemid=4514169)

Now here comes a question, What makes good documentation?

People often think that the value of docs is subjective or unquantifiable. This is rarely the case.

The value of writing is that it can be written once and shared many times, whereas in-person or real-time communication forms need to be repeated each time a new person needs the information.

The question here is not "How" to document but "What" to document?

-   Document questions that are clearly or probably going to be asked
-   When you get asked a new question, you might as well write it in a generally-applicable way if possible and quickly insert it into the best location in your document structure.

Okay, so what shouldn't be documented then? Even that has an answer.

-   Things nobody cares about
-   Things you are proud of, but really only you care about, like how hard you worked --- tell your mom or write a blog post.

> The trick is to anticipate the probable audiences for a subject matter and what they probably need to know.

So much for the value of a doc.

What about the quality of a doc? Isn't this subjective?

No. Not at all. Doc has a job to do. It is good inasmuch as it accomplishes that task; that is an absolute and completely objective standard to the quality of technical documentation. Suppose I write a document for experienced Kotlin engineers and, out of 100 engineers, 23 understand it. No matter how smart I think I am, I have failed. That score will save very few people any time.

Good docs follow the 4C principle, which says that your documentation should be:

-   **Concise:** Writing more words than required is certainly not an appreciated practice anywhere. And readers oftentimes are not patient enough to read something that doesn't add value. So wipe out those extra words from your docs!
-   **Complete:** Try to include everything that somebody is likely to want to know. Please do not include things that will not help other people with their work.
-   **Correct:** Get someone else who understands your content to sanity-check it for correctness. If readers find your document inaccurate, they will wonder why they should read your work anymore. In some situations, erroneous information can cause serious harm.
-   **Clear:** Clarity is the objective. If your intended audience does not understand your docs, your docs are not clear.

Well yeah, that's all you need to know to become a good programmer. It is not easy, but it is a skill that one can develop by practice.


To be able to code is a skill, which needs good knowledge to be appreciated. And I can say that many developers aren't able to perceive the art behind a piece of code when they see it.

Stories. Updates. Guides.

Featured Articles

Dependency Hell

Pragyan CTF 2020--2022

The Subtle Art of Sumptuous Code

All Articles