JP2018124850A - Program protection apparatus, program protection method, and program protection program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To realize protection of programs from analysis while avoiding analysis on a library function to be used at the time of program execution.SOLUTION: A program providing apparatus 10 is a unique loader that operates independently of a program loading mechanism provided by an operation system at the time of program execution, and includes a loader embedding unit 151 configured to previously embed, in a protection target program, a unique loader for loading an executable file including a library function and putting the library function included in the executable file in a ready state, and an output unit 13 configured to output a protected program which is the protection target program in which the unique loader is embedded.SELECTED DRAWING: Figure 2

Description

  The present invention relates to a program protection device, a program protection method, and a program protection program.

  With the spread of the Internet, software distribution methods such as downloading software from the Internet and executing it on a computer have become common. Digital data makes it possible to copy and distribute original software in response to a request from a user, taking advantage of the characteristics that can be easily duplicated. However, it is problematic that an unspecified number of users have the same software as the original.

  Here, the flow of software execution will be described using Windows (registered trademark) as an example. A Windows program loader reads an executable file in PE (Portable Executable) format and prepares an execution environment so that the program can be executed. As a process for preparing the execution environment, a first process for expanding an execution file on a memory and a DLL (Dynamic Link Library) including an API (Application Programming Interface) used by the execution file are expanded on a memory. There are two processes and a third process for adjusting the consistency of the pointer so that the API provided by the DLL can be called from the code portion of the executable file.

  First, the first process will be described. In the first process, the Windows loader first checks the PE header of the execution file and secures a memory area necessary for loading the execution file. Next, the Windows loader maps the area to the memory space in which the execution file is secured. Files mapped to this memory space are managed by Windows. Specifically, information on a file created and mapped for each memory area where a structure called VAD (Virtual Address Descriptor) is used is also stored in this VAD.

  Next, the second process will be described. In the second process, the Windows loader refers to the information stored in the import table of the PE header in order to know the DLL having the API used by the execution file. The Windows loader parses (analyzes) the data structure of the import table, identifies the necessary DLL and API, and expands (loads) the DLL onto the memory. The memory address where this DLL is arranged is called a base address. The loaded DLL information is held in a linked list structure in a data structure called PEB (Process Environment Block). Each entry of this list holds information on each loaded DLL. The DLL base address information is also stored in this entry.

  Then, the third process will be described. In the third process, the execution file calculates the address at which the target API is arranged in the memory based on the base address of the loaded DLL and the offset information of each API provided by the DLL export table. Store the address in its own import address table. The executable file is called via this import address table when calling the API. For example, the execution file uses an indirect call instruction such as “call [0x10001000]” and calls an address stored in “0x10001000” as a function to realize an API call.

  In addition, the execution file can dynamically acquire the address where the target API is arranged without going through the import address table, and call the API by a method of jumping directly. In the case of Windows, use LoadLibrary to know the address where the DLL is loaded (if the DLL is not loaded yet, load a new DLL), and use GetProcAddress to obtain the API address provided by this DLL It is also possible to dynamically know the API address.

  Next, the structure of the PE header that the execution file confirms will be described. FIG. 9 is a diagram for explaining the structure of the PE header. FIG. 9A shows an example of a PE file format in which a PE header exists. FIG. 9B shows a part of information extracted for explanation from the information included in the PE header. As shown in FIG. 9, the PE header is a header file that exists in a PE file format file, and stores information related to the file. The PE file format is a standard format for Windows executable files.

  Usually, a program uses a plurality of external libraries. In the case of Windows, the API corresponds to this external library function. The Windows system DLL provides these APIs.

  In the PE header, information on which API the execution file requires is described in the import table. The import table is “IMAGE_IMPORT_DESCRIPTOR” (see frame C2 in FIG. 9B) pointed from “IMAGE_DATA_DIRECTORY (IMAGE_DIRECTORY_ENTRY_IMPORT)” (see frame C1 in FIG. 9A). The import table includes an import name table in which information on names of APIs and DLLs used by the execution file is stored, an import address table in which address information on the memory of the DLL is stored (FIG. 9). (See (1)).

  Further, when the execution file discloses an interface to the outside (for example, in the case of DLL), API information provided by the program itself is held in the export table. The export table is “IMAGE_EXPORT_DIRECOTRY” (see frame C4 in FIG. 9B) pointed from “IMAGE_DATA_DIRECTORY (IMAGE_DIRECTORY_ENTRY_EXPORT)” (see frame C3 in FIG. 9A). In the export table, the name of the API provided and information on the location where the API is arranged are described (see (2) in FIG. 9). The information on the location where the API is arranged is expressed as a relative address (offset) from the base address.

  Such a mechanism of operation is open to the public. For this reason, the attacker uses various analysis techniques based on the structure of the PE format file related to execution and the behavior of API calls, etc., to clarify the internal structure of the software and invalidate the original function. , Adding functions, obtaining hidden information, etc.

  In other words, as long as any program is loaded by the Windows loader, it is necessary to appropriately provide the program structure information to the loader according to the PE file format. For this reason, the attacker can specify the code part related to the authentication of the paid software license based on the information obtained from the above structure and modify the program so that the part is bypassed without the license. Paid software can be used. There is also a concern that attackers may identify vulnerabilities in software and use them for infections such as computer viruses.

  For this reason, there are various protection techniques and code obfuscation techniques for protecting programs from analysis. For example, in recent years, a code obfuscation technique for preventing reverse engineering has been proposed (see, for example, Non-Patent Document 1). Furthermore, in order to hide the API imported by the program, part of the information included in the PE header, specifically, the name of the API and DLL used by the executable file is described in the import name table. There has been proposed a method of deleting or making it difficult to find the position of the import address table in which the address information on the memory of the DLL is stored (see, for example, Non-Patent Document 2).

