A binary file symbol table-based application software compatibility detection method

Abstract

The application relates to a binary file symbol table-based application software compatibility detection method and belongs to the technical field of testing. The method comprises the following steps: analyzing a symbol table of a binary reference file, obtaining a reference symbol of application software, introducing an intermediary module, modifying a native application software binary file reference symbol table, generating a new binary file, capturing a reference symbol call record through the intermediary module during dynamic testing of the software, forming a comparison benchmark, and detecting and judging the compatibility of the application program and other versions of operating systems based on the comparison benchmark. The application can judge the compatibility of the application software and the library package of the operating system, and provides a reliable testing method for the user to test the compatibility of the application software and the library package of the operating system based on static testing.

Description

Technical Field

[0001] This invention belongs to the field of testing technology, specifically relating to an application software compatibility testing method based on a binary file symbol table. Background Technology

[0002] Currently, the main method for determining the compatibility of application software with domestic operating systems is to test each function of the application software. This testing focuses on dynamic functional testing, which is labor-intensive and complex. With the increasing complexity and variety of operating system and platform combinations, the workload of compatibility testing will grow with the number of combinations. Static compatibility testing, on the other hand, focuses primarily on the API call interface, offering the advantages of automated testing, eliminating reliance on manual intervention, and ensuring the sufficiency of the tests. Determining application software compatibility through API referencing mainly involves two parts: 1. Whether the functions required by the application software are provided on the operating system; 2. Whether the application software correctly calls the referenced function symbols. Under Linux, the symbol table can be obtained from the ELF file header, and specific symbol identifiers in the symbol table can be parsed to accurately obtain the application software's referenced symbol table and the symbols provided by the operating system. However, simply comparing the application software's referenced symbol list with the symbols provided by the operating system only determines the presence or absence of symbols, ensuring correct linking. It cannot determine whether the parameter information of the referenced symbols is correct, thus failing to further determine whether the application software can run normally. Therefore, it is necessary to obtain a reliable comparison benchmark based on dynamic testing, capturing and recording the referenced symbol information when the application software executes correctly, and using this as a benchmark to calibrate subsequent static tests.

[0003] This invention proposes an application software compatibility detection and judgment method based on parsing binary file symbol tables. First, the binary file symbol table is parsed to obtain the reference function symbols of the application software, which are then compared with the function symbols provided by the operating system. The core step is to introduce an intermediary module into the binary executable file of the application software on an already adapted operating system. During the dynamic execution of the software, the reference symbol call records are captured as a comparison benchmark. This allows the application software to determine its compatibility with the operating system without having to repeat dynamic testing on new versions of the operating system.

[0004] The basic technical principle is as follows: The binary executable file (hereinafter referred to as the binary file) obtained after unpacking the benchmark application software is modified. The reference symbols dependent on the ELF symbol table of the binary file are modified, such as changing `sig` to `sig_1`. Simultaneously, a new binary intermediary library is generated. This intermediary library provides all modified application reference symbols, such as `sig_1` and `XXX_1`, and is added to the dependency library table of the newly generated binary file. During the execution of the new binary file, when reference symbols are called, they will be called through the intermediary library. The intermediary library records and exports call logs, thereby capturing all reference symbols called during the dynamic testing of the application software, and continuing to call the original function symbols provided by the operating system. If the application software file remains unchanged, the reference function symbols called by the application software will remain unchanged. Therefore, based on the test results, all reference symbols dependent on the application software's dynamic testing process on the new operating system version can be determined, eliminating the need for repeated testing and accurately determining application software compatibility. Summary of the Invention

[0005] (a) Technical problems to be solved

[0006] The technical problem to be solved by this invention is how to provide an application software compatibility detection method based on a binary file symbol table, which has been solved.

[0007] (II) Technical Solution

[0008] To address the aforementioned technical problems, this invention proposes an application software compatibility detection method based on a binary file symbol table, which includes the following steps:

