very simple regkey approach

[Mark Reed]

I have a solution I am bringing to a very small and narrow market.

Rather than doing something elaborate, I am looking for a very simple approach to protect it.

Registration will be via email, and the user will initially have a 30 day grace period to register - I can accomplish that by writting the system date to a field and comparing ect...

I thought about how to generate a unique key that gets emailed to me - that binds the solution to that user's pc.

I thought about getting the system NIC, but if they have multiple NICs, or flip from wifi to hardline, that would cause issues.

I then thought - what about using the get hostname and apply a formula to convert it to some format that tweaks it to something less obvious... I then use that kep emailed to me to generate a regkey that the script will compare to make sure the logic comes out true and allows it to continue to function.

Has anyone approached regkeys in this manner?

Also - if anyone has better suggestions on how to deploy a very simplified protection, Id love to hear more, or maybe see a sample.

Thanks all!!!

[comment]

how to deploy a very simplified protection

That's a loaded question. I think at the very least you should try and identify [a} what are you trying to prevent, how much time, effort, money and knowledge will your adversary be able to expend in order to circumvent your measures, and [c] how much time, effort and money are you prepared to invest in the protection.

[bcooney]

Check out Dunning's Easy Encrypt.

[Mark Reed]

thanks.

Basically I am just trying to prevent someone from buying the solution and making copies for a dozen friends. Id like the solution to tie itself to the machine it is installed on.

Im not too worried about someone with FMP knowledge breaking it apart and getting inside it.

The solution is for a VERY small demographic, so I do not want to put anything elaborate and time/money consuming into it - yet I want to minimize the illegal sharing of it.

[comment]

Id like the solution to tie itself to the machine it is installed on.

Well, it is possible - but it's a PITA for the legitimate customer upgrading their hardware. Wouldn't stamping every layout with the name of the customer provide a sufficient deterrent?

[Mark Reed]

the problem I will have with this market is one person buying it and giving a copy to 20 of their freinds.

In this case, the screen stamped with customer name would nto be a deterrent.

I need to have simple way of stopping that - and am open to suggestions. The market this will see is prone to "friends sharing with friends".

upgrading hardware would be a pain - the user would need to reinstall and then request a new product key.

Im not sure how to approach this to balance ease of use as keeping it simple.

The money isnt there for anything robust or elaborate - yet if I dont protect it, I will lose a good bit of sales just due to sharing among users.

[comment]

Im not sure how to approach this to balance ease of use as keeping it simple.

I don't see room to "balance" here: it's either tied to the hardware or not. If it's not, and the legitimate users are willing to give it to others, then that's what will happen.

[David Jondreau]

I thought about getting the system NIC, but if they have multiple NICs, or flip from wifi to hardline, that would cause issues.

You won't have those issues you think you'd have with Get ( SystemNICAddress ). That function returns all of the NIC addresses of a system, regardless of what's being used to connect to a network (something Filemaker doesn't even know or care about is hosting a local solution).

I'd say use a simple algorithm to code each NIC address (they're on separate lines) and that's your license key. The db will use that algorithm on start up and see if there's a match on the keys.

Don't expect to get your file to be completely locked down. That's impossible. You just want it inconvenient for the average user to be able to use it without a license.

[Mark Reed]

I think I have a viable working solution. Instead of going the get nic route, I am getting the machine name and using a formula to convert it to a number. When they register and buy the unlock key, they will supply this number - I then use a formula to create a different number based on it and compare it when they enter it. If it passes the logic, it continues the startup, if not, it prompts them to either register or re-enter a valid key.

Im taking it a step further and building in a demo time - where when the app is first launched it fills the current system date into a hidden field, then upon start up I look to see if that date is within X, once out, I says they must register and buy the unlock key described above.

If I lock down the app where they cannot change that date field, nor even see it, and using the machine name formula to unlock key, I think it will get me what I need.

The only caveat is it will be a manual process - I wont be able to have them register and systematically issue a key online - I will need to personally send the key via email. I know automation could be done, but 1, thats more time and cost - and 2, above my level at this point.

Does my approach seem ok? anyone see any major holes in it?

I guess the issues I see are:

1. what happens if someone renames thier system often? Dont knwo why they would, so this would be the exception to the rule.

2. Buys new PCs often - forcing a re-reg process. Again, Id have to cover that support manually after the sale.

[Vaughan]

I am getting the machine name

Which machine name is that?

Buys new PCs often - forcing a re-reg process. Again, Id have to cover that support manually after the sale.

What kind of service response are you offering? What if I re-install onto a new machine on Sunday midnight and NEED the database to work for a meeting 9:00 am Monday?

[Mark Reed]

Which machine name is that?

What kind of service response are you offering? What if I re-install onto a new machine on Sunday midnight and NEED the database to work for a meeting 9:00 am Monday?

get Hostname - which is the machine name on the mswindows side of the house.

As for service response, this app isnt something like a business ERP system or anything of the like - its more of an app geared towards hobbyists of a specific area.

You make a good point though of possibly isolating a user if they wanted to reinstall and run right away.

Not sure how to accomplish that on this - if it were a larger scale project, Id look at some web based type key issue ect... but this is such a narrow project, and small return that it doesnt allow for something that elaborate.

Any suggestions from folks out there reading this?

one thing that would solve the reinstall issue is that I have a 30 day "trial" time built in, and by reinstalling, it would allow that 30 days again.

Now having it this way leaves the hole open for someone to keep doing a backup of the data, reinstalling, then recovering the back up - but I think I may have an idea how to get around that - where a file is written to a location other than the app directory and is checked to see if it is there. if it is, limit the demo to a few days, or even not at all.

