We are now almost at the end of our journey. By now you should have a sound understanding of the overall principles of how to decompile, and hopefully, how to make some attempts at protecting your code. Having said that, I’ve found from clients and colleagues that even if you understand what decompilation and obfuscation really mean, it still doesn’t help you figure out what practical measures you can take to protect your code. A little knowledge can often create more questions than answers.

The Competency Centre for Java (JCC) shows an example of this on their deCaf web site FAQ:

So, in this chapter we’re going to look at some case studies to try to help you overcome this conundrum. Hopefully one of the cases will closely match your situation and help you come to a conclusion on how to best protect you code. Each of the case studies will have the following format:

• Problem description
• Pros and cons of the different options
• Solution

Case Studies

To help provide you with more practical insights into how to protect your code, we’ll now take a look at several case studies. Please note that the names of these companies have been changed to protect the innocent.

Case Study 1: To J2ME or Not to J2ME?

This case study looks at the implications of decompiling mobile Java code.

Problem Description

WAP Corp has the rights to an image rendering application written in C++ that it wants to port to Java so that it can be used on cell phones running the Java 2 Platform, Micro Edition (J2ME). Moving to Java will mean that they can roll out the application to many more phones than before because the Java Virtual Machine (JVM) offers a huge portability advantage over the previous proprietary systems. Multimedia cell phones have a significant market share in the US and an even larger market share elsewhere.

WAP Corp believes that this new application will present a real competitive advantage in speed and views the Java application as a significant part of their future revenue. However, if there’s one thing they don’t want to do, it is to allow their code to end up in the hands of any of their rivals, which would cause their competitive edge to evaporate.

WAP Corp sees the following as their only possible options:

• Performing obfuscation
• Moving to a server-based application
• Seeking legal protection
• Patenting the algorithm

Pros and Cons

Obfuscation is nowhere near 100 percent secure, but method overloading and code irreducibility are the most effective forms. However, when some form of code irreducibility is used, there is always the fear that the Java application might not pass the Java Verifier and might never get executed. Unfortunately, the application would have to be tested on all cell phones to ensure that it executed correctly after obfuscation, which would destroy the major portability advantage of moving to the Java platform. But if the code doesn’t use the strongest obfuscation possible, then it’s going to be decompiled with very little effort.

Moving to a server-based application would protect the code. But because of the bandwidth considerations, the information passing between the server and the client cell phone needs to be kept to a minimum. The cell phone needs to render the data. It has the processing power, and the application speed is largely built around a client-server architecture. However, sending the rendered data to the cell phone will eat up the bandwidth and add several hundred milliseconds to the time it takes to display the image.

Legal protections are only good after the fact. WAP Corp doesn’t want to engage in a lengthy legal battle, which could bankrupt it before the courts come to any agreement. Some of WAP Corp’s competitors have much deeper pockets so they could survive if they won or lost in court and can almost certainly afford better lawyers.

Patenting the algorithm would open it to the competition but would act as an extra revenue source if any competitors wanted to license it.

Solution

WAP Corp decided to employ a dual strategy: they obfuscated the code to provide some basic level of protection, but they also patented the algorithm in the US, Europe, and Japan because obfuscation would only offer “good enough” protection to keep out the casual hacker. The obfuscation had the added benefit of shrinking the deployed classfiles by 20 percent.

Case Study 2: Consultant’s Code

In this case study, we explore what happens when a consultant doesn’t want the client to have access to his or her code. We’re not exploring the reasons why, just how to meet the need to protect the code.

Problem Description

More often than not, a consultant’s code belongs to the client. But sometimes it is in the consultant’s interest not to give away the code. The consultants at Initiative Consulting are in just such a predicament; they have used the same inventory application code in many deployments. The last thing they want to do is allow the internal IT department at their present engagement to extend their code that has evolved over several engagements. Next year’s business plan includes a significant portion of revenue coming from releasing the application as a stand-alone product.

This web-based Struts application has a significant business component and is always deployed at the client site. If the consultants had used a scripting language such as Perl or VBScript, the code would be visible to anyone who has access to the web server’s directories. But from previous client’s support questions, it had become obvious over the past few months that their Java classfiles are being decompiled and extended.

Initiative Consulting’s main objective is to protect their intellectual property. They see their options as follows:

• Employ obfuscation
• Use code generation
• Use an Application Service Provider (ASP) model

Pros and Cons

Obfuscation has some major advantages for Initiative Consulting. This inventory application has only been rolled out to a limited number of clients and is not generally available. Assuming the obfuscator does more than simply rename the methods names, then it is unlikely that their clients would have the time or the expertise to decompile the obfuscated code. More importantly, it is very unlikely that the intellectual property would be compromised by any source code finding its way into the hands of any potential competitors. The one caveat is that the obfuscator would also have to be able to handle any maintenance upgrades for software patches that get applied from time to time.

When protecting intellectual property concerns are an issue, it can help to use code generation to move the code to a higher metadata level. Because this is a Struts application, each part of the front end code—web pages, forms, actions, and beans—could be generated from an XML definition file and converted into Java Server Pages (JSP) and Java. However, the majority of the business logic is in the business layer, which is not so easy to generate.

Moving the code to an ASP model where the client enters their inventory data into remote databases would protect the real intellectual core of the code, but Initiative Consulting would need to move to a different business model to support this new infrastructure. Web services Application Programming Interfaces (APIs) would also need to be developed so that clients could still integrate the code with existing applications. However, it would still be a hard sell for any existing clients.

Solution

Initiative Consulting decided that an obfuscator that could handle maintenance releases would be the best solution for their needs. The risk of a single client decompiling the code was significant, but the risk of a client going to the trouble of trying to unravel obfuscated code was not seen as very significant. Although code generation and an ASP model were interesting to entertain, the cost would have been too prohibitive at this time.

Case Study 3: I Can’t Find My Code

Here we investigate how decompilers can help when the source code is inadvertently lost or deleted.

Problem Description

Somewhere in the world just about now, some developer or manager has come to realize that they’ve lost their code. That sinking feeling is in their stomach as they hear the scraping sound of the hard drive whirr, a sound as unmistakable as a loose fan belt in a car, a sound that tells them that their code is now toast. Even if the developer has good backups, it can take considerable time for their network department to retrieve the appropriate backup tape. And, of course, this always happens close to a deadline or after the original developer who wrote the code has left.

Usually this only happens once or twice and then the developer suddenly becomes very adept at backing up different copies of their code on a floppy, on a USB drive, on a CD, in Visual SourceSafe or CVS,¹ and so on. Those who have been badly hit often make multiple copies just to be sure. For many, this isn’t a joke and is a really painful experience that results in missing a very public deadline, or getting overlooked for a job promotion or, worse still, getting fired.

Sometimes, if they’re lucky, they’ve written all the code in Java and have access to recent classfiles, and suddenly, a decompiler becomes their new best friend.

Pros and Cons

Decompilers really do recover the majority of the code. Sure, the comments are gone, but the developer can often use the Javadoc help files for their classes to re-create them. Thankfully, as long as they didn’t obfuscate the code, it will be readable and will easily decompile.

Solution

The solution is to use a free decompiler that can be downloaded off the Web to decompile the classes. The only down side is that some of classfiles are apt to be a little out of date, but instead of losing countless hours of development time, if the developer uses such a decompiler, he or she will only loose a couple of days.

The bigger picture solution is to invest in a proper backup solution on the network and make sure that it is backed up and tested at regular intervals.

Case Study 4: See No Evil, Hear No Evil

In this case study, we examine the zero option or what happens if we completely ignore the decompilation and hope it goes away.

Problem Description

For many people, the fear of someone decompiling their Java application or applet is nowhere near the top of the list of things that they should do something about. It ranks way below installing the latest web server security patches. Sure, it’s something that they’d like to protect against, but nobody has the time.

There are two simple options in this scenario:

• Use obfuscation to protect the application.
• Ignore the problem because it’s not really a problem.

Pros and Cons

Obfuscation does raise the bar and stops most people from recovering your source code. The cost of decompilation is that you are giving away money spent on research and development.

However, there are many reasons to ignore the problem. It’s a common belief that if you write good applications, then the source will protect itself. Using upgrades and having good support are much better ways to protect your code than obfuscation or any of the other techniques discussed in this book.

Software development is about how you apply your knowledge, not about getting access to someone else’s applications. The original code these days probably came from a design pattern, so nobody cares if it’s hacked. And all developers, well the good ones anyway, can always think of a better way of doing something after it’s completed, so why worry?

Chances are that if someone is so unimaginative that they have to resort to stealing your code, then they won’t be capable of building on the code and turning it into something useful.

Surely the problem is that someone could crack the program, but that can happen on any platform. It’s not as if the newspapers are full of reports about people who decompile a product and rebadge it as their own, and we’re forever hearing about the latest Microsoft exploit, so it can’t be a problem.

Solution

Although I talk about reasons to protect your code throughout this book, it is often worthwhile to take some time to play devil’s advocate. The solution for many is to simply ignore the problem using the arguments I just laid out and to assume that it doesn’t even exist as a real issue.

Case Study 5: Ice Cream for Escrow²

Remember, there are other ways of protecting your code other than simple obfuscation. Here, we take a look at protecting your code legally by housing the code using a third-party company that specializes in escrowing code.

Problem Description

T & C Solutions had a profiling application that they wrote in 100-percent Java to take advantage of Sun’s marketing push in the late 1990s for pure Java applications. T & C knew that obfuscation only provided limited protection, so they wanted to explore some alternative options.

The options that they saw open to them were as follows:

• Source code escrow
• Encryption
• Fingerprinting

Pros and Cons

