JP5387089B2 - Program and program execution device - Google Patents

Description

  The present invention relates to a program and a program execution device.

  The method of distributing the code is not only in the form of the completed program. For developers, a method of passing in the form of a library is widely used so that a code distributed from a program generated by itself can be called. The form of code included in this library is an intermediate state code after compiling and before linking called object code in a general compiler language such as C language.

  In addition, there is a request to encrypt a part of the code in order to conceal the secret contained in the code, but also for this object code, a request to conceal the information in the code by encryption Exists.

  Since the address to which each object is assigned at the time of linking is determined (address resolution), when encoding is performed for this object code, the result of address resolution at the time of linking for the encoded code Code rewriting occurs and address resolution results cannot be implemented correctly. In addition, there is a problem that decoding cannot be performed correctly as a result of changing the encoded code.

  If the code is created so that address resolution is unnecessary, the above problem does not occur, but the function that uses external data and code cannot be described, so the functions that can be realized are strongly limited, and practical functions are provided Can not.

  Executable code uses a method called position-independent code (PIC) that does not cause code rewriting by address resolution. This method is a technology for executable code after linking, and is based on object code. There is no mechanism to generate such code at this stage.

  Patent Documents 1 (particularly FIG. 1) and 2 disclose that an object file is encrypted and distributed, decrypted at the time of linking with another code, linked, and then encrypted again to recode the object file. A method for preventing disassembly is disclosed. The object file created by this technique operates in the procedure of decrypting the encrypted object code immediately before linking at the time of linking, and re-encrypting the decrypted code after linking.

  Further, Patent Document 3 (particularly FIG. 2) discloses that an execution format program and a dynamic link library code decode the target code before executing the code encoded during execution, Prior to executing the code, a technique is disclosed in which a part of the code in the code is encoded by a method of rewriting the code that requires an address change in the target code.

JP-A-4-268924 JP-A-4-310128 Japanese Patent No. 3033352

  An object of the present invention is to make it possible to correctly decode an encoded program code obtained by encoding an original program code that refers to an external object even when linking is performed using a normal linker.

The invention according to claim 1 is an encoded program code that is an encoding result of an original program code, and a decoding program for causing the computer to execute a process of decoding the encoded program code and restoring the original program code Code, external reference information indicating the address of an external object referred to in the original program code, and the original program code restored by the decrypted program code in response to a call from the external program. A calling program code for causing the computer to execute a process of calling by passing the address of the external object as an argument , wherein the original program code is an address of the external reference information passed as an argument to the external object It is described using By accessing the address of the external reference information passed as arguments from the calling program code acquires an address of the external object, to execute a process of referring to the external object using the address obtained in the computer, that This is an object file format program.

  The invention according to claim 2 is the invention according to claim 1, wherein the address of the external object referred to in the original program code is acquired, and information including the acquired address is generated as the external reference information. The computer program further includes external reference information creation program code for causing the computer to execute the above process.

  According to a third aspect of the present invention, in the first aspect of the invention, the program causes the computer to execute a process of ensuring a memory area that can be read, written, and executed on the memory of the computer. The decryption program code further causes the computer to execute a process for writing the original program code as a result of decryption into the reserved memory area.

  The invention according to claim 4 is the invention according to claim 1, wherein the computer stores flag storage means for storing a flag indicating whether the decoding program code is already executed or not executed, and the calling program code is called In addition, when the flag stored in the flag storage means represents unexecuted, the decoding program code is executed to change the flag to already executed, and when the flag represents already executed, the decoding program It is further characterized by functioning as a control means for controlling not to execute the code.

According to a fifth aspect of the present invention, there is provided decoding means for decoding an encoded program code that is an encoding result of an original program code to restore the original program code, and an address of an external object referred to in the original program code. External reference information storage means for storing external reference information to be represented, and calling means for calling the original program code restored by the decoding means by passing the address of the external reference information as an argument in response to a call from an external program And executing means for executing the original program code called by the calling means, wherein the original program code uses a reference to the external object as an argument and the address of the external reference information passed as an argument. are those described, the passed as arguments from the calling unit When referring to a part object, the address of the external reference information is accessed to acquire the address of the external object, and the execution unit is caused to execute a process of referring to the external object using the acquired address. It is a program execution device characterized.

  According to the first or fifth aspect of the invention, the encoded program code obtained by encoding the original program code that refers to the external object can be correctly decoded even if linking is performed using a normal linker.

  According to the second aspect of the present invention, even when the address of the external object is dynamically determined at the time of execution, the external object can be accessed from the original program code that is the decoding result of the encoded program code.

  According to the third aspect of the present invention, the original program code as the decoding result of the encoded program code can be executed by the computer.

  According to the fourth aspect of the invention, it is possible to eliminate the need for the external program to call the decryption code and the call code individually.

