JPWO2004075060A1 - Computer virus judgment method - Google Patents

Abstract

The present invention relates to protecting a computer from risks such as data falsification and information leakage due to execution of a malicious program or computer virus. Conventionally, as a technique for detecting a computer virus or the like, a technique using pattern matching has been the mainstream. On the other hand, in the present invention, a malicious program such as a computer virus is detected by checking the behavior during execution of the application program. In other words, monitored processes can be monitored by attaching to newly created or running processes on the computer, setting breakpoints, and monitoring system calls that can make significant changes to the computer. Compare the behavior of the computer with the characteristic behavior of past computer viruses.

Description

  The present invention monitors the execution of a program that can be executed by e-mail, WEB, peer-to-peer file exchange software, etc. that is executed from outside the computer, such as the Internet, and the behavior of a computer virus. Or, it relates to detecting a behavior similar to a computer virus and taking measures such as stopping execution of a program.

Currently, the mainstream of detection techniques for computer viruses (hereinafter sometimes simply referred to as “viruses”) uses pattern matching. This technique is disclosed in, for example, Japanese Patent Application Laid-Open No. 2003-216444, Japanese Patent Application Laid-Open No. 2002-196942, and WO 02/087717 A1. Pattern matching focuses on a file on a computer memory or hard disk, and detects a virus by comparing it with a signature signature of a virus found in the past. Pattern matching is a technique with few false detections, but only known viruses can be detected.
Currently, about 10 to 20 kinds of new viruses are found in one day. In order for computers used by regular users to be able to detect and deal with such new viruses, obtain frequently updated virus signature files from anti-virus companies promptly, Must be installed on the computer. By the way, there are many new viruses that have changed the past viruses a little. For this reason, the actual behavior of viruses is very similar. Nevertheless, the information pattern of virus programs is different, so each time a virus is found, a virus signature file must be installed.
Virus detection technology includes heuristic scanning in addition to pattern matching. In the heuristic scan, a pseudo code is executed to determine whether or not a behavior similar to a virus is performed based on emulation. However, not all executable file instructions can be emulated. Also, it takes a very long time to emulate a virus with a large program size and / or complicated encryption.

In the present invention, a process such as a system call that can create a new process on a computer or attach to a running process (Attach) to monitor the process and make important changes to the computer By monitoring the behavior. Then, the behavior of the process to be monitored is compared with the characteristic behavior of past computer viruses. When the characteristic behavior of the virus is detected, the user is notified so that the process to be monitored can be stopped. Here, the monitoring target process mainly refers to a process connected to the Internet.
FIG. 1 is a diagram conceptually illustrating the execution of a process in a computer. Applications 101 and 102, e-mail software 103, and WEB browser 104 operate in the upper layer. Of these, it is assumed that the application 102, the e-mail software 103, and the WEB browser 104 are processes for executing a program for introducing a program from outside the computer by connecting to the Internet. In the present invention, a security layer according to the present invention is provided between these processes and the system call API layer 105. This security layer is a layer that monitors the invocation of system calls.
Below the system call API layer 105 is a kernel layer 106 that implements an operating system (hereinafter sometimes abbreviated as “OS”), and below that is a device driver / hardware 107 layer. .
In an OS in a normal computer, processing is performed separately in a kernel mode and a user mode. A portion 108 above the system call API layer 105 is a portion where processing is performed in the user mode, and a portion 109 below the system call API layer 105 is a portion where processing is performed in the kernel mode.
A process executing in user mode has a separate context and a virtual address space. Therefore, processes executed in the same user mode cannot access the memory of other processes.
The present invention is based on the position of a breakpoint to be set when executing an application program, and when the execution of the application program reaches the breakpoint, the application program is stored in a computer virus based on the contents of the stack of the application program. And a determination program that determines whether or not it has a function. When a breakpoint is set in the application program and the execution of the application program reaches the breakpoint, the determination is held in association with the position of the breakpoint. A computer virus detection apparatus for executing a program is provided.
The computer virus detection apparatus may hold an application program and set a breakpoint in the application program when the held application program is executed.
The position of the breakpoint may be determined based on the system call API function. By doing so, the security layer of FIG. 1 is realized.
Further, when the execution of the application program reaches a breakpoint, the argument of the system call API function may be checked.
Further, when the system call API function changes the system resource, the computer virus detection device may generate a copy of the system resource before executing the system call.
Further, the computer virus detection device may be configured to prevent the execution of the system call API function when it is determined that the application program has a computer virus property.
Further, when the system call API function performs communication, the computer virus detection apparatus may output a command to an external communication device (for example, a router) so as to cause the communication to fail. .
Further, whether or not the application program has a computer virus property may be determined based on a history of breakpoints reached by the application program.
In the present invention, the application program may be a virtual machine for executing a program written in a language such as Java (registered trademark). Further, the virtual machine may operate on a mobile phone.
In an OS including WINDOWS (registered trademark), as a method of controlling the behavior of a process, there is a method of writing a kernel driver and hooking a system call (for example, used in eTrust Access Control “Soft hook” of Computer Associates, Inc.). Method). On the other hand, the monitoring of the behavior of the process according to the present invention is performed by using a function used in software development called a debugger.
The behavior monitoring in the present invention is characterized in that it is all performed in the user mode, that is, the application layer. As a result, there is no occurrence of a fatal error such as a system down often caused when a kernel driver is used.
In the following, in order to help understanding of the present invention, the function of a conventional debugger will be outlined.
FIG. 2 illustrates the relationship between the process 201 for executing the application program and the debugger 202. (1) First, the debugger 202 attaches to the process 201. By the attachment, the relationship between the process 201 and the debugger 202 is managed by the OS. That is, the OS associates the process 201 with the debugger 202. For example, when a change occurs in the state of the process 201, the debugger 202 is notified. (2) Next, the debugger 202 sets a breakpoint in the process 201. “Breakpoint” indicates a memory address at which execution of the CPU is stopped when the program counter of the process 201 reaches a predetermined value. Designating such a memory address is called setting a breakpoint. A method for setting a breakpoint is realized by setting the memory address value indicated by the breakpoint in the CPU or by replacing the instruction at the memory address indicated by the program counter value of the breakpoint with a special instruction. (See, for example, Jonathan B. Rosenberg, "How Debuggers Work, Algorithms, Data Structures, and Architecture", Wiley Computer Publishing, 1997). Thereafter, when the process 201 starts execution and reaches a breakpoint, (2) the OS is notified that execution has stopped. This notification is performed not by the process 201 but by a processing routine for processing the interrupt when the execution of the process reaches a breakpoint and the CPU is interrupted. Note that the processing routine is appropriately set by initializing the OS or the like. When the OS receives the notification, (4) the debugger 202 is notified, and the debugger 202 knows that the execution of the process 201 has reached a breakpoint. Thereafter, (5) debug operation of the process 201 is performed by the operation of the user of the debugger 202. As a typical debugging operation, the contents of the process stack are read, the sequence in which functions and procedures are called, and the values of arguments and variables are examined.
Breakpoints are set for each process. Therefore, the description “set a breakpoint in the process that executes the application program” is accurate, but the description becomes longer. Therefore, in the following, the application program and the process that executes the application program are regarded as the same. , “Set breakpoint in application program”, etc.
FIG. 3 illustrates how function and procedure calls in high-level languages are compiled in the prior art. In a high-level language, it is assumed that a function or procedure called “f (argument 1, argument 2,..., Argument n); . When this is compiled, it is converted into a machine instruction as indicated by reference numeral 302. That is, the argument is loaded on the stack by the push instruction, and finally f is called by “call f”. In many CPUs, when a machine instruction that calls a function such as call f is executed, a value set in the program counter is loaded on the stack when returning from the processing of the called function.
FIG. 4 illustrates the compilation result of the function f. When f is called, first, the value of the frame pointer (fp) before the call of f is put on the stack by a machine instruction “push fp”. The “frame pointer” is a CPU register for indicating a portion of the stack for function calls. As will be described later, the frame pointer plays an important role in obtaining a function call sequence (call sequence). Next, the value of the stack pointer (sp) is set to the frame pointer (fp) by “move sp → fp”. As a result, the frame pointer (fp) points to the stack portion of f currently being called. Thereafter, the process f is performed. When returning from the call to f, the value of the frame pointer (fp) before the call to f is set by “pop fp”, and the process returns from the call to f by “ret”. For example, the value of the program counter stacked on the stack is set in the program counter.
FIG. 5 illustrates a state in which values are stacked on the stack. The value stacked in the top part of the stack 501 (that is, the value stored in the top part of the stack) relates to the function currently being executed. , The argument values are stacked. In area 503, a program counter after the function call is stacked. The area 504 is loaded with the value of the frame pointer (fp) before the function call. An area 505 stores the values of automatic variables defined in the function. The frame pointer (fp) points to the upper part of the area 504, and the value accumulated in the area 504 is the position where the frame pointer (fp) accumulated in the stack 501 at the previous function call is stored. Pointing up. Therefore, by following the value of the frame pointer, it is possible to know through which call sequence the function is called. Further, by checking the value of the program counter loaded on the stack, it is possible to know from where in the program the function is called. In addition, it is possible to know what value is given to the function by examining the arguments stacked on the stack.
The computer virus detection apparatus according to the present invention monitors the behavior of a process by using such a debugger function. However, in the debugger in the prior art, a human operates the debugger to investigate the process to be debugged, whereas the process behavior monitoring by the computer virus detection apparatus according to the present invention is automatically performed.
The present invention also solves the problems associated with commercial software. Hereinafter, description will be made using spyware as an example. Spyware is an application program that sends information to its creator or caller over the Internet. Spyware behaves like a backdoor virus. Malicious spyware steals user information and keystrokes and sends information to other machines through a specific communication channel.
However, many anti-virus companies do not detect commercial software such as spyware as their policy. This is because there is commercial software that erases the data used to destroy the hard disk, which may be sent as an email from a friend. Anti-virus does not detect programs that erase data as intended by the user.
Therefore, even if the result of executing the program has an impact on a computer or a user's business, it is impossible to completely prevent these threats with the current anti-virus technology.
Some of the current viruses are active on Linux (registered trademark), but they are predominantly active on WINDOWS (registered trademark). One reason for this is that most people using WINDOWS® have added administrator rights to the logged-on user. Administrator authority is necessary when installing an application, but WINDOWS (registered trademark) does not have the custom of temporarily becoming a root (privileged user) for a system administrator like UNIX (registered trademark). In WINDOWS (registered trademark), a suspicious file sent by e-mail is often executed as a privileged user such as an administrator.
Administrator privileges have access to all resources of the system. In other words, you can tamper with important files necessary for the system to work. If a virus is executed in such an environment, important files on the computer may be altered, and computers around the world may be infected with the virus through the Internet. The execution environment of the program should be better protected for the user.

FIG. 1 is a diagram conceptually illustrating execution of a process on a computer in the prior art.
FIG. 2 illustrates the relationship between a process for executing an application program and a debugger in the prior art.
FIG. 3 illustrates how function and procedure calls in high-level languages are compiled in the prior art.
FIG. 4 illustrates the result of function compilation in the prior art.
FIG. 5 illustrates a state in which values are stacked on the stack in the prior art.
FIG. 6 illustrates a state in which a DLL file is mapped in the virtual process space in the prior art.
FIG. 7 shows a virtual memory space of a process in the prior art.
FIG. 8 illustrates a flowchart of processing in the present invention.
FIG. 9 illustrates a functional block diagram of the computer virus detection apparatus according to the first embodiment of the present invention.
FIG. 10 shows an example of a state in which breakpoint information is held.
FIG. 11 illustrates a state in which breakpoint information is provided for each application program.
FIG. 12 illustrates a flowchart of processing of the computer virus detection apparatus.
FIG. 13 illustrates a display screen by the computer virus detection apparatus according to the second embodiment of the present invention.
FIG. 14 illustrates a functional block diagram of a computer virus detection apparatus according to the second embodiment of the present invention.
FIG. 15 illustrates a flowchart of processing of the computer virus detection apparatus.
FIG. 16 illustrates breakpoint information according to the third embodiment of the present invention.
FIG. 17 illustrates a flowchart of processing of the computer virus detection apparatus.
FIG. 18 illustrates a functional block diagram of a computer virus detection device according to the seventh embodiment of the present invention.
FIG. 19 illustrates a flowchart of processing of the computer virus detection apparatus.
FIG. 20 illustrates an overview of the eighth embodiment of the present invention.
FIG. 21 illustrates a functional block diagram of a computer virus detection device according to the eighth embodiment of the present invention.
FIG. 22 shows an example of a communication blocking command.
FIG. 23 illustrates a flowchart of processing of the computer virus detection apparatus.
FIG. 24 illustrates a functional block diagram of a communication device according to the eighth embodiment of the present invention.
FIG. 25 is a flowchart of processing of the communication device.
FIG. 26 illustrates a functional block diagram of a computer virus detection device according to the ninth embodiment of the present invention.
FIG. 27 illustrates a flowchart of processing of the computer virus detection apparatus.
FIG. 28 illustrates a usage pattern of the computer virus detection device according to the tenth embodiment of the present invention.
FIG. 29 illustrates a usage pattern of the computer virus detection device according to the eleventh embodiment of the present invention.

