CN109145598B

CN109145598B - Virus detection method and device for script file, terminal and storage medium

Info

Publication number: CN109145598B
Application number: CN201710465968.5A
Authority: CN
Inventors: 王炳堪; 崔精兵; 郭晓龙; 于涛; 屈亚鑫; 张洁烽; 郭长宇; 赵子云
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2017-06-19
Filing date: 2017-06-19
Publication date: 2021-01-22
Anticipated expiration: 2037-06-19
Also published as: CN109145598A

Abstract

The application discloses a script file detection method, a script file detection device, a script file detection terminal and a script file storage medium, and belongs to the field of virus detection. The method comprises the following steps: in the running process of an object program, running a monitoring code included in a monitoring file injected in the object program in advance, wherein the object program is a program integrated with a script virtual machine; through the operation of the monitoring code, a method name and/or script parameters used when at least one calling function pointer is called are obtained, wherein the at least one calling function pointer refers to a calling function pointer of a distribution interface of an automation object called in the process of operating the non-PE script file by the target program; and performing virus detection on the non-PE script file based on the acquired method name and/or script parameters. The method and the device have the advantages that dynamic virus detection of the non-PE script file is realized, a script virtual machine does not need to be developed independently for the non-PE script file, development cost of the script virtual machine is reduced, and detection efficiency is improved.

Description

Virus detection method and device for script file, terminal and storage medium

Technical Field

The present invention relates to the field of virus detection, and in particular, to a method, an apparatus terminal, and a storage medium for detecting a virus in a script file.

Background

The script file is a computer programming file, including a non-PE (Portable Executable) script file. The non-PE script file is a script file that cannot be directly executed on the operating system of the terminal and needs to be executed by the script virtual machine. Programs such as WScript (script host), a browser, Office series software and the like on a common terminal are all integrated with a script virtual machine, and can run non-PE script files. In practical applications, in order to ensure the security of the operating system, virus detection is usually performed on the non-PE script file in the terminal to determine whether the non-PE script file is a virus file.

At present, virus detection software developed by security manufacturers is basically used, and a static detection method is adopted to perform virus detection on non-PE script files, namely, a characteristic matching mode is adopted to perform virus detection. Because the non-PE script file is usually encrypted, before performing the feature matching, the non-PE script file needs to be run through a script virtual machine integrated in the virus detection software to obtain a decrypted non-PE script file, then a virus feature is sequentially taken out from the virus feature library to be matched with the decrypted non-PE script file, whether the virus feature exists in the non-PE script file is checked, if so, the non-PE script file is determined to be a virus file, and if not, the next virus feature is continuously matched until all the virus features are traversed.

However, different non-PE script files may use different scripting languages, and one script virtual machine can only decrypt a non-PE script file of one scripting language, so that in order to implement virus detection of non-PE script files of multiple scripting languages, multiple script virtual machines need to be developed, which is very costly. Moreover, since the code amount of the script virtual machine is often large, the script virtual machine will also affect the detection efficiency of the virus detection software.

Disclosure of Invention

In order to solve the problems that a plurality of script virtual machines need to be developed, the development cost is high and the operation efficiency is affected in the related art, the embodiment of the invention provides a virus detection method, a device, a terminal and a storage medium for a script file. The technical scheme is as follows:

in a first aspect, a virus detection method for a script file is provided, where the method includes:

in the running process of an object program, running a monitoring code included in a monitoring file injected in the object program in advance, wherein the object program is a program integrated with a script virtual machine;

obtaining a method name and/or script parameters used when at least one calling function pointer is called through the running of the monitoring code, wherein the at least one calling function pointer refers to a calling function pointer of a distribution interface of an automation object called in the process of running a non-portable executable PE script file by the target program, and the automation object refers to a component object model COM object integrated with the distribution interface;

and performing virus detection on the non-PE script file based on the obtained method name and/or script parameters.

In a second aspect, an apparatus for detecting a virus in a script file is provided, the apparatus comprising:

the system comprises an operation module, a monitoring module and a monitoring module, wherein the operation module is used for operating a monitoring code included in a monitoring file injected in advance in an object program in the operation process of the object program, and the object program is a program integrated with a script virtual machine;

the acquisition module is used for acquiring a method name and/or script parameters used when at least one calling function pointer is called through the running of the monitoring code, wherein the at least one calling function pointer refers to a calling function pointer of a distribution interface of an automation object called in the process of running a non-portable executable PE script file by the target program, and the automation object refers to a component object model COM object integrated with the distribution interface;

and the detection module is used for carrying out virus detection on the non-PE script file based on the acquired method name and/or script parameters.

In a third aspect, there is provided a terminal, including a processor and a memory, where the memory stores at least one instruction, at least one program, a code set, or a set of instructions, and the instruction, the program, the code set, or the set of instructions is loaded and executed by the processor to implement the virus detection method for a script file according to the first aspect.

In a fourth aspect, there is provided a computer-readable storage medium, wherein at least one instruction, at least one program, a set of codes, or a set of instructions is stored in the storage medium, and the instruction, the program, the set of codes, or the set of instructions is loaded and executed by a processor to implement the virus detection method for a script file according to the first aspect.

The technical scheme provided by the embodiment of the invention has the following beneficial effects:

in the embodiment of the invention, in the process of actually running the non-PE script file by a program, the behavior of calling function pointers of a distribution interface of an automation object is monitored by a pre-injected monitoring file, and the method names and/or script parameters used when all the calling function pointers are called are obtained. That is, the dynamic virus detection of the non-PE script file can be realized through the injected monitoring file on the basis of the automatic COM component architecture used by the non-PE script file, so that a script virtual machine supporting multiple non-PE scripting languages does not need to be separately developed for the non-PE script file, and virus detection is performed on the non-PE script file through running the developed script virtual machine, so that the development cost of the script virtual machine is reduced, and the detection efficiency is improved.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings needed to be used in the description of the embodiments will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.

