Sample file processing method and apparatus, and computer-readable storage medium

By detecting sample files in multiple operating environments and generating a comprehensive report, the problem of poor detection quality caused by single-environment detection in existing technologies is solved, and more comprehensive sample file detection is achieved.

CN115630359BActive Publication Date: 2026-11-06HILLSTONE NETWORKS CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202211058676.7
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2022-08-31
Publication Date
2026-11-06
Estimated Expiration
2042-08-31

AI Technical Summary

Technical Problem

Existing technologies only detect sample files in a single operating environment, resulting in one-sided detection results and an inability to fully identify abnormal behavior in sample files.

Method used

The sample files are sent to multiple target runtime environments for testing, the test results of each environment are obtained, and a comprehensive test report is generated. It supports custom and pre-deployed runtime environments and uses virtual machines to run sample files and perform data analysis.

Benefits of technology

It enables comprehensive detection of sample files under various environments, improving the accuracy and efficiency of detection and enabling more accurate identification of abnormal sample files.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN115630359B_ABST
    Figure CN115630359B_ABST
Patent Text Reader

Abstract

The application discloses a sample file processing method and device and a computer readable storage medium. The method comprises the following steps: obtaining a sample file to be detected; conveying the sample file to at least one target running environment for detection; obtaining a detection result of the sample file in each target running environment, wherein the detection result is used to represent whether the sample file is abnormal when running in each target running environment; generating a target detection report according to the detection result, and sending the target detection report to a target device. The application solves the technical problem of poor sample file detection quality caused by detecting the sample file in a single running environment in the prior art.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of information security, and more specifically, to a method, apparatus, and computer-readable storage medium for processing sample files. Background Technology

[0002] In the field of information security, testers typically examine sample files in a specific runtime environment to identify whether they are anomalous. Existing technologies often utilize container technology to create a virtual runtime environment, then run the sample file to be tested within this virtual environment. By acquiring the runtime log data of the sample file after it has run in the virtual environment, the anomaly of the sample file is determined.

[0003] However, in the actual application environment of file detection, a sample file can often run in multiple operating environments, and its behavior may not be the same in different operating environments. Since the existing technology is limited to detecting sample files in one operating environment, it can only detect the running behavior of sample files in one operating environment at most, which leads to the one-sidedness of the sample file detection results and the inability to fully detect the sample file.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This application provides a method, apparatus, and computer-readable storage medium for processing sample files, so as to at least solve the technical problem in the prior art that the sample file detection quality is poor due to the fact that sample files are only detected in a single operating environment.

[0006] According to one aspect of the embodiments of this application, a method for processing a sample file is provided, comprising: acquiring a sample file to be detected; sending the sample file to at least one target operating environment for detection; acquiring the detection results of the sample file in each target operating environment, wherein the detection results are used to characterize whether there is an anomaly when the sample file is run in each target operating environment; generating a target detection report based on the detection results, and sending the target detection report to a target device.

[0007] Furthermore, the sample file processing method also includes: identifying the file type of the sample file and the user identifier corresponding to the sample file, wherein the user identifier is used to represent the user who uploaded the sample file; determining the preference setting conditions corresponding to the sample file based on the file type and the user identifier, wherein the preference setting conditions are used to constrain the binding relationship between the file type and at least one target runtime environment, and each user identifier corresponds to one preference setting condition; determining at least one target runtime environment from multiple pre-deployed runtime environments based on the preference setting conditions, and sending the sample file to at least one target runtime environment for detection.

[0008] Furthermore, the sample file processing method also includes: responding to a runtime environment creation request, determining a first runtime environment from at least one pre-deployed fixed runtime environment, wherein the multiple runtime environments include at least one fixed runtime environment, the fixed runtime environment being a runtime environment after system configuration adjustment, the system configuration being used to configure the fixed runtime environment to a runtime environment that enables the sample file to exhibit abnormal behavior; adjusting the first runtime environment to obtain a new runtime environment, wherein the environment adjustment includes at least operating system adjustment and / or software adjustment.

[0009] Furthermore, the sample file processing method also includes: after adjusting the environment of the first running environment to obtain a new running environment, uploading the new running environment to a preset storage area, and setting the status of the new running environment to a shared state, wherein the shared state is used to indicate that the new running environment is visible to all users, and each user can set preference settings based on the new running environment, and multiple running environments are stored in the preset storage area.

[0010] Furthermore, the sample file processing method also includes: converting each target runtime environment into a virtual machine and running the sample file on the virtual machine; obtaining runtime record data of the sample file running in the virtual machine; performing data filtering processing on the runtime record data to obtain target data, wherein the data filtering processing is used to filter invalid data in the runtime record data; and analyzing the target data to obtain detection results.

[0011] Furthermore, the method for processing the sample file also includes: obtaining the runtime of the sample file in the virtual machine; when the runtime exceeds a preset duration, prohibiting the sample file from continuing to run, and updating the running status of the sample file to the running completed state.

[0012] Furthermore, the sample file processing method also includes: each target runtime environment corresponds to multiple virtual machines, and each virtual machine can run the sample file. Before running the sample file on the virtual machine, it is detected whether there is an idle virtual machine among the multiple virtual machines. If there is no idle virtual machine among the multiple virtual machines, the working status of each virtual machine is monitored, and when an idle virtual machine is detected, the sample file is sent to that virtual machine so that the sample file can be run through that virtual machine.

[0013] Furthermore, the sample file processing method also includes: generating a detection report based on the detection results of the sample file in a target operating environment; comprehensively analyzing all detection reports corresponding to at least one target operating environment to obtain a target detection report, and sending the target detection report to the target device.

[0014] According to another aspect of the embodiments of this application, a sample file processing apparatus is also provided, comprising: a first acquisition module for acquiring a sample file to be detected; a transport module for transporting the sample file to at least one target operating environment for detection; a second acquisition module for acquiring the detection results of the sample file in each target operating environment, wherein the detection results are used to characterize whether there is an anomaly when the sample file is run in each target operating environment; and a generation module for generating a target detection report based on the detection results and sending the target detection report to a target device.

[0015] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, which stores a computer program, wherein the computer program is configured to execute the above-described sample file processing method when it runs.

[0016] In this application, a method is adopted to simultaneously send a sample file to at least one operating environment for detection. After obtaining the sample file to be detected, the sample file is sent to at least one target operating environment for detection. Then, the detection results of the sample file in each target operating environment are obtained, and a target detection report is generated based on the detection results and sent to the target device. The detection results are used to characterize whether there are any anomalies in the sample file during runtime in each target operating environment.

[0017] As can be seen from the above, this application can obtain at least one detection result by sending the sample file to at least one target operating environment for simultaneous detection. Therefore, compared with the prior art, this application performs more comprehensive detection on the sample file, enabling the sample file to exhibit abnormal behavior in more operating environments, thereby more accurately identifying abnormal sample files and improving the detection efficiency and quality of sample files.

[0018] Therefore, the technical solution of this application achieves the goal of detecting sample files based on at least one operating environment, thereby improving the detection quality of the detection results and solving the technical problem of poor sample file detection quality caused by detecting sample files only in a single operating environment in the prior art. Attached Figure Description

[0019] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0020] Figure 1 This is a flowchart of an optional sample file processing method according to an embodiment of this application;

[0021] Figure 2 This is a schematic diagram of an optional sample document detection system according to an embodiment of this application;

[0022] Figure 3 This is a schematic diagram of a custom operating environment according to an embodiment of this application;

[0023] Figure 4 This is a schematic diagram of a preference setting condition according to an embodiment of this application;

[0024] Figure 5 This is a timing diagram of a custom runtime environment being converted into a virtual machine according to an embodiment of this application;

[0025] Figure 6 This is a timing diagram of a test sample file under an optional multi-running environment according to an embodiment of this application;

[0026] Figure 7 This is an example diagram of detection results under an optional multi-operational environment according to an embodiment of this application;

[0027] Figure 8 This is a schematic diagram of an optional sample file processing apparatus according to an embodiment of this application. Detailed Implementation

[0028] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0029] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0030] Furthermore, it should be noted that all information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for display, data used for analysis, etc.) disclosed herein are information and data authorized by the user or fully authorized by all parties. For example, this system has interfaces with relevant users or organizations. Before obtaining relevant information, it is necessary to send an acquisition request to the aforementioned user or organization through the interface, and obtain the relevant information only after receiving consent from the aforementioned user or organization.

[0031] Example 1

[0032] According to an embodiment of this application, an embodiment of a method for detecting sample files is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0033] Figure 1 This is a flowchart of an optional sample file processing method according to an embodiment of this application, such as... Figure 1 As shown, the method includes the following steps:

[0034] Step S101: Obtain the sample file to be tested.

[0035] In step S101, the sample file can be of various types, such as a program script, a video file, a compressed file, and an email, etc.

[0036] In an optional embodiment, a sample document detection system can serve as the execution entity for the sample document detection method in this application, such as... Figure 2As shown, the sample file detection system includes at least a management server and node servers. These two types of servers have a one-to-many relationship, meaning one management server can correspond to multiple node servers. Since the functional design and responsibilities of multiple node servers are identical, for ease of explanation, the following description uses a single node server as an example.

[0037] Optionally, the management server may include at least the following functional modules: preference configuration management module, sample and report management module, runtime environment library management module, scheduling management module, detection result management module, and node management module. The sample and report management module receives sample files uploaded by users and provides users with sample detection results and report download functionality. This module comprises two sub-modules: a sample management sub-module and a report management sub-module. The sample management sub-module is primarily responsible for preprocessing sample files, saving sample files, and maintaining sample-related information. Upon receiving a sample file uploaded by a user, the sample management sub-module identifies the file type, records relevant information such as the user, upload time, file type, and MD5 / SHA1 / SHA256 hash, and saves the sample file. Each sample file can be uniquely mapped to its MD5 / SHA1 / SHA256 hash. The report management sub-module is primarily responsible for storing sample detection reports and handling and maintaining the correspondence between reports and samples.

[0038] Step S102: Send the sample file to at least one target operating environment for detection.

[0039] In step S102, the target operating environment can be either a first type of operating environment or a second type of operating environment. The second type of operating environment is a fixed operating environment pre-deployed in the sample file detection system. This second type of operating environment can be understood as the operating environment that comes with the sample file detection system when the user first uses it. The first type of operating environment, on the other hand, is a new operating environment obtained by the user after adjusting an existing second type of operating environment. In other words, the first type of operating environment can be understood as a new operating environment that the user customizes and creates based on the second type of operating environment.

[0040] It should be noted that, unlike existing technologies that only support sending sample files to one operating environment for detection, the sample file detection system in this application supports sending sample files to multiple operating environments simultaneously for detection, thereby obtaining more detection results, achieving more thorough and comprehensive detection of sample files, and improving the detection effect of sample files.

[0041] Step S103: Obtain the detection results of the sample file in each target operating environment.

[0042] In step S103, the detection results are used to characterize whether there are any anomalies in the sample file when it is run in each target runtime environment.

[0043] Optionally, after the sample file is delivered to at least one target runtime environment, the sample file detection system will acquire the runtime record data of the sample file in each target runtime environment, and determine the corresponding detection result of the sample file in each target runtime environment based on the runtime record data. It should be noted that if the file behavior exhibited by the sample file in a certain target runtime environment is abnormal, the sample file will be identified as an abnormal sample file, and a corresponding abnormal detection result will be generated based on the abnormal behavior.

[0044] Step S104: Generate a target detection report based on the detection results and send the target detection report to the target device.

[0045] In one optional embodiment, since each target runtime environment corresponds to one detection result, after the sample file is sent to at least one target runtime environment for detection, the sample file detection system will ultimately obtain at least one detection result. Based on this, the sample file detection system can generate a target detection report on the sample file in the following two ways.

[0046] The first method is to generate a detection report based on the detection results of the sample file in a target operating environment, then comprehensively analyze all the detection reports corresponding to at least one target operating environment to obtain the target detection report, and then send the target detection report to the target device.

[0047] It should be noted that since users view the target detection report through the target device, they will directly see the target detection report, not the detection report itself. If a user wants to view the detection results under a specific target operating environment, they can send a request carrying the target operating environment identifier to the sample file detection system through the target device. After receiving the request, the sample file detection system will send the detection report under the target operating environment corresponding to the target operating environment identifier to the target device for the user to view.

[0048] The second approach involves obtaining at least one detection result, performing a comprehensive analysis on that result, generating a target detection report based on the analysis, and then sending the report to the target device.

[0049] It should be noted that in the second method, a separate test report is not generated for each test result. Instead, a single target test result is generated after comprehensively analyzing all test results. This saves storage resources and improves the efficiency of target test report generation.

[0050] In an optional embodiment, in order to illustrate the technical solution of this application in more detail, each functional module of the sample document detection system in this application will be described in detail below.

[0051] As can be seen from the above, in addition to the sample and report management module, the management server also includes a runtime environment library management module, a scheduling management module, a test result management module, a node management module, and a preference configuration management module.

[0052] Among them, such as Figure 2 As shown, the preference configuration management module handles preference setting requests from users, recording and maintaining preference setting conditions. Preference setting conditions characterize the relationship between the file type of a sample file and the specified runtime environment; this is a one-to-many relationship, meaning one file type can correspond to multiple runtime environments. When a user specifies multiple runtime environments for a file type, the management server will treat subsequent uploaded sample files of this file type as a multi-environment detection task and process them accordingly. For file types where the user has not explicitly specified a runtime environment, the preference configuration management module provides a preset runtime environment determination strategy, which can be understood as a default preference strategy that cannot be changed by the user. When a user uploads a sample file whose file type does not have a corresponding preference setting condition, the preference configuration management module will assign a default runtime environment to the sample file according to the preset runtime environment determination strategy.

[0053] In addition, such as Figure 2As shown, the functions of the sample and report management module have been described in the introduction of step S101 above, and will not be repeated here. However, it should be noted that in order to reduce sample detection time and maximize the reuse of detection results to save resources, the report management submodule in the sample and report management module also serves as a report cache resource library. When the sample management submodule receives a sample file uploaded by the user, it will query the report cache resource library through the report management submodule to see if there is a ready-made detection report available. If so, the detection report will be returned to the user; otherwise, the sample file will be submitted to the scheduling management module for processing. The report cache resource library maintains the correspondence between the detection report, sample file, and operating environment, recording which sample file a detection report corresponds to and under which operating environments the sample file was detected. The report management submodule processes the detection results from the detection result management module to generate detection reports for display and download by the user. The detection reports in this application have a fixed format, such as HTML reports or PDF reports.

[0054] Optional, such as Figure 2 As shown, the runtime environment library management module stores and maintains runtime environment templates (corresponding to the second type of runtime environment) for users to download. Simultaneously, the runtime environment library management module receives custom runtime environments uploaded by users (corresponding to the first type of runtime environment), records and maintains information related to these custom runtime environments and their correspondence with users. The runtime environment refers to the operating system environment in which the sample file is started and run during subsequent detection, distinguished by operating system type, enabled / disabled system services, and software installed to run or load the sample file. The runtime environment template is provided by default by the runtime environment library management module. To ensure the accuracy of malicious sample detection and reduce false negatives, the runtime environment template optimizes the use of system services on different operating systems and intentionally disables some system-level protection measures to provide a good system environment for malicious sample operation. Therefore, users are not allowed to modify or change the runtime environment template.

[0055] The customizable runtime environment design allows users to make adjustments to the runtime environment template to better reflect the actual office environment. This enables sample files to be detected and analyzed in a manner that closely resembles the user's actual usage environment. Consequently, the detection results obtained in the customizable runtime environment are more meaningful to users and can help them identify weaknesses in their existing office environment in a timely manner.

[0056] Optional, such as Figure 2As shown, the scheduling management module is responsible for scheduling the detection and analysis of sample files. Based on the preference settings of the preference setting module, it plans a scheduling strategy for the sample files and sample-related information uploaded by the sample and report management modules. Through load balancing strategies, the sample files are scheduled to various node servers for detection and analysis, or historical detection results in the detection result management module are reused.

[0057] Optional, such as Figure 2 As shown, the detection result management module is used to receive the detection results of sample files returned from each node server in a single running environment, process and summarize all the detection results, and record and maintain the correspondence between the detection results and sample files, the correspondence between the detection results and the running environment, etc., so as to facilitate the reuse of historical detection results by the subsequent scheduling management module.

[0058] It's important to note the difference and connection between detection results and target detection reports. Detection results are the output of a sample file running in a single environment; they are the raw data of the sample's behavior during operation, not presented in a fixed format such as a JSON file. Target detection reports, on the other hand, can be a synthesis of detection results from multiple environments. This synthesis is generally derived from further refinement, processing, and summarization of the results from multiple single environments, ultimately presented in a fixed format. In short, detection results are raw data, while reports are the presentation format.

[0059] Optional, such as Figure 2 As shown, the node management module is responsible for managing each node server and synchronizing the user-uploaded custom runtime environment to each node server. Then, each node server converts the custom runtime environment into a specific virtual machine for running sample files and performing sample detection and analysis tasks.

[0060] It is important to note that when a new node server joins the sample file detection system of this application, it must first complete registration with the node management module. After registration, the node management module is responsible for synchronizing the various runtime environments and instructing the new node server to complete the configuration management of virtual machines according to the default virtual machine configuration information. Therefore, the node management module records and maintains the correspondence and quantity relationship between the existing runtime environments and virtual machines on each node server. In addition to synchronizing the runtime environments and managing the node servers, the node management module also counts the number of virtual machines running on each node server in real time, providing data support for the scheduling management module to perform load balancing.

[0061] In one alternative embodiment, such as Figure 2As shown, each node server includes at least a detection management module, a virtual machine management module, and a runtime record analysis module, as well as at least one virtual machine converted according to the runtime environment.

[0062] Among them, such as Figure 2 As shown, the detection management module receives sample files and specified runtime environment information uploaded by the scheduling management module in the management server. With the assistance of the virtual machine management module, it sends the sample files to the specified virtual machines for execution. Then, it receives the detection results generated by the runtime record analysis module and forwards them to the detection result management module in the management server for further processing. When all virtual machines corresponding to the specified runtime environment are busy, the detection management module also implements queue buffering to temporarily cache the current sample files. When a virtual machine becomes available for the specified runtime environment, the cached sample files are then sent to the idle virtual machine for execution and analysis.

[0063] Optional, such as Figure 2 As shown, the virtual machine management module, acting as an assistant module to the detection management module, receives sample files from the detection management module and starts virtual machines corresponding to the specified runtime environment for the detection management module to run the sample files. After the sample files have finished running, the virtual machine management module collects runtime record data about the sample files on the virtual machines and sends the runtime record data to the runtime record analysis module. Additionally, the virtual machine management module also receives runtime environments synchronized from the management server and, based on default virtual machine information, converts the runtime environment into a preset number of virtual machines. For example, in... Figure 2 In the middle, node server 1 is deployed with virtual machine 1 converted from runtime environment 1, virtual machine 2 converted from runtime environment 2, and virtual machine 3.

[0064] Optional, such as Figure 2 As shown, the runtime log analysis module is responsible for processing runtime log data. After obtaining the runtime log data, the module removes redundant and extraneous information according to predetermined logic, and further simplifies and summarizes the effective information to form clear and easy-to-read detection results. These results are then sent to the detection management module. It should be noted that runtime log data comes not only from records on the virtual machine but also from records in the virtual machine's external environment. This external environment includes peripheral devices such as the virtual network adapter, and runtime log data includes, but is not limited to, log files, screenshot files, network traffic files, memory binary files, and system configuration modification log files.

[0065] In one optional embodiment, this application supports users in creating custom runtime environments based on pre-deployed fixed runtime environments (corresponding to the second type of runtime environment). Specifically, in response to a runtime environment creation request, the sample file detection system determines a first runtime environment from at least one pre-deployed fixed runtime environment. The multiple runtime environments include at least one fixed runtime environment, which is a runtime environment adjusted by the system configuration. The system configuration is used to configure the fixed runtime environment to enable the sample file to exhibit abnormal behavior. The sample file detection system then performs environment adjustments on the first runtime environment to obtain a new runtime environment. These environment adjustments include at least adjustments to the operating system and / or software.

[0066] Optional, Figure 3 A schematic diagram of a custom runtime environment according to an embodiment of this application is shown, wherein, Figure 3 The runtime environment template in the text is the fixed runtime environment mentioned above, also known as the second type of runtime environment. Figure 3 The custom runtime environment mentioned above refers to the new runtime environment. Specifically, in this application, the main features of the runtime environment template are reflected in three aspects: operating system, system services, and installed software.

[0067] Among them, such as Figure 3 As shown, operating systems are distinguished by system version and system bitness. For example, Windows operating systems have multiple versions such as Windows 7 and Windows 10, with Windows 7 also having 32-bit and 64-bit versions. Linux systems have multiple versions such as Ubuntu 16.04, Ubuntu 18.04, and CentOS 7, with Ubuntu 16.04 also having 32-bit and 64-bit versions. System services are distinguished by built-in system services and custom services. Built-in system services are mainly reflected in which services are enabled and disabled, while custom services are mainly reflected in whether certain services have been added to manage individual applications and programs after removing the built-in system services. Installed software is distinguished by software name and software version. For example, PDF files can be opened by various applications and some system browsers, but different software opening the same PDF file may trigger different underlying system calls, so different software opening the same sample file may correspond to different test results. Meanwhile, with the continuous development of software technology, different versions of software can also affect the detection results. For example, for the same software, an abnormal sample file may successfully attack an older version of the software but fail to attack a newer version, thus generating two different detection results. Furthermore, similar to system services, users can adjust the runtime environment template by adding or deleting software.

[0068] It is noteworthy that, since the behavior of sample files is closely related to their environment, this application supports user-defined runtime environments to better help users discover vulnerabilities in their existing runtime environments and to better explain the attack potential of a particular sample file on their existing runtime environment. Discovering a malicious sample that is specifically designed to attack a user's runtime environment is more important than discovering a generic malicious sample; this application achieves this through customizable runtime environments.

[0069] like Figure 3 As shown, the main characteristics of a custom runtime environment are also reflected in the three aspects of the operating system, system services, and installed software. The difference is that a custom runtime environment can only be customized based on a runtime environment template. The process of customizing a runtime environment first involves selecting a runtime environment template (i.e., the first runtime environment) corresponding to a specific type and version of the operating system. Then, system services are reconfigured on this runtime environment template, including which services to start, stop, and add, as well as managing installed software. For example, a reader software can be installed to run PDF files, replacing the browser-based PDF opening setting in the runtime environment template. This achieves runtime environment customization, making the customized environment as close as possible to and replicating the user's actual office environment.

[0070] It should be noted that in this application, the custom runtime environment can only be customized based on a specific runtime environment template. This is mainly due to the following three considerations: First, the runtime environment template is a calibrated environment, including various complex adjustments to system configuration settings, making it a more suitable platform for sample files to exhibit malicious behavior. Second, when creating a custom runtime environment based on the template, users do not need to perform tedious and complex system configurations, thus making it more user-friendly and reducing the difficulty of configuring a custom runtime environment. Third, when configuring the runtime environment for detecting sample files, some configuration parameters are difficult for those not skilled in the art to find, especially in systems like Windows where various configurations are relatively hidden. Failure to enable a certain configuration may cause the sample file to fail to run, making it impossible to observe the sample's behavior. Based on the above three considerations, this application pre-deploys a runtime environment template with pre-configured system settings. Users only need to make a series of simple adjustments to the operating system and / or software based on the runtime environment template to obtain a custom runtime environment.

[0071] Furthermore, since the ultimate goal of this application is to increase the probability of detecting malicious samples by utilizing multiple operating environments, the operating system configuration cannot always be completely identical to the user environment. For example, if a firewall is enabled or antivirus software is installed in the user environment, malicious sample files are generally less likely to exhibit malicious behavior or even be able to start and run normally. Therefore, if the goal is still to maximize the replication of the user environment, it will be inadvertently overlooked, and the final result may be an inability to accurately detect malicious files.

[0072] Therefore, the custom runtime environment in this application may not be a runtime environment that is exactly the same as the user environment, but rather an environment that depends on a runtime environment template and makes individual adjustments to the features of system services and installed software relative to a certain runtime environment template.

[0073] In one optional embodiment, the sample file management system uploads the new runtime environment to a preset storage area and sets the status of the new runtime environment to a shared state. The shared state indicates that the new runtime environment is visible to all users, and each user can set preference settings based on the new runtime environment. Multiple runtime environments are stored in the preset storage area.

[0074] Optionally, this application will share the custom runtime environment. Specifically, although a custom runtime environment is created by a user, after the custom runtime environment is uploaded to the runtime environment library management module, the runtime environment library management module will set the status of the custom runtime environment to a shared state. That is, the custom runtime environment is shared by all users, and all users can select the configuration preference settings for the custom runtime environment and send sample files to the custom runtime environment for testing.

[0075] In one optional embodiment, each user can configure which runtime environments can receive sample files of each file type. Specifically, the sample file detection system first identifies the file type of the sample file and the corresponding user identifier, where the user identifier represents the user who uploaded the sample file. Then, the sample file detection system determines the preference settings corresponding to the sample file based on the file type and user identifier. These preference settings constrain the binding relationship between the file type and at least one target runtime environment. Each user identifier corresponds to one preference setting. Finally, the sample file detection system determines at least one target runtime environment from a pre-deployed pool of runtime environments based on the preference settings and delivers the sample file to at least one target runtime environment for detection.

[0076] Optional, Figure 4A schematic diagram of a preference setting condition according to an embodiment of this application is shown. Figure 4 As shown, preference settings characterize the binding relationship between the file type of the sample file and the runtime environment. The runtime environment must be stored in the runtime environment library. Preference settings are user-specific; different users can set different preferences and manage these preferences, including enabling and disabling them. The runtime environment library, on the other hand, is shared; custom runtime environments uploaded by different users and pre-set runtime environment templates are open to all users. The runtime environment library management module displays the environment configuration information and related descriptions for different runtime environments, facilitating user configuration of preference settings.

[0077] In one alternative embodiment, such as Figure 4 As shown, when configuring preference settings, users first need to select the file types for which the preference settings apply. The preference settings module will then automatically associate all runtime environments in the runtime environment library that support running sample files of that file type for testing, allowing the user to choose. The user can then manually select the target runtime environment for each file type. This application supports selecting multiple runtime environments as target runtime environments simultaneously. Additionally, the newly added preference settings are enabled by default, and users can manually disable enabled red-highlighted settings.

[0078] exist Figure 4 In this example, a user's preference configuration includes three bias configuration entries: the target runtime environment for the file type "doc" is runtime environment 1 and runtime environment 3; the target runtime environment for the file type "exe64" is runtime environment 2; and the target runtime environment for the file type "exe32" is runtime environment 2 and runtime environment 3. The preference settings for file type "doc" and file type "exe32" are enabled, while the preference setting for file type "exe64" is disabled.

[0079] In an optional embodiment, if no preference setting conditions corresponding to the sample file are detected based on the file type and user identifier, the sample file detection system initiates a preset runtime environment determination strategy, wherein the runtime environment determination strategy is used to directly determine one runtime environment as the target runtime environment from multiple runtime environments.

