I have an application that use a .properties data containing password from DB, this application will be used by my client but I don't want to give him any kind of access to this properties data, not even if we look in the .jar. I thought to use zip4j but is there any another best solution for this because when I unzip it the .properties will be decompressed somewhere giving the client access to it doesn't it??
This cannot be done. Just forget about this idea and re-think your system.
You can't provide read access not providing read access at the same time.
This is a wet dream of legal depts in the media industry. They invest piles of money in solving this insolvable problem with DRM that never works, but annoys everybody.
You can make it more annoying to extract the data - using various obfuscation techniques - but that's all.
One of those ideas is to encode the passoword in C++ library and link it via JNI. Then the user cannot extract it without disassembling the binary file, but will be able to make memory dump at runtime anyway.
You can read the password from central server at runtime. You can use one-time passwords for that. Again, this is futile if the user has modest technical skills, as you can still request the server for the password using curl or some simple script.
You can use hardware access-token that will allow connection to the database (smart-card or something). This was quite popular technique in '90.
All you can do is to add some level of annoyance which will stop non-technical person. With enough money you can build some decent DRM that will stop technical-savvy people for a while, but I seriously doubt it's worth the money.
If the database access is so precious that you can't give the user access to it, yet he needs it, your design is broken.
I have a old projects developed by java and that old project made by Jdk 1.4 version.
This is single application java program.
Currently server and database configuration is written by .ini file.
but That is not really good for security because everybody can see this file physically.
Do you guys have any way to hide perfectly instead of using .ini file.
I think this is two way.
1. Make properties class in side of project and make .jar files.
- I can make .jar file but also I can decode it.
2. Separate Back-End server and communicate.
- This way I have to fix too many source code. So I am not sure it's good or not.
- Also what is this concept for specific we are calling in Java environment?
And anything else please suggest to me
Thank you!
The least protection you can provide to your configuration file is encrypting it.
Make properties class [inside] of project and make .jar files.
As I pointed out in the comments, you should never place sensitive data in compiled files. For one, it makes your design quite unflexible: If you decided to change your server password, for instance, you would also have to change your compiled files. As a second and more important reason, saving configuration data in compiled code is insecure; especially for Java, there are decompilers out there which can be used to decompile and thus retrieve the sensitive data.
Separate Back-End server and communicate.
I do not understand what is meant by this so I will not comment on it.
A means to secure your files is encrypting them; this is the least layer of protection though. When you login to your server sent the encrypted password to your server and the server, knowing the encryption key, will be able to decrypt the password and check whether the password is valid. While the last part may seem to be obvious, I insist on communicating that to you.
However, you should not rely on encryption solely. Furthermore, if the information you are protecting is not client specific, such as their login credentials, you should not store it on the clients computer in the first place; anything can happen on the clients computer - the client may even be the one trying to crack the your sensitive data. If you do not have to, do not store it on a computer you do not have control over. I do not know you circumstances, so there are hardly specific answers I (and the community) could provide.
I hope this answer helped you
I've been thrown in at the deep end a bit here, as I never expected I would have to do something like this and I have no idea where to start; so I'm helping somebody will be able to help me (ideally by providing some java code)...
In my effort to protect my Java software from piracy I have found that it is completely impossible unless I continusely check online - so thats what I want to do. Only, the only details I know are that, my program needs to communicate with some sort of script online and verify the licence key the program is using and then report back accordingly.
However, that's all I know - I am still stuck as to what the server side actually consists of. I'm hoping that the fact I am not hosting the website myself (an using JustHost) will not stop me from being able to do what I need.
So basically, I would like some help in creating a setup that allows my prevent anyone from pirating my software while connected to the internet. I though about having something like a login system; the users licence key would act as a username and password, but to be honest I really have no idea because if I did it that way would have to manually login and logout each time they wanted to use the software.
And not to run before I can walk but what happens when the user is not connected to internet? Even worse, how do I tell if somebody has stealed an legitamate users licence key? etc.
Thanks in Advance,
Andy
PS If it helps, I plan to use PostgreSQL (or maybe MySQL) and I am not paying for a dedicated server with JustHost.com...
Once your code is on their machine they can modify to simply ignore your checks. You can make it as hard as possible but it will never be hack proof.
In general your question is identical to this one which has some good discussion.
Try to delegate part of your business logic to server side. This way some core processes can not complete unless the application license is valid. Of course, if you have some logic that can be delegated. If your application is client-only than this approach is a bad choice.
If your application will be sold for a lot of money, try implementing solution using HASP key approach (which is investment by itself) instead of server authentication I understand this is not what you asked, I am just giving another idea.
try to create security by obfuscation/encryption and you will fail if your application becomes popular, since there will always be someone who will crack it in 5 minutes :(
I'm in the process of developing an application that uses client side code (js to be specific), which needs to be secured. I.e. so that a user cannot steal the code and reuse it. Obfuscation is not an option, as I need the code to be fully secured (with encryption). After extensively scouring the internet for a solution that allows js encryption I have come come to the conclusion that this proprietary code can only be executed server side to ensure its security.
Does any one have any other ideas or solutions, that would relieve the server from having to process things that otherwise could be done on the client with js. Executing some of the code on the server is an option, but resources are limited. Another issue is that it would need to be something like "server side js" i.e. the user experience is not changed.
If the code is client side, they have the code. Period. That's how the internet works.
If you want to protect it from the end-user, then yes, you need to keep that on the server side. Alas, that will change the user experience. There really isn't a way around that, though perhaps via judicious AJAX calls you can find a happy medium.
Nope, it sounds like you've pretty much got the gist of things. Use the server to process anything that needs to be done securely. Use javascript to display the data sent from the server.
I don't know what application you're working on, but typically efforts to offload significant processing onto the client side involve so much data transfer that the server has to do more work in the long run. Can I ask what kind of processing you're wanting to do client-side?
The user experience would have to be changed for a server-side solution, simply by the fact that you'd be running code on a different box, with a network between the two. The latency will be different. It may be good enough, of course, but it's hard to say without knowing what kind of app it is.
The closest I can imagine is hosting some sort of JavaScript engine within an otherwise-secure application... but you can tell from the state of the games industry's attempts how easy they've found it to make unhackable client code. Basically, if it's going to run locally, the code has to be there to execute... and that means it can be inspected. All you can do is make it harder.
You could encrypt your javascript and then decrypt&eval it on the client side. If it´s a private application, you could use a password for the encryption, so anyone without password could not decrypt it. Otherwise you should make it really complex.
Apart from standard JS obfuscation which is discussed e.g. here: https://stackoverflow.com/questions/2285593/how-to-sell-and-protect-software-that-has-easily-visible-source-like-javascript
this is close to impossible to do.
I would tend to question whether there really is a need to protect the client side code in the first place. What makes it so unique that this is necessary? Any kind of sensitive data manipulation should be done on the server side anyway, as every obfuscation method will always be only imperfect protection.
Is there a way to deploy a Java program in a format that is not reverse-engineerable?
I know how to convert my application into an executable JAR file, but I want to make sure that the code cannot be reverse engineered, or at least, not easily.
Obfuscation of the source code doesn't count... it makes it harder to understand the code, but does not hide it.
A related question is How to lock compiled Java classes to prevent decompilation?
Once I've completed the program, I would still have access to the original source, so maintaining the application would not be the problem. If the application is distributed, I would not want any of the users to be able to decompile it. Obfuscation does not achieve this as the users would still be able to decompile it, and while they would have difficulty following the action flows, they would be able to see the code, and potentially take information out of it.
What I'm concerned about is if there is any information in the code relating to remote access. There is a host to which the application connects using a user-id and password provided by the user. Is there a way to hide the host's address from the user, if that address is located inside the source code?
The short answer is "No, it does not exist".
Reverse engineering is a process that does not imply to look at the code at all. It's basically trying to understand the underlying mechanisms and then mimic them. For example, that's how JScript appears from MS labs, by copying Netscape's JavaScript behavior, without having access to the code. The copy was so perfect that even the bugs were copied.
You could obfuscate your JAR file with YGuard. It doesn't obfuscate your source code, but the compiled classes, so there is no problem about maintaining the code later.
If you want to hide some string, you could encrypt it, making it harder to get it through looking at the source code (it is even better if you obfuscate the JAR file).
If you know which platforms you are targeting, get something that compiles your Java into native code, such as Excelsior JET or GCJ.
Short of that, you're never going to be able to hide the source code, since the user always has your bytecode and can Jad it.
You're writing in a language that has introspection as part of the core language. It generates .class files whose specifications are widely known (thus enabling other vendors to produce clean-room implementations of Java compilers and interpreters).
This means there are publicly-available decompilers. All it takes is a few Google searches, and you have some Java code that does the same thing as yours. Just without the comments, and some of the variable names (but the function names stay the same).
Really, obfuscation is about all you can get (though the decompiled code will already be slightly obfuscated) without going to C or some other fully-compiled language, anyway.
Don't use an interpreted language? What are you trying to protect anyway? If it's valuable enough, anything can be reverse engineered. The chances of someone caring enough to reverse engineer most projects is minimal. Obfuscation provides at least a minimal hurdle.
Ensure that your intellectual property (IP) is protected via other mechanisms. Particularly for security code, it's important that people be able to inspect implementations, so that the security is in the algorithm, not in the source.
I'm tempted to ask why you'd want to do this, but I'll leave that alone...
The problem I see is that the JVM, like the CLR, needs to be able to intrepert you code in order to JIT compile and run it. You can make it more "complex" but given that the spec for bytecode is rather well documented, and exists at a much higher level than something like the x86 assembler spec, it's unlikely you can "hide" the process-flow, since it's got to be there for the program to work in the first place.
Make it into a web service. Then you are the only one that can see the source code.
It can't be done.
Anything that can be compiled can be de-compiled. The very best you can do is obfuscate the hell out of it.
That being said, there is some interesting stuff happening in Quantum Cryptography. Essentially, any attempt to read the message changes it. I don't know if this could be applied to source code or not.
Even if you compile the code into native machine language, there are all sorts of programs that let you essentially decompile it into assembly language and follow the process flow (OlyDbg, IDA Pro).
It can not be done. This is not a Java problem. Any language that can be compiled can be decompiled for Java, it's just easier.
You are trying to show somebody a picture without actually showing them. It is not possible. You also can not hide your host even if you hide at the application level. Someone can still grap it via Wireshark or any other network sniffer.
As someone said above, reverse engineering could always decompile your executable. The only way to protect your source code(or algorithm) is not to distribute your executable.
separate your application into a server code and a client app, hide the important part of your algorithm in your server code and run it in a cloud server, just distribute the client code which works only as a data getter and senter.
By this even your client code is decompiled. You are not losing anything.
But for sure this will decrease the performance and user convenience.
I think this may not be the answer you are looking for, but just to raise different idea of protecting source code.
With anything interpreted at some point it has to be processed "in the clear". The string would show up clear as day once the code is run through JAD. You could deploy an encryption key with your app or do a basic ceasar cipher to encrypt the host connect info and decrypt at runtime...
But at some point during processing the host connection information must be put in the clear in order for your app to connect to the host...
So you could statically hide it, but you can't hide it during runtime if they running a debugger
This is impossible. The CPU will have to execute your program, i.e. your program must be in a format that a CPU can understand. CPUs are much dumber than humans. Ergo, if a CPU can understand your program, a human can.
Having concerns about concealing the code, I'd run ProGuard anyway.