• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

tools to encrypt jar and byte codes

 
Ranch Hand
Posts: 954
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
We have to use some type of tool which encrypt our jars/byte codes so that no one can decrypt it and read our code. I need to give some suggestion to my manager.. Any idea?

 
Ranch Hand
Posts: 159
IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Tushar ,

You could use an obfuscator. However, it's still possible to get your code if someone has the time and skills. It just makes it harder to read.
You could also encrypt your classes and write a custom ClassLoader which decrypts the classes just before they are loaded in the JVM. However, also this is not secure.

Tushar Goel wrote:...so that no one can decrypt it and read our code.


This is not possible.
 
Bartender
Posts: 689
17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There is a nice article that explains why encryption cannot work:

http://www.javaworld.com/article/2077342/core-java/cracking-java-byte-code-encryption.html?page=1.

As mentioned, obfuscation is a better bet if you really need to do that. Obfuscators vary in quality. Some simply change names, so its a fairly trivial exercise to get sensible java code back. The better ones perform functional-invariant bytecode transformations that produce bytecode that cannot be represented as Java source code. You can still read the bytecode, but getting Java code back is much more difficult.

Ultimately the JVM needs to see the bytecode to run your application, so whatever solution you use will have a flaw in it. If the attacker is motivated enough they can work out what your program does.

The most secure solution would be to find a way not to distribute your source code, such as keeping the sensitive code behind a secure webservice.

Who are you trying to protect the code from?
 
Tushar Goel
Ranch Hand
Posts: 954
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
actually we deliver jar to our customer. We use pro-guard for obfuscation our jars but people still able to read it.

I understand the problem with encryption. I am reading now about the tools available for obfuscation.
 
Mike. J. Thompson
Bartender
Posts: 689
17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I may be wrong but I believe proguard performs name mangling. When you decompile the code you get Java source code back but the names are very difficult to follow. However a modern IDE doesn't care about the name mangling, and can also perform automatic refactoring such as renaming. The obfuscation will slow down the attacker, but if they are motivated enough they will be able to get readable source code back by examining the code and performing renaming refactors as they figure out what things do.

How motivated are the people you are protecting against?
 
Tushar Goel
Ranch Hand
Posts: 954
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
we are security base company and provide security products to the client. So it is utmost important that user doesn't decompile back our jars.
 
Mike. J. Thompson
Bartender
Posts: 689
17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Then the only way you can guarantee that is by not delivering the jars to the customer. Obfuscation is the best that I'm aware you can achieve if you have to give them the jars.
 
Tushar Goel
Ranch Hand
Posts: 954
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Mike, We have to give jars. I think Obfuscation is only option left..

 
Rancher
Posts: 4801
50
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tushar Goel wrote:Thanks Mike, We have to give jars. I think Obfuscation is only option left..



Then all you are doing is making yourself feel better.
 
Tushar Goel
Ranch Hand
Posts: 954
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Dave, why?
 
Dave Tolls
Rancher
Posts: 4801
50
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tushar Goel wrote:Dave, why?



Because any code that exists on the client can be looked at by that client.
If people can hack (quite easily) compiled C code (think games) then hacking obfuscated Java byte code is going to be a breeze.
 
A berm makes a great wind break. And we all like to break wind once in a while. Like this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic