KR102341431B1 - Method for protecting protection target execution file and device for performing the method - Google Patents

Abstract

The present invention relates to a method for protecting an executable file to be protected and to a device for performing the same. The method for protecting an executable file to be protected includes: a step in which a protection process obtains information on a data area and a code area of the executable file to be protected; a step in which the protection process encrypts the data area and code area; and a step in which the protection process decrypts the encrypted data area and the code area based on a decryption request and decryption request data of a protected process based on the executable file to be protected.

Description

{Method for protecting protection target execution file and device for performing the method}

The present invention relates to a method for protecting an executable file to be protected and an apparatus for performing such a method. Specifically, it relates to a method for protecting a protected executable file (or a protected process) through encryption and decryption of the protected executable file, and an apparatus for performing such a method.

Along with the growth of the global software market, the need for intellectual property protection technology for key technologies including key algorithms used within each software is growing. Moreover, as the technology of reverse engineering of executable code continues to develop, the possibility of intellectual property infringement for most commercial software distributed in the form of executable code without source code is increasing. In particular, as reverse engineering tools are gradually automated, core technologies of software can be easily exposed without expertise in the field of reverse engineering. Executable code protection is a technique that protects software distributed in the form of executable code from malicious reverse engineering.

However, the existing executable code protection scheme has limitations. In particular, in the case of the encryption method among executable code protection methods, since the code for decryption is inserted into the executable file, the decryption routine of the protected process is exposed. There is a problem that the key may be exposed.

An object of the present invention is to solve all of the above problems.

In addition, the present invention protects the arbitrary execution of the protected process without increasing the capacity of the protected executable based on the independently operating protected process and reducing the execution speed of the protected process performed based on the protected executable. The purpose.

In addition, the present invention performs decryption of the protected process performed based on the protected executable file through communication between the protected process that operates independently and the protected process that is created when the protected executable file is executed to avoid reverse engineering. It aims to protect the process to be protected.

A representative configuration of the present invention for achieving the above object is as follows.

According to an embodiment of the present invention, a method for protecting an executable file to be protected includes: a protection process obtaining information about a data area and a code area of the protected executable file; The method may include encrypting a region, and the protection process decrypting the data region and the code region encrypted based on a decryption request and decryption request data of the protected process based on the protected executable file.

Meanwhile, the protection process may decrypt the data area and the code area on a decryption original entry point (OEP), and the protected process may be performed on the default OEP after being decrypted on the decryption OEP.

In addition, the decryption request data includes information on a process identification (PID), a base address, and a path to a protected executable file, the PID is an identifier of the protected process, and the base address is a memory start of the protected process. address, and the path of the executable file to be protected may be a path for decrypting the data area and the code area of the process to be protected.

According to another embodiment of the present invention, a user device for protecting an executable file to be protected includes a processor for running a protection process, the processor acquiring information about a data area and a code area of the executable file to be protected; , encrypt the data area and the code area, and decrypt the encrypted data area and the code area based on the decryption request and decryption request data of the protected process based on the protected executable file.

Meanwhile, the protection process may decrypt the data area and the code area on a decryption original entry point (OEP), and the protected process may be performed on the default OEP after being decrypted on the decryption OEP.

In addition, the decryption request data includes information on a process identification (PID), a base address, and a path to a protected executable file, the PID is an identifier of the protected process, and the base address is a memory start of the protected process. address, and the path of the executable file to be protected may be a path for decrypting the data area and the code area of the process to be protected.

According to the present invention, the arbitrary execution of the protected process can be protected without increasing the capacity of the protected executable file based on the independently operating protected process and reducing the execution speed of the protected process based on the protected executable. .

In addition, according to the present invention, reverse engineering is performed by performing decryption of the protected process performed based on the protected executable file through communication between the independently operated protected process and the protected process generated when the protected executable file is executed. The protected process can be protected from

1 is a conceptual diagram illustrating a method of protecting a process to be protected according to an embodiment of the present invention.
2 is a conceptual diagram illustrating an operation of a protection process according to an embodiment of the present invention.
3 is a conceptual diagram illustrating an operation of a protection process according to an embodiment of the present invention.
4 is a conceptual diagram illustrating an encryption area of an executable file to be protected according to an embodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS [0012] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS [0010] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS [0010] Reference is made to the accompanying drawings, which show by way of illustration specific embodiments in which the present invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the present invention. It should be understood that the various embodiments of the present invention are different but need not be mutually exclusive. For example, certain shapes, structures, and characteristics described herein may be implemented with changes from one embodiment to another without departing from the spirit and scope of the present invention. In addition, it should be understood that the location or arrangement of individual components within each embodiment may be changed without departing from the spirit and scope of the present invention. Accordingly, the following detailed description is not to be taken in a limiting sense, and the scope of the present invention should be taken as encompassing the scope of the claims and all equivalents thereto. In the drawings, like reference numerals refer to the same or similar elements throughout the various aspects.

