Welcome back to Basic Exploit Development, the exploit development process.
Now, there really is not a de facto standard and how exploits are developed.
But we generally agreed on a few key steps one fuzzing to proof of concept creation.
Three, Hijack the execution for bad character analysis.
And five, successful exploitation.
Fuzzing is a process of hurling random data and strings at a listening, vulnerable service to trigger
a crash.
Now we have many open source and commercial buzzers.
These are just a few of them.
File fires, pitch that name.
But the objective is to crash of brain process and analyze the results of the crash through lost but
opportunity to create and to craft a next quick.
So there are three indicators to trashing a application, assessing an opportunity to develop an exploit.
You can overwrite the IP register, extended instruction pointer, you can overwrite the structure exception
handler also known SDH Overwrite or detect access violations are invalid memory addresses.
When you can correctly determined that you can crash an application and also being able to reliably
perform any of the three events above you are now in possession of a proof of concept for possible code
execution.
Let's assume that we actually overall through our proof of concept memory dress where the extended instruction
pointer is located with four hexadecimal A's.
The external instruction pointer basically points to what is next in program execution.
It accepts little and in nice reverse memory addresses by overwriting that valid IPA for hexadecimal
BS.
We validate that we can clearly hijack execution by first sending a known buffer of A's and then clearly
overwriting the IP register for hexadecimal reads.
At this point, you can use the budget floor to look for usable assembly instructions such as jumps
within the debug application itself and then replace the piece of a ballot memory address in little
Indian format.
So bad characters, bad characters.
And the simplest form is basically assembly of codes that are in house decimal that do not properly
render memory in the debug application.
It can basically cause unpredictable execution of commands that will either redirect the exploitation
attempt away from our desired goal or crash and lose your one and only successful exploitation attempt.
So you will invest a significant amount of your time in locating and eliminating these bad characters.
I'm sorry.
My mouth is dry.
So once we successfully hijack execution, eliminate back characters, and 3 minutes to insert valid
show code in the application that we are about to perform a successful exploit.
These could result in spawning a command show, interpreter or Trojan session, as well as gaining a
foothold to offend the target organization's internal network through the initial compromised system.