Phoenix86 Writeup - stack{n}
Introduction
Hello, today I'm resolving all the stack challenges that will help me get started in the world of binary exploitation, for this I have chosen the challenges Stack of Pheonix that are very simple but are very good to digest how a stack buffer overflow works specifically for x86 Linux architecture.
I also want to emphasize that I am not yet an expert, in fact I have decided to make this post to learn more about memory corruption. If you have any correction do not hesitate to contact me.
Stack 0
Source code
If you read the description of the challenge you will notice that I'm supposed to overwrite the variable changeme which is a member of locals structure. Here’s the attached code which is also available on the site.
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#define BANNER \
"Welcome to " LEVELNAME ", brought to you by https://exploit.education"
char *gets(char *);
int main(int argc, char **argv) {
struct {
char buffer[64];
volatile int changeme;
} locals;
printf("%s\n", BANNER);
locals.changeme = 0;
gets(locals.buffer);
if (locals.changeme != 0) {
puts("Well done, the 'changeme' variable has been changed!");
} else {
puts(
"Uh oh, 'changeme' has not yet been changed. Would you like to try "
"again?");
}
exit(0);
}So let’s analyse the code. I have my targeted variable changeme which I need to modify to achieve the goal of this challenge, note that variable is declared as volatile.
The keyword volatile is placed before the variable name to indicate that the variable’s value may change unexpectedly and should not be optimized by the compiler.
I have a 64-byte buffer (where each char occupies 1 bytes), and the changeme variable is initialized to 0 within the locals structure.
Now what options do I have to overwrite changeme ? The only attack surface I could think of here is the gets() function as you can see below when attempting to compile the vulnerable program, I received a warning message describing that gets functions is dangerous.

Since gets() does not have any bounds checking, it's possible to trigger a buffer overflow condition here. This means if I write more than 64 bytes to buffer, I will overflow into the variable changeme and change its value.
Let’s fire up the GEF and take a look at what I have.

I can deduce that if I write for example 64 (which is exactly the size of the buffer) A I do not overwrite the variable that is given value in <+33> :

By examining the address of changeme (it's an integer so its length is 4 bytes) which is 0xffffd6fc it seems that it's not overwrite it, I can confirm this by examining also the top of the stack :

But as soon as I exceed 64 bytes, I can start writing in the changeme variable as demonstrated below:

And I have successfully modified the value of a changeme , using a buffer overflow.

Stack 1
Source code
If you read the description of the challenge you will notice that I'm supposed to overwrite the variable changeme with the hex value 0x496c5962 . Here’s the attached code which is also available on the site.
The philosophy of the code is the same as stack-zero except this time I noticed the usage of the function strcpy() instead of gets().
In this challenge, data is being read using the strcpy function, where the input is taken from the first command line parameter. However, this method is unsafe and can result in a stack buffer overflow.
To exploit this vulnerability and overwrite the variable changeme, I employed a similar approach as in the first challenge. However, I had to account for the endianness requirement because the data on the stack is stored in little endian format.
Let’s fire up the GEF and take a look at what I have.

By examining the address of changeme (it's an integer so its length is 4 bytes) which is 0xffffd68c it seems that I successfully overwrite it, I can confirm this by examining its address as below :

And I have successfully modified the value of a changeme , using a buffer overflow.

References
https://www.geeksforgeeks.org/why-strcpy-and-strncpy-are-not-safe-to-use/
Last updated