A software installation package security enhancement and analysis method and system for an industrial intranet

Abstract

A software installation package security enhancement and analysis method and system of an industrial intranet, comprising: obtaining an original installation package that has been constructed and completed initial signing; analyzing the original installation package to obtain its directory structure; setting a pre-constructed dynamic framework under a standard dynamic library directory in the directory structure; the dynamic framework comprising a function implementation binary file, a manifest file and a policy interface; reading a main executable file from the directory structure, analyzing a loading command area of the main executable file; inserting a loading command or a dependent item entry pointing to the dynamic framework in the loading command area, and updating the main executable file; recursively signing all files under the directory structure to generate a security-enhanced installation package; loading the security-enhanced installation package, analyzing the new loading command or dependent item entry to load the dynamic framework binary file; and verifying the policy configuration data, if the version is updated, parsing it into a policy instruction of a leaf node to execute a security protection operation.

Description

Technical Field

[0001] This invention relates to the field of Internet security technology, and in particular to a method and system for enhancing and parsing the security of software installation packages in industrial intranets. Background Technology

[0002] Mobile applications typically require security hardening before distribution to defend against security threats such as reverse engineering, code tampering, and data theft. Currently, mainstream mobile application security hardening solutions fall into two main categories: Category 1: Development-phase integrated hardening. This approach requires integrating security features into the business logic during application development, in the form of source code, static libraries, or software development kits (SDKs). For example, developers might call anti-debugging interfaces or data encryption interfaces within their code. The drawbacks of this approach are: security logic is highly coupled with business logic, significantly impacting the existing development process; any update to the security policy must be accompanied by a new application version release, resulting in a long response time; and security capabilities are fixed at compile time and cannot be dynamically adjusted based on the runtime environment.

[0003] The second type: Packaging-stage protective hardening. This approach encrypts, obfuscates, or packs the entire application package after compilation into binary files. Examples include overall packing and instruction virtualization. The drawbacks of this approach are: deep modification of the application's runtime environment can easily lead to compatibility issues with the operating system or third-party libraries, and may even cause performance degradation; once the protection logic is cracked, it cannot be dynamically updated after the application is released; some techniques may violate app store review policies, resulting in the application being unable to be listed.

[0004] The third type: Post-construction dynamic library injection-based hardening. For example, CN107305495A discloses a method for modifying the functionality of a software installation package, including: adding a dynamic library for implementing a preset function to the decompressed file of the target software installation package; modifying the executable file in the decompressed file so that the executable file calls the method class implementing the preset function from the dynamic library at runtime; re-signing and compressing the decompressed file to obtain the modified software installation package. The drawbacks of this approach are: firstly, the injected dynamic library is in a passive calling mode—its behavior is fixed at compile time, and the dynamic library only executes the corresponding logic when the main program explicitly calls its exported functions, making it impossible to dynamically adjust the protection strategy according to the runtime environment after release; secondly, the dynamic library lacks autonomous network communication capabilities and cannot obtain updated security policies remotely, resulting in security capabilities not evolving over time, leaving the released application unprotected once it faces new security threats; thirdly, the solution is only applicable to standard mobile distribution scenarios with internet connectivity and cannot adapt to industrial intranet environments without internet access.

[0005] In summary, the common flaw of existing technologies is that the integration of security capabilities is prematurely tied to the development or compilation phase, resulting in rigid security policies and the inability of security modules to operate and iterate independently of business logic. Summary of the Invention

[0006] To address the aforementioned technical problems, this invention provides a method for enhancing and parsing the security of software installation packages in industrial intranets, comprising the following steps: Obtain the original installation package that has been built and initially signed; Parse the original installation package to obtain its directory structure; The pre-built dynamic framework is set in the standard dynamic library directory in the directory structure; the dynamic framework includes a function implementation binary file, a manifest file, and a strategy interface; wherein, the function implementation binary file includes an initialization code segment and a network communication code segment, and the manifest file declares initialization function symbols; Read the main executable file from the directory structure and parse the load command area of ​​the main executable file; Insert a loading command or dependency entry pointing to the dynamic framework into the loading command area, and update the main executable file; All files under the directory structure are recursively signed to generate a security-enhanced installation package; wherein, when the security-enhanced installation package runs on an industrial intranet terminal without Internet access, the policy interface encapsulates the policy request into an extended field of an industrial communication protocol message, forwards it to the policy server via the industrial gateway, and extracts policy configuration data from the extended field of the protocol response message returned by the industrial gateway. The system loads the enhanced security installation package, parses the new loading command or dependency entry to load the dynamic framework binary file, and calls the corresponding initialization function according to the initialization function symbol. When the initialization function is executed, it calls the network communication code segment in the function implementation binary file to establish a communication connection with the policy server and pull the initial security policy. When the enhanced security installation package runs on an industrial intranet terminal without internet access, the policy interface encapsulates the policy request into the extended field of the industrial communication protocol message, forwards it to the policy server via the industrial gateway, and extracts the policy configuration data from the extended field of the protocol response message returned by the industrial gateway. The policy configuration data is verified. If the version is updated, it is parsed into policy instructions in the leaf nodes to perform security protection operations.

[0007] Optionally, the main executable file is in Mach-O format or ELF format; When the main executable file is in Mach-O format, a load command pointing to the dynamic frame is inserted into the load command area; the load command is the LC_LOAD_DYLIB command; updating the main executable file includes: updating the number of load commands and the total size of load commands in the Mach-O file header; after inserting the new load command, all segment commands in the Mach-O file are traversed, and the file offset recorded in each segment command is obtained; based on the total offset increment caused by the expansion of the load command area, each file offset is added to the total offset increment and rewritten to the corresponding field; the code signature data area pointed to by the LC_CODE_SIGNATURE load command is located, and the signature data therein is marked as invalid; When the main executable file is in ELF format, inserting a dependency entry pointing to the dynamic framework in the loading command area specifically involves: adding a DT_NEEDED dependency entry at the end of the dependency list in the dynamic section; updating the main executable file includes: updating the entry count field of the dynamic section and the file size and memory size of the corresponding entry in the program header table where the dynamic section is located; for the dynamic framework path referenced in the DT_NEEDED dependency entry, a relative path format containing only the library file name is used; wherein, before adding a DT_NEEDED dependency entry at the end of the dependency list in the dynamic section, the current remaining capacity of the segment where the dynamic section is located is read. If the remaining capacity is less than the length required for the DT_NEEDED dependency entry to be added, the entire dynamic section is relocated to the end of the ELF file and the allocated space is expanded. At the same time, all entries in the program header table are traversed, and the file offset field in the entries whose offset has changed due to relocation is updated to the new offset value.

[0008] Optionally, recursively sign all files under the directory structure, including: Obtain a dedicated signature, which includes a dedicated certificate and a description file; Iterate through each file in the directory structure, read the binary content of the file and calculate its hash value; The hash value is signed using the private key of the dedicated certificate to generate a signature block; The description file is copied to a preset location in the directory structure, and the signature block is written into the signature area of ​​the corresponding file.

[0009] Optionally, the manifest file includes at least a dynamic framework identifier and a dynamic security policy version number; The strategy interface performs the following steps during the dynamic framework's self-initialization phase: Detect the current network environment; If internet access is detected, a policy request is proactively sent to the remote server via the HTTPS protocol; If an industrial intranet without an internet exit is detected, an industrial protocol extension field communication channel is configured, and a preset industrial gateway address is read; wherein, the industrial protocol extension field communication channel encapsulates the policy request into the extension field of the industrial communication protocol message.

[0010] Optionally, the strategy request of the dynamic framework is initiated autonomously; the triggering timing of the strategy request includes: During the execution of the initialization function, a policy request is constructed and sent for the first time; after the initial security policy is successfully retrieved, a refresh interval parameter is extracted from the policy configuration data, and a timer is started according to the refresh interval parameter. When the timer expires, the policy request is reconstructed and sent; and when a preset security event is detected, an emergency policy request is immediately constructed and sent.

[0011] Optionally, after the dynamic framework is loaded, it automatically calls the initialization function. The initialization function sends a policy request to a preset remote address through the policy interface. The policy request carries the current application version identifier, device fingerprint, runtime environment parameters, locally effective policy version number, the status report data of the most recent policy execution, and security event summary information. The policy configuration data is verified. If the version is updated, it is parsed into policy instructions in the leaf nodes to perform security protection operations. This includes: obtaining the digital signature attached to the policy configuration data and verifying the digital signature using a pre-set policy server public key certificate; after successful verification, comparing the policy configuration data with the locally effective policy version number; if the version number of the policy configuration data is updated, parsing the policy configuration data into policy instructions in the leaf nodes; and performing security protection operations according to the policy instructions.

[0012] Optionally, parsing the strategy configuration data into strategy instructions for leaf nodes includes: performing JSON deserialization on the strategy configuration data to extract the strategy tree structure; traversing each strategy node in the strategy tree, expanding conditional branches layer by layer from the root node until each branch reaches a leaf node that no longer contains child nodes; extracting the strategy atomic instructions stored in each leaf node, wherein the strategy atomic instructions at least include the target protection module identifier, operation action code, and action parameters; sorting the extracted strategy atomic instructions by priority and registering them in the strategy execution scheduling table within the dynamic framework. The security protection operations include at least one of the following: performing instruction-level whitelist filtering on industrial communication protocol messages, performing integrity verification on the memory page attributes of application processes, encrypting sensitive data before writing it to storage, and performing hook detection on screenshot system calls and adding invisible watermarks.

[0013] Optionally, the policy configuration data is dynamically generated based on the device fingerprint, version identifier, and operating environment parameters. The generation steps include: after receiving a policy request, the remote server queries the terminal profile database based on the device fingerprint to obtain the terminal's historical security event records and historical risk scores; matches the corresponding policy rule set from the policy rule base based on the version identifier; assesses the current terminal's environmental risk level based on the operating environment parameters; and dynamically combines and generates differentiated policy configuration data from the policy rule set based on the environmental risk level, version identifier, and historical risk scores.

[0014] Optionally, the runtime environment parameters include at least jailbroken or rooted status, debug mode identifier, network type, and emulator detection results, with each parameter corresponding to a different scoring weight.

[0015] Corresponding to the aforementioned method for enhancing and parsing the security of software installation packages in industrial intranets, this invention provides a system for enhancing and parsing the security of software installation packages in industrial intranets, comprising: The acquisition module is used to obtain the original installation package that has been built and initially signed; The parsing module is used to parse the original installation package and obtain its directory structure; An injection module is used to set the pre-built dynamic framework in the standard dynamic library directory of the directory structure; the dynamic framework includes a function implementation binary file, a manifest file, and a strategy interface; wherein, the function implementation binary file includes an initialization code segment and a network communication code segment, and the manifest file declares initialization function symbols; The modification module is used to read the main executable file from the directory structure, parse the loading command area of ​​the main executable file, insert a loading command or dependency entry pointing to the dynamic framework into the loading command area, and update the main executable file; wherein, when the updated main executable file is loaded, the new loading command or dependency entry instructs the runtime environment to automatically load the dynamic framework and call the corresponding initialization function according to the initialization function symbol; when the initialization function is executed, it calls the network communication code segment in the function implementation binary file to establish a communication connection with the policy server and pull the initial security policy; The recursive signature module is used to recursively sign all files under the directory structure using a special signature to generate a security-enhanced installation package. The execution module is used to load the security-enhanced installation package, parse the new loading command or dependency entry to load the dynamic framework binary file, and call the corresponding initialization function according to the initialization function symbol. When the initialization function is executed, it calls the network communication code segment in the function implementation binary file to establish a communication connection with the policy server and retrieve the initial security policy. Specifically, when the security-enhanced installation package runs on an industrial intranet terminal without internet access, the policy interface encapsulates the policy request into an extended field of the industrial communication protocol message, forwards it to the policy server via the industrial gateway, and extracts policy configuration data from the extended field of the protocol response message returned by the industrial gateway. It also verifies the policy configuration data, and if the version is updated, parses it into policy instructions for leaf nodes to perform security protection operations.

[0016] Compared with the prior art, the present invention has the following beneficial effects: (1) The timing of security enhancement is shifted from the development stage to the post-construction stage, decoupling security logic from business logic. Security policies can be iterated independently without accompanying the release of new application versions. The automatic loading of dynamic framework and automatic invocation of initialization functions are achieved by utilizing the native dynamic library loading mechanism of the operating system. There is no need to encrypt, obfuscate or pack the application runtime environment, avoiding compatibility and performance issues. The network communication is established autonomously by the initialization function and the initial security policy is pulled, breaking through the limitation of passive invocation of traditional injection-type dynamic libraries, enabling released applications to dynamically obtain and update security capabilities. The policy request is encapsulated into the extended field of the industrial communication protocol message through the policy interface and forwarded by the industrial gateway, so that industrial intranet terminals without Internet exit can still obtain security policies, realizing unified coverage of standard mobile scenarios and industrial intranet scenarios.

[0017] (2) For the Mach-O format, by inserting the LC_LOAD_DYLIB command and compensating for the file offset of the segment command, and marking the original signature data as invalid, the modified file conforms to the operating system loader specification and can regenerate a complete code signature; for the ELF format, by adding the DT_NEEDED dependency entry and adopting the relative path format, and by relocating the dynamic section to the end of the file and updating the offset of the affected entry when space is insufficient, the dynamic framework can be correctly parsed and loaded by the dynamic linker; the synergistic effect of the two format modification schemes is that both achieve native automatic loading of the dynamic framework by accurately modifying the executable file format metadata, while maintaining file format compliance and signature validity, ensuring cross-platform compatibility.

[0018] (3) The signature block is generated by signing the file hash value with the private key of the special certificate, and the description file is copied to the preset location so that the integrity of each file can be independently verified and the source is trustworthy; the recursive signature covers all files in the directory structure, so that the security enhancement installation package forms a complete trust chain from a single file to the overall package structure.

[0019] (4) By declaring the dynamic framework identifier and dynamic security policy version number through the manifest file, the operating environment can accurately identify the security module identity and track the policy iteration status; the policy interface detects the network environment during the self-initialization phase. When the Internet is accessible, the policy request is sent via HTTPS. When there is no Internet exit, the request is encapsulated in the communication channel through the industrial protocol extension field, so that the same dynamic framework can adaptively select the communication method according to the actual network conditions of the terminal; the synergistic effect of the industrial protocol extension field and the pre-set industrial gateway address enables the policy request to penetrate the industrial network boundary and complete the transmission of security policy without affecting the original industrial communication services.

[0020] (5) By enabling policy requests to be initiated autonomously by the dynamic framework without relying on explicit calls from the main executable file, the acquisition and updating of security policies are completely independent of business logic; initialization triggers establish baseline protection, timed refresh triggers maintain the continuous effectiveness of policies, and emergency triggers for security events enable real-time emergency response. The synergistic effect of the three triggering times forms a closed-loop policy update system from static deployment to dynamic evolution, ensuring that released applications can continuously acquire protection capabilities against new security threats.

[0021] (6) Security capabilities are automatically activated through the operating system’s native loading mechanism without modifying the business code of the main executable file; policy requests carry version identifiers, device fingerprints, operating environment parameters, local policy version numbers and security event summaries, enabling remote servers to generate differentiated policies that accurately match the actual state of the terminal based on multi-dimensional terminal profiles; digital signature verification ensures the integrity and source credibility of policy configuration data, preventing policies from being tampered with or forged; after the signature is verified, version comparison is performed, and the policy is only parsed into leaf node policy instructions and executed when the policy is updated. Version comparison avoids the waste of resources caused by repeated execution, and leaf node parsing transforms the hierarchical policy tree into directly executable atomic instructions. The combination of the two ensures that the terminal always executes the latest policy and improves the efficiency and accuracy of policy execution.

[0022] (7) By deserializing JSON and expanding conditional branches layer by layer from the root node to the leaf node, the hierarchical policy tree is transformed into fine-grained policy atomic instructions that can be executed directly; after being sorted by priority, they are registered to the policy execution schedule table so that multiple policy atomic instructions can be executed in an orderly manner and avoid policy conflicts; the synergistic effect of industrial communication protocol message whitelist filtering, memory page attribute integrity verification, sensitive data encryption, screenshot hook detection and addition of invisible watermarks forms a defense-in-depth system from four dimensions: network communication, memory operation, data storage and user interface, and achieves comprehensive coverage of multiple security threats.

[0023] (8) Based on the device fingerprint association with historical security event records and risk scores, the policy generation can be personalized based on the long-term security behavior characteristics of the terminal; based on the version identifier, the corresponding policy rule set is matched so that the policy is accurately adapted to the code structure and security requirements of the current application version; based on the operating environment parameters, the real-time environmental risk level is evaluated so that the policy strength can be dynamically adjusted with the terminal security situation; the historical risk score provides long-term trend judgment, the environmental risk level provides real-time status assessment, and the version identifier provides application context constraints. The synergistic effect of the three realizes the transformation from unified static protection to dynamic and precise protection that varies from device to device and time to time.

[0024] (9) By incorporating jailbreak status, debug mode identifier, network type, and emulator detection results into the runtime environment parameters, the terminal security posture is fully quantified from four dimensions: system permission integrity, debug attack risk, network trustworthiness, and runtime environment authenticity. By configuring different scoring weights for each parameter, the impact of risks in different dimensions can be adjusted according to their security sensitivity, ensuring that high-risk environments trigger stricter policy responses, thereby improving the precision of environmental risk assessment and the sensitivity of policy triggering. Attached Figure Description

[0025] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this invention, illustrate exemplary embodiments of the invention and are used to explain the invention, but do not constitute an undue limitation of the invention. In the drawings: Figure 1 This is a simplified flowchart of an embodiment of the software installation package security enhancement and parsing method for industrial intranets according to the present invention; Figure 2 This is a framework diagram of an embodiment of the software installation package security enhancement and parsing system for industrial intranets of the present invention. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0027] This invention is applicable to mobile terminal security protection scenarios that combine internet access and industrial intranet environments. For example... Figure 1 As shown, the present invention provides a method for enhancing and parsing the security of software installation packages in an industrial intranet, which includes the following steps: Obtain the original installation package that has been built and initially signed; the original installation package can be any standard application distribution package generated by the developer through their regular development process (e.g., by manual download or from a build server); the original installation package has a valid digital signature (i.e., initial signature) provided by the developer when it is obtained to ensure its integrity before it is processed; Parse the original installation package to obtain its directory structure. This parsing process can be accomplished using decompression tools or specific file format parsing libraries. For example, for a compressed installation package, it can be decompressed to a temporary directory, thereby explicitly obtaining the hierarchical relationship of its files and folders. The pre-built dynamic framework is placed in the standard dynamic library directory in the directory structure. The dynamic framework includes a function implementation binary file, a manifest file, and a policy interface. This dynamic framework is an independent security function module, which contains a function implementation binary file that implements specific security functions, a manifest file that describes the framework's metadata, and a policy interface for interacting with external systems. For example, the dynamic framework can be directly copied to the preset library file storage path within the application package to ensure that the operating system can discover and load the framework at runtime. The function implementation binary file includes an initialization code segment (composed of the implementation code of the initialization function) and a network communication code segment, and the manifest file declares the initialization function symbols. The main executable file is read from the directory structure, and its load command area is parsed. The main executable file is the core binary file for application startup, and its load command area contains external dependency information required for application runtime. This parsing can be done using binary file editing tools or specialized parsing libraries to identify the starting position and current content of this area. When the updated main executable file is loaded, the new load commands or dependency entries instruct the runtime environment to automatically load the dynamic framework and call the corresponding initialization function according to the initialization function symbol. When the initialization function is executed, it calls the network communication code segment in the function implementation binary to establish a communication connection with the policy server and retrieve the initial security policy. Insert a load command or dependency entry pointing to the dynamic framework into the load command area and update the main executable file. This insertion operation is intended to inform the operating system or dynamic linker to automatically load the dynamic framework when the application starts. For example, a runtime dependency between the main executable file and the dynamic framework can be established by appending a new load instruction to the end of the load command area or by modifying an existing list of load instructions. After the insertion is completed, the relevant structural information of the main executable file needs to be adjusted to reflect the changes in the contents of the load command area. A secure-enhanced installation package is generated by recursively signing all files in the directory structure using a dedicated signature. This signing process involves digitally signing each file in the directory structure to ensure the integrity and trustworthiness of the entire application package. For example, a pre-defined signing tool can be used to sign each file after unpacking and embed the signature information into the metadata of the corresponding file or package, ultimately repackaging it into an installation package with a new signature. When the secure-enhanced installation package runs on an industrial intranet terminal without internet access, the policy interface encodes the policy request and encapsulates it in the extended field of the industrial communication protocol message, forwards it to the policy server via the industrial gateway, and extracts the policy configuration data from the extended field of the protocol response message returned by the industrial gateway. The system loads the security-enhanced installation package, parses new loading commands or dependency entries to load the dynamic framework binary file, and calls the corresponding initialization function according to the initialization function symbol. When the initialization function is executed, it calls the network communication code segment in the function implementation binary file, establishes a communication connection with the policy server, and pulls the initial security policy. When the security-enhanced installation package runs on an industrial intranet terminal without Internet access, the policy interface encapsulates the policy request into the extended field of the industrial communication protocol message, forwards it to the policy server through the industrial gateway, and extracts the policy configuration data from the extended field of the protocol response message returned by the industrial gateway. The policy configuration data is verified and signed. If the version is updated, it is parsed into policy instructions in the leaf nodes to perform security protection operations.

[0028] This invention decouples security logic from business logic by shifting the timing of security enhancement from the development phase to the post-build phase, allowing security policies to iterate independently without accompanying new application releases. It utilizes the operating system's native dynamic library loading mechanism to automatically load the dynamic framework and automatically call initialization functions, eliminating the need for encryption, obfuscation, or packing of the application runtime environment, thus avoiding compatibility and performance issues. By autonomously establishing network communication and retrieving initial security policies through initialization functions, it overcomes the limitations of traditional passive dynamic library injection, enabling released applications to dynamically acquire and update security capabilities. Furthermore, by encapsulating policy requests into extended fields of industrial communication protocol messages via a policy interface and forwarding them through an industrial gateway, even industrial intranet terminals without internet access can still obtain security policies, achieving unified coverage for both standard mobile scenarios and industrial intranet scenarios.

[0029] For ease of understanding, the following explains some key terms in this embodiment: An original installation package refers to an application distribution package that has been built, compiled, and digitally signed (e.g., by the developer) by the application developer. It typically contains all the application's code, resources, and metadata, but has not yet been processed by this security enhancement method. For example, on the iOS platform, it can be an .ipa file; on the Android platform, it can be an .apk or .aab file.

[0030] Directory structure refers to the organization of files and folders after the original installation package has been unpacked or parsed. This structure reflects the application's layout within the file system, including the location of executable files, resource files, library files, etc.

[0031] A dynamic framework is a self-contained, independently loadable and runnable security feature module. It is designed to be dynamically loaded by the operating system at application runtime to provide security capabilities. A dynamic framework typically includes a feature implementation binary file, a manifest file, and a policy interface. The feature implementation binary file carries the specific security logic and code. The manifest file declares the dynamic framework's identifier, version information, and metadata such as standard initialization entry functions. The policy interface provides a mechanism for communication with external systems (such as a cloud-based policy management center) to obtain and apply dynamic security policies at runtime.

[0032] The main executable file is the core binary file of an application, containing the application's entry point and main business logic. When the operating system starts the application, it first loads and executes this main executable file. This file typically has a specific file format, such as Mach-O format (for iOS / macOS) or ELF format (for Android / Linux).

[0033] The load command area is a specific region in the main executable file (such as a Mach-O or ELF format file) that instructs the operating system or dynamic linker on how to load and link other libraries or modules. This region contains a series of load commands or dependency entries that define the external dependencies required by the application at runtime.

[0034] Load commands or dependency entries are instructions inserted in the load command section that instruct the dynamic linker to load a specific dynamic framework. For example, in a Mach-O file, it could be the LC_LOAD_DYLIB command; in an ELF file, it could be a dependency entry of type DT_NEEDED.

[0035] A dedicated signature refers to the process of re-signing an application using a digital certificate and description file held by a security service provider, rather than the original application developer. This signature is used to verify the integrity and origin of the security-enhanced installation package, ensuring its legitimate operation on the operating system and distinguishing it from the original signature.

[0036] The security-enhanced installation package refers to the application installation package that has been processed using this method, injected with a dynamic framework, and re-signed. This installation package retains the original application functionality while gaining additional security protection capabilities, and can still be installed and run normally by the operating system.

[0037] In some embodiments of the present invention, a method for enhancing application security is proposed by parsing the original installation package, copying the dynamic framework, modifying the load command area of ​​the main executable file, and re-signing it. However, in implementation, the specific file format of the main executable file varies greatly, such as Mach-O and ELF formats. These different formats have significantly different file structures, leading to drastically different ways of modifying their load command areas or dependency entries. If the characteristics of these file formats are not addressed specifically and modifications are made blindly, the operating system may be unable to correctly parse the main executable file, resulting in dynamic framework loading failure or even application crashes, thus affecting the compatibility and stability of the security enhancement scheme.

[0038] In this embodiment, the main executable file is in Mach-O or ELF format. When the main executable file is in Mach-O format, a load command pointing to the dynamic frame is inserted into the load command area; the load command is the LC_LOAD_DYLIB command; updating the main executable file includes: updating the number of load commands and the total size of load commands in the Mach-O file header; after inserting the new load command, all segment commands in the Mach-O file are traversed, and the file offset recorded in each segment command is obtained; based on the total offset increment caused by the expansion of the load command area, the total offset increment is added to each file offset and then rewritten to the corresponding field; the code signature data area pointed to by the LC_CODE_SIGNATURE load command is located, and the signature data in it is marked as invalid; When the main executable file is in ELF format, inserting a dependency entry pointing to the dynamic framework in the load command area specifically involves: adding a DT_NEEDED dependency entry at the end of the dependency list in the dynamic section; updating the main executable file includes: updating the entry count field of the dynamic section and the file size and memory size of the corresponding entry in the program header table where the dynamic section is located; for the dynamic framework path referenced in the DT_NEEDED dependency entry, a relative path format containing only the library file name is used; before adding a DT_NEEDED dependency entry at the end of the dependency list in the dynamic section, the current remaining capacity of the segment where the dynamic section is located is read. If the remaining capacity is less than the length required for the DT_NEEDED dependency entry to be added, the entire dynamic section is relocated to the end of the ELF file and the allocated space is expanded. At the same time, all entries in the program header table are traversed, and the file offset field in the entries whose offset has changed due to relocation is updated to the new offset value.

[0039] Specifically, the main executable file is the core binary file of the application, and its format determines how the operating system loads and executes the program and its dependent dynamic libraries. Mach-O (Mach Object) format is the file format used by Apple operating systems (such as iOS and macOS) for executable files, object files, and dynamic libraries. ELF (Executable and Linkable Format) format is the standard file format for executable files, object files, and shared libraries widely used in Unix-like systems such as Linux and Android. These two formats differ significantly in their internal structure, loading mechanisms, and dynamic linking information storage methods, thus requiring targeted modifications.

[0040] When the main executable file is in Mach-O format, its load command section is a series of data structures following the Mach-O file header. These structures describe various information required for program loading and execution, including segment information, symbol tables, and dynamic library dependencies. To enable the operating system to automatically load pre-built dynamic frameworks when loading the main executable file, an LC_LOAD_DYLIB command needs to be inserted into this load command section. The LC_LOAD_DYLIB command is a type of Mach-O load command specifically designed to instruct the dynamic linker (dyld) to load a specified dynamic library at runtime. When inserting this command, the path to the dynamic framework is usually specified, for example, using the form "@rpath / dynamic framework name," to ensure that the dynamic linker can correctly find and load the framework. Since the Mach-O file header records the number of load commands (ncmds) and the total number of bytes for all load commands (sizeofcmds), these two fields in the Mach-O file header must be updated synchronously after inserting a new LC_LOAD_DYLIB command. If not updated, the dynamic linker will be unable to correctly parse the load command area, which may cause the application to fail to start or the security framework to fail to load.

[0041] When the main executable file is in ELF format, its dynamic linking information is primarily stored in a section named ".dynamic". This section contains a series of dynamic tags, where the DT_NEEDED tag specifies the shared libraries the program depends on. To introduce a dependency on a dynamic framework in the ELF-formatted main executable file, a DT_NEEDED dependency entry needs to be added to the end of the dependency list in the dynamic section. This entry points to the injected dynamic framework (usually a ".so" file). After adding the dependency entry, the structure information of the main executable file needs to be updated, including updating the entry count field of the dynamic section to reflect the new dependency. Furthermore, if the size of the dynamic section changes due to the added entry, the file size of the corresponding entry in the Program Header Table containing the dynamic section also needs to be updated to ensure that the operating system can correctly recognize and load the modified ELF file.

[0042] This invention addresses the Mach-O format by inserting the LC_LOAD_DYLIB command, compensating for the file offset of the segment command, and marking the original signature data as invalid. This ensures the modified file conforms to the operating system loader specification and can regenerate a complete code signature. For the ELF format, it adds a DT_NEEDED dependency entry using a relative path format and relocates the dynamic section to the end of the file and updates the offset of affected entries when space is insufficient. This enables the dynamic framework to be correctly parsed and loaded by the dynamic linker. The synergistic effect of these two format modification schemes is that both achieve native automatic loading of the dynamic framework by precisely modifying the executable file format metadata, while maintaining file format compliance and signature validity, ensuring cross-platform compatibility.

[0043] In some of the above implementations, all files in the directory structure are recursively signed using a dedicated signature to generate a security-enhanced installation package. However, in the mobile application ecosystem, especially in operating system environments with strict code signature verification mechanisms such as iOS, performing a single cryptographic signature operation may not be sufficient to ensure that the application package, after being modified and re-signed, can still be recognized as legitimate and trustworthy by the operating system, and can be successfully installed and run. The operating system typically needs to verify the source of the signature, permissions, and the application's distribution scope to prevent unauthorized applications from being loaded or tampered with, which poses a challenge to post-build, implant, and re-sign solutions.

