Securing Java-Based Mobile Agents through ByteCode Obfuscation Techniques

Syed Waqar Shah', P. Nixon2, R.I. Ferguson3, Syed Riaz ul Hassnain4, M. Naeem Arbab5, and Laiq Khan6

1, 4, 5Department of Electrical Engineering, N.W.F.P UET Peshawar, Pakistan.2 3University of Strathclyde, Department of Computer and Information Sciences,

Livingstone Tower, 25 Richmond Street, Glasgow GI 1XH, UK6Faculty of Electronics Engineering, GIKI, Topi, Swabi, N.W.F.P Pakistan.

Abstract- Mobile agents have the ability to relocate computationand then carry communication with their peers locally. The designand implementation of mechanism to relocate computationsrequires a careful assessment of security issues. If these issues arenot addressed properly, mobile agent technology cannot be used toimplement real-world applications. To address such issues thispaper proposes two code obfuscation techniques [1] for Java-basedmobile agents that are compiled into a platform independent bytecode format. These techniques will involve applying obfuscatingtransformations to the mobile agent's byte code in order to protectthem against malicious attacks. Consequently these techniques willprevent automatic software analysis tools, De-compilers, fromgenerating correct source code by introducing syntax and semanticerrors in the generated source code. The proposed techniques willbe applied on sample mobile agent's class files to examine theeffectiveness of the techniques in impeding reverse engineering.After obtaining the results, we will reveal the erroneous codesgenerated by the tested de-compilers.

Key words: Java, mobile agents, obfuscation, security.

I. INTRODUCTION

Mobile agents have the ability to relocate computationwhereby communication becomes local [2]. This transportationof computation and communication are not free of maliciousattacks. Hence the design and implementation of mechanism torelocate computation requires a careful assessment of securityissues. If these issues are not addressed properly, mobile agenttechnology cannot be used to implement real-world applicationslike e-commerce, mobile computing, etc.

We have a Java-based mobile agent framework -agentSpace-that facilitates the development ofmobile agents [3]. Java-basedmobile agents are platform independent and only need anagent-enabled execution environment at different nodes acrossthe network. The agent source code (ava file) is compiled in theintermediate byte code format, i.e., the class file format. A classfile contains a lot of information enough for easy reverseengineering [4]. When a host sends its Java-based mobile agent

to the other host on the network, it contains the byte code format.The receiving host may break all the laws and obligations byreverse engineering the agent code often with the help ofautomated tools, De-compilers, and make appropriate changesaccording to its needs, thus giving financial loss and breaking allthe ethical measures of the host who did all the efforts todevelop it [5]. More precisely, the developer places some sort ofprotection on the agent's program that may be removed by themalicious users. Most of this work has concentrated onembedding the license file or identification keys in the software,especially in commercial applications. The program containsthe code that checks for the presence of license file. In addition,the license file identifies the host to whom the agent was sent.This information can be used in a legal action against the userwho distributes the copies of the agent's software illegally.However, the attack on this type of protection is to reverseengineer the agent's code and remove the code that implementsthe protection or bypass the key checking, while leaving intactthe code that provides the core functionality.

For secure agent migration and communication with its peers,this paper proposes two byte code obfuscation techniques,namely, Un-letting the completion of statement and removingvariable and method names. The objective is to preventDe-compilers from generating correct source code by means ofapplying obfuscation techniques to the Java-based agent's bytecode. Successful program obfuscation will confer a number ofbenefits, including protection of secrets in an agent's program,license management for software, and provide software basedtamper resistance which will make reverse engineeringuneconomical and an uneasy task.

In the next section, we discuss briefly about codeobfuscation. In section 3, two different approaches of achievingcode obfuscation in Java are discussed along with theobfuscation techniques already suggested. Then in section 4, wepresent the two proposed byte code obfuscation techniques,namely, Un-letting completion of statement and removingvariable and method names for Java-based mobile agents. Insection 5, we present the discussion over the proposed byte code

1-4244-0794-X/06/$20.00 ©2006 IEEE 305