FIG. 1A is a flowchart of a virus detection method for a script file according to an embodiment of the present invention;

FIG. 1B is a COM basic principle diagram;

FIG. 1C is a schematic diagram of a scripting virtual machine running a non-PE script file;

FIG. 1D is a diagram illustrating a table of function pointers for automation objects according to an embodiment of the present invention;

FIG. 2 is a flowchart of another virus detection method for script files according to an embodiment of the present invention;

fig. 3A is a block diagram of an apparatus for detecting a script file according to an embodiment of the present invention;

fig. 3B is a schematic structural diagram of an obtaining module 302 according to an embodiment of the present invention;

FIG. 3C is a block diagram of another apparatus for detecting script files according to an embodiment of the present invention;

FIG. 3D is a block diagram of an apparatus for detecting a script file according to an embodiment of the present invention;

fig. 4 is a schematic structural diagram of a terminal 400 according to an embodiment of the present invention.

Detailed Description

In order to make the objects, technical solutions and advantages of the present invention more apparent, embodiments of the present invention will be described in detail with reference to the accompanying drawings.

Before explaining the embodiments of the present invention in detail, terms, application scenarios and implementation environments related to the embodiments of the present invention will be briefly described.

First, terms related to embodiments of the present invention will be described.

Script file

The script file is a file written in a certain format using a specific script language. Scripting languages are computer programming languages created to shorten the traditional "edit-complex-link-run" process.

PE file

The PE file is a Program file that can be directly executed on an operating system, and common EXE (Executable Program), COM (Component Object Model), DLL (Dynamic Link Library), and the like are PE files and are mainly used in operating systems such as 32-bit or 64-bit Windows.

COM

COM refers to an object-oriented programming mode, defines the behavior mode of an object in a single application program or among a plurality of application programs, and is a software component technology for interaction between a web server and a client, and between a gain set and Office series software.

Automation objects

An automation object refers to a COM object integrated with an IDispatch (distribution) interface.

DLL

A DLL refers to a type of software file that includes various types of functions. In an operating system such as Windows, many application programs are not a complete executable file, and are divided into relatively independent dynamic link libraries, i.e., DLL files, which are placed in the operating system. When an operating system executes a program, the corresponding DLL file is called. An application may have multiple DLL files, and a DLL file may also be shared by several applications.

Interface

An interface refers to communication rules between different functional layers of the same computer program, and the communication rules are often abstracted into a set of functions.

Function pointer

A function pointer refers to a variable that points to an address in program memory space from which a piece of instruction is the head of a function.

Next, an application scenario of the embodiment of the present invention will be described.

In practical applications, a terminal usually stores non-PE script files, or can download the non-PE script files in an operation process, some non-PE script files may include malicious codes, so that the terminal may generate malicious modification behaviors to the terminal in the operation process of the non-PE script files, and the non-PE script files are virus files.

For example, some non-PE script files may include some virus codes, and the terminal may perform virus infection on the operating system by running the PE script file, that is, malicious modification on the operating system is about to be performed, thereby affecting the security of the terminal. For another example, some non-PE script files may include websites of malicious websites such as yellow websites, promotional websites, or websites carrying viruses, and the terminal running the PE script file will force access to the malicious websites, thereby affecting the normal use of the user.

Therefore, in order to ensure the security of the terminal and the normal use of the user, it is also necessary to perform virus detection on the non-PE script file in the terminal to determine whether the non-PE script file is a virus file.

Finally, an environment in which embodiments of the present invention are implemented is described.

The embodiment of the present invention is applied to a terminal, which may be a computer, a smart phone, a tablet computer, a notebook computer, a netbook, a personal digital assistant, and the like.

The terminal stores the non-PE script file, or can download the non-PE script file in the running process, and the terminal needs to perform virus detection on the stored or downloaded non-PE script file. For example, the terminal may implement virus detection on the non-PE script file through installed security software. The security software may be a security housekeeper or antivirus software, etc.

The non-PE script file is mainly used in an operating system of the terminal, and the operating system of the terminal may be a computer operating system such as a Windows operating system, a Unix operating system, a Linux operating system, a Mac OS operating system, or a mobile Phone operating system such as an IOS operating system, an android operating system, a Windows Phone operating system, or the like.

Fig. 1A is a flowchart of a virus detection method for a script file according to an embodiment of the present invention, where the method is used in a terminal. Referring to fig. 1A, the method includes:

step 101: in the running process of the target program, running monitoring codes included in a monitoring file injected in the target program in advance, wherein the target program is a program integrated with a script virtual machine.

The target program may be WScript, browser, WPS, Office, PowerShell (a command line shell program and scripting environment), and other programs.

In the embodiment of the invention, the monitoring file can be injected into the process of the target program in advance when the target program is started, and the monitoring file can be operated in the operation process of the target program.

The monitoring file comprises a monitoring code, the monitoring code is used for monitoring the process of the target program running the non-PE script file, and is specifically used for monitoring the behavior of calling the distribution interface of the automation object in the process of the target program running the non-PE script file, analyzing whether the calling behavior can maliciously modify the terminal or not when the calling behavior of the distribution interface is monitored, and determining whether the running non-PE script file is a virus file or not.

In practical application, for a non-PE script file, if specific operations such as reading and writing the file, connecting a network, and the like are to be implemented in the running process of the non-PE script file, the non-PE script file must interact with the underlying operating system, and an interface interacting with the operating system is also a distribution interface of an automation object. Therefore, in the embodiment of the invention, the actual operation which is required to be realized by the non-PE script file can be analyzed by monitoring the behavior of calling the distribution interface in the process of running the non-PE script file, so that the virus detection is carried out on the non-PE script file. That is, in the embodiment of the present invention, it is not necessary to determine whether the non-PE script file is encrypted or not, and it is not necessary to determine which script language is used by the non-PE script file, but rather, dynamic virus detection may be performed on the running non-PE script file in the actual running process of the non-PE script file.

