Objective:
Secure my Java application from reverse engineering.
Idea:
split the program into two halves (loader and program)
loader will be a regular jar
program will be an encrypted jar file (bouncycastle, AES?)
loader asks secure server (https) for a key to decode program
loader then decodes program and loads up it's classes
Questions:
Would number 5 be possible?
Has anyone here done this?
Do you know any library already available?
Can you spot major pitfalls / would you do it differently?
Extra
I know it is impossible to prevent full reverse engineering of the code.
I'm just looking to make it harder and more traceable.
This is very possible using Class Loaders. But it is still very easy to decode your program. All one would need to do is change your Loader to write all the classes to disc before it loads them into memory with your custom ClassLoader.
Update
If the Loader is something your users can execute then I would just need to decompile and replace the Loader JAR file to dump the classes to disk. Not only that I am certain there must be something that can take a memory dump of a JVM and output all of the loaded byte code.
If the Loader is on a locked machine in which users cannot obtain access, then what is the Use Case you are trying to solve?
The "solutions" to these problems are:
Use an advanced Obfuscator that is designed to break decompilers.
Prevent access to the JAR files themselves. Either through ACL's on the machine or by employing a remote server to execute the code you want secure. This is essentially how Web Applications work. There can be a substantial amount of IP or processing that Stackoverflow does but we would never have access to the back-end processing, on the result of the User Experience output.
Sure, it's all completely possible; by defining your own classloader you can use an arbitrarily complex process to generate the classes, which will then be available to be reverse engineered.
The only way to protect an algorithm from reverse engineering is to execute
it remotely, in which case the problem becomes that all the inputs and outputs
of the remotely executed code can't be trusted.
Related
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 have been developing a static program analyzer (a kind of tool that attempts to detect program errors at compile-time), and it is almost finished. I would like to put a demo version to the web so that the few people who may be interested into the tool can test out its functionalities.
Context:
1. I have a personal computer to be used as a server if necessary. Otherwise, I am not sure if it is technically possible to put the demo to the computers of my institute because their computers do not have the required library used to launch the demo.
I am using Eclipse and Maven to develop this analyzer. The analyzer is written in Java.
The analyzer is somewhat time-consuming. It takes, for example, 5 seconds and 500 Mo JVM virtual memory to do an interesting work. So I need to limit the number of accessors.
I do not plan to send the .jar files to the clients, because I don't know who they will be.
I know nothing about the web application.
Under this context, what is, in your opinion, the easiest way to demonstrate my analyzer on the web?
This may be a different question from most questions about how to convert a desktop program to a Java web application, such as this
Thank you.
[EDITED] What would be the best solution if the constraint 3 above is to be taken into account?
You may be looking for Java Web Start, a deployment option used by the popular analyzer, FindBugs. This example illustrates few key concepts and leverages minimal-cost hosting.
Addendum: #Capn Sparrow helpfully comments that Java Web Start downloads copies of the program's JARs from the server to the client, violating requirement three in the question. This entails several risk/benefit tradeoffs:
Pro: The server can be easily updated to ensure that the client always has the latest version. JARs are cached on the client, minimizing latency on update.
Con: The cached JARs may be decompiled or tampered with. The user must accept whatever <security> setting is chosen or reject the application. Using jarsigner can mitigate some risks.
So I am working on a java application, and the customer has requested the ability to have features that which can be unlocked to make the application customizable based upon what their customer wants to pay for. So I am trying to come with ideas for doing this in a manner that will provide some level of security, but also general maintainability and readability.
I have been doing some searching around, and had some ideas of my own, maintaining an encrypted configuration file which could possibly be stored in a jar file that I could unload, repack, and load at run time.
Looking to see if anyone else has any interesting ideas on how you might do this. I have been doing some looking on google without a lot of success thus far.
Oh one last little caveat, the machines this java application is on may not have internet available to them. So running a license server doesn't seem like a viable option
I would suggest using some sort of dependency injection or runtime weaving aspects, so you can include new jar files that have the correct xml files or configuration files for new features.
I agree with coobird that including them and locking them is inherently risky as someone will eventually decompile your application and determine how to get all the features.
The only sure way to prevent "unauthorized access" to features that are "locked" in software is not to provide the code that one does not want the user to have access to in the first place.
Enabling extra features by unlocking using passwords, encryption (where's the key going to be? In the program itself?), configuration file can usually be defeated by someone who is determined to get to the code they want to execute.
At least unlocking using software means can most likely be defeated, if the code that is locked is already being distributed in the binary. One way that I can think of off the top of my head that seems a little secure is an hardware key dongle, or having important code that is stored on hardware, but not many people like the idea of having to plug in a piece of hardware to use the software.
When it really comes down to it, don't have features in the code itself which is only disabled by some software flags.
I suggest you build a trusting relationship with your customers. Either that, or bundle a USB key dongle, but even these are not 100%.
If you are distributing software, any kind of encryption must be able to decrypt itself. You are essentially giving the customer both the lock and the key.
You could possibly implement the core product, and then have the additional features as plugins. You could put each plugin in a separate jar file. The customer could then distribute a bundle that contained the core application, and the purchased plugins. Thus the un-purchased functionality is not in any of the binaries.
Distribute the full set. Have them call you for the keys to unlock various features. (Use a simple encryption scheme so that the keys are of reasonable length and can be conveyed over the phone.)
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I am working on project that must need to protect data (revealing code is not main problem) files. We are using Java + Netbeans. Is there any facility that will create jar in encrypted format? We are also using sqlite for database - so putting text file in encrypted format is not proper option for us too.
Creating encrypted JARs is not possible, since the executing JavaVM has to somehow be able to read the data it wants to execute.
And similar to a VM it would be possible for anyone with the proper tools and know-how to extract all data from the JAR.
If it would be possible to encrypt the JAR, you would also have to provide some decryption-key or facility to the client which wants to execute the JAR which defeats the purpose of encryption at all.
The best you can get is obfuscation, but that's no real security or hurdle for the ambitious attacker.
Kosi2801 is pretty much right on. The only thing I can think of you could do is the following, but it's ugly.
Ship a small standard JAR and an encrypted data file.
When the JAR runs, it decrypts (some) of the encrypted data file into memory (like the directory of where data is in the JAR, basically a simple in-memory file system of pointer/length pairs)
Set up your own class loader that, when called, gets the right encrypted bytes from the JAR (using the pseudo-FS table described in #2), decrypts it, and then loads the class data from there
This would let you load the classes. You could do the same thing (without the class loader) to load other resources.
While fun to implement (for those who like a challenge) there are a few problems with this:
You'd need to be able to decrypt the stuff, so the user would either have to enter a password every time or something similar. If the JAR knows enough to decrypt it's self, then anyone can look at it and figure out how to decrypt things. This could be mitigated by contacting a known-good server over the Internet to ask for the decryption key (as long as you make that process secure). Of course this requires an active 'net connection any time someone wants to run the program.
Everything ends up in memory. Without a custom JVM that handle tiny bits of encrypted byte code (as Cameron McKay mentioned) the classes will end up decrypted sitting in main memory at some point. Unless you rely on the OS to prevent other people from reading that memory, you've already lost the battle to anyone with a little time on their hands. Same issue for resources (such as images/fonts/etc) that you try to read out of some encrypted store.
So you can give people the run-around and make things harder, but in the situation you've given all you can do is try to make it not worth the time the other person will have to invest.
Software protection is tough, especially in something like Java that can easily be decompiled and can't alter it's own code like C/Assembly could. There is a reason some of the most expensive software out there requires hardware dongles or comes locked to a certain CPU or other hardware.
I agree with Kosi2801. Class file encryption is just imitation of security (see http://www.excelsior-usa.com/articles/java-obfuscators.html)
Use of custom ClassLoader's can break the application, e.g. in Application Servers.
There is the better way: use encryption of String constants in a class files. The most of commercial obfuscators have this function, for example Allatori, Stringer Java Obfuscation Toolkit, Zelix KlassMaster, Smokescreen, DashO (super expensive). The Stringer Java Obfuscator has call context check and integrity control features which makes protection really hard to hack.
The most secure way is to store and execute parts of bytecode on an external device like JavaCard.
N.B. I'm CEO at Licel LLC. Developer of Stringer Java Obfuscator.
In general, there is no way to do this in a secure fashion, if you want the app and its data to be self-contained. However, you can certainly encrypt the files and decript them with a key buried in the code. A determined hacker can get it, but if that's not what you are worried about, then fine. If you do this, remember that encypted data cannot be compressed, so compress first, then encrypt.
If you genuinely need the data to be secure (eg, confidential data), you will need to encrypt the data with a key and supply that key to the app my some external means, such as putting it on a thumbdrive and getting that to the user by means of a secure courier.
Another possibility it to make the data (or the key) available over SSL, and use a good authentication method to verify who your user is.
In general - it's not possible for any system to be perfectly secure, but it's also not nessesary. A system only needs to be secure enough to discourage the attackers that you think will be trying to crack it.
Another option would be to make a custom JVM that decrypted the JAR on the fly. But the same problem remains: at some point the JAR Java classes have to be decrypted to be run by the JVM, and at that point they can be captured and de-compiled.
Not to mention that having a custom JVM would then require all your users to download that JVM as well.
You could use the CipherOutputStream and CipherInputStream to serialize Java objects to disk in an encrypted format. This may an option open for saving data.
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.