Method of generating training data for training machine learning model for identifying malware

By generating well-adapted software samples and using a large language model (LLM) to decompose and integrate functional blocks, the problem of insufficient training data is solved, enabling efficient identification of malware and security assurance of engineering systems.

CN121412979APending Publication Date: 2026-01-27ROBERT BOSCH GMBH
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202511008803.6
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Priority Date
2024-07-24
Filing Date
2025-07-22
Publication Date
2026-01-27

AI Technical Summary

Technical Problem

Existing technologies struggle to effectively train machine learning models to identify malware in open-source software, primarily due to a lack of training data and insufficient data sharing mechanisms, making it difficult to identify and remove malware packages.

Method used

Malware samples are generated manually or synthetically, and functional blocks are decomposed and integrated using a large language model (LLM) to generate adapted, well-fitted software samples to train machine learning models for identifying malware.

Benefits of technology

It provides a large number of synthetic malware benchmarks for training machine learning models, improving the accuracy and efficiency of malware identification and ensuring the secure operation of engineering systems.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121412979A_ABST
    Figure CN121412979A_ABST
Patent Text Reader

Abstract

The invention relates to a method for generating training data for training a machine learning model for identifying malware, in particular malware in operating software for an engineering system, such as a control device, comprising: providing (110) malware data comprising a plurality of decomposition parts, wherein the decomposition units respectively include functional blocks obtained or already obtained by decomposing the attack vector; providing (120) good software data comprising a plurality of decomposition parts, wherein the decomposition parts respectively comprise functional blocks obtained or already obtained by decomposing the good software samples; generating (130) training data on the basis of the malware data and the good software data, the training data comprising adapted good software samples, the good software samples being respectively based on functional blocks of the corresponding good software samples, the functional blocks supplementing one or more functional blocks of the malware data; and training data is provided for training the machine learning model.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to a method for generating training data for training a machine learning model for identifying malware, and to a computing unit and computer program for performing the method. Background Technology

[0002] So-called open-source software can be used in many different fields. Due to the wide variety of such open-source software and the lack of testing at times, the presence of malicious software is often unavoidable. Summary of the Invention

[0003] According to the present invention, a method for generating training data, particularly a computer-implemented method, having the features of the independent patent claims, is proposed, along with a computing unit and computer program for performing the method. Advantageous designs are the subject of the dependent claims and the description below.

[0004] This invention relates to the identification of (potential) malware contained within other software. For example, so-called open-source software is considered as such software, but internal software or other third-party software is also considered. In particular, this invention relates to the identification of malware in operating software for engineering systems, such as control equipment.

[0005] Open source software, or open source packages, has become a crucial cornerstone of modern software development. It is estimated that free and open source software accounts for 70% to 90% of all modern software solutions. Therefore, the availability of such packages impacts virtually every aspect of modern software-based solutions, products, and services.

[0006] Numerous packages can be downloaded from various package registries, including npm (JavaScript), PyPI (Python), and RubyGems (Ruby). If developers publish tens of thousands of updates to these registries and upload hundreds of new packages daily, a collection of millions of publicly available packages is formed.

[0007] Unfortunately, the overwhelming availability of free software comes at a price—potentially dangerous software, often referred to below as malware. Malware specifically refers to software packages that have been modified to actively launch attacks. This contrasts sharply with traditional software vulnerabilities, which are not intentionally created.

[0008] The increased risk here can stem from several factors: (1) anyone can upload such packages, (2) only a limited number of packages are digitally signed or verified, and (3) repositories or databases typically lack proactive identification mechanisms to identify and filter out such malware when necessary. In this environment, it is easy to inject tampered packages (i.e., malware) to launch attacks on the supply chain, i.e., where the software is used. As mentioned earlier, this problem extends far beyond the JavaScript and Python ecosystems. While open-source software is the specific motivation here, the methods explained below can also be applied to other types of software, i.e., software from any source.

[0009] As has been found, the solution to this problem lies in using machine learning (ML) methods, i.e., using machine learning models or artificial intelligence (AI) to automatically identify indicators of malice or harmfulness in software benchmarks, i.e., to identify malware in general. However, ML-based identification requires a large number of software samples (so-called benchmarks) to train the machine learning model. It has been found that accessing real malware or malware packages is extremely difficult because (1) harmful malware is usually completely removed from the repository after it is discovered, and (2) due to the sensitive nature of the package content, the repository is usually not prepared to share data, i.e., malware (that may have been removed), i.e., not to provide it to other parties. Therefore, the lack of training data makes it very difficult to implement machine learning-based identification techniques.

