Oh here we go, boiiiiiiiiiiiiiii

We have arrived in the castle, boiiiiiiiiiiiiiiiii.

But oh no..

We were told to change the global variable WITHOUT any helper function.

Oh no.

So what we're going to do?

The challenge only give us so much info that we're left speechless.

Nah, i'm being too overreacting.

The challenge gave us a hint which relates to how data and instruction are differentiated by the computer. I'm gonna use "demon lord" as subtitution for "challenge" from here onwards.

Ahem.

The demon lord is so kind that he/she gave us a link to stackoverflow, our very bible, about how data and instruction are differentiated. You can check it out here.

Done reading?

Data and instruction are both represented by hexadecimal values, BECAUSE THAT'S HOW EVERYTHING WORKS IN THE WORLD FULL OF 0 AND 1.

But what makes them different?

Well, you see, instruction is basically data. But instructions are predefined by the processing unit, and they differs from producers to producers. This is basically why there are x86 softwares, 64-bit softwares, ARM softwares/application, or even other kind of softwares whom the architecture I've never heard of.

Okay, back to the demon lord.

Instructions are represented by binary opcodes, can have the length of only one byte into several bytes, depending on the manufacturer.

An example : This is the "mov" instruction in x86 systems.

In our current, program, the "mov" instruction is defined by hexadecimal value "c7".

And so on for another instructions.

So in order to modify the global variable, first locate the address of the said variable.

Which variable?, well, check the rebuild-overflow.c again.

Spoiler : keep_destroying_phrase

Open GDB and :

print &keep_destroying_phrase

Yea boi, we get the address : 0x0804c068

So, what should we do now?

I'm going to give you reference that is very useful and directly relates to this demon lord.

(Actually you can stop reading now because that reference is pretty much all you need).

.

.

.

.

.

.

.

OKAY THANKS FOR CONTINUING READING. THAT MEANS A LOT FOR ME.

Okay, back to the demon lord.

So, in order to modify the global variable, we need the program to execute some instructions that we want. There are nothing in the symbol table or functions that can help us to destroy the keep, so we're going to define it ourselves.

Yes, you heard that right.

We are going to write some assemblies.

Basically, we just want to change the global variable into something that the destroy_keep going to accept.

When we disassemble destroy_keep, the first comparison already reveals us on what value the global variable is going to be compared.

It's going to be compared with 0xabadb3ef, and doing the similar method reveals that the address for the keep_destroying_phrase is 0x0804c068.

destroy_keep : 0x080493e9
cmp : 0xabadb3ef
keep_destroying_phrase : 0x0804c069

Now, how we're going to change the global variable?

Remember that we have "mov" instruction that can modify an address or register with the desired value.

So let's construct our assembly code :

movl $0xabadb3ef, 0x0804c069

ret

Explanation :

"movl" overwrites the destination with the source. In GAS, first argument after the instruction is the source, second argument is the destination. So we're going to overwrite anything in address 0x0804c069 with 0xabadb3ef.
"ret" sets the %eip into anything in the stack right now. We need this because we need to go to somewhere after executing the instruction, rather than sliding down endlessly until we beautifully perform Segmentation Fault.

Save this into a file, let's say inject.s (because .s is a file extension with close relation with assembly instructions)

After that, use gcc to compile this into object code, with flag "-m32" to create object code in x86 assembly.

gcc -m32 -c inject.s -o inject.o

And then use objdump to "dump" the compiled object code into something that at least readable by us mortals.

Use "-d" flag as to "disassemble " it.

objdump -d inject.o

You'll get something similar with this.

The generated byte codes will be injected into the stack, and then it's our job to execute this.

But how?

Recall what we did in stage 4 and 3, we simply change the value in the current return address into somewhere we want. But where?

Let's first inject this code, and see the stack...or the buffer...or whatever...

Don't forget to add breakpoint in the "ret" of ekusupurushion_magic.

If you look closely, our instruction is inserted at 0xffffcf20 in little endian (below 0xaaaaaaaa).

So, change the return address into that address (in this case, 0x08049212 -> 0xffffcf20).

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 20 cf ff ff c7 05 68 c0 04 08 ef b3 ad ab c3

Then check the stack.

Then carefully step down one by one, use "layout regs" to make things look better. If you did things right, you'll step into the instruction that you just "injected", and then the program will execute the instructions. Lets stop at "ret".

And wow, the global value has been modified, wow.

But after this, if you step down and execute "ret", %eip will be set to something familiar

Look on how we're jumping into 0xc06805c7, which the first 4 bytes of the instructions we just injected.

So clearly the %esp also points at 0xffffcf20 after returning from ekusupuroshion_magic.

So what should we do?

We can "push" our injected instruction back by 4 bytes, and fill that 4 bytes with the address of destroy_keep. Because we "pushed" our instruction, it means that the start of the instruction also changes. Because we push it back by 4 bytes, change the previously 0xffffcf20 into 0xffffcf24, adding 4 into the value.

Look on how we get into the keep to destroy everything, and how we avoided the jump instruction by giving the right value.

Exit the program, and re-run it.

Now make some adjustments with the server.

and then

EKUSUPUROOOOSHIOOOOOOOON

WAOW, what a journey.

But wait, masih ada bonus meme round uwu.

Tapi jangan sekarang, lagi laper wkwk..

Orkom3 Write-Up : Stage 5 - Destroy Keep