Detailed Description
Various aspects and features of the present application are described herein with reference to the accompanying drawings.
It should be understood that various modifications may be made to the embodiments of the application herein. Therefore, the above description should not be taken as limiting, but merely as exemplification of the embodiments. Other modifications within the scope and spirit of the application will occur to persons of ordinary skill in the art.
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments of the application and, together with a general description of the application given above, and the detailed description of the embodiments given below, serve to explain the principles of the application.
These and other characteristics of the application will become apparent from the following description of a preferred form of embodiment, given as a non-limiting example, with reference to the accompanying drawings.
It is also to be understood that, although the application has been described with reference to some specific examples, those skilled in the art can certainly realize many other equivalent forms of the application.
The above and other aspects, features and advantages of the present application will become more apparent in light of the following detailed description when taken in conjunction with the accompanying drawings.
Specific embodiments of the application will be described hereinafter with reference to the accompanying drawings, in which, however, it is to be understood that the embodiments so applied are merely examples of the application, which may be practiced in various ways. Well-known and/or repeated functions and constructions are not described in detail to avoid obscuring the application in unnecessary or unnecessary detail. Therefore, specific structural and functional details disclosed herein are not intended to be limiting, but merely as a basis for the claims and as a representative basis for teaching one skilled in the art to variously employ the present application in virtually any appropriately detailed structure.
The specification may use the word "in one embodiment," "in another embodiment," "in yet another embodiment," or "in other embodiments," which may each refer to one or more of the same or different embodiments in accordance with the application.
An anti-cracking method in an embodiment of the present application, as shown in fig. 1, includes:
S10, acquiring a first byte sequence of a program to be executed, wherein the program to be executed is executed by a target operating system, and the first byte sequence is byte information of a target position of the program to be executed.
In this embodiment, the program to be executed is a program to be run on the target operating system. For example, in the Linux system, a web service program developed by a user may contain various functional codes and data, waiting for the operating system to schedule execution. For example, the program to be executed is an application program with a file format of an ELF format.
The first byte sequence is byte information of the program to be executed at the target location. For example, for an executable file, some bytes of the beginning may contain information such as file type, program entry, etc.
The target location is a selected specific location in the program, possibly a file header, a specific section or segment, etc., for identifying whether the program is a target program to be decrypted.
The target operating system is a Linux system, and the protected application program (i.e. the program to be executed) is bound with a kernel of the Linux system, so that the protected application program cannot run independently.
The binding mechanism sets a higher threshold for the running of the program, a malicious attacker cannot easily separate the program from the kernel environment on which the malicious attacker depends for attack or analysis, and the safety of the program is obviously improved.
For example, in a server program of a critical business system, binding of an application program with a kernel ensures that the program must run in a specific kernel environment, prevents the program from being illegally copied and run in other unsafe environments, and prevents leakage and abuse of core functions.
S20, determining whether the program to be executed is a target program to be decrypted or not based on the first byte sequence and the target byte sequence, wherein the target program to be decrypted comprises encrypted code segments.
In this embodiment, the target byte sequence is a predetermined byte sequence for comparison with the first byte sequence to determine whether the program to be executed is a program requiring special processing (decryption).
The target program to be decrypted refers to the program to be executed including the encrypted code segment, that is, the program that needs to be decrypted.
A code segment is a portion of a program that stores executable instructions, contains the core logic and algorithms of the program, etc., and is encrypted to prevent reverse engineering.
And S30, under the condition that the program to be executed is the target program to be decrypted, the target operating system decrypts the code segment, and maps the decrypted code segment back to the target program to be decrypted, wherein the target operating system stores a secret key, and the target operating system is in a forbidden call state when decrypting the code segment.
In this embodiment, the prohibited call state is a state in which the operating system is in when performing the decryption operation, in which other programs or users are not permitted to call certain functions of the system to prevent the decryption process from being disturbed or attacked.
The target operating system is a Linux system, and whether a product can be debugged or not is controlled by utilizing a kernel of the Linux system, so that the risk of leakage of a code segment of a protected program is reduced, and convenience is brought to program development and debugging.
When the method is used normally, the debugging function is limited, a malicious attacker can be prevented from checking and tampering program codes through a debugging means, and the safety of a program is ensured.
In the development stage, a developer can flexibly adjust the state of the kernel of the Linux system according to the requirement, so that the debugging of the program is facilitated, and the smoothness of the development process and the improvement of the program quality are ensured.
For example, when developing a complex image editing software, a developer can adjust the kernel of the Linux system in the development environment to allow debugging, and after the Linux system is released, the kernel of the Linux system limits the debugging to prevent program codes from being stolen by users or malicious persons through debugging means.
In addition, the target operating system is assumed to be a Linux system, a key is saved by using a Linux kernel image, and a code segment of an ELF format application program is temporarily decrypted when a product runs a protected program, so that the mechanism greatly improves the cracking difficulty.
Because the secret key is stored in the relatively safe Linux kernel image, an attacker is difficult to obtain easily, and only the secret key is decrypted temporarily when the program runs, the risk of password exposure is greatly reduced, and more reliable protection is provided for the core code.
For example, in network security software or financial system software, the code segments where the core algorithm and business logic are located are in an encrypted state when being stored and static, and can be decrypted only in a safe kernel environment when running, so that competitors and malicious attackers are effectively prevented from acquiring key information through cracking programs.
S40, the target operating system executes the decrypted target program to be decrypted.
In this embodiment, a byte sequence (first byte sequence) of a program to be executed at a target location is first obtained, and then compared with the target byte sequence to determine whether the program to be executed is a program requiring decryption (target program to be decrypted). If the program is determined to be the target program to be decrypted, the target operating system decrypts the code segment of the program by using the stored key, maps the decrypted code segment back to the original program, and finally executes the decrypted program.
Specifically, when a program is ready to run on a target operating system, the system obtains a first byte sequence of the program to be executed, the sequence being located at a target location of the program. The system compares the first byte sequence with a predetermined target byte sequence. If the two match, the program is the target program to be decrypted, and the system uses the stored secret key to decrypt the code segment of the program. The operating system remaps the decrypted code segments back to the corresponding locations of the original program. Finally, the operating system executes the decrypted program.
Illustratively, a piece of network security software is used as a program to be executed, and code segments of the network security software are stored on a disk after being encrypted by using an encryption tool in the development process.
When a user wants to start the software, the operating system reads a part of byte sequence (such as the first few bytes of the program head) of the program as a first byte sequence, compares the first byte sequence with a stored target byte sequence, decrypts the encrypted code segment by using a stored key if the first byte sequence is matched with the first byte sequence, maps the decrypted code segment back to the program and executes the program, and meanwhile, the operating system is in a forbidden call state in the decryption process to prevent other programs from being interfered.
Compared with the existing modes such as confusion, encryption and the like, the application does not change the code segment content of the protected program, and the operation efficiency is the same as that of the encryption after the program is started. The method avoids the performance loss possibly caused by the traditional encryption or confusion means, ensures that the program provides high security and simultaneously does not influence the use experience of the user and the overall performance of the system.
For example, in a real-time processing system with higher performance requirements, such as video processing software or data processing software, the running of the program cannot be blocked or delayed due to encryption, so that the smoothness and the high efficiency of the system are ensured.
The application protects the core code section of the program, prevents unauthorized access and reverse engineering, and enhances the security of the program. Only the specific program (target program to be decrypted) is decrypted, so that the running efficiency of the system is improved, and the resource waste of decrypting all the programs is avoided.
In an embodiment, the method further comprises:
and encrypting the code segment of the program to be executed by utilizing an encryption tool based on a preset encryption strategy, wherein the encryption tool contains the same key as the key stored by the target operating system.
In the present embodiment, the encryption policy refers to a rule and a method set in advance as to how encryption is performed, for example, an encryption algorithm used, a length of an encryption key, and the like.
An encryption tool is software or program for performing encryption operations on a section of program code that has the same key as the key stored by the target operating system to ensure consistency of subsequent decryption operations. Also included within the encryption tool is an initial vector, etc.
Before the program is executed, the code segment of the program to be executed is encrypted by using an encryption tool which contains the same key as the key stored by the target operating system according to a preset encryption strategy.
For example, for a piece of data encryption software, after development is completed, the code segment is encrypted according to a specific encryption policy (e.g., AES algorithm, key length of 256 bits) using an encryption tool. The key used by the encryption tool is stored therein and the key used by the target operating system is stored therein, and when the program is executed, the same key can be used by subsequent decryption operations.
The application enhances the safety of the program from the source, encrypts the program from the program storage stage and improves the anti-cracking capability.
In one embodiment, as shown in fig. 4, the encrypting the code segment of the program to be executed by using the encryption tool includes:
S51, determining that the program to be executed is a program to be encrypted based on the acquired first byte sequence of the program to be executed.
In the present embodiment, the program to be encrypted is similar to the program to be executed, but here, the attribute that it is to be encrypted, that is, the program that needs to perform the encryption operation, is emphasized more.
S52, determining a code segment based on the obtained node header table information of the program to be encrypted.
In this embodiment, the node header table information is a data structure of the program, and generally includes information such as a position, a size, etc. of each node (e.g., a code segment, a data node, etc.) of the program.
S53, based on the code segments, determining the position and the range of the program to be encrypted for encryption.
In this embodiment, when the encryption tool is used to encrypt the code segment of the program, the program is first determined to be the program to be encrypted according to the obtained first byte sequence of the program to be executed, then the code segment is found according to the node header table information thereof, and finally the position and the range of the encryption of the program are determined.
For example, for a file processing program, during encryption, it is first determined that it is the program that needs to be encrypted by reading a portion of the program's bytes, then the starting address and length of the code segment are found by analyzing the header table, and thus the extent to which the code segment is encrypted is determined, ensuring that only the core code portion is encrypted without affecting other data portions.
The application precisely determines the position and the range of the code segment, avoids the encryption operation on the non-code part, and improves the pertinence and the efficiency of encryption. The code segment can be accurately found by using the node list information, so that the accuracy of encryption operation is ensured, and misoperation is prevented.
In an embodiment, as shown in fig. 2, the determining, based on the first byte sequence and the target byte sequence, whether the program to be executed is a target program to be decrypted includes:
S21, comparing the obtained first byte sequence with a target byte sequence;
and S22, under the condition that the comparison result is determined to be matched, determining the program to be executed as a target program to be decrypted.
In this embodiment, the comparison result refers to a result obtained by comparing the first byte sequence with the target byte sequence, and is used to determine whether the program to be executed is the target program to be decrypted.
Specifically, when it is determined whether a program is a target program to be decrypted, the system compares the first byte sequence of the program with a pre-stored target byte sequence. And if the comparison result shows that the two are consistent, the program is considered as a target program to be decrypted.
For example, there are many programs in an operating system, for a video playing program, the system will read the byte sequence of a specific location, and compare with the stored target byte sequence, if the video playing program is a program that the developer sets to be protected, the byte sequence may be set to the target byte sequence, and when the two are consistent, it is determined that it is the target program to be decrypted.
The application provides a simple and effective program identification method, which is convenient for a system to screen out programs needing special processing (decryption). The accuracy of judgment is improved, and only programs meeting the requirements can enter the decryption flow.
In one embodiment, as shown in fig. 3, the target operating system decrypts the code segment and maps the decrypted code segment back to the target program to be decrypted, including:
S31, determining a first physical address of the code segment;
In this embodiment, the first physical address is the original physical address of the code segment at the time of program storage or execution, that is, the actual address of the code segment in memory or storage.
S32, mapping the code segment to a virtual memory and then decrypting, wherein the virtual memory is provided with a second physical address;
in this embodiment, the virtual memory is a memory provided by the operating system for the program, and maps the physical memory and the logical address space, so that the program sees the virtual memory address, and the operating system maps the virtual memory address to the physical memory.
The second physical address is a physical address after the code segment is mapped to the virtual memory, and is different from the first physical address because of the mapping mechanism of the virtual memory.
S33, remapping the decrypted code segment to the first physical address based on the second physical address and the first physical address.
In this embodiment, the first physical address of the code segment is found. The code segment is mapped to the virtual memory space, decrypted in the virtual memory, and then at the second physical address. And remapping the decrypted code segment back to the first physical address by using the mapping relation between the first physical address and the second physical address.
For example, for an image editing program, the code segment is stored in address 0x1000 (first physical address) of the physical memory, and when decrypting, it is mapped into the virtual memory, and assuming that the physical address corresponding to the virtual memory is 0x2000 (second physical address), after the decryption operation is completed at 0x2000, the decrypted code segment is re-mapped back to the address 0x 1000.
The application utilizes the virtual memory to carry out decryption operation, thereby avoiding the security risk possibly brought by direct operation on the original physical address. The decrypted code segment can be correctly mapped back to the original position, and normal operation of the program is ensured.
In an embodiment, as shown in fig. 5, the method further comprises:
S61, when the target operating system is determined to crack the code segment, a call request for accessing the target operating system is obtained.
In this embodiment, the call request is a request issued when a user or other program attempts to access the target operating system, specifically here an access request when the target operating system performs a code segment cracking (decrypting) operation.
S62, determining first feedback information of the judging module based on the calling request.
In this embodiment, the determining module is a module responsible for determining whether to allow access to the target operating system, and may give feedback information according to different situations.
The first feedback information is information given by the judging module when the target operating system is in a code segment cracking (decryption) state and an access request is received, and the information is used for prohibiting access.
S63, based on the first feedback information, prohibiting access to the target operating system.
In this embodiment, when the target operating system begins to crack (decrypt) the code segment, if an access request is received thereto. The judgment module generates first feedback information according to the situation. And refusing to access the operating system according to the first feedback information.
Specifically, modifying the ptrace system call of the Linux kernel source code achieves the purpose of prohibiting access, and ptrace is a powerful system call and is mainly used for process tracking and debugging. It allows one process (typically a debugger) to observe and control the execution of another process (the debuggee process). For example, a developer may use ptrace to view the register state, memory contents, or modify its execution flow of another process.
And adding a judgment condition variable in the ptrace system, finding a kernel code segment related to the ptrace system call, and adding a check on the judgment condition variable at a proper position. The initial value of this variable is set to false (default not allowed ptrace) in the appropriate kernel initialization function.
The predicate condition variable may be understood as a flag or condition set in the kernel to decide whether to allow the ptrace system call to be successfully executed. For example, a boolean type variable may be set that allows the ptrace system call to return a default error when the variable is false, and allows the ptrace system call to execute when the variable is true.
The application enhances the system security in the decryption process and prevents the interference and attack of external programs. The independence and the safety of the operating system in key decryption operation are ensured, and potential safety hazards are avoided.
In an embodiment, as shown in fig. 5, the method further comprises:
S64, obtaining the change information of the judging module.
In this embodiment, the modification information is information for modifying the judgment module, and may be an operation from a user or a system administrator.
S65, determining second feedback information of the judging module based on the change information.
In this embodiment, the second feedback information is information generated by the determining module when the modification information is received, and is used to allow access to the target operating system.
S66, allowing access to the target operating system based on the second feedback information.
In this embodiment, the system receives the modification information to the determination module. The judging module generates second feedback information according to the change information. And allowing access to the target operating system according to the second feedback information.
Specifically, a function is provided in the kernel module of the target operating system to modify the value of the judgment condition variable. For example, a function may be defined, and when this function is called, the judgment condition variable may be set to true or false.
Assuming a simple scenario, where a security sensitive application is running, it is not desirable for an average user to be able to debug the application through ptrace.
When a process attempts to call ptrace, the kernel first checks the judgment condition variable allowance_ptrace. If allowrace is false, an error is immediately returned and no debugging is allowed.
For example, a malicious user may attempt to track the progress of a security sensitive application using ptrace, which may fail due to the fact that allowances_ptrace is false by default.
Assuming that the developer of the system needs to debug a process, the ptrace. Ko module may be loaded. This module provides a function, such as enable_ptrace (), which when called will set allowance to true.
Now, a specific process may be debugged using ptrace, and after completing the debugging, another function (such as disable_ptrace ()) may be called to set the allowance_ptrace again to false, and the security state is restored. And, the ptrace. Ko module is not released with the product and is only used in the debugging stage.
The application provides a flexible access control mechanism, ensures the safety of the system, allows a system administrator to remove access restriction when necessary, and is convenient for the maintenance and management of the system. The controllability of the system under different states is ensured, and the usability and manageability of the system are improved.
Illustratively, a product employs a kernel of the linux-4.19.90 version, among which is a program in the form of an ELF (executable and linkable format) binary, which is a program in the product that provides core services and therefore needs to be protected.
An application program in an ELF format refers to an executable and linkable format program, and various application programs, system tools and the like commonly found in Unix-like operating systems such as Linux, and commands such as ls, cp and the like are executable programs in the ELF format.
The anti-cracking method of the application is characterized in that when an application program in an ELF format is protected, the method comprises the following steps:
The code segments of the application program in the form of an ELF to be protected are encrypted by means of an encryption tool, the code segments being parts of the program in which executable instructions are stored, for example the area of an image editing software in which the code for processing the image algorithm is located.
The encryption tool encrypts the code segment according to a specific encryption algorithm, a key and an initial vector, thereby protecting the core logic of the program. Specifically, as shown in fig. 6, the encryption tool reads the ELF header of the executable program, and confirms that the file is in the form of an ELF. Then the section header (section) table of the ELF of the executable program is read, the code section is searched, and if the code section fails, the code section is ended. After finding, the file offset and size of the code segment are obtained. Finally, the encryption tool reads the offset and size content of the code segment file in the executable program, and encrypts the content by using a preset encryption algorithm and a preset secret key and then writes the encrypted content back to the original position.
Wherein, the encryption can be carried out by adopting an AES256-CBC mode, the encryption key is key, the initial IV is IV, and the encryption tool encrypts the code segment (text section) of the protected program. CBC mode requires 16 byte alignment of data and is not encrypted when the tail data is less than 16 bytes.
Then, by means of the Linux kernel, in the call-back interface load_elf_binary of the ELF loading module, when the loaded application program is detected to be the application program with the preset ELF format needing to be protected, the system executes a series of key operations. For example, the file name pointed by the structfile pointer of the current loaded file is compared, and if the file name is just the preset core service program to be protected, the system executes the subsequent operation.
The Linux kernel is a core part of a Linux operating system and is responsible for managing system resources, scheduling processes and other operations. load_elf_binary is a key interface in the Linux kernel for loading an ELF binary, which is called to complete the relevant loading operation when the system starts an application in an ELF format or dynamically links libraries.
The system, when performing a series of critical operations, first maps the portion of the pt_load type pointed to by the ELF program header to virtual memory. The code segments mapped into the virtual memory are then decrypted and remapped back to the original location using the same encryption algorithm and key as the encryption tool.
The ELF program header is a part of the ELF file for describing the overall structure and attribute of the program, and contains important information such as program entry address, segment table and the like. The ELFPT _load type portion contains critical information when the program is loaded in memory, such as the layout, permissions, etc. in memory, for code segments and data segments. Virtual memory is an independent, abstract memory space provided by the operating system for each process.
In this way, the security of the protected ELF format application throughout the operation is ensured. When the program is not running, the code segment is in an encrypted state, even if the program file is illegally acquired, an attacker can not easily acquire the core code of the code segment, and when the program is running, the decryption operation is only carried out under a safe kernel environment and the specific condition is met, and the mapping of the decrypted code segment in the memory is strictly controlled, so that the risk of illegally acquiring and tampering the code segment is greatly reduced.
Based on the same inventive concept, the embodiment of the application also provides an electronic device, which comprises a memory and a processor, wherein the memory stores executable programs/instructions, and the processor executes the executable programs/instructions to realize the steps of the method.
The processor may be a general purpose processor, a digital signal processor, an application-specific integrated circuit (ASIC), a programmable logic device (programmablelogicdevice, PLD), or a combination thereof. The PLD may be a complex programmable logic device (complexprogrammablelogicdevice, CPLD), a field-programmable gate array (field-programmablegatearray, FPGA), generic array logic (genericarraylogic, GAL) or any combination thereof. The general purpose processor may be a microprocessor or any conventional processor or the like.
The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flashRAM). Memory is an example of a computer-readable medium.
Embodiments of the present application also provide a storage medium carrying one or more computer programs which, when executed by a processor, implement the steps of the method as described above.
The storage medium in the embodiments may be included in the electronic device/system or may exist alone without being assembled into the electronic device/system. The storage medium carries one or more programs which, when executed, implement methods in accordance with embodiments of the present application.
According to embodiments of the application, the computer-readable storage medium may be a non-volatile computer-readable storage medium, which may include, for example, but is not limited to, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
Based on the same inventive concept, embodiments of the present application also provide a computer program product comprising a computer program/instruction which, when executed by a processor, implements a method as described in any of the above embodiments.
It will be appreciated by those skilled in the art that embodiments of the application may be provided as a method, an electronic device, a computer-readable storage medium, or a computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media having computer-usable program code embodied therein. When implemented in software, these functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium.
The above embodiments are only exemplary embodiments of the present application and are not intended to limit the present application, the scope of which is defined by the claims. Various modifications and equivalent arrangements of this application will occur to those skilled in the art, and are intended to be within the spirit and scope of the application.