The present invention relates generally to software, and in particular to ensuring the integrity of software.
This section is intended to introduce the reader to various aspects of art, which may be related to various aspects of the present invention that are described and/or claimed below. This discussion is believed to be helpful in providing the reader with background information to facilitate a better understanding of the various aspects of the present invention. Accordingly, it should be understood that these statements are to be read in this light, and not as admissions of prior art.
It is relatively common for software providers to protect the integrity of a computer program with the goal of making sure that the program performs as intended. However, hackers commonly try to hack the program to perform in different ways. An example is that hackers sometimes wish to modify the code to get around access control features of the program in order to be able to use it without the necessary access rights.
A prior art method of ensuring the integrity of a program is to compute a signature (a.k.a. checksum) over at least some parts of the code. A signature may for example be a hash value, calculated over the parts of the code, and then signed using a secret key. The skilled person will appreciate that numerous other possibilities exist. During program execution, the signature of the code is calculated at least once. To increase the security level, the functions that calculate the signatures are nested, so that the integrity of each function is verified by at least one other function. Thus, if just one function remains intact, it will detect tampering with at least one other function. Further details and explanations may for example be found in US 2003/188231 and EP 1942431, and US 2002/138748 teaches how to determine integrity for relocatable code. A similar solution may be found in D. Aucsmith, Tamper Resistant Software: An Implementation, Proceedings of the International Workshop on Information Hiding, in which encrypted integrity functions are decrypted and then used to verify the integrity of specific, unencrypted modules.
As is to expect, a way to overcome this protection has been found, not by a hacker but academia: Glen Wurster et al., “A Generic Attack on Checksumming Based on Software Tamper Resistance”; in SP '05: Proceedings of the 2005 IEEE Symposium on Security and Privace; pages 127-138, Washington D.C., USA, 2005; IEEE Computer Society. Their method uses two copies of the code: one that is an unmodified version and another that has been modified. The modified copy of the code is executed and whenever a checksum is required, this is calculated using the unmodified copy of the code. The method thus makes it possible to modify the code while it at the same time is possible to provide correct checksums, i.e. checksums corresponding to the unmodified code, although it should be acknowledged that the attack cannot be performed on all kinds of processors.
A countermeasure proposed by Wurster et al. is to change the access rights for the page that contains the code. If the right to read the code is removed also for the code itself, then this provokes an interruption (when the code tries to read itself) that may be hooked to provide an unmodified code.
Another problem is that prior art checksums are not adapted to self-modifying code, since a specific checksum is valid only for one version of the code, i.e. before or after the modification.
It can therefore be appreciated that there is a need for an improved solution for ensuring the integrity of software code, in particular for code that is self-modifying. This invention provides such a solution.
In a first aspect, the invention is directed to a method of verifying the integrity of self-modifying software code during execution thereof. The software code comprises a plurality of modules, each being capable of being in at least two possible states—encrypted and unencrypted—during execution of the software code. A processor executing the software code modifies the software code by transforming one of the plurality of modules from a first state to a second state; and verifies the integrity of the software code by comparing the modified software code with a checksum for the modified software code.
In a first preferred embodiment, the checksum is a hash value.
In a second preferred embodiment, the checksum is embedded in a function verifying the integrity of the module.
In a third preferred embodiment, the checksum is included in a look-up table. It is advantageous that a function verifying the integrity of the modified software code uses a state variable indicating the state of each of the plurality of modules to access the checksum in the look-up table.
In a second aspect, the invention is directed to an apparatus for verifying the integrity of self-modifying software code during execution thereof. The software code comprising a plurality of modules, each module being capable of being in at least two possible states—encrypted and unencrypted—during execution of the software code. The apparatus comprises a processor adapted to execute the software code and thereby modify the software code by transforming one of the plurality of modules from a first state to a second state and verify the integrity of the software code by comparing the modified software code with a checksum for the modified software code.
In a first preferred embodiment, the checksum is a hash value.
In a second preferred embodiment, the checksum is embedded in a function verifying the integrity of the module.
In a third preferred embodiment, the checksum is included in a look-up table. It is advantageous that a function verifying the integrity of the modified software code uses a state variable indicating the state of each of the plurality of modules to access the checksum in the look-up table.
In a third aspect, the invention is directed to an apparatus for generating an integrity-protected self-modifying binary. The binary comprises a plurality of modules, each module being capable of being in at least two possible states—encrypted and unencrypted—during execution of the binary. The apparatus comprises a processor adapted to: receive a binary; generate a checksum for the binary in each of its states; and generate the integrity-protected binary by insertion at least one checksum verification function and the generated checksums into the binary, each checksum function being adapted to verify the integrity of each state of the integrity-protected binary by comparing the state of the binary with a checksum for the state of the binary.
In a first preferred embodiment, the processor is further adapted to insert 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.
In a fourth aspect, the invention is directed to a computer program product having stored thereon a self-modifying integrity-protected binary that, when executed by a processor, performs the steps of the method of the first aspect of the present invention.
In a third aspect, the invention is directed to a computer program product having stored thereon instructions that, when executed by a processor: generates a checksum for each state of a binary, the binary comprising a plurality of modules, each module being capable of being in at least two possible states during execution of the binary, wherein the possible states are encrypted and unencrypted; and
Preferred features of the present invention will now be described, by way of non-limiting example, with reference to the accompanying drawings, in which
A main inventive idea 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 passing from one state to another, at least one module of the code is dynamically modified. Finite state machines as such are well known in the art and will therefore not be described in detail. Non-limitative examples of modules are: subsections of code, chunks of code, and functions. To protect against tampering, it is possible to compute a checksum for each state, which can allow prevention against tampering with the code.
In the example, the initial state is S1. In this state, all the modules of the code are in their initial state and the state is associated with a first checksum, checksum V1, which enables integrity verification of at least one of the modules.
When execution causes a shift from state S1 to state S2, the first module M1 is modified, generating modified module M′1. It is preferred to verify the checksum (using checksum V2) at this time, but the verification may also be performed at a later stage, something that can apply to each state transition.
Similarly, when execution causes a change from state S2 to state S3, the second module M2 is modified, generating modified module M′2, and modified module M′1 is returned back to its unmodified state M1, so that the code comprises the three modules M1, M′2 and M3. As previously explained, it is preferred to verify the checksum (using V3) at this point.
When moving from state S3 to state S2 and from state S2 to state S1, the modifications are performed in the reverse direction; e.g. when going from S2 to S1, modified module M′1 is returned to its unmodified form M1. Also in these cases is it preferred to verify the checksum (using the relevant checksum) after the transition.
A module may for example be modified by deciphering of the module (in which case a decryption key is necessary) or by altering some bytes of the module, such as by permutation. In the first case, the code is enciphered to return it to its initial state (necessitating an encryption key that, in a symmetric encryption algorithm, may be the same as the decryption key); in the second case, the bytes are altered back to the initial configuration, such as by backwards permutation.
In order to protect the binary 410, the protection engine 420 analyses the binary 410 in order to calculate the possible states; to this end, it advantageously uses call graph analysis and state analysis. Once the states have been generated, the protection engine 420 computes the checksums for the states.
The protection engine then generates a protected binary 430 comprising at least one checksum invocation point 432 and a table (which may comprise a single value) of checksums 434, one for each state in which a checksum may be verified. The checksums are preferably associated with some kind of identifier allowing easy access, e.g. indications like State 1, State 2 . . . or indications along the lines of ‘Module 1 encrypted, Module 2 decrypted, Module 3 encrypted’. The checksum table 434 is preferably in the form of hash values for at least part of the protected binary, but other checksums may also be envisaged, such as the number of a certain character in a certain range of the binary. The checksums may be protected, for example by encryption, but it is preferred, as mentioned hereinbefore, to nest the checksum verification functions so that the integrity of each function is verified by at least one other function.
It should be noticed that it is also possible to do without the checksum table 434 provided that a checksum of a state may be determined from the checksum of the previous state in a deterministic manner. The checksums may also be obfuscated in the protected binary or even stored in a separate file.
Consider then the following non-limitative example. To facilitate the description and the understanding thereof, the example is limited to the case where a single code area (called ‘checksum range’) is protected by checksum verifications, which preferably occur at several invocation points during program execution. The skilled person will appreciate that the invention is easily extensible to the case of multiple checksum ranges. The example is further limited to the specific case where a module corresponds to a function that may be in two different states, encrypted and decrypted.
There are thus inherent state transitions in the code and each state is preferably verified in at least one checksum invocation point in the protected binary.
In the example, as each function may be in one of two possible states (encrypted and decrypted) it is possible to represent the state as a state bit Si in state variable S, preferably a bit stream. The state variable S can express values that are not possible depending on the function call graph of the application; as such, it is likely that only a subset of the possible values of the state variable S are valid for the application. Each value of the state variable S corresponds to a checksum value computed by the protection engine and these checksum values are embedded (advantageously as hash values) in the protected binary. A hashed checksum may then be looked up using the state variable S as an identifier.
Whenever a function is encrypted or decrypted—i.e. when the state changes—the state variable S is updated by flipping the appropriate state bit Si.
At first, the program executes the main function 510; the state S is S0=S1S2; the main function may call functions F1 and F2. If function F1 is called, the encrypted F1 is decrypted 520 and S1 is flipped, after which execution of F1530 commences; the state S is S2=S1S2. Similarly, if function F2 is called, the encrypted F2 is decrypted 550 and S2 is flipped, after which execution of F2560 commences; the state S is S1=S1S2.
There are two possibilities in function F1530: execution of F1 ends, and F1 calls F2. In the first case, F1 is encrypted 540, S1 is flipped and execution returns to the main function 510; the state returning to S0=S1S2.
In the second case, F2 is decrypted 550, state bit S2 is flipped, execution of F2560 commences. However, in contrast to when the main function 510 calls F2 directly, F1 is also decrypted, which means that the state is S3=S1S2. Hence, during execution of F2, the state may be either S1 or S3.
Thus, when execution of F2 ends, F2 is encrypted 570, the state bit S2 is flipped and execution returns to the calling function. If the calling function was main function, the main function 510 takes over execution; the state is then S0=S1S2. On the other hand, if the calling function was F1, then execution of F1530 resumes; the state is then S2=S1S2.
In
The simplest implementation of a checksum invocation point is for the program to read the current state S, find the corresponding checksum value in the checksum table, and generate a checksum to be verified against the stored checksum value. If the verification fails, execution is preferably stopped.
The skilled person will appreciate that an attacker may attempt to tamper with the checksum values, which is why it is preferable to protect the checksum table as well as the invocation functions with another checksum, so that these may be verified.
It is possible to raise the level of security by ‘inlining’ the checksum value in the invocation point code, whenever this is possible. In this case, the protection engine advantageously analyzes the call graph to distinguish between three cases.
In the description, the modules have been described as having two possible states (e.g. encrypted and decrypted); the skilled person will appreciate that it is possible for a module to have a plurality (in particular more than two) of states.
It will be appreciated that the present invention can provide a way of verifying the integrity of multiple state software code that can overcome the attack described hereinbefore.
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.
Number | Date | Country | Kind |
---|---|---|---|
10305164.5 | Feb 2010 | EP | regional |