Win a copy of Java Concurrency Live Lessons this week in the Threads forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

How to Prevent class files from downloading(S.O.S)  RSS feed

 
Hasan
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We made a chat application using Java1.2 and uploaded it for people to do chatting. Now the problem is anyone can download our class files because name of our class files is shown in the status bar of browser before applet initializes and anyone can download and decompile it. Is there anyway to protect it.
 
Carl Trusiak
Sheriff
Posts: 3341
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Hasan:
We made a chat application using Java1.2 and uploaded it for people to do chatting. Now the problem is anyone can download our class files because name of our class files is shown in the status bar of browser before applet initializes and anyone can download and decompile it. Is there anyway to protect it.

For an applet to run in a browser, it has to be downloaded anyway. If you don't want someone to decompile your code, you have to use an obtusifier on it. This will prevent that but, I'm not sure how it will impact performance.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hasan- your "application" is really an applet, right? Then Carl is correct. Anything that you want to run on other people's machines needs to be made available to them as one or more class files (probably in a jar). I'd never heard the term "obtusifier" before - I know it as an "obfuscator". Same thing I'm sure. Do a search for Java obfuscators at www.javasoft.com, yahoo, or other relevant sites of your choice. I don't think that most obfuscators impact performance too much, but I could be wrong. Often they have configurable options - some options may impact performance; most will probably not. Note also that it's always theoretically possible to reverse-engineer any code from the class files - the point of obfuscation is to make it as difficult as possible.
Alternately, you could have some sort of "chat server" which does most of the processing and is removed from the client computers, so they don't need to have access to that part of the program. I've never thought much about how chat software works, so I have no idea if this is a good idea in terms of performance or complexity, but it would allow you to isolate those parts of the program you wish to remain "secret".
[This message has been edited by Jim Yingst (edited June 27, 2000).]
 
Carl Trusiak
Sheriff
Posts: 3341
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok -10 SP

LOL sorry thanks much Jim
[This message has been edited by Carl Trusiak (edited June 27, 2000).]
 
Rob Whelan
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
from Jim Yingst's post:
I don't think that most obfuscators impact performance too much, but I could be wrong. Often they have configurable options - some options may impact performance; most will probably not.

I'm not an obfuscator expert, but I don't think they would negatively impacting performance. Basically, I believe, they strip out all line numbers and debug info from your classes, and rename all of your methods and variables to unhelpful character sequences. None of this changes how your code executes, except that your class files are generally smaller (because of shorter names and removed information), so you'll get a faster applet download.
There may be other things they can do, and I have heard of obfuscators changing code in ways to exploit bugs in the common decompilers, but the changes that can be made are fairly limited, because it still needs to be comprehensible to the VM.
 
Praveen Kannan
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jim Yingst:
I don't think that most obfuscators impact performance too much, but I could be wrong. Often they have configurable options - some options may impact performance; most will probably not.
[This message has been edited by Jim Yingst (edited June 27, 2000).]

Is it true that if you "obfuscate" your class file, then it might not work properly in all the JVMs???
 