Andreas Moser, Christopher Kruegel, and Engin Kirda, “Limits of Static Analysis for Malware Detection”, in Proceedings of the 23rd Annual Computer Security Applications Conference (ACSAC) 2007. Analyzing Malware-Infection Case Management Using Free Tools (Art Of Reversing), Arai Satoshi (Author), Iwamura Makoto (Author), Kawafuruya Yuhei (Author), Aoki Kazufumi (Author), Hoshizawa Yuji (Author) ), O'Reilly Japan (2010/12/20)

  However, even if measures are taken using the method described in Non-Patent Document 1, there is a problem that the program is actually operated, and the behavior of the program is analyzed by an attacker by the API call sequence to be called. Specifically, it is conceivable that an attacker sets an API hook for an important API and executes a method of intercepting the API call. Or, it is important that the attacker deceives the analysis target program by rewriting the return value, and causes the attacker to perform the intended operation, or extracts the arguments passed to each API and is used in the program It is conceivable to execute a method of peeping out (stealing) various information.

  In addition, a method has been established for restoring a hidden import name table by taking and analyzing a memory dump after restoration at the time of execution. Therefore, even if the import name table or the like is deleted using the method described in Non-Patent Document 2, there is a problem that an attacker can call an API or analyze an imported API.

  In this way, even using the code obfuscation technology and PE header rewriting technology that have been proposed in the past, it is possible to call APIs and analyze imported APIs. Could not be protected.

  The present invention has been made in view of the above, and provides a program protection device, a program protection method, and a program protection program capable of avoiding analysis of library functions used during program execution and protecting the program from the analysis. The purpose is to do.

  The program protection device according to the present invention is a unique loader that operates independently of the program loading mechanism provided by the operation system when executing a program. The program protection device loads an execution file including a library function and is included in the execution file. A loader embedding unit that embeds a unique loader that makes a callable library function into a protected program in advance, and an output unit that outputs a protected program that is a protected program in which the unique loader is embedded And

  According to the present invention, it is possible to avoid the analysis of the library function used at the time of executing the program and protect the program from the analysis.

FIG. 1 is a diagram schematically illustrating an example of an information system according to the present embodiment. FIG. 2 is a block diagram showing a configuration of the program providing apparatus shown in FIG. FIG. 3 is a diagram for explaining the processing of the loader embedding unit shown in FIG. FIG. 4 is a diagram for explaining the configuration of the unique loader according to the present embodiment. FIG. 5 is a flowchart showing the processing procedure of the program protection processing executed by the program providing apparatus shown in FIG. FIG. 6 is a flowchart showing a processing procedure of processing in which the protected program independently executes the loader. FIG. 7 is a flowchart showing another processing procedure for the protected program to independently execute the loader. FIG. 8 is a diagram illustrating an example of a computer in which a program protection device is realized by executing a program. FIG. 9 is a diagram for explaining the structure of the PE header.

  Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings. In addition, this invention is not limited by this embodiment. Moreover, in description of drawing, the same code | symbol is attached | subjected and shown to the same part.