[0009] S1, Analysis Application Software

[0010] Parse the binary files in the application software installation package to obtain the libraries and symbol tables that the application software depends on;

[0011] S2, Scan target operating system

[0012] The system scans the operating system to obtain basic information and traverses and parses the directories used by the operating system to store dynamic libraries, automatically obtaining all libraries and symbol tables of the operating system.

[0013] S3. Obtain application software compatibility comparison benchmarks.

[0014] Obtaining a benchmark involves three steps:

[0015] S31. On an operating system where the application software has been adapted, perform the operation of parsing the application software to obtain the libraries and reference symbols that the application software depends on.

[0016] S32. Modify the application software binary file based on the reference symbol table obtained by parsing: Modify the reference symbols that the application software depends on, generate new symbol names as intermediate symbols, replace the reference symbols called in the binary file with the intermediate symbols, generate a new application software binary file, and at the same time generate an intermediate link library. This library provides all the intermediate symbols that the newly generated binary file depends on, and records the intermediate symbol calling process through code when each intermediate symbol is called, thereby realizing the monitoring of the reference symbol calling process during the operation of the application software without affecting the functional behavior;

[0017] S33. Perform dynamic testing on the modified application software, record the symbol call process during the dynamic testing process, and based on the call process list, disassemble and parse the binary file to obtain the referenced symbol name, symbol code segment hash value and number of parameters, and complete the creation of the baseline symbol table.

[0018] S4. Compare symbol information based on the benchmark.

[0019] By parsing the reference symbol table of the application software to be tested, and combining it with the target operating system symbol table and the baseline symbol table, the application software compatibility dependency information is compared by determining whether the reference symbols that the application software depends on exist on the target operating system and whether they can run normally.

[0020] S5. Determine software compatibility.

[0021] Based on the feedback of the S4 comparison information and referring to the application software compatibility judgment rules, the application software compatibility judgment conclusions are drawn, including: application software dependency libraries are incompatible, application software reference symbols are incompatible, application software library package-level compatibility, and application software compatibility.

[0022] Further, step S1 specifically includes: using a script program to automatically parse the installation package according to different operating system architectures and different software package formats, obtaining symbol table information from the binary files in the installation package, traversing and selecting symbols in the symbol table, obtaining reference symbols, thereby obtaining the libraries and reference symbol tables that the application software depends on.

[0023] Furthermore, the information obtained from parsing the application software is stored in a JSON file.

[0024] Furthermore, in step S2, the basic information includes the operating system name and architecture.

[0025] Further, step S2 specifically includes: firstly, parsing the operating system environment variables and dynamic library configuration files under / etc to obtain the operating system's dynamic library access directory; secondly, scanning the obtained dynamic library storage directory and special directories of the operating system, and judging the files therein to obtain a dynamic library list; traversing the dynamic library list, parsing each dynamic library in the dynamic library list in turn to obtain all libraries and symbol tables provided by the current operating system.

[0026] Furthermore, the operating system information obtained in step S2 is stored as a JSON file.

[0027] Furthermore, in step S32, any binary executable file of the application software to be monitored is modified to generate a new executable file and an intermediate link library; the direct API call of the executable file to the third-party library is transformed into an API call of the executable file to the intermediate link library using the dynamic linking mechanism provided by the operating system; then the intermediate link library makes API calls to the third-party library; and the API call record is captured when the intermediate link library makes API calls, and the baseline information of the record is recorded.

[0028] Further, step S4 specifically includes: generating a reference symbol table D for the application software to be tested by parsing the application software, and obtaining an intersection symbol table G = D ∩ J by dynamically testing and capturing a baseline symbol table J on other adapted versions. This intersection symbol table contains the reference symbols that the application software depends on when running on the operating system to be tested, and the reference symbols in this table have all been verified to be functionally correct by baseline combination. Once it is confirmed that table G is a subset of the symbol table M provided by the target operating system, the comparison can be completed.

