Method and device for detecting malicious codes of automobile machine system

Abstract

The invention discloses a method and a device for detecting malicious codes of an automobile in-vehicle infotainment system, and belongs to the technical field of network security. The method comprises the following steps: traversing all processes currently operated by the automobile in-vehicle infotainment system; under the condition that it is determined that the target process is the process needing to be detected, function calling carried out by a thread of the target process is tracked; and under the condition that the target function called by the thread is a preset key function, detecting whether a target program instruction calling the target function belongs to a malicious program instruction or not.

Description

Technical Field

[0001] The present application belongs to the field of network security technology, and specifically relates to a method and device for detecting malicious code in an automobile system. Background Art

[0002] With the development of informatization, automotive electrical systems have become increasingly complex. Currently, cars generally have dozens of electronic control units (ECUs). A luxury car runs nearly 100 million lines of code and is interconnected through the in-car bus. In recent years, most of the automotive information security control incidents have been caused by accessing the target host through physical or network remote access, and exploiting vulnerabilities in the application software or operating system to obtain execution permissions or the highest management permissions (ROOT permissions), and then accessing the internal bus gateway such as CAN and sending arbitrary CAN messages to it.

[0003] Therefore, it is necessary to detect malicious codes on the automobile system to avoid malicious control of the automobile system, reduce the security of the automobile system, and affect the working efficiency of the automobile system. Summary of the invention

[0004] The embodiments of the present application provide a method and device for detecting malicious code in an automobile system, which can detect malicious code in the automobile system and avoid malicious control of the automobile system.

[0005] In order to solve the above technical problems, this application is implemented as follows:

[0006] In a first aspect, an embodiment of the present application provides a method for detecting malicious code in an automobile system, the method comprising: traversing all processes currently running in the automobile system; when it is determined that a target process is a process that needs to be detected, tracking function calls made by the thread of the target process; when the target function called by the thread is a pre-set critical function, detecting whether a target program instruction that calls the target function is a malicious program instruction.

[0007] In an implementation of the first aspect, the detecting whether the target program instruction that calls the target function is a malicious program instruction includes: when the target function called by the thread is a pre-set critical function, obtaining the positional relationship between the stack pointer and the stack boundary of the thread; and when the stack pointer is outside the range of the stack boundary of the thread, determining that the target program instruction that calls the target function is a malicious program instruction.

[0008] In an implementation of the first aspect, the detecting whether the target program instruction that calls the target function is a malicious program instruction includes: obtaining a first quantity of first stack data on the stack at a first moment, wherein the first moment is the moment when the target program instruction calls the target function, and the first stack data includes a first address of the target function; obtaining a second quantity of second stack data on the stack at a second moment, wherein the second moment is a return moment after calling the target function, and the second stack data includes a second address of the target function; when the first address is inconsistent with the second address, determining that the target program instruction is a malicious program instruction.

[0009] In an implementation of the first aspect, the detecting whether a target program instruction that calls the target function is a malicious program instruction includes: obtaining a call return address of the target function; and determining that the target program instruction is a malicious program instruction if the call return address does not meet a predetermined condition.

[0010] In an implementation of the first aspect, the predetermined condition includes: the call return address is an executable address; the first instruction is after the second instruction and is located adjacent to the second instruction, wherein the first instruction is an instruction for determining the function call return address, and the second instruction is an instruction for calling a process other than the target process.

[0011] In an implementation manner of the first aspect, the predetermined condition further includes: a target address of the second instruction is the same as an address of the target function.

[0012] In an implementation of the first aspect, the detecting whether the target program instruction that calls the target function is a malicious program instruction includes: obtaining the positional relationship between the stack frame pointer and the stack boundary of the thread; and determining that the target program instruction that calls the target function is a malicious program instruction when the stack frame pointer is outside the range of the stack boundary of the thread.

[0013] In an implementation of the first aspect, the detection of whether the target program instruction that calls the target function is a malicious program instruction includes: after the called target function returns, simulating the execution of a second number of program instructions; tracking the modifications of registers and stacks by the program instructions; when the modifications of registers and stacks are not within a preset range, determining that the target program instruction is a malicious program instruction.

[0014] In an implementation of the first aspect, the detecting whether the target program instruction that calls the target function is a malicious program instruction includes: determining that the target program instruction is a malicious program instruction when it is determined that the result of executing the target function will cause the security of the automobile system to be reduced.

[0015] In the second aspect, an embodiment of the present application provides a device for detecting malicious code in an automobile system, the device comprising: a traversal module for traversing all processes currently running in the automobile system; a tracking module for tracking function calls made by the thread of the target process when it is determined that the target process is a process that needs to be detected; and a detection module for detecting whether a target program instruction that calls the target function is a malicious program instruction when the target function called by the thread is a pre-set key function.

[0016] In a third aspect, an embodiment of the present application provides an electronic device comprising a processor, a memory, and a program or instruction stored in the memory and executable on the processor, wherein the program or instruction, when executed by the processor, implements a method for detecting malicious code in a vehicle system as in the first aspect.

[0017] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, on which a program or instruction is stored. When the program or instruction is executed by a processor, the method for detecting malicious code in a vehicle system as in the first aspect is implemented.

[0018] In a fifth aspect, an embodiment of the present application provides a chip, comprising a processor and a communication interface, wherein the communication interface is coupled to the processor, and the processor is used to run programs or instructions to implement a method for detecting malicious code in a vehicle system as in the first aspect.

[0019] In an embodiment of the present application, a method for detecting malicious code in an automobile system is provided, the method comprising: traversing all processes currently running in the automobile system; when determining that a target process is a process to be detected, tracking the function calls made by the thread of the target process; when the target function called by the thread is a pre-set key function, detecting whether the target program instruction that calls the target function is a malicious program instruction. The method detects malicious code in the automobile system to avoid malicious control of the automobile system.

[0020] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0022] Figure 1 A flowchart of a method for detecting malicious code in an automobile system provided in an embodiment of the present application;

[0023] Figure 2 A schematic diagram of the structure of a device for detecting malicious code in an automobile system provided in an embodiment of the present application;

[0024] Figure 3 It is a schematic diagram of the structure of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0025] In order to better understand the technical solution of the present application, the embodiments of the present application are described in detail below with reference to the accompanying drawings.

[0026] It should be clear that the described embodiments are only part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in the field without creative work are within the scope of protection of the present application.

[0027] The terms used in the embodiments of the present application are only for the purpose of describing specific embodiments, and are not intended to limit the present application. The singular forms "a", "said" and "the" used in the embodiments of the present application and the appended claims are also intended to include plural forms, unless the context clearly indicates other meanings.

[0028] It should be understood that the term "and / or" used in this article is only a description of the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in this article generally indicates that the associated objects before and after are in an "or" relationship.

[0029] In the description of this specification, it is necessary to understand that the words such as "substantially", "approximately", "approximately", "about", "roughly", "substantially" and the like described in the claims and embodiments of the present application refer to what can be generally recognized within a reasonable process operation range or tolerance range, rather than an exact value.

[0030] In conjunction with the accompanying drawings, a method and device for detecting malicious code in an automobile system provided by an embodiment of the present application will be described in detail through specific embodiments and application scenarios.

[0031] Figure 1A flowchart of a method for detecting malicious code in an automobile system provided in an embodiment of the present application.

[0032] like Figure 1 As shown, the method can be executed by an electronic device, and the electronic device can include: a vehicle system set on a car. In other words, the method can be executed by software or hardware installed in the electronic device, and the method includes the following steps:

[0033] Step 110: Traverse all processes currently running in the vehicle computer system.

[0034] When the car system is working, each process in the car system starts to interact and coordinate. When a specific program instruction is issued, the car system will perform corresponding operations. In order to accurately determine the target process to be detected later, all the processes currently running in the car system should be traversed first.

[0035] Step 120: When it is determined that the target process is a process that needs to be detected, the function calls made by the threads of the target process are tracked.

[0036] All processes currently running in the vehicle system can be obtained from step 110, and all processes that need to be detected in the vehicle system can be obtained based on all processes currently running in the vehicle system. When the target process is determined to be the process that needs to be detected, the vehicle system will track the function calls made by the thread of the target process.

