Reverse engineering PWN tasks or exploiting binary vulnerabilities (Part 4 / Stack3)

Good day to all! We are gaining momentum… Today we will 'pump' stack3.exe (link to the file, as usual, is on Github).

Stack3

Throw it into Ghidra:

We analyze…

We get the decompiled code. We are met by the same array of 64 bytes. The unsafe gets() function. The gets() function reads a string of characters from the standard input stream (stdin) and places it in the local_54 array. The code also contains a pointer (local_14) to the function and a check (if) to see if local_14 is NULL. That is, if we “overwrite” local_14, we will get to the THEN branch and get the message “calling function pointer, jumping to…”, and also go to the address with which we will overwrite local_14:

Everything seems clear, but there is a feeling that something is missing? 🙂

Please note the “win” function:

The “win” function simply outputs the message “code flow successfully changed”:

In fact, we need to use BOF to change the value of the function pointer so that it points to the address of the “win” function (this will make the “Stack3” task succeed).

Let's move on to “dynamics”. We search by strings:

Click on the line with “code flow successfully changed” and look at the address of the “push ebp” instruction (P.S. This is the beginning of the “win” function. If you are interested in why this is so, read about prologue/epilogue of the procedure):

Great! We have the address. Let's look at our “payload”, which we will feed to the standard input stream (stdin):

We exploit. The pointer has been changed and we have entered the “win” function (as indicated by the message “code flow successfully changed”):

Thank you all for your attention! If you liked the article, I'll be glad to give it a thumbs up!