obfuscation techniques. And finally, the conclusions andrecommendations are drawn in section 6.

II. CODE OBFUSCATION

Code obfuscation transforms a program into anotherprogram that has an equivalent behavior but which is difficult tounderstand and read [6, 7, 8, 9, 10, 11]. Code obfuscation hasbeen proposed as the solution to problems such as protection oftransient secrets in programs, protection of algorithms, licensemanagement for software, protection of digital watermarks inprograms, software-based tamper resistance, and protection ofmobile agents [12].

III. APPROACHES TO OBFUSCATION INJAVA

Java programs can be obfuscated in two major ways, (i)Source code obfuscation and (ii) Byte code obfuscation [1, 13].

A. Source Code Obfuscation

Source code obfuscation is a technique to convert sourcecode into another source code that has the same behavior butharder to understand and read [1]. Several attempts have beenmade in this regard. A very simple technique is to renameidentifiers with more ambiguous ones. More viable methods ofsource code obfuscation are based on composite functions,which are Array Index Transformation, Method ArgumentTransformation, and Hiding Constant [14]. The obfuscationtechniques that are based on composite functions make thecomputation complex. Further the extensive use of thesetechniques makes the software to respond slowly. Some sourcecode obfuscation methods are directed at the object orientedconcept; Class Coalescing, Class Splitting, and Type Hiding[15]. Other source code obfuscation techniques may includefalse refactoring, restructure arrays, inline and outline methods,clone methods, split variables, convert static to procedural data,and merge scalar variables [16]. The obfuscation techniques thatwork over object oriented concept and other techniques likerestructure arrays, split variables, merge scalar variables maydistort the logic of the software. Hence, care must be taken intheir use. The employment of obfuscation techniques likeoutline methods and clone methods convert static to proceduraldata and enhance the size of a class file without providing anysignificant advantage. Inlining method results in an unresolvedmethod call when some other class calls the inlined method.

B. Byte Code Obfuscation

Byte code obfuscation is a technique where a Java class fileis transformed into another Java class file that has the samefunctionality in order to make reverse engineering practicallydifficult. It is an advanced form of obfuscation that makes byte

code harder to decompile or recompile. While every Java sourcefile can be compiled to byte code by a Java compiler, it ispossible to create class files which no Java compiler canproduce, and yet, which pass the Java Verifier with flying colors.Such class files are said to be deviant [17]. The purpose of bytecode obfuscation is to produce deviant class files, such thatwhen class files are decompiled it becomes difficult torecompile them. Therefore, the byte code file becomes moresecure against the reverse engineering. The approaches to makedecompiled program uncompilable are introducing illegalidentifiers, nested type name, and static methods versus instancemethods [18]. A simple approach to these techniques ofobfuscation is to rename identifiers of the classes, fields andmethods, removal of debugging information, encrypting stringliterals, and replacing instructions with other ones in order tomake the resultant source code more difficult to understand andread [19]. Removal of debugging information does not preventDe-compilers from doing their job. In fact, debugginginformation can be removed by Java compiler itself if it isrequested, and encrypting string literals and replacinginstructions with other ones may impose performance penalty.

IV. THE BYTE CODE OBFUSCATIONTECHNIQUES FOR JAVA-BASED

MOBILE AGENTS

Since the official introduction of Java ProgrammingLanguage in 1995, several De-compilers have been developedand most of them are freely available on the Internet. Two bytecode obfuscation techniques have been proposed with theintentions that the De-compilers will be unable to generatecorrect source code; the code will contain syntax and semanticerrors.

A. Un-letting Completion ofStatement

Like every language, Java Programming Language followsits own grammar [20]. A Java program contains variousstatements performing some intended functions. Thefundamental purpose of the proposed technique will be to breakthe statement into two parts, the left and right hand sides. Theright hand side will be computed, but its result will not beassigned to the left hand side immediately, rather some deadvalues will be incorporated after the computation of right handside and let them stay there until left hand side is used in someother statement. After it would be found that the left hand side ofthat particular statement will be used in some other statement,all those dead values incorporated in the byte code will beconsumed, and the computation resulted from right hand sidewill be assigned to the left hand side. In this way, the techniquewould becomes successful in breaking the grammatical rule thata statement cannot be broken into parts, which will lead tosyntax and sometimes semantic errors in the reverse engineeredcode.

