Home page logo
/

webappsec logo WebApp Sec mailing list archives

Code Cracking in Java
From: Chitresh Sen <chitresh_sen () yahoo com>
Date: 12 May 2004 06:35:07 -0000




Code Cracking in Java

Scope 

This is not a pure technical paper but I would like to share one of my discovery in Java Security which I had done 
during one of my assignments and it was greatly appreciated by the client because my finding help them to develop a 
strong business case to convince top management for discarding the product. The following document provides some 
loopholes in Java and how they can be rectified. It also provides a guideline to the software designers while 
developing an application especially in Java.

Who can read this paper? 

Software developers, designers, security professional, auditors, managers responsible for evaluating products.  

About Me

Hi! I love programming in Java but unfortunately I didn’t get a chance to work in software development firm but I am 
very much happy with my profile, basically I am an ethical hacker currently working in Wipro and previously in PwC.  

Let me tell you about my experience in Java. During my third year of engineering I learnt Java. When I was about to 
join a fast track course at Concourse for Java my senior told me that socket programming in Java is hard to understand, 
that time I don’t know anything about Java so its OK for me. After the completion of course within one month I wrote a 
chat software in Java consisting of Socket programming and multithreading without reading any book. The teacher who 
taught me asked, could you share your code with me? Later on I had written some more applications for which I was 
rewarded. During my PG I was awarded for a project at national level, the project title was “Managing Network using 
Mobile Phone”. I had designed and developed the application in J2ME (Java 2 Micro Edition), the application allows 
system administrator to manage his network using mobile phone to some extent. Mr. Ashutosh Bhosle, Director of Try 
Catch Solutions, Pune gave the idea for the above project.

After my PG I was keen to join a software development firm but unfortunately or fortunately I had been selected in PwC 
in IT security and there were no software development. Initially I was frustrated because my core interest was 
programming and here I will never get a chance to work in Java. After some time I got a chance to work on cryptanalysis 
project in which I had written compromising code for checking encryption strength. Also I had done some research work 
in Java Security and consulted security features of Java, it was a great experience and this project gave me a new 
vision to work in Java security other then development. Now I start looking it in different manner that is how to 
exploit it loopholes. But for long time I didn’t get much chance to work in Java Security. 

Code Cracking 

After a year I got a chance to work in Java Security meanwhile I was doing assignments on Penetration Testing (PT), 
Vulnerability Assessment (VA), formulation of Information System Security Policy and some few small assignments. The 
Assignment, which we got, was basically a PT/VA but the client also wants a PT for their Internet Banking Application 
(IBA). 

Note: For security reasons I will not mention client name, application vendor and detail about the application 
architecture. Also a person having basic knowledge of Java can best understand the following text.

The IBA was developed in Java and it is downloadable from Internet. The real code cracking starts from here. Client has 
provided us some test user ids for testing the application. Our objective was to find the loopholes in IBA and try to 
explore that how an authorised user can misuse the application.

As we commonly know that the basic loophole in Java is that it can be reengineered from class file to source code, the 
class file consist of byte codes which is interpreted by Java Virtual Machine (JVM) to make Java platform independent. 

The IBA was vulnerable and I can convert any class file of application into source code and view its logic, but the 
application consists of almost 1400-1500 class files and it is required to understand the logical flow of application 
and find out how it behaves. I find out the first class file, which start the application and decompiled it and tried 
to understand its flow. Frankly speaking its very hard to understand others code and it requires lot of patience and 
dedication. Anyway while browsing through a bunch of class files I found some interesting class files where input 
validation checks for password min/max length, special characters etc were implemented. Only thing I have to change the 
reengineered class file as per my requirement and recompiled and repackaged it so that the application works as per my 
requirement. I did the same but the application didn’t start normally, I again tried but it didn’t work. Later on I 
found that they had implemented Secure Class Loader 
 which doesn’t allow repackaging a modified class file. 

