Information Technology Reference
In-Depth Information
defined above, is a finite-state
GSR
expression. Since
P
always contains relation rule
for
S
when detecting a
GSR
, the set of final states
F
contains
S
, such that
{}
F
=
S
,
T
. Therefore, the finite-state machine can be constructed for
GSR
detection purposes, so that all replication combination that are accepted by the
automata are, in fact, in the state space of a phrase-structure language defined as
)
L
(
G
. This language is to be generated by the
GSR
grammar in the following way:
{
}
(4)
L
(
G
)
=
x
|
x
∈
V
S
⎯
⎯→
x
, such that
,
G
S
⎯
⎯→
x
implies that
x
is
directly derived by another building block
S
, such that both
x
and
S
follow the
rule
P
by yielding
Where,
x
is a replication building block, and
G
S
=
ω
αω
x
=
ω
βω
α →
β
and
, where
by the
1
2
1
2
definition of
P
.
A complex computer operating system such as Microsoft Windows XP receives
hundreds of calls every second from many different processes. Most of the function
calls, produced by an application in
user mode
deal with secure objects and hardware
resources such as File System, Processes and Threads, Graphical System Services,
System Registry, etc., are transferred into the Kernel mode of the operating system for
further execution in secure environment. During this process, function calls are
processed into system calls for unification, compatibility, security and other reasons.
At the Kernel level, system calls are processed by System Service Dispatcher (SSD)
and routed to a designated service. The internal structure of system call dispatching is
even more complex and is not a subject of this paper.
The Operating System in question provides us with almost no support for
monitoring its Kernel level for security reasons; therefore such a software monitor has
to be created. While it is not a trivial task, as it requires very low-level system design
and implementation, the very basic idea for the monitor is shown in figure 3.
When Kernel receives a function call from user mode, it has to decide which
Kernel interface to call to process this function. The API Processing Unit also known
as System Service Dispatcher (KiSystemService) is responsible for making this
decision by looking up an appropriate system call handler in its System Service Table
(SST), which stores handlers to every system call supported by the Kernel, and
invoking it. However, if the handler to a particular system call in SST is replaced with
a fake one pointing to other memory location, System Service Dispatcher will simply
execute a different function at that location. This extra function can be designed to
gather information about the system call, its parameters and the origin. When all
needed information is collected, the function calls the original system call and the
entire system proceeds as usual.
All system calls, once invoked at the Kernel level, are expected to produce a result,
whether it was successful or not. This result is represented by the output arguments of
the system call, as well as the return value that confirms successful execution, or
indicates errors. All system calls, intercepted by the monitor, appear in two parts:
system call with input arguments and system call with output arguments.
