There are many good books written on Java. It sometimes amazes me how many books you can see on the same subject. Searching on www.amazon.com for a book on Enterprise JavaBeans (EJB) returns more than 50 results. Come on, people! EJB is a complex technology and today every self-respecting Java developer has to have it on his resume, but 50 books? So, what right do I have to add another tome to the Java bookshelf? Well, I believe that there are a few less-publicized development techniques that, when used correctly, can yield astonishing results. Most of the methods deal with core Java concepts and issues and therefore can be used in a variety of applications. The techniques presented in this book are unorthodox solutions to common problems in Java development. Some of them are controversial and should be used with great care, but all of them are powerful methods of achieving what you want. Learn them, and you will be able to separate yourself from the majority of other developers by delivering a solution when everyone else is grasping to understand what the problem really is. You might have used some of the techniques presented in this book already, and I congratulate you if this is the case, but I am confident that you'll pick up at least a few helpful new tricks as you peruse the advice I give here.
A large portion of the book is dedicated to techniques that are commonly considered to be hacking. Hacking is used rather freely in the media and oftentimes with negative connotation. Hackers are frequently portrayed as crazy geeks wanting to boost their self esteem, and for some cases this is certainly true. The methods presented here, however, are intended for professional software developers and each technique has a real-life application.
Java developers and architects stand the best chance of learning the most from this work. To truly appreciate the problems and solutions presented in this book, you should have completed at least a few significant Java applications and worked with third-party code. That is not to say that junior developers have nothing to gain from this work. To keep the book concise and focused on the main topics, little coverage is given to the subjects that are expected to be well-known or well-documented. For example, when talking about hacking non-public class members, the book does not explain the limitations imposed by each visibility modifier. Such information can be easily obtained from the Internet or books that cover these topics in detail. Covert Java: Techniques for Decompiling, Patching, and Reverse Engineering is about extreme techniques that punch through the commonly expected boundaries.
It is worth noting that the techniques presented here are largely independent of one another. Because the presentation of the material follows a “most common simpler methods first” order, feel free to skip chapters and go directly to the one you are interested in. Chapter 1, “Getting Started,” has a section that briefly describes each of the techniques and when to use it, so I recommend familiarizing yourself with it first.
Most of the chapters are strictly technical, but it is extremely important to understand that not all the techniques can be freely applied when working with applications. Not every approach presented in the book is “hacking” but, if used without first checking the legal consequences, it can certainly get you in trouble. Let's start by trying to give a broad definition of hacking and then look at how to tread that treacherous water.
Merriam-Webster's dictionary has the following definition for the term hacker: “an expert at programming and solving problems with a computer.” However, there is another meaning given right after it: “a person who illegally gains access to and sometimes tampers with information in a computer system.” Being an expert at programming is certainly a great thing; fiddling with illegal stuff lands you in jail. The short message is that this book is for the good guys, and if you are a bad guy, please stop reading right now and get a new job with the testing team. Any information or discovery can be used for good or ill. It is not the information but the use of it that determines whether the outcome is considered positive or negative.
By now, there have been a number of high-profile court cases revolving around digital copyrights, reverse engineering, and patent violations. Companies and individuals have lost millions of dollars and sometimes reputations as well. Although the laws are complex and the license agreements are written by lawyers for lawyers, it is not that difficult to steer clear of legal problems. Here are the two basic rules to follow:
If an author expects you to pay for her work, do so.
If you are tinkering with something, be sure that it does not hurt the author's interests.
Simple and effective. The first rule is very easy to understand, but the second is the one that is important to remember when applying the methods presented in the book. For example, if you reverse engineer someone's code to find a workaround for a bug, the author isn't likely to prosecute you. However, if you reverse engineer someone's code and make a competitive product based on the same unique principles, you are most likely to see the author in court.
It is important to remember that the software we are working with is written by people just like you and I, and just like you and I they have to pay bills. Open source is a different phenomenon, and because the source code is freely available, you don't need to use extreme methods to learn something about or change something in the product. But most of the software developed today is commercial and most of the innovation is done by commercial vendors. Hacking the software to avoid paying the license fees is counterproductive because it undermines the software market and indirectly hurts the developers. Stealing ice cream from a shop next door will either raise the price of the ice cream or drive the shop out of business. And if you own a bakery, the owner of the ice cream shop might start stealing cookies from you.
The two rules cover the moral aspects of hacking, but what generally covers the legal aspects are the copyright and intellectual property laws and end user license agreements (EULAs). The laws are complex and not easy to read, but EULAs are a must because they generally are more restrictive than the laws. They are written to provide the author with the protection that might not be adequately granted by the respective laws, and users are generally required to explicitly agree to the terms of the agreement before using a product. For example, even though reverse engineering is not prohibited by law, most software products forbid it in the EULA. It is therefore imperative to thoroughly study the EULA before using the techniques described in this book on a product. To avoid repetition and to keep the contents of the book strictly technical, the material of the chapters does not mention the legal aspects associated with the techniques. It is your responsibility to ensure the legality of your actions.
Several typographic conventions are used in Covert Java: Techniques for Decompiling, Patching, and Reverse Engineering to make the text more readable. Italic font is used for emphasis and to indicate new terms. Monospace font is used for parts of code, filenames, and URLs. Monospace italic font indicates placeholders in code syntax.
In addition, a few special elements are used in this book. “Stories from the Trenches” describe my own experiences in working with the various techniques described throughout Covert Java: Techniques for Decompiling, Patching, and Reverse Engineering to help you understand how these techniques work out in actual practice. Each chapter ends with an “In Brief” section summarizing the main points of the chapter, as well as a quiz section to help you review the material.