CA2668547C - Protecting software programs - Google Patents
Protecting software programs Download PDFInfo
- Publication number
- CA2668547C CA2668547C CA2668547A CA2668547A CA2668547C CA 2668547 C CA2668547 C CA 2668547C CA 2668547 A CA2668547 A CA 2668547A CA 2668547 A CA2668547 A CA 2668547A CA 2668547 C CA2668547 C CA 2668547C
- Authority
- CA
- Canada
- Prior art keywords
- processor
- program
- instructions
- corruption
- instruction
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Landscapes
- Debugging And Monitoring (AREA)
Abstract
In order to protect a software program, at least one corruption function is included in the program. Also included in the program is at least one instruction that causes the program to be directed to the corruption function. An available breakpoint is then set such that, when the starting location of the corruption function is reached, an exception is generated and the handling of the exception causes the corruption function not to run. This has the effect that, if a malicious user attempts to use the available hardware breakpoint to perform unauthorized actions on the software program, the corruption function will run, and the software program will be unusable.
Description
PROTECTING SOFTWARE PROGRAMS
This invention relates to a method for protecting software programs, and in particular for a method that protects software programs against attacks that use hardware breakpoints, or similar mechanisms, to compromise a program.
In releasing a software application for execution on end users' hardware, a program developer is effectively providing a user with complete access to the program code of that application. Unfortunately, it is a fact that some end-users will attempt to compromise a software application in order, for example, to obtain illegal copies, gain unlicensed access to certain features, steal IP from the application, inject malicious code or cheat in online games. Indeed, in the context of online gaming, which often seek to support hundreds or thousands of players simultaneously over a network, the occurrence of online cheating can seriously undermine honest players' experience of the game. Free access to executable code by unauthorised users can often result in loss of intellectual property and provides the user with an easy means for probing the application for security vulnerabilities. Also, applications may be reverse engineered and then modified to remove metering or usage control before being recompiled, ultimately resulting in a loss of revenue for the code provider.
Thus, the environment into which publishers release their programs can be considered to be a hostile one. There is therefore a need to protect programs from tampering or misuse, which may involve unauthorised modification and/or copying.
It has been recognized that hardware breakpoints may be used to perform unauthorised actions on a program. Typically, a hardware breakpoint is set by storing a memory address in a register (sometimes referred to as a "debug register").
When a running application accesses the memory at the stored memory address, the application is interrupted, and an exception is generated. The execution of the application code is halted, and a piece of user code is run. This mechanism is provided to allow for debugging of software. Thus, a legitimate user such as a software developer can set the hardware breakpoints such that debug operations can be performed when the application accesses the memory at one of the stored memory addresses. It should be noted that this mechanism, or something very similar, exists in many different processors and systems, although the terminology that is used to describe it may differ from one processor to another.
This invention relates to a method for protecting software programs, and in particular for a method that protects software programs against attacks that use hardware breakpoints, or similar mechanisms, to compromise a program.
In releasing a software application for execution on end users' hardware, a program developer is effectively providing a user with complete access to the program code of that application. Unfortunately, it is a fact that some end-users will attempt to compromise a software application in order, for example, to obtain illegal copies, gain unlicensed access to certain features, steal IP from the application, inject malicious code or cheat in online games. Indeed, in the context of online gaming, which often seek to support hundreds or thousands of players simultaneously over a network, the occurrence of online cheating can seriously undermine honest players' experience of the game. Free access to executable code by unauthorised users can often result in loss of intellectual property and provides the user with an easy means for probing the application for security vulnerabilities. Also, applications may be reverse engineered and then modified to remove metering or usage control before being recompiled, ultimately resulting in a loss of revenue for the code provider.
Thus, the environment into which publishers release their programs can be considered to be a hostile one. There is therefore a need to protect programs from tampering or misuse, which may involve unauthorised modification and/or copying.
It has been recognized that hardware breakpoints may be used to perform unauthorised actions on a program. Typically, a hardware breakpoint is set by storing a memory address in a register (sometimes referred to as a "debug register").
When a running application accesses the memory at the stored memory address, the application is interrupted, and an exception is generated. The execution of the application code is halted, and a piece of user code is run. This mechanism is provided to allow for debugging of software. Thus, a legitimate user such as a software developer can set the hardware breakpoints such that debug operations can be performed when the application accesses the memory at one of the stored memory addresses. It should be noted that this mechanism, or something very similar, exists in many different processors and systems, although the terminology that is used to describe it may differ from one processor to another.
2 Although hardware breakpoints are provided to allow a legitimate user to perform a necessary function, it has also been suggested that hardware breakpoints may be set by a malicious user in such a way that illegitimate operations are performed when the application accesses the memory at one of the stored memory addresses.
Preferred embodiments seek to provide methods of protecting software against such attacks.
In one embodiment, there is provided a method of protecting a computer-readable and executable software program comprised of instructions stored on a computer readable medium. The method involves including in the program instructions for causing a processor executing the program to perform at least one corruption function having a starting location, including in the program at least one instruction that causes the processor executing the program to be directed to the corruption function, and including in the program instructions that cause the processor executing the program to set a hardware breakpoint available in the processor executing the program such that when the processor executing the program has been directed to the corruption function and the starting location is reached, an exception is generated by the processor executing the program and handling of the exception by the processor executing the program causes the processor to execute the program to generate a return instruction so that normal running of the program is resumed by the processor executing the program, causing the corruption function not to be performed by the processor executing the program.
The processor may have a known number of available instruction breakpoints, and the method may involve including in the instructions for causing the processor to perform the at least one corruption function, instructions for causing the processor to perform a plurality of corruption functions, each having a respective starting
Preferred embodiments seek to provide methods of protecting software against such attacks.
In one embodiment, there is provided a method of protecting a computer-readable and executable software program comprised of instructions stored on a computer readable medium. The method involves including in the program instructions for causing a processor executing the program to perform at least one corruption function having a starting location, including in the program at least one instruction that causes the processor executing the program to be directed to the corruption function, and including in the program instructions that cause the processor executing the program to set a hardware breakpoint available in the processor executing the program such that when the processor executing the program has been directed to the corruption function and the starting location is reached, an exception is generated by the processor executing the program and handling of the exception by the processor executing the program causes the processor to execute the program to generate a return instruction so that normal running of the program is resumed by the processor executing the program, causing the corruption function not to be performed by the processor executing the program.
The processor may have a known number of available instruction breakpoints, and the method may involve including in the instructions for causing the processor to perform the at least one corruption function, instructions for causing the processor to perform a plurality of corruption functions, each having a respective starting
3 instruction, one corruption function being included for each of said available instruction breakpoints. The method may further involve including in the at least one instruction that causes the processor to be directed to the corruption function and a plurality of instructions comprising, for each of the corruption functions, at least one instruction that causes the processor executing the program to be directed to a respective corruption function. The instructions that cause the processor to execute the program to set the available hardware breakpoint include instructions that cause the processor to set each available instruction breakpoint such that, when the processor has been directed to one of the corruption functions and the respective one of said starting instructions is reached, the processor generates a respective exception, and the processor handles the exception by generating a return instruction so that the normal running of the program is resumed by the processor so that the respective corruption function is not performed by the processor.
The method may involve, including in the program, instructions that cause the processor to write random data to a processor stack as part of the corruption function.
The method may involve, including in the program, instructions that cause the processor to write data to random locations in a processor stack as part of the corruption function.
The at least one instruction may cause the processor executing the program to be directed to the corruption function only when a non-deterministic condition is met.
The non-deterministic condition may relate to lower bits of a timestamp counter value.
3a The starting instructions of the corruption functions may be placed so that they cannot be encompassed by a single breakpoint.
In another embodiment, there is provided a computer readable medium having recorded theron a computer- executable instructions for directing a processor to execute a program comprising program instructions and instructions including corruption function instructions. The computer readable medium includes instruction codes defining at least one corruption function having a starting location, and instruction codes defining at least one instruction that causes a processor executing the program to be directed to the corruption function. The computer readable medium further includes instruction codes for causing the processor to set an available hardware breakpoint such that, when the processor has been directed to the corruption function and the starting location is reached, an exception is generated by the processor and handling of the exception by the processor causes the processor to generate a return instruction that causes the processor to resume normal running of the program and that causes the processor not to execute the corruption function instructions.
The program may be configured for use on hardware having a known number of available instruction breakpoints, and the instructions defining said at least one corruption function may include instructions that cause the processor to execute a plurality of corruption functions, each having a respective starting instruction, one corruption function being included for each of said available instruction breakpoints.
The program may further include, for each of the corruption functions, at least one instruction that causes the processor to be directed to a respective corruption function, and the instructions may cause the processor to set an available instruction breakpoint, when the processor has been directed to the corruption function and reaches the respective one of the starting instructions, a respective exception may be generated by the processor, and the processor may handle the exception by causing 3b the processor to generate the return instruction so that the normal running of the program is resumed, and the respective corruption function is not executed by the processor.
The corruption function instructions may include instructions that cause the processor to write random data to a processor stack.
The corruption function instructions may include instructions that cause the processor to write data to random locations in a processor stack.
The at least one instruction may cause the processor to be directed to the corruption function only when a non-deterministic condition is met.
The non-deterministic condition may relate to lower bits of a timestamp counter value.
The starting instruction of the at least one corruption function may be placed so that it cannot be encompassed by a single breakpoint.
Reference will now be made, by way of example, to the accompanying drawings, in which:
Figure 1 is a flow chart, illustrating a method in accordance with the one embodiment.
3c Figure 2 illustrates a state of a software program, before application of the method of Figure 1.
Figure 3 illustrates a state of a software program, after application of the method of Figure 1.
Figure 4 illustrates a state of debug registers in a processor running the software program of Figure 3.
Figure 1 is a flow chart, illustrating a method in accordance with one embodiment.
In step 12, a functional software program is obtained. The program may be any existing program, to which it is desired to add a level of protection, in order to prevent at least one possible attack on the program. The description here assumes that the functional software program is written first, and that the method of Figure 1 is applied to it subsequently. Since the method of Figure 1 makes use of the debug registers that can be used by the software developer to debug the program, it may be most convenient for the method to be applied after the program has been written and debugged. However, it is equally possible that the steps required to protect the program could be incorporated while the program is being written. In addition, although it is assumed here that the method of Figure 1 is applied to the program after it has been compiled into executable code, it could also be performed on the application source code, or on any intermediate abstract representation of the code, for example an abstract syntax tree or a single static assignment form.
Moreover, the steps can be performed manually, or automatically by a suitable further program.
Figure 2 is a schematic representation of the functional software program 28, containing multiple instructions 30, 32, 34, etc. The reader will appreciate that, in 3d any realistic example, the program 28 will contain many thousands of separate instructions.
In step 14, a determination is made regarding the hardware platform on which the software is to run. The method of Figure 1 protects the software program specifically against an attack that is based on the use of hardware breakpoints, although related methods can be used to protect the program against similar attacks using other available mechanisms.
The method may involve, including in the program, instructions that cause the processor to write random data to a processor stack as part of the corruption function.
The method may involve, including in the program, instructions that cause the processor to write data to random locations in a processor stack as part of the corruption function.
The at least one instruction may cause the processor executing the program to be directed to the corruption function only when a non-deterministic condition is met.
The non-deterministic condition may relate to lower bits of a timestamp counter value.
3a The starting instructions of the corruption functions may be placed so that they cannot be encompassed by a single breakpoint.
In another embodiment, there is provided a computer readable medium having recorded theron a computer- executable instructions for directing a processor to execute a program comprising program instructions and instructions including corruption function instructions. The computer readable medium includes instruction codes defining at least one corruption function having a starting location, and instruction codes defining at least one instruction that causes a processor executing the program to be directed to the corruption function. The computer readable medium further includes instruction codes for causing the processor to set an available hardware breakpoint such that, when the processor has been directed to the corruption function and the starting location is reached, an exception is generated by the processor and handling of the exception by the processor causes the processor to generate a return instruction that causes the processor to resume normal running of the program and that causes the processor not to execute the corruption function instructions.
The program may be configured for use on hardware having a known number of available instruction breakpoints, and the instructions defining said at least one corruption function may include instructions that cause the processor to execute a plurality of corruption functions, each having a respective starting instruction, one corruption function being included for each of said available instruction breakpoints.
The program may further include, for each of the corruption functions, at least one instruction that causes the processor to be directed to a respective corruption function, and the instructions may cause the processor to set an available instruction breakpoint, when the processor has been directed to the corruption function and reaches the respective one of the starting instructions, a respective exception may be generated by the processor, and the processor may handle the exception by causing 3b the processor to generate the return instruction so that the normal running of the program is resumed, and the respective corruption function is not executed by the processor.
The corruption function instructions may include instructions that cause the processor to write random data to a processor stack.
The corruption function instructions may include instructions that cause the processor to write data to random locations in a processor stack.
The at least one instruction may cause the processor to be directed to the corruption function only when a non-deterministic condition is met.
The non-deterministic condition may relate to lower bits of a timestamp counter value.
The starting instruction of the at least one corruption function may be placed so that it cannot be encompassed by a single breakpoint.
Reference will now be made, by way of example, to the accompanying drawings, in which:
Figure 1 is a flow chart, illustrating a method in accordance with the one embodiment.
3c Figure 2 illustrates a state of a software program, before application of the method of Figure 1.
Figure 3 illustrates a state of a software program, after application of the method of Figure 1.
Figure 4 illustrates a state of debug registers in a processor running the software program of Figure 3.
Figure 1 is a flow chart, illustrating a method in accordance with one embodiment.
In step 12, a functional software program is obtained. The program may be any existing program, to which it is desired to add a level of protection, in order to prevent at least one possible attack on the program. The description here assumes that the functional software program is written first, and that the method of Figure 1 is applied to it subsequently. Since the method of Figure 1 makes use of the debug registers that can be used by the software developer to debug the program, it may be most convenient for the method to be applied after the program has been written and debugged. However, it is equally possible that the steps required to protect the program could be incorporated while the program is being written. In addition, although it is assumed here that the method of Figure 1 is applied to the program after it has been compiled into executable code, it could also be performed on the application source code, or on any intermediate abstract representation of the code, for example an abstract syntax tree or a single static assignment form.
Moreover, the steps can be performed manually, or automatically by a suitable further program.
Figure 2 is a schematic representation of the functional software program 28, containing multiple instructions 30, 32, 34, etc. The reader will appreciate that, in 3d any realistic example, the program 28 will contain many thousands of separate instructions.
In step 14, a determination is made regarding the hardware platform on which the software is to run. The method of Figure 1 protects the software program specifically against an attack that is based on the use of hardware breakpoints, although related methods can be used to protect the program against similar attacks using other available mechanisms.
4 However, where, as here, the method is being used to protect the software program against an attack that is based on the use of hardware breakpoints, it is preferable to have some information about the hardware on which the software is intended to be run by the eventual end users, and hence to have some information about the hardware breakpoints that will be available.
For example, where the hardware is to be run on a typical personal computer, it will be recognised that most PCs contain processors in which four hardware breakpoints may be set. In other situations, it may be necessary to have more detailed information about the class of processor, or the specific processor, on which the software will be run, in order to be able to take full account of the available hardware breakpoints.
Specifically, the method of Figure 1 requires that the number of available hardware breakpoints be taken into consideration, and requires knowledge of the mechanism for setting the hardware breakpoints.
In step 16 of the method shown in Figure 1, one or more corruption functions is/are generated, and incorporated in the program 28 of Figure 2. In the presently preferred embodiment described here, there is one corruption function associated with each of the available hardware breakpoints. That is, four hardware breakpoints may be set, and so four corruption functions are generated, although a smaller number of corruption functions will still provide some protection against some attacks that may be applied against the program.
Figure 3 shows the software program 36 after it has been modified in accordance with the method of Figure 1. Thus, the modified program 36 still contains the instructions 30, 32, 34 of the unmodified program 28, as well as four corruption functions 38, 40, 42, 44.
The corruption functions 38, 40, 42, 44 are blocks of code that, if they are run, adversely affect the running of the application. Preferably, the corruption functions cause serious and irreparable damage to the execution of the application. For example, an application may be made unable to save files, or may crash after a limited period of user activity. Further, the corruption function should preferably be such that its operation cannot be overridden by the user of the software (who may be the person trying to perform the unauthorised operation on the software), or by the program itself.
As an example, the corruption function might make random modifications to data stored on the process stack, for example by writing random values to particular locations, or writing zeroes to random locations. However, it will be appreciated that
For example, where the hardware is to be run on a typical personal computer, it will be recognised that most PCs contain processors in which four hardware breakpoints may be set. In other situations, it may be necessary to have more detailed information about the class of processor, or the specific processor, on which the software will be run, in order to be able to take full account of the available hardware breakpoints.
Specifically, the method of Figure 1 requires that the number of available hardware breakpoints be taken into consideration, and requires knowledge of the mechanism for setting the hardware breakpoints.
In step 16 of the method shown in Figure 1, one or more corruption functions is/are generated, and incorporated in the program 28 of Figure 2. In the presently preferred embodiment described here, there is one corruption function associated with each of the available hardware breakpoints. That is, four hardware breakpoints may be set, and so four corruption functions are generated, although a smaller number of corruption functions will still provide some protection against some attacks that may be applied against the program.
Figure 3 shows the software program 36 after it has been modified in accordance with the method of Figure 1. Thus, the modified program 36 still contains the instructions 30, 32, 34 of the unmodified program 28, as well as four corruption functions 38, 40, 42, 44.
The corruption functions 38, 40, 42, 44 are blocks of code that, if they are run, adversely affect the running of the application. Preferably, the corruption functions cause serious and irreparable damage to the execution of the application. For example, an application may be made unable to save files, or may crash after a limited period of user activity. Further, the corruption function should preferably be such that its operation cannot be overridden by the user of the software (who may be the person trying to perform the unauthorised operation on the software), or by the program itself.
As an example, the corruption function might make random modifications to data stored on the process stack, for example by writing random values to particular locations, or writing zeroes to random locations. However, it will be appreciated that
5 there are a very large number of possible functions that could be used in this way as corruption functions.
Each of the corruption functions 38, 40, 42, 44 has a respective starting instruction 46, 48, 50, 52, which is at or before the start of the code that causes the corruption. There may be one or more instruction before the starting instruction, provided that this does not have any detrimental effect on the program.
In step 18, a large number of instructions are inserted into the functional code, these inserted instructions representing calls to the corruption functions. As shown in Figure 3, there are instructions 54 that call the first instruction of the first corruption function 38, instructions 56 that call the first instruction of the second corruption function 40, instructions 58 that call the first instruction of the third corruption function 42, and instructions 60 that call the first instruction of the fourth corruption function 44.
These instructions are inserted at locations within the functional code that mean that one or more of the instructions will inevitably be reached whenever the program is run.
In the case of an averagely complex program of a few megabytes, there may be of the order of 10,000 of these instructions.
At step 20, additional code 62 is added to the program. This additional code causes the hardware breakpoints to be set to desired values when the program is first run. In addition, an exception handler 64 is included, as described in more detail below.
Specifically, as shown in Figure 4, where the hardware breakpoints are set in debug registers DRO, DR1, DR2, DR3, the first debug register DRO contains the starting address 46 of the first corruption function 38, the second debug register DR1 contains the starting address 48 of the second corruption function 40, the third debug register DR2 contains the starting address 50 of the third corruption function 42, and the fourth debug register DR3 contains the starting address 52 of the fourth corruption function 44.
Each of the corruption functions 38, 40, 42, 44 has a respective starting instruction 46, 48, 50, 52, which is at or before the start of the code that causes the corruption. There may be one or more instruction before the starting instruction, provided that this does not have any detrimental effect on the program.
In step 18, a large number of instructions are inserted into the functional code, these inserted instructions representing calls to the corruption functions. As shown in Figure 3, there are instructions 54 that call the first instruction of the first corruption function 38, instructions 56 that call the first instruction of the second corruption function 40, instructions 58 that call the first instruction of the third corruption function 42, and instructions 60 that call the first instruction of the fourth corruption function 44.
These instructions are inserted at locations within the functional code that mean that one or more of the instructions will inevitably be reached whenever the program is run.
In the case of an averagely complex program of a few megabytes, there may be of the order of 10,000 of these instructions.
At step 20, additional code 62 is added to the program. This additional code causes the hardware breakpoints to be set to desired values when the program is first run. In addition, an exception handler 64 is included, as described in more detail below.
Specifically, as shown in Figure 4, where the hardware breakpoints are set in debug registers DRO, DR1, DR2, DR3, the first debug register DRO contains the starting address 46 of the first corruption function 38, the second debug register DR1 contains the starting address 48 of the second corruption function 40, the third debug register DR2 contains the starting address 50 of the third corruption function 42, and the fourth debug register DR3 contains the starting address 52 of the fourth corruption function 44.
6 Thus, whenever the program is run, one of the instructions 54, 56, 58, 60 is reached at regular intervals. This causes the system to call one of the corruption functions 38, 40, 42, 44. However, while the hardware breakpoints are set at the starting addresses of the corruption functions, this always causes an exception to be generated.
When an exception is generated, the program passes to the exception handler 64.
This is user code that therefore runs when a hardware breakpoint is triggered.
The code is written such that it generates a return instruction so that the normal running of the program is resumed, without executing the corruption function.
If instead the malicious user sets any other value in one of the debug registers, in order to use the hardware breakpoint for his own malicious purposes, the corruption function is called, and the program stops operating.
It should be noted that some processors allow hardware breakpoints to be set in such a way that they operate not on single memory addresses, but on blocks of memory.
In such cases, care must be taken to ensure that the starting addresses of the corruption functions are placed appropriately that they cannot be encompassed by a single hardware breakpoint.
As described above, each of the instructions 54, 56, 58, 60 calls the relevant one of the corruption functions, whenever it is reached. However, in order to cause the program to operate in a more non-deterministic way, and thereby make it more difficult for an unauthorized user to perform illegitimate operations on the software, it is possible to introduce a mechanism that means that the instructions 54, 56, 58, 60 do not always call the relevant one of the corruption functions. For example, the instructions 54, 56, 58, 60 may be such that, when they are reached, a timestamp counter of the processor is examined (i.e. an RDTSC instruction in the case of an Intel x86 processor). Then, the relevant one of the corruption functions may be called only when the lower bits of the timestamp counter value take a certain value or fall within a certain range.
Thus, because the lower bits of the timestamp counter value change so frequently, it is effectively impossible in advance to predict whether the instructions 54, 56, 58, 60 will in fact call the relevant corruption function. That is, the instructions 54, 56, 58, 60 will only call the relevant corruption function when a non-deterministic condition is met.
Although the value of the lower bits of the timestamp counter value are used as the
When an exception is generated, the program passes to the exception handler 64.
This is user code that therefore runs when a hardware breakpoint is triggered.
The code is written such that it generates a return instruction so that the normal running of the program is resumed, without executing the corruption function.
If instead the malicious user sets any other value in one of the debug registers, in order to use the hardware breakpoint for his own malicious purposes, the corruption function is called, and the program stops operating.
It should be noted that some processors allow hardware breakpoints to be set in such a way that they operate not on single memory addresses, but on blocks of memory.
In such cases, care must be taken to ensure that the starting addresses of the corruption functions are placed appropriately that they cannot be encompassed by a single hardware breakpoint.
As described above, each of the instructions 54, 56, 58, 60 calls the relevant one of the corruption functions, whenever it is reached. However, in order to cause the program to operate in a more non-deterministic way, and thereby make it more difficult for an unauthorized user to perform illegitimate operations on the software, it is possible to introduce a mechanism that means that the instructions 54, 56, 58, 60 do not always call the relevant one of the corruption functions. For example, the instructions 54, 56, 58, 60 may be such that, when they are reached, a timestamp counter of the processor is examined (i.e. an RDTSC instruction in the case of an Intel x86 processor). Then, the relevant one of the corruption functions may be called only when the lower bits of the timestamp counter value take a certain value or fall within a certain range.
Thus, because the lower bits of the timestamp counter value change so frequently, it is effectively impossible in advance to predict whether the instructions 54, 56, 58, 60 will in fact call the relevant corruption function. That is, the instructions 54, 56, 58, 60 will only call the relevant corruption function when a non-deterministic condition is met.
Although the value of the lower bits of the timestamp counter value are used as the
7 non-deterministic condition in this example, it will be apparent that other non-deterministic conditions could be used.
The method described herein may work most successfully when used in conjunction with an anti-tamper mechanism, of the type that can detect and prevent any modification of the code.
There is thus described a system that may provide a degree of protection of a program against an attack based on hardware breakpoints.
The method described herein may work most successfully when used in conjunction with an anti-tamper mechanism, of the type that can detect and prevent any modification of the code.
There is thus described a system that may provide a degree of protection of a program against an attack based on hardware breakpoints.
Claims (14)
CLAIMED ARE DEFINED AS FOLLOWS:
1. A method of protecting a computer-readable and executable software program comprised of instructions stored on a computer readable medium, the method comprising:
including in the program instructions for causing a processor executing the program to perform at least one corruption function having a starting location;
including in the program at least one instruction that causes the processor executing the program to be directed to the corruption function;
including in the program instructions that cause the processor executing the program to set a hardware breakpoint available in the processor executing the program such that, when the processor executing the program has been directed to the corruption function and the starting location is reached, an exception is generated by the processor executing the program and handling of the exception by the processor executing the program causes the processor executing the program to generate a return instruction so that normal running of the program is resumed by the processor executing the program, causing the corruption function not to be performed by the processor executing the program.
including in the program instructions for causing a processor executing the program to perform at least one corruption function having a starting location;
including in the program at least one instruction that causes the processor executing the program to be directed to the corruption function;
including in the program instructions that cause the processor executing the program to set a hardware breakpoint available in the processor executing the program such that, when the processor executing the program has been directed to the corruption function and the starting location is reached, an exception is generated by the processor executing the program and handling of the exception by the processor executing the program causes the processor executing the program to generate a return instruction so that normal running of the program is resumed by the processor executing the program, causing the corruption function not to be performed by the processor executing the program.
2. The method of claim 1, wherein the processor has a known number of available instruction breakpoints, and wherein the method includes:
including in the instructions for causing the processor to perform the at least one corruption function, instructions for causing the processor to perform a plurality of corruption functions, each having a respective starting instruction, one corruption function being included for each of said available instruction breakpoints;
including in the at least one instruction that causes the processor to be directed to the corruption function and a plurality of instructions comprising, for each of the corruption functions, at least one instruction that causes the processor executing the program to be directed to a respective corruption function; and wherein the instructions that cause the processor executing the program to set the available hardware breakpoint include instructions that cause the processor to set each available instruction breakpoint such that, when the processor has been directed to one of the corruption functions and the respective one of said starting instructions is reached, the processor generates a respective exception, and the processor handles the exception by generating a return instruction so that the normal running of the program is resumed by the processor so that the respective corruption function is not performed by the processor.
including in the instructions for causing the processor to perform the at least one corruption function, instructions for causing the processor to perform a plurality of corruption functions, each having a respective starting instruction, one corruption function being included for each of said available instruction breakpoints;
including in the at least one instruction that causes the processor to be directed to the corruption function and a plurality of instructions comprising, for each of the corruption functions, at least one instruction that causes the processor executing the program to be directed to a respective corruption function; and wherein the instructions that cause the processor executing the program to set the available hardware breakpoint include instructions that cause the processor to set each available instruction breakpoint such that, when the processor has been directed to one of the corruption functions and the respective one of said starting instructions is reached, the processor generates a respective exception, and the processor handles the exception by generating a return instruction so that the normal running of the program is resumed by the processor so that the respective corruption function is not performed by the processor.
3. The method of claim 1 or 2, further comprising, including in the program, instructions that cause the processor to write random data to a processor stack as part of the corruption function.
4. The method of claim 1 or 2, further comprising, including in the program, instructions that cause the processor to write data to random locations in a processor stack as part of the corruption function.
5. The method of claim 1, wherein the at least one instruction causes the processor executing the program to be directed to the corruption function only when a non-deterministic condition is met.
6. The method of claim 5, wherein the non-deterministic condition relates to lower bits of a timestamp counter value.
7. The method of claim 2, wherein the starting instructions of the corruption functions are placed so that they cannot be encompassed by a single breakpoint.
8. A computer readable medium having recorded theron computer- executable instructions for directing a processor to execute a program comprising program instructions and instructions including corruption function instructions comprising:
instructions defining at least one corruption function having a starting location;
instructions defining at least one instruction that causes a processor executing the program to be directed to the corruption function; and instructions for causing the processor to set an available hardware breakpoint such that, when the processor has been directed to the corruption function and the starting location is reached, an exception is generated by the processor and handling of the exception by the processor causes the processor to generate a return instruction that causes the processor to resume normal running of the program and that causes the processor not to execute the corruption function instructions.
instructions defining at least one corruption function having a starting location;
instructions defining at least one instruction that causes a processor executing the program to be directed to the corruption function; and instructions for causing the processor to set an available hardware breakpoint such that, when the processor has been directed to the corruption function and the starting location is reached, an exception is generated by the processor and handling of the exception by the processor causes the processor to generate a return instruction that causes the processor to resume normal running of the program and that causes the processor not to execute the corruption function instructions.
9. The computer readable medium of claim 8, wherein the program is configured for use on hardware having a known number of available instruction breakpoints, and wherein:
the instructions defining said at least one corruption function include instructions that cause the processor to execute a plurality of corruption functions, each having a respective starting instruction, one corruption function being included for each of said available instruction breakpoints;
the program comprises, for each of the corruption functions, at least one instruction that causes the processor to be directed to a respective corruption function; and the instructions cause the processor to set an available instruction breakpoint such that, when the processor has been directed to the corruption function and reaches the respective one of said starting instructions, a respective exception is generated by the processor, and the processor to handles the exception by causing the processor to generate said return instruction so that the normal running of the program is resumed, and the respective corruption function is not performed by the processor.
the instructions defining said at least one corruption function include instructions that cause the processor to execute a plurality of corruption functions, each having a respective starting instruction, one corruption function being included for each of said available instruction breakpoints;
the program comprises, for each of the corruption functions, at least one instruction that causes the processor to be directed to a respective corruption function; and the instructions cause the processor to set an available instruction breakpoint such that, when the processor has been directed to the corruption function and reaches the respective one of said starting instructions, a respective exception is generated by the processor, and the processor to handles the exception by causing the processor to generate said return instruction so that the normal running of the program is resumed, and the respective corruption function is not performed by the processor.
10. The computer readable medium of claim 8 or 9, wherein the instructions defining the at least one corruption function include instructions that cause the processor to write random data to a processor stack.
11. The computer readable medium of claim 8 or 9, wherein the instructions defining the at least one corruption function include instructions that cause the processor to write data to random locations in a processor stack.
12. The computer readable medium of any one of claims 8 to 11, wherein the at least one instruction causes the processor to be directed to the corruption function only when a non-deterministic condition is met.
13. The computer readable medium of claim 12, wherein the non-deterministic condition relates to lower bits of a timestamp counter value.
14. The computer readable medium of claim 8, wherein the starting instruction of said at least one corruption function is placed so that it cannot be encompassed by a single breakpoint.
Applications Claiming Priority (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US5943708P | 2008-06-06 | 2008-06-06 | |
| EP20080251985 EP2131299B1 (en) | 2008-06-06 | 2008-06-06 | Protecting software programs |
| US61/059,437 | 2008-06-06 | ||
| EP08251985.1 | 2008-06-06 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2668547A1 CA2668547A1 (en) | 2009-12-06 |
| CA2668547C true CA2668547C (en) | 2017-09-05 |
Family
ID=41412304
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA2668547A Active CA2668547C (en) | 2008-06-06 | 2009-06-05 | Protecting software programs |
Country Status (1)
| Country | Link |
|---|---|
| CA (1) | CA2668547C (en) |
-
2009
- 2009-06-05 CA CA2668547A patent/CA2668547C/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CA2668547A1 (en) | 2009-12-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Pappas et al. | Transparent {ROP} exploit mitigation using indirect branch tracing | |
| Wilander et al. | RIPE: Runtime intrusion prevention evaluator | |
| US7996836B1 (en) | Using a hypervisor to provide computer security | |
| US7603713B1 (en) | Method for accelerating hardware emulator used for malware detection and analysis | |
| Volckaert et al. | Cloning your gadgets: Complete ROP attack immunity with multi-variant execution | |
| US8522015B2 (en) | Authentication of binaries in memory with proxy code execution | |
| Prakash et al. | Enforcing system-wide control flow integrity for exploit detection and diagnosis | |
| US11163645B2 (en) | Apparatus and method of control flow integrity enforcement utilizing boundary checking | |
| Kong et al. | Improving software security via runtime instruction-level taint checking | |
| Gupta et al. | Marlin: Mitigating code reuse attacks using code randomization | |
| US8407523B2 (en) | Method for protecting software programs | |
| CN109446799B (en) | Memory data protection method, security component, computer equipment and storage medium | |
| Jurczyk et al. | Identifying and exploiting windows kernel race conditions via memory access patterns | |
| Feng et al. | Stealth measurements for cheat detection in on-line games | |
| Resh et al. | Preventing execution of unauthorized native-code software | |
| Brandão et al. | Employment of secure enclaves in cheat detection hardening | |
| Porter et al. | Decker: Attack surface reduction via on-demand code mapping | |
| CA2668547C (en) | Protecting software programs | |
| Vinck et al. | Sharing is caring: Secure and efficient shared memory support for mvees | |
| EP2131299B1 (en) | Protecting software programs | |
| Philippaerts et al. | CPM: Masking code pointers to prevent code injection attacks | |
| Gadaleta et al. | Instruction-level countermeasures against stack-based buffer overflow attacks | |
| Geden et al. | RegGuard: Leveraging CPU registers for mitigation of control-and data-oriented attacks | |
| EP2720170A1 (en) | Automated protection against computer exploits | |
| Li et al. | MagBox: Keep the risk functions running safely in a magic box |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request |
Effective date: 20130412 |