PLC encryption subprogram calling method

Abstract

The invention belongs to the technical field of information security, provides a PLC encryption subprogram calling method, and is suitable for realizing security isolation and controlled calling of subprograms in a PLC control system. According to the method, an encryption label is allocated to a target subprogram, and the target subprogram is encrypted and then stored in an independent storage sector of a PLC, so that physical isolation from a main program area is realized. And when the second subprogram initiates a call request, the system confirms the authority by comparing the encryption label and then loads and executes the encrypted first subprogram, and the encrypted content is invisible to the second subprogram. According to the method, version label configuration, dynamic encryption writing, erasure control and storage state analysis are completed by depending on a control module and an information acquisition module in a user-defined encryption library. Storage address information is hidden in the calling process, AES encryption is kept before loading, dynamic decryption is carried out during running, access is limited only through an interface, and uploading prevention, reverse direction and cooperative development safety of the PLC system subprogram are remarkably enhanced.

Description

Technical Field

[0001] The present application relates to the field of information security, and in particular to a method for calling a PLC encryption subroutine. Background Art

[0002] Programmable logic controllers (PLCs) are widely used in industrial automation. Their internal subroutines often contain core control logic and key algorithms, posing a high level of intellectual property value. Existing PLC programming software often protects ladder diagram subroutines by setting encryption or entering passwords on the host computer. Once downloaded to the PLC, these subroutines can still be cracked during uploads or power outages by intercepting communication data, using external cracking software, or removing the Flash chip. This can lead to illegal access, tampering, or large-scale copying of user programs.

[0003] Furthermore, conventional encryption typically stores protected subroutines immediately following the main program, lacking physical isolation. Once the storage address is determined, attackers can read or rewrite them en masse, increasing the risk of reverse engineering. In multi-user collaborative development scenarios, while code can be segmented using libraries, it's still impossible to maintain flexibility and conceal module implementation during secondary development, making it difficult to meet the dual requirements of intellectual property protection and module reuse.

[0004] Therefore, there is an urgent need for a technical solution that takes into account both security and calling flexibility to meet the dual needs of industrial control systems for program protection and collaborative development. Summary of the Invention

[0005] The present application provides a PLC encrypted subroutine calling method to solve the technical problem in the prior art that subroutines in PLCs cannot be encrypted and isolated for storage and lack a controlled calling mechanism, resulting in the program being easily leaked or illegally accessed.

[0006] In a first aspect, the present application provides a method for calling a PLC encryption subroutine, characterized in that the method comprises: Assigning a corresponding encryption label to the first subroutine, and storing the first subroutine in an encrypted form in an independent storage sector of the PLC memory; receiving a call request from a second subprogram to the first subprogram, and verifying, based on an encryption label corresponding to the second subprogram, whether the encryption label matches the encryption label of the first subprogram; When the encryption label of the second subroutine matches the encryption label of the first subroutine, the first subroutine is loaded from the independent storage sector and executed, and the encrypted content of the first subroutine remains invisible to the second subroutine.

[0007] Optionally, the method includes: Importing a custom encryption library into the PLC programming environment, wherein the custom encryption library includes an encryption control module and an encryption information acquisition module; The encryption control module is used to receive configuration parameters and encrypt the first subroutine, and write the encrypted content into an independent storage sector that is physically isolated from the PLC main program storage area; The encryption information acquisition module is used to obtain the storage status information corresponding to the encryption label of the first subroutine according to the call request issued by the second subroutine, and the encryption control module supports receiving the configuration parameters to complete the configuration.

[0008] Optionally, the configuration parameters include a version number parameter and a label parameter, and the configuration process of the encryption control module includes: Inputting a version number parameter and a label parameter into the encryption control module; The version number parameter includes a fixed version number and a user version number. The fixed version number is a preset string constant, and the user version number is composed of user-defined characters and a version identifier. The label parameter is 16-bit binary data, and each bit is sequentially mapped to a corresponding different encryption label, which is used to establish a mapping relationship with each independent storage sector; When the version number parameter and the label parameter are not correctly input, the encryption control module uses a preset default version number for configuration.