[0037] In the vehicle system, attackers maliciously control the system based on vulnerability exploitation attack technology. For example, the normal process in the vehicle system is controlled to interact with other abnormal processes or kernels; specifically, this interaction includes creating processes, opening and writing files, etc. Among them, the vulnerability exploitation attack technology mainly detects the return-oriented programming detection technology (ROP technology) that appears in the binary vulnerability exploitation code. Furthermore, the return-oriented programming detection technology (ROP technology) is a vulnerability exploitation technology in computer security, which allows attackers to control the program execution flow and execute malicious code when the program enables security protection technology (such as stack non-executable). Generally speaking, for a piece of binary vulnerability exploitation program code, attackers will use return-oriented programming detection technology (ROP technology) to interact with other processes or the kernel of the vehicle system to bypass the vulnerability mitigation measures of the vehicle system, and perform corresponding remote code execution or obtain the highest management authority (ROOT authority) of the vehicle system, thereby maliciously controlling the vehicle system.

[0038] Based on this feature, we first define the concept of a key function. The key function defined here refers to the function that attackers can call to attack directly without the need for return-oriented programming detection technology (ROP technology). In other words, the key function is the attacked function that attackers can directly call without the need for ROP technology.

[0039] Specifically, the key function can be any one or more of the process-related functions, memory-related functions and file-related functions. Among them, the process-related functions mainly include fork(), vfork(), clone(), etc.; the memory-related functions mainly include kmalloc(), kzalloc(), vmalloc(), mprotect(), dlopen(), etc.; the file-related functions mainly include create(), open(), write(), etc.

[0040] In an embodiment of the present application, when it is determined that the target process is a process that needs to be detected, the function calls made by the thread of the target process are tracked, and then it is determined whether there is a problem with the target process through the called function.

[0041] Step 130: When the target function called by the thread is a preset key function, detect whether the target program instruction that calls the target function is a malicious program instruction.

[0042] The function call made by the thread of the target process can be traced by step 120. It is worth noting that the function called here is the target function. In the case where the target function called by the thread is a preset key function, it is detected whether the target program instruction that calls the target function is a malicious program instruction.

[0043] Among them, it can be understood that the key function includes multiple functions, which may be the target function or not; the target function may be one or more of the key functions. For example, in an actual vehicle system, the key function includes any one or more of the process-related functions, memory-related functions and file-related functions, and the target function to be detected is the write() function. At this time, in order to conduct a subsequent security detection of the vehicle system, it is necessary to first determine whether the target function write() function called by the thread is a function in the pre-set key function. In the case of determining that the target function write() function called by the thread is a pre-set key function, the target program instruction that calls the target function is detected to detect whether the target program instruction that calls the target function is a malicious program instruction.

[0044] The embodiment of the present invention provides a method for detecting malicious code in an automobile system, which first traverses all processes currently running in the automobile system; then, when it is determined that the target process is a process that needs to be detected, tracks the function calls made by the thread of the target process; and then, when the target function called by the thread is a pre-set key function, detects whether the target program instruction that calls the target function is a malicious program instruction. The above-mentioned method for detecting malicious code in an automobile system can solve the problem that attackers or hackers sneak into the automobile system and try to obtain control or the highest management authority (ROOT authority) through loopholes in application software or system, and maliciously control the automobile system, thereby improving the security and work efficiency of the automobile system.

[0045] In one implementation of the embodiment of the present application, the detection of whether the target program instruction that calls the target function is a malicious program instruction includes: when the target function called by the thread is a pre-set critical function, obtaining the positional relationship between the stack pointer and the stack boundary of the thread; and when the stack pointer is outside the range of the stack boundary of the thread, determining that the target program instruction that calls the target function is a malicious program instruction.

[0046] In most ROP attacks, attackers need to control the stack. When attackers exploit buffer overflow vulnerabilities, it is easy to control the stack. However, when exploiting other memory corruption vulnerabilities, it is more difficult and requires special techniques. Specifically, for example, through PC (instruction pointer register) and a general register (assumed to be RAX for simplicity), the common technique for controlling the stack is to move the value from RAX to the stack pointer, so the memory pointed to by RAX will become the "stack". Unless RAX itself points to the stack, this will cause the stack pointer to no longer point to the memory area specified by the current thread. Therefore, in each call of a key function, the vehicle system will check whether the stack pointer is within the boundary of the current thread stack. When the stack pointer is outside the range of the stack boundary of the thread, it indicates that the vehicle system is undergoing a ROP attack. Therefore, based on this feature, a first detection method is proposed, that is, when the target function called by the thread is a pre-set key function, the positional relationship between the stack pointer and the stack boundary of the thread is obtained; when the stack pointer is outside the range of the stack boundary of the thread, it is determined that the target program instruction that calls the target function is a malicious program instruction.

