Method for analyzing target software with respect to potentially harmful behaviors

Abstract

The invention relates to a method for analyzing target software, in particular operating software for a technical system, such as a control device, with respect to potentially harmful behaviors, comprising: providing target software data comprising a split body, the split body comprising functional blocks obtained or obtained by splitting the target software; providing malware data comprising a plurality of fractions, wherein the fractions each contain one or more of the functional blocks obtained or obtained by splitting the attack vector; providing a test set of comparative tests, where the comparative tests each include a comparative instruction that indicates how the target software data should be compared to a corresponding split of malware data; analyzing the target software data based on the malicious software data and the test set of the comparison test so as to obtain analysis result data; and providing analysis result data.

Description

Technical Field

[0001] The present invention relates to a method for analyzing target software, particularly operating software of a technical system, such as control equipment, in terms of potentially harmful behavior, as well as a computing unit and computer program for performing the method. Background Technology

[0002] So-called open-source software can be applied to many different fields. Because the number of such diverse open-source software programs is almost incalculable, and because they are sometimes lacking in vetting, it is often impossible to rule out the presence of malicious software. Summary of the Invention

[0003] According to the present invention, a method for analyzing target software, particularly a computer-implemented method, having the features of independent patent claims, is proposed, along with a computing unit and computer program for performing the method. Advantageous embodiments are the subject of the dependent claims and the following description.

[0004] This invention relates to identifying (potential) malware contained in other software, or more generally to analyzing target software (i.e., the specific software or software sample to be examined) in relation to potential malware or other potentially harmful behavior. Such software includes, for example, so-called open-source software, but internal software or other third-party software may also be considered. Particularly, this invention relates to identifying potential malware in operating software targeting technical systems, such as control devices.

[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 any modern software solution. Therefore, the availability of such packages impacts virtually every aspect of modern software-based solutions, products, and services.

[0006] A vast number of packages can be downloaded from one of many package registrars, including npm (JavaScript), PyPI (Python), RubyGems (Ruby), and many more. Developers release tens of thousands of updates to these registrars and upload hundreds of new packages every day, resulting in a collection of millions of publicly available packages.

[0007] Unfortunately, the widespread availability of free software comes at a price—potentially dangerous software, also generally referred to below as malware. Malware should be specifically understood as software packages modified to actively launch attacks. This is particularly different from traditional software vulnerabilities, which are not intentionally set up.

[0008] The increased risk in this situation can stem from a variety of factors: (1) anyone can upload such packages, (2) only a limited number of packages are digitally signed or checked, and (3) repositories or databases typically lack proactive identification mechanisms to identify and subsequently remove such malware if necessary. In this environment, it is easy to inject manipulated packages (i.e., malware) to attack the supply chain (i.e., where the software is subsequently deployed). As already shown, this problem extends far beyond the JavaScript and Python ecosystems. While open-source software is a particular motivation here, the methods explained below can also be applied to other types of software, i.e., software from any source.

[0009] A fundamental challenge in malware identification lies in checking or measuring whether an attack (i.e., malware or malicious code) is implemented within the software. As already shown, malware is therefore often not implemented as an interconnected part (Teil) within the target software, but rather, for example, distributed over a wide area of ​​the target software. This makes identifying malware or potentially harmful behavior, or its scope (Maß), significantly difficult.

[0010] Against this backdrop, a method is proposed to analyze the potential for harmful behavior or malicious software in target software, such as, in particular, operational software targeting technical systems, and more specifically, in the sense of the extent (or even the presence) of malware (e.g., attack vectors) in the target software. Specifically, a feature vector can thus be obtained that expresses the degree of matching between malware or attack vectors and steps found in the code. Therefore, the proposed method enables fuzzy reasoning on potential matches (e.g., to arrive at conclusions such as "a data theft attack is unlikely to exist in the code" and "a data theft attack has been found in the code"). Using this feature vector, the degree of matching between specific steps in the code and an attack can be analyzed, even if the code elements are distributed in different areas of the code and / or appear harmless due to their context or location.

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

[0012] Functional Block: A functional block is the smallest meaningful functional part of a software package or software, which is represented or can be represented in a partitioned or decomposed manner. For example, a functional block can be a function or a series of functions that implements a specific behavior. Here, it is particularly recommended that functional blocks be represented in the form of a textual (and therefore human-readable) description. For example, an example of a functional block could be a function that performs the action: "Establish a connection to a remote server via a protocol such as FTP or SFTP".

[0013] Functional Region: A functional region refers to a functional area (or area) of a set of interconnected functional blocks that perform specific, more complex behaviors. For example, a functional region could be a set of functional blocks that execute an attack, such as transmitting confidential information to a remote server. Therefore, a functional region representing this attack might consist of the following functional blocks: 1) Turn off logging.