[David Jondreau]

get Hostname - which is the machine name on the mswindows side of the house.

As for service response, this app isnt something like a business ERP system or anything of the like - its more of an app geared towards hobbyists of a specific area.

You make a good point though of possibly isolating a user if they wanted to reinstall and run right away.

Not sure how to accomplish that on this - if it were a larger scale project, Id look at some web based type key issue ect... but this is such a narrow project, and small return that it doesnt allow for something that elaborate.

Any suggestions from folks out there reading this?

Now having it this way leaves the hole open for someone to keep doing a backup of the data, reinstalling, then recovering the back up - but I think I may have an idea how to get around that - where a file is written to a location other than the app directory and is checked to see if it is there. if it is, limit the demo to a few days, or even not at all.

Based on your target market, I'd say use Get(HostName) and put in some disclaimers in your About... page and when you sell it. Something about changing system settings may make the file not work until they contact you and it may take a few days, or weeks.

You're not going to stop a serious hacker, but you can make it pretty inconvenient for a user to steal.

[qube99]

Let me ask a real stupid question. Why worry about it?

Reminds me of an ecommerce client who wanted to prevent people from stealing his product images. He just wouldn't believe me when I told him no one wanted his images and it was impossible to protect anything displayed on a web page. He spent weeks and months trying to protect those images.

It's like a songwriter worried about someone stealing their song. The only answer is to never perform it for anyone.

An easy way to bind an app to hardware is to have it write an invisible text file to the hard drive the first time it runs. Then check for that file each launch thereafter. No copy would possibly work. No key codes needed, either.

Of course, someone who knew how it worked could use a resource editor to discover the invisible file, turn it visible, unlock it and then copy it. the question is - who would bother?

[No_access]

With this type of thing I tend to follow the 80 / 20 rule, I would not build a system around 20%, I would only focus on the 80, thus I would not put to much into people stealing your software. If your software is good and the price is reasonable those who need it will buy, those who would steal it, wouldn't buy it anyways.

However your could do something as simple as

Substitute ( text ;

["a";"b"];

["A";"B"];

["c";"d"];

["C";"D"];

["e";"f"];

["E";"F"];

["g";"h"];

["G";"H"];

["i";"j"];

["I";"J"];

["k";"l"];

["K";"L"];

["m";"n"];

["M";"N"];

["o";"p"];

["q";"r"];

["Q";"R"];

["O";"P"];

["S";"#"];

["s";"1"];

["t";"2"];

["T";"@"];

["U";"3"];

["u";"&"];

["v";"4"];

["V";"$"];

["w";"5"];

["W";"*"];

["x";"8"];

["X";"+"];

["y";"9"];

["Y";";"];

["Z";"="];

["z";"s"]

)

[FMDuck]

I have two solutions that I sell. It's kind of one solution that changes drastically from version to version because of the small size of the industry that it supports. One 'solution' has up to about 25 users per installation and the other is single-user stand-alone. I've had them for about 25 years.

The first time I developed the smaller runtime solution, I had it pretty well open. I did add the customer's name to the screens with a warning. The piracy to sales ratio was about 75/25 so I got paid for about 1 in 4 copies. The first thing to consider though is that many of the people who will make illegal copies may not purchase it anyway so your loses aren't really that high but of course you really don't have any way to know exactly how many people use illegal copies or how many people would have purchased it so you can only guess.

Possibly consider releasing the first version without some key features and let it get out there. Once people start using the software they become used to it and their employees could get very comfortable with it. Then in the next release include the features that were left out and then include the tighter controls so once they install it, they can see the new features but will have to purchase the new version.

I mentioned that I have the big and small versions because in the big version I have MANY controls but I don't have a phone home feature because of military restrictions. I use Ray Cologon's CreateUID cf set which is free. It binds to the NICs, timestamp and record ID and works very well for me. I also have a grace period for activation and if the solution is moved, the grace period starts over again. This way not only does the user have the chance to move it to a new computer but if they share it with someone, that person can start using it just like a demo but it will expire. No data can be exported until it's activated. An issue with this is that it assumes that the historical data is of value and the grace period really doesn't work if the person doesn't care about maintaining data. I also use Ray's DataVaultMaker and have a key based on multiple fields so the NIC is only part of it but that's in the big solution.

Because FMP captures all the NICs, you're safe no matter if the user turns on wireless or not. You can check to see if any one NIC matches what you've stored and if so, recapture all of them in case one has gone out or they're running from a server and swapping NICs or something else. This isn't fool proof and isn't great for a server but it sounds like it would cover almost every NIC based control.

You could also write to the registry on Windows or add a hidden file somewhere but my experience is that I want to keep it simple enough that I can have a non-technical person support installation problems.

There really is much more to consider but hopefully this gives you a starting point. I have a honkin' long post here that goes a bit more in depth.

HTH

[FMDuck]

What no_access posted is another part of my security and it's also real easy. Sorry for the cut-and-paste screen shot rather than a file (I have a lot I'd have to clean out of the file to post it) but here's part of a code generator that I use that create the a code for the solution. One set of fields goes into a custom function in the solution and the other goes into my decoder. and a matching one for my decoder. The number which is the base of the code can come from the NIC, a date, license qty, whatever. Set the custom function Availability to Only accounts with full access to keep it hidden.

Note that FileMaker has a 164 pair limit in the Case function.

License Control Module.pdf

LCM Result.pdf

LCM cf in the solution.pdf