Method for locating vulnerability based on auxiliary tool

Abstract

In order to solve the problems that in the prior art, embedded resources are limited, and a third-party program cannot be embedded for locating vulnerabilities, the method for locating the vulnerabilities based on the auxiliary tool comprises the steps that a python automation tool is started at a computer end, a Micro-USB is used for connecting a computer and embedded equipment, and the embedded equipment is connected with the python automation tool. And the python automation tool automatically monitors the running state of the embedded equipment and carries out debugging management and control and log management. According to the method, the global resources of the program can be tracked, the current state of the global resources can be obtained, the global resources can be dynamically adjusted and controlled, and fault points can be effectively checked and prevented.

Description

Technical Field

[0001] The invention relates to the field of electronic digital data processing, and in particular to a method for locating a vulnerability based on an auxiliary tool. Background Art

[0002] ucosIII is an efficient and reliable real-time operating system designed for embedded systems. Embedded devices based on the UCOSIII system ARM architecture are small in size, occupy less resources, have low power consumption, and are lightweight and convenient. Based on the above advantages, this embedded device is often used in industrial control, medical equipment, automotive electronics, consumer electronics and other fields.

[0003] As embedded devices are increasingly used, the stability of the devices is becoming more and more important. How to quickly resolve the failure of embedded devices has become a top priority.

[0004] In order to solve the above problems, the Chinese invention patent with patent number CN112527631A proposes a bug location method, system, electronic device and storage medium, including inputting the bug to be located into a trained machine learning model and outputting a code block corresponding to the bug to be located; the machine learning model is trained based on a training set including each bug and a code block corresponding to each bug. However, this invention is different from the common Linux operating system and window operating system. It cannot run additional third-party programs on the system, cannot be operated for multiple users, and lacks some advanced functions. Summary of the invention

[0005] The present invention mainly solves the problem in the prior art that the embedded system itself is limited in resources and cannot embed a third-party program to locate vulnerabilities, and provides a method for locating vulnerabilities based on auxiliary tools.

[0006] The above technical problems of the present invention are mainly solved by the following technical solutions: A method for locating vulnerabilities based on auxiliary tools includes the following steps: S1. Start the python automation tool on the computer; S2. Use Micro-USB to connect the computer and embedded device; S3, Python automation tool automatically monitors the running status of embedded devices, wherein the running status includes abnormal failure of the device and memory usage; S4, Python automatic control and management module for debugging and control; S5. The fault detection module and the memory monitoring module perform log management.

[0007] As a preferred solution, step S3 specifically includes the following steps: S3.1. Locate the equipment fault; S3.2. Perform memory detection.

[0008] As a preferred solution, step S3.1 specifically includes the following steps: S3.1.1. Import the compiled Release file and program source code of the embedded device into the Python automation tool; S3.1.2, when an abnormal failure occurs in the embedded device, an abnormal interrupt is triggered, and the embedded device uses the URAT protocol to send the stack information of the current program and the address pointed to by the current pointer of the computer register to the Python automation tool; S3.1.3, extract the address pointed to by the current pointer of the current computer register, use the address to search in the Release file, and find the corresponding fault function; S3.1.4. After the embedded device sends the exception information, it will automatically execute its own code logic.

[0009] As a preferred solution, in step S3.1.3, if the function is a source code file function, the specific file and function can be directly located.

[0010] As a preferred solution, in step S3.1.3, if the function is a dynamic library function, the calling module of the function can be located.

[0011] As a preferred solution, a fault record is subsequently generated and reflected in the fault detection module, and the log management module will also have corresponding information.

[0012] As a preferred solution, step S3.2 specifically includes the following steps: S3.2.1. When the embedded device program applies for memory, it labels the corresponding module and uses UART to transmit the module value and memory application function name to the Python automation tool. The tool records the number of times the module applies for memory and the corresponding memory application function. S3.2.2. When the program memory is released, the module label is removed and the module value is passed to the Python automation tool again. At this time, the tool will reduce the statistical count and cascade delete the memory application function.

[0013] As a preferred solution, if the value of the global variable is not within the planned range, an alarm log is triggered, and all actions to adjust the value of the global static variable record an operation log.

[0014] As a preferred solution, in step S5, the memory monitoring module performs regular monitoring, and triggers an alarm log if there is an obvious surge in memory statistics.

[0015] As a preferred solution, if a suspected type of slow leakage is detected, a reminder log is triggered.

