Blog Posts on Monish Kumar's Blog

JITFP - PicoCTF 2026 Challenge Writeup

Fri, 20 Mar 2026 10:41:25 +0530

I took part in PicoCTF 2026, that happened between 9th March 2026 to 19th March 2026. I ranked at 570 globally and got a total score of 11,000 out of the maximum 14,500.

I didn’t plan on writing writeups for this one. But there was one challenge that was so good, that I had to write about it.

JITFP

Challenge Description

If we can crack the password checker on this remote host, we will be able to infiltrate deeper into this criminal organization. The catch is it only functions properly on the host on which we found it.

The challenge is now moved to picoCTF gym, you can access it here. In the live CTF, this challenge was for 500 points, which was the highest among all the other challenges (except for other 500 point challenge, of course).

Solution

The description doesn’t tell us much or doesn’t give us any files to actually reverse engineer binaries. However, there is an instance associated with the challenge. Launching it gives you credentials for a SSH login on a remote host.

Logging in, we are greeted with, uh well, a message. And put in a directory with only one binary. Assuming this is the target binary, I started to poke it.

The binary takes an arguement input and does something with it. There is a loading bar like output that takes some time to complete before printing the incorrect message. I wanted to time it, so I used time utility. It takes around 33 seconds to run once. This brings a thought, is this a timing side channel attack scenario? Perhaps if I give a correct character at a position it would speed up or slow down? I tried it but it still ran the same 33 seconds.

So to move further, we have to pop open and look under the hood. Since the binary was in a SSH instance, I used scp to make a local copy and then used it to analyze it locally. I loaded it in Binary Ninja and the main function looked like this:

We have a peculiar looking if statement, where if the condition is false, it calls another function, prints out “Incorrect” and then exits. The other flow is what we should be doing to get the correct message. We still need to know what the function sub_401932 does.

So basically, it prints out asterisk, sleeps and prints a new line and exits. Not that interesting except this is where the sleep happens.

Going back to the if condition, it didn’t make much sense to me, so I decided to get a second opinion from IDA (yes I have multiple decompilers, they are all awesome in their own way).

Now that is better. So we have one memory array that index into another memory array which has function pointers because whatever is in there is used to call a function, so the most sensible conclusion is that they are function pointers. So let’s take a look at the memory arrays. At the first layer memory array, that index into the function pointer array we have:

So we have a bunch of indices indeed. Looking at the second array, the one which should have function pointers, we have:

That don’t look like much. So I took a look at the same address in Binary Ninja:

There is nothing here. So I started to look around for other things.

Another important detail I found was that in the binary there are a lot of functions like these:

There were functions like these for all the lowercase and uppercase alphabets, digits, underscore and curly braces. So these functions basically check if the given character is the one there are validating or not. So it is logical to assume that, these are the functions that would be present and called from the function pointer array.

However that is empty. Or is it just uninitialized? Perhaps the function pointers are populated at runtime only? And then the title suddenly made sense, “Just In Time Function Pointers”, JITFP. So I just have to dump whatever that memory is in runtime and get the functions pointers. Easy, right?. Or that’s what I thought. But no, I can’t even run the thing in my local machine

Now, this shouldn’t really come as a surprise, because the description of challenge literally tells that we can only run it on the remote machine. So I have to rely on any debugging tools on the remote machine.

So, in terms of tools, there was none. Hence, the question became “how can I dump a memory of a live running process?”. Yes, the procfs at /proc. Every process’s has it’s mapping of memory at /proc/<pid>/maps and actual memory contents at /proc/<pid>/mem. So I opened two SSH shells into the remote machine with tmux and saw if I could access the procfs.

I could. Now we just have to dump the memory contents into a file and analyze it. Turns out the file system is read-only. Great. So I thought of redirecting the memory to xxd utility, copying the hex dump and then analyzing it. But before I could go further I wanted to check what kind of protection this binary has. Thankfully, checksec was installed.

We got PIE, Position Independent Executable. But this shouldn’t really be a problem as PIE just randomizes the base address of the virtual memory. If we had ASLR, then it would have been hell, because the entire layout of the virtual memory would be randomized, but thankfully no.

Now all I had to do was put together a bunch of commands that would take the /proc/<pid>/maps as input and dump the required memory. Since the memory we are interested is in 0x4120, the content would be present at base + 0x4120. We only need to read 264 bytes of information because that’s how long the function pointer array was. Put these together, I had this script to dump stuff:

./ad7e550b aaaa & pid=$!;
base=$(cat /proc/$pid/maps | grep -m1 "r--p 00000000" | cut -d'-' -f1);
target=$(printf "%d" $((16#$base + 0x4120)));
dd if=/proc/$pid/mem iflag=skip_bytes,count_bytes skip=$target count=264 2>/dev/null | xxd -p;

This gave an output like:

If I dumped the memory immediately, it is still uninititialized. So I had to add some sleep command to get some actual output. Right now it doesn’t look like much, but these do actually look like function pointers from a binary. I put together a small python script to parse this and print me the function offsets.

data = "<dumped hex>"

ptrs = [int.from_bytes(data[i : i + 8], "little") for i in range(0, len(data), 8)]

base = 0x....

offsets = [p - base for p in ptrs]

for i, o in enumerate(offsets):
    print(f"idx {i}: offset 0x{o:x}")

This prints out the offsets that are given by the addresses in the hexdump.

And good enough, these offsets correspond to actual function offsets in the binary. So the only thing now to do is index this offsets using the first memory array and see in which order, which functions are being called. I extended the previous script a little to get that part done.

data = "<dumped hex>"

func_map = {...} # A dictionary mapping which function offset correspond to which character

dword_4020 = [...] # The indices from the first memory array

ptrs = [int.from_bytes(data[i : i + 8], "little") for i in range(0, len(data), 8)]
base = 0x...
offsets = [p - base for p in ptrs]
flag = []

for idx in dword_4020:
    flag.append(func_map[offsets[idx]])

print("".join(flag))

Executing this gave:

Now that does not look like a flag to me. I checked my scripts and other things, everything seemed to be right. So I decided to do the same process one more time. And it gave me:

An entirely different output. But why? I did everything the same, except for one thing. I adjusted the sleep duration in bash from 5 to 2, thinking I need to read the memory early. At this point I had no idea what to do and I almost gave up. It wasn’t until later it struck me, “what if the entirety of the function pointer array changes every second?”. That would mean that only one memory address at a point of time would be the right one, the rest are just fillers.

I modified the bash script I used to extract the memory from procfs as:

./ad7e550b aaaa & pid=$!; i=1; cat /proc/$pid/maps; 
while [ $i -lt 35 ]; do
  base=$(cat /proc/$pid/maps | grep -m1 "r--p 00000000" | cut -d'-' -f1)
  target=$(printf "%d" $((16#$base + 0x4120)))
  dd if=/proc/$pid/mem iflag=skip_bytes,count_bytes skip=$target count=264 2>/dev/null | xxd -p
  i=$(($i+1))
  sleep 1
done

This dumped the memory address 33 times. I put 35 just to be sure, in case. So I put all those hex dumps in a text file and modified my python script to:

func_map = {...} # A dictionary mapping which function offset correspond to which character

dword_4020 = [...] # The indices from the first memory array

def parse_dump(line):
    hex_str = line.strip().replace(" ", "")
    data = bytes.fromhex(hex_str)
    return [int.from_bytes(data[i : i + 8], "little") for i in range(0, len(data), 8)]

lines = []
with open("dumps.txt") as f:
    for _ in range(33):
        l = []
        for _ in range(9):
            l.append(f.readline().strip("\n"))
        lines.append("".join(l))

base = 0x...

flag = []
for second, line in enumerate(lines):
    if second >= len(dword_4020):
        break
    ptrs = parse_dump(line)
    idx = dword_4020[second]
    ptr = ptrs[idx]
    offset = ptr - base
    char = func_map.get(offset, "?")
    flag.append(char)
    print(f"second {second:02d}: idx={idx:#x} offset={offset:#x} char={char}")

print(f"\nFlag: {''.join(flag)}")

Now, there is a bit of a timing requirement to this challenge, as the first time I ran it, it was some random output. But when I ran it again, it worked. I got:

I still didn’t get the ‘p’ in ‘picoCTF’ for some reason, but I could fill it, submit it and get the points. This was such a cool challenge, that I had to rethink everything again and again and again. And the part where the function pointer array getting randomized for every second execpt for the right index was absolutely devious. Loved it.

Barbwire: an eBPF based behavioral correlator

Sun, 08 Mar 2026 16:42:18 +0530

Introduction

After the eBPF learning phase I wrote about in the last post, I wanted to build something that looked like a real security tool. Not because I thought I’d ship it, but because the programs I tried before where stupid. At some point you need a problem with actual constraints.

Barbwire is that project. It’s a lightweight behavioral correlator for Linux. It watches for processes that open sensitive files and then make network connections within a short time window. This is classic exfil behavior and rough fingerprint for credential harvesting and so on. It’s not a production EDR. It’s an experiment. It’s on my Github if anyone’s interested.

The core design decision

The first instinct when building something with eBPF is to put logic in the BPF side. It’s running in the kernel, it’s fast, why not do the correlation there?

I thought about it and decided against it early. The BPF verifier gets unhappy with complex logic. It’s harder to debug, less portable across kernel versions, and for this use case, unnecessary. Userspace is fast enough. The design I landed on: BPF is a dumb data collector, userspace does the thinking.

The BPF side attaches tracepoints to three syscalls. sys_enter_openat for file opens, sys_enter_connect for network connections, and sys_enter_execve for process execution to track lineage. All three write into a single shared ring buffer with an event type field. Userspace reads and routes.

I used a ring buffer over a perf event array deliberately. Perf event arrays are per-CPU, so you have to poll multiple buffers and deal with out-of-order events. A ring buffer is a single shared buffer, better throughput, simpler consumer. So obviously I wanted the path of least resistance.

How correlation and scoring works

On the userspace side, three in-memory maps hold state. Recent file opens per PID, process lineage from exec events, and a deduplication map to avoid alerting on the same PID repeatedly. A cleanup goroutine evicts stale entries every 30 seconds.

The correlation window is configurable. I have it set to 5 seconds. When a connect event comes in, Barbwire looks back at that PID’s recent file opens and checks if any fall within the window. If they do, it scores the pair.

Scoring is based on file and connect pairs, not individual signals. A process connecting to the network is normal. Opening /etc/passwd on its own is normal. Both within 5 seconds is suspicious. The score comes from which file category was accessed:

suspicious_files:
  - category: "credential access"
    base_score: 3
    patterns:
      - "/etc/passwd"
      - "/etc/shadow"
      - "/.aws/credentials"
  - category: "ssh key exfiltration"
    base_score: 3
    patterns:
      - ".ssh/id_rsa"
      - ".ssh/id_ed25519"

Process lineage modifies the score up or down. A shell spawning a process that reads credentials and connects out is more suspicious than the same behavior happening under systemd:

suspicious_parents:
  - comm: "bash"
    modifier: 2
  - comm: "sshd"
    modifier: 3

legit_parents:
  - comm: "systemd"
    modifier: -2
  - comm: "dockerd"
    modifier: -2

Alert threshold and severity thresholds are decoupled. The threshold decides if the alert is an actual alert, severity is a classification of the alert. When a connect event comes in, Barbwire picks the highest scoring file match for that PID and emits one alert. One alert per connect event per process, no duplicates (hopefully).

A fired alert looks like this:

┌─ barbwire alert — PID 41890  ─────────────
│  command  : python
│  file     : /etc/passwd
│  connect  : 2404:6800:4007:821::200e:80
│  severity : HIGH
│  reasons  : credential access, suspicious parent: fish
│  parent   : fish (pid 13387)
│  gparent  : tmux: server (pid 9483)
└─────────────────────────────────────────────

My Screwups while building it

A few things broke in ways that were actually instructive. The first one was actually two bugs hiding behind each other, which made it genuinely annoying to debug.

There was a constant mismatch between the C and Go sides. EVENT_EXEC, the event type for sys_enter_execve tracepoint, was 2 and EVENT_CONNECT, the event type for sys_enter_connect, was 3 in the BPF code, but I had them swapped in Go. At the same time, I had attached the exec tracepoint and called Close() on it immediately without a defer, so it detached right after attaching (Yeah this is embrassing).

The symptom was simple, in terms of events I had none. Thing was execve events were being routed to the connect handler. Since those events carry no IP address family, they got dropped as invalid. Meanwhile connect events were being routed to the exec handler, which was already closed. Everything was failing quietly in a different place than where I was looking.

I spent a while staring at the correlation logic before going back to basics and checking whether the tracepoints were even active. Once I caught the missing defer, connect events started showing up, but in the wrong handler. That’s when I found the swapped constants. Two separate bugs, one symptom, neither pointing at the other. Really annoying

The most useful bug involved stale memory in the event struct. bpf_ringbuf_reserve gives you a pointer to uninitialized memory. If you skip the __builtin_memset before writing your fields, whatever was in memory from the previous event bleeds into the fields you didn’t set. I had filenames with garbage characters appended, leftovers from longer filenames earlier in the buffer. The fix is one line. But you have to know it’s needed.

Limitations and takeaways

The biggest problem with Barbwire is the one that can’t be tuned away.

For example, curl reads /etc/passwd on every invocation. Here is it making the call:

Not because it’s malicious, but because that’s how it works. I believe, basically any program using libc networking does this. Barbwire flags it every time. No matter how hard I tuned the knobs, I couldn’t get rid of such alerts. Then it hit me, single-process correlation without broader context has a ceiling.

Evidently, production security tools handle this differently. Binary hash whitelisting instead of process name matching, which is spoofable. Process ancestry graphs that track behavioral chains across multiple processes. Behavioral baselines built up over time. A shell that reads /etc/passwd and then forks a child that connects out would be caught by a graph-based correlator. Barbwire misses it because the file open and the connect are in different PIDs.

Building this made that limitation concrete in a way I don’t think I’d have gotten from just reading about EDR design. Honestly, I never even thought of these before. You also understand why process ancestry graphs exist when your tool fails exactly where they’d succeed.

The other thing I took away: the BPF to userspace boundary is unforgiving. Memory layout, pointer semantics, which helper functions apply where, what the verifier accepts. The documentation covers the what, but the why only shows up when things break.

All things considered, I had fun with all this. That’s the whole point if you think about it.

I wanted to poke at the Linux kernel. eBPF was the answer

Sat, 07 Mar 2026 20:32:58 +0530

Introduction

A while back I came across Cloudflare’s writeup on how they mitigated a 3.8 Tbps DDoS attack, the largest ever disclosed publicly at the time. The post goes deep into how their systems detected and dropped attack traffic autonomously (quite interesting stuff). One part that caught my eye: they used XDP and eBPF to drop packets directly at the NIC level, before the kernel network stack even saw them. I had zero clue on what eBPF was back then. I thought that was interesting, bookmarked it, and then forgot about it (Yeah I do that a lot).

When I eventually got around to it, I was looking to get into lower level Linux stuff anyway. How the kernel works, how you can poke at it from the outside. eBPF kept coming up. I also saw it framed as a safer alternative to writing kernel modules for certain use cases. That part made immediate sense to me, because writing kernel modules means one bad pointer dereference and your machine is just down. So I thought maybe I could look into it seriously.

What even is eBPF

eBPF lets you run sandboxed programs inside the Linux kernel without modifying the kernel source or loading a module. Before your program runs, the kernel verifies it. No unbounded loops, no out-of-bounds memory access, every code path has to terminate. If it doesn’t pass, it doesn’t load. However it doesn’t mean it’s bullet-proof, I still found some bugs and weird things happen now and then. But it catches the most obvious ones.

Evidently, it started as Berkeley Packet Filter, which was just a way to filter network packets efficiently. The “extended” part came later and expanded it well beyond that when people wanted better tracing options when debugging inside the kernel. These days it shows up in observability tools, performance profilers, security products, and a lot of infrastructure tooling that runs quietly in the background of production systems.

How I learned it

I started reading Learning eBPF by Liz Rice and went through it cover to cover. It builds up a solid mental model of how everything fits together, the verifier, maps, ring buffers, CO-RE, without throwing you into kernel internals from page one. Great book, would recommend it if you’re starting out.

After that I spent time staring and reading through examples at libbpf-bootstrap and cilium/ebpf. That was just to see how things are done in real projects and scripts.

Then I started writing stuff. A per-process file access counter. A pure C rough version of what would eventually become Barbwire. None of it was useful or anything. It was just to get familiar with the toolchain, get yelled at by the verifier, figure out why and repeat.

What I liked about eBPF

A couple of things genuinely impressed me.

The first was CO-RE, which stands for Compile Once, Run Everywhere. Despite my reservations on Java, I always thought the idea of Code once, run everywhere was pretty neat (Thanks to JVM). CO-RE brings the same thing to Linux kernel programming. It handles struct field offset relocations across kernel versions, so your program isn’t silently tied to the exact kernel it was compiled against. Without it, anything that walks kernel structs like task_struct breaks the moment you run it on a different machine. With it, the same binary works across versions. It is remarkable as far as I can tell.

The second was how dynamic the whole thing is. With kernel modules you write code, compile, load, and if something goes wrong you restart. With eBPF you attach programs to running systems and detach them without rebooting or disrupting anything. For observability and containers especially, that matters a lot. You can instrument a live system, see what you need, and pull the probe out. No downtime, no risk of leaving a bad module loaded.

What came next

After a few weeks of experiments I felt ready to build something with an actual purpose. That became Barbwire, a lightweight behavioral correlator that watches for processes opening sensitive files and then making network connections. I’ll write about that in the next post.

It’s not a production security tool. It’s an experiment. But building it was a good reason to use eBPF for something real instead of just counting file accesses forever.

Honeyfused: An intrusion detection script using FUSE filesystem

Tue, 26 Aug 2025 18:24:58 +0530

Introduction

First things first, what is Honeyfused? It’s a fun little side project that I spent some time on. It is on my github repo if anyone’s interested.

Honeyfused is in a sense an intrusion detection application using honey-files. The program emulates filesystem mounted on directories and presents files that are actually not part of the original filesystem. Since the program emulates folders that usually contains secrets and API keys, intruders and infostealers may try to access it and possibly exfil the files. Since we control the filesystem, we can generate alerts whenever the file is accessed or modified. That is the gist of it. In this article you’ll find why I did this, how I did this and things like that.

How did I get here?

I very recently learnt that you can implement virtual filesystems, that is, filesystem that are not actually present on the disk, using FUSE bindings. All one had to do is override the operating system filesystem function calls to mimic an actual filesystem and you can literally pull show a filesystem out of nowhere.

Armed with the knowledge, I thought “why can’t I just implement a decoy filesystem with decoy files and generate alerts whenever the files are accessed?”. But this is basically honey-files with extra steps, that is, the virtual filesystem. Then I thought a honey-file is always the same, always there in the same place, and it is usually something like “passwords.txt” or “keys.csv”. So what if I could dynamically generate new file contents in important places, places where applications usually keep their tokens, secrets and keys, places which are more believable and look like legit files to an attacker, places which an infostealer would automatically enumerate. And hence, I got started to find out.

The filesystem implementation

There are a few libraries that provide libfuse bindings in Python. Namely fusepy, python-fuse, mfusepy etc. I choose to work with mfusepy as it is one of the still maintained one. I couldn’t find any documentation about the module. But lucky for me, they maintain a folder of example implementations. One of those aligns closely with what I want, a pure in-memory virtual filesystem implementation. Even though it did not clearly specify what should be actually done, it did give me a gist of how to do it.

However the example script didn’t quite work out-of-the-box for me. So I made some modifications and additions of my own to emulate an actual filesystem. At the end of it, I had a script to create a virtual filesystem that can contain and display files, create new files, delete existing ones, create a directoy and so on.

What to generate?

Now that, I can mount an filesystem whereever I want, I need to generate files. Not just any files, files that appear to be legit, files that should be placed in places where popular applications places them. Then I spent some time researching in popular applications and their configurations. Nah, I’m kidding. I used ChatGPT to tell me how popular applications stored their configs and keys. At the end of it, I had a list of applications that seemed to be good candidates for the decoy files. I settled for Kubernetes’s kubeconfig, AWS’s credential and config file, Azure’s credentials.json, GCP’s default application config file, Terraform’s credential file, Docker’s config file and lastly Bitcoin’s config and wallet files. Mostly developer centric, I know.

With an list of candidate application, I then again asked ChatGPT to give me a blueprint of configuration files and what kind of data should I use to fill it with. With that, I used Python’s string.template to craft template of files and wrote generator functions to dynamically populate the templates. It took me some time to cover this aspect of the ground but it was fine.

Putting things together

At this point, I have a script to mount a fake filesystem anywhere I want and generator functions that can give me realistic looking files that popular applications use. Only thing left is to put these things together. I used a YAML file (config.yml) as the configuration file for user. With that user can specify which applications can the script emulate and present decoys for. Because we don’t want to present decoys for already present applications.

It took going a little back and forth on things, until I finally managed to put it together. So now my script (actually scripts), managed to generate decoy files for applications provided in config.yml and mount it in place I wanted.

The logging

I’ll admit, I haven’t done a lot of logging stuff in Python. Since mfusepy already provided debug logs for the filesystem, I tried to implement logging that gives debug information for my script. So I read the documentation (yes I actually did that), and implemented it. And then I remembered that I had to log alerts as well, because that is the whole point of the application. But I didn’t want to throw all the log at once. So I seperated logs from myfusepy, debug information from my script and the alerts I want to give out. Turns out it’s surprisingly easy than it sounds.

Conclusion

It took me over an week to put all these together. I mean I didn’t spent all my time on this, but okay. So basically I got an Intrusion detection system out that puts fake files on your filesystem and then alerts you when someone accesses it. It is geared more towards developers who keep these kinda files in their storage. But at the end this is just a stupid experiment. So I hope no one uses it as an actual security measure. Still it was pretty fun convincing the system that a filesystem exists when it doesn’t and generate configuration files for various applications.

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.