[0014] 2) Open the required local file in read mode.

[0015] 3) Read file content.

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

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

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

[0019] 7) Close remote files.

[0020] 8) Close local files.

[0021] 9) Continue logging.

[0022] Dekomposition: Dekomposition (also known as splitting) refers to the entire software (i.e., a software package) represented in the form of interrelated functional blocks.

[0023] In the proposed method, target software data is now provided, comprising a decomposition, wherein the decomposition contains functional blocks obtained by splitting the target software. In this case, it is conceivable that some functional blocks constitute functional regions. Therefore, the target software to be analyzed is first split accordingly.

[0024] The representation of the decomposition is here specifically as, or using, a so-called decomposition-based control flow graph (DCFG). A control flow graph (CFG) is a data structure in computer science, used, for example, in compilers. In this case, the target software can be decomposed into an CFG in which each basic block (a basic block is a linear sequence of code with no inward branches except for inputs and no outward branches except for outputs) is represented as a set of function blocks. A functional region may contain one or more basic blocks within the DCFG, depending on the functionality reflected in the CFG. Function blocks are here specifically represented as human-readable descriptions. Thus, a functional region is a group of function blocks that implement a specific behavior. The result of this step is therefore a decomposition of the target software.

[0025] In addition, malware data is provided. This malware data comprises multiple decompositions, each containing one or more functional blocks obtained or acquired by splitting attack vectors. Here, the attack vectors in the malware data can originate from various sources, such as online repositories, threat intelligence sources, synthetic generation, forums, academic papers, vulnerability databases, and others.

[0026] An attack vector (or "attack vector") specifically refers to a possible attack path or (potentially distributed / multi-stage) method, such as how an unauthorized intruder (by whatever means) can penetrate or compromise an external computer system in order to either take over the external computer system or at least misuse it for their own purposes. Attacks sometimes go beyond their primary purpose, such as leaking files to the internet or ensuring a system becomes unresponsive (DoS). Therefore, ultimately, there are interconnected functional blocks against an attack vector, similar to software samples. For this purpose, for example, a set of known attack vectors might be collected from various sources and broken down into functional blocks, resulting in a large number of decompositions (or a set of attack decompositions).

[0027] Here, the representation of the decomposition is specifically carried out as or using a so-called decomposition-based control flow graph.

[0028] Tags can be generated for decompositions or functional blocks of software data and / or malware data. These tags are labels or descriptions of relevant functional blocks (or possible functional areas). Labeling is performed, for example, by traversing functional blocks (and possible functional areas, as multiple functional blocks together) within the decomposition and assigning labels or tags based on comparisons with existing patterns. In principle, comparative resources (Vergleichsressourcen) from sources such as online databases targeting vulnerabilities, reports on threat analysis, threat data sources, collected honeypot data, forums, and other sources can be obtained for malware tagging or labeling. Similarly, tags can be found by searching online repositories, local projects, code examples in forums, papers, document compilations, and other sources. In both cases, a summary of all resources (Zusammenfassung) can be obtained, for example, through an LLM model or other machine learning model.

[0029] Therefore, labels for target software data include, for example, decomposed software with additional functional labels that describe the function of blocks or regions within the decomposed body. The size and distribution of functional blocks within a region assigned to a specific label (or multiple labels) are not inherently restricted.

[0030] For example, a malware tag thus comprises a set of split attack vectors with additional threat markers that describe the potential threat realized in a region of the komposition. There are no inherent limitations on the size and distribution of functional blocks within a region assigned to a particular tag (or multiple tags).

[0031] In addition, a test set for comparison tests is provided. These comparison tests each include comparison instructions (Vergleichsanweisung) that specify how the target software data should be compared with the corresponding decompositions of the malware data. Each comparison test in the test set can be applied to each decomposition of the malware data—each decomposition here corresponds to an attack vector.

