A remote software deployment method and system

Abstract

The application provides a remote software deployment method and system, the method comprising: obtaining a write path set corresponding to a target software installation package to be deployed; adding the write path set to an exclusion list of a uniform write filter of a target terminal; executing an installation program of the target software installation package when the uniform write filter is in a protection effective state; monitoring a process state of the installation program, and removing the write path set from the exclusion list when the process state is ended. The application realizes persistent installation of software without closing the system protection by pre-analyzing the software installation path and dynamically managing the exclusion items of the disk write protection mechanism, avoids the system security risk caused by closing the protection mechanism, and significantly improves the accuracy of installation result determination in combination with the dual detection mechanism of the registry and the script.

Description

Technical Field

[0001] This invention relates to the field of computer system operation and maintenance and terminal security management, and in particular to a remote software deployment method and system. Background Technology

[0002] In the field of enterprise IT management, with the increasing level of informatization, remote software installation and updates for a large number of terminal devices have become an important means of operation and maintenance management. To ensure the integrity and security of system files, many terminal devices running Windows systems (such as public computers and industrial control equipment) enable Unified Write Filter (UWF) or similar disk protection mechanisms. UWF can intercept write operations to protected volumes, redirecting writes to a memory overlay layer. These write operations are discarded after a system restart, thus ensuring that the system always remains in its initial clean state.

[0003] However, this characteristic of UWF inherently conflicts with the persistent writing requirements of software installation. According to existing technology, when remotely deploying software on a device with UWF protection enabled, the typical approach is to first remotely send a command to disable UWF protection, and then re-enable UWF protection after the software installation is complete.

[0004] This existing approach has significant flaws. Disabling UWF during software installation leaves the system completely vulnerable, lacking any protection mechanisms. This provides an opportunity for malware or unauthorized operations, making the device highly susceptible to attack or unauthorized system tampering, posing a serious security risk. Existing remote deployment solutions typically only check the termination status of the installation package. However, software installation is complex, and issues such as missing dependencies, insufficient permissions, or incorrect environment configuration often result in the program finishing running but failing to actually install. Relying solely on the termination status cannot accurately determine the deployment result. Summary of the Invention

[0005] The technical problem to be solved by the present invention is to provide a remote software deployment method and system that enables persistent software installation while the disk write protection mechanism is enabled on the terminal device.

[0006] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: A remote software deployment method, characterized in that it is applied to a target terminal, the method comprising: Obtain the set of write paths corresponding to the target software installation package to be deployed; Add the set of write paths to the exclusion list of the unified write filter on the target terminal; While the unified write filter is under protection, the installer of the target software installation package is executed; Monitor the process status of the installer, and when the process status indicates termination, remove the set of write paths from the exclusion list.

[0007] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: A system includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement the steps of the remote software deployment method described above.

[0008] The beneficial effects of this invention are as follows: By performing static feature parsing and dynamic runtime capture on the target software installation package, a set of write paths containing necessary registry entries and file paths is automatically generated, and the set is dynamically configured into the exclusion list of the unified write filter. This mechanism utilizes the specific allow rules of the exclusion list to grant the installer persistent write permissions for specific paths while the unified write filter remains in a protected state. Compared to the existing method of installing software by disabling write protection, this method does not require interrupting the system's disk protection function during deployment. While ensuring that the software installation data is successfully written to the disk, it maintains the operating system's ability to intercept writes to non-whitelisted areas, effectively avoiding system security vulnerabilities caused by the temporary failure of the write protection mechanism. Attached Figure Description

[0009] Figure 1 A flowchart illustrating the steps of a remote software deployment method provided in an embodiment of the present invention; Figure 2 A flowchart illustrating the execution logic of a remote software deployment method provided in this embodiment of the invention; Figure 3 This is a schematic diagram of a remote software deployment system provided in an embodiment of the present invention. Detailed Implementation

[0010] To explain in detail the technical content, objectives, and effects of the present invention, the following description is provided in conjunction with the embodiments and accompanying drawings.

