I wrote an encryption class to use in my database application and it works fine. But the thing is anyone can extract the class file from my jar and use it to decrypt what i encrypted as they like. Or they can decompile the file catch the encryption method. Have you got any idea how to overcome this problem..
A friend of mine suggested using native libraries and compiling my file to an .exe But neither him or I got an idea on how to do it..
The GNU GCJ compiler can create native code, although apparently not a lot of GUI stuff.
Since you seem to have an encrypting classloader already, have you considered the use of a password that the user must enter to unlock the application? [ January 28, 2007: Message edited by: Ulf Dittmer ]
Ran into this exact problem a few times myself. There isn't really a perfect solution here. You could run your code through a Java obfuscator, or compile native (as you suggested), but there is nothing that will guarantee prevent a hacker with enough desire, to decompile and figure out your code eventually.
The only perfect solution is to not embedded passwords in client code. Maybe move the password code to the middle layer, and have the client code contact it to forward requests to the database (after validation of the client, of course). This way the password is on a machine that the hacker doesn't have access to.
Maybe move the password code to the middle layer, and have the client code contact it to forward requests to the database (after validation of the client, of course). This way the password is on a machine that the hacker doesn't have access to.
Thats a good technique. Code obfuscation is great but it will not stop some one who is very determined. Same with native code. I have heard of people analyzing the assembly language to try to figure out whats going on (and they have succeeded). The only way to prevent this is to move the code somewhere the hacker does not even have access to.
No matter where you move the code, some hacker can find the Java line that says:
and just always make it true with a little bytecode magic. Getting an unencrypted string before or after it is sent to an external service is about the same. You can write encryption, security or licensing good enough to stop the honest user or slow down the amature hacker, but it's dangerous to think you will stop a determined expert from doing whatever they want.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Encryption that relies on the algorithm being secret is not fundamentally safe encryption. As the others have mentioned, if your encryption scheme is based on this idea, then there is always a way in which a hacker can break it.