A Java byte code is laid down with a standard format. The

306

methods that are implemented in the source code are convertedinto virtual machine instructions and are placed at a particularplace according to the class file format.

The byte code file will be traced for methods code and thetechnique will be implemented in the body of those methods.

Different De-compilers like DJ [21 ], and JReversePro [22],will be employed to demonstrate that the technique works. Thebyte code will be presented in XML format to make it easy tounderstand the byte code.

B. Removing the Names of Variables and Methods

Java class files follow a strict standard format. A Java classfile mostly contains a number of global variables and methods.According to the format of Java class file, the names of all themethods and global variable used in the class are listed in theconstant pool area of the class file. From the method's body,global variables and methods are referred with constant poolindexes; they are not called with their names. Method and globalvariable names are preceded with their length, number ofcharacters, in the constant pool area. De-compilers get thenames of global variables and methods from the constant poolwhile generating the source code from the class file. If thenames of global variables and methods are removed from theconstant pool with the restriction that they are not of the sametype, De-compilers won't be able to get sufficient informationand will not display the names of global variables and methodsin the generated source code. If the access attribute for a methodor a global variable is private, they can be removed from theconstant pool easily, because they are restricted to a single classonly. However, if the access modifier for a method or a globalvariable is public, protected, or no access modifier is defined,other class files need to be searched where these are used andremove their names from those classes as well. However,today's de-compilers are intelligent enough to detect names ofthe same variables and methods in the class file and replacethem with automatically generated names in the generatedsource code. So removal of names from the class file isrestricted to one global variable name and one method name,based on the frequency of their use in the class file.

As discussed above, names of global variables and methodsare preceded with their length in the constant pool. Thetechnique will be implemented, where the length would beupdated to contain the value zero and then remove the namefrom the constant pool.

V. DISCUSSION

After successful implementation of both proposedtechniques, there will be a need to show how the experimentedDe-compilers, the DJ, and the JReversePro, will behave andwhat syntax and semantic errors will be encountered in thegenerated source codes.

The first proposed technique seems to be better than the

second proposed technique, because it will not only producesyntax errors but also semantic errors, whereas the secondproposed technique only will produce syntax errors. The secondproposed technique seems to be efficient in terms of file sizebecause it will reduce the file size by removing the names ofvariables and methods. The first proposed technique willincrease the file size little bit by incorporating some dead valuesin the byte code, which could be compensated by applyingsecond proposed technique altogether.

VI. CONCLUSIONS ANDRECOMMENDATIONS

To thwart malicious reverse engineering attacks, two bytecode obfuscation techniques have been proposed. Thesetechniques will become successful in defeating automaticsoftware analysis tools i.e., De-compilers and will made reverseengineering extravagant. Further these techniques will enablethe mobile agents to have secure migration and communicationin a hostile distributed environment.

The proposed techniques will be implemented manually inorder to prove that the techniques are able to create obstacles inthe ways of De-compilers in order to prevent them fromgenerating correct source code. It is strongly recommended toimplement these techniques in the already built automaticobfuscation tools to perform byte code obfuscationautomatically rather than manually. It will save precious timeand hard slog that would have been done in applying thetechniques manually. The proposed byte code obfuscationtechniques would be applied along with other obfuscationtechniques to make the system more resilient to reverseengineering attacks. It appears as if there is an unending warbetween the De-compilers and the Obfuscators, so the needcrops up to develop new obfuscation techniques in order tomake software, especially software mobile agents, more secureand safe. Such measures will ensure the successful deploymentof mobile agent technology in real-world applications.

REFERENCES

[1] Jan M. Memon, Shams-ul-Arfeen, Asghar Mughal, and Faisal Memon,Preventing Reverse Engineering Threat in Java Using Byte CodeObfuscation Techniques. Proceedings of2nd International Conference onEmerging Technologies (IEEE- ICET 2006), Peshawar - Pakistan 13-14November 2006.

