I wrote a software application in Java. Now I want to deliver it to my clients. But before that, I want to do something on that software which are mentioned below. You can answer any or all of the below questions:
I want to:
Encrypt all the .class files so that no one can decompile it. How can I encrypt it?
After encryption I want to obfuscate that code to add extra safety. How can I do that?
Add some "serial-key" functionality so that the software works only after registering it with the key provided by me. This is very important so as to prevent multi-user usage of my software. How can I add that key functionality and how can I generate keys. And how can I restrict that software to work only on a single computer.
The jar file can be unzipped and the .class file can be seen. Is there any way to wrap jar file into something so that no one can unzip that file.
I don't want to tell the client to first install java to run my application. So is there any way by which if anyone installs my software, the java automatically gets installed on his/her computer without informing him that java is being installed to his computer. If it is possible, then Is it legal to use Java software in this way.
Change the icon of the jar file permanently.
Implement a code which checks my site for any available updates.
If you want any other suggestions to increase the security of the softwre, then you are welcomed too.
In no particular order:
2 - There are products that perform obfuscation. They typically rename classes / variables / methods to single letter names. This makes determining user reported errors rather difficult. Stack traces showing the exception occurs in a.b.c are not particularly helpful.
1,3,4 - You can't fully avoid this risk if your are distributing java. Your code needs to be unpacked and loaded at some point. If someone replaces rt.jar in the jvm then they can replace the top-level class loader and dump out your classes like that. Obfuscation makes this less useful for them, but see the above caveat.
5 - Distribute a "private jre". Basically, you have a jre in your program folder. Your launcher script runs it. Increases the size of your distribution though.
6 - On windows, this would be a file association issue. But that would also affect all other jar files. Unless as part of 4 (however you manage that) you also use a different extension. Not sure about other operating systems.
7 - Use Java Web Start? Failing that, just have a file on your server listing the most recent version, fetch the file and compare with the installed version.
For 1,2,4 and 5 you could also look into compiling to native code using gcj or similar. Beware of compatibility issues if you do that though.
Encrypt all the .class files so that no one can decompile it. How can
I encrypt it?
You can't. If no one can decompile it, how do you expect the target JVM to?
After encryption I want to obfuscate that code to add extra
safety. How can I do that?
I want to add some "serial-key"
functionality so that the software
works only after registering it with
the key provided by me. This is very
important so as to prevent multi-user
usage of my software. How can I add
that key functionality and how can I
generate keys. And how can I restrict
that software to work only on a single
computer.
There are a couple of ways to do this but a simple one is with public key cryptography:
Your software generates a random request ID or a request ID based on the machine attributes and your user submits this to you.
You sign the request ID with your private key and send it back to the user.
The user provides the signed request ID to the software which validates that it was signed by you.
The jar file can be unzipped and the .class file can be seen. Is there
any way to wrap jar file into
something so that no one can unzip
that file.
No
I don't want to tell the client to first install java to run my
application. So is there any way by
which if anyone installs my software,
the java automatically gets installed
on his/her computer without informing
him that java is being downloaded to
his computer. If it is possible, then
Is it legal to use Java software in
this way.
Try building an NSIS installer for your application that detects/installs Java and your program.
Build a better trust relationship with your clients.
Then you can spend extra time ( not doing tasks 1-5 ) to make improvements, fix bugs, etc., which in turn improves relationship with your clients.
You can compile it with GCJ, which will compile your application to a normal Windows/Linux native executable (.exe). Then you can create an installation, using a program like InstallShield.
The company where I work actually ships unobfuscated jar files, with all debug information in place. That way, if an error occurs at a client's site, they can send us the full stacktrace which helps enormously in analyzing and localizing bugs in the code.
Trying to obfuscate your code will lead you into an arms race with potential crackers and consume huge amounts of time with little or no real benefit. Instead, I'd advise you to try and find other ways to make buying (and not pirating) your software worthwhile to your clients. For example, you could offer them free updates, or tech support, or something like that.
As for 6: You can use JSmooth or a similar tool to create an exe wrapper for your app. It will allow you to change the icon, and your clients will have an exe file that they can doubleclick without having to mess with file associations for jar files.
Note, however, that the generated exe won't contain Java or your jar files. It will, however, print a nice error message if Java isn't available.
Just adding on to the other answers here:
1 and 4: You could actually do this if you modify the JVM and pre-package it with your installation, but it's against Java's license agreement to distribute a modified JVM without paying Sun like a billion dollars.
Who is your client? Piratebay.org? Seriously, every major company in the US pays for software. The risk of a client quitting and calling them in is just too high. You need enough protection to make it easier for a programmer to get purchasing to pay for the product than to circumvent your copy protection.
Related
Im thinking about creating spring boot application that i would like to comercialize some day.
I planned to build a Jar that i would allow to download, and once client launched it locally and provided some license key, it becomes useable.
I have some doubts about this distribution strategy especially in the meaning of the safety of the code and licensing.
If i provided a Jar, anybody may try reverse engeenering on it - so its easy to be hacked or cracked.
Turning it into executable is more user friendly, also possibly may hide the code better, but still i think its relatively easy to be reverse engineered.
It made me think about obfuscation. If i completely messed up the app before prod build, it would be a way harder to understand or change the code. It may seem okay in the matter of "copying and modifying" the app, but still i think it would be easy to locate licensing limitations in the source files. For example: limit for 5 users can be easilly located in sources by value "5" or the message the user sees, and even if code looks awfull, this lines can be removed, project compiled again, breaking the limitation and wasting my entire effort.
It will be small application, I want to provide clients the instalator, and let them set it up personally. I dont want to be responsible for settting it up in the cloud for the client (without publishing instalator or Jar), as clients may not be interested in cloud based access.
Could You advise me some wise solution for this situaltion?
Thanks in Advance ! :)
The short answer is that there is no way to prevent reverse engineering if someone can run the software on hardware that they control.
The only way to 100% prevent reverse engineering is to ONLY run the software on a platform that you control ... and that can prevent them from getting a copy of the executables.
There are a couple of ways that can make reverse engineering harder:
Use an obfuscator on your JAR files. It will make it harder for someone to read the decompiled code. There are 3rd-party obfuscator products you could use.
Use jpackage (or a 3rd-party tool) to create a native executable for your application.
But beware that modifying an application to disable a license check is much simpler than full reverse engineering. A determined software engineer (or hacker) will be able to do that, given enough time and incentive.
Look at this problem another way:
There are many people and companies making money out of writing and supporting software without resorting to license keys, obfuscation and so on.
Conversely, there are probably millions of aspiring software entrepreneurs who never even turn their clever idea into a worthwhile (saleable) product.
Conversely, there are millions of apps (e.g. in Android app stores) that are simply not worth the effort protecting from IP theft.
Don't get lost in the problem protecting your IP before you have actually created it. And don't overrate its (hypothetical) value.
Why should I sign my JAR files?
I know that I need to sign my client-side JAR files (containing Applets) so that special things like filesystem access can be done, and so that the annoying bit at the bottom of windows doesn't show, but why else? And do I need to sign my server-side JAR files containing Servlets, etc.?
Some basic rules for when and when not to sign JARs would be appreciated - thanks!
The short answer - don't, unless your company policy forces you to.
The long answer
Signing jars is effectively telling your customer "I made this, and I guarantee it won't mess up your system. If it does, come to me for retribution". This is why signed jars in client-side solution deployed from remote servers (applets / webstart) enjoy higher privileges than non-signed solutions do.
On server-side solutions, where you don't have to to placate the JVM security demands, this guarantee is only for your customer peace of mind.
The bad thing about signed jars is that they load slower than unsigned jars. How much slower? it's CPU-bound, but I've noticed more than a 100% increase in loading time. Also, patches are harder (you have to re-sign the jar), class-patches are impossible (all classes in a single package must have the same signature source) and splitting jars becomes a chore. Not to mention your build process is longer, and that proper certificates cost money (self-signed is next to useless).
So, unless your company policy forces you to, don't sign jars on the server side, and keep common jars in signed and non-signed versions (signed go to the client-side deployment, non-signed go to server-side codebase).
Signing a jar file, just like using certificates in other contexts, is done so that people using it know where it came from. People may trust that Chris Carruthers isn't going to write malicious code, and so they're willing to allow your applet access to their file system. The signature gives them some guarantee that the jar really was created by you, and not by an impostor or someone they don't trust.
In the case of server-side or library jars, there's usually no need to provide that kind of guarantee to anybody. If it's your server, then you know what jars you're using and where they came from, and you probably trust your own code not to be malicious.
A good reason could be if you never wanted anybody to be able to sneak in modfied classes to be called by your code.
Unfortunately that includes yourself :-D So this is only to be done if you really need it. Check the "sealed jar" concept.
In terms of applets: From 6u10, the Sun JRE replace the warning banner with less obtrusive (from 6u12, IIRC) warning triangle (necessary to support shaped and transparent windows). 6u10 also allows controlled file access through the JNLP services API.
The principle of least privilege says that you should not sign the classes of your jar files. Security is not necessarily easy.
Simply showing a certificate dialog box should not be construed to mean that the entire contents of a web page is to be trusted.
I'm deploying a JavaFX application and am not quite sure what does and doesn't need to be signed. Here are my thoughts:
- Installation file:
This obviously needs to be signed.
- The EXE that launches the application:
I believe this needs to be signed, although it feels a little bit funny because it isn't my code.
- My JAR files: I believe that these also need to be signed, although I'm not sure if anything terrible happens if I don't.
- Library JARs that I've grabbed off the internet: I don't feel like I should sign these. Is there any reason to?
- Java runtime:
I'm guessing there's no reason to sign this, and I'd probably violate some agreement if I do.
- JNLP file:
Not using this, no reason to touch this.
Have I looked at this properly? Am I signing the correct files?
A friend of mine has a saying " it's not what you did... it's what you can prove in court. "
With this respect, I advise you to look at this problem from a legal point of view and assume the worst possible context it can apply in; i.e. you becoming legally accountable after someone tampers with your software.
Digital signatures are designed especially for these types of problems.
With this respect, let's split your answer into 2 different classification parts:
the software you're releasing - includes your jars, jnlp, bundled .exes, etc.
all of these must be singed in order to ensure that you can't be affected by any unauthorized tempering with your own code. It doesn't matter whether or not you've released that jnlp. If someone generates an invasive one and it's traced back to you, your failure to authenticate your own released version of that jnlp will not be ok.
the software released by other people. - includes everything which you're using in order to get your system to work. (jre, libs)
when using something like this, it's a good idea to make sure you're using a genuine copy of whatever your lib manufacturer has released. Use their checksums/signatures/etc. to validate and verify their software integrity upon demand. You have to read their liability and disclaimer statements and in the event they fail to provide one themselves.
In general it is a good idea to place as little trust as possible when it comes to software sources other than yourself. Unfortunately, there are many compromised or malicious libs out there which are in fact security risks.
it is always a good idea to make sure you're releasing a downloaded lib which is certified by an external issuer and as such cannot be held responsible for any malicious code detected within.
To answer your question... it really depends on the client endpoint and the likelyhood of you getting sued for providing them with a security risk (i advise you to always expect this to be 100%). If you're liable for damages... you need to proceed accordingly.
In short... the best possible answer to this quesiton is to do whatever is possible to cover yourself in the event the worst happens.
Does your application need elevated privileges? If the installer is targeting Windows you wish to install the application to Program Files, then your installer will need to be signed. Without it, Windows will give a yellow banner during privilege escalation request.
So - sign your installer.
The exe that launches the application should ideally be signed as well. But for a java application, this is perhaps a mute point. Signing the exe is easy enough, that I'd just do it anyways.
Sign launcher exe - Optional, but I'd do it
Jar files. This is an interesting one and depends on what you goal is. Ie, the OS and the end user are probably not going to be aware of the signed or unsigned nature of your Jar. Therefore you will probably have to verify the integrity of the jar yourself. See https://docs.oracle.com/javase/tutorial/deployment/jar/signindex.html
Perhaps the launcher application can perform the integrity checks before the launch step ?
Library jars, Similar to the case above, if you want to make sure that no one has dropped in a diff jar into your application or some such use case, you will need to verify this yourself.
Java Runtime If you shipping this, is this not already signed by Oracle or your JVM vendor ?
I have a dilemma. Basically, I've given a group of people I'm friends with a program that utilizes source code that I don't want anyone outside the group knowing of. We all know Java is absolutely horrible at doing any level of obfuscation, as most obfuscation tools only rename objects, scramble code, etc. I've used such tools, but to be honest I'd like to go as far as possible with the security of the program.
Since the application requires a username, password, and other identifiers to log in to the server it uses, I was beginning to wonder if a unique AES key could be generated for the user to secure the JAR.
Basically, upon running a launcher of sorts to log in, the launcher app may request an AES key from the server, and use it to decrypt a secured JAR it's downloaded from the server already. The key would be completely unique to each user, which would mean the server would have to encrypt the JAR differently for each user.
Now, I know how crazy this sounds. But since this is such a low-level thing, I need to know if there is a way you can somehow both decrypt and run a JAR from any type of stream. Or, if that isn't possible, would it be reasonable to decrypt the file, run it, then re-encrypt it?
Of course you can decrypt and run Java bytecode on the fly - bytecode manipulation libraries such as ASM even go as far as creating new classes dynamically.
But, quite honestly, if something actually runs on a computer then its code is definitely going to be available to anyone with the knowledge. Java, especially, is even more convenient since it allows far better access to the bytecode of a class that is loaded by the JVM than any natively compiled language.
You could theoretically take your obfuscation a bit further by using JNA/JNI and a native shared library or two. But, in the hands of a determined attacker no measure will protect your code completely - it would just take more time for them to figure out how your algorithms work. And if you are concerned about piracy, well, we are in the era of virtualization; you can actually clone whole computer systems from top to bottom with a couple of key presses - you figure out the rest...
The only potentially viable solution would be to offer your software as a service, with all the issues entailed by that approach - and you would still not have absolute security.
If you are that concerned about protecting your intellectual property, then get a lawyer and consider publishing your algorithms in some form - obscurity will only go so far. It will not stop someone from doing black-box analysis on your system and quite often just knowing that something is possible is enough.
Please stop trying to find technical solutions to a problem that is so obviously not of a technical nature...
My answer would be to keep the server information outside of the jar entirely. Use a parameter or configuration file to point to where to get that information. Then the jar file has no secrets in it. Only the server where the code runs has that information. You can then do things like make the configuration file readable only by the user that can run the code in the jar.
Can we completely reverse-engineer the source code from java bytecode ? Why this feature is allowed in Java and How successful are java decompilers against obfuscators.?
I know this question is old but I kept looking for a reliable answer until I found nothing.
So in this post I summarize some of my effort to obfuscate a J2EE JAR.
It seems , that by year 2014 (time of writing) there are not many options out there.
If you read this review later then things may have changed or fixed.
When I think why , I start to sense that the whole obfuscation effort gives a false sense of security. Don't get me wrong. It does add a level of security, but not as much as I would hope.
I will try to give a preview of what I found to explain myself. My recommendation are personal , others may disagree with it.
So to begin with: obfuscation in Java is the process of taking bytecode and making it less readable (using a decompiler of course) while maintaining its original functionality.What can we do, Java ,working as an interperter, must keep its bytecode exposed. You run the obfuscator as a measure of security in case the class file falls into the wrong hands. The result of the obfuscation is a reverse-mapping files and a JAR with the obfuscated classes. The reverse mapping file is used of-course to perform stack trace reading (a.k.a re-trace) or to revert the bytecode to its original shape. The runtime performance hit of an obfuscated class should not pass the 10% (but this really depends on what you do in your code).
But there is a big “but” . Obfuscation will scramble your code but it won’t make it hacker-proof. Bare in mind you only buy time and a determined hacker will find a way to reverse engineer your bytecode into its pure algorithm.
IMHO: the best way to hide a sensitive piece of code is to drown it in some huge pile of meaningless code.
Some of the hackers will try to modify your bytecode (by code injection) to help them achieve their goals. Some obfuscators offer additional level of JAR hardening , making it harder to modify.
De-obfuscators and de-compilers: my favourite Java decompiler is JD-GUI . However, when it comes to de-obfuscators I found the market pretty empty. Most of the tools ask you for a hint (what obfuscation tool was used to encrypt the source JAR) , yet none of them really deliver results (some of them even crash when trying to de-cipher the JAR). They are open source projects with low maintenance. I couldn’t even find a paid application to do a decent de-obfuscation. so enlighten me if you know something.
Free solutions
There are open source , free obfuscators which usually simply rename the classes/methods names, making it one letter method (i.e. from printUsage(String params) to a(String p) ).
They might ,as hinted here , even strip debugging information to make it a bit more difficult. (debugging information is kept at the end of every Java method bytecode and contains: line numbers, variables names ,etc.).
Its a nice effort , but an experience Java developer with a debugger can very easily deduce the purpose of each parameter while doing few live runs.
One of the nice open source obfuscators is ProGuard but there are several more tools.
Nevertheless , if you truly security fanatic you will probably want something stronger. Stronger demands more features (and more money) which leads us to the next bullet:
Paid solutions
While free products may only change classes method names , paid product will usually offer more features:
code/flow obfuscation: this will change the method code and inject empty loops/dead code/confusing switch tables and alike. Some of them may even scramble the exception table content. the obfuscation strength usually determine the output size.
Note: regarding code obfuscation: I deliberately avoided the details in my review. Some of the bytecode I saw and analyzed expose their obfuscation methods, and I wish to protect their IP. I do have an opinion about who uses better algorithms. contact me if you wish to know.
classes/method renaming : well this is the obvious , we discussed it in the free obfuscation. Some of the product will rename the class name and then recursively search for reflection usage of that class and fix those too. Paid products may even rename Spring /Wink configuration files for the same purpose (renaming in reflection).
String encryption: for every string “like this” in the code, it will encrypt it to some level and keep the key somewhere (in the class constant table/static blocks/a new method or any other mean).
debug information : stripping parts or scrambling.many of them will remove the line numbers info.
class
hardening: all kinds of methods like injecting some signing scheme into the beginning of the class/method, making sure an outsider won’t be able to easily modify the JAR and run it. Less important for Android or applets as most of them are digitally signed anyhow. some will combine hardening with water-marking to track pirated copies. But we all know anti-pirating methods by software are doomed to be hacked. Game industry suffered from it for decades until network based subscriptions arrived.
Since most products here deal with Java , some of them provides Android integration. It means it will not only obfuscate the Java (dalvik) code , but also manipulates the Android's manifest file and resources. Some offer anti debugging: remove the debug flag in android apps.
Nice GUI app to configure the various options and maybe do a re-trance on a given log file. The UI is usually used to generate a config file. with such file you can later re-play the obfuscation many times, even from command line.
Incremental build support - this is useful for large groups who release product updates/fixes frequently. You can tell the obfuscator to preserve old “obfuscation” result and randomly obfuscate only “new” code flows. this way you can be sure minimal impact on your methods signature. Without this flag , each obfuscation cycle on a JAR would yield a different output as most good tools use some level of randomness in their algorithms.
CLI and distributed builds. When you work alone then running an obfuscator is not a big issue. you need to configure the obfuscator to your relevant options and run it.However, in enterprise , when integrating obfuscator into the the build script things are a bit different. There is another level of complexity: build engine tasks (like ant/maven) and license management. The good news that all obfuscator I tested have command line API. In distributed build environment there are cluster/pool of build machines to support concurrent demand of builds. The cluster is dynamic and virtual, machines are going up or down, depending on various conditions. Some obfuscation products are based on cpuID license file or hostname. This can create quite a challenge for the build teams to integrate. Some prefer a local floating license server. Some may require public license server (but then: not all build farms have access to the public internet). Some offer multi-site license (which in my opinion is the best).
Some offer code optimizations - algebric equivalence and dropping of dead code. Its nice, but I believe that today's JDK do good job in optimizing bytecode. Its true that dead code makes you downloadable bigger, but with today's bandwidth its less than a problem. I also want to believe that in software today 20:80 thumb rule still applies. in any application 20% is probably a dead code anyway.
So who are the players I tried ?
KlassMaster by Zelix.com - one of the oldest in the industry. Yet they deliver a solid product with 3-4 releases per year. This been going for decades (since 1997). Zelix provides good email support and answered all my emails in a timely manner. They have a nice GUI client to either obfuscate a JAR or create a config file for future obfuscation. It simple and slick. nothing special here. They provided simple to read on-line documentation for all their flags. they support both “exclude” and “include” regular expressions for what the engine should obfuscate. The thing I liked about their process most is that it also adds “noise” to the exception table. It makes it a bit more confusing regarding the method exception handling. Their flow obfuscator strength is quite good and can be configured between 3 possible levels (light,medium and aggressive). Another feature I liked is the fine tuning they provide for debug info stripping (online line numbers, or online local variables or both). Klass Master doesn’t provide any
dedicated Android flags or anti-tamper methods. Their licensing model is quite simple: a text file to be placed near the KlassMaster main JAR. They also support incremental obfuscation.
JFuscator from secureTeam.net : While secureTeam also has a .Net tool , I focus on their Java tool capabilities. Their (Swing based) GUI tool seems nice but it crash when trying the simplest obfuscation task. the error was always the same: Error reading '/opt/sun-jdk1.7.0_55/jre\lib\rt.jar'. Reason: ''/opt/sun-jdk1.7.0_55/jre\lib\rt.jar': no such file or directory' . Now of course I have my Java installed in /opt/sun-jdk1.7.0_55/jre. You can image that they simply didn’t expect linux back slash structure. I contacted secureTeam.net support by email with the minor “path” problem. They asked if I am a linux user and after I replied I am , they never answered my email. I also tried their web site on-line chat : no response. So there I stopped testing. Without further results, I couldn’t examine the obfuscated bytecode quality. From their web site it seems they have anti-tamper method , String manipulation, method renaming and few other features.
GuartIt4J (by Arxan.com) : Arxan is fairly solid player in the mobile environment and as such they offer Android obfuscator which of course works well for Java. They have one of the most flexible engines.They provide code obfuscation,string encryption and alike You can define the complexity of code obfuscation. it is simply an integer. the higher - the longer your method turns out. ofcourse, you must be carefull not to exceed the JVM 64KB limit per class… As I said before one of the best strategies to hide a sensitive code is not to encrypt it , but to inject it into huge pile of garbage. This is exactly what GuardIt does. It can also explode in the same way the methods exception table. I managed to create a method with 100 exceptions in its exception table (pre-obfuscator it was 5). what they miss: their re-trace program is not part of the supplied main JAR. Nevertheless, they were kind enough to send me a sample Java program that performs re-trace given the reverse mapping file and the log. They don’t support incremental obfuscation and no flexibility regarding debug information. Debug information stripping is either all or nothing. watching the output JAR you will tons of conditions and jumps that were injected. Bare in mind , exploding the class size has its performance hit. In some methods I measured almost 50% performance hit when applying long obfuscation (no I/O in those methods). so extrapolating the code comes with a price.(from a 400 opcodes - I went up to 2200 opcodes after obfuscation). JD-GUI , my de-compiler failed to open such classes and crashed (IndexOutOfBoundException). They also supply complete class encryption . Meaning the class is encrypted with some symetrical key which demands a special (or custom written) class loader to open it in memory. This is an anti-tamper mechanism as well as hiding code. Just remember that a JVM can’t run that class without the class loader help. Its a nice feature, but the secret key and the bootstrap loader JAR are probably there. If he got the encrypted JAR the hacker will eventually get his hands and decrypt the classes. Yet this another level of obstacle the common hacker will need to pass. What I didn’t like here is the license file policy: is bounded to CPUid or need to install a floating license server.
SecureIt (by Allatori.com) : SecureIt offers all the general code obfuscation, string encryption ,renaming and such. On top of the standard obfuscation methods they also offer some kind of water-marking which is an anti-tamper/pirating method. They support Android and JavaME (who uses ME these days?!). They support incremental obfuscation. The one thing to note about configuring SecureIt: it is all command line. No GUI tool this time. Personally , I don’t mind command line tools as long as they come with good documentation. Luckily they have a very good documentation and a rich API with many flags to tune if you wish. you can re-trace with they tool (also a command line ) . They can’t obfuscate the exception table. I didn’t check their licensing mechanism.
DashO (by Preemptive.com) : DashO obfuscator will be remembered probably as the best UI tool you can get (to create your configuration). Like SecureIt they lake the exception table obfuscation but they have all the rest of the required features (as well as CLI, Spring framework and gradle/ant integration, and even an eclipse plugin) . Well, they do document a try-catch obfuscator (which is same as exception table obfuscator) , but it is only a recommendation to the engine. When I tried it , it had nil effect on the exception table. As I said , the GUI tool is superb and has a re-trace embedded into it. they also offer some kind of application signing and water-marking as an anti-tamper/pirating mechanism. DashO provides superb Android integration and also combine in their product a door for analytics uploads. You can actually track your application. Injecting crash log uploaders and reporting code to your JAR. Nevertheless that’s not the scope of obfuscation - that’s a whole different code injection product. They have a very good support. both online and by phone. Their licensing scheme is based on monthly subscription or one time purchase payment. A bit different than others. They are using a floating license server to support large environments.
I hope this helps a bit..
Can we completely reverse-engineer the source code from java bytecode ?
Not completely, because some aspects of source code, such as whitespace, local variable names, and comments, are not preserved in bytecode. Otherwise, yes -- while you can't get the exact same source code out, you can almost always get something that can at least be compiled back to the same bytecode.
Why this feature is allowed in Java
It's not so much "allowed" as it is "not prevented". And it's not prevented because doing so is impossible -- the code must be runnable to be useful; if the code is runnable, then it is analyzable; if it is analyzable, then with sufficient analysis it can be converted back to source.
How successful are java decompilers against obfuscators?
Not very. Most obfuscators I've seen (esp. ProGuard) are primarily effective in removing meaningful function and class names; obfuscating the logic itself is not typically attempted.
you can get source code from binary these days. Although the source code obtained by Java's bytecode is more readable, obfuscating will make it slightly unreadable. Its not that only Java can be reverse engineered to code. Even C/C++ these days (with Hexrays plugin for IDA Pro) can be decompiled to source. Obfuscaters will make it hard to read but not impossible. There is nothing that can save your program from an intelligent and capable reverse engineer. :).
Good luck.
Can we completely reverse-engineer the source code from java bytecode
?
The java class file is based on a spec so anyone can read into it. A tool like JD-GUI will tear into your source code easily. It is not a 'feature' per se. While 100% reverse-engineering is not possible, most of your code can be reverse engineered.
How successful are java decompilers against obfuscators?
Depends. The point of the obfuscator is to remove any meaningful names and try to introduce confusion in the code without impacting performance. Most developers are great at obfuscating code themselves :) Pro-guard is pretty good at obfuscation.