Microcorruption — Algiers (without understanding the heap structure)

Hello again. This one is a heap exploitation level. I actually solved it without getting into the fascinating heap structure, but you still should understand how the heap works as many of today’s exploits rely on the heap.

First thing is to analyze statically the program. We can see two new functions: malloc and free, which tell us that we are going to exploit the heap. Second thing to do is playing with the user’s input, and so I did. Running the program with ‘A’*22 + ‘B’*22 overflowed the password’s field (22 is the exact number,check it by yourself), hence overflowing the password’s chunk header, causing the first free() function to corrupt, because ‘AA’ = 4141 is not aligned. Diving buttom-up (from the error to the exact line causing it) I noticed that the part of the input is being moved (that’s normal if you understand how the basic glib heap works), causing a faulty memory access at 0x4141. I ran a few instructions and noticed also that I have a control (with the user’s input) of writing into the memory:

4538:  8d4e 0000      mov	r14, 0x0(r13)
(free function)

r13 is in our control, and so does r14. In a matter of a fact, if you analyze a bit the function, r13 points to username[16:20] and r14 to the previous word: username[12:16]. We have a write ability, therefore we can change the return address of the free() function to our own shell which will open the door. the return address resides in the stuck, in my case was at address 0x4394. We want to write into it the address of our shellcode, that will reside in our username. Because we free the chunk, username[4:10] is modified and therefore we can’t put ourshellcode there, but we still have plenty of space!

The last thing we want to do is to jump into our shellcode, so we need to assemble a jump instruction into it. The final username will be as follows:

033c 424242424242 30127f00b012b646 0e24 9443 4242
(1)- (2)--------- (3)------------- (4)- (5)- (6)-

(1) — jump $+0x6 instruction. After we return from free(), we will continue the this instruction which will be a trampoline to the shellcode. You probably ask yourself, why don’t we jump straight away to our shellcode(3)? well, that’s because of we will put it’s address into r14, it will also change the shellcode itself (the value in r14 is used also in other places).
(2) — the these values are changed (part of the free operation)

(3) — the shellcode

(4) — the address of (1)

(5) — the address to return from free()

(6) — garbage to overflow the password

How this looks in the memory:

in the red we can see the flow of the program when we hit the ret instruction. in the green is the address of the address to overwrite (pointed by r13) and in the purple is the value to be places (pointed by r14)

This is probably not the way the writers wanted to solve this challenge, but it’s still legitimate and doesn’t require any knowledge about the heap.