[0029] Further, step S5 specifically includes: providing compatibility test results based on different comparison items between the application software and the target operating system. The comparison items include: presence or absence of dependent libraries, presence or absence of reference symbols, and correctness of benchmark judgment symbol parameters; the following compatibility types exist: application software dependent library incompatibility, application software reference symbol incompatibility, application software library package-level compatibility, and application software compatibility.

[0030] Furthermore, application software dependency library incompatibility means that the target operating system does not have the dependency libraries required by the application software; application software reference symbol incompatibility means that the target operating system has the dependency library packages required by the application software, but the reference symbols that the application software depends on are missing; application software library package-level compatibility means that the target operating system has all the dependency libraries and reference symbols required by the application software, but a comparison with the baseline symbol table has not been performed or has not passed; application software compatibility means that the target operating system has all the dependency libraries and reference symbols required by the application software, and a comparison with the baseline symbol table has passed, that is, the target operating system satisfies the presence or absence of application software library packages and reference symbols and verifies the correctness of the reference symbol functions, thus concluding that the application software is compatible.

[0031] (III) Beneficial Effects

[0032] This invention proposes an application software compatibility detection method based on binary file symbol tables. This method for determining application software compatibility based on parsing binary file symbol tables has the following characteristics:

[0033] 1) A method is provided to monitor the application interface call process under a domestic operating system. The application binary executable file is modified to generate a new binary file, and the system API calls are captured by calling an intermediary library, so as not to affect the normal operation of the application.

[0034] 2) A static detection and judgment method for application software compatibility based on a benchmark symbol table is presented, which can improve the efficiency and sufficiency of static testing and verification of software compatibility. Attached Figure Description

[0035] Figure 1 This is a flowchart of the application software compatibility detection method based on binary file symbol tables according to the present invention. Detailed Implementation

[0036] To make the objectives, contents, and advantages of the present invention clearer, the specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples.

[0037] This invention belongs to the field of testing technology. It mainly addresses the problem of the large number of domestic operating system types and rapid version changes, as well as the large workload of application software compatibility testing. It provides a method for application software compatibility detection and judgment based on parsing the binary file reference symbol table.

[0038] This invention provides a static compatibility testing method for application software by parsing the symbol table of a binary file. This method parses the symbol table of the binary reference file to obtain the reference symbols of the application software. By introducing an intermediary module and modifying the original binary file reference symbol table, a new binary file is generated. During dynamic testing of the software, the intermediary module captures the reference symbol call records, forming a comparison benchmark. Based on this benchmark, the compatibility of the application with other versions of the operating system is tested and determined. This method can record the library package and reference symbol call process of the application without affecting the operation of the target application, forming a static comparison benchmark based on the normal behavior of the application software and the library package call process. It enables the acquisition of a static test comparison benchmark after a single dynamic test of application software compatibility on a certain operating system. This allows for the determination of library package compatibility between the application software and the operating system on subsequent operating system versions without repeating dynamic testing. The method provides users with a reliable testing method for application software and operating system library package compatibility based on static analysis.

[0039] To address the challenges of testing application software compatibility with the numerous types and versions of domestically produced operating systems, this invention employs the following methods and steps to implement an application software compatibility determination method: First, parse the application software; second, scan the target operating system; third, obtain a benchmark and parse the reference symbol information within the benchmark; fourth, compare the reference symbol information based on the benchmark; fifth, perform compatibility testing and determination for the referenced software. Obtaining the benchmark involves three steps: first, parse the application software used as the benchmark; second, introduce an intermediary module; and third, dynamically test and obtain the reference symbol table of the benchmark application software.

[0040] The purpose of this invention is to provide a method for application software compatibility detection and judgment based on parsing binary file symbol tables, thereby solving the problem of low accuracy in static application software compatibility judgment results under current domestic operating systems.

[0041] S1, Analysis Application Software

