securely distirbute applications

Discussion in 'Java' started by saotome, Nov 1, 2006.

  1. saotome

    saotome Guest

    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?
    saotome, Nov 1, 2006
    #1
    1. Advertising

  2. -----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

    saotome wrote:
    > 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-----
    Michael Ansel, Nov 1, 2006
    #2
    1. Advertising

  3. saotome wrote:
    > 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
    --
    The comp.lang.java.gui FAQ:
    http://gd.tuwien.ac.at/faqs/faqs-hierarchy/comp/comp.lang.java.gui/
    ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq
    Thomas Weidenfeller, Nov 2, 2006
    #3
  4. saotome

    Tom Forsmo Guest

    Thomas Weidenfeller wrote:
    > saotome wrote:
    >> 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?


    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
    Tom Forsmo, Nov 2, 2006
    #4
  5. Tom Forsmo wrote:
    > 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


    --
    The comp.lang.java.gui FAQ:
    http://gd.tuwien.ac.at/faqs/faqs-hierarchy/comp/comp.lang.java.gui/
    ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq
    Thomas Weidenfeller, Nov 2, 2006
    #5
  6. saotome

    Chris Uppal Guest

    Tom Forsmo wrote:

    > 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
    Chris Uppal, Nov 2, 2006
    #6
  7. saotome

    Tom Forsmo Guest

    Thomas Weidenfeller wrote:
    > 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
    Tom Forsmo, Nov 2, 2006
    #7
  8. saotome

    Simon Brooke Guest

    in message <>, saotome
    ('') wrote:

    > 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).

    --
    (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
    Simon Brooke, Nov 3, 2006
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Boris Zakharin

    Securely logging onto an SQL server

    Boris Zakharin, Jul 30, 2003, in forum: ASP .Net
    Replies:
    2
    Views:
    347
    Boris Zakharin
    Jul 30, 2003
  2. Doruk
    Replies:
    4
    Views:
    482
    Polux
    Nov 14, 2003
  3. Guadala Harry

    Where/How to Securely Store ID and Password?

    Guadala Harry, Feb 20, 2004, in forum: ASP .Net
    Replies:
    5
    Views:
    4,338
    Guadala Harry
    Feb 22, 2004
  4. Olav Tollefsen

    How to integrate securely?

    Olav Tollefsen, Oct 12, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    281
    Scott Allen
    Oct 12, 2004
  5. Jim Bayers
    Replies:
    7
    Views:
    335
Loading...

Share This Page