A method for constructing a linux module function identification model and application
By constructing a function value matrix through reverse analysis and machine learning models, the problem of identifying the functions of unknown Linux kernel modules was solved, and accurate identification of unknown modules was achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- HUAZHONG UNIV OF SCI & TECH
- Filing Date
- 2023-10-07
- Publication Date
- 2026-06-02
AI Technical Summary
Existing technologies cannot effectively identify the functions of Linux kernel modules from unknown sources or with missing information, resulting in an inability to accurately identify their functions.
By reverse-engineering the call relationships between modules, a function value matrix is constructed, and a machine learning model is trained to identify the functions of unknown modules.
It achieves accurate functional identification of modules from unknown sources, improving the accuracy and efficiency of identification, and eliminating the influence of loop and recursive operations.
Smart Images

Figure CN117435184B_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of computer system security management technology, and more specifically, relates to a method for constructing and applying a Linux module function identification model. Background Technology
[0002] With the development of IoT technology, more and more embedded devices are being used. The vast majority of these devices use the Linux system, and the kernel modules on each device are different. Some of these modules have unknown functions. Identifying the functions of kernel modules with unknown functions plays a key role in kernel security verification, kernel vulnerability detection, and redundant module trimming.
[0003] Existing technologies for identifying the functions of unknown Linux kernel modules mainly employ three methods: querying local module information, comparing with existing databases, and querying network information. Querying local module information involves using the `modinfo` command to retrieve various information stored in the system about the kernel module, including filename, author, version, and description, thereby inferring the module's function. Comparing with existing databases refers to querying the database for unknown module functions, assuming a database of modules and functions has been established. This method is primarily used when the module's origin is known and the vendor's module function database is publicly available. Querying network information involves searching the internet for information such as the module's filename and file location to find relevant information about the module's function.
[0004] The three existing methods for identifying kernel module functions described above are all based on extracting existing module information. For modules not covered by known information, effective function identification is often impossible. Furthermore, among numerous IoT devices, there are many modules of unknown origin and lacking information. These modules cannot be analyzed based on local information, are not common enough to exist in existing databases, and lack sufficient information from the internet to identify their functions. Summary of the Invention
[0005] In view of the above-mentioned defects or improvement needs of the existing technology, the present invention provides a method for constructing a Linux module function identification model and its application, so as to solve the technical problem that the existing technology cannot accurately and effectively identify the functions of modules that are not covered by known information.
[0006] To achieve the above objectives, in a first aspect, the present invention provides a method for constructing a Linux module function identification model, comprising:
[0007] S1. Reverse Analysis: Perform reverse analysis on each module in the pre-collected kernel module set to obtain the call relationships between modules, as well as the external functions called within each module, the number of calls, and the module information defining each external function; based on the call relationships between modules, obtain the modules in the set that depend on other modules, and denot them as upper-level modules;
[0008] S2. Calculation of the function value matrix: For each upper-level module in the kernel module set, obtain the L external functions that are called most frequently, and take the definition module of each external function as a key calling module to obtain L key calling modules. Merge the function value vectors of the L key calling modules to construct the corresponding function value matrix.
[0009] S3. Model Training: Using the function value matrix of each upper-level module as input and the corresponding function value vector of the upper-level module as output, train the machine learning model to obtain the Linux module function recognition model.
[0010] Where L is the smaller of the total number of external functions S in the upper-level module and the preset threshold T; T≥1; the i-th value in the module's function value vector indicates whether the module has the i-th type of function; i=1,2,…,N; N is the number of function types of the Linux module.
[0011] More preferably, when the i-th value indicates that the module has the i-th type of function, the i-th value in the module's function value vector is 1; when the i-th value indicates that the module does not have the i-th type of function, the i-th value in the module's function value vector is 0.
[0012] More preferably, when L = S, after merging the function value vectors of the L key calling modules, one or more function value vectors with all zeros are further merged so that the number of function value vectors in the function value matrix is T.
[0013] More preferably, each non-all-zero function value vector in the function value matrix is multiplied by the number of times the corresponding external function is called.
[0014] More preferably, each non-all-zero function value vector in the function value matrix is multiplied by the smaller of the number of times the corresponding external function is called and the preset weight upper limit.
[0015] More preferably, after sorting the L key calling modules according to a preset sorting order of the number of times the corresponding external functions are called, the function value vectors of each module are merged according to the module order to construct the corresponding function value matrix.
[0016] More preferably, the above-mentioned number of calls is the number of valid calls;
[0017] The effective number of calls to any external function F is n = n1 + n2 - n3;
[0018] Where n1 is the number of times the external function F is called; n2 is the sum of the number of times each function that calls the external function F is called; and n3 is the sum of the number of invalid repetitions of the external function F and each function that calls the external function F.
[0019] The method for obtaining the invalid repetition count m of the external function F and any function F' that calls the external function F is as follows:
[0020] When a conditional statement controls k identical code blocks that call an external function F or F', and each code block calls the external function F or F' j times, then m = (k-1)*j; where k>1 and j is a positive integer.
[0021] When there are k calls to the external function F or function F' within the code block used to define the function, then m = k; where k ≥ 1;
[0022] When a call to an external function F or function F' occurs in a code block controlled by k adjacent loop statements with identical content in execution order, and each code block calls the external function F or function F' j times, then m = (k-1)*j; where k>1 and j is a positive integer;
[0023] When k adjacent code blocks of execution statements have the same content in the execution order, and each code block calls external function F or function F' j times, m = (k-1)*j; where k>1 and j is a positive integer.
[0024] More preferably, the functional categories of the Linux module include: sensor functions, virtualization functions, network device functions, network protocol stack functions, security functions, memory management functions, process management functions, block device functions, disk functions, data acquisition functions, character device functions, graphics card functions, sound card functions, Bluetooth functions, audio device functions, audio processing functions, video processing functions, video device functions, spurious functions, and spurious device functions.
[0025] Secondly, the present invention provides a method for identifying the function of a Linux module, including:
[0026] The Linux module to be identified and the modules it calls are reverse-engineered to obtain the external functions called within the Linux module and the number of times they are called.
[0027] The Linux module is processed according to the function value matrix calculation method described in step S2 of the Linux module function identification model construction method provided in the first aspect to obtain the corresponding function value matrix;
[0028] The function value matrix is input into the Linux module function identification model constructed using the method for constructing the Linux module function identification model provided in the first aspect of the present invention, and the function identification result of the Linux module is obtained.
[0029] More preferably, the above-mentioned number of calls is the number of valid calls;
[0030] At this point, step A2 includes: processing the Linux module according to the function value matrix calculation method in step S2 of the method for constructing a Linux module function identification model based on the number of effective calls provided in the first aspect of the present invention, to obtain the corresponding function value matrix;
[0031] Step A3 includes: inputting the function value matrix into the Linux module function identification model constructed using the construction method of the Linux module function identification model based on the effective call count provided in the first aspect of the present invention, to obtain the function identification result of the Linux module;
[0032] Wherein, the effective number of calls to any external function F is n = n1 + n2 - n3; n1 is the number of times the external function F is called; n2 is the sum of the number of times each function that calls the external function F is called; n3 is the sum of the number of invalid repetitions of the external function F and each function that calls the external function F;
[0033] The method for obtaining the invalid repetition count m of the external function F and any function F' that calls the external function F is as follows:
[0034] When a conditional statement controls k identical code blocks that call an external function F or F', and each code block calls the external function F or F' j times, then m = (k-1)*j; where k>1 and j is a positive integer.
[0035] When there are k calls to the external function F or function F' within the code block used to define the function, then m = k; where k ≥ 1;
[0036] When a call to an external function F or function F' occurs in a code block controlled by k adjacent loop statements with identical content in execution order, and each code block calls the external function F or function F' j times, then m = (k-1)*j; where k>1 and j is a positive integer;
[0037] When k adjacent code blocks of execution statements have the same content in the execution order, and each code block calls external function F or function F' j times, m = (k-1)*j; where k>1 and j is a positive integer.
[0038] Thirdly, the present invention provides a Linux module function identification system, comprising: a memory and a processor, wherein the memory stores a computer program, and the processor executes the Linux module function identification method provided in the second aspect of the present invention when executing the computer program.
[0039] Fourthly, the present invention also provides a computer-readable storage medium comprising a stored computer program, wherein, when the computer program is executed by a processor, it controls the device where the storage medium is located to execute the method for constructing a Linux module function identification model provided in the first aspect of the present invention and / or the method for identifying Linux module functions provided in the second aspect of the present invention.
[0040] In summary, the above-described technical solutions conceived in this invention can achieve the following beneficial effects:
[0041] 1. This invention provides a method for constructing a Linux module function identification model. By analyzing the call relationships between modules, modules that depend on other modules are identified, thus obtaining upper-level modules. For upper-level modules, the function information of the definition modules of multiple external functions with frequent calls is integrated to construct their function value matrix. By training the mapping relationship between the function value matrix and the function value vector of the upper-level modules, the correspondence between the function of the module to be identified and the functions of the other modules it depends on is learned, thereby constructing a Linux module function identification model. This allows for the reverse analysis of modules of unknown origin to obtain information about the modules they depend on, and then accurate and effective module function identification can be performed based on the mapping relationship between the functions of the dependent modules and their actual functions.
[0042] 2. Furthermore, the method for constructing a Linux module function identification model provided by this invention multiplies each non-all-zero function value vector in the function value matrix by the corresponding number of times the external function is called; weighting based on the number of calls effectively highlights the functional relationship between the module to be analyzed and the called module. A higher number of function calls indicates a stronger functional correlation, and weighting based on the number of calls further improves the accuracy of module function identification. In addition, compared to weighting based on the number of times the external function is run, the above method can also eliminate the influence of excessive weighting caused by loops and recursion.
[0043] 3. Furthermore, the method for constructing the Linux module function identification model provided by the present invention multiplies each non-all-zero function value vector in the function value matrix by the smaller of the number of times the corresponding external function is called and the preset weight limit. By setting the upper limit, the excessive weighting caused by calling the same function too many times in the same conditional branch during some program design is avoided, thereby further improving the accuracy of module function identification.
[0044] 4. Furthermore, the method for constructing the Linux module function recognition model provided by the present invention sorts the L key calling modules according to the preset sorting order of the number of calls to the corresponding external functions, and then merges the function value vectors of each module according to the module order, thereby making the construction rules of the function value matrix consistent and further improving the recognition accuracy of the model.
[0045] 5. Furthermore, the method for constructing the Linux module function identification model provided by this invention uses the number of calls as the number of valid calls. By calculating the number of valid calls, invalid duplications caused by calling the same function in the same way in the same conditional branch, calling the function when defining the function, calling the same function in the same way in the loop statements of adjacent execution order, and calling the same function in the same way in the code blocks of adjacent execution order are avoided in some program designs, thereby further improving the accuracy of module identification. Attached Figure Description
[0046] Figure 1 This is a flowchart of the method for constructing a Linux module function identification model provided in Embodiment 1 of the present invention;
[0047] Figure 2 This is a schematic diagram illustrating the classification of upper-layer and lower-layer modules provided in Embodiment 1 of the present invention. Detailed Implementation
[0048] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention. Furthermore, the technical features involved in the various embodiments of this invention described below can be combined with each other as long as they do not conflict with each other.
[0049] Example 1
[0050] A method for constructing a Linux module function identification model, such as... Figure 1 As shown, it includes:
[0051] S1. Reverse Analysis: Perform reverse analysis on each module in the pre-collected kernel module set to obtain the call relationships between modules, the external functions called within each module and their corresponding call counts (it should be noted that the call counts here are the direct call counts by default, which can be obtained directly by counting), and the definition module information of each external function; classify the modules in the set according to the call relationships between modules, and classify the modules that do not depend on other modules as the bottom-level modules, and the remaining modules (modules that depend on other modules) as the top-level modules;
[0052] In this embodiment, the modules in the kernel module set are collected from dynamically loadable kernel modules in the Linux system. All modules in the kernel module set are common modules in the Linux system. Specifically, the frequency of occurrence of dynamically loadable kernel modules in various devices (devices of various architectures, including embedded devices such as ARM, MIPS, x86, and PowerPC, as well as common PC devices) and various Linux kernel derivative systems (including Deepin, Ubuntu, etc.) is statistically analyzed. Dynamically loadable kernel modules whose frequency of occurrence accounts for a preset proportion (30% in this embodiment) of the total number of systems surveyed are placed in the kernel module set. It should be noted that extracting common kernel modules requires ensuring a sufficient quantity of collected modules. The judgment of whether a module is common should not affect the total number of modules collected, as the size of the total number of modules collected directly affects the accuracy of module function identification using this method. The devices and systems from which modules are extracted include systems with various architectures and devices of various categories and specifications, ensuring the universality of the extracted common kernel modules.
[0053] Furthermore, reverse engineering tools are used to reverse engineer the collected common modules to obtain information about the functions defined by the modules themselves and the external functions they call. Based on the information about the functions defined by each module and the external functions they call, they are compared to obtain information about the functions called by each module from other modules (external functions), as well as the defining module information of each external function, thus obtaining the calling relationship between modules. Based on the calling relationship between modules, the modules are classified as follows: modules that do not depend on other modules are classified as low-level modules, and modules that directly or indirectly call low-level modules are classified as high-level modules.
[0054] In one alternative implementation, a database can be established to input function definitions and call information, inter-module call relationship information, and upper-level and lower-level module classification information into the database, preparing for subsequent updates. The complete implementation is as follows:
[0055] The reverse engineering of the collected common modules to obtain information about the functions defined by the module itself and the external functions it calls includes: for any module m in the collected set of common modules M... i By using reverse engineering tools, we can obtain its own defined set of functions F. Di and the set of external functions F that it calls Ei Take the union of the function sets defined in all modules to obtain the complete set of functions defined in the module file, i.e., F. D =F D1 ∪F D2 …F Dn At the same time, the mapping relationship f1:F is obtained. D→M, where f is defined in module f1(f) = {m | f is defined in m}; for cases where different modules define functions with the same name, the specific call relationships and dependent modules of the relevant modules can be viewed by checking the modules.dep file and using the modinfo command; build a database to store the information of external functions called by each module and the functions defined by itself.
[0056] Furthermore, the methods for obtaining function information from other modules, i.e., external functions, called by each module include: for any module m i The set of external functions F that it calls Ei With the complete set of functions F defined in the module file D Taking the intersection, we get module m. i The set of functions defined in other modules that are called, namely F ei =F Ei ∩F D For module m i The set of external functions F that it calls Ei In addition to the set of functions F defined in other modules that it calls, ei Functions within the module are defined within the module itself; all other functions are defined outside the module and may originate from various basic libraries. These functions are marked in the constructed database and then filtered out during subsequent analysis. For any module m... i It iterates through the set F of functions defined in other modules that it calls. ei The set of source modules M for the functions defined in other modules that are called can be obtained through the mapping relationship f1. ei M ei ={m|m=f1(f), where f∈F ei The database stores the functions called by each module from external modules, along with the module information in which these functions are defined, forming a dependency information database for each module.
[0057] Furthermore, such as Figure 2 As shown, the process of classifying modules in the set according to their inter-module calling relationships includes: for any module m in the module set M... i Determine the source module set M of the function called that is defined in other modules. ei If M ei If it is not an empty set, then determine m. i If it is the upper-level module, otherwise check m. iModules not called by other modules are classified as upper-level modules, while those called by other modules are classified as lower-level modules. This classification of common modules into upper-level and lower-level modules is for ease of analysis in subsequent steps and is not entirely equivalent to the actual upper-level and lower-level relationship. A database of information related to common Linux kernel modules is established, inputting the function definitions, function calls, and classification information of kernel modules into the database. The database is kept dynamically updatable to facilitate the addition of new modules later. As needed, when the module data in the database is updated, if a newly added module m1 has functions defined within it that are called by other modules m2…m… n Call, and m2…m n Previously defined as a low-level module, now m2…m n The classification also needs to be adjusted accordingly to the upper-level module.
[0058] S2. Calculation of the function value matrix: For each upper-level module in the kernel module set, obtain the L external functions with the most calls, and treat the definition module of each external function as a key calling module, resulting in L key calling modules. The L key calling modules correspond one-to-one with the L external functions, and each key calling module is the definition function of the corresponding external function (i.e., each external function is defined in its corresponding key calling module); merge the function value vectors of the L key calling modules to construct the corresponding function value matrix.
[0059] Where L is the smaller of the total number of external functions S in the upper-level module and the preset threshold T; T≥1; the i-th value in the module's function value vector indicates whether the module has the i-th type of function; i=1,2,…,N; N is the number of function types of the Linux module. In this embodiment, when the i-th value indicates that the module has the i-th type of function, the i-th value in the module's function value vector is 1; when the i-th value indicates that the module does not have the i-th type of function, the i-th value in the module's function value vector is 0.
[0060] It should be noted that the same definition module may appear among the L key calling modules because multiple external functions may be defined by the same module. This invention introduces the concept of key calling modules, corresponding one-to-one with L external functions, and ensuring that each external function is defined in its corresponding key calling module. Specifically, the L key calling modules can be labeled from 1 to L, with each key calling module under a different label corresponding to one of the L external functions, and ensuring that each external function is defined in its corresponding key calling module. In this case, even if key calling module 1 and key calling module 2 are the same definition module, their corresponding external functions are not the same.
[0061] Specifically, in one optional implementation, the functions of the kernel modules are divided into N=20 categories in sequence, including: sensor functions, virtualization functions, network device functions, network protocol stack functions, security functions, memory management functions, process management functions, block device functions, disk functions, data acquisition functions, character device functions, graphics card functions, sound card functions, Bluetooth functions, audio device functions, audio processing functions, video processing functions, video device functions, spurious functions, and spurious device functions. For any module m in the collected common module set M... i By querying local and online information and conducting manual analysis, its approximate function can be obtained, resulting in one or more of the aforementioned 20 functional terms, and thus a functional value sequence v. i =[r1,r2...r 20 ], where r n The value is 0 or 1, representing whether the nth function out of the above 20 functions is included by module m. i Included, 0 represents no, 1 represents yes; store the function value sequence of each module into the database and summarize to obtain the module function value sequence dataset.
[0062] Furthermore, in one optional implementation, after sorting the L key calling modules according to a preset sorting order of the number of times the corresponding external functions are called, the function value vectors of each module are merged according to the module order to construct the corresponding function value matrix. The preset sorting order can be from largest to smallest, smallest to largest, pre-assigned sequence numbers, etc., and is not limited here. The purpose is to ensure that the construction rules of the function value matrix remain consistent, further improving the accuracy of the model's recognition.
[0063] It should be noted that when L = S, after merging the function value vectors of the L key calling modules, one or more function value vectors with all zeros are further merged so that the number of function value vectors in the function value matrix is T.
[0064] Furthermore, in one optional implementation, each non-all-zero function value vector in the function value matrix is multiplied by the number of times the corresponding external function is called. Weighting based on the number of calls effectively highlights the functional relationship between the module being analyzed and the called module; a higher number of function calls indicates a stronger functional correlation. Weighting based on the number of calls further improves the accuracy of module function identification. Compared to weighting based on the number of times the external function is run, this method eliminates the excessive superposition of weights caused by loops and recursion.
[0065] Furthermore, considering that multiple conditional branches correspond to only one call, but the call count is counted multiple times, in another optional implementation, each non-all-zero function value vector in the function value matrix is multiplied by the smaller of the corresponding external function call count and a preset weight limit. By setting an upper limit, the excessive weighting caused by calling the same function too many times in the same conditional branch during some program design is avoided, further improving the accuracy of module function identification.
[0066] It should be noted that the function value vector can be either a row or a column of the function value matrix. Taking a preset sorting order from largest to smallest and a function value vector that can be a row of the function value matrix as an example, the process of obtaining the function value matrix is as follows:
[0067] For any upper-level module m in the collected set of common modules M Uj Based on the inter-module call relationships and the number of function calls, m Uj Functions defined in other modules that are called are sorted by the number of times they are called; a threshold T is set, and m is extracted. Uj The T most frequently called functions defined in other modules are called module m. Uj The key calling modules; extract the function value sequence v1, v2...v from these modules. T Using the function value sequence as rows, arrange them from top to bottom according to the number of calls. If the number of key call functions is less than T, fill the empty rows with 0s, resulting in a T-row, N-column (N=20) matrix, which is the key call module function value matrix. Set an upper limit E value for the weights. For any row in the matrix, if the number of times its corresponding function is called does not exceed the upper limit E value, multiply the value of this row by the number of times it is called; if it exceeds, multiply the value of this row by the upper limit E value. This method completes the weighting, ultimately obtaining m. Uj The corresponding key calling module function value weighted matrix a j After analyzing all the collected module information, a weighted matrix set A of key calling module function values was obtained. u The corresponding data is then stored in the database.
[0068] S3. Model Training: Using the function value matrix of each upper-level module as input and the corresponding function value vector of the upper-level module as output, train the machine learning model to obtain the Linux module function recognition model.
[0069] It should be noted that the machine learning model can be SVM, neural network model, deep neural network module (such as CNN, VGG, YOLO), etc., and there are no restrictions here.
[0070] In one optional implementation, based on the extracted inter-module call relationships and function value sequences of the upper-level modules, the Binary Relevance multi-label classification method is used to transform the classification problem of 20 function values into 20 independent binary classification problems, namely, the relationship between the existence or non-existence of each function of a module and the weighted matrix of the function values of the key calling modules of the module; the function value sequences of all upper-level modules and the weighted matrices of the function values of the key calling modules of the upper-level modules are extracted from the database and input in pairs into the fully connected layer to learn a mapping function f:A U →V U After training the function f, test it using a test set. If the accuracy of the test results is insufficient, increase the number of training rounds. After the mapping function f is trained, save it to the database. The purpose of function f is to make the known upper-level module m... Uj The key calling module function value weighted matrix a j Under the condition that m is obtained through the mapping function Uj A matching sequence of function values.
[0071] Furthermore, in one implementation, the kernel module set is re-collected every preset time period (one month in this implementation), and the Linux module function recognition model is incrementally trained according to the method in steps S1-S3 to ensure continuous updates to the Linux module function recognition model, thereby further improving the accuracy of model recognition.
[0072] To further illustrate the method for constructing the Linux module function identification model provided by this invention, a complete implementation method is described in detail below:
[0073] The entire model building process includes:
[0074] Step 1: Collection of common modules
[0075] Common dynamically loadable Linux kernel modules were collected from various devices and systems, and their .ko files were extracted as examples for subsequent analysis. In this embodiment, the modules extracted in this process came from Ubuntu, Kali, and CentOS, totaling more than 3,000.
[0076] Step 2: Reverse engineering common modules
[0077] For any module m in the common module set M collected... i Using the reverse engineering tool IDAPro, its own set of functions F was obtained. Di and the set of external functions F called in the extern section. EiTaking the union of the function sets defined in all modules within set M yields the complete set of functions defined in the module files, i.e., F. D =F D1 ∪F D2 …F Dn At the same time, the mapping relationship f1:F is obtained. D →M, where f1(f)={m|f is defined in m}.
[0078] For module m i The set of external functions F that it calls Ei With the complete set of functions F defined in the module file D Taking the intersection, we get module m. i The set of functions defined in other modules that are called, namely F ei =F Ei ∩F D Next, we iterate through module m. i The set of functions F defined in other modules that are called ei The set of source modules M for the functions defined in other modules that are called can be obtained through the mapping relationship f1. ei M ei ={m|m=f1(f), where f∈F ei}
[0079] For module m i Determine the source module set M of the function called that is defined in other modules. ei If M ei If it is not an empty set, then determine m. i If it is the upper-level module, otherwise determine m. i Modules that are not called by other modules are considered upper-level modules, while modules that are called by other modules are considered lower-level modules.
[0080] The analyzed information is stored in a database for subsequent analysis and comparison.
[0081] Step 3: Marking Module Functionality
[0082] In this invention, the functions of kernel modules are categorized into 20 types in sequence: 1: Sensor function, 2: Virtualization function, 3: Network device function, 4: Network protocol stack function, 5: Security function, 6: Memory management function, 7: Process management function, 8: Block device function, 9: Disk function, 10: Data acquisition function, 11: Character device function, 12: Graphics card function, 13: Sound card function, 14: Bluetooth function, 15: Audio device function, 16: Audio processing function, 17: Video processing function, 18: Video device function, 19: Spurious function, 20: Spurious device function. For any module m in the collected common module set M...i By querying local and online information and manually analyzing it, its general function is obtained, and a function value sequence v is obtained according to 20 function categories. i =[r1,r2...r 20 ], where r n The value is 0 or 1, representing whether the nth function out of the above 20 functions is included by module m. i Included, 0 represents no, 1 represents yes.
[0083] As in the example, when the module xt_LOG.ko has functions including virtualization and network device functions, the corresponding function value sequence is [0,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0].
[0084] The function values of each module are entered into the database for storage.
[0085] Step 4: Extract the weighted matrix of key calling module function values
[0086] For any upper-level module m in the collected set of common modules M Uj Based on the inter-module call relationships and the number of function calls, m Uj Functions defined in other modules that are called are sorted according to the number of times they are called. In this example, a threshold T = 10 is set, and m is extracted. Uj The 10 most frequently called functions defined in other modules are called m. Uj The key calling modules are extracted, and the function value sequences v1, v2...v are obtained. T The function values are arranged in rows, ordered from top to bottom by the number of times they are called. A weight cap of E = 5 is set. For any row in the matrix, if the function corresponding to it is called no more than 5 times, the value of that row is multiplied by the number of times it is called; if it is called more than 5 times, the value of that row is multiplied by 5. This process is repeated to complete the weighting. If m... Uj If there are fewer than 10 critical calling modules, the remaining rows are padded with 0s. This method ultimately yields a T-row, 20-column matrix, i.e., m... Uj The corresponding key calling module function value weighted matrix a j After analyzing all the collected module information, a weighted matrix set A of the key calling module function values was obtained. u .
[0087] For example, in this embodiment, the number of times the cifs.ko module calls functions defined in other modules is as follows:
[0088] The function dns_query, derived from the module dns_resolver.ko, executes once.
[0089] The function __fscache_read_or_alloc_pages, derived from the module fscache.ko, reads once.
[0090] The function __fscache_write_page, derived from the module fscache.ko, executes once.
[0091] The function __fscache_read_or_alloc_page, derived from the module fscache.ko, reads once.
[0092] Functions from module fscache.ko: __fscache_maybe_release_page: 1 time; Functions from module fscache.ko: __fscache_wait_on_page_write: 1 time.
[0093] The function __fscache_acquire_cookie, derived from the module fscache.ko, is used 3 times.
[0094] The function __fscache_relinquish_cookie, derived from the module fscache.ko, is used once.
[0095] If the number of functions defined in other modules called is less than 10, all functions defined in other modules called are determined to be critical call functions. The critical call modules are dns_resolver.ko and fscache.ko. The function value sequence of module dns_resolver.ko is [0,0,1,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0], and the function value sequence of module fscache.ko is [0,0,0,0,0,0,0,0,0,1,0,1,0,0,0,0,0,0,0,0]. By weighting and padding the last two rows with 0s using the above information, the weighted matrix of function values of the critical call modules of cifs.ko is obtained.
[0096] The key function values of each module are weighted and entered into the corresponding database column for storage.
[0097]
[0098] Step 5: Training the module functional analysis model
[0099] Based on the extracted inter-module call relationships and function value sequences of the upper-level modules, the BinaryRelevance multi-label classification method is used to transform the classification problem of 20 function values into 20 independent binary classification problems, namely, the relationship between the existence or non-existence of each function of a module and the weighted matrix of the function values of the key calling modules of the module. The function value sequences of all upper-level modules and the weighted matrices of the function values of the key calling modules of the upper-level modules are extracted from the database and input in pairs into a fully connected layer to learn a mapping function f:A. U →V U After training the function f (i.e., the Linux module function recognition model), it is tested using a test set. If the accuracy of the test results is insufficient, the number of training rounds is increased. After the mapping function f is trained, it is saved to the database. The purpose of function f is to enable the recognition of known upper-level modules m. Uj The key calling module function value weighted matrix a j Under the condition that m is obtained through the mapping function Uj A matching sequence of function values.
[0100] In summary, this invention provides a Linux module function identification model that can be used for detecting unknown module functions. It offers an effective way to identify kernel module functions in cases of unknown origin, provides users with reference information on kernel module functions, and has good practicality.
[0101] Example 2
[0102] A method for constructing a Linux module function identification model;
[0103] It should be noted that the specific operation of the Linux module function identification model construction method provided in this embodiment is basically the same as that of the Linux module function identification model construction method provided in Embodiment 1. The difference is that the number of calls mentioned in this embodiment is the number of valid calls, and no invalid duplication occurs. In addition, the scheme for weighting the function value matrix according to the number of calls to effectively highlight the functional relationship between the module to be analyzed and the called module only includes: multiplying each non-all-zero function value vector in the function value matrix by the number of calls of the corresponding external function. Since the number of valid calls is used here, it avoids the influence of excessive weighting caused by calling the same function too many times in the same conditional branch in some program design. Specifically, by calculating the number of valid calls, it avoids invalid duplication caused by calling the same function in the same way in the same conditional branch, calling the function when defining the function, calling the same function in the same way in the loop statements of adjacent execution order, and calling the same function in the same way in adjacent code blocks of execution order in some program design, so as not to affect the weighting, and further improve the accuracy of module identification.
[0104] Specifically, the effective number of calls to any external function F is n = n1 + n2 - n3;
[0105] Where n1 is the number of times the external function F is called; n2 is the sum of the number of times each function that calls the external function F is called; and n3 is the sum of the number of invalid repetitions of the external function F and each function that calls the external function F.
[0106] The method for obtaining the invalid repetition count m of the external function F and any function F' that calls the external function F is as follows:
[0107] When a conditional statement controls k identical code blocks that call an external function F or F', and each code block calls the external function F or F' j times, then m = (k-1)*j; where k>1 and j is a positive integer.
[0108] When there are k calls to the external function F or function F' within the code block used to define the function, then m = k; where k ≥ 1;
[0109] When a call to an external function F or function F' occurs in a code block controlled by k adjacent loop statements with identical content in execution order, and each code block calls the external function F or function F' j times, then m = (k-1)*j; where k>1 and j is a positive integer;
[0110] When k adjacent code blocks of execution statements have the same content in the execution order, and each code block calls external function F or function F' j times, m = (k-1)*j; where k>1 and j is a positive integer.
[0111] Example 3
[0112] A method for identifying the function of a Linux module, comprising:
[0113] The Linux module to be identified and the modules it calls are reverse-engineered to obtain the external functions called within the Linux module and the number of times they are called.
[0114] The Linux module is processed according to the function value matrix calculation method described in step S2 of the Linux module function identification model construction method provided in Embodiment 1 of the present invention to obtain the corresponding function value matrix;
[0115] The function value matrix is input into the Linux module function identification model constructed using the construction method of the Linux module function identification model provided in Embodiment 1 of the present invention to obtain the function identification result of the Linux module.
[0116] Specifically, based on the Linux module function identification model obtained from the complete implementation method mentioned in the examples, for the Linux module m whose function is to be analyzed... i First, compare the module information with the known functionalities in the database. If the module's functional information already exists in the database, retrieve the relevant information and provide it to the user; otherwise, proceed to the next analysis step: for m i Perform reverse engineering to obtain the set of external functions F that it calls. Ei Information, along with the complete set of functions F defined in the module files stored in the database. D By comparing and taking the intersection, we obtain the set F of functions called by the function that are defined in other modules. ei Information; for m i Perform a judgment; if the function it calls is defined in a set F of functions in other modules... ei If m is an empty set, it means that it does not depend on any module or that the information about its dependent modules does not exist in the existing database, and analysis cannot be completed. Analysis must wait for the relevant data to be updated before proceeding. i The set F of functions defined in other modules that are called. ei If it is not an empty set, then the function value matrix of its key calling module is generated according to the function value matrix calculation method in step S2 of embodiment 1, and input into the Linux module function identification model. The item with the highest probability is selected from the obtained results as the function value sequence to identify its function.
[0117] The relevant technical solutions are the same as in Embodiment 1, and will not be repeated here.
[0118] Furthermore, in one optional implementation, the above-mentioned number of calls is the number of valid calls;
[0119] At this point, step A2 includes: processing the Linux module according to the function value matrix calculation method in step S2 of the Linux module function identification model construction method provided in embodiment 2 of the present invention to obtain the corresponding function value matrix;
[0120] Step A3 includes: inputting the function value matrix into the Linux module function identification model constructed using the Linux module function identification model construction method provided in Embodiment 2 of the present invention, to obtain the function identification result of the Linux module;
[0121] The relevant technical solutions are the same as in Embodiment 2, and will not be repeated here.
[0122] Example 4
[0123] A Linux module function identification system includes: a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the Linux module function identification method provided in Embodiment 3 of the present invention.
[0124] The relevant technical solutions are the same as in Embodiment 3, and will not be repeated here.
[0125] Example 5
[0126] A computer-readable storage medium includes a stored computer program, wherein when the computer program is run by a processor, it controls the device where the storage medium is located to execute the method for constructing a Linux module function identification model provided in Embodiment 1 or Embodiment 2 of the present invention and / or the method for identifying Linux module functions provided in Embodiment 3 of the present invention.
[0127] The relevant technical solutions are the same as those in Embodiments 1, 2 and 3, and will not be repeated here.
[0128] Those skilled in the art will readily understand that the above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.
Claims
1. A method for constructing a Linux module function identification model, characterized in that, include: S1. Reverse Analysis: Perform reverse analysis on each module in the pre-collected kernel module set to obtain the call relationships between modules, as well as the external functions called within each module, the number of calls, and the definition modules of each external function; based on the call relationships between modules, obtain the modules in the set that depend on other modules, and denot them as upper-level modules; S2. Calculation of the function value matrix: For each upper-level module in the kernel module set, obtain the L external functions that are called most frequently, and take the definition module of each external function as a key calling module to obtain L key calling modules. Merge the function value vectors of the L key calling modules to construct the corresponding function value matrix. S3. Model Training: Using the function value matrix of each upper-level module as input and the corresponding function value vector of the upper-level module as output, train the machine learning model to obtain the Linux module function recognition model. Where L is the smaller of the total number of external functions S in the upper-level module and the preset threshold T; T≥1; the i-th value in the module's function value vector indicates whether the module has the i-th type of function; i=1,2,…,N; N is the number of function types of the Linux module.
2. The method for constructing a Linux module function identification model according to claim 1, characterized in that, When the i-th value indicates that the module has the i-th type of function, the i-th value in the module's function value vector is 1; when the i-th value indicates that the module does not have the i-th type of function, the i-th value in the module's function value vector is 0. When L = S, the function value vectors of the L key calling modules are merged, and then one or more function value vectors with all zeros are further merged so that the number of function value vectors in the function value matrix is T.
3. The method for constructing a Linux module function identification model according to claim 1, characterized in that, After sorting the L key calling modules according to the preset sorting order of the number of times the corresponding external functions are called, the function value vectors of each module are merged according to the module order to construct the corresponding function value matrix.
4. The method for constructing a Linux module function identification model according to claim 1, characterized in that, Multiply each non-all-zero function value vector in the function value matrix by the number of times the corresponding external function is called.
5. The method for constructing the Linux module function identification model according to claim 1, characterized in that, Multiply each non-all-zero function value vector in the function value matrix by the smaller of the number of times the corresponding external function is called and the preset weight limit.
6. The method for constructing a Linux module function identification model according to any one of claims 1-4, characterized in that, The number of calls mentioned refers to the number of valid calls. The effective number of calls to any external function F is n = n1 + n2 - n3; Where n1 is the number of times the external function F is called; n2 is the sum of the number of times each function that calls the external function F is called; and n3 is the sum of the number of invalid repetitions of the external function F and each function that calls the external function F. The method for obtaining the invalid repetition count m of the external function F and any function F' that calls the external function F is as follows: When a conditional statement controls k identical code blocks that call an external function F or F', and each code block calls the external function F or F' j times, then m = (k-1)*j; where k>1 and j is a positive integer. When there are k calls to the external function F or function F' within the code block used to define the function, then m = k; where k ≥ 1; When a call to an external function F or function F' occurs in a code block controlled by k adjacent loop statements with identical content in execution order, and each code block calls the external function F or function F' j times, then m = (k-1)*j; where k>1 and j is a positive integer; When k adjacent code blocks of execution statements have the same content in the execution order, and each code block calls external function F or function F' j times, m = (k-1)*j; where k>1 and j is a positive integer.
7. A method for identifying the function of a Linux module, characterized in that, include: A1. Perform reverse analysis on the Linux module to be identified and the modules it calls to obtain the external functions called within the Linux module and the number of times they are called; A2. Process the Linux module according to the function value matrix calculation method described in step S2 of the method for constructing the Linux module function identification model according to any one of claims 1-6 to obtain the corresponding function value matrix; A3. Input the function value matrix into the Linux module function identification model constructed using the construction method of the Linux module function identification model according to any one of claims 1-6 to obtain the function identification result of the Linux module.
8. The Linux module function identification method according to claim 7, characterized in that, The number of calls mentioned refers to the number of valid calls. At this time, step A2 includes: processing the Linux module according to the function value matrix calculation method described in step S2 of the method for constructing the Linux module function identification model according to claim 6, to obtain the corresponding function value matrix; Step A3 includes: inputting the function value matrix into the Linux module function identification model constructed using the construction method of the Linux module function identification model according to claim 6, to obtain the function identification result of the Linux module; Wherein, the effective number of calls to any external function F is n = n1 + n2 - n3; n1 is the number of times the external function F is called; n2 is the sum of the number of times each function that calls the external function F is called; n3 is the sum of the number of invalid repetitions of the external function F and each function that calls the external function F; The method for obtaining the invalid repetition count m of the external function F and any function F' that calls the external function F is as follows: When a conditional statement controls k identical code blocks that call an external function F or F', and each code block calls the external function F or F' j times, then m = (k-1)*j; where k>1 and j is a positive integer. When there are k calls to the external function F or function F' within the code block used to define the function, then m = k; where k ≥ 1; When a call to an external function F or function F' occurs in a code block controlled by k adjacent loop statements with identical content in execution order, and each code block calls the external function F or function F' j times, then m = (k-1)*j; where k>1 and j is a positive integer; When k adjacent code blocks of execution statements have the same content in the execution order, and each code block calls external function F or function F' j times, m = (k-1)*j; where k>1 and j is a positive integer.
9. A Linux module function identification system, characterized in that, include: A memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the Linux module function identification method according to claim 7 or 8.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored computer program, wherein, when the computer program is executed by a processor, it controls the device where the storage medium is located to execute the method for constructing a Linux module function identification model according to any one of claims 1-6 and / or the method for identifying Linux module functions according to any one of claims 7-8.