[Embodiment]
Embodiments of the present invention will be described. In the embodiment of the present invention, a program protection device, a program protection method, and a program protection program for performing protection processing for avoiding analysis of a library function for a protection target program will be described. First, an example of the information system in the embodiment will be described.

[Information system configuration]
FIG. 1 is a diagram schematically showing an example of the configuration of an information system according to an embodiment of the present invention. Note that the information system according to the present embodiment will be described by taking as an example the case where each device executes an operation process on Windows among various operating systems (OS). Of course, even if the OS adopts Linux (registered trademark) or Macintosh (registered trademark) as the OS, the program protection processing can be performed in the same manner.

  The information system shown in FIG. 1 has a configuration in which, for example, a program providing apparatus 10 (program protection apparatus) and an information processing apparatus 100 are connected via a network N such as the Internet or a dedicated line.

  The program providing apparatus 10 provides a program to the information processing apparatus 100 via the network N. The program providing apparatus 10 provides the information processing apparatus 100 with a protected program obtained by performing a program protection process for avoiding the analysis of the library function for the protection target program. As the program protection process, the program providing apparatus 10 performs a process of pre-embedding a unique loader that operates independently of the program loading mechanism provided by the OS into the execution file of the protection target program. Independent of the program loading mechanism provided by the OS, this unique loader loads an execution file including a library function and makes the library function included in the execution file callable.

  That is, the program providing apparatus 10 generates a protected program that prevents analysis by the user by embedding a unique loader in the provided program. Then, the program providing apparatus 10 distributes the protected program to the users. Hereinafter, the protection target program indicates a program before the unique loader is embedded, and the protected program indicates a program in which an original loader or the like is embedded and obfuscation of a library function (for example, API) is obfuscated.

  The protected program may be provided to other devices (for example, the information processing device 100) via the network N, may be stored in a storage medium, and may be provided to other devices by distribution of the storage medium. Good.

  The information processing apparatus 100 is a server apparatus, a PC (Personal Computer), a smartphone, or the like. In the information processing apparatus 100, when the protected program provided by the program providing apparatus 10 is acquired, the protected program is loaded by the program loading mechanism provided by the OS and developed in the memory. Thereafter, control is transferred to the bootstrap code, and the original code is made executable by using the function of the original loader. In the information processing apparatus 100, the unique loader is capable of calling library functions included in the execution file. In other words, in the environment of the information processing apparatus 100 that is the user, the protected program starts the loading process independently of the program loading mechanism provided by the OS, and the API is used to increase the confidentiality by the original loader. API is obfuscated by loading the DLL that provides the above.

[Configuration of Program Providing Device]
Next, the configuration of the program providing apparatus 10 will be described. FIG. 2 is a block diagram showing a configuration of the program providing apparatus 10 shown in FIG. As illustrated in FIG. 2, the program providing apparatus 10 includes a communication unit 11, an input unit 12, an output unit 13, a storage unit 14, and a control unit 15.

  The communication unit 11 is a communication interface that transmits and receives various types of information to and from other devices connected via a network or the like. The communication unit 11 is realized by a NIC (Network Interface Card) or the like, and performs communication between another device and the control unit 15 via a telecommunication line such as a LAN (Local Area Network) or the Internet. For example, the communication unit 11 inputs a protection target program input via the network N or the like to the control unit 15. And the communication part 11 transmits the protected program by which the program protection process was performed to another apparatus via the network N etc.

  The input unit 12 is an input interface that accepts various operations from an operator of the program providing apparatus 10. For example, the input unit 12 includes an input device such as a touch panel, a voice input device, a keyboard, and a mouse.

  The output unit 13 is realized by, for example, a display device such as a liquid crystal display, a printing device such as a printer, an information communication device, or the like. The output unit 13 outputs the result of the program protection process to the operator.

  The storage unit 14 is realized by a semiconductor memory device such as a RAM (Random Access Memory) or a flash memory, or a storage device such as a hard disk or an optical disk, and a processing program for operating the program providing device 10 or a processing program The data used during the execution of is stored.

  The control unit 15 has an internal memory for storing a program that defines various processing procedures and the necessary data, and executes various processes using these. For example, the control unit 15 is an electronic circuit such as a CPU (Central Processing Unit) or an MPU (Micro Processing Unit). The control unit 15 includes a loader embedding unit 151.

  The loader embedding unit 151 embeds the unique loader in the protection target program in advance. This unique loader operates independently of the program loading mechanism provided by the OS of the execution destination apparatus (for example, the information processing apparatus 100) during execution of the program. Then, this unique loader loads an execution file including the API and makes the API included in the execution file callable. The loader embedding unit 151 includes a dependency API enumeration unit 152 (dependence library function enumeration unit), a data code injection unit 153, and a header correction unit 154.

  The dependency API enumeration unit 152 enumerates DLLs and APIs on which the protection target program depends, and obfuscates the names of the enumerated library functions. The data code injection unit 153 injects data necessary for execution such as a character string table obfuscated with an API name, a unique loader, and a bootstrap code into the protection target program.

  The header correction unit 154 corrects the PE header that is the header of the execution file so that the bootstrap is executed before the original code of the protection target program. Accordingly, the unique loader can operate before the original code of the protected program is executed when the protected program is executed in the information processing apparatus 100. The original code is a code part of the protection target program.