[0042] Parsing the binary files in the application software installation package reveals the libraries and symbol tables that the application software depends on. For any application software, analyzing its compatibility with the target operating system requires obtaining its dependent libraries. Whether the operating system provides the APIs that the software actually calls at runtime is key to determining the application software's compatibility with the target operating system.

[0043] S2, Scan target operating system

[0044] The system scans the operating system to obtain basic information such as its name and architecture. It also traverses and parses the directories used by the operating system to store dynamic libraries, automatically obtaining all the operating system's libraries and API symbol tables.

[0045] S3. Obtain application software compatibility comparison benchmarks.

[0046] Obtaining a benchmark involves three steps:

[0047] S31. First, on an operating system where the application software has been adapted, perform the operation of parsing the application software to obtain the libraries and reference symbol functions that the application software depends on.

[0048] S32. Secondly, the application software binary file is modified based on the reference symbol table obtained through parsing: the reference symbols that the application software depends on are modified to generate new symbol names as intermediary symbols, such as: sig is modified to sig_1; the intermediary symbols are used to replace the reference symbols called in the binary file to generate a new application software binary file. At the same time, an intermediary link library is generated. This library provides all the intermediary symbols that the newly generated binary file depends on, and records the intermediary symbol call process through code when each intermediary symbol is called, thereby realizing the monitoring of the reference symbol call process during the operation of the application software without affecting the functional behavior.

[0049] S33. Perform dynamic testing on the modified application software, record the symbol call process during the dynamic testing process, and based on the call process list, disassemble and parse the binary file to obtain information such as the referenced symbol name, symbol code segment hash value, and number of parameters, and complete the creation of the baseline symbol table.

[0050] S4. Compare symbol information based on the benchmark.

[0051] By parsing the symbol table of the application software to be tested, and combining it with the symbol table of the target operating system and the baseline symbol table, the system compares the application software compatibility dependency information by determining whether the reference symbols that the application software depends on exist on the target operating system and whether they can run normally.

[0052] S5. Determine software compatibility.

[0053] Based on the feedback of the S4 comparison information and referring to the application software compatibility judgment rules, the application software compatibility judgment conclusions are drawn, including: application software dependency libraries are incompatible, application software reference symbols are incompatible, application software library package-level compatibility, and application software compatibility.

[0054] The specific implementation steps of the application software compatibility determination method based on parsing binary file symbol tables are as follows:

[0055] Step 1: Analyze the application software

[0056] The script automatically parses the installation package based on different operating system architectures and software package formats, retrieves symbol table information from the binary files in the installation package, iterates through and selects symbols in the symbol table to obtain referenced symbols, thereby obtaining the libraries that the application software depends on and the API symbol tables it references.

[0057] The information obtained from parsing the application software is stored in a JSON file for easy comparison and processing later, as shown below:

[0058]

[0059]

[0060]

[0061] Step 2: Scan the target operating system

[0062] First, the operating system environment variables and dynamic library configuration files under / etc are parsed to obtain the operating system's dynamic library access directories. Second, the obtained dynamic library storage directories and special operating system directories such as / lib and / usr / lib are scanned, and the files in them are judged to obtain a list of dynamic libraries. The dynamic library list is traversed, and each dynamic library in the list is parsed in turn to obtain all the libraries provided by the current operating system and related APIs.

[0063] The obtained operating system information is stored in a JSON file, as shown below:

[0064]

[0065]

[0066] The third step is to obtain the reference and parse the symbol information in the reference.

[0067] Obtaining the benchmark is divided into three parts.

[0068] Part 1: Analyzing the binary files in the benchmark application software installation package.

[0069] Part Two: Modify any binary executable file of the application software to be monitored (hereinafter referred to as the executable file) to generate a new executable file and an intermediary link library. Utilize the dynamic linking mechanism (address translation and binding) provided by the operating system to transform the executable file's direct API calls to third-party libraries into API calls from the executable file to the intermediary link library, which then makes API calls to the third-party libraries. Capture API call records when the intermediary link library calls the API; the basic information format of the records is as follows:

[0070]

[0071]

[0072] The fourth step is to compare the symbol information based on the benchmark.

[0073] By parsing the application software to generate the reference symbol table D of the application software to be tested, and comparing it with the benchmark symbol table J captured by dynamic testing on other adapted versions, an intersection symbol table G = D ∩ J is obtained. This intersection symbol table contains the reference symbols that the application software depends on to run on the operating system to be tested, and the reference symbols in this table have all been verified to be functionally correct by benchmark combination. Therefore, it is only necessary to confirm that table G is a subset of the symbol table M provided by the target operating system to complete the comparison.

[0074] Step 5: Determine software compatibility

[0075] Compatibility test results are provided based on different comparison items between the application software and the target operating system. These comparison items include: presence or absence of dependent libraries, presence or absence of reference symbols, and correctness of baseline judgment symbol parameters. The following compatibility types exist: application software dependency library incompatibility, application software reference symbol incompatibility, application software library package-level compatibility, and application software compatibility. Figure 1 The comparison process and results are shown.

[0076] Application software dependency library incompatibility: The required dependency libraries for the application software do not exist on the target operating system;

[0077] Application software reference symbols incompatibility: The target operating system contains the dependency library packages required by the application software, but there are missing reference symbols for the application software's dependencies.

[0078] Application library package-level compatibility: The target operating system contains all the dependency libraries and reference symbols required by the application software, but a comparison with the baseline symbol table has not been performed or passed.

[0079] Application software compatibility: The target operating system contains all the dependency libraries and reference symbols required by the application software. The comparison with the benchmark symbol table confirms the presence or absence of the application software library packages and reference symbols on the target operating system and verifies the correctness of the reference symbol functions, thus concluding that the application software is compatible.

[0080] The application software compatibility detection and judgment method based on parsing binary file symbol tables of the present invention has the following characteristics:

[0081] 1) A method is provided to monitor the application interface call process under a domestic operating system. The application binary executable file is modified to generate a new binary file, and the system API calls are captured by calling an intermediary library, so as not to affect the normal operation of the application.

[0082] 2) A static detection and judgment method for application software compatibility based on a benchmark symbol table is presented, which can improve the efficiency and sufficiency of static testing and verification of software compatibility.

[0083] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the technical principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for application software compatibility testing based on binary file symbol tables, characterized in that, The method includes the following steps: S1, Analysis Application Software Parse the binary files in the application software installation package to obtain the libraries and symbol tables that the application software depends on; S2, Scan the target operating system The system scans the operating system to obtain basic information and traverses and parses the directories used by the operating system to store dynamic libraries, automatically obtaining all libraries and symbol tables of the operating system. S3. Obtain application software compatibility comparison benchmarks. Obtaining a benchmark involves three steps: S31. On an operating system where the application software has been adapted, perform the operation of parsing the application software to obtain the libraries and reference symbols that the application software depends on. S32. Modify the application software binary file based on the reference symbol table obtained by parsing: Modify the reference symbols that the application software depends on, generate new symbol names as intermediate symbols, replace the reference symbols called in the binary file with the intermediate symbols, generate a new application software binary file, and at the same time, generate an intermediate link library. This library provides all the intermediate symbols that the newly generated binary file depends on, and records the intermediate symbol calling process through code when each intermediate symbol is called, thereby realizing the monitoring of the reference symbol calling process during the operation of the application software without affecting the functional behavior; S33. Perform dynamic testing on the modified application software, record the symbol call process during the dynamic testing process, and based on the call process list, disassemble and parse the binary file to obtain the referenced symbol name, symbol code segment hash value and number of parameters, and complete the creation of the baseline symbol table. S4. Compare symbol information based on the benchmark. By parsing the reference symbol table of the application software to be tested, and combining it with the target operating system symbol table and the baseline symbol table, the application software compatibility dependency information is compared by determining whether the reference symbols that the application software depends on exist on the target operating system and whether they can run normally. S5. Determine software compatibility. Based on the feedback of the S4 comparison information and referring to the application software compatibility judgment rules, the application software compatibility judgment conclusions are drawn, including: application software dependency libraries are incompatible, application software reference symbols are incompatible, application software library package-level compatibility, and application software compatibility.

