HK1083653B - System and method of verifying the authenticity of dynamically connectable executable images - Google Patents

Description

System and method for confirming reliability of dynamically connectable executable images

The application is a divisional application of an invention patent application with the application date of 2000, 7, 25 and the application number of 00819775.X, and the invention name of the invention is 'a system and a method for confirming the reliability of a dynamically connectable executable image'.

Technical Field

The present invention relates to computer systems. And more particularly to a system and method for verifying the authenticity of a dynamic, connectable, executable image (image).

Background

Currently, new object models guarantee the dynamic integrity of application software during runtime. For example, Windows, an operating system authorized by Microsoft inc, uses dynamically linked libraries to maintain the integrity of application software during its execution. When a user requests execution of application software, the program loader copies the application's "disk image" from disk storage to main memory to create a "process image". Disk images refer to executable images before loading, and process images refer to executable images after being loaded into memory. Both disk images and process images typically include a fixed-up portion that indicates which portions of the software that require fixing reference a dynamically linked library during runtime.

Notably, after loading, the process image is different from the disk image. Thus, even if the process image has not been improperly tampered with, the checksum made regarding the disk image will no longer match the checksum of the process image.

Thus, there is a need for a system that can determine the identity of application software in a dynamic loading environment. In particular, the system should be able to determine whether application software that is dynamically connected to other data objects has been tampered with after the application software is executed.

Disclosure of Invention

One embodiment of the present invention includes a system for determining the authenticity of an executable image, the system comprising: an executable image having one or more pointers, and a validation program (validator) capable of generating a reference digital signature at a first point in time based on selected contents of the executable image excluding each pointer, wherein the validation program generates a true digital signature at a second point in time based on the selected contents of the executable image excluding each pointer. Wherein the validation program determines whether the reference digital signature matches an authentic digital signature.

Another embodiment of the present invention encompasses a system for determining the authenticity of an executable image, the system comprising: an executable image having one or more pointers, wherein the executable image includes information indicating whether each pointer references a location within the executable image, and a validation program capable of determining whether each pointer references a respective location within the executable image.

Another embodiment of the present invention encompasses a system for determining the authenticity of an executable image, the system comprising: the system includes a first executable image, a second executable image including a pointer referencing a location within the first executable image, and a validation program capable of determining whether the pointer references the location within the first executable image.

Another embodiment of the present invention includes a system capable of validating the authenticity of an executable image, the system comprising: a first executable image loadable into memory; a second executable image loadable into the memory, the second executable image comprising an import table having an identification of the first executable image and one or more external pointers, each external pointer referencing a location within the first executable image, and a code section containing machine code and one or more import pointers, each import pointer referencing a location within the import table; and a computer including a validation program capable of generating a reference digital signature at a first point in time from selected content of the executable image, wherein the selected content excludes each of the import pointers and the external pointers, wherein the validation program generates a true digital signature at a second point in time from the selected content of the executable image excluding each of the one or more pointers, wherein the validation program determines whether the reference digital signature matches the true digital signature, and wherein the validation program determines whether a location pointed to by each of the import pointers is within the first executable image.

Drawings

FIG. 1 is a general block diagram of a computer for receiving executable images from one or more sources that represents the present invention.

FIG. 2 is a block diagram illustrating a validation process capable of determining the authenticity of one or more executable images located on the computer of FIG. 1.

FIG. 3 is a block diagram illustrating the internal structure of the executable image of FIG. 2.

FIG. 4 is a block diagram showing the two executable images of FIG. 2 being joined after a loading process.

FIG. 5 is a flow chart illustrating a process performed by the validation program of FIG. 2 during a reliability check of an executable image such as that shown in FIG. 2.

FIG. 6 is a flow chart illustrating another process performed by the validation program of FIG. 2 during a reliability check of an executable image such as that shown in FIG. 2.

Detailed Description

The following detailed description is directed to certain specific embodiments of the invention. The invention may, however, be embodied in many different forms as defined and covered by the claims.

Overview of the system

Fig. 1 is a general block diagram illustrating a computer 90. The computer 90 initiates a reliability check of one or more executable images executing on the computer 90.

Computer 90 uses a conventional general purpose single-chip or multi-chip microprocessor, such asA processor,Pro processor, 8051 processor,Processor, PowerProcessor, orProcessors, and thus, the computer 90 may employ a conventional, dedicated microprocessor, such as a digital signal processor or image processor.

The computer 90 includes an operating system 95 and memory 108. The operating system may be provided by any operating system vendor, which may include: UNIX, LINUX, DOS, OS/2, Windows 3.x, Windows95, Windows 98, and Windows NT. For convenience of description, Windows95 will be used in the following embodiments of the present invention.

The computer 90 is connected to one or more executable image sources 107 that provide executable images 100 to the computer 90, as shown in FIG. 1, typical executable image providers include: server 110, internet 114, database 118, network 122, hardware device 126, and/or mobile storage device 130.

Executable image 100 is a data object that may be defined by itself or with other executable images, one or more application software. The application software may include, for example: word processors, databases, digital property management systems, personal financial tools, graphical tools, internet browsers, computer games, communication programs, rights programs, electronic wallets, multimedia players, or contract management. Moreover, executable image 100 is dynamically connectable to other executable images. For example, embodiments of the present invention were developed in the Windows95 environment, and the executable image is a Dynamic Link Library (DLL).

The internet 114 includes different network types, such as public internet, private network, public network, value-added network, intranet, and the like.

Network 122 may comprise any type of electrically connected group of computers, including: for example, the following networks: an intranet, a Local Area Network (LAN), and a Wide Area Network (WAN). Also, the connection to the network may be, for example, a remote modem, an ethernet (IEEE 802.3), a token ring network (IEEE802.5), a Fiber Distributed Data Interface (FDDI), or an Asynchronous Transfer Mode (ATM). It is noted that the computing device may be a desktop, server, portable, handheld, set-top, or other desired type of configuration. The hardware device 126 may be a logic chip, ROM, RAM, smart card, or central processing unit. Removable media storage 130 may be a floppy disk, a compact disk, hard disk, tape drive, ROM, or other persistent storage medium.

FIG. 2 is a block diagram illustrating the validation process 204. In one embodiment of the invention, validation program 204 is an executable image, in the same format as executable image 100. In another embodiment of the invention, validation program 204 is integrated with executable image 100. In another embodiment of the present invention, validation program 204 is integrated with program loader 208. One function of program loader 208 is to copy executable image 100 from storage device 105 (FIG. 1) to memory 108 and bind code and data pointers to the appropriate addresses before executing executable image 100. For ease of description, the following description assumes that validation program 204 is a separate program distinct from the executable image 100 and program loader 208 areas.

Validation program 204 validates the authenticity of executable image 100 under selected conditions as described in further detail below. It will be accepted by those skilled in the art that validation program 204 and program loader 208 comprise different subroutines, procedures, definition declarations, and macros, which are typically compiled separately and linked to a single executable program. Thus, the following description may be used to advantage to describe the functionality of these objects.

Validation program 204 and program loader 208 (FIG. 1) may be written in any programming language, such as C, C + +, BASIC, Pascal, Java, and FORTRAN. C. C + +, BASIC, Pascal, Java, and FORTRAN are industry standard programming languages, and for each language, there are many commercial versions of compilers and interpreters that can be used to create executable code.

FIG. 2 depicts executable image 100 after being connected to executable image 200. It should be noted that executable image 200 may include the same types of data objects as described above in connection with executable image 100. One function of validation program 204 is to validate the authenticity of executable images, such as executable image 100 and executable image 200, after they are loaded into memory 108.

The process for confirming the authenticity of an executable image will be described in detail below with reference to fig. 5 and 6. Briefly, however, validation program 204 analyzes executable image 100 and generates a reference digital signature associated with executable image 100 before executable image 100 is loaded into memory 108. After executable image 100 is loaded, validation program 204 generates a true digital signature to ensure that executable image 100 has not been tampered with. Moreover, validation program 204 checks the binding between executable image 100 and executable image 200 to ensure that the binding between executable image 100 is not incorrectly redirected to the other executable image.

FIG. 3 is a block diagram detailing the internal structure of an embodiment of the executable image 100, wherein the executable image is created as a dynamically linked library and stored in the storage unit 105 (FIG. 1).

Executable image 100 includes a number of sections, such as header section 300, code section 304, data section 308, import table 312, relocation table 316, and export table 320. It should be noted that executable image 100 includes a number of pointers, which will be described in further detail below. In general, however, a pointer is a reference value that identifies a relative address location in memory 108 with respect to an absolute address or other location of memory 108 (FIG. 1).

Header section 300 identifies the relative locations of other sections and/or tables in executable image 100. Code segment 304 comprises compiled machine code that can execute image 100. For example, code segment 304 comprises machine instructions for computer 90 (FIG. 1). As shown in FIG. 3, code segment 304 includes instructions that reference other segments that may or may not be internal to executable image 100. As shown at block 320, code segment 304 includes instructions for assigning a global variable "i" to a value of "2," however, since executable image 100 is not already loaded into memory 108, such as stored in memory device 105, the actual address of variable "i" is not defined in memory 108. Furthermore, code segment 304 includes an instruction to call the function foo (), and a call to the procedure foo () includes an import pointer that references a location in import table 312.

Data section 308 is used to store all global variables identified in code section 304. Import table 312 includes various data items (items) of information to help program loader 208 connect executable image 100 with other executable images. The import table 312 includes: identifiers such as the name of each process maintained by the other executable image, the name of the executable image, and one or more external pointers to addresses of externally maintained processes. Import table 312, as stored by storage device 105 (fig. 1), does not reference the memory address of process foo ().

Relocation table 316, when executable image 100 is loaded, identifies the location of each segment of code segment 304 that needs to be patched. The term fixing-up is used herein to denote the process of modifying an executable image in memory so that any unanalyzed pointers reference appropriate data and/or code locations. After the pointer is fixed by the program loader 208, it is said to bind an optional address.

Export table 320 specifies each process that may be publicly used by executable image 100. It should be noted that executable image 100 may include other information, such as debug information or other tables to facilitate the loading and/or connection process.

When executable image 100 is stored in storage device 105, validation program 204 (FIG. 2) determines the reference digital signature associated with it. The process for generating a digital signature will be described in detail with reference to fig. 6. In one embodiment of the invention, validation program 204 determines a reference digital signature for the entire executable image that removes the pointers that need to be fixed by program loader 208 (FIG. 2). In another embodiment of the invention, validation program 204 determines a reference digital signature for selected segments, such as code segment 304 and/or import table 312 of executable image 100, that removes addresses that need to be patched by program loader 208.

FIG. 4 is a block diagram depicting executable image 100 after executable image 100 has been patched in connection with executable image 200. from FIG. 4, it can be seen that the data pointer for variable "i" is bound to an address of data segment 308 in accordance with the modification information contained in relocation table 316. Further, the external pointer in the import table 312 is bound to the export table in the executable image 200. The external pointer at the reference address in the export table of the second executable image 200 is bound to the actual location of the procedure foo () in the executable image 200.

After patching, validation program 204 (FIG. 2) performs various reliability checks related to executable image 100. Each reliability check will be described in detail with reference to fig. 5 and 6, however, in short, the validation program 204 performs the functions described below.

First, validation program 204 determines the true digital signature for the same address that was used to generate the reference digital signature. If the true digital signature is different from the reference digital signature, validation program 204 (FIG. 2) assumes that executable image 100 has been tampered with.

Second, validation program 204 checks each binding in import table 312 to ensure that the address referenced by the import table has not been tampered with. If the import table 312 is incorrectly modified, the procedure call to the selected function may be redirected to an unreliable program other than the one intended by the provider of the executable image 100, such an unreliable program randomly or intentionally returning errors or other harmful data to the executable image.