Source code escrow is typically an agreement created as a client safeguard in case the consultant company goes out of business or some disaster occurs that makes it so they can no longer support the code. However, escrow is also a fairly simple legal option that you can use to protect your intellectual copyright. The source code can be mailed to your attorney by registered mail. This dates the source code in case any future litigation arises concerning who first produced the code. Also, several third-party companies such as Iron Mountain³ will allow you to upload product code in a much more structured web-based environment.

In Chapter 4, I covered why encryption wasn’t the best defense against decompilation—sooner or later the classfile has to be unencrypted. With custom classloaders, it is always possible that a hacker can gain access to the bytecode. However, you can use the Digital Millennium Copyright Act (DMCA) as a defense because it makes it a crime to circumvent any anti-piracy or encryption mechanisms. So the very act of classfile encryption makes it a crime under the DMCA. However, be aware that you’ll also experience a considerable performance hit if you unencrypt the code at runtime.

It’s worth noting that obfuscation could be considered an anti-piracy mechanism; this means that anyone decompiling obfuscated code may be subject to prosecution under the DMCA, but that has yet to be tested in court.

I also covered fingerprinting in Chapter 4, which is where a copyright notice or watermark is applied to the binary code using a fingerprinting tool. This tool encodes the information in a dummy method that never gets executed. The fingerprint can be recovered at a later stage if the code was decompiled and then added to another application. Unfortunately, the hacker can strip the dummy method from your application, thereby removing the fingerprint.

Solution

T & C Solutions decided to escrow the code using a third-party web-based system. This was used in conjunction with a series of fingerprints within the source code so that the code could be matched to the exact source code held in escrow, just in case anyone tried to repurpose the original source.

Conclusion

When the idea for this book was first conceived, it seemed that Java applets were going to take over the Web and march all over web pages as we knew them. But this never happened. The inevitable problems with download speeds and probably most importantly, the look and feel of a Java applet all conspired to turn Java applets into little more than a niche market on the World Wide Web.

Having said that, Java has outgrown its early roots and is very unlikely to disappear any time soon. As a language, Java is quite rightly in the top tier and is used in web-related and network applications and, more increasingly, in standard desktop applications where its object-oriented nature appeals to a different audience than, say, Visual Basic. It seems that Java has found itself a nice fit somewhere between the complexity of C and C++ applications. Applets have given way to applications and servlets, which of course, cannot be easily downloaded and decompiled. But Java classes, inside or outside of a jar file, still need to be distributed whenever Java programs are sold as shrinkwrapped software, and so they are still just as susceptible to decompilation.

The security restrictions on Java applets are, not surprisingly, pretty intense—an applet has to get by the Java bytecode Verifier before it can run within the protected applet sandbox. The class loader and the Java Verifier conspire to make it even harder to obfuscate Java code. Many obfuscators and bytecode manglers fail to get past this stage, and so they are pretty much useless at protecting your applet code (classfile encryptors are particularly prone to this problem). However, now that we’ve all moved to a more application-centric class model, there is much more scope for protecting your Java code, that is, assuming your code does not have to pass through a Java Verifier.

Having said that, no matter what anyone tells you, although there have been some significant developments in protecting bytecode, as yet, the only secure way of protecting your code is to compile it into an executable. Sun and others will tell you that executables are not exactly safe from decompilation either. But it is several orders of magnitude more difficult to decompile an executable than it is to decompile intermediate bytecode. Unfortunately bypassing bytecode and converting it into native format destroys any portability you might hope to have because it can no longer be used on any other platform or operating system. You may then find yourself asking the question “Well, why on earth did I write it in Java in the first place?”

Will this change in the near future? Well, I may be tempting fate, but I have to feel that the JVM design will be fixed. It has taken a number of years to write this book, and during that time, nothing has changed fundamentally with the design. New keyword and constructs will always have to be added to the decompiler, but the basic architecture of the JVM will remain the same. So, unlike other programming books, I suspect that, because of backward compatibility issues, the Java classfile is always going to be susceptible to decompilation.

The whole premise of this book is to show individual users how to decompile code from Java classes and what protection schemes are available and what they actually mean. In general, people are much more curious than fraudulent, and it is highly unlikely that anyone will use a decompiler to steal a software company’s crown jewel. Instead, they just want to take a peek and see how it all fits together—Java decompilers enable the average programmer to look much further into what are normally just black boxes. This book helps the user peek over that edge.

You might wonder where to go next. Things I’d suggest you try from here are using the JLex and CUP code in the downloads area of the Apress web site to try and extend the code if it doesn’t decompile your particular classfile. There are also several open-source decompilers available on the Web, such as JODE, which also provide a wealth of information.

I’ve tried my best to make this book easy to read. I’ve consciously decided to make it more practical than theoretical while still trying to avoid making it just an introduction to decompilers by including and analyzing a working decompiler. I hope it was worth the effort on my part and yours, and just remember, things change fast around here, so keep an eye on the Apress website⁴ for further updates.

___________________

¹I never knew that CVS stood for Concurrent Version Systems until the editor made me look it up.

²With apologies to Captain Beefheart.

³http://www.ironmountain.com

⁴Or http://www.decompilingjava.com