[0016] Therefore, the advantages of the present invention are: The present invention uses a third-party external program, which can solve the problem that the embedded system itself is limited in resources and cannot embed the third-party program to locate vulnerabilities. It can solve the problem that the program is out of bounds or the data is abnormal and difficult to locate in the ucosIII ARM system architecture. It can observe the device stack information and check whether the resource is out of bounds. It can continuously monitor the device memory usage to prevent memory leaks. In addition, it can track the global resources of the program, obtain the current status of the global resources, and dynamically adjust and control the global resources, which can effectively check and prevent the occurrence of fault points. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 It is a logic flow chart of the present invention.

[0018] Figure 2 It is a fault detection flow chart of the present invention.

[0019] Figure 3 It is a memory monitoring flow chart of the present invention.

[0020] Figure 4 It is a debugging control flow chart of the present invention. DETAILED DESCRIPTION

[0021] The technical solution of the present invention is further specifically described below through embodiments and in conjunction with the accompanying drawings.

[0022] Example: uC / OS-III is an efficient and reliable real-time operating system designed specifically for embedded systems. It performs well in the embedded field and has the characteristics of small size, low resource consumption, low power consumption, lightness and flexibility. These characteristics have made embedded devices based on the uC / OS-III system widely adopted in multiple application fields, such as industrial control, medical equipment, automotive electronics, consumer electronics, etc. Thanks to the streamlined and efficient design of uC / OS-III, these embedded devices can not only meet the scenarios with extremely high requirements for hardware resources, but also achieve stable operation in complex embedded environments. However, with the continuous promotion and popularization of embedded devices in all walks of life, their stability has been paid attention to by more and more users and developers. In practical applications, the stable operation of embedded devices is the key to the reliability of the equipment. Once the equipment fails, how to quickly locate the problem and effectively solve it has become a major challenge facing developers. For embedded devices, the difficulty of troubleshooting and repair has limited their further promotion and performance optimization to a certain extent.

[0023] Unlike common operating systems such as Linux or Windows, uC / OS-III, as a real-time operating system, is tailored for embedded application scenarios. It was originally designed to simplify the system architecture and improve resource utilization efficiency. Therefore, although its functions are streamlined, it is accompanied by some limitations in features. For example, uC / OS-III cannot support the running of additional third-party programs like Linux, nor does it support multi-user operation mode. This limitation makes uC / OS-III lack some advanced functions. Although this is not a serious problem in embedded systems, it brings certain challenges in actual development and troubleshooting. Especially when the device fails, due to the lack of advanced debugging tools and expansion capabilities, developers often need more time and energy to analyze and solve the problem.

[0024] Secondly, the debugging process of embedded devices is also a complex and challenging task. During the device development phase, developers usually need to rely on specific debugging tools and equipment, which are not universal and require special hardware support. After the device is put into use, if an abnormal failure occurs, traditional debugging methods are difficult to apply, because the device is usually in a closed operating environment and cannot be directly connected to the debugging tool for analysis. In this case, developers often have no choice but to return the device to the factory for disassembly and analysis, which not only increases maintenance costs, but also affects the normal use of the device. In some critical scenarios, such as industrial automation or medical equipment, equipment downtime may even cause serious economic losses or safety risks.

[0025] In addition, during the operation of embedded devices, although the abnormal reset and automatic restart mechanism of the program can ensure the continuity of the system to a certain extent, it is easy to cover up the actual fault point, making it difficult to locate the root cause of the problem. When the device restarts under abnormal circumstances, it may cause the loss of fault information, further increasing the difficulty for developers to troubleshoot the problem. This hidden safety hazard may accumulate in the long-term operation and eventually lead to bigger problems, especially in application scenarios that require high reliability and security. This situation is unacceptable.

[0026] At present, the means of locating vulnerabilities in embedded devices are relatively simple. Developers usually rely on printing logs and recording fault points to analyze problems. This method is more effective in dealing with common logical errors, but it is powerless for more complex program exception problems, especially the state analysis after the program dies. Once an unrecoverable crash occurs during the program's operation, traditional logging methods cannot capture complete on-site information, making it difficult to trace the root cause of the problem. In addition, the current logging function is often only for surface information of system operation, such as time, memory usage, module operation status, etc., but deeper operating status, such as stack information, module real-time data, etc., are usually not available. The lack of this information greatly limits developers' comprehensive analysis and accurate location of problems.

[0027] Developers currently have limited knowledge of the operating status of embedded devices. Common device operating status includes time, memory usage, module status, configuration files, etc., but this information is only the surface status of the device operation and cannot reflect the deeper operation of the system. For example, stack information anomalies, real-time data of certain modules, specific reasons for program interruptions, etc., these more important information are often not directly available. This lack of information means that developers lack sufficient credentials when troubleshooting problems, and must restore the problem site through repeated experiments, which is not only time-consuming and labor-intensive, but also difficult to ensure that the problem can be accurately reproduced.

