[Autogenerated] let's look at the main steps that are
required to create the process.
There are actually lots of steps that are involved in creating a
process but I'm only going to focus on the most,
I would say important ones.
So we have some things that have to happen in the
context of the creative process.
The process that caused the creative process API to create a new process or
perhaps one of the other process creation APIs and some of that initialization
happens in the context of this process because at this point the new process
is not yet ready to do any running of any kind of code and then later on some
of the industrialization of the new process has to happen in the context of
that new process.
So let's start with the creative process calling a
function such as create process.
The first thing that has to happen is that the
colonel has to open the image file,
the portable executable file and make sure that it is in
fact valid P file and contains the basic ingredients that
the P file should contain, assuming everything is okay.
It's going to create the kernel objects that manage a process.
This is the executive process object and within the kernel
process object which we'll look at later on in this module and
then it creates the threat object as well because we know that
when the process is created,
the first thread is created with it and that's the threat that
eventually will run the main function of that process.
The one that's coming from the image fight.
So we have an executable thread object and the kernel
thread object that are created as part of this
initialization step and then the image itself,
the executable and Anti Dll are mapped into the address
space of the newly created process.
This is necessary because nobody else can actually do it.
So the image itself is necessary because the data and the code is there
and then Anti Dll has the special role which is in this case called the
loader and its purpose here is to provide some initialization in the
car context of the new process.
So there's nobody else that can make that kind of mapping will see that
later on the other DLS that the process might need are going to be
mapped or at least loaded by Anti Dll itself,
but someone has to map anti Dll and so the Colonel does that explicitly.
So the first thing that we have in terms of mapping in the new process is always
are always the executable and anti Dll assuming we're talking about the process
creation that belongs to the Windows subsystem,
which is the most common case.
I'm not talking about native process creation at this point,
then CSR assess the Windows subsystem process needs to know about
the fact that a new process and have been created.
So,
a message is sent from the creative process to the properties are assessed the
one that belongs to this session and the message is provided there indicating
that the new process and thread has been created.
So at this point from the colonel's perspective,
the process creation has succeeded and the creative process API will
return true or successful status to its color.
However,
at this point some more initialization has to happen as part of the
loader which is part of anti DLL implementation.
So what are the things that are done by entity that at this point?
So one thing is creation of this usable data structure will take a look
at later on this module as well called the process environment block for
the process and the threat environment block for the first threat in the
process we've seen a few details of the threat environment block in the
previous course and then it also performs some extra visualizations which
are needed for code to be able to do stuff such as creating default heap,
which we'll discuss in the future course as well and the thread pool
and some other visualizations that are necessary at this point and
notice this is way before the code in our main function is actually
running so lots of things are actually happening even before our main
function is running.
The next step for anti DLL.
The loader is to locate all the required DLS as they are
listed in the p image all these dependencies that are
needed for execution of the process.
And so the loader here locate all these DLS and described
later on this module where it's actually looking for the
DLS and for each one of them,
it loads them and of course each DLL might have its own dependencies.
So this is a recursive process, so to speak.
So it might need to go into the pes of these other DLS and see what their
dependencies are until all the dependencies are satisfied,
meaning all the DLS have been loaded.
And then the next step is to call the deal main function,
which is the function every DLL can optionally implement that would allow
every DLL to initialize itself in an appropriate way.
If anything fails here,
if a deal is failed to be located or if some DLL returns a
failure status from its DLL main function.
The process will terminate and will not continue with execution,
but assuming everything goes as planned and all the DLS,
the dependencies are loaded correctly and initialized correctly.
Then the entry point coming from the portable executable is going to
be executed and that entry point is usually coming from the sea
runtime it's not really our main function,
it's actually the C runtime and that C runtime is going to call our main
function and then our real code that that we have perhaps written for that
particular executable is actually going to be executed.
So you might be wondering what's the purpose of the c runtime
anyway and I'll explain that later on in this module