RU2757265C1 - System and method for assessing an application for the presence of malware - Google Patents

Abstract

FIELD: information security.

SUBSTANCE: invention relates to the field of computing technology for ensuring information security. The technical result is achieved by: a) for a given application, forming a source code thereof; b) forming an intermediate code based on the generated source code; c) sampling the characteristics of at least one application from an application database based on the formed intermediate code; d) determining the degree of maliciousness of the given application based on the selected characteristics of the application.

EFFECT: increase in the accuracy of determining the degree of maliciousness of an application.

18 cl, 3 dwg

Description

Technology area

The invention relates to the field of information security, and more specifically to systems and methods for evaluating an application for harmfulness.

State of the art

The rapid development of computer technologies in the last decade, as well as the widespread use of various computing devices (personal computers, laptops, tablets, smartphones, etc.) have become a powerful incentive for the use of these devices in various fields of activity and for a huge number of tasks (from the Internet surfing to bank transfers and electronic document management). In parallel with the growth in the number of computing devices and software running on these devices, so did the number of malicious programs.

At the moment, there are a huge number of types of malware. Some steal personal and confidential data from users' devices (for example, logins and passwords, bank details, electronic documents). Others form so-called botnets from users' devices for attacks such as DDoS (Distributed Denial of Service) or for brute force brute-force attacks on other computers or computer networks. Still others offer users paid content through intrusive ads, sending SMS messages to paid numbers, etc.

Various technologies are used to detect the whole variety of malicious programs, such as:

static analysis - analysis of a program for malware, which excludes launching or emulating the operation of the analyzed program, based on the data contained in the files that make up the analyzed program.

dynamic analysis - analysis of a program for harmfulness based on data obtained during the execution or emulation of the analyzed program.

Both static and dynamic analysis have their own pros and cons. Static analysis is less demanding on the resources of the computer system on which the analysis is performed, and since it does not require execution or emulation of the analyzed program, static analysis is faster, but at the same time less efficient, i.e. has a lower detection rate for new types of malware. Dynamic analysis, due to the fact that it uses data obtained during the execution or emulation of the analyzed program, is slower and makes higher demands on the resources of the computer system on which the analysis is performed, but at the same time it is more efficient for detecting new types of malicious programs.

To increase the efficiency of static analysis, various technologies are used, including disassembly (as a special case of decompilation) and subsequent analysis of not the executable code of the application under study, but a deeper and more efficient analysis of the restored source code of the application under study. For example, this analysis is performed "in-stream" when data is fetched from network traffic.

Often, supplementing (or replacing) decompilation is the analysis of data obtained during emulation (or execution) of applications, i.e. when access is not to the instructions of the application (or algorithms of the application), but to the results of the execution of such instructions or algorithms.

US Patent Publication 9288220 B2 describes a technology for detecting malware in network traffic. For this purpose, characteristic features (features characterizing the type of the executable file, the behavior of the executable file during emulation, executed during file execution (API function calls), the triggering of signatures in the file, etc.) are distinguished from the data selected from the network traffic. which can be a feature description of the selected data, the so-called feature vector, composed of values corresponding to a set of features for an object containing the selected data. Using models for detecting safe files, detecting malicious files, and detecting types of malicious files, pre-trained using machine learning methods based on patterns composed of similar to the mentioned characteristics, determine the weight and what type of malicious 110 the selected data belongs to, and make a decision on the detection of malicious 110 in network traffic.

The present invention makes it possible to solve the problem of detecting malicious files using static analysis elements.

Disclosure of invention

The invention is intended to ensure information security.

The technical result of the present invention is to determine the degree of harmfulness of the application.

Another technical result of the present invention is the detection of a malicious application.

Another technical result of this application is to detect malicious code embedded in the application.

This result is achieved through the use of a system for generating individual content for the user of the service, which contains: a logging tool designed to collect data on the user's use of the computing device; a training tool for training a user behavior model based on the collected data; transfer means for transferring the trained model to the content generating means; content generating means for generating individual content for a service user based on a predetermined service environment, taking into account the behavior model provided by the transmission means.

This result is achieved by using a system for determining the degree of harmfulness, which contains: a source code generating tool designed to generate a source code for a given application; intermediate code generating means for generating intermediate code based on the generated source code; characteristic sampling means for retrieving characteristics of at least one application from the application database based on the generated intermediate code; severity determination means for determining the severity of a given application based on the selected characteristics of the application.

In another particular case of the system implementation, at least one of the following can act as an application: an executable file; a collection of at least one executable file and at least one resource file.

In another particular case of the system implementation, the source code is formed by decompiling a given application.

In another particular case of the implementation of the system, the means for generating the intermediate code is additionally intended for: separating from the generated source code at least one basic block, where at least one of the following can act as the basic block: a function; a set of instructions located between a jump instruction at a given address and an instruction located at a given address; at least: calculating a convolution from the base block; highlighting the codes of instructions contained in the base unit; allocation of constant arguments of instructions contained in the basic block; allocating variables from the stack; highlighting the arguments of the instructions contained in the base unit that do not fall into the area of virtual addresses, forming a symbolic expression of the base unit, including, for the instructions contained in the base unit, at least: a variable at the instruction input; constant argument to the instruction; the result of invoking the instruction; from the base unit.

In another particular case of the implementation of the system, instructions relating at least to: the code of standard libraries are excluded from the intermediate code; known secure applications.

In another particular case of the system implementation, the application base contains characteristics and generated intermediate code of at least one application.

In another particular case of the implementation of the system, the characteristics of the application are at least: the category to which the specified application belongs, while the category is at least: the category of safe applications, including applications that do not have malicious functionality; a category of malicious applications, which includes applications that have malicious functionality; a category of unknown applications, which includes applications whose functionality is unknown; the severity of the application, indicating the likelihood that the application has malicious functionality.

In another particular case, the implementation of the system is selected from the application database characteristics of the application, the intermediate code of which is similar to the generated intermediate code above a predetermined threshold value.

In yet another particular case of the implementation of the system, said system further comprises identification means designed to determine, based on the severity of a given application, at least: a piece of code in a given application, similar in functionality to a piece of application code from the application base; malicious code embedded in a given application; the category of the given application.

This result is achieved by using a method for determining the degree of harmfulness, while the method contains stages that are implemented using the means from the system for determining the degree of harmfulness and at which: for a given application, its source code is generated; generating an intermediate code based on the generated source code; fetching characteristics of at least one application from the application base based on the generated intermediate code; determine the severity of a given application based on the selected characteristics of the application.

In another particular case of the implementation of the method, at least one executable file can act as an application; at least one executable file and at least one resource file collectively providing application functionality.

In another particular case of the implementation of the method, the source code is formed by decompiling a given application.

In another particular case of the implementation of the method, the formation of the intermediate code contains the stages, at which: select from the generated source code at least one basic block, where the basic block is at least: a function; a set of instructions located between a jump instruction at a given address and an instruction located at a given address; based on the selected base block at least: calculating convolution from the base block; allocate codes of instructions contained in the base unit; extract the constant arguments of the instructions contained in the base block; the arguments of the instructions contained in the base block are selected that do not fall into the area of virtual addresses, a symbolic expression of the base block is formed, including, for the instructions contained in the base block, at least: a variable at the instruction input; constant argument to the instruction; the result of invoking the instruction.

In yet another particular case of the implementation of the method, instructions relating at least to: the code of standard libraries are excluded from the intermediate code; known secure applications.

In another particular case of the implementation of the method, the application base contains characteristics and generated intermediate code of at least one application.

In another particular case of the implementation of the method, the characteristics of the application are at least: the category to which the specified application belongs, while the category is at least: the category of safe applications, including applications that do not have malicious functionality; a category of malicious applications, which includes applications that have malicious functionality; category of unknown applications, including applications whose functionality is unknown, the degree of malware application, indicating the likelihood that the application has malicious functionality.

In another particular case of the implementation of the method, the characteristics of the application are selected from the application base, the intermediate code of which has a degree of similarity with the generated intermediate code above a predetermined threshold value.

In another particular case of the implementation of the method, on the basis of a certain degree of harmfulness of a given application, at least are determined: a piece of code in a given application, similar in functionality to a piece of application code from the application base; malicious code embedded in a given application; the category of the given application.

Brief Description of Drawings

FIG. 1 is a block diagram of a system for determining the degree of harmfulness.

FIG. 2 is a block diagram of a method for determining the degree of harmfulness.

FIG. 3 is an example of a general purpose computer system, personal computer or server.

Although the invention may take various modifications and alternative forms, the characteristic features shown by way of example in the drawings will be described in detail. It should be understood, however, that the purpose of the description is not to limit the invention to a specific embodiment. On the contrary, the purpose of the description is to cover all changes, modifications falling within the scope of this invention, as defined by the appended claims.

Description of embodiments of the invention

The objects and features of the present invention, methods for achieving these objects and features will become apparent by reference to exemplary embodiments. However, the present invention is not limited to the exemplary embodiments disclosed below, but may be embodied in various forms. The essence recited in the description is nothing more than the specific details necessary to assist a person skilled in the art in a thorough understanding of the invention, and the present invention is defined within the scope of the appended claims.

FIG. 1 is a block diagram of a system for determining the degree of harmfulness.

The structural diagram of the system for determining the degree of harmfulness consists of means for generating the source code 110, means for generating intermediate code 120, means for selecting characteristics 130, application base 131, means for determining the degree of harmfulness 140, identification means 150.

Application 101 can be at least:

one executable file;

at least one executable file and at least one resource file collectively providing the functionality of the application 101.

For example, files of PE, ELF, MACHO, BIN, etc. formats can be used as executable files.

The source code generator 110 is designed to generate source code for a given application 101.

In one embodiment of the system, the source code is generated by decompiling a given application 101.

For example, a disassembler is selected depending on the type of application from a pre-prepared set of disassemblers.

In another example, Capstone disassemblers can be used as a disassembler.

In another embodiment of the system, decompilation is performed in such a way that for applications running on different platforms and having different types (for example, PE and ELF), but having similar functionality, a similar source code is generated.

The intermediate code generating means 120 is for generating an intermediate code based on the generated source code.

In this case, the intermediate code or byte code (bytecode; English bytecode, also sometimes p-code, p-code from portable code) is a standard intermediate representation into which a computer program can be translated by automatic means. Compared to source code, which is easy to create and read by humans, bytecode is a compact representation of a program that has already gone through parsing and semantic analysis. It explicitly encodes types, scopes, and other constructs. Technically speaking, bytecode is a low-level machine-independent code generated by a translator from source code.

In one embodiment of the system, the intermediate code generating means 120 is additionally intended for:

a) extracting at least one basic block from the generated source code, where at least one of the following can act as the basic block:

function;

a set of instructions located between a jump instruction at a given address and an instruction located at a given address;

b) at least:

calculating convolution from the base block;

highlighting instruction codes (English opcode) contained in the base unit;

allocation of constant arguments of instructions contained in the basic block;

allocating variables from the stack;

allocation of arguments of instructions contained in the base block that do not fall into the range of virtual addresses,

forming a symbolic expression of the base unit, including, for instructions contained in the base unit, at least:

variable at the input of the instruction;

constant argument to the instruction;

the result of invoking the instruction.

from the base unit.

Thus, when preparing the intermediate code for the selected block, the logic of the operation of the said block is preserved, and most of the variable data is excluded. As a result, two basic blocks working with different data, but using similar algorithms, will have similar intermediate codes.

In another embodiment of the system, the MD5 algorithm acts as a convolution function. Thus, the intermediate code can be a collection of M05 values.

In yet another embodiment of the system, instructions relating at least to:

standard library code;

known secure applications.

For example, a whitelist collection is preliminarily compiled, for which intermediate code is generated similarly to the one described above. The intermediate code for the basic blocks present in the applications of the specified collection is excluded from the intermediate code generated for the specified file 101.

The exclusion of the instructions described above from the intermediate code makes it possible to reduce the likelihood of type I and type II errors in determining the maliciousness of an application, since it reduces the amount of data describing safe code (and safe functionality) relative to the total amount of data for a given application 101.

The feature extractor 130 is designed to retrieve the characteristics of at least one application from the application base 131 based on the generated intermediate code.

The application base 131 is designed to store characteristics and generated intermediate code of at least one application.

In one embodiment of the system, the characteristics of the application are at least:

the category to which the specified application belongs, while the category is at least:

a category of safe applications, which includes applications that do not have malicious functionality;

a category of malicious applications, which includes applications that have malicious functionality;

category of unknown applications, including applications, the functionality of which is unknown,

the severity of the application, indicating the likelihood that the application has malicious functionality.

Moreover, each category of an application can contain subcategories, for example, a category of malicious applications can contain categories of families (types) of malicious applications (for example, worms, Trojans, potentially dangerous applications, etc.).

In another embodiment of the system, the application characteristics are selected from the application database 131, the intermediate code of which has a degree of similarity with the generated intermediate code above a predetermined threshold value.

The means for determining the severity level 140 is for determining the severity level of a given application 101 based on the selected characteristics of the application.

In one embodiment of the system, the severity level is a numerical value in a given range (for example, from 0 to 100), where the minimum value means a guaranteed safe application, and the maximum value means a guaranteed malicious one.

The identification means 150 is intended to determine, based on the severity of the specified application 101, at least:

a piece of code 151 in a given application, similar in functionality to a piece of application code from the application base 131;

malicious code embedded in a given application

the category of the given application.

In one implementation of the system, the application database 131 contains malicious applications, which makes it possible to find malicious code in a given application 101. This, in turn, allows antivirus and information security companies to react more quickly to the emergence of new, previously unknown malicious applications (application code is new, but malicious algorithms are known, which allows new applications to be detected).

In yet another embodiment of the system, the application base 131 contains only secure applications. Therefore, when analyzing a given application, which is similar to applications from the application database 131, but contains embedded code, this code is detected, since the basic blocks containing it are absent in applications from the application database 131. After the unknown blocks are identified, they (the executable code contained in basic blocks) can be analyzed by any method known from the prior art (for example, based on signature or heuristic analysis). If malicious functionality is detected in the analyzed blocks, then it is recognized that malicious code has been injected into the specified application.

The simplest example of the case described above is an application infected with one of the viruses.

Consider an example of the technology described above: two files are analyzed (File 1, File 2), functional blocks are extracted from each block, by which intermediate code and convolution are calculated. The resulting convolutions are compared with each other for similarity:

File 1:

Base unit # 1 (before the first control transfer instruction):

Intermediate code # 1 (containing instructions):

Convolution:

(addresses of the beginning and end of the basic block, md5 hash of the original instructions of the basic block, md5 hash from the block of pseudo-instructions, a string of original bytes)

File 2:

Base unit # 1 (before the first control transfer instruction):

Intermediate code # 1 (containing instructions):

Convolution:

(addresses of the beginning and end of the basic block, md5 hash of the original instructions of the basic block, md5 hash from the block of pseudo-instructions, a string of original bytes)

It can be seen that the original bytes and their hash do not match, but the pseudocode hashes are the same.

FIG. 2 is a block diagram of a method for determining the degree of harmfulness.

The block diagram of the method for determining the degree of harmfulness comprises step 210, at which the source code is generated, step 220, at which the intermediate code is generated, step 230, at which the characteristics are selected, step 240, at which the degree of harmfulness is determined, step 250, at which the section of the code is determined ...

In step 210, the source code for the given application 101 is generated by the source code generating means 110.

In step 220, the intermediate code generating means 120 generates an intermediate code based on the source code generated in step 210.

In one of the special cases of the implementation of the method, step 220 comprises the steps at which:

a) at least one basic block is extracted from the source code generated at step 210, where at least one of the following acts as the basic block:

function;

a set of instructions located between a jump instruction at a given address and an instruction located at a given address;

b) based on the allocated base unit at least:

calculating convolution from the base block;

allocate codes of instructions contained in the base unit;

extract the constant arguments of the instructions contained in the base block;

allocate the arguments of the instructions contained in the base block that do not fall into the scope of virtual addresses,

a symbolic expression of the base block is formed, including, for the instructions contained in the base block, at least:

variable at the input of the instruction;

constant argument to the instruction;

the result of invoking the instruction.

At step 230, the feature fetch means 130 fetches the features of at least one application from the application database 131 based on the intermediate code generated at step 220.

In step 240, the severity determination means 140 determines the severity of the specified application 101 based on the characteristics of the application selected in step 230.

At step 250, using the identification means 150, based on the severity level of the specified application 101 determined at step 240, at least:

a piece of code in a given application 101, similar in functionality to a piece of application code from the application base;

malicious code embedded in a given application 101;

preset application category 101.

FIG. 3 shows an example of a general-purpose computer system, a personal computer or server 20, comprising a central processing unit 21, a system memory 22, and a system bus 23 that contains various system components, including memory associated with the central processing unit 21. The system bus 23 is implemented as any bus structure known from the prior art, containing in turn a bus memory or a bus memory controller, a peripheral bus and a local bus that is capable of interfacing with any other bus architecture. System memory contains read-only memory (ROM) 24, random access memory (RAM) 25. The main input / output system (BIOS) 26 contains basic procedures that transfer information between the elements of the personal computer 20, for example, at the time of loading the operating room. systems using ROM 24.

The personal computer 20, in turn, contains a hard disk 27 for reading and writing data, a magnetic disk drive 28 for reading and writing to removable magnetic disks 29 and an optical drive 30 for reading and writing to removable optical disks 31, such as CD-ROM, DVD -ROM and other optical media. The hard disk 27, the magnetic disk drive 28, and the optical drive 30 are connected to the system bus 23 via the hard disk interface 32, the magnetic disk interface 33, and the optical drive interface 34, respectively. Drives and corresponding computer storage media are non-volatile storage media for computer instructions, data structures, program modules and other data of a personal computer 20.

The present description discloses an implementation of a system that uses a hard disk 27, a removable magnetic disk 29 and a removable optical disk 31, but it should be understood that other types of computer storage media 56 that are capable of storing data in a computer readable form (solid state drives, flash memory cards, digital disks, random access memory (RAM), etc.), which are connected to the system bus 23 through the controller 55.

Computer 20 has a file system 36, where the recorded operating system 35 is stored, as well as additional software applications 37, other program modules 38 and program data 39. The user has the ability to enter commands and information into the personal computer 20 through input devices (keyboard 40, manipulator " mouse "42). Other input devices can be used (not shown): microphone, joystick, game console, scanner, etc. Similar input devices, as usual, are connected to computer system 20 through serial port 46, which in turn is connected to the system bus, but can be connected in another way, such as a parallel port, game port, or universal serial bus (USB). A monitor 47 or other type of display device is also connected to the system bus 23 via an interface such as a video adapter 48. In addition to the monitor 47, the personal computer may be equipped with other peripheral output devices (not displayed), such as speakers, a printer, etc. ...

The personal computer 20 is capable of operating in a networked environment using a network connection with other or more remote computers 49. The remote computer (or computers) 49 are the same personal computers or servers that have most or all of the elements mentioned earlier in the description of the entity. the personal computer 20 shown in FIG. 3. In a computer network, there may also be other devices, such as routers, network stations, peer-to-peer devices, or other network nodes.

Network connections can form a local area network (LAN) 50 and a wide area network (WAN). Such networks are used in corporate computer networks, internal networks of companies and, as a rule, have access to the Internet. In LAN or WAN networks, personal computer 20 is connected to local network 50 via a network adapter or network interface 51. When using networks, personal computer 20 may use a modem 54 or other means of providing communication with a wide area network, such as the Internet. Modem 54, which is an internal or external device, is connected to the system bus 23 via a serial port 46. It should be noted that the network connections are only exemplary and are not required to reflect the exact configuration of the network, i. E. in fact, there are other ways of establishing a connection by technical means of communication of one computer with another.

In conclusion, it should be noted that the information given in the description are examples, which do not limit the scope of the present invention defined by the claims.

Claims (75)

1. System for determining the degree of harmfulness, which contains: a) a source code generating means for generating a source code for a given application; b) intermediate code generating means for generating intermediate code based on the generated source code; c) a feature selection means for selecting the characteristics of at least one application from the application base based on the generated intermediate code; d) means for determining the degree of severity, designed to determine the degree of severity of a given application based on the selected characteristics of the application. 2. The system according to claim 1, in which at least one of the following can act as an application: executable file; a collection of at least one executable file and at least one resource file. 3. The system of claim 1, wherein the source code is generated by decompiling a given application. 4. The system according to claim 1, in which the intermediate code generating means is additionally intended for: a) extracting at least one basic block from the generated source code, where at least one of the following can act as the basic block: function; a set of instructions located between a jump instruction at a given address and an instruction located at a given address; b) at least: calculating convolution from the base block; highlighting the codes of instructions contained in the base unit; allocation of constant arguments of instructions contained in the basic block; allocating variables from the stack; allocation of arguments of instructions contained in the base block that do not fall into the range of virtual addresses, forming a symbolic expression of the base unit, including, for instructions contained in the base unit, at least: variable at the input of the instruction; constant argument to the instruction; the result of calling the instruction from the base unit. 5. The system of claim 4, wherein the intermediate code excludes instructions relating at least to: standard library code; known secure applications. 6. The system of claim. 1, in which the application base contains characteristics and generated intermediate code of at least one application. 7. The system according to claim 1, in which the characteristics of the application are at least: the category to which the specified application belongs, while the category is at least: a category of safe applications, which includes applications that do not have malicious functionality; a category of malicious applications, which includes applications that have malicious functionality; category of unknown applications, including applications, the functionality of which is unknown, the severity of the application, indicating the likelihood that the application has malicious functionality. 8. The system according to claim 1, in which the characteristics of the application are selected from the application base, the intermediate code of which is similar to the generated intermediate code above a predetermined threshold value. 9. The system according to claim 1, which further comprises identification means for determining, based on the severity of a given application, at least: a piece of code in a given application, similar in functionality to a piece of application code from the application base; malicious code embedded in a given application; the category of the given application. 10. A method for determining the degree of harmfulness, the method comprising stages that are implemented using the means from the system according to claim 1 and in which: a) generate its source code for a given application; b) generating an intermediate code based on the generated source code; c) sampling the characteristics of at least one application from the application database based on the generated intermediate code; d) determine the severity of a given application based on the selected characteristics of the application. 11. The method according to claim 10, wherein at least: one executable file; at least one executable file and at least one resource file collectively providing application functionality. 12. The method of claim 10, wherein the source code is generated by decompiling the specified application. 13. The method according to claim 10, according to which the formation of the intermediate code comprises the stages, at which: a) at least one basic block is extracted from the generated source code, where at least one of the following acts as the basic block: function; a set of instructions located between a jump instruction at a given address and an instruction located at a given address; b) based on the allocated base unit at least: calculating convolution from the base block; allocate codes of instructions contained in the base unit; extract the constant arguments of the instructions contained in the base block; allocate the arguments of the instructions contained in the base block that do not fall into the scope of virtual addresses, a symbolic expression of the base block is formed, including, for the instructions contained in the base block, at least: variable at the input of the instruction; constant argument to the instruction; the result of invoking the instruction. 14. The method of claim 13, wherein the intermediate code excludes instructions relating to at least: standard library code; known secure applications. 15. The method of claim 10, wherein the application base comprises characteristics and generated intermediate code of at least one application. 16. The method according to claim 10, wherein at least the following are the characteristics of the application: the category to which the specified application belongs, while the category is at least: a category of safe applications, which includes applications that do not have malicious functionality; a category of malicious applications, which includes applications that have malicious functionality; category of unknown applications, including applications, the functionality of which is unknown, the severity of the application, indicating the likelihood that the application has malicious functionality. 17. The method according to claim 10, according to which characteristics of an application are selected from the application base, the intermediate code of which has a degree of similarity with the generated intermediate code above a predetermined threshold value. 18. The method according to claim 10, according to which, additionally, based on a certain degree of harmfulness of a given application, at least is determined: a piece of code in a given application, similar in functionality to a piece of application code from the application base; malicious code embedded in a given application; the category of the given application.

Images