SOURCE CODE OBFUSCATION BY MEAN OF EVOLUTIONARY ALGORITHMS

Transcription

1 SOURCE CODE OBFUSCATION BY MEAN OF EVOLUTIONARY ALGORITHMS Sébastien Martinez 2011 Tutor : Sébastien Varrette Advisor : Benoît Bertholon University of Luxembourg, Faculty of Sciences, Technologies and Communications Master Informatique Spécialité Recherche en Informatique TELECOM Bretagne 1

2 2 RELATED WORK 1 Introduction Usually, when talking about security, the matter is about protecting a computer from intrusions or malicious software. Here, the matter will be about how to protect software from piracy. More precisely, how to make a program able to run without letting the user know its composition. To achieve this goal, distributing binaries instead of source code is not enough since debuggers and decompilers can be used to help get the secret algorithm or data structure one does not want to be known by the user. The solution would be having code that is impossible to understand for the user, but since this goal cannot be reached, the code will have to be complicated enough so that users wanting to get secret algorithms will either give up, either obtain the algorithm when it is obsolete (e.g. when a new, better version is available). The techniques used for this purpose are called Obfuscation techniques There are several reasons why someone would want to obfuscate his or her code. The most common reason would be to hide an algorithm from eavesdroppers while executing the code on an unsecured platform i.e. a public cloud. Code obfuscation is not only used to keep some pieces of code secret, it can as well be used to introduce a fingerprint into the software for each user allowing the detection of the user of a specific version of the code. For example, one would want to make special copy of his or her software for each person he or she distributes the software to. Hence, if illegal copies of the software are found it would be easy to trace the person who distributed the pirated copies. Since there are no easy ways to find the best transformations for a given program, we will study the possibility of using evolutionary algorithms to find the best obfuscated program accordingly to the criterion we give in this article. On a first step, a short overview of evolutionary algorithms and of the source to source compiler IS will be given before listing several software complexity metrics that can be used to measure obfuscation transformations efficiency. Then, obfuscation techniques will be classified based on the parts of the program they affect. Before summarizing the obfuscation metrics, the matter of deobfuscators will be tackled. Eventually, we will detail how the use of evolutionary algorithm is planned for finding best obfuscated programs. 2 Related Work 2.1 Evolutionnary Algorithm Evolutionary Algorithm (EA) is a class of solving techniques based on the Darwinian theory of evolution [8] which involves the search of a population X t of solutions. Members of the population are feasible solutions and called individuals. Each iteration of an EA involves a competitive selection that weeds out poor solutions through the evaluation of a fitness value that indicates the quality of the individual as a solution to the problem. The evolutionary process involves at each generation a set of stochastic operators that are applied on the individuals, typically recombination (or cross-over) and mutation. There exists many useful models of Evolutionary Algorithms (EAs) yet a pseudo-code of a general execution scheme is provided in the Algorithm 1. Algorithm 1: General scheme of an EA in pseudocode. t := 0; Generation(X t ) // generate the initial population Evaluation(X t ) // evaluate population while Stopping criteria not satisfied do ˆX t = arentsselection(x t ); // select parents X t = Modification( ˆX t ); // cross-over + mutation Evaluation(X t) // evaluate offspring X t+1 = Selection(X t, X t) // select survivors for the next generation t := t + 1; Execution of simple EA requires high computational resources in case of non-trivial problems. It might be encountered when dealing with large individuals (e.g. in case of Genetic Algorithm (GA) long sequences of genes, in case of Genetic rogramming (G) large parse trees) and/or large populations. This influences time required to evaluate the population, which usually is the costliest operation in EAs. In such cases, time-to-solution on a single computer is prohibitively long for practitioners (especially with usage of G). Such example of highly expensive EA for a computer vision problem is described in [13], where more than 24h are required to execute the algorithm. Another instance of even bigger requirements was reported by Melab et al. in [12], where predictive mathematical model for the concentration of sugar in beets was constructed using parallel GA cumulative CU

