Vulnerability detection method and device and electronic equipment

Abstract

Embodiments of the present disclosure disclose a vulnerability detection method and device, electronic equipment and a computer readable storage medium. The vulnerability detection method comprises: determining the location of a code segment related to external storage, the read-write mode of the code segment and the path of an external storage file in a target program by decompiling the target program; the target program is a program to be detected; inserting a monitoring program at the location of the code segment; running the target program and obtaining a first running result of the code segment through the monitoring program; performing a preset processing on a file at the path of the external storage file according to the read-write mode of the code segment; running the target program again and obtaining a second running result of the code segment through the monitoring program; comparing the first running result and the second running result to obtain an external storage vulnerability; wherein the obtaining of the external storage vulnerability comprises: when the comparison result meets a preset condition, determining that the target program has an external storage vulnerability. The above method solves the technical problems of inaccurate static analysis and incomplete dynamic detection by analyzing the code segment related to external storage in the target program and the execution results of the code segment in two tests.

Description

Technical Field

[0001] This disclosure relates to the field of vulnerability detection, and more particularly to a vulnerability detection method, apparatus, electronic device, and computer-readable storage medium. Background Technology

[0002] External storage typically refers to the storage method where applications save data files on the SD card. For example, the Android operating system uses a path ( / sdcard) to represent these storage devices. Before Android Q, applications only needed permission to access other applications' external storage data. Although Android Q restricted external storage access, third-party applications could still read and write external storage with lower security restrictions by setting the TargetAPI to below 29 (the API level corresponding to Android Q) during compilation. Android R completely restricted third-party applications from accessing other applications' private external storage directories, but due to Android R's low market share and the fact that other directories on the SD card were still unprotected, external storage remained insecure.

[0003] Existing security vulnerability detection technologies are generally static, analyzing applications statically and only providing a general conclusion of whether the application is secure or insecure. The results are relatively absolute or simplistic, unable to pinpoint specific security threats to particular data, and even less capable of detecting risks arising from applications reading from or writing to external storage. Dynamic detection technologies, on the other hand, cannot cover all application code paths, are unlikely to trigger deeply hidden code logic, and cannot provide further security assessments for the specific behaviors detected. Summary of the Invention

[0004] This summary section is provided to briefly introduce the concepts, which will be described in detail in the detailed description section below. This summary section is not intended to identify key or essential features of the claimed technical solution, nor is it intended to limit the scope of the claimed technical solution.

[0005] In order to at least partially solve the above-mentioned technical problems, the present disclosure proposes the following technical solutions.

[0006] In a first aspect, embodiments of this disclosure provide a vulnerability detection method, including:

[0007] By decompiling the target program, the location of code segments related to external storage, the read / write method of the code segments, and the path of the external storage file are determined; wherein, the target program is the program to be detected;

[0008] Insert a monitoring program at the location of the code snippet;

[0009] The target program is run, and the first execution result of the code snippet is obtained through the monitoring program.

[0010] The files on the path of the external storage file are pre-processed according to the read / write method of the code snippet;

[0011] The target program is run again, and the second execution result of the code snippet is obtained through the monitoring program.

[0012] The external storage vulnerability is obtained by comparing the first running result and the second running result; wherein, obtaining the external storage vulnerability includes: when the comparison result meets the preset conditions, determining that the target program has an external storage vulnerability.

[0013] Furthermore, the step of performing preset processing on files on the path of the external storage file according to the read / write method of the code fragment includes:

[0014] When the read / write method is to read external storage files, the files on the path of the external storage file are pre-processed according to the type of the external storage file;

[0015] When the read / write method is to write to an external storage file, a first preset file is set on the path of the external storage file;

[0016] When the read / write method is to delete an external storage file, if there is no file on the path of the external storage file, then a second preset file is set on the path of the external storage file.

[0017] Furthermore, the pre-processing of files on the path of the external storage file according to the file type includes:

[0018] When the type of the external storage file is an executable file, a preset executable file is stored in the path of the storage file; wherein, the executable file is used to implement a preset function;

[0019] When the type of the external storage file is a resource file, configuration file, unknown type file, or hidden file, add a mark to the file on the path of the external storage file or store the marked file in the path of the storage file.

[0020] Furthermore, the filename of the first preset file is the same as the filename in the write instruction.

[0021] Furthermore, the step of running the target program and obtaining the first execution result of the code segment through the monitoring program includes:

[0022] The execution process of the target program is controlled according to the test program;

[0023] The monitoring program records the call stack and page view of the code snippet during its execution.

[0024] Furthermore, the step of re-running the target program and obtaining a second execution result of the code fragment through the monitoring program includes:

[0025] The target program's execution process is controlled again based on the test procedure;