It is a figure which shows the example of the data structure of the object file of embodiment. It is a figure which shows the example of the data structure of an external reference table. It is a figure for demonstrating the flow of the production | generation and utilization of the object file of embodiment. It is a figure which shows the example of the content transition of the external reference table by compilation. It is a figure which shows the example of the content transition of the external reference table by a link and load and execution. It is a figure which shows an example of the hardware constitutions of a computer. It is a figure which shows an example of the flow of a process when the executable program after a link is performed. It is a block diagram which shows the example of a functional structure of the program execution apparatus which a computer implement | achieves by execution of an object file.

  Embodiments of the present invention will be described below with reference to the drawings. First, an example of the data structure of the object file 100 according to the embodiment will be described with reference to FIG. The object file 100 is used as a library function or a library file, for example.

  As illustrated in FIG. 1, the object file 100 includes an object header 110, a code section 120, a unique section 130 and a data section 140. Each of these sections is described in a machine language that can be executed by a microprocessor such as a CPU (Central Processing Unit).

  The object header 110 is a section describing header information of the file 100. The code section 120 is a section including program code, and the data section 140 is a section including data used in executing the program code. These object header 110, code section 120, and data section 140 also exist in a general object file format.

  On the other hand, the unique section 130 is unique to the object file of this embodiment. The unique section 130 is a section that can be read, written and executed. In the unique section 130, an encoded program code 132 that is an encoding result of a program code (referred to as an original program code) to be encoded (for example, encrypted) is placed. Here, the original program code is a program code describing a function that the object file 100 provides to other programs.

  The encoding program code 132 is placed in the unique section 130 at a stage after the object file 100 is protected by encoding (for example, at the time of distribution). Section 130 contains the original program code.

  In a general object file, the original program code is placed in the code section 120. In this embodiment, the encoded program code 132 obtained by encoding the original program code is not the code section 120 but unique as described above. Placed in section 130.

  On the other hand, in the code section 120 of this embodiment, program code for executing the encoded program code 132 placed in the unique section 130 is placed. That is, in this example, an initialization function 122 and a call code 128 are placed in the code section 120.

  The initialization function 122 is a program representing initialization processing of the library (object file 100). The initialization process includes a decoding process for the encoded program code 132 and a process for creating the external reference table 142. The program code for causing the microprocessor to execute the former is the decryption code 124, and the program code for executing the latter is the external reference table creation code 126. The initialization function 122 is called from, for example, a link source code (that is, an external program) that uses this library.

  Here, the external reference table 142 is a table for holding the address information of the external object referred to by the original program code that is the decoding result of the encoded program code 132. Here, the external object is, for example, a function call outside a section or static data placed outside the stack. The section mentioned here is a unique section loaded with the original program code of the decoding result, and the stack is a stack area created in the data section when the object file 100 is loaded into the memory. is there.

  The external reference table 142 is an array of addresses at the time of execution of each external object, as conceptually shown in FIG. In the figure, for convenience, each external object is specified by name, and the address value is shown in association with the name. However, actually, the external reference table image example 50 on the main memory shown in FIG. As described above, each address within the address range of the external reference table 142 on the main memory (which corresponds to the external object) stores the runtime address value of the external object (details will be described later). ). Note that the state of the external reference table 142 described above is the state when the object file 100 is linked to an external program and executed. How such an external reference table 142 is created will be described in detail later with reference to FIGS.

  The external reference table creation code 126 is a program code describing a process for creating a part that is dynamically created at the time of execution in the external reference table 142. In the external reference table 142, data of a static part is described in advance by a programmer. That is, the relocation information (for example, the relocation table is set so that the description of the static part written by the programmer is converted into machine language by compilation and the linker can construct the external reference table 142 of the data section 140 at the time of subsequent linking. ) Is generated. At the stage where the executable file generated by using the object file 100 and being linked into the external program is stored in the file system, the external reference table 142 in the data section 140 of the object file 100 is stored in the external reference table 142. , Only static external reference information, that is, address information about an external object whose address is statically determined is included. The address information of the external object whose address is not determined unless it is executed is created by executing the external reference table creation code 126 during the initialization process by the initialization function 122.

  The decoding code 124 is a program code describing a process of decoding the encoded code into a code that can be executed by the microprocessor.

  The call code 128 is a program code describing a function for calling an original program code obtained by decoding the encoded program code 132. After the decoding code 124 decodes the encoded program code 132 and the external reference table creation code 126 completes the external reference table 142, the call code 128 is the address of the external reference table 142 (for example, the top address). It describes the function of passing to the original program code via the stack or register and calling the original program code.

  The original program code of the decoding result is provided to an external program (for example, a link source program described later) while using an external object using the passed external reference table 142 in response to a call from the call code 128. It has a function to perform predetermined processing. That is, in the original program code, the description of the call of the external object is described in the form of pointing to the entry of the object in the external reference table 142 instead of pointing directly to the name of the object.

  A specific example of the source code of the library that is the basis of the object file 100 is shown below. This is an example for the purpose of showing the feature of the present embodiment regarding the external object reference, and the processing content of the original program code has no particular meaning.

// Example compiled by Microsoft Visual Studio (registered trademark)
#include <windows.h>
// Create your own section
#pragma section (". mysect", write, execute)

bool g_isInitialized = false;
char BaseData [1024];

// External reference table
struct ExternalObjectReferenceTable {
HANDLE hHeap;
char * pData;
DWORD (WINAPI * pGetLastError) (VOID);
LPVOID (WINAPI * pHeapAlloc) (HANDLE, DWORD, SIZE_T);
BOOL (WINAPI * pHeapFree) (HANDLE, DWORD, LPVOID);
} g_table = {NULL, BaseData, NULL, NULL, NULL};
// If you want to create an external reference table statically, do it here

extern bool DoDecrypt (unsigned char *, BYTE *, BYTE *);

// Initialization function
int initialize (void)
{
if (g_isInitialized) return 0;
// Decryption code
static unsigned char key [] = {0, 1, 2, 3, 4, 5, 6, 7};
BYTE * pFuncTop = reinterpret_cast <BYTE *>(topFunc);
BYTE * pFuncTail = reinterpret_cast <BYTE *>(tailFunc);
if (DoDecrypt (key, pFuncTop, pFuncTail)) return -6;

// External reference table creation code
g_table.hHeap = GetProcessHeap ();
if (g_table.hHeap == NULL) return -1;

HINSTANCE hKERNEL32 = LoadLibrary ("kernel32.dll");
if (hKERNEL32 == NULL) return -2;
// kernel32.dll
g_table.pGetLastError = (DWORD (WINAPI *) (VOID))
GetProcAddress (hKERNEL32, "GetLastError");
if (g_table.pGetLastError == NULL) return -3;
g_table.pHeapAlloc = (LPVOID (WINAPI *) (HANDLE, DWORD, SIZE_T))
GetProcAddress (hKERNEL32, "HeapAlloc");
if (g_table.pHeapAlloc == NULL) return -4;
g_table.pHeapFree = (BOOL (WINAPI *) (HANDLE, DWORD, LPVOID))
GetProcAddress (hKERNEL32, "HeapFree");
if (g_table.pHeapFree == NULL) return -5;
g_isInitialized = true;
return 0;
}

// calling code
int callTopFunc (unsigned char * x, unsigned int y) {
if (false == g_isInitialized) return -1;
return topFunc (x, y, &g_table);
}

#pragma code_seg (". mysect")
// Start original program code
int topFunc (unsigned char * x, unsigned int y,
// Example of passing external reference table address by argument (via stack or register)
struct ExternalObjectReferenceTable & pTable) {
// Example of referencing an external object from within the original program code
unsigned char * pBuffer = (unsigned char *) (* pTable-> pHeapAlloc) (pTable-> hHeap, 0, y);

// provide functionality

// Example of referencing an external object from within the original program code
if (pBuffer! = NULL) (* pTable-> pHeapFree) (pTable-> hHeap, 0, pBuffer);
return 0;
}

