Conditional Statement Strategies for Code Obfuscation

• Chandan Kumar Behera, Pawan Kumar, D. Lalitha Bhaskari

Abstract

Obfuscated code syntax has been set intentionally unclear. Different obfuscation techniques may have different impacts on the source code. In the presented paper, the ‘if condition’ has been used several times with the purpose to make the code obfuscated one, but in the mean time, the code should look like very simple. The idea behind this concept is to make feel the reader a simple code and ignore the code basically as it looks straightforward.

Keywords: Software code protection, code obfuscation, conditional statements, malicious code

Introduction

Software protection is increasingly becoming an important requirement for software development according to industry. The software protection problem is fundamentally harder than other security problems. When one has the adversary for full access to the chosen software or hardware and can examine, or modify it, then no piece of software can be protected for the long period of time. An example of very common form of protection against reverse engineering attacks is obfuscation, which modifies a program to make it harder for the adversary to understand or analyse. At the beginning this techniques is developed for automatically creating multiple transformations of same program, by that each version will be difficult to analyse and modify for some more time. That means code obfuscation makes it more laborious and troublesome for understanding completely, because of that it will be not advisable to go for code tampering.

The technique obfuscation helps for manipulating source code to make it harder to analyze and more difficult to understand for the attacker. Obfuscation is a common technique used to protect software against malicious reverse engineering. This approach could focus on changing a specific aspect of the code (e.g., complexity). But, the aim of code obfuscation is to prevent malicious users by disclosing the properties of the original source program.

Typical code obfuscation techniques include splitting of codes into smaller pieces, merging pieces of unrelated codes, randomizing the code placement, mangling of data structures, field assignment, obfuscates the literal strings of a program, merging local integers, use of random Dead Codes, inserting dead variables, reordering of instructions, parameter reordering, transparent Branch Insertion, variable renaming, variable reassigning, aggressive methods renaming, renaming of registers, duplication of registers, promoting primitive registers, reorders the constants in the bytecode and assigns random keys to them, randomly marks all basic bytecode blocks in the program with either 0 or 1, array folding, array splitting, constant unfolding, Control flow obfuscation, flattening or introducing bogus control flow, breaking abstraction boundaries, false refactoring, mapping of bytecode instructions to source code line numbers, removal of local variable tables in the bytecode that store the local variable names in the source code, also various techniques using Opaque Predicates (Ex: branch insertion) etc.

Some more techniques can be used in higher level languages, mostly in object oriented are splitting or merging of classes, finding of inner classes ( if available or not and then use obfuscation there even), new obfuscated names for methods and classes in a random fashion, encrypts class files and causes them to be decrypted at runtime, converting functions into inline methods at runtime, Interleave Methods by that will have the same signature, use of more methods having same names (overload names), takes a class and replaces all the fields with fields of the objects belong to the same class, converting the fields of a class to public, splits all of the non-static methods into a static method, open all the classes for modification, group the classes for modifying the original structure, selects a random method from the class or a random basic block from a method (i.e. a copy of the basic block will be created and some additional malicious code will be added in the new basic block, by which the values of local variable might be changed and the basic blocks will be bypassed from execution) etc.

In this paper, the discussion is basically about the conditional statement. There are different ways of different obfuscation techniques by using conditions. Like, reversing the ‘if’ and ‘else’ conditions, using negation of the condition, introducing ‘if condition’ which will never true, breaking of the condition into nested. Conversion form ‘if- else if’ conditions to switch cases, etc.

Proposed strategy

Generally, use of conditional statements in a program is common. Mostly, for optimizing a program, the writers give the stress towards the loops. According to this thought the obfuscation also can be done on conditions, where ever it is used. Normally, after obfuscating a program, the code will be lengthier as well as difficult to understand. But, in the proposed logic, neither the code will be lengthier nor the code will look difficult to understand. Therefore, the malware witters may ignore the code. Actually the modified code will give some undesired result, by which may surprise the reader.

Here, in place of “if else” or “if – else if – else” conditions, we use several times the ‘if’ condition. In the proposed method if the use of ‘if conditions’ several times is replaced by ‘if- else or if-else if-else’ condition, then output will be totally different and the logic is going to change totally.

Figure 1: Proposed code obfuscation logic by using ‘if condition’ several times

In this paper, some proper fractions have been used for generating different patterns. Those patterns with bit wise represented and by rounding-off the values, sometimes the result will be undesirable. But, actually this is not at all undesirable, and properly calculated. So before execution of the code, it can be identified the condition which is going to be satisfied and with that the function, which is going to be executed. As the result is not undesirable and looks very simple, by and large readers may ignore the conditional statements with high percentage.

The second concerned point is the repetition of patterns. As the remainder will be not zero, during the conversion of the proper fractional number into binary format, because of the infinite string of zero’s and ones. Obviously, the string will be getting a repetition of a kind of pattern. But, the visualization of the value in a variable is not possible, because of limited bytes are allowed to the variables.

Fig. 2 Function execution for different values, while the fraction is 2/3

Fig. 3 Function execution for different values, while the fraction is 2/3

Because of the proper fraction, there are several repetitions of the pattern of 10 in case of rational number 2/3. Then we try to store that infinite value in a double variable and a float variable. After that the both numbers are compared. According to the result shown in the graph in figure 2, more than 88% of times functionC is executed. Here, for the values, functionC is not executing, to be uncovered.

This concept can be used in several ways, like comparing two numbers or comparing a variable with a constant. Any type of program, if that consists of at least one condition is there, then that can be modified in the proposed method to obfuscate the program effortlessly. This strategy can be used in place of or with inserting some dead code or XOR operation or as well as doing some bit wise operations.