Now what to do, initially I was thinking I have achieved a lot and I can screw the application very easily. Later on I 
got an idea from my previous experience, during one of my assignment I had changed the FTP banner by modifying its .dll 
file using HEX editor. The idea was vague to change the class file directly into HEX Editor but what to change in class 
file because I don’t know anything about class file. Anyway I accept the challenge because I don’t have any option. 
First of all to change class file I have to understood the class file structure, its very much logical if you want to 
play with low level language you have to understand its format, somehow I manage to understand it. Also I had gone 
through the JVM specification. It was interesting and I was enjoying it but I had a time constraint so I have to be 
serous. 

After having an understanding of Java class format, the next challenge is to find out which byte to change. The byte 
codes are nothing but the assembly language instructions, which are interpreted by JVM at run time. In order to find 
the exact byte it is required to know the opcodes of JVM instructions. Then I found a list of JVM Instructions opcodes 
with their mnemonics. Now the next challenge was to search for exact byte in the class file for manipulation. 

Let me explain with an example. Let’s say a programmer written a following if condition for checking minimum length of 
password in one of the source file.

 If (pwdTextField.length() <= 6 )
 {
   Then
       Error – Password Length should be greater then 6 Characters
   Else
       Proceed
 }

Our aim is to change 6 to our requirement so that we can bypass the minimum password length check. For this we required 
to see the byte code in readable assembly language form. Byte Code Engineering Library helps us to see the byte code 
into the assembly language instructions i.e. functions in stack form. I used this library to see the skeleton of class 
file in assembly language instructions and I can easily see the stack of functions and their calls. I found the 
instruction for the above if statement which is kind of bipush 6 instruction, and its equivalent opcode in hexadecimal 
format. The understanding of Java class file format helps to search the hex value in a specific part of class file. Now 
open a class file using a HEX Editor and search for the opcode, which we had found above. Once we had found the hex 
value change it and save the modified file.

The following snapshot reflects the above activities in technical form.

Following is an assembly language instructions of class file generated using BCEL.

………..
……..
…

protected boolean checkPwd(String arg1)
Code(max_stack = 2, max_locals = 2, code_length = 57)
0:    aload_1
1:    invokevirtual     java.lang.String.length ()I (113)
4:    bipush            6
6:    if_icmplt         #18
9:    aload_1

……………
…………
……..

The opcode of bipush mnemonic is 0x10 and 6 is represented as 0x06 in hex format. Now open the class file using Hex 
editor and search for 0x1006 in a specific part of class file and change it to 0x1000. Now the if condition will change 
to;
If (pwdTextField.length() <= 0 )
{
  Then
           Error – Password Length should be greater then 6 Characters
  Else
Proceed
}

After modification I started the application and it was running fine. I changed my test user ids password as 0 
character since there were no server side validation checks were implemented hence after the client side security check 
was manipulated the application allows me to keep password of any length. This way the minimum password length check is 
overcomed and similar process can be used to manipulate any checks implemented at client side. Now I have the key with 
me only thing I have to investigate the proper class files and understand its logic and manipulate it. Later on I had 
overcomed the special character checks which makes application vulnerable for SQL injection, further exploitation of 
which leads to the compromisation of database. 

I hope you have understood that what I had done more with the application.

In the above section I mentioned the vulnerabilities related to Java but these vulnerabilities can be taken care. 
Obfuscation can be used to scramble class files so that it becomes hard to understand the decompiled source code; there 
are tools available for obfuscation.

The solution for byte code manipulation can be taken care by implementing hashing for a package and before starting an 
application the hash should be calculated and compared with the server side precalculated hash, if both of them match 
then only allow further execution. Other way to solve the problem is to implement server side checks no doubt it will 
affect the performance of server.

Suggestions and Comments are Welcome!

Thanks!

Chitresh Sen
Email: chitesh_sen () yahoo com
 



  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault