The present invention relates to a method and a device of protecting a first software application to generate a protected software application.

A state of the art approach to protect a program in-memory against malicious modification (e.g. removing of a license check) is known as dynamic selfchecksumming. The idea is that a protected program inspects at runtime its own instruction stream and computes some sort of checksum or hash from it. Additionally the protected program also contains some logic that ensures that the program only continuous to function correctly when the computed checksum matches its expected value. Code that does both, computing the checksum of the specific memory region and triggering some action if the computed checksum does not match its expected value can be called “checker” or “check module”.

However, if an attacker simply disarms a specific checker by locally patching it (e.g. updating its expected checksum or disabling its introspection code) the desired protection can be overcome.

Therefore, there is a need to provide a method for generating a protected software application which provides a better protection against in-memory modifications.

The invention is defined by the independent claims 1 , 14 and 15. Further developments over the invention are given in the dependent claims.

By providing the amended first code region the protected software application does regularly read its instruction stream as part of its normal operation. This obstructs the detection of a check module using dynamic taint analysis because the fact that some code reads the instruction stream is not sufficient anymore to classify the code as being a check module.

The device for protecting a first software application can comprise the same feature as the inventive method for protecting a first software application (including all further embodiments of the inventive method).

It goes without saying that the features mentioned above and so yet to be explained below are usable not only in the combinations specified but also in other combinations or on their own, without departing from the scope of the present invention.

In the following text, the invention is explained in more detail on the basis of exemplary embodiments with the reference to the appended drawings, which likewise disclose features which are essential to the invention. These exemplary embodiments serve merely for illustration and should not be interpreted as limiting. For example, the description of an embodiment having a large number of elements or components should not be interpreted as meaning that all of these elements or components are necessary for implementation. Rather, other embodiments can also contain alternative elements and components, further elements or components, or additional elements or components. Elements or components of different embodiments can be combined with one another, unless specified otherwise. Modifications and alterations that are described for one of the embodiments can also be applicable to other embodiments. In order to avoid repetitions, identical or mutually corresponding elements in different figures are provided with the same reference signs and not explained several times. In the figures:

Fig. 1 schematically shows the steps for generating the protected software application; Fig. 2 schematically shows an execution platform for executing the protected software application, and

Fig. 3 schematically shows a part of the protected software application loaded in the working memory of the execution platform shown in fig. 2.

In the following will be described a first embodiment of the computer- implemented method according to the invention for protecting a first software application to generate a protected software application.

The first software application to be protected is supplied to a first computer 2 which comprises a first computing module 3 (including, e.g. a processor, a hard disk, further hardware elements as well as an operating system), a first input unit 4 (in this case, a keyboard, for example) as well as a first output unit 5 (e.g. a screen).

The first computer 2 adds a protection module 6, and three check modules 7i, 7 ₂ , 73 to the first software application 1 . In addition, the first computer 2 selects a first code region of the first software application 1 (the first code region provides a first functionality when being executed) and amends that first code region such that an amended first code region 9i is generated. In the same way a second, third and fourth code regions of the first software application are selected and amended such that an amended second, third and fourth code regions 92, 9s and 94 are generated, respectively.

In this way, the protected software application 10 is generated.

The protected software application 10 can be executed on an execution platform 11 only if a predetermined license is present. In such an execution platform 11 shown in Fig. 2, the presence of the license can be verified, for example by means of a protection unit 12 which is part of the execution platform 11 (as shown) or which is connected to the execution platform 11 , respectively. The execution platform 11 further comprises a second computing unit 13 (comprising a processor, a working memory 14 and other hardware elements, including an operating system), a second output unit 15 in the form of a screen as well as a keyboard 16 as a second input unit. The execution platform 11 is preferably a different system than the first computer 2, by which the protected software application 10 is generated from the first software application 1 .

When the protected software application 10 is to be executed on the execution platform 11 , the protection unit 12 carries out a license verification. The protection unit 12 allows execution of the protected software application 1 only in the presence of a license.