Fig. 5 is a flowchart describing a process for confirming the authenticity of the executable image 100. Beginning at state 600, validation program 204 (FIG. 2) receives a request to validate the authenticity of executable image 100 (FIG. 1). In one embodiment of the invention, the request is generated by the program loader 208. In another embodiment of the present invention, the request is generated by operating system 95 (FIG. 1), in yet another embodiment of the present invention, the request is generated by an executable image (not shown) executing on computer 90 (FIG. 1), and in yet another embodiment of the present invention, the request is generated by a program in validation program 204.

Continuing to state 604, validation program 204 (FIG. 2) identifies each pointer in executable image 100 that needs to be patched. In one embodiment of the invention, if only the reliability of the selected segment is determined in executable image 100, validation program 204 only identifies the pointers that fall within the selected segment in executable image 100. For example, validation program 204 may be configured to identify only those pointers that fall within code segment 304 or import table 312 (FIG. 3).

In one embodiment of the invention, validation program 204 analyzes relocation table 316 to identify each of these pointers (FIG. 3). As described above with reference to FIG. 3, relocation table 316 identifies a location of an address relative to a base address of executable image 100. By examining relocation table 316, validation program 204 can identify the portion of code segment 304 that was modified by program loader 208 during the loading process.

Continuing to state 608, validation program 204 (FIG. 2) generates a reference digital signature of executable image 100. A digital signature, as used herein, is defined to include any method for identifying the content of the selected group of data. In its simplest form, the digital signature may comprise a complete copy of the selected set of data to be marked. However, the digital signature may also include the result of applying a hash function to the selected group of data. Further, the digital signature may be a digital certificate (certificate). It is accepted by those skilled in the art that any one of a number of standard hash functions may be used to generate the reference digital signature.

Referring to state 608 in one embodiment of the invention, the validation program determines the reference digital signature based on the contents of the entire executable image 100, excluding addresses that require fixing by program loader 208 (FIG. 2). In another embodiment of the invention, validation program 204 determines the reference digital signature based on the selected segments, e.g., the contents of code segment 304 and/or import table 312, excluding addresses that need to be fixed by program loader 208.

Advancing to state 612, validation program 204 (FIG. 2) stores the reference digital signature for later retrieval. In an embodiment of the present invention, validation program 204 stores the reference digital signature in storage device 105. In another embodiment of the invention, validation program 204 stores a reference digital signature in a selected segment of executable image 100, such as a resource table (not shown). In yet another embodiment of the present invention, the reference digital signature is preceded by an executable image 100, and in yet another embodiment of the present invention, the digital signature is stored in a database, a web server, or on the network 122 (FIG. 1). In yet another embodiment of the present invention, the reference digital signature is created before executable image 100 is provided to computer 90. In this embodiment, the reference digital signature may be generated in any of the ways described above.

Next, at state 614, validation program 204 (FIG. 2) determines the true signature of the executable image 100 before or after loading of the executable image into memory 108 (FIG. 2) by the program loader. At this step, validation program 204 again uses the hash function employed by validation program 204 in state 608. Validation program 204 may be configured to determine a true digital signature based on the occurrence of a selected one or more conditions, such as, for example, a timeout of a timer, a self-test of the reliability of the executable image, an idle time of computer 90 (FIG. 1), or a request from the executable image.

Continuing to decision state 618, validation program 204 (FIG. 2) determines whether the reference digital signature (generated at state 608) matches the authentic digital signature (generated at state 614). If the reference digital signature does not match the authentic digital signature, validation program 204 proceeds to state 622 where validation program 204 initiates a security alarm. At state 622, validation program 204 may perform a number of functions, such as: unloading executable image 100, loading a new copy of executable image 100 from memory 105 (FIG. 1) into memory 108 (FIG. 1), loading a new version of executable image 100 from network 122, removing executable image 100 from memory 105, displaying an alert to a user at computer 90 (FIG. 1), sending an error message to a remote computer (not shown) over network 122, or canceling one or more actions performed by executable image 100.

Referring again to decision state 618, if validation program 204 (FIG. 2) determines that the reference digital signature matches the authentic digital signature, validation program 204 proceeds to end state 624. According to an embodiment, the validation process (FIG. 2) may return to state 614 to re-determine the true digital signature based on the occurrence of the selection condition.