[0044] To address this, the present invention further proposes a dedicated signature comprising a dedicated certificate and a description file. The dedicated certificate is a digital identity credential, its core being a public key and a private key pair. The private key is used to encrypt the hash value of the application package, generating a digital signature to prove the identity of the signing entity. The public key is used by the operating system to verify the authenticity of this signature and the integrity of the application package. In practice, this dedicated certificate is typically issued by a trusted third-party organization (such as Apple) to a specific developer or enterprise and associated with a specific developer account. The description file not only defines the system services and functions the application can access (such as push notifications, data protection, etc.), but also specifies which certificates are authorized for signing the application and on which devices the application can run. During application packaging, the description file is embedded in the application package and rigorously verified by the operating system during application installation and startup to ensure the application complies with preset security and distribution policies.

[0045] In this embodiment, all files under the directory structure are recursively signed using a dedicated signature, including: Iterate through each file in the directory structure, read the binary content of the file and calculate its hash value; A signature block is generated by signing the hash value using the private key of a dedicated certificate. The description file is copied to a preset location in the directory structure, and the signature block is written to the signature area of ​​the corresponding file.

[0046] Specifically, during recursive signing, each file in the directory structure is first traversed. This traversal ensures that all files within the installation package, including the main executable, dynamic framework implementation binaries, manifest files, and other resource files, are included in the signature verification process. For each traversed file, its hash value is calculated. The hash value is a digital fingerprint of the file's content, typically generated using a specific hash algorithm (such as SHA-256). Its characteristic is that any minor modification to the file content will cause a significant change in the hash value. This step forms the basis for subsequent verification of file integrity.

[0047] Subsequently, the hash value of each file calculated above is signed using the private key of the dedicated certificate, thus obtaining a signature block. The dedicated certificate is a digital credential used to identify the application publisher, containing a public and private key pair. The private key is kept secret and held only by the authorized party, used to generate the digital signature; the public key is public and used to verify the validity of the signature. Signing the hash value with the private key actually creates an encrypted digest that proves the file content has not been tampered with after signing and that the signature was indeed generated by the entity holding the corresponding private key. This signature block typically contains the encrypted hash value and certificate chain information, and is embedded in a specific location within the installation package. For example, on the iOS platform, the signature information is stored in a specific section of the Mach-O file or a separate signature directory.

[0048] Simultaneously, the provisioning description file is copied to a preset location within the directory structure. This provisioning description file is a crucial component of the mobile application distribution mechanism, defining which devices the application can run on, which system services it can access, and which developer signed it. Placing it in the preset location specified by the operating system or application package format specification (for example, in iOS ".ipa" packages, the provisioning description file is typically named "embedded.mobileprovision" and placed in the root directory of the application package) is a necessary condition for the operating system to perform legitimacy verification when loading and running the application.

[0049] This invention uses the private key of a dedicated certificate to perform a signature operation on the file hash value to generate a signature block, and copies the description file to a preset location, so that the integrity of each file can be independently verified and the source is trustworthy; the recursive signature covers all files in the directory structure, so that the security-enhanced installation package forms a complete trusted chain from individual files to the overall package structure.

[0050] In some embodiments of the present invention described above, a pre-built dynamic framework is proposed to be set in the directory structure of the application installation package. This dynamic framework includes a function implementation binary file, a manifest file, and a policy interface. However, if the definitions of the manifest file and policy interface are too broad, it may lead to a lack of standardization and fine-grained control in the identification, version management, and runtime policy acquisition and application of the dynamic framework, thereby limiting the flexibility, maintainability, and rapid response capability to emerging threats in security protection.

[0051] To address this, the present invention further proposes that the manifest file should at least include a dynamic framework identifier and a dynamic security policy version number; the policy interface performs the following steps during the dynamic framework self-initialization phase: Detect the current network environment; If internet access is detected, a policy request is proactively sent to the remote server via the HTTPS protocol; If an industrial intranet without an internet exit is detected, an industrial protocol extension field communication channel is configured, and a preset industrial gateway address is read; wherein, the industrial protocol extension field communication channel encapsulates the policy request into the extension field of the industrial communication protocol message.

[0052] The dynamic framework identifier is a string or numeric value used to uniquely identify a specific dynamic framework. For example, it can be represented by a globally unique identifier (UUID), a reverse domain name format (such as "com.example.security.antifraud"), or a predefined integer encoding. Its purpose is to enable precise differentiation and management when multiple security dynamic frameworks exist in the system, ensuring no confusion occurs when loading, configuring, or unloading a specific framework, thus providing a foundation for framework lifecycle management and targeted policy distribution.

[0053] The dynamic security policy version number is used to indicate the version information of the set of security policies that the current dynamic framework expects or is using. This version number can be a semantic version (such as "1.0.0"), a timestamp, or an incrementing integer sequence. By introducing a version number, it is ensured that when the dynamic framework retrieves policies from a remote server, it can request the latest policy configuration that is compatible with itself, avoiding functional abnormalities or security vulnerabilities caused by policy version mismatches, while also supporting policy canary release and rollback mechanisms.

[0054] The manifest file declares initialization function symbols that are called when the operating system or application loads the dynamic framework to perform necessary initialization operations. For example, this function can be named "SEC_INIT()" or "initializeSecurityModule()". Its purpose is to provide a standardized start point for the dynamic framework. Within this function, critical preparatory work such as resource allocation, internal state settings, registration with the application entity, and establishing a communication channel with the remote policy server can be completed, ensuring that the dynamic framework is in the correct running state before starting to perform security protection tasks.

[0055] The policy interface is a set of application programming interfaces (APIs) or communication mechanisms designed to allow the dynamic framework to proactively interact with a remote policy management server at application runtime to obtain the latest security policy configuration data and adjust its own protection behavior accordingly. Specifically, this interface can encapsulate HTTP / HTTPS requests to send policy requests (e.g., carrying information such as the current application version and device fingerprint) to the remote server and receive policy configuration data returned by the server (e.g., in JSON or XML format). Upon receiving the policy data, the policy interface parses it and transforms it into executable policy instructions within the dynamic framework. This in turn guides the functional implementation binary to perform corresponding security protection operations, such as updating whitelist rules, adjusting encryption algorithm parameters, or enabling / disabling specific protection functions.

[0056] This invention declares the dynamic framework identifier and dynamic security policy version number through a manifest file, enabling the runtime environment to accurately identify the security module's identity and track the policy iteration status. During the self-initialization phase, the policy interface probes the network environment. When the Internet is accessible, policy requests are sent via HTTPS. When there is no Internet access, the request is encapsulated in the communication channel through the industrial protocol extension field, allowing the same dynamic framework to adaptively select the communication method based on the actual network conditions of the terminal. The synergistic effect of the industrial protocol extension field and the pre-set industrial gateway address enables policy requests to penetrate the industrial network boundary and complete the transmission of security policies without affecting the original industrial communication services.

[0057] The following details the complete runtime workflow of the policy interface: Three-dimensional triggering mechanism for policy requests: The policy interface of this invention does not trigger policy requests under a single condition, but adopts a three-dimensional triggering mechanism: 1) Startup-triggered: During the execution of the dynamic framework's initialization function, as the last step in the initialization process, it actively calls the policy interface to initiate the first policy request. This stage is a blocking mode—before the dynamic framework successfully pulls, verifies, and applies the first policy data, it does not open the normal execution path of the application's main business logic to ensure that security protection is in place before the business logic runs. If the first request fails (timeout or verification failure), the dynamic framework loads the local cached policy as a fallback and records an alarm. 2) Timer-triggered: The initial policy data carries a refresh_interval field (unit: minutes, default value 360), and the dynamic framework sets a background timer accordingly; each time the timer expires, the policy interface initiates an incremental update request, carrying the currently effective policy_version in the request. The policy server compares the version number in the request with the latest version number on the server: if they match, it returns HTTP 304 Not Modified (HTTPS channel) or status code 0x00 indicating no update (industrial protocol channel), and the dynamic framework resets the timer; if an updated version exists on the server, it returns the complete policy configuration data. 3) Event-triggered: The security event listener inside the dynamic framework continuously monitors changes in the terminal state. When any of the following security level change events are detected, an emergency policy request is immediately triggered (marked with priority=high in the request header, and the server processes it first): jailbreak / root status change (from non-jailbroken to jailbroken, or vice versa); USB debugging mode is enabled or disabled; network environment type switch (internal WiFi / public 4G / 5G / VPN); debugger attachment is detected (based on ptrace or the debugged flag TracerPid detection); suspicious dynamic library injection is detected (based on dyld insertion detection, discovering non-whitelisted dynamic library paths).

[0058] The policy request carries dynamically generated information: In addition to version identifier, device fingerprint, and runtime environment parameters, the policy request also dynamically generates and carries the following context information: policy_version—the version number of the currently effective local policy (0 for the first request); status_report—the operational statistics of each protection module in the most recent period, including the number of interceptions, alarm records, false alarms, and a list of specific rule IDs that were hit; event_summary—a list of event summaries for the most recent N security events (default N=20), each summary including the event type (event_type), occurrence time (timestamp), and handling result (result: blocked / passed / logged). The server uses the status reporting data to update the terminal profile in real time and continuously evaluate the effectiveness of policy rules (if a rule causes an excessively high false alarm rate, it will automatically downgrade or roll back).

[0059] Verification of the integrity and authenticity of policy configuration data: 1) Digital signature verification: When the policy server issues policy configuration data, it uses its RSA-2048 private key to sign the SHA-256 hash value of the policy data body (PKCS#1v1.5 format). After the dynamic framework extracts the policy data, it uses a pre-set public key certificate to decrypt the digital signature to obtain the expected hash value H1, and then calculates the SHA-256 hash value H2 for the policy data body independently. H1 and H2 are compared. If they match, the data integrity is confirmed. 2) Certificate chain verification: The dynamic framework pre-sets a root CA certificate (written offline and cannot be modified by the application layer). It verifies the certificate chain from the server certificate up to the root CA certificate, checking the validity period and signature validity of each level of certificate. 3) Version comparison and policy activation: After both verifications pass, the received policy version number is compared with the locally cached policy_version. If the new version number is higher, the parsing and scheduling registration process is entered and the local cache is updated; if the version number is the same or lower, it is discarded and a duplicate issuance event is recorded. 4) Rollback handling for verification failures: If the signature or certificate chain verification fails, discard the received policy data and record a detailed security log, and roll back to the previous version of the valid policy cached locally; if the policy verification fails 3 times in a row, trigger a security alarm - which may be due to a man-in-the-middle attack or the policy server being impersonated.

[0060] In this embodiment, the dynamic framework initiates its own policy requests; the triggering timing of policy requests includes: During the execution of the initialization function, a policy request is constructed and sent for the first time; after the initial security policy is successfully retrieved, the refresh interval parameter is extracted from the policy configuration data, and a timer is started according to the refresh interval parameter. When the timer expires, the policy request is reconstructed and sent; and when a preset security event is detected, an emergency policy request is immediately constructed and sent.

[0061] This invention enables policy requests to be initiated autonomously by the dynamic framework without relying on explicit calls from the main executable file, making the acquisition and updating of security policies completely independent of business logic. Initialization triggers establish baseline protection, timed refresh triggers maintain the continuous effectiveness of policies, and emergency triggers for security events enable real-time emergency response. The synergistic effect of these three triggering mechanisms forms a closed-loop policy update system from static deployment to dynamic evolution, ensuring that deployed applications can continuously acquire protection capabilities against new security threats.

[0062] In some embodiments of the present invention described above, a method is proposed to generate a security-enhanced installation package by embedding a pre-built dynamic framework into the application installation package and re-signing it. However, simply embedding the dynamic framework into the application package does not guarantee that it can be effectively loaded and initialized at application runtime, and that dynamic protection can be performed according to the latest security policies. This may result in the security protection capability failing to respond promptly to constantly changing security threats.

[0063] In response, this invention further proposes that after the dynamic framework is loaded, it automatically calls the initialization function. The initialization function sends a policy request to a preset remote address through the policy interface. The policy request carries the current application version identifier, device fingerprint, runtime environment parameters, locally effective policy version number, the status report data of the most recent policy execution, and security event summary information. The policy configuration data is verified. If the version is updated, it is parsed into policy instructions in the leaf nodes to perform security protection operations. This includes: obtaining the digital signature attached to the policy configuration data and verifying the digital signature using a pre-configured policy server public key certificate; after successful verification, comparing the policy configuration data with the version number of the locally effective policy; if the version number of the policy configuration data is updated, parsing the policy configuration data into policy instructions in the leaf nodes; and performing security protection operations according to the policy instructions.

[0064] For example, for a Mach-O format executable, the dynamic linker will recognize and process the LC_LOAD_DYLIB command, thereby loading the specified dynamic library into the process space; for an ELF format executable, it will load the corresponding shared library according to the dependency entries in the dynamic section.

[0065] Once the functional implementation binary file of the dynamic framework is successfully loaded, its preset initialization function will be automatically executed by the system or called during the application startup process. This initialization function is the key entry point for the dynamic framework to start its core functions and perform self-configuration. During initialization, the dynamic framework will actively send a policy request to a preset remote address through its built-in policy interface. This policy interface typically encapsulates network communication protocols and data transmission mechanisms to ensure that the dynamic framework can interact with the remote server securely and reliably. The policy request can carry the current application's identifier, version information, device fingerprint, and runtime environment parameters, so that the remote server can dynamically generate and issue customized security policies based on this information. Specifically, the current application version identifier carried in the policy request refers to the unique version information of the running application, such as the software version number and build number. By carrying the version identifier, the remote server can identify the current iteration stage of the application, thereby issuing customized security policies for known vulnerabilities or specific functions that may exist in that specific version. For example, for an older version of the application known to have a certain security flaw, the server can issue a stricter protection policy; while for a newer version, it may issue a more streamlined or optimized policy. The version identifier can typically be obtained from the metadata of the application installation package. The device fingerprint refers to a comprehensive set of information used to uniquely identify a user's device. It is generated by collecting device hardware information, operating system information, network information, and other application-related information, and then performing hash calculations or encryption. The introduction of device fingerprints allows remote servers to identify whether the device requesting the policy is a known device or has a history of abnormal behavior, thereby enabling differentiated policy delivery based on device reputation. For example, stronger protection measures can be applied to high-risk devices, or a smoother experience can be provided to trusted devices. The runtime environment parameters refer to the specific environmental state in which the application runs. This may include, but is not limited to: whether the device is jailbroken or rooted, whether debug mode is enabled, whether a VPN is connected, the current network type, geographical location information, system time, and whether an emulator or virtual machine environment exists. These parameters can reflect the security or potential risks of the application's runtime environment. For example, when a jailbroken device or debugger is detected, the server can issue stricter anti-debugging and anti-tampering policies; in an insecure network environment, stronger data encryption measures may be required. These parameters are typically obtained by calling APIs provided by the operating system or by performing system status checks.

[0066] Upon receiving the policy configuration data returned by the remote server, the dynamic framework parses it. This policy configuration data is typically carried in a structured format (e.g., JSON, XML, or a custom binary format), and the parsing module within the dynamic framework converts it into actionable policy instructions in leaf nodes. These leaf node policy instructions are the smallest granularity security rules, such as "enable anti-debugging functionality," "monitor specific APIs," and "restrict writing to a specific file path."

[0067] Ultimately, the dynamic framework will execute corresponding security protection operations during application runtime based on these parsed policy instructions. These operations may include, but are not limited to, encrypting sensitive data, intercepting specific system calls, verifying the memory integrity of application processes, and filtering network communications.

[0068] This invention automatically activates security capabilities through the operating system's native loading mechanism without modifying the business code of the main executable file. Policy requests carry version identifiers, device fingerprints, runtime environment parameters, local policy version numbers, and security event summaries, enabling remote servers to generate differentiated policies that accurately match the actual state of the terminal based on a multi-dimensional terminal profile. Digital signature verification ensures the integrity and reliability of policy configuration data, preventing policy tampering or forgery. After successful signature verification, version comparison is performed, and policy instructions are only parsed into leaf node instructions and executed when the policy is updated. Version comparison avoids resource waste caused by repeated execution, and leaf node parsing transforms the hierarchical policy tree into directly executable atomic instructions. The combination of these two aspects ensures that the terminal always executes the latest policy while improving the efficiency and accuracy of policy execution.

[0069] The following details the organizational structure of the strategy configuration data and the specific implementation process of leaf node parsing: The policy configuration data is structured in a tree format (JSON format): The policy configuration data issued by the policy server is encoded in JSON format, and its overall structure is a policy tree. The root node of the policy tree is a global policy metadata object, which contains at least the following fields: policy_id (unique policy identifier), policy_version (policy version number), effective_time (policy effective time window, including start and end timestamps), refresh_interval (policy refresh interval), and branches (policy branch array). Each policy branch object is an intermediate node or a leaf node. Intermediate nodes contain dimension (protection dimension identifier, such as network_filter, memory_protect, data_encrypt, anti_screenshot), condition (conditional expression), and sub_branches (sub-branch array). Each leaf node no longer contains sub_branches, but directly contains action—an atomic policy instruction object, which at least includes target_module (target protection module identifier), action_code (action code, such as 0x01=block, 0x02=alarm recording, 0x03=silently allow but report, 0x04=allow after encryption), action_params (action parameter object), and priority (priority, integer).

[0070] The strategy tree traversal and leaf node parsing algorithm: The strategy parsing module of the dynamic framework performs the following steps: a) Deserialize the received strategy configuration data into JSON. If deserialization fails, discard the data and trigger a security alarm; b) Extract strategy metadata from the root object and compare it with the local strategy version number. If the version number is not higher than the local cached version, skip the parsing; c) Take all strategy branches from the branches array of the root object and recursively execute the traversal algorithm for each branch: If the current node contains a condition field, match the environment variable name in the condition with the actual running environment parameters of the current device. If the match is successful, continue traversing the sub_branches of that node; if the match fails, skip the branch; if the current node does not contain a condition field (i.e., it is an unconditional branch), directly enter the sub_branches traversal. When a node without a sub_branches field is traversed, it is a leaf node, and the action object in it is extracted as an atomic strategy instruction; d) Sort all extracted atomic strategy instructions in ascending order of their priority field (the smaller the priority value, the earlier it is executed), and then register the sorted instruction list to the strategy execution schedule table. e) If a conditional branch expression in the policy tree references a field that is not supported by the current device or system version, skip that branch and use the default security baseline policy specified in the root node of the policy tree as a fallback.

[0071] Policy execution scheduling: During runtime, the security event listener within the dynamic framework continuously captures security events (such as network packet interception, memory page attribute changes, file I / O operations, screenshot system calls, etc.). Each security event carries an event type identifier (event_type). After an event is captured, the policy execution scheduling module traverses the atomic policy instructions in the scheduling table, comparing the target_module of each instruction in descending order of priority to see if it matches the event type—the first successfully matched instruction is executed, its action_code is invoked, and the action_params parameter is passed in; subsequent instructions of the same type are not executed (i.e., the policy is executed as soon as the first match is found), to avoid policy conflicts.

[0072] This invention transforms a hierarchical policy tree into directly executable fine-grained policy atomic instructions by deserializing JSON and expanding conditional branches layer by layer from the root node to the leaf node. After sorting by priority, these instructions are registered in the policy execution schedule table, enabling multiple policy atomic instructions to be executed in an orderly manner and avoiding policy conflicts.

[0073] In some of the above implementations, the dynamic framework performs security protection operations at runtime. However, if these operations lack specificity and diversity, they may be difficult to effectively cope with increasingly complex and ever-changing attack methods, especially in high-risk application scenarios such as industrial control and sensitive data processing. How to ensure that security protection operations can cover multiple attack surfaces and provide refined protection to effectively resist specific threats is a technical problem that urgently needs to be solved.

