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.
Related
My client wants to setup a script/file in Ubuntu in one of my client's contractors system to monitor his work/sites visited etc as long as he is in office.
His contractor will have root access in the system, so how can we make sure that the file cant be changed ? Deleting wont help him as his boss will know that because he wont get the online reports anymore after deleting.
But he can change it to the way he wants. Actually, we can write a java.java file or python or some program file but I found that even java.class files and python.pyc files can also be decompiled.
So, he can easily know the program and can easily change it.
So, any solution for this ?
Assuming you have legal issues taken care of, your only hope seem to be Encryption and Security through Obscurity.
Go for languages which are tougher to decompile, such as C/C++ (see this)
Ensure that you collect a lot of data, and store all the data encrypted so the client cannot directly access it.
Try and obsfucate to hide away your encryption keys, as well as the encryption algorithm.
Send the data from the contractor's system to the server encrypted.
Possibly also monitor whenever the contractor killed your process.
The best solution would be not to do this.
Now I don't know about your country's legislation, but in mine, any solution of this sort would be highly illegal. If the client is worried about the contractor, there would be other means of "monitoring" them.
Daily reporting
Set up a proxy blacklisting sites, possibly enforcing it over network tools
Actually meet the person and talk with them about their achievements, difficulties and such. Not inquiring, actually caring about how the project is going. If that doesn't motivate the contractor to work, nothing will.
I am working on a project which requires the secret key to be hidden somewhere in the Android app, so that it can't be taken out even after decompilation.
The requirement even states that the key should not be visible to the developer, that means it should be embedded into some pre-compiled library.
I have tried the following things:
Making Jar and obfuscating the jar, Which becomes unusable after that. And its useless method to work with Strings (it doesn't encrypt Strings).
Making C library and using that library(NDK). The strings can be easily read using linux commands. Example: '$ strings '.
I am trying to find out other ways by which this can be done.
Please help me with this. If you have any idea, please share. I would be more than obliged.
Thanks.
Anything that your app can do, can also be reverse engineered by a determined capable hacker, so don't expect some magic way to make this key perpetually secured.
If your goal is to supply an SDK that will be licensed to different developers, then the easy approach is to allocate a unique key for each developer, and let them take care of hiding it from hackers.
On the other hand, if I read your requirement literally, it is enough that the key string will not appear in plain text in the APK. The easy solution is to encode it. You can do something as easy as base64 encoding of the key, or as tricky as providing a C function that will calculate this key on the fly (so no traces of the key will appear in the output of strings).
It's a hard problem. You're fighting a battle against reverse engineering your application. There are tools that are build for this, notably DexGuard and Arxan. Arxan is really, really clever, but it will cost a lot more than a solution like DexGuard.
For aar and jar protection against decompilation you can use Quixxi. Of course the effort is about raising the overall protection as much as possible, impossible is nothing. But this solution joins the best of both the points you made. What happens is the following conversion:
input: unprotected jar file
output: java file calling the native layer
You [or the developer that will need to manage the app containing your library] can later integrate it as described in the same link. Moreover the entire app can be protected with the same tool if other parts of it will need to be secured
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
How can I obfuscate plain text data so that a Java program able to deobfuscate it is difficult to reverse engineer? That is, there should be no easy way to figure out how to descramble the data yourself by decompiling/disassembling the JVM code for the program.
I realize this is impossible if a bad guy is determined enough. Just want to make it as hard as possible.
The only idea I have is a native extension implementing an encryption algorithm with the key stored in a quirky way, not just a simple string. But would really like to avoid a native extension.
Edit
I vehemently disagree with the down and close votes. This is a real problem. The app is fielded to thousands of high school kids. To scramble the data, it currently implements RC4 encryption (in Java) with the key embedded in the code. Smart kids are able to decompile this and use the decompilation to write Java that reads other kids' data files. This in turn allows various forms of cheating. We need a simple, cheap way to make it harder to deduce the scrambling algorithm. That's all. We don't care about reverse engineering the rest of this 80k line app. In fact it's open source. We just need to protect the single function that does the data descrambling.
Anything that a program can decode, a program can decode. Any Java program can be decompiled. Even storing the data remotely won't work since after the data's downloaded you're decrypting it, and that can be replicated or patched. If plaintext is ever exposed, it can be accessed. You can make it difficult to access, but in the words of a hacker many years ago: "Hey, great, it's copy-protected -- that means it comes with a free puzzle!"
Remember, there's a reason password storage typically uses trap-door cyphers and compares the cryptographically hashed values. And even that requires keeping the encrypted passwords somewhere that the user is absolutely unable to access.
Step back and reconsider your design.
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.