3 2.2 IS - source code compiler 3 TAXONOMY OF OBFUSCATION METHODS time exceeded 27 days. 2.2 IS - source code compiler IS (arallélisation Interprocédurale de rogrammes Scientifiques) [9], [1] is an interprocedural source to source compiler analyzing C and Fortran programs and transforming them to optimize parallel executions of these programs. IS can apply transformations that can be used to obfuscate the input code like loop unrolling or variable renaming. Moreover, IS can use SIMD instructions to accelerate a program by means of vectorial instructions. SIMD introduces calls to intrinsics that can be hard to understand for programmers who don t know them. Using IS as a tool for operating transformations on programs, we gain a powerful tool for code obfuscation. The python frontend pyps allows the user to specify transformations to be applied or specific data structures to be used. In the list of transformations mentioned in this article, several are already available in IS. 3 Taxonomy of Obfuscation Methods Obfuscation methods can take many forms, and can affect many parts of a program : the data structures used, the functions called or even the textual representation of the source code (e.g. Suppressing any indentation). Colberg and Nagra proposed to use this fact to watermark or birthmark program [7], the mark being inserted using some transformations applied to the program. When obfuscating a program, some dead code is often inserted. If instead some special code making the program behave in an unwanted way by the user is inserted, we could tamperproof the program. Any reverse engineer would face side effects if he executed these pieces of dead code. In this article, we will focus on the usage of transformation to obfuscate the program. Although the transformations used for watermarking or tamperproofing are similar to the one that will be listed is this section. On a first step, the definition of a obfuscating transformation and of a transformation quality will be given. Then some complexity software metric will be enumerated before giving a non exhaustive list of obfuscation transformations based on the work of Colberg et al. [7], [5]. Then, before summing up the transformation qualities, the subject of deobfuscator will be tackled. 3.1 reliminary definitions In order to classify and evaluate obfuscation transformations, we will need to define several notions. Definition 1 (Obfuscating Transformation). Let τ be a transformation of a source program into a target. τ is an obfuscation transformation if and have the same observable behavior. More precisely, the following conditions are respected : If fails to terminate or terminate with an error condition, then may or may not terminate Otherwise must terminate and produce the same output as Observable behavior can be defined as being the behavior experienced by the user. This means everything the user can notice at first sight. Hence, if has side effects (new created files, network communications ) that are not noticed by the user, it can still have the same observable behavior (provided it has the same user experienced effects as ). In order to evaluate the quality of obfuscation transformations, we need to define several transformation properties and metrics. The three main properties being otency, Resilience and Cost. otency can be considered as a measure of a transformation usefulness in its task of hiding the intent of the program coder. otency can be seen as a measure of an obfuscation transformation efficiency toward human readers. Resilience can be seen as a measure of an obfuscation transformation efficiency toward automatic deobfuscators (as an opposition to potency) Transformation cost measures the penalty introduced by the transformation : a transformation can make the program use more memory or more time. These three measures compose the quality of a transformation. Definition 2 (Transformation otency). Let τ be a behavior-conserving transformation, such that τ transforms a source program into a target program. Let E( ) be the complexity of. τ pot ( ), the potency of τ with respect to a program is a measure of the extent to which τ changes the complexity of. It is defined as