FIG. 6 is a flow chart describing another process performed by the validation program of FIG. 2 during a reliability check of the executable image as shown in FIG. 2. The process performed by fig. 6, unlike the process performed by fig. 5, may be performed independently or in conjunction with the process performed by fig. 5. In particular, FIG. 6 describes a process for determining each pointer in an executable image bound to a correct location. The following text describes the reliability checking process associated with the import pointer in the code segment 304 of the executable image 100 and the export pointer in the import table 312. However, it is acceptable to those skilled in the art that the same process can be used for other types of pointers in executable images.

Beginning at state 700, validation program 204 (FIG. 2) receives a request from a requestor to validate the authenticity of executable image 100 (FIG. 1). In an embodiment of the present invention, the requestor is program loader 208 (FIG. 2). In another embodiment of the present invention, the requestor is operating system 95 (FIG. 1). In yet another embodiment of the invention, the requestor is an executable image (not shown) executing on computer 90 (FIG. 1). In yet another embodiment of the present invention, the requestor is a subroutine in the validation process 204. Further, the requestor may initiate the request upon occurrence of one or more selected conditions, wherein the conditions include: expiration of a timer, detection of idle time with respect to the computer 90 (fig. 1), and/or prior to a critical operation, such as a banking transaction.

Continuing to state 704, validation program 204 (FIG. 2) identifies each import pointer in code section 304. In one embodiment of the invention, validation program 204 analyzes relocation table 316 to determine each import pointer (FIG. 3).

Next, at state 708, validation program 204 (FIG. 2) checks each import pointer in code section 320 to determine whether each import pointer is bound to a location in import table 312. In this state, in one embodiment of the invention, validation program 204 reads head 300 and determines the start and end addresses of import table 312.

If each import pointer is not bound to a location in import table 312 (FIG. 3), validation program 204 (FIG. 2) proceeds to state 714 where validation program 204 initiates a security alarm. At state 714, validation program 204 may perform a number of functions, such as: unloading executable image 100, loading a new copy of executable image 100 from memory 105 (FIG. 1) into memory 108 (FIG. 1), loading a new copy of executable image, deleting executable image 100 from memory 105, displaying an alert message to a user at computer 90 (FIG. 1), sending an error message to a remote computer (not shown) over network 122, or canceling one or more actions performed by executable image 100. Process flow advances to end state 715 where the process ends.

Referring back to decision state 712, if validation program 204 (FIG. 2) determines that each of the import pointers in code segment 304 are bound to import table 312 (FIG. 3), validation program 204 proceeds to state 716 where validation program 204 identifies each of the external pointers in import table 312 at state 716.

Proceeding to state 720, validation program 204 (FIG. 2) determines the location of the binding of the external pointer in import table 312 (FIG. 2). In another embodiment of the invention, validation program 204 stores the location of the binding in an external pointer table (not shown) maintained by validation program 204.

Continuing to decision state 722, validation program 204 determines whether the location of the binding of the external pointer is within an executable image identified by import table 312 (FIG. 2). For ease of description, the executable image identified by the import table 312 is referred to as an export executable image.

In one embodiment of the invention, validation program 204 invokes operating system 95 (FIG. 1) to determine the location of the exported executable image in memory 108 (FIG. 1). For example, Windows95 provides a procedure call named "GetModuleHandle ()" which returns the base address of the executable image that gives the name of the executable image. Using the base address, validation program 204 is able to identify the header and derive the location of other segments of the executable image.

Still referring to state 722, if validation program 204 determines that each external pointer is not bound to a derived executable image, validation program 204 proceeds to state 714, which is described in detail above. However, if validation program 204 determines that each external pointer is bound to a derived executable image, validation program 204 proceeds to end state 715 and ends.

Advantageously, the present invention allows for the validation of the authenticity of an executable image, static, dynamic, and during runtime, without requiring modification of the source or object code of the executable image. The invention ensures that an executable image is authentic and has not been tampered with after it has been loaded. After the reference digital signature is determined, validation program 204 can then generate a true digital signature to ensure that the data object has not been modified. Moreover, validation program 204 can determine whether each pointer in the executable image is bound to the correct location.