[0011] In related technologies, in remote software deployment scenarios involving disk write protection mechanisms (such as the Unified Write Filter (UWF) in Windows systems), the common approach is to first disable the protection mechanism, perform the installation, and then re-enable it. This method leaves the terminal device completely exposed during installation, making it highly vulnerable to malware attacks or system tampering, posing a serious security risk. Furthermore, relying solely on the installation program's completion status to determine the deployment result cannot accurately identify actual installation failures caused by missing environmental dependencies or abnormal configurations, leading to inaccurate operational feedback.

[0012] To address the aforementioned problems, this application provides a remote software deployment method and system. The following is a detailed description of one such remote software deployment method.

[0013] The remote software deployment method in this application can be used in software distribution and installation management scenarios for terminal devices with disk write protection mechanisms. The system in this application can be an operating system of a Windows system terminal device with a unified write filter (UWF) or similar disk protection functions enabled, such as a Windows system running on a public service terminal, industrial control equipment, or enterprise office computer.

[0014] The following describes a remote software deployment method according to the present invention, with reference to the appendix. Figure 1 This includes steps 110-140.

[0015] Step 110: Obtain the set of write paths corresponding to the target software installation package to be deployed.

[0016] The client on the target terminal connects to the server, obtains the software task to be installed, downloads the target software installation package and a pre-analyzed set of write paths. The set of write paths includes registry paths and file paths that the target software installation package needs to persistently write to disk during the installation process.

[0017] Step 120: Add the set of write paths to the exclusion list of the unified write filter in the target terminal.

[0018] The target terminal calls the system configuration interface or uses a command-line tool (such as uwfmgr.exe) to add the paths in the write path set to the exclusion list of the Uniform Write Filter (UWF).

[0019] Step 130: With the unified write filter in a protected state, execute the installer of the target software installation package.

[0020] The target terminal launches the installer without disabling unified write filter protection. Since the relevant write paths are pre-added to the exclusion list, the installer's operations on these specific paths will bypass the overlay layer and write directly to the physical disk, achieving persistent deployment.

[0021] Step 140: Monitor the process status of the installer. When the process status is terminated, remove the write path set from the exclusion list.

[0022] The target terminal tracks the lifecycle of the installation process in real time. Once it detects that the main process and all its child processes have exited, it calls the configuration interface to remove the previously added path from the exclusion list and revokes the temporary permission.

[0023] By performing static feature parsing and dynamic runtime capture on the target software installation package, a set of write paths containing necessary registry entries and file paths is automatically generated, and this set is dynamically configured into the exclusion list of the unified write filter. This mechanism utilizes specific allow rules in the exclusion list to grant the installer persistent write permissions to specific paths while the unified write filter remains in a protected state. Compared to existing technologies that achieve software installation by disabling write protection, this method does not require interrupting the system's disk protection function during deployment. While ensuring that software installation data is successfully written to the disk, it maintains the operating system's ability to intercept writes to non-whitelisted areas, effectively avoiding system security vulnerabilities caused by the temporary failure of the write protection mechanism.

[0024] In one embodiment of this application, a process for generating a set of write paths is included before step 110, including steps 210-230.

[0025] It should be noted that this generation process can be executed by the target terminal using local computing power, or it can be executed by the server (management backend) and then obtained by the target terminal.

[0026] Step 210: Parse the file header information and built-in database of the target software installation package, and extract the predefined static write items.

[0027] By using static scanning technology, the metadata and underlying structure of the installation package are analyzed to identify the installation path and configuration write points defined by the program developer.

[0028] Step 220: Pre-run the target software installation package in an isolated virtualization environment, and use a process monitoring tool to capture the actual input and output behavior of the installation process and its derived child processes to obtain the dynamically written items.

[0029] The execution entity places the installation package in a sandbox environment and uses behavior capture technology to record every actual modification operation it makes to the file system and registry.

[0030] Step 230: Merge and deduplicate static write items and dynamic write items to generate a set of write paths.

[0031] If executed by the server, in step 110, the target terminal downloads the write path set corresponding to the target software installation package via the network; if executed locally by the target terminal, the result is generated by directly reading the write path set.

[0032] In this way, by combining static feature analysis with dynamic behavior capture, the constraint of software installation path uncertainty on the configuration of the exclusion list is resolved. From a logical correlation analysis perspective, static extraction provides a pre-defined installation skeleton for the software, while dynamic runtime capture corrects random paths generated by complex installation logic through actual testing. The combination of the two ensures the completeness of the written path set. This automated generation mechanism overcomes the inefficiency and path omission problems caused by relying on manual experience to configure exclusions in the previous technology, and improves the determinism of the subsequent deployment process.

[0033] In one embodiment of this application, the extraction process of static write items in step 210 includes steps 211-214.

[0034] Step 211: When the target software installation package is in a structured installation package format, parse the internal database table structure of the target software installation package.

[0035] For database driver installation formats (such as MSI format), the system parses the logical structure of its built-in database.

[0036] Step 212: Read the target path data from the registry component table and the file component table.

[0037] From the parsed internal database table structure, locate and extract the preset target path data from the registry component table and file component table.

[0038] Step 213: Write the target path data as a static item.

[0039] The extracted data is labeled as static features.

[0040] Step 214: When the target software installation package is an unstructured installation package, parse its portable executable file header and resource segment data, extract the installation path information defined in the metadata according to the characteristics of the packaging tool, and write the installation path information as a static item.

[0041] For EXE and other installation packages, parse their PE header information, identify the packaging engine used (such as NSIS or InnoSetup), and extract the installation configuration metadata contained in the resource segment.

[0042] In this way, by identifying the underlying metadata and internal database table structure of the installation package, the invisible binary configuration is transformed into deterministic path entries. Reading specific component tables in structured installation packages and extracting features from resource segment data in unstructured installation packages ensures that the system can be compatible with and parse software deployment intentions under different packaging architectures. This approach solves the problem of insufficient path recognition capability for diverse installation package formats in existing technologies, achieving accurate perception of software installation intentions and providing a deterministic static data foundation for the subsequent automated configuration of exclusion lists.

[0043] In one embodiment of this application, the process of obtaining the dynamically written item in step 220 includes steps 221-224.

[0044] Step 221: Start the container-based sandbox environment.

[0045] Create a lightweight virtualization container that is isolated from the production environment.

[0046] Step 222: Run the target software installation package in the sandbox environment and listen for registry write events and file creation events in the system kernel.

[0047] By utilizing kernel driver monitoring technology, we can listen for I / O requests from the file system and registry in real time.

[0048] Step 223: Identify the installation process and its derived child processes, filter out data write operations initiated by the installation process and its derived child processes, and record the target address of the data write operation.

[0049] By using process tree tracing technology, we can distinguish between native system processes and installation-related processes, and accurately record the paths generated by installation behavior.

[0050] Step 224: Treat the target address as a dynamically written item.

[0051] The recorded actual operation trajectory is identified as a dynamic feature.

[0052] In this way, by using behavior auditing in a sandbox isolation environment, the complex dynamic logic identification problem during software installation is solved. Process tracing solves the problem of unpredictable paths caused by dynamic script release and nested component calls during software installation. Compared with solutions that rely on static parsing, dynamic behavior auditing makes up for the blind spots in identifying runtime random write paths, ensuring the completeness of the write path set, thereby avoiding deployment failures and system malfunctions caused by missing path configurations.

[0053] In one embodiment of this application, steps 115-116 are included before adding the set of write paths to the exclusion list in step 120.

[0054] Step 115: Match and verify each path written into the path set with the preset high-risk system path library.

[0055] The generated whitelist suggestions are compared with the pre-stored sensitive system directories (such as System32, Driver, etc.) for conflict.

[0056] Step 116: If a target path that hits the high-risk system path library exists in the path set, a security alarm command is generated and the deployment process of the target software installation package is terminated.

[0057] If the installation package is found to be attempting to rewrite core system components, the distribution process will be immediately halted and administrators will be notified to intervene in the audit.

[0058] In this way, by combining automated whitelisting with security baseline verification, malicious software packages with design flaws are prevented from tampering with critical system paths, ensuring security during automated operation and maintenance.

[0059] In one embodiment of this application, after step 120, which adds the set of write paths to the exclusion list of the unified write filter of the target terminal, step 121 is further included; after step 140, which removes the set of write paths from the exclusion list, step 141 is further included.

[0060] Step 121: After adding the set of write paths to the exclusion list of the unified write filter on the target terminal, trigger the first system restart operation on the target terminal to activate the updated exclusion list configuration, and then start the installer.

[0061] Since UWF configuration changes require a reboot to take effect, the system uses preset instructions to guide the terminal to reboot, ensuring that exclusion rules are injected into the kernel before installation is performed.

[0062] Step 141: After removing the set of write paths from the exclusion list, trigger a second system reboot operation on the target terminal to restore the complete protection state of the unified write filter.

[0063] After the installation task is completed, a restart is triggered, forcing the driver to reload its configuration to revoke specific write permissions, clearing the memory overlay data generated during the installation, and resetting the file system to a strict baseline defense state.

[0064] In this way, by performing a system restart at the configuration change node, the timing of the unified write filter configuration reloading and software deployment tasks is seamlessly integrated. From a system architecture perspective, the restart process triggers the disk filter driver to reload the exclusion list, ensuring that the persistent write behavior of the installer occurs within the runtime of the exclusion rules. This closed-loop state switching process solves the deployment data loss problem caused by the lag in driver configuration activation in existing technologies, ensuring the reliability and security of the deployment process without interrupting the overall terminal defense capabilities.

[0065] In one embodiment of this application, step 130, during the execution of the installer of the target software installation package, further includes steps 131-133.

[0066] Step 131: Real-time detection and analysis of file write requests and registry write requests initiated by the installer.

[0067] During the installation process, the target terminal captures low-level I / O requests initiated by the installation process and its child processes in real time through system hooks or kernel filter drivers.

[0068] Step 132: Determine whether the target path of the file write request and the registry write request is included in the exclusion list.

[0069] The system will compare each captured write path with the list of exclusions preset in step 120 in real time.

[0070] Step 133: If the target path is not included in the exclusion list, record the target path and generate an audit log.

[0071] When the system detects that the installer is attempting to write data to a region that is not within the whitelist authorization range, it records the path, associated process, and operation type in the audit log. The audit log is used to verify the integrity of the set of write paths.

[0072] In this way, by dynamically offsetting actual I / O requests against preset exclusion rules during runtime, it is possible to detect in real time whether software installation behavior exceeds preset boundaries. This monitoring method not only provides objective data for subsequent optimization of path analysis algorithms, but also solves the problem of unobservable software deployment processes and reduces the difficulty of monitoring unknown write behaviors during operation and maintenance.

[0073] In one embodiment of this application, step 150 is included after the registration mark verification in step 140 is successful.

[0074] Step 150: Read the preset registry verification rules. The registry verification rules include the expected software name key value and version number key value.

[0075] After the target terminal completes environment cleanup and a second restart, it reads the verification criteria stored locally or obtained from the server to determine the expected values ​​of key keys such as DisplayName and DisplayVersion.

[0076] Step 151: Search the registry of the target terminal for the uninstallation path corresponding to the target software installation package.

[0077] The client program accesses the operating system's standard registry directory (such as HKEY_LOCAL_MACHINE\...\Uninstall) and searches for a path branch that matches the unique identifier of the target software.

[0078] Step 152: Determine whether the actual key value under the retrieved uninstallation item path matches the registry verification rules. If it matches, mark the registry verification as passed.

[0079] The system reads the actual attribute values ​​under this path. If the name, version, and other information are confirmed to be consistent with expectations, the system determines that the software has completed registration.