During execution of the protected software application 10 on the execution platform 11 there is provided protection against detecting the check modules 7i- 7 ₃ using dynamic taint analysis.

Fig. 3 shows a part of the protected software application 10 loaded in the working memory 14 of the execution platform 11 . As already described, a state of the art approach to protect a software application in-memory against malicious modification (e.g. removing of the protection module 6 for license check) is known as dynamic self-checksumming. The idea is that the protected program inspects at runtime its own instruction stream and computes some sort of checksum or hash from it. Additionally, the protected program also contains some logic that ensures that the program only continues to function correctly when the computed checksum matches its expected value.

Code that does both, computing the checksum of a specific memory region and triggering some action if the computed checksum does not match its expected value can be called check module or checker.

As can be seen in Fig. 3, the first check module 7i is code that calculates a checksum from program offset a4 to program offset a7 and compares the result to a first expected value, which is part of the first check module 7i and which at runtime is a constant part of the first check module 7i (cf. arrow A7i and bracket B7i). At runtime tampering is detected when the calculated value does not match the expected value.

Further, the second check module 72 includes code that calculates a checksum from program offset a5 to program offset a10 and compares the result to the expected value, which is part of the second check module 72 and which at runtime is a constant. At runtime tampering is detected when the calculated value does not match the expected value (cf. arrow A72 and bracket B72).

The third check module 7s includes code that calculates a checksum from program offset 0 to program offset a3 (cf. arrow A7s and bracket B7s). At runtime tampering is detected when the calculated value does not match the expected value, which is part of the third check module 7s.

As can be seen, the check modules 7i-7s are placed in an overlapping way, so that an attacker cannot simply disarm a specific checker 7i-7s by locally patching it (e.g. updating its expected checksum or disabling its introspection code) but instead is forced to disarm all check modules 7i-7s at once because the attacked check module is also protected by some other check module which is itself protected by another check module and so forth. This overlapping placement where check modules 7i-7s protect other check modules 7i-7s is referred as checker-graph.

However, the dynamic taint analysis is a dynamic analysis technique that tracks the information-flow through a program’s execution and can be used to detect checkers 7i-7s by their behavior. The technique exploits the fact that checkers 7i-7s behave differently than regular application code as they inspect at runtime the program’s instruction stream from working memory 14 and based on the observed instructions influence the program’s behavior. This is something regular applications do not do because they have no reason to do so and regular applications are usually written in some high level programing language, which means their actual in-memory instruction stream is unknown at the source level because the instruction stream is only created later by the compiler when it translates the high level program into machine code.

According to the invention, the amended code regions 9I -94 are generated in the protected software application 10 which, when being executed, carry out access to at least a part of the code of a protected software application 10 stored in the working memory 14 (as indicated by arrows A9i, A92, A9s and A94) for providing the first, second, third and fourth functionality of the respective first to fourth code region of the first software application 1 . Therefore each of the amended code regions 9I-94 (e.g. the amended second code region 92), when being executed, still provides the functionality of the selected code region (e.g. the second code region) but carries out access to code of the protected software application 10 stored in the working memory 14 for doing this. The accessed code can be unamended code (arrows A92, A9s and A94) compared to the first software application 10 or amended or added code (arrow A9i) compared with the first software application 1 . Therefore, the regular application code (i.e. code which is not part of a check module 7i-7s or of the protection module 6) does heavily inspect its own instruction stream as part of its program logic. This means that even without any artificially added check module 7i-7s or protection module 6, the compiled application does regularly read its instruction stream as part of its normal operation. Since the protected software application 10 includes the check modules 7i-7s and the amended code regions 9I-94 not only the artificially added check modules 7i-7s inspect the instruction stream but also the rest of the application. This obstructs check module detection using a dynamic taint analysis because the fact that some code reads the instruction stream is not sufficient anymore to classify the code as being a check module.

Of course it is possible not to add the protection module 6 to the first software application 1 to generate the protected software application 10. Even in this embodiment the protected software application 10 obstructs the check modules 7I-79 from being detected by a dynamic taint analysis.