[0009] Optionally, the label parameter supports dynamic configuration, including: When the bit of the label parameter is logic 1, the corresponding subroutine is triggered to perform the encrypted write operation; When the bit of the label parameter is logic 0, the corresponding subroutine is triggered to perform the erase operation.

[0010] Optionally, the process of verifying whether the encryption label of the second subprogram matches the encryption label of the first subprogram includes: Detecting storage status information corresponding to the encryption label of the first subroutine by the encryption information acquisition module; When the valid storage state is detected, the encryption label of the second subroutine is compared with the encryption label of the first subroutine to see whether they are consistent.

[0011] Optionally, when the comparison result is a match, the method includes: Read the storage length information of all encrypted subroutines and calculate the total length through the encryption information acquisition module; determining a corresponding label parameter based on the encrypted label of the second subroutine; The encrypted content of the first subroutine is downloaded from the independent storage sector mapped by the label parameter.

[0012] Optionally, the independent storage sector and the PLC main program storage sector are located in different Flash physical areas, and the two are physically isolated; The encrypted subroutine is prohibited from being extracted through upload operations, and its encrypted content remains invisible during the calling and running process.

[0013] Optionally, the physical address information of the independent storage sector is not disclosed during the download calling process, and the first subroutine remains in an AES encryption state before loading and is decrypted during runtime.

[0014] Optionally, before being called and downloaded, the first subprogram does not expose its content to the execution environment where the second subprogram is located, and is only accessed by the second subprogram through a restricted interface.

[0015] In a second aspect, an embodiment of the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method described above is implemented.

[0016] The above technical solution provided by the embodiment of the present application has the following advantages over the prior art: the present invention realizes the physical isolation storage and controlled calling based on label matching of PLC subroutines by introducing an encryption label mechanism and an independent storage structure. Specifically, the first subroutine is written into an independent storage sector in the PLC that is physically isolated from the main program after AES encryption. It can only be dynamically loaded and executed when the second subroutine has the same encryption label and issues a call request, and the content remains invisible during the execution process. This structure effectively blocks traditional cracking methods such as upload extraction, communication interception and chip reading, and improves the anti-leakage ability of the PLC program. At the same time, the bit mapping mechanism of the label parameter is used to realize the dynamic configuration and erase management of multiple encrypted subroutines, thereby enhancing the flexibility of the system. Compared with the traditional host computer encryption method, the present invention realizes an encryption protection closed loop on the PLC body side, and supports the implementation of module-callable but invisible access control logic in collaborative development, which significantly improves the security of the control system. BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0017] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0018] One or more embodiments are exemplarily illustrated by pictures in the corresponding drawings. These exemplifications do not constitute limitations on the embodiments. Elements with the same reference numerals in the drawings are represented as similar elements. Unless otherwise stated, the figures in the drawings do not constitute proportional limitations.

[0019] Figure 1 A flowchart of a method for calling a PLC encryption subroutine provided in an embodiment of the present application; Figure 2 A schematic diagram of configuration parameters of an encryption control module provided in an embodiment of the present application; Figure 3 Schematic diagram of encryption subroutine and encryption label provided in the embodiment of the present application; Figure 4 A schematic diagram of the structure of a computer-readable storage medium provided in an embodiment of the present application. DETAILED DESCRIPTION

[0020] To make the purpose, technical solutions, and advantages of the embodiments of this application more clear, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0021] The disclosure below provides many different embodiments or examples for implementing different configurations of the present invention. To simplify the disclosure of the present invention, the components and configurations of specific examples are described below. Of course, these are merely examples and are not intended to limit the present invention. In addition, the present invention may repeat reference numerals and / or letters in different examples. Such repetition is for the purpose of simplicity and clarity and does not in itself indicate the relationship between the various embodiments and / or configurations discussed.

