You are completely missing the point. I do not fear customers ripping me off. I fear another startup software company decompiling my code and even using parts of it to write and sell something similar.
-
Anil Philip

 

 

try yGuard.
http://www.yworks.com/en/products_yguard_about.htm

regards,
gaurav

 

 

Just to chip in without adding all that much value to the discussion, you won't go wrong with either Proguard or YGuard, I've used them both and they both work very well. YGuard is arguably a little easier to understand, especially when obfuscating as an Ant task, and it produces better map files - I've not really used as many features of it as I have Proguard but I'd assume it performs similarly with trimming etc. Proguard has a somewhat confusing interface, to be honest.

Aside from the discussions about usefulness of obfuscation, there are a few boundary conditions which will influence your decision. If you're using a number of aspects of reflection then you almost certainly don't want to be using it, since it's extremely difficult to ensure things are working correctly once obfuscated (so, things like Class.forName(), any Bean introspection, external IOC configuration such as Spring configs, or any code you use which obtains classnames and uses them for lookups in properties files, are all liable to break under obfuscation). Note that this is also true of code trimming (ie removing unreachable code) since the obfuscator can't work out what's reached and what's not unless it's conventionally coded. At the other end of the scale, mobile development pretty much mandates obfuscation: files need to be as small as possible, and reflection isn't supported anyway.

In general I would tend to obfuscate discrete applications because (a) I'm a bit of a purist and don't like Beans etc anyway, and (b) it's a bit of extra protection for little effort - but if it uses other technology, such as Spring, which depends on reflection, then it's probably not something to lose sleep over.

So there you go. In short, give YGuard a go. If it helps you then keep it, if it doesn't then don't sweat :o)

 

 

Has anyone tried Excelsior JET ($1200-4500)? I came across this while looking into Java Obfuscators. From what I read the best obfuscator is Zelix KlassMaster ($199-399) but it can still be decompiled.

Thank you.

 

 

ok, one last question.

Im including a security feature in my source code.

Specifically the writing of "preview" on all generated images created in an unpurchased product.

I assume a hacker will eventually come along and edit it out, and release a hacked version.

would obfiscation protect me from such a-holes?

 

 

I am working on Project and the Client s are very edgy by the fact that their application can easily be reverse engineered. Though obfuscation is not the ultimate solution but if the client feel better if the code is obfuscated then we will have to do it right?

Besides I have used ProGuard and Zelix KlassMaster, but both are not reliable as both had curropted the basic logic causing application to Crash. So what should I use.

 

 

Farrukh,

if you just went up four posts in this very thread, you would have come to a wonderful message from user "itchyscratchy". In that he explains a possible threat obfuscation can bring to a program's logic.

Have you checked that your program does not meet the preconditions which are explained up there?

Ciao, Di- "forums are no write-only devices..." -rk

 

 

I think I'm going to have to agree with Kerko on this one. Obfuscation, although interesting in some regards is on the whole useless. Almost all the code in an application that anyone really wants to modify isn't really obfuscated anyway. Consider if you will some who wants to take your program, and pretend they wrote it. Further assume that you've run it through an Obfuscater and that it uses a nice GUI with some associated graphics files for the frontend. Now, if I wanted to take that, and make it look like I created it, I would do 2 things. One, I would go and create new graphics files and just replace all the ones in the jar files with mine. Two, I would decompile and change a bunch of the Strings, which by their very nature are not Obfuscated, and then recompile.

Now, if I only wanted to take part of your code, or perhaps bypass something, then all I have to do is decompile, recompile, and then run the application with the debugger turned on to find the code/classes that I'm interested in taking or modifying.

All in all, the obfuscation hasn't really accomplished much, although if it's written poorly it could potentially degrade your applications performance.

And for the record, I am a Java developer employed by a large corporation, but I don't write code because they pay me (although that's nice), I write code because I enjoy doing it. Programming is a art form, and programmers should take pride in their craft.

 

 

I dont completely agree with "Herko_ter_Horst".
All the points that "Herko_ter_Horst" has mentioned are valid when you build your own products and sell it to small customers who are not concerned about their code being taken by others. I dont agree to the point that "ustomers pay for solutions, not code". My be you have n't come across big customers who are very secure.
I have been in business for 8 yrs now and I have seen all sorts of customers. When you want to sell your solution to a highly secure customer, for example banking industry, they are not going to buy your product without your word that it can not be EASILY seen by others. I mention the word easily because even they know that REAL Bad guys can break your code. But they do not want to give them easy tasks. They will decide upto which level one has to go to this security issue. They have other securities over this but at the final stage they want obfuscation as well. I have also seen many many customers who say obfuscation is enough for them because its cheaper. I know its not that useful bcoz we can break it, but when you come to customers they need that someone should not see or break into their code and see it.
TAKE MY WORD FOR IT. THEY ARE NOT GOING TO BUY BECAUSE THEY DONT WANT OTHERS TO KNOW THEIR INTERNAL BUSINESS LOGIC.

There is nothing wrong with Anilp1 thinking that his code is his effort and should not be stolen by others. Its his property. However obfuscation is not they right tool for it. And of course he has to know that your idea is however known to others and hence even if your code is not known to them they can write their own (may be better) implementation of the idea. This is rightly mentioned by Herko_ter_Horst.

So my conclusion about obfuscations is that it is necessary because of the customer needs and not with the perspective of an individual developer.

 

 

Not mentioned thus far is the use of obfuscation for J2ME applications where space, and cpu speed is much more limited.

Reducing the package name to a single character for all classes, like '' in Proguard with the "-defaultpackage " option does more than just remove uncalled classes. It takes out alot of space.

When this flattening of the package heirarchy is combined with the "-overloadaggressively" option, it makes quite a mess. This could act as a deterent to some people who would give up using your code, and force them to do it themselves. Note I said "some". Maybe most of the ones who happen to be targeting you are not all that motivated or skilled. Security is about layers.

Back to J2ME, I cannot find where I saw it, but I think Proguard 4.0 is going to do more optimizations, like replace calls to length for arrays in the loop checking of FOR statements.

Just any byte code optimization at all is definitely worth it on a phone application. Reflection is not even possible on that platform, so that downside is removed. Proguard, is bundled with the Netbeans mobility package

 

 

Why so much discussion. Just obfuscate the dang code. It is easy to look at decompiled code and steal ideas that do not show up in usage.

Furthermore time is the factor here, thieves don't rob cars with alarms because they dont have the time to do so. I have excellent decompiler tools and they will not decompile obfuscated code. So someon would have to take the time to hack through when it makes more sense to move on and just try to reverse engineer it. (this is going on hand over fist) Again taking more time allowing your solution to be in the market LONGER (time :).

Obfuscation is like a camera in that it keeps honest people honest and is enough of a burden to keep unsophistticated (the very people you obfuscate for) thieves away also. If you just invented a working AI class that woke up and started talking to people I'm sure nothing would stop some persons from decompiling your code no matter what.

When I learned how easy it was to decompile classes I started poking through everything that was held proprietary. Some things I was able to understand modify and recomile (illegallly?) for my own purposes.

I would obfuscate anyting that made sense to obfuscate; hence locking your doors.

Sean

Better yet just do this:
http://thc.org/root/phun/unmaintain.html

 

 

Listen, if you make a joke in text (like on this forum), you should really include the appropriate smileys, otherwise people are going to think you are serious.

 

 

Just joking.

 

 

I understand you aren't selling the source code. But what's preventing someone from copying your source AND idea = fully copy your company? For instance a customer who is very technical so they could run the free/open code themselves; and because they are a customer they already have intimate knowledge of your IDEA.