Hey everybody.
Welcome to another memory video.
In this particular one we're going to be talking about the stack.
So a general idea of how you can look at the stack.
Is this.
So we have the lowest memory addresses at the bottom and at the very bottom we have our tech section
which is our code segment where all the code data is and we have our initialized data so so variables
that we have already initialize instead of value to our own initialized data then we have the heap which
we'll be talking about the next video and then we had some slack space in between.
So that this is like the stack in the heat kind of share that section.
Then we have the stack itself which we're going to talk about in this video and then the high the high
level addresses.
So understanding where the stack is in this flow when an application is created you're going to see
this structure get built in it's own memory region.
Now what is the stack.
It is a special place a memory that holds temporary data.
It's a FIFO type data structure.
So it's a first in first out.
So when you when you push something onto the stack and you push something else onto the stack you can't
get that that second one down without taking off the first one and then taking off the next one.
So it's important to understand that that's how it works because you can't just reach in and grab five
things deep into the stack that messes up the whole stack structure and it won't let you do it.
So this can hold anything from assembly instructions or OPP codes to text to just random digits or values
you can push anything you want onto the stack you can push whole registers onto the stack understanding
you can put anything there.
And this was why I was talking about GSP was being so important so understanding where the top of that
stack is you know where to start pulling from.
So if you know the top ESB points to this particular memory address you know that if I pop two things
off the stack I can now grab the data that I wanted to and you can't find that data without knowing
what the ESB was supposed to be pointing to to be able to know where that Stack was.
Now the functions of this is that is the core stack that's being built when the application is ran.
So it generates that when an application is built.
So the data the fold out of the structure the heap for the application.
So when an application calls a function it create in and you create local variables so you programmers
out there or developers will know what I'm talking about.
So when you when you're creating a main application and you call a separate function and create some
variables there to do some data manipulation do whatever you need to do and then you return the function.
So whether you return data or something it doesn't matter.
The reason local variables get blown out and remove is because when the stat when it returns the main
function and the main application saved what GSP was before it before it sent off to that particular
function and because of that it will just pop everything off the stack into random places and delete
it until it gets back to the proper alignment of the stack before the function was called.
So that's why the variables vanish after you've already created them inside of a function just a little
tidbit for the programmers out there or anybody who's done any coding.
The reason that's the reason why local variables inside of functions don't actually get saved outside
of it.
Now Indian this we're going to be talking about a little Indian in detail but understanding big Indian
as well so big Indian is the highest address first goes into the stack.
Little Indian is the lowest.
So if we look back here we see the highest addresses at the top and the lowest is at the bottom.
This is little Indian.
Now reverse this and you have big Indian most operating systems will use little Indian now when working
with memory or working with applications at the memory level or instruction level you need to understand
little Indian in that it is very important.
So everything is backwards in an op or in memory when it's inside of an operating system.
So for example Red Team nation.
Right here.
This is its hex standard.
So this is just you know dumping that converting it to hex.
This is what it would be if I dumped this into an application and had it printed out it would print
the exclamation point first then the end then the O then the I T so I would print it in a reverse order
because it's expecting the data to already be reversed.
So what you would do is you would go here.
So twenty one is first.
0 6 is the next 0 6 9 is next 0 7 4 etc..
Understand that.
Because when you start working with exploits and you start injecting hex or OP codes directly into an
application because you're working on an exploit or whatever the case might be you have to be able to
flip those around.
More specifically when you're when you have hex code referring to memory addresses they have to be reversed
for a little Indian.
Otherwise it's not it's going to point to some random place a memory that you're not going to have any
control over might be right.
It might be right protected.
It might not be executable.
It might not even be a memory address.
So just be aware that little Indian is an important aspect when you start working with the low level
structures for OP codes and memory.