[0022] like Figure 1 As shown, Figure 1 A flowchart of a method for calling a PLC encryption subroutine provided in an embodiment of the present application. A method for calling a PLC encryption subroutine provided in an embodiment of the present application, the method comprising: S100: Assign a corresponding encryption label to a first subroutine, and store the first subroutine in an encrypted form in an independent storage sector of a PLC memory.

[0023] In the embodiment of the present application, two main processes are involved. The first is to store the first subroutine in an encrypted form in an independent storage sector in the PLC memory. The second is to download the first subroutine from the independent storage sector if it is necessary to call the first subroutine during the writing of the second subroutine. During the entire process, the first subroutine is invisible to the second subroutine. The second subroutine can only call the first subroutine but cannot view the specific encrypted content of the first subroutine. This is conducive to realizing module-callable but invisible access control logic in collaborative development, and significantly improves the security of the control system.

[0024] In the S100 PLC programming environment, import a custom encryption library containing an encryption control module (PROTECT_CTL) and an information acquisition module (PROTECT_GETINF). The user selects the first subroutine as the target to be protected and configures its encryption parameters by calling the PROTECT_CTL module.

[0025] Specifically, the method includes: importing a custom encryption library into a PLC programming environment, wherein the custom encryption library includes an encryption control module and an encryption information acquisition module; The encryption control module is used to receive configuration parameters and encrypt the first subroutine, and write the encrypted content into an independent storage sector that is physically isolated from the PLC main program storage area; The encryption information acquisition module is used to obtain the storage status information corresponding to the encryption label of the first subroutine according to the call request issued by the second subroutine. The encryption control module supports receiving version number parameters and label parameters to complete the configuration.

[0026] Before encrypting and calling PLC subroutines in this application, you first need to set up the PLC environment. In the STEP7-MicroWINSMART programming software, import the custom encryption library file (containing the PROTECT_CTL and PROTECT_GETINF function blocks) through "Library" → "Open Library File". Then refresh the library to make the encryption control and information acquisition modules available for calling in the ladder diagram. It should be noted that PROTECT_CTL in this application refers to the encryption control module, and PROTECT_GETINF refers to the encryption information acquisition module.

[0027] The configuration process of the encryption control module includes: Inputting a version number parameter and a label parameter into the encryption control module; The version number parameter includes a fixed version number and a user version number. The fixed version number is a preset string constant, and the user version number is composed of user-defined characters and a version identifier. The label parameter is 16-bit binary data, and each bit is sequentially mapped to a corresponding different encryption label, which is used to establish a mapping relationship with each independent storage sector; When the version number parameter and the label parameter are not correctly input, the encryption control module uses a preset default version number for configuration.

[0028] In the embodiment of the present application, the PROTECT_CTL function module is dragged into the main program (MAIN). If you want to enable the encryption control module, you need to enter the configuration parameters. The configuration parameters include version number parameters and label parameters, where the version number parameters include fixed version number and user version number.

[0029] Specifically, such as Figure 2 As shown, Figure 2 for Figure 2 A schematic diagram of configuration parameters of an encryption control module provided by an embodiment of the present application: First, a fixed version number parameter is set for the first input terminal PEN of the module, such as the string constant "UNIMAT-PTV1.0", and the characters therein cannot be modified by the user.

[0030] Secondly, input a 16-bit label parameter for the second input terminal SBR_FLAG, such as 0000000000000001, which is used to identify the first subroutine number to be encrypted. In the PLC project, add the target first subroutine (such as SBR112) to the call list. Figure 3 As shown, Figure 3 The schematic diagram of the encryption subroutine and encryption label provided for the embodiment of the present application, in the embodiment of the present application, there is an SBR_flag identification parameter in PROTECT_CTL, which indicates 16 subroutines. For example, if the subroutine subscripts that the user can use for encryption are 112 to 127, then the 16 bits of SBR_flag can correspond to them. SBR_flag can be understood as the subroutine encryption enable bit. SBR_flag is a 16-bit data, and each of its bits corresponds to a subroutine. The encryptable subroutines are SBR112 to 127, and these 16 bits must correspond to the bits of SBR_flag. For example, if only SBR112 is encrypted, then SBR_flag is 0x0001, and if only SBR113 is encrypted, then SBR_flag is 0x0002.

