0

I note there are already some questions regarding how to license-protect commercial java apps, listed below, and whilst I concur with the general consensus that all such protection will inevitably be beaten by determined-enough pirates, I am still minded that some protection is better than none so long as it does not cause legitimate users irritation.

Best Practice: License enforcement for Java Desktop application

How do I copy-protect my Java application?

How to protect my application against piracy

My question relates to the viability of a very specific solution to licensing additional content. I am considering the model of releasing a free version which is fully useable (no nonsense like limiting saves or watermarking generated content) and licensing additional premium content.

A mechanism I am considering is that the premium content would be packaged in a separate (small) jar which would be (re)-downloaded each time the app was started via https, and kept in memory only. Thus an internet connection would be required to start the app with premium content enabled, reverting to base functionality if not connected or if authentication fails.

This question is not about the user authentication process for loading the premium classes (could be anything), but rather how secure (i.e. piracy-proof) the idea of bundling the restricted classes as a network resource is - or what might be done to make it more piracy-proof.

Thanks

Community
  • 1
  • 1
barneypitt
  • 979
  • 9
  • 11
  • How sensible is requiring an Internet connection to exploit advanced functionality actually depends on what your application does. While for a, say, web browser, expecting an Internet connection is reasonable, for a scientific calculus suite it might be not. – Stefano Sanfilippo Jan 19 '14 at 11:57

3 Answers3

1

If you're loading the classes over the net, to crack your app you could set up a proxy to see where you download the jar's from and capture them, share these jars with other people, and then redirect requests to your domain to a local address.

More more "security" against this you could take information about the PC requesting the jar's and include that in the code, then, when running your jars validate whether the same machine requested the download that is currently trying to run them.

Bear in mind that java is relatively easy to decompile, and someone could come along and replace all your licensing logic with if(true).

All in all, somewhere along the line your app will be pirated if it is popular enough, it just becomes a tradeoff between time spent securing against it and the lost money.

Pez Cuckow
  • 14,048
  • 16
  • 80
  • 130
  • 1
    Regarding decompilation and changing licensing logic, the authentication logic would be server-side, so regardless of changes to the client-side logic the jar would only ever be served to a server-authenticated user. Since the extra functionality resides in the jar, no client-side change could "switch it on" without the jar. – barneypitt Jan 19 '14 at 22:31
  • 1
    @barneypitt that's until you share the jar with your friend and remove the logic validating it's use! – Pez Cuckow Jan 20 '14 at 08:33
  • 1
    I see what you mean. My premise was that the cracker would never be able to access the (unencrypted) jar file in the first place, as the unencrypted classes would only ever exist in the application RAM. But then I imagine that some clever memory sniffing might be able to reconstruct the jar? – barneypitt Jan 21 '14 at 01:34
  • I have actually bypassed the whole memory sniffing part by Isolating the down stream on video files being watched by a browser and just written the stream to file. It's not as simple as just saying it like I have and there are allot of details that need to be accounted for but It's allot easier than just memory sniffing. The file still maintains it's pattern it's just coming in in packets and is reassemble in memory. If you are getting the stream from your own machine it's a simple task of duplicating the stream and doing something like Stream.WriteToFile(path etc); or something similar. – That Homeless Guy Jan 28 '16 at 21:35
1

The cracker could use a tool like Wireshark to capture the network traffic between your app and your server. That way he could either copy the JAR directly from the data stream or see from which URL the program loads it and request that URL manually to obtain the JAR.

With that jar the cracker could set up an own webserver to host the JAR and tell any of your users to use an entry in their hosts - file to redirect your domain to theirs so the file is loaded from the crackers server.

Encrypting the file with a different key for each user wouldn't help either, because the cracker could just give the user a copy of their key or, when you hide the key somewhere in the program, his copy of the program.

Philipp
  • 67,764
  • 9
  • 118
  • 153
  • I suppose I could encrypt the jar based on requesting MAC address, but I guess there would be an easy enough way to fake your MAC address. Another thought was that the server could refuse to authenticate a given request if somebody else is currently online with those credentials - i.e. only one concurrent user per set of credentials. – barneypitt Jan 19 '14 at 22:43
  • @barneypitt Both are irrelevant when the cracker emulates your server with his own. – Philipp Jan 19 '14 at 23:06
0

My view remains that: yes all software will eventually be pirated if it is successful and yes: it is still worth trying to protect your assets within reason. I think that the encrypted jar idea "has legs" and the idea that someone may need to maintain a bogus license server in order to crack it ought to be a reasonable discouragement to most ill-wishers (although I'm sure that to some crackers, the harder a crack is to perpetrate, the more enticing it is to do so).

Sadly, I suspect it is probably possible to crack it without a bogus server, though a smart enough authentication scheme might at least make that rather difficult.

All contributions were very helpful.

barneypitt
  • 979
  • 9
  • 11