The monitoring code is a technical implementation code written by a developer and used for realizing the functions, and in practical application, the monitoring code can be compiled into a monitoring file so as to be injected into the process of a target program subsequently. For example, the monitoring file may be a DLL file.

Further, the monitoring file can be injected into the target program through a driver file pre-loaded in the terminal, the driver file is used for monitoring whether the target program is started, and when the target program is monitored to be started, the monitoring file is injected into the process of the target program.

The target program may be set by default by the terminal or manually by the user, which is not limited in the embodiment of the present invention. For example, the terminal may install security software, where the security software includes a driver file and a monitoring file, a user may start the installation software in the terminal, and may set one or more target programs in a setting interface of the security software, so that the security software may monitor the start of the target program set by the user through the driver file, and when monitoring that any target program is started, the monitoring file may be injected into the process of the target program.

Step 102: and through the operation of the monitoring code, acquiring a method name and/or script parameters used when at least one calling function pointer is called, wherein the at least one calling function pointer refers to a calling function pointer of a distribution interface of an automation object called in the process of operating the non-PE script file by the target program.

In practical applications, during the running process of the object program, the object program may run the non-PE script file through the integrated script virtual machine. For example, when the target program is a browser, the browser may run the non-PE script file embedded in a web page during the process of opening the web page. For another example, when the target program is a word, the word may run a non-PE script file embedded in a word document during the process of opening the word document. Furthermore, a call function pointer of a distribution interface of the automation object may be called during the running of the non-PE script file by the object program.

And the at least one calling function pointer is all calling function pointers called in the process of running the non-PE script file by the target program. The monitoring code in the monitoring file is specifically used for monitoring the behavior of calling a function pointer of a distribution interface of an automation object in the process of running the non-PE script file by the target program, and is used for acquiring a method name and/or a script parameter used when the function pointer is called when the behavior of calling the function pointer of the distribution interface is monitored.

The method name refers to a method name of a called automation object, and the script parameter refers to a script parameter corresponding to the method name in the non-PE script file.

The automation object refers to a COM object integrated with a distribution interface, and is specifically realized by a COM technology and an automation technology. For ease of understanding the present application, the COM technology, automation technology, and automation objects will be explained in detail below.

COM technology

In practical applications, the COM technology is provided by operating system manufacturers in order to facilitate various transactions performed by the terminals. The COM technology is a componentization programming technology irrelevant to languages, developers can select a specific language tool to realize development of COM components according to specific conditions, data and methods for completing certain functions can be bound together specifically and abstracted into a COM object, and one COM object can complete a specific business logic processing calculation task.

Moreover, the COM technology customizes a set of binary standards, and as long as the programming language conforms to the set of binary standards, the COM object can be provided for other programs to use, and the COM object provided by other programs can also be used. The binary standard of COM has a function pointer table, each item in the table is a function pointer, the application program calls the corresponding function by indexing the function pointer in the memory, and transmits the parameter and obtains the return value according to the signature of the interface function, thereby completing the function. There is one such table of function pointers in the memory of any COM object.

The bottom layer of the operating system is usually packaged with a plurality of COM objects, and in the running process of a program, various functions can be conveniently realized by calling the COM objects of the bottom layer.

Fig. 1B is a COM basic principle diagram. As shown in fig. 1B, the COM technology provides an interface pointer (pointer to interface) for each COM object, and the interface pointer corresponds to an interface (interface) of the COM object. The interface of the COM object comprises a function pointer table pointer (pointer to vtable), the function pointer table pointer corresponds to the function pointer table (vtable) of the interface, and the function pointer table comprises a plurality of function pointers (method pointers).

Automation technology

The automation technology is established on the basis of the COM technology, and is a technology provided by operating system manufacturers for solving the problem of the operation of a script language on an operating system. Theoretically, any scripting language running on an operating system such as Windows can use automation technology, and in fact, multiple scripting languages such as JavaScript, VBScript, Office macro, JScript and PowerShell apply automation technology.

The core of the automation technology is a distribution interface, namely an IDispatch interface, which is a standard interface for realizing exposure of the automation COM object.

Automation objects

The automation object is a COM object which realizes an automation technology and is integrated with an IDispatch interface.

Each automation object supports a plurality of methods, each method being used to implement a specific transaction under the function to which the automation object corresponds. For example, the plurality of methods may include a method of implementing a download, a method of implementing an access to a website, a method of implementing an operation program, and the like.

Each automation object corresponds to one IDispatch interface and comprises a function pointer table, the function pointer table comprises a plurality of function pointers, and one function pointer is a calling function pointer, namely an Invoke function pointer.

For example, if the COM object indicated in fig. 1B is an automation object implementing automation technology, the interface in fig. 1B is an IDispatch interface, and the function pointer table of the IDispatch interface includes an Invoke function pointer.

During the running process of the non-PE script file, the method of the automation object needs to be called by calling an Invoke function pointer of an IDispatch interface of the automation object. Specifically, based on the method of the automation object and the script parameter of the method object in the non-PE script file, an Invoke function pointer of the IDispatch interface is called, the Invoke function pointer is called to transfer to an Invoke function, then a method function corresponding to the method is called through the Invoke function, and the actual operation corresponding to the method is realized through the method function.