[Processing of loader embedding part]
Next, processing of the loader embedding unit 151 will be described. FIG. 3 is a diagram for explaining the processing of the loader embedding unit 151 shown in FIG.

  The loader embedding unit 151 receives an execution file in PE format as an input as a protection target program Pa. The loader embedding unit 151 embeds the original loader Da, the bootstrap code Db, and data Dc necessary for execution in the protection target program Pa. Further, the loader embedding unit 151 corrects the information of the PE header, and outputs the program with the corrected PE header as the protected program Pb.

  Here, the data Dc is information on DLLs and APIs imported by the protection target program Pa, an original entry point indicating the original entry of the protection target program (the first instruction to be executed first), and the like. It is. The entry point is the entry of the executable file (the head of the first instruction to be executed) written in the PE header of the executable file in the PE file format. The original entry point is the original entrance (the head of the first instruction to be executed) of the protection target program.

  Next, each process executed by the dependency API listing unit 152, the data code injection unit 153, and the header correction unit 154 constituting the loader embedding unit 151 will be described.

  First, the dependency API enumeration unit 152 scans the PE header of the protection target program Pa, and enumerates external DLLs and APIs on which the program depends. The enumerated API names are used later by the bootstrap code Db when executing the protected program in the information processing apparatus 100. For this reason, the dependent API enumeration unit 152 obfuscates the API name using an algorithm that can be restored, and requests the data code injection unit 153 to inject the obfuscated API name into the protection target program Pa.

  The data code injection unit 153 injects the passed data or code into the protection target program Pa. The data code injection unit 153 uses a method of finding an area of an appropriate size in an existing section for injection, or a method of adding a new section and adding data or code to the added section. . In addition, the data code injection unit 153 changes the appropriate permission for the section if necessary at the time of injection.

  What the data code injection unit 153 embeds in the protection target program Pa includes data necessary for execution such as a character string table obfuscated by the name of the API on which the protection target API depends, a unique loader, and a bootstrap code These are the three. When embedding the bootstrap code, the data code injection unit 153 embeds the original entry point information in the protection target program Pa in a form including the bootstrap code. Alternatively, the original entry point information may be stored in data (Dc), and the bootstrap code may refer to this.

  Then, the header correction unit 154 corrects the PE header so that it is executed before the original code. Specifically, the header correction unit 154 corrects the PE header entry point to point to the embedded bootstrap code. The entry point is information indicating the entry of the execution file written in the PE header of the execution file in the PE file format. Alternatively, the header correction unit 154 can use a method of registering the embedded bootstrap code as a handler for the TLS-callback by performing a specific process at the start and end of a thread called TLS-callback. . In addition, the header correction unit 154 deletes dependent API information, debug information, and the like in order to increase the confidentiality of the protected program.

[Bootstrap code]
Next, the bootstrap code Db will be described. The bootstrap code Db starts processing before the original code of the protection target program Pa is executed when the protected program Pb is executed. The bootstrap code Db loads the DLL on which the code of the protection target program Pa depends using the function of the unique loader Da. Then, the bootstrap code Db resolves the API and cancels the dependency. When the bootstrap code completes the dependency resolution, it jumps to the original entry point and starts executing the original code.

