aspose file tools*
The moose likes Java in General and the fly likes methods of protecting an app Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "methods of protecting an app" Watch "methods of protecting an app" New topic
Author

methods of protecting an app

Stuart Rogers
Ranch Hand

Joined: Oct 02, 2008
Posts: 133
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

Joined: Oct 27, 2005
Posts: 19541
    
  16

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

Joined: Oct 14, 2008
Posts: 1337
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

Joined: Oct 02, 2008
Posts: 133
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

Joined: Oct 27, 2005
Posts: 19541
    
  16

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

Joined: Oct 02, 2008
Posts: 133
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
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: methods of protecting an app
 
Similar Threads
Download file on client machine by user request
IDEA encryption in java.
New to Linux!!!
split function problem in AWK
Calling Html file from a servlet