Protection from people copying your programs.
This is probably a lot to ask. How can I keep my program from being copied. I ship it out on CD. I know the CD is being passed around. Are there any suggestions?
Well, you can always use a hardware dongle. See for example http://www.aks.com
Have a first-time-run-only routine that dials up a website and checks the individual CD's serial no. If it finds that the serial number has already been logged, it bombs out.
How to allow him to re-install?
Besides, if the buyer DOES NOT have Internet dial-up ....
(Impossible to narrow my application to Internet Users only..)
How to protect?!
I use a copy protection scheme than involves keeping track of the harddrive where it was initially installed, but that involves writing encrypted information to the floppy, which obviously in your case wouldn't work. Another approach that I use for demos may work for you ... your application should require the user to call for an authorization number from you ... they'll have 30 days (or whatever) to use the software before having to call. Obviously a pirate will not call you. The authorization number should be based on the harddrive's volser number, so the same number cannot be passed around along with the CD. Works pretty good for me.
I developed a passwording scheme that is tied to the system date. You can store a file on the hard drive that has an encrypted string of say 160 characters. You only need to use a few chars from that string and you should select them from different locations in the string in reverse order. An example might be where today is 06/27/1999 using American date format. DTOS of that date is 19990627. Break that up and place it in the string when installed.
An example using 60 chars:
your algorithm looks at the computer system date then looks for each char from the dtos(date()). The 1 is found at 22,9 at 13,9 at 14,9 at 25,0 at 46,6 at 49,2 at 53 and finally 7 at 1.
You can also embed a date for how long the program is avaliable, a flag for whether or not a timeout exists.
On install you could set it up to give them (n) days before expiration. They would have to call you or visit your web site for the permanent key. This method avoids the problem that arises when they upgrade hard drives, move their program or reformat. It still has it's problems though.
This would work fine as long as the file that you store the info in is not saved in the install directory, but somewhere where the user couldn't find it (or hidden, that would work too I guess, but not for the savvy hacker). Otherwise, a simple copy of that file would break your protection.
Any protection scheme that I've messed with over the years always seem to have some pro's and con's to it. My current method is obviously a burden when the user is legitimately copying to a newly installed hard-drive. But oh well ... then they just have to call me.
I like your idea tho ... looks like a tough encryption for the average person to break.
Actually, you can store it anywhere and even if the user finds it, they'll have a tough time deciphering 160 characters, particularly if you do a shift and scatter the date field around well. I doubt most people could break it, because of a lack of sophistication and time. If that is a big worry, just increase the size of the string to 100k or so. Eight to sixteen characters out of that would be very hard to deal with.
Full details in a public place is asking for trouble :( Just tips on a simple working scheme. A file generally occupies more space than it should, that means you can always find places on disk that no regular file operation writes over.
The way we designed ours is: The CD we distribute installs in demo mode and will run that way until registered (call in, Program generates a random password that the user reads, phone representative uses a program to convert that password to a registration ID). Users who have bought the program get both a CD and a Floppy Disk. The floppy disk is used to verify the purchase and automatically register the program (without the user calling on the phone). At the same time, information about the computer (and the user's name & organization) is written to the floppy disk (encrypted, of course). The only down side to this whole scheme is if the user copies the Floppy disk before installing.
What about requiring the user to call in for an unlock code. The code goes against a hard coded algorithm within the app that is date/time/year dependant. Upon successful entry of the code, the app writes a hidden file to their harddrive. The app checks for the hidden file each time it fires to allow entry. If they pass the CD around, the same code wouldn't likely unlock the app because the date/time/year changes. You could just go with date/year - or include time which would be +/- 2 hour period for the code to be valid. The broader you make the code window, the more likely for stealing but less likely for repeat calls from the same user who got the code in the morning, but didn't try to install until afternoon. One other thought, the hidden file you write could contain a timestamp code that you also write to a 1 record table. These are compared upon startup - further foiling the user that finds the hidden file and simply tries to copy it to another users install.
Category Application Design
We have VFP 7.0 software is going out to Mongolia. We already have keycode protection installed, but we are concerned over reverse engineering the software. We've spent six years creating this code and we do not want to send it to a country that does not respect copywrite protections. Does anyone have a way to protect code from reverse engineering?
Check this -
ReFox Decompiler and Brander for FoxPro and Visual FoxPro
ReFox is the decompiler and brander for FoxPro and Visual FoxPro. ... Support for Visual Foxpro 8.0. Refox now generates registry scripts and modifies the exe for relocating and ... New 32Bit Windows GUI - ReFox has been completely re-written as a ...
Just my $0.2 on copy protection.
I do NOT include such a feature. Copying is the best way of 'advertising' the app you want to sell.
The point however is, after copying a working version of an app, the evil minded person expecting a working app should automagically (I love that word, invented by wOOdy) be working with... a demo version, that (of course) expires after several days, runs or whatever...
After that time they need to register.
OK, next step to prevent is that they reinstall the demo again to have another go.
Hence the info of the last demo should be placed somewhere (or a multitude of places) so that this info can be picked up by the app...
Once the app is registered the demo-info files should be removed at first legal run.
So the remaining point is how to implement this idea.
I am working on this idea, whenever I have time, but there is only so little time left every day.
(and so much to do!)
( Topic last updated: 2004.09.09 04:46:52 PM )