[0026] The monitoring program records the call stack and page view of the code snippet during its re-run.

[0027] Furthermore, the step of comparing the first running result and the second running result to obtain the external storage vulnerability includes:

[0028] Comparing the call stack in the first execution result with the call stack in the second execution result reveals an external storage vulnerability; or,

[0029] The external storage vulnerability was identified by comparing the page views in the first run result and the page views in the second run result.

[0030] Furthermore, the comparison of the call stack in the first execution result and the call stack in the second execution result to obtain the external storage vulnerability includes:

[0031] If the call stack in the second execution result has changed compared to the call stack in the first execution result, then a vulnerability exists in the external storage.

[0032] Furthermore, the comparison of the page views in the first execution result and the page views in the second execution result to obtain the external storage vulnerability includes:

[0033] If the page view in the second execution result has changed compared to the page view in the first execution result, then a vulnerability is determined to exist in the external storage; or,

[0034] If a marker that is not present in the page view of the first run result appears in the page view of the second run result, then a vulnerability is identified in the external storage.

[0035] Furthermore, after running the target program and obtaining the first execution result of the code snippet through the monitoring program, the process further includes:

[0036] Clear the cached data of the target program and restore the target program to its initial state.

[0037] Secondly, embodiments of this disclosure provide a vulnerability detection device, comprising:

[0038] The decompilation module is used to determine the location of code segments related to external storage, the read / write method of the code segments, and the path of external storage files in the target program by decompiling the target program; wherein, the target program is the program to be detected;

[0039] An insertion module is used to insert a monitoring program at the location of the code snippet;

[0040] The testing module is used to run the target program and obtain the first running result of the code snippet through the monitoring program;

[0041] The file processing module is used to perform preset processing on the files on the path of the external storage file according to the read and write method of the code fragment;

[0042] The testing module is also used to run the target program again and obtain a second running result of the code snippet through the monitoring program;

[0043] The comparison module is used to compare the first running result and the second running result; when the comparison result meets the preset conditions, it is determined that the target program has an external storage vulnerability.

[0044] Furthermore, the file processing module is also used for:

[0045] When the read / write method is to read external storage files, the files on the path of the external storage file are pre-processed according to the type of the external storage file;

[0046] When the read / write method is to write to an external storage file, a first preset file is set on the path of the external storage file;

[0047] When the read / write method is to delete an external storage file, if there is no file on the path of the external storage file, then a second preset file is set on the path of the external storage file.

[0048] Furthermore, the file processing module is also used for:

[0049] When the type of the external storage file is an executable file, a preset executable file is stored in the path of the storage file; wherein, the executable file is used to implement a preset function;

[0050] When the type of the external storage file is a resource file, configuration file, unknown type file, or hidden file, add a mark to the file on the path of the external storage file or store the marked file in the path of the storage file.

[0051] Furthermore, the filename of the first preset file is the same as the filename in the write instruction.

[0052] Furthermore, the testing module is also used for:

[0053] The execution process of the target program is controlled according to the test program;

[0054] The monitoring program records the call stack and page view of the code snippet during its execution.

[0055] Furthermore, the testing module is also used for:

[0056] The target program's execution process is controlled again based on the test procedure;

[0057] The monitoring program records the call stack and page view of the code snippet during its re-run.

[0058] Furthermore, the comparison module is also used for:

[0059] Comparing the call stack in the first execution result with the call stack in the second execution result reveals an external storage vulnerability; or,

[0060] The external storage vulnerability was identified by comparing the page views in the first run result and the page views in the second run result.

[0061] Furthermore, the comparison module is also used for:

[0062] If the call stack in the second execution result has changed compared to the call stack in the first execution result, then a vulnerability exists in the external storage.

[0063] Furthermore, the comparison module is also used for:

[0064] If the page view in the second execution result has changed compared to the page view in the first execution result, then a vulnerability is determined to exist in the external storage; or,

[0065] If a marker that is not present in the page view of the first run result appears in the page view of the second run result, then a vulnerability is identified in the external storage.

[0066] Furthermore, the device also includes a cleaning module for:

[0067] Clear the cached data of the target program and restore the target program to its initial state.

[0068] Thirdly, embodiments of this disclosure provide an electronic device, including:

[0069] Memory, used to store computer-readable instructions; and

[0070] A processor for executing the computer-readable instructions, causing the electronic device to implement the method according to any one of the first aspects above.

[0071] Fourthly, embodiments of this disclosure provide a non-transitory computer-readable storage medium for storing computer-readable instructions that, when executed by a computer, cause the computer to implement the method described in any one of the first aspects above.

[0072] This disclosure provides a vulnerability detection method, apparatus, electronic device, and computer-readable storage medium. The vulnerability detection method includes: decompiling a target program to determine the location, read / write mode, and path of an external storage file within the target program that is related to external storage; wherein the target program is the program to be detected; inserting a monitoring program at the location of the code segment; running the target program and obtaining a first execution result of the code segment through the monitoring program; performing pre-defined processing on files at the path of the external storage file according to the read / write mode of the code segment; running the target program again and obtaining a second execution result of the code segment through the monitoring program; comparing the first execution result and the second execution result to obtain an external storage vulnerability; wherein obtaining the external storage vulnerability includes: determining that the target program has an external storage vulnerability when the comparison result meets preset conditions. This method, by analyzing the code segments related to external storage in the target program and the execution results of the two test code segments, solves the technical problems of inaccurate static analysis and incomplete dynamic detection.

[0073] The above description is merely an overview of the technical solution disclosed herein. In order to better understand the technical means of this disclosure and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this disclosure more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0074] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.

[0075] Figure 1 A flowchart illustrating the vulnerability detection method provided in this embodiment of the disclosure;

[0076] Figure 2 A further flowchart illustrating the vulnerability detection method provided in this embodiment of the disclosure;

[0077] Figure 3 A further flowchart illustrating the vulnerability detection method provided in this embodiment of the disclosure;

[0078] Figure 4 A schematic diagram of the structure of an embodiment of the vulnerability detection device provided in this disclosure;

[0079] Figure 5 This is a schematic diagram of the structure of an electronic device provided according to an embodiment of the present disclosure. Detailed Implementation

[0080] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0081] It should be understood that the steps described in the method embodiments of this disclosure may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this disclosure is not limited in this respect.

[0082] The term "comprising" and its variations as used herein are open-ended inclusions, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the description below.

[0083] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0084] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0085] Figure 1This is a flowchart illustrating an embodiment of the vulnerability detection method provided in this disclosure. The vulnerability detection method provided in this embodiment can be executed by a vulnerability detection device. This vulnerability detection device can be implemented as software, or as a combination of software and hardware. The vulnerability detection device can be integrated into a device within a vulnerability detection system, such as a vulnerability detection terminal or server. Figure 1 As shown, the method includes the following steps:

[0086] Step S101: By decompiling the target program, determine the location of the code segments related to external storage, the read / write method of the code segments, and the path of the external storage file in the target program; wherein, the target program is the program to be detected.

[0087] The target program is an application that may access external storage, such as applications installed on the Android system. It may access external storage to read files from, write files to, or delete files. Reading files from external storage may introduce unknown risks to the application; writing files to external storage may leak sensitive information; and deleting files from external storage may delete important files. Therefore, all of these actions could pose risks to the application.

[0088] In this step, the target program is decompiled, and the code of the decompiled target program is analyzed to obtain the location of code segments related to external storage, the reading and writing methods of code segments, and the path of external storage files.

[0089] For example, after decompiling the target program, based on the APIs or storage path strings related to external storage, the location of the code segments related to external storage in the target program's code is extracted. This includes information such as which module contains which number of lines, the read / write method of the code segments (i.e., whether the code segment reads, writes, or deletes files from external storage), and the storage path of the external storage files. For example, for the Android system, the APIs include, but are not limited to: getExternalStorageDirectory, getExternalStoragePublicDirectory, getExternalCacheDir, getExternalCacheDirs, and getExternalMediaDirs; the paths of the external storage files include, but are not limited to: " / sdcard / ", " / storage / emulated / ", and "DCIM".

[0090] By using pattern matching or machine learning algorithms, code snippets can be extracted from the target program's code based on the aforementioned string features. The read / write method of the code snippet can be determined by the API's functionality, the path of the external storage file can be determined by the storage path, and the location of the code snippet can be located in the target program's code using the function names, etc., within the code snippet.

[0091] Return to Appendix Figure 1 The vulnerability detection method further includes step S102: inserting a monitoring program at the location of the code segment.

[0092] To monitor the process, results, and state of the code snippet during the execution of the target program, a monitoring program is inserted at the location of the code snippet, such as using hook technology. For example, the monitoring program is used to record the call stack corresponding to the code snippet, the application's page views, artifacts in the storage path, etc., when the aforementioned API is called or the storage path is used, collecting data for subsequent analysis of external storage vulnerabilities.

[0093] Return to Appendix Figure 1 The vulnerability detection method further includes step S103: running the target program and obtaining the first running result of the code segment through the monitoring program.

[0094] In this step, the target program is run according to a preset process in its initial state. The preset process includes a testing process, which can be implemented using test cases, random triggering, and automated testing.

[0095] Optionally, step S103 further includes:

[0096] The execution process of the target program is controlled according to the test program;

