1

I have to create a jar with a java application that fulfills the following features:

  • There are xml data packed in the jar which are read the first time the application is started. with every consecutive start of the application the data are loaded from a dynamically created binary file.
  • A customer should not be able to reset the application to its primary state (e.g. if the binary file gets deleted for some reason, the application should fail to run again and give an error message).
  • All this should not depend on the os it is running on (which means e.g. setting a registry entry in windows won't do the job)

Summarizing I want to prevent a once started application to be reset in order to limit illegitimate reuse of the application.

Now to my ideas on how to accomplish that:

  • Delete the xml from the jar at the first run (so far I came to the understanding that it is not possible to let an application edit it's own jar. is that true?)
  • Set a variable/property/setting/whatever in the jar permanently at the first run (is that possible)

Any suggestions/ideas on how to accomplish that?

update:

I did not find a solution for this exact problem, but I found a simple workaround: along with my software I ship a certain file which gets changed after the program is started the first time. of course if someone keeps a copy of the original file he can always replace it and start over.

Jose Luis
  • 3,307
  • 3
  • 36
  • 53
gagabu
  • 41
  • 5
  • 2
    There is no perfect solution for this. Someone could always save a backup and restore from the backup before every run. – raptortech97 Mar 25 '13 at 16:29
  • i know there is no perfect solution for it, but i want to make it a bit more difficult. i am also aware that copying the jar before running it once would make the whole thing pointless. but it would be great to prevent an already run jar to be reset – gagabu Mar 25 '13 at 16:35

1 Answers1

1

Any user able to delete the binary file, will, with enough time, also be able to revert any changes made in the jar. When the only existing part of the application is in the hand of the user, you won't able to prevent changes to it.

You can easily just store a backup of the original jar, make a copy, use that for one run, delete, copy the original jar, etc. You would need some sort of mechanism outside the users machine, like an activation server. The user gets one code to activate an account, and can't use that code again.

Femaref
  • 60,705
  • 7
  • 138
  • 176
  • i am aware of that, but it would already necessitate to obtain a second instance of the application, as it is very unlikely someone will copy it already before trying it at least once. and then again this 'cheat' seems not be very obvious – gagabu Mar 25 '13 at 16:38