That is, if the non-PE script file wants to complete the interaction with the outside (e.g., reading and writing the file, connecting to the network), it calls the method of the automation object provided by the operating system, and such calling must pass through the Invoke function pointer of the IDispatch interface. Therefore, in the embodiment of the present invention, the call behavior of the non-PE script file can be monitored by using the HOOK function pointer. The "HOOK" refers to touching the entry point of the function to be modified and changing its address to jump to the custom function. In the embodiment of the invention, the HOOK Invoke function pointer can be used for monitoring the files.

Specifically, step 102 may be implemented by steps 1021-:

step 1021: and acquiring function pointer tables of distribution interfaces of all automation objects required to be called in the process of running the non-PE script file by monitoring the running of the code, wherein each function pointer table comprises a calling function pointer corresponding to the distribution interface of the automation object.

In practical applications, when a target program runs a non-PE script file, a script interpreter corresponding to a scripting language of the non-PE script file is usually integrated to perform syntax interpretation and lexical interpretation on the non-PE script file, so as to obtain method names and object names of all automation objects that need to be called by the non-PE script file. And then creating automation objects based on all the obtained object names, and acquiring a function pointer table of each automation object.

The step of creating the automation object refers to acquiring the automation object corresponding to the object name from the disk according to the object name, storing the acquired automation object in the memory, and then initializing the automation object so as to call the automation object later. And the created automation object includes the function pointer table of the automation object, i.e., the created function pointer table of the automation object will be stored in the memory together with the automation object.

Fig. 1C is a schematic diagram of a script virtual machine running a non-PE script file, and referring to fig. 1C, the code of the non-PE script file is:

“Var ws＝new ActiveXObject(‘WScript.Shell’)ws.Run(‘notepad.exe’)

the script language used by the non-PE script file is a JavaScript script language, and the script virtual machine is a JavaScript script virtual machine. In practical applications, the JavaScript script virtual machine may be integrated into an object program, and the object program may be a program such as a browser.

In the process of running the non-PE script file by the JavaScript script virtual machine, firstly, the JavaScript script virtual machine performs grammar interpretation and lexical interpretation on the non-PE script file to obtain two names, one is wsscript. Shell is the COM object name, corresponding to the WShell automation object, and Run is the method name corresponding to the automation object.

Then, the JavaScript script virtual machine calls a CoCreateInstance function to create a WshShell automation object corresponding to the object name, and obtains a function pointer table of an IDispatch interface of the object. The creating wshell automation object implementation code may be pDispatch CoCreateInstance (CLSID _ iwshell).

Step 1022: and modifying the obtained calling function pointer in each function pointer table into a self-defined function pointer.

Specifically, the monitoring file of the object program can monitor the behavior of creating the automation object in the process of running the non-PE script file, and when the behavior of creating the automation object is monitored, the calling function pointer in the function pointer table of each automation object in all the created automation objects can be modified into the custom function pointer.

After a calling function pointer in a function pointer table of an automation object is modified into a self-defined function pointer, when the calling function pointer of a distribution interface of the automation object needs to be called in the process of running the non-PE script file, the self-defined function pointer is actually called.

The self-defined function pointer may include two functions, the first function is used to obtain a method name and/or a script parameter used when the self-defined function pointer is called, and the second function is a function of the original calling function pointer, that is, may also be used to call a method function corresponding to the method name based on the used method name and the script parameter.

For example, referring to fig. 1D, the created function pointer table of the automation object includes a plurality of function pointers, which may specifically include function pointers such as Queryinterface, getidsofnamees, Invoke, run, Exec, and the like.

Step 1023: and monitoring the process of the target program running the non-PE script file.

Specifically, the behavior of calling the custom function pointer in the process of running the non-PE script file by the target program can be monitored through the modified custom function pointer.

Step 1024: and when the self-defined function pointer is monitored to be called in the process of running the non-PE script file, acquiring the method name and/or script parameters used when the self-defined function pointer is called.

That is, when the target program calls the custom function pointer of the distribution interface of the automation object through the method name of a certain custom object and the script parameter corresponding to the method name in the process of running the non-PE script file, the method name and/or the script parameter used in the calling can be obtained through the custom function pointer.

Specifically, referring to fig. 1C, after creating the automation object, the JavaScript script virtual machine may first call the getidseofnames method of IDispatch to obtain the ID (Identification) of the name of the method "Run". The method name acquisition implementation code is as follows:

“ID_Run＝pDispatch->GetIDsOfNames(‘Run’)”。

in the COM component architecture of the existing non-PE script file, referring to fig. 1C, when a method function corresponding to a method name needs to be called, the JavaScript script virtual machine may call an Invoke function pointer of IDispatch by using the obtained ID of the method name and a script parameter corresponding to the method name, and call the method function corresponding to the method name through the Invoke function pointer. The script parameter corresponding to the recipe name is a parameter 'normal.exe' of the Run function, and the implementation code for calling the Invoke function pointer is as follows:

“Ret＝pDispatch->Invoke(ID_Run，‘notepad.exe’)”。

in the embodiment of the invention, the COM component architecture of the existing non-PE script file can be modified through the running monitoring code, that is, the behavior of the non-PE script file for creating the automation object is monitored, and when the behavior of creating the automation object is monitored, the call function pointer in the function pointer table of the created automation object is modified into the custom function pointer. Then in the process of running the non-PE script file, when an Invoke function pointer table of the IDispatch needs to be called, the JavaScript script virtual machine of the target program calls a self-defined function pointer in the function pointer table of the IDispatch by using the obtained ID and the script parameters of the Run function in the non-PE script file, transfers the ID to a self-defined function through the self-defined function pointer, and obtains the method name and/or the script parameters used when the self-defined function pointer is called through the self-defined function.

Based on the embodiment shown in fig. 1C, after the Invoke function pointer table is modified into the custom function pointer My Invoke by the method provided by the embodiment of the present invention, the implementation code for calling the custom function pointer My Invoke is "Ret ═ pDispatch- > My Invoke (ID _ Run,' statepad.

