DEV Community: SJ W

picoCTF "homework" Walkthrough

SJ W — Sat, 05 Jul 2025 06:18:24 +0000

Introduction

Today, we are going to go over the picoCTF challenge I have completed a few days ago, called homework, a challenge in the category of binary exploitation. It has been a while since I posted anything in this blog, and before I start the walkthrough, I would like to briefly talk about my future career in cybersecurity. Recently, I made up my mind to fully pursue a career in cybersecurity. Fully transitioning into the field of cybersecurity feels like a daunting task, but at the same time, I believe that it will help me lead a fulfilling life that I have always envisioned. Evident in my blog, the vast majority of posts are related to various CTF challenges I have completed so far, and simply, it is the most enjoyable thing for me to do in life. Along the journey, there will be a plenty of challenges and obstacles that will, at times, make me feel doubtful about accomplishing my goal, but I believe that, with strong willpower and commitment, I can overcome those and keep moving forward for the ultimate goal I set in life. Enough with my gibberish, let's go ahead with the challenge.

Unlike all the challenges I have completed and posted in this blog, this challenge is of the category of Binary Exploitation, which involves a slightly different approach than Reverse Engineering. On top of understanding how a binary works, challenges in this category require you to carefully manipulate a binary into doing something that wasn't expected of it to do. Usually in this category, there are challenges involving heap and stack overflow that alters the behaviors of a program in unexpected ways.

This challenge basically involves providing a series of strings that are fed to a custom interpreter, which executes the custom instructions that a user provides. Ultimately, what we need the binary to do is, with our carefully crafted instructions, to output the flag that we need to submit in order to complete this challenge.

Analysis

Just as usual, it all starts with statically analyzing a binary with the help of Ghidra. Let's see what it contains.

With the completion of the analysis, we wind up right at the function main, which is the starting point of the binary.

Looking at the function main, we notice a few lines that seem pretty interesting. In lines 12 and 13, the function apparently copies the content of a file flag.txt to a memory address using the scanf function. The lines 16 and 17 contain variables named rows and cols, which seem to indicate that it has to do with a matrix of 0x32 rows and 0x16 columns (50 rows and 22 columns).

As you can see, the variable board mentioned in line 19 encompasses 1100 bytes (50 * 22).

And then, we encounter a for-loop that repeats the total of 4 times maximum, which does the followings:

Accept an input of up to 22 bytes and store the input at the following address.
- Address of the variable board + (0x16 * local_14)
- The reason why the function does (0x16 * local_14) is that there are 22 columns in each row, and multiplying it to local_14 results in the very first column of a certain row. Basically, local_14 acts as a row number.
Check if the input is not accepted or the first byte of an input is the ASCII value of 0x52.
- If either one evaluates to True, then terminate the for-loop prematurely.
Calculate the length of an input.
Replace the very last character of an input with a null byte.
- So, let's say you provided an input of 22 bytes. The process replaces the 22nd byte with a null byte, which turns into an input of 21 bytes. Essentially, each row is only able to contain up to an input of 21 bytes.

So, what we can gather from above is the following:

There is a board of 50 row and 22 cols that will be placed with our input. Each row contains 22 columns.
You provide an input 4 times total. If the max length of each line is 21 bytes, then you can provide inputs of up to 84 bytes.

Okay, so you place inputs to a board. What does each input do?

The "step" function

Once it exits the for-loop, it enters a do...while-loop, which seems to repeatedly call the function step. Once the function returns the value of 0, it exits the loop, thus terminating the process. Let's see what it does.

The function is just essentially a switch statement with a bunch of cases, each of which represents a unique instruction that a process executes. Notably, many of these instructions utilize the variable called stack, which is used to store data needed to execute instructions. To save some time on trying to figure out what each instruction does, I copied the entire thing and asked an LLM to tell me what each of them does. Here is a response from it:

Here is a breakdown of what each case in the switch statement does, identified by its hexadecimal value and corresponding ASCII character:

case 0x21 ('!') - Logical NOT:
Pops the top value from the stack. If the value is 0, it pushes 1 onto the stack. Otherwise, it pushes 0.

case 0x24 ('$') - Pop:
Discards the value at the top of the stack.

