3

I have a java program compiled as a .jar and it requires an activation key to be enabled. I want the jar to prompt you for the activation key on the first runtime and once its been activated, store a string which it could read during later runtimes to determine if it had been enabled.

Any suggestions on how to go about this?

Note: I want the string to be stored secretly so someone couldn't trick the program into thinking its been enabled.

Update: I've been toying with the preferences api and am using this code to store if the program has been enabled:

String key = "userKey";
String saveString = "enabled";
Preferences root = Preferences.userRoot();
root.put(key, saveString);

And this to get if during a later runtime: 

String key = "userKey";
String failedtoLoad="Program not enabled";
Preferences root = Preferences.userRoot();
String status=root.get(key, failedToLoad);

Everytime I run the program status ends up being failedtoLoad and the saveString isn't found, unless I save the string and get the string in the same runtime. Why is this?

  • 1
    How secure do you want it? Reverse engineering your jar would still be a viable option unless you took steps to obfuscate and/or encrypt the code. – JDong Feb 08 '15 at 20:10
  • It doesn't have to be encrypted or obfuscated, just reliable. The preferences api might be just what I need if i can figure out why its not working, but unzipping the jar itself and writing a .txt file inside of it is still on the table. –  Feb 08 '15 at 20:45
  • unzipping your jar and decompiling your class files would make it easy to remove the check if you continue in this manner – JDong Feb 08 '15 at 20:49
  • The Preferences API writes to registry (on Windows) or .dot-files. Both can fail. In your example you try to write to the root, I am not sure if that is possible. Try adding a root.node("com/you/program/settings") in it. – eckes Feb 09 '15 at 03:47

2 Answers2

1

Have a look at the Java Preferences API (http://docs.oracle.com/javase/8/docs/technotes/guides/preferences/index.html). It allows to store preferences and configuration data between executions of your program.

About the secrecy: As JDong already mentioned, if your program must be able to read it, it's very likely that somebody else can also read it, it's in the end just a question of how difficult you want to make it to them. Best is to have some String that your program can algorithmically verify to decide whether it is a valid key or not. In that case, somebody else could still search for the installed key and reuse it somewhere else, but that's just like if the first person passed the key along to some other user.

cello
  • 5,356
  • 3
  • 23
  • 28
  • I'm more concerned with people sharing keys than decompiling and reverse engineering my algorithm. So aside from storing keys in an online database and removing them once used, what are my options. I was thinking, although it sounds bizarre, to have my jar remove all the alphabets from the entered key and then divide the remaining double by the current day of the month and then by the current month. If it results in an integer, the bot is activated but if it is not a whole number, the key isn't valid. Thus each key would only work one day of the year. Users would have 1 day to activate. –  Feb 08 '15 at 20:56
  • not very user friendly, having only one day. what if a user needs to do a fresh install of his/her computer? also, what about time zones? the validity could be much shorter in another timezone. I would store the original key and revalidate it every time instead of storing only a flag if it was validated once. but this needs a different key-format. – cello Feb 08 '15 at 21:28
0

If you actually want security, you would have to work harder at obfuscation than any potential attacker would work at reverse engineering. Look at implementations of successful DRM if you want to know how to implement security at the code level. These usually involve multiple non-obvious checks in the code with some server that verifies the key.

An alternative I prefer is to have the user agree to some legalese that limits their usage.

JDong
  • 2,304
  • 3
  • 24
  • 42