int tailFunc (int a) {return a;}
// End of encoding target code
#pragma code_seg ()

  The above example is a source code that is assumed to be compiled by a Visual Studio (registered trademark) C / C ++ compiler of Microsoft Corporation. Further, this example is an example in which the specification information specifying the function to be encoded (encrypted) is a function list generated separately from the object code.

  In the above code example, first, a code for creating the unique section 130 is described. If it is a Microsoft Visual Studio C / C ++ compiler, the section can be created with the description [#pragma section (“name”, attribute)]. In the above example, a custom section named “.mysect” is created and set as a writable and executable section. And in the source code, the function defined function can be put in [#pragma code_seg (“name”)] and [#pragma code_seg ()] and placed in the original section that created the function ( (See the description of the original program code at the end of the example code above). When compiling with the GNU GCC compiler, you can specify the section where the function is installed by adding the [__attribute__ ((section (“name”)))] attribute to the function definition.

  In the above code example, the external reference table 142 (“g_table”) is defined after the code for instructing the creation of the unique section.

  After the definition of the external reference table 142, a static part of the external reference table 142 may be described. That is, data that can be generated statically by a label name or the like in the external reference table 142 generates a table entry using the label name, and the linker resolves the address corresponding to the label name.

  In addition, after the description of the external reference table 142, the code of the initialization function 122 is described. In the code of the initialization function 122, the decryption code 124 is first described, and then the external reference table creation code 126 is described.

  In the decoding code 124 of the above-described example, the start address and end address of the section are acquired as information indicating the range of the section to be decoded (that is, the original section 130, particularly the original program code) among the information used for decoding. doing. However, this is only an example. Instead, the start address and the section size may be acquired. As another example, labels may be added to the beginning and end of a section, and the section range may be acquired from these labels. Further, by using defined functions (topFunc and tailFunc in the above code example) at the beginning and end of the section, the decoded code 124 may acquire the section range. Further, if the process performed by the decryption code 124 is ciphertext decryption, a decryption key is required. However, a predetermined value may be used as the decryption key.

  The external reference table creation code 126 in the initialization function dynamically acquires an address at the time of execution for an object whose address should be resolved at the time of execution among the external objects referred to by the original program code, and sets the acquired address. A process to be set in the external reference table 142 is described. For example, in the Windows (registered trademark) operating system, the address of an external function can be acquired by an API function called GetProcAddress. For example, in the above code example, the process heap address of the link source program that calls the library (object file 100) is acquired and registered in the external reference table (g_table.hHeap = GetProcessHeap ()). This process heap is referenced in the original program code. In the above code example, the original program code refers to, for example, the function HeapAlloc included in the library file “kernel32.dll” as an external object. The addresses of these external objects in the memory are obtained by the GetProcAddress function. The acquired address is assigned to a member (eg, pHeapAlloc) of the external reference table g_table.

  Depending on the data used by the original program code, the data in the object may be set directly in the external reference table instead of the address of the external object containing the data.

  After the description of the initialization function 122, a call code 128 for calling the original program code of the decoding result is described. In the above-described example, the call code 128 is a description for calling the function topFunc in the original program code if the external reference table has been initialized (created) (the flag g_isInitialized is true). Here, the function topFunc takes the pointer of the external reference table structure as one argument, and the call code 128 sets the address of the table g_table completed by the external reference table creation code for the argument. Thus, the function topFunc of the called original program code can refer to the external reference table.

  In the above code example, the function topFunc in the original program code described after the call code 128 receives the address (p_table) of the external reference table as an argument. In addition, this function does not refer to an external object (for example, function HeapAlloc) by its name, but refers to that object via the address (p_table-> pHeapAlloc) indicated by the member corresponding to the object in the external reference table. To do. The function refers to the process heap of the calling external function through the member pTable-> pHeap of the external reference table.

  In the above code example, there is only one function providing a function in the original program code, but a plurality of such functions may be included in the original program code. In this case, a call code 128 for calling the function may be prepared for each function so that the functions can be called individually.

  What is necessary is just to produce the source code of such a library in the following flow, for example. That is, first, the original program code is described in a form in which access to the external object is performed via the external reference table as in the above code example. Also, code for specifying to the compiler to place the function of the original program code in its own section is written. In addition, a decoding code for decoding the unique section is implemented. Also, an external reference table is defined, and the contents of the table are described using the label name for data that can be generated statically by the label name. In addition, an external reference table generation code describing a process of registering information about an external object whose address should be resolved at the time of execution in the external reference table is implemented. In addition, a call code that calls a function in the original program code with an external reference table as an argument is described.

  Next, an example of a flow when the object file 100 of this embodiment is created as a library, distributed, and used will be described with reference to FIG.

  In this flow, the library developer first creates the source code 150 of the library as described above on his / her computer 200, and then causes the compiler to compile the source code 150. As a result, an object file 100A of the library is generated. The unique section 130 of the object file 100A is not encoded at this point. Next, the unique section 130 of the object file 100A is encoded by the encoding program. As a result, the distribution version of the object file 100B including the encoded program code 132 is completed. The completed object file 100B is distributed to users who use the library.

  In the above processing flow, before encoding the unique section 130, it is checked whether there is any code that directly refers to the external object in the unique section 130. If it exists, a warning is given to correct the code. Processing may be performed. Whether there is a code that directly refers to the external object may be determined based on, for example, whether there is a relocation table for the unique section 130 and whether the number of entries is 1 or more. That is, when compiling the source code, the compiler creates a relocation table for later processing such as linking or loading, and this relocation table is created for the unique section 130, and 1 is included in this table. If there is the above entry, it is determined that there is a code directly referring to the external object in the unique section 130. When it is determined that there is a code that directly refers to the external object in the unique section 130, the label name of the object referenced from the relocation table and the position of the target code (if debug information is included) , Up to a place on the source code), and the determined information may be displayed together with a warning.

  The user's computer 210 that has received the distribution version of the library (object file 100B) performs the following operations.

  That is, the library user first programs the link source code that uses the library. The link source code is a program code that describes a function that the recipient wants the microprocessor to execute. The link source code includes a description for calling a function (or a plurality of functions) provided by the library. Here, the link source code is programmed so as to call the initialization function 122 of the library prior to calling all the functions provided by the library. This is the general coding work by the recipient.

  The user compiles the created link source code to generate a link source code 155 in the object code format. The link source code 155 is linked to the library object file 100B and the linker. As a result, an executable file 160 is generated. This executable file 160 is loaded into the memory of the user's computer 210 and executed (170). This link may be a static link or a dynamic link.

  Next, an example of content transition of the external reference table 142 will be described with reference to FIGS. In this example, first, as shown in FIG. 4, it is assumed that the external reference table is described as in Code Example 10 in the source code. That is, in this code example 10, an external reference table g_table having pData, pfunc, pfunc2, etc. is defined as a member, and the second member of the table is statically described as a function func. The code example 10 includes, as an example of the external reference table creation code 126, an instruction to substitute the function func2 (address thereof) for the member pFunc2 of the external reference table g_table.

  When the source code including the code example 10 is compiled, an object file including the object code like the code example 20 is obtained. In this example, the external reference table creation code in the source code is “the eighth byte at address 0 (this is the entry of the pfunc entry in the external reference table) at the offset 1300 position in the code section in the object file. It is converted into an instruction (enter 0 in the address) (which has been described in text in the drawing for convenience, but is actually a machine language instruction). An appropriate address value is set later in the two “0” locations of the instruction. In addition, each entry of the external reference table is secured after the offset 4100 of the data section. Here, the address of the function func is set at the position of the offset 4104 at the time of the subsequent link processing. At this time, only the location is secured, and the value is 0. In the relocation section in Code Example 20, the contents of the relocation table, which is relocation information, are entered. The contents of the relocation table specify, for example, which part of the code contains which symbol address. The symbol section in the code includes information on each symbol such as g_table that appears in the code. The symbol information includes, for example, a name, contents (data or function name, etc.), and a definition location (inside or outside this object file).

  When the object file including the code example 20 is linked with an external program (link source code), an executable file including the code example 30 illustrated in FIG. 5 is generated. In this code example 30, the offset value changes from the time of the object file by linking with the external program. The link determines the address of each object (offset value because it is on the file at this point). For example, since the addresses of the external reference table g_table and the functions func and func2 are determined to be 6100, 4800, and 4940, these addresses are set at corresponding positions in the code.

  For example, the address of the function func is set at the position of the function func in g_table located after the offset 6100. This is an example of a static part of the external reference table 142. That is, at the time of linking, the linker refers to the symbol section and the relocation section of the object file to know that the symbol C corresponding to the function func is located at the offset 4104, and the offset 4104 is moved to the offset 6104 by the link. Based on these, the address 4800 of the function func is set in the offset 6104.

  The address 4800 of the function func2 is set in the external reference table creation code that is located at the offset 3300 by the link. In this example, the content of the external reference table creation code is an instruction to set the address 4940 of the function func2 at the eighth byte from the start address 6100 of the external reference table g_table. This is an example in which the address of the external reference table entry is dynamically set by executing the external reference table creation code.

  Note that pData and func2 in the external reference table in the data section are not set yet, and remain 0.

  When such an executable file is loaded into the main memory and activated, a part of the external reference table creation code is executed. Here, it is assumed that the executable file is loaded at address 0 of the main memory. In this case, as shown in Code Example 40, the external reference table in the data section is written at an address (address) having the same value as the offset. In this example, neither the code section nor the data section is changed by loading.

  When the external reference table creation code is executed, the value 4940 is set at address 6108 by executing the code at address 3300, for example. Thereby, the external reference table is completed.

  In the examples of FIGS. 4 and 5, the address of func2 determined at the time of linking is set to the address of the function in the external reference table on the memory by the external reference table creation code. It is just a convenient example for. The external reference table creation code is typically used for an object whose address is dynamically determined at the time of execution.

  The address of the external reference table configured in the main memory in this way (typically the start address) is used as an argument by executing the call code 128 to the microprocessor 300 that executes the original program code after decoding ( (For example, via stack or register). The microprocessor 300 converts the reference to the external object in the original program code into the address of the entry of the object in the external reference table on the main memory using the value of the argument. Then, by accessing the address, the runtime address of the external object is known, and the external object is accessed.

  The computers 200 and 210 used by developers and users may have a general hardware configuration as illustrated in FIG. That is, the computer illustrated in FIG. 6 includes, for example, a microprocessor 300 such as a CPU, a memory (primary storage) such as a random access memory (RAM) 302 and a read only memory (ROM) 304, and an HDD (hard disk drive) controller 308. The HDD 306, various I / O (input / output) interfaces 310, and the like connected via the network have a circuit configuration connected via a bus 314, for example. A network interface 312 for connecting to a network such as a local area network may be connected to the bus 314. In addition, the bus 314 has various standards such as a disk drive 316 for reading from and / or writing to a portable disk recording medium such as a CD and a DVD and a flash memory via the I / O interface 310, for example. A memory reader / writer 318 for reading from and / or writing to the nonvolatile recording medium may be connected. The RAM 302 is used as a main memory of the computer 200 or 210.

  A processing procedure in which the microprocessor 300 executes the loaded executable file 160 will be described with reference to FIGS.

  When the link source code is activated by the user, the executable file 160 is loaded into the memory 400 of the computer 210 (corresponding to the RAM 302 in FIG. 3). FIG. 8 shows a portion derived from the library in the executable image loaded in the memory 400. The link source code in the executable image is executed by the microprocessor 300. Here, the link source code includes a code that calls the library initialization function 122. When the microprocessor 300 executes this code (S10), the initialization function 122 is called. Then, the decoding code 124 and the external reference table creation code 126 are executed by the microprocessor 300. Thereby, the computer 210 functions as the decryption unit 410 and the external reference table creation unit 420.

  The decoding unit 410 decodes the encoded program code 132 of the unique section 130 (S12). Here, since the unique section 130 is a writable and executable section, the decoding unit 410 can write back the decoding result (that is, the original program code) of the code 132 in the section 130 into the section 130.

  Also, the external reference table creation unit 420 acquires the address of each external object that needs to dynamically resolve the address (for example, from the operating system using an API function) and registers it in the external reference table 142. Thereby, the external reference table 142 is completed (S14).

  When the execution of the initialization function 122 is completed, control returns to the link source code side. The microprocessor 300 sequentially executes the instructions in the link source code until the end of the link source code is reached (S16). In this process, when the code executed by the microprocessor 300 reaches the call code 128 (S18), the microprocessor 300 executes the call code 128 (S20). Thereby, the computer 210 functions as the calling unit 430. The calling unit 430 calls a function corresponding to the calling code 128 in the original program code in the unique section 130. At the time of this call, the address of the external reference table 142 is passed as an argument to the original program code side.

  In response to this call, the microprocessor 300 executes the called function in the original program code (S22). By this execution, the computer 210 functions as a function execution unit 440 that provides a function represented by the function. The function execution unit 440 accesses the external object referenced in the called function via the external reference table 142. That is, based on the address (start address) of the external reference table 142 passed as an argument, the address of the entry of the external object in the external reference table 142 is accessed, and the value at the accessed address (that is, the relevant address) The external object is accessed using the external object runtime address).

  When the execution of the called function is completed, the processing is returned to the link source code side. The processes of S18 to S22 are repeated until the end of the link source code is reached (S16).

  The configuration and use of the object file 100 according to this embodiment has been described above. As can be understood from the above description, the original program code of this embodiment does not include a description that directly refers to an external object. Instead, in the original program code, a reference to an external object is described in the form of an indirect reference using an entry in the external reference table 142 passed as an argument (p_table in the above code example) from the calling code 128. . Arguments are not registered in the symbol table generated as a result of compilation nor in relocation information (these are included in the object file 100 and referred to when linking or loading). References through the argument p_table such as p_table-> pHeapAlloc and p_table-> pHeap in the original program code of the section 130 are not registered in the symbol table or the relocation information. Therefore, in the address resolution process when the object file 100 is linked with the link source code, the symbol or address in the unique section 130 is not rewritten. Since the code in the unique section 130 is encoded at the time of linking (encoded program code 132), decoding cannot be performed when a part of the code is rewritten for address resolution. Since the unique section 130 is not rewritten at the time of address resolution, such a problem does not occur. In other words, if the configuration of the object file 100 of this embodiment is used, the encoded program code 132 can be prevented from being destroyed at the time of linking even when a normal compiler and linker are used.

  The point that the unique section 130 is prevented from being rewritten at the time of address resolution at the time of linking is that the entries of the external reference table 142 are statically described (that is, external addresses whose addresses are statically determined). This is true even if it is only for objects.