[0031] Finally, the third input is another version number for the user's encryption program, the format of which is character + Vx.x. The user version number does not exceed 12 characters, that is, the third parameter VERSION.

[0032] Specifically, the label parameters support dynamic configuration, including: When the bit of the label parameter is logic 1, the corresponding subroutine is triggered to perform the encrypted write operation; When the bit of the label parameter is logic 0, the corresponding subroutine is triggered to perform the erase operation.

[0033] In the embodiment of the present application, after the system parses the above-mentioned SBR_FLAG parameter, it checks its bit status bit by bit. If the corresponding position is logic 1 (such as the lowest bit 0, bit 3, and bit 4), for example: SBR112 (bit 0 = 1), the system automatically performs the AES encryption operation on SBR112 and writes the ciphertext to the independent Flash sector. SBR115 and SBR116 (bit 3 and bit 4 = 1) also trigger the encryption processing of the corresponding subroutine. For the subroutines whose corresponding positions are logic 0 (the remaining 13 bits), the system automatically performs the erase operation, that is, clears the encrypted records and storage contents of these subroutines in the independent storage sector to release storage space.

[0034] S200: Receive a call request from a second subprogram to the first subprogram, and verify whether the encryption label corresponding to the second subprogram matches the encryption label of the first subprogram based on the encryption label corresponding to the second subprogram.

[0035] In an embodiment of the present application, a PROTECT_GETINF function module is dragged into the second subroutine logic, and the input terminal SBR_FLAG of PROTECT_GETINF is set to the same label parameter 0000000000000001 as the first subroutine. During operation, the PROTECT_GETINF module outputs a 16-bit SBR_FLAG parameter by reading the label status of each sector in the Flash.

[0036] Specifically, the process of verifying whether the encryption label of the second subroutine matches the encryption label of the first subroutine includes: Detecting storage status information corresponding to the encryption label of the first subroutine by the encryption information acquisition module; When the valid storage state is detected, the encryption label of the second subroutine is compared with the encryption label of the first subroutine to see whether they are consistent.

[0037] In the embodiment of the present application, after the PLC parses the unencrypted main program, if it discovers that there is an encrypted area program, it continues parsing the encrypted area program. Specifically, the upper-level logic obtains the storage status of the first subroutine through the encryption information acquisition module. Based on the output, it determines whether the first subroutine has been encrypted and written according to the specified label. If the corresponding bit of the output is "1", it indicates that the first subroutine has been stored and can be subsequently called. Otherwise, it is 0, indicating that it cannot be called.

[0038] When the storage status is detected as valid, the encryption information acquisition module retrieves the first subroutine's encryption label. Ladder logic is then used to compare the output status bit with the corresponding bit of the second subroutine's input label. If the two match, it indicates that the current caller (the second subroutine) holds the same encryption label as the first subroutine, thus verifying that the call passes. The encryption label of the first subroutine is then compared bit by bit with the encryption label of the second subroutine. Otherwise, verification fails and subsequent loading operations are prohibited. Through this embodiment, the second subroutine can only obtain load permission for the first subroutine if its encryption label is completely consistent with the storage label of the first subroutine, strictly ensuring controlled access and execution security of the encrypted subroutine.

[0039] S300: When the encryption label of the second subprogram matches the encryption label of the first subprogram, the first subprogram is loaded from the independent storage sector and executed, and the encrypted content of the first subprogram remains invisible to the second subprogram.

[0040] Specifically, when the comparison result is a match, the method includes: Read the storage length information of all encrypted subroutines and calculate the total length through the encryption information acquisition module; determining a corresponding label parameter based on the encrypted label of the second subroutine; The encrypted content of the first subroutine is downloaded from the independent storage sector mapped by the label parameter.