[0010] Against this backdrop, the following feasibility is proposed: generating malware artificially or synthetically, and more precisely, generating malware automatically. This proposal relies particularly on text-based decomposition and integration of functional blocks and, especially, on large language models (LLMs) as machine learning models. In this way, effective and realistic malware (or malware benchmarks) can be generated, which can be used to train machine learning-based recognition models.

[0011] The following is a brief explanation of the various terms used in the scope of this application.

[0012] Function block: A function block is the smallest meaningful functional part of a software package that can be represented or decomposed. For example, a function block can be a function or a series of functions that performs a specific behavior. In particular, function blocks are represented in the form of textual (and thus human-readable) descriptions. An example of a function block could be a function that performs the action: "Establish a connection with a remote server via a protocol such as FTP or SFTP."

[0013] Functional Region: A functional region refers to a set of interconnected functional blocks that perform specific, more complex actions. For example, a functional region could be a set of functional blocks that perform an attack, such as forwarding confidential information to a remote server. Therefore, a functional region representing such an attack could consist of functional blocks such as:

[0014] 1) Turn off logging.

[0015] 2) Open the desired local file in read mode.

[0016] 3) Read the file content.

[0017] 4) Establish a connection to the remote server via protocols such as FTP or SFTP.

[0018] 5) Open a file on the remote server in write mode.

[0019] 6) Write the contents read from the local file to the remote file.

[0020] 7) Close remote files.

[0021] 8) Close local files.

[0022] 9) Continue logging.

[0023] Decomposition section: The decomposition section (also known as the parsing section) is the entire software (i.e., a software package) represented in the form of associated functional blocks.

[0024] Software Sample (SW Sample): A software sample (or software pattern or SW sample) is a software package, including its code, configuration files, and other components. For example, a software package could be a Python library used for training distributed machine learning models. It's important to note that the term "software package" is not necessarily limited to software parts from an online registry. In principle, any small piece of code written in any programming language or any software segment can be used as a software sample. Furthermore, there are no restrictions on specific programming languages. Here, a software sample refers to a component.

[0025] Software type: Software type refers to the type of functionality that implements a particular software sample (at arbitrary granularity). Examples of software types are math libraries, cryptography libraries, machine learning libraries, graphics libraries, etc. Therefore, type specifically refers only to a general description of functionality, rather than details of implementation such as programming language, code structure, algorithm specifications, file extensions, etc.

[0026] Here, we first provide data on malware and data on good software. This data can be obtained independently of each other; the order is not important.

[0027] Malware data comprises multiple decompositions, each consisting of functional blocks derived from the decomposition of attack vectors. An attack vector (or "attack vector") is specifically a possible attack path or (potentially distributed / multi-stage) method, such as how an unauthorized intruder (of any type) could penetrate or compromise an external computer system in order to then take over or at least misuse it for their own purposes. Attacks sometimes go beyond their intended purpose, such as leaking files to the internet or attempting to render a system unresponsive (DoS). Therefore, ultimately, there are coherent functional blocks for the attack vector, similar to those in a software sample. For this purpose, for example, a set of known attack vectors is collected from various sources and decomposed into functional blocks, resulting in a large number of decompositions (or a set of attack decompositions).

[0028] Good software data comprises multiple decomposition sections, each including functional blocks obtained by decomposing good software samples. A good software sample is understood as a software sample that is known, or at least presumed, not to contain, malicious software. Here, good software samples for each different software type may include good software samples collected, particularly from different sources. For example, for at least one different software type, good software samples may also include one or more good software samples generated from at least one collected good software sample.

[0029] Therefore, good software samples are collected for a range of different software types and decomposed into functional blocks, resulting in a large number of decomposition parts. Alternatively, additional variations of the good software samples can be generated prior to decomposition, for example, by reconfiguration (more details will be explained later).

[0030] Then, training data is generated based on malware data and good software data. This is done in such a way that the training data includes adapted good software samples, each good software sample being based on a corresponding function block of the good software sample, which supplements one or more function blocks of the malware data. For this purpose, the malware data and good software data can be compared, for example, to identify or find consistent regions with corresponding function blocks. Specifically, here, the decomposed portions of the malware data and good software data are compared with each other. Then, in the consistent regions, the function blocks of the good software data are supplemented with the corresponding function blocks of the malware data. Then, based on this, adapted good software samples are generated. Therefore, the adapted good software samples are artificially or synthetically generated malware.

[0031] In this context, it is important to note that malware typicality is always artificially generated in some way and through some method. Of course, within the scope of this application, this should be specifically understood as meaning that the malware is generated specifically for training a machine learning model that can subsequently identify malware, rather than for use in actual attacks.

[0032] When training a machine learning model for identifying malware, training data is generated and provided for training as described above. The machine learning model is then trained based on the training data, such that output data is determined based on the training data used as input data for the machine learning model. The output data includes information about the presence of malware in the input data. The trained machine learning model is then provided, for example, for the application described above. As mentioned above, the training data includes adapted samples of legitimate software, i.e., artificially or synthetically generated malware. Therefore, in this respect, information concerning malware is also present in the training data. Here, the data can be labeled or annotated at multiple levels. Thus, for example, the entire software can be labeled as malware or legitimate software, but only malicious functional areas can be labeled, and further, only functional blocks of malware can be labeled.

[0033] Therefore, the proposed method can generate synthetic malware or malware benchmarks that match real attack descriptions. The entire process is independent of the software's language and architecture, and thus can be applied to scripting languages ​​and embedded code. The proposed method can be applied to software of any size, from large projects to small code snippets.

[0034] In one implementation, the machine learning model trained in this way is used to identify malware in software samples. Such software samples are particularly used for engineering systems, such as operating software for control devices. However, vehicles, vehicle components or control devices, or robots or robot control devices can also be considered as engineering systems. Furthermore, sensors, particularly embedded sensors or other embedded systems, can be considered, for example.

[0035] Here, the operating software of the engineering system can be understood in particular as a computer program, which, when executed on a computing unit, causes the computing unit, i.e., a control device, to perform an operating or control method. This operating or control method, when executed, may include, for example, receiving signals or measurements and outputting control signals. If the control device is, for example, a motor control device, the control signal may cause control of a fuel injector or an electric motor.

[0036] Software samples, particularly operating software, are only used to run engineering systems, i.e., loaded onto control devices, if malware is not identified using the proposed method. This ensures the operation of engineering systems, such as control devices and their controlled components like motors or vehicles, because the presence of malware can be ruled out with at least a high probability.

[0037] The computing unit according to the invention, such as a computer or server (e.g., also in the so-called cloud), is particularly designed in terms of programming to execute the method according to the invention.

[0038] Especially when the control device being executed is also used for other tasks and thus always exists, an implementation of the method according to the invention in the form of a computer program or computer program product having program code for executing all method steps is also advantageous, as this results in particularly low costs. Finally, a machine-readable storage medium is provided having the computer program as described above stored thereon. In particular, suitable storage media or data carriers for providing this computer program are magnetic storage, optical storage, and electrical storage, such as hard disks, flash memory, EEPROM, DVDs, and others. Downloading the program via a computer network (Internet, intranet, etc.) is also feasible. Here, such downloading can be achieved wired or cabled or wirelessly (e.g., via WLAN networks, 3G, 4G, 5G, or 6G connections, etc.).

[0039] Other advantages and design solutions of the present invention can be derived from the specification and drawings.

[0040] The present invention is schematically illustrated in the accompanying drawings according to embodiments and is described below with reference to the accompanying drawings. Attached Figure Description

[0041] Figure 1a The device of the present invention is illustrated schematically.

[0042] Figure 1b The flowchart of one implementation method is illustrated schematically.

[0043] Figure 2 , 3 Figures 4 and 5 each illustrate a portion of a method of one embodiment. Detailed Implementation

[0044] Figure 1a The diagram schematically illustrates an apparatus in which the invention can be used. The apparatus exemplarily includes a computing unit 100, such as a computer or server, and an engineering system 102, which may be, for example, a vehicle control device.

[0045] Furthermore, software or a software sample 102 is shown. Here, it is particularly a computer program that, when executed on a computing unit, causes the computing unit—in this case, a control device 102—to perform an operating or control method. This operating or control method, when executed, may include, for example, receiving signals or measurements and outputting control signals. If the control device is, for example, a motor control device, the control signals may cause control of a fuel injector or an electric motor.

[0046] For example, if a new version of software 102 is to be loaded or applied to control device 104 now, software 102 should be free of malware to ensure the safe and reliable operation of the control device or the components controlled by it.

[0047] Therefore, the software or software sample 102 can be checked for malware first. In one implementation, in Figure 1b The flowchart for this method is shown in the figure.

[0048] In step 110, malware data including multiple decomposition units is provided, wherein each decomposition unit includes functional blocks obtained or already obtained by decomposing attack vectors.

[0049] In step 120, good software data including multiple decomposition parts is provided, wherein each decomposition part includes function blocks obtained or already obtained by decomposing a good software sample.

[0050] Then, in step 130, training data is generated, more specifically, training data is generated based on malware data and good software data; then, the training data is provided for use. Here, the training data includes adapted good software samples, each based on a function block of a corresponding good software sample, the function block being supplemented with one or more function blocks from the malware data.

[0051] Then, in step 140, a machine learning model is trained, more specifically, a machine learning model is trained based on training data; this is done as follows: output data is determined based on the training data as input data for the machine learning model, the output data including information about the presence of malware in the input data. The machine learning model thus trained is then provided for use or application.

[0052] Then, in step 150, a trained machine learning model is applied, more specifically, to, for example, software sample 102. Here, output data is then determined, which includes information about the presence of malware in the input data, i.e., software sample 102.

[0053] In step 160, if the software sample 102 does not contain or contains any malware, it is loaded onto, for example, control device 104, where it can be used for secure operation. Steps 110 through 150 may be performed on computing unit 100 or on a different computing unit. Furthermore, computing unit 100 (or other computing unit) may be used to load the software sample onto the control device.

[0054] The following will refer to Figure 2 , Figure 3 , Figure 4 Steps 110, 120, and 130 will be explained in more detail according to one implementation.

[0055] according to Figure 2 Step 110 will be further explained in detail according to one embodiment. The objective of this step is, in particular, to create a database with an attack vector parsing unit, that is, a database with a decomposition unit that has functional blocks obtained by decomposing attack vectors.

[0056] To this end, a set of attack vectors can be collected in step 200 and then stored in database 202; alternatively, multiple databases can be used, for example, based on the source of the attack vectors. An attack vector is, for example, a textual description of the steps required to perform a specific attack. Attack vectors can be obtained from various sources.

[0057] For this purpose, attack vectors can be manually input, for example, by a (human) user 204, step 206. An automated parser can also analyze and extract attack paths from various sources, step 208. Such sources could be, for example, forums and websites 210 on the Internet (and the deep web), databases containing known malware 212 and / or vulnerable software 214 (i.e., malware in the general sense). Attack vectors can also be extracted from literature, for example, from scientific papers, blogs, etc.

[0058] Alternatively, a machine learning (ML) model can be used. Step 216: Known attack vectors can be collected by querying a machine learning model (e.g., an LLM). In general, an LLM already contains knowledge from previous attack vector sources.

[0059] Then, in step 220, the attack vector can be decomposed into functional blocks, where each attack vector (text description) is decomposed into attack steps. Each step is a single functional block.

[0060] Decomposing into functional blocks can be done in different ways, for example by manually describing the attack by a (human) user, manually (at one cost) classifying the attack description into steps, step 222.

[0061] An automated parser can analyze and extract attack steps (functional blocks) from attack descriptions, for example, through regular expression-based analysis, step 224. Another example is extracting comments from malware code. Comments (provided they are of good quality) can be used to extract descriptive functional blocks.

[0062] Alternatively, a machine learning model (ML model) can be used. Step 226: The attack steps can be determined by querying a machine learning model (e.g., an LLM). In general, an LLM already contains knowledge from previous sources.

[0063] The resulting attack vector decomposition can then be stored in database 228; multiple databases can also be used for this purpose.

[0064] It should be noted here that: in step 110 or according to Figure 2 In the process, specific parts can be modularly constructed; more precisely, the representation of functional blocks 230, and the representation of decomposition parts, in this case, the representation of attack vectors 240, can be modularly constructed. This will be explained in more detail later.

[0065] according to Figure 3 Step 120 will be explained in more detail according to one embodiment. The objective of this step is, in particular, to create a database with a well-defined parsing section, i.e., a database having a decomposition section containing functional blocks obtained by decomposing a well-defined software sample.