Step 103: and performing virus detection on the non-PE script file based on the acquired method name and/or script parameters.

The virus detection is carried out on the non-PE script file based on the obtained method name and/or script parameters, and the method comprises any one of the following modes:

the first implementation mode comprises the following steps: and carrying out virus detection on the non-PE script file based on the acquired method name.

Specifically, the operation behavior corresponding to the obtained method name may be determined first, and then it may be determined whether the non-PE script file is a virus file based on the determined operation behavior.

The method name may be used to indicate a specific operation behavior, for example, the method name of the downloading method may be used to indicate a downloading operation, and the method name of the method for accessing the network may be used to indicate a behavior for accessing the network, so that an operation flow that the non-PE script file is desired to implement may be determined according to the operation behaviors corresponding to the obtained multiple method names, and whether the non-PE script file is a virus file may be determined according to the operation flow.

For example, the operation behaviors corresponding to the obtained method names are respectively downloading and running, and it is described that the operation flow that the non-PE script file is intended to implement is downloading first and running later, generally, such an operation behavior of downloading first and running later generally has a great risk, for example, a virus may be downloaded and then a virus is run, or a program that is not installed by a user is forcibly downloaded and then the program is installed and run, so when the operation behaviors corresponding to the obtained method names are respectively downloading and running, the non-PE script file can be determined as a virus file.

Of course, in practical applications, when the obtained method name corresponds to other risk operation behaviors, the non-PE script file may also be determined to be a virus file, which is not limited in the embodiment of the present invention.

The second implementation mode comprises the following steps: and performing virus detection on the non-PE script file based on the obtained script parameters.

The script parameter is a part of script codes obtained by decrypting the non-PE script file through a script virtual machine of the target program, and can reflect the substantial characteristics of the script, so that virus detection can be performed on the script parameter in a characteristic matching manner.

Specifically, the features in the first virus feature library may be sequentially matched with the obtained script parameters, and if the obtained script parameters include a preset number of features in the preset virus feature library, the non-PE script file is determined to be a virus file, and the features in the first virus feature library include script parameter features.

The first virus feature library may be a virus feature library of the security software, or may be another virus feature library stored by a terminal other than the security software, or may be a virus feature library in a cloud, which is not limited in the embodiment of the present invention. The preset number may be set by a default of the terminal or by a user, which is not limited in the embodiment of the present invention.

For example, a first virus feature library may be stored in the security software, and when the script parameters are obtained through the user-defined function pointer, the obtained script may be referred to and matched with features in the preset virus feature library, that is, a feature is sequentially taken out from the preset virus feature library and matched with each obtained script parameter, whether the feature exists in the script parameter is checked, and if the feature exists, the script parameter is determined to be matched with the feature until all virus features are traversed. And if the preset number of the obtained script parameters are matched with the characteristics in the first virus characteristic library, determining that the non-PE script file is a virus file.

For another example, when the obtained script parameter is a website, the website may be sequentially matched with a risk website in the browser, and when the website is the same as a certain stored risk website, the non-PE script file is determined to be a virus file.

The third implementation mode comprises the following steps: and carrying out virus detection on the non-PE script file based on the obtained method name and script parameters.

Specifically, the features in the second virus feature library are sequentially matched with the character string composed of the acquired method name and the script parameters, if the preset number of features in the second virus feature library exist in the character string composed, the non-PE script file is determined to be a virus file, and the features in the second virus feature library include method name features and script parameter features.

That is, each acquired method name and corresponding script parameter may be combined into a sub-string, each combined character string is sequentially matched with the features in the second virus feature library, and when a method name in a combined character string is matched with a method name feature in a certain feature and a script parameter feature in the character string is also matched with a script parameter feature in the feature, it is determined that the combined character string is matched with the feature. And when the character strings with the preset number in the formed character strings are matched with the characteristics in the second virus characteristic library, determining that the non-PE script file is a virus file.

Further, in order to kill viruses in the non-PE script file, after performing virus detection on the non-PE script file based on the obtained method name and/or script parameter, the method further includes: if the non-PE script file is determined to be a virus file, ending running the non-PE script file, and/or displaying reminding information, wherein the reminding information is used for reminding the non-PE script file of being the virus file; if the non-PE script file is determined not to be a virus file, calling a corresponding method function based on the obtained method name and the script parameter so as to complete the operation of the non-PE script file.

When the non-PE script file is determined not to be the virus file, the non-PE script file is indicated to have no virus codes, so that the method function corresponding to the method name used when the user-defined function pointer is called can be called based on the method name and the script parameters used when the user-defined function pointer is called, and the actual operation corresponding to the method is realized. Specifically, the method function corresponding to the method name can be called by calling the calling function pointer corresponding to the self-defined function pointer.

However, when it is determined that the non-PE script file is a virus file, in order to avoid the risk, the currently moving non-PE script file may be ended, that is, the calling of the method function corresponding to the acquired method name is stopped, so as to avoid malicious damage to the terminal in the process of calling the method function corresponding to the method name. Or, a prompting message may be displayed to prompt the user that the non-PE script file is a virus file, so that the user manually ends the running of the non-PE script file according to the prompting message, and performs antivirus on the non-PE script file. Alternatively, the non-PE script file of the current motion may be ended, and the reminder message may be displayed to indicate to the user why the non-PE script file has ended running.

Further, when it is determined that the non-PE script file is a virus file, the virus feature of the non-PE script file may be added to a preset virus feature library, or the non-PE script file may be uploaded to a server, so that the server updates a virus database, and the like.

Fig. 2 is a flowchart of another virus detection method for a script file according to an embodiment of the present invention, where the method is used in a terminal. Referring to fig. 2, the method includes:

step 201: in the running process of the target program, running monitoring codes included in a monitoring file injected in the target program in advance, wherein the target program is a program integrated with a script virtual machine.

For a specific implementation process, reference may be made to step 101, which is not described herein again.

Step 202: and acquiring function pointer tables of distribution interfaces of all automation objects required to be called in the process of running the non-PE script file by monitoring the running of the code, wherein each function pointer table comprises a calling function pointer corresponding to the distribution interface of the automation object.

The specific implementation process may refer to step 1021 in step 102, which is not described herein again.

Step 203: and modifying the obtained calling function pointer in each function pointer table into a self-defined function pointer.

The specific implementation process may refer to step 1022 in step 102, which is not described herein again.

Step 204: and monitoring the process of the target program running the non-PE script file.

The specific implementation process may refer to step 1023 in step 102, which is not described herein again.

Step 205: and when the self-defined function pointer is monitored to be called in the process of running the non-PE script file, acquiring the method name and/or script parameters used when the self-defined function pointer is called.

The specific implementation process may refer to step 1024 in step 102, which is not described herein again.

Step 206: and performing virus detection on the non-PE script file based on the acquired method name and/or script parameters.

For a specific implementation process, reference may be made to step 103, which is not described herein again.

Step 207: and if the non-PE script file is determined to be the virus file, ending the operation of the non-PE script file.

In another embodiment, if it is determined that the non-PE script file is a virus file, a reminding message may be displayed to remind the user that the non-PE script file is a virus file.

Step 208: if the non-PE script file is determined not to be a virus file, calling a corresponding method function based on the obtained method name and the script parameter so as to complete the operation of the non-PE script file.

For a specific implementation process, reference may be made to the related description in the embodiment shown in fig. 1A, which is not described herein again.

Fig. 3A is a block diagram of an apparatus for detecting a script file according to an embodiment of the present invention, where the apparatus may be a terminal, and referring to fig. 3A, the apparatus includes:

an operation module 301, configured to perform step 101 in the embodiment described in fig. 1A above;

an obtaining module 302, configured to perform step 102 in the embodiment described in fig. 1A above;

a detecting module 303, configured to perform step 103 in the embodiment described in fig. 1A.

Optionally, referring to fig. 3B, the obtaining module 302 includes:

a first obtaining unit 3021, configured to perform step 1021 in step 102 in the embodiment described in fig. 1A;

a modifying unit 3022, configured to perform step 1022 in step 102 in the embodiment described in fig. 1A;

a monitoring unit 3023, configured to perform step 1023 in step 102 in the embodiment described above in fig. 1A;

a second obtaining unit 3024, configured to execute step 1024 in step 102 in the embodiment described in fig. 1A.

Optionally, referring to fig. 3C, the apparatus further comprises:

a first triggering module 304, configured to, if it is determined that the non-PE script file is a virus file, end running the non-PE script file, and/or display a reminding message, where the reminding message is used to remind that the non-PE script file is a virus file;

and a second triggering module 305, configured to, if it is determined that the non-PE script file is not a virus file, call a corresponding method function based on the obtained method name and the obtained script parameter, so as to complete running of the non-PE script file.

Optionally, referring to fig. 3D, the apparatus further comprises:

and the injection module 306 is used for injecting the monitoring file into the process of the target program when the target program is started.

Fig. 4 is a schematic structural diagram of a terminal 400 according to an embodiment of the present invention. Referring to fig. 4, the terminal 400 may include a communication unit 410, a memory 420 including one or more computer-readable storage media, an input unit 430, a display unit 440, a sensor 450, an audio circuit 460, a WIFI (Wireless Fidelity) module 470, a processor 480 including one or more processing cores, and a power supply 490. Those skilled in the art will appreciate that the terminal configuration shown in fig. 4 is not intended to be limiting and may include more or fewer components than those shown, or some components may be combined, or a different arrangement of components. Wherein:

the communication unit 410 may be used for receiving and transmitting information or signals during a call, and the communication unit 410 may be an RF (Radio Frequency) circuit, a router, a modem, or other network communication devices. In particular, when the communication unit 410 is an RF circuit, downlink information of a base station is received and then processed by the one or more processors 480; in addition, data relating to uplink is transmitted to the base station. Generally, the RF circuit as a communication unit includes, but is not limited to, an antenna, at least one Amplifier, a tuner, one or more oscillators, a Subscriber Identity Module (SIM) card, a transceiver, a coupler, an LNA (Low Noise Amplifier), a duplexer, and the like. In addition, the communication unit 410 may also communicate with a network and other devices through wireless communication. The wireless communication may use any communication standard or protocol, including but not limited to GSM (Global System for Mobile communications), GPRS (General Packet Radio Service), CDMA (Code Division Multiple Access), WCDMA (Wideband Code Division Multiple Access), LTE (Long Term Evolution), email, SMS (Short Messaging Service), and the like. The memory 420 may be used to store software programs and modules, and the processor 480 executes various functional applications and data processing by operating the software programs and modules stored in the memory 420. The memory 420 may mainly include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application program required by at least one function (such as a sound playing function, an image playing function, etc.), and the like; the storage data area may store data (such as audio data, a phonebook, etc.) created according to the use of the terminal 400, and the like. Further, the memory 420 may include high speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other volatile solid state storage device. Accordingly, memory 420 may also include a memory controller to provide access to memory 420 by processor 480 and input unit 430.

