tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dmitry Leskov" <>
Subject RE: [OT] Securing Tomcat Applications from Reverse Engineering
Date Thu, 28 Jan 2010 06:04:08 GMT
> 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
> > 
> > - 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:

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: 
(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.


> > 
> > 
> >> -----Original Message-----
> >> From:	Jeffrey Janner []
> >> 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 [] 
> >> 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:
> >> For additional commands, e-mail:
> >>
> >>
> >>
> >> *******************************  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.
> >>
> >>
> > 

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message