[0041] In an embodiment of the present application, the length reading interface of the same encryption information acquisition module is called, and the system traverses the metadata of all encrypted subroutines in the independent storage sector, obtains the actual encrypted data length of each subroutine, and calculates its cumulative length. This step is used to ensure that the correct buffer can be allocated in one go during subsequent loading.

[0042] Based on the encryption label Second_SBR_FLAG used in the second subroutine, the independent storage sector number Sector_ID where the first subroutine is located is located through a mapping table or built-in calculation logic.

[0043] In the PLC runtime environment, a sector read command is issued, prompting the underlying system driver to read the encrypted data from the specified sector and fill it into an internal buffer. Once the read is complete, the system decryption interface is called to decrypt the ciphertext in the buffer into executable ladder code. This code is then injected into the runtime task to execute the first subroutine. Throughout this process, the sector read command does not expose the specific physical address; the interface uses only the logical sector number. The second subroutine and external monitoring can only see the encrypted data or execute it instantaneously after decryption; no source code can be persisted or uploaded. Only controlled interfaces such as Read_Sector and AES_Decrypt are publicly accessible; other access paths are prohibited.

[0044] Through this embodiment, the system completes the secure loading and execution of the encrypted subroutine after verifying the label match, achieving the design goal of "callable but invisible", and effectively preventing the subroutine content from being unauthorized access or cracking.

[0045] Furthermore, the independent storage sector and the PLC main program storage sector are located in different Flash physical areas, and the two are physically isolated.

[0046] The encrypted subroutine is prohibited from being extracted through upload operations, and its encrypted content remains invisible during the calling and running process.

[0047] In an embodiment of the present application, at the PLC hardware design or firmware level, the internal Flash is divided into two non-contiguous physical areas: the "main program area" (Sector 0–n) and the "encrypted subroutine area" (Sector n+1–m). Through hardware address mapping or Flash controller settings, the physical address of the encrypted subroutine area is inaccessible from the main program area, and the bus arbitration logic only allows access to this area through a dedicated sector number.

[0048] In the PLC communication protocol stack, upload commands are filtered: when a request is made to access the sector number of the encrypted subroutine area, "unauthorized" or blank data is directly returned, and the upload operation is rejected. The upload entry of the encrypted sector is canceled or hidden in the programming software, and the read button or download log is not exposed to the user.

[0049] During the call loading phase, the ciphertext in the sector is only obtained through the system's internal interface. At runtime, the PLC's internal decryption engine directly converts the ciphertext into an execution instruction stream, without displaying the decrypted source code in the user-accessible variable area or monitoring window. Memory read operations on the encrypted sector are blocked for external diagnostic or debugging tools, and only the execution results or status flags are allowed to be viewed.

[0050] When the second subroutine passes verification, the PLC calls the internal Read_Sector to read the sector data, and directly transfers it to the execution buffer after internal decryption, leaving no plaintext in the interactive interface or log. If an attempt is made to use conventional functions to start an upload operation, the PLC protocol stack detects that the target sector number belongs to the encrypted area and directly returns an error, thereby completely prohibiting upload and extraction.

[0051] Through the above embodiment, physical isolation of the encrypted subroutine area and the main program area, anti-upload and extraction, and multi-layer security protection of invisible content during the entire operation are achieved, effectively improving the security and anti-cracking capabilities of the PLC core logic.

[0052] Furthermore, the physical address information of the independent storage sector is not disclosed during the download calling process, and the first subroutine remains in an AES encryption state before loading and is decrypted during runtime.

[0053] When the second subroutine calls the first subroutine, the entire encrypted data (ciphertext) is loaded into the internal buffer. At this time, the data remains in the AES encryption state and no decryption or plaintext processing is performed.

[0054] During the actual execution phase, the ciphertext is decrypted into executable code via a controlled decryption interface and immediately passed to the PLC's task scheduler for execution. The decryption results are not written to persistent storage or the visual debug window, ensuring that the source code content cannot be observed externally. Ciphertext is decrypted only within the CPU's internal secure area and discarded after execution. It does not reside in monitored storage, ensuring that the code remains encrypted before loading.

