We Keep Coding

Safe distribution of Spring based application

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.

Java safest way to check client jar server side

I am creating a client-server application in which I have to make sure that the client has the exact same file I give them.
I was thinking about sending a hash or jar size to the server, but that can easily be bypassed with reverse engineering the code.
Is there a way to ensure that they have the same file yet they can't hack it?

Short answer: No.
Longer answer: Most likely no, at least not without e.g. having access to their hardware and locking it down some way, like with modern gaming consoles. Take PC software, especially games, as an example. Pretty much every game ships with copy protection, yet they all can be found for download free of charge in certain areas of the internet, with copy protection removed. Yes, most of them can't be used for online play anymore, but that's mostly because you need an account that you'd only get when buying the game. Then there are modifications to online games that will give you an advantage over other players, even though there are counter measurements by the game companies, like additional software that is running on the player's computer, scanning for suspicious activity. It's a race between the "hackers" and game vendors, but neither side can win. And we're talking about software made my multi-million dollar companies that should have the resources to make their software hacking proof, if it were possible.
For the case of Java applications, it's comparably easy to modify them, even if you're using obfuscation techniques or signing, as Java byte code simply is much easier to analyze, understand and turn back into Java source files than machine code generated by C/C++ compilers.

Decompiler Bytecode and Obfuscators

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.

Is it worth to obfuscate java web application? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Is it worth to obfuscate java web application? and why?

No. The code is stored on the server where external users (hopefully) don't have access to it. You may want to obfuscate the JavaScript if you feel it's worth the (minimal) IP protection.
The best thing is so make sure your server security is up to scratch and you don't have open access to your application directories (which shouldn't happen anyway).

IMO, no.
There are two main use-cases for obfuscation:
to protect access control "secrets" (e.g. passwords) embedded in the code, and
to protect against someone stealing your "intellectual property".
The problem is that obfuscation only foils half-hearted attempts at reverse engineering. A serious attempt will always succeed. It is really not that hard to decompile an obfuscated JAR file, and there are lots of tools around for doing it.
For the use-cases above, better alternatives to obfuscation are:
just don't embed secrets in the code, and
one or both of the following:
secure your webservers so that hackers cannot get at the code, and
don't ship the code that you consider to be valuable IP, or if you do, then only ship code to people who have signed a legally binding contract / license agreement that guards your IP rights.

The only scenario where you would obfuscate a java web application is if you gave the code to your customers to run on their servers. Otherwise, it is just a waste of time and an extra complexity.
Obfuscation is for the purpose of making it harder for someone to decompile your byte code and get useful code out of it. To do this, they have to have access to your class files, something that only exists when you deliver them to your customers, not when they access it remotely.

I would add that you should have a good justification, because obfuscation will make debugging harder.

You might find the answers to Do you obfuscate your commercial Java code? relevant.

Is it worth to obfuscate java web application?
It depends
and why?
If you're licensing your web-app to be installed on your customer's site and you don't want your customer to reuse your code by decompiling it*, then it is.
If you're serving your web-app and the installation is available only from you, I would say it is not worth it. Better would be to increase your net security.
* see Stephen C comment

Absolutely yes.
If your development process is correct, only binaries and some support files (markup and stylesheets, for instance) need to be on the server. There's no good reason to not obfuscate binaries in any production environment.
Others here have said that doing so creates problems for staff. The only people that should be aware of or concerned about the contents of your binaries are developers - and they have the source, so they shouldn't be concerned about poking around compiled objects.
The only reason I can see that anyone that doesn't have access to the source would be interested in the contents of binary would be reverse engineering - and no one on your staff should have any interest in reverse engineering your own product, unless they don't have access to the source. That means they either aren't cleared for that code, or you've lost it, which means your source control system either sucks or is missing entirely. That is a completely different conversation.
I've yet to hear any practical examples of server-side obfuscation causing development or administrative difficulties.

Is it a good idea to obfuscate your server side code? I'd give an unqualified YES.
The reality is that the end user is only one group which might have nefarious plans. All too often internal employees, whether they are business users, support staff, etc, might also have their own plans.. or made unwitting accomplices.
If you deal with ANY information which requires a password to access, then you have a duty to leverage every tool at your disposal in order to safeguard that information.
This includes protecting it against both external and internal people. Companies lose both data and intellectual property all of the time due to internal people with too much access. Whether those people purposely stole the information or simply lost control of their computers due to hacker attacks is immaterial.
So, again, yes one step is to obfuscate in the hopes of whoever acquires the binaries has a harder time in figuring out how your application works. Of course, you should go a lot further by securing the servers it lives on; and not just production, but all the way back to source control.

What are the minimum security precautions to put in place for a startup?

