I am developing a Checker for the applications that I give to users and when they pay me I give them new jar that will replace the older jar in a application folder. The application using it will just call one method that may or may not allow it to run based on a "true" or "false" returned.
I am keeping this line of thought. A jar file having these file
1) a file having computer name and folder where the application have been copied. This will be entered at install time.
2)* a file having initially having number of trials allowed. And when the user have buyed license from me, its number of times the license can be applied eg 1 or 2 or 3 licenses
3)* a file having the number of times the application has run and afterwards the number of times the license has been used.
This no. 3 related task ie issusing of licenses, it will perform using computer name and folder path from first file.
The class file which will be in this jar file and will do all the job such as reading from this archive and updating it. The class will have a check against someone tempering with it; Maybe date or crc.
The above is about local situation. If the number of trials have been expired, I would like my class (in the jar) to check for license issued to that application on my website ie net access. This function of my class will be invalid when license have been issued.
I have the classes or will code them. I just want a bit of discussion about it with possibly I displaying the classes here. Ihis will benefit all of us
I want you to tell me what am I missing or what can be added to it? No! I don't want to use keystore or other such things.
I have put a related question in the Other Java APIs forum about getting computer name. It is solved for Ms Windows OS now and is interesting too
Maki Jav [ January 15, 2008: Message edited by: Maki Jav ]
My main application has a licensing scheme on it that's much more sophisticated than the one you describe, but we still still don't kid ourselves that a determined cracker couldn't find a way around it.
If your aim is to provide a first-level "deterrent" to unlicensed use of your application, then fair enough, go ahead. If you require real security that is really hard to crack, you won't achieve it without months or years of reading, learning and effort.
Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.
I wrote a key-based licensing system for an application several years ago. The concept was that we used our company private key to generate a SHA1 hash of parts of an xml license file, particularly the bits that governed which modules were installed and what options the client had available.
It worked well, from the point of view that someone without any knowledge of cryptography would be unable to modify the license file without rendering the hash invalid.
this didn't solve the main problem, though - someone skilled enough would quickly have been able to decompile the license manager classes and simply alter the code so that all license checks returned true. Also, issuing new licenses was a PITA.
I've come to the belief that crippleware is evil. If you don't want people using your software without paying licensing fees, enforce this via a valid contractual agreement (not a EULA) and make it clear to them that if they violate the terms of the contract they will be sued.
No matter how 'secure' you make your application, at some point it is possible to get around the security. Whether it's by monitoring OS memory to get passwords, decompiling the source, or simply reverse-engineering the licensing scheme; if your application serves a useful purpose someone, somewhere is going to 'fix' it.
Far better to channel your energy into other projects. J
McFinnigan? Never heard of him. Nobody here but us chickens...<br /> <br />SCJP for Java 1.4<br />SCJD for Java 5.0
I guess if you just have a few customers, they won't share their application with others. And if you get much users, one of them will try to hack your System, probably succeeed, and make his success public.
Inspection of the jar, analysing files, observing network connections, decompiling and so on.
Instead of polling your server, he might modify his host-file to access a local modified version of your license. He may fool your MAC-check by faking the MAC.
On the other side, you're disturbing your customers, if they can't use your program while offline. They might think your program is spyware, when you connect to your server. Can you guarantee your server is allways up and running? Now they buy a new network-adaptor... - license expired. They uninstall it, and reinstall it on the new machine. License expired.