<Modification 1>
In the above-described embodiment, the configuration in which the initialization function 122 including the decryption code 124 and the external reference table creation code 126 is explicitly called from the link source code has been described, but this is merely an example. Instead of explicitly calling the initialization function 122 from the link source code, the initialization function 122 may be executed when the call code 128 is first called from the link source code. For this purpose, a flag indicating whether the initialization of the library has already been executed or not executed is prepared in the data section 140, for example, and the flag is checked each time the call code 128 is called, and the first call is made. If so, the initialization function 122 may be called. If the flag indicates already executed, the initialization function 122 is not called. In this example, the trouble of the link source code calling the library initialization function 122 is saved.

<Modification 2>
In the above-described embodiment, the external reference table is used for reference from the original program code to the external object. However, the data for external reference does not need to be a table, and information necessary for external reference is the original program. Any method that can be passed to the code can be used. For example, for each external object, external reference information indicating the address of the object in the memory 400 is described or generated in the data section 140, and the external reference information corresponding to the object is referred to a function that refers to the external object. May be passed as an argument. That is, the address information of a plurality of external objects may not be collectively transferred to the original program code in the form of a table, but the address information of each external object may be individually transferred to a function in the original program code. In particular, when the original program code has a plurality of interfaces, the same information (external reference table) is not passed to all interfaces, but the necessary external reference information can be passed for each interface.

