securely distirbute applications

[saotome]

I'm planning on distributing some java apps. I'm a bit preocupied that
some of the users may try to decompile the jars and learn about the
source.

Unless I'm mistaken (please indicate so if this is the case), I can go
one of two routes: bytecode obfuscation and native compilation. If it's
effective, I have no problem going either route. The only promising
java native compiler I've seen is excelsior jet, but It has a hefty
license fee. GCJ is up there as well, but it only supports java 1.3 and
is missing a couple of key libraries.

Any suggestions?

 

[Michael Ansel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Only suggestion I have is to remember that security through obscurity is
usually a bad plan. Good luck though!

Michael

I'm planning on distributing some java apps. I'm a bit preocupied that
some of the users may try to decompile the jars and learn about the
source.

Unless I'm mistaken (please indicate so if this is the case), I can go
one of two routes: bytecode obfuscation and native compilation. If it's
effective, I have no problem going either route. The only promising
java native compiler I've seen is excelsior jet, but It has a hefty
license fee. GCJ is up there as well, but it only supports java 1.3 and
is missing a couple of key libraries.

Any suggestions?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFSCE3ku86QLyIARQRAtr7AJ4u7g1J1lacBPoMMkhvb75RYuabTQCgz8uG
eiikWbhQwxcKCGjF2xh0GHE=
=C4MB
-----END PGP SIGNATURE-----

 

[Thomas Weidenfeller]

I'm planning on distributing some java apps. I'm a bit preocupied that
some of the users may try to decompile the jars and learn about the
source.

Are you ashamed of your code? Let's face it. Almost 100% of the code of
an typical commercial application is trivial in the sense that there are
no breakthrough algorithms or top-secret information in the code.
Typically is the amount of code and the perseverance shown to put it
together which makes it valuable, not any algorithm. However, it is the
algorithms from which one can learn most. And reverse-engineering and
understanding an algorithm consists of much more than just decompiling
the code.

For the rest, you might consider some of your code a trade secret in the
sense that you think it gives you a competitive advantage. But on closer
inspection this is often also not the case. Further, a competitor who is
really interested in this part of the application could still reveres
engineer the code if it was written in, let's say C. It is just a lot
harder, but not impossible. If the gain is high (your trade secret so
great), someone might be willing to go through a lot of pain anyhow to
get it.

And then there is of course the code which is there to prevent the user
from doing something the user would otherwise be allowed to do. Think
DRM and other restriction technologies. Since the gain in reverse
engineering these is very high (from a user's perspective), they are
often reverse engineered, even if written in other languages than Java
(again, think about the many DRM schema which have been hacked in the
past). Easy decompilation makes the hacking simpler, but difficult
disassembling doesn't prevent the hacking.

Any suggestions?

If it really worries you, you shouldn't have chosen Java as the language
for your project. Now, as an afterthought it is pretty much to late. The
properties of Java, including the relative ease of decompilation, are
well known for more than a decade. If you need to "do something now,
whatever it is", go with obfuscation as some kind of band-aid. It is
cheap, relatively painless to apply and raises the decompilation bar a
little bit. For future projects you might want to consider this special
Java property first, and probably chose another language.

/Thomas

 

[Tom Forsmo]

Are you ashamed of your code?

Not very relevant comment, is it?

Let's face it. Almost 100% of the code of
an typical commercial application is trivial

Yes, but this poster code might not be, that might be why he asks the
question. You are generalising your respons without knowing the details
of the application.

in the sense that there are
no breakthrough algorithms or top-secret information in the code.
Typically is the amount of code and the perseverance shown to put it
together which makes it valuable, not any algorithm. However, it is the
algorithms from which one can learn most. And reverse-engineering and
understanding an algorithm consists of much more than just decompiling
the code.

There might be pieces of information in the code that the OP wants to
protect, such as structure of communication/systems etc in the backend,
passwords/certificates in the code and so on, or just some small smart
way of doing a single thing which one can make some money on.

Easy decompilation makes the hacking simpler, but difficult
disassembling doesn't prevent the hacking.

No, but it can stop the general script kiddie and similar crackers.

The point of such things are not necessarily to make 100% unbreakable
solutions, as one would except from a technical perspective. But rather
to create barriers to shut out 99% of the people trying, its basically a
psychological game on human nature.

It would be nice if the community could started talking about security
and similar things pragmatically instead of ideally. Yes, most solutions
are ugly if they are not 100% perfect, but that's a technical problem.
Sure, for some problems only a 100% solution is good enough, such as
encryption etc. But in real life, a lot of security is about perceived
security, even in high security situations (such as protection of head
of states or military installations). The reason encryption, for
example, needs 100% security is that you can set the computer to brute
force the attack. While breaking into a system or reverse-engineering
some code requires human reasoning, planning and action, which can be
foiled by reasonable barriers.

tom

 

[Thomas Weidenfeller]

Not very relevant comment, is it?

Who are you to judge that in a discussion group?

Yes, but this poster code might not be, that might be why he asks the
question. You are generalising your respons without knowing the details
of the application.

So? You apparently know more details of the particular application, so
you are very welcome to offer your own view. Let me check your response
to the OP. Ups, there isn't any.

The point of such things are not necessarily to make 100% unbreakable
solutions, as one would except from a technical perspective. But rather
to create barriers to shut out 99% of the people trying, its basically a
psychological game on human nature.

How do you know the OP wants to play that game? Ups, I forgot, you you
know all the details of the OPs application. Or wait, could it be that
you are generalizing without knowing the details?

It would be nice if the community could started talking about security
and similar things pragmatically instead of ideally. Yes, most solutions
are ugly if they are not 100% perfect, but that's a technical problem.

Another generalization.

Interestingly you sound more and more like you are just looking for an
argument. I was explaining that there is no 100% solution, you now
complain that people don't talk about the fact that there is no 100%
solution. And you conveniently ignored the part of my posting where I
suggested obfuscation "to raise the bar", instead of a 100% solution.

Would you please make up your mind up about what you want to argue about?

But in real life,

Yet another generalization.

/Thomas

 

[Chris Uppal]

It would be nice if the community could started talking about security
and similar things pragmatically instead of ideally. Yes, most solutions
are ugly if they are not 100% perfect, but that's a technical problem.

The pragmatism has to work in the other direction too. I.e consider the
balance between the cost in time, effort, and money of implementing security
features against the (best available estimate of) the probable cost (in lost
revenue, etc) of not providing them.

It didn't sound to me as though the OP was thinking in those terms. For
instance if 1200$US for JET is too expensive, then either he wasn't thinking
cost/benefit at all (which is what I presume) or had decided that the loss to
himself through decompilation was probably not going to exceed that figure.
But in the latter case, why worry at all ?

I think Thomas's point (if expressed in these terms) is that it is rare for the
cost-benefit equation to come out in favour of elaborate security measures.
Where considerations like the customers' disinclination to waste their own
time, the (potential) effectiveness of legal/contractual protection, and the
customers' need for continuing updates to the software are taken into account,
the final balance may often suggest not bothering at all, or maybe sticking in
a bit of obfuscation as a mild deterrent.

In the cases where the above considerations /do/ indicate that elaborate
security could be worthwhile, there is the problem that -- by the same
reasoning -- the customers' own motivation the break the security will be
probably be significantly greater. In that case it becomes very relevant that
none of the available security systems will give 100% protection (or near
100%). There is little point in a deterrent that does not actually deter...

-- chris

 

[Tom Forsmo]

Would you please make up your mind up about what you want to argue about?

I am not arguing, I was stating that that your reply could be more
helpful. In relation to this I added a comment about what I think is a
typical dead-end type discussion about security aspects in the
community. I am entitled to an opinion, just as you are.

tom

 

[Simon Brooke]

I'm planning on distributing some java apps. I'm a bit preocupied that
some of the users may try to decompile the jars and learn about the
source.

Unless I'm mistaken (please indicate so if this is the case), I can go
one of two routes: bytecode obfuscation and native compilation. If it's
effective, I have no problem going either route. The only promising
java native compiler I've seen is excelsior jet, but It has a hefty
license fee. GCJ is up there as well, but it only supports java 1.3 and
is missing a couple of key libraries.

Any suggestions?

What's the point? What's so precious/unique/special about your code that
you should want to obfuscate it? Normal honest users are not going to try
to poke about in your code, and the people who do want to will just hit it
with a disassembler even if you do a native compile.

Produce an honest product at an honest price and offer recent support, and
you won't have any problems. It may even benefit you commercially to open
source your product and distribute it for free, and make your money mainly
or entirely from support and enhancements (which is what I do).

--
(e-mail address removed) (Simon Brooke) http://www.jasmine.org.uk/~simon/
;; Skill without imagination is craftsmanship and gives us
;; many useful objects such as wickerwork picnic baskets.
;; Imagination without skill gives us modern art.
;; Tom Stoppard, Artist Descending A Staircase