Hereinafter, the best mode for carrying out the present invention will be described as an embodiment with reference to the drawings. Note that the present invention is not limited to these embodiments, and can be implemented in various modes without departing from the spirit of the present invention.
(Outline of the present invention)
The present invention focuses on the behavior of the program and determines whether the program is a virus. A process embodying the present invention and a process to be monitored have a relationship similar to that of a debugger and a debuggee. The debugger corresponds to the process embodying the present invention, and the debug corresponds to the process to be monitored.
The debugged process is called debuggee. The present invention executes the monitored process as a debuggee. When monitoring a running process, attach to the running process.
The process embodying the present invention sets breakpoints in system calls (or API functions) that make significant changes to the system in order to check the behavior of the monitored process.
In the case of an Intel (registered trademark) CPU, a breakpoint can be realized by placing a hardware interrupt instruction of Int3 at a memory address indicated by the breakpoint. When the execution of the process reaches a breakpoint, the execution of the process stops, and the computer virus detection apparatus according to the present invention investigates the contents of the stack of the process, and the behavior of the process to be monitored and the past Compare the characteristic behavior of computer viruses.
The following are examples of characteristic behavior of viruses.
• Copy yourself to the system folder.
• Look for directories shared on the network. Then copy yourself.
・ Access the mail address book and send a large number of mails with viruses attached.
・ If file exchange software is installed, use it to distribute yourself.
-Delete important system files. Or tamper.
-Change the system so that it will run on reboot.
The present invention compares the API call of the monitoring target process with the past behavior of a computer virus, etc., and stops the monitoring target process or issues a warning to the user.
Hereinafter, WINDOWS (registered trademark) will be specifically described as an example. In WINDOWS (registered trademark), an API for manipulating files and directories is KERNEL32. It is included in a file called DLL. The API related to the registry is ADVAPI32. Included in the DLL. An API for operating a network shared drive is MPR. Included in the DLL. Hereinafter, these are called DLL files.
A method for determining which API the monitored process is trying to call will be described below. When the monitored process starts executing, the DLL file is mapped to the virtual process space.
FIG. 6 shows that the virtual process space 601 includes Kernel32. Dll, MRP. Dll, Advapi32. The state where Dll was mapped is illustrated. By performing the mapping in this manner, the monitoring target process is, for example, Adobe32. Functions such as RegCreateKeyEx defined in Dll can be called.
FIG. 7 shows the virtual memory space of the process. The virtual memory space 700 has an instruction part 701, a heap part 702, a DLL part 703 to which a DLL file is mapped, and a stack part 704 from the smallest memory address. The portion 703 is located between the heap portion 702 and the stack portion 704, and the DLL file is mapped to the portion 703. That is, when a reference is made to the memory address of the portion 703, the contents of the DLL file stored as a file are obtained.
The map address of the DLL file (the first address of the part where the DLL file is mapped to the virtual memory space) is called an image base, and is uniquely determined in each DLL so as not to overlap with the others.
For example, an API called RegOpenKeyExA that operates the registry is ADVAPI32. Included in the DLL.
The address of RegOpenKeyExA is obtained by “ADVAPI32.DLL image base” + “RegOpenKeyExA RVA”. Note that “RVA” is an abbreviation for “relative virtual address”. That is, it is a relative position where the API definition appears in the DLL file.
When the address is obtained, a breakpoint is set using a debugger API or the like.
When the execution of the monitored process hits a breakpoint, the API argument is analyzed.
If the monitored process calls an API that changes the registry or system file, a backup is created in this step.
If virus characteristics are detected, stop the process or report to the user. If not detected, processing continues.
A specific example will be described. Many WINDOWS® viruses add a value to the following registry to run and resident in the system upon restart:
HKEY_LOCAL_ACHINE \ SOFTWARE \ MICROSOFT \ Windows \ CurrentVersion \ Run
For reference, here are some major viruses that add values to this key:
NIMDA, LOVELATERTER, TROJ_MATRIX, W32_MAGISTR, TROJ_HYBRIS, WORM_KLEZ, WORM_BUGBEAR, WORM_BADTRANS, JS_EXCEPTION, WORM_LIRBA
An unknown program received by e-mail may not need to reside in the system.
To add the registry, the following two-step API call is required.
RegCreateKeyExA ... Creates a new key under Run.
RegSetValueExA ... Set the value.
The top two APIs are ADVAPI32. Included in the DLL. Here, ADVAPI32. Assume that the image base of the DLL is 0x77D80000. The number 0x indicates a hexadecimal number. Further, it is assumed that the RVA of RegCreateKeyExA is 0x29427 and the RVA of RegSetValueExA is 0x2C58D.
The address of RegCreateKeyExA is
0x77D80000 + 0x29427 = 0x77DA9427
The address of RegSetValueExA is
0x77D80000 + 0x2C58D = 0x77DAC58D
Is required. Since these are virtual address spaces, the DLL file is mapped with the same virtual address even if a plurality of processes are executed simultaneously.
When asked for addresses, set breakpoints on them.
If the process to be monitored is a program that is automatically executed when WINDOWS (registered trademark) is activated, a break point of RegCreateKeyExA is hit. Next, analyze the stack. This is because a compiler such as C language generates machine instructions that pass arguments through the stack.
80000002 0041f028 ADVAPI32! RegCreateKeyExA
For example, assume that the above numerical values are obtained. When calling RegCreateKeyExA, the second argument is the location of the registry. In this example, the location of the registry is stored in the memory address 41f028. Therefore, the memory address 41f028 is checked.
> 41f028
41f028 SOFTWARE \ Microsoft
41f038 ft \ Windows \ Cure
41f048 ntVersion \ Run \ Vi
41f058 rus
From the API and arguments, it can be seen that the monitoring process is trying to create a key called Virus under Run.
In order to return to the state before the program execution, the Virus key may be deleted. Therefore, a history of changes in system resources such as a registry, a copy of system resources, and the like may be held before execution of a system call.
Similarly, API necessary for grasping the behavior of the program is checked, and the tendency of the call is analyzed.
It is desirable that the correspondence between the API for monitoring the call and the argument (hereinafter referred to as a detection rule) can be added or changed by reading a file describing the detection rule from the outside, for example, the Internet, instead of hard coding.
With this method, there is no overhead of scanning the file. When the characteristic behavior of the virus is detected, it is preferable to display a dialog box or the like so that the process to be monitored can be stopped by the user's intention.
Or, continue without executing the program. A flowchart is illustrated in FIG.
(Embodiment 1)
As Embodiment 1 of the present invention, breakpoint position information and a determination program to be executed when an application program reaches a breakpoint indicated by the breakpoint position information are stored in association with each other, and the breakpoint is set in the application program A computer virus detection apparatus that executes a determination program will be described.
(Embodiment 1: Configuration)
FIG. 9 illustrates a functional block diagram of the computer virus detection device according to the present embodiment. The computer virus detection apparatus 900 includes a breakpoint information holding unit 901, a breakpoint setting unit 902, and a determination program execution unit 903.
As will become clear from the following description, a computer virus detection apparatus having these units can be realized as a program that runs on a computer. Therefore, FIG. 9 can also be interpreted as a diagram showing the module configuration of such a program. That is, such a program includes a breakpoint information holding step for realizing a breakpoint information holding unit by a program, a breakpoint setting step for realizing a breakpoint setting unit by a program, and a determination for realizing a judgment program execution unit by a program. A program for causing a computer to execute a program execution step.
A “breakpoint information holding unit” 901 holds breakpoint information. For example, breakpoint information is held in a hard disk or semiconductor memory. “Breakpoint information” is information including breakpoint position information and a determination program. Since “includes”, the components of the breakpoint information may not be limited to the breakpoint position information and the determination program.
“Breakpoint position information” is information indicating the position of a breakpoint to be set when the application program is executed. The position of the breakpoint is indicated by, for example, a memory address of the application program. It may also be indicated by the name of a function, procedure, or method (hereinafter referred to as “function or the like”) that is called by the application program.
The “determination program” means whether or not the application program has a computer virus property based on the contents of the stack referred to in the execution of the application program when the execution of the application program reaches the breakpoint. This is a program for making a decision. “The application program” means an application program in which a breakpoint is set at a position indicated by breakpoint position information by a breakpoint setting unit 902 described later. The “breakpoint” means a breakpoint set at a position indicated by breakpoint position information.
"Application program has computer virus" is designed not only when the application program itself is a computer virus, but also when the application program is infected with a computer virus, using bugs or security holes in the application program In some cases, such as when the operation is not expected. For example, there is a case where a malicious person performs an operation such as obtaining the contents of a file that cannot be obtained by a normal operation using a bug of the web server program.
There are various methods for determining whether or not the application program has a computer virus property based on the contents of the stack referred to when the application program is executed. For example, it is determined whether or not the stack referred to in the execution of the application program can be traced from the top of the stack to the bottom of the stack by following the frame pointer. Some computer viruses call system calls and the like in such a manner that they are not called if the application program operates normally by destroying the contents of the stack. Therefore, it is determined whether or not the contents of the stack are destroyed. One of the judgments is that the application program has a computer virus property depending on whether it can follow the frame pointer and call up to a function called first in the execution of the program (for example, a function named _startup). Judge whether or not.
In addition, when the application program reaches a breakpoint, it may be determined whether or not the application program has a computer virus property by checking through what call sequence the function is reached. If a breakpoint is reached after a sequence of calls such as an unexpected function, it is suspected to have a computer virus.
Further, it may be determined whether or not the application program has a computer virus property by examining an argument such as a function in which a breakpoint is set. For example, a computer virus that infects other computers using e-mail accesses the address book of e-mail addresses in order to obtain e-mail addresses. Therefore, the determination may be made based on whether an argument for accessing the address book is specified.
In many cases, the process for executing the program for realizing the computer virus detection device is different from the process for executing the application program. Usually, the program for realizing the computer virus detection device is the application program. The contents of the memory space of the executing process, especially the contents of the stack cannot be read. However, the operating system has a function that allows a certain process to read or change the contents of the memory space and registers of other processes if they are between processes in a specific relationship. It is normal. Examples of the “specific relationship” here include a parent-child relationship, a process executed by the same user, and a relationship in which a predetermined system call (for example, attach) is executed on another process, and so on. Therefore, when the computer virus detection apparatus is realized by a program, the process for executing the program and the process for executing the application program need to have a specific relationship.
Most operating systems provide system calls for reading and changing the memory space and register contents of other processes. Alternatively, there may be a case where the contents of the memory space and registers of other processes can be read or changed using a special device called / dev / proc.
For example, the determination program may be executed by an interpreter. For example, the determination program may be described in a language such as Lisp, Perl, or Ruby. Further, the determination program may consist of a sequence of machine instructions that can be directly executed by a computer. In this case, a determination program may be incorporated as a part of a program for realizing the computer virus detection device. Alternatively, the determination program may be loaded into a program that dynamically realizes a computer virus detection device, for example, as a dynamic library. If the determination program is executed by an interpreter or is dynamically loaded, the determination program can be easily replaced.
FIG. 10 shows an example of a state in which breakpoint information is held by the breakpoint information holding unit 901. In FIG. 10A, breakpoint information is held in a table. A column 1001 stores breakpoint position information, and a column 1002 stores a determination program. FIG. 10B shows an example of a state in which a pointer to the determination program is stored in the table. The pointer points to a specific location within the memory space of the process executing the program that implements the computer virus detection device.
FIG. 11 illustrates a state in which breakpoint information is provided for each application program. Thus, the breakpoint information holding unit 901 may hold breakpoint information for each application program.
The “breakpoint setting unit” 902 sets breakpoint information in the application program based on the breakpoint information held by the breakpoint information holding unit 901. That is, a breakpoint is set at a position indicated by breakpoint position information included in the breakpoint information. This setting is performed using a system call or special device provided by the operating system. “Based on” means that, for example, when the breakpoint position information is expressed using a name of a function or the like, an address of the function or the like is obtained from the name of the function or the like. Correspondence between names of functions and their addresses and their addresses can be obtained by reading a symbol table of an application program.
The “determination program execution unit” 903 executes the determination program included in the breakpoint information when the execution of the application program reaches the breakpoint set by the breakpoint setting unit 902. The “application program” is an application program in which a breakpoint is set by the breakpoint setting unit 902. The computer virus detection apparatus waits until the execution of the application program in which the breakpoint is set reaches the breakpoint. For this purpose, for example, a wait system call is called. When the execution of the application program reaches a breakpoint, (1) the processing of the computer virus detection device resumes from the wait system call, (2) determines which breakpoint has been reached, and (3) a determination program execution unit 903 To execute a judgment program. To determine which breakpoint the application program has reached, it is determined by obtaining the value of the program counter held in the register of the process executing the application program.
(Embodiment 1: processing)
FIG. 12 illustrates a flowchart of processing of the computer virus detection apparatus.
In step S1201, a breakpoint is set in the application program at the position indicated by the breakpoint position information. For example, this process is performed by the breakpoint setting unit 902.
In step S1202, the execution of the application program waits until a breakpoint is reached. This process is realized, for example, by executing a wait system call.
In step S1203, the determination program corresponding to the breakpoint at which the execution of the application program has been reached is executed. For example, this process is performed by the determination program execution unit 903.
In step S1204, it is determined whether or not to end the process. For example, if it is determined by execution of the determination program in step S1203 that the application program has a computer virus property, the process ends. If it is determined not to end the process, the process proceeds to step S1205.
In step S1205, the execution of the application program is continued. When the application program reaches a breakpoint, the execution of the application program stops, so that the processing is resumed from the point where it stopped. For example, a signal (for example, SIG_CONT) is sent to the process that executes the application program. Thereafter, the process proceeds to step S1202.
The computer virus detection apparatus can be considered as an apparatus for using a computer virus detection method including a breakpoint information holding step, a breakpoint setting step, and a determination program execution step. “Breakpoint information holding step” is a step for holding breakpoint information. “Breakpoint setting step” is a step for setting a breakpoint in the application program based on the breakpoint information held in the breakpoint information holding step. The “determination program execution step” is a step of executing the determination program included in the breakpoint information when the execution of the application program reaches the breakpoint set in the breakpoint setting step. . That is, the breakpoint information holding step is a step that operates the breakpoint information holding unit, the breakpoint setting step is a step that operates the breakpoint setting unit, and the determination program execution step executes the determination program execution unit. It is a step. The use of the computer virus detection method according to the present invention is not limited to the computer virus detection apparatus according to the present invention.
(Embodiment 1: Main effects)
According to the present embodiment, since the behavior of a process for executing an application program can be monitored by a computer virus detection device without modifying the kernel of the operating system, the occurrence of a system down can be avoided. Become. In addition, since the behavior of computer viruses is often very similar, the necessity of continuing to update the pattern file to the latest one, which was necessary in conventional anti-virus software, is reduced. Update is unnecessary.
(Embodiment 2)
As a second embodiment of the present invention, a computer virus detection apparatus that holds an application program will be described.
FIG. 13 illustrates a display screen by the computer virus detection apparatus according to the present embodiment. A window 1301 is a window displayed by the computer virus detection device according to the present embodiment. An application program icon is displayed in the sub-window 1302 of the window. If necessary, an icon (eg, icon 1304) displayed outside the window 1301 can be dragged and moved to the inside of the sub-window 1302. By double-clicking an icon (for example, icon 1303) displayed in the sub window 1302, a process for executing the application program is generated as a child process of the process for executing the computer virus detection device, and its behavior is monitored. Is done.
(Embodiment 2: Configuration)
FIG. 14 illustrates a functional block diagram of the computer virus detection device according to the present embodiment. The computer virus detection apparatus 1400 includes a breakpoint information holding unit 901, a breakpoint setting unit 902, a determination program execution unit 903, an application program holding unit 1401, a program execution start unit 1402, a breakpoint setting instruction unit 1403, Have.
Therefore, in the computer virus detection device according to the present embodiment, the computer virus detection device according to the first embodiment further includes an application program holding unit 1401, a program execution start unit 1402, and a breakpoint setting command unit 1403. It has a configuration. In the present specification, the same reference numerals are assigned to parts to which the same definition is applied as much as possible. It should be noted that assignment of the same code does not mean that the same configuration or the like is obtained in actual manufacturing or the like.
An “application program holding unit” 1401 holds an application program. There are various forms of holding. For example, there is a form in which the entire application program is stored. Further, there may be a form of storing a location where an application program is stored, for example, a path expressed in a file system.
The “program execution start unit” 1402 starts execution of the application program held by the application program holding unit 1401. For example, execution of an application program is started as a child process of a process that executes a program for realizing a computer virus detection device.
A “breakpoint setting instruction unit” 1403 instructs the breakpoint setting unit 902 to set a breakpoint for an application program whose execution is started by the program execution start unit 1402. For example, a function for realizing the breakpoint setting unit 902 is called.
(Embodiment 2: processing)
FIG. 15 illustrates a flowchart of processing of the computer virus detection device according to the present embodiment.
In step S1501, the application program is held. This process is performed by the application program holding unit 1401. For example, in FIG. 13, it is detected that the icon 1304 has been dragged into the sub-window 1302, and an application program represented by the icon 1304 is held.
In step S1502, the process waits until an application program is selected. For example, in FIG. 13, the process waits until an icon inside the sub window 1302 is double-clicked.
In step S1503, a command is issued to set a breakpoint at the position indicated by the breakpoint position information in the selected application. This processing is performed by the breakpoint setting command unit 1403.
In step S1504, the process waits for completion of the breakpoint setting. For example, it waits until it returns from a call of a function that implements the breakpoint setting unit 902.
In step S1505, the selected application program is executed. More precisely, a process for executing the selected application program is executed. After step S1505, step S1202, step S1203, step S1204, and step S1205 in the flowchart of FIG. 12 are executed. In recent operating systems, it is possible to operate a plurality of threads in parallel / parallel in one process. Therefore, execution of step S1202, step S1203, step S1204, and step S1205 may be performed by a thread different from the thread that executes the flowchart of FIG.
In step S1506, it is determined whether or not to end the process. For example, the determination is made based on whether the operator of the computer virus detection apparatus has pressed the end button. If not completed, the process returns to step S1502.
(Embodiment 2: Main effects)
According to this embodiment, it is possible to easily generate a process for executing an application program whose behavior is to be monitored. In addition, application programs that are not likely to introduce a computer virus from the outside can be excluded from monitoring, so the speed at which such application programs are executed is not reduced by setting breakpoints. .
(Embodiment 3)
As a third embodiment of the present invention, a computer virus detection apparatus that sets a breakpoint in a system call API function and monitors the behavior of a process will be described.
(Embodiment 3: Configuration)
The computer virus detection apparatus according to the present embodiment is configured so that the breakpoint information held by the breakpoint information holding unit 901 of the computer virus detection apparatus according to the first or second embodiment is determined based on the system call API function of the application program. It is a thing.
The “system call API function” means a library function for calling a system call. Such a library function or the like is normally configured such that an argument for a system call is loaded on the stack and a trap instruction is executed. By executing the trap instruction, an interrupt routine set in the CPU by the operating system is started, and processing inside the operating system is started. Since it is difficult to directly express a process of loading arguments and executing a trap instruction in a high-level language, a library function for performing such a process is prepared.
FIG. 16 illustrates breakpoint information in the present embodiment. In FIG. 16, RegCreateKeyExA is the name of the system call API function. Therefore, when the breakpoint setting unit sets a breakpoint, it is necessary to convert the name of the system call API function into an address. The conversion process is as described in the overview section.
(Embodiment 3: Main effects)
Since a computer virus often infects a computer itself using a system call API function, by detecting the call of the system call API function and determining whether the application program has a computer virus property, It is possible to make an accurate judgment with fewer breakpoints.
(Embodiment 4)
As a fourth embodiment of the present invention, a computer virus detection apparatus that makes a determination based on examination of arguments of a system call API function will be described.
(Embodiment 4: Configuration)
The computer virus detection apparatus according to the present embodiment has a configuration in which the system call inspection program is included in the determination program in the computer virus detection apparatus according to the third embodiment. The “system call inspection program” is a program for determining whether or not the application program has a computer virus property based on the inspection of the argument of the system call API function called by the application program. “The application program” means an application program in which a breakpoint is set by the breakpoint setting unit 902.
Therefore, in this embodiment, when the execution of the application program reaches a breakpoint, the argument of the system call API function of the application program is checked. Based on the result of this inspection, it is determined whether or not the application program has a computer virus property.
In the present embodiment, the system call API function whose argument is checked is not limited to the one in which a breakpoint is set. For example, all the machine instructions of the application program may be examined, and the arguments of all system call API functions may be examined. The argument of the system call API function at the reached breakpoint may be stored, and when the breakpoint is reached later, the argument may be checked in the stored system call API function.
(Embodiment 4: Main effects)
In the present embodiment, since the computer virus property is determined based on the examination of the argument of the system call API function, the determination can be made more accurately.
(Embodiment 5)
As a fifth embodiment of the present invention, a computer virus detection apparatus for inspecting an argument of a system call API function at a reached breakpoint will be described.
(Embodiment 5: Configuration)
The computer virus detection apparatus according to the present embodiment is a system in which an argument to be inspected by the system call inspection program is determined by breakpoint position information held by the breakpoint information holding unit 901 in the computer virus detection apparatus according to the fourth embodiment. This is an argument of the call API function.
For example, as illustrated in FIG. 16, when a breakpoint is set in a system call API function called RegCreateKeyExA, and the execution of the application program reaches the breakpoint, the system call inspection program sets an argument of RegCreateKeyExA. inspect. An example of the inspection is as described in the overview section of the present invention.
(Embodiment 5: Main effects)
According to the present embodiment, since the computer virus property is determined based on the examination of the argument of the called system call API function, the determination can be made more accurately.
(Embodiment 6)
As a sixth embodiment of the present invention, a computer virus detection apparatus that generates a copy of a changed system resource when a system call API function that changes the system resource is called will be described.
(Embodiment 6: Configuration)
The computer virus detection apparatus according to the present embodiment has a configuration in which a copy creation program is included in the determination program in the computer virus detection apparatus according to the fourth or fifth embodiment. The “copy creation program” generates a copy of the changed system resource when the system resource is changed by the system call API function of the application program. “The application program” is an application program in which breakpoints are set by the breakpoint setting unit 902.
Accordingly, in the present embodiment, the breakpoint position information indicates the position of the system call API function that changes the system resource. The system resource here means, for example, a resource that can be duplicated among resources used by a computer, such as a registry and a file.
For example, a break point is set in the system call API function for changing the registry, and when the execution of the application program reaches the break point, a copy creation program for copying the registry is executed. When a copy is created, the registry is changed by a system call. In duplicating the registry, the entire registry may be duplicated, or only the part to be changed may be duplicated. The part to be changed in the registry can be determined by an argument of the system call API function.
In the present embodiment, the copy creation program may be executed when it is determined that the application program has a computer virus property. As a result, the amount of duplicates to be created can be reduced.
(Embodiment 6: processing)
FIG. 17 illustrates a flowchart of processing of the computer virus detection device according to the present embodiment.
In step S1701, a breakpoint is set in the application program at the position indicated by the breakpoint position information.
In step S1702, the process waits until execution of the application program reaches a breakpoint.
In step S1703, a determination program is executed.
In step S1704, it is determined whether the execution result of the determination program is that the application program has a computer virus property. If it has a computer virus property, the process proceeds to step S1705, and if not, the process is skipped to step S1707.
In step S1705, it is determined whether the application program is changing the system resource. This determination can be made by examining the type of system call API function related to the reached breakpoint and its argument. If the system resource is to be changed, the process proceeds to step S1706, and if not, the process is skipped to step S1707.
In step S1706, a copy of the system resource is created by the copy creation program.
In step S1707, it is determined whether to end the entire process. If it is determined not to end, the process proceeds to step S1708.
In step S1708, execution of the application program is continued, and the process proceeds to step S1702. Even if the application program is a computer virus and the system resource is changed to an illegal one, the system can be restored by the copy created in step S1706.
(Embodiment 6: Main effects)
In this embodiment, since a copy of the system resource to be changed is created, even if the application program is a computer virus and the computer is infected, the system can be recovered using the copy of the system resource.
(Embodiment 7)
As a seventh embodiment of the present invention, a computer virus detection apparatus that does not execute a system call API function when an application program is determined to have a computer virus property will be described.
(Embodiment 7: Configuration)
FIG. 18 illustrates a functional block diagram of the computer virus detection device according to the present embodiment. The configuration of the computer virus detection device according to the present embodiment is such that any one of the computer virus detection devices according to the first to sixth embodiments includes an execution blocking unit. Therefore, for example, the computer virus detection apparatus 1800 includes a breakpoint information holding unit 901, a breakpoint setting unit 902, a determination program execution unit 903, and an execution prevention unit 1801. In addition, the computer virus detection apparatus 1800 may include an application program holding unit, a program execution start unit, and a breakpoint setting command unit.
As a result of the determination by the determination program execution unit 903, the “execution prevention unit” 1801 does not execute the system call API function of the application program when it is determined that the application program to be determined has a computer virus property. It is a part for.
When the use of the stack is illustrated in FIG. 5, the execution prevention unit 1801 uses the value of the frame pointer (fp) to calculate the value of the frame pointer before the function call stored in the part 504. It is acquired and set to the frame pointer (fp), and the value of the program counter is set to the value stored in the part 503 so that the system call API function is not executed.
(Embodiment 7: processing)
FIG. 19 illustrates a flowchart of processing of the computer virus detection device according to the present embodiment.
In step S1901, a breakpoint is set in the application program at the position indicated by the breakpoint position information.
In step S1902, the process waits until execution of the application program reaches a breakpoint.
In step S1903, a determination program is executed.
In step S1904, it is determined as a result of the determination program whether the application program has a computer virus property. If it has a computer virus property, the process proceeds to step S1905, and if not, the process is skipped to step S1906.
In step S1905, the system call API function is not executed. In this process, the execution prevention unit 1801 is used.
In step S1906, it is determined whether to end the entire process. If not finished, the process proceeds to step S1907.
In step S1907, execution of the application program is continued. Thereafter, the process proceeds to step S1902.
(Embodiment 7: Main effects)
In the present embodiment, since dangerous system calls are prevented from being executed, for example, when a macro program of a specific word processor has a computer virus property, the execution of the dangerous macro program without stopping the function of the word processor. Thus, it is possible to continue the execution of the application program while preventing the execution of a dangerous system call.
(Embodiment 8)
As an eighth embodiment of the present invention, a computer virus detection apparatus and a communication device for blocking communication of an application program having a computer virus property will be described.
FIG. 20 illustrates an overview of the present embodiment. A computer 2001 is connected to an external communication network 2003 via a communication device 2002. A typical example of the communication device 2002 is a router. Inside the computer 2001, a process 2004 for executing an application program and a process 2005 for realizing a computer virus detection apparatus operate. The process 2005 monitors the behavior of the process 2004. If an application program executed by the process 2004 has a computer virus property, an attempt is made to communicate with the outside 2006. In this case, the process 2005 considers that the process 2004 is performing harmful communication to the outside, and outputs a communication blocking instruction 2007 to the communication device 2002 in order to block the harmful communication. Based on the communication blocking instruction 2007, the communication device 2002 blocks communication by not relaying a packet of communication to be performed by the process 2004.
(Embodiment 8: Configuration of computer virus detection apparatus)
FIG. 21 illustrates a functional block diagram of the computer virus detection apparatus according to the present embodiment. The configuration of the computer virus detection device according to the present embodiment is such that the computer virus detection device according to any one of Embodiments 1 to 7 has a communication blocking command output unit. For example, the computer virus detection device 2100 includes a breakpoint information holding unit 901, a breakpoint setting unit 902, a determination program execution unit 903, and a communication blocking instruction output unit 2101.
The “communication blocking instruction output unit” 2101 determines that, as a result of the determination by the determination program execution unit 903, the application program to be determined has a computer virus property, the application program sends a communication system call API function. When executing, a communication blocking command is output. The “communication blocking instruction” is an instruction for causing an external communication device to fail communication using the communication system call API function executed by the application program.
For example, a system call API function for communication in order for an application program determined to have a computer virus property to transmit data to the outside of the computer or to receive data from the outside of the computer. Is executed, an instruction to fail the communication is output to an external communication device such as a router.
FIG. 22 shows an example of a communication blocking command. In this example, the communication blocking instruction is described as a structured document such as XML. In FIG. 22, for example, in FIG. 20, the IP address of the computer 2001 is 192.168.193.063, the process 2004 is the communication with the IP address of 10.139.210.254, and the port is No. 25. A communication blocking command output when an attempt is made is shown. Such a communication blocking command may be output to an external communication device by, for example, SOAP (Simple Object Access Protocol).
(Embodiment 8: Processing of computer virus detection device)
FIG. 23 illustrates a flowchart of processing of the computer virus detection device according to the present embodiment.
In step S2301, a breakpoint is set in the application program at the position indicated by the breakpoint position information.
In step S2302, the process waits until execution of the application program reaches a breakpoint.
In step S2303, a determination program is executed.
In step S2304, it is determined whether the application program has a computer virus. If it is determined that the computer virus is present, the process proceeds to step S2305; otherwise, the process skips to step S2307.
In step S2305, it is determined whether the reached breakpoint is a communication system call API function. If it is a communication system call API function, the process proceeds to step S2306; otherwise, the process is skipped to step S2307.
In step S2306, a communication blocking command is output to an external communication device. This processing is performed by the communication block command output unit 2101.
In step S2307, it is determined whether or not to end the entire process. If not finished, the process proceeds to step S2308.
In step S2308, execution of the application program is continued. Even if harmful communication is performed following execution, communication is blocked by the communication blocking command output in step S2306.
(Embodiment 8: Configuration of communication device)
FIG. 24 illustrates a functional block diagram of the communication device according to the present embodiment. The communication device 2400 includes a communication blocking command receiving unit 2401 and a communication blocking unit 2402.
The “communication block command receiving unit” 2401 receives a communication block command. The communication blocking command is output by, for example, the communication blocking command output unit 2101. When described in XML, the communication blocking command is exemplified in FIG. A port for receiving a communication blocking command is prepared, and the communication blocking command receiving unit 2401 waits until a communication blocking command is transmitted to this port. Moreover, you may perform the process for authenticating that the program which output the communication prevention command is a legitimate program as needed.
The “communication blocking unit” 2402 blocks communication based on the communication blocking command received by the communication blocking command receiving unit 2401. For example, when the communication blocking instruction is as shown in FIG. 22, the relay of the communication packet going from the IP address of 192.168.193.063 to the 25th port of the computer having the IP address of 10.139.210.254 is performed. Do something like not.
(Embodiment 8: Processing of communication device)
FIG. 25 is a flowchart of processing of the communication device according to the present embodiment. The communication device repeatedly executes the processing shown by this flowchart.
In step S2501, the process waits until a communication blocking command is received. This processing is performed by the communication blocking command receiving unit 2401.
In step S2502, communication is blocked based on the communication block command. This processing is performed by the communication blocking unit 2402.
(Embodiment 8: Main effects)
According to the present embodiment, it is possible to prevent a program such as so-called spyware from transmitting computer data to the outside. In addition, it is possible to prevent transmission of e-mails transmitted by computer viruses that spread through e-mails.
(Embodiment 9)
As a ninth embodiment of the present invention, a computer virus detection apparatus that determines whether an application program has a computer virus property based on a history of breakpoints reached by the application program will be described.
(Embodiment 9: Configuration)
FIG. 26 illustrates a functional block diagram of the computer virus detection device according to the present embodiment. The computer virus detection apparatus 2600 includes a breakpoint information holding unit 901, a breakpoint setting unit 902, a determination program execution unit 903, and a history holding unit 2601. Therefore, the computer virus detection apparatus whose functional block diagram is illustrated in FIG. 26 is configured such that the computer virus detection apparatus according to the first embodiment includes the history holding unit 2601. Note that the computer virus detection device according to this embodiment may be the computer virus detection device according to any one of the other embodiments, that is, any one of the second to eighth embodiments, including the history holding unit 2601. Good.
A “history holding unit” 2601 holds a history of the application program reaching the breakpoint set by the breakpoint setting unit 902. “The application program” means an application program in which a breakpoint is set by the breakpoint setting unit 902.
Therefore, in this embodiment, when the execution of the application program reaches a breakpoint, for example, which breakpoint has been reached, its date and time, and if the breakpoint is a system call API function, its arguments, etc. are used as a history. to add. This processing may be performed by a determination program, or may be performed by a program included in the determination program or a part of the computer virus detection device 2600. When the history holding unit 2601 holds a history of breakpoints reached by a plurality of application programs, it is preferable that identification information for identifying the application program is also added as a history.
In the present embodiment, the determination program has a history inspection program. The “history inspection program” determines whether the application program has a computer virus property based on the history held by the history holding unit 2601.
For example, there is an application program called a so-called daemon program. The daemon program is an application program that resides in the computer, waits for a request to be received, and provides a service for the request. The contents of services provided by such a daemon program are standardized, and therefore the operation of the daemon program is almost constant. For example, among the daemon programs, an application program that returns a requested web page in response to a web page transmission request (for example, a program named Apache) is requested to a specific port. Wait until it is sent, open the file that stores the requested web page, read the file, return the read result, close the file, and write to the log file Repeat. Further, the file location to be opened has a characteristic that it is under a specific directory. Therefore, if a process deviating from such a certain process is performed, there is a high possibility that the daemon program is infected with a computer virus or worm. In this embodiment, in this way, it is determined whether or not the application program has a computer virus property.
As a more specific example, the number of times reached is recorded for each breakpoint, and if a breakpoint that has never been reached is reached, it is determined that the application program has a computer virus. Alternatively, if the breakpoint position is a system call API function, the rule of the argument is extracted based on the history, and if an argument that does not match the rule is given, the application program is a computer virus It is judged that it has. For example, if the file path rule specified when opening a file is extracted as a wildcard or regular expression, and you try to open a file whose path does not match the wildcard or regular expression, the application program Is determined to have computer virus properties.
Note that the present embodiment can be applied not only to the daemon program but also to other application programs. For example, the use of word processors and the like by ordinary people is a routine one. Therefore, when a call other than a system call that is called for routine use is called, it may be determined that the word processor has a computer virus property. Although a word processor is used as an example, it can also be applied to application programs such as a spreadsheet program, a presentation program, a mailer, and a browser.
(Embodiment 9: processing)
FIG. 27 illustrates a flowchart of processing of the computer virus detection device according to the present embodiment.
In step S2701, a breakpoint is set in the application program at the position indicated by the breakpoint position information.
In step S2702, the process waits until execution of the application program reaches a breakpoint.
In step S2703, a history of reaching the breakpoint is added.
In step S2704, a determination program is executed. Here, the history inspection program is also executed.
In step S2705, it is determined whether or not to end. If not finished, the process proceeds to step S2706.
In step S2706, execution of the application program is continued. Thereafter, the process proceeds to step S2702.
Note that the process of step S2703 may be performed after the determination program is executed.
(Embodiment 9: Main effects)
According to the present embodiment, since the computer virus nature is determined based on whether the operation of the application program shows a different tendency than before, it is useful for monitoring the behavior of a daemon program or the like that repeatedly performs a certain operation. . In addition, if there is a history of normal operations, it is possible to make a determination of a computer virus, making it easy to create a determination program.
(Embodiment 10)
As a tenth embodiment of the present invention, a computer virus detection apparatus in which an application program is a virtual machine will be described.
(Embodiment 10: Configuration)
FIG. 28 illustrates a usage pattern of the computer virus detection device according to the present embodiment. Inside the computer 2801, a computer virus detection device 2802 and a virtual machine 2803 are operating. The computer virus detection device 2802 is a program that realizes the computer virus detection device according to any one of the first to ninth embodiments. The computer virus detection device 2802 sets a breakpoint in the virtual machine 2803 and monitors the behavior.
A “virtual machine” is an application program that executes another program 2805. Usually, the other program 2805 is described by a machine instruction of a computer having an assumed architecture. A typical example is one that executes a compiled program described in Java (registered trademark). Since a Java (registered trademark) program is assumed to be downloaded from the Internet, in many cases, the source / feature is unknown and the program may be a dangerous program. Thus, for example, a Java (registered trademark) virtual machine is designed to restrict a program to be executed from freely using an API (2804) to an OS to access computer resources. However, there are cases where a program 2805 running on the virtual machine freely accesses computer resources by utilizing a bug in the virtual machine.
Therefore, whether or not the computer virus detection apparatus 2802 of this embodiment sets a breakpoint in the virtual machine 2803, detects the behavior of the virtual machine 2803, and the virtual machine 2803 is not executing a program having a computer virus property. Judging. In the present embodiment, the fact that a virtual machine has a computer virus property also means that the virtual machine executes a program having a computer virus property.
(Embodiment 10: Main effects)
According to the present embodiment, it is possible to prevent execution of a program that uses a bug of a virtual machine.
(Embodiment 11)
As an eleventh embodiment of the present invention, an embodiment in which the computer in the tenth embodiment is a mobile phone will be described.
(Embodiment 11: Configuration)
FIG. 29 illustrates a usage pattern of the computer virus detection device according to the present embodiment. A computer 2801 in FIG. 28 is replaced with a mobile phone 2901.
(Embodiment 11: Main effects)
There is a remarkable improvement in the functionality of mobile phones. For example, not only a browser for the Internet but also a Java (registered trademark) virtual machine operates inside a mobile phone. In addition, an operating system that has conventionally been operated on a personal computer is now operating inside a mobile phone, and a program that operates on the mobile phone is complicated.
However, bugs and security holes may be found after cell phone sales begin. On the other hand, the number of mobile phones more than personal computers is on the market, and collecting mobile terminals is costly and time consuming. For this reason, if a computer virus that exploits bugs or security holes in a virtual machine that runs on a mobile phone is created, the scale of the infection cannot be predicted, which has a great social impact. For example, using a bug in a virtual machine, address book data of any mobile phone is collected, leading to leakage of privacy information.
Therefore, a computer that exploits bugs, security holes, etc. by operating a program that implements the computer virus detection device of the present invention inside a mobile phone and detecting a behavior by setting a breakpoint in a virtual machine. It becomes possible to prevent the action of viruses.

As described above, according to the present invention, execution of a monitored process can be stopped or rolled back to a state before execution depending on whether or not a registered instruction is executed, thereby reducing the burden on the user compared to the conventional case. Can prevent virus infection and clean up the system.
In addition, since the present invention detects the behavior at the time of program execution, it does not require preprocessing such as decompression of the compressed file before scanning and decryption of the encrypted file, which are necessary in the conventional signature scan.
Therefore, the present invention is useful as a computer virus detection device.

[Document Name] Statement
[Detailed explanation]
[0001]
Technical field
[0002]
The present invention monitors the execution of a program that can be executed by e-mail, WEB, peer-to-peer file exchange software, etc. that is executed from outside the computer, such as the Internet, and the behavior of a computer virus. Or, it relates to detecting a behavior similar to a computer virus and taking measures such as stopping execution of a program.
[0003]
Background art
[0004]
Currently, the mainstream of detection techniques for computer viruses (hereinafter sometimes simply referred to as “viruses”) uses pattern matching. This technique is disclosed in, for example, Japanese Patent Application Laid-Open No. 2003-216444, Japanese Patent Application Laid-Open No. 2002-196942, and WO 02/087717 A1. Pattern matching focuses on a file on a computer memory or hard disk, and detects a virus by comparing it with a signature signature of a virus found in the past. Pattern matching is a technique with few false detections, but only known viruses can be detected.
[0005]
Currently, about 10 to 20 kinds of new viruses are found in one day. In order for computers used by regular users to be able to detect and deal with such new viruses, obtain frequently updated virus signature files from anti-virus companies promptly, Must be installed on the computer. By the way, there are many new viruses that have changed the past viruses a little. For this reason, the actual behavior of viruses is very similar. Nevertheless, the information pattern of virus programs is different, so each time a virus is found, a virus signature file must be installed.
[0006]
Virus detection technology includes heuristic scanning in addition to pattern matching. In the heuristic scan, a pseudo code is executed to determine whether or not a behavior similar to a virus is performed based on emulation. However, not all executable file instructions can be emulated. Also, it takes a very long time to emulate a virus with a large program size and / or complicated encryption.
[0007]
Disclosure of the invention
[0008]
In the present invention, a process such as a system call that can create a new process on a computer or attach to a running process (Attach) to monitor the process and make important changes to the computer By monitoring the behavior. Then, the behavior of the process to be monitored is compared with the characteristic behavior of past computer viruses. When the characteristic behavior of the virus is detected, the user is notified so that the process to be monitored can be stopped. Here, the monitoring target process mainly refers to a process connected to the Internet.
[0009]
FIG. 1 is a diagram conceptually illustrating the execution of a process in a computer. Applications 101 and 102, e-mail software 103, and WEB browser 104 operate in the upper layer. Of these, it is assumed that the application 102, the e-mail software 103, and the WEB browser 104 are processes for executing a program for introducing a program from outside the computer by connecting to the Internet. In the present invention, a security layer according to the present invention is provided between these processes and the system call API layer 105. This security layer is a layer that monitors the invocation of system calls.
[0010]
Below the system call API layer 105 is a kernel layer 106 that implements an operating system (hereinafter sometimes abbreviated as “OS”), and below that is a device driver / hardware 107 layer. .
[0011]
In an OS in a normal computer, processing is performed separately in a kernel mode and a user mode. A portion 108 above the system call API layer 105 is a portion where processing is performed in the user mode, and a portion 109 below the system call API layer 105 is a portion where processing is performed in the kernel mode.
[0012]
A process executing in user mode has a separate context and a virtual address space. Therefore, processes executed in the same user mode cannot access the memory of other processes.
[0013]
The present invention is based on the position of a breakpoint to be set when executing an application program, and when the execution of the application program reaches the breakpoint, the application program is stored in a computer virus based on the contents of the stack of the application program. And a determination program that determines whether or not it has a function. When a breakpoint is set in the application program and the execution of the application program reaches the breakpoint, the determination is held in association with the position of the breakpoint. A computer virus detection apparatus for executing a program is provided.
[0014]
The computer virus detection apparatus may hold an application program and set a breakpoint in the application program when the held application program is executed.
[0015]
The position of the breakpoint may be determined based on the system call API function. By doing so, the security layer of FIG. 1 is realized.
[0016]
Further, when the execution of the application program reaches a breakpoint, the argument of the system call API function may be checked.
[0017]
Further, when the system call API function changes the system resource, the computer virus detection device may generate a copy of the system resource before executing the system call.
[0018]
Further, the computer virus detection device may be configured to prevent the execution of the system call API function when it is determined that the application program has a computer virus property.
[0019]
Further, when the system call API function performs communication, the computer virus detection apparatus may output a command to an external communication device (for example, a router) so as to cause the communication to fail. .
[0020]
Further, whether or not the application program has a computer virus property may be determined based on a history of breakpoints reached by the application program.
[0021]
In the present invention, the application program may be a virtual machine for executing a program written in a language such as Java (registered trademark). Further, the virtual machine may operate on a mobile phone.
[0022]
In an OS including WINDOWS (registered trademark), as a method for controlling the behavior of a process, there is a method of writing a kernel driver and hooking a system call (for example, used in eTrust Access Control “Soft hook” of Computer Associates). Method). On the other hand, the monitoring of the behavior of the process according to the present invention is performed by using a function used in software development called a debugger.
[0023]
The behavior monitoring in the present invention is characterized in that it is all performed in the user mode, that is, the application layer. As a result, there is no occurrence of a fatal error such as a system down often caused when a kernel driver is used.
[0024]
In the following, in order to help understanding of the present invention, the function of a conventional debugger will be outlined.
[0025]
FIG. 2 illustrates the relationship between the process 201 for executing the application program and the debugger 202. (1) First, the debugger 202 attaches to the process 201. By the attachment, the relationship between the process 201 and the debugger 202 is managed by the OS. That is, the OS associates the process 201 with the debugger 202. For example, when a change occurs in the state of the process 201, the debugger 202 is notified. (2) Next, the debugger 202 sets a breakpoint in the process 201. “Breakpoint” indicates a memory address at which execution of the CPU is stopped when the program counter of the process 201 reaches a predetermined value. Designating such a memory address is called setting a breakpoint. A method for setting a breakpoint is realized by setting the memory address value indicated by the breakpoint in the CPU or by replacing the instruction at the memory address indicated by the program counter value of the breakpoint with a special instruction. (See, for example, Jonathan B. Rosenberg, “How Debuggers Work, Algorithms, Data Structures, and Architecture”, Wiley Computer Publishing, 1997). Thereafter, when the process 201 starts execution and reaches a breakpoint, (2) the OS is notified that execution has stopped. This notification is performed not by the process 201 but by a processing routine for processing the interrupt when the execution of the process reaches a breakpoint and the CPU is interrupted. Note that the processing routine is appropriately set by initializing the OS or the like. When the OS receives the notification, (4) the debugger 202 is notified, and the debugger 202 knows that the execution of the process 201 has reached a breakpoint. Thereafter, (5) debug operation of the process 201 is performed by the operation of the user of the debugger 202. As a typical debugging operation, the contents of the process stack are read, the sequence in which functions and procedures are called, and the values of arguments and variables are examined.
[0026]
Breakpoints are set for each process. Therefore, the description “set a breakpoint in the process that executes the application program” is accurate, but the description becomes longer. Therefore, in the following, the application program and the process that executes the application program are regarded as the same. , “Set breakpoint in application program”, etc.
[0027]
FIG. 3 illustrates how function and procedure calls in high-level languages are compiled in the prior art. In a high-level language, it is assumed that a function or procedure called “f (argument 1, argument 2,..., Argument n); . When this is compiled, it is converted into a machine instruction as indicated by reference numeral 302. That is, the argument is loaded on the stack by the push instruction, and finally f is called by “call f”. In many CPUs, when a machine instruction that calls a function such as call f is executed, a value set in the program counter is loaded on the stack when returning from the processing of the called function.
[0028]
FIG. 4 illustrates the compilation result of the function f. When f is called, first, the value of the frame pointer (fp) before the call of f is put on the stack by a machine instruction “push fp”. The “frame pointer” is a CPU register for indicating a portion of the stack for function calls. As will be described later, the frame pointer plays an important role in obtaining a function call sequence (call sequence). Next, the value of the stack pointer (sp) is set to the frame pointer (fp) by “move sp → fp”. As a result, the frame pointer (fp) points to the stack portion of f currently being called. Thereafter, the process f is performed. When returning from the call to f, the value of the frame pointer (fp) before the call to f is set by “pop fp”, and the process returns from the call to f by “ret”. For example, the value of the program counter stacked on the stack is set in the program counter.
[0029]
FIG. 5 illustrates a state in which values are stacked on the stack. The value stacked in the top part of the stack 501 (that is, the value stored in the top part of the stack) relates to the function currently being executed. , The argument values are stacked. In area 503, a program counter after the function call is stacked. The area 504 is loaded with the value of the frame pointer (fp) before the function call. An area 505 stores the values of automatic variables defined in the function. The frame pointer (fp) points to the upper part of the area 504, and the value accumulated in the area 504 is the position where the frame pointer (fp) accumulated in the stack 501 at the previous function call is stored. Pointing up. Therefore, by following the value of the frame pointer, it is possible to know through which call sequence the function is called. Further, by checking the value of the program counter loaded on the stack, it is possible to know from where in the program the function is called. In addition, it is possible to know what value is given to the function by examining the arguments stacked on the stack.
[0030]
The computer virus detection apparatus according to the present invention monitors the behavior of a process by using such a debugger function. However, in the debugger in the prior art, a human operates the debugger to investigate the process to be debugged, whereas the process behavior monitoring by the computer virus detection apparatus according to the present invention is automatically performed.
[0031]
The present invention also solves the problems associated with commercial software. Hereinafter, description will be made using spyware as an example. Spyware is an application program that sends information to its creator or caller over the Internet. Spyware behaves like a backdoor virus. Malicious spyware steals user information and keystrokes and sends information to other machines through a specific communication channel.
[0032]
However, many anti-virus companies do not detect commercial software such as spyware as their policy. This is because there is commercial software that erases the data used to destroy the hard disk, which may be sent as an email from a friend. Anti-virus does not detect programs that erase data as intended by the user.
[0033]
Therefore, even if the result of executing the program has an impact on a computer or a user's business, it is impossible to completely prevent these threats with the current anti-virus technology.
[0034]
Some of the current viruses are active on Linux (registered trademark), but they are predominantly active on WINDOWS (registered trademark). One reason for this is that most people using WINDOWS® have added administrator rights to the logged-on user. Administrator authority is necessary when installing an application, but WINDOWS (registered trademark) does not have the custom of temporarily becoming a root (privileged user) for a system administrator like UNIX (registered trademark). In WINDOWS (registered trademark), a suspicious file sent by e-mail is often executed as a privileged user such as an administrator.
[0035]
Administrator privileges have access to all resources of the system. In other words, you can tamper with important files necessary for the system to work. If a virus is executed in such an environment, important files on the computer may be altered, and computers around the world may be infected with the virus through the Internet. The execution environment of the program should be better protected for the user.
[0036]
BEST MODE FOR CARRYING OUT THE INVENTION
[0037]
Hereinafter, the best mode for carrying out the present invention will be described as an embodiment with reference to the drawings. Note that the present invention is not limited to these embodiments, and can be implemented in various modes without departing from the spirit of the present invention.
[0038]
(Outline of the present invention)
The present invention focuses on the behavior of the program and determines whether the program is a virus. A process embodying the present invention and a process to be monitored have a relationship similar to that of a debugger and a debuggee. The debugger corresponds to the process embodying the present invention, and the debug corresponds to the process to be monitored.
[0039]
The debugged process is called debuggee. The present invention executes the monitored process as a debuggee. When monitoring a running process, attach to the running process.
[0040]
The process embodying the present invention sets breakpoints in system calls (or API functions) that make significant changes to the system in order to check the behavior of the monitored process.
[0041]
In the case of an Intel (registered trademark) CPU, a breakpoint can be realized by placing a hardware interrupt instruction of Int3 at a memory address indicated by the breakpoint. When the execution of the process reaches a breakpoint, the execution of the process stops, and the computer virus detection apparatus according to the present invention investigates the contents of the stack of the process, and the behavior of the process to be monitored and the past Compare the characteristic behavior of computer viruses.
[0042]
The following are examples of characteristic behavior of viruses.
[0043]
• Copy yourself to the system folder.
[0044]
• Look for directories shared on the network. Then copy yourself.
[0045]
・ Access the mail address book and send a large number of mails with viruses attached.
[0046]
・ If file exchange software is installed, use it to distribute yourself.
[0047]
-Delete important system files. Or tamper.
[0048]
-Change the system so that it will run on reboot.
[0049]
The present invention compares the API call of the monitoring target process with the past behavior of a computer virus, etc., and stops the monitoring target process or issues a warning to the user.
[0050]
Hereinafter, WINDOWS (registered trademark) will be specifically described as an example. In WINDOWS (registered trademark), an API for manipulating files and directories is KERNEL32. It is included in a file called DLL. The API related to the registry is ADVAPI32. Included in the DLL. An API for operating a network shared drive is MPR. Included in the DLL. Hereinafter, these are called DLL files.
[0051]
A method for determining which API the monitored process is trying to call will be described below. When the monitored process starts executing, the DLL file is mapped to the virtual process space.
[0052]
FIG. 6 shows that the virtual process space 601 includes Kernel32. Dll, MRP. Dll, Advapi32. The state where Dll was mapped is illustrated. By performing the mapping in this manner, the monitoring target process is, for example, Adobe32. Functions such as RegCreateKeyEx defined in Dll can be called.
[0053]
FIG. 7 shows the virtual memory space of the process. The virtual memory space 700 has an instruction part 701, a heap part 702, a DLL part 703 to which a DLL file is mapped, and a stack part 704 from the smallest memory address. The portion 703 is located between the heap portion 702 and the stack portion 704, and the DLL file is mapped to the portion 703. That is, when a reference is made to the memory address of the portion 703, the contents of the DLL file stored as a file are obtained.
[0054]
The map address of the DLL file (the first address of the part where the DLL file is mapped to the virtual memory space) is called an image base, and is uniquely determined in each DLL so as not to overlap with the others.
[0055]
For example, an API called RegOpenKeyExA that operates the registry is ADVAPI32. Included in the DLL.
[0056]
The address of RegOpenKeyExA is obtained by “ADVAPI32.DLL image base” + “RegOpenKeyExA RVA”. Note that “RVA” is an abbreviation for “relative virtual address”. That is, it is a relative position where the API definition appears in the DLL file.
[0057]
When the address is obtained, a breakpoint is set using a debugger API or the like.
[0058]
When the execution of the monitored process hits a breakpoint, the API argument is analyzed.
[0059]
If the monitored process calls an API that changes the registry or system file, a backup is created in this step.
[0060]
If virus characteristics are detected, stop the process or report to the user. If not detected, processing continues.
[0061]
A specific example will be described. Many WINDOWS® viruses add a value to the following registry to run and resident in the system upon restart:
[0062]
HKEY_LOCAL_MACHINE \ SOFTWARE \ MICROSOFT \ Windows \ CurrentVersion \ Run
For reference, here are some major viruses that add values to this key:
[0063]
NIMDA, LOVELATERTER, TROJ_MATRIX, W32_MAGISTR, TROJ_HYBRIS, WORM_KLEZ, WORM_BUGBEAR, WORM_BADTRANS, JS_EXCEPTION, WORM_LIRBA
An unknown program received by e-mail may not need to reside in the system.
[0064]
To add the registry, the following two-step API call is required.
[0065]
RegCreateKeyExA ... Creates a new key under Run.
[0066]
RegSetValueExA ... Set the value.
[0067]
The top two APIs are ADVAPI32. Included in the DLL. Here, ADVAPI32. Assume that the image base of the DLL is 0x77D80000. The number 0x indicates a hexadecimal number. Further, it is assumed that the RVA of RegCreateKeyExA is 0x29427 and the RVA of RegSetValueExA is 0x2C58D.
[0068]
The address of RegCreateKeyExA is
0x77D80000 + 0x29427 = 0x77DA9427
The address of RegSetValueExA is
0x77D80000 + 0x2C58D = 0x77DAC58D
Is required. Since these are virtual address spaces, the DLL file is mapped with the same virtual address even if a plurality of processes are executed simultaneously.
[0069]
When asked for addresses, set breakpoints on them.
[0070]
If the process to be monitored is a program that is automatically executed when WINDOWS (registered trademark) is activated, a break point of RegCreateKeyExA is hit. Next, analyze the stack. This is because a compiler such as C language generates machine instructions that pass arguments through the stack.
[0071]
80000002 0041f028 ADVAPI32! RegCreateKeyExA
For example, assume that the above numerical values are obtained. When calling RegCreateKeyExA, the second argument is the location of the registry. In this example, the location of the registry is stored in the memory address 41f028. Therefore, the memory address 41f028 is checked.
[0072]
> 41f028
41f028 SOFTWARE \ Microsoft
41f038 ft \ Windows \ Cure
41f048 ntVersion \ Run \ Vi
41f058 rus
From the API and arguments, it can be seen that the monitoring process is trying to create a key called Virus under Run.
[0073]
In order to return to the state before the program execution, the Virus key may be deleted. Therefore, a history of changes in system resources such as a registry, a copy of system resources, and the like may be held before execution of a system call.
[0074]
Similarly, API necessary for grasping the behavior of the program is checked, and the tendency of the call is analyzed.
[0075]
It is desirable that the correspondence between the API for monitoring the call and the argument (hereinafter referred to as a detection rule) can be added or changed by reading a file describing the detection rule from the outside, for example, the Internet, instead of hard coding.
[0076]
With this method, there is no overhead of scanning the file. When the characteristic behavior of the virus is detected, it is preferable to display a dialog box or the like so that the process to be monitored can be stopped by the user's intention.
[0077]
Or, continue without executing the program. A flowchart is illustrated in FIG.
[0078]
(Embodiment 1)
As Embodiment 1 of the present invention, breakpoint position information and a determination program to be executed when an application program reaches a breakpoint indicated by the breakpoint position information are stored in association with each other, and the breakpoint is set in the application program A computer virus detection apparatus that executes a determination program will be described.
[0079]
(Embodiment 1: Configuration)
FIG. 9 illustrates a functional block diagram of the computer virus detection device according to the present embodiment. The computer virus detection apparatus 900 includes a breakpoint information holding unit 901, a breakpoint setting unit 902, and a determination program execution unit 903.
[0080]
As will become clear from the following description, a computer virus detection apparatus having these units can be realized as a program that runs on a computer. Therefore, FIG. 9 can also be interpreted as a diagram showing the module configuration of such a program. That is, such a program includes a breakpoint information holding step for realizing a breakpoint information holding unit by a program, a breakpoint setting step for realizing a breakpoint setting unit by a program, and a determination for realizing a judgment program execution unit by a program. A program for causing a computer to execute a program execution step.
[0081]
A “breakpoint information holding unit” 901 holds breakpoint information. For example, breakpoint information is held in a hard disk or semiconductor memory. “Breakpoint information” is information including breakpoint position information and a determination program. Since “includes”, the components of the breakpoint information may not be limited to the breakpoint position information and the determination program.
[0082]
“Breakpoint position information” is information indicating the position of a breakpoint to be set when the application program is executed. The position of the breakpoint is indicated by, for example, a memory address of the application program. It may also be indicated by the name of a function, procedure, or method (hereinafter referred to as “function or the like”) that is called by the application program.
[0083]
The “determination program” means whether or not the application program has a computer virus property based on the contents of the stack referred to in the execution of the application program when the execution of the application program reaches the breakpoint. This is a program for making a decision. “The application program” means an application program in which a breakpoint is set at a position indicated by breakpoint position information by a breakpoint setting unit 902 described later. The “breakpoint” means a breakpoint set at a position indicated by breakpoint position information.
[0084]
"Application program has computer virus" is designed not only when the application program itself is a computer virus, but also when the application program is infected with a computer virus, using bugs or security holes in the application program In some cases, such as when the operation is not expected. For example, there is a case where a malicious person performs an operation such as obtaining the contents of a file that cannot be obtained by a normal operation using a bug of the web server program.
[0085]
There are various methods for determining whether or not the application program has a computer virus property based on the contents of the stack referred to when the application program is executed. For example, it is determined whether or not the stack referred to in the execution of the application program can be traced from the top of the stack to the bottom of the stack by following the frame pointer. Some computer viruses call system calls and the like in such a manner that they are not called if the application program operates normally by destroying the contents of the stack. Therefore, it is determined whether or not the contents of the stack are destroyed. One of the judgments is that the application program has a computer virus property depending on whether it can follow the frame pointer and call up to a function called first in the execution of the program (for example, a function named _startup). Judge whether or not.
[0086]
In addition, when the application program reaches a breakpoint, it may be determined whether or not the application program has a computer virus property by checking through what call sequence the function is reached. If a breakpoint is reached after a sequence of calls such as an unexpected function, it is suspected to have a computer virus.
[0087]
Further, it may be determined whether or not the application program has a computer virus property by examining an argument such as a function in which a breakpoint is set. For example, a computer virus that infects other computers using e-mail accesses the address book of e-mail addresses in order to obtain e-mail addresses. Therefore, the determination may be made based on whether an argument for accessing the address book is specified.
[0088]
In many cases, the process for executing the program for realizing the computer virus detection device is different from the process for executing the application program. Usually, the program for realizing the computer virus detection device is the application program. The contents of the memory space of the executing process, especially the contents of the stack cannot be read. However, the operating system has a function that allows a certain process to read or change the contents of the memory space and registers of other processes if they are between processes in a specific relationship. It is normal. Examples of the “specific relationship” here include a parent-child relationship, a process executed by the same user, and a relationship in which a predetermined system call (for example, attach) is executed on another process, and so on. Therefore, when the computer virus detection apparatus is realized by a program, the process for executing the program and the process for executing the application program need to have a specific relationship.
[0089]
Most operating systems provide system calls for reading and changing the memory space and register contents of other processes. Alternatively, there may be a case where the contents of the memory space and registers of other processes can be read or changed using a special device called / dev / proc.
[0090]
For example, the determination program may be executed by an interpreter. For example, the determination program may be described in a language such as Lisp, Perl, or Ruby. Further, the determination program may consist of a sequence of machine instructions that can be directly executed by a computer. In this case, a determination program may be incorporated as a part of a program for realizing the computer virus detection device. Alternatively, the determination program may be loaded into a program that dynamically realizes a computer virus detection device, for example, as a dynamic library. If the determination program is executed by an interpreter or is dynamically loaded, the determination program can be easily replaced.
[0091]
FIG. 10 shows an example of a state in which breakpoint information is held by the breakpoint information holding unit 901. In FIG. 10A, breakpoint information is held in a table. A column 1001 stores breakpoint position information, and a column 1002 stores a determination program. FIG. 10B shows an example of a state in which a pointer to the determination program is stored in the table. The pointer points to a specific location within the memory space of the process executing the program that implements the computer virus detection device.
[0092]
FIG. 11 illustrates a state in which breakpoint information is provided for each application program. Thus, the breakpoint information holding unit 901 may hold breakpoint information for each application program.
[0093]
The “breakpoint setting unit” 902 sets breakpoint information in the application program based on the breakpoint information held by the breakpoint information holding unit 901. That is, a breakpoint is set at a position indicated by breakpoint position information included in the breakpoint information. This setting is performed using a system call or special device provided by the operating system. “Based on” means that, for example, when the breakpoint position information is expressed using a name of a function or the like, an address of the function or the like is obtained from the name of the function or the like. Correspondence between names of functions and their addresses and their addresses can be obtained by reading a symbol table of an application program.
[0094]
The “determination program execution unit” 903 executes the determination program included in the breakpoint information when the execution of the application program reaches the breakpoint set by the breakpoint setting unit 902. The “application program” is an application program in which a breakpoint is set by the breakpoint setting unit 902. The computer virus detection apparatus waits until the execution of the application program in which the breakpoint is set reaches the breakpoint. For this purpose, for example, a wait system call is called. When the execution of the application program reaches a breakpoint, (1) the processing of the computer virus detection device resumes from the wait system call, (2) determines which breakpoint has been reached, and (3) a determination program execution unit 903 To execute a judgment program. To determine which breakpoint the application program has reached, it is determined by obtaining the value of the program counter held in the register of the process executing the application program.
[0095]
(Embodiment 1: processing)
FIG. 12 illustrates a flowchart of processing of the computer virus detection apparatus.
[0096]
In step S1201, a breakpoint is set in the application program at the position indicated by the breakpoint position information. For example, this process is performed by the breakpoint setting unit 902.
[0097]
In step S1202, the execution of the application program waits until a breakpoint is reached. This process is realized, for example, by executing a wait system call.
[0098]
In step S1203, the determination program corresponding to the breakpoint at which the execution of the application program has been reached is executed. For example, this process is performed by the determination program execution unit 903.
[0099]
In step S1204, it is determined whether or not to end the process. For example, if it is determined by execution of the determination program in step S1203 that the application program has a computer virus property, the process ends. If it is determined not to end the process, the process proceeds to step S1205.
[0100]
In step S1205, the execution of the application program is continued. When the application program reaches a breakpoint, the execution of the application program stops, so that the processing is resumed from the point where it stopped. For example, a signal (for example, SIG_CONT) is sent to the process that executes the application program. Thereafter, the process proceeds to step S1202.
[0101]
The computer virus detection apparatus can be considered as an apparatus for using a computer virus detection method including a breakpoint information holding step, a breakpoint setting step, and a determination program execution step. “Breakpoint information holding step” is a step for holding breakpoint information. “Breakpoint setting step” is a step for setting a breakpoint in the application program based on the breakpoint information held in the breakpoint information holding step. The “determination program execution step” is a step of executing the determination program included in the breakpoint information when the execution of the application program reaches the breakpoint set in the breakpoint setting step. . That is, the breakpoint information holding step is a step that operates the breakpoint information holding unit, the breakpoint setting step is a step that operates the breakpoint setting unit, and the determination program execution step executes the determination program execution unit. It is a step. The use of the computer virus detection method according to the present invention is not limited to the computer virus detection apparatus according to the present invention.
[0102]
(Embodiment 1: Main effects)
According to the present embodiment, since the behavior of a process for executing an application program can be monitored by a computer virus detection device without modifying the kernel of the operating system, the occurrence of a system down can be avoided. Become. In addition, since the behavior of computer viruses is often very similar, the necessity of continuing to update the pattern file to the latest one, which was necessary in conventional anti-virus software, is reduced. Update is unnecessary.
[0103]
(Embodiment 2)
As a second embodiment of the present invention, a computer virus detection apparatus that holds an application program will be described.
[0104]
FIG. 13 illustrates a display screen by the computer virus detection apparatus according to the present embodiment. A window 1301 is a window displayed by the computer virus detection device according to the present embodiment. An application program icon is displayed in the sub-window 1302 of the window. If necessary, an icon (eg, icon 1304) displayed outside the window 1301 can be dragged and moved to the inside of the sub-window 1302. By double-clicking an icon (for example, icon 1303) displayed in the sub window 1302, a process for executing the application program is generated as a child process of the process for executing the computer virus detection device, and its behavior is monitored. Is done.
[0105]
(Embodiment 2: Configuration)
FIG. 14 illustrates a functional block diagram of the computer virus detection device according to the present embodiment. The computer virus detection apparatus 1400 includes a breakpoint information holding unit 901, a breakpoint setting unit 902, a determination program execution unit 903, an application program holding unit 1401, a program execution start unit 1402, a breakpoint setting instruction unit 1403, Have.
[0106]
Therefore, in the computer virus detection device according to the present embodiment, the computer virus detection device according to the first embodiment further includes an application program holding unit 1401, a program execution start unit 1402, and a breakpoint setting command unit 1403. It has a configuration. In the present specification, the same reference numerals are assigned to parts to which the same definition is applied as much as possible. It should be noted that assignment of the same code does not mean that the same configuration or the like is obtained in actual manufacturing or the like.
[0107]
An “application program holding unit” 1401 holds an application program. There are various forms of holding. For example, there is a form in which the entire application program is stored. Further, there may be a form of storing a location where an application program is stored, for example, a path expressed in a file system.
[0108]
The “program execution start unit” 1402 starts execution of the application program held by the application program holding unit 1401. For example, execution of an application program is started as a child process of a process that executes a program for realizing a computer virus detection device.
[0109]
A “breakpoint setting instruction unit” 1403 instructs the breakpoint setting unit 902 to set a breakpoint for an application program whose execution is started by the program execution start unit 1402. For example, a function for realizing the breakpoint setting unit 902 is called.
[0110]
(Embodiment 2: processing)
FIG. 15 illustrates a flowchart of processing of the computer virus detection device according to the present embodiment.
[0111]
In step S1501, the application program is held. This process is performed by the application program holding unit 1401. For example, in FIG. 13, it is detected that the icon 1304 has been dragged into the sub-window 1302, and an application program represented by the icon 1304 is held.
[0112]
In step S1502, the process waits until an application program is selected. For example, in FIG. 13, the process waits until an icon inside the sub window 1302 is double-clicked.
[0113]
In step S1503, a command is issued to set a breakpoint at the position indicated by the breakpoint position information in the selected application. This processing is performed by the breakpoint setting command unit 1403.
[0114]
In step S1504, the process waits for completion of the breakpoint setting. For example, it waits until it returns from a call of a function that implements the breakpoint setting unit 902.
[0115]
In step S1505, the selected application program is executed. More precisely, a process for executing the selected application program is executed. After step S1505, step S1202, step S1203, step S1204, and step S1205 in the flowchart of FIG. 12 are executed. In recent operating systems, it is possible to operate a plurality of threads in parallel / parallel in one process. Therefore, execution of step S1202, step S1203, step S1204, and step S1205 may be performed by a thread different from the thread that executes the flowchart of FIG.
[0116]
In step S1506, it is determined whether or not to end the process. For example, the determination is made based on whether the operator of the computer virus detection apparatus has pressed the end button. If not completed, the process returns to step S1502.
[0117]
(Embodiment 2: Main effects)
According to this embodiment, it is possible to easily generate a process for executing an application program whose behavior is to be monitored. In addition, application programs that are not likely to introduce a computer virus from the outside can be excluded from monitoring, so the speed at which such application programs are executed is not reduced by setting breakpoints. .
[0118]
(Embodiment 3)
As a third embodiment of the present invention, a computer virus detection apparatus that sets a breakpoint in a system call API function and monitors the behavior of a process will be described.
[0119]
(Embodiment 3: Configuration)
The computer virus detection apparatus according to the present embodiment is configured so that the breakpoint information held by the breakpoint information holding unit 901 of the computer virus detection apparatus according to the first or second embodiment is determined based on the system call API function of the application program. It is a thing.
[0120]
The “system call API function” means a library function for calling a system call. Such a library function or the like is normally configured such that an argument for a system call is loaded on the stack and a trap instruction is executed. By executing the trap instruction, an interrupt routine set in the CPU by the operating system is started, and processing inside the operating system is started. Since it is difficult to directly express a process of loading arguments and executing a trap instruction in a high-level language, a library function for performing such a process is prepared.
[0121]
FIG. 16 illustrates breakpoint information in the present embodiment. In FIG. 16, RegCreateKeyExA is the name of the system call API function. Therefore, when the breakpoint setting unit sets a breakpoint, it is necessary to convert the name of the system call API function into an address. The conversion process is as described in the overview section.
[0122]
(Embodiment 3: Main effects)
Since a computer virus often infects a computer itself using a system call API function, by detecting the call of the system call API function and determining whether the application program has a computer virus property, It is possible to make an accurate judgment with fewer breakpoints.
[0123]
(Embodiment 4)
As a fourth embodiment of the present invention, a computer virus detection apparatus that makes a determination based on examination of arguments of a system call API function will be described.
[0124]
(Embodiment 4: Configuration)
The computer virus detection apparatus according to the present embodiment has a configuration in which the system call inspection program is included in the determination program in the computer virus detection apparatus according to the third embodiment. The “system call inspection program” is a program for determining whether or not the application program has a computer virus property based on the inspection of the argument of the system call API function called by the application program. “The application program” means an application program in which a breakpoint is set by the breakpoint setting unit 902.
[0125]
Therefore, in this embodiment, when the execution of the application program reaches a breakpoint, the argument of the system call API function of the application program is checked. Based on the result of this inspection, it is determined whether or not the application program has a computer virus property.
[0126]
In the present embodiment, the system call API function whose argument is checked is not limited to the one in which a breakpoint is set. For example, all the machine instructions of the application program may be examined, and the arguments of all system call API functions may be examined. The argument of the system call API function at the reached breakpoint may be stored, and when the breakpoint is reached later, the argument may be checked in the stored system call API function.
[0127]
(Embodiment 4: Main effects)
In the present embodiment, since the computer virus property is determined based on the examination of the argument of the system call API function, the determination can be made more accurately.
[0128]
(Embodiment 5)
As a fifth embodiment of the present invention, a computer virus detection apparatus for inspecting an argument of a system call API function at a reached breakpoint will be described.
[0129]
(Embodiment 5: Configuration)
The computer virus detection apparatus according to the present embodiment is a system in which an argument to be inspected by the system call inspection program is determined by breakpoint position information held by the breakpoint information holding unit 901 in the computer virus detection apparatus according to the fourth embodiment. This is an argument of the call API function.
[0130]
For example, as illustrated in FIG. 16, when a breakpoint is set in a system call API function called RegCreateKeyExA, and the execution of the application program reaches the breakpoint, the system call inspection program sets an argument of RegCreateKeyExA. inspect. An example of the inspection is as described in the overview section of the present invention.
[0131]
(Embodiment 5: Main effects)
According to the present embodiment, since the computer virus property is determined based on the examination of the argument of the called system call API function, the determination can be made more accurately.
[0132]
(Embodiment 6)
As a sixth embodiment of the present invention, a computer virus detection apparatus that generates a copy of a changed system resource when a system call API function that changes the system resource is called will be described.
[0133]
(Embodiment 6: Configuration)
The computer virus detection apparatus according to the present embodiment has a configuration in which a copy creation program is included in the determination program in the computer virus detection apparatus according to the fourth or fifth embodiment. The “copy creation program” generates a copy of the changed system resource when the system resource is changed by the system call API function of the application program. “The application program” is an application program in which breakpoints are set by the breakpoint setting unit 902.
[0134]
Accordingly, in the present embodiment, the breakpoint position information indicates the position of the system call API function that changes the system resource. The system resource here means, for example, a resource that can be duplicated among resources used by a computer, such as a registry and a file.
[0135]
For example, a break point is set in the system call API function for changing the registry, and when the execution of the application program reaches the break point, a copy creation program for copying the registry is executed. When a copy is created, the registry is changed by a system call. In duplicating the registry, the entire registry may be duplicated, or only the part to be changed may be duplicated. The part to be changed in the registry can be determined by an argument of the system call API function.
[0136]
In the present embodiment, the copy creation program may be executed when it is determined that the application program has a computer virus property. As a result, the amount of duplicates to be created can be reduced.
[0137]
(Embodiment 6: processing)
FIG. 17 illustrates a flowchart of processing of the computer virus detection device according to the present embodiment.
[0138]
In step S1701, a breakpoint is set in the application program at the position indicated by the breakpoint position information.
[0139]
In step S1702, the process waits until execution of the application program reaches a breakpoint.
[0140]
In step S1703, a determination program is executed.
[0141]
In step S1704, it is determined whether the execution result of the determination program is that the application program has a computer virus property. If it has a computer virus property, the process proceeds to step S1705, and if not, the process is skipped to step S1707.
[0142]
In step S1705, it is determined whether the application program is changing the system resource. This determination can be made by examining the type of system call API function related to the reached breakpoint and its argument. If the system resource is to be changed, the process proceeds to step S1706, and if not, the process is skipped to step S1707.
[0143]
In step S1706, a copy of the system resource is created by the copy creation program.
[0144]
In step S1707, it is determined whether to end the entire process. If it is determined not to end, the process proceeds to step S1708.
[0145]
In step S1708, execution of the application program is continued, and the process proceeds to step S1702. Even if the application program is a computer virus and the system resource is changed to an illegal one, the system can be restored by the copy created in step S1706.
[0146]
(Embodiment 6: Main effects)
In this embodiment, since a copy of the system resource to be changed is created, even if the application program is a computer virus and the computer is infected, the system can be recovered using the copy of the system resource.
[0147]
(Embodiment 7)
As a seventh embodiment of the present invention, a computer virus detection apparatus that does not execute a system call API function when an application program is determined to have a computer virus property will be described.
[0148]
(Embodiment 7: Configuration)
FIG. 18 illustrates a functional block diagram of the computer virus detection device according to the present embodiment. The configuration of the computer virus detection device according to the present embodiment is such that any one of the computer virus detection devices according to the first to sixth embodiments includes an execution blocking unit. Therefore, for example, the computer virus detection apparatus 1800 includes a breakpoint information holding unit 901, a breakpoint setting unit 902, a determination program execution unit 903, and an execution prevention unit 1801. In addition, the computer virus detection apparatus 1800 may include an application program holding unit, a program execution start unit, and a breakpoint setting command unit.
[0149]
As a result of the determination by the determination program execution unit 903, the “execution prevention unit” 1801 does not execute the system call API function of the application program when it is determined that the application program to be determined has a computer virus property. It is a part for.
[0150]
When the use of the stack is illustrated in FIG. 5, the execution prevention unit 1801 uses the value of the frame pointer (fp) to calculate the value of the frame pointer before the function call stored in the part 504. It is acquired and set to the frame pointer (fp), and the value of the program counter is set to the value stored in the part 503 so that the system call API function is not executed.
[0151]
(Embodiment 7: processing)
FIG. 19 illustrates a flowchart of processing of the computer virus detection device according to the present embodiment.
[0152]
In step S1901, a breakpoint is set in the application program at the position indicated by the breakpoint position information.
[0153]
In step S1902, the process waits until execution of the application program reaches a breakpoint.
[0154]
In step S1903, a determination program is executed.
[0155]
In step S1904, it is determined as a result of the determination program whether the application program has a computer virus property. If it has a computer virus property, the process proceeds to step S1905, and if not, the process is skipped to step S1906.
[0156]
In step S1905, the system call API function is not executed. In this process, the execution prevention unit 1801 is used.
[0157]
In step S1906, it is determined whether to end the entire process. If not finished, the process proceeds to step S1907.

In step S1907, execution of the application program is continued. Thereafter, the process proceeds to step S1902.
[0158]
(Embodiment 7: Main effects)
In the present embodiment, since dangerous system calls are prevented from being executed, for example, when a macro program of a specific word processor has a computer virus property, the execution of the dangerous macro program without stopping the function of the word processor. Thus, it is possible to continue the execution of the application program while preventing the execution of a dangerous system call.
[0159]
(Embodiment 8)
As an eighth embodiment of the present invention, a computer virus detection apparatus and a communication device for blocking communication of an application program having a computer virus property will be described.
[0160]
FIG. 20 illustrates an overview of the present embodiment. A computer 2001 is connected to an external communication network 2003 via a communication device 2002. A typical example of the communication device 2002 is a router. Inside the computer 2001, a process 2004 for executing an application program and a process 2005 for realizing a computer virus detection apparatus operate. The process 2005 monitors the behavior of the process 2004. If an application program executed by the process 2004 has a computer virus property, an attempt is made to communicate with the outside 2006. In this case, the process 2005 considers that the process 2004 is performing harmful communication to the outside, and outputs a communication blocking instruction 2007 to the communication device 2002 in order to block the harmful communication. Based on the communication blocking instruction 2007, the communication device 2002 blocks communication by not relaying a packet of communication to be performed by the process 2004.
[0161]
(Embodiment 8: Configuration of computer virus detection apparatus)
FIG. 21 illustrates a functional block diagram of the computer virus detection apparatus according to the present embodiment. The configuration of the computer virus detection device according to the present embodiment is such that the computer virus detection device according to any one of Embodiments 1 to 7 has a communication blocking command output unit. For example, the computer virus detection device 2100 includes a breakpoint information holding unit 901, a breakpoint setting unit 902, a determination program execution unit 903, and a communication blocking instruction output unit 2101.
[0162]
The “communication blocking instruction output unit” 2101 determines that, as a result of the determination by the determination program execution unit 903, the application program to be determined has a computer virus property, the application program sends a communication system call API function. When executing, a communication blocking command is output. The “communication blocking instruction” is an instruction for causing an external communication device to fail communication using the communication system call API function executed by the application program.
[0163]
For example, a system call API function for communication in order for an application program determined to have a computer virus property to transmit data to the outside of the computer or to receive data from the outside of the computer. Is executed, an instruction to fail the communication is output to an external communication device such as a router.
[0164]
FIG. 22 shows an example of a communication blocking command. In this example, the communication blocking instruction is described as a structured document such as XML. In FIG. 22, for example, in FIG. 20, the IP address of the computer 2001 is 192.168.193.063, the process 2004 is the communication with the IP address of 10.139.210.254, and the port is No. 25. A communication blocking command output when an attempt is made is shown. Such a communication blocking command may be output to an external communication device by, for example, SOAP (Simple Object Access Protocol).
[0165]
(Embodiment 8: Processing of computer virus detection device)
FIG. 23 illustrates a flowchart of processing of the computer virus detection device according to the present embodiment.
[0166]
In step S2301, a breakpoint is set in the application program at the position indicated by the breakpoint position information.
[0167]
In step S2302, the process waits until execution of the application program reaches a breakpoint.
[0168]
In step S2303, a determination program is executed.
[0169]
In step S2304, it is determined whether the application program has a computer virus. If it is determined that the computer virus is present, the process proceeds to step S2305; otherwise, the process skips to step S2307.
[0170]
In step S2305, it is determined whether the reached breakpoint is a communication system call API function. If it is a communication system call API function, the process proceeds to step S2306; otherwise, the process is skipped to step S2307.
[0171]
In step S2306, a communication blocking command is output to an external communication device. This processing is performed by the communication block command output unit 2101.
[0172]
In step S2307, it is determined whether or not to end the entire process. If not finished, the process proceeds to step S2308.
[0173]
In step S2308, execution of the application program is continued. Even if harmful communication is performed following execution, communication is blocked by the communication blocking command output in step S2306.
[0174]
(Embodiment 8: Configuration of communication device)
FIG. 24 illustrates a functional block diagram of the communication device according to the present embodiment. The communication device 2400 includes a communication blocking command receiving unit 2401 and a communication blocking unit 2402.
[0175]
The “communication block command receiving unit” 2401 receives a communication block command. The communication blocking command is output by, for example, the communication blocking command output unit 2101. When described in XML, the communication blocking command is exemplified in FIG. A port for receiving a communication blocking command is prepared, and the communication blocking command receiving unit 2401 waits until a communication blocking command is transmitted to this port. Moreover, you may perform the process for authenticating that the program which output the communication prevention command is a legitimate program as needed.
[0176]
The “communication blocking unit” 2402 blocks communication based on the communication blocking command received by the communication blocking command receiving unit 2401. For example, when the communication blocking instruction is as shown in FIG. 22, the relay of the communication packet going from the IP address of 192.168.193.063 to the 25th port of the computer having the IP address of 10.139.210.254 is performed. Do something like not.
[0177]
(Embodiment 8: Processing of communication device)
FIG. 25 is a flowchart of processing of the communication device according to the present embodiment. The communication device repeatedly executes the processing shown by this flowchart.
[0178]
In step S2501, the process waits until a communication blocking command is received. This processing is performed by the communication blocking command receiving unit 2401.
[0179]
In step S2502, communication is blocked based on the communication block command. This processing is performed by the communication blocking unit 2402.
[0180]
(Embodiment 8: Main effects)
According to the present embodiment, it is possible to prevent a program such as so-called spyware from transmitting computer data to the outside. In addition, it is possible to prevent transmission of e-mails transmitted by computer viruses that spread through e-mails.
[0181]
(Embodiment 9)
As a ninth embodiment of the present invention, a computer virus detection apparatus that determines whether an application program has a computer virus property based on a history of breakpoints reached by the application program will be described.
[0182]
(Embodiment 9: Configuration)
FIG. 26 illustrates a functional block diagram of the computer virus detection device according to the present embodiment. The computer virus detection apparatus 2600 includes a breakpoint information holding unit 901, a breakpoint setting unit 902, a determination program execution unit 903, and a history holding unit 2601. Therefore, the computer virus detection apparatus whose functional block diagram is illustrated in FIG. 26 is configured such that the computer virus detection apparatus according to the first embodiment includes the history holding unit 2601. Note that the computer virus detection device according to this embodiment may be the computer virus detection device according to any one of the other embodiments, that is, any one of the second to eighth embodiments, including the history holding unit 2601. Good.
[0183]
A “history holding unit” 2601 holds a history of the application program reaching the breakpoint set by the breakpoint setting unit 902. “The application program” means an application program in which a breakpoint is set by the breakpoint setting unit 902.
[0184]
Therefore, in this embodiment, when the execution of the application program reaches a breakpoint, for example, which breakpoint has been reached, its date and time, and if the breakpoint is a system call API function, its arguments, etc. are used as a history. to add. This processing may be performed by a determination program, or may be performed by a program included in the determination program or a part of the computer virus detection device 2600. When the history holding unit 2601 holds a history of breakpoints reached by a plurality of application programs, it is preferable that identification information for identifying the application program is also added as a history.
[0185]
In the present embodiment, the determination program has a history inspection program. The “history inspection program” determines whether the application program has a computer virus property based on the history held by the history holding unit 2601.
[0186]
For example, there is an application program called a so-called daemon program. The daemon program is an application program that resides in the computer, waits for a request to be received, and provides a service for the request. The contents of services provided by such a daemon program are standardized, and therefore the operation of the daemon program is almost constant. For example, among the daemon programs, an application program that returns a requested web page in response to a web page transmission request (for example, a program named Apache) is requested to a specific port. Wait until it is sent, open the file that stores the requested web page, read the file, return the read result, close the file, and write to the log file Repeat. Further, the file location to be opened has a characteristic that it is under a specific directory. Therefore, if a process deviating from such a certain process is performed, there is a high possibility that the daemon program is infected with a computer virus or worm. In this embodiment, in this way, it is determined whether or not the application program has a computer virus property.
[0187]
As a more specific example, the number of times reached is recorded for each breakpoint, and if a breakpoint that has never been reached is reached, it is determined that the application program has a computer virus. Alternatively, if the breakpoint position is a system call API function, the rule of the argument is extracted based on the history, and if an argument that does not match the rule is given, the application program is a computer virus It is judged that it has. For example, if the file path rule specified when opening a file is extracted as a wildcard or regular expression, and you try to open a file whose path does not match the wildcard or regular expression, the application program Is determined to have computer virus properties.
[0188]
Note that the present embodiment can be applied not only to the daemon program but also to other application programs. For example, the use of word processors and the like by ordinary people is a routine one. Therefore, when a call other than a system call that is called for routine use is called, it may be determined that the word processor has a computer virus property. Although a word processor is used as an example, it can also be applied to application programs such as a spreadsheet program, a presentation program, a mailer, and a browser.
[0189]
(Embodiment 9: processing)
FIG. 27 illustrates a flowchart of processing of the computer virus detection device according to the present embodiment.
[0190]
In step S2701, a breakpoint is set in the application program at the position indicated by the breakpoint position information.
[0191]
In step S2702, the process waits until execution of the application program reaches a breakpoint.
[0192]
In step S2703, a history of reaching the breakpoint is added.
[0193]
In step S2704, a determination program is executed. Here, the history inspection program is also executed.
[0194]
In step S2705, it is determined whether or not to end. If not finished, the process proceeds to step S2706.
[0195]
In step S2706, execution of the application program is continued. Thereafter, the process proceeds to step S2702.
[0196]
Note that the process of step S2703 may be performed after the determination program is executed.
[0197]
(Embodiment 9: Main effects)
According to the present embodiment, since the computer virus nature is determined based on whether the operation of the application program shows a different tendency than before, it is useful for monitoring the behavior of a daemon program or the like that repeatedly performs a certain operation. . In addition, if there is a history of normal operations, it is possible to make a determination of a computer virus, making it easy to create a determination program.
[0198]
(Embodiment 10)
As a tenth embodiment of the present invention, a computer virus detection apparatus in which an application program is a virtual machine will be described.
[0199]
(Embodiment 10: Configuration)
FIG. 28 illustrates a usage pattern of the computer virus detection device according to the present embodiment. Inside the computer 2801, a computer virus detection device 2802 and a virtual machine 2803 are operating. The computer virus detection device 2802 is a program that realizes the computer virus detection device according to any one of the first to ninth embodiments. The computer virus detection device 2802 sets a breakpoint in the virtual machine 2803 and monitors the behavior.
[0200]
A “virtual machine” is an application program that executes another program 2805. Usually, the other program 2805 is described by a machine instruction of a computer having an assumed architecture. A typical example is one that executes a compiled program described in Java (registered trademark). Since a Java (registered trademark) program is assumed to be downloaded from the Internet, in many cases, the source / feature is unknown and the program may be a dangerous program. Thus, for example, a Java (registered trademark) virtual machine is designed to restrict a program to be executed from freely using an API (2804) to an OS to access computer resources. However, there are cases where a program 2805 running on the virtual machine freely accesses computer resources by utilizing a bug in the virtual machine.
[0201]
Therefore, whether or not the computer virus detection apparatus 2802 of this embodiment sets a breakpoint in the virtual machine 2803, detects the behavior of the virtual machine 2803, and the virtual machine 2803 is not executing a program having a computer virus property. Judging. In the present embodiment, the fact that a virtual machine has a computer virus property also means that the virtual machine executes a program having a computer virus property.
[0202]
(Embodiment 10: Main effects)
According to the present embodiment, it is possible to prevent execution of a program that uses a bug of a virtual machine.
[0203]
(Embodiment 11)
As an eleventh embodiment of the present invention, an embodiment in which the computer in the tenth embodiment is a mobile phone will be described.
[0204]
(Embodiment 11: Configuration)
FIG. 29 illustrates a usage pattern of the computer virus detection device according to the present embodiment. A computer 2801 in FIG. 28 is replaced with a mobile phone 2901.
[0205]
(Embodiment 11: Main effects)
There is a remarkable improvement in the functionality of mobile phones. For example, not only a browser for the Internet but also a Java (registered trademark) virtual machine operates inside a mobile phone. In addition, an operating system that has conventionally been operated on a personal computer is now operating inside a mobile phone, and a program that operates on the mobile phone is complicated.
[0206]
However, bugs and security holes may be found after cell phone sales begin. On the other hand, the number of mobile phones more than personal computers is on the market, and collecting mobile terminals is costly and time consuming. For this reason, if a computer virus that exploits bugs or security holes in a virtual machine that runs on a mobile phone is created, the scale of the infection cannot be predicted, which has a great social impact. For example, using a bug in a virtual machine, address book data of any mobile phone is collected, leading to leakage of privacy information.
[0207]
Therefore, a computer that exploits bugs, security holes, etc. by operating a program that implements the computer virus detection device of the present invention inside a mobile phone and detecting a behavior by setting a breakpoint in a virtual machine. It becomes possible to prevent the action of viruses.
[0208]
Industrial applicability
[0209]
As described above, according to the present invention, execution of a monitored process can be stopped or rolled back to a state before execution depending on whether or not a registered instruction is executed, thereby reducing the burden on the user compared to the conventional case. Can prevent virus infection and clean up the system.
[0210]
In addition, since the present invention detects the behavior at the time of program execution, it does not require preprocessing such as decompression of the compressed file before scanning and decryption of the encrypted file, which are necessary in the conventional signature scan.
[0211]
Therefore, the present invention is useful as a computer virus detection device.
[Brief description of the drawings]
FIG. 1 is a diagram conceptually illustrating execution of a process on a computer in the prior art.
FIG. 2 is a diagram illustrating the relationship between a process for executing an application program and a debugger in the prior art.
FIG. 3 is a diagram illustrating how function and procedure calls in a high-level language are compiled in the prior art.
FIG. 4 is a diagram illustrating a result of function compilation in the prior art
FIG. 5 is a diagram illustrating a state in which values are stacked on a stack in the prior art.
FIG. 6 is a diagram illustrating a state in which a DLL file is mapped in a virtual process space in the prior art.
FIG. 7 is a diagram showing a virtual memory space of a process in the prior art
FIG. 8 is a diagram illustrating a flowchart of processing in the present invention.
FIG. 9 is a functional block diagram of the computer virus detection device according to the first embodiment of the invention.
FIG. 10 is a diagram illustrating an example of a state in which breakpoint information is held
FIG. 11 is a diagram illustrating a state in which breakpoint information is provided for each application program
FIG. 12 is a diagram illustrating a flowchart of processing of a computer virus detection device
FIG. 13 is a diagram illustrating a display screen by the computer virus detection device according to the second embodiment of the invention.
FIG. 14 is a diagram illustrating a functional block diagram of a computer virus detection device according to the second embodiment of the invention;
FIG. 15 is a flowchart of processing of a computer virus detection apparatus.
FIG. 16 is a diagram illustrating breakpoint information according to the third embodiment of the present invention.
FIG. 17 is a flowchart of processing of a computer virus detection apparatus.
FIG. 18 is a functional block diagram of a computer virus detection apparatus according to Embodiment 7 of the present invention.
FIG. 19 is a flowchart of processing of a computer virus detection apparatus.
FIG. 20 is a diagram illustrating an outline of an eighth embodiment of the present invention;
FIG. 21 is a functional block diagram of a computer virus detection device according to an eighth embodiment of the present invention.
FIG. 22 is a diagram showing an example of a communication blocking command
FIG. 23 is a flowchart of processing of a computer virus detection apparatus.
FIG. 24 is a functional block diagram of a communication device according to an eighth embodiment of the present invention.
FIG. 25 is a flowchart of processing of a communication device.
FIG. 26 is a functional block diagram of a computer virus detection apparatus according to the ninth embodiment of the present invention.
FIG. 27 is a diagram illustrating a flowchart of processing of a computer virus detection device
FIG. 28 is a diagram illustrating a usage pattern of the computer virus detection device according to the tenth embodiment of the invention;
FIG. 29 is a diagram illustrating a usage pattern of the computer virus detection device according to the eleventh embodiment of the present invention;