[0028] In order to solve the above problems, the present invention provides a method for locating vulnerabilities based on auxiliary tools, comprising the following steps: S1. Start the python automation tool on the computer. Check the computer environment and install the serial port driver when starting. The tool is a third-party software that runs on the computer. When the software starts, it automatically checks whether there is a serial port driver. If not, it will install the serial port driver. Then use a common Micro-USB (old-fashioned Android cable) to connect the computer and the embedded device. By default, the embedded device supports the URAT protocol and has corresponding hardware and drivers.

[0029] The method based on auxiliary tools of the present invention can greatly simplify the debugging and maintenance process of embedded devices. By using a universal USB interface and a standard communication protocol, the solution enables developers to quickly obtain the operating status information of the device without relying on a dedicated debugging tool. During the operation of the tool, real-time data of the device can be collected, including stack information, current values ​​of modules, program operating status, etc. The comprehensive acquisition of this information enables developers to analyze the root cause of the problem more intuitively and accurately. In addition, the method can also record complete log information during the operation of the device. Even if the program crashes abnormally, the on-site information can be retained, providing an important basis for subsequent fault analysis.

[0030] The Python automation tool used in the present invention supports Serial port module, file retrieval module, computer driver detection function, driver installation. The graphical interface includes fault detection, memory monitoring, debugging control, log management, etc.

[0031] S2. Automated monitoring of the device's operating status is particularly important. It can detect and locate device abnormalities in a timely manner and monitor memory usage, thereby providing developers with valuable debugging information and optimization directions. First, use Micro-USB to connect the computer to the embedded device. The embedded device hardware supports Micro-USB and drivers, the program supports the URAT protocol, and the program functions are divided into modules to improve the maintainability and scalability of the code. For example, the HTTP module is responsible for processing network requests, the log module is responsible for recording system operation information, and the fault handling module focuses on handling and reporting abnormal situations.

[0032] S3. Then, the Python automation tool automatically monitors the operating status of the embedded device, including abnormal device failures and memory usage. Python is widely used in the field of automated testing because it has rich libraries and powerful data processing capabilities. It can easily interact with various hardware devices and analyze and visualize data.

[0033] The specific steps include: S3.1. Locate the fault of the equipment, including the following steps: S3.1.1. In order to accurately locate the fault, the compiled Release file and program source code of the embedded device are imported into the Python automation tool. The Release file contains the binary code and symbol information of the program, while the source code provides the definition of functions and variables. This information will serve as the basis for subsequent retrieval and fault location. The Python automation tool will store these files locally and create indexes for subsequent retrieval.

[0034] S3.1.2. When an embedded device fails abnormally, such as a segmentation error or illegal instruction, an abnormal interrupt is triggered. The embedded device uses the URAT protocol to send the stack information of the current program and the address pointed to by the current pointer of the computer register to the python automation tool. The stack information records the hierarchical relationship of function calls and the value of local variables, while the address pointed to by the computer register indicates which instruction the program executed when the exception occurred. The python automation tool detects this abnormal information and saves it. In order to ensure the integrity and reliability of the data, the python automation tool will verify the received data and perform necessary format conversion.

[0035] S3.1.3. After receiving the exception information, the Python automation tool will start to locate the fault, extract the address pointed to by the current pointer of the current computer register, and use this address to search in the Release file. Since the Release file contains the symbolic information of the program, this method can find the corresponding fault function.

[0036] If this function is a source code file function, you can directly locate the specific file and function. The Python automation tool will generate a link to the fault code location based on the source code file path and function name, making it easy for developers to quickly view and modify the code.

[0037] If the function is a dynamic library function, the situation will be slightly more complicated. Dynamic library functions are usually located in shared libraries, and their codes are not included in the Release file. In this case, the calling module of the function can be located, that is, the dynamic library function that caused the exception when it was called. In order to further determine the cause of the fault, the developer needs to debug the dynamic library, or view the documentation and source code of the dynamic library.

[0038] A fault record is subsequently formed and reflected in the fault detection module for subsequent analysis and statistics. This record will contain information such as the time when the fault occurred, stack information, computer register address, fault function or module, etc. At the same time, the log management module will also have corresponding information so that developers can view the system's operation log at any time. The log management module will record various system events in chronological order, including start, stop, exception, warning, etc. In order to facilitate retrieval and filtering, log information can be classified according to different levels, such as De vulnerability, Info, Warning, Error, etc.

