>>>Howdy and good day to all,
>>>Currently developing VFP 9.0 application to be distributed to other potential clients. Are there any recommendations on how I can ensure that the software application can only be installed on ONE machine and the user can't send the install exe to others. Basically any ideas on how to ensure that the application can only be installed on one machine?
>
>Easiest approach most likely is to find latest Defox that includes a "branding" system to limit use of your app to a particular PC. Basically the user has to send you a key generated by the app and you send back an unlock key for that PC. There's sample sourcecode for trial periods as well.
>
>Defox is free, but no longer supported. The alternative is to carve your own. There's a few posts and articles floating around including quite a good summary from Craig Boyd that I wasn't able to find today using DuckDuckGo. If you carve your own, you need some sort of app protection so people can't decompile your app and disable your registration scheme. Defox does a good job of this with its protection written in ASM or you can use Refox or VFP C++ Compiler.
>
>Three things to watch: 1), purportedly unique identifiers for processor, disk, motherboard, even network MAC etc these days are easy to spoof, or may not even be unique when shipped from several of the bigger suppliers. E.g. Asus doesn't update UUID on several of their PC offerings, so an Asus customer could deliberately or inadvertently flout a protection scheme relying on UUID. Defox allows you to combine MAC with other identifier (? processor) which helps but does not prevent customers standardizing settings that can allow multiple use.
>2) Network MAC is likely to be unique at a customer since it's needed to route packets correctly, but many machines have multiple MAC e.g. for ethernet and wireless connectivity, so testing for MAC can fail if they register on ethernet and now try to use wifi. Defox used to have this issue, not sure whether Leonid ever resolved it apart from the option not to include MAC in your keys. You can iterate through a machine's MACs looking for a match, but that's another spoofing opportunity.
>3) if you use a date() to determine a trial period, it's not enough to add (say) 30 days from first use, as a customer may advance the system clock by a couple of years before installing, then enjoy years of free trial after the system date is corrected. You need a "phone home" mechanism that hits your website or other source for an encrypted date response. It has to be encrypted because it's also easy to redirect unencrypted GETs for years of free trial. People often say their customers would never do this, but an ounce of prevention is worth a pound of cure as Benjamin Franklin once observed!

Yet another method involves the use of a "dongle" (i.e. a hardware device that plugs into one of the PC's ports). Being that it's a hardware device means it's an extra cost item. Back before USB, one of the problems with the older style plugs that connect via the "legacy" serial or parallel port is that they sometimes interfere with other devices that plug into the same device. I do remember one of the things folks often had to do was to shuffle the dongles around just to get certain things to work correctly (say for example you had two dongles that pugged into parallel [i.e. printer] port -- sometimes it worked better if you plugged in dongle "A" into into the computer then "B" into "A" -- other situations might require you to exchange the dongles). Nowadays you'd be using USB dongles -- but then you might run into problem where the user runs out of free USB ports (more likely to happen on laptop than desktop). Some SUB devices might not work propery if used through a USB hub..