<Modification 3>
In the above-described embodiment, the example in which the original program code that is the decoding result of the encoded program code 132 is stored in the unique section 130 has been described, but this is only an example. According to the method of the embodiment, since the original program code accesses an external object through the external reference table, the original program code operates correctly regardless of where the original program code is placed in the memory space of the memory 400. Therefore, as a modified example, the decoding unit 410 realized by executing the decoding code 124 secures a memory area in the memory 400 that can be written, read, and executed in a necessary size. The original program code of the decoding result may be placed on the memory area. In this case, it is necessary to perform address resolution so that the calling code 128 can call the original program code in the secured memory area. In this case, since the decoding unit 410 knows the address of the memory area where the original program code is placed, the address is set to the function in the original program code by using a function pointer for the call code 128 or the like. It is only necessary to realize the address resolution by passing.

<Modification 4>
In the above-described embodiment, the configuration in which the original program code is collectively encoded has been described. However, when the original program code provides a plurality of functions, the original program code may be divided and encoded for each function. Each individual function is provided by one or more functions. In this case, it is necessary for the encoding program and the decoding code 124 (decoding unit 410) to grasp information about where the code is placed in the object file for each code that provides the function. This information can be obtained by using the library label name. For example, consider a case where a plurality of target functions are encoded as a group in the original program code (one or more such clusters exist in the original program code). In this case, from the code position having the function name of the first function in the target function group to be encoded as a symbol as a symbol, the code having the function name immediately after the target function group to be encoded as a symbol It is determined that the code up to just before the position is a group of codes to be encoded (that is, the original program code). If there is only one function to be encoded (that is, the unit of encoding is one function), the code from the beginning of the function to the immediately preceding head of the next function is recognized as one unit of encoding target code. Is done. As another method when using a compiler in which the end position of a function is defined as a symbol, the code position with the function name first placed in the target function (s) to be encoded as a symbol is used as the start position. This is a method of determining that the code position of the end symbol of the last function of the target function (group) to be encoded is the code to be encoded. The order in which functions are placed is generally the order of definitions in the source code. Some compilers can specify the order in which functions are placed from the outside. As a result, the order in which the functions to be encoded are placed can be controlled. In another method, a general linker can output information (referred to as map information) indicating which symbol function is placed at which position of the generated executable file as one of the output information. By referring to this map information, it is possible to know where in the file the code to be encoded has been placed. When encoding is performed in units of functions in this way, it is possible to use such that only codes necessary for execution are decoded.