[0066] Therefore, in step 300, a set of software types can be collected from various sources and stored in database 302. For example, a software type is a general description of the functionality of an implementation software package. Software types can be obtained from multiple sources.

[0067] For this purpose, for example, a (human) user 304 can input the software type based on previous experience, step 306. The automatic parser can also analyze and extract the software type from various sources, step 308. Such sources may be, for example, forums and websites from the Internet (and the deep web) 310, metadata, reviews or descriptions from software repositories 312, or existing software classifications.

[0068] Alternatively, a machine learning model (ML model) can be used. Step 316: Known software types can be collected by querying a machine learning model (e.g., an LLM). In general, an LLM already contains knowledge from previous sources of software types.

[0069] Then, in step 320, good software samples or good software templates can be collected. For each software type, a set of good software samples is collected. Good software samples can come from various sources, including software repositories 322, open-source Git repositories, and local project files.

[0070] Therefore, it should be noted that: in principle, a good software sample that is actually (i.e., verified) is not required; therefore, if a software sample has been tested, reviewed, used and verified by multiple parties or users over a long period of time, it can be considered to be good with at least a high probability or a sufficiently high probability.

[0071] Then, good software samples can be stored, for example, in database 324.

[0072] Optionally, in step 326, additional good software samples, i.e., good software variants, can be generated based on the already available, i.e., the collected good software samples as described above. The specific method used to generate the additional software variants is not important here. A possible method 328 for generating additional software variants through reconfiguration will be explained in more detail later.

[0073] If desired, the resulting variants can also be reviewed, for example, through testing, to ensure that the variants are always unquestionable. The additional, well-prepared software samples can then be stored, for example, in database 330 (or possibly database 324).

[0074] Then, in step 332, the good software sample can be decomposed into functional blocks. It's important to note here that the decomposition of a good software sample differs from the decomposition of an attack vector. Creating an attack decomposition means converting the textual description of the attack into a decomposition of functional blocks. In contrast, a good software sample is a software package that must be decomposed into functional blocks. The format of the decompositions doesn't necessarily have to be identical, but as will be explained in more detail later, if the representation of the decompositions adheres to the required characteristics, they should always be comparable and aligned.

[0075] However, for simplicity, we can assume that the decomposition of the attack vector and the decomposition of a good software sample are represented in the same format. Therefore, the decomposition representation combines the attack vector description and the intermediate representation of the software.

[0076] Like attack vectors, good software samples or software samples can often be transformed into decomposition parts in various ways.

[0077] Decomposition into functional blocks can be done in different ways, such as through manual description by (human) users, manually (at a one-time cost) associating software code with functional blocks and connecting them to the decomposition unit.

[0078] The automatic parser can analyze and extract functional blocks from software code, for example, by extracting each function or each basic block, analyzing comments in the code, etc., step 334.

[0079] Alternatively, a machine learning model (ML model) can be used. Step 336: The software can also be analyzed and decomposed using a machine learning model (LLM). Users can input all the software code into the LLM and request a description of each function (or other granularity).

[0080] The process of decomposing attack vectors (step 110) and decomposing good software samples (120) can be very similar, for example, by querying the LLM with different input requests.

[0081] The resulting decomposition of a good software sample can then be stored in database 338.

[0082] It should be noted here that: in step 120 or according to Figure 3 In the process, specific parts can be constructed modularly; more precisely, the generation of software variants 328, the representation of functional blocks 340, and the representation of decomposed parts (in this case, the good software sample 350) can be constructed modularly. This will be explained in more detail later.

[0083] according to Figure 4 Step 130 is explained in more detail according to one embodiment. The objective of this step is, in particular, to combine the decomposition of the attack vector with the decomposition of the good software sample to produce a adapted good software sample, i.e., a good software sample with malicious software (malicious software benchmark).

[0084] To this end, consistent regions can be found or identified in step 400: the decomposition part 404 of the good software is compared with the decomposition part 402 of the attack vector to identify regions that have common or corresponding functional blocks.

[0085] It's important to note that, in principle, it's feasible when no inconsistencies are found, or no direct inconsistencies are found. However, in these cases, alignment can determine the optimal position for assembling additional functional blocks.

[0086] Consistent regions can be identified in various ways, such as by string comparison matching. Step 406: Since the decomposition part contains functional blocks with specific characteristics, a search algorithm can be used to identify consistent regions.