[2] Fuggetta, A., Picco, G., and Vigna, G. (1998). Understanding codemobility. In IEEE Transactions on Software Engineering, volume 24.

[3] Ferguson, R.I. and Grey, D.J., The agentSpace mobile agent platform.(Online) http://www.agentspace.co.uk, downloaded Aug. 2003.

[4] Low, D. Protecting Java Code Via Code Obfuscation. ACM Crossroads,New York, USA, 1998, Vol. 4, pp. 21-23.

[5] Naumovich, G. and Memon, N. Preventing piracy, reverse engineering,and tampering. IEEE Computer Society, 2003, Vol. 36, No. 7, pp. 64-71.

[6] Nolan, G. Decompiling Java, Apress, Berkeley, 2004.[7] Stytz, M.R. and WHITTAKER, J.A. Software protection: security's last

stand. IEEE Security and Privacy, 2003, Vol. 1, No. 1, pp. 95-98.[8] Bakken, D.E., Parameswaran, R., Blough, D.M., Franz, A.A., and Palmer,

T.J. Data obfuscation: anonymity and desensitization of usable data sets.

307

IEEE Security and Privacy, 2004, Vol. 2, No. 6, pp. 34-41.[9] Stytz, M.R. Considering Defense in Depth for Software Applications.

IEEE Security and Privacy, 2004, Vol. 2, No. 1, pp. 72-75.[10] Yamauchi, H., Kanzaki, Y., Monden, A., Nakamura, M., Matsumoto, K.

Software Obfuscation from Crackers' Viewpoint. Proceedings of theIASTED International Conference on Advances in Computer Science andTechnology, Puerto Vallarta, Mexico, 2006.

[11] Udupa, S.K., Debray, S.K., and Madou, M. Deobfuscation: ReverseEngineering Obfuscated Code. Proceedings of the 12th WorkingConference on Reverse Engineering (WCRE'05), 2005, pp. 45-54.

[12] D'Anna, L., Matt, B., Reisse, A., Vleck, T.V., Schwab, S., and Leblanc, P.Self-protecting mobile agents obfuscation report. Technical Report No.03-015, Network Associates Laboratories, 2003.

[13] Madou, M., Anckaert, B., Bus, B.D., Bosschere, K.D., Cappaert, J., andPreneel, B. On the Effectiveness of Source Code Transformations forBinary Obfuscation. Proceedings of the International Conference onSoftware Engineering Research and Practice (SERP06). CSREA Press,2006, pp.527-533.

[14] Ertaul, L. and Venkatesh, S. Novel obfuscation algorithms for softwaresecurity. Proceedings of the 2005 International Conference on SoftwareEngineering Research and Practice, Las Vegas, 2005.

[15] Sosonkin, M., Naumovich, G. and Memon, N. Obfuscation of designintent in object oriented applications. Proceedings of the 2003 ACMWorkshop on Digital Rights Management, 2003, pp. 142-153.

[16] Collberg, C., Thomborson, C., and Low, D. Breaking abstractions andunstructuring data structures. Proceedings of the 1998 InternationalConference on Computer Languages, 1998, pp. 28.

[17] Ladue, M.D. When java was one: threats from hostile byte code.th

Proceedings of the 20 NIST-NCSC National Information SystemsSecurity Conference, 1997.

[18] Chan, J. and Yang, W. Advanced obfuscation techniques for Javabytecode. Journal ofSystems and Software, 2004, Vol. 71, pp. 1-10.

[19] Rusu, D. Protection methods of Java bytecode. Proceedings of theNetworking in Education and Research International Conference, 2003.

[20] Gosling, J., Joy, B., Steele, G., and Bracha, G. The Java LanguageSpecification, Third Edition, Addison-Wesley, 2005, 651 pp., ISBN0321246780.

[21] DJ Java Decompiler, http://members.fortunecity.com/ neshkov/dj.html[22] JReversePro Decompiler, http://sourceforge.net/projects/jrevpro.

308