[0080] Optionally, for file types without configured preference settings, and for file types with configured preference settings but whose corresponding preference settings are disabled, this application provides a preset runtime environment determination strategy. This strategy allows a suitable runtime environment to be selected by default for sample files of these file types. For example, if sample file 1 does not have corresponding preference settings, the preset runtime environment determination strategy will allow the sample file detection system to determine the closest sample file to sample file 1 (let's say sample file A) from a pre-stored sample file library. Then, the sample file detection system will determine that the runtime environment corresponding to sample file A is the default runtime environment corresponding to sample file 1.

[0081] In one optional embodiment, the runtime environment is stored as a virtual machine file in a preset storage area. The sample file detection system converts each target runtime environment into a virtual machine, runs the sample file on the virtual machine, and then acquires the runtime record data of the sample file running in the virtual machine. The runtime record data is then filtered to obtain the target data, whereby invalid data is filtered out from the runtime record data. Finally, the sample file detection system analyzes the target data to obtain the detection results.

[0082] Optionally, the aforementioned preset storage area is the aforementioned runtime environment library management module. The target runtime environment can be a runtime environment template or a custom runtime environment. In this application, the runtime environment template and the custom runtime environment are represented as virtual machine files in storage. The file format depends on the virtualization component used during deployment. For example, if the virtualization component is a KVM component, the runtime environment template and the custom runtime environment can be represented as qcow2 files, etc.; if the virtualization component is a VMware component, the runtime environment template and the custom runtime environment can be represented as OVF files or OVA files, etc.

[0083] In addition, each node server is equipped with a runtime log analysis module, which processes runtime log data. First, after obtaining the runtime log data, the module removes invalid data according to predetermined logic. Invalid data can be understood as redundant information within the runtime log data. After filtering out invalid data, the module obtains the target data, which is then further simplified and summarized to form clear and easy-to-read detection results. It should be noted that the runtime log data comes not only from records on the virtual machine but also from records in the virtual machine's external environment. This external environment includes peripheral devices such as the virtual network adapter, and the runtime log data includes, but is not limited to, log files, screenshot files, network traffic files, memory binary files, and system configuration tampering log files.

[0084] As can be seen from the above, the target runtime environment can be a runtime environment template or a user-created custom runtime environment. The following will combine... Figure 5 This section explains the process of defining a custom runtime environment and converting it into a virtual machine. For example... Figure 5 As shown, taking user A as an example, the process of defining the runtime environment from definition to conversion into a virtual machine includes the following steps:

[0085] Step S501: User A checks whether the existing runtime environment stored in the runtime environment library management module meets the requirements. If it does, proceed directly to step S512; otherwise, proceed to step S502.

[0086] Step S502: User A obtains and views the pre-deployed runtime environment templates, selects a runtime environment template that meets their own needs, and downloads it to their local machine.

[0087] Step S503: User A performs custom environment operations based on the downloaded runtime environment template, including starting or stopping system services, adding or updating software, and other environment adjustments.

[0088] Step S504: User A uploads the customized runtime environment to the runtime environment library management module.

[0089] Step S505: After receiving the custom runtime environment uploaded by user A, the runtime environment library management module updates the runtime environment record to achieve the sharing of the runtime environment, that is, it is visible to all users.

[0090] Step S506: The runtime environment library management module notifies the node management module that there is a runtime environment update;

[0091] Step S507: The node management module synchronizes the new runtime environment (i.e., the custom runtime environment created by user A) to each node server;

[0092] Step S508: After synchronization is complete, the node management module notifies the virtual machine management module on each node server to create the specified number of virtual machines for the custom runtime environment.

[0093] Step S509: After the virtual machine management module on the node server completes the creation of the virtual machine, it sends the creation result back to the node management module.

[0094] Step S510: The node management module updates and records the types of virtual machines and the number of virtual machines of each type on the node server;

[0095] Step S511: The custom runtime environment is now active. All users can subsequently bind file types to this custom runtime environment by setting preference conditions. Proceed to step S513.

[0096] Step S512: The existing operating environment can meet the requirements. User A can directly set the preference settings without customizing the operating environment. Proceed to step S513.

[0097] Step S513, process ends.

[0098] In one optional embodiment, each target runtime environment corresponds to multiple virtual machines, and each virtual machine is capable of running sample files. Before running the sample files on a virtual machine, the sample file detection system detects whether there are any virtual machines in an idle state among the multiple virtual machines. If there are no virtual machines in an idle state among the multiple virtual machines, the system monitors the working status of each virtual machine. When an idle virtual machine is detected, the system sends the sample files to that virtual machine so that the sample files can be run through that virtual machine.

[0099] Optionally, since the number of virtual machines may be limited, in order to improve detection efficiency, this application will allocate idle virtual machines to the sample files to be detected by calling the management module, thereby improving the utilization efficiency of the virtual machines. Additionally, Figure 6 A timing diagram of a detection sample file under an optional multi-running environment according to an embodiment of this application is shown, wherein, Figure 6 The document also covers the process of calling the management module to allocate virtual machines to sample files according to load balancing strategies, as detailed below:

[0100] Step S601: User A configures preference settings through the configuration settings management module to set the binding relationship between a certain file type and the target runtime environment;

[0101] Step S602, User A uploads a sample file B of this file type;

[0102] In step S603, after receiving sample file B, the sample and report management module identifies the file type and determines whether there is a historical test report that can be reused. If there is, it jumps to step S620; otherwise, it jumps to step S604.

[0103] In step S604, the sample and report management module transfers sample file B to the scheduling management module for processing;

[0104] In step S605, the scheduling management module retrieves the preference settings related to sample file B from the preference settings management module and submits the preference settings to the detection result management module for query, hoping that the detection result management module will assist in determining whether there are any historical analysis results that can be reused. If so, proceed to step S618; otherwise, proceed to step S606.

[0105] Step S606: The detection result management module notifies the scheduling management module that sample file B has no historical analysis results that can be reused under the specified preference settings.

[0106] In step S607, the scheduling management module maintains the proportion of detection tasks currently undertaken by each node server and allocates subsequent sample files to which node server for detection based on these statistics. After receiving feedback from the detection result management module, the scheduling management module transfers sample file B and the target runtime environment information specified by sample file B to the detection management module on the node server selected by the scheduling management module for processing. Let's assume that this node server is server C.

[0107] In step S608, when there is an available virtual machine, the detection management module of server C transfers the sample file B and the specified target runtime environment information to the virtual machine management module for processing.

[0108] Step S609: The virtual machine management module allocates and powers on the virtual machine corresponding to the specified target runtime environment for sample file B. Assume that the virtual machine is virtual machine D.

[0109] In step S610, the virtual machine management module sends the sample file B into virtual machine D for execution. The methods for sending the sample file to the virtual machine include, but are not limited to, communication methods such as HTTP and FTP, depending on the specific deployment and management scheme of the virtual machine.

[0110] Step S611: Wait for sample file B to finish running. In this application, "sample completion" means that the timer starts from when the sample file is started running. When the running time of the sample file exceeds the preset time, the sample running life cycle is forcibly terminated, and the sample is considered to have finished running. When the running time of the sample file does not reach the preset time, the sample's running process terminates its running life cycle automatically, and the sample is also considered to have finished running.

[0111] Step S612: After the sample file B has finished running, the virtual machine management module collects the running record data of the sample file B running process on the virtual machine and submits it to the running record analysis module for analysis and processing.

[0112] Step S613: The operation record analysis module removes redundant and extraneous information from the operation record data according to the established logic, and further simplifies and summarizes the effective information to form easy-to-read, clear and comprehensive test results.

[0113] Step S614: The running record analysis module returns the detection results to the detection management module;

[0114] Step S615: The detection management module returns the detection results to the detection result management module of the management server;

[0115] Step S616: After receiving the detection result of sample file B, the detection result management module updates the detection result record so that the detection result can be used as a historical detection result for other detection tasks to reuse.

[0116] Step S617: The detection result management module integrates the detection results corresponding to the multiple target operating environments of sample file B, and transfers the integrated detection results to the sample and report management module for processing, then jumps to step S619.

[0117] In step S618, the test result management module transfers the reusable historical analysis results to the sample and report management module;

[0118] In step S619, the sample and report management module is responsible for converting the integrated test results into the target test report and updating the historical test report records, so that the target test report can be reused as a historical report for other test tasks.

[0119] In step S620, the sample and report management module returns the target detection report to user A, ending the detection process for sample file B.

[0120] As described above, this application incorporates result reuse design for both the management of test results and sample reports. In practical applications, there are many scenarios where the same file is uploaded multiple times within a local area network for testing. Result reuse offers two advantages: resource saving and faster testing. However, since this application allows users to customize the runtime environment, this makes the test results strongly correlated with the detailed runtime environment settings. Without result reuse, many custom runtime environment results could only be applied to the current test task, resulting in a waste of testing resources. This application improves testing efficiency by binding test results and reports to layered runtime environments. When re-analyzing the same sample file, the reuse of historical results can be determined layer by layer according to specific runtime environment requirements.

[0121] In an optional embodiment, the sample file detection system will also obtain the runtime of the sample file in the virtual machine, and if the runtime exceeds a preset duration, prohibit the sample file from continuing to run and update the running status of the sample file to the running completed state.

[0122] It should be noted that some abnormal sample files may be a virus program, and the abnormal behavior exhibited by the target runtime environment may cause the virtual machine to run the abnormal sample file in an infinite loop. In order to avoid this problem, this application can forcibly stop the execution of abnormal sample files by setting a preset time.

[0123] To further illustrate the logic of reusing test results in this application, the following explanation is provided in conjunction with the accompanying drawings, in which... Figure 7 An example diagram of detection results under an optional multi-operational environment according to an embodiment of this application is shown. Figure 7 As shown in the diagram, this illustration primarily demonstrates the application and management of detection results in multi-environment detection tasks. First, the user must configure preference settings and submit a sample file of the corresponding file type to form a multi-environment detection task. This sample file will be referred to as Sample File A in the following description. The user's preference settings stipulate that Sample File A is simultaneously sent to both runtime environment 2 and runtime environment 3 for detection.

[0124] Optional, Figure 7The diagram illustrates a background scenario: the detection result management module currently maintains two detection results for sample file A, namely detection result 1 and detection result 2. Detection result 1 is the detection result of sample file A under runtime environment 1. Since runtime environment 1 is a custom environment based on runtime environment template 1, detection result 1 can also be considered as the detection result corresponding to runtime environment template 1. Detection result 2 is the detection result of sample file A under runtime environment 2. Since runtime environment 2 is a custom environment based on runtime environment template 2, detection result 2 can also be considered as the detection result corresponding to runtime environment template 2. In addition, the sample and report management module currently maintains two test reports. One test report is a multi-environment test report, which is generated based on the integrated test results of test result 1 and test result 2. In other words, this test report is the target test report obtained after running sample file A in two environments, runtime environment 1 and runtime environment 2. The other test report is a single runtime environment test report, which is generated based on test result 2. That is to say, this test report is the test report of sample file A in the single runtime environment 2. Since runtime environment 2 is a custom environment based on runtime environment template 2, this test report can also be regarded as the test report of sample file A after running in runtime environment template 2.

[0125] Based on the above premise, such as Figure 7 As shown, the processing logic of this application after simultaneously sending sample file A to both runtime environment 2 and runtime environment 3 for testing is as follows: Regarding the test results of sample file A running in runtime environment 2, the aforementioned test result 2 can be directly reused. Regarding the test results of sample file A running in runtime environment 3, it needs to be sent to the virtual machine corresponding to runtime environment 3 for testing and analysis. After generating test result 3 corresponding to runtime environment 3, the sample and report management module integrates test result 2 and test result 3, and then further generates a target detection report based on the integration result and presents it to the user. After generating test result 3, test result 3 will also be included in the test result library as a historical test result for management, correspondingly bound to the test result of sample file A in runtime environment 3. Finally, the generated target detection report will be included in the sample and report management module as a historical report for management, correspondingly bound to the test report of sample file A in multiple environments including runtime environment 2 and runtime environment 3.

[0126] In another optional embodiment, assume that user A and user B submit the same sample file 1 successively, and when user B submits sample file 1, the sample file 1 submitted by user A has already completed the generation of a detection report. User A's preference settings for the file type of sample file 1 correspond to runtime environment 1 and runtime environment 2. User B has not configured corresponding preference settings for the file type of sample file 1. Therefore, when user B uploads sample file 1, the preference setting module will determine the runtime environment of sample file 1 using a preset runtime environment determination strategy, assuming the runtime environment strategy determines runtime environment template 2. Based on this, since runtime environment 1 is a custom runtime environment customized based on runtime environment template 1, and runtime environment 2 is a custom runtime environment customized based on runtime environment template 2, when the detection result management module receives the detection result 2 of sample file 1 in runtime environment 2, it will automatically associate the detection result 2 with the detection result of runtime environment template 2 based on the definition of runtime environment 2. Therefore, when user B submits sample file 1, they are actually using the detection result 2 generated by user A in runtime environment 2 when submitting sample file 1, and thus generating the detection report.

[0127] It is important to note that the starting point for reusing detection results in this application is to save detection resources and improve detection efficiency. Specifically, there are two considerations for reusing detection results: First, the malicious behavior of some samples is strongly correlated with the operating system and unrelated to installed software. For example, the startup and operation of Windows executable files (.exe) do not depend on third-party software; that is, the software installed in the operating environment does not affect the operation of the .exe file. Second, for some users, they are not concerned about how the sample runs or what software it is launched by; instead, these users are more concerned about the sample detection results. Combining the two functional design points in this application—that the custom operating environment and the operating environment template have the same operating system and that the preset operating environment determination strategy binds the assignment relationship between certain file types and a certain operating environment template—a detection result based on a certain custom operating environment is also applicable to the operating environment template associated with that custom operating environment and can be used as the detection result of that operating environment template. This achieves result reuse, allowing some detection tasks to reuse historical detection results without occupying more detection resources in subsequent processes, enabling rapid report output and indirectly improving detection efficiency.

[0128] In one optional embodiment, the technical solution of this application is further explained below with reference to three application scenarios. Scenario 1 is a multi-runtime environment detection scenario. Assume user A sets a preference setting condition, specifying that sample files of sample file type B are simultaneously sent to runtime environment C and runtime environment D for detection. User A submits sample file E, where sample file type E is sample file type B. According to the technical solution of this application, sample file E will be simultaneously sent to the virtual machines corresponding to runtime environment C and runtime environment D for detection and analysis. Ultimately, user A will receive a target detection report containing the detection results from runtime environment C and runtime environment D. It is possible that runtime environment C discovers malicious behavior in sample file E, runtime environment D discovers malicious behavior in sample file E, or both runtime environments simultaneously discover malicious behavior in sample file E.

[0129] It is worth noting that multi-environment detection allows sample files to run in more environments, providing more platforms for sample files to demonstrate their behavior, thereby increasing the likelihood of discovering malicious behavior in sample files.

[0130] Secondly, scenario two involves a custom runtime environment application. Assume user A customizes and uploads a custom runtime environment C based on a pre-deployed runtime environment template B. User A sets preference settings to send sample files of sample file type F to both runtime environments C and D for detection. Runtime environment D can be either a template provided by the sample file detection system or a custom runtime environment uploaded by another user. User A submits sample file E, which corresponds to sample file type F. Sample file E will be simultaneously sent to the virtual machines corresponding to runtime environments C and D for detection and analysis. Ultimately, user A will receive a target detection report containing the detection results from runtime environments C and D.

[0131] Finally, scenario three is an application scenario for reusing detection results. Assume user A customizes and uploads a custom runtime environment C based on runtime environment template B. User A sets preference settings to send sample files of file type F to both runtime environment C and runtime environment D for detection. Runtime environment D can be either a runtime environment template or a custom runtime environment uploaded by another user. Then, user A submits sample file E, with file type F. Sample file E is simultaneously sent to the virtual machines corresponding to runtime environments C and D for detection and analysis. After detection, the sample file detection system obtains the detection result C of sample file E in runtime environment C and the detection result D of sample file E in runtime environment D. Since runtime environment C originates from template runtime environment B, the detection result C of sample file E in runtime environment C can be considered as the detection result of sample file E in runtime environment B.

[0132] As can be seen from the above, the sample file detection system directly obtains the detection result C of sample file E under operating environment C and the detection result D of sample file E under operating environment D, and indirectly also obtains the detection result of sample file E under operating environment B (i.e., the detection result C of sample file E under operating environment C). Finally, user A will receive a target detection report containing detection results C and detection results D.

[0133] Furthermore, suppose user H sets a preference setting that specifies sample files of type F will be sent to runtime environment B for detection. Then, user H also submits a sample file E. Since sample file E corresponds to file type F, theoretically, sample file E should be run in runtime environment B to obtain the corresponding detection results. However, because the sample file detection system already maintains the detection results for sample file E in runtime environment B (i.e., the aforementioned detection result C), the sample file detection system will directly reuse detection result C and begin generating the target detection report. Ultimately, user H will receive a detection report containing detection result C.

[0134] It is worth noting that by reusing the test results, the problem of resource waste caused by the custom runtime environment is solved. The test results of the custom runtime environment can be reused by other test tasks, which can not only improve the test efficiency, but also reduce the resource consumption of subsequent tests.

[0135] Example 2

[0136] According to an embodiment of this application, an embodiment of a sample file processing apparatus is also provided, wherein... Figure 8 This is a schematic diagram of an optional sample file processing apparatus according to an embodiment of this application, such as... Figure 8As shown, the device includes: a first acquisition module 801, a conveying module 802, a second acquisition module 803, and a generation module 804.

[0137] The first acquisition module 801 is used to acquire the sample file to be tested; the delivery module 802 is used to deliver the sample file to at least one target operating environment for testing; the second acquisition module 803 is used to acquire the test results of the sample file in each target operating environment, wherein the test results are used to characterize whether there are any abnormalities in the sample file when it is run in each target operating environment; and the generation module 804 is used to generate a target test report based on the test results and send the target test report to the target device.

[0138] It should be noted that the first acquisition module 801, the conveying module 802, the second acquisition module 803 and the generation module 804 mentioned above correspond to steps S101 to S104 in the above embodiments. The four modules and the corresponding steps implement the same examples and application scenarios, but are not limited to the content disclosed in the above embodiment 1.

[0139] Optionally, the above-mentioned delivery module further includes: an identification unit, a first determination unit, and a second determination unit. The identification unit is used to identify the file type of the sample file and the user identifier corresponding to the sample file, wherein the user identifier is used to identify the user who uploaded the sample file; the first determination unit is used to determine the preference setting conditions corresponding to the sample file based on the file type and the user identifier, wherein the preference setting conditions are used to constrain the binding relationship between the file type and at least one target operating environment, and each user identifier corresponds to one preference setting condition; the second determination unit is used to determine at least one target operating environment from multiple pre-deployed operating environments based on the preference setting conditions, and deliver the sample file to at least one target operating environment for detection.

[0140] Optionally, the sample file processing apparatus further includes a determining module and an adjusting module. The determining module is configured to respond to a runtime environment creation request and determine a first runtime environment from at least one pre-deployed fixed runtime environment, wherein the plurality of runtime environments includes at least one fixed runtime environment, the fixed runtime environment being a runtime environment after system configuration adjustment, the system configuration being used to configure the fixed runtime environment to enable the sample file to exhibit abnormal behavior; the adjusting module is configured to perform environment adjustment on the first runtime environment to obtain a new runtime environment, wherein the environment adjustment includes at least operating system adjustment and / or software adjustment.

[0141] Optionally, the sample file processing device further includes: an upload module, used to upload the new runtime environment to a preset storage area and set the status of the new runtime environment to a shared state, wherein the shared state is used to indicate that the new runtime environment is visible to all users, and each user can set preference settings based on the new runtime environment, and multiple runtime environments are stored in the preset storage area.

[0142] Optionally, the second acquisition module described above further includes: a conversion unit, a first acquisition unit, a filtering unit, and a first analysis unit. The conversion unit is used to convert each target runtime environment into a virtual machine and run the sample file on the virtual machine; the first acquisition unit is used to acquire runtime record data of the sample file running in the virtual machine; the filtering unit is used to perform data filtering processing on the runtime record data to obtain target data, wherein the data filtering processing is used to filter out invalid data in the runtime record data; and the first analysis unit is used to analyze the target data to obtain detection results.

[0143] Optionally, the above-mentioned conversion unit further includes a runtime acquisition subunit and a runtime prohibition subunit. The runtime acquisition subunit is used to acquire the runtime of the sample file in the virtual machine; the runtime prohibition subunit is used to prohibit the sample file from continuing to run when the runtime exceeds a preset duration, and to update the running status of the sample file to a running completed state.

[0144] Optionally, the sample file processing device further includes a detection module and a monitoring module. The detection module is used to detect whether any virtual machines are in an idle state among the multiple virtual machines. The monitoring module is used to monitor the working status of each virtual machine when no idle virtual machine is found, and when an idle virtual machine is detected, to send the sample file to that virtual machine for execution.

[0145] Optionally, the above-mentioned generation module further includes: a first generation unit and a comprehensive analysis unit. The first generation unit is used to generate a detection report based on the detection results of the sample file in a target operating environment; the comprehensive analysis unit is used to comprehensively analyze all detection reports corresponding to at least one target operating environment to obtain a target detection report, and send the target detection report to the target device.

[0146] Example 3

[0147] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, which stores a computer program, wherein the computer program is configured to execute the processing method of the sample file in Embodiment 1 above when it is run.

[0148] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0149] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0150] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some interfaces; indirect couplings or communication connections between units or modules may be electrical or other forms.

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

