IE85287B1 - Method for preventing malicious software from execution within a computer system - Google Patents
Method for preventing malicious software from execution within a computer systemInfo
- Publication number
- IE85287B1 IE85287B1 IE2008/0383A IE20080383A IE85287B1 IE 85287 B1 IE85287 B1 IE 85287B1 IE 2008/0383 A IE2008/0383 A IE 2008/0383A IE 20080383 A IE20080383 A IE 20080383A IE 85287 B1 IE85287 B1 IE 85287B1
- Authority
- IE
- Ireland
- Prior art keywords
- computer system
- application program
- execution
- cross
- malicious software
- Prior art date
Links
- 238000000034 method Methods 0.000 description 8
- 241000700605 Viruses Species 0.000 description 7
- 230000000903 blocking Effects 0.000 description 5
- 238000009434 installation Methods 0.000 description 5
- 230000001131 transforming Effects 0.000 description 4
- 230000006399 behavior Effects 0.000 description 3
- 238000001514 detection method Methods 0.000 description 3
- 238000007906 compression Methods 0.000 description 1
- 230000001010 compromised Effects 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 238000002955 isolation Methods 0.000 description 1
Abstract
ABSTRACT Method for preventing malicious software from execution within a computer system A method for preventing malicious software from execution within a computer system is disclosed. Before any actual execution of an application program on a computer system, the application program is cross-compiled to yield a set of cross-compiled code of the application program. The set of cross-compiled code of the application program can then be executed in an execution module that is capable of recognizing and translating the set of cross-compiled code of the application program to the actual machine code of the processor.
Description
METHOD FOR PREVENTING MALICIOUS SOFTWARE FROM EXECUTION
WITHIN A COMPUTER SYSTEM
The present invention relates to avoiding malicious software
in general, and, in particular. to a method for preventing
malicious software from execution within a computer system.
Malicious software, such as computer viruses, can enter a
computer system in many ways. For example, they can enter
a computer system via a disk that is to be inserted into
the computer system or they can enter the computer system
via an email that is to be opened by a user of the computer
system. Malicious software can cause problems to the
computer system: if they are executed within the computer
system. For example, computer security may be compromised or
files within the computer system may be destroyed.
Certain types of malicious software can easily be
detected using simple detection techniques, such as
scanning for a search string. However, this type of
detection process can also easily be subverted by
converting malicious code via compression or
encryption, thus bypassing- scanning filters. Another
approach to detecting malicious software is to run a
program while attempting to intercept malicious actions
during program execution. This technique, which is known
as behavior blocking, has a number of disadvantages.
Despite of the attempt to intercept malicious actions,
the program may nevertheless cause harm to the computer
system. Furthermore, the behavior blocking mechanism
typically cannot view an entire log of actions in
making a. blocking determination. Hence, the behavior
blocking mechanism may make
sub-optimal blocking
decisions, which means harmless programs may be blocked
while harmful programs may be allowed to execute.
Yet another approach to detecting malicious software is
to emulate suspect code within an insulated environment
of a computer system_ so that the computer system is
protected from malicious actions of the suspect code. One
drawback of emulation is that while it may protect parts
of the computer system from virus attacks, it is not
itself protected. Additionally, data can be infected,
which leads to a break in the isolation environment.
Consequently, it would be
desirable to provide an
improved method for preventing malicious software from
execution within a computer system.
In accordance with a first embodiment of they present
invention, a permutation is performed on a subset of
instructions within an application program to yield a
permuted sequence of instructions A before any actual
execution of the application program on a computer system.
A permutation sequence number of the permuted sequence of
instructions is stored iJ1 a permuted instruction pointer
table. The permuted sequence of instructions is executed in
an execution module that is capable of translating the
permuted sequence of instructions to an actual machine
code of a processor within the computer system according
to the permutation number of
sequence the permuted
sequence of instructions stored in the
permuted
instruction pointer table.
In accordance with a second embodiment of the present
invention, before any actual execution of an application
program on a computer system, the application program needs
to be cross-compiled to yield a set of cross-compiled code
of the application program. The set of cross—compiled code
of the application program can then be executed in an
execution module that is
capable of recognizing and
translating the set of
cross-compiled code of the
application program to the actual machine code of the
PIOCQSSOI .
All features and advantages of the present invention will
become the
apparent in following detailed written
description.
The invention itself, as well as a preferred mode of use,
further objects, and advantages thereof, will best be
understood by reference to the following detailed
description of an illustrative embodiment when read in
conjunction with the accompanying
drawings, wherein:
Figure 1 is a conceptual view of a method for preventing
malicious software
from execution within a
computer
system, in accordance with a preferred embodiment of the
present invention;
Figure 2 is a block diagram of a computing
environment in which a preferred embodiment of the
present invention is incorporated; and
Figures 3a—3e depict a sequence in which instructions is
being permuted, in accordance with a preferred
embodiment of the present invention.
Typically, there are several levels of instruction
sets within a computer system. The first (lowest) level
is the machine level instructions, and the second level
is the operating system application binary interface
instructions. At the second level, the operating system
has abstracted some of the machine level instructions to
make them easier to be understood. The third level is
the macro level instructions, at which an application
has further abstracted control of the computer system to
allow for ease of programming.
dedicated to the
third
instructions, the present invention is solely directed to
Since many techniques have been
protection of the second and levels of
the protection of first level of instruction,
especially when this is the level that is used by many
computer viruses.
Generally speaking, it is improbable, if not impossible,
to write a nmchine level program that can be executed
within a computer system without knowing the machine
level instruction set of a processor within the computer
system. In addition, an installation of software on a
computer system requires the software to first understand
the instruction set of the computer system on which it
is being installed. Thus, in accordance with a
preferred embodiment of the present invention, an
application program is initially transformed to a set
of cross-compiled code of the application program, and
the set of cross-compiled code of the application
program is then executed within an execution module that
is capable of recognizing the set of cross-compiled code
of the application program.
Referring now to the drawings and in particular to Figure
1, there is depicted is a conceptual view of a method for
preventing malicious software from execution within a
computer system, in accordance with a preferred
embodiment of the
present invention. As- shown, a
computer system 10 includes a transformation module 11
and an execution module 12. Any application program that
is to be executed. within computer system 10 needs to
undergo an
installation process. During the
installation process, a user of computer system 10 can
decide whether or not an application program should be
If the user decide
installed
installed within computer system 10.
the should be
application program within
computer system 10, the application program is then sent
to transformation module 11 in which the application
program will be transformed to a set of cross-compiled
code
of the application program. The set of cross-
compiled code of the application program can subsequently
be executed within execution module 12 that is capable of
recognizing and translating the set of cross-compiled
code of the application program to the actual machine
code of the processor.
Without going through the installation process, an
application program will not be able to be executed by
execution module 12. shown in an
For example, as
illicit path 15, even if a virus program has sneaked
under the detection of a user and was placed within
computer system 10 without the user's knowledge, the
virus program still cannot be executed by execution
module 12 because the virus program has not undergone
the installation process.
As such, computer system 30
is safe from the potential harm that could have been
brought on by the virus program.
In practice, transformation module 11 and execution
module 12 should be isolated from each other. In fact,
execution module 12 should be prevented from accepting
code from any source other than transformation module
With reference now to Figure 2, there is depicted a
block diagran1 of a computing environment in. which a
preferred embodiment of the
present invention is
incorporated. As shown, a computer system 20 includes a
hardware structure 21, a virtual machine manager (VMM)
or hypervisor 22 and virtual machines 23a-23b. Virtual
machines 23a and 23b are preferably located in separate
partitions such that any execution within virtual machine
23a is isolated from virtual machine 23b, or vice versa.
VMM 22 controls all communications between virtual
machines 23a and 23b. In addition, VMM 22 can directly
communicate with hardware structure 21. Hardware
structure 21 includes such known structures as
processors, registers, memory management units, memory
devices, input/output devices, etc.
An operating system and multiple application programs
can be executed concurrently within each of virtual
machines 23a-23b. For example, an operating system 24
and an application program 25 are executed within
virtual machine 23a, while an operating system 26 and
an application program 27 are executed within virtual
machine 23b.
Although it is not required, operating system 24 can be
different from operating system 26. For example,
operating system 24 can be an open source Linux (RTM)
operating system, while operating system 25 can be
Windowsm operating system manufactured by the Microsoft
Corporation. ,the
Similarly, underlying processor
emulated by virtual machine 23a can also be different
from the underlying processor emulated by virtual machine
b. For example, the underlying processor emulated by
virtual machine Pentiumo
can be a processor
while the
underlying processor emulated by virtual machine 23b
PowerPc°
manufactured by the Intel Corporation,
can be a processor
manufactured by the
International Business Machines Corporation.
Each of virtual machines 23a-23b, which includes its
operating system and associated application programs,
operates at a user—1evel.
when VMM 22 uses direct
execution, VMM 22 is set to a so-called user—mode (i.e.,
with reduced privileges) so that none of virtual
machines 23a-23b can directly access the various
privileged registers that control the operation of
hardware structure 21. Rather, all privileged
instructions will be trapped into VMM 22.
In Figure 2, virtual machine 23a is shown to include a
cross compiler 28 for performing initial cross-
compilations of application programs. In addition,
virtual machine 23b is shown to include an execution
module 29 for executing the cross-compiled code of the
application programs. The
cross-compilations are
preferably’ performed via a permutation algorithm, and
I the results are stored in a permuted instruction pointer
Claims (1)
- CLAIMS . Permuted instruction pointer table 30 includes multiple entries of permutation sequences. Each of the permutation sequences is associated with a set of cross- compiled code of an application program. All the permutation sequences within instruction permuted pointer table 30 are likely to be different from each other, although they are not required to be different from each other. In
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| USUNITEDSTATESOFAMERICA14/02/20061 | |||
| US11/353,893 US8694797B2 (en) | 2006-02-14 | 2006-02-14 | Method for preventing malicious software from execution within a computer system |
| US11/353,896 US8041958B2 (en) | 2006-02-14 | 2006-02-14 | Method for preventing malicious software from execution within a computer system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| IE20080383A1 IE20080383A1 (en) | 2008-08-20 |
| IE85287B1 true IE85287B1 (en) | 2009-07-22 |
Family
ID=
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Hähnel et al. | {High-Resolution} Side Channels for Untrusted Operating Systems | |
| US7845009B2 (en) | Method and apparatus to detect kernel mode rootkit events through virtualization traps | |
| US8041958B2 (en) | Method for preventing malicious software from execution within a computer system | |
| EP3738058B1 (en) | Defending against speculative execution exploits | |
| Ge et al. | Sprobes: Enforcing kernel code integrity on the trustzone architecture | |
| US7603704B2 (en) | Secure execution of a computer program using a code cache | |
| US20200372129A1 (en) | Defending Against Speculative Execution Exploits | |
| US7594111B2 (en) | Secure execution of a computer program | |
| Riley et al. | Guest-transparent prevention of kernel rootkits with vmm-based memory shadowing | |
| Gu et al. | Process implanting: A new active introspection framework for virtualization | |
| Lanzi et al. | K-Tracer: A System for Extracting Kernel Malware Behavior. | |
| Shi et al. | Deconstructing Xen. | |
| EP2881881B1 (en) | Machine-readable medium, method and system for detecting java sandbox escaping attacks based on java bytecode instrumentation and java method hooking | |
| US8694797B2 (en) | Method for preventing malicious software from execution within a computer system | |
| JP2013515989A (en) | Method and system for protecting an operating system from unauthorized changes | |
| Mi et al. | (mostly) exitless {VM} protection from untrusted hypervisor through disaggregated nested virtualization | |
| Laurén et al. | An interface diversified honeypot for malware analysis | |
| Hei et al. | Two vulnerabilities in Android OS kernel | |
| Piromsopa et al. | Survey of protections from buffer-overflow attacks | |
| Grill et al. | “Nice Boots!”-A Large-Scale Analysis of Bootkits and New Ways to Stop Them | |
| Oliveira et al. | Hardware-software collaboration for secure coexistence with kernel extensions | |
| Tian et al. | An Online Approach for Kernel-level Keylogger Detection and Defense. | |
| Neugschwandtner et al. | d Anubis–Dynamic Device Driver Analysis Based on Virtual Machine Introspection | |
| Jia et al. | Defending return‐oriented programming based on virtualization techniques | |
| Fu et al. | Subverting system authentication with context-aware, reactive virtual machine introspection |