Basic windows 7 exploitation analysis

As a System Administrator i realized that we can move through different specializations even it is not our primary role, that is interesting because one can never say that is bored!

I have seen many tutorials about exploit analysis, more about linux and less about windows but all of them very good.  I have studied this subject for a long time but only now i will share some words which may probably have been already said, but i hope this post helps somebody to understand with another example.  In the other hand, i share how i did things (which compiled i used, debugger)  there are many ways to do the same and that is not teached in books.

  1. Get a Windows 7 Professional.
  2. Get a ansi c compiler: Dev-Cpp but can also be Visual Studio 2017.
  3. A debugger (Ollydbg or Immunity).

Create a vulnerable program in C:

Screenshot from 2017-08-10 14-55-59

This is the source, you can copy and paste it:

#include <stdio.h>
#include <string.h>
void doit(char *buffer) {
 int i = 0;
 for(i = 0; i < 30; i++) {
 buffer[i] = 'A';
 printf("Done doit %s !\n", buffer);
void main() {
 char buffer[10];
 printf("Done main!\n");

Now if you compile and test it the program will crash:

Screenshot from 2017-08-10 14-58-51

Lets debug the program and see how this bug can be exploited:

Open the test2.exe file with the debugger of your choice, i will show the examples with Immunity Debugger.  Then step forwared with F8, the .exe will do some initial stuff:

Screenshot from 2017-08-10 15-16-23

The debugged program is displayed in Assembler.  When a function is called in Assm, this is done with the “CALL” instruction, when a Call instruction is executed then the Next line of the code (the next one after the function call) will be stored in the Stack.  This is done so the program can keep from the point where it left, when the function call finishes its work.  This step in particular is done automatically, i guess it is done by the CPU but i am not sure.

When a function is called, the Stack is used to store:

  1. Internal buffers and variables
  2. Saved EBP
  3. The return address

Our stack looks like this in this moment:

Screenshot from 2017-08-10 15-30-14

Then this function doit() is called:

Screenshot from 2017-08-10 15-36-36

Again, the “call” instruction automatically stores the Return Address and the Stack looks like this:

Screenshot from 2017-08-10 15-45-10

As told before, the function saves the Return Address into the STACK, then it saves the EBP (Base Pointer) and space for the variables.  Look that the Stack is a FIFO (First In First Out) Stack.

Screenshot from 2017-08-10 15-58-47

In this function, 30 characters ‘A’ (0x41 in hex) are stored into a variable of size 10, this causes the out of bounds overwrite.  Look the previous picture, where the return address was located in SP:28FECC now it says 41414141 (these are the ‘A’s) and this will cause the program to try to jump to that address and an error.

Screenshot from 2017-08-10 16-01-53

But not so fast, when the function ends, the “LEAVE” instruction is executed and the control of the program returns to the place it came from (Stack Pointer: 28FE9C) this is done by the RET instruction that takes the address in the SS:SP (Stack Segment:Stack Pointer) and continues there.  In this case it is 0040155A.

Screenshot from 2017-08-10 16-11-33

Finally, once in the Instruction Pointer 0040155A the instructions are a LEAVE and finally a RETN.  The LEAVE at 00401566 expects a return address at 0028FEC8 but there we wrote illegally a lot of ‘A’ (0x41 hex) which will exploit the program.

Screenshot from 2017-08-10 16-17-04

Like before, the RET instruction says “where should i go now ?”  It knows that the address should be in SS:SP but our SS:SP is contaminated with noice…. so occurs a Stack Based Buffer overflow.