[0047] Specifically, for this method, it is important to obtain the positional relationship between the stack pointer and the stack boundary of the thread. After obtaining the positional relationship between the stack pointer and the stack boundary of the thread, it can be determined whether the vehicle system is undergoing a ROP attack. It can be understood that when the stack pointer is within the stack boundary of the thread, it is determined that the target program instruction that calls the target function is not a malicious program instruction; when the stack pointer is outside the range of the stack boundary of the thread, it is determined that the target program instruction that calls the target function is a malicious program instruction.

[0048] In one implementation of the embodiment of the present application, the detection of whether the target program instruction that calls the target function is a malicious program instruction includes: obtaining a first quantity of first stack data on the stack at a first moment, wherein the first moment is the moment when the target program instruction calls the target function, and the first stack data includes the first address of the target function; obtaining a second quantity of second stack data on the stack at a second moment, wherein the second moment is the return moment after calling the target function, and the second stack data includes the second address of the target function; when the first address is inconsistent with the second address, determining that the target program instruction is a malicious program instruction.

[0049] If the target function is entered through the RETN instruction instead of through a CALL or JUMP type instruction, then when the execution flow enters the target function, the target function address must exist above the current stack pointer (RSP).

[0050] Specifically, if the RETN instruction is used to enter the target function, the target function address is at RSP-4; if the RETN n instruction is used, the target function address is at RSP-n-4.

[0051] It is understandable that when the target function is called and then returned, a target address will also be generated at the corresponding location. When the two addresses are inconsistent, it indicates that a ROP attack is occurring in the vehicle system.

[0052] In one implementation, firstly, the first amount of first stack data on the stack at the first moment is obtained, wherein the first moment is the moment when the target program instruction calls the target function, and the first stack data includes the first address of the target function; the vehicle system will save the first stack data for subsequent inspection and comparison. Then, the first amount of second stack data on the stack at the second moment is obtained, wherein the second moment is the return moment after calling the target function, and the second stack data includes the second address of the target function; at this time, the vehicle system has not only the first stack data but also the second stack data, and the obtained first stack data and the second stack data are compared, and when the first stack data and the second stack data are inconsistent, it is determined that the target program instruction is a malicious program instruction.

[0053] In one implementation of the embodiment of the present application, the detection of whether the target program instruction that calls the target function is a malicious program instruction includes: obtaining the call return address of the target function; and determining that the target program instruction is a malicious program instruction if the call return address does not meet a predetermined condition.

[0054] When the program instruction of the vehicle system enters the target function, the target function address must exist in the vehicle system. Specifically, the return address of the target function is located at the top of the stack, and the call return address of the target function can be obtained at the top of the stack; then, according to whether the call return address meets the predetermined conditions, whether the target program instruction of the target function belongs to a malicious program instruction. If the call return address meets the predetermined conditions, it is determined that the target program instruction does not belong to a malicious program instruction; if the call return address does not meet the predetermined conditions, it is determined that the target program instruction belongs to a malicious program instruction.

[0055] In one implementation, the predetermined condition includes: the call return address is an executable address; the first instruction is after the second instruction and is located adjacent to the second instruction, wherein the first instruction is an instruction for determining the function call return address, and the second instruction is an instruction for calling a process other than the target process.

[0056] Specifically, determining whether the call return address satisfies a predetermined condition can be understood as determining whether the call return address is an executable address, or determining whether the instruction of the function call return address is after the instruction of calling a process other than the target process. When the call return address is an executable address, and the instruction of the function call return address is after the instruction of calling a process other than the target process, it is determined that the target program instruction is not a malicious program instruction; when the call return address is a non-executable address or the instruction of the function call return address is not after the instruction of calling a process other than the target process, it is determined that the target program instruction is a malicious program instruction.

[0057] In one implementation, the predetermined condition further includes: a target address of the second instruction is the same as an address of the target function.