[0032] Specifically, these comparison tests can also be called behavioral matching tests. Comparison tests or matching tests thus define a method for measuring or determining specific characteristics that describe the degree of matching between the attack breakdown of malware data (i.e., the breakdown of attack vectors) and the breakdown of target software.

[0033] In one implementation, the test set includes at least one of the following comparative tests. The comparative tests may include: examining how many functional blocks of corresponding decompositions of malware data are included in the decomposition of the target software data, and precisely how many functional blocks contain corresponding decompositions of malware data regardless of the location of the functional blocks. For example, it may be necessary to first examine whether all functional blocks required for a specific attack exist, regardless of their location within the target software. This test can be used to measure the potential of attacks implemented or intended to be implemented in the target software.

[0034] Comparative testing can include examining the breakdown of the target software data, specifically how many functional blocks within a functional area contain the corresponding breakdown of malware data. This can indicate the range of probabilities against a relevant attack. If functional blocks belonging to an attack are found located in the same functional area of ​​the target software, the attack is more likely.

[0035] Comparative testing can include examining the breakdown of the target software data, specifically how many functional blocks within different functional areas contain the corresponding breakdown of malware data. This test is based on the assumption that attacks are more easily disguised when the functional blocks belonging to an attack are distributed across different areas.

[0036] Comparative testing may include checking how accurately the order of functional blocks in the corresponding breakdown of malware data maps to the breakdown of target software data. The order of functional blocks, such as reading local secrets first and then sending them to the internet, may be more damaging than communicating with the internet first and then reading local data. Furthermore, a very low match may indicate that while all the functional blocks of the attack exist, their order is different, and this difference in order may be harmless.

[0037] You may also use some or all of the comparison tests listed herein. Similarly, you may use further or other comparison tests not listed here.

[0038] Based on malware data and comparative test sets, the target software data is analyzed to obtain analysis results.

[0039] In one implementation, this can further involve performing at least one test set, preferably each comparison test, on at least one piece of malware data, preferably each fragment, to obtain behavioral features for each comparison test. Then, for at least one piece of malware data, preferably each fragment, behavioral vectors containing the corresponding behavioral features are determined to obtain a vector set of behavioral vectors. The analysis results data are then based on the behavioral vectors of this vector set.

[0040] Behavior vectors reflect the degree of implementation of an attack (potential) in the target software. Individual behavior vectors are generated by comparing functional blocks or regions in the target software's breakdown with those in the attack's breakdown (e.g., by analyzing a chain of steps). Each comparison test produces a behavior feature (i.e., a value, or even multiple values). Each further behavior feature can be appended to the chain of the previous behavior feature or preceding behavior features, thus producing a behavior vector. Once all behavior features or values ​​from all comparison tests have been collected, the final behavior vector is stored, for example, in a database. In particular, behavior vectors are thus generated for attacks or breakdowns of attacks. It should also be noted that if the comparison tests are part of a running system where obtaining a sufficiently good response is time-critical, certain comparison tests may be omitted to obtain earlier results if necessary.

[0041] In one implementation, analyzing the target software data further includes using an analysis set containing one or more analysis instructions, each instruction specifying how multiple behavior vectors should be evaluated against each other. This analysis set can be provided in a suitable manner. The behavior vectors in the vector set are then analyzed based on one or more of the multiple analysis instructions to obtain intermediate analysis results. The analysis result data is then based on these intermediate analysis results.

[0042] In one implementation, the analysis set includes at least one of the following analysis instructions. Analysis instructions may include sorting the behavioral vectors of the vector set according to a weighting criterion. For example, the weighting criterion may be adapted to focus the search for specific attacks. For instance, if all other (more obvious) attacks have been ruled out or identified, then searching for confidential or hidden attacks may be more relevant to the analysis.

[0043] Analysis instructions may include comparing the behavioral vectors of a vector set with known malware of similar types. Known malware may be, for example, malware that has already been identified. For instance, this analysis can help identify attack patterns that are more frequently used in specific types of software.

[0044] Analysis instructions may include examining whether multiple behavior vectors in a vector set are correlated. For example, such analysis can help identify whether an attack in software is achieved by combining different attack vectors into a more complex attack.

[0045] Based on behavioral vectors and analysis instructions, a report can be created, for example, containing conclusions about the potential match between the attack and the target software—as analysis results data. This report or analysis results data can be used to prioritize and develop security measures based on the potential impact of identified threats, or simply to respond to newly identified attacks in the software.