The input unit 430 may be used to receive input numeric or character information and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control. Preferably, the input unit 430 may include a touch-sensitive surface 431 and other input devices 432. The touch-sensitive surface 431, also referred to as a touch display screen or a touch pad, may collect touch operations by a user on or near the touch-sensitive surface 431 (e.g., operations by a user on or near the touch-sensitive surface 431 using any suitable object or attachment such as a finger, a stylus, etc.) and drive the corresponding connection device according to a predetermined program. Alternatively, the touch sensitive surface 431 may comprise both a touch detection device and a touch controller. The touch detection device detects the touch direction of a user, detects a signal brought by touch operation and transmits the signal to the touch controller; the touch controller receives touch information from the touch sensing device, converts the touch information into touch point coordinates, sends the touch point coordinates to the processor 480, and receives and executes commands sent from the processor 480. In addition, the touch-sensitive surface 431 may be implemented in various types, such as resistive, capacitive, infrared, and surface acoustic wave. The input unit 430 may include other input devices 432 in addition to the touch-sensitive surface 431. Preferably, other input devices 432 may include, but are not limited to, one or more of a physical keyboard, function keys (such as volume control keys, switch keys, etc.), a trackball, a mouse, a joystick, and the like.

The display unit 440 may be used to display information input by or provided to a user and various graphical user interfaces of the terminal 400, which may be made up of graphics, text, icons, video, and any combination thereof. The Display unit 440 may include a Display panel 441, and optionally, the Display panel 441 may be configured in the form of an LCD (Liquid Crystal Display), an OLED (Organic Light-Emitting Diode), or the like. Further, the touch-sensitive surface 431 may overlay the display panel 441, and when a touch operation is detected on or near the touch-sensitive surface 431, the touch operation is transmitted to the processor 480 to determine the type of the touch event, and then the processor 480 provides a corresponding visual output on the display panel 441 according to the type of the touch event. Although in FIG. 4 the touch sensitive surface 431 and the display panel 441 are two separate components to implement input and output functions, in some embodiments the touch sensitive surface 431 and the display panel 441 may be integrated to implement input and output functions.

The terminal 400 can also include at least one sensor 450, such as a light sensor, motion sensor, and other sensors. The light sensor may include an ambient light sensor that adjusts the brightness of the display panel 441 according to the brightness of ambient light, and a proximity sensor that turns off the display panel 441 and/or a backlight when the terminal 400 is moved to the ear. As one of the motion sensors, the gravity acceleration sensor can detect the magnitude of acceleration in each direction (generally, three axes), can detect the magnitude and direction of gravity when the mobile phone is stationary, and can be used for applications of recognizing the posture of the mobile phone (such as horizontal and vertical screen switching, related games, magnetometer posture calibration), vibration recognition related functions (such as pedometer and tapping), and the like; as for other sensors such as a gyroscope, a barometer, a hygrometer, a thermometer, and an infrared sensor, which can be configured in the terminal 400, detailed descriptions thereof are omitted.

The audio circuit 460, speaker 461, microphone 462 may provide an audio interface between a user and the terminal 400. The audio circuit 460 may transmit the electrical signal converted from the received audio data to the speaker 461, and convert the electrical signal into a sound signal for output by the speaker 461; on the other hand, the microphone 462 converts the collected sound signal into an electric signal, converts the electric signal into audio data after being received by the audio circuit 460, and then processes the audio data by the audio data output processor 480, and then passes through the communication unit 410 to be transmitted to, for example, another terminal, or outputs the audio data to the memory 420 for further processing. The audio circuit 460 may also include an earbud jack to provide communication of a peripheral headset with the terminal 400.

In order to implement wireless communication, a wireless communication unit 470 may be configured on the terminal, and the wireless communication unit 470 may be a WIFI module. WIFI belongs to a short-range wireless transmission technology, and the terminal 400 can help a user to send and receive e-mails, browse web pages, access streaming media, and the like through the wireless communication unit 470, and provides the user with wireless broadband internet access. Although the wireless communication unit 470 is shown in the drawing, it is understood that it does not belong to the essential constitution of the terminal 400 and may be omitted entirely as needed within the scope not changing the essence of the invention.

The processor 480 is a control center of the terminal 400, connects various parts of the entire mobile phone using various interfaces and lines, and performs various functions of the terminal 400 and processes data by operating or executing software programs and/or modules stored in the memory 420 and calling data stored in the memory 420, thereby integrally monitoring the mobile phone. Optionally, processor 480 may include one or more processing cores; preferably, the processor 480 may integrate an application processor, which mainly handles operating systems, user interfaces, application programs, etc., and a modem processor, which mainly handles wireless communications. It will be appreciated that the modem processor described above may not be integrated into processor 480.

The terminal 400 also includes a power supply 490 (e.g., a battery) for powering the various components, which may preferably be logically connected to the processor 480 via a power management system that may be used to manage charging, discharging, and power consumption. The power supply 460 may also include any component of one or more dc or ac power sources, recharging systems, power failure detection circuitry, power converters or inverters, power status indicators, and the like.

Although not shown, the terminal 400 may further include a camera, a bluetooth module, etc., which will not be described herein.

In this embodiment, the terminal 400 further comprises at least one instruction, at least one program, code set, or instruction set stored in the memory and configured to be loaded and executed by one or more processors to implement the virus detection method of the script file according to the embodiment of fig. 1A.

In another embodiment, a computer-readable storage medium is provided, in which at least one instruction, at least one program, a set of codes, or a set of instructions is stored, and the instruction, the program, the set of codes, or the set of instructions is loaded and executed by a processor to implement the virus detection method for a script file according to the embodiment of fig. 1A.

It will be understood by those skilled in the art that all or part of the steps for implementing the above embodiments may be implemented by hardware, or may be implemented by a program instructing relevant hardware, where the program may be stored in a computer-readable storage medium, and the above-mentioned storage medium may be a read-only memory, a magnetic disk or an optical disk, etc.

The above description is only for the purpose of illustrating the preferred embodiments of the present invention and is not to be construed as limiting the invention, and any modifications, equivalents, improvements and the like that fall within the spirit and principle of the present invention are intended to be included therein.