Hereinafter, various preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings in order to enable those of ordinary skill in the art to easily practice the present invention.

An object of the present invention is to prevent reverse engineering of a protected process performed on a user device based on a protected executable file (eg, exe, dll, bin) that is a protection target of the protected process.

Hereinafter, in an embodiment of the present invention, the executable file to be protected may include a file for executing a process such as a Windows executable file (eg, exe, dll, bin). The protected executable file of the present invention may include various executable files for executing a specific process on a computer as well as a Windows executable file.

In the present invention, the process of protecting the protected process from reverse engineering by encrypting the code area and data area of the protected executable file and decrypting the protected process performed based on the protected executable file is a protection process. is defined in terms of The protection process may be independently driven on the user device separately from the protected process to protect the protected process.

A protected executable file may include a code area and a data area. The code area is a set of codes (or instructions) for executing a process, and the data area is a set of data. In the code area, the algorithm created by the developer is exposed in the form of machine language. Since the machine language exposed on the code area is analyzed through reverse engineering, it is possible to know what function the protected executable file performs. That is, when the code area and data area of the protected executable file are analyzed, the protected executable file/protected process is exposed to risk.

In the prior art, the machine language is protected through a technology called code obfuscation in order to prevent the machine language from being exposed as it is. However, there is a problem that an existing code obfuscation machine can be analyzed through reverse engineering. In addition, since the code obfuscation data is inserted into the executable file to be protected, there is a problem in that the execution speed of the process to be protected based on the executable file to be protected is lowered as well as the capacity of the executable file to be protected is increased.

The present invention discloses a method for protecting a protected executable file/protected process from reverse engineering without code obfuscation, slowing down when executing the protected executable, or increasing the size of the protected executable.

1 is a conceptual diagram illustrating a method of protecting a process to be protected according to an embodiment of the present invention.

1 discloses a method for protecting a protected process from reverse engineering based on the protection process.

Referring to FIG. 1 , the protected process 100 operates independently of the protected process 150 performed based on the protected executable 110 , and the protected process 110 (or the protected executable 110 ) ) can be protected. The protection process 100 according to an embodiment of the present invention is operated independently of the protected process 150 , and is encrypted for the protected executable file 100 and is performed based on the protected executable file 110 . Through the decryption of the process 150, it is possible to prevent the analysis of the protected executable file 110 through reverse engineering. Since the protected process 100 is driven independently from the protected process 150 , there is no reduction in the execution speed of the protected process 150 performed based on the protected executable 110 and the protected executable 110 . There may be no increase in the capacity of

First, for encryption, the protection process 100 may distinguish the code area 120 and the data area 130 of the executable file to be protected 110 . The protection process 100 may encrypt the separated code area 120 and the data area 130 of the executable file 110 to be protected. When the process to be protected 150 performed based on the encrypted executable file 110 to be protected is driven, the protected process 100 requests decryption, and the protected process 100 responds to the request of the protected process 150 . The protected process 150 may be decrypted.

When the protected executable file 110 is driven, it is accessed from the memory rather than the file. Accordingly, encryption may be performed on the executable file 110 to be protected, and decryption may be performed on the process 150 to be protected based on the executable file 110 driven in the memory.

If there is no decryption for the protected process 150 of the protected process 100, the protected process 150 cannot be executed, so that arbitrary execution of the protected process 150 can be prevented.

The protection process 100 may perform decryption by setting a separate decryption original entry point (OEP) when decrypting the process to be protected 150 . After the decryption of the protected process 150 is completed, the protected process 150 may be driven on a default OEP of the protected process 150 . After decryption, the default OEP is the address that is executed first when the protected process 150 is executed.

When the protection process 100 encrypts the executable file 110 to be protected, information on the default OEP is also encrypted. Accordingly, when a decryption request of the protected process 150 is requested, the protection process 100 may separately set the decryption OEP and change the start position of the protected process 150 to perform a decryption procedure on the decryption OEP.

The protection process 100 may add a separate communication code when encrypting the protected executable file 110 and communicate with the protected process 150 based on the communication code. The process to be protected 150 may request decryption from the protection process 100 through communication code-based communication. The process to be protected 150 may transmit decryption request data such as a process ID (PID), a base address, and a path to an executable file to be protected to the protection process 100 when a decryption request is made. The PID is identification information of the protected process 150 , and the base address is a memory start address of the protected process 150 . The protected executable file path is information used to obtain information about the code area and data area of the protected process 150 .

