TryHackMe REloaded Write-Up | Complete Reverse Engineering Walkthrough

Hey everyone! 👋 In this challenge, we were provided with a compiled executable that conceals its flag behind a series of validation checks. Our objective was to reverse engineer the binary, analyze its execution flow, uncover the hidden verification logic, and recover the correct input required to reveal the flag.

Room link: REloaded

Task 1: Level 0 →

Initially, we have to download the file of level 0. I have downloaded the file.

Our first goal is to gather as much information as possible without opening a debugger.

Before diving into assembly or decompilation, I want to understand:

• What type of file is it?
• Does it contain useful strings?
• Are there any hardcoded secrets or flags?
• Is the challenge intended to be solved through simple enumeration?

Since this is the first level of the room and described as a basic reverse engineering challenge, I started with string enumeration.

Before string enumeration, check the file type by using the command:

$ file Level-0.exe 
Level-0.exe: PE32 executable for MS Windows 4.00 (console), Intel i386 (stripped to external PDB), 8 sections

So, we have confirmed that it’s an .exe file.

$ strings Level-0.exe 
!This program cannot be run in DOS mode.
.text
P`.data
.rdata
`@.eh_framP
0@.bss
.idata
.CRT
.tls
UWVS
[^_]
[^_]
;Pw(
 [^_
[^_]
<_t#<nt'
8TuE
UWV1
9_GLO
[^_]
BAL_
8Bu+
UWVS

Why Use strings?

The strings utility extracts human-readable text from a binary. A large number of beginner reverse engineering challenges store important information directly inside the executable. Running strings is often the fastest way to determine whether a challenge requires deeper analysis or whether the solution is already embedded in the binary.

However, we started with basic enumeration using the strings command to extract readable text from the executable. As we know that the flag is more than 10 characters to reduce noise, I filtered for strings between 10 and 100 characters:

While reviewing the output, the string L3v3lZ340_is_D02e stood out because it did not resemble a library name, Windows message, or API string. Its format matched what would be expected of a challenge flag, leading me to conclude that it was the correct answer.

Now we will move to the next task.

Task #2:

For task 2 again, we have to download the file of level 1. After downloading level 1, we have to go through the process of level 0.

Note that there is a string, "Thats ur lucky number!!!" Now we can find this string in the memory and trace it back to find out how it works. So, we need a deeper analysis of the file “Level -1.exe.” Doing this, we will use the tool Ghidra. If you are not familiar with this tool, you can see it here.

First, import the exe file “Level -1.exe." Then, press S and search for the string “Thats ur lucky number!!!”.

Then we have to go to the address "004b1045."

Then press XREF [1], and we get the code. Where if param_1 == 0x6ad, it prints "Thats ur lucky number !!!.". So, 0x6ad is the lucky number. Convert the hex number into the decimal value and submit it. This is the flag.

Task #3:

For task 3 again, we have to download the file of level 2. After downloading the level 2 .exe file, we have to go through the process of level 1.

Now load the "Level-2.exe" file into Ghidra. Then search the string "Get Ready For L4 ;)".

Then move to the location "004b1045."

After locating the authentication routine in Ghidra, I observed that user input was validated using strcmp(). The success branch printed the contents of local_20, which was initialized with the hardcoded string L3_1s_20t_Th3_L131t. By patching the conditional jump to always follow the success path, I bypassed the authentication check and recovered the flag.

We have to find out the answer to second questions for task 3.

So, the instruction is JNZ.

Task #4:

Download the file “Level-3.exe” and go through the process of task 2.

Then import the Level-3.exe file inside Ghidra, and press S and search for the string "Rooted !!!" .

From the code, we see that the password is generated into the following: variable

local_40

and then compared here:

iVar2 = strcmp(param_1,local_40);

Now, question: What value is stored inside local_40?

for (local_10 = 0; local_10 < 0x18; local_10++) {
    pcVar1 = (char *)FUN_00495490(local_28,local_10);
    local_40[local_10] = *pcVar1;
}

This means the password is being generated character-by-character and stored in local_40.

Get A. AntorCSE404’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

After identifying that strcmp() compared user input against the dynamically generated string stored in local_40.

The password is generated from:

FUN_00401410()
FUN_00495490()

Now move to the function FUN_00401410()

What FUN_00401410() does? It creates an array:

local_1f[0] = 0x54;
local_1f[1] = 0x48;
local_1f[2] = 0x4d;
local_1f[3] = 99;
local_1f[4] = 0x74;
local_1f[5] = 0x66;
local_1f[6] = 0x2d;
local_1f[7] = 0x4c;
local_1f[8] = 0x34;

Then

for (local_10 = 0; local_10 < 10; local_10++) {
    local_1f[local_10] = local_1f[local_10] ^ 7;
}

This means every byte is XORed with 7.

In this stage we will use the tool Binary Ninja to get the flag quickly. If you are not familiar with Binary Ninja, you can follow the steps given below:

Install Binary Ninja on your Linux machine.

Download BinaryNinja: click here. Then download it for Linux. After downloading the zip file, we have to unzip it and follow the steps given below:

Navigate to the directory where you have downloaded the zip file. For my case, I have downloaded it in the Download directory.

cd ~/Downloads
unzip binaryninja*.zip

Verify with:

ls

You should see something like:

binaryninja/
binaryninja_free_linux.zip

Move the entire directory to /opt

sudo mv binaryninja /opt/

Create a global command

sudo ln -s /opt/binaryninja/binaryninja /usr/local/bin/binaryninja

Verify:

which binaryninja
/usr/local/bin/binaryninja

Test it in your terminal from any directory:

binaryninja

Binary Ninja will be started. Now back to our challenge. Open the Level-3.exe file in binaryninja.

Now we have to find out the FUN_00401410() function. So, click G in the Binary Ninja. Put the address of functions inside the pop-up. then press Accept.

Then we see the row code of that function and get our desire flag:

Flag: THM***-*4

Task #5:

For task 5 again, we have to download the file of level 4. After downloading the level 4.exe file, we have to go through the process of level 1.

But from this, we did not get anything that is interesting. So, we have to try running the Level-4.exe file. For doing this, I am using the tool Wine, by which we can run the exe file inside the Linux machine.

$ chmod +x Level-4.exe
$ wine ./Level-4.exe 
AmcmQBu^YP+`lDV1pvY^BdR

After executing the program, it returns "AmcmQBu^YP+`lDV1pvY^BdR". Looking at this string, we can assume that it is being encrypted by an algorithm at some point in the program. Since the string is being encrypted and printed to the console, I could see where the printf function was being used in the program. In Ghidra, search for and click "printf." search → Program text

Then press the printf location.

Click the reference XREF[1]. From there, follow the XREFs until you land at the function where the printf function was used (FUN_00401453).

FUN_00401453 performs an XOR-based transformation on the input string. It iterates through each character, calls a helper function to determine the XOR key, and then XORs the character with either the constant 0x37 or its index. The transformed string is modified in place and printed, making this function a simple encoding/decoding routine.

Now load the "Level-4.exe" file in Binary Ninja. Then search the FUN_00401453 function, and then we will see our desired flag for the task.

Flag: **** ****** *** a *******

The REloaded room provided practical experience in reverse engineering by covering binary enumeration, string analysis, authentication bypassing, debugging, and basic encryption analysis. Throughout the challenges, we used static and dynamic analysis techniques to understand program logic, recover hidden values, patch binaries, and inspect memory at runtime. Overall, this room strengthened fundamental reverse engineering skills and demonstrated how different analysis techniques can be combined to solve real-world reversing challenges.

If you enjoyed this write-up, consider following me (A. AntorCSE404) for more CTF challenges, and feel free to leave feedback — I’d love to learn and improve!