[0152] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0153] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0154] The above are merely preferred embodiments of this application. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method of processing a sample file, characterized by, include: Obtain the sample file to be tested; The sample file is sent to at least one target operating environment for testing; The detection results of the sample file in each target runtime environment are obtained, wherein the detection results are used to characterize whether the sample file has any anomalies when it is run in each target runtime environment; A target detection report is generated based on the detection results, and the target detection report is sent to the target device; The process of sending the sample file to at least one target runtime environment for detection includes: identifying the file type of the sample file and the user identifier corresponding to the sample file, wherein the user identifier is used to identify the user who uploaded the sample file; determining preference settings corresponding to the sample file based on the file type and the user identifier, wherein the preference settings are used to constrain the binding relationship between the file type and the at least one target runtime environment, and each user identifier corresponds to one preference setting condition; determining the at least one target runtime environment from multiple pre-deployed runtime environments based on the preference settings, and sending the sample file to the at least one target runtime environment for detection; The method further includes: responding to a runtime environment creation request, determining a first runtime environment from at least one pre-deployed fixed runtime environment, wherein the plurality of runtime environments include the at least one fixed runtime environment, the fixed runtime environment being a runtime environment after system configuration adjustment, the system configuration being used to configure the fixed runtime environment to a runtime environment that enables the sample file to exhibit abnormal behavior; adjusting the first runtime environment to obtain a new runtime environment, wherein the environment adjustment includes at least operating system adjustment and / or software adjustment; The method further includes: after adjusting the first operating environment to obtain a new operating environment, uploading the new operating environment to a preset storage area, and setting the status of the new operating environment to a shared state, wherein the shared state is used to indicate that the new operating environment is visible to all users, and each user can set the preference settings based on the new operating environment, and the preset storage area stores the multiple operating environments; The method further includes: after determining the preference settings corresponding to the sample file based on the file type and the user identifier, submitting the preference settings to the detection result management module for querying; and if the detection result management module determines that there are reusable historical analysis results, generating the target detection report based on the reusable historical analysis results.