4 3.2 Metrics 3 TAXONOMY OF OBFUSCATION METHODS τ pot ( ) = E( )/E( ) 1 We say τ is a potent obfuscating transformation if τ pot ( ) > 0. In this definition E a measure of complexity. Since there are many software complexity measures, one has to be chosen. Several metrics will be listed in the next subsection. Software complexity metrics are often subjective and some transformation will increase the program complexity according to the metric in use while the deobfuscation of these transformations are really simple for a machine though uneasy for a human reader as we will see further. Hence, potency can be pictured as a measure of a transformation usefulness toward human readers. To measure a transformation usefulness toward automatic deobfuscators, resilience has to be introduced. Resilience takes two parameters in consideration : rogrammer Effort (the amount of time taken to build an automatic deobfuscator that will efficiently reduce the potency of τ) and Deobfuscator Effort (the execution time and the memory space required by the obfuscator to reduce efficiently the potency of τ). Definition 3 (Transformation Resilience). Let τ be a behavior-conserving transformation, such that τ transforms a source program into a target program. τ res ( ) is the resilience of τ with respect to a program. τ res ( ) = one-way if information is removed from such that cannot be reconstructed from. Otherwise, τ res = Res(τ Deobfuscatoreffort, τ rogrammereffort ) Where Res, the Resilience is the function defined by the matrix defined in the matrix in Figure 1 Transformations often introduce some loss in the program. The program can need more memory space or more time to terminate after the application of a transformation. Transformation cost introduces this notion. Definition 4 (Transformation Cost). Let τ be a behavior-conserving transformation, such that τ transforms a source program into a target program. τ cost ( ) is the extra execution time/space of compared to. τ cost ( ) is dear if executing requires exponentially more resources than costly if executing requires O(n p ), p > 1, more resources than cheap if executing requires O(n) more resources than free if executing requires O(1) more resources than otency, resilience and cost compose the quality metric of obfuscating transformations. Definition 5 (Transformation quality). τ qual ( ), the quality of a transformation τ, is defined as the combination of the potency, resilience, and cost of τ τ qual ( ) = (τ pot ( ), τ res ( ), τ cost ( )) Now that obfuscating transformations and transformation quality have been defined, several software complexity metrics will be tackled. Combining these notions will enable the evaluation of the different obfuscation transformations that will be listed further in this article. 3.2 Metrics Software complexity doesn t have one metric, software complexity because the complexity of a program can have many aspects, many of them being subjective. Moreover, complexity metrics depend on the language we use, more precisely on its paradigm. Hence, we have to chose the most adapted metric to our context. Since we want to classify and compare obfuscation transformation, we will have to consider several metrics depending on the transformation and the elements it affects. McCabe proposes a graph theory oriented metric [11] in which the control flow of programs is seen as graphs. Here, a program complexity is measured by the number of linearly independent paths which is equal to e n + p in strongly connected graphs (e being the number of edges, n the number of vertices and p the number of connected components of the graph). Control flows of programs being assumed to have a strongly connected structure, we can see how adding more independent paths in a program can increase its complexity. Chidamber and Kemerer listed several metrics for object oriented programs [4] like giving weight to classes, measuring coupling between classes (i.e. evaluating the interactions between classes) or the

5 3.3 Obfuscation Techniques 3 TAXONOMY OF OBFUSCATION METHODS rogrammer effort Inter process full full Inter procedural strong full trivial weak strong full one-way Global weak strong Low resilience High resilience Local trivial weak oly time Exp time Deobfuscator effort Figure 1: Resilience of obfuscating transformations : Scale of values (left) and resilience matrix (right) lack of cohesion in methods (i.e. measure the similarity between two methods counting the instance variables used in common). When not using object oriented program, some parallel lines can be drawn with data structures (e.g. Measuring global variable or data structures used by several functions, evaluation interactions between variables ). Colberg et al. referenced the most popular software complexity metrics [5]. Each of them will be written µn in the following and will determine a specific metric applying on functions, data or the whole program. µ1 rogram Length : The more has operators and operands, the more complex it gets. µ2 Cyclomatic Complexity : The complexity of a function is measured by the number of predicates it contains. µ3 Nesting Complexity : The more conditionals of a function are nested, the more complex that function is. µ4 Data Flow Complexity : The complexity of a function increases with the number of variables references in inter-basic blocks. µ5 Fan-in/out Complexity : A function is more complex if it has more formal parameters, its complexity also increases with number of global data structures it reads or writes. µ6 Data Structure Complexity : The complexity of a program increases with the complexity of the static data structure it uses. Scalar variable have a constant complexity. Arrays complexity increases with their number of dimension and the complexity of their element type. 3.3 Obfuscation Techniques Based on the metrics previously enumerated, a first way to obfuscate a program would be to increase the complexity of its data structures and of its functions. But in this section we will see that the best efficiency is accessible when combining theses types of transformation and when mixing variable and functions usages in order to make the control flow more complex. The notion of opaque construct will also be introduced. Obfuscation techniques can be classified in three categories based on the parts of the program it affects. The three main classes are layout obfuscation, data obfuscation and control obfuscation Data obfuscation Data obfuscation gathers all the transformations that obscur the data structures used in a program. For example, splitting a vector in two vectors is a data obfuscation technique. We can distinguish three classes of transformations : transformations affecting the storage, the encoding, the ordering or the aggregation of the data.

