Application risk detection method and apparatus

Abstract

The present application relates to the technical field of risk detection. Provided are an application risk detection method and apparatus, which can perform risk detection on an application, so as to determine an object having a cross-operating system application risk in the application. The method comprises: acquiring a calling relationship among M objects of an application, and on the basis of the calling relationship among the M objects and an operating system application to which each object belongs, determining an object having a risk, wherein M is greater than or equal to 2, the objects comprise functions and / or variables, the calling relationship among the M objects comprises at least one of a function accessing a variable, a function calling another function, a variable referencing another variable, and a variable referencing a function, and at least two operating system applications have different risk levels.

Description

Application risk detection method and device

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on January 31, 2024, with application number 202410146516.0 and application name “Application Risk Detection Method and Device”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of risk detection technology, and in particular to a method and device for detecting application risk. Background Art

[0003] The Automotive Open System Architecture (AUTOSAR) is a software architecture jointly established by global automakers, component suppliers, and other electronics, semiconductor, and software systems companies. AUTOSAR is committed to developing an open, standardized software architecture for the automotive industry.

[0004] However, during the development process, due to negligence or lack of knowledge of developers, some errors may occur in the operation of the developed application, which poses certain risks. Summary of the Invention

[0005] The present application provides an application risk detection method and apparatus, which can perform risk detection on an application to determine objects of cross-operating system application risk existing in the application.

[0006] In order to achieve the above objectives, this application provides the following technical solutions:

[0007] In a first aspect, the present application provides an application risk detection method, which includes: obtaining the calling relationship between M objects of the application, where M is greater than or equal to 2, and the objects include functions and / or variables; the calling relationship between the M objects includes at least one of function accessing variables, function calling functions, variable referencing variables, and variable referencing functions; based on the calling relationship between the M objects and the operating system application to which each object belongs, determining the risky objects, and at least two operating system applications have different risk levels.

[0008] Through the above methods, application risk detection can pre-detect risks on applications and identify objects in applications that have cross-operating system application risks, so that subsequent developers can adjust the applications and eliminate cross-operating system application risks.

[0009] In a possible implementation, application risk detection simulates the execution of machine code of the application to obtain the calling relationships between M objects of the application.

[0010] Compared to the related art method of manually configuring function pointers to obtain the calling relationship between objects in the application, the method of the present application can reduce the workload of developers and improve the efficiency and accuracy of determining the calling relationship between M objects in the application. In addition, the present application processes the binary file (machine code) of the application, does not rely on the source code, does not need to be run in a real environment, and reduces the detection cost.

[0011] In a possible implementation manner, the method further includes: displaying objects that are at risk.

[0012] Through the above methods, developers can easily and intuitively obtain information about risky objects in their applications, improving user experience.

[0013] In one possible implementation, the method further includes: determining first information and / or second information based on the calling relationship between M objects and the operating system application to which each object belongs; the first information indicates the calling relationship between the risky object and other objects, and the second information indicates the operating system application to which the risky object belongs; and displaying the first information and / or second information.

[0014] Through the above methods, developers can also obtain other information related to risky objects in the application, which makes it easier for developers to modify risky applications and further improve the user experience.

[0015] In one possible implementation, the method includes: obtaining a configuration file of an application, the configuration file including N segments and an operating system application to which each segment belongs, where N is greater than or equal to 1; the N segments including M objects; each segment including a data segment or a code segment; and determining, based on the configuration file, the operating system application to which each of the M objects belongs.

[0016] Optionally, the application risk detection apparatus can receive an application configuration file from a developer, where the configuration file includes N segments to which M objects belong, and the operating system application to which each segment belongs. In this manner, the application risk detection apparatus can determine the operating system application to which each object belongs based on the N segments to which the M objects belong and the operating system application to which each segment belongs, thereby determining whether the calling relationships between the M objects pose a cross-operating system application risk.

[0017] In one possible implementation, the risk includes a cross-operating system application risk, the M objects include a first object and a second object, and the object at risk is determined based on the calling relationship between the M objects and the operating system application to which each object belongs, including: if the first object calls the second object, the first object belongs to the first operating system application, the second object belongs to the second operating system application, and the first operating system application is prohibited from accessing the second operating system application, then it is determined that the first object has a cross-operating system application risk.

[0018] Exemplarily, when the vehicle functional safety integrity level of the first operating system application is equal to or lower than the vehicle functional safety integrity level of the second operating system application, it is determined that the first object has a cross-operating system application risk.

[0019] In one possible implementation, the configuration file includes a third-party library of the application, and the method further includes: parsing the third-party library of the application to obtain a calling relationship between L objects; simulating the execution of the application based on the calling relationship between the L objects to obtain a calling relationship between H objects, where the H objects include the above-mentioned L objects and M objects.

[0020] Through the above methods, application risk detection can determine the calling relationship between H objects in the third-party library and the application, and can more comprehensively detect the data competition risks in the application.

[0021] In a possible implementation, the configuration file further includes a thread entry function, and determining a risky object includes: if at least two or more thread entry functions call the same object, determining that the object has a data contention risk.

[0022] For example, if thread entry function 1 and thread entry function 2 call variable 2, there is a data competition risk for variable 2.

[0023] In the second aspect, the present application provides an application risk detection device, including: a transceiver module, used to obtain the calling relationship between M objects of the application, M is greater than or equal to 2, and the objects include functions and / or variables; the calling relationship between the M objects includes at least one of function accessing variables, function calling functions, variable referencing variables, and variable referencing functions; a processing module, used to determine the objects with risks based on the calling relationship between the M objects and the operating system application to which each object belongs, and the risk levels of at least two operating system applications are different.

[0024] In a possible implementation, the device further includes: a display module, configured to display risky objects.

[0025] In one possible implementation, the processing module is further used to determine the first information and / or the second information based on the calling relationship between M objects and the operating system application to which each object belongs; the first information indicates the calling relationship between the risky object and other objects, and the second information indicates the operating system application to which the risky object belongs; the display module is further used to display the first information and / or the second information.

[0026] In one possible implementation, the transceiver module is further configured to obtain an application configuration file, the configuration file comprising N segments and the operating system application to which each segment belongs, where N is greater than or equal to 1; the N segments comprising M objects; each segment comprising a data segment or a code segment; and the processing module is further configured to determine, based on the configuration file, the operating system application to which each of the M objects belongs. In one possible implementation, the risk comprises a cross-operating system application risk, the M objects comprising a first object and a second object, and the processing module is further configured to determine that the first object has a cross-operating system application risk if the first object calls the second object, the first object belongs to the first operating system application, the second object belongs to the second operating system application, and the first operating system application prohibits access to the second operating system application. In one possible implementation, the configuration file comprises a third-party library of the application, and the processing module is further configured to parse the third-party library of the application to obtain calling relationships between L objects; and simulate the execution of the application based on the calling relationships between the L objects to obtain calling relationships between H objects, where the H objects comprise the aforementioned L objects and the M objects. In a possible implementation, the configuration file further includes a thread entry function and a processing module, and is further configured to determine that a data contention risk exists on the object if at least two or more thread entry functions call the same object.

[0027] In a third aspect, the present application provides an application risk detection system, comprising: the application risk detection device described in the second aspect above.

[0028] In a fourth aspect, the present application provides a computer-readable storage medium, which includes a computer program or instructions. When the computer program or instructions are run on an application risk detection device, the application risk detection device executes the method described in the first aspect.

[0029] In a fifth aspect, the present application provides a chip system comprising at least one processor and at least one interface circuit, wherein the at least one interface circuit is used to perform transceiver functions and send instructions to the at least one processor. When the at least one processor executes the instructions, the at least one processor executes a method as described in any one of the above-mentioned first aspects.

[0030] In a sixth aspect, the present application further provides a computer program product comprising instructions, which, when executed on a computer, enables the computer to execute the method as described in any one of the first aspects.

[0031] In a seventh aspect, the present application further provides a circuit system, the circuit system including a processing circuit, and the processing circuit is configured to execute the method of the first aspect or any one of the embodiments of the first aspect.

[0032] The technical effects corresponding to the second to seventh aspects and any implementation method of the second to seventh aspects can be referred to the technical effects corresponding to the above-mentioned first aspect and any implementation method of the first aspect, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] FIG1 is a schematic diagram of a cross-operating system application risk provided by an embodiment of the present application;

[0034] FIG2 is a schematic diagram of the structure of an application risk detection device provided in an embodiment of the present application;

[0035] FIG3 is a schematic diagram of an application risk detection system provided in an embodiment of the present application;

[0036] FIG4 is a flow chart of an application risk detection method provided in an embodiment of the present application;

[0037] FIG5 is a schematic diagram of a cross-operating system application risk provided by an embodiment of the present application;

[0038] FIG6 is a schematic diagram of a data contention risk provided by an embodiment of the present application;

[0039] FIG7 is a schematic diagram of the structure of an application risk detection device provided in an embodiment of the present application;

[0040] FIG8 is a schematic structural diagram of a chip system provided in an embodiment of the present application. DETAILED DESCRIPTION

[0041] The terms "including," "having," and any variations thereof mentioned in the description of the embodiments of the present application are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or apparatus comprising a series of steps or units is not limited to the listed steps or units, but may optionally include other steps or units not listed, or may optionally include other steps or units inherent to the process, method, product, or apparatus.