[Original loader]
Next, the unique loader Da will be described. The original loader Da has a function for loading a DLL specified by a method with increased confidentiality, and name resolution of an API exported by the DLL loaded by the above method (from the API name to the API memory). A function for obtaining a placement address).

  FIG. 4 is a diagram illustrating the configuration of the unique loader Da according to the present embodiment. As shown in FIG. 4, the unique loader Da includes a load DLL management data area Ra, a DLL load function Rb, and an API resolution function Rc.

  First, the load DLL management data area Ra will be described. The load DLL management data area Ra is an area for managing data loaded by the unique loader Da. Specifically, the load DLL management data area Ra is related to the loaded base address, size, presence / absence of initialization, exported API name and offset, imported API name and offset, and the like. Information to be stored is stored.

  These pieces of information are information managed in a data area such as PEB (Process Environment Block) or TEB (Thread Environment Block) that is normally managed by Windows of the information processing apparatus 100 receiving the program.

  In the present embodiment, it is designed so that traces of the loaded DLL are not left in these data areas managed by Windows of the information processing apparatus 100. For this reason, the unique loader Da uniquely manages information on the loaded DLL in its own load DLL management data area Ra. Therefore, when the protected program is executed in the information processing apparatus 100, the unique loader stores the information on the loaded execution file in a data area (load DLL management data area different from the data area managed by the OS of the information processing apparatus 100). Save to Ra).

  Next, the DLL loading function Rb will be described. The DLL loading function Rb is a function for loading a DLL designated by a method with enhanced confidentiality. The DLL loading function Rb receives the DLL file name as an input and returns the loaded address of the DLL as an output. First, the DLL loading function Rb checks whether the specified DLL has been loaded by the unique loader Da. If the specified DLL has been loaded, the DLL loading function Rb returns the base address of the DLL. On the other hand, if the designated DLL has not been loaded, the DLL loading function Rb loads the DLL by a method with enhanced confidentiality, and returns the newly loaded base address.

  Here, the method of increasing the confidentiality specifically means that the DLL file can be executed on the memory by a method that does not leave a trace in a data structure such as PEB managed by Windows or a method that does not use a map function or the like. How to make it. When a map function used to expand the contents of a file on memory is used, a data structure for managing the mapped file is generated on the operating system side. In Windows, VAD (Virtual Address Descriptor) corresponds to this structure. This structure can be a hint for identifying the loaded DLL during analysis.

  Therefore, the unique loader Da makes the DLL file executable on the memory by a method that does not use a map function or the like. When executing the protected program in the information processing apparatus 100, the unique loader Da reads the contents of the execution file into a buffer (load DLL management data area Ra) secured in advance without using the map function.

  Further, the unique loader Da deletes a part of the information of the PE header of the uniquely loaded DLL in order to improve confidentiality. The PE header includes information that is required only at the time of loading and is unnecessary after loading, information that is used only during debugging, and the like. Specifically, information that is not necessary after loading is completed or information that is necessary only during debugging is information related to “IMAGE_DEBUG_DRECTORY” included in the PE header and import / export APIs. The DLL loading function Rb deletes “IMAGE_DEBUG_DRECTORY” included in the PE header and information related to the import / export API after the loading is completed.

  If the name table of the API being exported is deleted, dynamic API resolution cannot be performed. In preparation for such a case, the DLL loading function Rb holds the API information being imported and exported in the corresponding entry in the load DLL management data area.

  Next, the API solving function Rc will be described. The API resolution function Rc is a function that returns the address on the memory of the corresponding API in the DLL uniquely loaded from the specified API name. The API resolution function Rc receives as input the base address at which the DLL is loaded and the API name. Then, the API resolution function Rc returns the address of the designated API. As the API address, a value calculated by adding the base address at which the DLL including the API is loaded and the offset from the base address of the designated API is output. The API resolution function Rc uses a DLL base address specified as an input value. As an API offset acquisition method, the following two methods are conceivable.

  First, a first method relating to API offset acquisition will be described. In this method, the API resolution function Rc accesses the header of the target DLL from the designated base address. Then, the API resolution function Rc finds an entry that matches the specified API name from a table that manages a list of APIs that this DLL exports to the outside, and acquires offset information managed by this table. . This behavior is the same behavior as GetProcAddress provided by Windows.

  Next, a second method relating to API offset acquisition will be described. In this method, the API resolution function Rc finds and acquires offset information of the corresponding DLL and API from the load DLL management data area Ra. As described above, the load DLL management data area Ra is an area for managing an API that is being exported and an offset that matches the API.

  These DLL loading function Rb and API resolution function Rc are also effective when the original code dynamically performs API resolution. For example, a call to a DLL load function and an API resolution function is hooked from the original code by some method, and the function is executed for each of the original loaders Da provided. In this state, when the original code performs dynamic API resolution, the DLL load function Rb and API resolution function Rc provided by the original loader are called, so that the target API is also obfuscated by the original loader Da. Will be solved.

  Here, as a hooking method, for example, a method of rewriting the import address table of the original code, a method of embedding a jump instruction at the head of the original DLL loading function and API solving function, or the like can be considered.

  The loader embedding unit 151 may select an API to be obfuscated when the API is resolved by the unique loader Da. For example, when it is not desired to obfuscate some APIs by the original loader Da due to implementation restrictions or user intentions, API resolution is performed by loading with normal Windows, and a pointer indicating the API is set to the import address table. You may make it possible to store it.