Claims (14)

Breakpoint position information, which is information indicating the position of the breakpoint to be set when executing the application program, and the contents of the stack that is referenced when executing the application program when the execution of the application program reaches the breakpoint A breakpoint information holding unit for holding breakpoint information that is information including a determination program for determining whether the application program has a computer virus property based on
A breakpoint setting unit for setting a breakpoint based on the breakpoint information held in the breakpoint information holding unit in the application program;
A determination program execution unit that executes a determination program included in the breakpoint information when execution of the application program reaches a breakpoint set in the breakpoint setting unit;
A computer virus detection device. An application program holding unit for holding application programs;
A program execution start unit for starting execution of the application program held in the application program holding unit;
A breakpoint setting command unit for instructing the breakpoint setting unit to set a breakpoint for an application program whose execution is started by the program execution start unit;
The computer virus detection device according to claim 1, comprising: The computer virus detection device according to claim 1, wherein the breakpoint position information held by the breakpoint information holding unit is determined based on a system call API function of the application program. 4. The system call inspection program according to claim 3, wherein the determination program includes a system call inspection program for determining whether or not the application program has a computer virus property based on an inspection of an argument of a system call API function of the application program. The computer virus detection device described 5. The computer virus detection device according to claim 4, wherein the argument to be inspected by the system call inspection program is an argument of a system call API function defined by breakpoint position information held by the breakpoint information holding unit. The determination program is
Claim 4 or Claim 5 includes a copy creation program for creating a copy of the changed system resource when the system resource is changed by executing the system call API function of the application program. The computer virus detection apparatus as described. As a result of the determination by the determination program execution unit, when it is determined that the application program to be determined has a computer virus property, the system call API function of the application program determined to have the computer virus property is executed. The computer virus detection device according to claim 4 or claim 5, further comprising an execution blocking unit for preventing the execution. As a result of the determination by the determination program execution unit, when it is determined that the application program to be determined has a computer virus property, when executing the communication system call API function with which the application program performs communication, 5. The computer virus detection according to claim 4, further comprising: a communication block instruction output unit that outputs a communication block instruction that is a command for causing communication apparatus to fail communication by a communication system call API function executed by an application program. apparatus. A history holding unit that holds a history of the application program reaching the breakpoint set in the breakpoint setting unit;
2. The computer virus detection apparatus according to claim 1, wherein the determination program includes a history inspection program for determining whether the application program has a computer virus property based on the history held by the history holding unit. . The computer virus detection apparatus according to claim 1, wherein the application program is a virtual machine. The computer virus detection device according to claim 10, wherein the virtual machine operates in a mobile phone. A communication blocking command receiving unit for receiving the communication blocking command;
A communication device having a communication blocking unit for blocking communication based on the communication blocking command received by the communication blocking command receiving unit. Breakpoint position information, which is information indicating the position of the breakpoint to be set when executing the application program, and the contents of the stack that is referred to when executing the application program when the execution of the application program reaches the breakpoint A breakpoint information holding step for holding breakpoint information that is information including a determination program for determining whether the application program has a computer virus property based on
A breakpoint setting step for setting a breakpoint on the application program based on the breakpoint information held by the breakpoint information holding step;
A determination program execution step for executing a determination program included in the breakpoint information when the execution of the application program reaches the breakpoint set in the breakpoint setting step;
A computer virus detection program that causes a computer to execute. Breakpoint position information, which is information indicating the position of the breakpoint to be set when executing the application program, and the contents of the stack that is referred to when executing the application program when the execution of the application program reaches the breakpoint A breakpoint information holding step for holding breakpoint information that is information including a determination program for determining whether the application program has a computer virus property based on
A breakpoint setting step for setting a breakpoint on the application program based on the breakpoint information held by the breakpoint information holding step;
A determination program execution step for executing a determination program included in the breakpoint information when the execution of the application program reaches the breakpoint set in the breakpoint setting step;
A computer virus detection method including:

Images