[Autogenerated] The last topic,
IDE like to discuss in this module is user and G D I objects.
So the common object we discussed so far.
In fact,
are the primary objects we use in Windows are the possibility of the
object manager they have these reference counting,
and handles, per plus all the stuff we discussed already.
However, there, are also these user and graphics objects,
which are managed by win 32 K, dot CSS which we know is the Windows subsystem,
kernel mode component,
which is tasked with handling all the user interface in
Windows including the graphics device interface,
which is the original graphics,
API in Windows which is still very much supported.
So I'd like to Discuss how these objects.
Are being managed.
And compare that to how kernel objects,
are being managed in terms of APIs the APIs themselves don't go through ant,
DLL ant,
DLL is only about the kernel APIs that deal directly with the
kernel and not with user interface stuff.
Instead, there's a different DLL called win 32 U,
dot DLL L which serves the same purpose as ant,
DLL for the user mode sorry, the user interface,
and G D I APIs For example, the create window E X,
API I goes through win 32 U, that would call the anti user create window,
API I which is the actual system, call to create a window.
Let's discuss user objects, first what are user objects.
Anyway, we have Windows these are these rectangular objects we're familiar with.
We have menus which are also kind of specialized Windows In fact,
and there's also hooks, and the hooks.
I'm referring to here, are the hooks available built by the API set,
Windows HS, to inject, DLL into other processes,
that also are using some kind of user interface.
They have user 32 dot DLL loaded,
and this is typically used for cases where you want to intercept,
Windows messages, and stuff like that So,
these kinds of handles, are private, to a Windows station.
So they're not private to a process as kernel handles,
are kernel object handles,
are which means that If I want to give another process.
A handle, to window.
I created I can Just give it that handle value, and that is It, there's no need.
To duplicate or anything like that In fact, that's not even supported.
And these handler have the namespace inside the Windows station.
So these handles, can be passed freely between processes.
That are assigned to the same Windows station,
Windows stations, are also part of sessions,
which means that for different sessions.
Windows handles cannot be shared.
They might have the same value.
And they mean different things.
So it's not the process which is the one that provides the privacy for handles.
But in fact, a larger object called the Windows station.
So you can pass these handles along to other processes freely
assuming they're part of the same Windows station.
There's also no handle reference counting at all,
which means that If I pass a handle, to a window,
for example, to another process,
and then Later on I'll call the store window function with my handle,
that window, is destroyed immediately.
And the other process holding onto that handle now holds a garbage handle,
and that handle will not be serving its purpose.
So there's no reference counting associated with user objects at all.
What about GDI objects, GDI objects, are objects related,
to graphical work, these are the classic objects,
that Windows supported from day one such as a device,
context a pen, a brush, a bit map, a palette,
and some other objects of that kind, these kinds of handles.
Are always private to a process, and In fact,
there's no reference counting there.
And no way.
To share them with other processes.
They're always private, to a process, and that is It.
So if I would like to share, a handle, to a brush,
say with another process I can't the only thing,
I can do is to provide the other process the logical
properties of the brush such as its color and let that
other process create its own brush.
That has the same logical properties,
but we can't just pass the handle in any kind of way GDI object handles.
Are kind of weird because they have very severe limits
even in today's Windows for example, only two to the 16th,
power objects,
can be created per session which is not a very small
number but not a very big one.
Either.
In fact, you can have a malicious process,
try to create many many of these GDI objects,
and that would affect other processes as well which is counter,
to the normal way of,
of working in Windows where one process has no effect on another process.
But in this case,
it does and at least it might and There's also a limit which is 10,000 objects,
per process, which can be lifted, in the registry.
However, you can't go beyond 65 65536.
it's a Very weird limit.
It's probably there for, I would say legacy reasons or compatibility reasons,
but really should be lifted because its possible to have a denial of
service kind of attack When you have multiple processes creating GDI
objects as many as it can possibly create and that might be delete
the number of objects can create in a session which might cause
certain processes.
To misbehave such as task manager,
cross explore which use lots of G D I objects at least something we
can see in task manager which I'll demonstrate next.