2. The application software compatibility detection method based on binary file symbol tables as described in claim 1, characterized in that, Step S1 specifically includes: using a script program to automatically parse the installation package according to different operating system architectures and different software package formats, obtaining symbol table information from the binary files in the installation package, traversing and selecting symbols in the symbol table, obtaining reference symbols, thereby obtaining the libraries and reference symbol tables that the application software depends on.

3. The application software compatibility detection method based on binary file symbol tables as described in claim 2, characterized in that, The information obtained from parsing the application software is stored in a JSON file.

4. The application software compatibility detection method based on binary file symbol tables as described in claim 1, characterized in that, In step S2, the basic information includes the operating system name and architecture.

5. The application software compatibility detection method based on binary file symbol tables as described in claim 1, characterized in that, Step S2 specifically includes: first, parsing the operating system environment variables and dynamic library configuration files under / etc to obtain the operating system's dynamic library access directory; second, scanning the obtained dynamic library storage directory and special directories of the operating system, and judging the files in them to obtain a dynamic library list; traversing the dynamic library list, parsing each dynamic library in the dynamic library list in turn to obtain all libraries and symbol tables provided by the current operating system.

6. The application software compatibility detection method based on binary file symbol tables as described in claim 5, characterized in that, The operating system information obtained in step S2 is stored in a JSON file.

7. The application software compatibility detection method based on binary file symbol tables as described in claim 1, characterized in that, In step S32, any binary executable file of the application software to be monitored is modified to generate a new executable file and an intermediate link library; the direct API call of the executable file to the third-party library is transformed into an API call of the executable file to the intermediate link library using the dynamic linking mechanism provided by the operating system; then the intermediate link library makes API calls to the third-party library; and the API call record is captured when the intermediate link library makes API calls, and the baseline information of the record is recorded.

8. The application software compatibility detection method based on binary file symbol tables as described in any one of claims 1-7, characterized in that, Step S4 specifically includes: generating a reference symbol table D for the application software to be tested by parsing the application software, and obtaining an intersection symbol table G = D ∩ J by dynamically testing and capturing a baseline symbol table J on other adapted versions. This intersection symbol table contains the reference symbols that the application software depends on when running on the operating system to be tested, and the reference symbols in this table have all been verified to be functionally correct by baseline combination. Once it is confirmed that table G is a subset of the symbol table M provided by the target operating system, the comparison can be completed.

9. The application software compatibility detection method based on binary file symbol tables as described in claim 8, characterized in that, Step S5 specifically includes: providing compatibility test results based on different comparison items between the application software and the target operating system. The comparison items include: presence or absence of dependent libraries, presence or absence of reference symbols, and correctness of benchmark judgment symbol parameters. The following compatibility types exist: application software dependent library incompatibility, application software reference symbol incompatibility, application software library package-level compatibility, and application software compatibility.

10. The application software compatibility detection method based on binary file symbol tables as described in claim 9, characterized in that, Application software dependency library incompatibility means that the target operating system does not have the dependency libraries required by the application software; application software reference symbol incompatibility means that the target operating system has the dependency library packages required by the application software, but the reference symbols that the application software depends on are missing; application software library package-level compatibility means that the target operating system has all the dependency libraries and reference symbols required by the application software, but a comparison with the baseline symbol table has not been performed or has not passed; application software compatibility means that the target operating system has all the dependency libraries and reference symbols required by the application software, and a comparison with the baseline symbol table has passed, that is, the target operating system satisfies the presence or absence of application software library packages and reference symbols and verifies the correctness of the reference symbol functions, thus concluding that the application software is compatible.

Images