The protected process 100 identifies the protected process 150 based on the PID and obtains information about the code area 160 and the data area 170 of the protected process 150 based on the protected executable file path. can do. When the protected executable file 110 is loaded into the memory as the protected process 150 by an operating system (OS), the encrypted code area 120 and the data area 130 are created without the intervention of the protected process 100 . Failure to relocate to executable memory normally.

Accordingly, the protected process 100 does not obtain information through the base address, but rather in the code area 160 and data area 170 of the protected process 150 through the protected executable file path of the protected process 150 . get information about

Specifically, the protection process 100 obtains information about the code area 160 and the data area 170 through the received executable file path of the protected process 150, and the code area 160 and the data area. (170) can be decrypted. The protection process 100 overwrites the decrypted code area 160 and the data area 170 with the code area 160 and the data area 170 already loaded in the memory to operate the protected process 150 normally. can

Through this method, the protection process 100 operates independently outside of the protected process 150 , and when an encryption request for the protected executable files 110 is requested, the code area 120 and the data area of the protected executable file 110 . By performing a role of encrypting 130 and decrypting the protected process 150 only upon request of the protected process 150, it is possible to avoid arbitrary execution of the protected process 150 due to a reverse attack. The boso process 150 can be protected.

The protected process 100 and the protected process 150 may be driven on at least one user device and based on at least one processor of the at least one user device.

2 is a conceptual diagram illustrating an operation of a protection process according to an embodiment of the present invention.

2 discloses a method in which a protection process determines a code area and a data area of an executable file to be protected, and performs encryption.

Referring to FIG. 2 , the protection process 200 may determine the code area 220 and the data area 230 of the executable file 210 to be protected. The code area 220 is a set of codes (instructions) for executing the protected process 250 , and the data area 230 is a set of data related to the protected process 250 .

The code area 220 and the data area 230 are areas analyzed through reverse engineering. Accordingly, the protection process 200 can prevent the analysis (or hacking) of the protected executable file 210 through reverse engineering by encrypting the code area 220 and the data area 230 .

The encryption protection process 200 may add a communication code 280 for communication between the protection process 200 and the protection target process 250 when the protected executable file 210 is executed. The protected process 250 may communicate with the protection process 200 based on the communication code 280 to request the protection process 200 for decryption. As described above, when the executable file to be protected 210 is driven, it is accessed from the memory rather than from the file, so encryption is performed based on the executable file 210 to be protected, and decryption can be performed based on the process 250 to be protected. have.

The protected process 250 may transmit decryption request data (eg, PID, base address, and executable file path) to the protection process 200 when decryption is requested. The protection process 200 may decrypt the protected process 250 based on the decryption request data.

3 is a conceptual diagram illustrating an operation of a protection process according to an embodiment of the present invention.

In FIG. 3 , a method of decrypting the code and data areas of the protected process after the protection process encrypts the code and data areas of the executable file to be protected is disclosed.

Referring to FIG. 3 , the protection process may receive a decryption request and decryption request data from a process to be protected.

The decryption request data may include a PID 350 , a base address (not shown), and a path to an executable file to be protected 360 .

The PID 350 is identification information of a process to be protected, and a base address (not shown) is a memory start address of the process to be protected. The base address (not shown) may be used to obtain a memory start address and a memory end address of the code area/data area of the process to be protected. The protected executable file path 360 may be used to obtain information about the code area and the data area, and to decrypt the code area and the data area.

The protection process may decrypt the protected process according to the decryption request of the protected process.

The protection process identifies the process to be protected based on the PID (S300). After identification of the process to be protected, the protection process may obtain information on the code area and data area of the protected process through the protected executable path (S310), and may decrypt the code area and the data area (S320).

When decoding the process to be protected, decoding may be performed on the decryption OEP (S325). OEP is the address that is executed first when the program is executed. In the present invention, the decryption OEP in which the decryption of the protected process is performed is different from the default OEP, which is the starting address for the actual execution of the protected process. Since the code area and data area are encrypted, the protected process is decrypted on a separate decryption OEP rather than the default OEP. Decryption is performed on the decryption OEP, and after the decryption is completed, the default OEP is returned to normal execution of the protected process (S335).

Specifically, when a protected executable file is loaded into the memory as a protected process by the OS, the encrypted code area and data area cannot be normally relocated on the executable memory without the intervention of the protected process. Accordingly, after the information on the code area and the data area is obtained and decoded through the protected executable file path 360, the code area and the data area that are loaded into the memory based on the base address and decoded into the data area are separated. By overwriting the information, the protected process can operate normally.

4 is a conceptual diagram illustrating an encryption area of an executable file to be protected according to an embodiment of the present invention.

