Decompiling Classes, Replacing & Patching Core Java Classes

Discussions

News: Decompiling Classes, Replacing & Patching Core Java Classes

  1. Sample chapters from Covert Java, by Alex Kalinovsky, have been made available for download. The 'Decompiling Classes' chapter provides a list of popular Java decompilers and shows you how to decompile a class using JAD. 'Replacing and Patching Core Java Classes' looks at how to patch core Java classes using the boot class path, and shows you a simple patch to java.lang.Integer.

    Read Decompiling Classes and Replacing and Patching Core Java Classes

    Threaded Messages (49)

  2. BLANK PDF[ Go to top ]

    Hum,... PDF is blank
  3. Sample chapters from Covert Java, by Alex Kalinovsky, have been made available for download. The 'Decompiling Classes' chapter provides a list of popular Java decompilers and shows you how to decompile a class using JAD. 'Replacing and Patching Core Java Classes' looks at how to patch core Java classes using the boot class path, and shows you a simple patch to java.lang.Integer.Read Decompiling Classes and Replacing and Patching Core Java Classes
    Unless you are in IT land and don't have to worry about distribution, "Replacing and Patching Core Java Classes" violates the Java license.

    Bill
  4. <quote>Unless you are in IT land and don't have to worry about distribution, "Replacing and Patching Core Java Classes" violates the Java license.</quote>

    I don't think Sun gives a damn. Really.
  5. I don’t know how legal or illegal it is, but if some one has access to the java command line then the AOP would be much cleaner, I guess.
    On the other hand all this decompiling stuff is good for cracking licenses and other stuff like that which forces vendors to obfuscate the code and so on. I would actually prefer if java byte code would be hard or even better impossible to decompile in the same way as C/C++ programs.
  6. I don’t know how legal or illegal it is, but if some one has access to the java command line then the AOP would be much cleaner, I guess. On the other hand all this decompiling stuff is good for cracking licenses and other stuff like that which forces vendors to obfuscate the code and so on. I would actually prefer if java byte code would be hard or even better impossible to decompile in the same way as C/C++ programs.
    People have been cracking c/c++ programs forever so that doesn't seem to be a valid enough argument to take away a really handy tool.

    It is not illegal to decompile code, just to copy it. For example, the documentation for BEA's portal 7 was really weak in certain areas when I was trying to get it working at a client. By decompiling some of their sample code (that didn't have source provided) I was better able to understand how they used their own apis.

    Decompiling is an essential learning tool.
  7. It is not illegal to decompile code, just to copy it.
    It is not illegal to decompile code *and* it is not illegal to copy it. Copyright infringement only occurs if you distribute copies.
  8. But, if the aspects are coded in Java, and therefore need the java.lang pachage loaded, how are you going to intercept them? You could use a dymanic proxy implementation and create all instances from a custom factory, but that'd be a pain. Regardless of the implementation details, modifying the core classes would always be a very bad idea.
  9. Java Virus[ Go to top ]

    Great, the next chapter will be "how to create java viruses/trojan"...
  10. Totally stupid idea[ Go to top ]

    To patch Sun's classes is really stupid. It seems like the author is insane.
  11. I think most licence agreements for commercial software include clauses regarding 'reverse engineering' - decompiling == violation of this agreement.
  12. I think most licence agreements for commercial software include clauses regarding 'reverse engineering' - decompiling == violation of this agreement.
    You may find terms like this in a EULA (End User License Agreement), but these are of highly questionable validity. However, this has nothing to do with a copyright license which, by definition, exists to define the constraints under which software can be distributed (i.e. the license only applies if you are distributing the software).
  13. IANAL but you'll find that decompiling etc. is looked at differently in different jurisdictions. For example, in Europe (at least a few years back) it would have been very defensible to decompile software that you had paid for, if it had a problem that impacted your business in an immediate manner and they couldn't fix it in an immediate manner. In other jurisdictions, such as the USA with DCMA, if the vendor wishes to pursue a case, it could be quite serious.

    I wish vendors could just ship their source code, but unfortunately there are few protections for their work, other than copyright itself, which really does not protect much at all.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  14. I wish vendors could just ship their source code, but unfortunately there are few protections for their work, other than copyright itself, which really does not protect much at all.
    Really? Perhaps there are many examples in which copyright has failed to adequately protect against unauthorized redistribution of source code, but I can't think of one. There are some cases in which companies have incorporated someone else's source into their product and distributed it in violation of the license, but copyright law has generally been proved a capable means of dealing with this situation.
  15. As long as you don't copy the source word for word (digitally or otherwise,) copyright offers no protection. I can read a piece of source, look at how it works, have it up on one screen while I write my own "version" on another, and it is not a violation of copyright. (IANAL but this was explained to me by lawyers.)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  16. I can read a piece of source, look at how it works, have it up on one screen while I write my own "version" on another, and it is not a violation of copyright.
    In the circumstances where this might be a problem then it is because the source contains Trade Secrets and so that law would be provide the relevant protection.
    Obviously these must not be disclosed, so in the case where you want to supply the source but have protection against people reimplementing an idea that it embodies then you're looking at software patents.
    However, it is extremely unusual that patented software ideas are actually worthy of such protection and extemely usual that the law is simply used to prevent interoperability (with patented "standards"). These patents are also often handed out to anyone with the gall to apply for a monopoly on a basic and already well-understood idea.
  17. In the circumstances where this might be a problem then it is because the source contains Trade Secrets and so that law would be provide the relevant protection.
    Obviously these must not be disclosed, so in the case where you want to supply the source but have protection against people reimplementing an idea that it embodies then you're looking at software patents.
    However, it is extremely unusual that patented software ideas are actually worthy of such protection and extemely usual that the law is simply used to prevent interoperability (with patented "standards"). These patents are also often handed out to anyone with the gall to apply for a monopoly on a basic and already well-understood idea.
    Unfortunately, patents are of questionable use, and often take longer to write than the software that they protect. Further, they are only valid for the country that they are acquired in, and getting a patent that protects in the "major" markets of the world is a US$300k undertaking.

    It is unfortunate, all in all. I had many conversations with our own lawyers, trying to figure out how we could ship full source code yet be protected from people just blatantly stealing our implementations, yet they couldn't provide any real form of protection.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  18. It is unfortunate, all in all. I had many conversations with our own lawyers, trying to figure out how we could ship full source code yet be protected from people just blatantly stealing our implementations, yet they couldn't provide any real form of protection.
    In practice, good implementations are scarce and the basic ideas are common. Therefore copyright is probably a perfectly adequate protection for your software.
    It is also worth questioning how much control can be reasonably asked of society, rather than opportunistically grabbing all potential legal means available (as has happened with the use of software patents).
  19. Copyright covers a very, very narrow range - in fact it is almost a literal one. Change a song or a story with mechanical translation and you may make the work non derivative - but you ruin the work in the process. Change source code mechanically and you may make it a non-derivative work - but functionally equivalent to the machine running it.

    In music and movies and novels you can't make substitutions and switch pieces around because the details of the copyrighted work _are_ the work. Change those things and you're fiddling with the fundamentals. But you _can_ change software in this manner so that the "new" work no longer resembles the original one in source form - but it does almost exactly the same thing - exact enough that the end user of the binary may not notice a difference.

    To put it another way - the value in a Tom Clancy novel isn't the plot or the characters - it's the specific words and phrases he uses to create the novel. But the value in a software program isn't the exact phraseology of classes/variable names/source file layout, it's in the underlying semantics. Translate a Clancy novel from English-->Chinese-->Indian-->French-->English and the end result will be a disaster. But you could do such translations to software and have a totally different looking program that does _exactly_ the same thing as the original. Refactoring IDEs are a simple example of this.

        -Mike
  20. Change a song or a story with mechanical translation and you may make the work non derivative - but you ruin the work in the process. Change source code mechanically and you may make it a non-derivative work - but functionally equivalent to the machine running it.
    Realistically though, I don't think that much software contains another person's/company's source code that has been mechanically translated into a relatively unrecognisable state. It would be unmaintainable and someone redistributing such code would be inviting suspicion.
  21. Realistically though, I don't think that much software contains another person's/company's source code that has been mechanically translated into a relatively unrecognisable state. It would be unmaintainable and someone redistributing such code would be inviting suspicion.
    I think you missed the point. Let's try again - think about a refactoring IDE, changing class names, stripping comments, changing variables. You can show many alternative source formats, including slightly different class structures and relationships, that all boil down to the same runtime code.

    Right now I'm in the middle of some refactorings of my own code. I'm making minor cleanups and also switching some areas of responsibility in the code, changing APIs around a little and that sort of thing. It's very little work, and doesn't really change the runtime behavior. But the source looks very different.

    Pick an open source project. Any will do. Take a look at the source code. Think how you could change it in such a way that your changes would not be covered under copyright law. It's honestly not very difficult. More importantly - this sort of change doesn't break code - but it _does_ break the works that copyright law was founded upon (music, novels, etc).

        -Mike
  22. Cameron:As long as you don't copy the source word for word (digitally or otherwise,) copyright offers no protection. I can read a piece of source, look at how it works, have it up on one screen while I write my own "version" on another, and it is not a violation of copyright. (IANAL but this was explained to me by lawyers.)

    That's interesting. I've spoken with lawyers and they say just the opposite depending on the underlying license agreement. Hence the need for "Clean Room" versions of software to avoid IP issues. (You get interviewed under oath that you didn't see any of the source code of the software that you are providing a "version").

    As a side note, this idea of patching core classes and Third-Party AOP cross-cutting concerns brings up more legal and business issues. After applying the core patch or AOP pattern, who is responsible for the Service Level Agreement(SLA), the original vendor or the patcher? Patching the Core Java Classes seems to violate any warranty or SLA agreements that would be in place. As far as AOP, one third party crosscutting another third party's code brings up all sorts of legal problems.
  23. That's interesting. I've spoken with lawyers and they say just the opposite depending on the underlying license agreement. Hence the need for "Clean Room" versions of software to avoid IP issues. (You get interviewed under oath that you didn't see any of the source code of the software that you are providing a "version").
    A cleanroom approach makes it _easier_ to defend yourself against lawsuits. It does _not_ mean that a non-cleanroom approach is not viable.

    There are also pragmatic considerations here. Wall Street is perhaps the best example because its so incestuous. Really good programmers on the street have excellent mobility because they often take the knowledge of what they did for company X and apply it to company Y - to give Y the same competetive advantage that X has for some IP that they own. This programmer will create a big bunch o' IP for company X and then go and effectively do exactly the same thing for company Y. The same thing happens in product areas. Don't think for a moment that IBM doesn't get copies of BEA stuff, and vice versa, with Oracle and other vendors getting into the act at the same time - and that open source people don't do the same. They copy each other's ideas all the time and people are not adverse to "playing" with other people's code (don't say reverse engineering :-). Providing source code would just make this much much easier to do. Lawsuits almost never happen because "infringement" is so hard to prove for something like computer programs.

    A clean room approach is a way to create something new that's fairly unassailable from a legal standpoint. This doesn't mean this is the only approach. People can (and do) take non-cleanroom approaches all the time, and rarely get caught out on it. It may not be as unassailable as a true cleanroom approach, but it's almost as difficult to go after someone for this in practice.

        -Mike
  24. Cameron: "have it up on one screen while I write my own "version" on another, and it is not a violation of copyright"

    There are so much misunderstanding and superstition about code copyright.
    What you say is the plain truth. All this talk from Open Source about "a complete rewrite" is completely bullshit and hypocrisy. Having the old code while writing the new saves 90% of the work. That is how why Open Source succeeds so well when they "copy". But never can make a product of their own.

    A company invests a large amount of time, money and resources to develop a product and the somebody comes along a do "a total rewrite". ;)

    Did somebody mention Linux?

    Obfuscating your code should be routine to make it at least a little more difficult. But you can never protect yourself against an employee that runs away with code.

    Regards
    Rolf Tollerud
  25. Who is copying?[ Go to top ]

    Rolf,

    You have thrown this accusation of OSS developers stealing people's code for quite some time. To whom are you referring? What OS projects were developed from stolen code?

    Ryan
  26. who is copying whom?[ Go to top ]

    "To whom are you referring? What OS projects were developed from stolen code?"

    Ryan, I am referring **ALL** Open Source projects of some substance (dismissing small projects like xDoclets).

    So I will put it the other way around. Please mention one(1) big Open Source project that in your opinion is not "stealing" so will I do some detective work.

    Regards
    Rolf Tollerud
  27. Who is copying whom?[ Go to top ]

    Rolf,

    I guess we need to agree on what "stealing" is. Do you mean implementing similar features or do you mean decompiling the class files and ripping off source code? The former is not stealing.

    In either case, I would be curious to here your thoughts on...

    1. Tomcat - as the RI, from whom would they be stealing?
    2. Hibernate
    3. Spring

    If these projects "stole", from whom did they steal and what exactly did they steal. If Hibernate "stole" in your mind, did they provide similar features as other existing ORM tool (e.g. TopLink) or did they blatantly copy source code? Again, if it is the format, this is *not* stealing.

    In other words, do you have evidence or is this FUD? Because if you are acussing the above projects of stealing code (which you implicitly did when you indicted all "OS project of some substance"), that is a pretty bold claim with nothing to back it up. I doubt you will back it up.

    Ryan
  28. 1) Tomcat. They tried first to make their own but after a while throw it away to started anew with a copy of Java Web Server from Sun.

    2) Hibernate. OR tools are completely commodized. What Gavin did was to "apply the principle of KISS".

    3) Spring. They started with the code from Rod Johnson’s book which he donated to the project.

    So in none of the cases did they start from scratch even if in these cases they did not have to "steal", but they still were copying.

    Regards
    Rolf Tollerud
  29. 1) Tomcat. They tried first to make their own but after a while throw it away to started anew with a copy of Java Web Server from Sun.
    2) Hibernate. OR tools are completely commodized. What Gavin did was to "apply the principle of KISS".
    3) Spring. They started with the code from Rod Johnson’s book which he donated to the project.

    So in none of the cases did they start from scratch even if in these cases they did not have to "steal", but they still were copying.
    Why does you crazy "everything is OS software is stolen" principal only apply to OS software? Isn't .NET stolen by your standards?

    Ryan
  30. Very nice Rolf, so we have three more cathegories adding to your original "OSS from stolen source":
    - "OSS derived from a source received from Sun"
    - "KISS OSS" (it's a concept quite difficult to grasp, could you be more specific, Rolf ?)
    - "OSS derived from a source illustrating a book, with author's acception"
    It is however interesting to note that none of the three cathegories qualifies as "stealing", which was in fact the subject of your previous post (to quote you "**ALL** Open Source projects of some substance [...] are total rewrites of code taken home by commercial entities employees"). Thus, I have to logically infer that your previous post was wrong.
    Hmm, maybe you should note that somewhere, just in case - for future debates ;)
  31. That is how why Open Source succeeds so well when they "copy". But never can make a product of their own. A company invests a large amount of time, money and resources to develop a product and the somebody comes along a do "a total rewrite".
    What are you talking about!? You seem to be implying that Open Source projects that ape functionality available in pieces of proprietary software do so by subtly rewriting the source of those products. This is nonsense because the proprietary source is not usually available for inspection.

    Successful Open Source projects rely on a clean, well-understood, design because that benefits the collaberative approach. If you take a look at the source it is usually clear that, whilst in a few cases the overall functionality may bear some resemblance to a proprietary program, the design of the structure and individual units of code are original.
  32. nonsense?[ Go to top ]

    Peter,

    the proprietary source is not usually available for inspection

    The problem here in TSS many times is that you don not know if someone is just naive or a bonafide hypocrite. Well I assume the former so my advice is, try to read books and go to the theater and otherwise learn about The Human Nature, especially the tricks and things they is capable to when they imagine them working for a good cause.

    The answer is: People take the code home from work and keep it when they switch job.

    The only thing they need to think about is not copying word-for-word, and of course, after the code is released as Open Source" it is further enchanted and changed so after a time it is impossible to recognize the original.

    Regards
    Rolf Tollerud
  33. nonsense?[ Go to top ]

    The answer is: People take the code home from work and keep it when they switch job.
    Odd world you live in Rolf. I have been in this business for some time working with a lot of different developers and companies and I can safely say that I never have, and I'm pretty certain that next to none of my colleagues have taken company code home.

    What you fail to realise about a lot of open source developers (and I've known a few) is that they develop open source software in reaction to the rubbish they are forced to work on in their day jobs. The abhorrence they develop usually goes so far as to make them work in a completely different domain from their day jobs.

    While I can't speak for all open source developers and certainly not for the commercially funded ones. I think that your personal situation colours your view of the section of humanity that works on open source.

    Regards,

    Bob B.
  34. the times are changing[ Go to top ]

    Robert: "I think that your personal situation colors your view of the section of humanity that works on open source"

    You may have a point there. The situation is quite different than under the Web bubble. At this time there was an abundance of jobs and contracts with a pay-for-hour we only can dream of. Then there is outsourcing. Now even "stars" like Mike Spille may be out of a job.

    The Open Source idea that you get your daily bread from support and consulting does not work so well anymore. Therefore, many of my former colleagues and people I know today live on small nice products and protection of IP and code is important issues.

    Regards
    Rolf Tollerud
  35. As long as you don't copy the source word for word (digitally or otherwise,) copyright offers no protection. I can read a piece of source, look at how it works, have it up on one screen while I write my own "version" on another, and it is not a violation of copyright. (IANAL but this was explained to me by lawyers.)Peace,Cameron Purdy
    I wish it were that simple, but the reality is far worse.

    If you come up with a technology and you get sued by someone who has a patent on similar technology, they can very well take you to court and it will be up to you to prove that not only you did not copy their code, but that you didn't even know about that technology. Even then, you might not get away with it.

    --
    Cedric
  36. You are right. In the UK and America, copyright has been a fairly successful protection most of the time, but it isn't the same every where. Europe, and especially Asia are notorious for copyright violations, although international copyrights are still shaky anyway until we have a democratic One World Government.

    The GPL would never be successful if copyright weren't a successfull deterrent.
  37. PlatformAge[ Go to top ]

    [...]
    I wish vendors could just ship their source code
    [...]
    I just wish vendors would not ship mickey-mouse, monolithic piece of crap "platforms". I don't need their source. These middleware vendors should take a lesson in execution, and in conception for that matter, from macromedia.
  38. Legality[ Go to top ]

    The legality of creating copies varies with jurisdiction.

    In my country (Denmark), the local copyright law handles both creation of copies and distribution. It is not legal to make a digital copy of a music CD if you don't own the original.

    Also, we do have our own implementation of the InfoSec directive (the the DMCA is the US implementation of), so our guaranteed right to reverse engineer in order to create compatible software, or make digital copies of music for personal use, is restricted if we need to bypass a copy protection (almost no matter how inefficient).

    Sigh.
    /L
  39. Legality (AOP?)[ Go to top ]

    How is dynamic decompilation and addition of code (AOP) any different from static decompilation, change code, recompile, redploy? The process is exactly the same, meaning, some byte code manipulator loads the class files, parses information, and spits something out.

    This means that AOP on any third party software (90%+ which prohibit decompilation) and the core classes is illegal. Correct?

    Legaility aside, what are some people's ethical thoughts about it? I'm not talking about decompilation to fix bugs (IMO, ethical but rarely legal) or to blatantly copy architecture/code structure (IMO, neither ethical nor legal), I'm talking about using AOP to "enhance" functionality. (Not legal, but is it ethical?)

    Jeff
  40. In the patching chapter the reason for making Integer modifiable is given by stating that there is no known reason to have it immutable.

    Well, I think there certainly is as it reflects some very common use cases. From the documentation of HashMap
    [snip]
    Note: great care must be exercised if mutable objects are used as map keys. The behavior of a map is not specified if the value of an object is changed in a manner that affects equals comparisons while the object is a key in the map. A special case of this prohibition is that it is not permissible for a map to contain itself as a key. While it is permissible for a map to contain itself as a value, extreme caution is advised: the equals and hashCode methods are no longer well defined on a such a map.
    [/snip]

    Or am I just picky?

    Regards,
    Robert
  41. (getting back to the real subject here....)

    I finally read the chapter, and the author really does say that Integer should be mutable, and the java community knows of no reason for it to be immutable. Well thats just rubbish.

    The JDKs mistake is not that Integer is immutable, but that it provides no MutableInteger class to act as a parallel. The JDK should also have provided a factory for creating Integer objects, which is to appear in 1.5 IIRC.

    Why immutable, search the web and you'll find many explanations, key amongst which are thread safety and good hash keys.

    That said, the chapter is useful information - just a very, very poor example.
  42. This is stupid and ridiculous writing a book on changing the Java Core classes. This is unethical and illegal. The author is insane to produce this kind of book the community. There are better ways to contribute. This is destructive idea.
  43. your message shows that you appreantly have not read or understood the sample chapter provided by TSS -- reading the chapter will advance your knowledge on "the inner workings of Java", and you will hopefully realize that knowledge is never a bad thing.

    As for legal/illegal: The auther even presented a (quite impressive) motivating story for a legal for morally justified and highly beneficial class-decompilation. So, what's so bad about learning a few additional Java tricks??
  44. hm :)

    it's really very strange to hear such kind of comments in IT community.

    my 0.05$

    A.
    when you take a course of "advanced\extreme driving technic" with your nice Porche\BMW\Opel\Fiat\Ford\Zhiguli\Trabant and learn how use the whole power of your vehicle and getting the picture what is your\your vehicle's limits in every kind of "unexpected" situation - you learn how to drive in stress conditions, breaking some rules but keeping your life from a fatal excedent

    is it as well "Absolute stupid and ridiculous" (95% of drivers gonna never use this)?
    is it as well "unethical and illegal" (you learning how to break rules) ?

    B.
    take a look at *nix security community and MS:
    MS idea - if you did not inform community about bugs\features there are no problem at all (aka ostrich)

    *nix idea - we warned you, it's possible to make such things with your system

    take a look at the result - I don't know any really sophisticated server side solutions 24x7 based on MS

    C.
    it's not possible to stop mankind in any kind of research activity, so I preffer shared knowledge model than vetoed one


    Sincerely yours,
    Serge S. Vasiljev

    P.S.
    just can't wait to read the whole book
  45. I have tried all obfuscators and other means of
    protect the intellectual value of my code, and
    the result was: don't use Java.

    Any Java program, albeit obfuscated, classloaded or
    variously tricked, has its source fully open...

    sigh...
  46. Just because the majority of developers can't/don't/won't read assembler, doesn't mean some of them don't. I for one can and do read ASM on a regular basis and have worked with no source products because companies have lost their source, an employee destroyed it, etc. Provide a skilled assembler developer with a binary and they can give you the general structure of your source, the logic you attempted and most likely how the compiler mangled it. The argument that java is insecure is a fallacy in my opinion, because if you distribute it someone has full access to it's internal logic whether you like it or not. There are tools to decompile java, c, vb, <insert_lang_here>, etc. Sure I can't generate C++ application from a binary, but it doesn't mean that a skilled developer can't figure out the inner workings of you application anyway.

    I'd suggest you look into tools such as OllyDBG (free), Softice (Commercial) and take apart some of your own native applications. You might be amazed at what gets left behind by a C compiler sometimes.

    Cheers,
      Tyler Pitchford
  47. Guys,

    I am the author of Covert Java and even though I saw some bashing in this forum I am glad that the chapter has generated such interest. A lot of the questions and comments that were made here (most of them valid) are actually covered in the book. There is a chapter that talks about the morality and legality of actions and there is a separate chapter on protection from hacking. Even though the book shows various controversial techniques, the intent is to educate the reader and to make the development more efficient. Teaching how to hack licenses is certainly not a goal. Hackers have almost always been able to crack commercial software, regardless of how strong the protection was. The Internet offers a wealth of information on how to hack software, so Covert Java is not the holy grail of hackers.

    Having said that, let me comment on some of the posts I've seen in this thread.

    "To patch Sun's classes is really stupid. It seems like the author is insane."
    - Luckily for my friends and relatives, I'm not insane:-) As suggested by other people on the forum, take some time to read the chapters, they explain why and when the techniques can reap great benefits. Knowledge is power.

    "Legality of decompiling and patching"
    - This is a valid point and throughout the book I caution the reader to verify the legality of actions. Most of the products prohibit reverse engineering and decompiling in their EULAs, and even though one can argue that EULAs are hard to enforce, it is better to comply. There is a lengthy discussion of this topic in the book, but I would summarize it by saying that as long as your actions do not hurt the intellectual property and the revenue stream of the author, the author is not going to be compelled to enforce EULA. To give an example, say there is a bug in a commercial product that your company paid money for. The vendor is hard to reach and take a long time to find and fix problems. If the EULA does not strictly prohibit decompiling and patching, you can fix the bug, patch the product and notify the vendor of the fix (or better yet, ask their permission before doing so). Most likely the vendor will thank you for helping them retain a good relationship with your company. Win-win.

    "Copyrights and patents"
    Copyrights and patents should be viewed as one of several protection measures, rather then the only measure. The copyright protects the author from other people copying the code word-for-word, but it does not offer protection against stealing ideas. The patent is much better because it protects the idea behind the product, but it is hard to get and it takes years to obtain. Control flow obfuscation offers a very strong protection for Java applications, and the book has a whole chapter dedicated to protecting commercial applications.

    The message in the book is that knowledge is power, and it is up to the developer to decide how to use it. Throughout the book I recommend complying with the law and following the license agreements. The bad guys may already be using hacking techniques, so why not educate yourself?

    Once again, thanks for reading the chapters and do check out the book - you'll find some cool stuff.
  48. An interesting article here also :

    http://www.javaworld.com/javaworld/javaqa/2003-05/01-qa-0509-jcrypt.html


    <Vladimir>

    ClassLoader.defineClass(): The inevitable intercept point
    All ClassLoaders have to deliver their class definitions to the JVM via one well-defined API point: the java.lang.ClassLoader.defineClass() method. The ClassLoader API has several overloads of this method, but all of them call into the defineClass(String, byte[], int, int, ProtectionDomain) method. It is a final method that calls into JVM native code after doing a few checks. It is important to understand that no classloader can avoid calling this method if it wants to create a new Class.

    The defineClass() method is the only place where the magic of creating a Class object out of a flat byte array can take place. And guess what, the byte array must contain the unencrypted class definition in a well-documented format (see the class file format specification). Breaking the encryption scheme is now a simple matter of intercepting all calls to this method and decompiling all interesting classes to your heart's desire (I mention another option, JVM Profiler Interface (JVMPI), later).

    Doing this interception is not hard at all. In fact, breaking my own protection scheme takes less time that it took to implement it! First, I get the source for java.lang.ClassLoader for my Java 2 Platform, Standard Development Kit (J2SDK) and modify defineClass(String, byte[], int, int, ProtectionDomain) to have some additional class logging:
    </Vladimir>


    then how one can really protect one's code,if required,for whatsoever reasons.??
    [as even encryption/obfuscation does not solve the trouble]
    Does book answers the question?
    [Can author give it freeeeeeeeeee here... ;)]
  49. Nothing really new....[ Go to top ]

    Nothing really new in both sample chapters....
    About the decompiling chapter:
    The author did neither invent a new technique (instead he describes JAD, a tool that is quite self-describing) nor did he provide links that go beyond a mediocre google search. He is for example missing the sandmark project (http://www.cs.arizona.edu/sandmark/), which provides really cool documentation about decompiling, obfuscation and related techniques for FREE.....

    About the patching chapter:
    The example does not fit here, and after applying the fix, you should be prepared for problems with serialisation as a new public method is added...

    Hopefully the remaining chapters are better...
  50. Jad doesn't seem to work any more on JDK 1.5 class files.

    jad XX.class
    Parsing XX.class...The class file version is 48.0 (only 45.3 and 46.0 are supported)
    JavaClassFileParseException: Class file version mismatch

    I found one reference to changing the class version in the class files to allow jad to work - this rather annoying one doesn't give you the information unless you register
    http://www.esus.com/docs/GetQuestionPage.jsp?uid=1795
    ...but this seems like a ham-fisted approach.

    This Russian thread also aludes to the problem.

    http://groups.google.co.uk/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=bkv75n%24v00%24627%40www.fido-online.com&rnum=1&prev=/groups%3Fq%3Dclass%2520file%2520version%2520is%252048.0%2520(only%252045.3%2520and%252046.0%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26sa%3DN%26tab%3Dwg

    Anyone know of any better ways of decompiling 1.5 classes?

    Cheers
    Jeremy