Method for detecting malware and apparatus thereof

Abstract

The present disclosure presents a method for detecting malicious code using static analysis. The malicious code detection method according to the present disclosure may include the steps of: obtaining a token embedding-based feature vector for each basic block included in a Control Flow Graph (CFG) of an executable file; generating a representation of the CFG using the connection relationships between each basic block of the CFG and the feature vector of each basic block; generating an input feature vector from the representation of the CFG; inputting the input feature vector into a Graph Neural Network (GNN)-based graph classification model; and determining whether the executable file is malicious code using the output data of the graph classification model.

Description

Technology Field

[0001] The present disclosure relates to a method, apparatus, or system for detecting malicious code. More specifically, it relates to a method, apparatus, or system for detecting malicious code based on static analysis. Background Technology

[0002] A technology for detecting malicious code in an executable file is provided. The executable file may be, for example, a compiled binary file; executable files used in the Windows operating system, Dynamic Linked Library (DLL) files, etc., are configured based on the PE format and are therefore also referred to as PE files. The PE file contains various information necessary for the detection of malicious code, such as information about called subroutines, and this information can be verified without executing the PE file.

[0003] Compared to dynamic analysis, which requires the execution of executable files, static analysis has several advantages. For example, static analysis does not require the establishment of an isolated execution environment for the execution of executable files, the consumption of computational resources associated with execution, or the setup of various execution environments. On the other hand, static analysis that extracts feature values ​​from the executable file and compares them with known malicious code has a vulnerability to malicious code variants.

[0004] Although static analysis techniques are provided to detect malware using machine learning malware detection models to detect even unknown or variant malware, they have limitations such as being vulnerable to malware similar in format to normal files due to their strong reliance on format information, potentially leaving unanalyzed areas in the case of large malware, being difficult to apply to executable files with static analysis prevention techniques applied such as packing, and requiring a large amount of training data to train the malware detection model. To overcome the reality of insufficient training data, malware detection techniques utilizing unsupervised-learning-based malware detection models such as deep learning are also provided, but there are limitations to commercialization in terms of accuracy. Prior art literature

[0005] U.S. Patent Publication No. 2021-0029145 (Published Jan. 28, 2021) U.S. Patent Publication No. 2021-0029157 (Published Jan. 28, 2021) U.S. Patent Publication No. 2019-0362074 (Published Nov. 28, 2019) Korean Registered Patent No. 1880686 (Published July 20, 2018) U.S. Patent Publication No. 2019-0034632 (Published Jan. 31, 2019)

[0006] Yue Duan, Xuezixiang Li, Jinghan Wang, and Heng Yin, "DEEPBINDIFF: Learning Program-Wide Code Representations for Binary Difng" in Network and Distributed Systems Security (NDSS) Symposium 2020, 23-26 February 2020 (https: / / dx.doi.org / 10.14722 / ndss.2020.24311)Aravind Nair, Avigit Roy, Karl Meinke, "funcGNN: A Graph Neural Network Approach to Program Similarity", 2020 (https: / / doi.org / 10.1145 / 3382494.3410675)Lan Zhang, Peng Liu, Yoon-Ho Choi, "Semantics-preserving Reinforcement Learning Attack Against Graph Neural Networks for Malware Detection", 2020 (https: / / arxiv.org / abs / 2009.05602)Samuel Kim,"PE Header Analysis for Malware Detection PE Header Analysis for Malware Detection", 2018(https: / / doi.org / 10.31979 / etd.q3dd-gp9u)Edward Raff, Jared Sylvester, Charles Nicholas, "Learning the PE Header, Malware Detection with Minimal Domain Knowledge", 2017, (https: / / doi.org / 10.1145 / 3128572.3140442)Angelo Oliveira, "MALWARE ANALYSIS DATASETS: RAW PE AS IMAGE", 2019, (https: / / dx.doi.org / 10.21227 / 8brp-j220)Damin Moon, JaeKoo Lee, MyungKeun Yoon, "Compact feature hashing for machine learning based malware detection", 2021.8, (https: / / doi.org / 10.1016 / j.icte.2021.08.005)Jifeng Xuan, He Jiang, Zhilei Ren, Yan Hu, Zhongxuan Luo, “A Random Walk Based Algorithm for Structural Test Case Generation”, 2017 (https: / / arxiv.org / pdf / 1704.04772). The problem to be solved

[0007] The technical problem to be achieved through some embodiments of the present disclosure is to provide a static analysis-based malware detection method and apparatus that is difficult to bypass, based on semantic information for each subroutine (e.g., function) extracted from an executable file.

[0008] Another technical objective to be achieved through some embodiments of the present disclosure is to provide a static analysis-based malware detection method and apparatus that is difficult to bypass, based on semantic information of a basic block extracted from an executable file.

[0009] Another technical objective to be achieved through some embodiments of the present disclosure is to provide a static analysis-based malware detection method and apparatus that operate even when static analysis prevention technology is applied to executable files.

[0010] Another technical objective to be achieved through some embodiments of the present disclosure is to provide a high-accuracy static analysis-based malware detection method and apparatus by comprehensively considering the results of various types of static analysis to finally determine whether or not the code is malicious.

[0011] The technical problems of the present disclosure are not limited to those mentioned above, and other unmentioned technical problems will be clearly understood by a person skilled in the art of the present disclosure from the description below. means of solving the problem

[0012] A malicious code detection method according to one embodiment of the present disclosure comprises: obtaining a token embedding-based feature vector for each basic block included in a Control Flow Graph (CFG) of an executable file; generating a representation of the CFG using the connection relationships between each basic block of the CFG and the feature vector of each basic block; generating an input feature vector from the representation of the CFG; inputting the input feature vector into a Graph Neural Network (GNN)-based graph classification model; and determining whether the executable file is malicious code using the output data of the graph classification model. In this case, the executable file is composed of a plurality of instructions, and each instruction corresponds to a token including an opcode and an operand.

[0013] In one embodiment, the malicious code detection method may further include, prior to the step of obtaining the token embedding-based feature vector, the step of constructing a token dictionary composed of tokens and their token embeddings using a training dataset containing a plurality of executable files. Additionally, the step of obtaining the token embedding-based feature vector may include the step of obtaining the token embedding of each token corresponding to the basic block by querying the token dictionary. The step of obtaining the token embedding of each token corresponding to the basic block by querying the token dictionary may include the step of assigning the token embedding of a new token that is not queried in the token dictionary as a zero embedding.

[0014] The step of constructing the token dictionary may include: obtaining a first executable file included in the training dataset; obtaining a CFG of the first executable file; disassembling the first executable file to obtain assembly code of the first executable file; obtaining an article for the first executable file using the result of performing a random walk on the CFG and the assembly code; extracting a plurality of tokens from the article; calculating a token embedding for each of the extracted tokens; optimizing the calculated token embedding by applying a Continuous Bag of Words (CBOW) method; and adding the extracted tokens and the optimized token embedding to the token dictionary. At this time, the number of context words used in applying the CBOW method may be adjusted according to the required accuracy of malicious code detection. For example, the step of optimizing by applying the above CBOW method may include the step of applying the above CBOW method using a first number of context words when the malware detection accuracy is set to a first level, and the step of applying the above CBOW method using a second number of context words smaller than the first number when the malware detection accuracy is set to a second level lower than the first level.

[0015] Additionally, the step of configuring the token dictionary may include the step of performing a token addition process into the token dictionary for an executable file included in the training data set, and the step of repeating the token addition process for each executable file included in the training data set, wherein if the number of additional tokens resulting from the repetition falls below a threshold, the token addition process is terminated even if there are remaining executable files.

[0016] In one embodiment, the step of inputting the input feature vector into a GNN-based graph classification model may include the step of inputting the input feature vector into a graph classification model that includes a GIN layer (Graph Isomorphism Network layer). The graph classification model may include five or fewer GIN layers. For example, the graph classification model may include three GIN layers.

[0017] The step of inputting the above input feature vector into the graph classification model including a GIN layer (Graph Isomorphism Network layer) may include the step of inputting the above input feature vector into a first graph classification model including a first number of GIN layers when the malware detection accuracy is set to a first level, and the step of inputting the above input feature vector into a second graph classification model including a second number of GIN layers smaller than the first number when the malware detection accuracy is set to a second level lower than the first level.

[0018] A malicious code detection method according to another embodiment of the present disclosure may include the steps of: obtaining a feature vector for each function included in an executable file; generating a representation of the function call graph using the feature vector of each function and the connection relationships between each function included in the function call graph of the executable file; generating an input feature vector from the representation of the function call graph; inputting the input feature vector into a graph classification model based on a Graph Neural Network (GNN); and determining whether the executable file is malicious code using the output data of the graph classification model.

[0019] The above-described malicious code detection method may further include, prior to the step of obtaining a feature vector for each of the above-described functions, the step of constructing a token dictionary composed of tokens and token embeddings using a training dataset containing a plurality of executable files, and the step of training an optimization model to optimize the feature vector of the function. The step of training the optimization model may include: generating a function embedding for identification information of a first function of a first executable file included in the training dataset; obtaining a first function control flow graph (CFG) for the first function; obtaining assembly code of the first function; obtaining an article for the first function using instructions connected to edges sampled from the first function CFG as a result of performing a random walk on the assembly code of the first function and the first function CFG; querying a token embedding for a token constituting the article from the token dictionary; and inputting the queried token embedding and the function embedding into a Paragraph Vector Distributed Memory (PV-DM) model to train the PV-DM model. In this case, the optimization model may be understood to refer to the PV-DM model.

[0020] The step of training the PV-DM model may include: a step of setting a window consisting of three consecutive tokens included in the article; a step of updating the function embedding and the token embedding of each token in the window so that the average of the function embedding, the first token of the window, and the third token of the window matches the second token of the window; and a step of repeating the setting step and the updating step while shifting the window until the end of the article is reached.

[0021] The step of obtaining the feature vector may include: generating a function embedding for identification information of a first function of the executable file; obtaining a first function CFG (control flow graph) for the first function; obtaining assembly code of the first function; obtaining an article for the first function using instructions connected to edges sampled from the first function CFG as a result of performing a random walk on the assembly code of the first function and the first function CFG; querying a token embedding for a token constituting the article in the token dictionary; inputting the queried token embedding and the function embedding into a pre-trained PV-DM model to optimize the function embedding; and determining the optimized function embedding as a feature vector for the first function.

[0022] The step of optimizing the function embedding may include: a step of setting a window composed of three consecutive tokens included in the article; a step of updating the function embedding such that the average of the function embedding, the first token of the window, and the third token of the window matches the second token of the window; and a step of repeating the setting step and the updating step while shifting the window until the end of the article is reached. The step of updating the function embedding may include a step of updating the function embedding while the parameters of the PV-DM model and the tokens of the window are fixed.

[0023] A malicious code detection method according to another embodiment of the present disclosure may include the steps of obtaining a feature vector for each function included in an executable file, constructing an input feature vector including the feature vectors of each function, inputting the input feature vector to a classification model based on a Convolutional Neural Network (CNN), and determining whether the executable file is malicious code using the output data of the classification model.

[0024] The step of constructing an input feature vector including the feature vectors of each of the above functions may include the step of constructing the input feature vector by arranging the feature vectors of each of the above functions in an order sorted according to the address of each function. Additionally, the step of constructing the input feature vector by arranging the feature vectors of each of the above functions in an order sorted according to the address of each function may include the step of constructing the input feature vector by arranging the feature vectors of each of the above functions in an order sorted in ascending order according to the address of each function.

[0025] The above CNN-based classification model may be a 1D CNN-based classification model trained by 1D convolution operations.

[0026] A malicious code detection method according to another embodiment of the present disclosure may include the steps of obtaining a feature vector for each function included in an executable file, attempting to extract a function call graph of the executable file, performing a first process when the extraction of the function call graph is successful, and performing a second process when the extraction of the function call graph fails. The first process may include the steps of generating a representation of the function call graph using the connection relationships between each function included in the function call graph of the executable file and the feature vector of each function, generating an input feature vector from the representation of the function call graph, inputting the input feature vector into a graph classification model based on a Graph Neural Network (GNN), and determining whether the executable file is malicious code using the output data of the graph classification model. Additionally, the second process may include the steps of obtaining a feature vector for each function included in an executable file, constructing input data containing the feature vectors of each function, inputting the input data into a classification model based on a Convolutional Neural Network (CNN), and determining whether the executable file is malicious code using the output data of the classification model.

[0027] A malware detection device according to another embodiment of the present disclosure may include a storage that stores token dictionary data including a token indicating an instruction (opcode) and an operand thereof, and an embedding of said token, a memory, and a processor that executes a malware detection program loaded into said memory.

[0028] The above-described malware detection program comprises: a first instruction for obtaining a token embedding-based first feature vector for each basic block included in the Control Flow Graph (CFG) of an executable file targeted for malware detection, and generating a first input feature vector representing the CFG using the connection relationships between each basic block of the CFG and the first feature vector of each basic block; a second instruction for obtaining a second feature vector for each function included in the executable file; a third instruction for generating a second input feature vector representing the function call graph using the connection relationships between each function included in the function call graph of the executable file and the second feature vector of each function; a fourth instruction for generating a third input feature vector including the second feature vectors for each function included in the executable file; and a fifth method for determining whether the executable file is malware using the output data of a first Graph Neural Network (GNN)-based graph classification model that receives the first input feature vector. It may include an instruction, a sixth instruction for determining whether the executable file is malicious code using the output data of a second GNN (Graph Neural Network)-based graph classification model that receives the second input feature vector, and a seventh instruction for determining whether the executable file is malicious code using the output data of a CNN (Convolutional Neural Network)-based graph classification model that receives the third input feature vector.

[0029] The above malware detection program may execute a first group instruction consisting of the third instruction and the sixth instruction if it succeeds in extracting the function call graph from the executable file, and execute a second group instruction consisting of the fourth instruction and the seventh instruction if it fails to extract the function call graph. That is, the malware detection program may selectively execute either the first group instruction or the second group instruction. Brief explanation of the drawing

[0030] FIG. 1 is a configuration diagram of a malicious code detection system according to one embodiment of the present disclosure. FIGS. 2 and 3 are flowcharts of a malicious code detection method according to another embodiment of the present disclosure. FIG. 4 is a flowchart of a malicious code detection method according to another embodiment of the present disclosure. FIG. 5 is a drawing for illustrating a token preconfiguration method referenced in some embodiments of the present disclosure. FIG. 6 is a flowchart of a malicious code detection method according to another embodiment of the present disclosure. FIG. 7 is a flowchart of a malicious code detection method according to another embodiment of the present disclosure. FIG. 8 is a flowchart of a malicious code detection method according to another embodiment of the present disclosure. FIG. 9 is a hardware configuration diagram of a computing device that can be used as a component in some embodiments of the present disclosure. Specific details for implementing the invention

[0031] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the attached drawings. The advantages and features of the embodiments of the present disclosure, and the methods for achieving them, will become clear by referring to the embodiments described below in detail together with the attached drawings. However, the technical concept of the present invention is not limited to the following embodiments but can be implemented in various different forms. The following embodiments are provided merely to complete the technical concept of the present invention and to fully inform those skilled in the art of the scope of the present invention, and the technical concept of the present invention is defined only by the scope of the claims.

[0032] It should be noted that when assigning reference numerals to the components of each drawing, the same components are given the same reference numeral whenever possible, even if they are shown in different drawings. Furthermore, in describing the embodiments of the present disclosure, if it is determined that a detailed description of related known components or functions could obscure the essence of the matter, such detailed description is omitted.

[0033] Unless otherwise defined, all terms used in this disclosure (including technical and scientific terms) may be used in a meaning commonly understood by those skilled in the art to which the embodiments of this disclosure pertain. Additionally, terms defined in commonly used dictionaries are not to be interpreted ideally or excessively unless explicitly and specifically defined otherwise. The terms used in this disclosure are intended to describe the embodiments and are not intended to limit the embodiments of this disclosure. In this disclosure, the singular form includes the plural form unless specifically stated otherwise in the text.

[0034] Additionally, terms such as "first," "second," etc., may be used to describe the components of the embodiments of this specification. These terms are intended merely to distinguish the component from other components, and the nature, order, or sequence of the component is not limited by such terms. Where it is stated that a component is "connected," "coupled," or "joined" to another component, it should be understood that the component may be directly connected or joined to the other component, but that another component may also be "connected," "coupled," or "joined" between each component.

[0035] Hereinafter, several embodiments will be described with reference to the attached drawings.

[0036] With reference to FIG. 1, the configuration and operation of a malicious code detection system according to one embodiment of the present disclosure will be described. The malicious code detection system according to the present embodiment may include a service server (100), a first database server (101), and a second database server (102).

[0037] The service server (100) obtains an executable file, determines whether the executable file is malicious code, and outputs the determination result. The executable file may be stored in the storage device or memory of the service server (100), or may be received by the service server (100) via a network. Additionally, data regarding the determination result may be transmitted to another service server via a network or to a user terminal (103).

[0038] The first database server (101) can store a training data set composed of a plurality of executable files. The executable files may be, for example, PE files. The service server (100) can transmit the executable files to the first database server (101). For example, the service server (100) is a server that provides corporate cloud storage services and can provide a malicious code detection service for executable files stored in cloud storage. At this time, the service server (100) can selectively transmit executable files that meet certain conditions to the first database server (101).

[0039] The above executable file is not limited to PE files. For example, the embodiments of the present disclosure may be applied to executable files of various formats, such as ELF, an executable file format of Unix-like operating systems; Mach-O, an executable file format of macOS; and COM, an executable file format of DOS operating systems.

[0040] The service server (100) may perform a preliminary preparation process using a training data set stored in the first database server (101) periodically or non-periodically. The preliminary preparation process may include at least some of the token preliminary configuration, token preliminary update, and the execution of a training stage of a model composed of an artificial neural network.

[0041] The service server (100) may store the data generated as a result of performing the above preliminary preparation process itself or store it in the second database server (102). For example, the second database server (102) may store token preliminary data.

[0042] The service server (100) can use the data generated as a result of the execution of the above-mentioned preliminary preparation process to execute a static analysis method of malicious code detection logic on an executable file and output whether the executable file is malicious code. The malicious code detection logic may include at least one of a preprocessing process, a detection process based on the semantic information of a basic block of a CFG (Control Flow Graph), a detection process based on the semantic information of a subroutine such as a function, a detection process based on the format information of an executable file, and a detection process based on the byte stream of the executable file itself.

[0043] Each process included in the above preliminary preparation process and the above malicious code detection logic will be described in detail later through several embodiments of the present disclosure. Additionally, although the first database server (101) and the second database server (102) are shown in FIG. 1 as devices separate from the service server (100), at least one of the first database server (101) and the second database server (102) may be omitted depending on the embodiment.

[0044] Next, a method for detecting malicious code according to another embodiment of the present disclosure will be described with reference to FIGS. 2 and 3. The method for detecting malicious code according to the present embodiment may be performed by one or more computing devices. That is, the method for detecting malicious code according to the present embodiment may have all operations performed by one computing device, or some operations performed by another computing device. In describing the method according to the present embodiment below, the description of the entity performing some operations may be omitted. In this case, it should be understood that the entity performing the operation is the computing device. The computing device may be, for example, the service server (100) in the embodiment described with reference to FIG. 1, but the computing device is not limited to being the service server (100).

[0045] FIG. 2 may be understood as a flowchart for explaining the above-mentioned preprocessing process. Hereinafter, a 'PE file' may be illustrated as an example of the executable file in the drawings, but it should be noted that the embodiments of the present disclosure may also be applied when an executable file other than a PE file is input.

[0046] When a PE file (10) is input, it is checked whether it is packed (S1). Since static analysis is not possible for a packed PE file (10), if the packed PE file is in a format that can be unpacked using a known binary unpacking technique (S2), unpacking is attempted (S3). If unpacking fails (S4) or if the packed PE file is in a format that cannot be unpacked (S2), an error message indicating the unpacking failure is output (S5), and the malicious code detection procedure is terminated.

[0047] In some embodiments, the malicious code detection procedure may not be terminated even if unpacking fails (S4) or if the packed PE file is in a format that cannot be unpacked. That is, steps S6 to S19 of FIG. 3 may be executed even if unpacking fails (S4) or if the packed PE file is in a format that cannot be unpacked. In other words, since various methods of malicious code detection are performed comprehensively in the present disclosure, malicious code detection is possible even if the unpacking of the PE file fails.

[0048] Referring to Fig. 3, the malicious code detection logic after the preprocessing process is explained.

[0049] First, it must be understood that the above-mentioned malicious code detection logic can output a final malicious code detection result by comprehensively considering various types of malicious code detection results. As illustrated in FIG. 3, various types of malicious code detection results (S12 to S18) are comprehensively considered, and a final malicious code detection result can be generated according to the ensemble prediction method (S19). That is, during the ensemble prediction (S19) process, the malicious code detection results (S12 to S18) are weighted and summed, and whether the result exceeds a threshold value can be determined as to whether the executable file is malicious code.

[0050] Of course, the above malware detection logic may execute only some types of malware detection processes. The above malware detection logic may execute only specific types of malware detection processes.

[0051] As a first method of malware detection, a malware detection model that receives PE format information may be used. The first type of PE format information-based malware detection model may receive format information of an unpacked PE file (S6, S12). The second type of PE format information-based malware detection model may receive format information of the PE file itself (S11, S17). Regarding the first method of malware detection mentioned above, Samuel Kim, "PE Header Analysis for Malware Detection PE Header Analysis for Malware Detection", 2018 ( https: / / doi.org / 10.31979 / etd.q3dd-gp9u ), Edward Raff, Jared Sylvester, Charles Nicholas, "Learning the PE Header, Malware Detection with Minimal Domain Knowledge", 2017, ( https: / / doi.org / 10.1145 / 3128572.3140442 You may refer to publicly available literature such as ).

[0052] As a second method of malware detection, a byte stream-based malware detection model that receives the PE file itself as input may be used (S18). At this time, it can be understood that it is determined whether the PE file itself has characteristics similar to an executable file known as malware. In relation to the second method of malware detection mentioned above, Angelo Oliveira, "MALWARE ANALYSIS DATASETS: RAW PE AS IMAGE", 2019, ( https: / / dx.doi.org / 10.21227 / 8brp-j220 ), Damin Moon, JaeKoo Lee, MyungKeun Yoon, "Compact feature hashing for machine learning based malware detection", 2021.8, ( https: / / doi.org / 10.1016 / j.icte.2021.08.005 You may refer to publicly available literature such as ).

[0053] As a third method of malware detection, malware detection based on the basic block semantic information of a Control Flow Graph (CFG) may be performed. To this end, an attempt is made to extract and disassemble a Control Flow Graph (CFG) for a PE file (10) (S7). If the result of the attempt (S7) is successful (S8), malware detection using a malware detection model based on the basic block semantic information of a CFG will be performed (S13). If the result of the attempt (S7) is a failure (S8), data indicating the failure will be considered in the ensemble prediction (S19) process (S14). The third method of malware detection will be described in more detail later through several embodiments of the present disclosure.

[0054] As a fourth method of malicious code detection, malicious code detection based on semantic information of subroutines, such as functions, may be performed. To this end, a function call graph extraction and disassembly of a PE file (10) is attempted (S9), and if the result of the attempt (S9) is successful (S10), malicious code detection using a malicious code detection model based on semantic information of each function called in the PE file is performed (S15), and if the result of the attempt (S9) is a failure (S10), data indicating failure is considered in the ensemble prediction (S19) process (S16). The fourth method of malicious code detection will be described in more detail later through several embodiments of the present disclosure.

[0055] Next, with reference to FIGS. 4 and 5, a method for detecting malicious code based on the semantic information of the basic blocks of a Control Flow Graph (CFG) will be described.

[0056] First, the pre-training process (S130) is explained.

[0057] For malware detection, several operations need to be prepared in advance, which are referred to as pre-training in this disclosure. The pre-training includes the construction of a token dictionary and machine learning processes for several neural network-based models. Each of these processes is described in detail below.

[0058] 1. Building a Token Dictionary

[0059] The aforementioned token dictionary can be understood as data containing the token embedding for each token. It can be understood as pre-storing optimized token embeddings to save time in obtaining token embeddings for each token at the time of malware detection.

[0060] In the present disclosure, the 'token' refers to each instruction of the assembly code. That is, the token will correspond to the opcode and its operand included in the assembly code corresponding to the token. Additionally, a token embedding may be understood as one or more numbers representing the token.

[0061] For example, the process of assigning token embeddings to the instruction "cmp ecx, 0x408963" is described. In some embodiments, normalization of the operands may be performed to prevent the number of tokens included in the token dictionary from increasing unnecessarily. For example, 4-byte registers such as ecx, r8d, and eax may be normalized as 'reg4', and constant values ​​such as 0x408963 may be normalized as 'im'.

[0062] As described above, the process of assigning token embeddings to the normalized instruction "cmp reg3, im" is explained. Let us assume that the operator 'cmp' is assigned an embedding of [0.03, 0.16, 1.92, 쪋], the operand "reg4" is assigned an embedding of [0.62, -0.125, 0.76, 쪋], and the operand "im" is assigned an embedding of [1.5, 1.6, -0.92]. In this case, to reflect the importance of the operator, operator importance can be generated using keyword selection logic such as a TF-IDF model, and the said operator importance can be reflected as a weight in the embedding for the operator. Next, the operator embedding with the weighted embedding and the operand embedding are concatenated to finally generate the token embedding.

[0063] Assembly code is obtained by applying disassembly to each executable file of the training data, and token embeddings are generated for at least some of the instructions included in the assembly code in the manner described above. Each token and the generated token embedding will form a pair and be added to the token dictionary.

[0064] In some embodiments, the instruction for the token to be added to the token dictionary is not obtained from the assembly code of the executable file itself, but rather from the sequential execution statement obtained as a result of performing a random walk on the CFG extracted from the executable file. Regarding the random walk, see Jifeng Xuan, He Jiang, Zhilei Ren, Yan Hu, Zhongxuan Luo, "A Random Walk Based Algorithm for Structural Test Case Generation", 2017( https: / / arxiv.org / pdf / 1704.04772 You may refer to various public literature such as ).

[0065] The above sequential execution statement reflects instructions to be executed sequentially at runtime. It may be understood that the above sequential execution statement better represents the behavior of the executable file when it is executed than the assembly code itself, and in this disclosure, the above sequential execution statement is referred to as an article.

[0066] In addition, in some embodiments, tokens may be extracted from the assembly code of the executable file itself, and additionally, tokens may be extracted from the article. In this case, the effect of extracting as many tokens as possible from the training data can be obtained.

[0067] In some embodiments, the token embedding may be optimized using Word2Vec technology. For example, Continuous Bag of Words (CBOW) technology among Word2Vec technologies may be used for the optimization of the token embedding. In this case, since CBOW technology is a technology that predicts a target word using adjacent context words, token embedding optimization using CBOW technology may be performed on tokens extracted from articles that reflect the execution order of each instruction when an executable file is executed.

[0068] When applying CBOW technology, the range of context words may vary depending on the required detection accuracy. In other words, the window size can be adjusted according to the required detection accuracy. That is, if the token dictionary is designed to handle a high level of detection accuracy, a large window will be applied to optimize token embedding, even if it takes more time; conversely, if the token dictionary is designed to handle a low level of detection accuracy, a small window will be applied to optimize token embedding quickly. The aforementioned detection accuracy may be managed as a system configuration value. Alternatively, the detection accuracy may be automatically adjusted considering factors such as system traffic.

[0069] In some embodiments, as illustrated in FIG. 5, the token dictionary construction may be stopped at a point where the number of added tokens is negligible, even if training data remains, in order to minimize the time required for the token dictionary construction. That is, the token addition process is repeated for each executable file included in the training data set, and it can be understood that the token addition process is terminated when the number of added tokens resulting from the repetition falls below a first threshold, even if there are remaining executable files. The first threshold may also be managed as a system environment setting value.

[0070] Additionally, in some embodiments, the intermediate termination requirement may be strengthened so that the token addition process is terminated only when the number of times the number of additional tokens resulting from the iteration falls below the first threshold is greater than or equal to the second threshold. The second threshold may also be managed as the system environment setting value.

[0071] The above first threshold and the above second threshold may be automatically adjusted based on the detection accuracy or automatically adjusted considering system traffic.

[0072] 2. Machine learning for artificial neural network-based models

[0073] (1) Machine learning of the CBOW model

[0074] As described above, optimization of token embeddings using CBOW technology is performed during the construction of the token dictionary. Machine learning of the CBOW model for the application of the CBOW technology may be performed prior to the construction of the token dictionary. Since the machine learning process of the CBOW model can be described by referring to numerous known literatures, a detailed explanation is omitted.

[0075] (2) Machine learning of classification models

[0076] Machine learning is performed on classification models based on artificial neural networks. In this disclosure, a GNN-based classification model or a CNN-based classification model may be used. Both the GNN-based classification model and the CNN-based classification model may include a Fully-Connected Layer (FCL) that acts as a classifier, and the FCL will be connected prior to the output layer.

[0077] 1) GNN-based classification model

[0078] The above GNN-based classification model can be used in the process of detecting malware based on semantic information by basic block of CFG or in the process of detecting malware based on semantic information by function. For convenience, the GNN-based classification model used in the process of detecting malware based on semantic information by basic block of CFG will be referred to as the first GNN-based classification model, and the GNN-based classification model used in the process of detecting malware based on semantic information by function will be referred to as the second GNN-based classification model.

[0079] The above-described first GNN-based classification model receives input feature data pointing to a representation of a CFG during the process of detecting malicious code based on semantic information per basic block of a CFG, and outputs data regarding whether or not it is malicious code. The representation of the CFG includes a feature vector of a basic block, which is a node of the graph. The feature vector of the basic block points to semantic information of the basic block.

[0080] The feature vector of the basic block may be generated using the token embeddings of each token belonging to the basic block. Each token belonging to the basic block may be extracted from the article corresponding to the basic block. For example, the feature vector of the basic block may be a representative value (e.g., an average value) of the token embeddings of all tokens in the article corresponding to the basic block, or a representative value of the token embeddings of some tokens selected based on the importance of the token's instruction (opcode).

[0081] The token embedding for each token belonging to the above basic block is a value read from a token dictionary configured in the manner described above. If a token belonging to the above basic block is not included in the token dictionary, the value of the token embedding may be zero.

[0082] That is, the first GNN-based classification model receives input information regarding the semantic information of each basic block of an executable file and the connection relationships between the basic blocks. In other words, the first GNN-based classification model detects whether a file is malicious code based on CFG information indicating the overall execution flow of the executable file. Since the feature vector of the basic block, which is a node of the CFG, represents the semantic information of the basic block, it will not be easy to evade detection of malicious code through simple modifications.

[0083] In the training process of the first GNN-based classification model, input feature data pointing to CFG representations for each executable file included in the training data is input into the first GNN-based classification model, and the weights of the first GNN-based classification model will be updated in a direction in which the output of the first GNN-based classification model predicts whether the executable file is malicious.

[0084] Next, the training process of the above-mentioned second GNN-based classification model is explained.

[0085] The above-described second GNN-based classification model receives input feature data indicating a representation of a function call graph during the process of detecting malicious code based on the semantic information of a function, and outputs data regarding whether or not it is malicious code. The representation of the function call graph includes feature vectors of functions that are nodes of the graph. The feature vectors of the functions indicate the semantic information of the functions.

[0086] The feature vector of the above function can be generated using the token embeddings of each token belonging to the function and the embeddings of the function itself. Each token belonging to the function may be extracted from an article corresponding to the function. For example, the feature vector of the function may be a representative value (e.g., an average value) of the token embeddings of all tokens in the article corresponding to the function, or a representative value of the token embeddings of some tokens selected based on the importance of the token's instruction (opcode).

[0087] The token embedding for each token belonging to the article corresponding to the above function is a value read from a token dictionary configured in the manner described above. If a token belonging to the above basic block is not included in the above token dictionary, the value of the token embedding may be zero.

[0088] Furthermore, the embedding of the function itself can be optimized using Word2Vec technology after an initial value is assigned based on identification information, such as an ID assigned to the function. During the application of Word2Vec technology, the embedding of the function itself is updated to reflect the token embedding of the token included in the function's article. Among the Word2Vec technologies, PV-DM (Paragraph Vector - Distributed Memory) technology may be applied. That is, it should be understood that the training of the PV-DM model precedes the training of the second GNN-based classification model. The training of the PV-DM model will be described in detail later.

[0089] The above second GNN-based classification model receives semantic information about each function of an executable file and information about the call relationships between functions as input. That is, the above second GNN-based classification model detects whether a file is malicious code based on function call information that indicates the overall execution flow of the executable file. Since the feature vector of a function, which is a node of the function call graph, represents the semantic information of the function, it will not be easy to evade malicious code detection with only simple modifications.

[0090] During the training process of the second GNN-based classification model, input feature data indicating the representation of the function call graph for each executable file included in the training data is input into the second GNN-based classification model, and the weights of the second GNN-based classification model are updated in a direction in which the output of the second GNN-based classification model predicts whether the executable file is malicious.

[0091] At least some of the first GNN-based classification model and the second GNN-based classification model may include a GIN layer (Graph Isomorphism Network layer). The GIN layer can more accurately reflect structural differences between graphs in the embeddings compared to a GCN (Graph Convolutional Network).

[0092] In some embodiments, the number of layers of the GIN layer is limited to N (where N is a natural number). N may be 5 or less, for example, 3. In the case of malicious code, it is thought that characteristics indicating the nature of the malicious code will appear in a very small area of ​​instructions or a structure of connections between a small number of nodes. This is because detection becomes easier if the characteristics of the malicious code exist in a wide area. Therefore, configuring the GIN layer with multiple layers may lead to a waste of resources. Of course, the number of the GIN layer may be adjusted according to detection accuracy. As the detection accuracy increases, the number of the GIN layer may increase.

[0093] 2) PV-DM model

[0094] The training of the PV-DM model is explained below.

[0095] The above PV-DM model optimizes the function embedding so that the function embedding reflects the token embeddings of the tokens belonging to the function. If the function is a single document, the tokens of the article corresponding to the function will be the words contained within the document. Just as the document embedding is optimized to reflect the words belonging to the document, it can be understood that the function embedding is optimized to reflect the token embeddings of the tokens belonging to the function. In the machine learning process of the above PV-DM model, each executable file included in the training data may be utilized.

[0096] An article corresponding to a function may be constructed using the CFG of the function and the assembly code of the function. An article corresponding to a function may be constructed by including at least one of the tokens selected in the process of repeatedly selecting tokens corresponding to two instructions connected to an edge randomly sampled in the CFG of the function, and tokens selected as a result of a random walk on the CFG of the function.

[0097] Function embedding optimization using a PV-DM model is performed based on the tokens included in the function-corresponding article configured as described above. The optimization may mean that the update of the function embedding is repeated, and such update may be performed by shifting the window for each token included in the article. For example, the window will be shifted from the start point to the end point of the article. When the update is completed when the window reaches the end point of the article, the function embedding value may be understood as optimized. In some embodiments, if the parameter is set so that the epoch is greater than 1, window traversal equal to the epoch may occur for the article.

[0098] The case where the size of the window is 3 is explained as an example. The function embedding and the token embedding of each token in the window can be updated so that the average of the function embedding, the first token of the window, and the third token of the window matches the second token of the window. That is, by updating the matrix included in the PV-DM model, the function embedding and the token embedding of each token in the window can be updated so that they match the second token of the window.

[0099] The window size can be adjusted according to the required detection accuracy. That is, to handle a high level of detection accuracy, the PV-DM model will be trained using a large window, even if it takes more time, while to handle a low level of detection accuracy, the PV-DM model will be trained using a small window.

[0100] 3) CNN-based classification model

[0101] The above CNN-based classification model can be used in the process of detecting malicious code based on semantic information of functions. To train the above CNN-based classification model, function embedding optimization using a PV-DM model can be performed for each function belonging to each executable file included in the training data, and the optimized function embedding is used as a feature vector of the function.

[0102] The input feature vector of the CNN-based classification model is obtained using the feature vectors of each of the above-mentioned functions. For example, if the feature vector of the function is composed of n dimensions and the number of functions in the executable file is m, the input feature vector of the CNN-based classification model may be composed of (m x n) matrix data containing each function feature vector.

[0103] In this case, the order in which each function feature vector is included in the input feature vector may depend on the address value of each function. For example, the input feature vector may be constructed by arranging the function feature vectors in increasing order of each function's address. In this case, by having the CNN layer initially learn the feature vector of the function most likely to be executed first, the learning speed of the CNN-based classification model can be increased.

[0104] Of course, in some embodiments, the input feature vector may be constructed by arranging the function feature vectors in decreasing order of the addresses of each function.

[0105] In the convolution operation performed during the training process of the above CNN-based classification model, the kernel can traverse the input feature vector in one dimension. This is because, among the two axes constituting the input feature vector (index movement of the feature vector of a single function and movement to different functions), index movement in the feature vector of a single function is not significant. That is, the above CNN-based classification model may be a 1D CNN-based classification model trained by 1D convolution operations.

[0106] So far, the pre-training process (S130) has been explained. The method illustrated in FIG. 4 is a method performed during the inference process, and since the actions performed during the training process can be performed identically depending on the similarity between the training process and the inference process, we will omit redundant explanations and continue to explain the malicious code detection method of FIG. 4.

[0107] When a PE file is input (S131), disassembly is performed on the PE file to obtain the assembly code of the PE file and the CFG of the PE file is extracted (S132).

[0108] Next, a feature vector for each basic block of the CFG is extracted in the manner described above. That is, an article of the basic block is constructed, and the token embedding of each token included in the article is looked up in the token dictionary. At this time, the token can be looked up in the token dictionary after normalization. If the token is not looked up in the token dictionary, its token embedding will be determined as 0. Additionally, the feature vector of the basic block can be determined using the representative value of the optimized token embeddings.

[0109] Next, a representation of the CFG reflecting the feature vector for each basic block is generated (S134), and an input feature vector is generated from the representation of the CFG (S135). In addition, the generated input feature vector is input into the first GNN-based graph classification model (S136).

[0110] Finally, the data output from the first GNN-based graph classification model is used to determine whether the PE file is malicious code (S137).

[0111] Next, a first malicious code detection method based on semantic information of a function is described with reference to FIG. 6. The pre-training step (S150) refers to the description with reference to FIG. 4.

[0112] When a PE file is input (S151), disassembly is performed on the PE file to obtain the assembly code of the PE file and the function unit CFG of the PE file is extracted (S152). In addition, a function call graph can be extracted for the PE file.

[0113] Next, a feature vector for each function included in the PE file is extracted in the manner described above (S153). That is, an article of the function is constructed, and the token embedding of each token included in the article is looked up in the token dictionary. It has already been explained that the article can be constructed using instructions connected to edges sampled from the function's CFG as a result of performing a random walk on the assembly code of the function and the function's CFG. At this time, the token can be looked up in the token dictionary after normalization. If the token is not looked up in the token dictionary, its token embedding will be determined as 0.

[0114] Additionally, the feature vector of the above function may be a function embedding that is initially set using the identification information of the function and optimized by a Word2Vec model such as PV-DM. It has already been explained that in the optimization process, the function embedding reflects information about the tokens belonging to the function's article by reflecting the token embeddings of the tokens within the function's article. That is, a window consisting of three consecutive tokens included in the article is set, and the function embedding can be updated so that the average of the function embedding, the first token of the window, and the third token of the window matches the second token of the window. The setting step and the updating step may be repeated while shifting the window until the end of the article is reached. At this time, the function embedding will be updated while the parameters of the PV-DM model and the tokens of the window remain fixed.

[0115] Next, a representation of a function call graph reflecting the feature vector of each function is generated (S154), and an input feature vector is generated from the representation of the function call graph (S155). In addition, the generated input feature vector is input into the second GNN-based graph classification model (S156).

[0116] Finally, the data output from the second GNN-based graph classification model is used to determine whether the PE file is malicious code (S157).

[0117] Next, a second malicious code detection method based on semantic information of a function is described with reference to FIG. 7. The pre-training step (S160) refers to the description with reference to FIG. 4.

[0118] When a PE file is input (S161), disassembly is performed on the PE file to obtain the assembly code of the PE file and the function unit CFG of the PE file is extracted (S162).

[0119] Next, feature vectors for each function included in the PE file are extracted in the manner described above with reference to FIG. 6 (S163). Next, an input feature vector is generated using the feature vectors of each function (S164). At this time, as described above, the input feature vector can be generated by arranging the feature vectors of each function in a sorted order based on the function's address value. The generated input feature vector is input into the CNN-based graph classification model (S165). Finally, whether the PE file is malicious code is determined using the data output from the CNN-based graph classification model (S166).

[0120] In some embodiments, as illustrated in FIG. 8, the function semantic information-based malware detection method may selectively perform the first method described with reference to FIG. 6 and the second method described with reference to FIG. 7. That is, for an input PE file (S161), when the extraction of the function call graph is successful (S162-1), a GNN-based malware detection model according to the first method (S1500) described with reference to FIG. 6 may be used, and when the extraction of the function call graph fails (S162-1), a CNN-based malware detection model according to the second method (S1600) described with reference to FIG. 7 may be used.

[0121] The technical concept of the present disclosure described so far with reference to FIGS. 1 through 8 may be implemented as computer-readable code on a computer-readable medium. The computer-readable recording medium may be, for example, a removable recording medium (USB storage device, removable hard disk). The computer program recorded on the computer-readable recording medium may be transmitted to another computing device via a network such as the Internet and installed on the other computing device, thereby being used on the other computing device.

[0122] Hereinafter, the hardware configuration of an exemplary computing device according to some embodiments of the present disclosure will be described with reference to FIG. 9. The computing device may be, for example, a service server (100) described with reference to FIG. 1.