6 3.3 Obfuscation Techniques 3 TAXONOMY OF OBFUSCATION METHODS When choosing data structures, the most adapted way for storing or encoding the data is usually chosen. For example, when coding a 16 bit int, we represent the value 6 by , respecting conventions. We could decide not to respect conventions and decide that the previous bit pattern would code the value 4. Changing encoding A typical example of encoding transformation would be to use more than one variable to encode one value. For instance, if we want to transform the variable k in, we can use constants and use c 1 k + c 2 instead of k in. There is a trade-off between resilience and potency and between resilience and cost. The previous example has a little impact on the execution time of but common compiler analysis can deobfuscate such a transformation. (c 1 = 5c 2 = 2) int k; for (k=1;k<100;k++) { vect[k] int k; for (k=7;k<502;k++) { vect[(k-2)/5] k+=4; romoting variables romoting a variable means replacing a specialized storage structure by a more general one. For example, in a language such as Java, an integer typed variable can be replaced by an Integer class. Such transformation usually has a low resilience and potency but can be more effective when used in conjunction with other transformations. The variable promotion could also be an increasing of its lifetime, like making a local variable be global. Such a transformation increases the number of global variable used by the program functions. void foo() { int i; i void bar() { int k; k int c; void foo() { c void bar() { c Splitting variables Splitting a variable i means replacing it by a set of variables (i 1, i k ). Three pieces of information have to be given : a function f(i 1,, i k ) that maps the i 1,, i k to i, a function g(i) that maps i to the corresponding i 1,, i k and operations on i 1,, i k corresponding to the operations available on i. The potency and cost of such transformations increases with k, hence this transformation is usually applied for k = 2 or 3. Converting static data to procedural data These transformations replace static data by a function that returns this data. Many pieces of data can be replaced by a function taking one parameter and returning one of these pieces of data depending on the given parameter. Since storing all the static data in one function is not desirable at all, we can split this function into many functions spared in the program control flow. "abc" "dfe" string foo(int a) { if (a == 0) return "abc" elif (a == 1) return "dfe" foo(0) foo(1) Aggregation Transformations The same way splitting data obfuscate the code, aggregating data adds obscurity to the code. One could merge several variable in one. For example, a 64-bit integer could store two 32-bits integers. Or a k-size array could store k variables sharing the same type. These transformations have low resilience since a deobfuscator only needs to study the operations on the aggregated data. Still, we can insert fake operations in blocks of dead code. One would also restructure arrays : merging several arrays in one, splitting an array into several arrays, folding an array (increasing its dimension) or flattening an array (decreasing its dimension). These transformations often have low potency because complexity metrics cannot measure the fact that some of these transformations introduce new struc-

7 3.3 Obfuscation Techniques 3 TAXONOMY OF OBFUSCATION METHODS tures. For example, a programmer manipulating an image would declare a 2 dimension array. Manipulating a one dimension array or a 3 or more dimension array would increase the obscurity significantly of the program. Ordering transformations Randomizing the order of declarations is generally a good idea. That being the ordering of data in arrays or the order of function definition. In the example below we reordered the data in A using a function f. A[100]; A[100]; for (i=1,i<100,i++) for (i=1,i<100,i++) { { A[i] A[f(i)] Layout obfuscation Layout obfuscation gathers all the transformations that change the information included in the code formating. For example, scrambling identifier names or the code indentation are layout obfuscation techniques. Layout transformations often are one-way and free while their potency may vary depending on the transformation Control obfuscation Control obfuscation obscures the program controlflow. Control transformation may affect the aggregation, ordering or computations of the control flow. Control aggregation transformation sparse computations that should stay grouped and groups computations that have nothing in common. Control ordering transformations randomize the order of instructions and computations transformations insert new code or change the algorithms employed in the program. Applying control obfuscation technique often implies slowing down the program. The programmer will have to chose between the highly efficient program he intends to distribute and its highly obfuscated, but slower alternative. Opaque predicates Opaque constructs are predicates or variables that have priority known by the obfuscator but are hard for the deobfuscator to guess. There is a link between the resilience and the cost of an opaque construct and the cost and resilience of the transformation that uses it. Resilience and cost of an opaque construct are measured using the same scale as obfuscating transformations. Definition 6 (Opaque constructs). A variable V is opaque at a point p in a program if V has a property q at p that is known at obfuscation time. We write Vp q A predicate is opaque at a point p in a program if its value (True or False) is known at obfuscation time. We write p T if is True at p, p F if is False at p and p? if is sometimes True and sometimes False at p. An opaque construct is said to be trivial if a deobfuscator can deduce its value by static local analysis and is said to be weak if a static global analysis is required to deduce its value. Inserting dead code Using opaque predicates enables the insertion of irrelevant code, A block of instructions can be put in an if condition of an opaque predicate T and some dead code (ie : code with no actual effect but still hard to understand) could be inserted in the else case of that condition. Another usage of dead code insertion is using a? opaque predicate and insert two version of the same code in the if and the else condition. Then, the version of the code that is run is determined at runtime, and the deobfuscator could take some time to understand the two versions actually have the same effect. We could also use a T opaque construct and two versions of the same code S a if true and S b if false, but the S b version would have some bugs in it (see 2). Extending loop conditions We can use opaque predicate to make loop termination conditions more complex without changing the number of iteration. For example, we could replace a condition C by C&& T. Converting a reducible flow graph to a nonreducible one Using gotos combined with opaque predicates, we can make unused skips in the programm that will make the flow graph unreducible and force the deobfuscator to make an equivalent of the program which flow graph it can reduce. Since gotos introduce ruptures in a program s control flow, deobfuscators canot easily reduce control flow that use many of them. Adding Redundant Operands rovided result accuracy is not of high importance, we can use opaque variables to add redundant

8 3.3 Obfuscation Techniques 3 TAXONOMY OF OBFUSCATION METHODS T T F T? F T T F C C a C b C a C b f(c a ) = f(c b ) f(c b ) f(c a ) Figure 2: Dead code insertion and opaque predicates operands, increasing the program potency. withr =1, =2Q, Q = /2 x=x+y; x=x+y*r; z=w+1; z=w+(/q)/2; arallelizing code arallel programs are not as easy to understand as non parallel ones. Since there is nowadays plenty of tools for parallelism, we can use them to obscure the program control flow. We could create useless threads that would appear to do real work or we could run several independent tasks of the control flow at the same time. Of course, if the computer that runs the program cannot run more than one process at a time, theses transformation will slow down the program. But our goal here is to obfuscate our program, any actual acceleration of our program would be a side effect. When coding, a programmer would group some pieces of code that have common points, write functions Making the code more understandable and easier to maintain. The next transformation will be aggregation transformations that inline or outline code, unroll loops or interleave functions. Inlining or outlining functions Inlining a function implies replacing calls to a function by the function code. Inlining is a one-way resilient transformation, it remove every abstraction set by the presence of the function. Outlining instructions in a function means making a functions that runs theses instructions. One use of outlining for obfuscation is to outline parts of semantically different procedures in a same function. (see 3). l1; l2; lk; m1; m2; mk; <typea> foo(<args>){ lk-1; lk; m1; m2; l1; lk-2; foo(<args>) m3; mk; Interleaving functions Interleaving functions means merging two (or more) functions in one, merging body, arguments and returned results. The resulted function would take another argument that tells the instructions whose initial functions has to be run. Detecting function interleaving is really difficult for reverse engineers since it scrambles the semantics of the functions that were interleaved. Cloning functions For a given function, one writes several functions that have the exact same role and obfuscate each one a different way. Then, each time the function is to be called, the programmer would call one of its clones instead. Since the context of function calls are used to understand the function purpose and since the body of the function is obfuscated, this transformation makes the understanding of the function more difficult.

9 3.4 Deobfuscation 3 TAXONOMY OF OBFUSCATION METHODS Loop transformations Three loop transformations can be enumerated : loop blocking, loop unrolling and loop fission. For each of these transformations, an example is given in figure 3. Loop blocking means partitioning the loop iteration space in smaller loops. This transformation is usually used to make sure the data used in the loop are kept in the CU cache. Loop unrolling means replicating a loop body several times in order to reduce the number of iterations of the loop. This transformation is often used as a preliminary to the parallelization of the loop. Loop fission is a transformation that expands a loop with a compounded body into several loops with the same iteration space. Independently, these transformations have a fairly good potency but have a very low resilience since in most cases, static analysis can counter these transformations. But when these transformations are used together, the program resilience skyrockets. rogrammer s preference is to increase their code locality, making them more understandable. When obfuscating a program, we will want to mix pieces of the code (e.g. declarations of functions, of variables). Such transformations have low potency since they don t obscure the code that much. However, their resilience is one-way in most cases since once the transformation is applied, there is no information about the original order of the mixed pieces. When applying aggregation transformation, one would pay attention to the order according to which the transformations are applied. For example inlining several functions and outlining a block of the resulting code (making sure the outlined block includes instructions from the inlined functions) will be more efficient than outlining a block of code with the same monolithic semantic. building high resilience opaque constructs redicate such as have trivial or weak resilience. Since the resilience of an opaque construct influences the quality of the transformation that uses it, one would like to have high resilience opaque constructs. There are severals methods for building resilient and cheap opaque constructs ([6]). One first method is to use aliasing. Trying to deduce properties from pointers is difficult since they refer to different memory spaces during the program execution. An example of opaque predicate based on aliasing could be *i==*j (the pointers i and j are referring to the same memory space). Another method would be to take advantage of parallel processing of variable. A variable (or a pointer) modified by many threads would make a highly resilient opaque variable as it would be very difficult and time consuming to analyse statically. For example, there is n! way to execute n parallel instructions. 3.4 Deobfuscation A deobfusactor takes a program and simplifies it, removing useless control and data flow. The three main actions are : eliminating dead code determining whether a block of code will be reached or not, eliminating irrelevant variables determining whether the value of a variable is relevant further in the code from a given point and removing aliasing. If in theory, code obfuscation seems inefficient, there is nowadays no actual easy way to deobfuscate a program. Appel ([2]) tackled the matter of a white box obfuscation of a program. This means that the obfuscating program F is perfectly known to the public, but it uses a key K, kept secret, to obfuscate, thus we have : = F (, K). Knowing F the task of the deobfuscator is N-easy : the deobfuscator would run the following steps : Guess a source program S Guess a key K Compute = F (S, K) Check = Therefore white box deobfuscation is N-easy, but this doesn t lead to really useful deobfuscation programs. As we saw previously, some transformations are one-way and many deobfuscators don t take the risk to invert such transformations. And when they do, failure is very usual. Barak et al. tackled the matter of black box obfuscation ([3]). The virtual black box property stipulates that Anything that can be efficiently computed form O( ) can be efficiently computed given oracle access to. Building a special set of unobfuscable functions, Barak et al. proved that black box obfuscation is not

10 3.4 Deobfuscation 3 TAXONOMY OF OBFUSCATION METHODS for (i=1,i<=n,i++); for(j=1,j<=n,j++) a[i,j]=b[j,i]; (loop blocking) for (I=1,I<=n,I+=64) for(j=1,j<=n,j+=64) for(i=i,i<=min(i+63,n),i++) for(j=j,j<=min(j+63,n),j++) a[i,j]=b[j,i]; for (i=2,i<(n-1),i++) a[i] += a[i-1]*a[i+1]; (loop unrolling) for(i=2,i<(n-2),i+=2){ a[i] += a[i-1]*a[i+1]; a[i+1] += a[i]*a[i+2]; if (((n-2) % 2) == 1) a[n-1]+= a[n-2]*a[n]; for(i=1,i<n,i++){ a[i] += c; x[i+i]=d+x[i+1]*a[i]; (loop fission) for(i=1,i<n,i++) a[i] += c; for(i=1,i<n,i++) x[i+i]=d+x[i+1]*a[i]; Figure 3: Loop transformations (from top to bottom): Loop blocking, loop unrolling and loop fission possible, even when using approximate obfuscators (meaning that has a certain probability to give the same result as ). A major function of a deobfuscator is to eliminate bogus code that were inserted using opaque predicates. It is easier for a deobfuscator to identify and evaluate local opaque construct rather than global ones. Colberg et al. [5] listed several techniques to boost a code s resilience towards automatic deobfuscators. If a transformation can be easily reversed by a deobfuscator, we can introduce bogus code based on that transformation, making reversing less obvious. Since some deobfuscators use pattern matching to identify opaque predicate, one can use the same syntax used for the real code for opaque constructs. One could also exploit the flaw in slicing techniques for deobfuscation like introducing aliasing or adding useless variable dependencies, making it harder to identify sliceable blocks. Several deobfuscators use program slicing [14] to reduce the deobfuscation problem into several smaller problems. Usually, adding aliasing of extending variable dependencies make it harder to slice a program. When using static analysis, a deobfuscator can assume a construct to be opaque. But to prove it, the reverse engineer will have to make a mutant version 1 of the program where the assumed opaque construct is set to its assumed value. If and 1 give the same outputs for the same inputs then the assumption was right. Since choosing the correct input values set will be long and difficult (all the paths in the program have to be covered), we would prefer to use? predicate or use interleaved predicate that would have to be solved together at the same time. One could also make data flow analysis harder or

11 6 CONCLUSION force the deobfuscator to prove complex theorem in order to crack an opaque predicate. In theory, code obfuscation is impossible as it was proved, since its deobfuscation is possible. In reality, exploiting flaws of automatic obfuscators can make a program obfuscation be hard enough to crack so that a new version of the program can be computed and obfuscated. 4 Summary of the obfuscation metrics The obfuscation transformation previously listed have been classified by quality by Colberg in his paper [5]. The table 1 summarizes his work. Transformations are classified by target and operation. The quality of each transformation is exposed and the metric(s) used to measure the transformations potency is(are) enumerated according to the notations used sooner in this article. As seen previously, layout transformations offer high resilience for a free cost whereas their potency may vary. Loop transformations have a very low cost but also have a low potency and resilience. arallelizing code offers strong potency and resilience but is also costly. On several cases, the transformation quality depends on the quality of opaque constructs or complexity of a data structure or function. 5 lanned use of EA for obfuscation As in a compiler, choosing transformations to apply and ordering them is a complex task that can take a long time. In common compilers the transformations and their order are fixed according to an average of good performance. Guelton and Varrette combined the source to source compiler IS with evolutionary algorithms ([10]) to seek the best combination of optimization transformations for a given program. Since IS uses configuration files to specify the nature, order and localization of the transformations it applies, the EA can manipulate text based files instead of binaries. Each individual being represented by a set of configuration files that leads to a binary that will be compared to other individuals binary. Comparing the results brought by the evolutionary approach (compared to a complete approach and a glutton approach), they found that the evolutionary approach gave an optimal result like the complete approach in times comparable to the glutton approach that was unable to give an optimal result. Since code obfuscation is a matter of transformations applied in a particular order, we can think of a use of evolutionary algorithm to find the optimal sequence of transformations to apply on a program. Moreover, we could use distributed Evolutionary Algorithm (dea) to deal with obfuscation problem that would be particular long to solve. 6 Conclusion Software obfuscation have many applications, not only being that of protecting a program s secrets (powerful algorithm, extremely efficient data structure ) but also, birthmarking, watermarking or even tamperproofing. Like software compilation, program obfuscation is a matter of transformation that have to be applied in a correct order to provide an optimal result, transformations having different potency and resilience depending on the other transformations they are combined with. Trying each combination, though guaranteeing the finding of an optimal configuration, can take a very long time. That s why the use of evolutionary algorithms and dea can be a good idea for this matter. Since software complexity doesn t have one single metric, the evaluation of the quality of an obfuscation transformation is not simple. Some transformations can be me more or less efficient on different programs and on different programming languages. Moreover, some transformations may not be available (or just be useless) in some languages. Although it has been proved that, in theory, program obfuscation is impossible and inefficient, whether a black box obfuscator or a white box obfuscator is used, today s deobfuscator have many flaws than can be exploited and deobfuscating a program is still long enough to slow down reverse engineers. Hence, it is possible to protect a program secret by obfuscating it while developing a new version, making the cracking of the last program pointless when the new one is available.

12 6 CONCLUSION Obfuscation Quality Target Operation Transformation otency Resilience Cost Layout Control Data Computations Aggregation Ordering Storage & Encoding Aggregation Ordering Scramble Identifiers medium one-way free Change Formatting low one-way free Remove Comments high one-way free Metrics Insert Dead or Irrelevant Code µ Depends on the quality of the opaque 1, µ 2, µ 3 construct and on the nesting depth of its Extend Loop Condition µ insertion 1, µ 2, µ3 Reducible to non- µ 1, µ 2, µ3 Reducible Add Redundant µ 1, µ 2, µ3 Operands arallelize Code high strong costly µ 1, µ 2 Inline Method medium one-way free µ 1 Outline Statements medium strong free µ 1 Interleave Functions Depends on the quality of the opaque µ 1, µ 2, µ 5 Clone Functions predicate µ 1 Block loop low weak free µ 1, µ 2 Unroll loop low weak cheap µ 1 Loop fission low weak free µ 1, µ 2 Reorder Statements low one-way free Reorder Loops low one-way free Reorder Expression low one-way free Change Encoding romote Scalar to Object Change Variable Lifetime Split Variable Depends on the complexity of the encoding function low strong free µ 1 low strong free µ 4 Depends on the number of variables into which the original variable is split Depends on the complexity of the generated function µ 1, µ 2 low weak free µ 1 Convert Static to rocedural Data Merge Scalar Variables Split Array * weak free µ 1, µ 2, µ 6 Merge Arrays * weak free µ 1, µ 2 Fold Array * weak cheap µ 1, µ 2, µ 6, µ 3 Flatten Array * weak free Reorder Functions & low one-way free Variables Reorder Arrays low weak free µ 1 Table 1: Obfuscation transformations and their qualities (Courtesy Colberg et Al). A * in the quality columns indicates that the measure depends on circumstances discussed previously in this article

13 REFERENCES B NOTATIONS References [1] arallélisation interprocédurale de programmes scientifiques (pips). [2] Andrew Appel. Deobfuscation is in N [3] Boaz Barak, Oded Goldreich, Russel Impagliazzo, Steven Rudich, Amit Sahai, Salil Vadhan, and Ke Yang. On the (im)possibility of obfuscating programs [4] Shyam R. Chidamber and Chris F. Kemerer. A metrics suite for object oriented design [5] Clark Thomborson Christian Collberg and Douglas Low. A taxonomy of obfuscating transformations [6] Douglas Low Christian Collberg, Clark Thomborson. Manufacturing cheap, resilient, ans stealthy opaque constructs [7] Christian Collberg and Jasvir Nagra. Surreptitious Software: Obfuscation, Watermarking, and Tamperproofing for Software rotection. Addison-Wesley rofessional, [8] C. Darwin. The Origin of Species. John Murray, [9] Rémi Triolet François Irigoin, ierre Jouvelot. Semantical interprocedural parallelization [10] Serge Guelton and Sébastien Varrette. Une approche génétique et source à source de l optimisation de code [11] Thomas McCabe. A complexity measure [12] N Melab, S Cahon, and E Talbi. Grid computing for parallel bioinspired algorithms. Journal of arallel and Distributed Computing, 66(8): , August [13] Leonardo Trujillo and Gustavo Olague. Automated design of image operators that detect interest points. Evolutionary computation, 16(4): , January [14] Mark Weiser. rogram slicing A Acronym used dea distributed Evolutionary Algorithm EA Evolutionary Algorithm EAs Evolutionary Algorithms GA Genetic Algorithm G Genetic rogramming B Notations Do a table of notations Ex: = rogram = rogram obfuscate

14 B NOTATIONS τ pot ( ) = potency of the transformation from to τ res ( ) = resilience of the transformation from to τ cost ( ) = cost of the transformation from to τ qual ( ) = quality of the transformation from to E() = the complexity of,