• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

methods of protecting an app

 
Stuart Rogers
Ranch Hand
Posts: 141
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So I've developed a stand-alone app that I'd like to sell. For now I'll just obfuscate the runnable jar, perhaps later buy a AOT compiler to produce equivalent native exe's.
The app runs locally, reads and writes local files, and connects to a remote database via the 'net.
I'd like to bake in some rudimetary copy protection (well, execution protection really). Trying to determine a machine's identity by creating a "fingerprint" from MAC address and the serial numbers of various hardware components seems somewhat daunting.

My idea:

1- At time of purchase I generate a username, initial password and store it in the database. I send username and initial password to user in an email.
2- User uses username and password to download app to their local machine.
3- Upon execution the app looks for a key somewhere on the local machine and if not found but username and password are valid then
generates a key and writes the key and also UPDATEs the database record.

Question1: where could/should such a key be written? CMOS? Somewhere on the HHD? Assuming a file-copy grabs only the actual number of bytes indicated by file size, could the key be written in the unused space between the end of the file and the end of the disk sector? Can Java do such low-level I/O? Where do modern apps place their copy-protection sneakiness? I'd rather not rely on hidden files/partitions.

Quesiton2: How could a unique key be baked into the app as part of the download process?

Any and all suggestions/hints/links/constructive criticisms and especially examples are most welcome!

TIA,

Still-learning Stuart
 
Rob Spoor
Sheriff
Pie
Posts: 20611
63
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stuart Rogers wrote:creating a "fingerprint" from MAC address and the serial numbers of various hardware components seems somewhat daunting.

You are going to annoy quite a few of your users. If somebody's network card breaks, and he replaces it, he can no longer use your app because the MAC has changed. Likewise for other components.

Question1: where could/should such a key be written? CMOS? Somewhere on the HHD? Assuming a file-copy grabs only the actual number of bytes indicated by file size, could the key be written in the unused space between the end of the file and the end of the disk sector? Can Java do such low-level I/O?

You're going to have a lot of trouble writing to the CMOS or HDD like this. First of all, Java cannot do such low-level I/O without JNI. Secondly, you risk messing up the entire partition table of the user's computer if you're going to write to the disk directly without knowing what you are doing. Likewise for the CMOS, you may render the machine inoperable.

Where do modern apps place their copy-protection sneakiness? I'd rather not rely on hidden files/partitions.

I wish I knew. It's possible they use the registry or hidden files somewhere, but both have their flaws. In the registry it can be found, and therefore deleted / modified. Likewise for files, and partitions can be seen from any partitioning tool (including Windows' own Disk Management).
 
Lester Burnham
Rancher
Posts: 1337
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's possible they use the registry or hidden files somewhere, but both have their flaws. In the registry it can be found, and therefore deleted / modified.

I'd probably go with the registry (via the Preferences API so that it works cross-platform). Someone who goes to the trouble of hunting down registry entries is probably savvy enough to decompile the app and remove all traces of the protection you put in anyway (and probably unwilling to part with money to begin with, so it's not like you'd lose a sale).

If you can require the app to be used online then you could keep part of the functionality running on a server - which would check the license number (or username/password - whatever you end up using) for validity each time the server is accessed.
 
Stuart Rogers
Ranch Hand
Posts: 141
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you for your responses.

There's a few more tricks I though of, but all require customizing the app slightly for each customer. This might be tolerable if one could automate the build process (Ant, Maven), something like:

-user logs on to secure website using username and initial password supplied previously by me via email
-user clicks Download button, which triggers the build process, which in turn bakes some uniqueness into the jar and also writes that uniqueness to the database.

then
-user fires up app, enters username and password. username, password and uniqueness get passed to database and if all three match, great else not-so-great.

Ah, but now a build process must run on the server. Oof.

Anyone else have some ideas?


Still-learning Stuart
 
Rob Spoor
Sheriff
Pie
Posts: 20611
63
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Build is not necessary. Just pack into a JAR file, if you use a customizable resource. Of course that resource is readable in the JAR file since that's little more than a ZIP file. You could encrypt the resource in the "build", then decrypt it in your code.
 
Stuart Rogers
Ranch Hand
Posts: 141
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here's a link that does a good job explaining what must go in to a thorough licensing scheme
http://www.ehow.com/i/#article_5741380

Looks like I'll be trying something simpler for the time being.

Thanks to all who replied!



Still-learning Stuart
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic