> Dmitry Leskov wrote: > > So far only some aspects of code protection have been considered in this > > (off-)topic, namely preventing illegal use and protecting the code itself > > as a piece of intellectual property. However, there are at least two other > > scenarios that may make protection against reverse engineering desirable: > > > > - a malicious user inside the organization that runs the application, > > tampering with the code in order to disrupt its operation, steal sensitive > > data, and so on. > > > > - a hacker decompiling a legally obtained trial/demo version of a boxed > > app, looking for security vulnerabilities. > > > > Note that both do not need to comprehend how the entire application works, > > they only need to learn enough to determine the vector of attack. > > > > Dmitry > > > You forgot another one, in the practice much more likely : a disgruntled > employee *inside the organisation that creates the code*, stealing a > copy for his own usage. > I think this falls under unfair/illegal use, no?
Here is another product that solves the same problem, but in a different way. Their list of scenarios includes five items: http://www.arxan.com/software-protection-products/java-GuardIt/ Now that I plugged a competing product, we can have a vendor-neutral discussion. :) > I believe it all boils down to "there is no one-size-fits-all" solution. > And anything that is done to "protect" the code has its downside in > terms of ease-of-use, user-friendliness etc.. > Sorry, but I cannot fully agree with this one. If you have a bit of time, I would greatly appreciate you checking out the following content and telling me what exactly is wrong with the ease-of-use and user-friendliness: http://www.excelsior-usa.com/protect-java-web-applications.html#samples http://www.excelsior-usa.com/tutorials/jet/eclipse/ (this screencast is on protecting Eclipse RCP apps, a very similar one for Tomcat is in the works right now.) > You can also put 3 separate locks on all the doors of your house, and > require 3 separate family members to be present to open them, each one > with his own key. > I do not see how this is relevant to protection against reverse engineering. Perhaps you meant copy protection again: online activation, hardware locks, license managers, that kind of stuff? > It all depends, ultimately, on the kind of application, the kind of > customers, the kind of distribution of the application, the kind of > employees you have, and so on. > Absolutely. Not everyone needs to protect their Web apps. Dmitry > > > > > >> -----Original Message----- > >> From: Jeffrey Janner [SMTP:jeffrey.jan...@polydyne.com] > >> Sent: Tuesday, January 26, 2010 12:09 AM > >> To: Tomcat Users List; Tomcat Users List > >> Subject: RE: [OT] Securing Tomcat Applications from Reverse Engineering > >> > >> Good points all around. We had the same issues with our CEO worrying > >> about copies of the app being passed around when we started targeting > >> markets where piracy is fairly common. Eventually, we convinced him the > >> best way to address them was via legal and marketing techniques. That is, > >> a very tight license and convincing the customer that our product provides > >> a unique tactical advantage that they would want to give to their > >> competitors. We did make a few technical product changes to aid in the > >> license compliance arena, one of which was incorporating a license key > >> that is uniquely and obviously tied to the company licensing the product > >> and stored along with the data. The theory being that a customer (or his > >> employee) might be willing to fork over a copy of the code, but not their > >> proprietary data. > >> It's not perfect, but it seems to get the job done. > >> > >> -----Original Message----- > >> From: André Warnier [mailto:a...@ice-sa.com] > >> Sent: Thursday, January 21, 2010 4:56 PM> > >> To: Tomcat Users List > >> Subject: Re: [OT] Securing Tomcat Applications from Reverse Engineering > >> > >> Jeffrey Janner wrote: > >>> André - > >>> Welcome to the world of small business, for-profit software development. > >>> This is a more common attitude that you might be aware. > >> I was being somewhat ironic. Being myself a small for-profit software > >> development business, I am well aware of the circumstances. > >> ;-) > >> But here are another few arguments (apart from the ones I already > >> mentioned in another post) : > >> If you are a small software business whose customers are businesses that > >> use your product, and your product is good and your prices are > >> reasonable, chances are good that none of your customers is even going > >> to bother taking the time to try to copy your product. If they > >> themselves are small/medium businesses, what would they do with it ? > >> They have their own business to run. They are not a software company, > >> you are. > >> And if they are big, they will never risk their reputation and their > >> money trying it. > >> And, agreeing with another post by Leon, you are probably much better > >> off spending your time improving and supporting your product, than > >> developing ways to try protecting it from unfair copying. > >> Things would be different of course if your product was something > >> destined for the mass-market, or if you intend to sell it through > >> resellers, or if your customers are themselves software companies. > >> I will not mention the fact that in all of the above cases, your highest > >> level of risk is probably inside, not outside. > >> And if you really insist on protecting your code, then I am afraid that > >> Java is not the best choice of tool. > >> And I'll finish with another sarcastic note about code obfuscation : in > >> my experience, it is not really necessary to put a lot of effort into > >> this. Other people's code tends to be naturally obfuscated, all by > >> itself.> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > >> > >> > >> ******************************* NOTICE ********************************* > >> This message is intended for the use of the individual or entity to which > >> it is addressed and may contain information that is privileged, > >> confidential, and exempt from disclosure under applicable law. If the > >> reader of this message is not the intended recipient or the employee or > >> agent responsible for delivering this message to the intended recipient, > >> you are hereby notified that any dissemination, distribution, or copying > >> of this communication is strictly prohibited. If you have received this > >> communication in error, please notify us immediately by reply or by > >> telephone (call us collect at 512-343-9100) and immediately delete this > >> message and all its attachments. > >> > >> > > > >
