Professional Documents
Culture Documents
EH Project Report
EH Project Report
By,
Nitin Chandra (17100030)
M Krishna Chaitanya (17100026)
C Tarun Sai (17101015)
Department of CSE
Dr. Shyama Prasad Mukherjee
International Institute of Information Technology, Naya Raipur (A
Joint Initiative of Govt. of Chhattisgarh and NTPC) Email:
iiitnr@iiitnr.ac.in, Tel: (0771) 2474040, Web: www.iiitnr.ac.in
CERTIFICATE
This is to certify that the project titled “BUFFER OVERFLOW ATTACK TO
CONTROL VARIABLES ON STACK” by “NITIN CHANDRA, M KRISHNA
CHAITANYA, C TARUN SAI” has been carried out under my/our supervision and
that this work has not been submitted elsewhere for a degree/diploma.
December, 2020
DECLARATION
I declare that this written submission represents my ideas in my own words and where
others' ideas or words have been included, I have adequately cited and referenced the
original sources. I also declare that I have adhered to all principles of academic
honesty and integrity and have not misrepresented or fabricated or falsified any
idea/data/fact/source in my submission. I understand that any violation of the above
will be cause for disciplinary action by the Institute and can also evoke penal action
from the sources which have thus not been properly cited or from whom proper
permission has not been taken when needed.
Signature: ___________________
Nitin Chandra
(17100030)
Signature: ___________________
M Krishna Chaitanya
(17100026)
Signature: ___________________
C Tarun Sai
(17101015)
Approval Sheet
Signature: ________________________
Dr. Appala Naidu
Uninitialized Data: 7 4. Stack: 7 5. Heap: 7 1.2 Buffer Overflow: 7 1.3 Buffer Overflow Attacks: 8
ABSTRACT
Buffer overflow attacks have been the most common attacks from the past 10
years. With the help of these attacks, an anonymous attacker can gain either the
total or partial control over the program. Attackers can do many malicious
things with the help of buffer overflow attacks like Code Injection, Control the
variables on stack, Function calls etc. In this project, we will be focusing mainly
on how an attacker can control the variables of stack with the help of buffer
overflow attack by some examples and also the possible ways to control these
types of attacks. If these types of vulnerabilities could be eliminated, then a
large portion of the serious threats would also be eliminated.
CHAPTER 1
INTRODUCTION
LITERATURE SURVEY
2. Disassembler:
Disassembler is a tool, which is used for reverse engineering the
programs. It generally displays the instructions in low level language (machine-
level). We used Cutter Disassembler, in order to perform the reverse
engineering.
Fig
3.3: Figure shows the example Graph of the Reverse Engineered Program.
For additional help in understanding the exact meaning of the code, we could
also use a decompiler and strings that appear in the code. These features are
readily available in Cutter.
3. Debugger:
At this stage, we will be using the GDB-PEDA debugger, in order to understand
the step wise low level language (assembly language) operations that are
happening while the program is under execution. By using the debugger we can
identify whether the variables present on the stack are getting affected by the
overflow attack or not.
Fig 3.4: The above figure shows the sample output of GDB-PEDA, It shows the
register values in the register section, Upcoming instructions in code section and
Stack content in the stack section.
4. Exploit:
At this stage, we will be sending the desired value as extra space (main cause
for the overflow) and the value present at the top of the current value in the
stack will be overwritten by this extra space. If the value of the variable is
changed then the sample program outputs “Cracked”, else the output will be
“Try Again”.
Fig 3.5: The above figure shows the output, when the overflow doesn’t happen
and the value of the variable isn’t changed.
Fig 3.6: The above figure shows the output, when the overflow happens and the
value of the variable is changed.
CHAPTER 4
IMPLEMENTATION
Fig 4.1: Showing the randomly generated test cases using Radamsa tool.
The above figure shows the randomly generated test cases using Radamsa
Fuzzer. The program is cracked for some of the above inputs, where the length
of the string is greater than 64. Hence from this step we can say that this
program can be cracked using the Buffer overflow attack.
b. Dissassembler
Fig 4.2 : Dashboard for 1st object file
This is the Dashboard for the 1st object file in Cutter. It shows that it is an ELF-
32 bit file. It uses the x86 architecture instruction set. It runs on a Linux
machine. It has been compiled by a Ubuntu compiler (gcc). It has also guessed
that the programming language used might be C.
Fig 4.9 :
Output when
the program is cracked.
The above program changes the modified variable value. The above figure
shows the output as “Cracked”, as the modified variable value is changed. Here
the input given is 64 times “a” + “bcde”. Hence the modified value becomes the
decimal ascii values of (“edcb”), as the modified variable is an integer variable.
2. Analysis of 2nd ELF file :
a. Fuzzing
Fig 4.10: Showing the randomly generated test cases using Radamsa tool.
The above figure shows the randomly generated test cases using Radamsa
Fuzzer. The program is cracked for some of the above inputs, where the length
of the string is greater than 64. Hence from this step we can say that this
program can be cracked using the Buffer overflow attack.
b. Dissassembler
Fig 4.11 : Dashboard for 2st object file
This is the Dashboard for the 2nd object file in Cutter. It shows that it is an ELF-
32 bit file. It uses the x86 architecture instruction set. It runs on a Linux
machine. It has been compiled by a Ubuntu compiler (gcc). It has also guessed
that the programming language used might be C.
Fig 4.12 : Flow control for 2nd object file
This is a graph which shows the control flow of the 2nd executable file. Initially,
it checks if arguments are present or not. If arguments are not present then some
string is printed. Then an integer variable is initialized to zero and a buffer is
filled with the string argument. The integer variable is compared with
0x61626364 and if they are equal, some string is printed. Else some other string
is printed.
c. Debugger
d. Exploit
Fig 4.18 : Output when
the program is not
cracked.
The program runs
smoothly if we give
64 times “a” as
input. The value of
the variable
(modified) will not
be changed. The
above figure shows
the output of the
program, when 64
times “a” is given as
input to the program.
The above figure shows the randomly generated test cases using Radamsa
Fuzzer. The program is cracked for some of the above inputs, where the length
of the string is greater than 64. Hence from this step we can say that this
program can be cracked using the Buffer overflow attack.
b. Dissassembler
d. Exploit
From the above, we can conclude that attackers can easily gain the control over
variables that are present on the stack. Apart from modifying variables,
attackers can do a variety of tasks through buffer overflow attack. They can
access private information, change the flow control of the program and also the
most dangerous task of running a program of attacker’s choice.
In order to prevent these kinds of attacks, various defense mechanisms can be
used.
1. Primarily good and safe programming techniques should be used such as
input data validation
2. Good choice of safe programming languages should be made 3. Features
of OS and compilers which provide security against buffer overflow attacks
such as Stack canaries, Non-executable data, Address space layout
randomization (ASLR), Control flow Integrity etc., are to be used.
CHAPTER 6
REFERENCES