EchoCTF on Monish Kumar's Blog

Run Run, Ember Run! - EchoCTF Writeup

Sun, 22 Jun 2025 13:45:21 +0530

Introduction

This writeup deals with the Run Run, Ember Run! challenge from EchoCTF. This challenge focused on understanding the MBR boot record format and the bootstrap code it contains. A compressed gunzip archive run_run_ember_run.img.gz contains challenge file.

Challenge Statement:

A small challenge with only four questions for you to answer.

An attacker gained access to one of the systems leaving behind the file attached to this challenge.

Not many details are known about the file but there are at least two ways to get what you want. Depending on the road you'll take it can be as easy as walking in the park or hard as climbing the Himalayas.

You need to analyze the file and answer the following questions...

This is not a filesystem, even though you'll find it on disks... and although its not executable you can still run it!!!

Q1: What is the first thing you'd see from running this image? (200 pts)
The first thing that would greet you is a flag. Give it for answer to this question.

Q2: What do you get from address 0? (300 pts)
What are the values of the first 16 bytes starting from address 0. Remove any spaces from your answer.

Q3: What is the address backdoored by the attacker? (400 pts)
The attacker seemed to have added a backdoor at a certain address. When you try to print this address you will get a flag. What is the backdoored address in hex (prefixed by 0x).

Q4: What is the flag from the backdoored address? (500 pts)
What is the flag being displayed from the backdoored address?

Writeup

The question makes it look like the challenge has something to do with a binary reverse engineering analysis. But also there are points that suggest that it a disk? So first we need to understand what it is we are given.

It says that the file is a DOS/MBR boot sector. So we can’t “run” a boot sector right? That’s what I thought and decided to take a look at the hex dump of the file.

That’s all of the hex dump. So taking a preliminary look at it revealed nothing. I mean no hidden files, no corrupted data, nothing. But what caught my attention is how it is exactly 512 bytes. The boot partitions are indeed 512 bytes. So that suggested we really do have a MBR boot sector at our hands. Hence we should be able to look at the entries using something like fdisk.

So we have something. The partition data that the sector holds. But this is of no use without the actual disk (except for now we know what kinda partitions the computer this record belonged to had). But that can’t be it. I was missing something. And then looking at the wikipedia page for MBR boot record had the following table:

Huh, so there IS something that I was missing. There is an entire 446 bytes of “Bootstrap code area”. That should have been obivous but it wasn’t for me. After all this code region is usually targetted by malicious softwares called Bootkits.

According to the wiki at OSDev (not explicitly mentioned, the example provided there indicated it), this code is of 16-bit x86 instruction set. So all I have to do is disassemble the image provided. Easy.

But before going head first into assembly, recall that the challenge statement explicitly stated to “run” the image. Since we have a valid boot sector image, perhaps we can? Quick search on the internet showed QEMU is good for it. Using the command,

qemu-system-i386 -drive format=raw,file=run_run_ember_run.img

we are able to boot into the boot sector on a virtualized machine console.

Yeah we are indeed greeted with a message. Hence our answer for Q1. It looks like a prompt waiting for input.

Hitting enter on the prompt gave some interesting output. It displays the memory dump of the sector. Since our second question is literally what are the values of first 16 bytes of address 0, we have our answer for that as well.

And for Q3, we apparently have a backdoor of sorts. I saw no other option than having to dive into the assembly code. We can dump the entire image using objdump, I specifically used the following command:

objdump -D -b binary -mi386 -Maddr16,data16 -Mintel run_run_ember_run.img

The options being:

-D : Disassemble the file
-b binary : target object is binary
-mi386 : target architecture is x86
-Maddr16,data16 : Disassembler options
    addr16 : Addresses are in 16-bit
    data16 : Data is in 16-bit
-Mintel : Use intel style assembly code

There was a lot of disassembly. As a matter of fact, we have dumped the entire image file, but the actual code is only 446 bytes, which would mean the offset upto 1bd is the valid code.

And now we read assembly.

Skimming through the assembly dump, the instruction at offset 86 caught my attention. A compare statement that compares the value at the register bx with 0x3750. As far as I could tell 0x3750 is nothing special. But the instruction checks for it, and then branches. So the question arises, what are the two branches?

86:   81 fb 50 37             cmp    bx,0x3750
8a:   75 30                   jne    0xbc
8c:   b0 6d                   mov    al,0x6d

Assuming the likely case that bx won’t be equal to 0x3750, it seems the code we want to execute is at bc offset. That begs the next question, how could bx be set to 0x3750.