<Modification 5>
In the above-described embodiment, the original program code once decoded is only executed, but may be encoded again after being executed. If the purpose of encoding is information concealment like encryption, re-encoding in this way can conceal information more firmly by reducing the time that the original program code exists in the memory. I can expect that. For example, the decoding code 126 is executed immediately before calling the calling code 128, and the code for encoding is executed after the execution of the calling code 128 is overwritten to overwrite the original section 130 with the encoding result. That's fine.

  In particular, it can be considered to be combined with Modification 4. In this case, each function may be decoded before the function is executed, encoded again after the function is executed, and the encoded result is overwritten on the original program code.

  100 object file, 110 object header, 120 code section, 122 initialization function, 124 decoding code, 126 external reference table creation code, 128 calling code, 130 original section, 132 encoding program code, 140 data section, 142 external reference table .

Claims (5)

An encoded program code which is an encoding result of the original program code;
Decoding program code for causing the computer to execute a process of decoding the encoded program code and restoring the original program code;
External reference information representing the address of an external object referenced in the original program code;
In response to a call from an external program, a calling program code for causing the computer to execute a process of calling the original program code restored by the decryption program code by passing an address of the external reference information as an argument;
With
The original program code describes a reference to the external object using the address of the external reference information passed as an argument, and the address of the external reference information passed as an argument from the calling program code. Obtaining the address of the external object by accessing, causing the computer to execute a process of referring to the external object using the acquired address;
An object file format program characterized by that. External reference information creation program code for acquiring an address of an external object referred to in the original program code and causing the computer to execute processing for generating information including the acquired address as the external reference information ,
The program according to claim 1, further comprising: The program is
Program code for causing the computer to execute a process of securing a memory area that can be read, written, and executed on the memory of the computer;
Further including
The decryption program code causes the computer to execute a process for writing the original program code as a result of decryption into the secured memory area.
The program according to claim 1. The computer,
Flag storage means for storing a flag indicating whether the decryption program code is already executed or not executed;
When the calling program code is called, if the flag stored in the flag storage means represents unexecuted, the decrypted program code is executed to change the flag to already executed, and the flag is already set. Control means for controlling not to execute the decryption program code when representing execution;
The program according to claim 1, further functioning as: Decoding means for decoding the encoded program code that is the result of encoding the original program code and restoring the original program code;
External reference information storage means for storing external reference information representing an address of an external object referred to in the original program code;
Calling means for calling the original program code restored by the decoding means by passing an address of the external reference information as an argument in response to a call from an external program;
Execution means for executing the original program code called by the calling means;
With
The original program code describes a reference to the external object by using the address of the external reference information passed as an argument, and refers to the external object passed as an argument from the calling unit. , Obtaining the address of the external object by accessing the address of the external reference information, and causing the execution means to execute a process of referring to the external object using the acquired address.
A program execution device.

Images