Marius Holm
Ranch Hand
Posts: 84
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi.
I just wanted to drop a note about obfuscators/obtusifiers and decompiling. I think anyone being able to reproduce your code through decompiling has DESERVED to have that code!
Let me explain: Programmers are in my eyes the people suffering most from copyright laws and regulation. We are always looking out for new tricks to improve our own code, and for this reason sites giving code samples are popular. If we were able to use any applet or running program for such purposes, that would be great! Now, there are as I see, two main reasons why people would protect their code:
1) Commercial reasons
The GNU/Open Source project (or what they call it, programmers will probably know what I'm referring to) addresses these issues, and I heartily support this initiative. As I said above, I claim that programmers are the ones suffering most from commercial barriers imposed on the freedom to gain information in the area we are speaking of. While sw companies earn a lot on copyrights, very little of this goes to the person who wrote the code. He/she may get a raise in his/her salary for doing a good job, but this is as all know, fragmentary compared to sales revenues for a product that sells good. Conversely, we know that developing costs for a program are the same whether it sells good or not, production costs are minimal, only sales revenues shows the big difference (probably there is a connection between development cost and popularity of a product, but this relationship is not easy to point out, and it does anyway not belong to this discussion) If there were no copyright to code, payment models for programmers (and sales models) would have to be different. Now a company can own a product and the rights to license it, and it can earn a lot of money by just doing this (selling licenses). If there were no copyrights, that company would have to earn its money otherwise. Programmers on the other hand, would have a lot more code samples to pick from, and here comes the big point: We would get paid for what we knew, as we mostly do today, but we would be able to know more, and be free to pick sw/enterprise platforms to program on. Today it is for instance not easy for a programmer to start programming on, say, Microsoft SQL Server or Oracle, as he/she would need the product installed and configured in a way that today usually would impose great costs on software products. He/she might of course get hold of a free trial Beta version, but the work overhead associated with setting up a test platform that will work for three months (and often only Beta) prevents a lot of people from doing this. (And that's not three months at a time, most trial versions state in their licence agreements that it is intended for the licence period (3m) period, and that you are not allowed to reinstall it. (If you didn't know this, it means you don't read the licence agreement, which in itself is a violation of copyright law, that makes you a criminal )
To make a conclusion: if there were no copyright laws (on computer programs) programmers would be able to learn more faster. This would lead to increased expertise among programmers globally, increasing the competition between them (not all people see the advantage of being exposed to more competition, but those are the people clinging to copyrights as far as I see). Software companies would be more dependent on employing proficient programmers to stay in the market, as their competitors do this, and it would anyway be no money in passively selling licenses. That would add up to more jobs for programmers, and also more paid for those who are willing to keep learning to stay ahead. If anyone disagrees to this, I would like to see arguments for what makes copyright laws beneficial for programmers.
2) Security reasons
As opposed to the previous point, which I claim is irrelevant, the issue of security is an important one. However, secure implementations of apps is (at least usually) not dependent of the code being secure or secret. As an example I will mention encryption. That you know a certain encryption algorithm, does not mean that you can decrypt anything encrypted with that algorithm. You also need the key. (That this should be secure enough, should be evident from the fear expressed by US authorities during last year about who should be allowed to use their most secure form of encryption (128-bits?), a technology they (US auth) would prefer to be the only one to use. The fear arose from the possibility that elements considered dangerous or detrimental by US authorities, such as citizens of Iraq, or drug dealers (it is indeed difficult to see who is the worst menace ) should be able to encrypt communication, although US auth held the algorithm, it would be practically impossible to decrypt such communication without the key. Now, to make my point clear, the security model that you use can be independent of code. Today, compiled code makes your app even more difficult to hack, and that's fine of course, but to what costs? More time would be invested in finding good security models if things were different, and as a programmer, I (and you) should be happy to learn more about what you actually can do to make your app more secure, instead of letting the compiler do the job. (A job it doesn't even know it has, and therefore doesn't put much effort in, as opposed to tuning and optimizing). Again, if anyone has thoughts about this that go against this, I would be happy to hear it!
Well, my point here is: I can only see the practice of hiding code as an understandable practice in todays business landscape, but nevertheless a damaging one to programmers at large. As such, it should be undermined by us whenever encountered! (If that doesn't set you out of work, or put you in a lawsuit versus your employer that is ) Do not ofuscate/obtusify your work! It can be of great value to a (clever) fellow programmer (not me, I'm not that clever, but maybe one day...). Please tell me if you think otherwise.
For a free, open world!
Regards,
Marius
 
Mark Herschberg
Sheriff
Posts: 6037
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Praveen Kannan

Is it true that if you "obfuscate" your class file, then it might not work properly in all the JVMs???

That's false. Obfuscation generally does the following:
1) Changes names (variable and method)
It will rename your fields, methods, and classes to short names, such as: a, b, aa, a1. This cuts down on .class fiel size, and makes it hard to read, I can guess what the calcSQRT(int) method does, a(int) isn't as obvious, especially when it calls b(int) and c(int) inside it. :-)
2) Changes packaging
Package names also give you a hint as to functionality. Some obfuscators let you collapse the entire structure to a single package.
3) Code optimization
Some optimizers perform code optimization based on speed (e.g. inlining methods, loop unrolling), or size.
4) Scope
Some obfuscators let you change the scope (e.g. public, private) of fields, methods, and classes. If you make everything public, the JVM saves time doing checks on accessibility of the given field, method, or class. Note that this doesn't violate good coding practices, since the source code still uses scope, and the compiler respects the tags. It's only after the code was compiled into .class files, that the obfuscator goes in and changes the tags.
Different tools suport the above to differing degrees, and may offer other options. In all cases, the bytecode producted is valid, Java bytecode, which should run on any spec compliant JVM.
Note that if you are making an API, then some fields, methods and classes (such as public ones), cannot be renamed, since the developer will look for a method called foobar(), but only see methods: a(), b(), c()...

However I should note that currently our obfuscated code (which is an API, and so did not rename public fields, methods or classes), does not work under JBuilder 3.5 foundation. JBuilder cannot find the public fields. We're working on it. (Anyone encounter this problem?)

--Mark
hershey@vaultus.com
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!