is an inexpensive payware ($19 USD) java class file byte code protection tool. Written as a DLL (or shared object file), it serves to protect classfile data via actual encryption and not obfuscation without access to source code.
Knowing that the majority of Java applications are server applications deployed on UNIX machines why is there no *NIX version of your tool?
Presumably, the encryption takes place on a Windows machine, but the site specifically says that the decryption mechanism is in ANSI C, and definitely is able to run under UNIX, although I haven't tried it.
To decrypt your byte code this tools should keep key with program distributive. If this will happen smart hacker can find the key and decrypt code. I'm not saying about JVTMI API which makes possible to view any loaded classfile so you can decrypt classfiles even without hacking library code.
I think it is possible to create virtual machine which make it is possible to exceute encrypted code in a such a way that it will use a memory and other resources in a encrypted way so it will be impossible to view without key which isn't supplied. It might be similar to RSA open/private key encryption algorithm or impersonalized internet money. I think guy who do this will earn a lot of money :-) But definitely this tools doesn't do something like this.
With current computer architectures and memory models - 100% security is not possible. Anyone telling you otherwise is only looking to sell you some product or service.
I'm not a big fan of analogies, but it is somewhat comparable to the lock on your front door. It will not stop the determined intruder but will slow him down and deter the casual intruder.
If you distribute the key (which is required for decrypting and using the class files), then the key can be recovered. Whether the key is symmetric or asymmetric (public/private), does not matter.
If you go for a model with encrypted memory, you would still need the decryption key somewhere. And the CPU must still be able to read the code and since the CPU also runs any code for key extraction, you're back to square one. Unless, perhaps the memory is properly protected against reading by other processes (not even the user-installed operating system can be trusted) and of course, since java is really an application on top of the CPU, it must also protect various parts of the application from reading other parts.
It might not be impossible, but I wouldn't really classify it as reasonably feasible either. Better memory protection, yes. Providing a system, which does not trust the operating system of the user, no (this was attempted with the original Xbox and while the Xbox360 utilizes much more advanced security, even one of the key engineers at MS has stated that it is not 100% secure).
If you read this link: http://www.javaworld.com/javaworld/javaqa/2003-05/01-qa-0509-jcrypt.html
you see that it's pretty simple to 'dump' the decrypted class: Don't care with the key and encryption algo, you only need to modify your java rt.jar.
In the past, I have seen 3-4 similar products, but they seems to have disappear...
The cost is low, so is the security.
I'd like to know what algorithm is used. If is a custom one, it can probably be broken.
But don't bother breaking the encryption algorithm. The encryption key is available locally, probably in the DLL. The streght of the encryption algorithm is irrelevant.
But don't bother getting the key either. It't too easy to make another program that will call the right exported functions of the DLL so that it will spit back the unencrypted class files.
But don't bother writing a custom program and reverse engineer the DLL either still. The easiest way is to run as intended and read the decrypted class files directly from memory.
Just remember this : is java.exe can read it, so can you. Just have to look at the right places !
I can remember discussing the bytecode protection problem seven or eight years ago. I even wrote a tool that was quite similar in concept to this product.
A few dollars to raise the bar might be worthwhile if your business rests on nobody being able to get at your code but if this kind of security is considered critical to the success of your business I would definatly not want to be one of your investors.
The advantages of web applications are often quoted but while zero maintainence on the client usually makes the list along with global access and central configuration I don't often see code security as a benefit but I suspect that this played its part in the popularity of web applications.
If web applications dont solve the problem for you, then it becomes a case of either opening up your code and relying on your services offering to pay the bills (seems to be a pretty successful model right now) or relying on some form of legal IPR protection.
c.It is impossible to decrypt the encrypted class files by using any decompiling and translate tools.
How to you bypass the problem describe in this article:http://www.javaworld.com/javaworld/javaqa/2003-05/01-qa-0509-jcrypt.html?
Check out www.saffeine.com
It is much more powerful and platform independent.
You actually can use any JCE-compatible provider with this
The main reason to use a tool such as this is to obfuscate, the primary concern being that someone can easily obtain a reasonable representation of your SOURCE code w/o much effort.
For example it's trivial to open a .class file with some editors.
So one would want such a tool so that people (mainly competitors) cannot use your source code or classes in their programs so easily (if they are going to steal.. make them work for it). The purpose being that such reverse engineering would require so much effort that they would prefer just to write it themselves.
That being said.. I think compiling w/Excelsior Jet or GCJ would serve that purpose. You can still reverse engineer it.. but it would be hard to get it to look like the original source code.