This stage is pretty similar with the previous stage, as now we're required to modify the "local" variable yet again.

So, when we see the source code yet again, we can see that in order to access destroy_castle_gate(), we need to modify the value of "local" so that it matches the desired value.

But what is the desired value? Nah dude, it ain't zero, the real value is [REDACTED]

Asisten lab sister be like :

Okay so, let's open the GDB and disassemble the ekusupuroshion_magic function.

Check the stuffs that happened right after we returned from the gets() function.

As we can see, in order to access destroy_castle_gate(), we need to skip the "jump not equal" instruction, which tells use that the comparison above needs to be equal in order to skip this.

The value of %eax then compared with $0xdead100c, and from the source code, this %eax was retrieved from -0xc(%ebp), which the value of "local" that's stored in the stack.

From this, we can clearly see that it's just as simple as overwriting the value of "local" into something so that it matches 0xdead100c (in hex).

BUT

Okay here is where it goes tricky.

This program is compiled into Intel x86 architecture (32-bit systems), and one of the characteristics of 32-bit systems is that it uses "little endian" convention.

What is "little endian" again?

Well, it's a simple as "the least significant byte gets placed on the lowest address".

OR

"if you give us 0xAABBCCDD then we stored it in memory so that it reverses in a block of one byte, so you'll see 0xDDCCBBAA when you see it in stack.

Notice in previous post, after we fill the buffer and overwriting the "local" with "1234", it then stored in as "0x34333231".

Meanwhile, the hex representation of "1234" ix 0x31323334. So we can clearly see there is some sort of reversing happened in here, but you don't need to know much. Just put in mind that this happens.

And so... what we're going to do if we want to write 0xdead100c in the stack?

We reverse it.

So, in input.txt, put "0c 10 ad de" in the position of "local", so that when the gets() function overwrites it, it forms 0xdead100c in which the value we're looking for.

To check this, open GDB, place breakpoint after gets(), then check the stack, especially the buffer.

In case you want to run the program in GDB with the input piped from the python script, with the gdb has the program loaded, do :

run <<< $(python hex2raw.py <your token>)

Wow look at that, 0xdead100c, just like what we want!

Do the same thing again with the server and then we got the flag.

Remember to use your own token, uwu.

Stage 3 nyusul again

Loading...

There will be awesome contents here

Orkom3 Write-Up : Stage 2 - Destroy Castle Gate