[0042] It should be noted that in the embodiments of this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of this application should not be interpreted as being more preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0043] In the description of the embodiments of this application, unless otherwise specified, "plurality" means two or more. "And / or" in this document is merely a description of the association relationship between associated objects, indicating that three relationships can exist. For example, "A and / or B" can mean: A exists alone, A and B exist simultaneously, or B exists alone.

[0044] The features, structures, or characteristics of this application may be combined in any suitable manner in one or more embodiments. In the various embodiments of this application, the order of the sequence numbers of the processes does not necessarily indicate the order of execution. The order of execution of the processes should be determined by their functions and inherent logic, and should not constitute any limitation on the implementation of the embodiments of this application.

[0045] Some optional features in the embodiments of the present application can be implemented independently in some scenarios without relying on other features to solve corresponding technical problems and achieve corresponding effects. They can also be combined with other features in some scenarios according to needs.

[0046] In this application, unless otherwise specified, the same or similar parts between the various embodiments can be referenced to each other. In the various embodiments of this application, unless otherwise specified and there is no logical conflict, the terms and / or descriptions between different embodiments are consistent and can be referenced to each other. The technical features in different embodiments can be combined to form new embodiments based on their inherent logical relationships. The implementation methods of this application do not constitute a limitation on the scope of protection of this application.

[0047] In addition, the network architecture and business scenarios described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. Ordinary technicians in this field can know that with the evolution of network architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0048] First, some technical terms involved in the embodiments of this application are introduced:

[0049] 1. Operating system application (OS-Application, OSA)

[0050] The operating system application (OSA) is a concept within the AUTOSAR Classic Platform (CP). An OSA represents a functional safety domain, corresponding to an automotive safety integrity level (ASIL). An OSA can have five automotive safety integrity levels (ASILs): QM, A, B, C, and D. Functions and variables within the same OSA can be freely called from one another, but calls between functions and variables in OSAs with different ASILs are strictly restricted. Functions and variables in an OSA with a lower ASIL cannot call functions and variables in an OSA with a higher ASIL, nor can calls between OSAs with the same ASIL. If a function or variable in an OSA with a different ASIL violates these restrictions, the operating system will fail and cease operation.

[0051] Optionally, some functions / variables may also be located in a common library, and the functions / variables in the OSA of each vehicle functional safety integrity level may call the functions / variables in the common library.

[0052] Optionally, the variables in the embodiment of the present application are variables (global variables) whose life cycle is the same as the system life cycle.

[0053] 2. Third-party libraries

[0054] Third-party libraries are software libraries created and maintained by independent developers or organizations to enhance or extend the functionality of a programming language or framework.

[0055] In software development, third-party libraries are often used to solve specific problems, provide additional functionality, or simplify the implementation of common tasks. These libraries are often shared and provided by other developers and distributed and available through package managers or official websites.

[0056] A third-party library can be a target file, i.e., a binary file to be linked generated by a compiler (e.g., a file called xxx.o), which stores code, data, and other linker-related information in a certain format. For example, code, data, and other linker-related information can be stored in formats such as the Executable and Linkable Format (ELF) or the Common Object File Format (COFF). Symbols in target files do not have a specific execution address and are therefore not executable. Symbols are a concept used in compilation and linking, and are a general term for functions, variables, constants, and the like.

[0057] A third-party library can also be a static library (e.g., a file called xxx.a) that packages multiple target files together in an orderly manner, such as the C standard library.

[0058] 3. Section

[0059] Symbols in target files / executable files are classified and stored in corresponding segments according to the same attributes (such as read / write / executable attributes), such as code segment, data segment, heap segment, stack segment, etc. Among them, executable files are binary files that have been linked and can be loaded and executed. The symbols in them have determined the running address and can be executed.

[0060] In one solution, AUTOSAR CP imposes strict restrictions on access to functions and variables across operating system applications. Figure 1 shows the relationship between functions and variables and OSA. OSA 1, with a QM vehicle safety integrity level, includes functions f11, f12, and f13. OSA 2, with a QM vehicle safety integrity level, includes functions f21, variables d22, and f23. The public library includes functions f31, variables d32, and d33. OSA 4, with a D vehicle safety integrity level, includes functions f41, f42, and f43.

[0061] The call relationship f12->f21 (f12 calls f21) violates the constraints of a cross-OS application call. OSA 1, to which function f12 belongs, has a vehicle functional safety integrity level of QM, while OSA 2, to which function f21 belongs, has a vehicle functional safety integrity level of QM. OSA 1 and OSA 2 have the same vehicle functional safety integrity level, so function f12 cannot call function f21.

[0062] The call relationship f13->f41 violates the constraints of a cross-OS application call. The vehicle functional safety integrity level of OSA 1, to which function f13 belongs, is QM, while the vehicle functional safety integrity level of OSA 4, to which function f41 belongs, is D. The vehicle functional safety integrity level of OSA 4 is higher than that of OSA 1. Therefore, function f13 cannot call function f41.