[0046] Based on the analysis results, the following conclusions can be drawn, for example: it can be identified whether the target software has implemented a covert channel, and / or whether the target software is executing a data theft attack. Even if the two are located in different areas of the target software, they may belong to the same attack. Therefore, the target software uses a covert channel to execute a data theft attack.

[0047] Analysis instructions (analyzers)—and more generally, the analysis of target software data—can be implemented in various ways. For example, human-based rules can be used. Conclusions can then be drawn based on thresholds and rules that transform behavioral vectors into human-readable reports. These can be implemented as a set of rules applied to the behavioral vectors.

[0048] Machine learning models can also be used. Conclusions can then be drawn based on machine learning models trained on behavior vectors. These models can be used to draw conclusions based on behavior vectors.

[0049] This method can also be based on logic. Conclusions can be drawn from logical operations applied to behavior vectors. These conclusions can then be implemented as a set of rules applied to the behavior vectors.

[0050] This method can also be based on fuzzy logic. Conclusions can be drawn based on fuzzy logic operations applied to behavior vectors. These can be implemented as a set of rules applied to behavior vectors.

[0051] The combination of these variations can also be used to draw conclusions based on behavior vectors. It should be noted that conclusions drawn from combinations are generally more reliable than those obtained using a single method.

[0052] At least if malicious behavior has been identified in the target software, it provides information about its presence. It's worth mentioning that malicious behavior is especially prevalent if malware is present. However, it's also conceivable that paths to enabling malicious behavior might unexpectedly exist within the target software—paths that could be exploited by attackers.

[0053] Based on the analysis results, messages can be sent within the scope of automated systems to notify users of potential threats in deployed or under-development software. Furthermore, the features stored in the behavior vectors can be used to learn attacker strategies and techniques, and improve malware identification in the future.

[0054] If the analysis reveals a potential threat, and the target software has already been integrated (e.g., into a development environment, product, proof of concept, etc.), a threat warning can be generated. This warning can be used to notify the user of the potential threat, which includes the analysis results data.

[0055] In one implementation, the proposed method is used to analyze the operating software of a technical system, such as a control device, in terms of potential malware. However, in general, vehicles, vehicle components or control devices, or robots or robot control devices can also be envisioned as technical systems. Furthermore, sensors, particularly embedded sensors, or other embedded systems are considered, for example.

[0056] The operating software for a technical system is hereby understood in particular as a computer program that, when executed on a computing unit, i.e., a control device, causes the computing unit to perform an operation or control method. This operation or control method, when executed, may include, for example, receiving signals or measured values ​​and outputting control signals. If the control device is, for example, an engine control device, the control signal may cause control of a fuel injector or an electric motor.

[0057] The target software, specifically the operating software, will only be used to operate the technical system, i.e., loaded onto the control device, if no harmful behavior is detected using the proposed method. In this way, the operation of the technical system, i.e., the control device and its controlled components (e.g., an engine or vehicle), can be guaranteed, as the presence of malware can be ruled out with at least a high probability. However, it is also conceivable that the target software already used to operate the technical system can be analyzed; if harmful behavior is identified, operation can be stopped, or other measures can be initiated, for example.

[0058] The computing unit, such as a computer or server (which is also, for example, in the so-called cloud), according to the invention is configured, particularly in terms of programming, to perform the method according to the invention.

[0059] It is also advantageous to implement the method according to the invention in the form of a computer program or computer program product containing program code for performing all method steps, as this results in particularly low costs, especially when the control device performing the execution is also used for other tasks and therefore already exists. Finally, a machine-readable storage medium is provided in which the computer program as described above is stored. Suitable storage media or data carriers for providing the computer program are, in particular, magnetic, optical, and electrical memories, such as hard disks, flash memory, EEPROM, DVDs, etc. The program can also be downloaded via a computer network (Internet, intranet, etc.). Such downloads can be made wired or cable-based or wirelessly (e.g., via WLAN networks, 3G, 4G, 5G, or 6G connections, etc.).

[0060] Further advantages and embodiments of the present invention will become apparent from the specification and drawings.

[0061] The present invention is schematically illustrated in the accompanying drawings by way of embodiments, and is described below with reference to the accompanying drawings. Attached Figure Description

[0062] Figure 1 The apparatus in which the present invention can be applied is illustrated schematically.