[0080] In this way, system-level verification of deployment results is achieved by leveraging the standard configuration persistence features of the operating system. The successful execution of the software installer inevitably involves the accurate writing of uninstallation information to the system registry. By directly verifying the physical existence and attribute values ​​of these key configuration items, the two states of process termination and successful deployment can be effectively distinguished. This resolves the risk of misjudgment caused by relying solely on process return codes to determine the result, thus improving the engineering reliability of the result feedback.

[0081] In one embodiment of this application, after marking the registry verification as passed in step 150, steps 161-163 are further included.

[0082] Step 161: Obtain the detection script file associated with the target software installation package and run it on the target terminal.

[0083] The client downloads the corresponding custom detection script (such as a batch script) from the server and starts it with administrator privileges.

[0084] Step 162: Execute the file existence check logic or service running status check logic defined in the detection script file.

[0085] The script performs specific business detection actions, such as checking whether dynamic link libraries under a specific path are stored locally, or querying whether related system services are running through script commands.

[0086] Step 163: Receive the execution result code output by the detection script file, and determine the final deployment status of the target software installation package based on the execution result code.

[0087] The client captures the result code after the script finishes running and generates a final deployment success or failure report based on a preset mapping relationship.

[0088] In this way, by introducing detection logic based on custom scripts, functional verification of software deployment results at the application layer is achieved. Registry verification focuses on confirming the registration status of the installer at the operating system level, while script verification verifies the actual running performance of the software by executing specific probe actions; the combination of the two constitutes a hierarchical verification system for installation results. This approach solves the problem of false installation success caused by abnormal local operating environment (such as missing dynamic links or service startup timeouts), ensuring the consistency between the obtained remote deployment status and the actual running status of the terminal, and reducing the misjudgment rate of installation results in large-scale software distribution scenarios.

[0089] In summary, this invention resolves the underlying conflict between persistent software installation requirements and disk protection mechanism interception characteristics by dynamically managing exclusions while the Unified Write Filter (UWF) is enabled and combining configuration changes with standardized restart scheduling. This ensures precise timing synchronization between kernel-level write permissions and application-level installation tasks without interrupting the overall terminal defense capabilities, avoiding system security exposure risks caused by disabling protection mechanisms. Furthermore, by utilizing a combination of static feature analysis and dynamic behavior capture, it addresses the path identification blind spot caused by the diversity of installation package formats, ensuring the completeness of the automatically generated write path set. Finally, through dual verification via registry validation and script detection, it avoids the risk of false installation success caused by relying solely on process termination status, thus improving system security and reliability.

[0090] Please refer to Figure 2 The execution logic of the remote software deployment method in this invention will be described in detail below.

[0091] 1. Initial startup and path acquisition (corresponding) Figure 2 S1→S2 in the above steps correspond to obtaining the set of write paths corresponding to the target software installation package to be deployed in step 110 above. Step S1: The target terminal completes system boot, and the client program loads automatically with the system. The client connects to the server and obtains the software task to be deployed. During this process, the target software installation package is downloaded, and the set of write paths pre-analyzed and generated by the server is obtained simultaneously.

[0092] Step S2: The client queries the task progress record (such as registry markers or configuration files) stored locally. Since the task has just been issued, the progress record shows that it has not yet entered the post-installation check phase. Based on this, the client determines whether the environment configuration operation needs to be performed.

[0093] By querying local records, state retention across restart cycles is achieved. Since the remote deployment process involves multiple system restarts, the program state in memory will be lost. By reading the progress records on the hard drive, the client can accurately continue the previous operation after each restart (whether to add to the whitelist or verify the result), preventing process interruption or duplicate execution.

[0094] 2. Exclusion Item Configuration and Environment Activation (corresponding) Figure 2 S6→S7 in the above steps correspond to adding the set of writing paths to the exclusion list in step 120 above. Step S6: The client queries the driver configuration interface of the Unified Write Filter (UWF). It confirms that the exclusion rules for the target software are not currently included and triggers the environment pre-configuration process.