[0063] The call relationship f43->f11 is a permitted cross-OS application call. The vehicle functional safety integrity level of OSA 4, to which function f43 belongs, is D, while the vehicle functional safety integrity level of OSA 1, to which function f11 belongs, is QM. The vehicle functional safety integrity level of OSA 4 is higher than that of OSA 1, so function f43 can call function f11.

[0064] The call relationships f41->f31 and d22->f31 are permitted cross-OS application calls. Function f31 is in a public library, and functions / variables in each OSA of the vehicle functional safety integrity level can call functions / variables in the public library. Therefore, function f41 can call function f31, and variable d22 can call function f31.

[0065] In the call relationship f23->d22->f31->d32->d33, d33->f42 violates the constraints of a cross-OS application call. Function f23 in this call relationship belongs to OSA 2, which has a vehicle functional safety integrity level of QM, while function f42 belongs to OSA 4, which has a vehicle functional safety integrity level of D. Therefore, this call relationship violates the constraints of a cross-OS application call, and variable d33 cannot call function f42.

[0066] During application development, developers often map functions or variables in the application to the wrong OSA due to negligence or lack of knowledge, causing operating system exceptions when running the application.

[0067] To solve the above problems, an embodiment of the present application proposes an application risk detection method. In this method, the application risk detection device can obtain the calling relationship between M objects of the application, and determine the objects with risks based on the calling relationship between the M objects and the operating system application to which each object belongs. Wherein, M is greater than or equal to 2, and the objects include functions and / or variables; the calling relationship between the M objects includes at least one of function accessing variables, function calling functions, variable referencing variables, and variable referencing functions; and the risk levels of at least two operating system applications are different. In this way, the application is risk-detected in advance to determine the objects in the application that have cross-operating system application risks, so that subsequent developers can adjust the application and eliminate cross-operating system application risks.

[0068] In one embodiment, the application risk detection device can be a separate maintenance and testing device. Alternatively, the application risk detection device can be an embedded device, applied in development scenarios such as vehicle-mounted devices, terminal devices, and industrial control equipment. Alternatively, the above method can be integrated into the application compilation process. This embodiment of the present application does not impose specific limitations on this.

[0069] Figure 2 shows a schematic diagram of the hardware structure of an application risk detection device provided in an embodiment of the present application. The application risk detection device includes at least one processor 201, a communication circuit 202, a memory 203, and at least one communication interface 204. Memory 203 may also be a memory in processor 201.

[0070] The processor 201 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0071] The communication link 202 may include a pathway for transmitting information between the aforementioned components.

[0072] Communication interface 204 is used to communicate with other devices. In embodiments of the present application, the communication interface can be a module, circuit, bus, interface, transceiver, or other device capable of implementing communication functions. Optionally, when the communication interface is a transceiver, the transceiver can be a standalone transmitter that can be used to send information to other devices, or a standalone receiver that can be used to receive information from other devices. The transceiver can also be a component that integrates the functions of sending and receiving information. Embodiments of the present application do not limit the specific implementation of the transceiver.

[0073] In some embodiments, the communication interface may be a media interface, that is, an interface may be used as both a communication interface and a media interface.

[0074] The memory 203 may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. The non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM may be used, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM), or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory may be independent and connected to the processor 201 via the communication line 202. The memory 203 may also be integrated with the processor 201.

[0075] The memory 203 stores computer-executable instructions for implementing the solution of the present application, and is controlled by the processor 201. The processor 201 is configured to execute the computer-executable instructions stored in the memory 203, thereby implementing the application risk detection method provided in the following embodiments of the present application.

[0076] Optionally, the computer executable instructions in the embodiments of the present application may also be referred to as application code, instructions, computer program or other names, which is not specifically limited in the embodiments of the present application.

[0077] In a specific implementation, as an embodiment, the processor 201 may include one or more CPUs, such as CPU0 and CPU1 in FIG. 2 .

[0078] In a specific implementation, as an embodiment, the application risk detection apparatus may include multiple processors, such as processor 201 and processor 205 in Figure 2. Each of these processors may be a single-core processor or a multi-core processor.

[0079] It should be understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the application risk detection device. In other embodiments of this application, the electronic device may include more or fewer components than shown, or may combine or separate certain components, or arrange the components differently. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0080] Figure 3 is a schematic diagram of an application risk detection system provided by an embodiment of the present application. The application risk detection system includes an application risk detection device.

[0081] Optionally, the application risk detection device is configured to receive a machine code of an application and a configuration file of the application, and determine risky objects in the application based on the machine code of the application and the configuration file of the application.

[0082] Optionally, the configuration file of the application may include the relationship (dependency) between the segment and the OSA.

[0083] In one embodiment, the configuration file of the application may also include a third-party library.

[0084] In one embodiment, the configuration file of the application may further include a thread entry function.