For example, for the data pointer of code segment 304, validation program 204 may check relocation table 316 to ensure that the data pointer references a location in data segment 308. Also, for example, with respect to the external pointer of the import table 312, the validation program 204 can determine that the external pointer references a reliable executable image, wherein its name is contained in the import table 312. Since the name of the executable image has not been modified by program loader 208 (FIG. 2), validation program 204 may ensure that the name of the authentic executable image has not been modified by using the reference digital signature and the true digital signature.

While various embodiments have been shown, described, and pointed out novel and innovative features of the present invention in various detail, it will be understood by those skilled in the art that various omissions, substitutions, and changes in the form and details of the processes and devices described may be made without departing from the spirit of the invention. The scope of the invention is indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims (15)

1. A system for determining the authenticity of an executable image, the system comprising:

an executable image having one or more pointers that need to be patched by the program loader, wherein the executable image has information indicating whether each pointer references a location within the executable image; and

a computer including a validation program capable of determining whether the respective location referenced by each of said pointers is within an executable image, thereby determining the authenticity of said executable image.

2. The system of claim 1, wherein the pointer references an import table in the executable image.

3. The system of claim 1, wherein the validation program generates the alert based on a determination that the pointer does not reference a location within the executable image.

4. The system of claim 1, wherein the validation program generates an alert to a source of the executable image based on a determination that the pointer does not reference a location within the executable image.

5. A system for determining the authenticity of an executable image, the system comprising:

a first executable image;

a second executable image having a pointer to be patched by the program loader, wherein the pointer references a location within the first executable image; and

a computer including a validation program capable of determining whether a pointer references a location within a first executable image, thereby determining the authenticity of the second executable image.

6. The system of claim 5, wherein the validation program generates the alert based on a determination that the pointer does not reference a location within the first executable image.

7. The system of claim 5, wherein the validation program generates an alert to a provider of the executable image based on a determination that the pointer does not reference a location within the first executable image.

8. The system of claim 5, wherein the validation program determines whether the pointer references a location within the first executable image by:

requesting a base address of a first executable image from an operating system;

reading a predefined header at a start location of the first executable image, the header indicating start and end addresses of the first executable image; and

it is determined whether the pointer references a location within the first executable image as indicated by the predefined header.

9. A system for determining the authenticity of an executable image, the system comprising:

a first executable image loadable into memory;

a second executable image loadable to the memory, the second executable image comprising:

an import table having an identification of the first executable image and one or more external pointers, wherein each external pointer references a location within the first executable image; and

a code segment comprising machine code and one or more import pointers, each import pointer referencing a location in an import table; and

a computer containing a validation program capable of generating a reference digital signature at a first point in time from selected content of the executable image excluding each of the import pointers and the external pointers, wherein the validation program generates a true digital signature from selected content of the executable image excluding each of the one or more pointers, wherein the validation program determines whether the reference digital signature matches the true digital signature, and wherein the validation program determines whether each import pointer references a location within the first executable image, thereby determining the authenticity of the executable image.

10. A method for determining the authenticity of an executable image, the method comprising:

identifying one or more locations of the executable image that have been loaded into memory, each identified location having a pointer to a selected address in memory to be patched by the program loader; and

determining whether each pointer at the identified location references a destination address indicated by the executable image, thereby determining the authenticity of the executable image.

11. The method of claim 10, wherein the destination address is an address that can be located in an import table of the executable image.

12. The method of claim 10, wherein the destination address is an address in another executable image.

13. A system for determining the authenticity of an executable image, the system comprising:

means for identifying one or more locations of the executable image that have been loaded into memory, each identified location having a pointer to a selected address in memory to be patched bound by the program loader; and

for determining whether each pointer at the identified location references a destination address indicated by the executable image, thereby determining the authenticity of the executable image.

14. The system of claim 13, wherein the destination address is an address that can be located in a import table of the executable image.

15. The system of claim 13, wherein the destination address is an address in the other executable image.