[0097] The monitoring program records the call stack and page view of the code snippet during its execution.

[0098] Taking test cases as an example, after obtaining the code snippets related to external storage and their read / write methods in step S101, corresponding test cases can be designed to allow the target program to execute the code snippets during runtime to obtain the execution results of the code snippets. When using a random triggering method, it is necessary to monitor the coverage of random triggering. When all code snippets related to external storage are covered, the test can be stopped. When using automated testing, the code snippets or functions to be tested can be pre-designed, and then the execution of the target program can be automatically controlled by the testing tool. During the process of controlling the execution of the target program through the testing program, the call stack and page view of the code snippets during execution are recorded by the monitoring program pre-injected in step S102. The call stack is used to store the return address of the code snippet execution result, etc. Under the same initial state, the information stored in the call stack of the same code snippet should be the same. The page view is the page displayed during or after the execution of the code snippet. For example, some applications will display the contents of the read file through the page view after reading the file.

[0099] After the target program finishes running, if a file exists in the path of the extracted external storage file, the contents of the file are recorded; otherwise, no further operations are performed.

[0100] Return to Appendix Figure 1 The vulnerability detection method further includes step S104: performing preset processing on the files on the path of the external storage file according to the read / write method of the code fragment.

[0101] To find vulnerabilities in external storage, it is necessary to predict different operating results based on different read and write scenarios in order to verify the existence of the vulnerabilities.

[0102] Optionally, step S104 further includes:

[0103] Step S201: When the read / write method is reading an external storage file, perform preset processing on the files on the path of the external storage file according to the type of the external storage file;

[0104] Step S202: When the read / write method is writing to an external storage file, a first preset file is set on the path of the external storage file;

[0105] Step S203: When the read / write method is to delete an external storage file, if there is no file on the path of the external storage file, then a second preset file is set on the path of the external storage file.

[0106] In step S201, when the code fragment is read from an external storage file, the type of the file being read will affect the subsequent use of the file by the target program. Therefore, it is necessary to distinguish between different types of files.

[0107] Optionally, the step of performing preset processing on files on the path of the external storage file according to the type of the external storage file further includes:

[0108] Step S301: When the type of the external storage file is an executable file, a preset executable file is stored in the path of the storage file; wherein, the executable file is used to implement a preset function;

[0109] Step S302: When the type of the external storage file is a resource file, configuration file, unknown type file or hidden file, add a mark to the file on the path of the external storage file or store the marked file in the path of the storage file.

[0110] When the external storage file is an executable file, it means that the target program needs to execute the file to achieve a preset function after obtaining it. To determine whether malicious code might damage the application through an executable file, a specific executable file can be constructed and stored in the path of the storage file. The executable file includes, but is not limited to, files with extensions such as .dex, .so, and .jar. Special code matching these file types is constructed within the executable file as a marker. This special code is used to implement preset functions, such as achieving a reverse shell to a specified server or writing a marker to a specific file. The executable file is stored in the path of the storage file so that it can be read when the target program is run again.

[0111] When the external storage file is a resource file, including but not limited to: images, videos, advertisements, H5 files, etc., if such a file exists in the path of the aforementioned storage file, the content of the file is modified and preset tags are set, such as adding specific tag elements to images, adding specific text to H5 files, etc.; if such a file does not exist in the path of the aforementioned storage file, a file that meets the above type is created, the file carries preset tags, and the created file is stored in the path of the aforementioned storage file.

[0112] When the external storage file is a configuration file, including but not limited to files with suffixes such as .json, .ini, and .xml, these files are used to configure the execution logic of the target program. If such a file exists in the path of the storage file, the field content in the file is parsed, and several fields are randomly selected and modified to contain markers or random characters. If such a file does not exist in the path of the storage file, a file of the corresponding type is created, and the file is filled with preset content or a random string. The created file is then stored in the path of the storage file.

[0113] When the external storage file is of an unknown type, since the file type cannot be determined, if the file of the unknown type exists in the path of the storage file, a portion of the content of the file is selected and randomly filled; if the file of the unknown type does not exist in the path of the storage file, a new file is created and the content of the file is filled with random characters, and then the created file is stored in the path of the storage file.

[0114] When the external storage file is a hidden file, typically one prefixed with ".", such files are primarily hidden to prevent user detection, but are transparent to the program and behave like ordinary files. Therefore, the operation is the same as for the unknown types mentioned above.

[0115] After the above steps S301 and S302, the pre-processed files are preset on the storage file path, and different processing methods are used for different file types, so that each file type can be processed accordingly.

[0116] In step S202, when the read / write mode of the code segment is to write to an external storage file, since the file type does not affect the writing logic, it is only necessary to pre-set a first preset file with the same file name as the file specified in the write instruction in the file path of the storage file. In this way, when the code segment is executed subsequently, the code segment will write the information to the first preset file.