[Program protection processing procedure]
In the present embodiment, in order to realize protection of the protection target program, a process for embedding a unique loader by the program providing apparatus 10 to protect the program, and a process for the information processing apparatus 100 to independently execute the loader in the information processing apparatus 100 Two processes are required. Hereinafter, an operation flow for each process will be described.

  First, program protection processing by the program providing apparatus 10 will be described. The program providing apparatus 10 embeds an original loader, a bootstrap code, and data necessary for execution in the protection target program designated as the protection processing target, and the original code is executed in the information processing apparatus 100 that is the program providing destination. Modify the PE header so that the bootstrap code is executed before.

  FIG. 5 is a flowchart showing the processing procedure of the program protection processing executed by the program providing apparatus 10 shown in FIG. As shown in FIG. 5, when the protection target program designated as the protection processing target is input to the program providing apparatus 10 (step S1), the loader embedding unit 151 reads the PE header of the passed protection target program. The import address table and the import name table are specified (step S2).

  Subsequently, the dependent API listing unit 152 reads each entry in the import name table, and adds each read entry to the protection target program (step S3). At this time, the dependent API enumeration unit 152 may encode the API name being imported. The dependent API enumeration unit 152 also adds the storage location of the address corresponding to the name to the protection target program. In other words, the dependency API enumeration unit 152 requests the data code injection unit 153 for data required at the time of execution, such as a character string table obtained by obfuscating the name of the API on which the protection target API depends, and the protection target program Add to Pa.

  Subsequently, the data code injection unit 153 adds the unique loader to the protection target program (step S4). The data code injection unit 153 adds the bootstrap code to the protection target program (step S5).

  Then, the header correction unit 154 corrects the PE header of the protection target program and directs it to the bootstrap code (step S6). Subsequently, the header correction unit 154 deletes the import name table of the PE header (step S7). The header correction unit 154 further corrects the PE header, deletes the pointer to the import name table and the import address table (step S8), and generates a protected program.

  And the program provision apparatus 10 outputs a protected program to another apparatus via the communication part 11 or a storage medium (step S9), and complete | finishes a program protection process.

[Procedure for the original load execution process]
Next, processing that the protected program loads independently in the information processing apparatus 100 will be described. In the information processing apparatus 100, the process in which the unique loader executes the loader independently includes loading a protected program (EXE file) and loading a DLL. First, processing when loading a protected program will be described.

  FIG. 6 is a flowchart showing a processing procedure of processing in which the protected program independently executes the loader. The bootstrap code embedded in the protected program first acquires information on the external DLL and API embedded in the protected program on which the protection target program depends (step S11).

  Then, the bootstrap code loads the dependent DLL using the DLL load function of the unique loader (step S12). Subsequently, the bootstrap code obtains the address of the dependent API using the API resolution function of the unique loader (step S13).

  Then, the bootstrap code writes the acquired API address in the import address table of the protected program (step S14). The bootstrap code determines whether or not all dependent DLL loads and dependent API name resolution have been completed (step S15).

  If the bootstrap code determines that all the dependent DLL loads and the dependent API name resolution have not been completed (step S15: No), the process returns to step S12 to load the DLL. Do. On the other hand, if the bootstrap code determines that the loading of all dependent DLLs and the name resolution of the dependent APIs are complete (step S15: Yes), the bootstrap code jumps to the original entry point and executes it. Is started (step S16).

