Art of BI: Obsfucating or Preventing Decompiling of Your Java Code

By | In Art of BI, Big Data, Business Intelligence | September 02nd, 2011

So, when creating a non open source Java application or library where you do not want the uncompiled code assessable, there seems to only be one way to truly achieve this.  That is through obsfucating your code at compile time. Preferably this is done using an obfuscation tool and integrating it into the ANT build process (build.xml). There are a few pay, free, and open-source solutions that will help a developer accomplish this.

I wanted to focus on the free/OSS solution for this and since NetBeans is my Java IDE of choice I stayed close to that combined solution.  What I found was that the main solutions to obsfucate are proguard, yGuard, and RetroGuard.

I like the idea of going with the open-source concept of proguard (or some mod) as this seems like what a lot of vendors such as Oracle are using within several of their applications/tools.

There are a few tutorials such as this one from Geertjan at Oracle a few years back.  Clearly, if Oracle is pushing this strategy it is probably a good way to go.  Check the comments on that blog post to see that some people have even attempted to use deobfsfucator/decompilers tools such as JD to no avail.  I like it!

References:

Contact Us
Christian Screen
Christian is an innovator in analytics and data warehousing design, best practices, and delivery. With more than fifteenyears of decision support and data warehousing with key experiences at Office Depot HQ, Sierra-Cedar, and Capgemini, he oversees the Oracle Analytics Practice which includes the technical development and delivery of Oracle BI collaboration software, data warehouse solutions, Oracle BI/EPM projects, and packaged analytics solutions at Datavail.

Leave a Reply

Your email address will not be published.
Required fields are marked (*).

2 thoughts on “Art of BI: Obsfucating or Preventing Decompiling of Your Java Code”

  1. Nice article but obfuscation is no encryption… so if someone really wants to read the code it will takes more time but it will be still possible – so in that case just make open!nIndeed Oracle should make it open so concerned people would be able to report and correct the billions of bug standing in EPM releases such as SmartView or Essbase Studio. nnNow the best way to decompile java classes is using DJ Java Decompiler (http://www.neshkov.com/), a great tool which as turn free lately : test it with your Essbase.jar or other!

    Reply

  2. Nice article but watch out, obfuscation is no encryption! So if someone really want to reverse engineer your obfuscated code it will be just a matter of time.nnNow if you want to decompile java class I recommend DJ Java Decompiler freely available at http://www.neshkov.com/ – just try it with your essbase.jar when looking for inspiration to develop custom defined functions!nnNow if Oracle could make their code more open then this would save many TIME and MONEY to customers that have to fight with support in order to obtain what they paid for, which is stable and tested software. Just think about it…

    Reply