[0058] Specifically, when the target address of the second instruction is the same as the address of the target function, it is determined that the target program instruction is not a malicious program instruction; when the target address of the second instruction is different from the address of the target function, it is determined that the target program instruction is a malicious program instruction.

[0059] In one implementation of the embodiment of the present application, the detection of whether the target program instruction that calls the target function is a malicious program instruction includes: when the target function called by the thread is a pre-set critical function, obtaining the positional relationship between the stack frame pointer and the stack boundary of the thread; and when the stack frame pointer is outside the range of the stack boundary of the thread, determining that the target program instruction that calls the target function is a malicious program instruction.

[0060] Specifically, if the program is compiled in a way that uses the RBP register or other registers as a stack frame pointer, this feature can be used to check the consistency of the information on the stack, where not only the return address of the target function can be checked, but also the return address of the function that calls the target function can be checked.

[0061] In this implementation, it is important to obtain the positional relationship between the stack frame pointer and the stack boundary of the thread. After obtaining the positional relationship between the stack frame pointer and the stack boundary of the thread, it is possible to determine whether a ROP attack is occurring in the vehicle system. It is understandable that when the stack frame pointer is within the stack boundary of the thread, it is determined that the target program instruction that calls the target function is not a malicious program instruction; when the stack frame pointer is outside the range of the stack boundary of the thread, it is determined that the target program instruction that calls the target function is a malicious program instruction.

[0062] In one implementation of the embodiment of the present application, the detection of whether the target program instruction that calls the target function is a malicious program instruction includes: after the called target function returns, simulating the execution of a second number of program instructions; tracking the modifications of registers and stacks by the program instructions; when the modifications of registers and stacks are not within a preset range, determining that the target program instruction is a malicious program instruction.

[0063] Specifically, we can simulate instructions that change the stack and track the modifications of these instructions to the stack pointer value. Once a RETN instruction is encountered, the system will check whether the return address is executable and whether the instruction at the return address is before the call instruction. This can not only check the return address of the current key function, but also if the current key function is called from the ROP code ended by the RETN instruction, then the subsequent return address can be checked, and the data of the registers and stack in the vehicle system after the target function returns can be saved. The changes in the registers and stack in the vehicle system are compared. When the modification of the registers and stack is not within the preset range, it is determined that the target program instruction is a malicious program instruction.

[0064] In one implementation of the embodiment of the present application, the detection of whether the target program instruction that calls the target function is a malicious program instruction includes: determining that the target program instruction is a malicious program instruction when it is determined that the result of executing the target function will cause the security of the automobile system to be reduced.

[0065] Specifically, the system will also perform additional checks related to the target function parameters to determine whether the target function may endanger system security. If it is determined that the result of executing the target function will reduce the security of the vehicle system, the target program instruction is determined to be a malicious program instruction. For example, for the target function mprotect(), if it attempts to modify the attributes of a piece of memory to be writable and executable at the same time, the call of this target function will be blocked or an alarm will be issued, and the target program instruction is determined to be a malicious program instruction.

[0066] Figure 2 A schematic diagram of the structure of a device for detecting malicious code in an automobile system provided in an embodiment of the present application.

[0067] like Figure 2 As shown, the device 200 may include: a traversal module 210, a tracking module 220 and a detection module 230.

[0068] In the implementation column of the present application, the traversal module 210 is used to traverse all processes currently running in the automobile system; the tracking module 220 is used to track the function calls made by the thread of the target process when it is determined that the target process is a process that needs to be detected; the detection module 230 is used to detect whether the target program instruction that calls the target function is a malicious program instruction when the target function called by the thread is a pre-set key function.

[0069] In one implementation, the detection module 230 detects whether the target program instruction that calls the target function is a malicious program instruction, including:

[0070] When the target function called by the thread is a preset key function, obtaining a positional relationship between a stack pointer and a stack boundary of the thread;

[0071] In a case where the stack pointer is outside the range of the stack boundary of the thread, it is determined that the target program instruction that calls the target function is a malicious program instruction.

[0072] In one implementation, the detection module 230 detects whether the target program instruction that calls the target function is a malicious program instruction, including:

[0073] Acquire a first quantity of first stack data on a stack at a first moment, wherein the first moment is a moment when the target program instruction calls the target function, and the first stack data includes a first address of the target function;

[0074] Acquire a second stack data of a first quantity and a second stack quantity on the stack at a second moment, wherein the second moment is a return moment after calling the target function, and the second stack data includes a second address of the target function;

[0075] When the first address is inconsistent with the second address, it is determined that the target program instruction is a malicious program instruction.

[0076] In one implementation, the detection module 230 detects whether the target program instruction that calls the target function is a malicious program instruction, including:

[0077] Obtaining the call return address of the target function;

[0078] When the call return address does not satisfy a predetermined condition, it is determined that the target program instruction is a malicious program instruction.

[0079] In one implementation, the predetermined condition includes:

[0080] The call return address is an executable address;

[0081] The first instruction is after the second instruction and is located adjacent to the second instruction, wherein the first instruction is an instruction for determining the return address of the function call, and the second instruction is an instruction for calling a process other than the target process.

[0082] In one implementation, the predetermined condition further includes:

[0083] The target address of the second instruction is the same as the address of the target function.

[0084] In one implementation, the detection module 230 detects whether the target program instruction that calls the target function is a malicious program instruction, including:

[0085] Obtaining a positional relationship between a stack frame pointer and a stack boundary of the thread;

[0086] In a case where the stack frame pointer is outside the range of the stack boundary of the thread, it is determined that the target program instruction that calls the target function is a malicious program instruction.

[0087] In one implementation, the detection module 230 detects whether the target program instruction that calls the target function is a malicious program instruction, including:

[0088] After the called target function returns, simulating execution of a second number of program instructions;

[0089] Tracking the modification of registers and stacks by the program instructions;

[0090] When the modification status of the register and the stack is not within a preset range, it is determined that the target program instruction is a malicious program instruction.

[0091] In one implementation, the detection module 230 detects whether the target program instruction that calls the target function is a malicious program instruction, including:

[0092] When it is determined that the result of executing the target function will cause the safety of the automobile system to be reduced, it is determined that the target program instruction is a malicious program instruction.

[0093] The embodiment of the present application provides a detection device for malicious code in a vehicle system that can achieve Figure 1 To avoid repetition, the various processes implemented in the illustrated method embodiment will not be described again here.

[0094] In the embodiment of the present application, a detection device for malicious code in a vehicle system can be a device, or a component, an integrated circuit, or a chip in an electronic device. The embodiment of the present application is not specifically limited.

[0095] In the embodiment of the present application, a detection device for malicious code in a vehicle system may be a device having an operating system. The operating system may be a vehicle system, an Android operating system, an iOS operating system, or other possible operating systems, which are not specifically limited in the embodiment of the present application.

[0096] Optional, Figure 3 Schematic diagram of the structure of an electronic device according to an embodiment of the present application. Figure 3 As shown, the embodiment of the present application also provides an electronic device 300, including a processor 310, a memory 320, and a program or instruction stored in the memory 320 and executable on the processor 310; when the program or instruction is executed by the processor 310, each process of the above-mentioned flow anomaly detection method embodiment is implemented, and the same technical effect can be achieved. To avoid repetition, it will not be repeated here.

[0097] An embodiment of the present application also provides a computer-readable storage medium, on which a program or instruction is stored. When the program or instruction is executed by a processor, each process of the above-mentioned flow anomaly detection method embodiment is implemented, and the same technical effect can be achieved. To avoid repetition, it will not be repeated here.

[0098] The processor is the processor in the electronic device described in the above embodiment. The readable storage medium includes a computer readable storage medium, such as a computer read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0099] An embodiment of the present application further provides a chip, which includes a processor and a communication interface, and the communication interface and the processor are coupled, and the processor is used to run programs or instructions to implement the various processes of the above-mentioned flow anomaly detection method embodiment, and can achieve the same technical effect. To avoid repetition, it will not be repeated here.

[0100] It should be understood that the chip mentioned in the embodiments of the present application can also be called a system-level chip, a system chip, a chip system or a system-on-chip chip, etc.