I'm working with a start-up, mostly doing system administration and I've come across a some security issues that I'm not really comfortable with. I want to judge whether my expectations are accurate, so I'm looking for some insight into what others have done in this situation, and what risks/problems came up. In particular, how critical are measures like placing admin tools behind a vpn, regular security updates (OS and tools), etc.
Keep in mind that as this is a start-up, the main goal is to get as many features as possible out the door quickly, so I'll need as much justification as I can get to get the resources for security (i.e. downtime for upgrades, dev time for application security fixes).
Background Info:
Application is LAMP as well as a custom java client-server.
Over the next 3 months, I project about 10k anonymous visitors to the site and up to 1000 authenticated users.
Younger audience (16-25) which is guaranteed to have an above average number of black-hats included.
Thanks in advance for your responses, and I'll welcome any related advice.

Also, don't forget you need to have your server secured from current (that is, soon-to-be-past) employees. Several startups were totally wiped due to employee sabotage, e.g. http://www.geek.com/articles/news/disgruntled-employee-kills-journalspace-with-data-wipe-2009015/

If security isn't thought of and built into the application and its infrastructure from day one it will be much more difficult to retrofit it in later. Now is the time to build the processes for regular OS/tool patching, upgrades, etc.
What kind of data will users be creating/storing on the site?
What effect will a breach have on your users?
What effect will a breach have on your company?
Will you be able to regain the users' trust after a breach?
Since your company is dependent on keeping existing users and attracting new ones, you should present your concerns along the lines of how the users would react to a breach. The higher-ups will understand that the users are your bread and butter.

Reputation is everything here, especially for a startup. As a startup, you don't have a long history of reliability/security/... - so all depends on users to give you the 'benefit of the doubt' when they start using your app.
If your server gets hacked and your users notice that, your reputation is gone. Once it's gone, it doesn't matter whether your app and your features are the 'next new thing' or not. It doesn't matter whether the security breach was minor or not - people won't trust your app/company anymore.
So, I would consider security to be the top priority.

I agree with Stefan about reputation. You don't want to get hacked because you were lacking on security. Not only will that hurt your site and company, it will look bad on you since you're in charge of that.
My personal opinion is to do as much as you can because no matter how much you do there will be vulnerabilities.
Unfortunately security like testing and documentation are often afterthoughts. You should really make sure to do risk assessments early in your site/software's life and to keep on doing assessments. I think it is important to patch all software for security holes.

These will probably be obvious:
Limit password attempts.
Sanitize your database inputs
Measures to prevent XSS attacks
It's also worth mentioning that, as you said, the network architecture should be set up appropriately. You should definitely have a decent firewall that's locked down as much as possible. Some people recommend putting your systems between dual firewalls of different makes so that in the event one of them has a critical vulnerability, the second will most likely not have the same vulnerability and you'll be safe. It all depends on what you can afford since it's a startup.

If you're explicitly trying to attract the sort of users who are inclined to try to crack systems, then you can pretty well bet that your system will come under attack.
You should suggest to the management that if they're not going to take security seriously, then you should just go ahead and post the company's bank statements and accounting books (in clear text) on the site, with a prominent link from the home page. At least that way, you can tell them, the end result will be about the same, but they're less likely to damage everything else to get what they're looking for.
I'd think that the reputation issue might have a slightly different cast with this audience, too -- they may forgive you for being hacked, but they probably won't forgive you for being an easy target.

Make sure you know what version and patch level your servers are running, not just the OS, but all related components and everything that is actually executing the the machine.
Then make sure you are never more than a day behind.
Not doing so leads to much pain, and you don't hear of most of it - most of my past employers would never publicly admit being hacked as it reflects badly on them, so you can assume systems are getting hacked left and right with pretty serious consequences to companies, you just don't hear about most of these events.

A few basic "security" measures here that while are more reactive than proactive, are some things to consider.
1) Backup strategy, of course not just for those who hack into your site, but it is nice to restore everything back to pre-hack days if possible, make sure it's reliable and most importantly was tested in a near-live restore drill
2) Mitigation, have plans in place at least on a napkin somewhere for how to react if the server is hacked
3) Insurance, find insurance companies that understand the world of cyber-business and the damages resulting from these things, buy policies
4) Someone already mentioned employee sabotage problems, you're screening your employees beforehand right? Background checks are cheap and do dig up stuff...

My best suggestion is monitoring.
There is no perfect security and it is all about accepting risks and preventing them when necessary. However, if you have no monitoring in place you will have no way to know if something (an attack) has succeeded and how it happened.
So, keep your system updated and install a few lightweight tools to monitor it properly. If you have custom applications, add logging in there. Log on error-generated errors (bad input), failed passwords, or any user-generated error.
As for lightweight tools to monitor, there is quite a few free/open source:
OSSEC (to look for anomalies, changes and logs)
modsecurity (web-based monitoring)
Sucuri (whois/dns/blacklisting monitoring)

Have a look at Mod Security for the various possibilities in the software setup:
Do a Google search for "mod_security howto example"
Simple example to start: http://www.ghacks.net/2009/07/15/install-mod_security-for-better-apache-security/