Let's begin from where we left off in the previous video, we have compiled the binary and we have disabled
X, Stack, Keniry and Ocilla.
Now let's see how we can crash this application.
There are multiple ways we can simply produce a long input here on the terminal and we can crash the
application.
But what we are going to do is we are going to create a simple point program so we can use it as a template
for the rest of the course.
So let's create a file called Exploit One Dot P.L..
All right, and let's provide the shebang.
And then let's use this particular line with a pipe set to one.
This line forces are flush after every right and print, so the output appears as soon as it's generated
rather than being buffered.
Now let's create a variable called junk and let's give it three hundred is.
All right, and then let's simply print it.
And that's OK, so that's a very simple template that we are going to use throughout the course, right.
So let's save the file and let's also make sure that we give it executable permissions so we can simply
execute it using DOT instead of typing pool space, the filing every time we want to run it.
So I haven't given it executable permissions.
Now, this file should produce 300 days for us when executed.
So let's quickly check it.
There you go.
There are 300 is on my screen, I'm not going to count them for you when I believe you trust your instructor.
Now, let's ride this out, put into a file called Pillar One.
We are going to do this multiple times, so you will get habituated by the time we finish this exploit.
Now, what I'm going to do is I will simply run this vulnerable program and I will pass the contents
of payload one as input to the program.
Let's do that.
Not vulnerable
cat payload one.
There you go.
There is a segmentation fault and it says conduct.
Let's check the current directly by typing ellis'.
And if you notice, in the current directorate there is nothing like a Crashdown.
There are no new files created due to this segmentation fault.
So one interesting thing that we can do here is to enable code dumps so we can understand what caused
the segmentation for it by analyzing the code.
So let's run.
You limit the C and hit enter currently set to zero.
So let's say you limit Dash C unlimited and hit enter once again.
Let's type you limit dash C.
Now it is set to unlimited.
Now once again, if we try to crash the application using the payload we have created, we should observe
a new file.
Dirigo.
There is a new file called Code.
This file is a code dump which gives us the details about the situation of this program and the time
of the crash so we can use this code file to analyze the crash.
It is something like black box for flight crashes, right?
So let me show you how we can analyze the code file using Jilib.
We can type GBE bascule for quite more, so we won't see a lot of outpoured when we are loading a file
using Jilib and Dash code.
And let's specify the name of the file, which is caught in this case, Dirigo.
Now, if you see the output, it says the file code was generated by this command, which is here,
and the segmentation fault is caused by this value.
What it means is this long input has overwritten Oraibi somewhere.
Arop is the register that decides what is the next instruction to be executed.
If you notice, the next instruction to be executed is at this address, which is probably not a valid
address, and that's the reason why the application is crashed.
So, as I mentioned earlier, we can use the code dump to analyze the crash.
We can also type in four registers
to understand what values each register is holding at the time of the crash.
As I mentioned, Oraibi is overwritten with this particular address and that's what is causing the crash.
And there is another interesting thing that's happening here at the time of the crash.
The Army register contains this value.
This is part of the junk that we have used to crash the application.
So this means it is out of our three hundred errors are loaded into our register.
Let's keep that in mind.
It may be useful for us later.
Now, I just wanted to give you a brief idea about condoms.
You can explore further if you are interested, but let's stop talking about condoms here and let's
quit this job.
We will come back to condoms later after completing our first buffer overflow exploit.
So I'm just quoting here now, let us run the program itself in Greevey.
I'm typing glib and slash vulnerable.
And the file is loaded once again.
Now, let's try this as main.
This is the disassembly of the main function.
And if you notice, there is a call to one underscore func.
This is a function inside which we have a vulnerable ECPA function, if you remember.
So let's quickly double check that.
So I'm typing this as one underscore func D'Arrigo.
We have a call to SDR S.P.I at PLB.
We will discuss more details about procedure linkage, Jabel or Paldi and later in this course.
But for now, just remember that there is a call to start CPA function inside.
This one underscored Funt function.
Now let's run the program by passing the contents of Paillard one as input.
If you remember, we have loaded the vulnerable program in GDP, but we haven't run it.
So I'm just clearing the screen and let's just type A run and get payload one.
Let's get into.
Look at that, if you notice this, there is a segmentation fight once again, and if you notice the
output, Jeff is showing us all this beautiful output.
If you're not using Jeff and if you are just using plain G.V., you will have to type a lot of different
commands to see all these things.
For example, you are seeing the registers here without Jeff.
If you want to see the information of the registers, you will have to type in four registers playing
Jollibee.
But Jeff shows you many interesting details with every command you run.
If you look at this, this is the state of registers and this is the stack and these are the instructions
that are being executed.
Now, if you look at the output, this is the same as what we have already seen within the code dump.
It is have overwritten r b register, but we have passed 300 s and we don't know which eight are among
those 300 s overwriting r, b, b register.
We want to be able to find that if we can find out that offset of which eight is actually overriding
the R B to register, we will be able to find out the offset to all right.
IP register that will in turn help us to reletting the program, flow to some code that is written by
us.
Now, it may sound a little confusing, but by the time we finish this exploit, it will be clear.
Right.
So that's all for this video.
In the next video, we're going to find the offset of how many s are needed to override IBP as well
as our IP registers.