[0117] In step S203, when the read / write mode of the code fragment is to delete the file in the storage file path, the corresponding file can be stored on the external storage file path according to the vulnerability to be detected. If there is no file on the external storage file path, a file corresponding to the path is set on the path. For example, if the path is "DCIM", then if there is no picture in the album, a preset picture is stored in the album.

[0118] After steps S201 to S203, corresponding files are set for the storage path corresponding to each read / write method, whether modifying existing files or creating new files, and the changes these files bring to the target program are predictable.

[0119] Return to Appendix Figure 1 The vulnerability detection method further includes step S105: running the target program again and obtaining the second running result of the code segment through the monitoring program.

[0120] Before running the target program again, in order to ensure that the initial state of the target program is the same as when the target program was run for the first time, after running the target program and obtaining the first running result of the code segment through the monitoring program, the method further includes: clearing the cached data of the target program and restoring the target program to its initial state.

[0121] Optionally, step S105 further includes:

[0122] The target program's execution process is controlled again based on the test procedure;

[0123] The monitoring program records the call stack and page view of the code snippet during its re-run.

[0124] The test program used in this step is the same as that used in step S103, that is, it uses the same test cases, or it uses pre-recorded randomly triggered actions to perform the same actions as in step S103, or it uses the same automated test program. This ensures that the content of the target program is the same, allowing for comparison of the target program's execution results.

[0125] Return to Appendix Figure 1 The vulnerability detection method further includes step S106: comparing the first running result and the second running result to obtain an external storage vulnerability; wherein, obtaining the external storage vulnerability includes: when the comparison result meets preset conditions, determining that the target program has an external storage vulnerability.

[0126] Different types of comparison results can correspond to different preset conditions.

[0127] Optionally, the first and second execution results may include a call stack and / or a page view, etc.

[0128] Optionally, step S106 further includes:

[0129] Comparing the call stack in the first execution result with the call stack in the second execution result reveals an external storage vulnerability; or,

[0130] The external storage vulnerability was identified by comparing the page views in the first run result and the page views in the second run result.

[0131] In the above steps, the call stacks in the first and second execution results are compared. If the call stack has changed, a vulnerability in external storage is determined. Alternatively, in the above steps, if the page view in the second execution result has changed compared to the page view in the first execution result, a vulnerability in external storage is determined; or, if a marker not present in the page view of the first execution result appears in the page view of the second execution result, a vulnerability in external storage is determined. In this embodiment, the preset conditions include a change in the call stack, a change in the page view, or the appearance of a marker not present in the page view of the first execution result in the page view of the second execution result, etc., which will not be elaborated further here.

[0132] Specifically, when the code snippet reads and writes files from external storage, and the file type is an executable file, it can be determined whether the call stack of the code snippet has changed. Since executable files generally implement specific functions, such as implementing a reverse shell to a specified server as mentioned above, checking the call stack of the code snippet can determine whether the executable file has been executed. If it has been executed, it means the executable file's function has been implemented in the target program. If the executable file contains malicious code, it will damage the target program, indicating an external storage vulnerability. Additionally, for executable files that can generate markers, the existence of storage vulnerabilities can be determined by comparing page views. For example, if the executable file's function is to write a marker to a specific file (i.e., write a preset marker to a specific file), opening the specific file and comparing the view to see if the preset marker exists can determine if a storage vulnerability exists. During the comparison, it can be determined whether the page views in the first and second execution results are the same. If they are different, it is determined that the preset marker was generated in the second page view. Alternatively, the existence of the preset marker can also be determined directly through the page view in the second execution result.

[0133] When the code snippet reads and writes files from external storage, and the type of the read file is a resource file, the existence of a storage vulnerability can be determined by comparing the page views recorded during the two runs of the target program. As mentioned above, since the files in the storage file path are marked, the existence of a storage vulnerability can be determined by judging whether the page view of the second run result includes the marked information. Alternatively, for more accurate results, the page view of the first run result can be used as a reference, comparing the page view of the first run result with the page view of the second run result. If the marked information is not present in the page view of the first run result but is present in the page view of the second run result, a storage vulnerability is determined to exist.

[0134] When the code snippet reads and writes files from external storage, and the file type is a configuration file, the call stack of the code snippet is also checked for changes to determine if a storage vulnerability exists. Because the configuration file is related to the execution logic of the target program, if the configuration file contains markers or random characters that the target program cannot understand, the program will crash. Therefore, by checking for crashes or other anomalies in the target program and observing differences in the call stacks before and after the crashes, a storage vulnerability can be determined.