[Other processing procedures for original load execution processing]
Next, a description will be given of the case of loading a DLL in the unique load execution process. FIG. 7 is a flowchart showing another processing procedure for the protected program to independently execute the loader.

  The protected loader of the protected program opens the designated DLL as a file, and calculates the size required to expand the file on the memory (step S21). The protected loader of the protected program secures the memory in the load DLL management data area based on the size calculated in step S21 (step S22). The unique loader copies the contents of the file from the opened file to the memory secured in step S22 (step S23).

  The unique loader performs DLL relocation based on the PE header relocation table (step S24). When the memory address where the DLL is allocated is tentatively determined, the relocation table rewrites a part of the program when the actually loaded address is determined, and the current loaded address This is a table with information for updating.

  Then, the unique loader loads the DLL imported by the designated DLL, resolves the API (step S25), and writes the address of the resolved API in the DLL import address table (step S26). The unique loader changes the permission of each memory area based on the header information (step S27). Then, the unique loader executes the DLL entry function to initialize the DLL (step S28). Subsequently, the protected loader of the protected program deletes unnecessary information in the PE header (step S29) and ends the process.

[Effect of the embodiment]

  As described above, the program providing apparatus 10 according to the present embodiment embeds the unique loader in the protection target program in advance, and then provides the protection target program to other apparatuses. This unique loader operates independently of the program loading mechanism provided by the operation system during program execution, loads an executable file containing library functions, and makes the library functions included in the executable file callable. To do. That is, the unique loader reads the DLL independently of the program loader provided by the OS of the information processing apparatus 100 that is the program providing destination when executing the protection target program, and sets up the protection target program in an executable state.

  Therefore, according to the present embodiment, the executable file providing the library function is expanded and initialized to be executable without depending on the program loading mechanism provided by the OS of the information processing apparatus 100 that is the program providing destination. Can do. For this reason, in this embodiment, the library function used by the original code can be made unknown to the analysis tool in the information processing apparatus 100. As a result, according to the present embodiment, by embedding a unique loader, analysis of the library function (API) used at the time of program execution by other devices can be avoided, and the protection target program can be protected from the analysis. it can.

  Further, according to the present embodiment, the unique loader operates before the original code of the protection target program is executed when the protection target program is executed. Therefore, according to the present embodiment, it is possible to load the execution file of the protection target program without depending on the function of the program loader originally provided by the OS of the information processing apparatus 100.

  Then, the unique loader can read the contents of the executable file into a buffer secured in advance without using the map function when executing the protection target program. The unique loader stores the information of the loaded execution file in a data area different from the data area managed by the operation system of the information processing apparatus 100 when the protection target program is executed. Further, the unique loader deletes information used only at the time of loading from the header information of the executable file after loading the executable file into the information processing apparatus 100. Thus, in the present embodiment, the DLL including the API is read secretly, and the confidentiality of the used API is enhanced.

  That is, in this embodiment, the Windows system DLL (execution file) is read using this unique loader, the dependency of each DLL is uniquely resolved, and initialization is performed. Thus, in this embodiment, the API provided by the DLL loaded by the original loader can be called in the same manner as the API provided by the DLL loaded by the Windows loader, and the confidentiality of the API can be obtained. Is increasing.

  Therefore, in this embodiment, it is possible to obfuscate library function calls and imported library functions, avoid analysis by other devices of library functions used during program execution, and protect the program from analysis. .

[System configuration, etc.]
Each component of each illustrated device is functionally conceptual and does not necessarily need to be physically configured as illustrated. In other words, the specific form of distribution / integration of each device is not limited to the one shown in the figure, and all or a part of the distribution / integration is functionally or physically distributed in arbitrary units according to various loads or usage conditions. Can be integrated and configured. Further, all or a part of each processing function performed in each device can be realized by a CPU and a program that is analyzed and executed by the CPU, or can be realized as hardware by wired logic.

  In addition, among the processes described in this embodiment, all or a part of the processes described as being automatically performed can be manually performed, or the processes described as being manually performed can be performed. All or a part can be automatically performed by a known method. In addition, the processing procedure, control procedure, specific name, and information including various data and parameters shown in the above-described document and drawings can be arbitrarily changed unless otherwise specified.