Two components can be provided to do the rewriting of the application code of the first software application 1 to generate the amended code regions 9I-94: The first component extends the code generation pipeline of the compiler (e.g. LLVM, gcc, etc.). The second component is a tool that applies patches to the binary image (exe/dll) produced by the linker. In the following description the name “compiler-plugin” refers to the first component, the name “post-linker-tool” refers to the second component. The first component can carry out a transformation phase and the second component can carry out a separate reference replace phase.

The job of the compiler-plugin is to replace all uses of constants in the application code (e.g. a C program) of the first software application 1 with a sequence of reads from extern global variables. Thereby a larger constant, e.g. a 32bit integer should be split into a sequence of smaller reads that create the final value in some variable (can be both, local or global). Also the names of the referenced extern globals encode their desired value.

Example: Something like if( var == OxBEEFBEEF ) {

}

Would be rewritten by the compiler-plugin into something like this: extern uint8_J g_uint8_be_1 ; extern uint8_t g_uint8_ef_1 ; extern uint8_t g_uint8_be_2; extern uint8_t g_uint8_ef_2; uint32_t my constl; uint8_t* ptr = (uint8_t*)&my_const1 ; ptr[3] = g_uint8_be_ 1; //Reverse order because of little endian. ptr[2] = g_uint8_ef_ 1; ptr[ 1 ] = g_uint8_be_2; ptr[O] = g_uint8_ef_2; if( var == my constl {

}

Here the C-Code is used to illustrate the idea, the actual compiler-plugin would not rewrite actual C-Code but (possibly optimized) intermediate code of the compiler (e.g. LLVM-IR).

Note that because we use extern global variables and e.g. not simply dummy values we get the guarantee that the compiler really generates four 8bit reads in the object file as the compiler’s optimizer only sees 4 references to 4 distinct 8bit-wide undefined symbols. E.g. the optimizer cannot know that g_uint8_be_1 and g_uint8_be_2 are really constants and that they will have an identical runtime value of OxBE. Also because the compiler only sees undefined symbols for the global variables he has to create relocations for the four load instructions. These relocations then enable the post-link tool to patch the linked binary image (exe/dll) so that the load instructions will load their target-values from the program code. The point of splitting larger constants into a sequence of smaller reads increases the odds that the post-linker-tool finds the required values somewhere inside the program code. In order to ensure that the program code of the linked binary image (exe/dll) will contain all necessary constants the compiler-plugin can additionally insert the values via inline assembler such as in the following code: asm (

"jmp skip_data\n"

".byte Oxde, Oxad, Oxbe, 0xef\n"

"skip_data:\n"

);

This code can be placed in a C-function and inserts the bytes OxDE, OxAD, OxBE, OxEF inside the machine code of that function while not interfering with the regular execution as the unconditional jmp instruction jumps over the inserted data. Thereby the compiler-plugin could follow different strategies, e.g. make sure all 255 bytes values are somewhere present in the binary image or just add the values that are actually needed by the rewritten code so that the post-linker-tool will definitely find at least one occurrence.