74:   e8 c5 00           call   0x13c    
77:   72 05              jb     0x7e     
79:   93                 xchg   bx, ax

A little above the offset of 86, at offset 74, we can see that a call is made to the address 0x13c. In x86 convention a call’s return value is usally found in ax register (if it returns). Then instruction xchg exchanges or swaps the value between bx and ax registers. So bx depends on whatever is returned from the instructions at 0x13c.

13c:   e8 04 00                call   0x143
13f:   72 15                   jb     0x156
141:   88 c4                   mov    ah,al
143:   ac                      lods   al,BYTE PTR ds:[si]
144:   e8 10 00                call   0x157
147:   72 0d                   jb     0x156
149:   c0 e0 04                shl    al,0x4
14c:   88 c2                   mov    dl,al
14e:   ac                      lods   al,BYTE PTR ds:[si]
14f:   e8 05 00                call   0x157
152:   72 02                   jb     0x156
154:   08 d0                   or     al,dl
156:   c3                      ret

To be quite honest, I don’t exactly understand what’s going in here. The call to 0x13c in turn makes a call to 0x143 which is 3 instruction away and kinda confusing and we are missing a ret instruction.

But in a gist the instruction at 0x143 loads a string, an input string to be specific, and calls to another 0x157. It does the same set of instruction twice, but the instruction shl al, 0x4 (shift the contents of al[lower 8 bits of ax] to the left by 4 places), suggests it just processes an input of 16 bits, 8 bits each time. And then the processed contents is stored at the register ax.

So looking at 0x157 we have:

                    ; turns strings to ascii. Like '0' -> 0
157:   2c 30                   sub    al,0x30    
                    ; jump to ret if subtraction is negative. For cases less than '0'
159:   72 0e                   jb     0x169      
                    ; compare al and 10(in decimal)
15b:   3c 0a                   cmp    al,0xa
                    ; compliment carry bit, not sure why
15d:   f5                      cmc
                    ; jump to ret(0x169) if al is above or equal to 10.
                    ; so al must have value between 0 and 9
15e:   73 09                   jae    0x169
160:   2c 31                   sub    al,0x31
162:   72 05                   jb     0x169
164:   04 0a                   add    al,0xa
166:   3c 10                   cmp    al,0x10
168:   f5                      cmc
169:   c3                      ret

Now just looking at the first few lines of the routine, we can see that the call converts the string input to number input. So if we want 0x3750 as value of ax register, we just need to input it?

Yes. We just had to put it there and the flag is given. Could’ve tried that first, nevertheless it was good. So we have our answer for Q4.

We still need answer for Q3. Now this part, I think the question is kinda misleading. It asks for the “backdoored address”. Technically, the backdoor is at offset 86. MBR base address starts at 0x7c00, making the “backdoored address” as 0x7c86. But this is not it. The answer is the value we need to meet at this address. That is our answer for Q3. Or maybe I’m mistaken, but as far as I can tell, that is not an address.

Note

You can actually find the both of the flags in the hex dump from the beginning if you look for it (with some ‘pattern recognition’). I didn’t.But it’s just the flags.

Conclusion

It did take me quite some time to figure out Q3, but nevertheless, the challenge was fun and unique. There ain’t many challenges that require you to boot a boot sector. So all things considered it was a solid.

The Bin in the Dump - EchoCTF Writeup

Mon, 21 Apr 2025 22:27:44 +0530

Introduction

This writeup deals with the The bin in the dump challenge from EchoCTF. This challenge focused on forensic examination of a filesystem image. A compressed gunzip archive the_bin_in_the.dump.gz contains the filesystem image to be examined.

Challenge Statement:

This forensics exercise is about demonstrating some basic tasks that are required in order to trace an attack on a compromised system.

The actual data are illustrative and no actual trojans or exploits exist in any of the files

You are given a filesystem dump and you are tasked to find and report the following details...

Writeup

First things first. Before jumping into the questions we need to understand what kind of file system we are dealing with.

So the output of file command tells us this is a linux-based EXT3 file system. Now we can try to list some contents of the file system using fls from The Slueth Kit.

It looks like we got a root file system at our hands.

Now the questions. The questions are not answered in order as a single output command can give more than one.

Q3. What is the UUID of the filesystem? (100 pts)
Analyze the file and provide the UUID of the filesystem as an answer

As from the file command, we already know the UUID. So that’s one.

