Inside the stack, this is the temporary, local, and automatic area of the actual memory itself.
The stack is more of a scratch pad for use for the overall system, and it exists only while a
specific function is running. So like earlier we were talking about word.exe, that word.exe is
going to be inside the actual stack itself whenever the program is called upon, and then when it's
done, it gets moved to the heap because it's on its way out. And as soon as the function hits
return at the end of the actual memory call itself, or at the end of the program,
and when I say function, I'm talking about the program that's being executed, the memory is
destroyed and basically gets pushed into the heap. So there are local variables that we can
look at inside of there, and it starts getting into that area of looking into a program through
the hex editor at the assembly level, because you're going to see assembly calls at the most
basic level, no pun intended there, of coding when things are pulled in and out of the memory for
those programs. Yes, you can still pull data out of there, but this is how it's being looked at
by the actual processor. And we also have fixed size arrays of memory inside the actual RAM,
and this is why we have buffer overflows attacks, because once we create a buffer overflow to fill
it up with NOP sleds until the end of time, it goes outside of that actual fixed array.
And you could use something as simple as just creating an infinite loop of NOPs,
or a nested loop for all you programmers out there that want more coding talk.
But this is the classic buffer overflow target, and this is primarily where most of the actual
memory attacks happen at whenever they do exist. So if our, for example, let's say we have a
variable call out of a program for a character that is a username, and that username only has,
let's say, 50 character limit, and you go in and allow 55 to be typed, that five characters is
going to spill over outside the actual fixed size array, causing a buffer overflow. Will it be as
detrimental as something that we create? No, but that's what happens. And usually in programming,
we prevent this by putting in variable checks and balances to make sure that those variables
don't go over what the actual limit is supposed to be. Same with program size, program memory calls,
and all sorts of things like that. And there's also a return address, basically stating inside
the actual program or the program inside of the memory at the time, telling it where to go back to
once the program either needs it or is completed. Because, again, our example is where exe, if we're
going to take up from slot zero all the way up to 100, as an example, the return address is just
saying that the return back to zero in order to rerun the program or perform another function
within that program itself. Again, we're in a very structured environment here when we're inside
the stack, so we're going to see calls going back and forth inside the memory to a pinpoint area
instead of just saying, grab all of it and hope for the best.