Methods for analyzing target software for potentially harmful behavior
The method decomposes software into functional blocks, labels them using machine learning, and analyzes behavior to detect and prevent malware in open-source software, ensuring the integrity of technical systems.
Patent Information
- Authority / Receiving Office
- DE · DE
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2024-09-11
- Publication Date
- 2026-03-12
AI Technical Summary
The widespread use of open-source software in modern software solutions introduces a high risk of malware due to unmanaged review processes and lack of active detection mechanisms in repositories, making it difficult to identify potentially harmful behavior across distributed functional steps.
A method involving software decomposition into functional blocks, labeling with software and malware data, and behavioral analysis using machine learning models to detect and report potential malware or harmful behavior in target software.
Enables automated and comprehensive analysis of software for malware, identifying complex attack vectors and ensuring the integrity of technical systems by preventing the integration of malicious software.
Smart Images
Figure 00000000_0000_ABST
Abstract
Description
[0001] The present invention relates to a method for analyzing target software, in particular operating software for a technical system, e.g. a control unit, with regard to potentially harmful behavior, as well as a computing unit and a computer program for carrying out this analysis. Background of the invention
[0002] So-called open-source software can be used in many different areas. Due to the almost unmanageable number of different open-source software programs and the sometimes lacking review processes, the presence of malware in open-source software often cannot be ruled out. Disclosure of the invention
[0003] According to the invention, a method, in particular a computer-implemented method, for analyzing target software, as well as a computing unit and a computer program for carrying it out, are proposed, comprising the features of the independent claims. Advantageous embodiments are the subject of the dependent claims and the following description.
[0004] The invention relates to the detection of (potential) malware contained in other software, or more generally, the analysis of target software (i.e., a specific piece of software or software sample to be examined) with regard to potential malware or other potentially harmful behavior. Such software could include, for example, so-called open-source software, but also internal software or other third-party software. In particular, it concerns the detection of potential malware in operating software for a technical system, such as a control unit.
[0005] Open-source software, or open-source software packages, have become a fundamental cornerstone of modern software development. It is estimated that free and open-source software comprises 70 to 90% of any modern software solution. The availability of such software packages therefore shapes almost every aspect of modern software-based solutions, products, and services.
[0006] Numerous packages can be downloaded from one of many software package registries, including npm (JavaScript), PyPI (Python), Ruby Gems (Ruby), and others. Distributed across these registries, developers release tens of thousands of updates and upload hundreds of new packages daily, resulting in a collection of several million openly available software packages.
[0007] Unfortunately, this overwhelming availability of free software comes at a price – namely, potentially dangerous software, also generally referred to as malware. This specifically means that a software package has been modified to actively carry out an attack. This contrasts with traditional software vulnerabilities, which are not intentionally designed to cause harm.
[0008] The increased risk can arise from several factors: (1) Anyone can upload such software packages, (2) only a limited number of packages are digitally signed or verified, and (3) the repositories or databases typically lack an active detection mechanism to identify and potentially filter out such malware. In this environment, it is easy to introduce manipulated software packages (i.e., malware) to launch attacks on the supply chain, i.e., where the software is ultimately deployed. As has been demonstrated, this problem extends far beyond the JavaScript and Python ecosystems. While open-source software is a particular motivation here, the procedure described below can also be applied to other types of software, i.e., software from any source.
[0009] A fundamental challenge in malware detection lies in identifying and interpreting potential indicators of code compromise based on the software's general behavioral characteristics. A specific behavior, such as "remote file transfer," might suggest that a mathematical library is conducting a data theft attack. However, it could also be harmless behavior if the mathematical library supports distributed computing. Therefore, identifying malware or malicious (or harmful) behavior in software can require a more comprehensive analysis of multiple functional characteristics, especially since an attack can involve several functional steps spatially distributed across different modules, files, and functions.
[0010] Against this background, a method is proposed to analyze target software, such as operating software for a technical system, for potentially harmful behavior or malware. This means, for example, checking whether malware is present in the target software, whether the target software exhibits harmful or malicious behavior, and, if applicable, identifying the specific type of malware. This can be done automatically.
[0011] The following section briefly explains various terms used in this application.
[0012] Functional block: A functional block is the smallest meaningful functional part of a software package or software application, which is represented, or can be represented, in a fragmented or decomposed manner. A functional block could, for example, be a function or a series of functions that implement a specific behavior. In particular, it is suggested that functional blocks be represented in the form of textual (and therefore human-readable) descriptions. An example of a functional block could be a function that performs the following action: "Establish a connection to the remote server using a protocol such as FTP or SFTP."
[0013] Functional area: A functional area is a functional region within a group of functional blocks that are related to each other and implement a specific, more complex behavior. For example, a functional area could be a group of functional blocks that carry out an attack, such as transmitting confidential information to a remote server. The functional area representing this attack could therefore consist of the following functional blocks: 1) Turn off logging. 2) Open the desired local file in read-only mode. 3) Read the contents of the file. 4) Establish a connection to the remote server using a protocol such as FTP or SFTP. 5) Open a file on the remote server in write mode. 6) Write the content read from the local file to the remote file. 7) Close the remote file. 8) Close the local file. 9) Continue logging.
[0014] Decomposition: In decomposition (also called decomposition), the entire software (e.g., a software package) is represented in the form of related functional blocks.
[0015] The proposed approach involves providing target software data that includes a decomposition. This decomposition comprises functional blocks obtained or obtained by decomposing the target software. It is conceivable that some functional blocks form functional areas. Thus, the target software to be analyzed is first decomposed accordingly.
[0016] In addition, software label data and malware label data are provided. These may have been obtained independently of each other; the order is irrelevant.
[0017] The software label data comprises labels for functional blocks of software data, where the software data includes a multitude of decompositions. The decompositions, in turn, each comprise one or more of the functional blocks that are or have been obtained by decomposing a software sample. The software samples could, for example, be good software.
[0018] The malware label data includes labels for functional blocks of malware data, wherein the malware data comprises a variety of decompositions, each decomposition comprising one or more of the functional blocks obtained or obtained by decomposing an attack vector.
[0019] First, software data and malware data can be collected and then labeled accordingly. The software packages within the software data can be obtained from various sources, such as online registries, repositories, local source code, synthetic generation, and other sources. Similarly, the attack vectors within the malware data can originate from various sources, such as online repositories, threat intelligence feeds, synthetic generation, forums, papers, vulnerability databases, and other sources.
[0020] An attack vector is, in particular, a possible attack path or a (potentially distributed / multi-stage) procedure by which an unauthorized intruder, of any kind, can penetrate or compromise a foreign computer system in order to then either take it over or at least misuse it for their own purposes. Attacks sometimes go beyond these purposes, such as leaking files to the internet or causing a system to become unresponsive (DoS). Ultimately, an attack vector consists of coherent functional blocks, similar to a software probe. For this purpose, a set of known attack vectors from various sources is collected and decomposed into functional blocks, resulting in a multitude of decompositions (or a set of attack decompositions).
[0021] The software samples included in the software data specifically comprise good software samples. A good software sample is defined as a software sample that is known, or at least can be assumed, to be neither malicious nor containing malware.
[0022] Labels can be generated for the functional blocks of software data and malware data. These labels are identifiers or descriptions of the relevant functional blocks (or, if applicable, functional areas). Labeling is achieved, for example, by iterating through the functional blocks (and, if applicable, functional areas, as several functional blocks combined) in the decompositions and assigning identifiers or labels based on a comparison with existing patterns. Comparison resources for malware identification or labeling can generally be obtained from online vulnerability databases, threat analysis reports, threat data feeds, collected honeypot data, forums, and other sources. Similarly, labels can be found by searching online repositories, local projects, code samples in forums, papers, documentation, and other sources. In both cases, for example...A summary of all resources should be available via an LLM model or another machine learning model.
[0023] The software label data thus includes, for example, a collection of decomposed software packages with additional functional labels that describe the functionality of the blocks or areas in the decomposition. The size and distribution of the functional blocks within an area assigned to a specific label (or multiple labels) is not inherently limited.
[0024] The malware label data thus includes, for example, a collection of decomposed attack vectors with additional threat labels that describe the potential threat implemented in the areas of the composition. There is no inherent limit to the size and distribution of functional blocks within an area assigned to a particular label (or multiple labels).
[0025] It should be noted that there are essentially no limits to the definition of the labeling. For example, areas can be labeled based on the so-called STRIDE model.
[0026] Based on the software label data and the malware label data, the target software data is then analyzed to obtain analysis result data. In one embodiment, this can include generating labels for the functional blocks of the target software data, based on the software label data and the malware label data, thereby obtaining target software label data that includes labels for the functional blocks of the target software data. The analysis result data then includes the target software label data.
[0027] In one embodiment, this can also include analyzing a composition of the target software based on the labels for the functional blocks of the target software data, thereby obtaining a behavioral report. The analysis result data then includes the behavioral report.
[0028] The labeled decompositions can therefore be used to perform a behavioral analysis of the target software's decomposition, resulting in a behaviorally labeled decomposition—referred to here generally as analysis result data. The term "behaviorally labeled" specifically implies that both aspects—functionality and threats—have been included in the labeling process.
[0029] When generating the labels for the functional blocks of the target software data (i.e., the target software label data), the functional blocks and areas in the target software decomposition are compared with the functional blocks and areas of the software label data and malware label data. In this way, information about the functions implemented in the target software and potential threats, i.e., potentially contained malware, is incorporated into the decomposition.
[0030] After labeling, the target software label data can be further refined through a composite analysis of the already assigned labels or identifiers. This step allows, in particular, the identification of complex attacks that are implemented across multiple functional blocks and areas.
[0031] The results of this step are a behaviorally labeled decomposition of the target software and, for example, a behavioral security report. The latter provides, for example, a summary of the analysis, including a collection of behavioral characteristics, identified threats, and potential attacks associated with those threats.
[0032] The analysis results obtained in this way are then provided. The target software can then be additionally checked for the presence of malware or potentially harmful behavior, based on these results. Information about the presence of harmful behavior is then provided, at least if harmful behavior is detected in the target software. It should be noted here that harmful behavior is present, in particular, when malware is present. However, it is also conceivable that the target software unintentionally contains pathways that enable harmful behavior, i.e., pathways that could be exploited by an attacker.
[0033] If the analysis reveals a potential threat and the target software is already integrated (e.g., in a development environment, product, proof of concept, etc.), a threat alert can be generated. This threat alert can then be used to inform the user about the potential threat, including the analysis results.
[0034] In one embodiment, the proposed method is used to analyze operating software for a technical system, e.g., a control unit, for potential malware. More generally, however, a vehicle, a component or control unit of a vehicle, or a robot or a robot's control unit could also be considered as a technical system. Furthermore, a sensor, in particular an embedded sensor or another embedded system, could also be considered.
[0035] Operating software for a technical system refers specifically to a computer program that, when executed on a processing unit—such as a control unit—causes it to perform an operating or control procedure. This operating or control procedure, when executed, may include, for example, receiving signal or measured values and outputting control signals. If the control unit is, for example, an engine control unit, the control signals may activate fuel injectors or an electric motor.
[0036] Target software, particularly operating software, is only used for the operation of the technical system—for example, loaded onto the control unit—if no malicious behavior is detected using the proposed procedure. This ensures the continued operation of the technical system, such as the control unit and the components it controls (e.g., an engine or vehicle), as the presence of malware can be ruled out with a high degree of probability. It is also conceivable that target software already in use for the operation of the technical system is analyzed; if malicious behavior is detected, operation can then be stopped, or another measure can be initiated.
[0037] A computing unit according to the invention, e.g. a computer or server (e.g. also in the so-called cloud), is, in particular in terms of programming, configured to carry out a method according to the invention.
[0038] Implementing a method according to the invention in the form of a computer program or computer program product with program code for carrying out all method steps is also advantageous, as this incurs particularly low costs, especially if an executing control unit is already available for other tasks. Finally, a machine-readable storage medium is provided with a computer program stored on it as described above. Suitable storage media or data carriers for providing the computer program are, in particular, magnetic, optical, and electrical storage media, such as hard drives, flash memory, EEPROMs, DVDs, etc. Downloading a program via computer networks (Internet, intranet, etc.) is also possible. Such a download can be wired or wireless (e.g., via a WLAN network, a 3G, 4G, 5G, or 6G connection, etc.).
[0039] Further advantages and embodiments of the invention will become apparent from the description and the accompanying drawing.
[0040] The invention is schematically illustrated in the drawing using exemplary embodiments and is described below with reference to the drawing. Brief description of the drawings Fig. Figure 1 schematically shows an arrangement in which the invention can be used. Fig. 2 and Fig. Figure 3 schematically shows the sequence of a procedure in one embodiment. embodiment(s) of the invention
[0041] In Fig. Figure 1 schematically shows an arrangement in which the invention can be used. The arrangement includes, by way of example, a computing unit 100, e.g., a computer or a server, and a technical system 104, which may, for example, be a control unit of a vehicle.
[0042] Furthermore, a target software or software probe 102 is shown. This is, in particular, a computer program that causes a computing unit—in this case, the control unit 102—to perform an operating or control procedure when executed on the computing unit. When executed, the operating or control procedure may, for example, include receiving signal or measured values and outputting control signals. If the control unit is, for example, an engine control unit, the control signals may trigger the control of fuel injectors or an electric motor.
[0043] If, for example, a new version of software 102 is to be loaded or applied to the control unit 104, then software 102 should be free of malware in order to ensure safe and reliable operation of the control unit or the component it controls.
[0044] For this purpose, the software or software probe 102 can first be checked for malware (or, as mentioned, generally for potentially harmful behavior). It is also conceivable, however, that already loaded software is analyzed for potential malware.
[0045] One possible method for this is, in one embodiment, in Fig. 2 shown.
[0046] First, a target software 200 can be obtained, which is then decomposed in step 202 to obtain a decomposition comprising functional blocks. This decomposition of the target software can then be stored as target software data 204, for example, in a database 206. This target software data 204 can then be made available in step 208.
[0047] The target software 200 could be, for example, a Python library downloaded from a specific source that implements a mathematical library which has (potentially) been maliciously manipulated to carry out a data theft attack. The decomposition could include functional areas such as structure, number representations, matrix multiplication, printing or outputting the final result, and other related tasks.
[0048] Furthermore, in step 210, software data 212 can be obtained, comprising a multitude of decompositions, each decomposition comprising one or more of the functional blocks obtained or obtained by decomposing a software sample. This software data 212 can, for example, be stored in a database 214.
[0049] Furthermore, in step 216, malware data 218 can be obtained, comprising a variety of decompositions, each decomposition comprising one or more of the functional blocks obtained or obtained by decomposing an attack vector. This malware data 218 can, for example, be stored in a database 220.
[0050] In step 222, the functional blocks or functional areas (i.e., areas of several functional blocks) of the malware data 218 are then marked, i.e., labeled. Software label data 224 is obtained in this process and stored, for example, in a database 226. This software label data 224 can then be made available in step 228.
[0051] In malware data 218, an entry could be, for example, a decomposition representing the "data theft" attack vector. This decomposition might then include, for instance, functional blocks that send local data to a remote server via a communication link.
[0052] Similarly, in step 228, the functional blocks or functional areas (i.e., areas of several functional blocks) of the malware data 218 are marked, i.e., labeled. Malware label data 230 is obtained in this process and stored, for example, in a database 232. This malware label data 232 can then be made available in step 236.
[0053] The decomposition "Data Theft" with the label could, for example, have been obtained based on STRIDE. In this example, two nested areas might be labeled. The first area might be labeled "Rejection," expressed by an area that stops all logging activity to prevent the tracing of malicious actions. The second area might be labeled "Information Disclosure," describing a set of functional blocks that allow data to leak to a remote server. In this example, both threat-labeled areas work together to enable a stealthy attack: untraceable data theft.
[0054] Steps 222 and 230 can essentially proceed in the same way. For example, a machine learning model 238, e.g., an LLM, can be used to recognize and label corresponding function blocks or function areas. Alternatively, an automatic parser 240 can be used.
[0055] It should be noted that the steps for obtaining software label data and malware label data can be carried out independently of the steps for obtaining the target software data. In fact, the software label data and malware label data can, for example, be stored in the aforementioned databases so that they can be accessed as needed.
[0056] In step 242, the target software data 204 is now analyzed. The process from Fig. 2 goes into Fig.Step 3 continues, with step 242 shown in both figures for better understanding. This can initially include generating labels for the functional blocks of the target software data in step 244. This is done based on the software label data and the malware label data. Target software label data 246 is obtained, which includes labels for the functional blocks of the target software data. The target software label data 246 can, for example, be stored in a database 248.
[0057] Furthermore, in step 250, a composition of the target software can be analyzed based on the labels for the functional blocks of the target software data. This results in a behavior report 252. The behavior report 252 can, for example, be stored in a database 254.
[0058] For steps 244 and 250, for example, one or more machine learning models 256, such as an LLM, can be used to recognize, label, and analyze the corresponding function blocks or functional areas. An automatic parser 258 can also be used.
[0059] 6. The parser can, for example, analyze potential attack paths based on the labels extracted from the decompositions (e.g., by comparison with known attack paths). Within STRIDE, for instance, a database could be provided that defines which functional labels are associated with the disclosure of information. If these are found (e.g., via a simple search pattern, not necessarily a machine learning model), this could be an indication of malicious behavior.
[0060] Behavior report 252 can, for example, include general behavioral characteristics for the target software or a library thereof. This might include, for example, support for various number formats, support for multiple mathematical functions including vector and matrix multiplication, addition, subtraction, etc., support for communication with external servers, or support for logging.
[0061] Behavior Report 252 can, for example, contain potential indicators of compromise. This could include, for instance, tampering and repudiation, where matrix multiplication appears to add a random value to the actual result, and this operation is not logged. It could also indicate information disclosure, where, before the final result is displayed, the target software or its library establishes a connection to a remote server and transmits the result. This would, for example, suggest a data theft attack.
[0062] It is important to note that malicious or harmful behavior is identifiable primarily based on two perspectives: functionality and threats. For example, matrix multiplication leads to a distortion of the result. The manipulation is concealed (repudiation) by stopping all logging activities. The manipulated result is then sent to a remote server (information disclosure) in a different area of the library.
[0063] The target software label data 246 and the behavior report 252 can then, in step 260, be provided together as analysis result data.
[0064] In step 262, the target software can be checked for the presence of malware. If malware is found, information 264 about the presence of malware can be provided, at least if malware has been detected in the target software. For example, a suitable message can be sent for this purpose.
Claims
[1] Method for analyzing target software (102, 200), in particular operating software for a technical system (104), e.g. a control unit, with regard to potentially harmful behavior, comprising: Providing (208) target software data (204) comprising a decomposition, wherein the decomposition comprises functional blocks that are or have been obtained by decomposing the target software; Providing (228) software label data (224) comprising labels for functional blocks of software data (212), wherein the software data comprises a plurality of decompositions, each decomposition comprising one or more of the functional blocks obtained or obtained by decomposing a software sample; Providing (236) malware label data (232) comprising labels for functional blocks of malware data (218), wherein the malware data comprises a plurality of decompositions, each decomposition comprising one or more of the functional blocks obtained or obtained by decomposing an attack vector; Analyzing (242) the target software data, based on the software label data and the malware label data, to obtain analysis result data; and Providing (260) the analysis result data. [2] Method according to claim 1, wherein the analysis of the target software data comprises: Generating (244) labels for the functional blocks of the target software data, based on the software label data and the malware label data, obtaining target software label data (246) that includes labels for the functional blocks of the target software data, where the analysis result data includes the target software label data. [3] Method according to claim 2, wherein the analysis of the target software data further comprises: Analyzing (250) a composition of the target software based on the labels for the functional blocks of the target software data, obtaining a behavioral report, the analysis results data includes the behavior report. [4] Methods according to one of the foregoing claims, further comprising: Examine (262) the target software for the presence of potentially harmful behavior, based on the analysis result data; and Providing information (254) about the presence of harmful behavior, at least when harmful behavior has been detected in the target software. [5] Method according to any of the preceding claims, wherein the analysis of the target software data is carried out using a machine learning model and / or a parser. [6] Method according to any of the preceding claims, wherein the target software is the operating software for the technical system, and wherein the target software is used for the operation of the technical system only if, according to the analysis result data, no harmful behavior is present in the target software. [7] Method according to claim 6, wherein the technical system is one of the following technical systems: - A vehicle, - A component or control unit of a vehicle, - A robot or a robot's control unit, - A sensor. [8] Computing unit (100) configured to perform all process steps of a process according to any of the preceding claims. [9] Computer program that causes a computing unit to perform all the process steps of a method according to any one of claims 1 to 7 when executed on the computing unit. [10] Machine-readable storage medium with a computer program stored thereon according to claim 9.