Q1. What is the filesystem LABEL? (100 pts)
Analyze the file and provide the filesystem LABEL as an answer

Q2. What is the last folder this file system was mounted under? (100 pts)
Analyze the file and find what was the last folder this file system was mounted under. Provide the folder name verbatim as an answer.

Q4. When was the filesystem created? (100 pts)
Analyze the filesystem and report what was its creation date and time in UTC. The date format is: YYYY-MM-DD HH:MM:SS

Q5. When was the filesystem last write time? (100 pts)
Analyze the filesystem and report what was the last write date and time in UTC. The date format is: YYYY-MM-DD HH:MM:SS.

Now, all this information can be obtained in a number of ways. Here we use debugfs. Using the tool with the -R option allows us to execute a single “request” command. Otherwise the tool is interactive. It’s quite the loaded tool for debugging and examining EXT2/3/4 file systems.

Now we have a lot of information on the screen. We have our filesystem label as the volume name, Last mounted on folder name, file system creation date, last write date among them. Note that there is a matter of localization in the dates. The question specifies we need it in UTC, but I’m on IST, so I had to convert the time.

Q6. What is the file modified by the attacker? (150 pts)
Analyze the filesystem and report what was the full path of the filename that was modified by the attacker?

Now it’s time to get a little creative. Assuming that the file system dump was created after the supposed “attack”, the file modified by attacker needs to have the most recent last modified date. Now I’m not familiar with ways to directly find out the most recently modified file directly.

So I dumped all the files in to my local file system using a tool called testdisk (about the tool). This can also be used to recover recently deleted files.

The tool has a ncurses-like interface with nice hints. So it is pretty self-explanatory. One can also use tsk_recover tool from TSK for the same purpose as well. But the problem is tsk_recover does not preserve the modification date from the original file.

Now you can use the basic ls command in long list mode to find the most recently modified one manually. But we can use find tool with some pipeline magic to do that for us. The following is the command I ended up going with:

find output -type f -exec stat --format '%Y |%y %n ' '{}' \; | sort -nr | awk -F'|'' '{print $2}' | head -10

On top of the list we have our answer which seems to have modified in 2006. The others are from 2002. So that’s our answer.

Q7. What is the full path of the ETSCTF binary that got deleted? (250 pts)
Analyze the filesystem and report what was the full path of the ETSCTF file (the file may have extension)?

Now any file we delete is not actually wiped from the disk by default. Their inodes are declared as free and will be overwritten eventually. But until that happens the data is still present in the same location. Most data recovery programs use this.

Parsing through all the inodes can be a tedious task. Lucky for us, TSK provides a tool fls that is used to list all the files in a file system image. One can make it to return only deleted entries with the -d option.

Above is a snippet of the output. Note that we have a few entries with a non-zero number and others with a 0. As far as I know we can only recover the non-zero entries. The numbers are nothing but the inode numbers of that particular file or directory. So I think a zero means overwritten inode.

Among the entries we have a peculiar directory w0W_d1s_iz_a_hidden_f0ld3r. Yes it is a directory. Notice the ’l’s, ‘r’s and ’d’s? That’s what kind of data was stored in that inode. ’d’ means directory.

But the question is for a file. So maybe it is in the directory? But if it was in the directory and if it was recoverable it should be in the dumped files right?

Nope. Not there. It’s an empty directory. But let’s not give up just yet. There is tool called extundelete(about the tool) that is specific for recovering data from EXT partitions. Using the --restore-all option we can see 2 inodes are recovered.

Listing the files recovered, we have:

So there is our deleted file and the answer.

 Q8: What is the flag that would have been displayed by the ETSCTF binary? (300 pts)
Analyze the filesystem and restore the deleted ETSCTF file. If you only change the first 2 bytes you may be able to run this... If you run this you will be able to get a flag. Give it as an answer here verbatim

By looking at the hex dump, we can say it is not a JPEG. But it doesn’t have any other known file signature as well. But the question says we have to modify the first 2 bytes. So what should we change to? The third and fourth bytes are ‘L’ and ‘F’ respectively. So it is safe to assume that this may be an ELF binary.

Open the binary in a hex editor of choice and change the first two bytes to “7F 45” as the file signature for ELF is “7F 45 4C 46” according to wikipedia.

Do that and slap on the executable bit on the binary with chmod +x, we can execute it. Executing it yields:

Conclusion

And that brings the challenge to an end. I wouldn’t say it as easy as the challenge description puts it. But if you’re strong with the fundamentals and know how to search for tools to do things, it is doable.