Covert Java: Obfuscating Classes
- Protecting the Ideas Behind Your Code
- Obfuscation As a Protection of Intellectual Property
- Transformations Performed by Obfuscators
- Knowing the Best Obfuscators
- Potential Problems and Common Solutions
- Using Zelix KlassMaster to Obfuscate a Chat Application
- Cracking Obfuscated Code
- Quick Quiz
- In Brief
This chapter is from the book
This chapter is from the book
This chapter is from the book
"Any sufficiently advanced technology is indistinguishable from magic."
Murphy's Technology Laws
In this chapter
-
Protecting the Ideas Behind Your Code
-
Obfuscation As a Protection of Intellectual Property
-
Transformations Performed by Obfuscators
-
Knowing the Best Obfuscators
-
Potential Problems and Common Solutions
-
Using Zelix KlassMaster to Obfuscate a Chat Application
-
Cracking Obfuscated Code
-
Quick Quiz
-
In Brief
Protecting the Ideas Behind Your Code
Reverse engineering and hacking have been around since the early days of software development. As a matter of fact, stealing or replicating someone else's ideas has always been the easiest way of creating competitive products. There is, of course, a perfectly acceptable method of building on previous discoveries by others—and as long as the others don't mind, it works fine. Most inventors and researchers, however, would like to get credit and possibly a financial reward for their work. In simpler terms, they also have mortgages to pay and vacations to take.
A good way of protecting intellectual property is for the author to obtain copyrights and patents on the unique features of the work. This is certainly recommended for inventions and major discoveries that required a lot of investment into research and development. Copyrighting software is a rather easy and cost-effective process, but it protects only the "original" code of the application, not the ideas behind it. Others would not be able to take copyrighted code and use it in their applications without the author's permission, but if they have their own implementation of the same feature, it would not be considered a violation to use that. Patents provide a much better protection because they cover the ideas and algorithms rather than a specific implementation, but they are expensive to file and can take years to obtain.
Is the risk of having your application hacked real? If it has good ideas, then absolutely. Most of the widely publicized reverse engineering cases at the time of this writing did not occur with Java products, but here's an excerpt from a Java vendor (DataDirect Technologies):
ROCKVILLE, MD., July 1, 2002—DataDirect Technologies, Inc., an industry-leading data connectivity vendor has filed a lawsuit against i-net Software GmbH alleging copyright infringement and breach of contract. DataDirect Technologies is seeking both preliminary and permanent injunctive relief to prevent i-net from engaging in further efforts to market and sell products which DataDirect Technologies believes were illegally reverse-engineered from its products.
DataDirect Technologies claims that a competitor reverse engineered its product, and yet even today its product has only minimal protection from decompiling.
In the real world, copyrighting the code and getting a patent for an approach cannot provide adequate protection if a competitor or hacker can easily learn the implementation from the source code. The issues of legal protection are discussed in a separate chapter, but for now, let's focus on smart ways to protect the intellectual property (IP) of Java applications.