[0101] It should be noted that, in this article, the terms "comprise", "include" or any other variant thereof are intended to cover non-exclusive inclusion, so that the process, method, article or device including a series of elements includes not only those elements, but also includes other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise one..." do not exclude the presence of other identical elements in the process, method, article or device including the element. In addition, it should be pointed out that the scope of the methods and devices in the embodiments of the present application is not limited to performing functions in the order shown or discussed, and may also include performing functions in a substantially simultaneous manner or in reverse order according to the functions involved, for example, the described method may be performed in an order different from that described, and various steps may also be added, omitted, or combined. In addition, the features described with reference to certain examples may be combined in other examples.

[0102] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, a magnetic disk, or an optical disk), and includes a number of instructions for a terminal (which can be a mobile phone, a computer, a server, an air conditioner, or a network device, etc.) to execute the methods described in each embodiment of the present application.

[0103] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the invention disclosed herein. The present application is intended to cover any modification, use or adaptation of the present application, which follows the general principles of the present application and includes common knowledge or customary techniques in the art that are not disclosed in the present application. The specification and examples are intended to be exemplary only, and the true scope and spirit of the present application are indicated by the claims.

[0104] It should be understood that the present application is not limited to the precise structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims

1. A method for detecting malicious code in a vehicle system, characterized in that: The method comprises: Traverse all the processes currently running in the car system; When determining that the target process is a process that needs to be detected, tracing function calls made by threads of the target process; In the case that the target function called by the thread is a preset key function, it is detected whether the target program instruction that calls the target function is a malicious program instruction.

2. The method according to claim 1, characterized in that: The detecting whether the target program instruction that calls the target function is a malicious program instruction includes: When the target function called by the thread is a preset key function, obtaining a positional relationship between a stack pointer and a stack boundary of the thread; In a case where the stack pointer is outside the range of the stack boundary of the thread, it is determined that the target program instruction that calls the target function is a malicious program instruction.

3. The method according to claim 1, characterized in that The detecting whether the target program instruction that calls the target function is a malicious program instruction includes: Acquire a first quantity of first stack data on a stack at a first moment, wherein the first moment is a moment when the target program instruction calls the target function, and the first stack data includes a first address of the target function; Acquire a second stack data of a first quantity and a second stack quantity on the stack at a second moment, wherein the second moment is a return moment after calling the target function, and the second stack data includes a second address of the target function; When the first address is inconsistent with the second address, it is determined that the target program instruction is a malicious program instruction.

4. The method according to claim 1, characterized in that: The detecting whether the target program instruction that calls the target function is a malicious program instruction includes: Obtaining the call return address of the target function; When the call return address does not satisfy a predetermined condition, it is determined that the target program instruction is a malicious program instruction.

5. The method according to claim 4, characterized in that The predetermined conditions include: The call return address is an executable address; The first instruction is after the second instruction and is located adjacent to the second instruction, wherein the first instruction is an instruction for determining the return address of the function call, and the second instruction is an instruction for calling a process other than the target process.

6. The method according to claim 5, characterized in that The predetermined conditions also include: The target address of the second instruction is the same as the address of the target function.

7. The method according to claim 1, characterized in that The detecting whether the target program instruction that calls the target function is a malicious program instruction includes: Obtaining a positional relationship between a stack frame pointer and a stack boundary of the thread; In a case where the stack frame pointer is outside the range of the stack boundary of the thread, it is determined that the target program instruction that calls the target function is a malicious program instruction.

8. The method according to claim 1, characterized in that: The detecting whether the target program instruction that calls the target function is a malicious program instruction includes: After the called target function returns, simulating execution of a second number of program instructions; Tracking the modification of registers and stacks by the program instructions; When the modification status of the register and the stack is not within a preset range, it is determined that the target program instruction is a malicious program instruction.

9. The method according to claim 1, characterized in that: The detecting whether the target program instruction that calls the target function is a malicious program instruction includes: When it is determined that the result of executing the target function will cause the safety of the automobile system to be reduced, it is determined that the target program instruction is a malicious program instruction.

10. A detection device for malicious code in a vehicle system, characterized in that: The device comprises: The traversal module is used to traverse all the processes currently running in the vehicle system; A tracing module, for tracing function calls made by threads of the target process when it is determined that the target process is a process to be detected; The detection module is used to detect whether the target program instruction that calls the target function is a malicious program instruction when the target function called by the thread is a preset key function.

Images