We've destroyed the bridge and the gate, now what?

DESTROY THE WALLS, OF COURSE

BUT OH NO

WE DON'T EVEN HAVE ANY ACCESS FROM THE FUNCTION.

OH NO.

Fear not, because that's what our current objective now.

Let's see on the function ekusupuroshion_magic again.

Let's see again how stuffs are defined inside the stack, especially around the base pointer or anything that relates to return address.

Ooookay, that maybe not such a good image reference (ya maaf aing maling uwu), but what I want you to focus is where the local variables are stored and where is the return address for the current function we're in. Now let's focus on the func_B().

We stored our local variables with the order LIFO, that is to say, when we traversed the stack from low memory to high memory, the last stored variable is the first thing we're gonna meet when we check the stack (in context of local variables). After that, the previously pushed variable, and another one, and another one, and another one, yada yada yada.

After we're finished with variables, there will be stack frames (can be ignored), then THE MOST IMPORTANT THING, the return address for the current function.

Lets see the previous example back in Stage 1.

When we see on the overwritten stack, address for buf is on 0xffffcef4, address for local is on 0xffffcf00, and right after that are few field of values that represent the stack frame. We can ignore that actually, but don't ignore too much because we're searching the position of the return address for the current function.

And so...

How the heck do we find which one that indicates the return address?

Let's disassemble the main() function, then search on where ekusupuroshion_magic get called.

Ah there it is. You see, when a function done it's job and returning, the %eip will go into the address right below the call instruction. In this case, address below the call instruction for the function ekusupuroshion_magic() is 0x080496e3

Now... look at the stack again... Do you notice something?

RIGHT BELOW THAT 0x34333231 IS 0x080496e3. That very position is 0xffffcf1c, but that's not important.

What important is that we know where is the return address.

So what do we do now?

Recall that when we execute the "ret" instruction, our %eip jumps into the value of whatever the top of the stack has that time.

But first, how do we go into the "ret" instruction in our current function?

We need to go into the very end of the function, that is to say, we're not going to jump into any other function (except print function, but lets ignore that).

The "if-else if" block that we have tells us that

If the local value doesn't match the [REDACTED] value, then we go to else if block
When we're in else if block, if the local is not equal with the potion, then we execute the inside.

Surely, we don't want to execute either of the blocks, we already have the answer for that. So we need to skip the entire if-else if block, AND that can be accomplished by changing the local value into the value of potion, or to retain the value of local variable.

On our local machine, the potion is 0x12345678, so we need to keep that value on the "local" variable.

So, in the input.txt, replace the value so that it forms 0x12345678. Remember that it's little endian.

The value in input.txt

61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 78 56 34 12

Execute this and we will got "Nothing happens", and this is what we desire.

But sadly, we don't go anywhere. As we returned to the main function, the program decided to commit not living by "return 0;", and that's not good.

So, our objective now is to jump into the desired function, and that is by changing the return address.

First, find the address for destroy_castle_walls()

On GDB, you can do this in 2 ways.

print *<name of function>, or
disas <name of function>, then see the address for the first, topmost instruction.

We get the same information that the function starts at 0x80492e0

Now, use this address as the thing that we want to overwrite in the return address.

On the input.txt, add some arbitrary bytes just to fill the gap inbetween. Just fill with "AA" 4 times then "BB" 4 times, and so on until you think it reached the return address.

And then, add the address of destroy_castle_walls.

61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 78 56 34 12 aa aa aa aa bb bb bb bb cc cc cc cc e0 92 04 08

Now try to run the program.

WE GOT INTO THE FUNCTION WOO HOO, but wait...

"Not strong enough to destroy castle walls...", and then it ended with segfault.

What happened?

Now, when stumbling upon this problem, it's very wise to actually use the debugger to step down through the instruction one by one, while keeping your eyes on the stack, on the registers, and on where you are now.

You can use gdb hooks to automate the checking every time you step, or use the "proper" layout of gdb in order to see everything at once.....okay maybe not everything. I prefer the latter tho.

Now lets change our layout into something better. On GDB, write

layout regs

AND BAM

What a beautiful sight.... I'm crying :'D

Now let's add a breakpoint on the beginning of destroy_castle_walls function, then re-run the program.

The program will stop on the moment it's going to call another function.

Add another breakpoint after that call <blah blah blah>, and then let's just step the function by using command "step" or "s". If you want to step one by one, use "step instruction" or "stepi" or "si".

Step down until we get into the comparison.

We can see that it's going to compare 0x1ceb00da with whatever lies in $ebp+8, or the first argument supplied to the function.

Let's check what kind of information that this... $ebp+8 has.

x/x $ebp+8

We can now see that it compares with whatever 0xffffcf24 has, in this case, 0x00000000

So we need to overwrite 0xffffcf24 with 0x1ceb00da so our calling succeeds.

Because our input.txt right now only reach up to 0xffffcf20, we need to add 4 more bytes so we can reach 0xffffcf24, so lets add arbitrary bytes, lets say "DD" 4 times in the input, then add the desired value 0x1ceb00da

61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 78 56 34 12 aa aa aa aa bb bb bb bb cc cc cc cc e0 92 04 08 DD DD DD DD da 00 eb 1c

And then let's try to run the program again.

\

Oh shit. We overwrite too much.

It seems that the information that overwritten by 0xdddddddd was used by the function. It's okay, shit happens.

So let's keep the information intact, just like we did in the local variable.

61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 78 56 34 12 aa aa aa aa bb bb bb bb cc cc cc cc e0 92 04 08 40 cf ff ff da 00 eb 1c

Before we go, notice that we have "00" in our input.txt, which means that we're going to insert null byte as an input. GDB is ANGERY when having null bytes as input, so gdb ignores it.

And so, we need to test our file outside the gdb environment.

Run the program just like what we did in Stage 1 and 2.

Pro gaymer moment, bro.

And now, REMEMBER THAT THIS IS FOR LOCAL MACHINE.

And the potion, ekusupuroshion_magic, and buffer differs for each person on the server.

So now you job is to calculate the difference between your X address in local machine and X address in server.

Adjust your input to fit the address in the server, and assuming that your math is good, you'll get the answer.

WAOW, what a journey. PALA AING PUSING, PAUSE SEJENAK DULU LAH ANJAY

Stage 4 nyusul uwu.

Loading...

There will be awesome contents here

Orkom3 Write-Up : Stage 3 - Destroy Castle Walls