[0074] In this embodiment, the security protection operations include at least one of the following: performing instruction-level whitelist filtering on industrial communication protocol messages, performing integrity verification on the memory page attributes of application processes, encrypting sensitive data before writing it to storage, and performing hook detection on screenshot system calls and adding invisible watermarks.

[0075] Specifically, instruction-level whitelist filtering of industrial communication protocol messages refers to the dynamic framework performing deep parsing of industrial communication protocol messages sent or received by the application at runtime and verifying them according to preset whitelist rules. These whitelist rules can be dynamically issued by policy configuration data and include allowed protocol instruction types, parameter ranges, register addresses, etc. For example, for the Modbus TCP protocol, the whitelist can restrict reading only data from specific register addresses, limit the numerical range of write operations, or filter abnormally frequent query requests to prevent denial-of-service attacks. Any message that does not conform to the whitelist rules will be intercepted or logged, effectively preventing malicious instruction injection or tampering.

[0076] Integrity verification of application process memory page attributes refers to the dynamic framework periodically checking the page attributes (e.g., read, write, and execute permissions) of the memory regions occupied by the application process during application runtime or when triggered by specific events. By comparing these attributes with preset, known security baselines, unauthorized modifications to memory page attributes can be detected, such as modifying non-executable data pages into executable pages. This is typically a characteristic of code injection or memory tampering attacks. Once an anomaly is detected, the dynamic framework can trigger alerts, terminate the process, or take other protective measures to maintain the integrity of the application's runtime environment.

[0077] Encrypting sensitive data before it is written to storage refers to the dynamic framework encrypting sensitive data (such as user credentials, encryption keys, personal identification information, industrial control parameters, etc.) before an application attempts to write it to the device's persistent storage medium. This encryption process can be implemented by intercepting file I / O-related system calls or APIs. The dynamic framework uses a preset encryption algorithm (e.g., AES-256) and a key to encrypt the sensitive data, and then writes the encrypted ciphertext to storage. In this way, even if the storage medium is accessed illegally, unauthorized third parties cannot directly obtain the original sensitive data, thus effectively protecting the confidentiality of the data.

[0078] Hooking and adding invisible watermarks to screenshot system calls refers to a dynamic framework intercepting screenshot-related system calls or APIs provided by the operating system or application framework using hooking technology. When a screenshot operation is detected, the dynamic framework can choose to block the screenshot behavior according to policy instructions, or process the screenshot image before it is generated, embedding an invisible watermark that is difficult to detect with the naked eye. This invisible watermark can encode information such as device identifier, user ID, and timestamp. Once the screenshot content is leaked, the source of the leak can be traced by analyzing the watermark information, thereby effectively preventing data leakage through screenshots.

[0079] This invention achieves fine-grained access control at the network communication layer by filtering industrial communication protocol messages using an instruction-level whitelist, preventing attacks on industrial control systems by unauthorized commands; it provides runtime memory protection by verifying the integrity of application process memory page attributes, preventing code injection and memory tampering; it ensures the confidentiality of the data storage layer by encrypting sensitive data before writing it, preventing data theft; and it enables data leakage tracing capabilities at the UI layer by detecting screenshot system call hooks and adding invisible watermarks. The synergistic effect of these multi-dimensional protection operations constructs a full-stack security protection system from network, memory, storage to UI.

[0080] Based on this, policy configuration data is dynamically generated based on device fingerprints, version identifiers, and runtime environment parameters. The generation steps include: after receiving a policy request, the remote server queries the terminal profile database based on the device fingerprint to obtain the terminal's historical security event records and historical risk scores; matches the corresponding policy rule set from the policy rule base based on the version identifier; assesses the current terminal's environmental risk level based on runtime environment parameters; and dynamically combines and generates differentiated policy configuration data from the policy rule set based on the environmental risk level, version identifier, and historical risk scores. This means that the remote server no longer simply returns a preset static policy, but instead generates or selects the most suitable policy configuration data for the current context in real time through intelligent analysis and decision-making engines based on the received version identifier, device fingerprint, and runtime environment parameters. For example, the server can maintain a policy rule base containing policy templates or rule sets for different application versions, different device risk levels, and different runtime environment conditions (such as jailbreaking, debugging, and specific networks). When a policy request is received, the server matches and combines the most appropriate policy instructions from the rule base based on the parameters carried in the request, thereby achieving refined and adaptive policy management.

[0081] The following details the specific implementation mechanism for generating differentiation strategies: Terminal Profile Database: The remote policy server maintains a unique terminal profile record for each device fingerprint, including the following fields: device registration time, recent active time, historical security event record list (each record includes event type, occurrence time, and handling result), policy hit count statistics for each protection module (including the number of interceptions and false alarms), and device reputation score (0-100 points, initial value 50 points, dynamically adjusted each time a security event is triggered: deduct 30 points for detecting jailbreaking / root behavior, deduct 20 points for detecting debugger attachment, and add 5 points for no security events for 30 consecutive days).

[0082] Environmental Risk Level Assessment Matrix: When constructing a policy request, the dynamic framework collects the following runtime environment parameters of the current terminal and reports them in the request: jailbroken / rooted status (risk weight 30), debug mode identifier (risk weight 25), emulator / virtual machine environment identifier (risk weight 30), VPN / proxy connection status (risk weight 15), and unauthorized USB debugging status (risk weight 10). After receiving the above parameters, the policy server performs a weighted summation of each parameter to obtain an environmental risk score. A score ≥ 50 indicates a high-risk environment, 20-49 indicates a medium-risk environment, and < 20 indicates a low-risk environment.

[0083] Specific examples of policy differentiation: Terminal A (engineer-specific explosion-proof tablet, not jailbroken, WiFi intranet, reputation score 85, environmental risk score 5 = low risk): Receives a policy including basic Modbus whitelist filtering + standard data encryption, refresh interval 360 minutes, performance overhead approximately 2%; Terminal B (ordinary commercial tablet, rooted, connected to public WiFi, reputation score 15, environmental risk score 70 = high risk): Receives a comprehensive protection policy including strict anti-debugging detection + full memory page integrity verification + prohibition of screenshots + interception of all non-whitelisted Modbus commands, refresh interval 30 minutes, whitelist scope narrowed to only allowing reading of specified register addresses; Terminal C (old version application v1.2, reputation score 40, environmental risk score 35 = medium risk): Receives a specific protection policy for known v1.2 vulnerabilities (additionally adds hook detection for known API vulnerabilities in this version), and a prompt field suggesting an upgrade.

[0084] It should be noted that this invention differs fundamentally from the third type of prior art implementation method mentioned in the background section: for example, CN107305495A, which performs the exact same modification operation (adding the same dynamic library) on all devices, and the modified application exhibits completely consistent functions and behaviors on all terminals. However, this invention, through a differentiated policy generation mechanism, enables the same application installation package to load and execute different security policies on different terminals, achieving personalized policy distribution based on terminal context. Specifically, this invention uses device fingerprints to associate historical security event records and risk scores, enabling policy generation to be personalized based on the long-term security behavior characteristics of the terminal; it matches the corresponding policy rule set according to the version identifier, ensuring that the policy is precisely adapted to the code structure and security requirements of the current application version; it assesses the real-time environmental risk level based on runtime environment parameters, allowing the policy strength to be dynamically adjusted according to the terminal's security posture; historical risk scores provide long-term trend judgments, environmental risk levels provide real-time status assessments, and version identifiers provide application context constraints. The synergistic effect of these three elements achieves a shift from unified static protection to dynamic and precise protection that varies depending on the device and time.

[0085] More importantly, the third type of prior art implementation method mentioned in the background technology is fundamentally different: for example, CN107305495A, its dynamic library only executes the corresponding logic when the main program explicitly calls its exported functions (such as dlopen / dlsym), which belongs to the passive calling mode; the dynamic framework of this invention declares the initialization function entry (such as SEC_INIT) in the manifest file, which is automatically called by the operating system dynamic linker after the dynamic library is loaded, without the main executable file needing to call it explicitly, which belongs to the self-starting mode.

[0086] Furthermore, the dynamic library of CN107305495A lacks any autonomous network communication capabilities; all its behaviors are driven by the main program. In contrast, the dynamic framework of this invention actively probes the network environment and establishes a communication channel with the policy server during the initialization phase, autonomously initiating policy requests, thus constituting an active network behavior entity. Moreover, the functionality of the dynamic library of CN107305495A is fixed at compile time, making it impossible to adjust its behavior after release. The dynamic framework of this invention adopts a policy-driven architecture, where its runtime behavior is dynamically determined by remotely distributed policy configuration data, completely separating policy and execution logic in time and space.

[0087] Furthermore, CN107305495A does not involve the design of policy acquisition channels; the dynamic framework of this invention uses the HTTPS protocol in the Internet environment, and automatically switches to the industrial protocol extended field transmission mode (such as Modbus reserved function code 0x42, OPC UA custom node) in the industrial intranet environment without Internet, and has the ability to adapt to the network environment.

[0088] Preferably, the runtime environment parameters include at least jailbroken or rooted status, debug mode identifier, network type, and emulator detection results, with each parameter corresponding to a different scoring weight.

[0089] This invention incorporates jailbreak status, debug mode identifier, network type, and emulator detection results into the runtime environment parameters, enabling a comprehensive quantification of the terminal's security posture across four dimensions: system permission integrity, debug attack risk, network trustworthiness, and runtime environment authenticity. By configuring different scoring weights for each parameter, the impact of risks in different dimensions can be adjusted according to their security sensitivity, ensuring that high-risk environments trigger stricter policy responses and improving the precision of environmental risk assessment and the sensitivity of policy triggering.

[0090] The present invention will be further described below in the context of an industrial setting. Those skilled in the art will understand that this embodiment is merely illustrative of the specific application of the invention in an industrial environment and is not intended to limit the scope of the invention.