case 0x25 ('%') - Modulo:
Pops two values from the stack (let's call them a and b, where a is the top value). It then calculates b % a and pushes the result back onto the stack.

case 0x2a ('*') - Multiplication:
Pops two values (a and b) from the stack, multiplies them (b * a), and pushes the result onto the stack.

case 0x2b ('+') - Addition:
Pops two values (a and b) from the stack, adds them (b + a), and pushes the result onto the stack.

case 0x2c (',') - Output Character:
Pops a value from the stack and prints it to the console as its corresponding ASCII character.

case 0x2d ('-') - Subtraction:
Pops two values (a and b) from the stack, subtracts them (b - a), and pushes the result onto the stack.

case 0x2e ('.') - Output Integer:
Pops a value from the stack and prints it to the console as a decimal integer.

case 0x2f ('/') - Division:
Pops two values (a and b) from the stack, divides them (b / a), and pushes the integer result onto the stack.

case 0x3a (':') - Duplicate:
Duplicates the value at the top of the stack. If the stack is empty, this will result in an error.

case 0x3c ('<') - Go Left:
Sets the direction of program flow to the left. The program counter will now move left in the next step.

case 0x3e ('>') - Go Right:
Sets the direction of program flow to the right.

case 0x40 ('@') - End Program:
Terminates the program by returning 0 from the step function.

case 0x5c ('\') - Swap:
Swaps the top two values on the stack.

case 0x5e ('^') - Go Up:
Sets the direction of program flow upwards.

case 0x5f ('_') - Horizontal If:
Pops a value from the stack. If the value is 0, the direction of flow is set to the right ('>'). Otherwise, it is set to the left ('<').

case 0x60 ('') - Greater Than: 
Pops two values (aandb) from the stack. It checks if b > a. If true, it pushes 1 onto the stack; otherwise, it pushes 0.

case 0x67 ('g') - Get:
Pops a y-coordinate and then an x-coordinate from the stack. It retrieves the ASCII value of the character at that (x, y) position on the board and pushes it onto the stack.

case 0x70 ('p') - Put:
Pops a y-coordinate, an x-coordinate, and a value from the stack. It then modifies the board by placing the character corresponding to the value's ASCII code at the specified (x, y) position.

case 0x76 ('v') - Go Down:
Sets the direction of program flow downwards.

case 0x7c ('|') - Vertical If:
Pops a value from the stack. If the value is 0, the direction of flow is set downwards ('v'). Otherwise, it is set upwards ('^').

default:
This block handles any characters not explicitly covered by the other cases. It specifically checks if the character on the board is '0' (ASCII 0x30). If it is, it pushes the integer value 0 onto the stack. For any other character (e.g., '1' through '9' or other symbols not defined), it does nothing and the program counter simply moves to the next position.

So, to summarize what you can do with these instructions:

You can move around the board. Wherever you land at is exactly an instruction that an interpreter will execute.
You can add, subtract, multiply, and divide the top two values on the stack.
You can output what is on the stack, either in the form of an ASCII character or an integer.
You can duplicate the top value or swap the top two values on the stack, essentially changing their positions.
You can flip the value on the stack either from 0 to 1 or any non-zero value to 0.
Lastly, you can insert a value to a certain cell, and retrieve a value from a certain cell on the board and push it to the stack.

Mind you that, for the number 6, there is a huge caveat that limits which cell you can insert a value to or get a value from: with the help of the variable rows and cols, it forbids you to access values off the board. For example, the very logic is implemented in the if-statement of the instruction 0x67 (an instruction for pushing to the stack the value at a certain cell) from the line 162 to 167. If the top value on the stack exceeds the value of the variable rows, which is 0x32 (50), or the 2nd top value on the stack exceeds the value of the variable cols, which is 0x16 (22), it terminates a process early.

So, like I said earlier, our goal is to somehow make it output the flag for the completion of the challenge. Being aware of the fact that we can't access values off the board and that the flag we are trying to output is not on the board, how can we potentially access values off the board?

Like I said, the caveat is that both rows and cols are used to prevent access to values off the board. Can we perhaps modify either of the values in order to access values off the board?

Where Are Rows and Cols?

Going through the disassembly, I discovered that both rows and cols are located right after the board variable. Both rows and cols occupy 4 bytes each. Modifying either of those values to a value that exceeds their original values allows us to access values off the board! Let's see if we can modify them.

Above is a screenshot of the instruction 0x70, which is used to insert a value at a certain cell. The mechanism with which it chooses a cell on the board is the following:

The address of the variable board + (0x16 * row) + col.
- row is the very top value on the stack. It can be any value from 0 to 50.
- col is the 2nd top value on the stack. It can be any value from 0 to 22.

Okay, so ideally, if we were to choose a cell on the end of the board, we would need both row and col to be their respective max values. So, for (0x16 * row), let's pretend that the value of row is 50. (0x16(22) * 50) results in the value 1100. If we were to pretend that the value of col is 22, adding it to 1100 results in the value 1122.

If there are only 1100 cells on the board and we can access up to 1122 cells, we can access up to 22 extra bytes off the board, and since both rows and cols are located right after the board and within those 22 extra bytes, we can modify them!

Where Is The Flag?

Okay, since we have confirmed that the values of both rows and cols can indeed be modified, it's time to find out where the flag is located.

The flag is located somewhere after cols, and the memory for the flag spans 104 bytes. The very first address of the flag is 0x1056e0, and the very last address of the flag is 0x105747. To calculate how many bytes we need in order to access the flag, all we have to do is to subtract the very last address of the variable board from 0x105747. The very last address of the board is 0x1056ab, so it would be (0x105747 - 0x1056ab).

We need to modify the variable cols to contain the value of 156 at least in order to access the entirety of the flag.

Crafting Input

Like I said previously, we can provide up to 4 lines in total, each of which may contain up to 21 bytes. So the maximum amount of instructions that we can provide to the process amounts to 84 bytes.

Okay, so here is what we have to do basically:

Set the variable cols to a value that exceeds 156.
Repeatedly, retrieve and push to the stack each character of the flag, and output each character.

The very first instruction that the interpreter executes is the very first byte of the first input a user provides. By default, once it executes an instruction, it moves to the next cell on the right and executes the next instruction. Unless modifying the direction, once it reaches the last instruction of a row, with the help of modulus, it goes back to the first instruction of the same row.

So, since we have only 84 instructions at max to print out the entirety of the flag, it would make sense to make the most out of it by doing the following:

Above is how I decided to go about crafting the inputs in order to use as many instructions as possible, given our limitation of being able to use up to 84 instructions. Since the first instruction that the interpreter executes is the one on top-left corner, let it go over the first row until the very last column, which moves down to the next row of the same column. And then change the direction to the left and let it also cover the entirety of the row in reverse. The same pattern continues until the very last row.

In order to change the value of the variable cols, we have to calculate the exact row and column that we have to target.

As we can see in a screenshot above, right after the board is rows, which is followed by cols. So, accessing the last cell of the board requires us to set the very top value on the stack to 50 and the 2nd top value to 0, since (50 * 0x16) + 0 results in 1100. Since the cols is located 4 bytes after the last cell of the board, all we have to do is to make the 2nd top value on the stack hold the value of 4, thus resulting in (50 * 0x16) + 4.

So, let's get to crafting the first line of the input for pushing 50 to the stack.

create_50_on_the_stack = b'\x30\x21\x3a\x2b\x3a\x3a\x3a\x3a\x2b\x2b\x2b\x2b\x3a\x3a\x3a\x3a\x2b\x2b\x2b\x2b\x76'
line_1 = create_50_on_the_stack

Here is a breakdown of the instructions of the line 1 above:

\x30\x21\x3a\x2b - Push 2 to the stack
\x3a\x3a\x3a\x3a\x2b\x2b\x2b\x2b - (0x3a) Duplicate the top value on the stack 4 times and (0x2b) add the top 2 values on the stack 4 times. This means 2 becomes 10.
\x3a\x3a\x3a\x3a\x2b\x2b\x2b\x2b - Same as the one above, except 10 becomes 50.
\x76 - Move down to the same column of the next row.

Upon the executions of instructions in the first row, there is only one value on the stack, which is 50. Let's craft the 2nd line of the input.

insert_200_to_cols_1 = b'\x3c\x30\x30\x70\x30\x30\x67\x3a\x3a\x3a\x2b\x2b\x2b\x30\x30\x67\x30\x21\x3a\x2b\x76'
line_2 = insert_200_to_cols_1[::-1]

Here is a breakdown of the instructions of the line 2 above:

\x3c - Change the direction to the left, thus moving leftwards.
\x30\x30\x70 - (0x30) Push 0 twice to the stack and (0x70) write the 3rd top value on the stack to the board using the very top value on the stack as the row number and the 2nd top value on the stack as the column number.
- At this point, upon pushing 0 twice to the stack, the stack has 3 items - (50 (last), 0, 0 (top)). What this means is that we are writing 50 to the first cell of the board in the top left corner. Those values used to write to the board are popped, and the stack becomes empty.
\x30\x30\x67 - (0x30) Push 0 twice to the stack and (0x67) retrieve the value from the board and push it to the stack.
- So, right before this, we inserted the value 50 to the first cell of the board at (0, 0). We retrieve 50 from the top left corner of the board and push it to the stack, so there is only 50 on the stack at this point.
\x3a\x3a\x3a\x2b\x2b\x2b - (0x3a) Duplicate the top value on the stack 3 times and (0x2b) add the top 2 values on the stack 3 times. This means 50 becomes 200.
\x30\x30\x67 - Same as the 3rd one, retrieve 50 from the first cell of the board and push it to the stack.
\x30\x21\x3a\x2b - Push 2 to the stack.
\x76 - Move down to the same column of the next row.

Upon the executions of instructions in the second row, there are three values on the stack, (200 (last), 50, 2).

insert_200_to_cols_2 = b'\x3e\x3a\x2b\x5c\x70\x30' + b'\x3e' * 14 + b'\x76'
line_3 = insert_200_to_cols_2

Here is a breakdown of the instructions of the line 3 above:

\x3e - Change the direction to the right, thus moving rightward.
\x3a\x2b - Duplicate the top value (2) on the stack and add the top two values (2 + 2), resulting in the previous top value of 2 turning into 4.
\x5c - Swap the top two values on the stack.
- So it goes from (200 (last), 50, 4) to (200 (last), 4, 50).
\x70 - Write the 3rd top value on the stack to the board using the very top value on the stack as the row number and the 2nd top value on the stack as the column number.
- What this does is inserting 200 to the (50 * 0x16 + 4), which is where cols is located! After this, cols holds the value of 200!
\x30 - Push 0 to the stack.
\x3e (14 times) - Change the direction to the right. Basically, this doesn't do anything, and the reason why we are inserting this is that we are ready to start printing out characters with the help of the instructions on the last row.

Upon the executions of instructions in the third row, there is only one value on the stack, which is 0.

print_each_char = b'\x3c\x3a\x30\x30\x67\x67\x2c' + b'\x30\x21\x2b' + b'\x3c' * 11
line_4 = print_each_char[::-1]

The last row is where you start printing out characters. Unlike other rows, it doesn't involve moving down to the next row since there is no instruction on the next row. Using the concept of a for-loop here, we repeatedly print out characters consecutively starting from the last cell of the board to every one of the next 200 extra cells after, which include the flag we need.

Here is a breakdown of the instructions of the line 4 above:

\x3c - Change the direction to the left, thus moving leftwards.
\x3a - Duplicate the very top value on the stack. The very top value of the stack at this point is the value of the column that we will use to print out each character. With the output of each character, it increments by 1. Currently, at the outset, it holds 0.
\x30\x30\x67 - Retrieve 50 from the first cell of the board and push it to the stack.
\x67 - Retrieve the value from (50 * 0x16 + column) and push it to the stack.
\x2c - Print out the value at the top of the stack in the form of ASCII character.
\x30\x21\x2b - Push 1 to the stack and increment the column by 1.
\x3c (11 times) - Skip the rest of the row to the next iteration of the for-loop.

Here is a full script that you can use to print out the flag.

from pwn import *

# Set the target host and port
HOST = 'mars.picoctf.net'
PORT = 31689

def main():
    """
    Establishes a remote connection to the specified host and port
    using pwntools, receives initial data, and then drops into
    an interactive shell.
    """
    log.info(f"Connecting to {HOST}:{PORT}...")

    try:
        # Establish a remote connection
        # The 'remote()' function returns a 'tube' object, which can be
        # used to send and receive data.
        r = remote(HOST, PORT)
        log.success("Connection established!")

        # Receive and print initial data from the server.
        # This is useful to see any banners or prompts the binary sends
        # right after connection.
        log.info("Receiving initial data...")
        initial_output = r.recvline() # Adjust if the initial output is multi-line or not line-terminated
        log.info(f"Initial output: {initial_output.decode().strip()}")

        log.info("Dropping into interactive mode. Use Ctrl+D to exit.")

        create_50_on_the_stack = b'\x30\x21\x3a\x2b\x3a\x3a\x3a\x3a\x2b\x2b\x2b\x2b\x3a\x3a\x3a\x3a\x2b\x2b\x2b\x2b\x76'
        line_1 = create_50_on_the_stack

        insert_200_to_cols_1 = b'\x3c\x30\x30\x70\x30\x30\x67\x3a\x3a\x3a\x2b\x2b\x2b\x30\x30\x67\x30\x21\x3a\x2b\x76'
        line_2 = insert_200_to_cols_1[::-1]

        insert_200_to_cols_2 = b'\x3e\x3a\x2b\x5c\x70\x30' + b'\x3e' * 14 + b'\x76'
        line_3 = insert_200_to_cols_2

        print_each_char = b'\x3c\x3a\x30\x30\x67\x67\x2c' + b'\x30\x21\x2b' + b'\x3c' * 11
        line_4 = print_each_char[::-1]

        r.sendline(line_1)
        r.sendline(line_2)
        r.sendline(line_3)
        r.sendline(line_4)

        r.interactive()

    except Exception as e:
        log.error(f"Failed to connect or interact: {e}")
        # In case of an error, ensure the connection is closed if it was opened
        if 'r' in locals() and r.connected:
            r.close()

    finally:
        # Ensure the connection is closed when the script finishes or exits
        if 'r' in locals() and r.connected:
            r.close()
            log.info("Connection closed.")

if __name__ == "__main__":
    main()

Upon executing the script, we get the flag we need for the completion of the challenge!

It wasn't as bad in my thought overall, except for crafting the inputs part, where I struggled only a bit. Thank you for reading this walkthrough, and will post more walkthroughs of other challenges as well soon. Thank you!

picoCTF "Breadth" Walkthrough

SJ W — Tue, 10 Dec 2024 13:10:33 +0000

Long time no see! It has been a while since the last time I posted basically anything in my blog, lol. For the last 3 months or so, I have been extremely busy with life in general, and it may sound like an excuse, but as a result, I didn't come up with time to take on any of the challenges. However, for the first time in a while, life finally allowed me some free time to enjoy spending some time doing what I love to do, and here I am, back with another walkthrough of one of the challenges in picoCTF. Unlike the last time I completed the challenge MATRIX, they no longer award a user with points for completing a challenge, and instead, opted to go with marking each challenge with their level of difficulty. The challenge I completed this time is called "Breadth", and I was surprised by how simple this challenge was, even though it was marked as Hard. Just with any other RE challenges, this involves decompiling binaries using Ghidra, comparing and going through the code to ultimately find the flag that we need for the completion of the challenge. Without further ado, let's go pwn this challenge!

1. Examining the Binaries

Unlike the previous challenges we have completed so far, this challenge has two binaries that a user is tasked with analyzing. Let's decompile these two binaries using Ghidra.

One of the first steps I always take when it comes to RE is to go through a list of function calls at face value, as in, trying to see if there are any interesting functions, including the function "main."

As you can see, there are a lot of randomly named functions without giving any clue to their functionalities? Randomly clicking one of those functions and checking out its content show that there is only one line, which is "return"; however, in the viewer that shows both hexadecimal values and their translations in Assembly language, we are able to see some interesting strings.

It basically loads the address of the string starting with picoCTF{TjVxTcVux2adLBDDDFJ6FMs to the register EDI, which is going to be used as the first argument for the function "puts." Every flag needed to complete a challenge in picoCTF starts with picoCTF{ followed by a series of random characters and a closed curly bracket. It's not just this function that that has a potential flag; basically, there are tens of thousands of the randomly named functions that have a string starting with picoCTF. This led to believe that what we are trying to do is to sort of comparing and ascertaining the differences between these two binaries, in order to ultimately find the function that was changed between two versions. So, let's try to compare them and find out what has been changed!

Before moving on, I had to check out the function main, to cover all the bases to make sure that I didn't miss out on anything that might give a clue to solving this challenge. Upon inspection, I realized that there was basically nothing interesting inside the main function, besides calling itself "Dead code".

2. Comparing the Binaries

To compare the binaries, I decided to opt for the program called radiff2, which is part of the CLI-based RE tool, radare2. I later found out that Ghidra has a function for comparing two binaries, but at the time of tackling this challenge, I wasn't aware of its existence.

Running the tool made me realize that there aren't as many differences between the binaries as I had initially expected. Providing no option to the tool, as you can see, doesn't yield the information on which line is added to and removed from the version 2 of the binary. To do so, we provide the option -u.

We can confirm that the changes in binaries took place in the following addresses:

0x000002d4
0x0009504e

The lines in the red show the hexadecimal values that are removed from the version 2 of the binary, and the green lines show the hex values that have replaced their removed counterparts. Let's go back to Ghidra and search for the series of hexadecimal values of 43 52 e5 d7 4f 75 9f f9 9c 57 06 0c 2b c2 df 27 51 a7 dd a9 located at the address 0x000002d4 to see if it is anything interesting.

Searching for the series of hexadecimal values results in the following section of the code. We are basically at the very beginning of the binary, and the viewer seems to show the metadata of the binary, and doesn't seem to yield anything that has to do what we need at the moment. Let's move on to the next candidate, which is the address 0x0009504e, with the series of hexadecimal values of 48 3d 3e c7 1b 04 74 0a c3 66 0f 1f 84 00.

Okay, searching for those hexadecimal values leads to the following function of the code, with the code viewer showing the potential flag, picoCTF{VnDB2LUf1VFJkdfDJtdYtFlMexPxXS6X}. At this point, I am kind of thinking that there is no way this is a flag we need to complete the challenge. Regardless, let's proceed with submitting this to check if this is indeed the right flag.

It was the right flag, and we completed the challenge. It was really simple compared to other challenges that we did, and I personally think this should be marked either Easy and Medium. Thank you for reading another walkthrough, and I will make sure to come back with something both interesting and challenging for the next walkthrough!

Using Snippets in Visual Studio Code

SJ W — Mon, 10 Jun 2024 14:52:53 +0000

Introduction

Compared to the posts I have uploaded so far, this will be super short and brief, so I will briefly go through the topic of Snippets and how you should utilize it in Visual Studio Code, to ultimately enhance your experience as a developer! I am writing this as an assignment of the coding bootcamp that I am currently attending right now, so like I previously mentioned, it will be very concise and right to the point.

Snippets?

Snippets are simply bits of code that you frequently utilize in your daily coding lives, that you tend to sort of copy and paste in so many parts of your projects. For example, to create an HTML document, you mostly start with the very line, which is <!DOCTYPE html> followed by various tags, such as <html>, <head>, <body>, etc. Quickly, having to repeat the patterns of typing all those manually become somewhat tedious, and you want to find the solution to simply not having to repeat those manually, every time you create a new page for your website. That's where Snippets come in. By using a functionality that simply include the code at your whim, you tend to use less time having to set up the basic structure of code, which simply allows you to save your time and let you work towards your goal from the get-go.

How to use it?

I am currently writing this in context of using Visual Studio Code by Microsoft, since it seems to be the most convenient and advanced form of IDE currently. To enable the functionality of Snippets in VSC, we first have to download the extension called Snippet Generator by the user called fiore.

I will use part of what I am currently working on as an example, in an effort to showcase the usage of the extension we have downloaded. To give you context, as part of the project, I am currently creating the frontend of the bookshop project that I have been working on for some time, using TypeScript and React. In React, there is a thing called a component, which is basically a piece of reusable code that may be used throughout a project. To create a component, you tend to repeat the same process: You first have to create a function, import the same libraries, etc. Like I said, it starts feeling really tedious and annoying. I will show you in an example below, alongside how to register and use snippets.

Regardless of the nature of the language and the project you are working on, as long as you feel like you tend to repeat a lot of the same code over and over again, throughout your experience as a developer, it's going to come very useful.

import styled from "styled-components";
import { useForm } from "react-hook-form";
import InputText from "../components/common/InputText";
import useAuth from "../hooks/useAuth";


const Login = () => {
  const { userLogin, error } = useAuth();
  const { handleSubmit, register } = useForm<LoginFormProps>();

  return (
    <LoginStyle>
        <form onSubmit={handleSubmit(userLogin)}>
            <InputText placeholder="Email" inputType="text" {...register("email")} />
            <InputText placeholder="Password" inputType="password" {...register("password")} />
            <button type="submit">Login</button>
        </form>
        {error && <p>{error}</p>}
    </LoginStyle>
  );
};


const LoginStyle = styled.div`
  padding: ${props => props.theme.layout.medium.padding};
  background-color: ${props => props.theme.color.background};
  border-radius: 0.25rem;
`;

export default Login;

Above is a file for containing the component called Login, which is rendered and displayed on the screen, when a user decides to log in to the website. Some of the notable lines in the code block includes the followings:

import styled from "styled-components";
- styled is used in every page component. Definitely a part worth being a part of the snippet.
const Login
- You may replace the word Login, with any name that you would like to call your component with. Regardless of whatever page component you create, you always have to name a component, so it is something that gets repeated every time.
const LoginStyle
- This is also a bit of code that gets used for every page component. Just with the example above replacing the name of the component, we may replace the substring Login with the same name that the component is named after, so it is definitely worth making this part of the snippet for creating a page component.
export default Login;
- Lastly, using the component Login in other files requires it being exported. This line gets used in every page component, and should be a part of the snippet. Just with the variable LoginStyle, this contains the name of the component, so you know what to do.

Identifying bits of lines that may be incorporated and used in other files that contain a page component, we end up with the following code block:

import styled from "styled-components";

const Login = () => {
  return (
    <LoginStyle>

    </LoginStyle>
  );
};

const LoginStyle = styled.div``;

export default Login;

Okay, so let's get to turning the code above into the snippet!

1. Replace the name of the component

Before we turn those into a snippet that we would like to use over and over again, we have to prep them into being used as one. Like I said, in order to reuse the bits of code above, all we have to do is to replace the name of the component, which in this case is Login, with its respective name. Replace its name with $1

import styled from "styled-components";

const $1 = () => {
  return (
    <$1Style>

    </$1Style>
  );
};

const $1Style = styled.div``;

export default $1;

As you can see, I have replaced the substring Login with the substring $1.

2. Highlight, Right-click them, and choose an option for creating a snippet

If you have installed the extension I mentioned at the beginning, once you right-click the highlighted section of the code, you should see the option called Generate snippet in the options.

3. Choose the programming language

What programming language is the code based on? If you are writing a snippet for C language, then choose C. Since I am trying to use this snippet to automate the initial process of creating a page component, I will choose the option typescriptreact.

4. Name a snippet

Name it how you like!

5. Choose the prefix

The prefix is basically used to generate the snippet in your code. The naming convention seems to be that it should always start with the underscore character, for the fact that it may be more distinct and may not be confused with other items in the autocompletion feature that VSC provides us with.

6. (Optional) Provide a description

Maybe you would like to explain to yourself what it is used for, for future references. This step is completely optional, so you may skip this step by simply pressing the ENTER on your keyboard!

7. Let's use this

Typing the prefix of the snippet that I just created, I get prompted with the following autocomplete. By pressing ENTER, I end up with the following snippet of code, with which I can start working on making a new page component right away!

picoCTF "MATRIX" Walkthrough (Caution: an extremely lengthy post)

SJ W — Fri, 24 May 2024 17:21:12 +0000

Introduction

For this post, we are going to tackle one of the hardest challenges when it comes to the category of Reverse Engineering on picoCTF that is worth 500 points. Certainly, it was a lot harder and took more time to understand and ultimately obtain the flag than two previous challenges I completed, but it was a pretty great learning experience I would say, which taught me a good deal about the mindset and technique I should use to approach reverse engineering in general. Since the challenge is a lot harder than others, the post may be a bit longer than the usual to explain some of the findings, but I will do my best to explain things concisely and right to the point. Without further ado, let's dive in to it!

1. Analyzing the Binary

Start

Just with two previous challenges, this requires one to download the binary and examine the content inside. Let's download and import it to Ghidra for analysis.

Here are various details regarding the binary. In some cases, there may be some noteworthy details that might aid one in finding out what one is working with, but I don't really see anything too interesting in it, so we move on to the next phase where Ghidra commences analysis.

Let's use the default options for the analysis of the binary.

Here we are in the part of Ghidra for examining the innards of the binary. You can check the bottom-right corner to check the progress of an analysis. Once it's done, we start analyzing it ourselves!

"Main" Function

So, the very first thing I do is to check a list of functions that might give away some hints on how we should approach the challenge. Let's check out what kind of functions it has.

I don't even see anything too noteworthy that piques my interest, and in fact, there is no main function that we usually encounter in a binary written in C. Hmm, I think this binary is written in C and compiled with GCC, but I don't see any function called main. However, there is a function called __libc_start_main, which is called inside the function entry. Let's check out the function entry.

The function __libc_start_main is provided with the total 7 arguments. There are a few interesting arguments worth checking out. In Ghidra, any function that cannot be named, due to it being stripped during the compilation process or for some reason, gets assigned a random name that starts with the substring FUN_. As you can see, there are a few arguments whose name starts with the substring FUN_. So what one can deduce is that one of the functions passed to the function __libc_start_main is called when the program starts? Rummaging through the Internet, I come across this help page for the function __libc_start_main.

The page basically states that the function __libc_start_main is called to initialize the environment for a process, prior to executing the main function we call. The very first argument passed to the function is actually a function pointer for the main function that will be executed, once the preparation for running a process is done. The name of the function we must check out is FUN_001010d0. Let's move on to checking out the very function FUN_001010d0.

Seems like we are at the right place to start figuring out how things work!

In the screenshot right above this paragraph, line 39 outputs the string Have a flag!, which subsequently in the next line outputs the flag we need to complete the challenge. Since we are in the initial stage of analysis, it is still very unclear what we should do to lead the binary to output the flag in general. Let's investigate the function for more clues.
From line 32 to 34, it repeatedly calls the function FUN_00101350 inside the do...while block. The function FUN_00101350 is provided with total two arguments, &local_168 and local_16c. In line 37, it checks the first value of local_16c to see if it amounts to a NULL byte (0), and once it checks that it is indeed a NULL byte, it proceeds to the next line to check whether the value of the variable local_16a is a NULL byte as well. Based on the information I laid out, you can presume that the variable local_16c is passed to the function FUN_00101350, and somehow gets modified after each execution. The character & indicates that it accepts the address of the variable local_168. So what does the variable &local_168, the first argument of the function FUN_00101350, contain?

The variable local_16a gets assigned the address of the data DAT_001020f0. Since its name starts with the substring DAT_, we can presume that it may be pointing to a constant data that is located somewhere within the binary. Let's check out what data it contains.

Okay, we end up at the address of 0x1020f0, and it contains a byte, which is equal to the value of 0x81. And in the next bytes, the values 0x75, 0x00, 0x80 are laid out. Still not sure about its purpose. After further investigating and scrolling around, I find something interesting.

Let's read this thing from bottom to top: m a k e i t o u t a l i v e ?.

Another interesting artifacts that read like the following, when you read it from bottom to top: Congratulations,.

Actually, let's run the binary in a VM to check out how it works at face value.

Okay, at the outset, it actually outputs the message WELCOME to the M A T R I X \n Can you make it out alive?. Did you notice that at the last part of the output, it contains the substring make it out alive? that we found during the analysis of the binary?
Subsequently, I input a random string to see what happens, and press ENTER, and am instantly greeted with the message You were eaten by a grue.
So, I basically have to provide the right password to the binary to eventually obtain the flag. What's the right password? Let's go back to Ghidra and investigate further statically.

Exploring the function "FUN_00101350"

Back to Ghidra! Since the function FUN_00101350 seems to be the one that dictates the overall flow of the binary, it's time to check out its contents.

Okay, so this is quite a lot to digest, with nearly 200 lines of code welcoming us right before our eyes. Nonetheless, we have to go over the entirety of the function, in order to figure out what's going on.

Here are some references that you should know prior to continuing. These will be referenced throughout the post, and will greatly help you understand how things work basically:

param_1[0] (param_1 + 0 bytes == 0x00007fffffffdfc0) - holds the address 0x1020f0 (0x00005555555560f0), from which the real program starts. When the function FUN_00101350 gets invoked, the binary passes the address 0x00007fffffffdfc0 to the FUN_00101350 as the first argument.
param_1[1] (param_1 + 8 bytes == 0x00007fffffffdfc8) - holds the offset of two bytes, with which the address, at which the current command is located, is calculated, by adding 0x1020f0 to the offset.
param_1[2] (param_1 + 16 bytes == 0x00007fffffffdfd0) - holds the address of the top of one of the makeshift stacks. This stack gets used the most often. The starting address of the stack is at
param_1[3] (param_1 + 24 bytes == 0x00007fffffffdfd8) - holds the address of the top of one of the makeshift stacks. This stack gets used the least often and is mainly for temporarily storing values needed in another stack.

The register r12 stores the lowest address of the stack at param_1[3], which is 0x0000555555559ab0.
The register r13 stores the lowest address of the stack at param_1[2], which is 0x00005555555592a0.
- Every item on the stack is 2 bytes worth, which means that an item occupies 4 digits at once. And also, considering the fact that the binary is in little-endian, the value starts from the right, so you can read like 0x0001|0001|0000|0061. In the screenshot above, the address at 0x00005555555592a6 holds the value 0061, which is basically the hexadecimal value of a in ASCII. a is the very first character of the input I provided to the binary. So I assume that every character gets placed at the exact address of 0x00005555555592a6 for processing. What about 0x0001|0001|0000| in the front? We will see what they represent.

At this point, all we know is that the function receives two arguments, the first one being a pointer to another pointer - &local_168 gets passed as the first argument, and & indicates the memory address of the variable local_168. local_168, by the way, is assigned an address of 0x1020f0 prior to entering this function - local_168 = &DAT_001020f0; - so we know for sure that it is a pointer.
In line 17, the binary dereferences the pointer param_1, whose value is 0x00007fffffffdfc0, and assigns it to the variable lVar4. lVar4 ends up with the address of 0x1020f0.
In line 18, it adds 1 to the argument param_1, which becomes 0x00007fffffffdfc8. Since param_1 is a pointer of the long type (8 bytes), when you add 1 to it, it is equal to adding 8. And then it change its type from long * to ushort *, which means that it turns into a pointer that can reference up to two bytes only. And lastly, it dereferences the pointer - the first two bytes from the address of param_1 + 1 (0x00007fffffffdfc8) - and assigns it to the variable uVar2.
In line 19, the binary adds the value of the variable uVar2 to 1, and assigns it to the variable uVar9.
In line 20, the binary assigns the value of uVar9 to the address param_1 + 1 (0x00007fffffffdfc8). The value at param_1 + 1 increments.
In line 21, it adds the address 0x1020f0 (0x00005555555560f0) stored in the variable lVar4 to the value of uVar2, which results in the address bigger than 0x1020f0, subsequently converts its type from long * to byte *, and lastly dereference it to fetch a byte from the calculated address.
Summary - The variable uVar2 in line 18 holds the offset, which in line 21 is added to the address 0x1020f0 and subsequently dereferenced for a command that needs to be executed. Let's see what kind of commands there are by going through the screenshots below.

Going through the screenshots, you may notice that there are some notable case clauses with the following values:

0 (0x00)
1 (0x01)
0x10 - 0x14
0x20 - 0x21
0x30 - 0x34
default - 0x80 - 0x81, 0xc0 - 0xc1

Each case clause performs different functions for the binary, but one thing in common is that the most of them use the line at the beginning to fetch the address of the top of the stack at param_1[2]. The binary actually utilizes two makeshift stacks to store various data needed in calculation. The memory address at param_1[2] stores the top address of one of the makeshift stacks that the binary uses. Stacks used in this binary consist of values up to 2 bytes each, so when the binary pushes or pops the stack, the address of the top of the stack increases or decreases by two bytes.

Explaining what each value does in detail may be way too time-consuming, so instead, I will give you the brief explanations of what each does.

0 - It doesn't do anything
1 - Executing this results in the end of the binary. This is where the binary determines whether you have successfully finished the challenge.
0x10 - Copies the value at the top of the stack (-0x2) and pushes to the stack at param_1[2], basically duplicating the value. The value at param_1[2] increases by 2.
0x11 - Pops the stack, whose value at param_1[2] decreases by 2.
0x12 - Adds the value at the top of the stack (-0x2) to the value of the item right below (-0x4), and store it at the offset (-0x4). Then pops the stack.
0x13 - Subtracts the value at the top of the stack (-0x2) to the value of the item right after (-0x4), and store it at the offset (-0x4). Then pops the stack.
0x14 - Swap the value at the top of the stack (-0x2) with one right after (-0x4).
0x20 - This involves two stacks - the one at param_1[2] and param_1[3]. The top of the stack param_1[2] pops and pushes to the stack at param_1[3].
0x21 - This involves two stacks - the one at param_1[2] and param_1[3]. The top of the stack param_1[3] pops and pushes to the stack at param_1[2].
[0x30] - Pops the top of the stack at param_1[2] and puts the offset at param_1[1]. This is where we increments and stores the value in line 20 of the function. It basically changes the flow of the program.
[0x31] - Pops the top of the stack at param_1[2] TWICE. If the second popped item has the value of 0x0000, then change the offset at param_1[1] to that of the first popped item.
0x80 - Pushes the value of a byte to the stack param_1[2]. Increases the offset at param_1[1] by 2.
0x81 - Pushes the value of two bytes to the stack param_1[2]. Increases the offset at param_1[1] by 3.
0xc0 - Accepts the input from a user.
0xc1 - Outputs whatever is on the stack param_1[2].

Most of the commands above only increment the offset at param_1[1] by a number from one to three at most, but ones that are surrounded by square brackets (0x30 and 0x31) drastically change the offset using the value stored on the stack param_1[2], which means that they kind of act like the JMP instruction in Assembly.

Okay, so basically the offset at param_1[1] starts with the value 0, which means that if you add the value 0 to the base address 0x1020f0, it results in the address of 0x1020f0. The very first command located at that address is the following:

There is a byte value of 0x81 at the address 0x1020f0. Revisiting the explanation on the command related to the byte 0x81, we know that it has to do with pushing the value of two bytes to the stack param_1[2]. So which value does it push to the stack? It combines the next two bytes (0x1020f1 => 0x75, 0x1020f2 => 0x00) after the current address 0x1020f0, pushes the very combined value 0x0075 to the stack param_1[2], and lastly, increases the offset at param_1[1] by 3, which results in the next command at the address 0x1020f3 => 0x80.

The very next command 0x80 at 0x1020f3 is also really similar to that of 0x81, albeit it pushes only the value of one byte located right after the given address to the top of the stack, and increases the offset at param_1[1] by 2. So why does it try to achieve from pushing a bunch of bytes to the stack? When you run the binary, it actually outputs the intro message before you have to input an answer. Basically, it is preparing to output the message Welcome to the M A T R I X\nCan you make it out alive?!

Once it fully pushes all the necessary bytes to the stack, it eventually reaches the address 0x102161, which holds the byte 0x81. It pushes the value 0x013b to the top of the stack, increases the offset by 3, and proceeds to the next command 0x30 at 0x102164. At this point, the very value at the top of the stack at param_1[2] is 0x013b. The command 0x30 pops the stack at param_1[2] to param_1[1]. The next command after this will be calculated by adding 0x013b at param_1[1] to the base address 0x1020f0, which results in the address 0x10222b.

Having learned how the binary works, one thing that comes to my mind is basically this: At which address does it accept our input? Let's go back to the dynamic analysis of the binary and check the address at which we wind up for providing our answer to the binary.

One way to figure out the offset at which the command for accepting an input from a user is to stop the process upon the invocation of the function that accepts the input! Upon going through Ghidra, we discover the following code.

Inside the main function FUN_001010d0, we discover the lines above, at which the pointers to some unknown functions are passed to the variables. Let's click each function and where we end up at.

Clicking the function FUN_00101320, we end up at the address 0x101320. Inside it, we discover the line that calls the function getc whose argument is stdin. The function getc alongside stdin as the argument causes the program to stop and accept an input from a user! So what we have to do right now is to stop the program upon the process calling the function getc. And then skipping a few steps, we end up finding out the exact address, at which the command for accepting an input from a user gets invoked.

The process stops upon entering the function getc. With that, I type the GDB command next multiple times, until the program accepts an input from a user. I type in asdfasdfasdfasdf and press ENTER to continue.

Eventually, the process exits the function getc and returns back to the function FUN_00101320. One thing to note is that the instruction for calling the function getc is located at 0x55555555532b inside the function FUN_00101320. Let's briefly go back to check out the line that is responsible for calling the function FUN_00101320. In order to do that, we go back to GDB and type the command si a few times, until we exit the function FUN_00101320.

We wind up at the address 0x5555555555c5. Going back to Ghidra and searching for any address that ends with 5c5, we find the following:

The last two screenshots contain the identical instructions, and upon clicking the instruction at the address of 001015c5 in Ghidra, we learn that the command c0 is responsible for accepting an input from a user.

The very next offset at param_1[1] after accepting an input from a user is 0x7c, and it is stored in the rax register. We know this for sure, for the fact that inside the function FUN_00101350, it passes the offset to the variable uVar2. When you click the variable uVar2 and checks the assembly code to see which line is associated with the line, you see that the instruction at the address 00101357 passes the value to the rax register.

Processing input from a user

Adding the offset 0x7c to the base address 0x1020f0 results in the address 0x10216c.

Let's basically go through what is going on above. The only valid characters that the binary accepts for an input are the followings:

Providing a character other than those above results in the binary outputting the message You were eaten by a grue. This is how it works.

After accepting an input, the binary pushes the first character of your input to the stack at param_1[2].
It first pushes the value 0x75, a hex value for the character u, to the top of the stack at param_1[2].
Using the command 0x13, it subtracts the first character of your input from the value at the top of the stack, which is 0x75, pops the stack, and replaces the value at the top of the stack with the calculation result.
It then pushes the new offset value that may potentially replace the offset at param_1[1] to the stack.
Using the command 0x31, if the calculation result is 0, it replaces the offset at param_1[1] with the new offset value that was pushed to the stack at param_1[2] in the previous step. Lastly, the stack at param_1[2] pops twice. If the calculation result is not zero, proceeds to the next step:
- u --> 0x102190
- d --> 0x10219a
- l --> 0x1021a4
- r --> 0x1021b0
The steps 2-5 repeat until a character matches 0x64 == d, 0x6c == l, or 0x72 == r. If not, you fail the challenge, and are greeted with the message You were eaten by a grue. Once the binary pushes the value 0x00FB to the stack at param_1[2], you can assure that you are doomed to fail the challenge, because the offset 0xFB added to the base address 0x1020f0 is the very address for printing out the message for the failure of the challenge!

A series of characters consisting of those characters? u means UP, d means DOWN, l means LEFT, and r means RIGHT. Yes, you are basically navigating the maze that a single wrong step leads to your demise.

Creating the script that simulates the binary

So far, we have extensively covered the binary. It's really grueling to manually go through every single command to fully keep track of how the binary works. Starting at the base address 0x1020f0, it ends at the address 0x1026c1, which means that there are about a thousand of the commands to go through to fully understand the inner-workings of the binary. Going through this manually might take forever to cover every little detail it contains. What about creating a Python script that simulates the inner-workings of the binary? That's what I set out to do.

Why creating a script that replicates the inner-workings of the binary? I can fully control and observe how the state of both stacks at param_1[2] and param_1[3] changes after processing each character, without the help of GDB, outside the VM.

In order to replicate the inner-workings of the binary, we have to sort of understand how the binary works right after it accepts an input from a user. Some of the things we will take into considerations are the followings:

The state of the stack at param_1[2] - With every character being processed by the binary, the binary produces a sort of accumulative results and saved them to the stack for future calculations.
The state of the stack at param_1[3], which is temporarily used for storing data from the stack at param_1[2].
How each command manipulates those two stacks above - The commands we discussed above directly manipulates the stack at param_1[2].

Here is how I came up with the script that simulates the binary:

Parse all the available commands starting from the address of 0x1020f0 to the address of 0x1026c1, since those are what the function FUN_00101350 executes into the JSON file.
Create a script that simulates the binary.

Creating a map of the maze inside the binary

The only allowed characters are u, d, l, and r, as an input, and we can presume that those are characters used to navigate the maze that somehow leads to the exit. So, if there is the maze, can we actually map it? One thing that we have to take into consideration is that any step that leads the offset at param_1[1] to become 0x00FB is to be avoided! Let's go back to Ghidra and go through the list of commands a bit to find all the the addresses with the value of fb.

There are a lot of 0xfb in a list of commands from the base address 0x1020f0 to 0x1026c1.
The first address with 0xfb is 0x0010218d. This address actually is not that relevant to the maze, since 0xfb at this address is pushed to the stack at param_1[2] upon finding out that one of the characters of an input of a user is not u, d, l, r.
The really interesting address with the value of 0xfb starts at the very next address 0x102265. The next values of 0xfb are found at the address 0x102269, 0x10226d, 0x102271, etc. 0xfb is placed next to each other at the offset of 4 bytes consistently, which continues until the address of 0x102667, the one with the last value of 0xfb.

Starting from the first relevant address 0x102265 that contains the value of 0xfb and scrolling down the list of commands, you notice that every value 0xfb is preceded by the value of 0x81, which makes sense since the command 0x81 is used to push the value of two bytes located right next to it. Basically, 0x81 pushes the value of 0x00fb to the stack, prior to the command 0x30 changing the value of the offset at param_1[1].

Okay, so what we are sure about is that the actual map may be starting from the address of 0x102264, which holds the value of 0x81. Increasing the address in increments of 4, you notice that each address ends up with either the value of 0x81 or 0x30. 0x30's are definitely safe, for the fact that it doesn't replace the offset at param_1[1] with the value of 0xFB.

The address 0x102664 is the last address in increments of 4 starting from the address 0x102264, before the last value of 0xFB at the address 0x102267. So if I were to subtract 0x102264 from 0x102664, I get the value of 1024 in decimal. Considering the fact that the binary increases the address in increments of 4, dividing 1024 by 4 results in the value of 256. If you multiply 16 by 16, you get 256. Are we dealing with a 16 * 16 grid? With that very conjecture, let's create a simple Python script for visualizing the maze.

Here is what I did:

Create a two dimensional array for storing 16 arrays of 16 elements.
Starting from the address at 0x102264, you evaluate the followings:
- If the value at the address is 0x81, and the value at the very next address is 0xFB, you are dead. Mark it with -
- If the value at the address is 0x81, and the value at the very next address is not 0xFB, you are alive. Mark it with O
- If the value at the address is 0x30, you are alive. Mark it with O
Increase the address in increments of 4, and repeat the step 2, until the last address of 0x102664.

When you run the script above and output the grid, you get the following result.

That looks like a breakthrough! So, where do we actually start the maze from? It's got to be the very first corner at the top left of the maze, and our goal is to get out of the maze through the only exit at the bottom right corner.

If we were to start from the top left, we can technically exit the maze with the following: rrrddrrrrrrddddddlllllddrrrrdddrruuuruuuuuuurrddddddddlddrd. Let's see if it works or not.

It is wrong! Frustrating. Let's check out why we got it wrong and how we can fix this, by analyzing the binary. The key to analyzing why we got it wrong is checking the states of those two stacks at param_1[2] amd param_1[3].

Analysis of the first failed attempt

Let's modify the script that simulates the binary for debugging purposes, by having a look at the stacks.

So moving right three times seems perfectly okay, and interestingly increments the value at the lowest item on the stack at param_1[2] by 1 with each move to the right. The problem occurs when we try to move downwards. Let's see what is being pushed at the very address that seems to be causing the problem. Starting from the very first item in the 2-D array we created for visualizing the grid, we wind up at the address 0x1022F4.

The address 0x1022F4 holds the value of 0x81, and it seems to push the value of 0x0574 and ultimately replace the offset at param_1[1] with it. Are there several addresses with the value of 0x0574 in the list of commands?

There are about 5 addresses between the address of 0x102264 and 0x102664 with the value of 0x74. Let's factor that into the map, fix the script, and see the difference between the previous one and the new one.

I marked every address that pushes 0x574 with the plus sign, and yes, they are all placed in the path to the exit. So, how do we possibly pass this? In midst of trying various methods, I find something very, very interesting.

So I know for sure that, from the starting point, I can move to the right the five times max, and when I do that, the third value from the lowest on the stack at param_1[2] increments by 1. Is the third value from the lowest on the stack the key to passing through the plus sign that we discovered earlier? Let's go back to the starting point, and see if we can move downward this time.

I was able to move downward with the input rrrrrlllllrrrdd! The third value from the lowest on the stack decrements by 1, whenever you go past the plus sign! So, since there are total five plus signs that we have to get past, in order to exit the maze, that means that the third value from the lowest on the stack must be at least 5. With that in mind, let's create the input and check if it works.

I provide the input rrrrrlllllrrrrrlllllrrrrrlllllrrrrrlllllrrrrrlllllrrrddrrrrrrddddddlllllddrrrrdddrruuuruuuuuuurrddddddddlddrd, and yes, it seems like I got it right! Let's try it on the binary being run on the server by picoCTF, and obtain the flag!

Yay! I got the flag, and submit it for the whopping 500 points!

This is the end of the walkthrough, but I feel like I didn't explain about how I came to the conclusions in some parts. I will review this post and revise and fill in some of the missing parts from time to time! Thanks for reading!

Link to the scripts I made for this challenge

TailwindCSS vs Semantic CSS

SJ W — Thu, 23 May 2024 17:09:08 +0000

Introduction

Currently, I am participating in the bootcamp for the full-stack web development, and started and finished the simple project using the React Framework, and in order to make your website look presentable, you cannot forgo using the HTML's best friend, CSS. Even though I could have chosen the path of creating the separate CSS files and defining various CSS rules there, I chose to go with one of the most well-used CSS frameworks at the moment, which is TailwindCSS. So, at the very outset of my journey to web development, I was utterly hopeless when it comes to designing the website, and for that fact, TailwindCSS has basically been my go-to when it comes to styling my website. Despite its reputation for being verbose - to achieve something complex, you end up with an insanely long string of various classes - I gave it a shot and was instantly hooked on its usefulness and quickness for being able to come up with the somehow decent-looking website. Thus, I was no longer hopeless, and found creating the website much more enjoyable.

Recently, however, watching the instructor use some sort of the CSS-related library from NPM that resembles the plain CSS, it got me questioning whether what I am doing - using the approach of TailwindCSS - is really the right thing to do or not. So I started googling basically something along the line of Is TailwindCSS bad? and wound up in the thread that was wildly varying in opinions on which one is better. To get myself really acquainted with both the pros and cons of what TailwindCSS is doing versus the basic plain CSS - Semantic CSS, I thought that it would be good to do due diligence spending some time learning and comparing both pros and cons of both approaches, especially for those that are stuck in making a choice between those two.

For this post, I am going to go over each, and present both their pros and cons for the readers to equip with knowledge for making a right decision for themselves.

Semantic CSS

Semantic CSS refers to so-called, the vanilla CSS that we first approach when we learn CSS. There are often three ways of styling various HTML elements using the plain CSS:

Use the inline style for an element that you want to apply designs to.
Use the <style> HTML tags inside an HTML page, for specifying the CSS rules for a specific page.
Use an external file whose name ends with .css. There, you may specify a bunch of rules in the same way as the approach above; however, you may import those files to one or more pages, and apply the styles to the HTML elements simultaneously.

Here is usually how we use the plain CSS, for example:

<head>
<style>
.flex-container {
  display: flex;
  justify-content: center;
  align-items: center;
  color: red;
}
</style>
</head>

<body>
<div class="flex-container">
  <div>Container 1</div>
  <div>Container 2</div>
  <div>Container 3</div>
</div>
</body>

The approach above is what we do with the approach number two. Basically, it requires one to create a CSS rule with a name - in the example above, it defines a rule named .flex-container that must be used with the class attribute in one or more elements. You are not limited to creating rules with mere classes, instead, you may even go further, by separately designing each element based on the value of its id attribute by prepending it with #, as well as the name of the HTML tag, which requires no special letter to be prepended.

Some of the advantages for the plain CSS include:

Customizable - Obviously, this is the biggest advantage, but for those that must be in complete control over how the design of the website should be, then this is for you. Using the vanilla CSS makes much more sense for those that want to create something complex that involves animations and transitions. With the right amount of creativity and know-how, the sky is the limit when it comes to coming up with what you like!
Succinct - As opposed to forcing the source code of the HTML page with the bombardment of the inline classes like TailwindCSS, you can separately define CSS rules in external files ending with .css, and import them to the HTML pages. Like I said, this may be a major advantage to those that prefer not seeing the source code filled with the bunch of classes. It looks way cleaner!
Fast Rendering Speed - Not sure if it really matters, since there is about a 0.4-second difference when it comes to it, but based on the metrics of both LCP and FCP. FCP (first contentful paint) is a metric for how long it takes for a user to see the very first item on the page, whereas LCP (largest contentful paint) is a metric for how long it takes for the page to adequately render to be usable by a user. The vanilla CSS has apparently the advantage, which kind of makes sense, I guess due to the fact that the files of TailwindCSS are a lot bigger than that of the vanilla CSS?
Learning - Actually, there is no better way to learn CSS at a much deeper level than trying to use it without the help of frameworks. You can definitely achieve a lot of insanely cool stuffs with vanilla CSS, and if that is what you are looking for and you want to learn more about CSS in general, you should at least try to stick with vanilla CSS, before moving on to frameworks, such as TailwindCSS, that may or may not make your life easier.

Tailwind CSS

TailwindCSS is the CSS framework that provides a set of utility classes, which basically allow a user to design without creating a custom CSS file. All you have to do to use TailwindCSS is to download all the necessary files via CDN or NPM, depending on the medium you are working on your project, and simply include the available classes to HTML elements in a page. Let me show you an example below.

<div className="grow w-full text-left px-10 flex flex-col justify-center items-center text-white text-xl gap-5">
    <h1>Select a board :(</h1>
    <h1>Or create one!</h1>
</div>

Yes, it may look extremely verbose and confusing to many people. Since you have to be aware of what each class does to the looks of the element, there may be a bit of a learning curve for those that first try this, but once you get used to its class-based approach and functionalities, it becomes less of an issue moving forwards. Some of the advantages of using TailwindCSS include:

Development Speed - The ease of applying a predefined set of classes to elements greatly increases the web development. Also, you don't have to name each CSS rule, for the fact that everything is already named for your convenience.
Maintainability - Imagine the situation where you have to revisit the old HTML code that has been sitting on your computer for a long, long time. The consistency in the name of every class throughout its evolution allows one to easily revisit and understand the code with ease. Imagine hiring a new developer that knows TailwindCSS and goes through your company's source code, that would greatly save time from having to educate a new developer on the design system.
Frequent Update - One thing that I didn't think about, but if you are frequently updating the pages of your website, then it may be better to approach using TailwindCSS. The reason is that the frequent update of the website may make keeping up with CSS rules much more arduous, than being able to directly adjust the looks of the element individually by incrementally changing the classes of each element?
Consistency - Using a predefined set of classes that are readily available for you throughout the entirety of the application provides the website with much more consistent looks. People who came up with this framework definitely took into considerations the need for a consistent design system. If you are not a designer, but somehow need to come up with a decent-looking UI, a gigantic mess of inline classes, with which TailwindCSS is associated, becomes less of a big deal.
Responsive - I guess this is one of the biggest selling points of TailwindCSS, but yes, you can easily implement the responsive design of the website, by using what we call the breakpoint. Here is an example:

<div className="w-full md:w-[300px] ...>

The element above has two classes, w-full and w-[300px]. As you can see, in front of w-[300px], it has the md:, which is a breakpoint that tells the browser to resize the width of the element to 300px, upon the width of the viewport exceeding 768px. The breakpoint md is associated with 768px by default, and if you would like to map the breakpoint with a different value, you are free to do so with the use of the config file!

What's better?

There is no clear, right answer to this, because both have its own strength that make each stand out over one another. I guess it all comes down to this:

If you are working on designs that are highly specific and require granular control over how it should look, then Semantic CSS may be the choice for you.
If you are working on a project that requires fast prototyping and very little of animations and transitions, you may easily get away with TailwindCSS. Not merely limited to its predefined set of utility classes, you can easily customize it to your likings, just as well as Semantic CSS.

If anything, you can always mix the both approaches and simply take advantage of each approach! Like I said, there is simply no right or wrong answer. Both approaches warrant use cases, and you can't go wrong with any one of them. If not, then try things like SASS, which seems like another method for utilizing CSS in a fancy way.

I will continuously update this post, since I didn't spend too much time on organizing my thoughts on this topic and its structure. This post feels way too incomplete and horribly thought-out, so I will keep updating this. Thank you.

picoCTF "Classic Crackme 0x100" Walkthrough

SJ W — Sun, 12 May 2024 16:32:42 +0000

Introduction

In this post, we are going to go through the walkthrough for the challenge of Classic Crackme 0x100 on picoCTF. The last post was also about one of the challenges hosted by picoCTF, but this one is a lot harder for the fact that it awards much more points than the last one (+200 points more)! Indeed, it felt a lot harder than the last one, for the fact that it is more complex and involves a bit more thinking on understanding the mechanism by which this binary works; however, just like the last one, this challenges involves decompiling the binary and finding the flag for the challenge. To get the flag, I used tools such as Ghidra and a custom Python script, and was able to solve it after a few tries for some time. Let's go and pwn this!

Classic Crackme 0x100

Just like the last challenge I completed, we need to download the binary and examine its content to find the flag we need to submit for the completion of the challenge. Let's download it and examine it with the tool Ghidra.

1. Examine the binary

The name of the binary is crackme100. It is basically a binary that can be run in x86_64 Linux systems.

This shows a list of options that you may use to examine a binary. Let's just leave it as it is and analyze the binary on default options.

Okay, we entered the screen that displays the result of a decompiled binary. The first thing I do is to check out a list of functions that exist within a binary and see if there is anything interesting. Let's check out a list of its functions.

Checking out the list of its functions, I couldn't find any function with an interesting name, which naturally led me to examining the function main, which is the entry point for every binary that is written in C.

Upon checking out the function, we notice a few interesting points that hints at capturing the flag.

In line 33, it has a function called printf displaying the text to the screen for instructing a user to enter the secret password. So, with that, you can easily assume that it has something to do with a user providing its input and checking if it is indeed the password that the binary is looking for.
From line 51 to line 55, it seems to compare the contents of two different pointers, which made me assume that they are both pointing to addresses containing the string. Once the comparison is made, when both match with one another, the binary jumps to line 53, which displays the following string to a screen: SUCCESS! Here is your flag: %s\n","picoCTF{sample_flag}.

Okay, so what is the exact password that one needs to provide, in order to complete this challenge?

From line 25 to line 31, there are five variables holding the hexadecimal values of the size of 8 bytes each, one variable holding a hexadecimal value of the size of 7 bytes, and lastly, another variable holding a hexadecimal value of the size of 3 bytes. Let's see if they are placed adjacent to one another, to see if they together form a giant string.

Finding the right password

According to memory layout of the function main, the very first variable (local_68) with a hexadecimal value is placed at the address of EBP minus the offset of 0x68, and the variable after this (local_60) gets placed right after the variable local_68, which basically confirms that they together form a string when the variable local_68 is referenced using its pointer. From local_68 to local_48 holds a string the size of 40 bytes total, and the very last variable in the screenshot above, which is local_40, holds a string the size of 11 bytes. So when you add 11 to 40, it results in total 51 bytes. So is the password a string of total 51 bytes? No, it is actually 51 bytes minus 1 byte, because a string in C should always end with a NULL byte to mark the end of the string, so the very last byte is likely to be a NULL byte, which doesn't count as part of a string in C. So, the password is likely to be of the size of 50 bytes. So what's the password? Let's actually run the binary in a VM and see what the password is.

Here is a screenshot of running the binary. It basically accepts a password from a user, and compare it to the password that it holds. In this instance, inputting the random string fails and exits the process. Let's check out the password that our password is being compared to using the GNU Debugger.

So, in order to analyze the running binary, we have to first set the breakpoint, at which we can see the string itself. A breakpoint is essentially the point at which we can completely stop the program from executing further. At line 34 is where the program stops to accept a password from a user using the function called scanf. And the very second argument passed to the function scanf is a variable local_a8, a pointer to an array of type char where our input is going to be stored. In line 51, the binary compares the alleged password local_68 with our input local_a8, using the function called memcmp. So we can set the breakpoint at where memcmp is called, and check out what the alleged password is. Let's go ahead and try.

We set the breakpoint at where the function memcmp is called, by typing b memcmp. And we run the binary, by typing in run.

The process is created, and it asks for the password again, just like the first time we ran the binary. I type in asdfasdfasdfasdfasdf and press ENTER.

The screenshot above is a screen upon invoking the function memcmp, and as you can see, we can observe what it does, by watching the contents of its registers, stacks, flags, etc.

In the code section shows the exact instruction that the code is currently running. The highlighted line in green text is the next instruction that the process is planning on running when you decide to proceed, and its angle brackets(<>) has the word memcmp+0 inside to show the function that it is about to run, so we are basically about to run the function memcmp. Let's move on to executing next instructions, by typing in si and next until we stumble upon something interesting.

After executing a number of instructions, we stumble upon some weird strings on stack memory. Those strings consist of 50 characters each, and we are currently in the code where we are comparing two strings with one another. That means, one of them has to be the password that we have to match! One thing to note is that the string we provided (asdfasdfasdfasdfasdf) at the start of the process is no longer to be seen, and transformed into one of those two strings. So which one is the right password, and which one is our input? Let's go back to Ghidra and find out.

Hovering a cursor over the hexadecimal value of local_68, the very start of the right password to match our input against, we see the information above in which we can see how they are converted to either a decimal or a series of characters. Right next to char[], we see the following string jhpnnkpm. The one thing we learned from solving the last challenge is that the string is stored in little-endian (reversed), so if we reverse the string, it becomes mpknnphj.

So the string that starts with mpknnphj is the password, and here is that very string! So the one that starts in avgl is the string we have provided (asdfasdfasdfasdfasdf), and it has turned into something completely new. That means there must be a section of code that converts our string into something brand new, and our job is to find the string that, after conversion, turns into the exact string that starts with mpknnphj! Let's go back to Ghidra and see how its encryption works.

Understanding how its encryption works

Here is an excerpt of code relevant for the encryption of an input we provide to the binary. The code is really hard to read in general, due to a lot of variables whose names are prefixed with local. So, we will have to sort of modify the code, by changing the names of those variables into something readable, and understand how it works.

Let's go over the mechanism by which its encryption works, by going through the code above.

In line 7, the process determines the length of the variable right_password (local_68), the address of the right password, and subsequently, in line 8, assigns its length to a variable right_password_length (local_14). In line 15, the process iterates over the for-loop exactly 50 times by comparing its counter to right_password_length.
From line 14 to line 15, we see the nested for-loops, and line 14 shows that it exactly repeats the process 3 times. With every iteration in a for-loop in line 14, the for-loop at line 15 goes over every character of the password provided by a user. Since the counter involved in it goes from 0 to 49 (50 times), it goes over and transform each character of our input into something new, by the method with which it encrypts a string.
So, the conclusion is that it repeats the encryption process the total three times, with every iteration transforming each letter of our input.

Time to delve into how it transforms each character of our input! The second screenshot above from this shows a list of variables used in the encryption process. They are basically nothing but numbers used to modify each character; however, the screenshot very above this is where all the magic happen.

In line 16, it executes the line in sequential order. The variable local_18 holds the constant value of 0x55 (85).
- (password_index % 0xff >> 1 & local_18) // Let's call this "Operand 1" - 1. Two operands on modulus --> 2. Shift bits to right once --> 3. Do AND bitwise operation
- (password_index % 0xff & local_18) // "Operand 2" - 1. Two operands on modulus --> 2. Do AND bitwise operation
- local_28 = (Operand 1) + (Operand 2) - Add both and assign the result to the variable local_28.
In line 18, it utilizes the variable local_28 from line 16 for further computation. The variable local_1c holds the hexadecimal value of 0x33 (51).
- ((int)local_28 >> 2 & local_1c) // "Operand 1" - 1. Shift the bits of local_28 to right twice --> 2. Do AND bitwise operation
- (local_1c & local_28) // Operand 2 - 1. Do AND bitwise operation
- local_2c = (Operand 1) + (Operand 2) - The result of addition of Operand 1 and Operand 2 gets assigned to the variable local_2c, which is going to get utilized in the very subsequent line of code.

For both the line 16 and 18, what I noticed is that they don't involve the input of a user at all. All they require is an index at which a character is located, so since they will always retain the constant values depending on a very index, and are definitely used for encrypting each character of our input, let's make a note of this and move on to the next line, which is line 20.

In line 20, it utilizes the variable local_2c from line 18 for further computation. The variable local_20 holds the hexadecimal value of 0xf (15).
- ((int)local_2c >> 4 & local_20) - 1. Shift the bits of local_2c to right four times --> 2. Do AND bitwise operation with the value 0xf
- ((int)our_input[password_index] - (int)character_a) - 1. Subtract the decimal value of a character in ASCII with the decimal value of the character "a", which is 97
- (local_20 & local_2c) - 1. Do AND bitwise operation
- iVar1 = (Operand 1) + (Operand 2) + (Operand 3) - The result of the addition of Operand 1, Operand 2, and Operand 3 gets assigned to the variable iVar1, which is going to get utilized in the very subsequent line of code.

The last line is where a newly encrypted character gets placed in our input rightfully at its index. Let's briefly check out how it works, and see what we should do to somehow reverse the process of encryption.

In line 23, it utilizes the variable iVar1 from line 18 for further computation.
- our_input[password_index] = character_a + (char)iVar1 + (char) (iVar1 / 0x1a) * -0x1a;
- 1. Divide the value of iVar1 with 0x1a, which is 26 in decimal
- 2. Multiply it with -0x1a (-26)
- 3. Add the result of the step 2 with the value of iVar1
- 4. Lastly, add the result of the step 3 with the decimal value of the character "a" (97)
Summary
- From line 16 to 18, they don't involve the input of a user at all, so the only value that holds sway over the values of the variables local_28 and local_2c is the counter (which runs from 0 to 49, since the right password is of 50 characters) in the for-loop in line 15. The variable local_28 is used in calculating the value of local_2c.
- Line 20 is where it involves the input of a user for calculating the value of the variable iVar1. In the very next line, iVar1 is then used to transform a character of an input of a user, and a transformed character replaces an original character in the input of a user.

So, that's pretty much it when it comes to encryption. At this point, since we are equipped with adequate information on how the program works basically, it's time to actually figure out the actual input, which will be transformed to the string mpknnphjngbhgzydttvkahppevhkmpwgdzxsykkokriepfnrdm after three rounds of encryption. Let's say if we were to reverse the following encryption method that consists of four steps above, the logical way to approach solving this would be to completely go backwards from the point at which we end up with the right password.

2. Reversing the encryption process

Since we learned that three rounds of encryption using the method above wind up with the following mpknnphjngbhgzydttvkahppevhkmpwgdzxsykkokriepfnrdm, we are going to iterate over the string from its very last character to its first and eventually work our way towards the answer we need.

So, beginning with the letter m at the index of 49 in the string above, let's start from line 23.

m = character_a + (char)iVar1 + (char) (iVar1 / 0x1a) * -0x1a;
- The only value we are missing right now is iVar1. There may be more than one number that can take place of iVar1, so we kind of have to guess to find out what iVar1 is, by placing a random value from 0 to 50 to see if we end up with the letter m.
iVar1 = ((int)local_2c >> 4 & local_20) + ((int)our_input[password_index] - (int)character_a) + (local_20 & local_2c)
- Once we learn what iVar1 is, we move on to line 20, where the only value missing is a character, our_input[password_index]. We already know in advance what the values of both local_2c and local_20 are going to be, with the realization that the only factor that controls the values of local_28 and local_2c in line 16 and 18 is an index of our input at which a character is located. Once we guess a right character, with which we end up with the same value of iVar1, we replace a letter in the string with a very letter we find.

Let's create a script for finding the right input!

We are going to go over the code in the screenshot right above this paragraph, to see what's going on.

Remember that the only factor that controls the values of local_28 and local_2c in line 16 and 18 is an index of a letter, at which a character is located in our input? The first for-loop in the screenshot basically calculates the values of local_28 and local_2c using an index, saves them in the list wowow, and puts the list wowow in the list whose name is keys. Since the answer consists of 50 letters, the list keys will have the total 50 items. Those values will be used in the helper function called find_previous_letter, to find a previous letter before encryption.
The second for-loop is a rendition of the reversed process of the encryption process we saw above, and nested, for the fact that the encryption is done for three rounds. In its nested loop, it goes over from an index 49 to 0 (50 times) and uses one helper function called find_iVar to guess a right number that can take place of iVar1, and uses a number to find a previous letter to reverse encryption. The function find_iVar actually returns an integer value, which subsequently gets converted to a ASCII letter associated with the very value, so its name isn't really accurate.

Let's go over two helper functions that are instrumental in finding the right answer.

the function find_iVar does the job of finding the right candidates for a value that may be used as that of iVar1. Once it identifies a potential value of iVar1, it passes a value to the function find_previous_letter.
The function find_previous_letter accepts the potential value of iVar1 and an index, at which a character is located in the input, as arguments. It is the function for finding the right character (our_input[password_index]) in the line iVar1 = ((int)local_2c >> 4 & local_20) + ((int)our_input[password_index] - (int)character_a) + (local_20 & local_2c). Occasionally, the function find_iVar may find and pass a wrong candidate to the function find_previous_letter, which results in not matching a single character from 'a' to 'z' - an early exit. To avoid the script from exiting early with an exception, I use the "try...except" block that skips the wrong candidate for iVar1, and the script continues finding a next candidate for the value of iVar1.

Running the script outputs the following answer:

mmhhkjbakavyaqprqnpbuygdymyyddkratrjsbbceizsgtbcxd is what the script says an answer is basically. Let's see if it spits out the right flag with the submission of the answer.

Yay! We got the flag! I submit the very flag and get 300 points!

Overall, it was a pretty interesting challenge to solve, albeit it was kind of challenging compared to the previous one I did. In the near future, I will complete more challenges and post their walkthroughs from time to time. Thank you for reading.

picoCTF "GDB Test Drive" Walkthrough

SJ W — Thu, 02 May 2024 15:20:06 +0000

Introduction

In this post, we are going to delve into something entirely different from what you usually stumble upon in my blog. A few years ago, I was sort of getting into what is known as binary exploitation, a form of hacking that finds vulnerabilities in various binaries, which essentially are executables whose extension starts with .exe in Windows OS for example. My first step into the world of binary exploitation started with going over the book called Hacking: The Art of Exploitation by Jon Erickson, which basically revolves around the topic of the hacking technique called buffer overflow. For the next post right after this, I will go over some of the examples of buffer overflow by going over the CTF challenge that involves the ROP chain, but it basically initiated my fascination with the world of binary exploitation. However, due to some circumstances in life, my interest in it kind of waned eventually, and recently, after reading and watching various contents associated with it kind of rejuvenated my interest in the topic of binary exploitation again. For that exact reason, I decided to get back into it, by actually learning how to write a program in NASM (x86 assembly in Intel syntax), decompiling binaries using tools, such as Ghidra and Radare2, and completing various CTF challenges that have to do with reverse engineering in general.

In this post, we are going to try the CTF challenge called GDB Test Drive on the website called picoCTF, a website that hosts a multitude of CTF challenges for anyone to try for free. I love feeling challenged in general, and feel like there is no better way to learn something other than actually doing and struggling with it.

GDB Test Drive

Okay, so here is how this challenge works: download a binary that must be examined with the tools of your choice, find and submit the flag that is hidden within the binary in order to complete the challenge. In picoCTF, every challenge works differently from another, but the one thing that remains the same is that you have to submit a flag for completing a challenge. Anyway, let's download the binary to see what's going on inside.

1. Examine the binary

Let's use the tool called Ghidra to decompile the binary we downloaded for the challenge.

The author of this challenge clearly instructs one to run the binary with the GNU Debugger (GDB), but I just decided not to do so, since I felt lazy. I thought that using Ghidra would be enough to complete the challenge.

Ghidra is showing various options for decompiling a binary, but I decided to go with the default choices, since it seems to be the safest basically.

Here we are! Now, let's get to the task of analyzing the binary and finding the flag hidden within it. To understand how the binary works, I decided to go through a list of functions that exist within the binary, to see if there is anything interesting.

So in C, every program starts with a function called main, and in the list of functions above, right alongside the function main, I have discovered a function called rotate_encrypt. The first thing that came to my mind when I saw it was that it might have something to do with encrypting a string into something illegible to our eyes, basically. Let's check out both functions of main and rotate_encrypt

Inside the function "main"

In the screenshot above, we are basically seeing a decompiled version of the function main, and it is unclear what each variable is for, since every variable is replaced with the name that is prefixed by the word local. However, as you can see, about midway through the function, that it invokes the function rotate_encrypt with two arguments, to encrypt something that is passed to it, and one of the arguments is of a pointer, which I assume is an address to the first letter of the string. Let's see what gets passed to the function!

There are total four variables that get assigned with the 8 bytes worth of data each, and we know that they are located right next to one another, for the fact that local_38 is located 8 bytes before local_30, which is also placed next to local_28, and local_20. local_38 is located at the address of EBP plus the offset of -0x38 bytes (when the offset is lower, it gets placed higher), and since it occupies 8 bytes starting from the address, it stores the data from the address of -0x38 to -0x31. And below local_38 is local_30 whose location is the address of EBP plus the offset of -0x30 bytes. For local_30, it occupies the address of -0x30 to -0x29. You can assume the same for the last two variables: local_28 and local_20.
local_38 = 0x4c75257240343a41: The binary assigns the hexadecimal value of 0x4c75257240343a41 to a local variable of local_38 of undefined8 (I assume you can store the data of the size of 8 bytes). When a computer stores a string in memory (RAM), it usually stores a string in a series of numbers in succession, and each character is mapped with a certain number. Each cell in memory can hold up to a byte worth of data, and the data may represent anything from an integer of 0 to 255 (0x00-0xff). Since the number (0x4c75257240343a41) we are seeing above represents eight bytes worth of data, we can split the hexadecimal value into a byte worth of data (0x4c75257240343a41 --> 0x4c, 0x75, 0x25, 0x72, 0x40, 0x34, 0x3a, 0x41) and convert each to a character according to ASCII encoding, which results in the following string: Lu%r@4:A. In ASCII, 0x4c is mapped with a character L, 0x75 is mapped with a character u, and so on.
local_30 = 0x4362383846336235: Let's apply the same logic to this as the example above. Converting the hexadecimal numbers of 0x4362383846336235 to ASCII string results in the following string: Cb88F3b5.
local_28 = 0x6630624760433530: Converting the hexadecimal numbers of 0x6630624760433530 to ASCII string results in the following string: f0bG`C50.
local_20 = 0x4e64646267353361: Converting the hexadecimal numbers of 0x4e64646267353361 to ASCII string results in the following string: Nddbg53a.

When you concatenate each one of them, it becomes the following string: Lu%r@4:ACb88F3b5f0bG`C50Nddbg53a. So at this point, I would like to assume that the string gets converted to the flag we have to submit for the challenge. Let's see what the function rotate_encrypt does with the string we have discovered.

Inside the function "rotate_encrypt"

Carefully going through the contents of the function, I have noticed the followings:

It copies the content of the string (Lu%r@4:ACb88F3b5f0bG`C50Nddbg53a) to a new pointer, with the help of the function called strdup
In line 11, it stores the length of the copied string.
In line 12, it iterates over the string using a for-loop.
In line 13, there is a conditional logic that checks the followings: (' ' < __s[local_20]) && (__s[local_20] != '\x7f'). First, it evaluates whether a character in the string is bigger than ' ', which in ASCII evaluates to an integer of 32. Second, it checks whether a character in the string is not equal to \x7f, which in ASCII evaluates to an integer of 127. If a character evaluates to "true" in both cases, it enters the line 14, else move on to a next character of the string.
In line 14, it adds an integer of 47 to a character, and assigns it to the variable cVar1. For example, if I add ')' - in ASCII, it is 41 - with 47, it becomes 88 ('X').
In line 15, it checks if the variable cVar1 is smaller than an integer of 127. If it evaluates to "true", then a character is replaced with the content of the variable cVar1. If not then, it subtracts an integer of 94 from cVar1, and replaces a character with it.

Since we pretty much figure out how the program works, we can try to replicate the code with the help of Python!

2. Exploit

Since we know how the program works, we should be able to figure out the flag needed to complete the challenge!

Failure to submit the right flag

Here is my first attempt at writing the python code that replicates the function rotate_encrypt in the binary we analyzed. What it does is that it iterates over the string, converts each character in the string to a number according to ASCII encoding, adds 47 to it, and checks whether it evaluates to being bigger than an integer of 127. If it does, then it subtracts 94 from a number, and lastly, converts the number back to a character, which gets appended to a new string.

Running the script results in the following string: {FTCocipr3ggub3d7_3v1rd_}5538db2. Hmm, looks a bit broken, since the flag is supposed in the format of picoCTF{flagssss}. Anyway, let's try to submit it and see if it is an answer. Surely, it is not an answer! Still though, I find some solace in the fact that reversing the first 8 characters of the string above results in the following: picoCTF{. After learning that very important fact, I come up with a new script to rectify the situation.

Finding the right flag

Since reversing the first 8 characters results in the right result of picoCTF{, which is how a flag should start, we can reverse each data stored in each variable in the following manner:

Lu%r@4:A --> A:4@r%uL
Cb88F3b5 --> 5b3F88bC
f0bG`C50 --> 05C`Gb0f
Nddbg53a --> a35gbddN

When you concatenate each reversed substring, it results in the string A:4@r%uL5b3F88bC05C`Gb0fa35gbddN. Let's run the script to see what it outputs.

It is still weird. Maybe, I should reverse it? Let's fix the code and output it in reverse.

Seems like the right flag! Let's submit it and see how it works! It is right, which means that I have successfully finished the challenge!

It was a fun challenge overall to ultimately test my knowledge in reverse engineering. From time to time, I will post walkthroughs of different challenges that I come across in picoCTF from time to time. Thank you for reading this post!

How to avoid CSRF?

SJ W — Thu, 25 Apr 2024 16:54:49 +0000

Introduction

Hello, in this post, we will briefly go over what CSRF is and how you can possibly avoid your users from being victims of the such attack. Recently, I have been working on the project for creating the backend of the website for selling books. While learning about how to basically handle authentication for safely allowing users to access the sensitive information, instead of using a cookie to store the credentials of a user, the instructor decided to go for a route of using HTTP headers for sending JSON web tokens in a request. When she went for that method, I couldn't initially understand why she would ditch a cookie for the storage of tokens for manually storing tokens somewhere in the browser - such as localStorage or sessionStorage, which may be vulnerable to XSS attacks. And then I realized there must be a reason for that, which led me down the path to search for an answer as to why a cookie may not be a good candidate for storing sensitive information. That's when I came across the topic of CSRF and how it may be used to make users perform unwanted actions.

CSRF?

CSRF is essentially an attack that tricks users into unknowingly performing nefarious actions wanted by an attacker. An attacker utilizes the credentials stored in the cookies of the browser of a user, and its malicious website, to potentially trick users into submitting requests to a legitimate website using its credentials. For example, a legitimate website issues and sends tokens to a user via cookies, which get stored in the user's browser for its subsequent requests. With the tokens saved in the browser, an attacker somehow leads a victim to its website, creates a form for submitting information to a legitimate website and makes a user submit the form for whatever purposes, such as changing one's password or making a purchase. As you can see, allowing such an action to an attacker is often very catastrophic and may lead to the complete compromise of the website itself - imagine an attacker somehow tricking a user with admin privileges to perform actions.

This is how it works:

A user logs in to a legitimate website for whatever it intends to do.
In response, a website issues tokens for allowing users to make subsequent requests to the various pages of the website. The purpose of the tokens is to allow users not to have to log in to the website every time it tries to access some pages that are only meant for authenticated users. A website issues tokens to a user via the cookies, which are stored in the browser of a user for making subsequent requests to the website.
Unknowingly, an attacker lures a user to a page of the malicious website of an attacker that looks awfully similar to that of the legitimate website, and provides the form for making a POST request to the endpoint of a legitimate website. The form is meant to send data to the endpoint for changing the password of a certain user. Here is an example:

<!DOCTYPE html>
<html>
<head>
    <title>My First Web Page</title>
</head>

<body>
    <h1>Welcome to my first web page!</h1>
    <p>This is a paragraph of text</p>
    <form action="https://targetWebsite.com/api/change-password" method="post">
        <input type="hidden" id="password" name="password" value="attackProvidedPassword1234">
        <input type="submit" value="Click Here!">
    </form>
</body>
</html>

A user willfully clicks the button above to see what happens out of curiosity. At this point, it doesn't matter what information a user provides to the form, since an attacker is completely free to change the contents of the form via JavaScript, and may provide the new password of its choice - attackProvidedPassword1234 - on behalf of a user.
A user ultimately sends a form to a legitimate website. In our example above, it sends the form to the website at the URL of a https://targetWebsite.com/change-password. A legitimate website handles the form, as if a user has willfully submitted the form, and proceeds to change the password of a user with the new password provided by an attacker.

The example above is kind of a simple example of what an attacker can do to a victim with CSRF attacks, but it is still an entirely feasible scenario that may result in catastrophic results. If an attacker manages to trick an admin into performing actions vital to the management of the system itself, it may result in the complete takedown of the system. So, since we know the mechanism of the attack, how do we exactly defend our users against falling victims to such an attack?

Solutions

One thing we have to know is that problems lie in the way the system is designed, so there is no way you can deflect some of the blames to a user when this attack occurs. There is no one-size-fits-all solution for completely mitigating the CSRF attacks, but rather it requires a combination of various measures that, when used together, provides a robust defense for end users. Here are some of the solutions you may implement in your system.

1. Avoid GET requests for making changes to data

Stick with methods other than that of the GET for making changes to existing information in the system. The GET method is strictly used for retrieving the information, and it shouldn't be used for anything other than that. Imagine if there was a URL for sending money to a certain user like this, http://bank.com/transfer.do?acct=MARIA&amount=100000. The URL accepts two query parameters, acct and amount, and an attacker may easily construct a URL for sending a certain amount of money to itself by replacing the acct with its value, and may attack it to a link, such as <a href="http://bank.com/transfer.do?acct=MARIA&amount=100000">Click Here</a>. All it is left at this point is for a user to click that link and send the money to an attacker.

2. Use CORS

CORS allows the system to block requests from all the domains other than the ones that it is configured to accept requests from. The system often utilizes the HTTP methods such as POST and PUT to introduce or make changes to the data, and CORS essentially protects a user by filtering requests that are from the domains that are not approved by the system itself. Thankfully, the browsers nowadays are set up by default to avoid making the cross-origin requests, unless the target server allows it without any restriction.

3. Use CSRF Token

Provide a single-use token to a user before every POST or PUT request a user makes. For example, when a user makes changes to its password, it submits its new password alongside the token provided by the system prior to changing the password. Once the token is used, it becomes invalid and prevents itself from being reused again. In my personal opinion, I don't know how effective this method is, when frontend and backend are decoupled, but I assume this may be very useful in a case where backend serves the HTML pages. Here is how you may use it to secure your webpage from attacks:

Assign a session token to a user upon accessing the website.
With a session token provided to a user, generate a CSRF token, which is essentially mapped to a session token of a user.
A user uses it to submit a POST or PUT request to submit information, and the system verifies the CSRF token against a session token of a user to make sure that it is indeed from a user.

Online Bookshop Project (Part 3)

SJ W — Thu, 25 Apr 2024 10:04:18 +0000

Introduction

Back at it again with the project for developing an e-commerce website for selling books. In the previous post, we went over the phase of designing the database schema for the system using the E-R diagram. Through the process, we were able to identify a few key entities - User, Book and Order - pivotal in storing data that we may need for the system. And each entity shares relationships with various additional entities whose existence came about with the help of the concept of normalization, to avoid the duplication of the data. For this post, there are going to be two main things that are going to be covered: the DB initialization and creating the project using Express.js. Since we have completed the schema for the DB in the last post, we will move on to actually implementing them using MariaDB, by creating the new DB and a number of its tables. And also, we are finally going to get into the real fun of the project, which is coding! Since the bootcamp I attend is fully based on JavaScript from frontend to backend, we will go over some of the endpoints that I identified, and start implementing the API endpoints using Express.js and various third-party libraries from Node.js.

Identifying API Endpoints

An API is essentially an interface that allows two different programs to talk to one another. Think of it as a bridge that connects one or more independent programs to facilitate the data exchanges. For example, the system I am creating is a facilitator of the data exchange between the browser and the database for the necessary data for buying books. Through the system, a user may be able to create, fetch, update and delete various information that it has access to. The system exposes a various number of "bridges" designed for the specific functionalities that they try to perform for end users.

Since I am trying to separate the frontend and backend using the different technologies - Express.js and React.js, the backend will return data to users in the form of JSON for the most part, which is parsed by the frontend, and ultimately rendered and viewed as a component for display for the users. The backend system will adhere to various principles in regard to what we call REST. REST is an architectural style for distributing data using HTTP endpoints. Offering the guidelines rather than a set of rules and laws that one must strictly adhere to, it provides developers freedom to implement the system in a variety of ways. There are various principles that one must conform to for the system to be considered RESTful, and if you are interested in what makes the system RESTful, please check out the link here for more information.

With my mind in REST :), It is time to create each URL for every endpoint that gives off the vibes of REST. An endpoint is where the system and a user meet to interact with one another. There are two main important aspects when it comes to each HTTP endpoint - name and method.

Name - Since it represents a specific functionality or the resource that one intends to exchange or perform, the URL of an endpoint must be both simple and descriptive at face value. For example, If I create an endpoint for returning the information of all the books in the system at the moment, it might be better to stick with something like "/books". Just from the name "/books", you can easily tell that it has something to do with books. To go further, if you want an endpoint that has to do with a specific book, you may utilize the URL, such as "/books/{:book_id}" - replace the curly braces and its content with a unique ID of a book you need.
Method - In addition to the mere name of an endpoint, each endpoint may have one or more methods that further describe the actions to undertake for the resource you are trying to access. For communication, the REST style uses the HTTP protocol, and it has four main methods that achieve what we call CRUD functions (Create, Read, Update, and Delete): POST, GET, PUT, DELETE. Let's say an endpoint "/users" allows the HTTP methods of POST, GET. With the POST method often being associated with submitting the information, we can use the endpoint "/users" of POST for creating a new user. And since the method GET is associated with fetching the existing information stored in the system, we can use the GET method to retrieve the information of all the users in a system.

As you can see in what I said, there is a hierarchy in each URL. For this project, the RESTful API endpoints will have their names starting with the most generic thing that you can have in the system - since we are making the backend for selling books online, books, orders, and users come to mind - and become more detailed as it goes further and gets appended by slashes (/). Here are the types of API endpoints that I identified and implemented as a result.

Authentication / Authorization
Authors
Books
Carts
Categories
Orders
Users

To run the e-commerce website for selling books, you can kind of guess the types of functionalities needed based on the list above. For example, at the very basic level, we need to control who can have access to various information at various levels. To control the access to information, we will have Authentication / Authorization, which represent functionalities that have to do with accessing the system in general. Some of the example include logging in and out, password change, etc. For the rest of the main entities, it will have the following functionalities, such as creating, retrieving, updating, and deleting objects.

Project Structure

Currently, the project is structured in various files and modules to keep it largely modular. Here is how I structured my project:

Let's try to go over some of the files and folders that are integral to the system.

controllers - This is the directory for various controller modules that contain various callback functions directly associated with API endpoints. Essentially, each file in this directory holds various functions that get invoked whenever a user makes a request to the system with a specific URL. Each callback function is directly tied to a specific endpoint. To learn more about what the controller is, check out this link here.
middlewares - This directory stores various middleware modules. S*imply, middleware is a function that gets invoked before the request makes its way to a function in one of the functions in the modules in the directory of controllers.* There are many different use cases for middleware, but it's really useful for deciding whether a user is authorized to access the resource or not. By checking the credentials provided by a user inside the request object, you can determine whether one has rights to access the certain information.
models - Sequelize uses a class called model to represent each table in DB. Since the system involves about more than 20 different tables of the DB for storing various critical information, creating a separate directory as a module for storing various models related to the project just makes sense, and most importantly, makes the project look a lot cleaner.
routes - The directory stores various files that store the API endpoints, from which the interaction between the system and users may occur. Each endpoint accepts the URL pattern and the callback functions that we define in files inside the directory of controllers as arguments.
services - The directory contains files which store the domain-specific logic. What I mean by domain is the entity, in which the system basically revolves around. For example, there is a service file just for handling the users-related logic, including the fetching of the information of a user, registration of a new user, etc. Also, since the system is all about selling books to users, you can easily infer that the system may contain logic for books as well.
db.js - A file for storing the information on the DB for the system. It initializes the instances of the modules of both MySQL and Sequelize. The system currently makes uses of both for the DB-related activities, but plans on making a full transition to Sequelize in the near future.
app.js - A file that starts the web server for accepting connections from users. This is where all the routes and middlewares get converged and merged into the server instance. To start the server, we run the following command in the project directory: "node ./app.js".

In the next blog post, we will go over each file and directory mentioned, and see how they interact with another in unison to form the backend of the e-commerce website for books!

Online Bookshop Project (Part 2)

SJ W — Mon, 15 Apr 2024 11:40:25 +0000

Introduction

In the previous post, I went over the process of analysis for the project I had been tasked with, by going over the data flow diagram that I constructed to visualize the comprehensive view of the system's architecture. With the overall understanding of what the system consist of under our belt, we will move on to the next step of the analysis phase, by focusing on the database design to fully accommodate our needs for storing various data in an efficient, standardized manner. Storing data is the single most important aspect of the system, and for that simple reason, it is very imperative not to neglect getting things right. The proper design of the system results in various upsides, such as the elimination of data redundancy, high efficiency in queries, thus improving the performance of the system. In order to kick-start the process of the DB design, we will go over the E-R diagram for the system.

E-R Diagram

An E-R diagram is a tool that provides a template you can use for designing the DB of the system. It allows you to visualize the overall looks of the system by picturing various "things" that we need for the system, and drawing the relationships between those "things". There are three main components that comprise an E-R diagram: Entity, Attributes, and Relationships. An entity in a diagram represents something in real life that is either tangible or intangible. When we talk about something tangible, some of its examples would be Human, Bike, Car, etc. When it comes to the intangibles, the examples are Order, Review, Roles. Those are something that can neither be touched nor seen, while all we can do is to sort of picture how they may seem in our brain. In order to identify entities necessary for the system, we have to focus on what the system is all about. For example, since the system I am working on is the e-commerce website for books, you can easily infer that I need to store the data related to books. And also, in order to keep track of the orders made by each customer, you can easily infer that I need an entity for both customers and orders they make. Every entity we identify will always be mapped to one of the tables of the database, and used to store various data related to it. Each entity has a distinct set of attributes that uniquely represent the relevant aspects of itself for the system to operate seamlessly. It is our job to fully identify and specify the types of data we are trying to store in relation to each entity. To establish a relationship between two or more objects, you simply draw a line that connects one to another, and specify further by defining associations and dependencies that occur between objects. For example, each customer in the system may have one or more orders at any given moment. And each order may be associated with one or more books, and each book may be associated with one or more orders, which makes it a "Many-to-Many Relationship." Each element in an E-R diagram serves to enhance the understanding of how the system should operate and how it may be improved by spotting the glaring problems that we may identify from each iteration of a diagram. With that being said, let's look at the E-R diagram I came up with.

As you can see, there are various entities that comprehensively represent the distinct part of the data of the system, and shares relationships with various entities. Let's briefly delve into the diagram by using a few key entities that the system will primarily deal with. The User entity represents a table for storing the data of users for the system. As you can see, I added various attributes, such as email, password, nickname, etc. to distinguish each user from another. Every email that a user provides for registration must be completely unique, as in, there should be no other users with the same email at the time of registration. Besides those attributes I already defined, there could be various attributes that I may add in the near future, depending on the needs arising from various circumstances, but what I already defined would suffice for now. There is a Book entity, which is not directly related to the User entity, but they are kind of intertwined with each other based on the Order entity. Just with the User entity, the Book entity is adequately structured for the system as of now, and it shares relationships with various entities in a way that aligns with the concept of normalization. The Order entity basically gives away the type of data it stores, but they are directly related to both the User and Book entity. It directly stores the "id" attribute of the User entity, and indirectly stores a number of books via the Order_Books entity. There are other entities that greatly enhance the quality of the system, but the User, Book, Order are essentially the core that ultimately enable the system I envision.

With that being out of the way, I think it is about time to start designing and implementing the system, based on two previous artifacts. I could potentially take more time analyzing and identifying more needs for the system before I move on to the designing phase of the project, but since this is meant to be relatively simple, rather than too complex, I believe that those will suffice as the foundation for developing the project without too many issues. If anything, I can always go back and modify them or add a few artifacts to meet the needs that I may have yet to discover and resolve. For the next post, I will go over the basic design of the API endpoints that I came up with, prior to actually implementing them using JavaScript.

Online Bookshop Project (Part 1)

SJ W — Tue, 09 Apr 2024 15:45:09 +0000

Introduction

In this post, I will showcase the process of working on the first e-commerce backend project for the bootcamp that I am currently attending. What I get to work on right now is not actually the first project I worked on in the bootcamp so far, but it is the first project with some difficulty far greater than others we did, since we are actually tasked with creating a first backend that sort of emulates the real-world e-commerce website for selling books. Compared to the first one, it is more challenging, with a far more number of APIs for various entities and being tasked with coming up with the designs of the SW as well. I feel like the structure of the project is still basic at best, since I didn't get to spend a lot of time thinking through the project thoroughly, but I still intend to improve upon it with each iteration for the foreseeable future.

Background

Prior to bootcamp, I had a few experiences of creating a website from scratch, but in every single case, to my dismay, I abandoned them prematurely since it became way too big of a monstrosity to deal with at the end. The main culprit for why I always wound up ruining the project lies in the fact that I simply lacked the knowledge of how to create the SW in a right way. Whenever some interesting ideas come about, regardless of the sheer difficulty of a project, I impulsively took on each idea by facing it head-on and powering through the great deal of the unknown, which caused a lot of headaches, rather than carefully planning everything from the start and learning about various techniques and tools for creating the SW efficiently. Through these unfinished projects and a great deal of frustration, I learned a great deal about how vital it is to systematically approach building the SW from scratch, encompassing every important step in the process of the SW Engineering, from the stage of analysis to maintenance. What I plan on doing in this project is to apply almost all the things I learned about SW Engineering so far from the start to finish, thus actually completing the project.

Data Flow Diagram

I decided to begin the project with DFD. Even though I should have come up with a list of requirements prior to creating a DFD for the SW, I remember learning that DFD is actually a great tool to reveal some of the missing requirements of the SW, by creating a diagram and visualizing how data moves from one to another. Anyway, one of the classes I am taking right now at school recently went over the topic of DFD and emphasized it as an integral part of the SW Engineering. Taking into consideration many different aspects I learned of DFD, I created the first DFD of level 0 intended to showcase the high-level overview of how the system being developed intends to operate.

Let's go over what I did with the DFD above. I am sorry if it is way too fuzzy and unrecognizable, but you can see a number of symbols, whose shape sort of imply the different roles they play in the diagram. In DFD, there are total four symbols that are used - rectangle, circle, open symbol, and an arrow, and each plays an important role that in combination, aids the overall understanding of the system.

Every data in the DFD starts from external entities - a rectangular symbol. External entities refer to anything that is outside the system, and essentially represent a starting point, from the which data originates. For example, in the DFD above, a user makes a request to the system, in order to retrieve information on a certain user. To start the process, it utilizes the web browser to make a GET request with the certain URL and various information needed for inquiring about a user to the system.

There are about eight different groups of functions that I described as processes - you use a circle to indicate a process in DFD. Processes are simply responsible for taking and processing an input, and passing the output to either one of the following types: external entity, data store or process. Let's use one of the processes in the DFD to go over what I had in mind when it comes to designing the system. When an external entity called User sends a request to the system, the first destination it ends up is the process called Authentication Management, which encompasses any logic related to authentication and authorization. Making sure that each user accesses information that it is rightfully authorized to have access to, this process contains the logic of checking the role of a user for every request a user sends to the system, so it is extremely vital for keeping the system secure from being misused by a malicious attacker. Once a user is verified to have access to a certain API endpoint, the request gets passed to another process in the system - if the request is intended to fetch the information about a certain user in the system, then it is appropriate to direct the request to the process of User Management.

With each process taking a data flow as an input, a data flow gets transformed into another data flow as an output with a different name. One of the caveats of DFD is that you can't re-use the same name on two or more data flows, in order to avoid ambiguity in the meaning of the data. Even if the data flow contains the same kind of data after it gets processed, it should still change its name to point out the fact that it has been processed without changes taking place. For example, in the DFD above, after a request from a User entity gets processed by the process of Authentication Management to verify and check the user's identity to allow access to certain resources, it then gets passed to another process, and the process of Authentication Management does not necessarily change the structure of the request, since all it does it to make sure that a user is authorized to have access to certain sensitive materials that the system stores.

Data Store represents a storage that holds the information originating from the process. It retains and returns the information that may be used at some point in the future - for both the long-term and short-term - for various purposes. Let's take the situation in which the system registers a user, with the information provided by a user using the registration form. When the process of User Management receives a request from the user for registration, it first makes sure that the email provided by a new user is not used by another user by going through a list of users. Once it is fully verified that the email provided by a new user is unique, then the system registers a new user by saving the information of a new user, sending the data to the data store called User Store, a storage intended for storing anything related to users. Now, whenever a user provides the credentials used for its registration, the process of User Management verifies them against the existing information of a user and gives a signal whether the right credentials have been provided.

Even though it would be lovely to delve into every aspect of the DFD possible, it would simply take way too long to go over every aspect of the DFD above, so I will stop going over the DFD part of the project, and move on to covering other things I did for the project. For the next post regarding this series, I will go over the E-R diagram and various other artifacts I generated for showcasing and understanding the system in a much more detailed manner.

Design Patterns (Creational)

SJ W — Fri, 29 Mar 2024 10:25:41 +0000

Introduction

In the fifth post of my blog, I will go over all the design patterns that can be applied as solutions to various problems that we commonly face during the design process of the SW. The proper design of the SW is extremely crucial, for the fact that a poorly designed SW is an absolute nightmare to deal with as a developer and a customer. For developers, it can lead to issues of SW vulnerabilities, scalability, and the bad reputation of a company, and for customers, performance, UX, etc. What's a better way to mitigate those issues than to properly design the SW from scratch? By utilizing the well-known design strategies used by developers all across the programming industries, you can simply save others from having to spend an enormous amount of time fixing bugs and trying to make sense of the code you wrote, and ultimately make everyone who comes into contact with the SW happy. I am not trying to say that these are some sort of bulletproof, one-size-fits-all solutions that may completely eliminate all the problems that the SW may have later down the line; however, we can mitigate some of the unnecessary issues arising from haphazardly approaching the design process by incorporating the well-proven, brilliant techniques into the SW.

Prior to writing this, I have to remind you first that I do not have expertise in this domain of knowledge. The primary purpose of writing this post is to deepen my understanding of design patterns by writing about what I learn and know in order to improve my skill set as a programmer. If you see any errors or mistakes in my writing about pretty much anything you see, feel free to point them out by commenting below so that I can fix them!

What are Design Patterns?

Since the inception of the very first computer, the ever-shifting landscape of the computing world has seen an incomprehensible amount of software that ultimately changed the history of mankind forever. The combination of physical components that together make up the backbone of what we know as the computer is basically nothing without the SW. For example, an operating system provides us various tools that enable us to gracefully and effectively control this marvel of the invention without having to directly communicate with various pieces of hardware. It also provides us with a virtual platform on which we run various pieces of application software that aid us in conveniently managing and solving our daily tasks. In fact, you are using an application called Web Browser on your smartphone or computer to read this very post right now to learn more about Design Pattern, and the very web browser you are using is made by a group of people intent on helping people connect to the ever-increasing world of the Internet.

Creating well-run, maintained software requires one to carefully plan everything from the start to make sure that it has a good foundational background from which things can flourish. Unfortunately, people who came to invent the SW at the outset of the computing world did not have the luxury of developing the SW with such knowledge. Since it was something that was so new, they had to pave ways for us to get to where we are today by experimenting and trying various things that gave birth to brilliant solutions that we resort to to this day, but it was not expected to be without issues. Without all the tools and methodologies at their disposal, creating the SW was not really efficient and structured. Some of the problems they faced included failing to meet the requirements, being overdue, budgeting, etc. Recognizing the need to address those issues, people decided to come up with the discipline of SW Engineering which focused on processes, methodologies, and guidelines to develop the SW as efficiently and methodically as possible.

Design patterns aim to make the design process of the software's development much more pleasant and, most importantly, efficient. During the design process, we often come across instances where we may have no idea how to come up with fundamentally sound solutions to mitigate the unforeseen issues that can arise in the future. Design patterns provide you with a set of ideas or guidelines on how to think about approaching the issues from a high-level view. I would like to think of it as the template from which we can standardize approaches to coming up with robust solutions to all the recurring problems we often face. It does not necessarily give you a set of concrete solutions that may be incorporated right into the SW or encompasses only a few handfuls of situations to which design patterns could be applied, but sort of guides you towards where you may find the solutions. Why racking your brains trying to reinvent the wheel when you can simply resort to the proven-to-work guidance from the brilliance of those that came before us on the implementation of the SW? You also get to reap the benefits of efficiency, scalability, flexibility, etc.!

Currently, there are about 22 design patterns that are well-used to this day and are grouped into three different types: Creational, structural, and behavioral. Each category aims to address different types of problems, and their names simply give away which to use for the types of problems you are trying to resolve. Creational Patterns deal with the creation of objects. Structural patterns deal with merging two or more objects into compositional structures. Behavioral patterns streamline communication and delegate various responsibilities to objects in situations. As the first part of the series, I am going to cover creational patterns first—their definition, description, and how we may apply each pattern to instances that we may encounter in the future—and structural patterns and behavioral patterns subsequently.

Creational Patterns

Click patterns below to navigate

My Definition

As the name suggests, Creational Patterns mainly deal with creating objects. Here are some of the concepts that you will often encounter while going through each pattern:

Abstraction
Reusability

Abstraction

While going through and researching various aspects of each pattern of this category, I noticed that some of the patterns use some sort of an abstract class that is used to create other subclasses. I guess, since Design Patterns are for OOP in general, any concept related to OOP is often utilized. So how does an abstract class give you an advantage? One of the biggest advantages you can have from this is that you can simply add new subclasses, without having to introduce the new code to many different parts of the system. Here is an example: let's say you are creating an application for reading the documents of various types. Regardless of the type of document, you can assume that they all share the following functionalities: you must be able to open, write, save and close. Let's say that you decide to create a function for creating a document. Instead of having to create functions for opening each type of document tediously, you can simply create a function that accepts any object that inherits the abstract class, and invoke "open()" of its abstract class. Since you can add more concrete classes that represent the new types of document, from now on, as a result, your system your system becomes more flexible!

Economical

Some of the Creational Patterns we are going to delve into put a huge emphasis on the economical use of the objects. What I mean by economical is that it aims to reduce the unnecessary creation and use of the objects. One of the examples would be a pattern called Singleton, which ensures that there is one object of a specific class that is created and gets shared by other objects. There is also a pattern called Prototype, which deals with cloning an object, entirely avoiding the process of generating a new object - sometimes, it's just more time-consuming to generate a new object from the direct instantiation of an object than to clone an object that already exists in the memory. We will go deeper into those patterns mentioned above, so make sure to read it until the end!

Factory Method

The Factory Method is a design pattern that emphasizes using an abstract Factory class to provide an interface for creating an object, with its concrete subclasses determining the type of object to create. Let's delve into this pattern with a simple example:

Example

Scenario: Your business has a Payment Processor class that initially accepts only credit cards as a valid payment method. However, as your business grows, there is a demand to also accept PayPal as a payment method. Since your existing Payment Processor class is strictly for accepting credit cards, you would need to create a separate Payment Processor class for PayPal. While creating a separate Payment Processor class for each payment method might not always be overly complicated, in a large system, this approach could require various parts of the code to be updated to start accepting new payment methods.
Solution: To resolve this issue, an abstract factory class can be used to provide interfaces for creating objects, although the actual object creation implementation may vary depending on its subclasses. This allows for having the client code that accepts any subclass of an abstract Factory class. The client code creates a specific payment method object, using the Factory object, and then processes a payment with it. Check out the code below or the GitHub link here

// Abstract class called PaymentMethod
class PaymentMethod {
    constructor() {
        if (this.constructor === PaymentMethod) {
            throw new Error("Cannot instantiate abstract class!");
        }
    }
    connectToGateway() {
        throw new Error("This method must be overwritten!");
    }
    pay(amount) {
        throw new Error("This method must be overwritten!");
    }
}

// Concrete class called CreditCard
class CreditCard extends PaymentMethod {
    #gateway;
    constructor(cardNumber, cardHolder, expiryDate) {
        super();
        this.#gateway = this.connectToGateway(cardNumber, cardHolder, expiryDate);
    }
    connectToGateway(cardNumber, cardHolder, expiryDate) {
        console.log('Connecting to payment gateway...');
    }
    pay(amount) {
        console.log(`Paying $${amount} using Credit Card`);
    }
}

// Concrete class called PayPal
class PayPal extends PaymentMethod {
    #gateway;
    constructor(email, password) {
        super();
        this.#gateway = this.connectToGateway(email, password);
    }
    connectToGateway(email, password) {
        console.log('Connecting to payment gateway...');
    }
    pay(amount) {
        console.log(`Paying $${amount} using PayPal`);
    }
}

// Concrete class called BitPay
class BitPay extends PaymentMethod {
    #gateway;
    constructor(email, password) {
        super();
        this.#gateway = this.connectToGateway(email, password);
    }
    connectToGateway(email, password) {
        console.log('Connecting to payment gateway...');
    }
    pay(amount) {
        console.log(`Paying $${amount} using BitPay`);
    }
}

// Abstract factory method to create payment methods
class PaymentMethodFactory {
    constructor() {
        if (this.constructor === PaymentMethodFactory) {
            throw new Error("Cannot instantiate abstract class!");
        }
    }
    createPaymentMethod() {
        throw new Error("This method must be overwritten!");
    }
}

// Concrete factory method to create CreditCard payment methods
class CreditCardPaymentMethodFactory extends PaymentMethodFactory {
    #cardNumber;
    #cardHolder;
    #expiryDate;
    constructor(cardNumber, cardHolder, expiryDate) {
        super();
        this.#cardNumber = cardNumber;
        this.#cardHolder = cardHolder;
        this.#expiryDate = expiryDate;
    }
    createPaymentMethod() {
        return new CreditCard(this.#cardNumber, this.#cardHolder, this.#expiryDate);
    }
}

// Concrete factory method to create PayPal payment methods
class PayPalPaymentMethodFactory extends PaymentMethodFactory {
    #email;
    #password;
    constructor(email, password) {
        super();
        this.#email = email;
        this.#password = password;
    }
    createPaymentMethod() {
        return new PayPal(this.#email, this.#password);
    }
}

// Concrete factory method to create BitPay payment methods
class BitPayPaymentMethodFactory extends PaymentMethodFactory {
    #email;
    #password;
    constructor(email, password) {
        super();
        this.#email = email;
        this.#password = password;
    }
    createPaymentMethod() {
        return new BitPay(this.#email, this.#password);
    }
}


// Class that will use the factory method to create payment methods
class PaymentProcessor {
    #paymentMethodFactory;
    #paymentMethod;
    constructor(paymentMethodFactory) {
        this.#paymentMethodFactory = paymentMethodFactory;
    }
    processPayment(amount) {
        this.#paymentMethod = this.#paymentMethodFactory.createPaymentMethod();
        this.#paymentMethod.pay(amount);
    }
}

// Usage
const creditCardPaymentMethodFactory = new CreditCardPaymentMethodFactory('123123', 'John Doe', '12/23');
const paymentProcessor = new PaymentProcessor(creditCardPaymentMethodFactory);
paymentProcessor.processPayment(100);

In the example above, there are two abstract classes that essentially enable this pattern: PaymentMethod and PaymentMethodFactory. The PaymentMethod class represents an interface, with which the various types of payment method are implemented, and the PaymentMethodFactory class represents an abstract class, with which various subclasses are created depending on the types of objects they intend to generate.

PaymentMethod class has one abstract function called "pay" that needs to be overridden by its subclasses. The reason why is that, regardless of the type of payment method you use, the only purpose of payment method is to allow users to pay for items with their choices of payment method. That means that every payment method should commonly share the function of "pay" a user may use to make a payment; however, the exact implementation of every subclass may vary. To allow the system to accept payments using credit cards, PayPal and BitPay(Cryptocurrency), the business decides to implement each payment method, creating a subclass inheriting the PaymentMethod class and uniquely implementing its own version of the function "pay."
PaymentMethodFactory class, just like the PaymentMethod class, provides an interface for a subclass generating an object of a single type of payment method. Since each subclass that extends the PaymentMethod class is responsible for creating a single type of object, we can assume that we will have to create a subclass that extends the PaymentMethodFactory class for each payment method available. The only job that a Factory subclass performs is providing an interface for generating an object of a certain payment method. Every Factory subclass has to implement its own version of a function called "createPaymentMethod", because the way an object of each class gets generated may differ. In order to create an object of the class CreditCard, you have to provide the card number, name of the holder, and expiration date; however, in order to create an object of the class PayPal, all you have to provide is the credentials used to log in to one's PayPal account. Regardless, all we have to ensure is that it has to return an object of the PaymentMethod variant.
Lastly, the instatiation of an object of PaymentProcessor class - we'll call this client code - requires any subclass that extends the PaymentMethodFactory Class. Inside the constructor function of PaymentProcessor class, you can see that it assigns the class you provide it with to the private variable called #paymentMethodFactory - In JavaScript, prepending a variable with "#" results in it becoming a private instance variable. Finally, when you invoke its function called "processPayment," it generates an object of a subclass extending the PaymentMethod class, by utilizing the Factory subclass you provided at the time of its instantiation, and proceeds to make a payment based on the argument you provide to the function.

When to Use This?

When you do not have a clear idea of the types of object that could be created - Considering the situation above, you can tell that the system may or may not be extended at some point, by providing more payment methods on demand; however, you have no idea exactly which payment methods will get implemented later down the line. I don't know about you, but for me, it feels a lot cleaner to have the function accept an object of any subclass extending the PaymentMethodFactory class.
When you want to create an object inside the factory class - Honestly, I had a hard time coming to terms with this statement, when I first learned about it - like why do you have to use a Factory method to generate an object when you can directly generate it without the Factory class outside the client code; however, when the creation of an object is often complex and requires some crazy preparation logic, then it is probably better for the system to delegate the responsibilities of creating an object to another class. Providing an Factory interface, whose sole responsiblity is generating an object, to the client code promotes decoupling and flexibility. Decoupling makes the system a lot modular.
How about not altering the client code? - Adding new classes by extending the abstract class, without altering the content of the client code whenever you introduce new payment method, the system becomes more flexible and maintainable!

Back To List

Abstract Factory

Another pattern that involves the word Factory in its name, you can easily assume that it might work in a similar manner as its Factory Method counterpart; however, unlike Factory Method pattern, it can generate more than one type of object! Abstract Factory is a creational design pattern that let you generate families of related objects without specifying their concrete classes. Let's explore what it is all about, by going through the example below.

Example

Scenario: You are a lazy developer that tries to develop the comprehensive system toolkit for the maintenance of various OS. The tookit has the following functionalities: Task Manager, Disk Manager, and Network Manager. Since every OS works differently, even though they work fundamentally similar, the implementation of the toolkit for each OS may differ from one another, and you initially think of creating a separate SW for each OS; however, you are too lazy for that approach and start thinking that it would be nice if you can just have one program completely compatible with the operating systems of many different types. Instead of having the toolkit working for just one specific OS, it would be neat if the program detects the type of OS, in which the program runs, and functions accordingly.
Solution: Create an abstract class for each tool in the toolkit, and an abstract Factory class for generating those tools in the toolkit based on the type of OS, in which the toolkit runs. Since the toolkit you are trying to develop, regardless of the type of OS, should have the same functionalities as one another, you can simply create an abstract class for each functionality that is going to be integrated into the SW. For each OS, you can simply implement its own version of the functionality inheriting the abstract class. The abstract Factory class provides the interfaces for generating the tools included in the toolkit. For each OS, extend the abstract Factory class! Check out this GitHub link or the code below for clarification!

// Abstract class for creating a factory for various toolkits for various OS
class ToolkitFactory {
    constructor() {
        if (this.constructor === ToolkitFactory) {
            throw new Error("Cannot instantiate abstract class!");
        }
    }
    createTaskManager() {
        throw new Error("This method must be overwritten!");
    }
    createDiskManager() {
        throw new Error("This method must be overwritten!");
    }
    createNetworkManager() {
        throw new Error("This method must be overwritten!");
    }
}

// Concrete class for creating a factory for a Windows toolkit
class WindowsToolkitFactory extends ToolkitFactory {
    createTaskManager() {
        return new WindowsTaskManager();
    }
    createDiskManager() {
        return new WindowsDiskManager();
    }
    createNetworkManager() {
        return new WindowsNetworkManager();
    }
}

// Concrete class for creating a factory for a Linux toolkit
class LinuxToolkitFactory extends ToolkitFactory {
    createTaskManager() {
        return new LinuxTaskManager();
    }
    createDiskManager() {
        return new LinuxDiskManager();
    }
    createNetworkManager() {
        return new LinuxNetworkManager();
    }
}

// Abstract class for a TaskManager
class TaskManager {
    constructor() {
        if (this.constructor === TaskManager) {
            throw new Error("Cannot instantiate abstract class!");
        }
    }
    list() {
        throw new Error("This method must be overwritten!");
    }
    start() {
        throw new Error("This method must be overwritten!");
    }
    stop() {
        throw new Error("This method must be overwritten!");
    }
}

// Concrete class for a Windows TaskManager
class WindowsTaskManager extends TaskManager {
    list() {
        console.log("Listing Windows tasks...");
    }
    start() {
        console.log("Starting Windows task...");
    }
    stop() {
        console.log("Stopping Windows task...");
    }
}

// Concrete class for a Linux
class LinuxTaskManager extends TaskManager {
    list() {
        console.log("Listing Linux tasks...");
    }
    start() {
        console.log("Starting Linux task...");
    }
    stop() {
        console.log("Stopping Linux task...");
    }
}

// Abstract class for a DiskManager
class DiskManager {
    constructor() {
        if (this.constructor === DiskManager) {
            throw new Error("Cannot instantiate abstract class!");
        }
    }
    list() {
        throw new Error("This method must be overwritten!");
    }
    format() {
        throw new Error("This method must be overwritten!");
    }
}

// Concrete class for a Windows DiskManager
class WindowsDiskManager extends DiskManager {
    list() {
        console.log("Listing Windows disks...");
    }
    format() {
        console.log("Formatting Windows disk...");
    }
}

// Concrete class for a Linux
class LinuxDiskManager extends DiskManager {
    list() {
        console.log("Listing Linux disks...");
    }
    format() {
        console.log("Formatting Linux disk...");
    }
}

// Abstract class for a NetworkManager
class NetworkManager {
    constructor() {
        if (this.constructor === NetworkManager) {
            throw new Error("Cannot instantiate abstract class!");
        }
    }
    list() {
        throw new Error("This method must be overwritten!");
    }
    connect() {
        throw new Error("This method must be overwritten!");
    }
    disconnect() {
        throw new Error("This method must be overwritten!");
    }
}

// Concrete class for a Windows NetworkManager
class WindowsNetworkManager extends NetworkManager {
    list() {
        console.log("Listing Windows networks...");
    }
    connect() {
        console.log("Connecting to Windows network...");
    }
    disconnect() {
        console.log("Disconnecting from Windows network...");
    }
}

// Concrete class for a Linux
class LinuxNetworkManager extends NetworkManager {
    list() {
        console.log("Listing Linux networks...");
    }
    connect() {
        console.log("Connecting to Linux network...");
    }
    disconnect() {
        console.log("Disconnecting from Linux network...");
    }
}

// Client code for returning the correct toolkit factory
function getToolkitFactory(os) {
    if (os === 'Windows') {
        return new WindowsToolkitFactory();
    } else if (os === 'Linux') {
        return new LinuxToolkitFactory();
    } else {
        throw new Error("Unsupported OS");
    }
}

// Client code for using the toolkit factory
function useToolkit(toolkitFactory) {
    const taskManager = toolkitFactory.createTaskManager();
    const diskManager = toolkitFactory.createDiskManager();
    const networkManager = toolkitFactory.createNetworkManager();

    while (1) {
        console.log('1. List tasks');
        console.log('2. Start task');
        console.log('3. Stop task');
        console.log('4. List disks');
        console.log('5. Format disk');
        console.log('6. List networks');
        console.log('7. Connect to network');
        console.log('8. Disconnect from network');
        console.log('9. Exit');
        const choice = prompt('Enter your choice: ');
        switch (choice) {
            case '1':
                taskManager.list();
                break;
            case '2':
                taskManager.start();
                break;
            case '3':
                taskManager.stop();
                break;
            case '4':
                diskManager.list();
                break;
            case '5':
                diskManager.format();
                break;
            case '6':
                networkManager.list();
                break;
            case '7':
                networkManager.connect();
                break;
            case '8':
                networkManager.disconnect();
                break;
            case '9':
                return;
            default:
                console.log('Invalid choice');
        }
    }
}

// Usage
const windowsToolkitFactory = getToolkitFactory('Windows');
useToolkit(windowsToolkitFactory);

In the example above, we see four abstract classes: ToolkitFactory, NetworkManager, DiskManager, and TaskManager.

ToolkitFactory - Your goal is to create the toolkit for only two types of OS: Windows and Linux. Since the ToolkitFactory class provides the interface for generating the available tools whose name end with Manager, you can extend this class by creating a Factory subclass for each OS.
NetworkManager, DiskManager, and TaskManager - The toolkit provides the functionalities for managing one's computer, but since it consists of many tools, whose implementation may vary depending on the OS, you simply extend them as well by creating a subclass for each class, and let the concrete Factory class instantiate an object using the subclass, just like how we did in the example of Factory Method pattern.
The client code consists of two functions: one for generating the toolkit, and another for interacting with the toolkit. The function "getToolkitFactory" creates an object of a concrete Factory class based on the type of OS the program runs in. The function "useToolkit" accepts the Factory class as its argument, generates an object of each tool, and provides a prompt for a user to use the tools.

When to Use This?

When you do not have a clear idea of which families of objects to create - The only difference between this pattern and Factory Method pattern is that you can generate objects of more than one type. If you group the related items into several groups based on the families they belong to, then I guess you can use this pattern.
Supporting multiple variants of products: If you develop an application like above where you have to support multiple variants of products without knowing the specifics of each variant, then this pattern may be for you.

Back To List

Builder

The Builder pattern is a creational design pattern that provides a flexible approach for constructing a complex object. In this pattern, the builder provides the interface for making a modification to an object it intends to generate, and the client code updates an object by invoking the functions of a builder class successively. The definition might be hard to understand unless you have a look at the example below:

Example

Scenario: You are a developer tasked with creating a simple script for making an HTTP request to a server. There is a number of aspects that you have to consider when it comes to an HTTP request: you may include in an HTTP request various properties, such as URL, method, cookies, headers, etc. Here is a thing though: you do not always have to provide every one of those properties I mentioned above for each request. For example, if you are making a simple request for fetching information from a website that doesn't require a log-in, then you can simply provide "URL" and "method" parameter with arguments. Or let's say that you want to log in to the website, then the most common approach is to provide "POST" for the "method" parameter, login information for the "data" parameter, and an URL for the "URL" parameter. Every instance is different, and you should allow a user to configure it however you want based on one's circumstances.
Solution: How about providing a class with various functions for configuring an object that you intend to generate. Invoking a function of the class alters a certain aspect of an object, and you can invoke or skip them based on your needs at any given point, providing you with flexibility. When you are finally done with the configuration of an object, you can simply return the object, by invoking a function called "build". Check out this GitHub link or the code below for clarification!

class HTTPRequest {
    constructor() {
        this.url = null;
        this.method = 'GET'; // Default method
        this.headers = {};
        this.cookies = {};
        this.data = null;
    }

    toString() {
        return `HTTPRequest(${this.method} ${this.url}, Headers: ${JSON.stringify(this.headers)}, Cookies: ${JSON.stringify(this.cookies)}, Data: ${this.data})`;
    }

    send() {
        console.log(`Sending request to ${this.url} using method ${this.method}`);
    }
}

// Abstract class for a builder
class HTTPRequestBuilder {
    constructor() {
        if (this.constructor === HTTPRequestBuilder) {
            throw new Error("Cannot instantiate abstract class!");
        }
    }

    setURL(url) {
        this.request.url = url;
        return this;
    }

    setMethod(method) {
        this.request.method = method;
        return this;
    }

    setHeaders(headers) {
        this.request.headers = headers;
        return this;
    }

    setCookies(cookies) {
        this.request.cookies = cookies;
        return this;
    }

    setData(data) {
        this.request.data = data;
        return this;
    }

    build() {
        return this.request;
    }
}

// Concrete class for a GET request builder
class GetRequestBuilder extends HTTPRequestBuilder {
    constructor() {
        super();
        this.request = new HTTPRequest();
        this.request.method = 'GET';
    }
}

// Concrete class for a POST request builder
class PostRequestBuilder extends HTTPRequestBuilder {
    constructor() {
        super();
        this.request = new HTTPRequest();
        this.request.method = 'POST';
    }
}

// Director class to build requests (optional)
class RequestDirector {
    constructor(builder) {
        this.builder = builder;
    }

    construct(url, data = {}, headers = {}, cookies = {}) {
        return this.builder
            .setURL(url)
            .setHeaders(headers)
            .setCookies(cookies)
            .setData(data)
            .build();
    }
}

// Usage
const director = new RequestDirector(new PostRequestBuilder());
// Prompts the user to enter data
const request = director.construct('http://example.com', { name: 'John Doe', age: 42 });
console.log(request.toString()); // HTTPRequest(POST http://example.com, Headers: {}, Cookies: {}, Data: {"name":"John Doe","age":42})
request.send(); // Sends the request to the server

We have one abstract class called HTTPRequestBuilder which has various functions for altering a request object depending on the situational context. Its only responsibility is to provide the abstract interface for configuring an object flexibly. Each function it provides, except for the function "build", returns an object itself, which allows an object to chain itself, every time it modifies the request. Lastly, you invoke the function "build" to finally get the object of HTTPRequest that you modify.
Using the HTTPRequestBuilder class, two concrete builder classes - GetRequestBuilder and PostRequestBuilder - are created. Usually in HTTP, you often differentiate the types of the requests based on their method - GET is often used to fetch the information, whereas POST is used for submitting information of a user, etc. At the time of instantiation, each concrete Builder class instantiates an object of HTTPRequest whose properties are going to be modified by the builder itself, and immediately assigns the method to it accordingly.
The RequestDirector class is completely optional and performs the task of modifying the request to one's liking, by receiving an object of a concrete builder class and invoking its various functions.

When to Use This?

When you have to provide a lot of different arguments to a class for the instantiation of an object - A class having a large amount of parameters for generating an object is usually a bad programming approach, so one way to mitigate this is to provide a builder class that modifies gradually by invoking each function specific for altering only an aspect of an object.
When there are multiple ways of instantiating an object - I think, in Java and multiple programming languages - you can simply provide as many constructor functions as possible to provide as many different ways to create an object. But it may often look bad if you don't do it right, and I feel like an approach of builder class that promotes the gradual change of an object is suited for the readability of the code and the customization of an object.

Back To List

Prototype

The Prototype pattern is a creational design pattern that lets you create objects without having to instantiate them using classes. It is often used when it takes a while to instantiate an object via a class, saving computing and temporal resources. Let's check out the example for understanding it better!

Example

Scenario: You are developing a graphical video game and are tasked with creating an NPC that is going to be spawned in huge numbers. However, due to the way generating a character works, you find out that it takes quite a while to generate a single character using a standard approach of the instantiation of an NPC via a class, which makes it really inefficient and a waste of time.
Solution: Eventually, you figure out the cause of the issue: the texture processing of an NPC. The process of loading the texture files of an NPC and applying them to a character proves to be really inefficient. What if you could just generate a single NPC and copy its processed texture to other NPCs by cloning it? Check out the excerpt of the code below or this GitHub link for source code.

// Abstract class for a game NPC
class NPC {
    constructor() {
        if (this.constructor === NPC) {
            throw new Error("Cannot instantiate abstract class!");
        }
    }
    clone() {
        throw new Error("This method must be overwritten!");
    }
}

// Concrete class for a game NPC with a lot of properties, including textures
class Orc extends NPC {
    #name;
    #health;
    #attack;
    #defense;
    #textures;
    constructor(name, health, attack, defense, textures) {
        super();
        this.#name = name;
        this.#health = health;
        this.#attack = attack;
        this.#defense = defense;
        if (Array.isArray(textures))
            this.loadTextures(textures);
        else
            this.#textures = textures;
    }
    processTextures(textures) {
        console.log("Processing textures...");
        return textures;
    }
    loadTextures(textures) {
        console.log("Loading textures...");
        this.#textures = this.processTextures(textures);
    }
    clone() {
        const clone = structuredClone(this);
        clone.#health = 100;
        return clone;
    }
}

// Usage
// Create an Orc NPC
const orc = new Orc("Orc", 100, 20, 10, ["orc.png", "orc.3d"]);
const orc2 = orc.clone();

The abstract class called NPC is an abstract class providing the interface for implementing a class that represents a type of NPC. It has one function called "clone," and delegates the responsiblity of cloning to objects.
The instantiation of an object of a concrete class called Orc, which is going to be one of the NPCs of the game, launches the initialization process that runs the complex code for loading and processing the texture files of the character for rendering it on the screen. Instead of generating a new object using the Orc class, you invoke the function "clone" of an already existing object and make a hard copy of it. That way, you simply bypass the process of loading and processing the texture files needed to render an NPC on the screen.

When to Use This?

When instantiating an object is resource-intensive: If instantiating an object is simply too inefficient, compared to that of cloning, then you know that this might be a better choice than creating it from scratch.
Avoiding subclassing: Apparently, subclassing excessively can make your code complex and hard to maintain in many situations. If you are in a situation where you have way too many subclasses, then it is probably better to clone an object than to follow a rigid class hierarchy. For example, In a graphics editing application, different shapes might share the same set of functions but differ in their properties, such as color, size, or position. Using the Prototype Pattern, you can clone a shape and adjust its properties, avoiding the need for a subclass for each shape variant.

Back To List

Singleton

The Singleton pattern is a creational design pattern that emphasizes using one object for a class, providing a single access point for controlling an object. If you need only one object of a class for an application, then this may be what you need. Let's check out the example below to see how it may be used.

Example

Scenario: You develop an online document-editing application with a functionality that allows multiple people to work on a single document simulataneously in real-time. Your job is to ensure that only one person modifies a document at a time, which essentially prevents others from doing so.
Solution: Instead of making multiple copies of a document for each user in a session, you generate a single object representing a document, and let others take turns editing it. To allow a single user to edit a document while others wait, you may implement the lock feature that gives only one person access to the editing feature of the document; However, to prevent a person from locking a document indefinitely, you implement a timeout feature, which revokes one's access to a lock after a certain time. Check out this GitHub link or the code below for clarification!

class Document {
    static #lock = null;
    static #content = {
        title: "Document",
        body: "This is a document",
        footer: "End of document"
    };

    constructor() {
        throw new Error("Cannot instantiate this class!");
    }

    static acquireLock(name) {
        if (Document.#isLockExpired()) {
            Document.releaseLock();
        }
        if (!Document.isLocked()) {
            Document.#lock = {
                name: name,
                timestamp: Date.now()
            };
        } else {
            throw new Error("Document is already locked!");
        }
    }

    static releaseLock() {
        Document.#lock = null;
    }

    static isLocked() {
        return Boolean(Document.#lock);
    }

    static #isLockExpired() {
        return Document.#lock && (Date.now() - Document.#lock.timestamp > 5000);
    }

    static modifyContent(key, content) {
        if (!Document.isLocked() || Document.#lock.name !== key)
            throw new Error("Document is locked or you do not hold the lock!");
        Document.#content = content;
        Document.releaseLock();
    }

    static getContent() {
        return Document.#content;
    }
}

// Usage
const key = 'John Doe';
Document.acquireLock(key);
console.log(Document.isLocked()); // true
console.log(Document.getContent());
Document.modifyContent(key, {
    title: "New Document",
    body: "This is a new document",
    footer: "End of new document"
});
console.log(Document.getContent());

In the example, there is a class called Document. The class cannot be instatiated, since it intends to provides a single access point for everyone that access the application.
It has two static private variables: lock and content. The lock holds the key of a user and timestamp for recording when the lock was acquired by the user. Modifying the content of the Document class requires one to acquire a lock by invoking the static function called "acquireLock." The function essentially checks if the lock is already acquired by someone, and if it does, then determines if the lock is already expired or not. A user modifies the content of the Document class, by invoking the function "modifyContent", which accepts two arguments: key, content. A user provides its key that one uses to generate a lock, and the system verifies to make sure that the user is the one that has acquired the lock by comparing the user key to that of "lock" static variable. The Document class replaces its "content" static variable with what a user provides, and lastly, releases a lock, which allows others to acquire it for modifying the Document.

When to Use This?

When you have to manage a shared resource: I feel like this is often used in a situation where various objects need to share a single object. Sharing a configuration object, a connection to DB, and such come to mind.
Controlled access and modification - When you have to make sure that only one person may modify the content and such at a time, like in the example above, then you should consider appplying this pattern to the application, to prevent concurrent modifications.

Back To List

Summary

For this blog post, we went over the Design Patterns: why they matter, the types of patterns, and most importantly, the patterns of the Creational variant. Emphasizing the economical and inheritable approaches, the creational design patterns provide the effective ways of creating objects. Factory Method pattern provides an interface for creating an object of a certain type. Abstract Factory pattern provides an interface for creating the objects of families. Builder pattern provides an interface for creating a complex object flexibly. Prototype pattern provides you a efficient way of creating an object with the concept of cloning. Singleton pattern utilizes a single access point to resource, providing a way to share resource concurrently while preventing race conditions. They are all well effective in decoupling the system, making it more modular and manageable! For the next blog, I will go over the rest of the Structural Patterns. Thank you for reading this long post!