[0135] When the code snippet reads and writes files from external storage, and the type of the file being read is an unknown type or a hidden type, since the file type is unknown, the existence of a storage vulnerability can be determined by the call stack and / or page view. The method of determination is the same as that for other types of files mentioned above, and will not be repeated here.

[0136] When the code snippet reads and writes to a file on external storage, a vulnerability can be determined by checking whether the file on external storage contains sensitive information after the second execution. For example, sensitive information includes, but is not limited to, the following:

[0137] User information: User information refers to information related to a user's identity, including but not limited to the user's mobile phone number, ID card number, biometric information such as facial recognition and fingerprints, login account, login password, etc.

[0138] Target program information: Target program information refers to the output of the target program during execution, including but not limited to application log files, cookies, tokens, keys, traffic data, core files of the program, etc.

[0139] Device information: Device information specifically refers to fields that can uniquely identify a device, including but not limited to IMEI, IMSI, serial number, Android ID, and other information that can be used to track users.

[0140] By analyzing whether files on external storage contain this information, it is possible to determine whether an external storage vulnerability exists. Understandably, when detecting vulnerabilities, the aforementioned sensitive information can be pre-defined sensitive information used for testing, i.e., information written to files on external storage by a testing program.

[0141] When the code snippet involves deleting files from external storage, the risks vary depending on the scenario. For example, deleting the photo album directory might trigger a warning from the phone manufacturer; deleting core data required by the target program could cause it to crash indefinitely; deleting advertising resource files might remove application ads. For special types of external storage data, in addition to considering the possibility of leakage, the risk of malicious deletion must also be considered. Deleting files from external storage can include the following scenarios: deleting files in user privacy directories such as photo albums triggers system pop-ups or rejection alerts; deleting specific data causes changes in application stability, such as crashes or automatic restarts; deleting specific resource files causes changes in application content, such as removing ads or not displaying core content; deleting specific configuration files causes changes in application state, such as logging out or losing user data; and other potential privacy and security issues. Therefore, for deletion scenarios, it is necessary to monitor the call stack and / or page view to determine if any risks have occurred after deletion. For example, changes in the call stack can reveal program stability issues, and page view can reveal whether alerts are present.

[0142] In this way, by recording the results of running the target program normally and the results of running the target program again after pre-processing, it is possible to determine whether the target program has vulnerabilities in external storage.

[0143] Furthermore, the external storage vulnerabilities discovered in the above steps will be summarized and displayed on a display device in a preset format to facilitate user analysis. This preset display format may include external storage vulnerability reports, external storage vulnerability alerts, etc.

[0144] In this embodiment, the above steps first extract the location, path, and read / write methods of code segments related to external storage. Then, a monitoring program monitors the execution process and results of the target program. Based on the read / write methods and file types, the files in the external storage are preprocessed accordingly. The target program is then run again, and its execution process and results are monitored. The results of the two executions are compared to identify vulnerabilities in the external storage. Compared to static analysis and dynamic detection, the method in this embodiment solves the problems of simplistic conclusions from static analysis and incompleteness from dynamic detection.

[0145] Although the steps in the above method embodiments have been described in the above order, those skilled in the art should understand that the steps in the embodiments of this disclosure are not necessarily executed in the above order. They can also be executed in reverse, in parallel, or in other orders. Moreover, those skilled in the art can add other steps based on the above steps. These obvious variations or equivalent substitutions should also be included within the protection scope of this disclosure, and will not be elaborated here.

[0146] Figure 4 This is a schematic diagram of the structure of an embodiment of the vulnerability detection device provided in this disclosure. Figure 4 As shown, the device 400 includes: a decompilation module 401, an insertion module 402, a testing module 403, a file processing module 404, and a comparison module 405. Among them,

[0147] The decompilation module 401 is used to determine the location of code segments related to external storage, the read / write method of the code segments, and the path of external storage files in the target program by decompiling the target program; wherein, the target program is the program to be detected;

[0148] Insertion module 402 is used to insert a monitoring program at the location of the code segment;

[0149] Test module 403 is used to run the target program and obtain the first running result of the code segment through the monitoring program;

[0150] The file processing module 404 is used to perform preset processing on the files on the path of the external storage file according to the read and write method of the code fragment;

[0151] The test module 403 is also used to run the target program again and obtain the second running result of the code segment through the monitoring program;

[0152] The comparison module 405 is used to compare the first running result and the second running result to obtain an external storage vulnerability; wherein, obtaining the external storage vulnerability includes: when the comparison result meets the preset conditions, determining that the target program has an external storage vulnerability.

[0153] Furthermore, the file processing module 404 is also used for:

[0154] When the read / write method is to read external storage files, the files on the path of the external storage file are pre-processed according to the type of the external storage file;