4 shows a code area and a data area of an executable file to be protected.

Referring to FIG. 4 , an area to be encrypted among the structure of the executable file to be protected may be a section area. In particular, encryption may be performed on a text section 420 and a data section 440 among the section areas. The text section 420 may mean a code area of the executable file to be protected, and the data section 440 may mean a data area of the executable file to be protected.

For encryption of the code area and the data area, information on the sizes and addresses of the text section 420 and the data section 440 is required. Information on the addresses and sizes of the text section and data section in the format of the executable file may be acquired through the IMAGE_SECTION_HEADERS 420 . The protection process may encrypt the text section (code region) 420 and data section (data region) 440 based on information about the size and address of the text section 420 and data section 440 . The protection process may add a communication code when encrypting the code area and the data area.

Upon decryption, the protected process may acquire addresses of functions necessary to communicate with the protected process based on the communication code. If the protected process succeeds in communication with the protected process based on the acquired function, the protected process can request decryption. The protected process may transmit the decryption request data to the protection process when a decryption request is made. As described above, the decryption request data may include information about a PID, a base address, and a path to an executable file to be protected.

The protected process identifies the protected process based on the PID. After identification of the protected process, the protected process may obtain information about the code area and data area of the protected process through the protected executable file path, and may decrypt the code area and the data area. Decryption of the code area and the data area of the protected process may be performed on the decryption OEP.

The protected process may obtain information on the code area and data area of the protected process based on the path of the protected executable file, and may decrypt the code area and the data area. Thereafter, the protection process can operate the protected process normally by overwriting the decoded code area and data area with the code area and data area already loaded in the memory. More specifically, after the decoding of the code area and the data area is finished, the default OEP of the protected process may be returned to the protected process, and the protected process may be normally executed.

The embodiments according to the present invention described above may be implemented in the form of program instructions that can be executed through various computer components and recorded in a computer-readable recording medium. The computer-readable recording medium may include program instructions, data files, data structures, etc. alone or in combination. The program instructions recorded on the computer-readable recording medium may be specially designed and configured for the present invention, or may be known and available to those skilled in the computer software field. Examples of computer-readable recording media include hard disks, magnetic media such as floppy disks and magnetic tapes, optical recording media such as CD-ROMs and DVDs, and magneto-optical media such as floppy disks. medium), and hardware devices specially configured to store and execute program instructions, such as ROM, RAM, flash memory, and the like. Examples of program instructions include not only machine language codes such as those generated by a compiler, but also high-level language codes that can be executed by a computer using an interpreter or the like. A hardware device may be converted into one or more software modules to perform processing in accordance with the present invention, and vice versa.

In the above, the present invention has been described with reference to specific matters such as specific components and limited embodiments and drawings, but these are provided to help a more general understanding of the present invention, and the present invention is not limited to the above embodiments, and the present invention is not limited to the above embodiments. Those of ordinary skill in the art to which the invention pertains can make various modifications and changes from these descriptions.

Therefore, the spirit of the present invention should not be limited to the above-described embodiments, and the scope of the spirit of the present invention is not limited to the scope of the scope of the present invention. will be said to belong to

Claims (6)

How to protect a protected executable file:
obtaining, by a protection process, information about a data area and a code area of the executable file to be protected;
encrypting the data area and the code area by the protection process;
Decrypting, by the protection process, the encrypted data area and the code area based on a decryption request and decryption request data of the protected process based on the protected executable file;
The protection process performs decoding on the data area and the code area on a decryption original entry point (OEP),
The method of claim 1, wherein the protected process is performed on a default OEP after being decrypted on the decryption OEP. delete According to claim 1,
The decryption request data includes information on a process identification (PID), a base address, and a path to an executable file to be protected,
The PID is an identifier of the protected process,
the base address is a memory start address of the protected process;
The method of claim 1, wherein the protected executable file path is a path for decrypting the data area and the code area of the protected process. The user device protecting the protected executable file is:
a processor for running a protection process;
The processor obtains information about the data area and the code area of the executable file to be protected,
encrypting the data area and the code area;
It is implemented to decrypt the encrypted data area and the code area based on the decryption request and decryption request data of the protected process based on the protected executable file,
The protection process performs decoding on the data area and the code area on a decryption original entry point (OEP),
and the protected process is executed on a default OEP after being decrypted on the decryption OEP. delete 5. The method of claim 4,
The decryption request data includes information on a process identification (PID), a base address, and a path to an executable file to be protected,
The PID is an identifier of the protected process,
the base address is a memory start address of the protected process;
The user device, characterized in that the path of the executable file to be protected is a path for decoding the data area and the code area of the process to be protected.

Images