[0095] Step S7: The client calls the system interface to inject the write path set into the UWF exclusion list. After configuration, the client triggers the first system restart.

[0096] By configuring exclusions and triggering a restart, write permissions were pre-configured. Since the unified write filter driver loads its configuration during the system boot phase, the restart operation forces the driver layer to reload the rule table containing the new path, preparing for subsequent installations.

[0097] 3. Controlled installation execution (corresponding) Figure 2 S1→S2→S6→S8 in the above steps correspond to the execution of the target software installation package's installer in step 130 above. Steps S1 to S6: After the system restarts, the client is re-initialized. If the local progress record indicates that the post-installation check phase has not yet begun, and the current UWF configuration already includes the target path, then the installation process will proceed.

[0098] Step S8: With the UWF protection mechanism continuously running and the whitelist in effect, the client starts the target software installation package. Data generated by the installation program is written to disk according to preset exclusion rules, achieving persistent deployment.

[0099] Software installation was performed without disabling system write protection by using existing exclusion rules. This mechanism allows the installer to persistently write data to disk while the rest of the system remains write-protected, limiting the impact of the installation process on unauthorized areas.

[0100] 4. Permission revocation and status reset (corresponding to) Figure 2 S9 in the above refers to removing the set of write paths from the exclusion list in step 140 above. Step S9: The client monitors the installation process status in real time. Once the process exit is detected, firstly, the system interface is called to remove the set of write paths from the exclusion list to close the temporary write channel; then, the local task progress record is updated and marked as pending post-installation check status so that it can automatically enter the subsequent result verification stage after the system restarts; finally, a second system restart is triggered.

[0101] By removing the exclusions and triggering a reboot, the system's initial defense state was restored. The second reboot made the whitelist removal configuration effective, thereby revoking temporary write permissions and ensuring the file system returned to the baseline state defined by the write protection mechanism. Simultaneously, updating the local progress log ensured that after the system reboot, the client could recognize that the installation process was complete, thus automatically executing subsequent verification logic.

[0102] 5. Registry verification (corresponding) Figure 2 S1→S2→S3 in the above steps correspond to the registry-based verification steps in step 150 above. Steps S1 to S2: After the system restarts, the client reads the local task progress record, recognizes that the current state has been marked as pending installation check, and enters the installation result verification stage.

[0103] Step S3: The client retrieves standard uninstallation items and key values ​​(such as DisplayName) from the system registry.

[0104] If a match is found and the registry verification is confirmed to be successful, a custom script check will be performed. If no matching item is found, the registry verification is deemed to have failed, and an exception is reported.

[0105] By utilizing standard operating system registry records for objective verification, this method verifies whether the software has completed standardized registration at the system level, providing a criterion independent of the installer's running state. This verification method effectively avoids the risk of misjudgment that may arise from relying solely on the installer's termination status, thereby improving the accuracy of determining the actual software installation result.

[0106] 6. Custom script validation (corresponding) Figure 2 S4→S5 in the above steps correspond to the verification step based on the custom script in step 160 above. Step S4: After passing the registry verification, the client runs the associated detection script to detect the existence of core files and the running status of system services.

[0107] If the script returns a success message, the deployment is considered successful. If the script returns a failure, the deployment is considered abnormal.

[0108] Step S5: The client summarizes the judgment results, sends them back to the server, and clears the local status flag, thus completing the deployment task loop.

[0109] This phase uses custom scripts to monitor the software's running status. Compared to static registry records, script verification can detect dynamic indicators such as whether services are running and files are complete, providing supplementary verification of software functionality and ensuring that the feedback results reflect the software's actual operating status.

[0110] This application coordinates the timing relationship between kernel driver configuration activation and application layer installation tasks through the cooperation of local status identification and restart scheduling. With the Unified Write Filter (UWF) enabled, this scheme achieves persistent writing of software data by dynamically managing exclusions, avoiding system security risks arising from disabling write protection mechanisms. Furthermore, by combining static registry characteristics with dynamic script execution status detection, the installation results are verified from both system registration and functional operation dimensions, improving the accuracy of deployment status feedback.

