A program protection method
By compiling the target source code into an address-independent executable and setting export interfaces and loading logic, the problems of core software logic leakage and abuse are solved, and the software security protection and legal use are achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- FUJIAN HUIJIETONG TECH CO LTD
- Filing Date
- 2024-12-30
- Publication Date
- 2026-06-30
AI Technical Summary
Existing software is prone to leaking core logic and being abused. The code segments of the target linked file contain symbol tables and visualizations that are easily decompiled, allowing users to use them for illegal purposes.
The target source code is compiled into an address-independent executable file, a target linker file is generated, and export interfaces and loading logic are set. User executable files must pass a validity check before they can run.
Protect the core logic of the software from being decompiled, prevent the software from running in an illegal environment, and ensure that the software runs normally only in an authorized environment.
Smart Images
Figure CN122310486A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of software protection technology, and in particular to a program protection method. Background Technology
[0002] With the development of IoT technology, software applications are becoming increasingly widespread. The core processing logic of software is a core secret of software developers. To protect this core logic from leakage, target linker files are typically used to provide software functionality. The code segments in these target linker files are compiled into machine language by a compiler to prevent the leakage of the core processing logic. Users need to add their own source code projects to the target linker files to generate executable files. However, the code segments in target linker files also include various symbol tables and visual content (e.g., function names, variable names). Using relevant tools, it's easy to decompile these symbol tables and visual content into assembly language, leading to logical leaks in the software. Furthermore, the target linker file is only a semi-finished product; even if it meets the compiler's target environment requirements, users can easily misuse the software. Summary of the Invention
[0003] The technical problem to be solved by this invention is to provide a program protection method to solve the problems of existing software easily leaking core logic and software being easily abused.
[0004] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is: a program protection method, comprising the following steps: S1. Compile the target source code into an address-independent executable file, generate a target linker file based on the executable file, and create an export interface and set loading logic in the target linker file based on the executable file; S2. Generate a user executable file based on the target link file. The user executable file includes an attached executable file generated based on the executable file. Perform the process of loading the attached executable file according to the exported interface, and run the attached executable file according to the loading logic. S3. Perform a legality check on the runtime environment of the user executable file to determine whether the runtime environment of the user executable file passes the legality check; if yes, the attached executable file provides software services; if no, the attached executable file does not provide software services.
[0005] Furthermore, in step S2, the attached executable file is run according to the loading logic, specifically including: The process involves invoking the export interface, which in turn calls the loading interface; locating the position of the attached executable file using the loading interface; initializing the dependency environment of the user executable file and configuring the dependency interfaces of the attached executable file; passing the running parameters to the entry point of the attached executable file through the loading logic for execution; and returning the attached executable file to the interface group, which is then invoked based on the user request.
[0006] Furthermore, initializing the dependent environment of the attached executable file includes: initializing the dependent interface of the attached executable file, allocating the RW segment, and allocating the ZI segment.
[0007] Furthermore, in step S2, the process of loading and attaching executable files is executed according to the exported interface, including: initializing the RW segment; initializing the ZI segment; and initializing the global offset table.
[0008] Furthermore, in step S1, compiling the target source code into an address-independent executable file specifically includes: compiling and linking the target source code and its dependent interfaces based on address-independent compilation rules to generate an unauthorized file; and signing the unauthorized file according to the vendor key system to generate the executable file.
[0009] Furthermore, in step S2, running the attached executable file according to the loading logic includes: configuring the dependency interface of the attached executable file according to the user executable file.
[0010] Furthermore, in step S3, the legality of the runtime environment of the user executable file is verified, including: obtaining the signature data of the attached executable file and verifying the legality of the runtime environment of the user executable file according to the authorization information file.
[0011] Furthermore, the signature data includes the vendor's private key.
[0012] Furthermore, verifying the legitimacy of the user-executable file based on the authorization information file specifically includes: The address information of the RW segment and the address information of the ZI segment are obtained according to the operating environment, and the relevant content of the authorization information file is obtained. The relevant content is parsed according to the signature data and an authorization file is generated. The signature content of the authorization file is calculated based on the verification file, and it is determined whether the signature content matches the visible signer information; if yes, the attached executable file provides software services; if no, the attached executable file does not provide software services.
[0013] Furthermore, the authorization information file includes a bin file, a vendor public key, vendor identity information, a first restricted address of the RW segment, and a second restricted address of the ZI segment.
[0014] The beneficial effects of this invention are as follows: The program protection method provided by this invention compiles the core logic code of the program into an address-independent executable file, and generates a target linker file based on the executable file. Users cannot obtain the core logic of the executable file through decompilation, thus protecting the core logic of the program. In addition, the executable file of this program protection method needs to undergo an environment legality authorization operation after running. The program only provides software services after the executable file legality authorization operation is passed. This can ensure that the software can only run successfully in a feature-authorized environment, preventing the software from being illegally used in other unauthorized projects and ensuring that the software is not abused. Attached Figure Description
[0015] Figure 1 This is a flowchart illustrating the program protection method described in this invention. Figure 2 A flowchart illustrating the process of generating target link files for this invention; Figure 3 A flowchart illustrating the process of generating an executable file for this invention; Figure 4 A flowchart illustrating the process of generating user executable files for this invention; Figure 5 This is a schematic diagram of the format of the target link file of the present invention; Figure 6 A schematic diagram of the format of existing linkable files; Figure 7 According to Figure 6 The diagram shown illustrates the process of generating user-executable files from linkable files. Detailed Implementation
[0016] To explain in detail the technical content, objectives, and effects of the present invention, the following description is provided in conjunction with the embodiments and accompanying drawings.
[0017] Please refer to Figures 1 to 5 This invention provides a program protection method, comprising the following steps: S1. Compile the target source code into an address-independent executable file, generate a target linker file based on the executable file, and create an export interface and set loading logic in the target linker file based on the executable file; S2. Generate a user executable file based on the target link file. The user executable file includes an attached executable file generated based on the executable file. Perform the process of loading the attached executable file according to the exported interface, and run the attached executable file according to the loading logic. S3. Perform a legality check on the runtime environment of the user executable file to determine whether the runtime environment of the user executable file passes the legality check; if yes, the attached executable file provides software services; if no, the attached executable file does not provide software services.
[0018] As described above, the beneficial effects of this invention are as follows: The program protection method provided by this invention compiles the core logic code of the program into an address-independent executable file, and generates a target linker file based on the executable file. Users cannot obtain the core logic of the executable file through decompilation, thus protecting the core logic of the program. In addition, the executable file of this program protection method needs to undergo an environment legality authorization operation after running. The program only provides software services after the executable file legality authorization operation is passed. This can ensure that the software can only run successfully in a feature-authorized environment, preventing the software from being illegally used in other unauthorized projects and ensuring that the software is not abused.
[0019] Furthermore, in step S2, the attached executable file is run according to the loading logic, specifically including: The process involves invoking the export interface, which in turn calls the loading interface; locating the position of the attached executable file using the loading interface; initializing the dependency environment of the user executable file and configuring the dependency interfaces of the attached executable file; passing the running parameters to the entry point of the attached executable file through the loading logic for execution; and returning the attached executable file to the interface group, which is then invoked based on the user request.
[0020] As described above, the target linker can compile the executable file into the user executable file, forming an attached executable file within the user executable file. During execution, the user executable file needs to prepare the necessary dependencies for the executable environment based on the loading logic, locate the entry point of the executable program according to the loading logic, and finally pass the execution parameters to the entry point of the executable program for execution. The program protection method provided by this invention enables programs to run normally and provide software services only after the environment parameters provided by the user and the loading program have been processed.
[0021] Furthermore, initializing the dependent environment of the attached executable file includes: initializing the dependent interface of the attached executable file, allocating RW segments, and allocating ZI segments.
[0022] Furthermore, in step S2, the process of loading and attaching executable files is executed according to the exported interface, including: initializing the RW segment; initializing the ZI segment; and initializing the global offset table.
[0023] As described above, this program protection method sets restricted addresses for the RW and ZI segments respectively, so that executable files authorized under specific conditions can be used, preventing the program from being abused in other unauthorized runtime environments.
[0024] In the program protection method provided by this invention, the RW segment is the part that needs to be read and written during program execution, and the ZI segment is the part that is initialized to 0 when the program starts.
[0025] Furthermore, in step S1, compiling the target source code into an address-independent executable file specifically includes: compiling and linking the target source code and its dependent interfaces based on address-independent compilation rules to generate an unauthorized file; and signing the unauthorized file according to the vendor key system to generate the executable file.
[0026] As described above, the executable file is generated before authorization through the manufacturer's key system. The program can only run when the user executes the file and is authorized through the key system, ensuring that the program cannot be illegally used in other unauthorized product projects.
[0027] Furthermore, in step S2, running the attached executable file according to the loading logic includes: configuring the dependency interface of the attached executable file according to the user executable file.
[0028] As described above, the executable file's dependency interface and memory are provided by the user's runtime environment. After the user's executable file is loaded according to the loading logic, it is passed to the attached executable file through parameters.
[0029] Furthermore, in step S3, the legality of the runtime environment of the user executable file is verified, including: obtaining the signature data of the attached executable file and verifying the legality of the runtime environment of the user executable file according to the authorization information file.
[0030] Furthermore, the signature data includes the vendor's private key.
[0031] As described above, the bin file, the vendor's public key, and the vendor's ID can be used as the input sources for authorization, and the signature can be made based on the vendor's private key.
[0032] Furthermore, verifying the legitimacy of the user-executable file based on the authorization information file specifically includes: The address information of the RW segment and the address information of the ZI segment are obtained according to the operating environment, and the relevant content of the authorization information file is obtained. The relevant content is parsed according to the signature data and an authorization file is generated. The signature content of the authorization file is calculated based on the verification file, and it is determined whether the signature content matches the visible signer information; if yes, the attached executable file provides software services; if no, the attached executable file does not provide software services.
[0033] Furthermore, the authorization information file includes a bin file, a vendor public key, vendor identity information, a first restricted address of the RW segment, and a second restricted address of the ZI segment.
[0034] Example 1 Please refer to Figures 1 to 5 The first embodiment of the present invention is to provide a program protection method to solve the problems of existing software being prone to leaking core logic and being easily abused.
[0035] Modern software vendors typically provide users with linkable files (ELF files). These linkable files are statically linked files that users compile together. Therefore, linkable files contain segment information needed during the linking process, and their format and content are as follows: Figure 6 As shown. After obtaining the linkable file, the user adds their source code project (i.e., user code) to it, and finally generates a runnable user executable file (the generation process is as follows). Figure 7 (As shown).
[0036] However, the existing linkable files have the following characteristics: 1. The code segment of a linkable file is compiled into machine code by the compiler. Linkable files also contain various symbol tables and visual content (such as function names and variable names). They can be directly decompiled into assembly language by relevant tools, and even further converted into high-level languages such as C. This makes it easy for the logic of the target file to be leaked by linkable files, especially the key technical processing can be guessed by users. 2. Furthermore, the linkable file is only a semi-finished product. If the relevant requirements of the compiler's target environment are met, the user can use the linkable file for other purposes, causing the software's usage scope to exceed the software development vendor's intention and resulting in software abuse.
[0037] To address the above problems, this invention provides a program protection method, comprising the following steps: S1. Compile the target source code into an address-independent executable file, generate a target linker file based on the executable file, and create an export interface and set loading logic in the target linker file based on the executable file; S2. Generate a user executable file based on the target link file. The user executable file includes an attached executable file generated based on the executable file. Perform the process of loading the attached executable file according to the exported interface, and run the attached executable file according to the loading logic. S3. Perform a legality check on the runtime environment of the user executable file to determine whether the runtime environment of the user executable file passes the legality check; if yes, the attached executable file provides software services; if no, the attached executable file does not provide software services.
[0038] In this embodiment, the core processing block diagram of the target linked file is as follows: Figure 2 As shown, the program protection method provides the user with a target link file, which includes three sub-modules: an executable file, an exported interface, and loading logic.
[0039] In this embodiment, the key software code is used as the target source code, and the target source code is compiled into an address-independent executable file. Therefore, the executable file includes the core logic of the program and has the following characteristics: The executable file is compiled in a custom format. The executable file is compiled into address-independent code, and the user cannot know the internal layout of the executable file, making it impossible for the user to decompile the executable file. The executable file is like a black box to the user, which has high security and can prevent the leakage of the core logic of the program. The executable file's execution requirements are address-independent; it can be loaded and run from any address location allocated by the user. The target library of the executable file forms a general and standardized library file.
[0040] In this embodiment, the software services provided to users by the program are restricted by the runtime environment, and the software services to be made available are provided through the interface export method, and the export interface is set accordingly.
[0041] Since executable files are binary files compiled into machine code, they cannot be used directly by users. Executable files need to be processed by loading logic based on the parameters of the user-provided runtime environment before the user can execute the program functions.
[0042] In this embodiment, the target linker can protect sensitive logic processing code by placing it within the executable file, preventing users from obtaining the executable's internal contents through decompilation or other means. After the executable code is run, it undergoes a validity check; only programs that pass the check can execute their functions normally. Otherwise, the relevant functions are disabled, thus preventing unauthorized and illegal use of the program.
[0043] In this embodiment, when the export interface is called through the target link file, the runtime environment will be configured according to the export interface to ensure that the executable file can only run in a specific runtime environment.
[0044] An executable file is a complete, executable binary code, and the following conditions must be met during the executable file generation process: I. The contents of the executable file, including the functional implementation logic of the user library, the logic for verifying the legality of the user library's operation, and the interface address for the export function; 2. Dependencies of the executable file. This part is provided by the user's runtime environment, including dependency interfaces and memory. After the user's executable file is loaded according to the loading logic, it is called or accessed in the attached executable file by passing parameters to the user's executable file. Third, the execution rules of executable files include compiling using an address-independent compilation method, and processing content that the CPU can automatically map in memory, in accordance with the CPU's method. Fourth, the license for executable files is granted through the software vendor's key system. The vendor's private key is used to sign the executable file, and the vendor's public key is embedded in the executable file's code through compilation.
[0045] The components of an executable file are shown in the table below:
[0046] Please refer to Figure 3 In step S1 of this embodiment, compiling the target source code into an address-independent executable file specifically includes: compiling and linking the target source code and its dependent interfaces based on address-independent compilation rules to generate an unauthorized file; and signing the unauthorized file according to the vendor key system to generate the executable file.
[0047] In this embodiment, the target linker places the executable file into a code segment in the source code that is being compiled, so that the executable file is part of the target linker.
[0048] As an example: In C, an executable file can be placed into an object linker file using the following definition: Const int Exefile[]={0xaaaa,……}; This content is a binary file containing an executable file.
[0049] Alternatively, the executable file can be placed in the target linker file using segment definitions: asm("\ ..global _binary_bin_start\n\ _binary_bin_start:\n\ .incbin \"exefile.bin\"\n\ .global _binary_test_bin_end\n\ _binary_bin_end:\n\ "); When an executable file is placed into the target linker file using segment definitions, the source code of the loading logic can be directly referenced, for example: void loadExefile(void arg){ int *exefile = Exefile; } void loadExefile(void arg){ int *exefile = _binary_bin_star; } The above functions, through compilation by the compiler, generate the target linker file from the loading logic, exported interfaces, and executable file. The format of the target linker file is as follows: Figure 5 As shown, when a user calls the executable file's interface, the executable file is automatically linked to the corresponding code segment, achieving the effect of attaching the executable file. The code segment of the target linker file includes: exported interfaces and loading logic. Since this part of the code does not contain the logic that needs to be protected in this case, it can be decompiled by users and can be placed in the target linker file.
[0050] After the user links to the target executable file, a user executable file is generated, and an attached executable file generated from the corresponding executable file is appended to the user executable file. The process of generating the user executable file is as follows: Figure 4 As shown, it includes: linking the target linker file and adding user code to the target linker file to generate a user executable file, wherein the user executable file includes an attached executable file generated from the corresponding executable file.
[0051] The user executable file can obtain the entry address of the attached executable file according to the loading logic, and configure the dependency interface of the attached executable file through the dependency interface provided by the user, and finally run the executable file.
[0052] Specifically, in step S2, running the attached executable file according to the loading logic includes: The process involves invoking the export interface, which in turn calls the loading interface; locating the position of the attached executable file using the loading interface; initializing the dependency environment of the user executable file and configuring the dependency interfaces of the attached executable file; passing runtime parameters to the entry point of the attached executable file through its dependency interfaces for execution; and calling the interface group of the attached executable file based on user requests.
[0053] The initialization of the user executable's dependency environment includes: initializing the dependency interface of the attached executable; allocating the RW segment; and allocating the ZI segment.
[0054] This embodiment prepares the necessary environment for the executable file (the executable file's dependency interfaces, memory, etc.) through loading logic, locates the executable file's entry point, and finally passes the running parameters to the executable file's entry point for execution.
[0055] Once the executable file is executed according to the loading logic, the software functions of the executable file can be run correctly. At this point, the interface functions of the executable file need to be validated before being called.
[0056] In step S3 of this embodiment, the legality verification of the runtime environment of the user executable file includes: obtaining the signature data of the attached executable file, wherein the signature data includes the vendor's private key, and verifying the legality of the runtime environment of the user executable file according to the authorization information file.
[0057] In this embodiment, the authorization information file specifically includes a bin file, a vendor public key, vendor identity information, a first restricted address of the RW segment, and a second restricted address of the ZI segment.
[0058] Specifically, verifying the legitimacy of the user-executable file based on the authorization information file includes: The address information of the RW segment and the address information of the ZI segment are obtained according to the operating environment, and the relevant content of the authorization information file is obtained. The relevant content is parsed according to the signature data and an authorization file is generated. The signature content of the authorization file is calculated based on the verification file, and it is determined whether the signature content matches the visible signer information; if yes, the attached executable file provides software services; if no, the attached executable file does not provide software services.
[0059] In this embodiment, the authorization information file can set a first restricted address for the RW segment and a second restricted address for the ZI segment to authorize the use of software functions under specific authorization conditions in the executable file, thereby preventing the program from being abused in other unauthorized operating environments.
[0060] In step S2 of this embodiment, the process of loading and attaching executable files is executed according to the exported interface, including: initializing the RW segment; initializing the ZI segment; and initializing the global offset table.
[0061] In this embodiment, the runtime environment is constructed by initializing the RW segment and ZI segment, and the addresses of the RW segment and ZI segment are restricted by the authorization information file to ensure that the executable file can only be run in a specific environment and prevent it from being abused in other unauthorized runtime environments.
[0062] In summary, the program protection method provided by this invention compiles the core logic code of a program into an address-independent executable file, and generates a target linker file based on the executable file. Users cannot obtain the core logic of the executable file through decompilation, thus protecting the core logic of the program. In addition, the executable file of this program protection method requires an environment legality authorization operation after execution. The program only provides software services after the executable file legality authorization operation is passed. This ensures that the software can only run successfully in a feature-authorized environment, preventing the software from being illegally used in other unauthorized projects and ensuring that the software is not abused.
[0063] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention's specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.
Claims
1. A program protection method, characterized in that, Includes the following steps: S1. Compile the target source code into an address-independent executable file, generate a target linker file based on the executable file, and create an export interface and set loading logic in the target linker file based on the executable file; S2. Generate a user executable file based on the target link file. The user executable file includes an attached executable file generated based on the executable file. Perform the process of loading the attached executable file according to the exported interface, and run the attached executable file according to the loading logic. S3. Perform a legality check on the runtime environment of the user executable file to determine whether the runtime environment of the user executable file passes the legality check; if yes, the attached executable file provides software services; if no, the attached executable file does not provide software services.
2. The program protection method according to claim 1, characterized in that, In step S2, the attached executable file is run according to the loading logic, specifically including: The process involves invoking the export interface, which in turn calls the loading interface; locating the position of the attached executable file using the loading interface; initializing the dependency environment of the user executable file and configuring the dependency interfaces of the attached executable file; passing the running parameters to the entry point of the attached executable file through the loading logic for execution; and returning the attached executable file to the interface group, which is then invoked based on the user request.
3. The program protection method according to claim 2, characterized in that, Initialize the dependent environment of the attached executable file, including: initializing the dependent interface of the attached executable file, allocating the RW segment, and allocating the ZI segment.
4. The program protection method according to claim 1, characterized in that, In step S2, the process of loading and attaching executable files is executed according to the exported interface, including: initializing the RW segment; initializing the ZI segment; and initializing the global offset table.
5. The program protection method according to claim 1, characterized in that, In step S1, the target source code is compiled into an address-independent executable file, which specifically includes: compiling and linking the target source code and its dependent interfaces based on address-independent compilation rules to generate an unauthorized file; and signing the unauthorized file according to the vendor key system to generate the executable file.
6. The program protection method according to claim 5, characterized in that, In step S2, the attached executable file is run according to the loading logic, including configuring the dependency interface of the attached executable file according to the user executable file.
7. The program protection method according to claim 1, characterized in that, In step S3, the legality of the runtime environment of the user executable file is verified, including: obtaining the signature data of the attached executable file and verifying the legality of the runtime environment of the user executable file according to the authorization information file.
8. The program protection method according to claim 7, characterized in that, The signature data includes the vendor's private key.
9. The program protection method according to claim 7, characterized in that, Verifying the legitimacy of the user-executable file based on the authorization information file specifically includes: The address information of the RW segment and the address information of the ZI segment are obtained according to the operating environment, and the relevant content of the authorization information file is obtained. The relevant content is parsed according to the signature data and an authorization file is generated. The signature content of the authorization file is calculated based on the verification file, and it is determined whether the signature content matches the visible signer information; if yes, the attached executable file provides software services; if no, the attached executable file does not provide software services.
10. The program protection method according to claim 7, characterized in that, The authorization information file includes a bin file, a vendor public key, vendor identity information, a first restricted address for the RW segment, and a second restricted address for the ZI segment.