Claims

1. A virus detection method for a non-portable executable PE script file, the method comprising:

in the running process of the target program, running a monitoring code included in a monitoring file injected in the target program in advance, and monitoring the process of running the non-PE script file by the target program; the target program refers to a program integrated with a script virtual machine;

monitoring the behavior of calling a distribution interface of an automation object in the process of running the non-PE script file by the target program through running of the monitoring code, and acquiring a method name and/or script parameters used when at least one calling function pointer is called; the at least one calling function pointer refers to a calling function pointer of a distribution interface of an automation object called in the process that the target program runs the non-PE script file, and the automation object refers to a component object model COM object integrated with the distribution interface;

when the calling behavior of the distribution interface is monitored, whether the calling behavior can maliciously modify the terminal is analyzed based on the acquired method name and/or script parameters, and whether the running non-PE script file is a virus file is determined.

2. The method of claim 1, wherein obtaining, through execution of the monitoring code, a method name and/or script parameters used when at least one call function pointer is called comprises:

acquiring function pointer tables of distribution interfaces of all automation objects required to be called in the process of running the non-PE script file through running of the monitoring code, wherein each function pointer table comprises a calling function pointer corresponding to the distribution interface of the automation object;

modifying the obtained calling function pointer in each function pointer table into a user-defined function pointer;

monitoring the process of the target program for running the non-PE script file;

and when the self-defined function pointer is called in the process of running the non-PE script file, acquiring a method name and/or script parameters used when the self-defined function pointer is called.

3. The method of claim 1, wherein determining whether the executed non-PE script file is a virus file based on the retrieved method name and/or script parameters comprises:

determining an operation behavior corresponding to the acquired method name, and determining whether the non-PE script file is a virus file or not based on the operation behavior; alternatively, the first and second electrodes may be,

sequentially matching the features in a first virus feature library with the obtained script parameters, and if the obtained script parameters have a preset number of features in the first virus feature library, determining that the non-PE script file is a virus file, wherein the features in the first virus feature library comprise script parameter features; alternatively, the first and second electrodes may be,

and sequentially matching the characteristics in a second virus characteristic library with the character string consisting of the obtained method name and the script parameters, and if the preset number of characteristics in the second virus characteristic library exist in the character string consisting of the preset number of characteristics, determining that the non-PE script file is a virus file, wherein the characteristics in the second virus characteristic library comprise method name characteristics and script parameter characteristics.

4. The method of claim 1, wherein after determining whether the executed non-PE script file is a virus file based on the retrieved method name and/or script parameters, further comprising:

if the non-PE script file is determined to be a virus file, ending running the non-PE script file, and/or displaying reminding information, wherein the reminding information is used for reminding the non-PE script file of being the virus file;

if the non-PE script file is determined not to be a virus file, calling a corresponding method function based on the obtained method name and the script parameter to complete the operation of the non-PE script file.

5. The method according to claim 1, wherein the running of the monitoring code included in the monitoring file injected in advance in the target program further includes:

and when the target program is started, injecting the monitoring file into the process of the target program.

6. The method of any of claims 1-5, wherein the monitoring file is a Dynamic Link Library (DLL) file.

7. An apparatus for virus detection of a non-portable executable PE script file, the apparatus comprising:

the running module is used for running a monitoring code included in a monitoring file injected in the target program in advance in the running process of the target program and monitoring the process of running the non-PE script file by the target program; the target program refers to a program integrated with a script virtual machine;

the acquisition module is used for monitoring the behavior of calling a distribution interface of an automation object in the process of running the non-PE script file by the target program through running the monitoring code and acquiring a method name and/or a script parameter used when at least one calling function pointer is called; the at least one calling function pointer refers to a calling function pointer of a distribution interface of an automation object called in the process that the target program runs the non-PE script file, and the automation object refers to a component object model COM object integrated with the distribution interface;

and the detection module is used for analyzing whether the calling behavior can maliciously modify the terminal or not based on the acquired method name and/or script parameters when monitoring the calling behavior of the distribution interface, and further determining whether the running non-PE script file is a virus file or not.

8. The apparatus of claim 7, wherein the acquisition module comprises:

the first acquisition unit is used for acquiring function pointer tables of distribution interfaces of all automation objects required to be called in the process of running the non-PE script file through running of the monitoring code, and each function pointer table comprises a calling function pointer corresponding to the distribution interface of the automation object;

the modification unit is used for modifying the obtained calling function pointer in each function pointer table into a user-defined function pointer;

the monitoring unit is used for monitoring the process of the target program running the non-PE script file;

and the second acquisition unit is used for acquiring the method name and/or the script parameter used when the self-defined function pointer is called when the self-defined function pointer is monitored to be called in the process of running the non-PE script file.

9. The apparatus of claim 7, wherein the apparatus further comprises:

the first trigger module is used for ending the running of the non-PE script file and/or displaying reminding information if the non-PE script file is determined to be a virus file, wherein the reminding information is used for reminding the non-PE script file of being the virus file;

and the second trigger module is used for calling a corresponding method function based on the obtained method name and the script parameter to finish the operation of the non-PE script file if the non-PE script file is determined not to be the virus file.

10. The apparatus of claim 7, wherein the apparatus further comprises:

and the injection module is used for injecting the monitoring file into the process of the target program when the target program is started.

11. A terminal, characterized in that it comprises a processor and a memory in which at least one instruction, at least one program, set of codes or set of instructions is stored, which is loaded and executed by the processor to implement the virus detection method of a script file according to any of claims 1 to 6.

12. A computer-readable storage medium, in which at least one computer program is stored, the computer program being loaded and executed by a processor to implement the virus detection method for a non-portable executable PE script file according to any one of claims 1 to 6.