[0155] When the read / write method is to write to an external storage file, a first preset file is set on the path of the external storage file;

[0156] When the read / write method is to delete an external storage file, if there is no file on the path of the external storage file, then a second preset file is set on the path of the external storage file.

[0157] Furthermore, the file processing module 404 is also used for:

[0158] When the type of the external storage file is an executable file, a preset executable file is stored in the path of the storage file; wherein, the executable file is used to implement a preset function;

[0159] When the type of the external storage file is a resource file, configuration file, unknown type file, or hidden file, add a mark to the file on the path of the external storage file or store the marked file in the path of the storage file.

[0160] Furthermore, the filename of the first preset file is the same as the filename in the write instruction.

[0161] Furthermore, the test module 403 is also used for:

[0162] The execution process of the target program is controlled according to the test program;

[0163] The monitoring program records the call stack and page view of the code snippet during its execution.

[0164] Furthermore, the test module 403 is also used for:

[0165] The target program's execution process is controlled again based on the test procedure;

[0166] The monitoring program records the call stack and page view of the code snippet during its re-run.

[0167] Furthermore, the comparison module 405 is also used for:

[0168] Comparing the call stack in the first execution result with the call stack in the second execution result reveals an external storage vulnerability; or,

[0169] The external storage vulnerability was identified by comparing the page views in the first run result and the page views in the second run result.

[0170] Furthermore, the comparison module 405 is also used for:

[0171] If the call stack in the second execution result has changed compared to the call stack in the first execution result, then a vulnerability exists in the external storage.

[0172] Furthermore, the comparison module 405 is also used for:

[0173] If the page view in the second execution result has changed compared to the page view in the first execution result, then a vulnerability is determined to exist in the external storage; or,

[0174] If a marker that is not present in the page view of the first run result appears in the page view of the second run result, then a vulnerability is identified in the external storage.

[0175] Furthermore, the device 400 also includes a cleaning module for:

[0176] Clear the cached data of the target program and restore the target program to its initial state.

[0177] Figure 4 The device shown can perform Figure 1-3 For the methods shown in the embodiments, the parts not described in detail in this embodiment can be referred to the following: Figure 1-3 The relevant descriptions of the illustrated embodiments are provided below. For the execution process and technical effects of this technical solution, please refer to [link / reference]. Figure 1-3 The descriptions in the illustrated embodiments will not be repeated here.

[0178] The following is for reference. Figure 5 The diagram illustrates a structural schematic of an electronic device 500 suitable for implementing embodiments of the present disclosure. The terminal devices in the embodiments of the present disclosure may include, but are not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0179] like Figure 5 As shown, the electronic device 500 may include a processing unit (e.g., a central processing unit, a graphics processor, etc.) 501, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 502 or a program loaded from a storage device 508 into a random access memory (RAM) 503. The RAM 503 also stores various programs and data required for the operation of the electronic device 500. The processing unit 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0180] Typically, the following devices can be connected to I / O interface 505: input devices 506 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 507 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 508 including, for example, magnetic tapes, hard disks, etc.; and communication devices 509. Communication device 509 allows electronic device 500 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 5 An electronic device 500 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0181] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 509, or installed from a storage device 508, or installed from a ROM 502. When the computer program is executed by the processing device 501, it performs the functions defined in the methods of embodiments of this disclosure.

[0182] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0183] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0184] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0185] The aforementioned computer-readable medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to perform the vulnerability detection method described in the above embodiments.

[0186] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof, including but not limited to object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0187] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0188] The units described in the embodiments of this disclosure can be implemented in software or hardware. The names of the units are not, in some cases, intended to limit the specific unit.

[0189] The functions described above in this document can be performed, at least in part, by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: Field Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application Standard Products (ASSPs), System-on-Chip (SoCs), Complex Programmable Logic Devices (CPLDs), and so on.

[0190] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0191] According to one or more embodiments of the present disclosure, an electronic device is provided, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform any of the vulnerability detection methods described in the first aspect above.

[0192] According to one or more embodiments of the present disclosure, a non-transitory computer-readable storage medium is provided, characterized in that the non-transitory computer-readable storage medium stores computer instructions for causing a computer to perform any of the vulnerability detection methods described in the first aspect above.

[0193] The above description is merely a preferred embodiment of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features disclosed in this disclosure that have similar functions.

Claims