[0063] Figure 2 The flow of a method in one implementation is illustrated schematically. Detailed Implementation

[0064] Figure 1 The diagram schematically illustrates an apparatus in which the invention can be applied. This apparatus includes, for example, a computing unit 100, a computer or server, and a technical system 104, which may be, for example, a vehicle control device.

[0065] Furthermore, target software or software sample 102 is also shown. In this case, this is particularly true of a computer program that, when executed on a computing unit, or control device 104 in this example, causes the computing unit to perform an operation or control method. This operation or control method, when executed, may include, for example, receiving signals or measurements and outputting control signals. If the control device is, for example, an engine control device, the control signals may cause control of a fuel injector or an electric motor.

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

[0067] Therefore, the software or software sample 102 can be examined first in terms of malware (or, as mentioned above, generally in terms of potential harmful behavior). However, it is also conceivable to analyze the loaded software in terms of potential malware.

[0068] In one implementation, Figure 2 The flowchart of the method is shown in the figure.

[0069] First, target software 200 can be obtained, and then it can be split in step 202 to obtain a decomposition comprising multiple functional blocks. As mentioned above, the representation of this decomposition is here specifically as or using a so-called decomposition-based control flow graph (“Decomposition-based Control Flow Graph”, DCFG). To do this, the target software can be split first, i.e., step 204, and then transformed according to the DCFG, i.e., step 206. Optionally, as previously described, labels 208 for the decomposition or functional blocks of the target software can be provided, i.e., step 210.

[0070] The decomposed parts of the target software, which may be tagged, can then be stored as target software data 212 in, for example, a database 214. This is illustrated here using a DCFS-based decomposition as an example. The target software data 214 can then be provided, i.e., step 216.

[0071] The target software 200 could be, for example, a Python library or library that has been downloaded from a specific source and implements a mathematical library, which has (potentially) been maliciously manipulated to perform a data theft attack. The decomposed component might include functional areas such as structures, numerical representations, matrix multiplication, printing, or outputting the final result. Malicious code may also potentially be contained here.

[0072] Furthermore, malware data 220 containing multiple decomposers can be obtained, i.e., step 218, wherein these decomposers each contain one or more functional blocks obtained or acquired by splitting attack vectors. The malware data 220 can be stored, for example, in a database 222.

[0073] For example, in malware data 220, an entry could be, for instance, a breakdown representing a "data theft" attack vector. This breakdown would then include functional blocks, for example, those for sending local data to a remote server via a communication connection.

[0074] Here, similar to target software data, functional blocks or functional areas (i.e., areas with multiple functional blocks) of malware data can also be marked, i.e., tagged.

[0075] The malware data 220 can then be provided, i.e., step 224.

[0076] Furthermore, multiple comparison tests can be defined, i.e., step 226. For example, three comparison tests 228, 230, and 232 are shown, which together constitute test set 234. Test set 234 can then be stored, for example, in database 238, i.e., step 236, and provided later, i.e., step 240. Each of these comparison tests contains comparison instructions that specify how the target software data should be compared with the corresponding decomposed parts of the malware data.

[0077] In step 242, the target software data is now analyzed. This is based on malware data 220 and the test set of comparison test 234.

[0078] To this end, for example, for each fragment of malware data, each comparison test of the test set is performed, i.e., step 244, to obtain behavioral features for each comparison test. For each fragment of malware data, behavioral vectors containing the corresponding behavioral features are thus determined (i.e., step 246) to obtain a vector set of behavioral vectors.

[0079] Here, for the corresponding decomposer of malware data, an empty behavior vector 250 can be initialized, for example, in step 248. Behavioral features are obtained through each comparison test performed (step 252), and these behavioral features are appended to the behavior vector. After all comparison tests have been performed for the decomposer of malware data, the final behavior vector 254 is obtained. This is performed for each decomposer of malware data, which is represented by repeating step 256.

[0080] Therefore, the behavior vectors form a vector set 258, which is stored in, for example, a database 260.

[0081] Furthermore, several analysis instructions are defined, namely step 262, which together constitute analysis set 264. Three analysis instructions 266, 268, and 270 are shown exemplarily. Analysis set 264 may then be stored, for example, in database 274, namely step 272, and subsequently provided, namely step 276. Each of these analysis instructions specifies how the multiple behavioral vectors should be evaluated against each other.