[0091] Application Background: A wind power company has developed a mobile application called "WindMonitor" to allow field engineers to monitor wind turbine status and configure parameters via a dedicated industrial tablet (explosion-proof tablet). The application connects to the wind turbine control system via Wi-Fi or 4G / 5G networks, enabling real-time monitoring of wind turbine operating parameters (speed, power, vibration, temperature, etc.), receiving equipment warnings and fault alarms, remotely configuring PLC parameters (such as yaw angle and pitch angle), downloading equipment operation logs and fault codes, and uploading inspection reports and maintenance work orders.

[0092] The application faces the following security threats: risk of tampering with operating instructions (attackers tamper with control instructions sent to the wind turbine, causing equipment damage or shutdown), risk of production data leakage (sensitive information such as wind turbine operating data, power generation, and equipment status is stolen), risk of malicious code propagation (malicious software is spread through the APP on the industrial intranet, affecting the entire wind farm), and risk of identity impersonation (unauthorized personnel impersonate engineers to operate equipment, causing security risks).

[0093] Security hardening requirements: prevent application reverse engineering to leak the fan control protocol; ensure the integrity of instructions sent to the PLC and prevent man-in-the-middle attacks; protect equipment operation data and prevent leakage through application side channels; and achieve strong correlation auditing between engineer identity and equipment operation.

[0094] The security enhancement approach integrates the following three dynamic security frameworks: 1) IndustrialCommSec.framework: An industrial communication protocol security module with built-in parsers for mainstream industrial protocols such as Modbus TCP, OPCUA, Profinet, and DNP3; 2) DataLeakagePrevent.framework: A data leakage prevention module used to monitor sensitive data outgoing channels and add dynamic watermarks; 3) OperatorAuthAudit.framework: Operator authentication and auditing module, used to implement identity authentication and operation auditing.

[0095] Post-build implantation: In the CI / CD pipeline, WindMonitor.ipa is hardened using a dedicated industrial security certificate. The specific steps are the same as the aforementioned method: parsing the original installation package, copying the dynamic framework, modifying the load command section of the main executable (inserting the LC_LOAD_DYLIB command and updating ncmds and sizeofcmds for Mach-O format), and recursively re-signing using the dedicated certificate and description file.

[0096] Policy Configuration: The cloud-based policy center configures specific policies for wind farms, such as: allowing reading only specific Modbus register addresses, restricting the range of written values ​​(e.g., temperature setpoints not exceeding the process limit), filtering abnormally frequent query requests to prevent DoS attacks, and digitally signing and binding engineer RFID tags with operation instructions.

[0097] Operational results: The hardened application automatically intercepts and alerts when it detects Modbus commands that are not on the whitelist; all wind turbine operations are bound to engineer ID RFID tags via digital signatures, enabling complete operation auditing; screenshot or photo operations are automatically watermarked to facilitate tracing the source of the leak.

[0098] Furthermore, the dynamic framework provided by this invention can further encapsulate the following industry-specific security protection functions to address advanced threats in industrial control environments: 1) Deep protection of industrial communication protocols: Through protocol instruction-level whitelist filtering, only predefined register address read and write operations are allowed, the range of written values ​​is limited, and abnormal frequency query requests are filtered (DOS prevention); at the same time, protocol compliance verification is performed to check whether the industrial protocol message format conforms to RFC or industry standards to prevent malformed message attacks.

[0099] 2) Production data outflow detection and control: Based on NLP and regular expressions, identify production data (formula, process parameters, output, quality data), monitor all data outlets such as email, instant messaging, cloud storage, and USB; add invisible watermarks to screenshots, photos and other behaviors to trace the source of leakage, and report detected events to the enterprise data leakage prevention system.

[0100] For application scenarios where mobile terminals cannot directly connect to the internet (such as industrial intranets), this invention provides the following strategy update and adaptation scheme. The complete implementation mechanism of the industrial protocol extension channel in dual-channel architecture is detailed below: 1) Indirect Updates Based on Industrial Gateways: When a terminal accesses industrial equipment (such as PLCs and sensors) through an industrial gateway, the gateway also acts as a policy relay. During the initialization phase, the dynamic framework's policy interface detects the network environment: if three consecutive HTTPS requests time out (timeout threshold 5 seconds), it automatically determines that there is no internet connection and switches the policy transmission mode to the industrial protocol extended channel. In this mode, the policy interface serializes the policy request metadata (including device fingerprint, policy version number, and request timestamp) to be sent into a JSON string, encodes it, and embeds it into the extended field of the industrial communication protocol message, sending it to the gateway along with the normal industrial communication message. After parsing the message, the gateway extracts the policy request data from the extended field and forwards it to the remote policy server via its own internet or dedicated network link. The policy server's response is encapsulated back into the extended field of the industrial protocol response message by the gateway and sent to the terminal's dynamic framework.

[0101] 2) Modbus TCP Protocol Extension Implementation: Taking Modbus TCP as an example, this implementation utilizes user-defined function codes (function codes 65-72 and 100-110) reserved in the protocol standard to carry policy data. Specifically, a policy service function code 0x42 (decimal 66, within the user-defined range) is defined: When the client (dynamic framework) constructs a policy request message, it sets the function code field to 0x42 after the standard MBAP header (7 bytes) and within the Protocol Data Unit (PDU). The data field carries policy request metadata in JSON format. After receiving the message with function code 0x42, the gateway does not forward it to the industrial equipment but extracts the data field content and sends it to the policy server through a secure channel. The policy configuration data returned by the policy server (including the policy version number, effective timestamp, and encrypted policy payload) is sent back by the gateway in the form of a return message with the same function code 0x42. The data field of the return message includes: a 4-byte policy version number (uint32), an 8-byte effective timestamp (Unix millisecond timestamp), a variable-length AES-256-GCM encrypted policy payload (the first 12 bytes are the nonce, and the last 16 bytes are the authentication tag), and a 32-byte HMAC-SHA256 signature. When parsing the Modbus response message, the dynamic framework's industrial protocol parser matches the function code field: if the function code is 0x42, it extracts the data field for decryption and verification; if the function code is another standard industrial function code, it is processed according to normal industrial logic.

[0102] 3) OPC UA Protocol Extension Implementation: Utilizing the OPC UA protocol's ExtensionObject mechanism and custom nodes to carry policy data. A dedicated policy service node (e.g., NodeId: ns=2;i=9001, BrowseName: SecurityPolicyChannel) is registered in the industrial gateway's OPC UA address space, with its TypeDefinition set to a variable node type. The dynamic framework uses the OPC UA client to call the Read service to read the node's current value. If the node value is empty or the version number is lower than the local cache, the policy request metadata is written to the node via the Write service. After detecting the write event of this node, the gateway initiates a policy request to the policy server through its uplink and updates the node's value attribute with the returned policy configuration data. The terminal dynamic framework monitors the node's data changes through a subscription mechanism, automatically fetching the latest policy data when a node value update is detected. The policy data uses UA Binary encoding, and the data structure definition includes: policy version number (UInt32), policy effective time (DateTime), encrypted policy payload (ByteString), and digital signature (ByteString).

[0103] 4) Fragmented Transmission and Resume Transmission: When the encrypted policy configuration data exceeds the single-frame carrying capacity limit (Modbus TCP ADU maximum 253 bytes, OPC UA single write limit depends on gateway configuration), the gateway adopts a fragmented transmission mechanism. Each fragment's protocol extension field includes a fragment header (8 bytes total): a 2-byte fragment identifier (frag_id, shared by all fragments in the same transmission), a 2-byte fragment sequence number (seq, starting from 0), a 2-byte total number of fragments (total), and a 2-byte fragment payload length. After receiving the fragments, the terminal dynamic framework arranges them in ascending order of seq and writes them to a temporary buffer. Once all fragments are received, the fragment headers are removed, and the fragments are concatenated into a complete ciphertext. The SHA-256 hash value is calculated and compared with the expected hash value carried in the first frame. If they match, the decryption and signature verification process begins; otherwise, a retransmission request is carried in the next round of industrial communication messages (the data field of function code 0x42 sets request_type=retransmit and a list of missing seq values).

[0104] 5) Rollback Mechanism and Local Caching: When the industrial protocol extended channel becomes unavailable (e.g., the gateway does not support function code 0x42 due to an outdated firmware version, or the OPC UA gateway has not registered a policy service node), the dynamic framework automatically rolls back to the locally cached policy. The locally cached policy is persisted to the application sandbox's private directory after each successful update, recording the policy's effective timestamp and version number. During each initialization phase, the dynamic framework first attempts an extended channel handshake (sending a policy handshake probe message with function code 0x43). If three consecutive handshakes fail (each with a 30-second interval), the locally cached policy is loaded, and the extended channel becomes unavailable. Simultaneously, a periodic retry timer (default retry interval 10 minutes) is started to continuously probe the extended channel's recovery status.

[0105] like Figure 2 As shown, the present invention also provides a software installation package security enhancement and parsing system for industrial intranets, which includes: Get module 10, used to obtain the original installation package that has been built and completed its initial signing; Parsing module 20 is used to parse the original installation package and obtain its directory structure; The injection module 30 is used to set the pre-built dynamic framework in the standard dynamic library directory in the directory structure; the dynamic framework includes a function implementation binary file, a manifest file, and a strategy interface; wherein, the function implementation binary file includes an initialization code segment and a network communication code segment, and the manifest file declares initialization function symbols; Modify module 40 to read the main executable file from the directory structure, parse the load command area of ​​the main executable file; and insert a load command or dependency entry pointing to the dynamic framework into the load command area and update the main executable file. The recursive signature module 50 is used to recursively sign all files in the directory structure using a special signature to generate a security-enhanced installation package; Execution module 60 is used to parse loading commands or dependency entries to load the functional implementation binary file of the dynamic framework when the security-enhanced installation package is loaded, and to call the corresponding initialization function according to the initialization function symbol. During execution, the initialization function calls the network communication code segment in the functional implementation binary file, establishes a communication connection with the policy server, and retrieves the initial security policy. Specifically, when the security-enhanced installation package runs on an industrial intranet terminal without internet access, the policy interface encapsulates the policy request into an extended field of an industrial communication protocol message, forwards it to the policy server via the industrial gateway, and receives a protocol response message from the industrial gateway. The system extracts policy configuration data from extended fields; the policy request carries the current application version identifier, device fingerprint, runtime environment parameters, locally effective policy version number, the status report data of the most recent policy execution, and security event summary information; it is also used to obtain the digital signature attached to the policy configuration data after extraction, and to verify the digital signature using a pre-set policy server public key certificate; after successful verification, the policy configuration data is compared with the locally effective policy version number. If the version number of the policy configuration data is updated, the policy configuration data is parsed into policy instructions for leaf nodes; and security protection operations are executed according to the policy instructions.