[0085] In one embodiment, the configuration file of the application may also include other files, which is not specifically limited in this embodiment of the present application.

[0086] Optionally, the application risk detection device may also be called a static scanning device, a static scanning system, etc.

[0087] FIG4 is a flowchart of an application risk detection method provided in an embodiment of the present application, which includes steps S101-S102:

[0088] S101. The application risk detection apparatus obtains the calling relationship between M objects of the application.

[0089] Wherein, M is greater than or equal to 2, and the objects include functions and / or variables.

[0090] Optionally, the application risk detection apparatus may obtain a machine code of the application and parse the machine code to obtain M objects in the application.

[0091] In one embodiment, the application risk detection apparatus may simulate the execution of each function in the application to obtain the calling relationship between M objects in the application.

[0092] Optionally, the calling relationship between the M objects may include at least one of a function accessing a variable, a function calling a function, a variable referencing a variable, and a variable referencing a function.

[0093] In one scenario, an application includes a function call instruction, which can record the calling relationship between functions or between functions and variables, save the calling site, and enable the application to jump to the called object.

[0094] Optionally, the function call instruction may include a direct call instruction and an indirect call instruction.

[0095] Among them, the direct call instruction can directly obtain the address of the target object (called object) from the instruction.

[0096] Alternatively, the indirect call instruction may be an instruction that calls a function through a function pointer. A function pointer is a pointer variable that points to a function and can be used to store the address of the function and call the corresponding function through the pointer variable. The application risk detection device can traverse all target objects that the function pointer may point to.

[0097] Optionally, when calling an object through a function pointer, if the user specifies a target object, the application may preferentially call the target object specified by the application. The application risk detection device may only detect whether there is a risk in the calling relationship of the function calling the specified target function.

[0098] In another scenario, the application includes calculation instructions. The application can perform calculations according to the semantics of the calculation instructions and subsequently write the calculation results into the target register.

[0099] Optionally, the calculation instruction may include an assignment instruction, an operation instruction, etc. The embodiment of the present application does not impose any specific limitation on this.

[0100] In another scenario, the application includes jump instructions.

[0101] Optionally, jump instructions will cause only some function instructions to be simulated and executed. Therefore, when simulating the execution of an application, the application risk detection device can ignore jump instructions and simulate the execution of the entire application to ensure that the calling relationship between all objects is obtained.

[0102] Optionally, instructions in the application program that are irrelevant to the result may also be ignored, such as instructions for operating system status, instructions for disabling interrupts, instructions for enabling interrupts, and the like.

[0103] In another scenario, the application includes a memory write instruction, wherein the memory write instruction indicates that the application writes a value into the memory.

[0104] In another scenario, the application includes a memory read instruction, wherein the memory read instruction indicates that the application reads a value from the memory.

[0105] Alternatively, when an application reads a value from memory for the first time (i.e., when the application begins execution), the operating system allocates memory for the application and loads the initial values ​​of the variables in the data segment into the corresponding memory locations. Subsequent execution of the application can access the variables in memory to read the initial values.

[0106] Optionally, a pointer is a variable that stores a memory address, allowing indirect access and modification of data in memory. A variable can store multiple function pointers. When an application reads a memory address, if the address corresponds to a variable in the application, the application can search and record the functions in the variable's storage space and save them as a function list. When the application calls an object through a function pointer, it can traverse this function list, improving simulation execution efficiency.

[0107] Optionally, the application may further include other instructions, which will not be given one by one in the embodiments of the present application.

[0108] Exemplarily, as shown in FIG5 , the calling relationship of objects in the application obtained by simulating the execution of each function in the application can be function 1 (an example of the first object) -> function 2 (an example of the second object), that is, function 1 calls function 2.

[0109] In another embodiment, the application risk detection device can directly read the function call relationship specified by the user.

[0110] For example, after the user determines the function call relationship in the application, it can be directly sent to the application risk detection device.

[0111] S102 : The application risk detection device determines an object with risk based on the calling relationship between the M objects and the operating system application to which each object belongs.

[0112] Optionally, the application risk detection apparatus may also parse the machine code of the application to obtain the segment to which each object of the application belongs.

[0113] Exemplarily, the application includes function 1 and function 2; function 1 is located in segment 1, and function 2 is located in segment 2.

[0114] Optionally, the application risk detection apparatus may obtain an application configuration file, the configuration file including N segments and the operating system application to which each segment belongs, wherein N is greater than or equal to 1; the N segments include M objects in the application; and each segment includes a data segment or a code segment.

[0115] For example, the configuration file includes segment 1 and segment 2, where segment 1 belongs to operating system application 1 and segment 2 belongs to operating system application 2. The vehicle functional safety integrity level of operating system application 1 is QM, and the vehicle functional safety integrity level of operating system application 2 is D.

