What techniques could I use to make my "jar" file Reverse Engineer proof?
You can't make it reverse engineer proof. If the java runtime can read the instructions, so can the user.
There are obfuscators which make the disassembled code less readable/understandable to make reverse engineering it harder, but you can't make it impossible.
Don't release it.
There is no such thing as hacker proof. Sorry.
EDIT FOR COMMENT:
The unfortunate truth is that no matter what barricade you put in the way, if the honestly want in, they'll get in. Simply because if they're persistent enough they'll be looking at your code from an Assembly level. Not a thing on earth you can do about it.
What you can look at doing is Obfuscating code, packing the jar and merging all externals packages into a single to make life harder. However no matter how high the hurdle, my comment in the previous paragraph still applies.
I think this is more about hardening the access path to the jar, more than anything else.
Try to determine what user context
will actually be executing the code
that will access the .jar. Lock
down access to the jar to read-only
access from only that user. How you do this
will depend on if you're using the jar from
a web app or a desktop .exe, and it will also
depend on the operating system you're running
under.
If possible -- sign the jar and
validate the signature from the
executable code. This will at least
tell you if the .jar has been
tampered with. You can then have
some logic to stop the executing application
from using the .jar (and log and display an error).
See jarsigner docs for more information.
I have seen one case where a company wrote a custom classloader, that could decrypt an encrypted jar file. The classloader itself used compiled JNI code, so that the decryption key and algorithm were fairly deeply obfuscated in the binary libary.
You are looking for an "obfuscator" (if you want to ship jars) . Many exist:
http://java-source.net/open-source/obfuscators
You should be aware that many obfuscation techniques removes information you may want to keep for troubleshooting purposes - think of the value of a stack trace from an irreproducible situation - or actual debugging sessions. Regardless of what you do, your quality testing should be done on the jars-to-be-shipped since the obfuscator may introduce subtle bugs.
If you really want to hide things, consider compiling to an native binary with gcj.
Definitely avoid placing any sensitive data in the code. For example:
passwords
database connection strings
One option would be to encrypt these (using industry-standard encryption routines; avoid rolling your own) and place them in an external configuration file or database.
As others have stated, any algorithms in deployed code can be reverse-engineered.
Sensitive algorithms could be placed in a web service or other server-side code if desired.
Related
how can I store API credentials like authentication key, google map API key securely, currently I have stored that credentials in strings.xml.KeygenratorSpec requires minimum API level of 23 is there any way to store securely any help will be more helpful I am stuck since 2 days but no idea.
Short answer: you can't do it.
Longer answer: You can use obfuscation in order to make it difficult to find the API credentials, but still, someone with enough time and a few skills will find it and break it. Using KeyGenerator will also not help. I am assuming that you were planning to encrypt/decrypt the API credentials. You will still need a key to be stored in or retrieved by your application. So, the same problem still remains, someone will just have to find one more string before being able to access your credentials.
Obfuscation is probably your best chance. Of course it's not bullet proof, but if it's complicated enough it might delay or demotivate someone who is trying to break your application. You can use proguard to obfuscate your application code (if you don't want to pay for something more advanced), however it will not obfuscate strings. You will have to use other techniques for that. You can find plenty of examples online, and you can use your own layers of obfuscation as well. I don't think that you will find any good recommendations or standards in order to do it. Of course, no matter how hard you try, it will still be a matter of time for someone to revert.
EDIT:
This is a good tutorial for configuring proguard: http://wiebe-elsinga.com/blog/obfuscating-for-android-with-proguard/ (be careful what you include because otherwise you might get crashes when you generate an apk)
Regarding string obfuscation, you can use something similar to this: https://github.com/efraespada/AndroidStringObfuscator however you will still need some password, so decryption will be possible. Using an existing string as a password (one that you are already using in your app) might confuse someone if you combine it with code obfuscation. Hiding parts of the string in various files/resources and combining them when you want to create the string will probably add more confusion. However if you make it too complicated it might be easy to spot. For example if your strings.xml contains only 1 encrypted string (unreadable), there is a good chance that this is the string that you are trying to protect. Following this will lead to this information. So, in my opinion, there are no best/good practices. You can get a few ideas by looking online, but I would suggest you judge for yourself where is the best (less obvious) way to hide it, and this depends on your code and application structure. But anyway, this will only trick inexperienced/lazy attackers and automated tools.
Another thing that I do often is to not allow certain parts of the code to run if debugging is enabled, or when the apk file is not signed by myself. These countermeasures are not bullet proof either, but might demotivate a lazy attacker. Here is a good guide on how to do this and other things: https://www.airpair.com/android/posts/adding-tampering-detection-to-your-android-app
Whenever I build my app all classes (logically) are visible in the .jar that comes out of it.
Aswell as a class that holds information to my MYSQL server (for the app to connect to). But I dont want this information to be publicly visible!
How can I "hide" this code or "hide" the class?
Thanks!!
I think you mean you dont want someone to do reverse engineering with your .class inside your jar file. There are many decompilers that can do that.
So you would need to Obfuscate your code with an obfuscator utility.
The process of obfuscation will convert bytecode into a logical
equivalent version that is extremely difficult for decompilers to pick
apart. Keep in mind that the decompilation process is extremely
complicated and cannot be easily 'tweaked' to bypassed obfuscated
code. Essentially the process is as follows:
Compile Java source code using a regular compiler (ie. JDK)
Run the obfuscator, passing in the compiled class file as a
parameter. The result will be a different output file (perhaps with a
different extension).
This file, when renamed as a .class file, will be functionally
equivalent to the original bytecode. It will not affect performance
because a virtual machine will still be able to interpret it.
Here is an article describing this process in more detail and
introducing an early obfuscator, Crema:
http://www.javaworld.com/javaworld/javatips/jw-javatip22.html
i have a desktop application that consists of 10 features, and some clients asks only for 8 features or 7 features.
i want to have a way to manage adding/removing the permissions/features for the client (only i can control that). so that i can hide/show feature based on a flag.
is that should be done through a property file that contains the name of the feature with boolean flag, or what ?
please give me some ideas, thanks.
From your other answers, it sounds to me like the following additional details have cropped up; please let me know if I have these wrong:
You're delivering your application as a .jar file,
Each customer gets their build directly from you, and there's a small number of customers,
You configure a build specifically for each customer, and
You don't want your customers to be able to modify their feature access.
In that scenario, I'd store the "active" feature list in a hashed property value stored in a .properties file bound into the .jar. I'll describe one way to do that below. You generate the properties file just before delivery, add the file to the jar:
jar -uf applicationJarFile.jar configuration.properties
then sign the .jar and deliver it. At runtime, your app can load the properties file, run the hash of each feature, compare with the properties you've stored, and determine which ones are off or on.
Your properties, which determine which features are enabled, might consist of a list like this:
feature1=enabled
feature2=disabled
feature3=disabled
feature4=enabled
Write yourself a utility which hashes the whole string "feature1=enabled" plus a salt value, e.g. "feature1=enabledaKn087*h5^jbAS5yt". (There's code for this built into java; see How can I generate an MD5 hash?, for example.) The result will be an opaque 16-byte number, which you can then store in another properties file to be included in your app: feature1=1865834.... The salt value should be broken into multiple shorter strings in your code so your customer can't just retrieve it and easily duplicate the process themselves.
In your app, at startup, you construct the string above using both the "enabled" and the "disabled" value, run the MD5 of both, and compare it with the stored hash. That'll tell you what features to enable.
I think a separate .jar or .properties is a bad idea; it clutters your delivery.
You can automate the whole process fairly easily, since you can generate the properties on the fly any time, and bind them into your app.
You can add other "baked in" properties which gives you a lot of flexibility in the final deliverable, including things like skinning for customer branding.
As others have pointed out, though: there's lots of ways to approach this, depending on the rest of the details of your product and your overall goals. This is one way to do it, given the assumptions above. AFAIK, there's no "canonical" way to do this sort of thing.
You should consider using a License management api to do the same, which will give u both security and capability to change License pre/post installations.
It is not advisable to build adhoc licensing capabilty, take a look at License3j and TrueLicense, they are both free and can help you gain perspective or better fulfil your requirement
You could try and encode that in a file. I assume each user has an own installation/version of the application, right? I further assume the application should not need to check some web resource. Thus you need to implement that in a file.
However, you should encrypt that file and put the salt and key somewhere in the code where they can't easily be decompiled. Additionally create a hash to check for modifications of the file. That hash could be based on the application's size or something else.
Please note that there's no 100% security and any hacker could still crack your application. But in that case this would need some form of criminal energy not commonly present in the business world.
Modularize the application and deploy to each client only those parts that he wants/has access to. There's many ways to do it (the most complete but heavyweight being OSGi), but the specifics depend on your circumstances and requirements.
The quickest way to implement it might be to simply extract your extra functionality in separate JARs, and on deployment update the classpath appropriately.
It depends on the kind of application,kind of security you want and the number of people likely to use the application.
If the number of clients is not that big you can store their preference in some in memory data structure like a Map . Otherwise you can use file system or a DB depending upon the kind of security you want.
This is very open ended - it really depends on what you're trying to achieve, and what you mean by a feature.
One approach is to use a plugin based architecture. e.g. you have an interface
public interface Feature {}
and provide each of your ten features as implementors of this interface. Then have some method which runs at application start which looks for Feature subclasses on the classpath.
You can control which features a client has by including only the relevant features on the classpath, e.g. using maven.
I did a quick search and could not find anything on this topic. I am not even sure if this is possible, but I am curious.
Is it possible to compile a Java program on a server right before a user downloads the program. The application that I can think of for this would be to modify a program's source code on the fly before a user downloads it. This could be helpful in a setup where the program is modified based on user input or settings on a website and those changes are hard baked into the program so what they download is a stand alone program that is customized and fully portable. The other application I thought of would be if each user were to use a different feature combination in a program so it is compiled only with the feature set they need/want on the fly.
I have a few programs ideas that I could test this out with, but this is mostly an academic thought and curiosity of mine.
So long story short, does anyone know of any technologies that could make a system like this work?
Sure, it's possible.
Just let the download link point to some script, that compiles / packages the source and sends back the result. This can be implemented in, for instance PHP, in just a few lines of code. It's quite similar to captchas: On-the-fly generated unique data, retrieved through a URL.
I myself have thought about this idea for protocol obfuscation purposes and for "software registration key algorithm" generation.
I would however recommend you to factor out the parts which you want to be recompiled into a separate class / set of classes, compile only these, and package it with the rest of the (already compiled) program upon request.
I have written a library using the Compile API (comes with Java 6) to compile code in ememory but I would suggest you don't need to pre-generate code as anything you can do with generated code you can do with dynamic code. There can be a slight performance advantage, but I suggest you try doing what you need with dynamic code (i.e. code with loops, if statements and reflection) to do what your generated code would do first as this is alot simpler and likely to do what you want.
Even if you must have generated code, it is useful to write the code in a non-generated form first so you are clear as to what you need the code to do.
I'm trying to create a process to patch our current java application so users only need to download the diffs rather than the entire application. I don't think I need to go as low level as a binary diff since most of the jar files are small, so replacing an entire jar file wouldn't be that big of a deal (maybe 5MB at most).
Are there standard tools for determining which files changed and generating a patch for them? I've seen tools like xdelta and vpatch, but I think they work at a binary level.
I basically want to figure out - which files need to be added, replaced or removed. When I run the patch, it will check the current version of the software (from a registry setting) and ensure the patch is for the correct version. If it is, it will then make the necessary changes. It doesn't sound like this would be too difficult to implement on my own, but I was wondering if other people had already done this. I'm using NSIS as my installer if that makes any difference.
Thanks,
Jeff
Be careful when doing this--I recommend not doing it at all.
The biggest problem is public static variables. They are actually compiled into the target, not referenced. This means that even if a java file doesn't change, the class must be recompiled or you will still refer to the old value.
You also want to be very careful of changing method signatures--you will get some very subtle bugs if you change a method signature and do not recompile all files that call that method--even if the calling java files don't actually need to change (for instance, change a parameter from an int to a long).
If you decide to go down this path, be ready for some really hard to debug errors (generally no traces or significant indications, just strange behavior like the number received not matching the one sent) on customer site that you cannot duplicate and a lot of pissed off customers.
Edit (too long for comment):
A binary diff of the class files might work but I'd assume that some kind of version number or date gets compiled in and that they'd change a little every compile for no reason but that could be easily tested.
You could take on some strict development practices of not using public final statics (make them private) and not every changing method signatures (deprecate instead) but I'm not convinced that I know all the possible problems, I just know the ones we encountered.
Also binary diffs of the Jar files would be useless, you'd have to diff the classes and re-integrate them into the jars (doesn't sound easy to track)
Can you package your resources separately then minimize your code a bit? Pull out strings (Good for i18n)--I guess I'm just wondering if you could trim the class files enough to always do a full build/ship.
On the other hand, Sun seems to do an okay job of making class files that are completely compatible with the previous JRE release, so they must have guidelines somewhere.
You may want to see if Java WebStart can help you as it is designed to do exactly those things you want to do.
I know that the documentation describes how to create and do incremental updates, but we deploy the whole application as it changes very rarely. It is then an issue of updating the JNLP when ready.
How is it deployed?
On a local network I just leave everything as .class files in a folder. The startup script uses robocopy or rsync to copy from network share to local. If any .class file is different it is synced down. If not, it doesn't sync.
For non-local network I created my own updater. It downloads a text file of md5sums and compares to local files. If different it pulls file down from http.
A long time ago the way we solved this was to used Classpath and jar files. Our application was built in a Jar file, and it had a launcher Jar file. The launcher classpath had a patch.jar that was read into the classpath before the main application.jar. This meant that we could update the patch.jar to supersede any classes in the main application.
However, this was a long time ago. You may be better using something like the Java Web Start type of approach, which offers more seamless application updating.