In the above code, in figure 1, if the rational number 2/3 is replaced by 3/7, then the functionB will be not executed at all. The functionA will be called, when the value will be in between 1 to 2 or 27 to 31 or 251 to 255 and so on. Here the pattern is 001. i.e. the functionA executes, when the value will be with the range as follows:

Fig. 4. Function execution for different values, while the fraction is 3/7

Similarly, if the proper fraction number 2/3 is replaced by 1/7, then the functionA will not execute. But, the functionB will be called, when the value will be from 3 to 7 or 59 to 63 or 507 to 511 and so on. Here, the pattern is 011.

Fig. 5. Function execution for different values, while the fraction is 1/7

Conclusion

Many times the code seems to be very simple and understandable, but actually not, and because of this, anybody can be confused more. This paper mostly discusses similar to that by using ‘if’ condition. In the paper, it is discussed about code obfuscation by using ‘if condition’ several times. Simply looking to the program, it is very difficult to guess that whether the program is obfuscated. Because, neither the size of the program increases nor the program looks difficult as compare to the original code. The use of several ‘if’ conditions is not at all looking different than that of ‘if –else if-else’ conditions. Most of the cases the values will be same. The important thing is when exactly the values will differ and if they differ, then which function is going to be executed. This need to be understood and bring into play in the code and the obfuscated code should give the desired output. There are several software engineering code techniques to measure the effect of code obfuscation, in terms of the complexity, the modularity and the size of obfuscated code. This methodology will not affect much in complexity or in size of the code. Even the original code and the obfuscated one will be not having much difference according to the modularity. This proposed obfuscation scheme may not be able to satisfy any strong definition of obfuscation, but the combination with any other obfuscation techniques to the same program, can go for a much better result.

References

1. The Effectiveness of Source Code Obfuscation: an Experimental Assessment, Mariano Ceccato, Massimiliano Di Penta, Jasvir Nagra,, Paolo Falcarin, In Proceedings of the17th IEEE International Conference on Program Comprehension (ICPC 2009),Vancouver, Canada, 17-19 May 2009.IEEE, pp-178-187,
2. A Large Study on the Effect of Code Obfuscation on the Quality of Java Code, Mariano Ceccato, Andrea Capiluppi, Paolo Falcarin, Cornelia Boldyreff. Empirical Software Engineering, Springer,

3. Towards experimental evaluation of code obfuscation techniques, Mariano Ceccato, Massimiliano Di Penta, Jasvir Nagra, Paolo Falcarin, Filippo Ricca, Marco Torchiano and Paolo Tonella..InQoP `08: Proceedings of the 4th ACM workshop on Quality of protection,Alexandria (Virginia), USA, 27 October 2008. ACM pp. 39-46 (2008).

4. A family of experiments to assess the effectiveness and efficiency of source code obfuscation techniques, Mariano Ceccato,Massimiliano Di Penta,Paolo Falcarin,Filippo Ricca,Marco Torchiano,Paolo Tonella, Empirical Software Engineering, August 2014,Volume 19,Issue 4,pp 1040-1074
5. A New Code Obfuscation Scheme for Software Protection, 8th International Symposium on Service Oriented System Engineering (SOSE), 2014, Oxford, IEEExplorer, pp 409 – 414, DOI:10.1109/SOSE.2014.57
6. A taxonomy of obfuscating transformations , Collberg C, Thomborson C, Low D (1997). Technical Report 148, Dept. of Computer Science, The Univ. of Auckland
7. Protecting software code by guards. Chang H, Atallah M (2002) In: ACM workshop on security and privacy in digital rights management. ACM
8. Program obfuscation: a quantitative approach., Anckaert B, Madou M, Sutter BD, Bus BD, Bosschere KD, Preneel B (2007) In: QoP ’07: Proc. of the 2007 ACM workshop on quality of protection, ACM, New York, NY, USA, pp 15–20. doi:10.1145/1314257.1314263
9. Locating features in source code. Eisenbarth T, Koschke R, Simon D (2003) IEEE Trans Softw Eng 29(3):195–209
10. Deobfuscation: reverse engineering obfuscated code, Udupa S, Debray S, Madou M (2005). In: 12^th working conference on reverse engineering. doi:10.1109/WCRE.2005.13
11. Obfuscated Malicious Code Detection with Path Condition Analysis, Wenqing Fan, Xue Lei, Jing An, Journal of Networks, Vol 9, No 5, May 2014, doi:10.4304/jnw.9.5.1208-1214
12. Static analysis of executables to detect malicious patterns, M. Christodorescu and S. Jha, In Proceedings of the 12th conference on USENIX Security Symposium – Volume 12, Berkeley, CA, USA, 2003, pp. 12–12.
13. Software protection technology research based on code obfuscation, Song Yaqi, Northwestern University, 2005
14. Hong Luo, Jiang Jianqin, Zeng Qingkai. Code obfuscation techniques based on software protection, Computer Engineering, 2006, Vol 32 No. 11
15. A. Balakrishnan and C. Schulze,”Code Obfuscation: Literature Survey”, Technical report, Computer Science Department, University of Wisconsin, Madison, USA, 2005.
16. B. Anckaert, M. Madou, B. D. Sutter, B. D. Bus, K. D. Bosschere, and B. Preneel. ”Program obfuscation: a quantitative approach”, In QoP ’07: Proc. of the 2007 ACM Workshop on Quality of protection, pages 15-20, New York, NY, USA,2007. ACM.
17. Intellectual property protection using obfuscation, S. Drape et al. Proceedings of SAS 2009, 4779:133–144, 2009