JP2011170847A - Method and apparatus for verifying integrity of software during execution and apparatus for generating such software - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To ensure the integrity of software code that is a self-modifying type. <P>SOLUTION: In order to verify the integrity of software code, for various states of the code, a checksum, (e.g. a hash value), is generated for at least a part of the code. During execution, the state of the code is changed (320), a module is modified (330), and an integrity check is performed (340) using the checksum for the state of the code. The checksum may be stored in a look-up table or it may be embedded in an integrity verification function. A state variable indicating the state of the modules may be used to look up the checksum included in the table. Possible states of a module are encrypted and not-encrypted states. <P>COPYRIGHT: (C)2011,JPO&INPIT

Description

  The present invention relates generally to software, and particularly to ensuring software integrity.

  This section is intended to introduce the reader to various aspects of the technology related to various aspects of the present invention described and / or claimed below. This discussion is believed to help provide readers with background information to help a better understanding of the various aspects of the present invention. Thus, of course, these descriptions should be read in this light and not as an admission of the prior art.

  It is relatively common for software providers to protect the integrity of a computer program in order to ensure that the program executes as intended. However, hackers usually try to break into programs to be executed in various ways. As an example, hackers sometimes want to rewrite code to avoid the program's access control functions so that the program can be used without having the necessary access rights.

  A prior art method of ensuring program integrity is to calculate a signature (also referred to as a “checksum”) for at least some parts of the code. For example, the signature may be a hash value calculated for a portion of code and signed with a private key. There are many other possibilities, as will be appreciated by those skilled in the art. During program execution, the code signature is calculated at least once. To increase the level of security, functions that calculate signatures are nested so that the integrity of each function is verified by at least one other function. In this way, if only one function remains intact, it detects tampering with at least one other function. Further details and explanation can be found, for example, in US Patent Application Publication No. 2003/188231 (Patent Document 1) and European Patent No. 1942431 (Patent Document 2). No. 138748 teaches how integrity should be determined for relocatable code. A similar solution is described in D.A. Auxmith, Tamper Resist Software: An Implementation Processes of the International Workshop on Information Hiding (Non-Patent Document 1). In this document, the encrypted integrity function is decrypted and used to verify the integrity of a special unencrypted module.

  As expected, ways to address such protection have been found by scholarly interest rather than hackers (see, eg, Glen Wurster et al., “A Generic Attack on Checking Based on Software Tamper Resistance”, SP'05. : Proceeding of the 2005 IEEE Symposium on Security and Privacy, pages 127-138, Washington, DC, 2005, IEEE Computer Society (Non-patent Document 2)). Such a method uses two copies of the code. One copy has not changed and the other copy has changed. A copy of the code that has been changed is executed, and when a checksum is needed, this is calculated using a copy of the code that has not changed. In this way, the method can change the code and at the same time provide a correct checksum, i.e. a checksum corresponding to the code that has not been changed. It should be recognized that attacks cannot be performed on any kind of processor.

  A countermeasure proposed in Non-Patent Document 2 is to change the access right source for a page including a code. If the right to read the code is also released for the code itself, this causes an interrupt (if the code tries to read itself) that is connected to provide the code that has not changed.

  Another problem is that the checksum according to the prior art does not fit into a self-modifying code. This is because a particular checksum is only valid for one version of the code, i.e. before or after the change.

US Patent Application Publication No. 2003/188231 European Patent No. 1942431 US Patent Application Publication No. 2002/138748

D. Auxmith, Tamper Resistant Software: An Implementation Processes of the International Works on Information Hiding Glen Wurster et al., “A Generic Attack on Checking Based on Software Tamper Resistance, SP’05: Proceeding of the 2005 E1, United States, Sci.

  Therefore, there is a need for an improved solution for ensuring the integrity of software, particularly code that is self-writing. The present invention provides such a solution.

  In a first aspect, the present invention is directed to a method for verifying the integrity of self-rewriting software code during its execution. The software code has a plurality of modules, and each module can be in at least two possible states during execution of the software code: an encrypted state and an unencrypted state. The processor executing the software code changes the software code by changing one of the plurality of modules from the first state to the second state, the checksum and the changed software for the changed software code Verify the integrity of the software code by comparing the code.

  In the first preferred embodiment, the checksum is a hash value.

  In a second preferred embodiment, the checksum is embedded in a function that verifies the integrity of the module.

  In a third preferred embodiment, the checksum is included in the lookup table. Advantageously, the function that verifies the integrity of the modified software code uses a state variable that indicates the state of each of the plurality of modules to access the checksum contained in the lookup table.

  In a second aspect, the present invention is directed to an apparatus for verifying the integrity of self-modifying software code during its execution. The software code has a plurality of modules, and each module can be in at least two possible states during execution of the software code: an encrypted state and an unencrypted state. The apparatus executes the software code, thereby changing the software code by changing one of the plurality of modules from the first state to the second state, and checksumming the changed software code. And a processor configured to verify the integrity of the software code by comparing the modified software code.

  In the first preferred embodiment, the checksum is a hash value.

  In a second preferred embodiment, the checksum is embedded in a function that verifies the integrity of the module.

  In a third preferred embodiment, the checksum is included in the lookup table. Advantageously, the function that verifies the integrity of the modified software code uses a state variable that indicates the state of each of the plurality of modules to access the checksum contained in the lookup table.

  In a third aspect, the present invention is directed to an apparatus for generating an integrity-protected self-rewriting binary. A binary has multiple modules, and each module can be in at least two possible states during execution of the software code: an encrypted state and an unencrypted state. The apparatus includes a processor that receives the binary, generates a binary checksum in each of its possible states, and inserts at least one checksum verification function and the generated checksum into the binary. By doing so, the integrity is configured to generate a protected binary. Each checksum function is configured to verify the integrity of each state of the protected binary by comparing the binary state with the checksum for the binary state.

  In a first preferred embodiment, the processor further inserts a plurality of checksum verification functions in a nested manner so that during execution, the integrity of each checksum verification function is at least one other checksum verification function. Configured to be ascertained by.

  In a fourth aspect, the present invention stores a self-rewritable integrity-protected binary and executes the method steps according to the first aspect of the present invention when executed by a processor. Target the program.

  In a fifth aspect, the present invention, when executed by a processor, generates a checksum for each binary state having a plurality of modules, each module being in at least two possible states during execution of the binary. The possible states are an encrypted state and an unencrypted state, and by inserting at least one checksum verification function and the generated checksum into the binary, integrity is improved. Generate a protected binary and each checksum function is configured to verify the integrity of each state of the protected binary by comparing the state of the binary with a checksum for the state of the binary. For computer programs that store instructions That.

  Embodiments of the present invention provide an improved solution for ensuring the integrity of software, particularly code that is self-writing.

Fig. 4 represents an example of a computing device in which the present invention is implemented. FIG. 4 is a state diagram illustrating a preferred embodiment of the present invention. 2 illustrates a method for integrity verification according to a preferred embodiment of the present invention. Represents binary protection. An example state transition diagram is shown.

  Preferred features of the invention will now be described by way of non-limiting example with reference to the accompanying drawings.

  FIG. 1 represents an example of a computing device (computer) 100 in which the present invention is implemented. The computer 100 may be any type of computer or device capable of performing calculations, such as a standard personal computer (PC). The computer 100 comprises at least one processor 110, a RAM memory 120, a user interface (UI) 130 for interacting with a user, and a second interface (I / O) for reading a software program from the digital data carrier 150. 140. As will be apparent to those skilled in the art, the computer shown is simplified for clarity, and the actual computer further has functions such as network connectivity and persistent storage devices.

  The main inventive concept of the present invention is the use of a finite state machine during execution of the program, where each state corresponds to a state of the protected program code. When transitioning from one state to another, at least one module of code is dynamically changed. Finite state machines are themselves well known in the art and will not be described in detail. Non-limiting examples of modules are code subsections, code chunks, and functions. In order to protect against tampering, a checksum can be calculated for each state, which prevents the code from being tampered with.

  FIG. 2 is a state diagram illustrating a preferred embodiment of the present invention. For clarity of explanation, the example state diagram includes only three states (S1, S2, and S3), each state is associated with a checksum, and the code is divided into three modules (M1, M2, and Only have M3). As will be apparent to those skilled in the art, the present invention applies equally to more (or fewer) states and modules, and corresponding different state transitions are possible.

  In the example, the initial state is S1. In this state, all modules of the code are in their initial state, and the state is associated with the first checksum, i.e. checksum V1. This first checksum enables integrity verification of at least one module.

  If execution causes a shift from state S1 to state S2, the first module M1 is changed and a changed module M'1 is generated. Preferably, the checksum is verified at this point (using checksum V2), but the verification may be performed at a later stage that can be applied to each state transition.

  Similarly, if the execution causes a shift from state S2 to state S3, the second module M2 is changed and a changed module M'2 is generated. The modified module M'1 returns to its unmodified form M1, so that the code has three modules M1, M'2 and M3. As previously described, the checksum is preferably verified at this point (using checksum V3).

  When the state S3 is changed to the state S2, and further from the state S2 to the state S1, the change is performed in the reverse direction. For example, when proceeding from state S2 to state S1, the changed module M′1 returns to its unmodified form M1. Also in such a case, the checksum is preferably verified after the transition (using the associated checksum).

  FIG. 3 represents a method for integrity verification according to a preferred embodiment of the present invention. The method can begin with normal program execution (step 310). At some point, it is determined to change the state (step 320). At least one module is changed (step 330) and integrity is checked (step 340). Thereafter, normal program execution returns at step 310.

  The module may be changed, for example, by decrypting the module (in which case a decryption key is required) or by changing some bytes of the module (eg, by substitution). In the former case, the code is encrypted to return to its original state (a symmetric encryption algorithm requires the same encryption key as the decryption key). In the latter case, the bytes are returned to the original configuration, eg, by backwards permutation.

  FIG. 4 represents binary 410 protection. The protection engine 420 functions to enumerate the possible states and their respective checksum values. These checksum values are inserted into the protected binary 430 along with some reference that allows identification. The protection engine 420 may be any type of suitable computer device such as a personal PC. It preferably includes a processor, memory, etc. (not shown). The computer program product 415 is a CD-ROM or USB memory, for example, and stores instructions that protect the binary as described herein when executed by a processor.

  To protect the binary 410, the protection engine 420 parses the binary 410 and calculates possible states. For this purpose, the protection engine 420 advantageously uses call graph analysis and state analysis. When a state is generated, the protection engine 420 calculates a checksum for that state.

  The protection engine 420 then checks at least one checksum invocation point 432 and a checksum table (which may have a single value) 434, one for each state for which the checksum is verified. Generate a protected binary 430 with Preferably, the checksum is a type of identifier that allows easy access (eg, state 1, state 2..., Or “encrypted module 1, decrypted module 2, encrypted Display along the line of the module 3 ″ made). Desirably, the checksum table 434 takes the form of a hash value for at least a portion of the protected binary, although other checksums may be envisioned (eg, the number of specific characters in a range of binaries). The checksum is protected, for example by encryption, but it is preferable to nest the checksum verification function as described above so that the integrity of each function is verified by at least one other function Is done.

  Note that it is possible to do without the checksum table 434 if the state checksum is determined deterministically from the previous state checksum. The checksum may also be obfuscated in the protected binary or stored in a separate file.

  Then consider the following non-limiting example. For ease of description and understanding thereof, an example is given when a single code region (referred to as a “checksum range”) is preferably protected by checksum verification that occurs at multiple verification points during program execution. Limited. As will be apparent to those skilled in the art, the present invention can be easily extended to multiple checksum ranges. The example is further limited to the specific case where the module corresponds to a function that can be in two different states: an encrypted state and a decrypted state.

  In this way, there is a unique state transition in the code, and each state is preferably verified at at least one matching point in the protected binary.

  In the example, if each function is in one of two possible states (encrypted state and decrypted state), the state is set as state bit Si in state variable S (preferably a bitstream). Can be represented. The state variable S can represent an impossible value depending on the function call graph of the application. As such, only a subset of possible values of the state variable S may be valid for the application. Each value of the state variable S corresponds to a checksum value calculated by the protection engine, and these checksum values are embedded in the protected binary (preferably as a hash value). The hash checksum may then be examined using the state variable S as an identifier.

  Whenever a function is encrypted or decrypted, ie when the state changes, the state variable S is updated by flipping the appropriate state bit Si.

FIG. 5 represents an example state transition diagram with two functions F1, F2 associated with state bits S1, S2, respectively. Each function may be encrypted (represented by S1, S2) and decrypted, resulting in four different states.

S0: F1 and F2 are encrypted-(S1S2)
S1: F1 is encrypted, F2 is decrypted-(S1 S2 )
S2: F1 is decryption, F2 is encryption-( S1 S2)
S3: F1 and F2 are decrypted-( S1S2 )

Initially, the program executes the main function 510. At this time, the state S is S0 = S1S2. The main function can call functions F1 and F2. When the function F1 is called, the encrypted F1 is decrypted (520). Thereafter, execution 530 of F1 begins. At this time, the state S is S2 = S1 S2. Similarly, when the function F2 is called, the encrypted F2 is decrypted (550) and S2 is inverted. Thereafter, execution of F2 (560) begins. At this time, the state S is S1 = S1 S2 .

  There are two possibilities for the function F1 (530). The execution of F1 ends and F1 calls F2. In the first case, F1 is encrypted (540), S1 is inverted, and execution returns to the main function 510. Then, the state returns to S0 = S1S2.

In the second case, F2 is decoded (550), status bit S2 is inverted, and execution of F2 560 begins. However, in contrast to the case where the main function 510 calls F2 directly, F1 is also decoded. This means that the state is S3 = S1S2 . Thus, during execution of F2, the state is either S1 or S3.

Thus, when execution of F2 ends, F2 is encrypted (570), status bit S2 is inverted, and execution returns to the function call. If the function to call is the main function, the main function 510 takes over execution. At this time, the state is S0 = S1S2. On the other hand, if the function to call is F1, execution 530 of F1 resumes. At this time, the state is S2 = S1 S2.

  In FIG. 5, the checksum call point is omitted for ease of understanding, but of course each function (main function, F1, F2) preferably has a checksum associated with the state. It has at least one checksum call point to verify (possibly as part of an encryption / decryption function).

  The simplest implementation of a checksum call point is that the program reads the current state S, finds the corresponding checksum value in the checksum table, and generates a checksum that is to be checked against the stored checksum value. It is to be. If the verification is unsuccessful, execution is preferably aborted.

  As will be apparent to those skilled in the art, the attacker attempts to tamper with the checksum value. For this reason, it is preferable to protect the checksum table in the same way as calling functions that include other checksums, so that they are verified.

Whenever possible, it is possible to increase the level of security by inlining the checksum value in the call point code. In this case, the protection engine advantageously analyzes the call graph to distinguish between the following three cases:

1. If a protected function is entered, the state is unique. That is, a single execution path leads to the function. In this case, the checksum value is unique and the call point code may comprise a code that embeds the checksum value (preferably in an obfuscated manner). For example,
if (checksum_value equals checksum_ref) then (do_something)

2. When a function to be protected is input, there are a few (less than 5) possible states. In this case also, it is possible to embed a checksum value in the call point code. For example,
if (S equals S1 and checksum_value equals checksum_S1) or
if (S equals S2 and checksum_value equals checksum_S2)
then (do_something)

3. If there are many possible states, a checksum table is a desirable solution. For example,
if (checksum_value equals LookupInChecksumTable (S)) then (do_something)

In the specification, a module has been described as having two possible states (eg, encryption and decryption). As will be apparent to those skilled in the art, a module can have multiple (particularly more than two) states.

  It will be appreciated that the present invention can provide a method for verifying the integrity of multi-state software code that can overcome the above attacks.

  Each feature disclosed in the description and (where appropriate) the claims and drawings may be provided independently or in any appropriate combination. Features described as being implemented in hardware may also be implemented in software and vice versa. Reference numerals appearing in the claims are by way of illustration only and shall have no limiting effect on the scope of the claims.

100 Computer 110 Processor 120 RAM Memory 130 User Interface (UI)
140 Second interface (I / O)
150 Digital data carrier 150
410 Binary 415 Computer Program Product 420 Protection Engine 420
430 Protected binary 430
432 Checksum call point 434 Checksum table F1, F2 Functions M1-M3, M'1-M'3 Modules S0-S3 Status V1-V3 Checksum

Claims (14)

A method to verify the integrity of self-modifying software code during its execution,
The software code has a plurality of modules, and each module can be in at least two possible states during execution of the software code, the possible states being an encrypted state and an encrypted state. Is not in the state
The method is executed by a processor that executes the software code,
Changing the software code by changing one of the plurality of modules from a first state to a second state;
Checking the integrity of the software code by comparing a checksum with the modified software code for the modified software code.   The method of claim 1, wherein the checksum is a hash value.   The method of claim 1, wherein the checksum is embedded in a function that verifies the integrity of the module.   The method of claim 1, wherein the checksum is included in a lookup table.   The function of verifying the integrity of the modified software code uses a state variable indicating a state of each of the plurality of modules to access the checksum included in the lookup table. Method. A device that verifies the integrity of self-modifying software code during its execution,
The software code has a plurality of modules, and each module can be in at least two possible states during execution of the software code, the possible states being an encrypted state and an encrypted state. Is not in the state
Execute the software code, thereby
Changing the software code by changing one of the plurality of modules from a first state to a second state;
An apparatus comprising a processor configured to verify the integrity of the software code by comparing a checksum with the modified software code for the modified software code.   The apparatus of claim 6, wherein the checksum is a hash value.   The apparatus of claim 6, wherein the checksum is embedded in a function that verifies the integrity of the module.   The apparatus of claim 6, wherein the checksum is included in a lookup table.   The function of ascertaining the integrity of the modified software code uses a state variable that indicates a state of each of the plurality of modules to access the checksum included in the lookup table. apparatus. A device that generates integrity-protected self-rewriting binaries,
The binary has a plurality of modules, and each module can be in at least two possible states during execution of the binary, the possible states being encrypted and unencrypted. Yes,
A processor, the processor comprising:
Receive binaries,
Generating a binary checksum in each of its possible states;
The integrity is configured to generate a protected binary by inserting at least one checksum verification function and the generated checksum into the binary;
Each checksum function is configured to verify the integrity of each state of the protected binary by comparing the binary state to a checksum for the binary state.   The processor further inserts a plurality of checksum verification functions in a nested manner so that, during execution, the integrity of each checksum verification function is verified by at least one other checksum verification function. The apparatus of claim 11, configured as follows.   6. A computer program for carrying out the steps of the method according to any one of claims 1 to 5, when the self-rewritable integrity stores a protected binary and is executed by a processor. When executed by the processor,
Generating a checksum for each state of a binary having a plurality of modules, each module being in at least two possible states during execution of the binary, the possible states being an encrypted state and an encryption Is not in the state,
An integrity protected binary is generated by inserting at least one checksum verification function and the generated checksum into the binary, each checksum function representing the binary state for the binary state. A computer program storing instructions configured to verify the integrity of each state of a protected binary by comparing the integrity with a checksum.

Images