[0055] Furthermore, before being called and downloaded, the first subprogram does not expose its content to the execution environment of the second subprogram, and is only accessed by the second subprogram through a restricted interface.

[0056] In an embodiment of the present application, in a PLC system, the encrypted data and execution logic of the first subroutine are stored only in a protected memory area and are not mapped to the runtime stack or variable area directly accessible by the second subroutine. When the second subroutine is running, its local variable table and program pointer do not contain the actual code or plaintext data of the first subroutine, ensuring that the content of the first subroutine is "invisible" to the execution environment.

[0057] The present application is applicable to the application scenarios of anti-upload, anti-reverse engineering and cooperative development of subroutines. In one possible implementation, it involves multi-user development, in which a first user writes a first subroutine and a second user writes a second subroutine to jointly develop a project. When the second user needs to call the first subroutine written by the first user when writing the second subroutine, the present application saves the first subroutine in an independent storage sector, and only loads and executes the encrypted first subroutine after confirming the authority by comparing the encryption label, and the encrypted content remains invisible to the second subroutine. It should be noted that the second user can call the first subroutine or not when writing the second subroutine. For the above embodiment, there can be multiple users writing together, or there can be only one user writing the first subroutine and the second subroutine. For the sake of security and confidentiality, the first subroutine is encrypted and saved in an independent storage sector through the present application solution, and then the first subroutine is called invisible by the second subroutine. Specifically, the process is as follows: (1) Install a custom library, which includes an encryption control module and an encryption information acquisition module; (2) The first user writes a first subprogram and configures the first subprogram with a corresponding encryption label, and downloads the first subprogram to an independent storage sector. The encryption control module is configured by filling in a version number and a label parameter, wherein the label parameter and the encryption label have a corresponding relationship, and each label parameter is mapped to an independent storage sector. That is, the corresponding label parameter can be determined according to the encryption label, thereby downloading the first encrypted program in an encrypted form to the corresponding independent storage sector; (3) sending the PLC including the encrypted first subroutine to the second user; (4) The second user writes a second subroutine and configures a corresponding encryption label for the first subroutine; (5) Obtaining the storage status of the first subroutine and the encryption label of the first subroutine through the encryption information acquisition module; (6) When the encryption label of the second subroutine matches the encryption label of the first subroutine, the corresponding first subroutine is downloaded from the independent storage sector under the label parameter corresponding to the encryption label.

[0058] There is another possible implementation method, in which the method further includes support for nested subroutine calls. Specifically, a subroutine call entry is reserved within the first subroutine, allowing it to call other subroutines that are also stored in independent sectors and share the same or different encryption labels. By setting the nesting depth parameter in the PROTECT_CTL module, the maximum number of nesting levels can be limited to prevent infinite recursive calls from causing stack overflow.

[0059] In another possible implementation, the interrupt service routine is also encrypted and protected. The interrupt service subroutine (ISR) triggered by the interrupt is also included in the encryption management scope, assigned a dedicated encryption label and stored in an independent sector. When an interrupt occurs, the PROTECT_GETINF module verifies the ISR label in real time and loads it for execution, ensuring that high-priority tasks are also protected.

[0060] In another possible implementation, a version number comparison function is introduced in PROTECT_CTL to support version upgrades or rollbacks of stored subroutines. When it is detected during loading that the version number corresponding to the called label is higher than the local preset value, it can automatically trigger a rollback to a compatible version or throw a version mismatch warning.

[0061] Another possible implementation utilizes the PLC's built-in security module for hardware acceleration of AES encryption and decryption, improving execution efficiency. During initialization, the PROTECT_CTL module derives the key from the RoT secure zone to prevent key exposure at the software level. A hash checksum (such as SHA-256) is appended to each encrypted subroutine data block. The PROTECT_GETINF module verifies data integrity before loading. If the check fails, a security interrupt or alarm is triggered, and the load is rejected, preventing malicious tampering with the Flash area.