[0087] Step 408: A user-defined adaptation or alignment algorithm can also be used to identify consistent regions. This algorithm can be based on the similarity of functional blocks, the order of functional blocks, or other characteristics. In a user-defined implementation, similarity assessment can be used to confirm whether two sets of functional blocks represent similar regions. The similarity calculation is not limited here. A machine learning (ML) model can also be used; step 410: An ML model can be used to identify consistent regions.

[0088] The consistent region thus obtained can then be stored in database 412.

[0089] Then, in step 420, the function blocks of good software data can be supplemented in the consistent area with the corresponding function blocks of malware data to satisfy the functions of the attack described in the decomposition section.

[0090] Therefore, in step 422, missing function blocks can be extracted from the decomposition of the attack vector. Then, in step 424, function blocks with good software data can be supplemented in the consistent region. For example, this can include post-positioning and / or pre-positioning and / or insertion of function blocks in the consistent region.

[0091] The supplementary function blocks or decompositions thus obtained can then be stored in database 426.

[0092] Then, in step 430, the changes or additions made can be reflected in the good software sample: in the previous steps, a series of decompositions with malicious regions were created. Now, these decompositions should be converted into a specific software sample (benchmark).

[0093] To this end, step 432 may involve collecting a range of implementation options for each functional block in the malicious region. This can be done by querying a machine learning model 434, retrieving example implementations from the Internet 436 or database 438, or by manually collecting a range of implementation options 440.

[0094] Then, in step 442, each functional block can be converted back into software code. This step can be performed, for example, through a deterministic mapping process or through a machine learning model.

[0095] After taking into account all the variations in the software, the final result of this invention is a collection of benchmarks of malware that can be stored in database 444.

[0096] It should be noted here that: in step 130 or according to Figure 4 In the process, specific parts can be constructed modularly. More precisely, the alignment algorithm 450 (see also step 408) used to find consistent regions, the similarity evaluation 452 used herein, and the algorithm 460 in step 430 can be constructed modularly.

[0097] Below, we will explain the aforementioned modularity in more detail. As mentioned above, specific parts can be constructed modularly, meaning there are no restrictions on how or should the parts be implemented.

[0098] For a representation of function blocks, see [link to documentation]. Figure 2 230 and Figure 3 340 in the middle.

[0099] As previously stated, a functional block is the smallest meaningful functional part of a software package, represented in a decomposed or parse manner. This application is not limited to a specific representation or granularity of functional blocks. However, the representation of a functional block should include specific characteristics, such as:

[0100] • Descriptiveness: The representation of a functional block should include a description of the function performed by that block.

[0101] • Parsability: The representation of the functional blocks should be analyzable by a machine.

[0102] • Distinctiveness: This means that different functional blocks should be implemented.

[0103] If an existing format meets the above requirements, then the existing format can also be used for representation. For example, a function block can be represented as a single processor instruction, a single function call, a basic block in a control and data flow graph, an instruction sequence, an API call sequence, etc.

[0104] For the representation of the decomposition section, see [link to relevant documentation]. Figure 2 240 and Figure 3 The representation of the decomposition part (or parsing part) is not limited to a specific format. However, the representation of the decomposition part (or parsing part) should include specific features, such as:

[0105] • Adaptability: The representation of the parsing unit should be adaptable, that is, functional blocks can be added, removed or changed.

[0106] • Reconfigurability: The representation of the analytic part should be reconfigurable, meaning it should be reflectable in the software. More precisely, if necessary, only the adapted parts of the decomposition part should be reflected in the software.

[0107] • Parsability: The representation of the decomposition parts should be analyzable by a machine.

[0108] Possible examples of representations of the decomposition part are control and data flow graphs and abstract syntax trees.

[0109] To generate additional good software variants, see also the examples of other good software. Figure 3 328 in the middle.

[0110] Generating additional good software variants is an optional step. The goal of this step is to generate additional good software variants based on already available good software samples, i.e., good software samples. In principle, this corresponds to the typical steps of data augmentation. However, the challenge lies in how to perform data augmentation within a software environment. This application does not specify any specific limitations on how data augmentation should be performed. However, generating additional good software samples should produce functionally equivalent (or at least very similar) software samples.