[0116] Optionally, the application risk detection device can determine the first information and / or the second information based on the calling relationship between M objects and the operating system application to which each object belongs; the first information represents the calling relationship between the risky object and other objects, and the second information represents the operating system application to which the risky object belongs.

[0117] For example, function 1 belongs to operating system application 1, and function 2 belongs to operating system application 2. In the calling relationship between the application objects, function 1 calling function 2 is a cross-operating system application calling relationship that violates the constraint. Function 1 has a cross-operating system application risk, and the operating system application to which function 1 belongs is operating system application 1.

[0118] Optionally, the application risk detection device may display the existence of a cross-operating system application risk object.

[0119] Exemplarily, the application risk detection device may display function 1.

[0120] Optionally, the application risk detection apparatus may also display call relationships that involve cross-operating system application risks.

[0121] Exemplarily, the application risk detection apparatus may display a calling relationship in which function 1 calls function 2.

[0122] Optionally, the application risk detection apparatus may further display the operating system application to which the object with cross-operating system application risk belongs.

[0123] Exemplarily, the application risk detection apparatus may display the operating system application 1 to which the function 1 belongs.

[0124] In another embodiment, the application risk detection apparatus may also send information such as the risky object, the first information, and the second information to other devices.

[0125] For example, the application risk detection device may also send information such as the risky object, the first information, and the second information to a terminal device of a developer, and the developer obtains the risky object, the first information, and the second information through the terminal device.

[0126] Optionally, subsequent developers can modify the application based on the risky objects, call relationships, and operating system applications to which the objects belong in the application to ensure that cross-operating system application risks no longer occur in the application.

[0127] In another possible scenario, there may be a risk of data contention in the application, which can cause many unexpected errors in the application and bring unpredictable serious consequences to the operating system.

[0128] In one implementation, static scanning of the application can be performed to identify objects with data race conditions. However, this approach requires manual configuration of function pointers, which is labor-intensive and error-prone.

[0129] For example, for the following application:

[0130] int var

[0131] var=0

[0132] void thread1()

[0133] {

[0134] var++

[0135] }

[0136] void thread2()

[0137] {

[0138] var++

[0139] }

[0140] The developer expects the variable var to have a value of 2. However, the actual execution process of the application may be: int: 0 => var; thread 1: var + 1; thread 2: var + 1; thread 2: 1 => var; thread 1: 1 => var. The actual value of var may be 1. This poses a data race risk for var.

[0141] In the embodiment of the present application, the application can be simulated and executed. During the simulation, all target objects that the function pointer may point to can be traversed. There is no need to manually configure the function pointer, which improves the efficiency of determining data competition risks.

[0142] In one embodiment, the configuration file of the application program obtained by the application program risk detection apparatus may further include a thread entry function.

[0143] Optionally, the application risk detection device may determine risky objects based on the thread entry function and the calling relationship between the M objects.

[0144] Optionally, if at least two or more thread entry functions call the same object, then the object is determined to have a data race risk. The thread entry function that calls the object is a thread entry function that causes data race risk, and the calling relationship related to the object is a calling relationship that causes data race risk.

[0145] The application risk detection device can display objects with data contention risks, thread entry functions that cause data contention risks, and calling relationships that cause data contention risks.

[0146] For example, as shown in FIG6 , a schematic diagram of data competition is shown, including the calling relationship: thread entry function 1 -> function 2 -> variable 1, thread entry function 1 -> function 2 -> variable 2, thread entry function 3 -> function 4 -> variable 2.

[0147] Among them, variable 2 is called by thread entry function 1 and thread entry function 3 at the same time, so there is a data competition risk for variable 2. Thread entry function 1 and thread entry function 3 are the thread entry functions that cause data competition risk. Thread entry function 1->function 2->variable 2 and thread entry function 3->function 4->variable 2 are the calling relationships that cause data competition risk.

[0148] In one embodiment, the configuration file of the application obtained by the application risk detection apparatus may further include a third-party library.

[0149] Optionally, the application risk detection apparatus may parse a third-party library of the application to obtain the calling relationships between L objects.

[0150] Alternatively, the calling relationships between the L objects can be reflected in the relocation table of the unconnected third-party library. The relocation table is output by the compiler and describes the collection of relocation information in the segment. Relocation is performed by the linker. The relocation information may include the location to be relocated, the relocation type, and information about the dependent target object.

[0151] Optionally, relocation means determining the running address of an object. When an object calls a target object, it is necessary to know the running address of the target object. However, in most cases, the running address of the target object cannot be known during the compilation phase. At this time, the object with an undetermined running address needs to be handed over to the linker to complete the relocation to determine the address of the target object.

[0152] For calls between objects within the same source code file, the application directly determines the jump target address during compilation, without the involvement of the linker. Therefore, it is not reflected in the relocation table of the third-party library. Therefore, relying solely on the relocation table may miss the calling relationships between some objects.

[0153] Optionally, the application risk detection device can simulate the execution of an application based on the calling relationships between L objects in a third-party library. During the simulated execution of the application, the application may call objects in the third-party library. In this way, the application risk detection device can obtain the calling relationships between H objects. These H objects include the aforementioned L objects and M objects. In other words, the application risk detection device can obtain the calling relationships between the application and all objects in the third-party library, enabling more comprehensive detection of data race risks in the application.

[0154] In one embodiment, the configuration file of the application risk detection device may not include the third-party library. The application risk detection device needs to simulate the execution of each instruction in the application to determine the situation in which the application calls the third-party library.

[0155] This method simplifies external input and does not require the input of third-party libraries. It can also determine the situation in which the application calls the third-party library and obtain the calling relationship between the application and the objects in the third-party library. It can more comprehensively detect the data competition risks in the application.

[0156] In one embodiment, the configuration file of the application risk detection device may also include function pointers to improve the efficiency of the application risk detection device during simulation execution.

[0157] Data race risks exist in a wide range of scenarios, such as smartphones, smart homes, and industrial control. Therefore, the application risk detection device can detect data race risks during the compilation process of applications for smartphones, smart home devices, and industrial control equipment to eliminate them.

[0158] In another embodiment, the configuration file of the application risk detection device may further include other files to determine other corresponding risks. For example, the configuration file of the application risk detection device may include files related to shared memory, and the application risk detection device may determine the risk of shared memory data consistency, etc.

[0159] It should be noted that some operations in the processes of the above-mentioned method embodiments are optionally combined, and / or the order of some operations is optionally changed. In addition, the execution order between the steps of each process is only exemplary and does not constitute a limitation on the execution order between the steps. There may also be other execution orders between the steps. It is not intended to indicate that the execution order is the only order in which these operations can be performed. Those of ordinary skill in the art will think of various ways to reorder the operations described herein. In addition, it should be noted that the process details involved in a certain embodiment of this invention are also applicable to other embodiments in a similar manner, or different embodiments can be used in combination.

[0160] Furthermore, some steps in the method embodiments may be equivalently replaced with other possible steps. Alternatively, some steps in the method embodiments may be optional and may be deleted in certain usage scenarios. Alternatively, other possible steps may be added to the method embodiments.

[0161] Furthermore, the above method embodiments may be implemented separately or in combination.

[0162] Other embodiments of the present application provide a device, which may be an application risk detection device or a component (such as a chip system) in an application risk detection device.

[0163] The apparatus may include a memory and one or more processors. The memory and processors are coupled. The memory is configured to store computer program code, which includes computer-executable instructions. When the processor executes the computer-executable instructions, the electronic device may perform the functions or steps described in the application risk detection apparatus of the aforementioned method embodiment.

[0164] The core structure of the application risk detection device may be as shown in FIG. 7 , including: a processing module 151 , a transceiver module 152 , a storage module 153 , and a display module 154 .

[0165] Processing module 151 may include at least one of a central processing unit (CPU), an application processor, or a communication processor. Processing module 151 may perform operations or data processing related to control and / or communication with at least one of the other components of the application risk detection device. Optionally, processing module 151 is configured to support the application risk detection device in executing S102 in FIG. 4 .

[0166] Transceiver module 152 is configured to obtain the application (the application's machine code) and / or the application's configuration file input by the developer and transmit the obtained application (the application's machine code) and / or the application's configuration file to other modules of the application risk detection apparatus. Transceiver module 152 is also configured to send the risky object and / or the first information and / or the second information to other devices.

[0167] Storage module 153 is used when the application reads a memory address. If the read memory address corresponds to a variable of the application, it can search and store the function in the storage space of the variable. When the application calls an object through a function pointer, it can traverse the function list to improve the efficiency of simulation execution.

[0168] The display module 154 is configured to display the risky object and / or the first information and / or the second information.

[0169] Optionally, the application risk detection device may further include a communication module 155 for enabling the application risk detection device to communicate with other personal devices (via a communication network). For example, the communication module may connect to a network via wireless or wired communication to communicate with other personal devices or a network server. The wireless communication may employ at least one of cellular communication protocols, such as 5G, Long Term Evolution (LTE), Long Term Evolution-Advanced (LTE-A), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Universal Mobile Telecommunications System (UMTS), Wireless Broadband (WiBro), or Global System for Mobile Communications (GSM). The wireless communication may include, for example, short-range communication. Short-range communication may include at least one of Wireless Fidelity (Wi-Fi), Bluetooth, Near Field Communication (NFC), Magnetic Stripe Transmission (MST), or GNSS. For example, the application risk detection device may transmit the risky object and / or the first information and / or the second information to another device.

[0170] The device shown in FIG. 7 may also include more or fewer components, or split some components, or have other ways of arranging components, which is not limited in the embodiments of the present application.

[0171] An embodiment of the present application also provides a chip system, as shown in Figure 8, which includes at least one processor 161 and at least one interface circuit 162. The processor 161 and the interface circuit 162 can be interconnected via lines. For example, the interface circuit 162 can be used to receive data from other devices (such as the memory of an electronic device). For another example, the interface circuit 162 can be used to send data to other devices (such as the processor 161). Exemplarily, the interface circuit 162 can read instructions stored in the memory and send the instructions to the processor 161. When the instructions are executed by the processor 161, the electronic device can perform the various steps in the above embodiments. Of course, the chip system can also include other discrete devices, which are not specifically limited in the embodiments of the present application.

[0172] The present application also provides a computer storage medium comprising computer-executable instructions. When the computer-executable instructions are executed on the electronic device, the electronic device executes the functions or steps performed by the mobile phone in the above-mentioned method embodiment. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a mobile hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0173] The embodiment of the present application further provides a computer program product, which, when executed on a computer, enables the computer to execute the functions or steps executed by the mobile phone in the above method embodiment.

[0174] Through the description of the above embodiments, those skilled in the art will clearly understand that for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working processes of the above-described systems, devices, and modules can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0175] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the modules or units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0176] The units described as separate components may or may not be physically separate, and the components shown as units may be one physical unit or multiple physical units, that is, they may be located in one place or distributed in multiple places. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0177] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0178] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on such understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the software product is stored in a storage medium, including several instructions to make a device (which can be a single-chip microcomputer, chip, etc.) or a processor (processor) perform all or part of the steps of the method described in each embodiment of the present application. The above content is only the specific implementation method of the present application, but the protection scope of the present application is not limited thereto, and any change or replacement within the technical scope disclosed in the present application should be included within the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A method for detecting application risk, characterized in that: The method comprises: Obtaining call relationships between M objects of an application, where M is greater than or equal to 2, and the objects include functions and / or variables; the call relationships between the M objects include at least one of a function accessing a variable, a function calling a function, a variable referencing a variable, and a variable referencing a function; According to the calling relationships between the M objects and the operating system application to which each object belongs, risky objects are determined, and at least two operating system applications have different risk levels.

2. The method according to claim 1, characterized in that The method further comprises: The objects at risk are displayed.

3. The method according to claim 1 or 2, characterized in that The method further comprises: Determining first information and / or second information based on the calling relationships between the M objects and the operating system application to which each object belongs; the first information indicating the calling relationship between the risky object and other objects, and the second information indicating the operating system application to which the risky object belongs; The first information and / or the second information is displayed.

4. The method according to any one of claims 1 to 3, characterized in that The method comprises: Obtaining a configuration file of the application, the configuration file including N segments and an operating system application to which each segment belongs, where N is greater than or equal to 1; the N segments including the M objects; and each segment including a data segment or a code segment; The operating system application to which each of the M objects belongs is determined according to the configuration file.

5. The method according to any one of claims 1 to 4, characterized in that The risk includes a cross-operating system application risk, the M objects include a first object and a second object, and determining the object at risk based on a call relationship between the M objects and an operating system application to which each object belongs includes: If the first object calls a second object, the first object belongs to a first operating system application, the second object belongs to a second operating system application, and the first operating system application prohibits access to the second operating system application, then it is determined that the first object has a cross-operating system application risk.

6. The method according to any one of claims 1 to 3, characterized in that The configuration file includes a third-party library of the application, and the method further includes: Parsing the third-party library of the application to obtain the calling relationship between L objects; The application is simulated and executed according to the calling relationship between the L objects to obtain the calling relationship between H objects, where the H objects include the L objects and the M objects.

7. The method according to any one of claims 1 to 6, characterized in that The configuration file also includes a thread entry function, and the object determined to be at risk includes: If at least two or more thread entry functions call the same object, it is determined that the object has a data competition risk.

8. An application risk detection device, characterized in that: include: a transceiver module, configured to obtain a call relationship between M objects of an application, where M is greater than or equal to 2, and the objects include functions and / or variables; the call relationship between the M objects includes at least one of a function accessing a variable, a function calling a function, a variable referencing a variable, and a variable referencing a function; The processing module is used to determine risky objects based on the calling relationships between the M objects and the operating system application to which each object belongs, wherein the risk levels of at least two operating system applications are different.

9. The device according to claim 8, characterized in that The device further comprises: A display module is used to display the object with risk.

10. An application risk detection system, characterized in that: The device comprises the application risk detection device as claimed in claim 8 or 9.

11. A computer-readable storage medium, characterized in that The computer-readable storage medium includes a computer program or instructions. When the computer program or instructions are executed on the application risk detection device, the application risk detection device is caused to perform the method according to any one of claims 1 to 7.

Images