Understanding Buffer Overflow and JOP Exploitation

This project delves into the concepts of buffer overflow and Jump-Oriented Programming (JOP) exploitation. It begins by explaining stack and heap buffer overflows, illustrating how they occur and the architecture involved. The project includes a C program example demonstrating a stack buffer overflow, explaining program execution, and how memory addresses are affected. It further explores heap buffer overflows with a vulnerable C program and discusses how to exploit them. The project then moves on to a detailed explanation of JOP, a more advanced exploitation technique that bypasses security measures. JOP utilizes short code sequences (gadgets) ending with a jump instruction. The project also touches upon Return-Oriented Programming (ROP) and highlights how JOP differs by not relying on return instructions. The goal is to understand how attackers can manipulate program control flow to execute arbitrary code, and how these vulnerabilities can be exploited. The project provides a comprehensive overview of these critical computer security topics.

1. Understanding Buffer Overflow
1.1 Stack Buffer Overflows
a) Architecture of Stack OverFlow
Before Stack-Overflow

After Stack-Overflow
b) Program Execution
#include <stdio.h>
int main(int argc, char *argv[])
{
char buf[12];
memcpy(buf, argv[1], strlen(argv[1]));
printf(buf);
}
As stack grows from bottom to top, memory address decreases from high to low
 Buf size: 12 bytes
 Frame pointer 4 bytes
 Return address 4 bytes
 Arguments 4 bytes

1.2 Heap buffer overflow
a)

b) Testing Program
int main(int argc, char *argv[])
{
……
vulnerable(argv[1]);
return 0;
}
int vulnerable(char *buf)
{
HANDLE hp = HeapCreate(0, 0, 0);
HLOCAL chunk = HeapAlloc(hp, 0, 260);
strcpy(chunk, buf); ''' Vulnerability'''

……..
return 0;
}
In the above program, if char buf exceeds its limit i.e. 260 bytes pointer will will be overwritten
by the adjacent boundary tag, result in overwrite of an different memory location with 4 bytes of
data once the heap management routine enters into the scene.
string = cli_malloc(length + 1); ''' Vulnerability'''
if(fread(string, 1, length, fp) != length) {''' Vulnerability'''
free(string);
return -1;
}
The malloc allocates memory depend on the value of length, which is 32 bit integer. Length is
user-controllable and TNEF file can be crafted to set length to ‘-1’, which would result in
malloc( 0 ). Hence malloc would allocate a small heap buffer, which would be 16 bytes on most
32 bit platforms.
2. Exploiting Buffer Overflow
Consider the following C program :
#include <string.h>
#include <stdio.h>
void function2() {
printf(“Execution flow changed\n”);
}

void function1(char *str){
char buffer[5];
strcpy(buffer, str);
}
void main(int argc, char *argv[])
{
function1(argv[1]);
printf(“Executed normally\n”);
}
Above code consist of two functions function1() and function2()
1) main() calls function1 and prints message “Executed normally”.
2) function1() intialises buffer of length 5 and copies string passed by main() into it.
3) function2() prints “Execution flow changed” and is not called from main() or function1().
Our aim here is to call function2() by controlling EIP and hijacking the execution.
Now compile our program using following command.
gcc -g -fno-stack-protector -z execstack -o bufferoverflow overflow.c
-g tells GCC to add extra information for GDB
-fno-stack-protector flag to turn off stack protection mechanism
-z execstack, it makes stack executable.
Run program with command line argument “AAAA” and it will display “Executed normally”
message.
Next step is to try to crash the program with argument “AAAAAAAAAAAAAAAAAAAA”, the
program will crash due to Segmentation fault.

Lets examine the program execution using GDB. Open bufferoverflow binary with GDB. Use
list command to render source code and then add breakpoints on function call, strcpy() and
function exit.
After adding breakpoints run program with argument “AAAA” and analyze ESP and EBP at
each breakpoint and try to find location at which AAAA (0x41414141) is getting stored.
At function call, EBP and ESP are

When you overwrite the return address with As you will get segmentation fault with message
0x41414141 in GDB. This means you successfully overwritten the return address.
“Return address” is just below the EBP in the stack please refer image stack frame layout and
breakpoint3. After figuring out EBP and “return address” on the stack lets try to crash the
program and hijack execution.

Exit of gdb and run the program with payload as the value argument. Here we successfully
exploited stack based overflow vulnerability.
3. JOP
In a JOP-based assault, the aggressor deserts all dependence on the stack for control flow for
device disclosure and affixing, utilizing simply a succession of aberrant hop directions. Since
every single known procedure to safeguard against ROP rely upon its dependence on the stack or
ret, none of them are equipped for distinguishing or protecting against this new approach. Like
ROP, the building squares of JOP are still shortcode successions called devices. Be that as it
may, rather than consummation, each such device closes with an aberrant jmp1. A portion of
these jmp directions are purposefully produced by the compiler. Others are not proposed but
rather present due to the thickness of x86 directions and the practicality of unaligned execution.

Return Oriented Programming (ROP) - A PC security misuses strategy that enables an
aggressor to execute code within the sight of security safeguards, for example, executable space
insurance and code marking. In this system, an aggressor picks up control of the call stack to
capture program control stream and after that executes precisely picked machine direction
groupings that are as of now present in the machine's memory, called "gadgets".[2] Every
contraption ordinarily closes in an arrival guideline and is situated in a subroutine inside the
current program or potentially shared library code. Anchored together, these devices enable an
assailant to perform self-assertive activities on a machine utilizing barriers that foil easier
assaults.manipulate the return destinations in the (writeable) stack in such a way that short
sequences of existing benign instructions before return instructions will be “stapled together”
into a big malicious program.