[0111] exist Figure 5 The text describes possible ways to generate additional good software samples through reconfiguration.

[0112] For example, the input to the process is dataset 500, which contains software samples associated with software types. Output 502 is the same dataset populated with other software sample variants.

[0113] The process is described below with reference to only one software sample; however, the same process can be repeated for all software samples in the dataset of 500.

[0114] In step 504, the software sample is decomposed into functional blocks using the previously explained decomposition concept (the method for generating decomposition parts).

[0115] In step 506, variants are generated: For each functional block, a list of potential code variants representing the functional block is created. These variants are generated, for example, by using machine learning (ML) (e.g., LLM), by retrieving variants from an existing database 508, or through other code transformations.

[0116] In step 510, the software sample is reconfigured: using machine learning or a user-defined replacement method, the original software sample is reconfigured with available function block variants (existing blocks are replaced by new variants). This can be repeated for all function blocks in the software sample, thereby creating a large number of new software samples. Changes to the function blocks are reproduced in the code in the same way that has already been explained.

[0117] The reflection of change (or perhaps a "mirror image"), see [link / reference]. Figure 4 460 in the middle.

[0118] After supplementation, any added, removed, or generally adapted functional blocks in the decomposition section must be incorporated back into the original software implementation. However, within the scope of this application, the manner in which this is done is irrelevant. However, it is preferable, for example, to generate the software deterministically from prior work, or through a machine learning model (such as LLM).

Claims

1. A method for generating training data for training a machine learning model to identify malware, particularly malware in operating software used in engineering systems, such as control equipment, the method comprising: Provide (110) malware data including multiple decomposition units, wherein each decomposition unit includes functional blocks obtained or already obtained by decomposing attack vectors; Provide (120) good software data including multiple decomposition sections, wherein the decomposition sections respectively include functional blocks obtained or already obtained by decomposing good software samples; The training data (130) is generated based on the malware data and the good software data, wherein the training data includes adapted good software samples, each adapted good software sample being based on a corresponding function block of a good software sample, the function block supplementing one or more function blocks of the malware data; and The training data is provided for training the machine learning model.

2. The method according to the preceding claim, wherein the plurality of decomposition parts for obtaining the good software data by decomposing good software samples include: Provide the good software samples, wherein the good software samples include good software samples collected for each different software type, and the good software samples are specifically from different sources; and The good software sample is decomposed into the functional blocks.

3. The method of claim 2, wherein the good software samples of at least one software type among the different software types include one or more good software samples generated from at least one of the collected good software samples.

4. The method of claim 3, wherein the good software sample generated from at least one of the collected good software samples is generated from at least one of the collected good software templates by means of reconfiguration.

5. The method according to any one of the preceding claims, wherein generating the training data comprises: Compare (400) the malware data and the good software data to identify consistent regions with corresponding functional blocks; In the consistent region, the function block of the good software data is supplemented (420) with the corresponding function block of the malware data; and Based on the good software data, the function block supplemented with the malware data generates (430) a good software sample.

6. A method for training a machine learning model for identifying malware, particularly in operating software for engineering systems, such as control equipment, the method comprising: Training data is generated (130) and provided according to any one of the preceding claims; The machine learning model is trained (140) based on the training data, such that output data is determined based on the training data as input data for the machine learning model, the output data including information about the presence of malware in the input data; and Provides trained machine learning models.

7. A method for identifying malware using a machine learning model trained according to claim 6, the method comprising: Provide input data for the machine learning model, wherein the input data includes software samples; The machine learning model described in (150) is applied, wherein output data is determined based on the input data, the output data including information about the presence of malware in the input data; and Provide the output data.

8. The method of claim 7, for identifying malware in operating software for engineering systems, such as control equipment.

9. The method according to claim 8, wherein, The software sample for the input data is the operating software of the engineering system, and The software sample is used to run the engineering system only if there is no malicious software in the input data according to the output data.

10. The method according to claim 8 or 9, wherein the engineering system is one of the following engineering systems: -vehicle, - Vehicle components or control devices - Robot or robot control equipment, -sensor.

11. A computing unit (100) designed to perform all method steps of the method according to any one of the preceding claims.

12. A computer program, when executed on a computing unit, causes the computing unit to perform all the method steps of the method according to any one of claims 1 to 10.

13. A machine-readable storage medium having a computer program according to claim 12 stored on the machine-readable storage medium.