[0062] In another possible implementation, an audit log of encryption operations is maintained locally on the PLC, including encryption, erasure, and call events, to facilitate subsequent tracking and compliance checks.

[0063] Compared with the prior art, this application brings the following beneficial effects: (1) Implementing secure isolation and invisible storage of PLC subroutines: By encrypting the first subroutine with the AES algorithm and writing it to an independent Flash storage sector physically isolated from the main program, storage-level protection for key subroutines within the PLC is achieved. Since the encrypted data is written to an independent area that cannot be uploaded, combined with hardware logic shielding and communication protocol restrictions, it can effectively prevent the program content from being extracted through burners, communication interception, or software upload.

[0064] (2) Constructing a subroutine authorization call mechanism based on encryption labels: The system configures encryption labels for the first and second subroutines, and only allows the loading and calling of the first subroutine when the labels match, thus implementing the control logic of "encrypted authorization call" between modules. The second subroutine cannot access the first subroutine through code references or addresses, and can only make runtime calls through restricted interfaces when the authorization conditions are met.

[0065] (3) Support for dynamic configuration and centralized management of multiple subroutines: 16-bit encryption label parameters are introduced, each bit can independently correspond to a subroutine, and support dynamic execution of "encryption write" or "erase" through flag setting. This realizes the needs of batch configuration, label remapping, permission switching, etc. of multiple subroutines, improving the flexibility and scalability of the system.

[0066] (4) Ensure that the program contents are always invisible during the calling process: the ciphertext is read through the system's restricted interface, dynamically decrypted at runtime, and immediately executed. The decryption process is not exposed to the caller or user, and the memory contents are cleared after execution. When the second subroutine calls the first subroutine, its decrypted contents cannot be obtained in the variable table, task stack, or monitoring interface, achieving "callable but invisible".

[0067] (5) Enhance intellectual property protection capabilities in collaborative development: In scenarios where multiple developers or suppliers are involved, developers can package their core logic into encrypted subroutines and authorize others to call them only through labels. The caller cannot view the implementation details. This achieves secure boundary isolation for cross-organizational module reuse and eliminates the risk of source code leakage.

[0068] like Figure 4 As shown, Figure 4 Schematic diagram of the structure of the computer-readable storage medium provided in the embodiment of the present application. The computer-readable storage medium 800 of this embodiment includes: a server 810 ( Figure 4 Only one is shown), a client 820 and a data recovery program 821 stored in the client 820 and executable on the at least one client 820, the client 820 executes the data recovery program 821 to send a request to the server 810, and the server 810 feeds back a result to implement the steps in the above method embodiment.

[0069] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0070] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant description of other embodiments.

[0071] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed in this application can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0072] In the embodiments provided in this application, it should be understood that the disclosed devices / terminal equipment and methods can be implemented in other ways. For example, the device / terminal equipment embodiments described above are merely illustrative. For example, the division of the modules or units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0073] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0074] If the integrated module / unit is implemented as a software functional unit and sold or used as a standalone product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application can implement all or part of the process steps in the above-mentioned method embodiments by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium. When executed by a processor, the computer program can implement the steps of each of the above-mentioned method embodiments. The computer program includes computer program code, which can be in source code form, object code form, executable file, or some intermediate form. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal, and software distribution medium. It should be noted that the content of the computer-readable medium can be appropriately increased or decreased based on the requirements of legislation and patent practice in a jurisdiction. For example, in some jurisdictions, based on legislation and patent practice, computer-readable media does not include electric carrier signals and telecommunication signals.

[0075] The present application implements all or part of the processes in the above-mentioned embodiment method, and can also be completed through a computer program product. When the computer program product is run on a terminal device, the terminal device can implement the steps in the above-mentioned method embodiments when executing.

