Making commercial Java software (DRM)

Question

I intend to make some software to be sold over internet. I've only created open-source before, so I have really no idea of how to protect it from being cracked and distributed as warez. Bearing in mind that I know like two programms that aren't either cracked or not really useful I decided that the only more or less reliable way may look like this:

1. Connect to a server and provide licensing info and some sort of hardware summary info
2. If everything is fine, the server returns some crucial missing parts of the program bound to that certain pc along with the usage limit of say 2 days
3. That crucial stuff is not saved to hard drive, so it is downloaded every time the program starts, if the programm runs more than 2 days, data is downloaded again
4. If the same info is used from different computers, suspend the customer account

What do you think about this? It may seem a bit to restrictive, but I'd better make less sales at first then eventually see my precious killer app downloaded for free. Anyways, first I need some basic theory/tutorials/guides about how to ensure that user only uses a certain Java app if he has paid for it, so please suggest some.

Thanks

Answer 1

I work for a company selling protected Java software.

I won't comment on the scheme for user authentication, but I can comment on the online license check.

Don't make it even "work for two days": that's how I pirate most software... Virtual Machine set "back in time" and externally firewalled so that it doesn't "phone home" anymore (that is: only allowing it to contact the server once, to get the trial key), always reimaged from the point where the software got freshly installed and bingo, the 30-days trial (or two days trial) has become a lifetime trial. Why do I do this? To learn how to better protect our app of course ;) (ok, ok, I do it just for fun too)

What we do in our commercial Java software is to check the license at every startup.

We've got hundreds of customers and nobody ever bitched about it. Not once. We generate a unique class at each run, which is different at every run, which depends both on things unique for that launch on the client side and on things generated once on the server side.

In addition to that having the app contact your server at every launch is a great way to gather analytics: download to trial ratio, nb average launches per trial, etc. And it's not nasty anymore than having an Urchin/Google JavaScript tracker on each webpage is nasty.

Simply make it clear to people that your software performs the online licence check: we'got a huge checkbox either on or off saying: "Online licence verification: OK/Failed". And that's it. People know there's a check. If they don't like it, they go use inferior competitor products and life is good.

People are used to live in a wired world.

How often can you not access GMail because your Internet connection is down? How often can you not access FaceBook or SO because your Internet connection is down?

Point is: make as much computation as possible dependent on the server side:

• licence check
• save user preferences
• backup of the data generated by your app
• etc.

Nobody will complain. You'll have 0.1% of your user complain and anyway you don't want these users: they're the one who would complain about other things and post negative feedback about your app online. You better have them not to use your software at all and complain about the fact that it requires an always-on Internet connection (which 99.99% of your target demographic and hence they won't care about the complain) rather than actually have them use the app, and complain about other things related to your app.

Regarding decompiling, .class can usually be decompiled back to .java unless you're using a code flow obfuscator that produces valid bytecode but that it impossible to be generated from .java file (hence it is impossible to get back a valid .java file).

String obfuscator helps make it harder to figure out.

Source code obfuscator helps make it harder to figure out.

Bytecode obfuscator like the free Proguard makes it harder (and produce faster code, especially noticeable in the mobile world) to figure out.

If you're shipping Windows/Linux only then you can use a Java-to-native converter like Excelsior Jet (not free and kinda expensive for startups, but it produces native code from which you simply cannot find the .java files back).

As a funny side note you'll see people trying to mess with your online server... At about 30 beta-testers we had already people (which we know where part of the trial) trying to pirate our online servers.