Method for automatically analyzing a computer program
Patent Information
- Application Number
- DE102023208591
- Authority / Receiving Office
- DE · DE
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2023-09-06
- Publication Date
- 2025-03-06
Smart Images
Figure 00000000_0000_ABST
Abstract
Description
[0001] The present disclosure relates to methods for automatically analyzing a computer program.
[0002] A manufacturer of a programmable device and its associated software is responsible for its proper functioning and must therefore have knowledge of the software it contains and any potential vulnerabilities. However, a corresponding software development team often lacks complete knowledge of the software's source code because they use precompiled third-party program components (e.g., certain program libraries). Therefore, efficient approaches for analyzing software starting from its binary code are desirable.
[0003] The dissertation “Comparison of Compiler's Intermediate Representations and Input / Output Access Patterns with String Kernels” by Raul Ernesto Torres Carvajal, University of Hamburg, 2018, hereinafter referred to as Reference 1, describes the application of string kernel search to compiler intermediate representations.
[0004] According to various embodiments, a method for automatically analyzing a computer program (ie, in particular, determining the program components present in a computer program (to be analyzed) (which is present in a compiled version, ie, binary code)) is provided, comprising: • Generating intermediate representation code comprising a sequence of intermediate representation instructions by decompiling binary code of the computer program; • Generating one or more intermediate representation code strings from the sequence of intermediate representation instructions; • Searching, in the one or more intermediate representation code strings, by means of a string kernel search for reference intermediate representation code strings of a plurality of reference intermediate representation code strings (from a database), where each reference intermediate representation code string belongs to a program component (e.g. a function but possibly also a larger (sub-)program); and • Determining the program components to which the reference intermediate representation code strings found in the one or more intermediate representation code strings belong as the program components present in the computer program.
[0005] The procedure described above enables - the comparison between code compiled by a compiler (binary code) and source code, regardless of the changes made by the compiler at compile time. - finding code similarities even if obfuscation techniques were used during compilation. - The generation of a SBOM (Software Bill of Materials) for a computer program from its binary code. - Finding software vulnerabilities that are stored, for example, in a CVE (Common Vulnerabilities and Exposures) database. - Ensuring the analysis of the final binary code. Since the binary code is used as the test object, all possible vulnerabilities contained in the source code or introduced during compilation due to compiler changes, options, and target architecture influences are included in the analysis by default. This ensures that the analyzed binary code is the one that will be deployed (e.g., included in a shipped product).
[0006] Various examples of implementation are given below.
[0007] Embodiment 1 is a method for automatically analyzing a computer program as described above.
[0008] Embodiment 2 is a method according to embodiment 1, wherein the one or more intermediate representation code strings are a plurality of intermediate representation code strings generated by combining subsequences of the sequence of intermediate representation instructions into program code segments each forming a function, and wherein the reference intermediate representation code strings are searched for in each intermediate representation code string.
[0009] This makes it possible to determine whether a program code segment corresponds to a specific program component and to avoid program components being found incorrectly based on code components that are distributed across several functions in the computer program.
[0010] Embodiment 3 is a method according to embodiment 1 or 2, comprising determining security vulnerabilities of the computer program based on the determined program components and information about security vulnerabilities of the determined program components.
[0011] For example, the program components to which the reference intermediate representation code strings belong can be at least partially marked as program components with security vulnerabilities. Thus, a security check of the computer program can be performed using the method.
[0012] Embodiment 4 is a method according to any one of embodiments 1 to 3, wherein the one or more intermediate representation code strings are generated from the sequence of intermediate representation instructions at least partially by compensating for or considering obfuscation techniques.
[0013] For example, the strings can be generated in a special way by reversing or taking into account obfuscation techniques, so that even obfuscated (partial) sequences of intermediate representation instructions can be assigned to the reference intermediate representation code strings (and thus to the associated program components).
[0014] Embodiment 5 is a method according to one of the embodiments 1 to 4, comprising determining program components missing in the computer program based on the program components determined to be present in the computer program.
[0015] This makes it possible to find security gaps or malfunctions that arise due to missing program components (e.g. error handling functions).
[0016] Embodiment 6 is a method according to one of the embodiments 1 to 5, comprising controlling a robot device with the computer program depending on the program components determined to be present in the computer program corresponding to a predetermined set of required and / or permissible program components.
[0017] This allows safe control to be achieved.
[0018] Embodiment 7 is a software analysis system configured to perform a method according to any one of embodiments 1 to 6.
[0019] Embodiment 8 is a computer program including instructions that, when executed by a processor, cause the processor to perform a method according to any one of embodiments 1 to 6.
[0020] Embodiment 9 is a computer-readable medium storing instructions that, when executed by a processor, cause the processor to perform a method according to any one of embodiments 1 to 6.
[0021] In the drawings, like reference characters generally refer to the same parts throughout the several views. The drawings are not necessarily to scale, emphasis instead generally being placed upon illustrating the principles of the invention. In the following description, various aspects are described with reference to the following drawings. Fig. 1 shows a computer for developing and / or testing software applications. Fig. Figure 2 shows a flowchart for the analysis of a computer program starting from its binary code using binary lifting and subsequent string kernel search. Fig. 3 shows a flowchart illustrating a method for automatically analyzing a computer program according to one embodiment.
[0022] The following detailed description refers to the accompanying drawings, which, by way of illustration, show specific details and aspects of this disclosure in which the invention may be practiced. Other aspects may be utilized, and structural, logical, and electrical changes may be made without departing from the scope of the invention. The various aspects of this disclosure are not necessarily mutually exclusive, as some aspects of this disclosure may be combined with one or more other aspects of this disclosure to form new aspects.
[0023] Various examples are described in more detail below.
[0024] Fig. 1 shows a computer 100 for developing and / or testing software applications.
[0025] The computer 100 has a CPU (Central Processing Unit) 101 and a random access memory (RAM) 102. The RAM 102 is used to load program code, e.g., from a hard disk 103, and the CPU 101 executes the program code.
[0026] In this example, it is assumed that a user (developer) intends to develop and / or test a software application using the computer 100.
[0027] To do this, the user executes a software development environment 104 on the CPU 101.
[0028] The software development environment 104 enables the user to develop and test an application (i.e., software) 105 for various devices 106, i.e., target hardware, such as embedded systems for controlling robotic devices, including robot arms and autonomous vehicles, or even for mobile (communication) devices. For this purpose, the CPU 101, as part of the software development environment 104, can execute an emulator to simulate the behavior of the respective device 106 for which an application is or was developed. If it is used only for testing software from another source, the software development environment 104 can also be viewed or configured as a software test environment.
[0029] The user can distribute the finished application to corresponding devices 106 via a communications network 107. Instead of via a communications network 107, this can also be done in another way, for example, using a USB stick.
[0030] Before this happens, however, the user should be aware of potential security vulnerabilities in the application 105 to avoid distributing an insecure, functioning application to the devices 106. This can also be the case if the user did not write the application 105 themselves, at least in part (but, for example, adopted program components from third-party providers, e.g., libraries). For a Tier-1 supplier of an application (or a device with associated software), the application consists, for example, of its own code (the supplier's), OSS (Open Source Software) components, and precompiled libraries from third-party providers. In particular, it can happen that the user does not have the source code of the (entire) application, but only its executable code (i.e., the binary program), i.e., that the application (computer program) 105 is (at least partially) a black-box computer program from the tester's perspective.
[0031] In the event that the user (or a respective development team) did not (completely) write the application 105 themselves, the starting point for the security check is the binary code of a computer program. According to various embodiments, an approach is described that enables an analysis, particularly with regard to its security (which may also depend on whether all intended program components are present), starting from binary code.
[0032] The starting point for the analysis is thus compiled code, which, according to one embodiment, is reduced to its intermediate representation by binary lifting (this can be viewed as part of reverse engineering). The intermediate representation is then converted into a character string. Finally, string kernel comparison algorithms are applied to find similarities between the generated string and, for example, a local (string) database containing strings of reference program code. The reference program code can be viewed as the program code of a program library (where this can include source code from publicly available libraries, commercial libraries, or even program code previously written by the respective user (or a user group to which the user belongs)).
[0033] With this approach, code similarities (between the binary code and the database) are found even if the compiler made changes during compilation. Even if the source code was compiled for different architectures and optimization settings and obfuscation techniques were applied, string kernel pattern matching is capable of finding similarities between the binary code strings generated from the intermediate representation and the strings from the string database. Applying this string kernel approach can detect whether certain code snippets or library functions are part of the analyzed binary files, for example, to facilitate security and vulnerability management through the creation of a Software Bill of Materials (SBOM).Furthermore, malware analysis can be performed by comparing the generated strings with known software that has been reported as vulnerable. For example, strings corresponding to code contained in the (open) CVE (Common Vulnerabilities and Exposures) database can be added to the string database.
[0034] Some of the terms used herein are explained below: - Binary lifting is the technique of translating machine instructions into an intermediate representation. - Reverse engineering involves discovering the components and functionality of a program. The original software is reconstructed by analyzing the compiled code. Hackers use this technique to find vulnerabilities. - Code obfuscation refers to a set of techniques used to improve code security by hiding implicit values and obfuscating logic, making it more difficult to reverse engineer the compiled software and recover the original source code. - Obfuscation techniques are applied to the following areas of code: data, control flow and layout structure. - The intermediate representation acts as the central data structure of a compiler. Optimizations and analyses are applied to it. Intermediate representations thus serve as a connection point between the frontend and backend of the compiler. - The compiler's purpose is to generate machine code from the source code. The compiler's frontend takes the source code as input and creates an intermediate representation. This intermediate representation is then passed to the backend, which generates the target code (binary code) as the final result. - String kernels represent tree-like data structures that are treated as a set of consecutive weighted tokens. - The Software Bill of Materials (SBOM) for a program (i.e., a piece of software) is a list of third-party and open-source components that are part of the program code. SBOMs also contain licenses for these components, the component version used in the code, and the corresponding patch status.
[0035] According to various embodiments, as mentioned above, string kernel comparison methods (in the area of code similarity) are applied to generate an SBOM (e.g., complete, at least with regard to the list of program components) of a program from its binary code. This allows the security management of the program to be improved and automated.
[0036] Most third-party software components (i.e., "external" program components) are delivered as binary code, so a developer or development team does not have access to the source code. Even within a manufacturer, software libraries (i.e., "internal" program components) can be transferred from one software management system to another without proper tracking. External software components are difficult to correctly identify and assign vulnerabilities to, but the same may be true for internal software components as well.
[0037] The approach described here enables the search for vulnerabilities in binary code without external support, thus improving the knowledge of risks associated with the software and its security management. Furthermore, a developer can identify whether and which parts are missing from a deployed SBOM. String kernel searches allow for a certain degree of fuzzy search for software components (especially source code components) starting from compiled binaries.
[0038] Fig. Figure 2 shows a flowchart for the analysis of a computer program starting from its binary code using binary lifting and subsequent string kernel search.
[0039] The starting point is binary code (e.g., a compiled binary file) 201 of a program under investigation, which is lifted to lifted binary code 202 using binary lifting. Based on the lifted binary code 202, an intermediate representation (IR) 203 can be generated. Character strings 204 are generated from these two sources (IR 203 and / or lifted binary code 202).
[0040] This generation of character strings is also performed for program components that are to be detected in the compiled binary file 201 (if they are present therein), i.e., a program code database in string form 205 is generated. The set of program code for which the program code database 205 contains strings can be viewed as a program library (which contains software components (e.g., subprograms, functions, etc.) that are to be detected for an SBOM of the binary code therein, or known malicious program components or program components with vulnerabilities that are to be detected for security analysis of the binary code therein).The strings for the program code database 205 can be generated from binary code of program components for which the program code database 205 is to contain strings, in the same way as for the binary file 201 (or alternatively from the source code of the respective program component, if known). For example, known suspicious source code can be converted directly into an IR and strings, or it can be compiled first and further analyzed from there (i.e., for example, strings can be generated for it analogously to the binary file 201).
[0041] Kernels can now be used to search for program components in the program to be examined, for which the program code database 205 contains strings, using kernel search 206.
[0042] Thanks to the fuzziness of the approach provided by kernel search, it is possible, for example, to find comparable vulnerable code in binary file 201 for known program components with vulnerabilities (for which the program code database contains 205 strings).
[0043] The results 207 of the kernel search 206 can be used in many ways, e.g. • To generate an SBOM for the program under test: Even if there is no access to its source code, known program components (e.g. from third-party software libraries) can be identified and listed. • To find vulnerable code segments based on internal and external program components (e.g., code snippets) for which strings are contained in the database 205, even if code from third-party libraries has been reused for the program under test or internal libraries (e.g., program components from the same vendor as the program under test) have been transferred and renamed between code databases. • Identification of obfuscation: The fuzziness of the string kernel search makes it possible to identify program components from the database 205 even for certain classes of obfuscation.
[0044] The following is a simple example of processing according to Fig. 2 is specified.
[0045] The source code of the program to be examined is #include in this example<stdio.h> int loop(int i) { for(int a=0; a < i ; a++){ printf("%d \n",a);}} int main() { printf("Start IDA Tracing\n"); int i=2; / / change this to increase or decrease the trace size int x=loop(i); printf("Stop IDA Tracing\n"); return 0;}
[0046] The binary code 201 of this program is
[0047] The lifted binary code 202 is:
[0048] The generation of the lifted binary code 202 particularly comprises decompiling the binary code 201, thereby generating a sequence of intermediate representation instructions. The lifted binary code 202 specifies which values refer to memory addresses and which to instructions, as well as which areas of the binary code 201 together form a function. For this purpose, intermediate representation instructions of subsequences of the sequence of intermediate representation instructions are grouped into program code segments, each of which forms a function.
[0049] The intermediate representation 203 (in this example p-code) has the form
[0050] A string kernel search can now be applied to the intermediate representation 203, as described, for example, in Reference 1.
[0051] One or more strings are generated from the intermediate representation 203, for example via an intermediate step (grouping several characters into “tokens”, ie the strings are then chains of such tokens, which in turn are (short) character strings).
[0052] If the program to be examined is given to the program database 205 in string form, the string kernel search searches for the longest strings that are contained both in the program to be examined and in the program database 205.
[0053] The number of such common substrings between the program to be examined and a program component in string form in the program database 205 can be used as a similarity measure and then it can be determined (e.g. by a comparison with a threshold value) whether the program component is contained in the program to be examined or not.
[0054] Tokens can be assigned weights and the parameter “cut weight” specifies the minimum weight that such common substrings must have to be considered.
[0055] The search is carried out, for example, per program code segment, ie for each program code segment identified in the lifted binary code 202 or in the intermediate representation 203, a similarity to program code segments stored in the program database 205 in string form is determined and, depending on the similarity, a decision is made as to whether this program component (as a program code segment) is contained in the program to be examined or not.
[0056] The intermediate representation code strings from the sequence of intermediate representation instructions can be generated at least partially by compensating for obfuscation techniques. For example, the strings can be generated in a special way by reversing or taking obfuscation techniques into account, so that even obfuscated (partial) sequences of intermediate representation instructions can be assigned to the reference intermediate representation code strings (and thus to the associated program components).
[0057] The following table shows an example of this in intermediate representation code. Original-Code verschleierter Code .model small .model small .code .code Mov AH, 2 Mov AH, 2 Mov DL, 65 Mov DL, 65 Mov BL, 70 Mov BL, 70 L1: Int 21h L1: Int 21h Add DL, 1 Add DL, 1 Cmp DL, BL Add BL, 185 JLE L1 JNC L1 Mov AH, 76 Mov AH, 76 Int 21h Int 21h end end
[0058] Although the obfuscated code is different from the original code, the approach described above can find it because string kernel search does not search for code one-to-one, but rather looks for similarities.
[0059] For example, the strings could be generated in such a way that not mnemonics are used as tokens (here, for example, JLE and JNC), but classes of commands (here, for example, the class “Jump”).
[0060] In summary, according to various embodiments, a method is provided as described in Fig. 3 shown.
[0061] Fig. 3 shows a flowchart 300 illustrating a method for automatically analyzing a computer program (ie, in particular, determining the program components present in a computer program (to be analyzed) (which is present in a compiled version, ie, binary code)) according to one embodiment.
[0062] In 301, intermediate representation code with a sequence of intermediate representation instructions is generated by decompiling the binary code of the computer program (to be analyzed). The intermediate representation code can be generated, for example, from the binary code by first decompiling it into assembly instructions and then generating the intermediate representation code (e.g., p-code) from it by binary lifting.
[0063] At 302, one or more intermediate representation code strings are generated from the sequence of intermediate representation instructions. This is done, for example, by generating a control flow graph (call graph) and, based thereon, generating tokens (e.g., one token per node of the control flow graph) and generating intermediate representation code strings from the tokens.
[0064] In 303, a string kernel search is carried out in the one or more intermediate representation code strings for reference intermediate representation code strings of a plurality of reference intermediate representation code strings (from a database), wherein each reference intermediate representation code string belongs to a program component (e.g., a function but possibly also a larger (sub-)program).
[0065] In 304, the program components to which the reference intermediate representation code strings belong that were found in the one or more intermediate representation code strings by means of the string kernel comparison are determined as the program components present in the computer program.
[0066] The procedure of Fig. 3 can be performed by one or more computers having one or more data processing units. The term “data processing unit” can be understood as any type of entity that enables the processing of data or signals. The data or signals can, for example, be treated according to at least one (i.e., one or more than one) specific function performed by the data processing unit. A data processing unit can comprise or be formed from an analog circuit, a digital circuit, a logic circuit, a microprocessor, a microcontroller, a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), a programmable gate array (FPGA) integrated circuit, or any combination thereof.Any other way of implementing the respective functions described in more detail herein may also be understood as a data processing unit or logic circuit arrangement. One or more of the method steps described in detail herein may be performed (e.g., implemented) by a data processing unit through one or more specific functions performed by the data processing unit.
[0067] In particular, the method is computer-implemented according to various embodiments.
[0068] The approach of Fig. 3 is used to analyze a program (e.g., for vulnerabilities), such as control software for a robotic device. The term "robotic device" can be understood as referring to any technical system, such as a computer-controlled machine, a vehicle, a household appliance, a power tool, a manufacturing machine, a personal assistant, or an access control system. The control software can also be used for data processing systems, such as a navigation device.
[0069] The procedure of Fig. 3 is, for example, by a test arrangement (e.g. computer 100 and target device 106 of Fig. 1) was carried out. QUOTES CONTAINED IN THE DESCRIPTION
[0000] This list of documents submitted by the applicant was generated automatically and is included solely for the convenience of the reader. This list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions. Cited non-patent literature
[0000] Comparison of Compiler's Intermediate Representations and Input / Output Access Patterns with String Kernels" by Raul Ernesto Torres Carvajal, University of Hamburg, 2018
[0003]
Claims
[1] A method for automatically analyzing a computer program (105), comprising: Generating (301) intermediate representation code having a sequence of intermediate representation instructions by decompiling binary code (201) of the computer program (105); generating (302) one or more intermediate representation code strings (204) from the sequence of intermediate representation instructions; Searching (303) in the one or more intermediate representation code strings (204) by means of a string kernel search (206) for reference intermediate representation code strings of a plurality of reference intermediate representation code strings, each reference intermediate representation code string belonging to a program component; and Determining (304) the program components to which the reference intermediate representation code strings belong that were found in the one or more intermediate representation code strings (204) by means of the string kernel comparison as the program components present in the computer program (105). [2] The method of claim 1, wherein the one or more intermediate representation code strings (204) are a plurality of intermediate representation code strings (204) generated by combining subsequences of the sequence of intermediate representation instructions into program code segments each forming a function, and wherein the reference intermediate representation code strings are searched for in each intermediate representation code string. [3] Method according to claim 1 or 2, comprising determining security gaps in the computer program (105) based on the determined program components and information about security gaps in the determined program components. [4] The method of any one of claims 1 to 3, wherein the one or more intermediate representation code strings (204) are generated from the sequence of intermediate representation instructions at least partially by compensating for or taking into account obfuscation techniques. [5] Method according to one of claims 1 to 4, comprising determining program components missing in the computer program (105) on the basis of the program components determined to be present in the computer program. [6] Method according to one of claims 1 to 5, comprising controlling a robot device with the computer program (105) depending on the program components determined to be present in the computer program (105) corresponding to a predetermined set of required and / or permissible program components. [7] Software analysis system (100) configured to perform a method according to any one of claims 1 to 6. [8] A computer program comprising instructions which, when executed by a processor, cause the processor to perform a method according to any one of claims 1 to 6. [9] A computer-readable medium storing instructions which, when executed by a processor, cause the processor to perform a method according to any one of claims 1 to 6.