1. A vulnerability detection method characterized by, The application relates to a method for detecting external storage vulnerabilities. The method comprises the following steps: determining the position of a code segment related to external storage in a target program, the read-write mode of the code segment and the path of an external storage file by decompiling the target program, wherein the target program is a program to be detected; inserting a monitoring program at the position of the code segment; running the target program and obtaining a first running result of the code segment through the monitoring program; performing preset processing on a file at the path of the external storage file according to the read-write mode of the code segment; running the target program again and obtaining a second running result of the code segment through the monitoring program; comparing the first running result and the second running result to obtain an external storage vulnerability; wherein the external storage vulnerability is obtained by determining that the target program has an external storage vulnerability when a comparison result meets a preset condition; wherein the preset processing on the file at the path of the external storage file according to the read-write mode of the code segment comprises: when the read-write mode is reading an external storage file, performing preset processing on the file at the path of the external storage file according to the type of the external storage file; when the read-write mode is writing an external storage file, setting a first preset file at the path of the external storage file; when the read-write mode is deleting an external storage file, if there is no file at the path of the external storage file, setting a second preset file at the path of the external storage file; the preset processing on the file at the path of the external storage file according to the type of the external storage file comprises: when the type of the external storage file is an executable file, storing a preset executable file in the path of the external storage file; wherein the executable file is used to realize a preset function; 2. The method of claim 1, wherein, when the type of the external storage file is a resource file, a configuration file, an unknown type file or a hidden file, adding a mark to the file at the path of the external storage file or storing a file with the mark in the path of the external storage file.

3. The method of claim 1, wherein, The file name of the first preset file is the same as that in a write instruction. The running of the target program and the obtaining of the first running result of the code segment through the monitoring program comprise: controlling the running process of the target program according to a test program; 4. The method of claim 3, wherein, recording the call stack and the page view of the code segment in the running process through the monitoring program. The running of the target program again and the obtaining of the second running result of the code segment through the monitoring program comprise: controlling the running process of the target program again according to the test program; 5. The method of claim 4, wherein, recording the call stack and the page view of the code segment in the running process again through the monitoring program. The comparison of the first running result and the second running result to obtain the external storage vulnerability comprises: comparing the call stack in the first running result and the call stack in the second running result to obtain the external storage vulnerability; or comparing the page view in the first running result and the page view in the second running result to obtain the external storage vulnerability.

6. The method of claim 5, wherein, The comparison of the call stack in the first running result and the call stack in the second running result obtains the external storage vulnerability, and the comparison includes: If the call stack in the second running result is changed compared with the call stack in the first running result, it is determined that the external storage has a vulnerability.

7. The method of claim 5, wherein, The comparison of the page view in the first running result and the page view in the second running result obtains the external storage vulnerability, and the comparison includes: If the page view in the second running result is changed compared with the page view in the first running result, it is determined that the external storage has a vulnerability; or If a mark appears in the page view in the second running result, which does not exist in the page view in the first running result, it is determined that the external storage has a vulnerability.

8. The method of claim 1, wherein, After the target program is run and the first running result of the code segment is obtained by the monitoring program, the method further includes: Clearing the cache data of the target program, and restoring the target program to an initial state.

9. A vulnerability detection apparatus characterized by comprising: The method includes: A decompilation module is configured to determine the position of a code segment related to external storage, the read-write mode of the code segment, and the path of an external storage file in a target program by decompiling the target program, wherein the target program is a program to be detected; An insertion module is configured to insert a monitoring program at the position of the code segment; A test module is configured to run the target program and obtain a first running result of the code segment by the monitoring program; A file processing module is configured to perform a preset processing on a file at the path of the external storage file according to the read-write mode of the code segment; The test module is further configured to run the target program again and obtain a second running result of the code segment by the monitoring program; A comparison module is configured to compare the first running result and the second running result to obtain an external storage vulnerability, wherein the obtaining of the external storage vulnerability includes: when a comparison result meets a preset condition, it is determined that the target program has an external storage vulnerability. The file processing module is specifically configured to: When the read-write mode is reading an external storage file, perform a preset processing on a file at the path of the external storage file according to the type of the external storage file; When the read-write mode is writing an external storage file, set a first preset file at the path of the external storage file; When the read-write mode is deleting an external storage file, if there is no file at the path of the external storage file, set a second preset file at the path of the external storage file; The preset processing on the file at the path of the external storage file according to the type of the external storage file includes: When the type of the external storage file is an executable file, store a preset executable file in the path of the storage file, wherein the executable file is used to implement a preset function; When the type of the external storage file is a resource file, a configuration file, an unknown type file, or a hidden file, add a mark to the file at the path of the external storage file or store a file with a mark in the path of the storage file.

10. An electronic device, comprising: a memory configured to store computer-readable instructions; and a processor configured to execute the computer-readable instructions. a processor configured to execute the computer readable instructions, such that the processor, when executing, implements the method of any of claims 1-8.

11. A non-transitory computer readable storage medium storing computer readable instructions which, when executed by a computer, cause the computer to perform the method of any of claims 1-8.

Images