[program]
FIG. 8 is a diagram illustrating an example of a computer in which the program providing apparatus 10 is realized by executing a program. The computer 1000 includes a memory 1010 and a CPU 1020, for example. The computer 1000 also includes a hard disk drive interface 1030, a disk drive interface 1040, a serial port interface 1050, a video adapter 1060, and a network interface 1070. These units are connected by a bus 1080.

  The memory 1010 includes a ROM (Read Only Memory) 1011 and a RAM 1012. The ROM 1011 stores a boot program such as BIOS (Basic Input Output System). The hard disk drive interface 1030 is connected to the hard disk drive 1090. The disk drive interface 1040 is connected to the disk drive 1100. For example, a removable storage medium such as a magnetic disk or an optical disk is inserted into the disk drive 1100. The serial port interface 1050 is connected to a mouse 1110 and a keyboard 1120, for example. The video adapter 1060 is connected to the display 1130, for example.

  The hard disk drive 1090 stores, for example, an OS 1091, an application program 1092, a program module 1093, and program data 1094. That is, a program that defines each process of the program providing apparatus 10 is implemented as a program module 1093 in which a code executable by the computer 1000 is described. The program module 1093 is stored in the hard disk drive 1090, for example. For example, a program module 1093 for executing processing similar to the functional configuration in the program providing apparatus 10 is stored in the hard disk drive 1090. The hard disk drive 1090 may be replaced by an SSD (Solid State Drive).

  The setting data used in the processing of the above-described embodiment is stored as program data 1094 in, for example, the memory 1010 or the hard disk drive 1090. Then, the CPU 1020 reads the program module 1093 and the program data 1094 stored in the memory 1010 and the hard disk drive 1090 to the RAM 1012 and executes them as necessary.

  The program module 1093 and the program data 1094 are not limited to being stored in the hard disk drive 1090, but may be stored in, for example, a removable storage medium and read out by the CPU 1020 via the disk drive 1100 or the like. Alternatively, the program module 1093 and the program data 1094 may be stored in another computer connected via a network (LAN, wide area network (WAN), etc.). Then, the program module 1093 and the program data 1094 may be read by the CPU 1020 from another computer via the network interface 1070.

  Although the embodiment to which the invention made by the present inventor is applied has been described above, the present invention is not limited by the description and the drawings that form part of the disclosure of the present invention according to this embodiment. That is, other embodiments, examples, operation techniques, and the like made by those skilled in the art based on the present embodiment are all included in the scope of the present invention.

DESCRIPTION OF SYMBOLS 10 Program provision apparatus 11 Communication part 12 Input part 13 Output part 14 Storage part 15 Control part 100 Information processing apparatus 151 Loader embedding part 152 Dependent API enumeration part 153 Data code injection part 154 Header correction part Da Original loader Db Bootstrap code Dc Data Ra Load DLL management data area Rb DLL load function Rc API resolution function

Claims (8)

A unique loader that operates independently of the program loading mechanism provided by the operation system when executing a program, and can load an executable file containing library functions and call the library functions contained in the executable file A loader embedding unit that embeds the original loader to be protected in advance in the protection target program,
An output unit that outputs a protected program that is a protection target program in which the unique loader is embedded;
A program protection device comprising:   2. The program protection apparatus according to claim 1, wherein the unique loader operates before the original code of the protection target program is executed when the protection target program is executed.   3. The program protection apparatus according to claim 1, wherein the unique loader reads the contents of the execution file into a buffer secured in advance when the protection target program is executed.   The unique loader stores information on the loaded execution file in a data area different from a data area managed by the operation system when the protection target program is executed. The program protection device according to claim 1.   5. The program protection according to claim 1, wherein after the execution file is loaded, the unique loader deletes information used only at the time of loading from the header information of the execution file. apparatus. The loader embedding unit is
A dependent library function enumeration unit that enumerates executable files and library functions on which the protected program depends, and obfuscates the names of the enumerated library functions;
A table of character strings obfuscated by the name of the library function, a data code injection unit for injecting the unique loader and bootstrap code into the protection target program;
A header correcting unit that corrects header information of the executable file so that the unique loader is executed before the original code of the protection target program;
The program protection device according to claim 1, wherein the program protection device includes: A program protection method executed by a program protection device for protecting a protection target program,
A unique loader that operates independently of the program loading mechanism provided by the operation system when executing a program, and can load an executable file containing library functions and call the library functions contained in the executable file Embedding the original loader to be protected in the program to be protected in advance,
Outputting a protected program that is a protection target program in which the unique loader is embedded;
The analysis method characterized by including.   The program protection program for functioning a computer as a program protection apparatus as described in any one of Claims 1-6.

Images