[0039] S3.1.4, After the embedded device sends the abnormal information, it will automatically execute its own code logic, generally restarting the program. Program restart can restore the device to normal working state and avoid long-term downtime. Of course, the specific recovery operation needs to be designed according to the actual situation. For example, for some critical systems, more complex fault handling may be required, such as data backup, state rollback, etc.

[0040] In summary, the embedded device operation status monitoring solution based on Micro-USB connection and Python automation tools can effectively monitor device abnormal faults and memory usage. By capturing and analyzing abnormal information, the fault code can be quickly located and repaired accordingly. At the same time, through log management, the operating status of the system can be understood and potential problems can be discovered in time. This automated testing solution can greatly improve the development efficiency and reliability of embedded systems and ensure the stable operation of products. In addition, in order to improve the maintainability of the system, the automated testing tool can also be integrated with the version control system to track code changes and the evolution of test results. Moreover, with the development of artificial intelligence technology, it is possible to try to apply machine learning algorithms to fault analysis to achieve smarter fault prediction and diagnosis.

[0041] S3.2, perform memory detection, including the following steps: S3.2.1. When the embedded device program applies for memory, it labels the corresponding module and uses UART to transmit the module value and memory application function name to the Python automation tool. The tool records the number of times the module applies for memory and the corresponding memory application function.

[0042] S3.2.2. When the program memory is released, remove the module tag and pass the module value to the Python automation tool again. At this time, the tool will reduce the statistical count and cascade delete the memory allocation function.

[0043] Through the above methods, you can view the current memory usage of each module, whether there are modules that apply for a large amount of memory but do not release it, and you can intuitively see the memory application function of the corresponding module to quickly locate the problem. You can also observe the memory growth and decline trends of each module within a certain period of time, determine whether there is a slow memory leak, and locate the module application function with slow leaks.

[0044] S4, Python automatic control and control module for debugging and control, which is an efficient and flexible method that can help developers deeply understand the program's operating logic and ensure that the program can maintain the correct state under various expected and unexpected conditions. This function has a wide range of application scenarios in practice, especially in observing program operation logic, monitoring global status values, and testing specific conditions. This function is often used to observe whether the program operation logic is normal, view and control the program's global status value, and achieve certain specified test conditions.

[0045] The temporary variable value inside the function is destroyed when the function is popped out of the stack, and its value cannot be viewed. This function can only view and adjust the value of global static variables.

[0046] Using the Python automated control module, you can pre-plan the range of changes in the global static variable value, and use the serial port module regularly to check the current value of the specified global static variable to determine whether it is within the correct range. At the same time, you can adjust the global variable value according to the test requirements to test critical status, abnormal status, etc.

[0047] The core advantage of this step in the present invention is that it can view and regulate the value of global static variables. In Python, temporary variables inside a function are automatically destroyed after their life cycle ends (i.e. when the function is executed and popped out of the stack), which means that once the function is executed, the values ​​of these temporary variables can no longer be accessed. However, for global static variables, they exist throughout the life cycle of the entire program and can be accessed and modified multiple times. Therefore, using the Python automated regulation and control module, developers can monitor the current values ​​of these global static variables in real time, which is of great significance for understanding the overall operating state of the program, tracking the changing process of variables, and identifying potential problem points.

[0048] Specifically, by pre-planning the change interval of global static variable values, developers can set reasonable monitoring thresholds and regularly use serial port modules or other communication methods to check whether these variables are within the preset correct range. This process not only helps to detect abnormal fluctuations in variable values ​​in a timely manner, but also prevents potential errors in the early stages, avoiding these errors from causing bigger problems in subsequent program operations. For example, in a control system, a global variable may represent the operating status of the system. By monitoring the changes in this variable, the operating parameters of the system can be adjusted in a timely manner to ensure the stability and reliability of the system.

[0049] In addition, another important application of the Python automated control module is to adjust the value of global variables according to test requirements to test critical and abnormal states. In software testing, testing critical and abnormal states is an important means to ensure the robustness and robustness of the program. By manually or automatically adjusting the value of global variables, developers can simulate specific operating environments or conditions to verify the performance of the program in these extreme cases. For example, in a network application, you can adjust the global variables representing the network status to simulate abnormal situations such as network connection interruption and packet loss to test whether the program can correctly handle these exceptions and return to normal. This testing method can not only improve the program's error handling capabilities, but also enhance the user experience of the program in actual use.

[0050] When implementing this function, developers can take advantage of Python's flexibility and powerful library support, combined with an automated testing framework, to build an efficient debugging and testing environment. For example, you can use a testing framework such as `unittest` or `pytest`, combined with the `serial` library to implement serial communication and automatically read and set the value of global variables. By writing test cases, you can automatically execute a series of test steps, including setting the initial state, triggering specific events, reading and verifying variable values, etc., which greatly improves the efficiency and accuracy of the test.

[0051] S5. The fault detection module and the memory monitoring module perform log management.

[0052] If the value of a global variable is not within the planned range, an alarm log is triggered. All actions to adjust the value of a global static variable record an operation log.

[0053] The memory monitoring module monitors regularly and triggers an alarm log if a significant memory statistics surge occurs. If a suspected type of slow leak is detected, a reminder log is triggered.

[0054] The positioning auxiliary tool used in the present invention is a third-party external program that can solve the problem that the embedded system itself is limited in resources and cannot embed the third-party program to locate vulnerabilities. It can solve the problem that the program is out of bounds or the data is abnormal and difficult to locate in the ucosIII ARM system architecture. It can observe the device stack information and check whether the resource is out of bounds. It can continuously monitor the device memory usage to prevent memory leaks.

[0055] In addition, it can track the global resources of the program, obtain the current status of global resources, and dynamically adjust and control global resources, which can effectively check and prevent the occurrence of fault points.

[0056] The specific embodiments described herein are merely examples of the spirit of the present invention. Those skilled in the art may make various modifications or additions to the specific embodiments described or replace them in similar ways, but they will not deviate from the spirit of the present invention or exceed the scope defined by the appended claims.

Claims

1. A method for locating vulnerabilities based on auxiliary tools, characterized in that: The following steps are involved: S1. Start the python automation tool on the computer; S2. Use Micro-USB to connect the computer and embedded device; S3, Python automation tool automatically monitors the running status of embedded devices, wherein the running status includes abnormal failure of the device and memory usage; S4, Python automatic control and management module for debugging and control; S5. The fault detection module and the memory monitoring module perform log management.

2. According to claim 1, a method for locating vulnerabilities based on auxiliary tools is characterized in that: The step S3 specifically comprises the following steps: S3.

1. Locate the equipment fault; S3.

2. Perform memory detection.

3. The method for locating vulnerabilities based on auxiliary tools according to claim 2, characterized in that: The step S3.1 specifically includes the following steps: S3.1.

1. Import the compiled Release file and program source code of the embedded device into the Python automation tool; S3.1.2, when an abnormal failure occurs in the embedded device, an abnormal interrupt is triggered, and the embedded device uses the URAT protocol to send the stack information of the current program and the address pointed to by the current pointer of the computer register to the Python automation tool; S3.1.3, extract the address pointed to by the current pointer of the current computer register, use the address to search in the Release file, and find the corresponding fault function; S3.1.

4. After the embedded device sends the exception information, it will automatically execute its own code logic.

4. The method for locating vulnerabilities based on auxiliary tools according to claim 3 is characterized in that: In step S3.1.3, if the function is a source code file function, the specific file and function can be directly located.

5. A method for locating vulnerabilities based on auxiliary tools according to claim 3 or 4, characterized in that: In step S3.1.3, if the function is a dynamic library function, the calling module of the function can be located.

6. The method for locating vulnerabilities based on auxiliary tools according to claim 5, characterized in that: A fault record is subsequently generated and reflected in the fault detection module, and the log management module will also have corresponding information.

7. The method for locating vulnerabilities based on auxiliary tools according to claim 2, characterized in that: The step S3.2 specifically includes the following steps: S3.2.

1. When the embedded device program applies for memory, it labels the corresponding module and uses UART to transmit the module value and memory application function name to the Python automation tool. The tool records the number of times the module applies for memory and the corresponding memory application function. S3.2.

2. When the program memory is released, the module label is removed and the module value is passed to the Python automation tool again. At this time, the tool will reduce the statistical count and cascade delete the memory application function.

8. The method for locating vulnerabilities based on auxiliary tools according to claim 1, characterized in that: In step S5, for step S4, if it is detected that the global variable value is not within the planned range, an alarm log is triggered, and all actions of adjusting the global static variable value are recorded in an operation log.

9. The method for locating vulnerabilities based on auxiliary tools according to claim 1, characterized in that: In step S5, the memory monitoring module performs regular monitoring, and triggers an alarm log if there is an obvious surge in memory statistics.

10. The method for locating vulnerabilities based on auxiliary tools according to claim 8, characterized in that: If a suspected type of slow leakage is detected, a reminder log is triggered.

Images