Everybody and welcome to the video on the colonel.
Now this is gonna be a quick video to kind of get you an idea of what the colonel is the structure around
it how it's architected and why it's important to the operating system.
Now what is a colonel.
It is the main core of the system.
So this is what runs everything on the system whether it's a users process or device driver fit you
know physically manipulating memory on the stick inside of the machine and everything in between.
So this is the core application that kind of runs everything.
This is written in C with assembly.
Now we're going to go over assembly and in its own course.
However know that C is a compiled language that is pretty low level and you can interact with assembly
and hardware directly with C and assembly.
Now there are two different spaces inside of a colonel.
There is Colonel space and user space and we will go over that now.
So Colonel space this is a protected state.
This so this is also protected space as well.
This means that everything from memory hardware core services inside of the kernel such as writing the
physical hardware or presenting data all of that is identified and protected inside of kernel space.
Now users can read data however they have to go through kernel space to do it.
There's very little restrictions once you are inside of this space.
Now there are a lot of precautions and measures put in place to help you not be able to just reach into
kernel space but it does happen occasionally where there's privilege escalation exploits that allow
it to a user to go from user space to kernel space without any without any issues such as one system
call it doesn't do the correct protection filtering and just runs kernel space has full access to all
hardware memory and even protected memory space which is dedicated for just the kernel accessing that
type of data and modifying it when it's not meant to be can immediately crash the machine and cause
it to reboot user space.
Now this is most commonly used for applications.
So when you load up Microsoft Office or anything like that you are in user space when you interact with
a system call such as to reach the kernel you have to use something called CIS calls which is similar
to the wind API stuff that we looked at earlier.
Now CIS calls reach into kernel space depending on what they're trying to do.
Sometimes the CIS calls reach into a service called interface that then reaches into the kernel which
will go over and a little bit so but understanding the difference between user space and kernel space
is important to knowing what context your application is being ran.
So the kernel has something called a stack so the kernel stack is a set of software and hardware that
allow it to perform its day to day functions.
Now the top of the stack we have a cis call interface.
So we have the where the applet user applications call into the kernel to read to read read files or
perform some sort of networking aspect that they need to do then there's memory and process management
where they handle all the processes.
Then we've got the network stack which will go over a little bit later then there's a virtual file system
that sits over top of the physical one and then we have all of the devices such as the keyboard the
hard drive etc..
Now we have architecture dependent code which are all over minute.
Now the systems this this call interface is a layer of abstraction between the hardware and user space.
So for example trying to read a file you don't want to have the user have to manage how to interact
with the hardware which could be different every time.
Because keep in mind that one type of hard drive is not the same as another.
Nowadays it's pretty pretty similar they tend to use the same architecture when it comes to reading
and writing.
However in the past that wasn't always the case so this type of interface was good to have and it's
always going to be there.
So this also allows the user to make those calls without needing to reach directly in the kernel space
which is which is important.
This also provides some sort of standard across the board so that all applications hit the same system
call rather than having five different versions of the same system call because one application wants
to do it slightly differently.
This is again for a security aspect as well as well as just a code management aspect would be uncontainable
to a developer to have to handle.
However many other people want to write into a certain Siskel and then have they want to do it how they
want to do it now memory and process management.
This is what handles all the processes on the system and manage all the memory.
Now when it comes to memory this handles the virtual and physical which will go over the difference
in its own mini course after this.
But understand that this particular set of the stack everything to do with processes everything to do
with memory is done here.
Now we have the network stack and this controls how the machine interfaces with the actual physical
hardware.
So the wire coming out of the back of the machine.
That's the physical hardware.
Now the entire network stack is the application layer where your user application is and then we've
got the TCB IP and Ethernet layer which is like building up the packets which will have a whole video
on that as well.
The driver to interface with the particular network card or Nic.
And then we also have of course the NIC.
And then we've got the physical medium.
So this is whether it's Ethernet again if it's a fiber optic no matter what the type of medium is it
needs to be able to interface with that.
Now we've got the Virtual File System now the virtual file system is used as an abstraction layer between
the direct hardware like we talked about.
Now this is useful to avoid memory corrupt or not memory problems but any corruptions on the disk any
issues because everything is done in a uniform way and it can use its own file system so if we try to
do this a different way it would have to each application would have to know how to store something
and how to retrieve it.
But with the virtual file system we can then tell it does save this file and let the virtual file system
handle sorting everything putting it into the blocks.
All of that next we have the devices which is the most of the kernel code.
This is what interacts directly with the hardware.
Now the hardware can vary depending on the system which is why this there is so much of this code because
again one device might be different from another.
We have standards now but there's still times where a hard hardware might react differently than the
other one on the opposite competitor.
Now all this calls and kernel operations will will end up going to a driver at some point.
And that's important to understand.
So when you see on windows you see all those DL levels that we had.
Those are the drivers.
So Windows still has a kernel as well.
It's not just Linux that has the kernel Windows has a more modified version specifically and proprietary
to itself while Linux the one we're talking about right now is more open source but it's still important
to understand that drivers are required to interface with hardware and that's what it needs to go through
the last bit is we have the architecture dependent code.
Now this is for example when the CPSU is 64 bit or 32 bit which will over in the next video it needs
to understand how to communicate with it how to communicate with all of the hardware on the system that
it's being installed on which is normally why you can't flip flop a lot of internal hardware in the
past you can now because it just loads all of the code at once but it's important to understand that
every install you do for an operating system it's going to put architecture specific code on that system
based on what you have installed at that point in time.
Now one more thing I mentioned about this part the drivers arm take up majority of the architecture
dependent code that is going to be the real difference of the drivers and architecture the kind of code
tend to be one in one but there is some differences that can happen between the two.
Now the last part I won't talk about is the local kernel module so these are called the L cams.
What they do is they allow you to add kernel code to the system without having to update recompile rebuild
it update the kernel itself and then restart the system you can load these bits of code in and out of
the kernel while it's still running without having to deal with anything.
Now keep in mind this provides full access to the kernel and that's important to understand because
you can use this as a red timer to create your own LJM.
That's that you can use as a rootkit to hide the persistence that you have.
So if it's a reverse shell whether it's know creating user every single time it starts up locking up
and opening up a socket for somebody to connect to.
So whatever the case might be if you have kernel level access you can tell it to not show up.
So when you run commands like net stack you can have it not show the port that's opened.
If you have kernel level access which is what you can do here we'll have an entire video on how to do
AMS with root kits to kind of hide the persistence.
But I just want you to understand that it's the reason why it's there.
So this is going to be the end of the video for the kernel.
There are there's a lot more to talk about and the kernel again could be its own course on its own.
So if you guys have any questions feel free to jump over to the Facebook group past that point.
Feel free to touch on different topics look up different aspects of the kernel like look up the M and
find out exactly how it works interfacing with the kernel itself.
It's always good to know how things work under the hood so you can better protect yourself and your
organization and know how what ways attackers could use to exploit that.