In actual application code constants are pretty common, e.g. C-Code like for( int i = 0; i < length; i++ {

} would be rewritten into something like extern uint8_t g_uint8_00_1 ; extern uint8_t g_uint8_00_2; extern uint8_t g_uint8_00_3; extern uint8_t g_uint8_00_4; uint32_t my_const2; uint8_t* ptr2 = (uint8_t*)&my_const2; ptr[3] = g_uint8_00_ 1; ptr[2] = g_uint8_00_2; ptr[ 1 ] = g_uint8_00_3; ptr[O] = g_uint8_00_4; for( int i = my_const2; i < length; I++

{

}

As zero/NULL is probably the most common constant in actual application code, one code easily apply some encoding that maps zero/NULL to something else (here OxBEEF), e.g. C-Code like int a = 0; would 1 st be rewritten into, e.g. a simple xor encoding int a = OxBEEF ^A OxBEEF //A constant xor with itself yields 0. and then in a 2nd step the newly created constant(s) (here OxBEEF and OxBEEF) into something like extern uint8_J g_uint8_be_3; extern uint8_t g_uint8_ef_3; extern uint8_t g_uint8_be_4; extern uint8_t g_uint8_ef_4; uint16_t my_const3; uint16_t my_const4; uint8_t* ptr3 = (uint8_t*)&my_const3; uint8_t* ptr4 = (uint8_t*)&my_const4; ptr3[1] = g_uint8_be_3; ptr3[0] = g_uint8_ef_3; ptr4[ 1 ] = g_uint8_be_4; ptr4[0] = g_uint8_ef_4; int a = my_const3 ^A my_const4;

Another common source of constants in application code is the sizeof operator, e.g. code like: customType* dyn array = malloc( sizeof (customType) * elemCount );

In this code sizeof (customType) returns the size in bytes of customType which is just a simple compile time constant whose value is directly available at the compiler’s intermediate representation. For the sake of this example we assume sizeof (customType) returns 24 (aka 0x18).

So at the level of the compiler’s intermediate representation the call looks like customType* dyn array = malloc( 24 * elemCount ); which would be rewritten into something like uint8_t my_const5 = g_uint8_ 18_1 ; customType* dyn array = malloc( my_const5 * elemCount ); Another very common source of constants are string literals such as: puts( “Hello”);

This would be rewritten into something like: uint8_J my_const6[6]; //sizeof(“Hello”) is 6 because of the ‘\0’. my_const6[0] = g_uint8_48_1 ; //0x48 is ‘H’ my_const6[ 1 ] = g_uint8_65_1 ; //0x65 is ‘e’ my_const6[2] = g_uint8_6c_1 ; //0x6C is T my_const6[3] = g_uint8_6c_2; //0x6C is T my_const6[4] = g_uint8_6f_2; //0x6f is ‘o’ my_const6[5] = g_uint8_00_5; //0x6f is ‘\0’ puts( my_const6 );

A different source of constants are constants not defined by the programmer but by the compiler, e.g. an address calculation to access a specific field of a struct. For performance reasons usual compilers try to encode such constants directly as an immediate of the machine instruction. The compiler-plugin can also extend the compiler backend and modify the instruction selection to use explicit register loads instead of immediates.

Example: The backend requests an instruction that loads a given CPU register with a 32bit constant, e.g. on x86_64: Load register eax with value OxBEEFBEEF. A decent x86_64 instruction selector would emit mov eax, Oxbeefbeef

The instruction selector provided by the compiler-plugin would emit instead something like this: lea rax, [rip+my_constant] #load address of label ‘my constant’ into rax. mov eax, DWORD PTR [rax] #load Oxbeefbeef into eax. jmp skip data #make sure we are not executing the constant as code, my constant:

.4byte Oxbeefbeef skip data: This code performs an explicit, program-counter (register rip) relative load of the constant Oxbeefbeef (labeled ‘my constant’) which is placed inside the program code. Similar to the previously described code rewrites the compilerplugin could also split the rip-relative load of the constant into a sequence of smaller (e.g. byte) loads from different addresses and emit the necessary relocations, so that the post-link-tool can find the necessary somewhere in the program code and then adjust the offsets of the rip-relative loads accordingly.

The job of the post-link-tool is to resolve the symbols originating from the rewriting (the g_<type>_<target_value>_<id> symbols) against existing data values already present in the linked binary image of the exe/dll. So when building the application the regular linker first creates as usual the binary image (exe/dll) by linking the object files together but ignores errors from undefined symbols that originate from the rewriting. In a second step the post-link-tool resolves these undefined symbols against values from the binary image. E.g. to resolve the symbol g_uint8_48_1 the post-link-tool scans the binary image for an occurrence of the byte 0x48, determines the load-address of this value and resolves the associated relocation with the determined load-address. In case of a non-ASLR executables the relocation can be removed, for dlls and ASLR- enabled executables the existing relocation will be replaced with an associated base-relocation (“add runtime base address to relocation-target”). Note that the post-link-tool is not necessarily a separate executable but might be also integrated into the linker. The important aspect is that it runs at the end of the link when the binary image itself is already constructed.