2. The method of claim 1, wherein, The target runtime environment is stored in a preset storage area as a virtual machine file. The detection results of the sample file in each target runtime environment are obtained, including: Each target runtime environment is converted into a virtual machine, and the sample file is run on the virtual machine; Obtain the runtime record data of the sample file when it is run in the virtual machine; The operation record data is subjected to data filtering processing to obtain target data, wherein the data filtering processing is used to filter out invalid data in the operation record data; The target data is analyzed to obtain the detection results.

3. The method of claim 2, wherein, Convert each target runtime environment into a virtual machine, and run the sample file on the virtual machine, including: Obtain the runtime of the sample file in the virtual machine; If the runtime exceeds a preset duration, the sample file is prevented from continuing to run, and the running status of the sample file is updated to the running completed state.

4. The method of claim 2, wherein, Each target runtime environment corresponds to multiple virtual machines, and each virtual machine is capable of running the sample file. Before running the sample file on the virtual machine, the method further includes: Detect whether any of the multiple virtual machines are in an idle state; If no virtual machine is in an idle state among the plurality of virtual machines, the working status of each virtual machine is monitored, and when an idle virtual machine is detected, the sample file is sent to that virtual machine so that the sample file can be run through that virtual machine.

5. The method of claim 1, wherein, Generate a target detection report based on the detection results, and send the target detection report to the target device, including: A detection report is generated based on the detection results of the sample file in a target operating environment; The target detection report is obtained by comprehensively analyzing all detection reports corresponding to the at least one target operating environment, and then the target detection report is sent to the target device.

6. A processing apparatus of a sample file, characterized by, include: The first acquisition module is used to acquire the sample file to be detected; A delivery module is used to deliver the sample file to at least one target operating environment for detection; The second acquisition module is used to acquire the detection results of the sample file in each target running environment, wherein the detection results are used to characterize whether the sample file has any abnormalities when running in each target running environment; The generation module is used to generate a target detection report based on the detection results and send the target detection report to the target device; The delivery module includes: an identification unit for identifying the file type of the sample file and the user identifier corresponding to the sample file, wherein the user identifier is used to represent the user who uploaded the sample file; a first determination unit for determining preference settings corresponding to the sample file based on the file type and the user identifier, wherein the preference settings are used to constrain the binding relationship between the file type and the at least one target operating environment, and each user identifier corresponds to one preference setting condition; and a second determination unit for determining the at least one target operating environment from a plurality of pre-deployed operating environments based on the preference settings, and delivering the sample file to the at least one target operating environment for detection. The sample file processing device further includes: a determining module, configured to respond to a runtime environment creation request and determine a first runtime environment from at least one pre-deployed fixed runtime environment, wherein the plurality of runtime environments include the at least one fixed runtime environment, the fixed runtime environment being a runtime environment after system configuration adjustment, the system configuration being configured to configure the fixed runtime environment to enable the sample file to exhibit abnormal behavior; and an adjusting module, configured to adjust the first runtime environment to obtain a new runtime environment, wherein the environment adjustment includes at least operating system adjustment and / or software adjustment. The sample file processing device further includes: an upload module, used to upload the new operating environment to a preset storage area, and set the status of the new operating environment to a shared state, wherein the shared state is used to indicate that the new operating environment is visible to all users, and each user can set the preference settings based on the new operating environment, and the preset storage area stores the multiple operating environments; The sample file processing device is further configured to: after determining the preference setting conditions corresponding to the sample file based on the file type and the user identifier, submit the preference setting conditions to the detection result management module for querying; and if the detection result management module determines that there are reusable historical analysis results, generate the target detection report based on the reusable historical analysis results.

7. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program is configured to execute the sample file processing method according to any one of claims 1-5 when it is run.

Citation Information

Patent Citations

  • Configuring a sandbox environment for malware testing

    CN106022112A

  • Malicious file detection method and device, computer equipment and storage medium

    CN110543759A