[0082] Then, the analysis of the target software data further includes: in step 278, analyzing the behavioral vectors of the vector set based on one or more of a plurality of analysis instructions 266, 268, and 270 to obtain intermediate analysis results 280. Based on this, the analysis result data 282 can then be determined.

[0083] An example that can be seen here is, for instance, a math library containing malicious code with the following characteristics. In the matrix multiplication area, the library disables logging, reads variables from a local file, and stores the values ​​of those variables in one of the matrices. This creates a covert channel through which selected (confidential) data can be leaked. In the final result area, the library sends the matrix to a remote server via a network connection.

[0084] Based on the analysis results, the following conclusions can be drawn, for example: It was identified that the target software implemented a covert channel and executed a data theft attack. Both are likely part of the same attack, even if they are located in different areas of the target software. Therefore, the target software utilized the covert channel to execute a data theft attack.

[0085] Then, analysis result data 282, i.e., step 284, can be provided. In step 286, it can be checked whether the target software contains malware. If malware is present, at least if malware has been identified in the target software, information 288 regarding the presence of malware can be provided. For example, an appropriate message can be sent for this purpose.

Claims

1. A method for analyzing target software (102, 200), particularly operating software of a technical system, such as a control device (104), in terms of potential harmful behavior, said method comprising: Provide (216) target software data (212) including decomposed components, wherein the decomposed components include functional blocks, which are obtained by splitting the target software (200) or by splitting the target software (200); Provide (224) malware data (220) comprising multiple decomposers, wherein each decomposer contains one or more of the functional blocks obtained or acquired by splitting attack vectors; A test set (234) is provided for comparison tests (228, 230, 232), wherein each comparison test includes comparison instructions that specify how the target software data should be compared with the corresponding decomposed parts of the malware data; Based on the malware data (220) and the test set (234) of the comparative test, the target software data (212) is analyzed (242) to obtain analysis result data (282); and Provide the analysis results data.

2. The method according to claim 1, wherein analyzing (242) the target software data includes: For at least one, preferably each fragment, of the malware data: perform at least one, preferably each comparison test in the test set (244) to obtain behavioral characteristics for each comparison test. For at least one, preferably each decomposed component of the malware data, a behavior vector containing the corresponding behavioral features is determined (246) to obtain a vector set (258) of behavior vectors (250). The analysis results data are based on the behavioral vectors of the vector set.

3. The method according to claim 2, wherein, The analysis of the target software data also includes: Provides (276) an analysis set (264) comprising one or more analysis instructions (266, 268, 270), wherein each analysis instruction specifies how multiple behavior vectors should be evaluated against each other. The behavior vectors of the vector set are analyzed (278) based on one or more of the plurality of analysis instructions to obtain intermediate analysis results (280). The analysis result data (282) is based on the intermediate analysis results.

4. The method of claim 3, wherein the analysis set includes at least one of the following analysis instructions: - Sort the behavior vectors of the vector set according to a weighting criterion. - Compare the behavior vectors of the vector set with those of similar types of known malware. - Check whether the multiple behavior vectors of the vector set are related to each other.

5. The method according to any one of the preceding claims, wherein the test set includes at least one of the following comparison tests: - Examine how many function blocks containing corresponding decompositions of malware data are included in the decomposition of the target software data, and more precisely, how many function blocks containing corresponding decompositions of malware data are included regardless of the position of the function blocks. - Examine the breakdown of the target software data, and more specifically, how many functional blocks of the corresponding breakdown of the malware data are contained within a functional area. - Examine the number of functional blocks within the decomposed body of the target software data, specifically the number of functional areas containing the corresponding decomposed body of the malware data. - Check the accuracy of the mapping of the order of the functional blocks of the corresponding decomposition of the malware data in the decomposition of the target software data.

6. The method according to any one of the preceding claims, further comprising: If harmful behavior has been identified at least in the target software, information about the existence of harmful behavior is provided (288).

7. The method according to any one of the preceding claims, wherein a machine learning model is used to analyze the target software data.

8. The method according to any one of the preceding claims, wherein the target software is operating software for a technical system, and in, The target software is used to operate the technical system only if the analysis results show that there is no harmful behavior in the target software.

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

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

11. 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 9.

12. A machine-readable storage medium having a computer program as claimed in claim 11 stored thereon.

Images