[0123] FIG. 9 is an exemplary hardware configuration diagram that can implement a computing device in various embodiments of the present disclosure. A computing device (1000) according to the present embodiment may include a processor (1100), a system bus (1600), a communication interface (1200), a memory (1400) for loading a computer program (1500) executed by the processor (1100), and a storage (1300) for storing the computer program (1500). FIG. 9 illustrates only the components related to the embodiments of the present disclosure. Therefore, a person skilled in the art to which the present disclosure pertains will understand that other general-purpose components may be included in addition to the components illustrated in FIG. 9.

[0124] The processor (1100) controls the overall operation of each component of the computing device (2000). The processor (1100) may be understood as a Central Processing Unit (CPU). Additionally, the processor (1100) may perform operations for at least one application or program to execute a method / operation according to various embodiments of the present disclosure. In some embodiments, the computing device (1000) may further include a Graphics Processing Unit (GPU) (1150). Operations related to machine learning, etc., may be executed through the GPU (1150) rather than the processor (1100).

[0125] The memory (1400) stores various data, commands and / or information. The memory (1400) may load one or more programs (190) from the storage (1300) to execute methods / operations according to various embodiments of the present disclosure. Examples of the memory (1400) may be Random Access Memory (RAM), but are not limited thereto.

[0126] The system bus (1600) provides communication functions between components of the computing device (1000). The system bus (1600) can be implemented as various types of buses, such as an address bus, a data bus, and a control bus. The communication interface (1200) supports wired and wireless internet communication of the computing device (1000). The communication interface (1200) may also support short-range wireless communication methods other than internet communication, such as Bluetooth.

[0127] A computing device (1000) may be connected via a communication interface (1200) to at least one of a database server (not shown) in which learning data composed of PE files, etc. is stored, and a database server (not shown) in which data of a token dictionary containing data for each token extracted as a result of analysis of said learning data is stored. Additionally, the computing device (1000) may be connected via a communication interface (1200) to a user terminal.

[0128] Storage (1300) may store one or more computer programs (1500) non-temporarily. Storage (1300) may be configured to include non-volatile memory such as flash memory, a hard disk, a removable disk, or any form of computer-readable recording medium well known in the art to which this disclosure belongs.

[0129] A computer program (1500) may include one or more instructions in which methods / operations according to various embodiments of the present disclosure are implemented. When the computer program (1500) is loaded into memory (1400), a processor (1100) may perform methods according to various embodiments of the present disclosure by executing the one or more instructions.

[0130] The computer program (1500) is a malicious code detection program that analyzes an executable file, which is a target for malicious code detection, using a static analysis method and determines whether the executable file is malicious code using the analysis results. The executable file may be a file stored in storage (1300) or a file received through a communication interface (1200).

[0131] A computer program (1500) comprises: a first instruction for obtaining a token embedding-based first feature vector for each basic block included in a Control Flow Graph (CFG) of an executable file that is a target for malicious code detection, and generating a first input feature vector representing the CFG using the connection relationship between each basic block of the CFG and the first feature vector of each basic block; a second instruction for obtaining a second feature vector for each function included in the executable file; a third instruction for generating a second input feature vector representing the function call graph using the connection relationship between each function included in the function call graph of the executable file and the second feature vector of each function; a fourth instruction for generating a third input feature vector including the second feature vectors for each function included in the executable file; and determining whether the executable file is malicious code using the output data of a first Graph Neural Network (GNN)-based graph classification model that receives the first input feature vector. It may include a fifth instruction for determining, a sixth instruction for determining whether the executable file is malicious code using output data of a second GNN (Graph Neural Network)-based graph classification model that receives the second input feature vector, and a seventh instruction for determining whether the executable file is malicious code using output data of a CNN (Convolutional Neural Network)-based graph classification model that receives the third input feature vector.

[0132] The above malware detection program may execute a first group instruction consisting of the third instruction and the sixth instruction if it succeeds in extracting the function call graph from the executable file, and execute a second group instruction consisting of the fourth instruction and the seventh instruction if it fails to extract the function call graph. That is, the malware detection program may selectively execute either the first group instruction or the second group instruction.

[0133] Although embodiments of the present disclosure have been described above with reference to the attached drawings, those skilled in the art will understand that the embodiments of the present disclosure may be implemented in other specific forms without altering the technical concept or essential features thereof. Therefore, the embodiments described above should be understood as illustrative in all respects and not restrictive. The scope of protection of the present invention shall be interpreted by the claims below, and all technical concepts within the equivalent scope shall be interpreted as being included within the scope of rights of the technical concepts defined by the present disclosure.

Claims

Claim 1 A method performed by a computing device comprises: obtaining a token embedding-based feature vector for each basic block included in a Control Flow Graph (CFG) of an executable file; generating a representation of the CFG using the connection relationships between each basic block of the CFG and the feature vector of each basic block; generating an input feature vector from the representation of the CFG; and inputting the input feature vector into a Graph Neural Network (GNN)-based graph classification model. A method for detecting malicious code, comprising the step of determining whether the executable file is malicious code using the output data of the graph classification model, wherein the executable file is composed of a plurality of instructions, and each instruction corresponds to a token including an opcode and an operand; further comprising, prior to the step of obtaining the token embedding-based feature vector, the step of constructing a token dictionary composed of tokens and their token embeddings using a training dataset including a plurality of executable files; and wherein the step of obtaining the token embedding-based feature vector includes the step of obtaining the token embedding of each token corresponding to the basic block by querying the token dictionary. Claim 2 delete Claim 3 A method for detecting malicious code according to claim 1, wherein the step of constructing the token dictionary comprises: obtaining a first executable file included in the training dataset; obtaining a CFG of the first executable file; disassembling the first executable file to obtain assembly code of the first executable file; obtaining an article for the first executable file using the result of performing a random walk on the CFG and the assembly code; extracting a plurality of tokens from the article; calculating a token embedding for each of the extracted tokens; optimizing the calculated token embedding by applying a Continuous Bag of Words (CBOW) method; and adding the extracted tokens and the optimized token embedding to the token dictionary. Claim 4 In claim 3, the step of optimizing by applying the CBOW method comprises: a step of applying the CBOW method using a first number of context words when the malware detection accuracy is set to a first level; and a step of applying the CBOW method using a second number of context words smaller than the first number when the malware detection accuracy is set to a second level lower than the first level. Claim 5 A method for detecting malicious code according to claim 1, wherein the step of configuring the token dictionary comprises: a step of performing a token addition process into the token dictionary for an executable file included in the training data set; and a step of repeating the token addition process for each executable file included in the training data set, wherein if the number of additional tokens resulting from the repetition falls below a threshold, the token addition process is terminated even if there are remaining executable files. Claim 6 A method for detecting malicious code according to claim 1, wherein the step of obtaining a token embedding of each token corresponding to the basic block by querying the token dictionary includes the step of assigning a token embedding of a new token not queried in the token dictionary as a zero embedding. Claim 7 A method for detecting malicious code according to claim 1, wherein the step of inputting the input feature vector into a GNN-based graph classification model includes the step of inputting the input feature vector into a graph classification model including a GIN layer (Graph Isomorphism Network layer). Claim 8 A malicious code detection method according to claim 7, wherein the graph classification model comprises five or fewer GIN layers. Claim 9 In claim 7, the step of inputting the input feature vector into the graph classification model including a GIN layer (Graph Isomorphism Network layer) comprises: the step of inputting the input feature vector into a first graph classification model including a first number of GIN layers when the malware detection accuracy is set to a first level; and the step of inputting the input feature vector into a second graph classification model including a second number of GIN layers smaller than the first number when the malware detection accuracy is set to a second level lower than the first level, wherein the malware detection method. Claim 10 A method performed by a computing device comprises: obtaining a feature vector for each function included in an executable file; generating a representation of a function call graph using the connection relationships between each function included in the function call graph of the executable file and the feature vector of each function; generating an input feature vector from the representation of the function call graph; inputting the input feature vector into a graph classification model based on a Graph Neural Network (GNN); and determining whether the executable file is malicious code using the output data of the graph classification model, wherein the step of obtaining the feature vector comprises: generating a function embedding for identification information of a first function of the executable file; obtaining a first function control flow graph (CFG) for the first function; and obtaining assembly code of the first function. A method for detecting malicious code, comprising: a step of obtaining an article for the first function using instructions connected to edges sampled from the first function CFG as a result of performing a random walk on the assembly code of the first function and the first function CFG; a step of querying a token embedding for a token constituting the article in a token dictionary; a step of inputting the queried token embedding and the function embedding into a pre-trained PV-DM (Paragraph Vector - Distributed Memory) model to optimize the function embedding; and a step of determining the optimized function embedding as a feature vector for the first function. Claim 11 In claim 10, prior to the step of obtaining a feature vector for each of the above functions, the method further comprises the step of constructing the token dictionary composed of tokens and their token embeddings using a training dataset including a plurality of executable files, and the step of training an optimization model for optimizing the feature vector of the function, wherein the step of training the optimization model comprises: generating a function embedding for identification information of a second function of a first executable file included in the training dataset; obtaining a first function CFG for the second function; obtaining assembly code of the second function; obtaining an article for the second function using instructions connected to edges sampled from the second function CFG as a result of performing a random walk on the assembly code of the second function and the second function CFG; and querying the token embedding for the token constituting the article in the token dictionary. A malicious code detection method comprising the step of inputting the queried token embedding and the function embedding into the PV-DM model to train the PV-DM model, wherein the optimization model is the PV-DM model. Claim 12 In claim 11, the step of training the PV-DM model comprises: a step of setting a window composed of three consecutive tokens included in the article; a step of updating the function embedding and the token embedding of each token of the window such that the average of the function embedding, the first token of the window, and the third token of the window matches the second token of the window; and a step of repeating the setting step and the updating step while shifting the window until the end of the article is reached. Claim 13 delete Claim 14 In claim 10, the step of optimizing the function embedding comprises: a step of setting a window composed of three consecutive tokens included in the article; a step of updating the function embedding such that the average of the function embedding, the first token of the window, and the third token of the window matches the second token of the window; and a step of repeating the setting step and the updating step while shifting the window until the end of the article is reached. Claim 15 A malicious code detection method according to claim 14, wherein the step of updating the function embedding includes the step of updating the function embedding while the parameters of the PV-DM model and the token of the window are fixed. Claim 16 A method performed by a computing device comprises: obtaining a feature vector for each function included in an executable file; constructing an input feature vector containing the feature vectors of each function; inputting the input feature vector into a classification model based on a Convolutional Neural Network (CNN); and determining whether the executable file is malicious code using the output data of the classification model, wherein the step of obtaining the feature vector comprises: generating a function embedding for identification information of a first function of the executable file; obtaining a first function control flow graph (CFG) for the first function; obtaining assembly code of the first function; obtaining an article for the first function using instructions connected to edges sampled from the first function CFG as a result of performing a random walk on the assembly code of the first function and the first function CFG; and querying a token embedding for a token constituting the article in a token dictionary. A method for detecting malicious code, comprising: a step of inputting the retrieved token embedding and the function embedding into a pre-trained PV-DM (Paragraph Vector - Distributed Memory) model to optimize the function embedding; and a step of determining the optimized function embedding as a feature vector for the first function. Claim 17 A malicious code detection method according to claim 16, wherein the step of constructing an input feature vector including feature vectors of each of the above functions comprises the step of constructing the input feature vector by arranging the feature vectors of each of the above functions in an order sorted according to the address of each function. Claim 18 In claim 17, the step of constructing the input feature vector by arranging the feature vectors of each function in an order sorted according to the address of each function comprises the step of constructing the input feature vector by arranging the feature vectors of each function in an ascending order sorted according to the address of each function. Claim 19 In claim 16, the above-mentioned CNN-based classification model is a 1D CNN-based classification model learned by 1D convolution operations, a malicious code detection method. Claim 20 A method performed by a computing device comprises: obtaining a feature vector for each function included in an executable file; attempting to extract a function call graph of the executable file; performing a first process if the extraction of the function call graph is successful, and performing a second process if the extraction of the function call graph is unsuccessful, wherein the first process comprises: generating a representation of the function call graph using the connection relationships between each function included in the function call graph of the executable file and the feature vector of each function; generating an input feature vector from the representation of the function call graph; inputting the input feature vector into a graph classification model based on a Graph Neural Network (GNN); and determining whether the executable file is malicious code using the output data of the graph classification model, and the second process comprises: obtaining a feature vector for each function included in the executable file; constructing input data including the feature vectors of each function; and inputting the input data into a classification model based on a Convolutional Neural Network (CNN). A method for detecting malware, comprising the step of determining whether the executable file is malware using the output data of the classification model. Claim 21 Storage for storing token dictionary data including a token indicating an instruction (opcode) and its operand, and an embedding of said token; memory; and a processor for executing a malicious code detection program loaded into said memory, wherein the malicious code detection program comprises: a first instruction for obtaining a first feature vector based on a token embedding for each basic block included in a Control Flow Graph (CFG) of an executable file that is a target for malicious code detection, and generating a first input feature vector representing said CFG using the connection relationship between each basic block of said CFG and said first feature vector of each basic block; and a second instruction for obtaining a second feature vector for each function included in said executable file. A third instruction for generating a second input feature vector representing the function call graph using the connection relationships between each function included in the function call graph of the executable file and the second feature vector of each function; a fourth instruction for generating a third input feature vector including the second feature vectors for each function included in the executable file; a fifth instruction for determining whether the executable file is malicious code using the output data of a first GNN (Graph Neural Network)-based graph classification model that receives the first input feature vector; and a sixth instruction for determining whether the executable file is malicious code using the output data of a second GNN (Graph Neural Network)-based graph classification model that receives the second input feature vector.A malicious code detection device comprising a seventh instruction that determines whether the executable file is malicious code using output data of a CNN (Convolutional Neural Network)-based graph classification model that receives the third input feature vector. Claim 22 A malware detection device according to claim 21, wherein the malware detection program executes a first group instruction consisting of the third instruction and the sixth instruction if the extraction of the function call graph from the executable file is successful, and executes a second group instruction consisting of the fourth instruction and the seventh instruction if the extraction of the function call graph fails.

Images