Classic Passwd TryHackMe walkthrough

Introduction

Hello guys back again with another walkthrough this time we’ll be doing Classic Passwd from TryHackMe. Am really not great at reverse engineering but from learning buffer overflows i know my way around binary exploitation and some bit of reversing binaries to identify vulnerabilities and that’s what this walkthrough will be all about. I know there are a great number of walkthroughs are out there about solving the challenge but am really a great fan of gdb since it’s one of the main tool used in exploiting buffer overflows and i haven’t seen a walkthrough solving this specific challenge with gdb the second method which I’ll use to solve the binary is to patch it so that even if the wrong password is supplied we still get an authentication success

The first step whenever i get a binary i tried finding the most basic information about it even before trying to reverse it

First i ran the file command

file Challenge.Challenge

From that command we get really important information like the binary is a 64 bit binary also we see that the binary is not stripped meaning we can access all the symbols within the binary making our jobs much easier. We also see that the binary is dynamically linked meaning all the shared libraries are access from our very own operating systems

Next command that i always run is strings

strings Challenge.Challenge

And if you can see at least some portion of what later on will be the password but for the binary. But still it wasn’t much useful you can also try with different strings encodings and if anything useful will show up

But next i decided to load up the binary in ghidra and so some light reverse engineering. Any program gets executed from the main function and that’s where we’ll beginning analyzing the binary

We see that once the program enters the main function it jumps to the vuln function immediately

In the vuln function we see the program is asking for a username and if the username is correct is continues execution of the program by jumping to the gfl function but if the username is wring the program exit with a status code of 0 meaning we never hit the gfl function which contains the flag

Let’s execute the binary and see this happening

N/B Before running any binary from untrusted source always try finding as much information about the binary through the basic reverse engineering skills no matter how little and also utilize publicly available information like virus total to see if what you are executing is a malware

Let’s take a look at the gfl function and see if we can get some quick wins

We can see the flag yes but it’s somewhat obfuscated using hexadecimal encoding but we can use a simple online hex to dec converter to get the flag though i didn’t like this method

Exploitation

But we now have a decent idea of what the script does let’s load it in gdb and use gdb as a debugger

An using the gef extension since I’ve actually come to like it and it’s more often maintained. The first thing you usually after loading a binary in gdb is set breakpoints and looking at the stack for any useful information like memory addresses

So let’s first set a break point on main so that gdb hint it when it reaches the main function

Then let’s continue execution of the program

We’ve successfully hit our first break point sweet. But remember the function we are interested in is vuln since that’s where authentication takes place

So let’s disassemble the vuln function and set a break point where the supplied username is compared to the real function

Let’s set a break point at that memory address and continue through execution of the program

b *0x000055555555525a

After continuing though the execution of the program we directly get asked to enter a username

Let’s enter a wrong username in my case I’ll enter my name musyoka and press enter to continue execution of the program

And we again hit a break point this time in the string compare memory address and looking at the string compare memory address we have our username in pretty much clear text

Trying to use that username on the binary

And we have the flag. That’s the first way we can get the flag from the binary.

SECOND METHOD

The second way is to patch the binary by changing the flow which the binary takes even if we give it an incorrect password

To demonstrate this we’ll be using ghidra to patch the binary so let’s begin

First we need to import the binary but in a raw format

Things will look different when we open the binary in a raw format but out goal is to find the main function of the program

Depending in the result the code flow execution changes. Looking at the assembly code we see that when the “jump is not equal to zero it jumps to LAB_00001271 ” let’s invert the instruction so that jump always becomes zero

Right clicking on that instruction and selecting patch instruction

Original Instruction

Changed instruction

Now that we have successfully changed the instruction let’s save the binary by pressing o

Doing a directory listing we get another binary was created

Doing a md5sum show they are different binary

Now to show the difference I’ll split my tmux window and the upper window will have the modified binary and the lower window will have the original binary

Trying to use a wrong password on the original binary we get an authentication error

But using the wrong password on the patched binary we get authentication was successful and we even get the flag

We get the flag and it’s the same decimal value we had decoded using the online converter. And that’s it!!!! Easy right I hope you enjoyed the walkthrough if so don’t forget to clap for me down below and don’t forget to follow me so that you won’t miss any upcoming articles