[Autogenerated] let's start by launching the Colonel debugger going to
launch a local current debugging session some running win debug with
the mean privileges and then selecting, connect to Colonel,
which we have already done in the previous course And now we get some basic
output in the current debugger as we've seen already.
Now one of the commands I've shown you already in a
foundation scores was processed 00 which simply shows the
list of processes in the system.
So that's nice but it didn't really explain what the meaning
of all these um parameters to process 00.
What are the other possible options?
So the first parameter to process this is indicating
which process I'm interested in, where zero indicates all available processes.
The second number is a detailed level where zero
means the least amount of detail.
So we have these bits which we can specify to add more and more details.
So for instance if I'm only interested in this particular process,
I can grab the address of that process.
That's in fact the address of the process,
data structure and just give it to the process command.
Once they do that we get the basic four lines here for this particular process.
This is the process running the wind Logan image you can
see here is the process data structures.
In fact this is its address and we can dig into that which
we'll do very soon by using the normal D.
T and other commands you can see the session A.
D the process ID.
That's the process of the we see in task manager process Explorer.
We can see the process environment block, which is kind of tricky.
Which I'll show you the moment what I mean by that and
then there's the parent client idea.
So that's the parent process for this process.
That was is it's IDE The process may or may not exist at this point.
The debugger doesn't really care if you press that link,
you'll get information about this process whether that exists or not.
Even if it exists, it might not be the real parents.
So you have to be careful there a little bit we have the
directory base which is a physical address that is used for the
future to physical translation of addresses,
something we'll discuss in the future.
Course there's a handle table for the process which is pointed to
by this address here and the current number of handles in the
table and of course the image name.
If I go ahead and add or change the value here to a
larger value such as the one.
The first bit is being turned on here.
I'll get more details.
I'm going to get the four first four lines but then I have some extra
details here such as a pointer to something called the mutual arteries
descriptors which we'll discuss in the future course,
the process primary access token, the elapsed time,
the time that uh that the process was alive.
The actual time it was running and using more than caramel
and some other memory related um counters.
So this happened when I added one here.
If I change that to three, so add one and two.
Then we get even more details.
We get a summary of all the threads in this process and some
of the basic parameters of the threads.
So for example we see here the address of each thread and each thread is
actually managed by a data structure called the thread.
Executive threat, something we'll discuss in the future course as well.
We have the client I.
D.
Which is the process I.
D.
And thread IDE There is a threat environment block which we met already in the
previous course and there are some other details here which I won't get into at
this point because this is related to threats.
We can see the thread state here as being a waiting state
and this is the way to reason that we briefly mentioned in
the foundations course as well.
And then because the threat is in a waiting state,
it's waiting on something and you see here exactly what that something is.
So this thread is waiting on the synchronization event object,
something will will discuss in the future course as well.
Same idea here, this is another thread waiting on the semaphore.
This one is waiting on the queue object and so on.
If I continue that route by adding another bit in
this case it will be 712 and four.
Then we'll get even more details about each and every threat,
not just the summary of its main characteristics,
but also more properties such as its stack size,
beginning and end of the stack, the priority of the thread,
the times it was running in user mode and kernel and things like that.
Eventually we even see a cold stack of each thread
assuming the stack is in physical memory.
So you can see this says the kernel stack is not resident,
so we don't see the current stack here.
But then for this threat we do see the kernel stack And you also know that we
also see something here which resembles using with address.
Indeed this is a small address,
relatively small address in the lower 128 terabytes of memory.
So this is definitely in user space but we don't see any symbols and
explain why that is very soon and we'll see how to fix it.
So essentially the meaning of the process command is to give us a high level
overview of the process and its threats based on the amount of detail would
like to look at and this is the meaning of process.
But um we can dig deeper if we wanted to by looking at the actual
process data structure but before we do that,
let's open a Notepad here and attached to it using a user mode debugger
let me launch another instance of windy bug here and use attached to
process to attach to this Notepad instantiate and we see the usual stuff
we've seen already in previous demos.
But now let me look at the process environment block by using the P.
B command.
This is the user more data structure that contains
information that is interesting, especially for user mode colors.
So essentially why do we have the P.
B.
I mean the process in the kernel has everything and
it's the real or the source of truth, so to speak.
However,
in user mode hanging onto the PB is useful because it provides an optimization.
It's faster to access the PB from user mode client talking to its own PB
without the need to have a user to Colonel transition.
And some of the information here is not really very interesting for
the Colonel and doesn't even care if the process gets um food
because things might have changed here.
So you can see stuff here such as the list of modules in the process.
And it's possible by doing some clever coding to hide the DLL by removing it
from the list because there is a link list behind the scenes.
In fact the same link list time that is used to manage processes.
It's actually used everywhere in Windows in kernel space and
buy things managed by anti DLL in user space.
So this is possible to uh to hide this deal and so certain enumeration
functions will not be seeing that dealer anymore.
Another example here is the fact that this process is currently being debugged
and this is something that is also something we can change.
We can change by making changes to memory and I believe I've already
demonstrated that previously in the previous course.
But let's see that once again.
So the PBS in this address, I can grab this address,
look at the real data structure that has the name underscore PB Now you can see
the true data structure and with this true data structure.
Beat number sorry,
bite number two here is this being the bug thing
which currently has the value of one.
So you can use the edit command or edit family of commands and I'm
going to select e B here for edit in chunks of bytes and add to
here and just grab and put zero here.
So if I use the PB command again then we'll see that In fact the
process is being reported as not being debugged anymore and
certainly APIs such as these debugger President will actually look
at the P B and will not bother going to the current to ask whether
the process is being debugged.
So you can perhaps full malicious code or something is running this
process into thinking that it's not being debugged.
And so there are other ways of making that check and dote and that
other way or other ways to go into the kernel.
So the colonel knows the real truth,
but sometimes you might be able to fool certain pieces
of coal by making changes to the P B.
And so we're talking here about this Notepad process.
Let's go back to our kernel debugger and locate the Notepad process.
And one of the features of the process command is that it's able to
search based on executable name by providing executable name as yet
another parameter to the command.
So it's going to show me the the summary details for the Notepad process.
Maybe there will be more than one,
but in this case I expect only want to exist in the system because I've
only created one note that is that I'm aware of And so we'll be able to
see the process environment block as well in user space there's no point
in using an address for the PB.
So obviously going back to using mode debugger for a moment,
I know the PB is here so it's definitely possible to just write PB
and provide this address that would work just fine.
But because the P b is just a single tone in the process it's
kind of redundant providing the address.
So let me go back again to the Colonel the Colonel.
debugger you notice that in fact it found Notepad here and we can
see the process environment block right here.
In fact notice it's exactly the same address as we've seen user space
obviously it has to be the same because it is the same process.
I'm looking at my running system right now the freeze count
here is shown as one because it's currently at the breakpoint
by using more debugger But anyway,
what happens if I try to use the same PB command here in
the kernel debugger if I try that, this is what I get,
I get a weird looking error saying hey something is wrong here,
something just doesn't seem right.
So the PB command is a high level command that examines its parameter and makes
sure it makes sense and so it makes sure that this is really something that
points to a PB and not some random piece of memory.
So what does this fail?
You might want to pause the video here and think about that,
why did this command fail where it succeeded just fine in
our user mode debugger So here's the thing because we're in
kernel debugging mode right now,
we have a holistic view of the entire system which means that colonel
addresses are absolute and always valid but using mode addresses
depends on the particular process in which process do I mean because
every process has this address, so in which process I'm looking at and the,
the answer is that the debugger has the current process
and that current process is not um, this noted process.
In fact it doesn't happen to be that process and I would be
very lucky if that was exactly that process.
In fact default process is the buggers process itself and so that is
not bound to work because it accesses the current process address
space and looks at that address which may not even be mapped to
anywhere and that's why we have this link here in the P b notice what
it does if I click that,
it seems to work just fine and it does work fine but the command is slightly
different than the user mode command notice what we have here,
we have actually two command here.
The second one is indeed using the bank PB command with the same address,
but the first one first changes the context of the
process to the processing question.
So it tells the debugger using the dot process command
not bank process but dot process.
This is a meta command that says that debugger hey,
this process is the one to use for using with address
translation from this point on until further notice.
So the semicolon is just a way to to run multiple commands on the same line.
You can definitely do that on two separate lines by using two separate commands.
And so this is going to be the current process from the
buggers process in this current debugging session at this
point until we change that once again.
So this dot process slash p with the process address is necessary
and this is why all the PBS we've seen here have these links and
these links are not just by accident,
they're the ones that actually being used in order to switch the
correct process and then use the PB command with the appropriate
address and that is bound to succeed.
So this is also the reason why we didn't see the call stack for win Logan.
So for win Logan we might want to see the call stack in user space
as well as space is never a problem because all addresses are
absolute but user space might be a problem.
And so we need to first switch the correct process.
I'm going to grab the process for this.
Well Logan process and use the dot process command slash p.
And switch to that process.
I can even adhere slash are in order to reload user mode
symbols which is necessary because the debugger doesn't
load user mode symbols by default.
We can also do that later on by using the dot reload slash user command.
If I go back to my command here for listing the
information about this win logon process.
I'm just going to do process with that same address.
We should be able to see the call stack for that thread
assuming the stack is still resident.
We should be able to see the user mode call stack as well.
You can see that symbols are being downloaded while we're doing that because
symbols for win Logan are are actually shown at this point.
So we'll take a few more seconds for these symbols to download.
And you should you should be able to see using with stack, which we do.
You notice here?
We have a TPP worker thread function which already familiar with as the
startup function for the thread pool in user space.
And this is calling the system call Auntie,
wait for work worker factory, which is waiting for work.
And so this is why this thread is where it is right now,
waiting right now for a queue object,
which is the way thread pools are actually
implemented within the Windows kernel.
In the next clip, we'll dig deeper into the process and data structure.