[0076] The above embodiments are intended only to illustrate the technical solutions of the present application and are not intended to limit them. Although the present application has been described in detail with reference to the above embodiments, those skilled in the art should understand that they may still modify the technical solutions described in the above embodiments or replace some of the technical features therein with equivalents; and such modifications or replacements do not deviate from the spirit and scope of the technical solutions of the embodiments of the present application and should be included within the scope of protection of the present application.

Claims

1. A method for calling a PLC encrypted subroutine, characterized in that: The method comprises: Assigning a corresponding encryption label to the first subroutine, and storing the first subroutine in an encrypted form in an independent storage sector of the PLC memory; receiving a call request from a second subprogram to the first subprogram, and verifying, based on an encryption number corresponding to the second subprogram, whether the encryption number matches the encryption number of the first subprogram; When the encryption label of the second subroutine matches the encryption label of the first subroutine, the first subroutine is loaded from the independent storage sector and executed, and the encrypted content of the first subroutine remains invisible to the second subroutine.

2. The PLC encryption subroutine calling method according to claim 1, characterized in that: The method comprises: Importing a custom encryption library into the PLC programming environment, wherein the custom encryption library includes an encryption control module and an encryption information acquisition module; The encryption control module is used to receive configuration parameters and encrypt the first subroutine, and write the encrypted content into an independent storage sector that is physically isolated from the PLC main program storage area; The encryption information acquisition module is used to obtain the storage status information corresponding to the encryption label of the first subroutine according to the call request issued by the second subroutine, and the encryption control module supports receiving the configuration parameters to complete the configuration.

3. The PLC encryption subroutine calling method according to claim 2, characterized in that: The configuration parameters include a version number parameter and a label parameter. The configuration process of the encryption control module includes: Inputting a version number parameter and a label parameter into the encryption control module; The version number parameter includes a fixed version number and a user version number. The fixed version number is a preset string constant, and the user version number is composed of user-defined characters and a version identifier. The label parameter is 16-bit binary data, and each bit is sequentially mapped to a corresponding different encryption label, which is used to establish a mapping relationship with each independent storage sector; When the version number parameter and the label parameter are not correctly input, the encryption control module uses a preset default version number for configuration.

4. The PLC encryption subroutine calling method according to claim 3, characterized in that: The label parameters support dynamic configuration, including: When the bit of the label parameter is logic 1, the corresponding subroutine is triggered to perform the encrypted write operation; When the bit of the label parameter is logic 0, the corresponding subroutine is triggered to perform the erase operation.

5. The PLC encryption subroutine calling method according to claim 2, characterized in that: The process of verifying whether the encryption label of the second subroutine matches the encryption label of the first subroutine includes: Detecting storage status information corresponding to the encryption label of the first subroutine by the encryption information acquisition module; When the valid storage state is detected, the encryption label of the second subroutine is compared with the encryption label of the first subroutine to see whether they are consistent.

6. The PLC encryption subroutine calling method according to claim 5, characterized in that: When the comparison result is a match, the method includes: Read the storage length information of all encrypted subroutines and calculate the total length through the encryption information acquisition module; determining a corresponding label parameter based on the encrypted label of the second subroutine; The encrypted content of the first subroutine is downloaded from the independent storage sector mapped by the label parameter.

7. The PLC encryption subroutine calling method according to claim 6, characterized in that: The independent storage sector and the PLC main program storage sector are located in different Flash physical areas, and the two are physically isolated; The encrypted subroutine is prohibited from being extracted through upload operations, and its encrypted content remains invisible during the calling and running process.

8. The PLC encryption subroutine calling method according to claim 6, characterized in that: The physical address information of the independent storage sector is not disclosed during the download calling process, and the first subroutine remains in an AES encryption state before loading and is decrypted during runtime.

9. The PLC encryption subroutine calling method according to claim 6, characterized in that: Before being called and downloaded, the first subprogram does not expose its content to the execution environment where the second subprogram is located, and is only accessed by the second subprogram through a restricted interface.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, which, when executed by a processor, is used to implement the steps of the method according to any one of claims 1 to 9.

Images