Reverse Engineering 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.

Reverse Engineering - GoCrackMe1

Sat, 26 Apr 2025 17:51:33 +0530

GoCrackMe1

Challenge Statement

Author: @HuskyHacks

TENNNNNN-HUT!

Welcome to the Go Dojo, gophers in training!

Go malware is on the rise. So we need you to sharpen up those Go reverse engineering skills. We’ve written three simple CrackMe programs in Go to turn you into Go-binary reverse engineering ninjas!

First up is the easiest of the three. Go get em!

Archive password: infected

Attachment: GoCrackMe1.zip

Solution

Extracting the archive we are provided with ELF executable (linux executable) that is obviously written and compiled with Go language.

Even though this is a reverse engineering challenge, my first thought was to run it. So when I ran it (of course in a virtual machine), I got an “Access denied!” straight. So there is a good chance there is a conditional statement in the binary, that controls the execution flow.

So I decided to do a static analysis and opened the file in Cutter which is a nice frontend for the radare2 tool. Opening it, there was a lot of functions inside that turned up in the analysis. But Go language like most language, starts it execution from main function, I decided to look for the main function.

At first I was focused on the hex data that was being declared and initialized. On a quick look they might seem like data put in different variables across different locations. But you see, they are being written to consecutive locations right after one another. The reason why they are broken is because they are moved to the memory in different instructions. Some decompilers may recognize this and collate them, but the one I used didn’t.

But then I looked below it, and saw a if-else statement. Since I already suspected a conditional statement somewhere that controls the flow, I thought this might be it. Both the if and else block contained a fprintln function which is basically print function in Go. Whatever the case might be, if this indeed is the check I’m looking for then reversing the jump statement that directs the execution flow should execute the other part.

Cutter allows one to patch binaries if opened in write mode. So I made a copy of the binary as a backup if it is not what I think it is and switch to write mode. In Cutter any changes made to the binary in write mode is instantly written to the binary which is in contrast to several other tools which requires some sort of explicit ‘Patch binary’ options to write to binary.

So now, I’m looking for a jump statement in the disassembly.

As I skimmed through the disassembly, the disassembler could locate the call that goes to the function checkCondition. Following it is a test instruction and a je (jump if equal) condition. So basically this je instruction is what I’m looking for.

Cutter provides option to edit the instruction in such a way to reverse the jump, that is change je to jne. This turns the execution around.

Now that I’ve reversed the jump now, all I have to do to test my theory is to run it. Which indeed provides the flag.

Even though I got the flag, I still wanted to check if the data I was focused on previously was indeed the data that was xored to give the flag. So I opened cyberchef, copied the data in it and put the key. You may find the key at the other end of the expression in the for loop which is 0x56.

And it indeed was that data. So this could be considered an alternate method to do the challenge.

Reverse Engineering - Stack It

Sat, 26 Apr 2025 17:51:33 +0530

Stack It

Challenge Statement

Author: @sudo_Rem

Our team of security analysts recently worked through a peculiar Lumma sample.

The dentists helping us advised we floss at least twice a day to help out.

He also gave us this weird file. Maybe you can help us out.

Attachment: stack_it.bin

Note: This challenge was accompanied with a per-user instance

Solution

Running file command on the attachment, we can see that it’s an ELF executable.

Since this is a Reverse Engineering challenge I decided look into the disassembly. I used Cutter with Ghidra decompiler plugin to disassemble and decompile the ELF binary for me.

Luckily there was only one function in the ELF executable and it was fairly easy to understand. Let me walk you through it. Below is the screenshot of the decompiled function:

First thing we can notice is some data is written directly to the memory addresses 0x0804a050 till 0x0804a054.

And if you look at the data it is writing, this is hexadecimal for the characters f, l, a, g and {. Seems familiar huh?

Next up we can notice variables puVar7 and puVar8 (names given by the decompiler), are initialized to some strings each. It doesn’t matter much right now, but it will in a moment.

We can also see another variable, a pointer to be specific, is made to point the address 0x0804a055. This is right after where the program wrote the ‘{’ character above.

Then there is a loop where the contents from puVar7 and puVar8 are XORed and put in the address of puVar4 incrementally, which is just a temporary pointer with same address as puVar2, the original pointer.

Once the loop is over, couple bytes of data is put at the end of it. It is 0x7d which is the ‘}’ character and the 0 is essentially the null terminator. So this is our flag. But if you follow along the code, you’ll notice data is written again starting from 0x0804a050 which is the start of the flag.

So essentially, our flag is written to the memory, actually in the stack as it is a local variable, and then rewritten again. So to acquire the flag, we have to stop the execution midway and read the memory directly.

We can use a debugger, a program that can stop execution of a running program and analyze it from various perspectives. It was originally intended for programmers to debug programs, but the print (or cout) statement method is widely used (so do I). So mostly it is used for reverse engineering and malware analysis.

Anyway I went with using the GNU debugger (gdb) to get the job done. Oh and yeah, we are about the execute an unknown binary in a control manner, but still executing it. So it is advisable to do this in a virtual environment so that your main system is not affected. Checkout my hacky script to quickly setup a arch linux vm.

On loading the program with gdb, we can see that there is no symbols loaded required for “debugging”. Simply put we cannot disassemble the code directly.

But we already have the address actually. Cutter already disassembled the code and the assembly code is under the disassembly section.

So we need address of the instruction right after the insertion of ‘}’ character into the address space. So that address seems to be 0x8049045. So all I have to do is set a breakpoint at that address and examine the address space at 0x0804a050.

Set up a breakpoint at 0x08049048 using command break *0x08049048, then run the program to hit the breakpoint. Examined the address 0x0804a050 with x/30s 0x0804a050 ( x - examine, 30 - 30 spaces, s - string format ). Why 30 strings? Not sure why but I do it like that. So yup, there’s the flag.