[0111] Please refer to Figure 3 The present invention also provides a system including a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement the steps of the remote software deployment method described above.

[0112] The beneficial effects of the electronic device of the present invention are the same as those of the method described above, and will not be repeated here.

[0113] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A remote software deployment method, characterized in that, Applied to a target terminal, the method includes: Obtain the set of write paths corresponding to the target software installation package to be deployed; Add the set of write paths to the exclusion list of the unified write filter; While the unified write filter is under protection, the installer of the target software installation package is executed; Monitor the process status of the installer, and when the process status indicates termination, remove the set of write paths from the exclusion list.

2. The remote software deployment method according to claim 1, characterized in that, Before obtaining the set of write paths corresponding to the target software installation package to be deployed, the following steps are included: Parse the file header information and built-in database of the target software installation package, and extract predefined static write items; The target software installation package is pre-run in an isolated virtualization environment. The actual input and output behavior of the installation process and its derived child processes is captured by a process monitoring tool to obtain dynamically written items. The static write items and the dynamic write items are merged and deduplicated to generate the write path set.

3. The remote software deployment method according to claim 2, characterized in that, The process of parsing the file header information and built-in database of the target software installation package and extracting predefined static write items includes: When the target software installation package is in a structured installation package format, the internal database table structure of the target software installation package is parsed, and the target path data in the registry component table and file component table is read. The target path data is used as the static write item; When the target software installation package is an unstructured installation package, the portable executable file header and resource segment data of the target software installation package are parsed, and the installation path information defined in the metadata is extracted according to the characteristics of the packaging tool; The installation path information is used as the static write item.

4. The remote software deployment method according to claim 2, characterized in that, The obtained dynamically written item includes: Start a container-based sandbox environment; The target software installation package is run in the sandbox environment, and the system kernel registry write events and file creation events are monitored. Identify the installation process and its derived child processes, filter out data write operations initiated by the installation process and its derived child processes, and record the target address of the data write operation; The target address is used as the dynamically written item.

5. The remote software deployment method according to claim 1, characterized in that, Before adding the set of write paths to the exclusion list, the following steps are included: Each path in the path set is matched and verified against a pre-set high-risk system path library; If a target path in the set of write paths matches the high-risk system path library, a security alarm command is generated and the deployment process of the target software installation package is terminated.

6. The remote software deployment method according to claim 1, characterized in that, Also includes: After the set of write paths is added to the exclusion list of the unified write filter of the target terminal, the first system restart operation of the target terminal is triggered to activate the updated exclusion list configuration, and then the installation program is started. After the set of write paths is removed from the exclusion list, a second system restart operation is triggered on the target terminal to restore the complete protection state of the unified write filter.

7. A remote software deployment method according to claim 1, characterized in that, The process of executing the installer of the target software installation package also includes: Real-time detection and analysis of file write requests and registry write requests initiated by the installation program; Determine whether the target paths of the file write request and the registry write request are included in the exclusion list; If the target path is not included in the exclusion list, the target path is recorded and an audit log is generated. The audit log is used to verify the integrity of the set of write paths.

8. A remote software deployment method according to claim 1, characterized in that, After removing the set of write paths from the exclusion list, the following is included: Read the preset registry verification rules, which include the expected software name key value and version number key value; Retrieve the uninstallation path corresponding to the target software installation package from the registry of the target terminal; If the actual key value under the uninstallation item path matches the registry verification rule, then the registry verification is marked as successful.

9. A remote software deployment method according to claim 8, characterized in that, After the registry verification is passed by the marked flag, the following is also included: Obtain the detection script file associated with the target software installation package; Run the detection script file on the target terminal and execute the file existence check logic or service running status check logic defined in the detection script file. The system receives the execution result code output by the detection script file and determines the final deployment status of the target software installation package based on the execution result code.

10. A system, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement the various steps of a remote software deployment method according to any one of claims 1 to 9.

Images