[0106] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For system embodiments, since they are basically similar to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0107] Furthermore, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0108] The foregoing description illustrates and describes preferred embodiments of the present invention. It should be understood that the present invention is not limited to the forms disclosed herein and should not be construed as excluding other embodiments. It can be used in various other combinations, modifications, and environments, and can be altered within the scope of the inventive concept by means of the foregoing teachings or techniques or knowledge in related fields. Any modifications and variations made by those skilled in the art that do not depart from the spirit and scope of the present invention should be within the protection scope of the appended claims.

Claims

1. A method for enhancing and parsing the security of software installation packages in an industrial intranet, characterized in that, Includes the following steps: Obtain the original installation package that has been built and initially signed; Parse the original installation package to obtain its directory structure; The pre-built dynamic framework is set in the standard dynamic library directory in the directory structure; the dynamic framework includes a function implementation binary file, a manifest file, and a strategy interface; wherein, the function implementation binary file includes an initialization code segment and a network communication code segment, and the manifest file declares initialization function symbols; Read the main executable file from the directory structure and parse the load command area of ​​the main executable file; Insert a loading command or dependency entry pointing to the dynamic framework into the loading command area, and update the main executable file; Recursively sign all files in the directory structure to generate a security-enhanced installation package; The system loads the enhanced security installation package, parses the new loading command or dependency entry to load the dynamic framework binary file, and calls the corresponding initialization function according to the initialization function symbol. When the initialization function is executed, it calls the network communication code segment in the function implementation binary file to establish a communication connection with the policy server and pull the initial security policy. When the enhanced security installation package runs on an industrial intranet terminal without internet access, the policy interface encapsulates the policy request into the extended field of the industrial communication protocol message, forwards it to the policy server via the industrial gateway, and extracts the policy configuration data from the extended field of the protocol response message returned by the industrial gateway. The policy configuration data is verified. If the version is updated, it is parsed into policy instructions for leaf nodes to perform security protection operations. Parsing the policy configuration data into policy instructions for leaf nodes includes: performing JSON deserialization on the policy configuration data to extract the policy tree structure; traversing each policy node in the policy tree, expanding conditional branches layer by layer from the root node until each branch reaches a leaf node that no longer contains child nodes; extracting the policy atomic instructions stored in each leaf node, wherein the policy atomic instructions at least include the target protection module identifier, operation action code, and action parameters; sorting the extracted policy atomic instructions by priority and registering them in the policy execution scheduling table inside the dynamic framework.

2. The method for enhancing and parsing the security of software installation packages in industrial intranets according to claim 1, characterized in that, The main executable file is in Mach-O or ELF format; When the main executable file is in Mach-O format, insert a loading command pointing to the dynamic frame in the loading command area; The loading command is the LC_LOAD_DYLIB command; Updating the main executable file includes: updating the number of load commands and the total size of load commands in the Mach-O file header; after inserting new load commands, traversing all segment commands within the Mach-O file and obtaining the file offset recorded in each segment command; adding the total offset increment to each file offset based on the total offset increment caused by the expansion of the load command area and rewriting it to the corresponding field; locating the code signature data area pointed to by the LC_CODE_SIGNATURE load command and marking the signature data therein as invalid; When the main executable file is in ELF format, inserting a dependency entry pointing to the dynamic framework in the loading command area specifically involves: adding a DT_NEEDED dependency entry at the end of the dependency list in the dynamic section; updating the main executable file includes: updating the entry count field of the dynamic section and the file size and memory size of the corresponding entry in the program header table where the dynamic section is located; for the dynamic framework path referenced in the DT_NEEDED dependency entry, a relative path format containing only the library file name is used; wherein, before adding a DT_NEEDED dependency entry at the end of the dependency list in the dynamic section, the current remaining capacity of the segment where the dynamic section is located is read. If the remaining capacity is less than the length required for the DT_NEEDED dependency entry to be added, the entire dynamic section is relocated to the end of the ELF file and the allocated space is expanded. At the same time, all entries in the program header table are traversed, and the file offset field in the entries whose offset has changed due to relocation is updated to the new offset value.

3. The method for enhancing and parsing the security of software installation packages in industrial intranets according to claim 1, characterized in that, Recursively sign all files under the aforementioned directory structure, including: Obtain a dedicated signature, which includes a dedicated certificate and a description file; Iterate through each file in the directory structure, read the binary content of the file and calculate its hash value; The hash value is signed using the private key of the dedicated certificate to generate a signature block; The description file is copied to a preset location in the directory structure, and the signature block is written into the signature area of ​​the corresponding file.

4. The method for enhancing and parsing the security of software installation packages in industrial intranets according to claim 1, characterized in that, The manifest file shall include at least the dynamic framework identifier and the dynamic security policy version number; The strategy interface performs the following steps during the dynamic framework's self-initialization phase: Detect the current network environment; If internet access is detected, a policy request is proactively sent to the remote server via the HTTPS protocol; If an industrial intranet without an internet exit is detected, an industrial protocol extension field communication channel is configured, and a preset industrial gateway address is read; wherein, the industrial protocol extension field communication channel encapsulates the policy request into the extension field of the industrial communication protocol message.

5. The method for enhancing and parsing the security of software installation packages in industrial intranets according to claim 4, characterized in that, The strategy requests of the dynamic framework are initiated autonomously by the framework itself. The timing of triggering the policy request includes: During the execution of the initialization function, a policy request is constructed and sent for the first time; after the initial security policy is successfully retrieved, a refresh interval parameter is extracted from the policy configuration data, and a timer is started according to the refresh interval parameter. When the timer expires, the policy request is reconstructed and sent; and when a preset security event is detected, an emergency policy request is immediately constructed and sent.

6. The method for enhancing and parsing the security of software installation packages in industrial intranets according to claim 1, characterized in that, After the dynamic framework is loaded, it automatically calls the initialization function. The initialization function sends a policy request to a preset remote address through the policy interface. The policy request carries the current application version identifier, device fingerprint, runtime environment parameters, locally effective policy version number, the status report data of the most recent policy execution, and security event summary information. The policy configuration data is verified. If the version is updated, it is parsed into policy instructions of leaf nodes to perform security protection operations, including: obtaining the digital signature attached to the policy configuration data and verifying the digital signature using a preset policy server public key certificate. After the signature verification is successful, the policy configuration data is compared with the version number of the locally effective policy. If the version number of the policy configuration data is updated, the policy configuration data is parsed into policy instructions for the leaf nodes; and security protection operations are performed according to the policy instructions.

7. The method for enhancing and parsing the security of software installation packages in industrial intranets according to claim 6, characterized in that, The security protection operations include at least one of the following: performing instruction-level whitelist filtering on industrial communication protocol messages, performing integrity verification on the memory page attributes of application processes, encrypting sensitive data before writing it to storage, and performing hook detection on screenshot system calls and adding invisible watermarks.

8. The method for enhancing and parsing the security of software installation packages in an industrial intranet according to claim 6, characterized in that, The policy configuration data is dynamically generated based on the device fingerprint, version identifier, and operating environment parameters. The generation steps include: after receiving a policy request, the remote server queries the terminal profile database based on the device fingerprint to obtain the terminal's historical security event records and historical risk scores; matches the corresponding policy rule set from the policy rule base based on the version identifier; assesses the current terminal's environmental risk level based on the operating environment parameters; and dynamically combines the environmental risk level, version identifier, and historical risk scores from the policy rule set to generate differentiated policy configuration data.

9. The method for enhancing and parsing the security of software installation packages in an industrial intranet according to claim 8, characterized in that, The runtime environment parameters include at least jailbroken or rooted status, debug mode identifier, network type, and emulator detection results, with each parameter corresponding to a different scoring weight.

10. A software installation package security enhancement and parsing system for an industrial intranet, characterized in that, include: The acquisition module is used to obtain the original installation package that has been built and initially signed; The parsing module is used to parse the original installation package and obtain its directory structure; An injection module is used to set the pre-built dynamic framework in the standard dynamic library directory of the directory structure; the dynamic framework includes a function implementation binary file, a manifest file, and a strategy interface; wherein, the function implementation binary file includes an initialization code segment and a network communication code segment, and the manifest file declares initialization function symbols; The modification module is used to read the main executable file from the directory structure, parse the loading command area of ​​the main executable file, insert a loading command or dependency entry pointing to the dynamic framework into the loading command area, and update the main executable file. The recursive signature module is used to recursively sign all files in the directory structure using a dedicated signature to generate a security-enhanced installation package. The execution module is used to load the security-enhanced installation package, parse the new loading command or dependency entry to load the dynamic framework binary file, and call the corresponding initialization function according to the initialization function symbol. When the initialization function is executed, it calls the network communication code segment in the function implementation binary file, establishes a communication connection with the policy server, and pulls the initial security policy. When the security-enhanced installation package runs on an industrial intranet terminal without Internet access, the policy interface encapsulates the policy request into the extended field of the industrial communication protocol message, forwards it to the policy server through the industrial gateway, and extracts the policy configuration data from the extended field of the protocol response message returned by the industrial gateway. In addition, it is used to verify the signature of the policy configuration data, and if the version is updated, it is parsed into policy instructions of leaf nodes to perform security protection operations; parsing the policy configuration data into policy instructions of leaf nodes includes: performing JSON deserialization on the policy configuration data to extract the policy tree structure; traversing each policy node in the policy tree, expanding the condition branches layer by layer from the root node until each branch reaches a leaf node that no longer contains child nodes; extracting the policy atomic instructions stored in each leaf node, wherein the policy atomic instructions at least include the target protection module identifier, operation action code and action parameters; sorting the extracted policy atomic instructions by priority and registering them in the policy execution scheduling table inside the dynamic framework.

Images